Re: SoC: port state reasons

[Fyodor <fyodor () insecure org>]

On Wed, Jun 07, 2006 at 11:18:21AM +0200, Eddie Bell wrote:
> I am in the middle of the port state reason implementation, here is what it
> looks like at the moment

Hi Eddie.  Thanks for the update!  This looks good.  My comments are inline.

> Not shown: 1233 closed portsReasons: 1233 remote resets
> PORT    STATE    SERVICE REASON
> 21/tcp    filtered    ftp               admin-prohibited
> 22/tcp    open       ssh
> 25/tcp    filtered    smtp          port-unreachable
> 53/tcp    open       domain
> 113/tcp  filtered    auth           no-response

This table doesn't line up -- I'm assuming that is just due to copy &
paste or mailer issues?

> So far the reason can be one of the following depending on the scan. Can
> anyone think of any other
> reasons I can infer?
>
> open, closed,  remote-reset, no-response
> unreachable, net-unreachable, host-unreachable
> proto-unreachable, port-unreachable
> admin-prohibited, net-prohibited
> host-prohibited and unknown

I don't see a need for "open" or "closed" reasons.  In a SYN scan, for
example, open ports would probably have the reason "SYN/ACK" and
closed ones "RST".  You can abbreviate "unreachable" to "unreach" to
save a little space.

I think we should have a "from" and "ttl" field.  So we can give reasons like:

RST from 198.12.14.6 ttl 129

I would suggest only showing the "ttl" part in normal output in
verbose mode.  It would always go in the XML.  Of course "from" and
"ttl" information isn't printed if you don't have the information
(like with a connect scan, or reasons like no-response).

> Here is my idea for the xml structure. I have added a reason attribute for
> the state and extraports tag
>
> <ports>
> <port protocol="tcp" portid="22">
> <state state="filtered" reason="port unreachable" />
> <service name="ssh"/>
> </port>
>
> <extraports state="filtered" count=102 />
> <extraports reason="admin-prohibited" count=102/>
> .....
> .....
> </ports>

Looks good.  But I would add the reasonsrc and reasonttl attributes too.

Also note that you may need more extraports directives now, since some
of the "filtered" ports may have a different reason (or reasonsrc or
ttl) than others.

> Also one last question, I am severely limited on what reasons I can get from
> a connect scan. This is understandable as a user, but as root does nmap
> still use the API connect call or does it use raw packets?

Nmap always uses connect() for a Connect scan.  You should be able to
distinguish the RST, SYN/ACK, and no-response cases.  You may not be
able to distinguish between some of the different ICMP errors so you
may have to add an extra reason code for those icmp errors you cannot
distinguish.

Also remember to update the Nmap documentation
( http://www.insecure.org/nmap/data/nmap-man.xml ).

A reason for the host status (e.g. why was the host considered "up" or
"down") should be created too.  That would presumably use the same set
of codes (though you'd have to add one for ARP).  It should support
the "from" and "ttl" fields where relevant.

Cheers,
-F


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