Dealing with initial TTLs > 255

[David Fifield <david () bamsoftware com>]

Fyodor and I noticed that some OS fingerprint submissions had a
calculated TTL that was greater than 255. Values of 256, 257, 258, and
even 263 have been submitted. Values like these indicate some sort of
network shenanigans. They also hinder OS detection, because while these
initial TTLs are probably supposed to be 255, they won't match prints in
the database with the value of 255.

r4950 in /nmap-exp/soc07/nmap deals with this. It caps too-large TTLs at
255 (the most likely value, I think). If any large TTLs are found, it
marks a fingerprint as unsuitable for submission, because something
strange is probably going on in the network.

Unfortunately, this sort of network strangeness is only detectable with
a true initial TTL near 255. With a lower initial TTL on the target
host, the results will still be anomalous, but it won't be as obvious
because the initial TTLs will still be in the valid range.

Here's a way to reproduce the network conditions that lead to this using
Linux. The target host must be on a different network segment than the
scanning host.

Set the TTL on the target host to 255:
        # echo 255 > /proc/sys/net/ipv4/ip_default_ttl
On the scanning host, set the TTL for outgoing packets to something low,
overriding whatever Nmap chooses:
        # iptables -t mangle -I POSTROUTING -o eth0 -j TTL --ttl-set 35
Scan:
        # nmap -O2 -d <target>
You will observe a very large network distance (more than 15 hops) and
out-of-range initial TTLs.

To put things back the way they were, run
        # echo 64 > /proc/sys/net/ipv4/ip_default_ttl
on the target host and
        # iptables -t mangle -D POSTROUTING 1
on the scanning host.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org