jared at puck.nether.net
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:
These ASNs spoof my machine I use to send queries out to 220.127.116.11 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.
More information about the NANOG