Re: Rejecting udp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I am trying to remember my networking class.... 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
>

The normal thing to do would be to DROP unwanted UDP, however it
is possible to use a --reject-with and return an ICMP with "port
unreachable"
or "host unreachable" or similar if you want.

Mike





>
> > ----- 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
>
>
>
>
>



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux