Nmap Development mailing list archives
Re: Using TTL value of response packets on nmap port scans.
From: Otto Airamo <otairamo () kapsi fi>
Date: Fri, 13 Apr 2012 07:11:34 +0300 (EEST)
Hello, It seems that I was explaining in the details WHAT I would like from Nmap, but I was missing WHY this is needed. When port scan is executed over TCP, there is in most cases three relevant cases that may occur in each port that is scanned. 1) SYN-ACK packet is received. In most cases this means that port is open in target host. 2) No reply. In this case we do not know if target host is listening port. At least it is known that from this scope* this port is not accessible in target host. (*With scope I mean that either network firewall or personal firewall blocks incoming SYN/outgoing RST/ICMP error message. It is possible that port is open in target host and would answer with SYN-ACK if packet would come from, for example, same network or different IP address) Important point here is that WE DO NOT KNOW if port is actually open (from different scope)! 3) RST packet is received. Typically this means that port is closed in target host. If RST packet is generated by target host TCP/IP stack because port is closed, it does not matter what is the scope where we are performing scan. Result will remain same even if scan would be performed from same network/using any source IP address. At the same time RST packet may be generated by firewall located between scanner and target host. If scanner is not able to tell if RST packet is generated by target host or device between, result of the scan will fall into same category as case #2. (We do not know if port is open)If scanner would be able to detect difference between RST packet generated by target host TCP/IP stack and other cases, scanner would have better knowledge of target.
Options are: a) Target host TCP/IP stack generated RST packet => we know that port is closed b) Somebody else than target host TCP/IP stack generated RST packet => we do not know if port is actually open even we do not have access from this scope. Now we have following network setup: scanner -- FW -- target Firewall is configured to RST connections to port 22. Some ports are allowd, mosts of the ports are dropped silently. Result of nmap could be: # nmap --reason target --top-ports=10 Interesting ports on target: PORT STATE SERVICE REASON TTL 21/tcp open ftp syn-ack 62 22/tcp refused ssh reset (ttl?) 63 23/tcp closed telnet reset 62 25/tcp filtered smtp no-response N/A 80/tcp open http syn-ack 62 110/tcp filtered pop3 no-response N/A 139/tcp filtered netbios-ssn no-response N/A 443/tcp filtered https no-response N/A 445/tcp filtered microsoft-ds no-response N/A 3389/tcp filtered ms-term-serv no-response N/A
From this result penetrator tester can assume that telnet port is closed
in target host (TTL is same in RST packet as it is in syn-ack packet). At the same time ssh port seems interesting. Port might still be open even RST packet is received. I think that current nmap implementation works incorrectly by calling port closed even it seems evident that other device is resetting connection. I dont know what would be best term under STATE and REASON for this situation. Now I used terms refused and reset(ttl?). Those terms are not optimal and need to be renamed something better. Does this make it more clear what I'm trying to propose? Regards, Otto Airamo On Wed, 11 Apr 2012, David Fifield wrote:
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/
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Using TTL value of response packets on nmap port scans. Otto Airamo (Apr 11)
- Re: Using TTL value of response packets on nmap port scans. David Fifield (Apr 11)
- Re: Using TTL value of response packets on nmap port scans. Otto Airamo (Apr 12)
- Re: Using TTL value of response packets on nmap port scans. David Fifield (Apr 12)
- Re: Using TTL value of response packets on nmap port scans. Otto Airamo (Apr 14)
- Re: Using TTL value of response packets on nmap port scans. David Fifield (Apr 13)
- Re: Using TTL value of response packets on nmap port scans. Otto Airamo (Apr 12)
- Re: Using TTL value of response packets on nmap port scans. David Fifield (Apr 11)