Re: [Patch] Showing TTL in default output

[Daniel Miller <bonsaiviking () gmail com>]

Jay,

Thanks for the quick turnaround on this idea. I had a chat with Fyodor and
we came up with some other concerns that are related to reporting of TTLs.
I think these should be resolved in some way (even if it's just a public
"we're not doing this right now" statement) before we commit a patch to
display ttls in regular output.

First, there is the rather minor issue of how to display the TTLs. Your
patch adds a column, "TTL", to the output, as well as noting the TTL for
the host state reason. Another approach (since we assume nearly all the
TTLs will be the same from each host) would be to add another row to the
output instead, something like: "TTL 62: 998 responses; TTL 63: 25/tcp,
445/tcp." This particular scheme could get cumbersome, but perhaps we could
work it out somehow.

Second, and more importantly, we are currently losing information about
TTLs when we roll up port states. Say we scan a system that has one open
port and 999 closed ports. Currently, we roll these 999 up into a single
<extraports> element in the XML, and the output states "Not shown: 999
closed ports." The reasons are in a child element, <extrareasons>, and
output on the next line, "Reason: 999 conn-refused". Obviously, we do not
show the TTL in normal output yet, but we also fail to show it in XML
output, primarily because it is not necessarily the same for all those
ports. If we are going to go through the trouble of adding TTL output, we
should probably also solve this problem.

One approach would be to key the rollup on the (state, TTL) pair, instead
of just the state. Actually, this is about the only way that I can think to
do it, though I am open to correction. This would require significant
changes to the code in portreasons.cc and output.cc. I envision something
like the following:

Not shown: 997 closed ports
Reason: 997 conn-refused (TTL: 62)
PORT    STATE   SERVICE       REASON        TTL
22/tcp  open    ssh           syn-ack       62
25/tcp  closed  smtp          syn-ack       62
445/tcp closed  microsoft-ds  conn-refused  63

This could get hazardous, especially when we consider how to show the same
info to a user who has *not* requested TTL output (e.g. just -v, no
--reason). In that case, I don't see a need to split out the ports based on
a metric that is not being shown, but it may be too difficult to support
both cases. The XML output should be the same no matter what (and should
reflect the addition of TTL into the consideration for extraports).

A couple more short considerations:

1. Some OSs use different initial TTLs for TCP vs UDP ports, or even for
open vs closed TCP ports. Not likely to matter here, but something that
people may notice once this is implemented.

2. Adding TTL to the <extrareasons> element (as a reason_ttl attribute,
e.g.) will require a change to the DTD and possibly an xmloutputversion
bump, though I think it's usually OK to add new attributes without changing
elements.

3. Since the TTL is displayed after the reason in every case, I think we
can simplify the presentation by removing the (parentheses) and colon: Host
is up, received echo-reply ttl 56 (0.077s latency).

4. Nearly unrelated, we don't report latency (host's smoothed
round-trip-time or srtt) in the XML.

Dan

On Wed, Jul 16, 2014 at 7:16 AM, Jay Bosamiya <jaybosamiya () gmail com> wrote:

> Hi All!
>
> There has been discussion [1] of being able to see the TTL in default
> output mode.
> According to some of the points in the discussion, I've written a patch
> that does this (attached).
>
> Just to summarize the changes:
> "-vv" now implies "--reason".
> TTL is shown when --reason is made verbose (i.e. "--reason -v" or "-vv"
> is called).
> No extra CLI option was added for showing TTL.
>
> Feedback is welcome as always.
>
> Cheers,
> Jay
>
> Links:
> [1] http://seclists.org/nmap-dev/2014/q3/50
>
> _______________________________________________
> 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/