Re: Block UDP Ports?

From: NetAdmin (netadmin@here.com)
Date: 02/04/03


From: "NetAdmin" <netadmin@here.com>
Date: Tue, 04 Feb 2003 22:25:46 GMT

I'm using Checkpoint Firewall-1. I think it sounds reasonable that we are
blocking them but the scanner is giving a false open... it doesn't seem
reasonable that Firewall-1 would leave UDP wide open.

"DougNews" <dougnews@Doesn'tWork.net> wrote in message
news:E9V%9.80684$HG.15601977@news4.srv.hcvlny.cv.net...
> UDP scanning is questionable to many - if the port is open, it doesn't
have to
> send an acknowledgement. Closed ports are not required to send an error
message
> but some firewalls do so the scan looks for those not reporting as open.
So how
> to tell if it is open or closed is problematic. You may be blocking the
ports
> with the firewall (which one?) and it doesn't respond so the scan reports
it as
> open:
>
> http://www.insecure.org/nmap/nmap_doc.html
>
> UDP ICMP port unreachable scanning : This scanning method varies from the
above
> in that we are using the UDP protocol instead of TCP. While this protocol
is
> simpler, scanning it is actually significantly more difficult. This is
because
> open ports don't have to send an acknowledgement in response to our probe,
and
> closed ports aren't even required to send an error packet. Fortunately,
most
> hosts do send an ICMP_PORT_UNREACH error when you send a packet to a
closed UDP
> port. Thus you can find out if a port is NOT open, and by exclusion
determine
> which ports which are. Neither UDP packets, nor the ICMP errors are
guaranteed
> to arrive, so UDP scanners of this sort must also implement retransmission
of
> packets that appear to be lost (or you will get a bunch of false
positives).
> Also, this scanning technique is slow because of compensation for machines
that
> took RFC 1812 section 4.3.2.8 to heart and limit ICMP error message rate.
For
> example, the Linux kernel (in net/ipv4/icmp.h) limits destination
unreachable
> message generation to 80 per 4 seconds, with a 1/4 second penalty if that
is
> exceeded. At some point I will add a better algorithm to nmap for
detecting
> this. Also, you will need to be root for access to the raw ICMP socket
necessary
> for reading the port unreachable. The -u (UDP) option of nmap implements
this
> scanning method for root users.
> Some people think UDP scanning is lame and pointless. I usually remind
them of
> the recent Solaris rcpbind hole. Rpcbind can be found hiding on an
undocumented
> UDP port somewhere above 32770. So it doesn't matter that 111 is blocked
by the
> firewall. But can you find which of the more than 30,000 high ports it is
> listening on? With a UDP scanner you can!
>
> UDP recvfrom() and write() scanning : While non-root users can't read port
> unreachable errors directly, Linux is cool enough to inform the user
indirectly
> when they have been received. For example a second write() call to a
closed port
> will usually fail. A lot of scanners such as netcat and Pluvius' pscan.c
does
> this. I have also noticed that recvfrom() on non-blocking UDP sockets
usually
> return EAGAIN ("Try Again", errno 13) if the ICMP error hasn't been
received,
> and ECONNREFUSED ("Connection refused", errno 111) if it has. This is the
> technique used for determining open ports when non-root users use -u
(UDP). Root
> users can also use the -l (lamer UDP scan) options to force this, but it
is a
> really dumb idea.
>
>
> "NetAdmin" <netadmin@here.com> wrote in message
> news:_AU%9.79501$c41.2688342@news2.telusplanet.net...
> I was just busy probing my firewall using NMAP and I did a UDP port scan
> with a range of 1-65535. It came back with results listing tons of open
UDP
> ports, in fact it said they were all open. When I do a TCP port scan, it
> says that they are all closed.
>
> I'm using Firewall-1... should I be blocking those UDP ports? If so, how
> would I do it? Any help would be greatly appreciated. BTW... please
reply
> here to the newsgroup because my e-mail addy is fake. Thanks.
>
>
>