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