Re: [Patch] Port and Host State Reasons

[David Fifield <david () bamsoftware com>]

On Wed, May 16, 2007 at 02:41:20PM +0100, Eddie Bell wrote:
> This patch is an updated version of one I wrote last year. Essentially
> it gives you packet level detail as to why a port is deemed to be in a
> particulate state. It is activated with the --reason switch and
> supports all scan/ping types.
>
> This is (hopefully) a pretty simple patch but testing and suggestions
> are always appreciated  :)

This patch is really neat. Here are some suggestions I thought of:

Maybe you should enumerate the possible values the "reason" attribute of
the "status" element can take (in the same way that the "state"
attribute can take on only certain values.

In the output table, I think the REASON column should come before the
SERVICE column. The reason for this is that REASON pairs naturally with
STATE and SERVICE pairs with VERSION. This may cause problems if a
program tries to screen-scrape Nmap's output, but then those programs
are going to have trouble with an additional column anyway.

The functions state_reason_init and state_reason_summary_init initialize
the state to ER_NORESPONSE, which is a reason that might plausibly be
returned after a scan. Perhaps it's better to initialize it to
ER_UNKNOWN instead, to make it more obvious if someone modifies the scan
engine to handle another scan type but forgets to call setStateReason.

Putting the reasons in the XML output even without the --reason flag is
the right decision. It may be surprising, though, that the reason
appears in the XSL transformation of the output even when reasons
weren't requested. Maybe it's not a big issue.

Why does the reason_id go in the XML output. The textual names seems
like they'll be more robust.

When scanning a host that returns a response for every port (i.e., every
port is unfiltered), there's an "extrareasons" element in the XML output
with a count of 0:

        <extrareasons reason="resets" reason_id="0" count="1702"/>
        <extrareasons reason="no-responses" reason_id="33" count="0"/>

This patch looks to be really useful, and you've got a good
implementation.

David

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org