Home page logo
/

nanog logo nanog mailing list archives

Re: SNMP DDoS: the vulnerability you might not know you have
From: Mark Andrews <marka () isc org>
Date: Thu, 01 Aug 2013 12:58:02 +1000


In message <CA+2UFhntL-iKdGc7Ev9UbPB-y5QkO5eA=nxFfsmNMq50ZUkPqA () mail gmail com>
, bottiger writes:
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.

Then name and shame.
 
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.

Just define a EDNS option which contains the real ip address and
update who-am-i services to look for that when replying, use a
modified DNS cookies or similar to prevent this being used as
amplifier.  You can do this with a experimental EDNS option code
points today.

Send a non-spoofed request then send a spoofed request using the
cookie learnt from the first request.

Standardise it and every nameserver on the planet and be used to
detect if spoofing is possible.  Using DNS puts up to costs for
ISP's that want to block people checking.

The blackhats already check whether spoofing is possible so there
is little point in blocking whitehats checking.

As for time and money to maintain these acls it really shouldn't
now that SIDR is becoming a reality.  Present a properly signed
CERT to the other providers and automatically generate the acls
based on those.  There is a little setup cost to get the system
running and almost no additional recurrent costs to keep it up
to date.  The CERTs need to be generated for sBGP anyway.

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
compliant today.

On Wed, Jul 31, 2013 at 4:42 PM, Jimmy Hess <mysidia () gmail com> wrote:
On 7/31/13, 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?

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....

--
-JH


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault