SNMP DDoS: the vulnerability you might not know you have

Wed Jul 31 22:02:13 UTC 2013

This vulnerability has been present ever since SNMP v2 was announced
back in 1993.

There is a reason why the biggest attacks these days are from
protocols that are decades old like DNS and Chargen.

People making widely spread protocols these days are aware of the
problem and are usually able to get their software to auto-update.

Enforcing source IP filtering seems like a lost cause. Not much
progress has been made that I can tell and it is difficult to discover
if the network allows it without being inside it.

I don't see many uses for unsecured SNMP access so this is not like
blocking all syn and udp packets.

On Wed, Jul 31, 2013 at 2:29 PM, Blake Dunlap <ikiris at gmail.com> wrote:
> I bet blocking all SYN packets and non related flow UDP packets to
> customers would be even more effective. Why don't we do that and be done
> with it instead of playing whack a mole every 3 months when someone finds
> some new service that was poorly designed so that it can be used to send a
> flood?
>
> Yes, I'm being sarcastic above.
>
> This is hardly the first finger of death amplification attack, and I
> strongly doubt it'll be the last. Years ago it was smurf, then Quake
> servers, then DNS, then Battlefield boxes, etc etc. Now it seems to be snmp
> and recently chargen, and tomorrow it'll be some peer 2 peer service, the
> next day it'll be a voice app. It will never end, and breaking the internet
> port by port doesn't do anything to make it better.
>
> I've been the victim of week long DDoS attacks that took down our
> upstreams, not to mention us, and I still maintain the above.
>
> It works better to fix the design issues than to play whack a mole by
> blocking every imaginable service to your customers that responds to the
> public with data larger than a FIN. Like getting their providers to more
> proactively police their spew, manufactures to stop making negligent
> devices, or implementing more intelligent filter communication so the only
> option doesn't begin with calling your provider and asking them over the
> phone to block X ip for you since you're off the internet.
>
> Maybe even look into liability laws for allowing said attacks to originate
> from your customers and not doing anything about it, or being manufacturer
> of said devices that harm others through their lack of due diligence
> implementing proper security. It's still way more effective than trying to
> fix the *last instance* of the problem, instead of it's reasons for
> enduring as an issue at a global scale.
>
> -Blake
>
>
> On Wed, Jul 31, 2013 at 3:46 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
>>
>> On Aug 1, 2013, at 3:11 AM, bottiger wrote:
>>
>> > The most disturbing part is the lack of logging.
>>
>> Flow telemetry can be of use in this instance.
>>
>> -----------------------------------------------------------------------
>> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>>
>>           Luck is the residue of opportunity and design.
>>
>>                        -- John Milton
>>
>>
>>