Re: [Patch] Showing TTL in default output

[Jay Bosamiya <jaybosamiya () gmail com>]

Otto,

I think I understand what you mean. However, correct me if I am wrong.

What you propose is that Nmap should just do an analysis of the TTLs
(after scan is done, not sending any extra packets) and then report to
the user if it finds any indication of a firewall (for example, "Note:
Due to the different TTLs in SYN-ACK and RST packets, Nmap has very
strong reason to believe that the target might be protected by an
external security device").

I think that this might be a nice addition to Nmap, especially since it
gives the user some extra information without having to do anything
extra. :)

I will look into this as time permits.

BTW, in http://seclists.org/nmap-dev/2014/q3/33, John seems to be
suggesting the same (although for a different reason - for improving OS
detection).

Cheers,
Jay

On Tuesday 29 July 2014 11:40 AM, Otto Airamo wrote:
> This new feature is implementing almost what I was suggesting in following posting a couple of years ago:
> http://seclists.org/nmap-dev/2012/q2/129
>
> With just a small change to this patch, nmap could detect and report in there is a security device between scanner 
> and target host generating RST packets for the scanned SYN packets. With this approach, external behavior of nmap 
> does not need to change as no extra packets are sent to the network.
>
> In my proposal TTL handling logic would be improved to detect situation where external security device is generating 
> fake RST packets. As things get very interesting when TTL values are same for echo-reply packets and SYN-ACK packets, 
> but different with RST packets. I believe that in most cases, this is very strong indication of external L2/L3 
> security device generating fake RST packets. With this information penetration tester can learn that it is unknown if 
> port in target host is open or closed after bypassing security device between.
>
> Best regards
> Otto Airamo

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