Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Raymond Leach <raymondl@knowledgefactory.co.za>
To: Netfilter Mailing List <netfilter@lists.netfilter.org>
Subject: Re: Rejecting udp
Date: 04 Mar 2003 13:26:22 +0200	[thread overview]
Message-ID: <1046777181.3924.1.camel@raylinux.internal> (raw)
In-Reply-To: <33803.192.222.90.38.1046775610.squirrel@pelorus.org>

[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]

I suppose being able to reject UDP packets is just allowing you to
control access to a service that may be listening on that UDP port. For
example blocking the nimba virus by rejecting UDP port 137,138,139.

On Tue, 2003-03-04 at 13:00, Skip Morrow wrote:
> I am trying to remember my networking class (/me shakes the cobwebs out)
> 
> I think that the original question is a good question.  UDP packets
> (legitimately) arriving at my computer are not acknowledged.  That is, I
> don't tell the sender "Yeah, I got that packet.  Thanks."  Nor, do I tell
> the sender "Whoops.  I didn't quite get all of that last packet.  Could
> you send it again?" So, REJECTing a UDP packet doesn't make sense.  The
> sender isn't looking for any type of OK message or anything for that
> matter.  In fact, where would the REJECT message go?  Does the sender even
> have a listen port open?
> 
> But then again, I could be completely wrong.
> 
> Regards,
> Skip
> 
> > ----- Original Message -----
> > From: "Michael K" <micke@klintan.se>
> > To: <netfilter@lists.netfilter.org>
> > Sent: Monday, March 03, 2003 6:28 PM
> > Subject: Rejecting udp
> >
> >
> >> I saw this rule someware on the net.
> >> $IPTABLES -A FORWARD -o $EXTERNALIF -p udp --dport 137 -j REJECT
> >>
> >> Whats the use to use reject on a UDP packet? Isn't udp connection-less
> >> A more correct shouldn't that be "-j DROP"? Or am I thinking wrong
> >> here?
> >>
> >> Regards Klintan
> >>
> >
> > First of all: This has little to do with TCP or UDP (or connection-less
> > stuff).
> >
> > Many firewalls have a policy to drop packets coming from the outside
> > when nothing on the inside has started communicating to the internet
> > (outside). But, port 137 is part of the SMB (filesharing) protocol. It
> > starts inside your network, broadcasting that services are available.
> > The firewall will see this as legitimate traffic, since it started on
> > the inside.
> > If you wouldn't block port 137, you'd be broadcasting to the internet
> > that you have filesharing enabled on your network, thereby opening up
> > port 137 to the internet, as the firewall sees no danger.
> > The next step for a cracker would be easy, get into your filesharing
> > network, steal passwords or worse...
> > Simply: Things that "You Don't Want to Happen" (TM).
> >
> > Short answer: You do want to filter port 137 (and 138/139).
> >
> > A good approach is to block all traffic to the firewall/internet from
> > the inside, then open op ports (POP, SMTP, HTTP and other services) as
> > needed, but no more then what's needed.
> >
> > HTH,
> > Willem
> 
> 
-- 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-03-04 11:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 17:28 Rejecting udp Michael K
2003-03-03 17:38 ` Athan
2003-03-03 20:14   ` Arnt Karlsen
2003-03-04  0:08 ` Willem Oldeman
2003-03-04  2:42   ` Skip Morrow
2003-03-06 10:53     ` Michael J. Tubby B.Sc. (Hons) G8TIC
2003-03-04 11:00   ` Skip Morrow
2003-03-04 11:26     ` Raymond Leach [this message]
2003-03-04 13:31       ` Skip Morrow
2003-03-04 23:51         ` Arnt Karlsen
2003-03-05 10:03           ` Maciej Soltysiak
2003-03-06 19:53     ` Manuel Samper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1046777181.3924.1.camel@raylinux.internal \
    --to=raymondl@knowledgefactory.co.za \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox