Using TTL value of response packets on nmap port scans.

[Otto Airamo <otairamo () kapsi fi>]

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.

This proposal is not perfect and has know limitations. I still believe that in 
many cases it would add some value. For that reason my proposal is to add TTL 
value (either by default of behind some parameter) to port scan result. In 
addition to that scan result should inform user that there is likely some 
active device causing these RST packets. (that are reiceved with different TTL 
value than SYN-ACK packets). Similar behavior can be applied to other protocols 
as well.

Best regards,
Otto Airamo

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