Re: Using TTL value of response packets on nmap port scans.

[David Fifield <david () bamsoftware com>]

On Wed, Apr 11, 2012 at 07:52:22AM +0300, Otto Airamo wrote:
> Hello,
>
> Currently Nmap is not detecting, by default, if there is
> firewall/IDS resetting connections between target host/network and
> scanner.
>
> 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
> target host)
>
> 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.

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