Denial of Service

In a denial-of-service attack (DoS attack), the attacker tries to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a server.

Attackers in this type of attack are not really interested in getting any responses back from the target, and therefore spoofing the source IP address is commonly used to obscure the identity of the attacker, which also makes the attack mitigation more difficult.

DOS attacks using the ICMP protocol

Ping flood

Normally, ping is used as a simple way to see if a host is working properly. However, the attacker can take advantage of this maliciously. In particular, in a ping flood attack, the attacker tries to take down a victim’s computer by overwhelming it with ICMP echo requests (i.e., ping requests).

The Smurf attack

A more clever ICMP attack is a smurf attack in which the attacker spoofs ping request (i.e., ICMP echo request) packets as follows:

The source address: the target's address (instead of the actual attacker's address)
The destination address: the broadcast address.

As shown in the figure below, if the routers are not cautiously configured, these ping packets they will be broadcast to all computers on that network. In turn, these computers will then send the ping reply packets back to the source (i.e., the target) contained in the request packets. The target's network will be overwhelmed.

One easy way to prevent the smurf attack could be configuring the routers and hosts to ignore broadcast requests. If a server is relatively weak, it would also be wise to completely ignore ping requests, which will help mitigating ping floods as well.

SYN Flood

A SYN flood attack takes advantage of the 3-way handshake protocol when a TCP connection is established.

Three-way handshake

In the TCP protocol, before a client can talk to a server, both sides need to establish a TCP connection, and the three-way handshake protocol is used for this purpose.

The handshake protocol consists of three steps.

The client sends a special packet called SYN packet to the server. That is, the SYN bit tin the TCP header should be set to 1. The sequence number for this packet is randomly chosen. Let x be the chosen random sequence number.
Upon receiving the SYN packet, the server replies the SYN+ACK packet (both SYN and ACK bits in the TCP header are set to 1). The server chooses its own random sequence number. Let y be the chosen random sequence number. The ack number for this packet should be x+1.
Upon receiving the SYN+ACK packet, the client sends back an ACK packet with seq number x+1 and ack number y+1.

Observation

Focus on step 3 in the above description on the three-way handshake protocol. During step 3, the server is waiting for the client's ACK packet. This implies the following:

If the client never sends the ACK packet, the server waits for a time-out period and then discard the TCP connection.

Before the three-way handshake protocol is finished, the server stores all the half-open connections in a queue, and the queue has a limited capacity. If the attacker can fill up this queue quickly, the server will not be able to accept new SYN packets even if the server has enough CPU and bandwidth resources.

Using random source IP address

When flooding the target server with SYN packets, the attacker needs to use random source IP addresses. Otherwise, i.e., if a fixed IP address is used, then these SYN packets will be blocked easily by a single line of filtering rule of a firewall. Chances are that a random IP address won't have the corresponding machine up and working on the Internet due to various reasons, in which case, the server will wait for a time-out period.

SYN flood attack: summary

The client sends a lot of SYN packets to the target server. In each SYN packet, the source IP address is randomly chosen.

SYN Cookies: Defense Against the SYN Flood Attack

An effective way to defend against SYN flooding attacks is a technique called SYN cookies.

Main idea

The main idea is as follows:

Do not allocate resources at all when the server has only received the SYN packet.
Allocate the resource only if the server received the final ACK packet.

If the above idea is implemented correctly, there will be no resource allocated for the half open connection, and we can avoid the SYN flooding attacks.

Problem with the above idea: potential ACK flooding attack

There is one problem though.

Since the server does not keep any information about the SYN packet, there is no way to tell whether the ACK packet really comes from the same host that sent the SYN packet.

In a sense, one can now launch an ACK flooding attack. This attack will be much worse now, since each ACK packet will amount to an "established connection"!

Cryptography to the rescue!

Note that the relation between the SYN+ACK packet and ACK packet:

(SYN+ACK).ack = ACK.seq = x+1
(SYN+ACK).seq = ACK.ack = y+1

Moreover, observe the following facts:

It is the server that randomly chooses number y.

The main idea behind the technique of SYN cookies is as follows:

The server uses some cryptography mechanism for computing y so that the client cannot guess correctly.

In particular,

The value y is the cryptographic hash output based on

IP addresses
port numbers
sequence number x
random secret key that only the server knows.

So, upon receiving an ACK packet, the server extracts the value x and y, and check if y does match the above hash computation. Since the attacker doesn't know the server's secret key, the attacker won't be able to compute the correct y that passes this test.

Summary: SYN Cookies

The server doesn't store any half-open connection. So, SYN flooding attack doesn't work.
This could introduce another attack of ACK flooding. Still, that can be overcome by the server choose y carefully by taking advantage of a cryptographic hash function.

UDP Flooding

ICMP message: Port Unreachable

Consider the following simple code:


from socket import *

sock = socket(type=SOCK_DGRAM)
sock.sendto(b"Hello!\n", ("192.168.172.5", 9000))

Assume that there is no program listening at port 9000 on the host 192.168.172.5. Here's what Wireshark shows:

What's going on?

There is no programming that receives the UDP packet sent by the program. Therefore, the host 192.168.172.5 kindly informs that the packet was not delivered --- 9000 was an unreachable port.

UDP flooding

By taking advantage of ICMP port unreachable message, a UDP flood attack can be initiated as follows:

The attacker sends a large number of UDP packets to random ports on the target host.
As a result, the target host will:
- Check if there is any program listening at that port. It's unlikely to have a program listening at that port.
- Reply with an ICMP Port Unreachable packet.
- Note that the incoming packet is 49 bytes long, and the outoing packet is 77 bytes long. Moreover, the receiver needs to use computational resource to see if the port is open. This way, the attacker causes the victim to consume more resources.

Thus, for a large number of UDP packets, the target system will be forced to send many ICMP packets, eventually leading it to be unreachable by other clients.

Spoofing the source IP

The attacker(s) may also spoof the IP address of the UDP packets, ensuring that the excessive ICMP return packets do not reach them, and anonymizing their network location(s).

Fix?

Most operating systems mitigate this part of the attack by limiting the rate at which ICMP responses are sent.

UDP Fraggle attack

There is an echo service in UDP (port 7), which works like the ICMP ping service. This means that using this port, a variation of the smurf attack is possible. This kind of attack is called the Fraggle attack.

It is recommended to close the echo service to protect against these types of attacks.

DNS Amplification

Amplification attacks exploit a disparity in bandwidth consumption between an attacker and the target. When the disparity in cost is magnified across many requests, the resulting volume of traffic can disrupt network infrastructure. For example, the Smurf attack is an amplification attack that takes advantage of the broadcast address.

During a DNS amplification attack, the attacker sends out a DNS query with a forged IP address (the target’s) to an open DNS resolver, prompting it to reply back to that address with a DNS response. With numerous fake queries being sent out, and with several DNS resolvers replying back simultaneously, the target’s network can easily be overwhelmed by the sheer number of DNS responses.

Amplification

vm@it432a:~$ dig www.google.com

; <<>> DiG 9.16.1-Ubuntu <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19339
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.google.com.			IN	A

;; ANSWER SECTION:
www.google.com.		116	IN	A	142.251.163.147
www.google.com.		116	IN	A	142.251.163.103
www.google.com.		116	IN	A	142.251.163.99
www.google.com.		116	IN	A	142.251.163.106
www.google.com.		116	IN	A	142.251.163.105
www.google.com.		116	IN	A	142.251.163.104

;; Query time: 11 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Feb 10 12:47:12 EST 2023
;; MSG SIZE  rcvd: 139

Looking at the left, you can easily guess see that a DNS reply usually contains (a lot) more information that its request. This can be used for amplification.

To amplify even more, the attacker can use the cryptographic feature of the DNS security extension (DNSSEC) to increase the reply size. With this, a DNS request message of some 60 bytes can be configured to elicit a response message of over 4000 bytes to the target server. This significantly increases the volume of traffic the target server receives.

HTTP slow POST DoS attack

First discovered in 2009, the HTTP slow POST attack sends a complete, legitimate HTTP POST header, which includes a Content-Length field to specify the size of the message body to follow.

However, the attacker then proceeds to send the actual message body at an extremely slow rate (e.g. 1 byte/110 seconds).
Due to the entire message being correct and complete, the target server will attempt to obey the Content-Length field in the header, and wait for the entire body of the message to be transmitted, which can take a very long time.
The attacker establishes hundreds or even thousands of such connections until all resources for incoming connections on the victim server are exhausted, making any further connections impossible until all data has been sent.

One can consider the following mitigations:

Upgrade the server availability (multiple servers with a loading balancing feature). The more connections your server can simultaneously maintain, the more difficult it will be for an attack to clog your server.
Set an absolute connection timeout based on the median of connections from legitimate clients.
Establish a minimum incoming data rate, then drop any connections that are slower than that rate.

Distributed DOS

A distributed denial-of-service (DDoS) attack occurs when multiple systems flood the bandwidth or resources of a targeted system.

Filtering doesn't work well

A DDoS attack uses more than one unique IP address or machines, often from thousands of hosts infected with malware. Since the incoming traffic flooding the victim originates from different (possbily fake) sources, it may be impossible to stop the attack simply by using ingress filtering. It also makes it difficult to distinguish legitimate user traffic from attack traffic when spread across multiple points of origin.

Scalability of DDOS (Wikipedia)

The largest DDoS attack to date happened in September 2017, when Google Cloud experienced an attack with a peak volume of 2.54 Tb/s.
In February 2020, Amazon Web Services experienced an attack with a peak volume of 2.3 Tb/s.
In July 2021, CDN Provider Cloudflare boasted of protecting its client from a DDoS attack from a global Mirai botnet that was up to 17.2 million requests per second.
In February 2023, Cloudflare faced a 71 million/requests per second attack which Cloudflare claims was the largest HTTP DDoS attack at the time.
In October 2023, exploitation of a new vulnerability in the HTTP/2 protocol resulted in the record for largest HTTP DDoS attack being broken twice, once with a 201 million requests per second attack observed by Cloudflare, and again with a 398 million requests per second attack observed by Google.