On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" <[email protected]> wrote:
> On Aug 02, 2013, at 09:37 , [email protected] 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
