From: "Willem Oldeman" <willem@king-pin.nl>
To: Michael K <micke@klintan.se>, netfilter@lists.netfilter.org
Subject: Re: Rejecting udp
Date: Tue, 4 Mar 2003 01:08:24 +0100 [thread overview]
Message-ID: <003f01c2e1e2$2d9bd100$0301a8c0@hotpop3> (raw)
In-Reply-To: 000801c2e1aa$3fc8f660$0200a8c0@klintan.local
----- 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
next prev parent reply other threads:[~2003-03-04 0:08 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 [this message]
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
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='003f01c2e1e2$2d9bd100$0301a8c0@hotpop3' \
--to=willem@king-pin.nl \
--cc=micke@klintan.se \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.