ddos attacks

Sat Aug 3 00:39:24 UTC 2013

In message <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40 at puck.nether.net>, Jared Mauch 
writes:
>
> On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" <patrick at ianai.net>
> wrote:
>
> > On Aug 02, 2013, at 09:37 , sgraun at airstreamcomm.net wrote:
> >
> >> I'm curious to know what other service providers are doing to
> >> alleviate/prevent ddos attacks from happening in your network.  Are you
> >> completely reactive and block as many addresses as possible or null0
> >> traffic to the effected host until it stops or do you block certain ports
> >> to prevent them.  What's the best way people are dealing with them?
> >
> > #1: Ensure your network is BCP38 compliant.
> >
> > Hard to complain about others attacking you when you are not clear. And
> > if you do not block source-address spoofing, you are not clean.
> >
> > As for the rest, I'll let others with more recent experience explain
> > what they do.
>
> We have had challenges with deploying BCP38, even on simple connections.
> We have outstanding defects in IOS-XR that prevent us from deploying it.
>
> Wherever possible we have enabled source address validation (bcp38).  I
> do have a map of some networks that don't do this as a result of the
> OpenResolverProject.org data.
>
> Here's some top ASNs that can send spoofed packets:
>
>   Count ASN
> ---------------
>    1006 18747
>    1004 262824
>     877 196753
>     522 29119
>     516 5617
>     514 34977
>     513 47570
>     513 12615
>     512 262336
>     512 12301
>     372 6739
>
>
> These ASNs spoof my machine I use to send queries out to 8.8.8.8 and
> goole responds back to me.
>
> Likely some firewall/CPE/NAT that does this, but the provider lets those
> spoofed packets reach outside their network to google.
>
> I have many more of these if folks want to see a broader list.
>
> If you look at the ASN relationships involved here, it means either 3491
> or 3257 allows these spoofed packets from 18747.
>
> - Jared

Please publish the full list.  It is long past the time when operators
should be filtering out spoofed source address traffic.

This sort of data should be refreshed and published quarterly.

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