It has been a while, but it is time to jump back into the Application Denial of Service series with both feet. As we described in the introduction, application denial of service can be harder to deal with than volume-based network DDoS because it is not always obvious what’s an attack and what’s legitimate traffic. Unless you are running all your traffic through a scrubbing center, your applications will remain targets for attacks that exploit the architecture, application stacks, business logic, and even legitimate functionality of the application.

As we start digging into specific AppDoS tactics, we will start with attacks that target the server and infrastructure of your application. Given the popularity and proliferation of common application stacks, attackers can attack millions of sites with a standard technique, most of which have been in use for years. But not enough web sites have proper mitigations in place. Go figure. Server and infrastructure attacks are the low-hanging fruit of application denial of service, and will remain that so long as they continue to work.

So let’s examine the various types of application infrastructure attacks and some basic mitigations to blunt them.

Exploiting the Server

Most attacks that directly exploit web servers capitalize on features of the underlying standards and/or protocols that run the web, such as HTTP. This makes many of these attacks very hard to detect because they look like legitimate requests – by the time you figure out it’s an attack your application is down. Here are a few representative attack types:

• Slowloris: This attack, originally built by Robert ‘RSnake’ Hansen, knocks down servers by slowly delivering request headers, forcing the web server to keep connections open, without ever completing the requests. This rapidly exhausts the server’s connection pool.
• Slow HTTP Post: Similar to Slowloris, Slow HTTP Post delivers the message body slowly. This serves the same purpose of exhausting resources on the web server. Both Slowloris and Slow HTTP Post are difficult to detect because their requests look legitimate – they just never complete. The R-U-Dead-Yet attack tool automates launching a Slow HTTP Post attack via an automated user interface. To make things easier (for your adversaries), RUDY is included in many penetration testing tool packages to make knocking down vulnerable web servers easy.
• Slow Read: Yet another variation of the Slowloris approach, Slow HTTP Read involves shrinking the response window on the client side. This forces the server to send data to the client slowly to stay within the response window. The server must keep connections open to ensure the data is sent, which means it can be quickly overwhelmed with connections.

As with RUDY, these techniques are already weaponized and available for easy download and usage. You can expect innovative attackers to combine and automate these tactics into weapons of website destruction (as XerSeS has been portrayed). Regardless of packaging, these tactics are real and need to be defended against.

Mitigating these server attacks typically requires a combination of web server configuration with network-based and application-based defenses. Keep in mind that ultimately you can’t really defend the application from these kinds of attacks because they are just taking advantage of web server protocols and architecture. But you can blunt their impact with appropriate controls.

For example, Slowloris and Slow HTTP Post require tuning the web server to increase the maximum number of connections, prevent excessive connections from the same IP address, and allow a backlog of connection requests to be stored – to avoid losing legitimate application traffic. Network-based defenses on WAFs and IPSes can be tuned to look for certain web connection patterns and block offending traffic before the server becomes overwhelmed. The best approach is actually all of the above. Don’t just tune the web server or install network-based protection in front of the application – also build web applications to limit header and body sizes, and to close connections within a reasonable timeframe to ensure the connection pool is not exhausted. We will talk about building AppDoS protections into applications later in this series.

An attack like Slow HTTP Read games the client side of the connection, requires similar mitigations. But instead of looking for ingress patterns of slow activity (on either the web server or other network devices), you need to look for this kind of activity on the egress side of the application. Likewise, fronting the web application with a CDN (content delivery network) service can alleviate some of these attacks, as your web application server is a step removed from the clients, and insulated from slow reads. For more information on these services, consult our Quick Wins with Website Protection Services paper.

Brute Force

Another tactic is to overwhelm the application server – not with network traffic, but by overloading application features. We will cover an aspect of this later, when we discuss search engine and shopping cart shenanigans. For now let’s look at more basic features of pretty much every website, such as SSL handshakes and serving common web pages like the login screen, password reset, and store locator.

These attacks are so effective for overwhelming application servers because functions like SSL handshake and pages which require database calls are very compute intensive. Loading a static page is easy, but checking login credentials against the hashed database of passwords is a different animal.

First let’s consider the challenges of scaling SSL. On some pages, such as the login page, you need to encrypt traffic to protect user credentials in motion. SSL is a requirement for such pages. So why is scaling SSL handshaking such an issue? As described succinctly by Microsoft in this Tech Bulletin, there are 9 distinct steps in establishing a SSL handshake, many of which require cryptographic and key generation operations.

If an attacker uses a rented botnet to establish a million or so SSL sessions at the same time, guess what happens? It is not a bandwidth issue – it is a compute problem – and the application becomes unavailable because no more SSL connections can be established. Mitigating an SSL handshake attack involves offloading SSL termination to either a device specifically designed to terminate SSL connections, or having a CDN (or other website protection service) terminate the connections for you and then sending the traffic back to your site over a single (low-overhead) encrypted pipe.

In contrast, a database-driven page like login or a store locator needs to hit the database for every request. That typically involves 2-10 different database transactions, as well as field-level validation and other techniques for defending against cross-site scripting (XSS), CSRF (cross-site request forgery)], and other application-layer attacks.

How do you defend against these kinds of attacks? Similar to the way you deal with HTTP-based attacks like Slowloris and Slow HTTP: using network-based defenses and/or website protection services. You need to meter the transaction flow to those demanding pages, understanding that this can increase latency for visitors trying to use those capabilities during a high usage periods. But the alternative is to have your site crater.

Our next post will look at how databases and programming languages can be attacked to impact application availability.