What is a UDP flood attack?

A UDP flood is a type of denial-of-service attack in which a large number of User Datagram
Protocol (UDP) packets are sent to a targeted server with the aim of overwhelming that device’s
ability to process and respond. The firewall protecting the targeted server can also become
exhausted as a result of UDP flooding, resulting in a denial-of-service to legitimate traffic.

How does a UDP flood attack work?

A UDP flood works primarily by exploiting the steps that a server takes when it responds to a
UDP packet sent to one of it’s ports. Under normal conditions, when a server receives a UDP
packet at a particular port, it goes through two steps in response:

1. The server first checks to see if any programs are running which are presently listening
for requests at the specified port.

2. If no programs are receiving packets at that port, the server responds with a ICMP (ping)
packet to inform the sender that the destination was unreachable.

A UDP flood can be thought of in the context of a hotel receptionist routing calls. First, the
receptionist receives a phone call where the caller asks to be connected to a specific room. The
receptionist then needs to look through the list of all rooms to make sure that the guest is
available in the room and willing to take the call. Once the receptionist realizes that the guest is
not taking any calls, they have to pick the phone back up and tell the caller that the guest will not
be taking the call. If suddenly all the phone lines light up simultaneously with similar requests
then they will quickly become overwhelmed.

As each new UDP packet is received by the server, it goes through steps in order to process the
request, utilizing server resources in the process. When UDP packets are transmitted, each packet
will include the IP address of the source device. During this type of DDoS attack, an attacker will
generally not use their own real IP address, but will instead spoof the source IP address of the
UDP packets, impeding the attacker’s true location from being exposed and potentially saturated
with the response packets from the targeted server.
As a result of the targeted server utilizing resources to check and then respond to each received
UDP packet, the target’s resources can become quickly exhausted when a large flood of UDP
packets are received, resulting in denial-of-service to normal traffic.

How is a UDP flood attack mitigated?

Most operating systems limit the response rate of ICMP packets in part to disrupt DDoS attacks
that require ICMP response. One drawback of this type of mitigation is that during an attack
legitimate packets may also be filtered in the process. If the UDP flood has a volume high
enough to saturate the state table of the targeted server’s firewall, any mitigation that occurs at
the server level will be insufficient as the bottleneck will occur upstream from the targeted
device.

How does Cloudflare mitigate UDP Flood attacks?

In order to mitigate UDP attack traffic before it reaches its target, Cloudflare drops all UDP
traffic not related to DNS at the network edge. Because Cloudflare’s Anycast network scatters
web traffic across many Data Centers, we have sufficient capacity to handle UDP flood attacks
of any size. Learn more about Cloudflare DDoS Protection.

What is a SYN flood attack?

A SYN flood (half-open attack) is a type of denial-of-service (DDoS) attack which aims to make
a server unavailable to legitimate traffic by consuming all available server resources. By
repeatedly sending initial connection request (SYN) packets, the attacker is able to overwhelm
all available ports on a targeted server machine, causing the targeted device to respond to
legitimate traffic sluggishly or not at all.

How does a SYN flood attack work?

SYN flood attacks work by exploiting the handshake process of a TCP connection. Under
normal conditions, TCP connection exhibits three distinct processes in order to make a
connection.

1. First, the client sends a SYN packet to the server in order to initiate the connection.

2. The server than responds to that initial packet with a SYN/ACK packet, in order to
acknowledge the communication.

3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from
the server. After completing this sequence of packet sending and receiving, the TCP
connection is open and able to send and receive data.

To create denial-of-service, an attacker exploits the fact that after an initial SYN packet has been
received, the server will respond back with one or more SYN/ACK packets and wait for the final
step in the handshake. Here’s how it works:

1. The attacker sends a high volume of SYN packets to the targeted server, often with
spoofed IP addresses.

2. The server then responds to each one of the connection requests and leaves an open port
ready to receive the response.

3. While the server waits for the final ACK packet, which never arrives, the attacker
continues to send more SYN packets. The arrival of each new SYN packet causes the
server to temporarily maintain a new open port connection for a certain length of time,
and once all the available ports have been utilized the server is unable to function
normally.
In networking, when a server is leaving a connection open but the machine on the other side of
the connection is not, the connection is considered half-open. In this type of DDoS attack, the
targeted server is continuously leaving open connections and waiting for each connection to
timeout before the ports become available again. The result is that this type of attack can be
considered a “half-open attack”.

A SYN flood can occur in three different ways:

1. Direct attack: A SYN flood where the IP address is not spoofed is known as a direct
attack. In this attack, the attacker does not mask their IP address at all. As a result of the
attacker using a single source device with a real IP address to create the attack, the
attacker is highly vulnerable to discovery and mitigation. In order to create the half-open
state on the targeted machine, the hacker prevents their machine from responding to the
server’s SYN-ACK packets. This is often achieved by firewall rules that stop outgoing
packets other than SYN packets or by filtering out any incoming SYN-ACK packets
before they reach the malicious users machine. In practice this method is used rarely (if
ever), as mitigation is fairly straightforward – just block the IP address of each malicious
system. If the attacker is using a botnet such as the Mirai botnet they won’t care about
masking the IP of the infected device.

2. Spoofed Attack: A malicious user can also spoof the IP address on each SYN packet they
send in order to inhibit mitigation efforts and make their identity more difficult to
discover. While the packets may be spoofed, those packets can potentially be traced back
to their source. It’s difficult to do this sort of detective work but it’s not impossible,
especially if Internet service providers (ISPs) are willing to help.

3. Distributed attack (DDoS): If an attack is created using a botnet the likelihood of

tracking the attack back to its source is low. For an added level of obfuscation, an attacker
may have each distributed device also spoof the IP addresses from which it sends packets.
If the attacker is using a botnet such as the Mirai botnet, they generally won’t care about
masking the IP of the infected device.

By using a SYN flood attack, a bad actor can attempt to create denial-of-service in a target
device or service with substantially less traffic than other DDoS attacks. Instead of volumetric
attacks, which aim to saturate the network infrastructure surrounding the target, SYN attacks
only need to be larger than the available backlog in the target’s operating system. If the attacker
is able to determine the size of the backlog and how long each connection will be left open
before timing out, the attacker can target the exact parameters needed to disable the system,
thereby reducing the total traffic to the minimum necessary amount to create denial-of-service.

How is a SYN flood attack mitigated?

SYN flood vulnerability has been known for a long time and a number of mitigation pathways
have been utilized. A few approaches include:

Increasing Backlog queue

Each operating system on a targeted device has a certain number of half-open connections that it
will allow. One response to high volumes of SYN packets is to increase the maximum number of
possible half-open connections the operating system will allow. In order to successfully increase
the maximum backlog, the system must reserve additional memory resources to deal with all the
new requests. If the system does not have enough memory to be able to handle the increased
backlog queue size, system performance will be negatively impacted, but that still may be better
than denial-of-service.

Recycling the Oldest Half-Open TCP connection

Another mitigation strategy involves overwriting the oldest half-open connection once the
backlog has been filled. This strategy requires that the legitimate connections can be fully
established in less time than the backlog can be filled with malicious SYN packets. This
particular defense fails when the attack volume is increased, or if the backlog size is too small to
be practical.

SYN cookies

This strategy involves the creation of a cookie by the server. In order to avoid the risk of
dropping connections when the backlog has been filled, the server responds to each connection
request with a SYN-ACK packet but then drops the SYN request from the backlog, removing the
request from memory and leaving the port open and ready to make a new connection. If the
connection is a legitimate request, and a final ACK packet is sent from the client machine back to
the server, the server will then reconstruct (with some limitations) the SYN backlog queue entry.
While this mitigation effort does lose some information about the TCP connection, it is better
than allowing denial-of-service to occur to legitimate users as a result of an attack.

How does Cloudflare mitigate SYN Flood attacks?

Cloudflare mitigates this type of attack in part by standing between the targeted server and the
SYN flood. When the initial SYN request is made, Cloudflare handles the handshake process in
the cloud, withholding the connection with the targeted server until the TCP handshake is
complete. This strategy takes the resource cost of maintaining the connections with the bogus
SYN packets off the targeted server and places it on Cloudflare’s Anycast network. Learn more
about how Cloudflare's DDoS Protection works.
What is a DNS Flood?
Domain Name System (DNS) servers are the “phonebooks” of the Internet; they are the path
through which Internet devices are able to lookup specific web servers in order to access Internet
content. A DNS flood is a type of distributed denial-of-service attack (DDoS) where an attacker
floods a particular domain’s DNS servers in an attempt to disrupt DNS resolution for that
domain. If a user is unable to find the phonebook, it cannot lookup the address in order to make
the call for a particular resource. By disrupting DNS resolution, a DNS flood attack will
compromise a website, API, or web application's ability respond to legitimate traffic. DNS flood
attacks can be difficult to distinguish from normal heavy traffic because the large volume of
traffic often comes from a multitude of unique locations, querying for real records on the
domain, mimicking legitimate traffic.

How does a DNS flood attack work?

The function of the Domain Name System is to translate between easy to remember names (e.g.
example.com) and hard to remember addresses of website servers (e.g. 192.168.0.1), so
successfully attacking DNS infrastructure makes the Internet unusable for most people. DNS
flood attacks constitute a relatively new type of DNS-based attack that has proliferated with the
rise of high bandwidth Internet of Things (IoT) botnets like Mirai. DNS flood attacks use the
high bandwidth connections of IP cameras, DVR boxes and other IoT devices to directly
overwhelm the DNS servers of major providers. The volume of requests from IoT devices
overwhelms the DNS provider’s services and prevents legitimate users from accessing the
provider's DNS servers.
DNS flood attacks differ from DNS amplification attacks. Unlike DNS floods, DNS
amplification attacks reflect and amplify traffic off unsecured DNS servers in order to hide the
origin of the attack and increase its effectiveness. DNS amplification attacks use devices with
smaller bandwidth connections to make numerous requests to unsecured DNS servers. The
devices make many small requests for very large DNS records, but when making the requests,
the attacker forges the return address to be that of the intended victim. The amplification allows
the attacker to take out larger targets with only limited attack resources.

How can a DNS Flood attack be mitigated?

DNS floods represent a change from traditional amplification based attack methods. With easily
accessible high bandwidth botnets, attackers can now target large organizations. Until
compromised IoT devices can be updated or replaced, the only way to withstand these types of
attacks is to use a very large and highly distributed DNS system that can monitor, absorb, and
block the attack traffic in realtime. Learn about how Cloudflare's DDoS Protection protects
against DNS flood attacks.

What is a SSDP DDoS Attack?

A Simple Service Discovery Protocol (SSDP) attack is a reflection-based distributed denial-of-
service (DDoS) attack that exploits Universal Plug and Play (UPnP) networking protocols in
order to send an amplified amount of traffic to a targeted victim, overwhelming the target’s
infrastructure and taking their web resource offline.

Here is a free tool to check to see if your public IP has any exposed SSDP devices: check SSDP
DDoS vulnerability.

How does a SSDP Attack work?

Under normal circumstances, the SSDP protocol is used to allow UPnP devices to broadcast their
existence to other devices on the network. For example, when a UPnP printer is connected to a
typical network, after it receives an IP address, the printer is able to advertise its services to
computers on the network by sending a message to a special IP address called a multicast
address. The multicast address then tells all the computers on the network about the new printer.
Once a computer hears the discovery message about the printer, it makes a request to the printer
for a complete description of its services. The printer then responds directly to that computer
with a complete list of everything it has to offer. An SSDP attack exploits that final request for
services by asking the device to respond to the targeted victim.

Here are the 6 steps of a typical SSDP DDoS attack:

1. First the attacker conducts a scan looking for plug-and-play devices that can be utilized as
amplification factors.

2. As the attacker discovers networked devices, they create a list of all the devices that
respond.

3. The attacker creates a UDP packet with the spoofed IP address of the targeted victim.

4. The attacker then uses a botnet to send a spoofed discovery packet to each plug-and-play
device with a request for as much data as possible by setting certain flags, specifically
ssdp:rootdevice or ssdp:all.

5. As a result, each device will send a reply to the targeted victim with an amount of data up
to about 30 times larger than the attacker’s request.

6. The target then receives a large volume of traffic from all the devices and becomes
overwhelmed, potentially resulting in denial-of-service to legitimate traffic.

How is a SSDP Attack mitigated?

For network administrators, a key mitigation is to block incoming UDP traffic on port 1900 at
the firewall. Provided the volume of traffic isn’t enough to overwhelm the network
infrastructure, filtering traffic from this port will likely be able to mitigate such an attack. For a
deeper dive on SSDP attacks and more mitigation strategies, explore technical details about an
SSDP attack.
Do you want to know if you have a vulnerable SSDP service that can be used in a DDoS attack?
As mentioned before, we’ve created a free tool to check to see if your public IP has any exposed
SSDP devices. To check for a SSDP DDoS vulnerability, you can use this free tool.

How does Cloudflare mitigate SSDP attacks?

Cloudflare eliminates SSDP attacks by stopping all the attack traffic before it reaches it’s target;
UDP packets targeting Port 1900 are not be proxied to the origin server, and the load for
receiving the initial traffic falls on Cloudflare’s network. We offer full protection from SSDP and
other layer 3 amplification attacks.

Although the attack will target a single IP address, our Anycast network will scatter all attack
traffic to the point where it is no longer disruptive. Cloudflare is able to use our advantage of
scale to distribute the weight of the attack across many Data Centers, balancing the load so that
service is never interrupted and the attack never overwhelms the targeted server’s infrastructure.
During a recent six-month window, our DDoS mitigation system "Gatebot" detected 6,329
simple reflection attacks (that's one every 40 minutes), and the network successfully mitigated all
of them. Learn more about Cloudflare's DDoS Protection.

What is a NTP amplification attack?

A NTP amplification attack is a reflection-based volumetric distributed denial-of-service (DDoS)
attack in which an attacker exploits a Network Time Protocol (NTP) server functionality in order
to overwhelm a targeted network or server with an amplified amount of UDP traffic, rendering
the target and its surrounding infrastructure inaccessible to regular traffic.

How does a NTP amplification attack work?

All amplification attacks exploit a disparity in bandwidth cost between an attacker and the
targeted web resource. When the disparity in cost is magnified across many requests, the
resulting volume of traffic can disrupt network infrastructure. By sending small queries that
result in large responses, the malicious user is able to get more from less. When multiplying this
magnification by having each bot in a botnet make similar requests, the attacker is both
obfuscated from detection and reaping the benefits of greatly increased attack traffic.

DNS flood attacks differ from DNS amplification attacks. Unlike DNS floods, DNS
amplification attacks reflect and amplify traffic off unsecured DNS servers in order to hide the
origin of the attack and increase its effectiveness. DNS amplification attacks use devices with
smaller bandwidth connections to make numerous requests to unsecured DNS servers. The
devices make many small requests for very large DNS records, but when making the requests,
the attacker forges the return address to be that of the intended victim. The amplification allows
the attacker to take out larger targets with only limited attack resources.

NTP amplification, much like DNS amplification, can be thought of in the context of a malicious
teenager calling a restaurant and saying “I’ll have one of everything, please call me back and tell
me my whole order.” When the restaurant asks for a callback number, the number given is the
targeted victim’s phone number. The target then receives a call from the restaurant with a lot of
information that they didn’t request.

The Network Time Protocol is designed to allow internet connected devices to synchronize their
internal clocks, and serves an important function in internet architecture. By exploiting the
monlist command enabled on some NTP servers, an attacker is able to multiply their initial
request traffic, resulting in a large response. This command is enabled by default on older
devices, and responds with the last 600 source IP addresses of requests which have been made to
the NTP server. The monlist request from a server with 600 addresses in its memory will be 206
times larger than the initial request. This means that an attacker with 1 GB of internet traffic can
deliver a 200+ gigabyte attack - a massive increase in the resulting attack traffic.

An NTP amplification attack can be broken down into four steps:

1. The attacker uses a botnet to send UDP packets with spoofed IP addresses to a NTP
server which has its monlist command enabled. The spoofed IP address on each packet
points to the real IP address of the victim.

2. Each UDP packet makes a request to the NTP server using its monlist command,
resulting in a large response.

3. The server then responds to the spoofed address with the resulting data.

4. The IP address of the target receives the response and the surrounding network
infrastructure becomes overwhelmed with the deluge of traffic, resulting in a denial-of-
service.

As a result of the attack traffic looking like legitimate traffic coming from valid servers,
mitigating this sort of attack traffic without blocking real NTP servers from legitimate activity is
difficult. Because UDP packets do not require a handshake, the NTP server will send large
responses to the targeted server without verifying that the request is authentic. These facts
coupled with a built-in command, which by default sends a large response, makes NTP servers
an excellent reflection source for DDoS amplification attacks.
How is a NTP amplification attack mitigated?
For an individual or company running a website or service, mitigation options are limited. This
comes from the fact that the individual’s server, while it might be the target, is not where the
main effect of a volumetric attack is felt. Due to the high amount of traffic generated, the
infrastructure surrounding the server feels the impact. The Internet Service Provider (ISP) or
other upstream infrastructure providers may not be able to handle the incoming traffic without
becoming overwhelmed. As a result, the ISP may blackhole all traffic to the targeted victim’s IP
address, protecting itself and taking the target’s site off-line. Mitigation strategies, aside from
offsite protective services like Cloudflare DDoS protection, are mostly preventative internet
infrastructure solutions.

Disable monlist - reduce the number of NTP servers which support the monlist command.

A simple solution to patching the monlist vulnerability is to disable the command. All version of
the NTP software prior to version 4.2.7 are vulnerable by default. By upgrading a NTP server to
4.2.7 or above, the command is disabled, patching the vulnerability. If upgrading is not possible,
following the US-CERT instructions will allow a server’s admin to make the necessary changes.

Source IP verification – stop spoofed packets leaving the network.

Because the UDP requests being sent by the attacker’s botnet must have a source IP address
spoofed to the victim’s IP address, a key component in reducing the effectiveness of UDP-based
amplification attacks is for internet service providers (ISPs) to reject any internal traffic with
spoofed IP addresses. If a packet is being sent from inside the network with a source address that
makes it appear like it originated outside the network, it’s likely a spoofed packet and can be
dropped. Cloudflare highly recommends that all providers implement ingress filtering, and at
times will reach out to ISPs who are unknowingly taking part in DDoS attacks (in violation of
BCP38) and help them realize their vulnerability.

The combination of disabling monlist on NTP servers and implementing ingress filtering on
networks which presently allow IP spoofing is an effective way to stop this type of attack before
it reaches its intended network.

How does Cloudflare mitigate NTP amplification attacks?

With a properly configured firewall and sufficient network capacity (which isn't always easy to
come by unless you are the size of Cloudflare), it's trivial to block reflection attacks such as NTP
amplification attacks. Although the attack will target a single IP address, our Anycast network
will scatter all attack traffic to the point where it is no longer disruptive. Cloudflare is able to use
our advantage of scale to distribute the weight of the attack across many Data Centers, balancing
the load so that service is never interrupted and the attack never overwhelms the targeted server’s
infrastructure. During a recent six-month window, our DDoS mitigation system "Gatebot"
detected 6,329 simple reflection attacks (that's one every 40 minutes), and the network
successfully mitigated all of them. Learn more about Cloudflare's advanced DDoS Protection.

What is a DNS amplification attack?

This DDoS attack is a reflection-based volumetric distributed denial-of-service (DDoS) attack in
which an attacker leverages the functionality of open DNS resolvers in order to overwhelm a
target server or network with an amplified amount of traffic, rendering the server and its
surrounding infrastructure inaccessible.

How does a DNS amplification attack work?

All amplification attacks exploit a disparity in bandwidth consumption between an attacker and
the targeted web resource. When the disparity in cost is magnified across many requests, the
resulting volume of traffic can disrupt network infrastructure. By sending small queries that
result in large responses, the malicious user is able to get more from less. By multiplying this
magnification by having each bot in a botnet make similar requests, the attacker is both
obfuscated from detection and reaping the benefits of greatly increased attack traffic.

A single bot in a DNS amplification attack can be thought of in the context of a malicious
teenager calling a restaurant and saying “I’ll have one of everything, please call me back and tell
me my whole order.” When the restaurant asks for a callback number, the number given is the
targeted victim’s phone number. The target then receives a call from the restaurant with a lot of
information that they didn’t request.

As a result of each bot making requests to open DNS resolvers with a spoofed IP address, which
has been changed to the real source IP address of the targeted victim, the target then receives a
response from the DNS resolvers. In order to create a large amount of traffic, the attacker
structures the request in a way that generates as large a response from the DNS resolvers as
possible. As a result, the target receives an amplification of the attacker’s initial traffic, and their
network becomes clogged with the spurious traffic, causing a denial-of-service.

A DNS amplification can be broken down into four steps:

1. The attacker uses a compromised endpoint to send UDP packets with spoofed IP
addresses to a DNS recursor. The spoofed address on the packets points to the real IP
address of the victim.

2. Each one of the UDP packets makes a request to a DNS resolver, often passing an
argument such as “ANY” in order to receive the largest response possible.

3. After receiving the requests, the DNS resolver, which is trying to be helpful by
responding, sends a large response to the spoofed IP address.
 4. The IP address of the target receives the response and the surrounding network
infrastructure becomes overwhelmed with the deluge of traffic, resulting in a denial-of-
service.

While a few requests is not enough to take down network infrastructure, when this sequence is
multiplied across multiple requests and DNS resolvers, the amplification of data the target
receives can be substantial. Explore more technical details on reflection attacks.

How is a DNS amplification attack mitigated?

For an individual or company running a website or service, mitigation options are limited. This
comes from the fact that the individual’s server, while it might be the target, is not where the
main effect of a volumetric attack is felt. Due to the high amount of traffic generated, the
infrastructure surrounding the server feels the impact. The Internet Service Provider (ISP) or
other upstream infrastructure providers may not be able to handle the incoming traffic without
becoming overwhelmed. As a result, the ISP may blackhole all traffic to the targeted victim’s IP
address, protecting itself and taking the target’s site off-line. Mitigation strategies, aside from
offsite protective services like Cloudflare DDoS protection, are mostly preventative Internet
infrastructure solutions.

Reduce the total number of open DNS resolvers

An essential component of DNS amplification attacks is access to open DNS resolvers. By

having poorly configured DNS resolvers exposed to the Internet, all an attacker needs to do to
utilize a DNS resolver is to discover it. Ideally, DNS resolvers should only provide their services
to devices that originate within a trusted domain. In the case of reflection based attacks, the open
DNS resolvers will respond to queries from anywhere on the Internet, allowing the potential for
exploitation. Restricting a DNS resolver so that it will only respond to queries from trusted
sources makes the server a poor vehicle for any type of amplification attack.

Source IP verification – stop spoofed packets leaving network

Because the UDP requests being sent by the attacker’s botnet must have a source IP address
spoofed to the victim’s IP address, a key component in reducing the effectiveness of UDP-based
amplification attacks is for Internet service providers (ISPs) to reject any internal traffic with
spoofed IP addresses. If a packet is being sent from inside the network with a source address that
makes it appear like it originated outside the network, it’s likely a spoofed packet and can be
dropped. Cloudflare highly recommends that all providers implement ingress filtering, and at
times will reach out to ISPs who are unknowingly taking part in DDoS attacks and help them
realize their vulnerability.

How does Cloudflare mitigate DNS amplification attacks?

With a properly configured firewall and sufficient network capacity (which isn't always easy to
come by unless you are the size of Cloudflare), it's trivial to block reflection attacks such as DNS
amplification attacks. Although the attack will target a single IP address, our Anycast network
will scatter all attack traffic to the point where it is no longer disruptive. Cloudflare is able to use
our advantage of scale to distribute the weight of the attack across many Data Centers, balancing
the load so that service is never interrupted and the attack never overwhelms the targeted server’s
infrastructure. During a recent six month window our DDoS mitigation system "Gatebot"
detected 6,329 simple reflection attacks (that's one every 40 minutes), and the network
successfully mitigated all of them. Learn more about Cloudflare's advanced DDoS Protection.

What is a Ping (ICMP) flood attack?

A ping flood is a denial-of-service attack in which the attacker attempts to overwhelm a targeted
device with ICMP echo-request packets, causing the target to become inaccessible to normal
traffic. When the attack traffic comes from multiple devices, the attack becomes a DDoS or
distributed denial-of-service attack.

How does a Ping flood attack work?

The Internet Control Message Protocol (ICMP), which is utilized in a Ping Flood attack, is an
internet layer protocol used by network devices to communicate. The network diagnostic tools
traceroute and ping both operate using ICMP. Commonly, ICMP echo-request and echo-reply
messages are used to ping a network device for the purpose of diagnosing the health and
connectivity of the device and the connection between the sender and the device.

An ICMP request requires some server resources to process each request and to send a response.
The request also requires bandwidth on both the incoming message (echo-request) and outgoing
response (echo-reply). The Ping Flood attack aims to overwhelm the targeted device’s ability to
respond to the high number of requests and/or overload the network connection with bogus
traffic. By having many devices in a botnet target the same internet property or infrastructure
component with ICMP requests, the attack traffic is increased substantially, potentially resulting
in a disruption of normal network activity. Historically, attackers would often spoof in a bogus IP
address in order to mask the sending device. With modern botnet attacks, the malicious actors
rarely see the need to mask the bot’s IP, and instead rely on a large network of un-spoofed bots to
saturate a target’s capacity.

The DDoS form of a Ping (ICMP) Flood can be broken down into 2 repeating steps:

1. The attacker sends many ICMP echo request packets to the targeted server using multiple
devices.

2. The targeted server then sends an ICMP echo reply packet to each requesting device’s IP
address as a response.

The damaging effect of a Ping Flood is directly proportional to the number of requests made to
the targeted server. Unlike reflection-based DDoS attacks like NTP amplification and DNS
amplification, Ping Flood attack traffic is symmetrical; the amount of bandwidth the targeted
device receives is simply the sum of the total traffic sent from each bot.

How is a Ping flood attack mitigated?

Disabling a ping flood is most easily accomplished by disabling the ICMP functionality of the
targeted router, computer or other device. A network administrator can access the administrative
interface of the device and disable its ability to send and receive any requests using the ICMP,
effectively eliminating both the processing of the request and the Echo Reply. The consequence
of this is that all network activities that involve ICMP are disabled, making the device
unresponsive to ping requests, traceroute requests, and other network activities.

How does Cloudflare mitigate Ping Flood attacks?

Cloudflare mitigates this type of attack in part by standing between the targeted origin server and
the Ping flood. When each ping request is made, Cloudflare handles the processing and response
process of the ICMP echo request and reply on our network edge. This strategy takes the
resource cost of both bandwidth and processing power off the targeted server and places it on
Cloudflare’s Anycast network. Learn more about Cloudflare DDoS Protection.

What is a low and slow attack?

A low and slow attack is a type of DoS or DDoS attack that relies on a small stream of very slow
traffic which can target application or server resources. Unlike more traditional brute-force
attacks, low and slow attacks require very little bandwidth and can be hard to mitigate, as they
generate traffic that is very difficult to distinguish from normal traffic. Because they don’t
require a lot of resources to pull off, low and slow attacks can be successfully launched using a
single computer; two of the most popular tools for launching a low and slow attack are called
Slowloris and R.U.D.Y.

How does a low and slow attack work?

Low and slow attacks target thread-based web servers with the aim of tying up every thread with
slow requests, thereby preventing genuine users from accessing the service. This is accomplished
by transmitting data very slowly, but just fast enough to prevent the server from timing out.
Think of a 4-lane bridge with a tollbooth for each lane. Drivers pull up to the tollbooth, hand
over a bill or a handful of coins, and then drive across the bridge, opening up the lane to the next
driver. Now imagine four drivers showing up at once and occupying every open lane while they
each slowly hand pennies over to the tollbooth operator, one coin at a time, clogging up all
available lanes for hours and preventing other drivers from getting through. This incredibly
frustrating scenario is very similar to how a low and slow attack works.

Attackers can use HTTP headers, HTTP post requests, or TCP traffic to carry out low and slow
attacks. Here are 3 common attack examples:

 The Slowloris tool connects to a server and then slowly sends partial HTTP headers. This
causes the server to keep the connection open so that it can receive the rest of the headers,
tying up the thread.
  Another tool called R.U.D.Y. (R-U-DEAD-YET?) generates HTTP post requests to fill
out form fields. It tells the servers how much data to expect, but then sends that data in
very slowly. The server keeps the connection open because it is anticipating more data

 Yet another type of low and slow attack is the Sockstress attack, which exploits a
vulnerability in the TCP/IP 3-way handshake, creating an indefinite connection.

How to stop a low and slow attack?

The rate detection techniques used to stop traditional DDoS attacks won’t pick up on a low and
slow attack. One way to mitigate a low and slow attack is to upgrade your server availability; the
more connections your server can simultaneously maintain, the more difficult it will be for an
attack to clog your server. The problem with this approach is that an attacker can attempt to scale
their attack to meet your server’s availability. Another solution is reverse-proxy based protection,
which will mitigate low and slow attacks before they ever reach your origin server. Learn about
how Cloudflare’s cloud-based DDoS protection can mitigate slow and low attacks.

What is an Application Layer DDoS attack?

Application layer attacks or layer 7 (L7) DDoS attacks refer to a type of malicious behavior
designed to target the “top” layer in the OSI model where common internet requests such as
HTTP GET and HTTP POST occur. These layer 7 attacks, in contrast to network layer attacks
such as DNS Amplification, are particularly effective due to their consumption of server
resources in addition to network resources.

How do application layer attacks work?

The underlying effectiveness of most DDoS attacks comes from the disparity between the
amount of resources it takes to launch an attack relative to the amount of resources it takes to
absorb or mitigate one. While this is still the case with L7 attacks, the efficiency of affecting both
the targeted server and the network requires less total bandwidth to achieve the same disruptive
effect; an application layer attack creates more damage with less total bandwidth.

To explore why this is the case, let's take a look at the difference in relative resource
consumption between a client making a request and a server responding to the request. When a
user sends a request logging into an online account such as a Gmail account, the amount of data
and resources the user’s computer must utilize are minimal and disproportionate to the amount of
resources consumed in the process of checking login credentials, loading the relevant user data
from a database, and then sending back a response containing the requested webpage.

Even in the absence of a login, many times a server receiving a request from a client must make
database queries or other API calls in order to produce a webpage. When this disparity is
magnified as a result of many devices targeting a single web property like during a botnet attack,
the effect can overwhelm the targeted server, resulting in denial-of-service to legitimate traffic.
In many cases simply targeting an API with a L7 attack is enough to take the service offline.

Why is it difficult to stop application layer DDoS attacks?

Distinguishing between attack traffic and normal traffic is difficult, especially in the case of a
application layer attack such as a botnet performing a HTTP Flood attack against a victim’s
server. Because each bot in a botnet makes seemingly legitimate network requests the traffic is
not spoofed and may appear “normal” in origin.

Application layer attacks require an adaptive strategy including the ability to limit traffic based
on particular sets of rules, which may fluctuate regularly. Tools such as a properly configured
WAF can mitigate the amount of bogus traffic that is passed on to an origin server, greatly
diminishing the impact of the DDoS attempt.

With other attacks such as SYN floods or reflection attacks such as NTP amplification, strategies
can be used to drop the traffic fairly efficiently provided the network itself has the bandwidth to
receive them. Unfortunately, most networks cannot receive a 300Gbps amplification attack, and
even fewer networks can properly route and serve the volume of application layer requests an L7
attack can generate.

What tactics help mitigate application layer attacks?

One method is to implement a challenge to the device making the network request in order to test
whether or not it is a bot. This is done through a test much like the CAPTCHA test commonly
found when creating an account online. By giving a requirement such as a JavaScript
computational challenge, many attacks can be mitigated.

Other avenues for stopping HTTP floods include the use of a web application firewall, managing
and filtering traffic through an IP reputation database, and through on-the-fly network analysis
by engineers.

Having the advantage of scale with over 6 million users on our network, Cloudflare has the
ability to analyze traffic from a variety of sources, mitigating potential attacks with constantly
updated WAF rules and other mitigation strategies, often before they occur or have a chance to
retarget others. Explore Cloudflare's DDoS advanced protection services.

What is a Ping of Death attack?

A Ping of Death attack is a denial-of-service (DoS) attack, in which the attacker aims to disrupt a
targeted machine by sending a packet larger than the maximum allowable size, causing the target
machine to freeze or crash. The original Ping of Death attack is less common today. A related
attack known as an ICMP flood attack is more prevalent.

How does a Ping of Death work?

An Internet Control Message Protocol (ICMP) echo-reply message or “ping”, is a network utility
used to test a network connection, and it works much like sonar – a “pulse” is sent out and the
“echo” from that pulse tells the operator information about the environment. If the connection is
working, the source machine receives a reply from the targeted machine.

While some ping packets are very small, IP4 ping packets are much larger, and can be as large as
the maximum allowable packet size of 65,535 bytes. Some TCP/IP systems were never designed
to handle packets larger than the maximum, making them vulnerable to packets above that size.
When a maliciously large packet is transmitted from the attacker to the target, the packet
becomes fragmented into segments, each of which is below the maximum size limit. When the
target machine attempts to put the pieces back together, the total exceeds the size limit and a
buffer overflow can occur, causing the target machine to freeze, crash or reboot.

While ICMP echo can be used for this attack, anything that sends an IP datagram can be used for
this exploit. That includes TCP, UDP and IPX transmissions.

How is a Ping of Death DDoS attack mitigated?

One solution to stop an attack is to add checks to the reassembly process to make sure the
maximum packet size constraint will not be exceeded after packet recombination. Another
solution is to create a memory buffer with enough space to handle packets which exceed the
guideline maximum.

The original Ping of Death attack has mostly gone the way of the dinosaurs; devices created after
1998 are generally protected against this type of attack. Some legacy equipment may still be
vulnerable. A new Ping of Death attack for IPv6 packets for Microsoft Windows was discovered
more recently, and it was patched in mid 2013. Cloudflare DDoS Protection mitigates Ping of
Death attacks by dropping malformed packets before they reach the targeted host computer.