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?
Scott
The answers will vary from "nothing" to "extensive network planning
and contracts with mitigation services", depending on the respondent's
budget and how many DDoS attacks they attract per fiscal year...
#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
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
Scott,
Use a DDOS detection and mitigation system with DPI capabilities to deal
with traditional DDOS attack and anomalous behaviour such as worm
propagation, botnet attacks and malicious subscriber activity such as
flooding and probing. There are only a few vendors who successfully play in
this space who provide a self healing/self defending system.
Cheers
Ahad
Can anyone recommend a vendor solution for DDOS mitigation? We are looking
for a solution that detects DDOS attacks from sflow information and
automatically announces BGP /32 blackhole routes to our upstream providers,
or a similar solution.
Thank You.
We use Arbor for this - works quite well…. Peakflow/TMS .. We don’t do
anything announcement wise upstream but don’t see why you couldn’t via
communities...
I’ve looked at one cloud based solution to date and decided appliance is a
better solution specific to our needs.
Paul
Dan,
If you are using sFlow for your measurements, then you might want to take a
look sFlow-RT for DDoS mitigation. The following case study describes how
sFlow and null routing are being used to mitigate flood attacks:
http://blog.sflow.com/2013/03/ddos.html
The analytics engine will detect flood attacks in less than a second and
you can use the embedded scripting API to initiate automated responses. The
following articles contain basic DDoS mitigation scripts - you just need to
replace the block() and allow() functions with calls to expect scripts,
OpenFlow rules, or REST API calls - whatever makes sense in your
environment.
http://blog.sflow.com/search/label/DoS
This is a commercial product, but it's free to try out (no registration
required):
http://inmon.com/products/sFlow-RT.php
Cheers,
Peter
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?
Scott
I am strongly considering having my upstreams to simply rate limit ipv4
UDP. It is the simplest solution that is proactive.
The facts are that during steady state less than 5% of my aggregate traffic
is ipv4 udp. During an attack, 100% of the attack traffic is ipv4 udp (dns,
chargen, whatever). The attacks last for about 10 minutes, so manual
intervention is not possible. Automated intervention has its own warts.
Conclusion: ipv4 udp is a toxic dump. It is a shame that DNS (can be
tcp), webrtc (should be sctp), and Google's QUIC are going to suffer the
rate limited fate. My advice to them is to get aways from ipv4 udp, the
problem is getting worse not better.
CB
What are the prospects for ipv6 UDP not suffering the same fate?
Roughly 0%, but there's so little v6 traffic compared to v4, you probably don't have to worry about v6 attack traffic yet...particularly if you're not dual stack yet. 
Dear All
We have been using NSFOCUS Anti DDoS hardware both locally within Australia and Internationally for the past 12 months and have been very happy with the platform capabilities and the support provided by their support engineers. For more information have a read on their website !
http://www.nsfocus.com/en/index.html
I would highly recommend looking at their ADS, ADS-m and NTA hardware product lines which as a combination provides a complete automatic platform with monitoring, detection and surgical cleaning of Layer 4/7 IPv4 and IPv6 traffic including providing a client platform !
Of course for any form of Anti DDoS hardware to be functional you need to make sure your network can route and pass the traffic so you can absorb the bad traffic to give you a chance cleaning the traffic.
Kindest Regards
James Braunegg
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666
W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21
[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
* James Braunegg
Of course for any form of Anti DDoS hardware to be functional you
need to make sure your network can route and pass the traffic so you
can absorb the bad traffic to give you a chance cleaning the
traffic.
So in order for an Anti-DDoS appliance to be functional the network
needs to be able to withstand the DDoS on its own. How terribly useful.
Tore
Hi,
You can also test WANGUARD, http://www.andrisoft.com/ for DDoS detection
and BGP triggered blackholing.
I am strongly considering having my upstreams to simply rate limit
ipv4 UDP. It is the simplest solution that is proactive.
I understand your willingness to do this, but I'd strongly advise
you to rethink such a strategy. At its simplest implementation, as
soon as you do this any UDP flood of that size will then starve
important UDP traffic. Yes DNS is probably the most important, but NTP
is another one important one you may inadvertently harm.
The facts are that during steady state less than 5% of my aggregate
traffic is ipv4 udp.
I had found this to be generally true years back when I was doing ops
at an edu and had in fact put UDP (and other IP protocol) rate
limits at the ingress edge, host facing interfaces. This actually
worked pretty well, at least after I also remove the aggregate UDP rate
limit in the middle of the network that led to the public Internet.
So for instance, a Slammer/Sapphire worm infection was severely limited
and contained to impact only a small portion of the infrastructure,
meanwhile we could immediately spot the problem when the rate limit
alarms were triggered.
The problem with your proposal is that it complete the job for your
entire network. Now perhaps if you excluded, or provided a separate
limit for what you know to be important UDP flows, then the idea may
be more palatable to everyday operations.
John
Due to the nature of network infrastructure devices and TCP/IP, it's quite necessary that they themselves are resilient in the face of attack:
<https://app.box.com/s/osk4po8ietn1zrjjmn8b>
This is a base requirement for any network operator, without exception.
in fact, this comes down to cost / benefit / application analysis, without
exception.
Many hosting profiles don't require this sort of anti-DDoS kit. In many
cases it's far cheaper to permanently disconnect a customer who is the
subject of continual DoS's rather than fork out loadsamoney for boxes like
this.
For applications at the higher end of the spectrum, there are many
situations where it's more cost effective / resilient / sensible to farm
out online content to CDNs, whose infrastructure will be much better
equipped to handle several tens of gigs of DDoS traffic than even a
reasonably large deployment of local anti-ddos boxes.
I'm sure mitigation boxes like this serve well in many situations if the
cost / benefit justifies the expenditure, but as with most things, it's a
case of applying the best tool for the job rather than blind application of
shiny toys.
Nick
Many hosting profiles don't require this sort of anti-DDoS kit.
My post had nothing to do with 'anti-DDoS kit'.
I'm sure mitigation boxes like this serve well in many situations if the cost / benefit justifies the expenditure, but as with most things, it's a
case of applying the best tool for the job rather than blind application of shiny toys.
'Mitigation boxes' like what?
Again, my post had nothing to do with 'mitigation boxes' or 'shiny toys'. Unless you count routers and switches as 'shiny toys'.
I've never advocated the 'blind application' of any feature, function, mechanism, or 'shiny toy'.
Perhaps you've confused me with someone else.