Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Using TTL value of response packets on nmap port scans.
From: Otto Airamo <otairamo () kapsi fi>
Date: Sat, 14 Apr 2012 00:27:22 +0300 (EEST)

On Thu, 12 Apr 2012, David Fifield wrote:

On Fri, Apr 13, 2012 at 07:11:34AM +0300, Otto Airamo wrote:

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.

SYN-ACK packet is received. In most cases this means that port is open in
target host.

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
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

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

Thanks for explaining what you mean. The output example especially makes
it clear.

I don't think we would add a TTL column to the output by default. The
information is already in the XML for tools that want to use it. Also,
by convention, states like "closed" are understood to mean that a RST
was received, or whatever else is appropriate for the type of port scan.
The --reason flag is for those who want to see the reason without any

The firewalk script also does what you describe in a thorough manner.

David Fifield


is not really doing same thing as there TTL value of scanner host is alternated. In my idea scanner does not change anything compared to regular scan. It is just using result of the TTL value target host is sending. I believe that --badsum option is actually closer to behavior that I am proposing.

Main benefit with my proposal is that behavior outside of the nmap does not need to change. There is no need to send any extra packets to detect situation I descript in previous emails. That was the main thing that I wanted to bring out this idea. I wanted to get some comments if this would give some real added value in real life scenarios.

TTL value would be trivial to add to nmap output with some new flag. Would you add this to mainstream if patch would be provided? If you see that this does not add any value in real life scenarios, let's not add just one more "use-only-in-a-lab" command line parameter.

Otto Airamo

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

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