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@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@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@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton