ddos attacks

Fri Aug 2 14:55:17 UTC 2013

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