Re: [Patch] Showing TTL in default output

[Fyodor <fyodor () nmap org>]

On Wed, Jul 30, 2014 at 12:47 AM, Jay Bosamiya <jaybosamiya () gmail com>
wrote:
> I feel that the reason we made it "--reason -v" instead of just making it
> default for "--reason" is that some users might not be interested in TTL
> information.

That's a good point, but we could also hypothesize about users who want the
TTL information, but don't want all the other stuff which comes with -v.
 But the users I'm most worried about are the ones who would like the TTL
info, but might never know about or see it if it requires two non-default
options to enable.  I see that as a bigger problem than the case that users
might see this short output and somehow be annoyed by the information, even
after they have specified --reason or -vv or -d (which enable --reason).


> They might be used to seeing things from --reason and find the new output
> (i.e. with TTL) confusing.

It is a pretty minor change in the Nmap output as a whole, so I think they
can handle it.  And our policy is to try and find the best output at the
current time and we're not afraid to change things.  The exception is XML
output, which is meant to stay compatible and is what folks reading Nmap
output programmatically should be using.  Nmap is 2 weeks away from it's
17th birthday, and it would never have gotten this far if we were afraid to
make changes.

However, by saying "--reason -v" they say that they want a "more verbose
> reason"

We Nmap developers may design our command lines with skill and care and
subtlety, but I'm afraid you may be overestimating how many normal Nmap
users do that :).  So I'd rather err on the side of including this extra
bit of short information, particularly considering that they will have to
specify --reason, -vv, or -d to get it anyway.

As for the different way of showing output (TTL in the reason column), I
> don't see how it would save horizontal space. The TTL column makes the
> table wider by 4 characters (always), but the "syn-ack (ttl 52)" method
> would use more characters in most cases.

Yeah, I think the combined format probably is slightly longer (the longest
lines are two characters longer in my previous scanme.nmap.org example).
 However, I think it is easier to read that way.  Including the TTL on its
own line separates it from the reason and also gives this column of digits
too much prominence, placing them at the same level as other fields like
the service name and whether the port is open.  Putting the TTL in a
parenthetical after the reason (like "syn-ack (ttl 53)") puts the
information more in context.  And actually, maybe we don't really need the
parenthesis.  If we just do "syn-ack ttl 53" it will be the same length as
in the separate column mode.  So it would look like:

PORT     STATE    SERVICE      REASON
22/tcp   open     ssh          syn-ack ttl 52
25/tcp   filtered smtp         no-response
80/tcp   open     http         syn-ack ttl 52
135/tcp  filtered msrpc        no-response
139/tcp  filtered netbios-ssn  no-response
445/tcp  filtered microsoft-ds no-response
9929/tcp open     nping-echo   syn-ack ttl 52

 So the format above would be my suggestion.


Also, I think that the reason we need to have a TTL column is to be able to
> see (at a single glance) if any TTLs are different. When in a column form,
> the numbers are almost instantly interpreted by a human (or alien, if they
> have started using Nmap :D) and they can tell if there is any anomaly
> (maybe one of the TTLs is off by one: possibly implying a firewall, etc).

That is a good reason for the column mode, but I think they will be roughly
in a column with the combined output (as above) too.  If there are
different types of responses (syn-ack, reset, etc.) the column numbers
won't match up exactly, but I think it will be close enough to read.  And
Nmap is better than humans at detecting subtle differences like this
anyway, so this is sort of where the roll-up stuff you mention comes in.

I will be looking into the roll-up stuff in a short while; and I do agree
> that it would give a lot of interesting information. I personally do not
> mind added complexity as long as it provides more useful information.

Yeah, that could be interesting.

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