tcpdump -v host 10.0.1.1 -c 2 -i eth0 | grep length & perl snmp_rdos.pl
[5] 18795
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2 packets captured
2 packets received by filter
0 packets dropped by kernel
22:26:32.615999 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 84)
22:26:32.617181 IP (tos 0x0, ttl 255, id 7855, offset 0, flags [none], proto UDP (17), length 1480)

A single 80 byte request binding only two SNMP objects can almost exceed IPv4 max size (1500 to avoid fragmentation issues that might cause IPS/Firewall alerts).
Amplification: 1480/84=17.62

Regarding the reflection amplification ratio keep in mind that there exist responses with large string values. First came my mind is “sysORDescr” (there exist many others too), with request being 73 bytes and response ~320 bytes.

The temp network setup with requests sent over a poor wireless channel, was for the article’s purposes. The main research is conducted under my university’s network. Obviously, I cannot publish this info in such a blog post.

Of course 40K cannot kneel any UDP listening service, the measurements provided at the article was indicative of the impact factor of a single source with a pour bandwidth.

The effect on the UDP running services will be the overhead of the service’s primary packet decoder. Of course the impact depends on the service’s architecture, with impact ratio varying from service to service.

Writing this blog post my intension was to inform the infosec community about the SNMP hazards. I did not mention anywhere in the article that NOC admins should shutdown their SNMP services. Instead, like you said, I propose to revise their anti-spoofing and security network mechanisms.

My research is in its early stages and I’m now trying to upgrade my lab (with the poor university resources) to conduct some larger scale experiments, in order to conclude to the real impact factor and how this might affect SNMP infrastructures.

Anestis

2061710 packets (164936800 bytes) sent
Elapsed time = 140.923743 seconds

avg pps = 2061710 / 141 = 14622
avg b(ytes)ps = 164936800 / 141= 1169764 ~ 1Mbyte/s
avg bps = 1169764 * 8 = 9358112

Of these 9358112 bit 36864(=36*1024) bit made it to the server, thats not even 1%.
Better use something different than wifi for ddos research.

If 40kbit/s udp to a closed service cause problems with your hardware in terms of load, well … proof it.
I’m confident you can hit a box with gbit/s snmp-reflection flood to a not running service port and nothing will happen other than saturating the link.
For services offered, lets say you can hit the dns server, slamming him with snmp response packets on udp/53, it will reach the service, but what would be the effect?
You’ve saturated the line already, does it matter?

While snmp is a problem, *this* is not a snmp problem, you could have the same effect with dns, but most companies don’t have as much dns services as snmp services running.
Primary mitigation is not closing down snmp, which is a good idea for many other reasons, primary mitigation is in making sure you can’t spoof packets on the network using the port security of your switches.