Around The Globe ATG.WORLD

Visit our sister website :

http://www.atg.world/

This is a social network for enthusiasts just like us. No Junk! Only meaningful conversations with the people who share the same enthusiasm as us.

Around The Globe ATG.WORLD

Visit our sister website :

http://www.atg.world/

This is a social network for enthusiasts just like us. No Junk! Only meaningful conversations with the people who share the same enthusiasm as us.

Thursday, August 13, 2009

ICMP Scanning - OS Detection

  • There are numerous possible ICMP query messages that one can generate and send across a network. The list is available at: http://www.isi.edu/in-notes/iana/assignments/icmp-parameters.
  • When a host receives a particular type of ICMP query message, then according to its operating system, the host will generate a predefined respond.
  • This response varies from OS to OS and the contents of the response generated due to the ICMP messages varies from one OS to another and is same for one type of OS.
  • In other words, the response of a host to a particular type of ICMP message is hugely dependent on the OS running on it.
  • The same ICMP message sent to a UNIX system and a Windows system, will generate two different responses. This difference in responses, exists due to different Operating Systems.
  • By sending ICMP messages to a host and comparing the responses invoked against the known responses, one can deduce the OS running on the host.

ICMP Error Message Quenching -- Some (smart) operating systems limit the rate at which various error messages are sent. 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. One way to test this is to send a bunch of packets to some random high UDP port and count the number of unreachables received. This test would make the OS detection take a bit longer since you need to send a bunch of packets and wait for them to return, so it is hardly used in any scanner. Also dealing with the possibility of packets dropped on the network would be a pain.


ICMP Message Quoting -- The RFCs specify that ICMP error messages quote some small amount of an ICMP message that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows NMap to recognize Linux and Solaris hosts even if they don't have any ports listening.


ICMP Error message echoing integrity -- Machines have to send back part of your original message along with a port unreachable error. Yet some machines tend to use your headers as 'scratch space' during initial processing and so they are a bit warped by the time you get them back. For example, AIX and BSDI send back an IP 'total length' field that is 20 bytes too high. Some BSDI, FreeBSD, OpenBSD, ULTRIX, and VAXen fuck up the IP ID that you sent them. While the checksum is going to change due to the changed TTL anyway, there are some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. Same thing goes with the UDP checksum. All in all, nmap does nine different tests on the ICMP errors to sniff out subtle differences like these.need to send a bunch of packets and wait for them to return. Also dealing with the possibility of packets dropped on the network would be a pain.

No comments:

Post a Comment