Rejecting udp

Rejecting udp

[Michael K]

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

Re: Rejecting udp

[Athan]

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

On Mon, Mar 03, 2003 at 06:28:01PM +0100, Michael K wrote:
> 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?

   REJECT is "return some ICMP code saying 'no go'" usually something
like 'port unreachable'.
   DROP is "just forget about this packet, send nothing back to the
source".

  Thus the difference has nothing to do with connectionful vs.
connectionless.

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Rejecting udp

[Arnt Karlsen]

On Mon, 3 Mar 2003 17:38:06 +0000, 
Athan <netfilter@miggy.org> wrote in message 
<20030303173805.GB24602@miggy.org>:

> On Mon, Mar 03, 2003 at 06:28:01PM +0100, Michael K wrote:
> > 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?
> 
> REJECT is "return some ICMP code saying 'no go'" usually something
> like 'port unreachable'.
> DROP is "just forget about this packet, send nothing back to the
> source".

...the latter is appropriate for your external interface to evade 
scriptkiddies looking for easy enough prey, while you may prefer 
the former for your internal lan wintendo users, to help them avoid 
stalling their wintendos on trying to share files.
 
> Thus the difference has nothing to do with connectionful vs.
> connectionless.
> 
> -Ath


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: Rejecting udp

[Willem Oldeman]

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

Re: Rejecting udp

[Skip Morrow]

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

Re: Rejecting udp

[Michael J. Tubby B.Sc. (Hons) G8TIC]

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

Re: Rejecting udp

[Skip Morrow]

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

Re: Rejecting udp

[Raymond Leach]

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

Re: Rejecting udp

[Skip Morrow]

I agree that it is important to block certain UDP ports/traffic.  What the
issue is, is what is the purpose of REJECTing a UDP packet versus DROPping
the UDP packet?  My point is, sending back a REJECT message doesn't make
sense with UDP.

Skip

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

Re: Rejecting udp

[Arnt Karlsen]

On Tue, 4 Mar 2003 08:31:34 -0500 (EST), 
"Skip Morrow" <skip-lists@pelorus.org> wrote in message 
<39942.192.222.90.38.1046784694.squirrel@pelorus.org>:

> I agree that it is important to block certain UDP ports/traffic.  What
> the issue is, is what is the purpose of REJECTing a UDP packet versus
> DROPping the UDP packet?  My point is, sending back a REJECT message
> doesn't make sense with UDP.

..I agree.  In my response to Athan, I was thinking tcp.  
And for testing, and developing sniffers, you sniff everywhere 
anyway.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: Rejecting udp

[Maciej Soltysiak]

> > I agree that it is important to block certain UDP ports/traffic.  What
> > the issue is, is what is the purpose of REJECTing a UDP packet versus
> > DROPping the UDP packet?  My point is, sending back a REJECT message
> > doesn't make sense with UDP.
Why not? RFCs say that a closed UDP port should elicit
icmp dest.unreach./port unreach.
So it does make sens to be in conformance with the standards.

That is how portscanners see if a port is closed or not. If you drop the
packets, it may mean that the port is either open or is filtered.

Regards,
Maciej

Re: Rejecting udp

[Manuel Samper]

Skip Morrow, on Tuesday, Mar  4 2003 at 12:00, 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.

Maybe. UDP connectionless means any protocol lying on top should
implement their own connection tracking mechanism if it wants one, tftp
is an example that comes to my mind (http://www.ietf.org/rfc/rfc1350.txt
if you are curious).

I don't knwon the SMB internals, but it's wise to reject a blocked port
from inside your lan instead of let any timeouts expire, as someone
noted.

	Manuel