Re: [Patch] Showing TTL in default output

[Daniel Miller <bonsaiviking () gmail com>]

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/