Security Researchers have officially observed large application-layered distributed denial-of-service attacks using new techniques that could end up foiling DDoS protection and defenses. This could be a sign of things and change for web application operators.
This attack targeted a Chinese Lottery website that uses DDoS protection from Imperva. The attack peaked at 8.7Gbps. Now these days, attacks peak past 100Gbps, so this might seem really small compared to other attacks, but it’s actually scary for an attack that is operating on the application-layer.
These DDoS attacks will target either the network or application layers. With the network-layer attacks, the attackers goal is to send malicious packets over different networking protocols. These attacks will consume all of the available bandwidth which will end up clogging the internet pipes.
However, this is slightly different with application-layer attacks, which are known as HTTP floods. The goal of these attacks is to consume computation resources — such as CPU and RAM — that a web server has to process the requests. When the limits of the server is reached, the server will stop answering new requests. This will end up resulting in denial-of-service condition for all clients.
The difference between the network-layer attacks, the HTTP flood usually doesn’t reply on the size of the data to do the damage. This attack relies on the number of requests that has to be processed by the web application. Up until now, even the largest HTTP flood, which generated over 200,000 requests, didn’t even end up consuming more than just 500Mbps. This was because the packet size of each request was extremely small.
Usually most companies build the infrastructure so that the application can handle about 100 requests per second. Unless the application is protected by a DDoS protection service that finds and filters fake requests, it’s pretty simple to disrupt them, according to the Researchers at Imperva.
Being able to protect against the application-layer attacks is often done through a special hardware appliance that will sit on the customer’s network in front of the web server.
The Researchers have reported that the attack was launched from a botnet make up of computers infected with the Nitol malware. They were sending legitimate POST requests mimicking the web crawler of the Baidu search engine. The requests, at only 163,000 per second, attempted to upload randomly-generated large files to the server, resulting in the attack’s extremely large bandwidth footprint.
Imperva Researchers said in a blog post:
Application layer traffic can only be filtered after the TCP connection has been established. Unless you are using an off-premise mitigation solution, this means that malicious requests are going to be allowed through your network pipe, which is a huge issue for multi-gig attacks.
This means that the network-layer DDoS protection service will let the packets through to be inspected by the customer’s on-premise appliance. This is designed to protect the application layer even more. However, the packets won’t even reach the appliance because they will generate more traffic than the customer’s uplink will be able to handle. It’s pretty much hiding a network-layer attack behind an application-layer one.
Imperva Researchers also said:
Granted, some of the larger organizations today do have a 10Gb burst uplink. Still, perpetrators could easily ratchet up the attack size, either by initiating more requests or by utilizing additional botnet resources. Hence, the next attack could easily reach 12 or 15Gbps, or more. Very few non-ISP organizations have the size of infrastructure required to mitigate attacks of that size on-premise.
For the organizations in industries like finance, there’s no easy answer to fighting off such high-bandwidth application-layer attacks at all. The custom web applications require the use of HTTPS to encrypt data in transit and they need to terminate those HTTPS connections inside their own infrastructure. This is to be in compliance with the regulatory requirements regarding the protection of financial and personal data.
Therefore, the application-layer DDoS protection that relies on inspecting the requests after they’ve been decrypted also needs to happen within their own infrastructure.