[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Port Scan for UDP



I can't believe nobody has answered this correctly yet.  UDP is 
different than TCP in that it is a stateless protocol, and that means 
you have to understand a few things to interpret UDP port scan results 
correctly.  With TCP scans, you get one of three results:  OPEN 
(meaning that the TCP handshake sequence to open a connection 
completed), CLOSED (meaning that the target sent a "port closed" ICMP 
message), or FILTERED (meaning that no response was received at all: 
this is also called "stealthed" by so-called "security experts" like 
Steve Gibson but it's a good idea to ignore him just on general 
principles).

UDP is a completely stateless protocol, though.  Even if you send a UDP 
packet to a port that a valid daemon is listening on, the system isn't 
obligated to send anything back to you at all: there is no handshake 
sequence to establish a connection.  So making a determination is 
harder than with TCP.  If you receive a "port closed" ICMP message, the 
port can be safely listed as CLOSED, but if you receive nothing at all, 
that could mean that the port is either OPEN or FILTERED -- it's pretty 
much impossible to tell the difference.

NMAP assumes that every UDP port that it doesn't receive a responsee 
from is OPEN, which means that if you have your firewall DROP all UDP 
connections, every UDP port will appear as open.  If you want to fix 
this, have your firewall REJECT instead of DROP, and the ports will 
appear correctly as CLOSED to a port scan.  DROPing connections without 
a response is in violation of the RFCs, too, if you care about that 
sort of thing.  Having the local machine portscan itself will also tell 
you which UDP ports are *actually* open, because I assume you don't 
have your firewall set to DROP packets from itself.

Also, did you know that by default, nmap only scans ports listed in its 
services file?  So although it scans commonly-used ports, it's not 
scanning the entire system.  If you have enough time (this will make 
the scan very slow, especially over a slow network link), use the "-p 1-
" argument to every scan to force nmap to scan every port from 1 to 
65535 instead of just the maybe 400 or 500 ports that it has listed in 
its services file.  That's the only way you can get a complete picture 
of what your box looks like from the outside.

> I'm doing portscans on a system I'm working to learn more about
> securing hosts and setting up iptables.  My tcp portscan reported
> what I expected, only www, ssh and smtp listening.  The udp
> portscan reported a huge list of 'open' ports.  I really didn't
> know what to expect for this scan, so I want to know if this is
> normal.  Just for grins, I removed every udp listing in
> /etc/services and restarted inetd and the scan came back the
> same.  I figure this is normal, but if someone can confirm this
> behaviour, I'd really appreciate it.
> 
> If this isn't secure behaviour, perhaps I can add an iptables
> entry like:
> 
> iptables -A INPUT -p udp -j drop
> 
> However, I don't have any applications running using udp, so the
> 'open' port doesn't have anywhere to go, as far as I know. 
> Again, if someone can confirm this, I'd really appreciate it.
> 
> thanks,
> jc

-- 
Craig McPherson
Information Technology Coordinator
Baptist Collegiate Ministry



Reply to: