Re: Traceroute scripts and their output

[Daniel Miller <bonsaiviking () gmail com>]

On Sun, Sep 28, 2014 at 7:22 AM, Jacek Wielemborek <d33tah () gmail com> wrote:
> In addition to my previous post about enhancing port scanning output
> with NSE-defined columns (http://seclists.org/nmap-dev/2014/q3/500), I
> would like to suggest a change in the output format here as well:
>
> TRACEROUTE (using port 24/tcp):
> HOP RTT       ADDRESS                                      GEOLOCATION
> 1   0.58 ms   172.16.1.1                                   - ,-
> |_firewalk: blocked ports: 25
> 2   11.90 ms  10.200.0.2                                   - ,-
> 3   ... 4
> 5   11.93 ms  10.44.10.2                                   - ,-
> 6   ...
> 7   13.67 ms  henet.plix.pl (195.182.218.197)              52,20 Poland
> (Unknown)
> 8   27.65 ms  10ge1-2.core1.prg1.he.net (184.105.213.241)  37,-121
> United States (California)
> 9   30.81 ms  10ge15-3.core1.fra1.he.net (184.105.213.233) 37,-121
> United States (California)
> 10  40.02 ms  100ge5-2.core1.par2.he.net (72.52.92.13)     37,-121
> United States (California)
> 11  123.28 ms 10ge15-1.core1.ash1.he.net (184.105.213.93)  37,-121
> United States (California)
> 12  178.67 ms 10ge9-2.core1.pao1.he.net (184.105.213.177)  37,-121
> United States (California)
> 13  183.55 ms 10ge4-4.core3.fmt2.he.net (184.105.222.89)   37,-121
> United States (California)
> 14  183.57 ms router3-fmt.linode.com (65.49.10.218)        37,-121
> United States (California)
> 15  178.38 ms scanme.nmap.org (74.207.244.221)             37,-121
> United States (California)
>
> This would make it more readable because instead of reading three
> traceroute lists, user would have to run through just one.
>
> What do you think about this suggestion?

Jacek,

I agree that more unified output would be nice, and the traceroute
scripts seem like a good candidate. However, I am opposed to allowing
scripts to modify the existing Nmap output beyond what they are
currently able to do. To put it a different way, let's come up with a
way to improve script output without altering the NSE API [1].

Here are some ideas that could generally improve output from various scripts:

1. Unify output formatting. This was one of my sub-goals in
introducing XML structured output, because in fact that project
started as wanting structured *text* output that could be easily
parsed. I considered (and half-implemented) a solution in YAML before
we settled on dual XML and indented text outputs. We have lots of
tools available for this sort of effort: the tab library [2], the
older/deprecated stdnse.format_output format, the various
stdnse.format_* functions for formatting times and dates, etc. What
can generally be improved is the fine-grained stuff like
capitalization of table keys, ordering of table columns, and other
things that give a unified look to NSE output.

2. Join script results into one with multi-rule scripts. This could
take a bit of cleverness to pull off, but it is probably the way to go
for your particular suggestion. At one level, multi-rule scripts are
fairly simple (see ssh-hostkey, http-affiliate-id, nfs-showmount,
etc.). A bit more complicated are the ones that try to aggregate
results from multiple scripts (See creds-summary, duplicates, etc.).
Generally for this to work, you have to store the information in the
registry and then pull it out later. For traceroute-related scripts,
the aggregator script could be a hostrule script that depends on all
the other traceroute scripts.

Of course, then you just have one more output in addition to all the
existing fractured output formats. Perhaps it would be best to
register the fact that your unification script is running (set a
global registry flag in the prerule phase). Then the individual
scripts could know to forgo their own output and let the unification
script handle it.

My point is that there are ways of improving the user experience that
don't require drastic changes. If those are sufficient, we should use
them instead.

Dan

[1] http://nmap.org/book/nse-api.html
[2] http://nmap.org/nsedoc/lib/tab.html
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/