Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: SNMP: The next big thing in DDoS Attacks? - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
SNMP: The next big thing in DDoS Attacks?

It started with DNS: Simple short DNS queries are easily spoofed and the replies can be much larger then the request, leading to an amplification of the attack by orders of magnitude. Next came NTP. Same game, different actors: NTP's "monlist" feature allows for small requests (again: UDP, so trivially spoofed) and large responses. 

Today, we received a packet capture from a reader showing yet another reflective DDoS mode: SNMP. The "reflector" in this case stands nicely in line for our "Internet of Things" theme. It was a video conferencing system. Firewalling these systems is often not practical as video conferencing systems do use a variety of UDP ports for video and audio streams which are dynamically negotiated. As a result, they are often left "wide open" . And of course, these systems not only let attackers spy on your meeting rooms, but the also make great SNMP reflectors as it turns out.

Here is an anonymized traffic capture (target anonymized with -> SNMP 87 getBulkRequest -> IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=1f48) -> IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=1f48)
... [ additional fragments omitted ] ... -> IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=54760, ID=1f48) -> IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=56240, ID=1f48) -> SNMP 664 get-response    [... large response payload ...]

That is right! A simple 87 byte "getBulkRequest" leads to about 60k Bytes of fragmented data being sent back. We can only assume that poor is the victim of this DoS attack. The user reporting this saw about 5 MBit/sec of traffic. 

Similar to what we have seen with other reflective attacks like this, the fragmentation of the traffic is likely going to make filtering even harder. Prolexic posted a white paper about some of the different DrDOS attacks, including SNMP attacks [1]

So what to do:

- SNMP should probably not traverse your perimeter. Stop it at the firewall. (and I don't think video conferencing systems need it)
- proper egress/ingress control is a good idea.  But you already knew that.



Johannes B. Ullrich, Ph.D.
SANS Technology Institute


3189 Posts
ISC Handler
I beg to disagree that NTP came second.
The SNMP reflection DDoSes have been going on for longer. Saw them 4 to 5 months before the first NTP MONLIST reflections.

My impression was the SNMP reflections disappeared or became less predominant after NTP MONLIST came out.
Perhaps bad guys concentrating their efforts on the more abusable issue.

Now when people start patching their NTP servers; a bunch of bad guys revert back to SNMP and DNS reflection, perhaps.

146 Posts Posts
True. These different attack modes appear to be coming in waves. I think DNS was so dominant because it was so easy (and there are so many DNS servers out there). NTP kept "flaring up" from time to time. Haven't seen a ton of SNMP myself, but I am certain there are lots of amplifiers out there, and unlike NTP, you are not limited to "active" systems (monlist) is most effective if many clients use the NTP server).

3189 Posts Posts
ISC Handler
SNMP is used by video conferencing systems when you manage them with something like Cisco TMS. That being said, having a router filter at the border for SNMP is trivial to do, and won't interfere with the rest of the ports needed for H.323 and SIP video conferencing.

1 Posts Posts
The first reflection/amplification attacks were TCP-based - induced SYN-ACK floods and the like, which made their debut in the mid-1990s.

In the late 1990s, the Smurf attack was a quite popular reflection/amplification vector, until Cisco and other router manufacturers made 'no ip unreachables' a configuration default.

DNS reflection/amplification attacks were first posited around 2000 or 2001, and started to show up in the wild in late 2004/early 2005.

SNMP reflection/amplification attacks began showing up in the wild in the 2006 - 2007 timeframe.

ntp reflection/amplification attacks began showing up in the wild around 2008 - 2009.

chargen reflection/amplification attacks began showing up in the wild around 2009 - 2010.

tftp reflection/amplification attacks began showing up in the wild around 2009 - 2010.

None of this stuff is new.
Roland Dobbins

7 Posts Posts
Attackers launching ntp reflection/amplification attacks typically 'prime' the monlist cache on the abusable ntpds by sending them a bunch of pseudo-randomly-spoofed ntp time queries before leveraging them in an attack.
Roland Dobbins

7 Posts Posts
No, these various reflection/amplification attack methodologies have all been around for years, and they don't 'disappear'.

The public brouhaha over ntp reflection/amplification attacks began when some gamer script-kiddies (there's always been a strong correlation between online gaming and DDoS attacks) got hold of some simple scripts which had filtered downwards from more sophisticated attackers, along with access to compromised servers on IDC hosting networks which didn't enforce anti-spoofing.

They attacked online game services with very large ntp reflection/amplification attacks; these services typically have tens of millions of simultaneous users, and that's what brought this attack methodology into the view of non-specialists.

But there are DDoS attacks using all these various reflection/amplification methodologies taking place every second of every minute of every our of every day of every year. Attackers add new methodologies to their individual arsenals, but we don't see DNS reflection/amplification attacks being *discarded* in favor of ntp reflection/amplification attacks, for example.
Roland Dobbins

7 Posts Posts
Also, the population of abusable ntpds has declined from ~1.7M to ~110K, due in large part to concerted remediation efforts over the last 6 months or so.

The one thing which would make all forms of reflection/amplification attacks impossible is anti-spoofing at all network edges. BCP38/84 is the answer.
Roland Dobbins

7 Posts Posts
I very much agree! This isn't so much a problem with these specific applications, but a problem with the ability to spoof traffic.

3189 Posts Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!