mailing list archives
Re: Using TTL value of response packets on nmap port scans.
From: David Fifield <david () bamsoftware com>
Date: Wed, 11 Apr 2012 10:14:44 -0700
On Wed, Apr 11, 2012 at 07:52:22AM +0300, Otto Airamo wrote:
Currently Nmap is not detecting, by default, if there is
firewall/IDS resetting connections between target host/network and
Let's taken an example:
Between scanner and target host, there is a firewall blocking all
other ports than 80 and 443. Firewall refuses connections by sending
RST. Currently result of the scan is that ports 80 and 443 are open,
rest are closed. If Nmap would follow TTL values, it could trivially
detect that there is third party device generating RST packets as
TTL value of responses differs.
I'm aware that Nmap already provides " -badsum" options to solve
same problem, but I believe that my suggested approach is more
elegant way to solve the problem. At least when option -sS is used
(raw sockets), it would be very easy to get TTL value of the packet
and do some automatic detection if there is firewall or IDS.
(Actually detecting firewall should be 100% sure. If firewall and
target host uses same initial TTL value, firewall should have at one
or more higher TTL. Detection with IDS is not as sure. IDS might
have same TTL value if it is located into same layer-two segment as
I'm aware that there can be scenarios where altering TTL values from
single host do not automatically mean FW/IPS. Certain load balancing
scenarios and NAT decisions based on port information are likely to
produce results where port scan to single IP address will produce
reply packets with different TTL values. Reply packets may also be
routed via different route when TTL value will not be same.
Nmap does in fact keep track of TTLs of response packets. I think it is
only exposed in the XML output with --reason, though:
# nmap --reason nmap.org -F -oX -
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="53"/>
I'm afraid I don't understand what you're proposing. A new output for
Nmap? A script that processes the TTL values?
It would be very helpful if you could show us an example of what Nmap
output would look like with your proposed change.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/