Re: Block UDP Ports?
From: NetAdmin (email@example.com)
- Next message: Greg Hennessy: "Re: Do I need a firewall"
- Previous message: Fox: "Re: Version 3.5X VSMON eating CPU"
- In reply to: DougNews: "Re: Block UDP Ports?"
- Next in thread: Stupified: "Re: Block UDP Ports?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "NetAdmin" <firstname.lastname@example.org> 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
> UDP scanning is questionable to many - if the port is open, it doesn't
> send an acknowledgement. Closed ports are not required to send an error
> but some firewalls do so the scan looks for those not reporting as open.
> to tell if it is open or closed is problematic. You may be blocking the
> with the firewall (which one?) and it doesn't respond so the scan reports
> UDP ICMP port unreachable scanning : This scanning method varies from the
> in that we are using the UDP protocol instead of TCP. While this protocol
> simpler, scanning it is actually significantly more difficult. This is
> open ports don't have to send an acknowledgement in response to our probe,
> closed ports aren't even required to send an error packet. Fortunately,
> hosts do send an ICMP_PORT_UNREACH error when you send a packet to a
> port. Thus you can find out if a port is NOT open, and by exclusion
> which ports which are. Neither UDP packets, nor the ICMP errors are
> to arrive, so UDP scanners of this sort must also implement retransmission
> packets that appear to be lost (or you will get a bunch of false
> Also, this scanning technique is slow because of compensation for machines
> took RFC 1812 section 18.104.22.168 to heart and limit ICMP error message rate.
> example, the Linux kernel (in net/ipv4/icmp.h) limits destination
> message generation to 80 per 4 seconds, with a 1/4 second penalty if that
> exceeded. At some point I will add a better algorithm to nmap for
> this. Also, you will need to be root for access to the raw ICMP socket
> for reading the port unreachable. The -u (UDP) option of nmap implements
> scanning method for root users.
> Some people think UDP scanning is lame and pointless. I usually remind
> the recent Solaris rcpbind hole. Rpcbind can be found hiding on an
> UDP port somewhere above 32770. So it doesn't matter that 111 is blocked
> 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
> when they have been received. For example a second write() call to a
> will usually fail. A lot of scanners such as netcat and Pluvius' pscan.c
> this. I have also noticed that recvfrom() on non-blocking UDP sockets
> return EAGAIN ("Try Again", errno 13) if the ICMP error hasn't been
> and ECONNREFUSED ("Connection refused", errno 111) if it has. This is the
> technique used for determining open ports when non-root users use -u
> users can also use the -l (lamer UDP scan) options to force this, but it
> really dumb idea.
> "NetAdmin" <email@example.com> wrote in message
> 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
> 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
> here to the newsgroup because my e-mail addy is fake. Thanks.