Re: SNMP DDoS: the vulnerability you might not know you have

[bottiger <bottiger10 () gmail com>]

Public SNMP being exploited for 8000x amplification is a very serious
issue. It is
arguably worse than open email relays.

Not only does it expose critical information from your users
but it offers the largest possible amplified DDoS by far, likely
bigger than DNS when you take into account the amplification size and
ubiquity. It will also cause your user's device to lag.

The most disturbing part is the lack of logging. We have tried
reporting these exploited servers for many weeks and because of the
logging problem most of them never get shut down because they just
assume they were being spoofed. We even had replies threatening to
block us because they thought were because they couldn't see they
were sending anything. When we were reported chargen attacks we
had much more positive responses.

Maybe you could refine the block by denying SNMP requests with the
public string. As network operators some compromises must be
made for a problem of this magnitude instead of just saying that you
should only be the best dumb pipe you can be.

We have seen attacks large enough to disturb 10G uplinks so as network
administrators you should not ignore this issue because you think it
is a small problem affecting only end users. This will affect you once
more people figure out how to get 8000x amplification from it.

It is great news that Comcast is trying to proactively solve this
problem on their network and hope that more networks would follow
their example.

On Wed, Jul 31, 2013 at 8:24 AM, Blake Dunlap <ikiris () gmail com> wrote:
> Agreed, but progressively breaking every service on the internet at the edge
> because you think there might possibly be an issue just leads to bad places.
>
> Get better defaults sure, but don't slowly turn the internet into a cable
> distribution system because "they're just users". It's bad enough already,
> don't make it worse trying to solve every issue with the nuclear option
> before trying anything else.
>
> -Blake
>
>
> On Wed, Jul 31, 2013 at 10:17 AM, Thomas St-Pierre <tstpierre () iweb com>
> wrote:
> > The problem isn't the people on this list leaving the public snmp
> > community on their devices, it's the vendors of home routers leaving it
> > there in their devices. Normal end users don't know or even care what snmp
> > is. (nor can we expect them too)
> >
> > A simple scan of a large cable/dsl ISP's address space will likely net you
> > tens of thousands of devices which respond to the "public" snmp community.
> >
> > Thomas
> >
> >
> >
> > On 13-07-31 10:57 AM, "Blake Dunlap" <ikiris () gmail com> wrote:
> >
> > > This looks like more a security issue with the devices, not border
> > > security
> > > issues.
> > >
> > > If you're seeing replies of that size, it means the devices themselves
> > > are
> > > set up to allow public queries of their information (not secured by even
> > > keys), which no one should be comfortable with. People should never be
> > > leaving the public access snmp strings on devices even if they are
> > > internal. Edge blocking just masks the real issue.
> > >
> > >
> > > -Blake
> > >
> > >
> > > On Tue, Jul 30, 2013 at 11:25 PM, bottiger <bottiger10 () gmail com> wrote:
> > >
> > > > Before you skim past this email because you already read the Prolexic
> > > > report on it or some other article on the internet, there are 2
> > > > disturbing properties that I haven't found anywhere else online.
> > > >
> > > > 1) After sending abuse emails to many networks, we received many angry
> > > > replies that they monitored their traffic for days without seeing
> > > > anything (even as we were being attacked) and that their IPs were
> > > > spoofed and would block us for spamming them.
> > > >
> > > > What we discovered was that their firewalls/routers/gateways coming
> > > > from vendors like Cisco and SonicWall apparently didn't record SNMP
> > > > traffic going in or out of themselves. We confirmed this multiple
> > > > times by running a query to an IP that was claimed to be clean and
> > > > watching the response come 10-60 seconds later because the device was
> > > > being so heavily abused.
> > > >
> > > > 2) SNMP reflection offers the largest amplification factor by far,
> > > > even surpassing DNS, Chargen, or NTP by a wide margin. I have tested a
> > > > 68 byte query and received responses of up to 30,000 to 60,000 bytes.
> > > > The trick is to use GetBulkRequest to start enumerating from the first
> > > > OID and setting max repetitions to a large number. This is contrary to
> > > > the other articles online which suggest a much smaller amplification
> > > > factor with other queries.
> > > >
> > > > This protocol is also prevalent in many devices ranging from routers
> > > > to printers.
> > > >
> > > > To solve this problem you should block SNMP traffic coming from
> > > > outside your network and whitelist outside IPs that require it.