In message <1C2F65D3-1E71-4C08-9A05-BA6536FDBF40@puck.nether.net>, Jared Mauch writes:
On Aug 2, 2013, at 10:38 AM, "Patrick W. Gilmore" <patrick@ianai.net> wrote:
On Aug 02, 2013, at 09:37 , sgraun@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@isc.org