Oulu Protos is a great tool for finding SNMP implementation vulnerabilities via fuzzing.
However, it lacks a few things. The main problem when using it is difficulty in determining
which particular SNMP packet has caused a crash. This particularly applies to blackbox testing
without an access to the device, as usually happens in penetration testing. Also, you can not
send a single testcase packet, only the whole battery. And there is no user-friendly interface.

Snmpfuzz sorts out this problems. The CLI is easy to use, sending a single testcase is not a 
problem and there is additional flexibility in testing by setting the amount of forks and processes,
as well as timeout. But the main thing about snmpfuzz is the ability to determine which particular
packet was harmful for the target. This can be done by two methods applied simultaneously:

1. ICMP port unreachable packets are sniffed out and shown in console. The last SNMP packet that 
is likely to be the cause of the problem is encapsulated inside of the ICMP port unreachable. This
is the most simple and efficient way to discover which packet has crashed the tested service/device.

2. "SNMP pings" (SNMPv1 get requests for SysDescr object) are sent in accordance to the timeout set.
They are also affected by a --nodos option (see below). If a reply for such packet ("SNMP pong") is 
not recieved, the service is down. If an option --kill is set, the scan stops as soon as there is no
SNMP pong recieved.

When a problem is detected (ICMP port unreachable recieved, no SNMP pong), check out the contents of
ICMP port unreachable. Also, you can suspect any of the last N packets, where N is a variable supplied
to the --maxprocess option. To be 100 % sure, send these N packets to the target one-by-one using 
a single packet send option (--file). 

When the problem has occured, it could be because

- SNMP service crashed
- host crashed
- host resources exhaused

You can't distinguish these conditions using snmpfuzz alone, so we recommend to run an ICMP ping at the
same time in a different terminal. When a crash is detected, have a look whether the host still responds 
to pings. 

When snmpfuzz is ran with all default options, a single mode in which only ICMP listener is forked. The queries
go one after the other, not in parallel, and an SNMP ping will follow every single query if a --ping flag is
enabled (recommened). In such case, discovering which packet produced the crash is straightforward - it's the
last one :-).

Now to the --nodos option. In a testing process we have discovered that a Cisco 2600 router against which
the tool was run hangs due to the CPU resource exhaustion. The cause of an exhaustion appears to be SNMP
"pinging" for SysDescr. When running a scan with --fork and --ping, enabling --nodos option will prevent
this from happening. On the other hand, omitting --nodos appears to be useful in SNMP services stress 
testing. 

Of course, in SNMP trap acceptance testing the NMS on port 162 may go down without any interference with 
SNMP querying process via port 161. In this case, dissecting ICMP port unreachable messages is the best
and only way to determine the problematic packet. 

Remember, at the end, the best way to find out how and when the crash has happened is to run a debugger on the SNMP
service problem. 

This tool was mainly tested on Cisco hosts since it was written when working on "Hacking Exposed: Cisco Networks",
namely a section on the blackbox approach to hacking Cisco SNMP services. It is distributed under GPL. Please give
snmpfuzz some credit when publishing new vulnerabilities found with it. 
