[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ddos attacks
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
- References:
- ddos attacks
- From: sgraun at airstreamcomm.net (sgraun at airstreamcomm.net)
- ddos attacks
- From: patrick at ianai.net (Patrick W. Gilmore)