Re: [Patch] Showing TTL in default output

[Otto Airamo <otto.airamo () kapsi fi>]

My initial point with the proposal was that nmap query does already have all the needed information for TTL analysis 
without sending any extra packets to the network. If the middle box were sending RST, suggested approach would be able 
to detect it in most of the cases just by comparing TTL values of the responses. For example, firewalk script does 
iterate different TTL values and requires extra packets in order to perform required action.

Anyhow, as Dan is saying, there are scenarios where oddities of various IP stacks would make this analyze impossible 
with information available after simple scan.

Implementing TTL analysis in NSE script would allow finding out all the exceptional cases as well where oddness in 
target IP stack requires more iteration. With NSE script approach solution will be more complete.

At the same time, if TTL analysis is implemented in default behavior (with --reason), people would be able to benefit 
this logic always when scan is performed. Does anybody have a good educated guess what would be success rate with 
initial approach in real life networks? Just being curious.

Otto

On 30 Jul 2014, at 20:31, Daniel Miller <bonsaiviking () gmail com> wrote:

> This type of TTL analysis might be suited for a NSE script. Currently, the reason and reason-ttl are not available 
> via the NSE API [1], but that could be remedied easily. This might even make scripts like firewalk.nse [2] simpler, 
> though I haven't looked to see.
>
> Regarding using TTL variance to choose ports for OS fingerprint probing, that could be tricky given the oddities of 
> various IP stacks (different initial TTL values for open vs closed ports, or for TCP vs UDP vs ICMP, etc.). I'd guess 
> a reasonable algorithm would be to
>
> 1. partition the ports according to TTL, with the partitions being (hex) 00-25, 26-45, 46-85, 86-FF. This corresponds 
> to the overwhelmingly most-popular initial TTLs of 0x20, 0x40, 0x80, and 0xFF, with a little wiggle room. 
>
> 2. Then we would choose the partition with the most results (on the completely unfounded assumption that most of the 
> open or closed responses come from the target, not a firewall) and
>
> 3. pick a port from the set of ports in that partition that have the lowest TTL (on the assumption that a firewall is 
> closer to us than our target, and so its TTL would be decremented fewer times).
>
> 4. If all the candidate ports in this set turn out to be tcpwrapped, then we can assume that we picked the wrong 
> partition (and are instead looking at responses from the firewall) and go back to step 2 and pick the partition with 
> the second-most open ports. This is better than going back to 3 because the assumption in 3 is stronger than the one 
> in 2.
>
> This scheme could still be defeated by a firewall that sends responses with an initial TTL that is slightly lower 
> than the target's initial TTL (e.g. target's initial TTL is 0x40, and the firewall 2 hops away from the target sends 
> with initial TTL 0x37, so its responses actually look like they are coming from 6 hops beyond the target). I highly 
> doubt such a device exists, and at that point we are reaching the point of diminishing returns.
>
> I'll reiterate my point about an NSE script: if the NSE API were extended to include the reason and TTL, then we 
> could try out various algorithms for grouping and classifying ports without needing to muck with the osscan innards. 
> Once a scheme were chosen, we could implement it for osscan and reap the benefits.
>
> Dan
>
> [1] http://nmap.org/book/nse-api.html
> [2] http://nmap.org/nsedoc/scripts/firewalk.html
>
>
> On Wed, Jul 30, 2014 at 3:01 AM, Jay Bosamiya <jaybosamiya () gmail com> wrote:
> 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/

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