Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Using TTL value of response packets on nmap port scans.
From: Otto Airamo <otairamo () kapsi fi>
Date: Wed, 11 Apr 2012 07:52:22 +0300 (EEST)


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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]