Effectively Completing the Attack (and this posting)…
….let’s try this again…Blognostication and saving things as drafts seems to have gotten the best of me and munged some previous versions of this post, my apologies – please reread for a slighly less confusing version.
In compiling results from the current revision of Arbor’s recent Infrastructure Security Survey, I’m still not exactly sure what to think [again] about the primary reported techniques employed for DDoS mitigation. That is, destination-based router ACLs and, trailing closely, BGP destination-based blackhole routing. Unquestionably, these two techniques continue to dominate as the primary mitigation mechanisms employed by ISPs and hybrid network operators today.
Now, in case you’re not following, both of these mitigation techniques effectively complete the attack by taking the target host/service offline, with destination-based ACLs being slightly more elegant than blackhole routing because select services on the target host can be blocked rather than breaking all reachability to the host. Unfortunately, it’s usually the most critical service on the target host that’s being attacked, so there’s effectively very little difference.
However, why these techniques are attractive to the network operator is rather straight forward, IMO. With the rise in attack magnitude (bps & pps) many attacks today not only impact the target host, their entire local network segment and quite often their entire upstream Internet connection, but the upstream service providers entire PoP as well. For example, consider a target host with an upstream dedicated Internet access connection that’s provided via a T1 (~1.5Mbps) circuit being attacked. Assume some user at the site provokes a would-be attacker by calling them a name on IRC. Now, this attacker decides he’s going to attack the user’s host with his bantamweight botnet (say, 200 hosts).
Well, the attacker doesn’t have the time or clue to determine that he can likely take the user offline with just a couple Mbps of data, nor would he care if he did. So, he commands all of his bots to flood the users IP address with large UDP packets – each of the bots being more than capable of generating, hrmm… three Mbps of UDP traffic towards the target’s IP address. So, we have 200 hosts * 3 Mbps == 600 Mbps, easy enough.
This is unfortunate for the user’s upstream service provider as the PoP to which the user’s T1 is connect provides fractional and full T1 Internet access to 999 other similar small business customers, all of which rely heavily on the availability of their Internet services. When the user’s Internet service provider was building out the PoP to which the user is now connected they applied reasonable [or perhaps overly gratuitous given today’s standards!] oversubscription ratios (e.g., planning for 1000 dedicated access ports at the PoP with T1 or less subscribed access bandwidth requirements and sufficient redundancy, they provisioned two OC-3/155 Mbps backbone uplinks resulting in packet love with the user, not only is the user and their entire organization quickly taken offline, but the service provider’s inter-PoP connections (with an aggregate available capacity of ~300 Mbps) are immediately saturated, resulting in collateral damage that impacts all users in the PoP. Largely dependent, of course, on the attack source distribution and network ingress locations, but more than likely additional upstream backbone links and interconnections with other networks, and subsequently, other customers, are effected as well.
As such, the network operator must immediately focus on solutions that restore services to as many subscribers as possible, as fast as possible. The simplest way to do this is to drop as much of the attack traffic as feasible at the optimal point in the network – the optimal point typically being the point where the attack traffic is entering the network. And how do you do this – with destination-based ACLs applied at the ingress network interfaces and/or BGP destination-based blackhole routing on the ingress nodes in the network.
The result is that collateral damage is minimized; the offshoot being that the attack is effectively completed.
Fortunately, most of the attacks are rather temporal in nature and with the right clue and an ever-growing arsenal of DNS, scrubbing and related load-balancing tricks (and a slew of other techniques) the services at the victims location can _usually be restored in short order. If attacks employ more sophisticated attack vectors this becomes more difficult – but unfortunately or not, the bar for successfully launching DDoS attacks today is just not that high.
Now, consider for a moment some real-world stats:
- the idea of greater than one million bots under a single command and control
- attacks that have exceeded 15 Gbps sustained
- attacks that have exceeded 22 Mpps (Yes, that’s 22 million packets per second!)
- evolving interest in greater amplification and Application Layer attack vectors
— it makes for interesting soup…
With the impact on infrastructure, coupled with complexity and cost ($$$) of deployment for better mitigation mechanisms – I’m not actually surprised by the fact that effectively completing the attack techniques tend to dominate DDoS mitigation today; I’ll remain optimistic that technical and business models will continue to evolve to accommodate the market opportunity, making things a bit more difficult for the miscreants.
I do also hope that the ease of localized temporal mitigation by employing destination-based ACLs and BGP destination-based blackhole routing doesn’t make folks lose sight of the fact that until the bots are identified and sanitized and the enabling command and control substrate disrupted – and perpetrators prosecuted, the bot problem will just continue to manifest itself via DDoS .. and more economically appealing avenues (e.g., spam, phishing, click fraud, etc..).