Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Proving a UDP port is closed

by Limbic~Region (Chancellor)
on Feb 01, 2011 at 14:31 UTC ( #885501=note: print w/ replies, xml ) Need Help??


in reply to Proving a UDP port is closed

davis,
Wouldn't it just be easier to parse a system call to netstat?

Cheers - L~R


Comment on Re: Proving a UDP port is closed
Re^2: Proving a UDP port is closed
by davis (Vicar) on Feb 01, 2011 at 14:54 UTC
    *nods at L~R

    Hmmm. Maybe; I hadn't really thought of that... However, I'm not sure that a netstat would show all services that are started by inetd (the reason I switched to rpcbind here is because more people are likely to have rpcbind available, hence the failure's easier to prove). I'm also trying to get as close to evidential proof as possible -- e.g. "You want port 1234 closed?": "Let's prove it's closed by trying to connect to it"


    davis

      davis,
      The netstat command shows network information and is not concerned with what services/processes are running. Also, inetd isn't magical and can't establish a connection without a listener. In order for the server to accept connections on a port then there has to be a listener for that port. The netstat command can be used to show what listeners are out there.

      As far as proving it by attempting to connect to it, I would have no way of testing presently.

      Cheers - L~R

        Sorry, I realised the stupidity of what I'd said (the implied magic) fairly quickly! Yeah, grokking the "netstat -af inet" output would almost certainly work for me for both TCP and UDP listeners, but there's still something somehow... cleaner about the attempted connection method, at least in my head.

        davis

Re^2: Proving a UDP port is closed
by gman (Friar) on Feb 01, 2011 at 14:59 UTC

    I would recommend reading the man page for nmap;

    "Upon hitting a closed port on the target machine, the UDP probe should elicit an ICMP port unreachable packet in return. This signifies to Nmap that the machine is up and available. Many other types of ICMP errors, such as host/network unreachables or TTL exceeded are indicative of a down or unreachable host. A lack of response is also interpreted this way. If an open port is reached, most services simply ignore the empty packet and fail to return any response. This is why the default probe port is 31338, which is highly unlikely to be in use. A few services, such as chargen, will respond to an empty UDP packet, and thus disclose to Nmap that the machine is available."

    AND

    " -sU (UDP scans) While most popular services on the Internet run over the TCP protocol, UDP3 services are widely deployed. DNS, SNMP, and DHCP (registered ports 53, 161/162, and 67/68) are three of the most common. Because UDP scanning is generally slower and more difficult than TCP, some security auditors ignore these ports. This is a mistake, as exploitable UDP services are quite common and attackers certainly donĀ“t ignore the whole protocol. Fortunately, Nmap can help inventory UDP ports. UDP scan is activated with the -sU option. It can be combined with a TCP scan type such as SYN scan (-sS) to check both protocols during the same run. UDP scan works by sending an empty (no data) UDP header to every targeted port. If an ICMP port unreachable error (type 3, code 3) is returned, the port is closed. Other ICMP unreachable errors (type 3, codes 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a service will respond with a UDP packet, proving that it is open. If no response is received after retransmissions, the port is classified as open|filtered. This means that the port could be open, or perhaps packet filters are blocking the communication. Versions scan (-sV) can be used to help differentiate the truly open ports from the filtered ones. A big challenge with UDP scanning is doing it quickly. Open and filtered ports rarely send any response, leaving Nmap to time out and then conduct retransmissions just in case the probe or response were lost. Closed ports are often an even bigger problem. They usually send back an ICMP port unreachable error. But unlike the RST packets sent by closed TCP ports in response to a SYN or connect scan, many hosts rate limit ICMP port unreachable messages by default. Linux and Solaris are particularly strict about this. For example, the Linux 2.4.20 kernel limits destination unreachable messages to one per second (in net/ipv4/icmp.c). Nmap detects rate limiting and slows down accordingly to avoid flooding the network with useless packets that the target machine will drop. Unfortunately, a Linux-style limit of one packet per second makes a 65,536-port scan take more than 18 hours. Ideas for speeding your UDP scans up include scanning more hosts in parallel, doing a quick scan of just the popular ports first, scanning from behind the firewall, and using --host-timeout to skip slow hosts. "

      I'm aware of nmap, thanks. The problem is that my code above shows _no_difference_ between a closed and an open UDP port. I understand that I might have to try timing out, and that I might have to lump all "connection failed" responses together, and I'm completely fine with that.

      Edit: Holy cow. I just realised that gman and I joined PM about 2 weeks apart. Almost 10 years ago!

      davis

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://885501]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (4)
As of 2014-09-20 20:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (161 votes), past polls