Which of the following security attacks occurs when an attacker sends the target system a flood of data or requests that consume the target systems resources?

The basis for this attack often targets applications like Web Servers (i.e., Windows IIS, Apache, etc…); however, application layer attacks have been evolving to application platforms like WordPress, Joomla, Drupal, Magento, and others.

The goal of application layer attacks is to take out an application, an online service, or a website.

These attacks are usually smaller than the ones we have seen before. Nevertheless, the consequence of an application layer attack can be nefarious, since they can go unnoticed until it is too late to react. That is why they are called “low and slow attacks” or even “slow-rate attacks”. They can be silent and small, especially when compared to network-layer attacks, but they can be just as disruptive.

For example, a small VPS on Linode, Digital Ocean or AWS (Amazon) can easily handle a 100,000 to 200,000 packets per second SYN flood. However, the same server running on a WordPress or Joomla CMS can barely break 500 HTTP requests per second without shutting down. That is why application layer attacks can cause as much damage as a network application attack.

When you think about the amplification effect that we discussed in Section 1.4, even one HTTP request (which an attacker can perform without spending much money or resources) can cause a server to execute a large number of internal requests and load numerous files to create the page.

Note

When application layer attacks start, they look very similar to legitimate requests from users and can escalate. The reason for that is that these attacks focus on the web application layer, which generally includes:

Hitting the web server
Running PHP scripts and
Contacting the database just to load one web page.

Application-layer attacks (mostly known as Layer 7 attacks) can be part of attacks which not only target the application, but also the bandwidth and network.

One of the reasons why these attacks are on the rise is that they tend to be less expensive to implement by malicious actors. On an application-layer attack, the amplification is CPU, memory or resource based, not network based.

These attacks are also harder to detect than network-layer attacks.

Pro Tip: Sucuri has developed a robust Website Application Firewall (WAF) solution that impedes DDoS attacks from shutting down your website. We will explain more about the Sucuri Firewall later.

Your devices, such as home routers, can be compromised and act as a botnet for DDoS attacks. We have discovered a number of large-scale DDoS attacks related to IoT devices.

Application Layer Attacks include:

The Domain Name System (DNS) is vital to the website infrastructure. DNS associates information with domain names and they can also be a target of DDoS attacks.

These attacks use spoofing, reflection, and amplification, which means that a tiny query can be largely amplified in order to result in a much larger response in bytes.

Botnets are used to send DNS requests. If the attacker wanted to target a DNS server, it would use all the botnet zombies in his network to issue DNS request messages for an amplification record from open recursive DNS servers that translate domain names into IP addresses. When it is a new request, the server promptly issues its own request to an infected server with a view to obtain the amplification record. This attack is completed using spoofing so that even though the server has never sent a request, it has been overburdened with responses.

These attacks are very popular today. They occur at Layers 3 / 4, using publicly accessible DNS servers around the world to overwhelm your web server with DNS response traffic. Your web server is overwhelmed by the influx of responses in turn making it difficult to function as its resources are depleted, making it impossible to respond to legitimate DNS traffic.

A Layer 3 DNS Amplification is a type of DDoS attack where the attacker hides the origin of the attack from the targeted site by reflecting the attack off of a third party. It uses amplification, meaning that the victim receives more byte counts than what is being sent from the attacker, increasing the power of the attack.

If these attacks are successful, the targeted site will go down and be unavailable.

Layer 7 HTTP Flood – Cache Bypass is the smartest type of attack. The attackers try to use URLs that cause the most damage making the site use up all of its resources without being cached. For example, an attack can do random dictionary searches for “news”, “gov”, “faith”, which will consume a lot from the site and will not easily be detected since it looks like a normal user’s search habits.

A Layer 7 HTTP Flood Attack is a type of DDoS attack made to overload specific parts of a site or server. They are complex and hard to detect because the sent requests look like legitimate traffic. These requests consume the server’s resources causing the site to go down. These requests can also be sent by bots, increasing the attack’s power.

An interesting point about layer 7 DDOS attacks, aka HTTP flood attacks, is that they have little dependency on bandwidth allowing them to easily take down a server by overloading its resources. Depending on the web server and application stack, even a low number of requests per second can choke the application and backend databases. On average, attacks greater than 100 requests per second have the potential to bring down most mid-sized websites.

We categorize the HTTP Floods (Layer 7 DDoS attempts) into 4 major categories:

Basic HTTP Floods: Common and simple attacks that try to access the same page over and over. They generally use the same range of IP addresses, user agents, and referrers.

Randomized HTTP Floods: Complex attacks that leverage a large pool of IP addresses and randomized the URLs, useragents and referers used.

Cache-bypass HTTP Floods: A sub-category of the randomized HTTP Floods that also try to bypass web application caching.

WordPress XMLRPC Floods: A sub-category that uses WordPress pingback as a reflection for the attacks.

Any WordPress site with pingback enabled, which is on by default, can be used in DDoS attacks against other sites.

XMLRPC is used for pingbacks, trackbacks, remote access via mobile devices and many other features. However, it can also be heavily misused by attackers.

What can happen is that other WordPress sites can send random requests at a very large scale and bring a website down.

One attacker can use thousands of clean WordPress installations to perform a DDoS attack with a simple pingback request to the XML-RPC file. In other words, a simple command in Linux can start a mammoth attack.

If you are interested in learning more about legitimate WordPress websites being abused in order to perform a DDoS attack, read this blog article: More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack.

TCP SYN flood (a.k.a. SYN flood) is a type of Distributed Denial of Service (DDoS) attack that exploits part of the normal TCP three-way handshake to consume resources on the targeted server and render it unresponsive.

Essentially, with SYN flood DDoS, the offender sends TCP connection requests faster than the targeted machine can process them, causing network saturation.

Attack description

When a client and server establish a normal TCP “three-way handshake,” the exchange looks like this:

Client requests connection by sending SYN (synchronize) message to the server.
Server acknowledges by sending SYN-ACK (synchronize-acknowledge) message back to the client.
Client responds with an ACK (acknowledge) message, and the connection is established.

In a SYN flood attack, the attacker sends repeated SYN packets to every port on the targeted server, often using a fake IP address. The server, unaware of the attack, receives multiple, apparently legitimate requests to establish communication. It responds to each attempt with a SYN-ACK packet from each open port.

The malicious client either does not send the expected ACK, or—if the IP address is spoofed—never receives the SYN-ACK in the first place. Either way, the server under attack will wait for acknowledgement of its SYN-ACK packet for some time.

Progression of a SYN flood.

During this time, the server cannot close down the connection by sending an RST packet, and the connection stays open. Before the connection can time out, another SYN packet will arrive. This leaves an increasingly large number of connections half-open – and indeed SYN flood attacks are also referred to as “half-open” attacks. Eventually, as the server’s connection overflow tables fill, service to legitimate clients will be denied, and the server may even malfunction or crash.

While the “classic” SYN flood described above tries to exhaust network ports, SYN packets can also be used in DDoS attacks that try to clog your pipes with fake packets to achieve network saturation. The type of packet is not important. Still, SYN packets are often used because they are the least likely to be rejected by default.

Methods of mitigation

While modern operating systems are better equipped to manage resources, which makes it more difficult to overflow connection tables, servers are still vulnerable to SYN flood attacks.

There are a number of common techniques to mitigate SYN flood attacks, including:

Micro blocks—administrators can allocate a micro-record (as few as 16 bytes) in the server memory for each incoming SYN request instead of a complete connection object.

SYN cookies—using cryptographic hashing, the server sends its SYN-ACK response with a sequence number (seqno) that is constructed from the client IP address, port number, and possibly other unique identifying information. When the client responds, this hash is included in the ACK packet. The server verifies the ACK, and only then allocates memory for the connection.

RST cookies—for the first request from a given client, the server intentionally sends an invalid SYN-ACK. This should result in the client generating an RST packet, which tells the server something is wrong. If this is received, the server knows the request is legitimate, logs the client, and accepts subsequent incoming connections from it.

Stack tweaking—administrators can tweak TCP stacks to mitigate the effect of SYN floods. This can either involve reducing the timeout until a stack frees memory allocated to a connection, or selectively dropping incoming connections.

Obviously, all of the above mentioned methods rely on the target network’s ability to handle large-scale volumetric DDoS attacks, with traffic volumes measured in tens of Gigabits (and even hundreds of Gigabits) per second.

Imperva mitigates a 38 day-long SYN flood and DNS flood multi-vector DDoS attack.

Imperva DDoS protection leverages Anycast technology to balance the incoming DDoS requests across its global network of high-powered scrubbing centers. With the combined capacity of its global network, Incapsula can cost-effectively exceed attacker resources, rendering the DDoS attack ineffective. The service is build to scale on demand, offering ample resources to deal with even the largest of volumetric DDoS attacks.

To assure business continuity, Imperva filtering algorithm continuously analyzes incoming SYN requests, using SYN cookies to selectively allocate resources to legitimate visitors. This enables transparent DDoS mitigation, wtih no downtime, latency of any other business disruptions.

Learn more about Imperva DDoS Protection services.