Determining UDP 161 port (SNMP) status using SNMPv3

[Tom Sellers <nmap () fadedcode net>]

Hello all,

        I have been working with a security vendor's product
(as a customer) to determine why this particular software
determines that UDP port 161 (SNMP) is open on one device and
open|filtered on another.  This product implements (under license)
certain aspects of NMap and their results track along with NMap's.

After looking at how the UDP port detection works, I think I have
a handle on the problem and a solution.  Please correct me where
I am wrong.

If I understand correctly when it comes to UDP ports everything
is pretty much considered open|filtered unless an ICMP response
flags it as closed or a service response indicates that it is
open.


In my case, the problem port is SNMP.

When it comes to SNMP (UDP port 161) the SNMPv1public probe can
elicit a response if the community string is actually public,
resulting in the port being flagged as open.  If the string is
not public then the host does not provide a response at all,
leaving the port state as open|filtered.

I believe that we can augment this port status detection by
adding a SNMPv3 probe.  In my experience SNMPv3, when provided
with a bogus username, will respond with a packet that says
that the username is unknown.  This response will allow NMap
to determine that the port is open.  I have a probe that does
just this and I can build a match line for it. I think integrating
this probe or a similar one would improve NMap's port status
accuracy against SNMP daemons that support SNMPv3.

What I am curious about is:

1.  This is essentially a login attempt.  I know that the SNMPv1
     probe tries to use"public" but I don't know if people will
     consider this the same.

2.  Would this be more appropriate as a NSE script as it could be
     flagged as "auth" and only run when that is ok?

3.  If using this probe is ok, what username should be used?  I
     have been considering using either "public" or null.



Feedback on this would be greatly appreciated.

Thanks,

Tom

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