Re: Determining UDP 161 port (SNMP) status using SNMPv3 - Update patch

[Tom Sellers <nmap () fadedcode net>]

Fyodor wrote:
> On Tue, Jun 17, 2008 at 11:04:37PM -0500, Tom Sellers wrote:
> > I have attached a patch to nmap-service-probes that includes the probe/match
> > combination that I spoke of earlier.  It sends a SNMPv3 connection request
> > that with the username sent to "public".  The rarity has been set to 4, the
> > same as the SNMPv1public probe.
>
> Hi Tom.  That is great, but the match line may be too generic.  It says:
>
> > +match snmp m|^..\x02\x01\x030.\x02\x02\x20\x97\x02.{32,38}\x04\x06public\x04\0\x04\x00|s p/SNMPv3 server/
>
> For version detection purposes, it would be best if we could at least
> try to match individual SMTPv3 servers where possible.  So if you know
> what is running on the remote host, maybe try to include as much
> context as you can with the match (this may be enough) and then
> include the details in the match line.  Then, if you have another
> SMTPv3 server, maybe you will be able to match that separately.  This
> way we know more than just that it is some snmpv3 server.  Now it may
> turn out that SNMPv3 responses are so generic that we can't glean any
> more details.  But it is best to start specific and then we can
> generalize it if needed when we receive correction reports at
> http://nmap.org/submit/ .
>
> Cheers,
> -F

Fyodor,

        Thanks for challenging me on this patch.  I have attached a new, better,
patch below.  This patch does not make a log in attempt, but uses a basic, pre auth
request instead.  It will match several vendors and trigger fingerprint output for
unrecognized services.

I gathered most of the information watching network traffic with Wireshark while
running the following command  "snmpwalk -v3 -u public target_host".


There are 9 vendor match lines and 1 generic softmatch line.  There are comments
for each match line that provide background info that may be useful when building
future match lines.  All of this may be a bit wordy/unnecessary for the probes file.

For the most part, the last two bytes in the match lines are the Engine ID and are
vendor/platform specific.  They are IANA numbers for the vendor.  Sometimes the name
listed does not match the equipment manufacturer.  One example of this is the QLogic
gear using an engine ID that belongs to Ancor Communications.  This is a company that
QLogic bought/merged with years ago.  For others I have no idea how the arrangement
came about.

Hopefully this patch will help by both improving the ability to detect UDP port 161
status on some devices and identifying certain platforms.

As always, feedback is greatly appreciated.

Tom

Attachment: snmpv3_rev3.txt
Description:

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