Nmap Development mailing list archives
Re: Determining UDP 161 port (SNMP) status using SNMPv3 - Update patch
From: Tom Sellers <nmap () fadedcode net>
Date: Sat, 21 Jun 2008 21:04:21 -0500
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
Current thread:
- Determining UDP 161 port (SNMP) status using SNMPv3 Tom Sellers (Jun 17)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Fyodor (Jun 17)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Tom Sellers (Jun 17)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Fyodor (Jun 18)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Tom Sellers (Jun 18)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 - Update patch Tom Sellers (Jun 21)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 - Update patch Fyodor (Jun 28)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Tom Sellers (Jun 17)
- Re: Determining UDP 161 port (SNMP) status using SNMPv3 Fyodor (Jun 17)