The result is a flash-crowd style flood of attacks that overwhelm not only the site, but its infrastructure. Firewalls have become overwhelmed, ISPs have been been flooded, services have been disrupted. All because the attacks are not a single concerted effort to disrupt service but a dizzying array of SYN flood, TCP connection flooding, pings of death, excessive HTTP headers and SlowLoris, and good old fashioned HTTP GETs flooding. These attacks are happening simultaneously, directed at the same service, and they’re doing a good job in many cases of achieving its goals: service outages. That’s because defeating an attack is infinitely easier than detecting it in the first place, particularly at the application layer. It’s nearly impossible for traditional security measures to detect because many of the attacks perpetrated at the application layer appear to be completely legitimate requests; there’s just a lot more of them.
Traditional solutions aren’t working. Blocking the attack at the ISP has proven to be too slow and unable to defend against the (new) distributed nature of these attacks. Firewalls have buckled under pressure, unable to handle the load, and been yanked out of the line of fire, being replaced with other technology more capable of fending off attacks across the entire network stack. And now it’s been reported that a Java Script DDoS is in the works, aimed again at MasterCard.
TOP-to-BOTTOM SECURITY
What this means is organizations need to be thinking of security as spanning all attack vectors at the same time. It is imperative that organizations protect critical applications against both traditional attack vectors as well as those at the application layer disguised as image_thumb_2[1] legitimate requests. Organizations need to evaluate their security posture and ensure that every infrastructure component through which a request flows can handle the load in the event of a massive “3DoS”. It’s not enough to ensure that there’s capacity in the application infrastructure if an upstream network component may buckle under the load.
And it’s costly to leverage virtualization and cloud computing as a means to automatically scale to keep ahead of the attack. The price of uptime may, for some organizations, become overwhelming in the face of a targeted 3DoS as more and more capacity is provisioned to (hopefully) handle the load.
Organizations should look for strategic points of control within their architectures and leverage capabilities to detect and prevent attacks from compromising availability. In every data center architecture there are aggregation points. These are points (one or more components) through which all traffic is forced to flow, for one reason or another.
For example, the most obvious strategic point of control within a data center is at its perimeter – the router and firewalls that control inbound access to resources and in some cases control outbound access as well. All data flows through this strategic point of control and because it’s at the perimeter of the data center it makes sense to implement broad resource access policies at this point. Similarly, strategic points of control occur internal to the data center at several “tiers” within the architecture. For web applications, that strategic point of control is generally the application delivery controller (load balancer for you old skool architects). Its position in the network affords it the ability to intercept, inspect, and manipulate if necessary the communications occurring between clients and web applications.
These points of control are strategic precisely because their topological location within the architecture provides the visibility necessary to recognize an attack at all layers of the network stack and apply the proper security policies to protect resources downstream that are not imbued with a holistic view of application usage and therefore cannot accurately determine what is legitimate versus what is an attack.
AS ATTACK TECHNIQUES EVOLVE, SO TOO MUST SECURITY STRATEGIES
Old notions of “security” have to evolve, especially as the application itself becomes an attack vector. The traditional method of deploying individual point solutions, each addressing a specific type or class of attack, is failing to mitigate these highly distributed and context_2[1] diverse attacks. It’s not just the cost and complexity of such a chained security architecture (though that is certainly a negative) it’s that these solutions are either application or network focused, but almost never both. Such solutions cannot individually recognize and thus address 3DoS attacks because they lack the context necessary to “see” an attack that spans the entire network stack – from top to bottom.
An integrated, unified application delivery platform has the context and the visibility across not only the entire network stack but all users – legitimate or miscreant – accessing the applications it delivers. Such a platform is capable of detecting and subsequently addressing a 3DoS in a much more successful manner than traditional solutions. And it’s much less complex and costly to deploy and manage than its predecessors.
The success of Anonymous in leveraging 3DoS attacks to disrupt services across a variety of high-profile sites will only serve to encourage others to leverage similar methods to launch attacks on other targets. As the new year approaches, it’s a good time to make an organizational resolution to re-evaluate the data center’s security strategy and, if necessary, take action to redress architectures incapable of mitigating such an attack.
https://devcentral.f5.com/weblogs/macvittie/archive/2010/12/15/what-we-learned-from-anonymous-ddos-is-now-3dos.aspx
No comments:
Post a Comment