udp port 135

udp port 135

[cc]

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

Hi,

Can someone comment on the following script as to whether or not
it should work?  (It's related of course to the influx of 135
scans..)

iptables -A INPUT -i $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
iptables -A INPUT -i $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP

iptables -A OUTPUT -o $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
iptables -A OUTPUT -o $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP

Perhaps my understand of UDP packets isn't very deep, so I
might have missed some tidbit regarding the states of udp ports.

But with the above script portion, when I execute:

nmap -sT -p 135 <ext ip>

from a remote machine, I get a host down message. With

nmap -sT -P0 -p 135 <ext ip>,

I get a (135/tcp filtered).  (Good news?)

But with :

nmap -sU -P0 -p 135 <ext ip>,

I get a (135/udp open).

Can someone explain to me what I'm doing wrong or what
information I have forgotten?    Does it even matter
if the udp 135 port is open?  I'm currently in
the process of closing all unneccessary ports
(be it tcp or udp).

Thanks.








** All information contained in this email is strictly     **
** confidential and may be used by the intended receipient **
** only.                                                   **

RE: udp port 135

[Rob Sterenborg]

> iptables -A INPUT -i $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
> iptables -A INPUT -i $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP
                                       ^^^^^^^^^^^

I guess the above and below is are typos ? It should be -d $EXT_IP.

> iptables -A OUTPUT -o $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
> iptables -A OUTPUT -o $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP

-d $EXT_IP --dport 135 should be -s $EXT_IP --sport 135.

> But with :
> 
> nmap -sU -P0 -p 135 <ext ip>,
> 
> I get a (135/udp open).

I have the same results.

> Can someone explain to me what I'm doing wrong or what
> information I have forgotten?    Does it even matter
> if the udp 135 port is open?  I'm currently in
> the process of closing all unneccessary ports
> (be it tcp or udp).

No. I am interested too in why udp shows "open" from a foreign host,
while tcp shows filtered.
How can I check if an udp port is really closed/filtered or opened ?


Gr,
Rob

Re: udp port 135

[Maciej Soltysiak]

> iptables -A INPUT -i $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
> iptables -A INPUT -i $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP
>
> iptables -A OUTPUT -o $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
> iptables -A OUTPUT -o $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP
These are fine to block it.

But you might consider using -j REJECT for UDP, because it is the nature
of UDP that you do not get confirmation of received packets (as with TCP),
you only get confirmation of closed ports (with ICMP dest-unreach).
So by using DROP on udp you are making it look as it is really open.
By using DROP on tcp you are making sure the scanner that you actually
_are_ filtering.

> nmap -sT -P0 -p 135 <ext ip>,
>
> I get a (135/tcp filtered).  (Good news?)
Good. nmap says filtered, when you can ping a host, but do not
get any replies for TCP packets. (when you use DROP).
nmap says closed when it receives TCP-RST for TCP packets or ICMP
dest-unreach for UDP packets.
When you are not giving responses, nmap knows there's something going on:)
Anyway, there are two schools on that.
One says to DROP, to allow as little packet flow as possible, and data
leakage (especially OS fingerprinting)
One says to REJECT with RST for TCP and ICMP for UDP, to go along with the
RFCs.

> But with :
>
> nmap -sU -P0 -p 135 <ext ip>,
>
> I get a (135/udp open).
>
> Can someone explain to me what I'm doing wrong or what
> information I have forgotten?    Does it even matter
> if the udp 135 port is open?

>  I'm currently in the process of closing all unneccessary ports
> (be it tcp or udp).
That's standard security procedure.

> Thanks.
Regards,
Maciej

Re: udp port 135

[cc]

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

Rob Sterenborg wrote:

>>iptables -A INPUT -i $EXT_DEV -p tcp -d $EXT_DEV --dport 135 -j DROP
>>iptables -A INPUT -i $EXT_DEV -p udp -d $EXT_DEV --dport 135 -j DROP
> 
>                                        ^^^^^^^^^^^
> 
> I guess the above and below is are typos ? It should be -d $EXT_IP.
> 
Yup.  They are.  Sorry.  Thought a copy& paste was sufficient. :)

> 
> No. I am interested too in why udp shows "open" from a foreign host,
> while tcp shows filtered.
> How can I check if an udp port is really closed/filtered or opened ?

I'm completely stumped on this issue.

Thanks.



** All information contained in this email is strictly     **
** confidential and may be used by the intended receipient **
** only.                                                   **

Re: udp port 135

[Maciej Soltysiak]

> > No. I am interested too in why udp shows "open" from a foreign host,
Because it received no response.
> > while tcp shows filtered.
Because it received no response.

> > How can I check if an udp port is really closed/filtered or opened ?
For UDP, remotely you can only find out if it is closed (ICMP response
for close port) or filtered/open (No response at all)

> I'm completely stumped on this issue.
To completely graps it, you would have to make tests with tcpdump while
scanning your host with different decisions: REJECT, DROP , --reject-with
tcp-reset, etc...

I did it once, and I know exactly what will nmap say for what it receives.

Regards,
Maciej

Re: udp port 135

[Ralf Spenneberg]

Am Don, 2003-08-14 um 09.54 schrieb cc:
> Rob Sterenborg wrote:
> > 
> > No. I am interested too in why udp shows "open" from a foreign host,
> > while tcp shows filtered.
> > How can I check if an udp port is really closed/filtered or opened ?
> 
> I'm completely stumped on this issue.
There are three possible responses to an udp probe as nmap sends it:

1. Port is closed. OS hopefully sends an ICMP-Port-Unreachable

2. Port is open. Either the application sends an error via UDP or does
not answer at all

3. Port is filtered. No response since the original packet is dropped.

When you compare 2 and 3, you will see that nmap cannot distinguish
between an open and an filtered port. Thus nmap will mark all (drop)
filtered and open ports as open and will recognize only closed and
rejected ports as closed.

Cheers,

Ralf
-- 
Ralf Spenneberg
RHCE, RHCX

Book: Intrusion Detection für Linux Server   http://www.spenneberg.com
IPsec-Howto				     http://www.ipsec-howto.org
Honeynet Project Mirror:                     http://honeynet.spenneberg.org