SNMP DDoS: the vulnerability you might not know you have
bottiger10 at gmail.com
Thu Aug 1 00:07:57 UTC 2013
I realize the root cause is security-oblivious designers and one level
below that, lack of BCP38.
But realistically those 2 problems are not going to be solved any time
in the next decade. I have tested 7 large hosting networks only one of
them had BCP38.
To my knowledge it is practically impossible for someone outside a
multi-homed network to know if they allow spoofing which means it will
be difficult to punish. It also cost time and money to maintain these
ACLs, much more than blocking the occasional wide-spread protocol with
8000x amplification every couple of years.
I am here to talk about solutions today. BCP38 has been repeated to
death and people aren't going to start doing it because I said so. The
fact that the amplification factor is so high means that you need to
ensure near 100% conformity even if everyone started to become BCP38
On Wed, Jul 31, 2013 at 4:42 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On 7/31/13, 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
> Because it breaks applications that people are paying to be able to use.
> The way I see it; more and more samples keep getting found about
> protocols abused because networks have not implemented BCP38.
> The latest SNMP trend is just another uptick to the sample size, and
> proof that Closing off perfectly OK recursive DNS services is
> totally inadequate and not a useful long-term fix to the problem of
> DDoS or IP/UDP reflection attacks.
> Asking folks to improve the security of access to their SNMP instances
> is just chasing the latest exploit implementation, with no attention
> to the vulnerability or the root cause....
More information about the NANOG