In today’s modern web world, a denial-of service (DoS) attack can take down an entire website in a matter of minutes. According to a report by security and network management vendors Prolexic and Arbor Networks, these types of attacks are on the rise, and were recently one of the key forms of attacks in the U.S. Department of Homeland Security’s investigation on America’s water and energy utilities constant cyber-espionage. Whether a governmental organization or business, these types of attacks need to be on everyone’s radar.
While DoS attacks themselves are nothing new, new techniques and technologies in DoS attacks can be more aggressive than their predecessors and require a different kind of approach to network security. This blog will explain what’s different about these new attacks, how best to approach them and identify measures that are no longer successful in combating them.
A quick history of DoS/DDoS/AppDoS
The goal of any Denial of Service attack is simply to overwhelm a service to the point where it no longer works. This is typically done via brute force methods mixed with varying degrees of cleverness.
A “classic” example of a DoS attack is SYN flooding which attacks a (web) server directly by starting a conversation at the TCP layer, but never finishing it. The attack was effective because there were relatively few resources on servers for partially-open connections. Solutions initially focused on protecting web servers with a proxy server (or security appliance) in front of the real server. These proxies would validate remote clients by ensuring that the TCP 3-way handshake completed into a full connection. The “real” solution came with server OS fixes to reinforce the weaknesses exploited by the DoS.
The next major advance in DoS technology was Distributed Denial of Service (DDoS), in which large numbers of attackers simultaneously targeted a single service. The coordinated nature of the attack comes from botnets, which are composed of PCs infected by a worm, Trojan, or virus designed to make the PC an unwitting attacker. The infected PCs typically monitor a location on the Internet, looking for orders to attack. The real game changer in DDoS is that the large numbers of attackers can simply use brute force to overwhelm the network resources around a server. Placing a proxy or firewall in front of a server is an ineffective defense if the WAN link itself is flooded. Defense here usually requires either coordinating with the WAN provider to block addresses upstream, or moving the service to a hosting provider with enough bandwidth to simply absorb a DDoS.
In an interesting twist, self-proclaimed “hacktivist” groups like “Anonymous” have evangelized DDoS as a method of protest. Rather than using botnets of infected PCs, these groups are providing “opt-in” tools – although some versions of these tools provide no later method to opt back out or even uninstall.
The latest approach in DoS is following the trends of attackers in moving up the stack to applications. Application Denial of Service (AppDoS) uses vulnerabilities in specific server applications to create high-impact DoS with very low attack bandwidth. Whereas DDoS relied almost purely on brute force to overwhelm infrastructure, AppDoS shows a return to the cleverness of the original DoS. What makes AppDoS so effective is that application-specific vulnerabilities use layer 7 attacks. While these attacks will not work on every server, they use the regular behavior of lower-layer protocols like TCP, which makes them harder to detect. A true AppDoS attack on a web server would even use a well-formed HTTP request. Attacks of this kind include Slowloris, which only works against Apache.
The author of the Slowloris tool has provided some excellent points of comparison about why it’s a new generation attack tool. Compared, to first generation DoS, “This is NOT a TCP DoS, because it is actually making a full TCP connection, not a partial one; however it is making partial HTTP requests. It’s the equivalent of a SYN flood but over HTTP.” Also, compared to brute force DDoS methods, “Slowloris is also NOT a GET request flooder. Slowloris requires only a few hundred requests at long term and regular intervals, as opposed to tens of thousands on an ongoing basis.”
The new approach to DoS attacks versus the old
As stated before, today’s DDoS attacks aren’t just against servers, but also against the network infrastructure. A firewall can only protect what’s behind it, so if it’s on-premise, it can’t prevent the WAN links from being flooded. Instead, to properly respond to a DDoS attack, network administrators need to coordinate with their WAN carrier to try and block the traffic upstream. There is a category of service provider offering “clean pipe” hosting with automatic DDoS squelching, but it’s often more cost effective to simply move externally-visible servers to a host with enough bandwidth to absorb DDoS attacks invisibly.
Secondly, the attack is going to come from a large number of IP addresses. These attackers will likely be a mix of botnets and self-proclaimed hacktivists. With an influx of this size, it is virtually impossible to add entries by hand for each node you are trying to block. In response you may want to try and filter aggregated blocks of addresses, but remember that the nature of botnets implies that the addresses will be widely dispersed rather than clustered together—so a lot of legitimate traffic could potentially be blocked as well. Rate limiting may be useful for brute-force DDoS, identifying each attacker by its aggressive connection rate, and automatically blocking. However, AppDoS attacks can evade rate limits by using high-impact, low-bandwidth techniques.
Finally, the speed at which the attack commences – sometimes referred to as the “thundering herd” effect – doesn’t leave much time to react and counter the problem. A coordinated DDoS, leveraging botnets and other always-on attackers, can hit without any advance warning. If you don’t have a tested plan to respond to DoS attacks, you’re going to have to invent one on the fly while simultaneously reporting your status every 15 minutes to the CIO.
How to Combat this New Approach:
Despite attempts of new tools to avoid automated blocking, there are usually key indicators which uniquely identify packets as belonging to the attack. Analysis by the University of Twente on the LOIC DDoS tool found the techniques to be surprisingly simple from a protocol perspective, featuring high repetition of a similar URL pattern, and absolutely no lower-layer obfuscation like IP spoofing. If you have a packet capture infrastructure in place, the attack packets will be easy to find, as they’ll constitute the majority of your capture. With this in mind, you’ll need to find a signature or behavior which is common to the attack traffic, but not on your normal traffic. In some cases your packet analyzer has visualization or an expert analysis tool to identify a useful characteristic for you. A very useful example of this kind of fingerprint analysis is the SpiderLabs analysis of LOIC, including packet dump and Snort rules.
The key here is to turn the attack’s strength into its weakness. Highly automated attacks will be fairly homogenous, so an attack fingerprint can quickly be developed and deployed, and the attack impact halted. The strength of DDoS comes from central coordination of large numbers of already-deployed attack engines. While these engines have dynamic target settings, they have fixed methods of attack. Identifying and blocking those attack methods greatly reduces the attack impact. This is true even of tools which are designed to provide increased detection avoidance via mixed attack method and increased randomization. After the HOIC tool was released as a detection-resistant alternative to LOIC, SpiderLabs analysis of HOIC showed that it has certain hard-coded aspects which still allow for detection and blocking. Fixing those mistakes might be easy for the attack tool authors, but the difficulties of distribution of black-hat software make upgrade releases problematic. Anyone who has done PC support knows the pain of large-scale application version management. Imagine performing version upgrades without benefit of an official trusted source of the software.
As an additional step in combating DoS attacks, once you have a fingerprint identified, you can also use it to determine if any of the hosts in your own network are sending similar traffic, causing someone else the same pain you’re feeling. If you have a network traffic recorder, use your packet analyzer dashboard to examine the historical traffic to and from that host. Even without a fingerprint, you can get started by looking at suspicious traffic. Command and Control of botnets has historically happened via IRC, so look for traffic to port 6667 and surrounding ports (e.g. 6660-6669). Any outbound traffic to a non-standard port is worth investigating to identify the C&C, report it per your CERT process, and block traffic from your network to prevent future botnet activity.
In the end, no security system on the market is foolproof, but as cyber crimes get more sophisticated, businesses must be able to recognize and constantly adapt to new security threats. In order to ensure that you are completely prepared in the event of a DoS attack, there must also be a security “insurance policy” in place—often in the form of a network recorder. The ability to quickly suspend this new level of DoS attacks is tantamount to protecting your reputation, your data, and your business a whole. Hopefully this blog serves as a reminder that if you don’t have a DoS mitigation plan already, now is a good time to create one before it’s too late.