mailing list archives
Re: Updated: ICMP Error Message Quoting Size (Identifying Sun Solaris, HP-UX 11.x and LINUX based machines)
From: Fyodor <fyodor () insecure org>
Date: Sat, 25 Nov 2000 19:52:15 -0800 (PST)
On Sat, 25 Nov 2000, Ofir Arkin wrote:
Except for LINUX, Sun Solaris, and HP-UX 11.x based machines all other
operating systems will closely follow RFC 1122 guidelines ? quoting the IP
Header and the first 8 bytes of data of the offending packet.
I would be careful about saying things like "all other operating systems".
There are a lot of them out there. For example, I'll bet you didn't try
the Ricoh Aficio AP4500 Network Laser Printer :). It does send back more
than 8 bytes (it sends back the entire packet, in fact, at least up to the
Nmap-sized probe of 328 bytes).
But there are also more important operating systems that show this
behavior. Pretty much all MacOS boxes (tested against 7.55, 8.0, 8.1,
9.04) will send back up to 300 bytes of the packet in their
icmp-port-unreach messages. Many switchers & routers ( including some
3Com, Foundry, Alcatel, and Shiva models) also send back more than 8 bytes
). The Nokie IPSO boxes which frequently run Checkpoitn Firewall-1 send
back up to 196 bytes of data.
Also, your statement above implies that Linux, Solaris and HP-UX are not
"closely follow[ing] RFC 1122 guidelines". I don't see anything in that
RFC which suggests sending only 8 bytes. It says upfront that you may
send back as many bytes as you would like, as long as you send at least 8.
Thus it seesm that sending back the entire packet does "closely follow RFC
1122 guidelines" just as well as sending only 8 bytes.
The fact is not new. Fyodor outlined this in his article "Remote OS
Identification by TCP/IP Fingerprinting". The differences between LINUX, Sun
Solaris, and HP-UX 11.x regarding the extra quoting size issue were not been
discussed/discovered (The HP-UX 11.x issue was not discussed at all.
Thanks for the attribution. My paper (
http://www.insecure.org/nmap/nmap-fingerprinting-article.html ) doesn't
try to provide a comprehensive list of how each OS reacts to each of the
probes. I didn't see much point in that since Nmap already comes with a
comprehensive and up-to-date list of hundreds of operating systems and how
they react to the probes.
For an example, to obtain a list of operating systems that return
icmp-port-unreachables and send a different number of bytes back than the
"normal" 28, try (on one line):
egrep -i '^Fingerprint|(^PU.*IPLEN=[^3][^8])' /usr/local/share/nmap/nmap-os-fingerprints | egrep -B1 '^PU'
Note that nmap-os-fingerprints may be in /usr/share instead if you used
the rpm version. It is also in the tarball distro at
If we examine LINUX 2.2.x / 2.4t-x based Kernel, Sun Solaris, and HP-UX 11.x
operating systems behavior with ICMP Port Unreachable we will see the same
pattern regarding the size of quoted information. All will quote the entire
Yes, in this case they do. Although it is worth noting that the maximum
bytelength they quote may differ. For example, Solaris will generally
return up to 64 bytes of data (after the IP header) while Foundry switches
send back up to 20 and Linux sends more than either of them. Nmap uses a
relatively large probe ( 328 bytes) so it can distinguish between these.
With a small probe, it looks like each is sending back the entire
packet. I wanted to send an even larger probe, but I didn't want to risk
problems or fragmentation on low MTU networks (eg many PPP/SLIP
13:14:56.942897 < 127.0.0.1 > y.y.y.y: ip-proto-38 0 (ttl 39, id 37623)
4500 0014 92f7 0000 2726 02cb xxxx xxxx
13:14:56.942964 > y.y.y.y > x.x.x.x: icmp: y.y.y.y protocol 38 unreachable
Offending pkt: x.x.x.x > y.y.y.y: ip-proto-38 0 (ttl 39, id 37623) [tos
0xc0] (ttl 255, id 1884)
45c0 0044 075c 0000 ff01 b59a yyyy yyyy
xxxx xxxx 0302 fb1a 0000 0000 4500 0014
92f7 0000 2726 02cb xxxx xxxx yyyy yyyy
0050 dc84 ae6f 6910 0000 0000 5004 0000
LINUX adds to the entire offending packet that was quoted, another 20 bytes.
Hmm ... that is an interesting find! Has anyone checked the source to see
what is going on there? In particular, I wonder where the 20 bytes came
from. Any information leakage?
Another thing that might be worth checking into is whether all operating
systems correctly send back the FULL IP HEADER plus at least 8 bytes. I
wonder if some just assume the IP header is 20 bytes and so they just send
back the first 28 bytes of the packet. Obviously you can bloat the header
size through IP options and other factors. That could be useful for OS
For help using this (nmap-hackers) mailing list, send a blank email to
nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).