\section{What is a DoS attack}

Acronym of denial of service, DoS attacks are an impacting threat to the stability of the network systems and their services. They consist in keeping the victim busy, in order to prevent it to provide its service or take care of its task. It is possible to perform it by flooding the target with traffic or resource-consuming task, trying to exploit the resource limitation and vulnerabilities \cite{Zargar2013}.
The denial of service results in potential significant loss in productivity, finance and reputation with relatively inexpensive resources. As noticeable from the graph \ref{fig:downtimeCost}, extracted by Statista, even just a downtime of an hour can lead to millions of loss \cite{statista2021downtime}
.

Attacks to ministerial websites can cause important inconveniences, bureaucratic issues or be used to send a threat message, especially in international conflicts. In other cases, in which the victim relies on its reputation for the availability of service, it can cause image damages \cite{Zargar2013}.
In the online gaming environment, for example, the term ``DDossing'' has become very popular and consist in the attempt of lagging the game and obstacle the enemy strategy \cite{kaspersky_ddos}. 
Apart from very famous attacks like the one of 2020 against AWS (incoming traffic of 2.3 terabit per second) or GitHub 2018 (1,3 Tbit/sec), the majority of the attacks keeps lying in the smaller range (Graph \ref{fig:bitRate}), demonstrating that even smaller services providers are in danger \cite{cloudflare_ddos_q2_2020}. 

\begin{figure}[tbh]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{2DoSattacks/bitRate.png}}
\caption{Percentage of attack by bitrate (source: \href{https://blog.cloudflare.com/network-layer-ddos-attack-trends-for-q2-2020/}{Cloudflare}).\label{fig:bitRate}}
\end{figure}

Instant recognition of DDoS attack and their mitigation is significant in the reduction of loss in the previously mentioned fields. The famous example of GitHub 2018 is a great demonstration of how the immediate detection of these attack can drastically reduce the damage. The website, in fact, remained unavailable only for 20 minutes \cite{cloudflare_ddos_q2_2020}. 

\begin{figure}[tbh]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{2DoSattacks/attackDuration.png}}
\caption{Attack duration percentage (source: \href{https://blog.cloudflare.com/network-layer-ddos-attack-trends-for-q2-2020/}{Cloudflare}).\label{fig:attackDuration}}
\end{figure}


\section{Types of DoS attack} 
DoS attacks can be differentiated in categories: volume-based attacks, protocol attacks and application layer attacks.

\subsection{Volume-based attacks}
Also known as volumetric attacks, the volume-based attacks, are the most common and known DoS attack. They consist in overwhelming the target network, service, or application by flooding it with traffic aiming to consume its resources or bandwidth so that legitimate users can not access the services. Examples of volumetric attacks are:
\begin{itemize}
    \item UDP flood: UDP packets destinated to random ports on the target system, to which the system answers with ICMP "Destination Unreachable" consuming bandwidth.
    \item ICMP floods: large number of Echo Request, in other words ``ping'', sent to the target that will answer with Echo Reply packets.
    \item Amplification attacks: a kind of reflection attack, in which are exploited protocols that have a bigger answer than the request, such as DNS, with the target address spoofed, in order to redirect these resource consuming answers to the victim.
\end{itemize}
Real-world examples are the DynDNS attack of the 2016 claimed by Anonymous and New World Hackers, hitting services like Twitter, Reddit, Netflix or Spotify with a huge traffic volume, or the already mentioned GitHub attack of the 2018 reaching an amount of traffic equal to 1.35 Tbps \cite{volumetric_attacks} \cite{cloudflare-ddos}.
%https://ieeexplore.ieee.org/abstract/document/9562660 also interesting
\subsection{Protocol attacks} 
The protocol attacks exploit the weakness in a protocol aiming to consuming the resources of the victim. TCP Fragmentation attack, for example, send fragmented headers forcing the server to reassemble them, wasting resources \cite{fragmentation_attack}. TCP Reset instead, consist in sending fake TCP reset packets in order to disrupt ongoing communication between clients and servers.
A real-world example can be the NTP Amplification Attack of the 2014 against Microsoft Xbox live, a famous platform for gaming. The NTP amplification attack rely on the vulnerabilities in the Network Time Protocol servers. As a reflection attack, implies the sending of small request, with spoofed addresses, to NTP servers. The latter will answer with larger packets to the victim, resulting in an amplification of the attack. An NTP server is the node of a network responsible for synchronising the others, by maintaining precise timekeeping, referenced with reliable time source such as atomic clocks or GPS satellites. To prevent this type of attack it is mandatory to implement rate limiting, access controls and network filtering \cite{Rudman2015}.
Another example is the well known Great Firewall of Chine, that uses the TCP reset attack to operate an Internet censorship \cite{clayton2006}.

\subsection{Application layer attacks}
The application layer attacks target a specific flaw of a resource or application in order to disrupt a service. Examples of application layer attacks are the HTTP Flood and the Slowloris attack.
The HTTP Flood launches requests against a web server to overwhelm its capacity to react to legitimate traffic.
The Slowloris and the Slow POST Attack are the lighter version of the HTTP flood. As the light steps of a ninja, they are harder to be detected, making them very dangerous. These attacks, in fact, aim to consume the resources to slow down the provided services. To avoid them, it's advised to implement rate limiting logic and throttling, namely limiting the number of request an IP can accept by a single IP address \cite{Praseed2019} \cite{suroto2017}.
Other solutions might be
\begin{itemize}
    \item Input validation and sanitation to avoid SQL injections and buffer overflow attacks, that try to exploit vulnerabilities that cause high resource consumption.
    \item Efficient code practices to reduce the load of work of the computational resources.
    \item Content delivery networks which are used to distribute the traffic to support network to reduce the impact of overwhelming traffic and get the chance to filter the malicious traffic.
    \item Behavioural analysis and the detection of anomalies, a very complex technique which involve a high waste of resource if the analysis is conducted manually.
\end{itemize}  
Real-world example are: the Slowloris attack to Iran government sites after Iranian election of the 2009 in which the attacker caused significant delays and downtime for the online services by keeping open several connections with the servers by sending incomplete HTTP request \cite{Praseed2019}.
\subsubsection*{Throttling}
In real-life business, throttling is used with API (Application Programming Interface). Since they work as a gateway between users and the software application, it is crucial to implement a throttling algorithm to avoid the service provider to be flooded with requests. In general, when an API throttling logic receives a call to an API, it checks if the request exceeds the maximum number of calls, if that's the case, an error response is returned to the user that will wait a pre-agreed period of time. Possible throttling algorithms are the leaky bucket, the fixed window or the sliding window.
The leaky bucket is not different from a first-in first out queue with a specific size. At regular intervals, the algorithm removes a request from the head of the queue and processes it. If the queue is full, then the request is discarded. In this way, the requests are processed at a constant rate, avoiding the system to get overwhelmed and get stuck. Since it is a FIFO queue, there's a chance of starvation when the queue is full, the request that try to get on the top don't get the chance to enter the queue. 
The fixed window allows N number of API calls for a user in a particular range of time, in which each user is equipped of a unique key and a counter associated. When the counter reaches the limit, the user's API request are rejected. The counter gets then reset when the fixed time window ends. To solve the possible burst of request at the beginning of the window, each user is equipped with a time window, which is saved by means of a timestamp together with the counter.
In conclusion, the throttling reduces the malicious use and improves the performance of the web service. In addition, it can be used to increase the revenue by allowing the user to pay money for the possibility of requesting more APIs \cite{Firmani2019}.

\section{How to recognise a DoS attack}
A DoS attack is typically recognised through various signs and detection methods. Some of generic indicators of a DoS attack are:
\begin{itemize}
    \item Unusual Traffic Patterns: without the help of automation, it is easy to notice only sudden increase of traffic that is not aligned with normal usage patterns, especially if from a single IP address or a range of IP addresses. What it should be looked for, in general, are the periodic presence of traffic spikes in short interval of time \cite{Feinstein2003}.
    \item Degraded Network Performance: the performance of the network get worse, causing delays in accessing the services or the content of the server and grow of the latency in the transmission of data.
    \item Unavailable Services: the ceasing of working of websites or services that were previously available, manifesting frequent outages and errors like "Service Unavailable" or "Server Timeout" \cite{Feinstein2003}.
    \item High System Resource Utilisation: Servers experiencing high CPU or memory usage due to handling excessive number of requests. Moreover, a fast increment of disk usage may indicate the logging of huge volume or traffic \cite{Feinstein2003}.
    \item Log File Entries: repetitive or excessive entries may indicate attempts to gain access to resources or unusual pattern of request \cite{Feinstein2003}.
\end{itemize}


\section{Detection Techniques}
There may be several indications that a network or server may be under DoS attack. To certify these suspicions, it is necessary to collect concrete data. A possible method may be to start from the clue and link a tangible parameter.
\subsection{Traffic Analysis}
The traffic analysis is conducted by observing network traffic. The monitoring can be done by means of monitoring tools like Wireshark, NetFlow or sFlow in search of patterns and anomalies typical of DoS attacks, such as a high rate of incoming packets or connections and presence of connection opened but never closed. Other way of monitoring the system are the IDS (intrusion detection systems) in the pursuit to signs of suspicious activities \cite{Feinstein2003}.

Looking for spikes in the traffic, it's possible to check the:
\begin{itemize}
    \item Source IP Address Distribution, analysing the diversity and volume of IP addresses generating traffic by means of tools like Wireshark or firewall logs \cite{Feinstein2003}.
    \item Protocol distribution, inspecting the proportion of the different protocols in use, relying on in software like Wireshark or NetFlow analysers \cite{Feinstein2003}.
    \item Request per seconds, counting the number of request made to the server or the application using web server logs (like Apache or Nginx) or application performance monitoring tools such as New Relic;
    \item Bit per Second (bps) and Packets per Second (pps) 
    the volume of data transmitted over the network and the number of packets sent to and from the network. This can be monitored with Wireshark or SolarWinds NPM.
\end{itemize}

\subsection{Anomaly Detection} 
The anomaly detection can be run using machine learning (behavioural analysis) or statistical methods to spot outliers or unusual traffic patterns that deviate from the baseline of normal networks. Another possibility could be a Heuristic-based detection, which consist in creating fixed rule to identify suspicious activity.
As an example, it is possible to start from a baseline and monitor the alterations from the normal behaviour. In this sense may be useful to monitor metrics like:
\begin{itemize}
    \item Packets per second (PPS) either in total or from a specific source, bits per second (bps) in total or from a specific source (capacity of a communication channel), or requests per second (RPS) with tools like Wireshark.
    \item The number of new connection per second overall or from a specific IP address with instruments as firewall logs.
    \item Response time of servers and applications.
    \item How long a connection is active.
    \item The error and failed request rates.
    \item The bandwidth consumed over time.
    \item CPU and memory usage of a connection.
\end{itemize}

\subsection{Degraded Network Performance}
An evident and  concrete sign of DoS attack corresponding of the delays in the network are the latency, the jitter, the throughput and the number of lost packets.
The latency of the packet delivery is, in other words, the time a packet spent to travel from the source to the destination. It is usually measured in milliseconds with tools like \cmd{ping} or \cmd{traceroute}. It can be calculated as one-way latency or round-trip time (RTT). The first is the time it takes from source to destination, while the second is the first plus the time from destination to source. In this regard, the ping calculates it as RTT while the traceroute measures the path and time taken for the packets to reach each hop \cite{Feinstein2003}.
The jitter measures the fluctuation in delay times for the packet arriving at the destination. It can be calculated between consecutive packets or over a certain period of time. In other words, it can be considered as the difference of latency between consecutive packets \cite{Barford2009}.
The number of lost packet is the number of packet that failed to reach the destination, measurable with ping or SolarWinds NPM \cite{Barford2009}.
The throughput is the rate of successful data transmitted over the network \cite{Barford2009}.

\subsection{Unavailable Services}
The ceasing of working of websites or services that were previously available can be recognised mostly with HTTP response code, which is the status code returned by the web servers. 
\begin{itemize}
    \item 500 Internal Server Error: resource exhaustion can raise this error of unexpected condition that prevents to solve the request
    \item  502 Bad Gateway: when the server acting as a gateway or proxy receive an invalid response from the upstream server.
    \item 503 Service Unavailable: the server can not handle the request because of a current overloading or maintenance.
    \item 504 Gateway Timeout: when the server acting as gateway or proxy does not receive a response from the upstream server in time.
    \item 429 Too Many Requests: when a user exceeds the rate limit or throttling
    \item 408 Request Timeout: the server timed out waiting for the request
\end{itemize}

It is possible to recover the number of error status code by means of web server logs and application performance monitoring tools \cite{Fielding2014}.



\subsection{High System Resource Utilisation}
Servers experiencing high resource usage due to handling excessive number of requests could be measured with: the percentage of CPU usage (monitorable with top or htop command) \cite{Zhan2023}; the amount of memory used with tools like \cmd{free}, that display the amount of free and used physical and swap memory in the system and \cmd{vmstat,} that reports information about processes, memory, paging and so on \cite{Islam2023}; the rate of read and write operation on the disk with tools like \cmd{iostat}; the amount of data being sent and received through the network interfaces of the network nodes. It is possible to use tools like \cmd{iftop} to measure the bandwidth usage on the interface required \cite{Barford2009}.

\subsection{ Log File Entries}
Excessive presence of error messages, failed login attempts, unusual or suspicious IP addresses, highly repeated request can be spotted in the Log Files. It is possible to get all of these infos with web server log tools like Apache or Nginx, or system logs tools like Journald, syslog or syslog-ng \cite{Feinstein2003}. 


\subsection{Signature-based Detection}
Using signatures or predefined rules of security systems to identify known attack patterns. These signatures, realised by security expert and researches, can be based on traffic pattern, packet content or usual behaviour. Finally, they get released in IDS or IPS with the aim of constantly monitoring in search for traces of these signatures. For example, a signature for a SYN Flood Attack could be a high number of TCP SYN packet without their corresponding ACK response. The drawback of this technique is that the attacker can slightly modify his technique to bypass the signature-base block \cite{Canfora2015}.

\subsection{Honeypots}
Honeypots are bait systems to attract and analyse attack traffic, helping to identify attack patterns. As a bait, it is made purposely vulnerable but placed in a DMZ in order to keep far the organisation from any risk and at the same time taking the control of the area and analyse the gained information. Honeypots can be made with a limited number of service in order to be more manageable up to a completely developed and real operative systems and applications. Of course, the more is the Honeypot similar to the original, the more can gain information about the attack \cite{spitzner2002honeypots}.

\subsection{Example Workflow to Detect a DoS Attack}
Based on the previous information, it is possible to define a template of workflow.
\begin{enumerate}
    \item Set up the monitoring of one or more metrics.
    \item Configure threshold-based alerts for key parameters (traffic volume, connection rates, response times).
    \item Establish baseline metrics for normal traffic and resource usage patterns.
    \item Perform a real-time analysis by continuously monitoring network and application performance.
    \item Investigate the alerts triggered.
    \item Mitigation: Deploy rate limiting and IP blocking using WAF (web application firewall) or load balancers. Engage DDoS mitigation services if necessary.
\end{enumerate}


\section{Defence techniques}
In order to mitigate the DoS attacks or defend the system from them, it is possible to implement some countermeasures.
Rate Limiting is the set of the threshold. It can be imposed with throttling of the request to APIs or of the limit of maximum simultaneous connection set to prevent overloads. It is also possible to shape traffic by controlling the flow of traffic to ensure critical services to remain available during an attack \cite{Praseed2019}.
Tarpit is a defending mechanism that consists in slowing down malicious connections, in order to exhaust the attacker resources, delay their progress and make it difficult for attackers to complete their objectives \cite{spitzner2002honeypots}.
A Load Balancer can help distribute network or application traffic across multiple servers to prevent any from getting stuck. It acts as a reverse proxy, distributing incoming traffic across backend servers, balancing the load and ensuring optimal utilization of the resources \cite{Zebari2020}.
A Failover Mechanism can back up systems that can become active in case the main one goes down.
The Content Delivery Network (CDN) is a system of distributed servers that delivers web content to users based on their geographical position. This means that the content is copied in several servers around the world called edge servers, which are closer to the end users. In this way, by means of a load balancer, the origin server gets offloaded.
Firewalls and Access Control: permits the use of filters and the blocking or allowing of the traffic coming from specific IP addresses.


\section{SYN flood attack}
The SYN flood attack is a protocol-based DoS attack that exploit the vulnerability of the TCP threw-way handshake. The Transmission Control Protocol (TCP) is a protocol of the layer 4 (Transport) that provides a reliable, ordered and error-checked stream of bytes. 

\subsubsection*{Three-way handshake}
Similarly to the real life, the handshake is used as a form of presentation to start a communication. It is called three-way because it consists of 3 messages:
\begin{enumerate}
    \item SYN: The client sends a SYN (synchronise) packet that contains a sequence number, called ISN (initial sequence number), which is used to synchronise the sequence numbers between the client and the server. The aim of the synchronisation is to ensure the correct order of the packet at the receiving end. In this way it is ensured a protection from data loss, a control of the flow (operated through the acknowledgement numbers and window size) and duplicate detection.
    \item SYN-ACK: The server this time answer with a SYN-ACK packet that has 2 purposes, acknowledge the client's SYN with an ISN+1 and synchronise its own sequence.
    \item ACK: finally, the client sends the last acknowledgment to server with server's ISN+1 to confirm the synchronisation.
\end{enumerate}

\begin{figure}[hbt]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{2DoSattacks/syn-flood1.png}}
\caption{Three-way handshake (Source: \href{https://www.cloudflare.com/img/learning/ddos/syn-flood-ddos-attack/syn-flood-attack-ddos-attack-diagram-1.png}{Cloudflare}).\label{fig:threewayHandshake}}
\end{figure}


\subsubsection*{The attack}

In a SYN flood attack, the attacker sends a large number of SYN requests to the server, sometimes with spoofed IP addresses. Every time the server receive a SYN, it reserves resources enough to establish a connection for a certain amount of time. Once all the possible port will be reserved, he will not be able to work normally. From his side, the attacker, will not respond to the SYN-ACKs. By doing so, the server is left with many half-open connections, consuming resources and preventing legitimate connections. 

\begin{figure}[hbt]% per piazzare la tabella t:top b:bottom h:here, in ordine di preferenza; h è sconsigliato
\centerline{\includegraphics[width=0.9\textwidth]{2DoSattacks/syn-flood2.png}}
\caption{Syn Flood attack (Source: \href{https://www.cloudflare.com/img/learning/ddos/syn-flood-ddos-attack/syn-flood-attack-ddos-attack-diagram-2.png}{Cloudflare}).\label{fig:attackDuration}}
\end{figure}

Since the servers allocate memory and processing power for each half-open connection, the result is a highly degraded or complete unavailability due to the exhaustion.
The effects can be particularly severe on systems with limited resources or inadequate mitigation mechanisms.


\subsubsection*{Mitigation Strategies}

With the SYN Cookies method, a server is allowed to handle incoming SYN request more efficiently to mitigate the impact of the flood, by generating and encoding the information need to establish the connection directly in the SYN-ACK phase, without allocating resources for maintaining half-connections. This information, are called cookie and consist of the couple IP address-port of the source, a timestamp or a unique identifier and a secret key only known by the server. They are combined into one single value, hashed and finally encoded in the initial sequence number (ISN) field of the SYN-ACK response. By using the cookies the necessities of other structures or state maintenance is avoided and thanks to the cryptographic hash function it is granted the integrity and authenticity of the message, making it resistant to tampering or forgery by attackers.

Another method is the backlog queue, which is where the information about half-opened connections are stored, waiting for the completion of the handshake. By adjusting the size of the queue, the server can accommodate more SYN request and resist better to the attack. However, a larger queue means a bigger memory usage, potentially leading to memory exhaustion and performance degradation. Furthermore, to overcome the problem, the attacker just has to increase the power of its attack, turning the tentative of defence in a delay.

The Firewall can be used to implement Rate Limiting rules to track the rate of incoming SYN packets from each source IP address (if the rate exceeds the threshold within a specific time window that the packet is blocked) or monitor the active connection (if a connection has been half-opened for a huge amount of time or if no data has been exchanged). In addition, the firewall can also be used as a SYN proxy. This means that the firewall will block the incoming connection until the three-way handshake is complete.
Despite that, configuring and managing firewalls and IDS systems can be complex and time-consuming, especially because they require regular updates and maintenance to ensure effective protection against evolving threats.

Finally, it is possible to use an Intrusion Detection Systems (IDS). It can be both network based or host based. In case of NIDS, the analysis made of the header and payload of the packets may raise an alarm in case of high number of SYN packet without a SYN-ACK and in case the traffic flow differ from the baseline. In case the IDS is host based, the system can monitor the resource of the host by checking the CPU and memory usage or the half-open connections \cite{Eddy2007}.


%https://ieeexplore.ieee.org/abstract/document/1019404
%https://eprints.ugd.edu.mk/6729/1/IJCNIS-V5-N8-1.pdf)
\section{HTTP Flood}
\subsubsection*{The attack}
An HTTP Flood attack consists in using the HTTP protocol to send high volume of legitimate HTTP GET or POST, generally, or custom HTTP verbs. These request consume significant resources, causing the server to become unresponsive. Differently from other attacks, like the SYN flood or the ping of death, HTTP flood sends seemingly legitimate request, randomising headers, user agents and other parameters making them harder to detect and mitigate. Being a volumetric attack, it sends a high number of requests in a shorts time, aiming to saturate server resources. The flood may lead to CPU saturation, impact the server's ability to cache data causing memory exhaustion, and bandwidth congestion saturating server sockets. The immediate and recognisable effect are high latency in downloading web pages, submitting forms or accessing resources, disrupting the user experience, and connection timeouts, which means the server may fail to respond to legitimate requests in a reasonable time window. In extreme cases it can cause crashes of the server, that need manual intervention to restore the service, or unavailability to the user leading to complete service downtime.
The detection of the HTTP flood involves monitoring network traffic pattern and behaviour anomalies, that indicate an abnormal influx of HTTP request. To do so, it is possible to monitor the metric related to the connection or analyse the insights of the traffic.
For the former, it is possible to check the rate of requests, the rate from specific IPs, unusual patterns in request distribution, session duration the size of the payload and other metrics.
For the latter it is possible to study the request uniformity, because often they present similarities in the header, user-agent string or URI patterns, or in the payload due to automation. 

\subsubsection*{Mitigation strategies}
To mitigate these attack, it is possible to implement the strategies already treated in the chapter, such as rate limiting, traffic filtering, throttling, the use of firewall with IP address blocking and reputation lists, or it is possible to proceed in the direction of resource optimisation, in order to handle a higher volume of traffic until the attack ends, use content delivery networks to distribute the traffic across different servers and data centers. Another well known solution is the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) challenges to differentiate the human users from the automated bots \cite{Sairam}.



\section{Slowhttp}
\subsubsection*{The attack}
Slowhttp is a kind of attack that uses a small stream and very slow traffic. Differently from the more known DoS attack, low and slow attacks operate a very little bandwidth and can be very hard to distinguish from the normal traffic.
It consists in maintaining open connection to the server by sending request ad a slow rate, but fast enough to avoid the connection to be closed. Signs of slow attacks can be, in fact, unusual performance of the servers or the network. These attacks are particularly effective against servers that allocate significant resources for each connection, such as those running web applications or using SSL/TLS.

As an example, Slowloris tool connects to the server and sends HTTP headers incrementally without completing the request. In this way, the server keeps the connection open in the tentative to receive the remaining part of the headers. Another type is the HTTP POST, that making use of tools like RUDY (R U DEAD YET) or Slowhttptest, fills the form of the request, making the server expect a certain amount of data and finally send them in very small chunks, prolonging the duration of the request.

\subsubsection*{Mitigation Strategies}
To mitigate these attacks, it is possible to try upgrading the server availability, with the risk that the aggressor simply scales up its attack. 
Another chance is to use a Reverse Proxy or Application Layer Gateways to mitigate the attack before they even reach the server.
With Timeout and Rate Limiting, it is possible to configure rules to close connections incomplete within a certain timeframe or limiting the rate of incoming requests.
Finally, by means of a load balancer, is likely to distribute incoming traffic across multiple servers to prevent any single server from becoming overwhelmed \cite{suroto2017}.


\section{ICMP flood}

\subsubsection*{The Attack}
This is a DoS attack in which the aggressor tries to overwhelm the victim with Internet Control Message Protocol (ICMP) echo-request packets. This message is typically produced by means of the tool Ping, that gives the name to a similar attack (Ping of Death), which is, together with traceroute, usually used with the diagnostic purposes.
Receiving a high number of ICMP Echo Request, the system is forced to answer each packet, consuming progressively its power and bandwidth. Originally, the IP of the sender was spoofed to avoid to be blacklisted, however, with modern botnets attacks and the possibility to rely on several unspoofed bots, this is not even necessary. Differently from others attack, the use of bandwidth is symmetrical, making it not ideal to perform an attack, however they are still employed for basic DDoS campaigns.


The Ping of Death (PoD) is a specific type of ping flood attack where the attacker sends oversized ping packets to the target. Usually a ping packet is from 56 bytes in size, 84 including the IPv4 header, though in PoD the packet is made as large as possible. Since the Ethernet frame size is usually limited to 1500 bytes, against the 65535 of the IP packet maximum size, in the phase of reassemble a buffer overflows can be caused, potentially crashing the target system \cite{Yihunie2018}. 

\subsubsection*{Mitigation Strategies}
To mitigate the ICMP flood, is usually employed the Firewall to apply a rate limiting in presence of an attack signature. As instance, to reduce the number of ICMP request the system will answer, configure it in such a way that ignores ICMP echo request bigger than expected when they are reassembled or completely disable ICMP, especially if from untrusted sources.
Alternatively, the Intrusion Detection Systems (IDS) or the performance of Network Traffic Analysis to monitor and filter out suspicious ICMP traffic patterns could be enough \cite{harshita2017}.


%useful links:
%https://www.researchgate.net/profile/Riyadh-Rahef-Nuiaa/publication/351978952_Distributed_reflection_denial_of_service_attack_A_critical_review/links/612a7f3f2b40ec7d8bce8170/Distributed-reflection-denial-of-service-attack-A-critical-review.pdf
%https://wires.onlinelibrary.wiley.com/doi/epdf/10.1002/wfs2.1418
%https://www.unb.ca/cic/datasets/cicev2023.html
%https://www.unb.ca/cic/datasets/ddos-2019.html
%https://blog.cloudflare.com/network-layer-ddos-attack-trends-for-q2-2020/%
%https://journals.sagepub.com/doi/full/10.1177/1550147717741463

