\lstset{
    basicstyle=\ttfamily,
    columns=fullflexible,
    keepspaces=true,
    showstringspaces=false
}


\section{Installation of the system}
It is mandatory to use a Linux distribution, because of compatibility problem with the Windows Subsystem for Linux (WSL). The WSL, in fact, lack of the necessary headers to run the eBPF programs and tools, used in this experiment. It has been tested with Linux Ubuntu 22.04.4.

The system is a network simulated in the Docker environment. In order to build it, it is necessary the installation of Docker and the docker-compose.

Step by step commands:
\begin{enumerate}
    \item \textbf{Update the apt package index}
    \begin{lstlisting}[language=bash]
sudo apt-get update
    \end{lstlisting}

    \item \textbf{Install packages to allow apt to use a repository over HTTPS}
    \begin{lstlisting}[language=bash]
sudo apt-get install apt-transport-https ca-certificates curl software-properties-common
    \end{lstlisting}

    \item \textbf{Add Docker’s official GPG key}
    \begin{lstlisting}[language=bash]
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
    \end{lstlisting}

    \item \textbf{Set up the stable repository}
    \begin{lstlisting}[language=bash]
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    \end{lstlisting}

    \item \textbf{Update the apt package index again}
    \begin{lstlisting}[language=bash]
sudo apt-get update
    \end{lstlisting}

    \item \textbf{Install Docker Engine}
    \begin{lstlisting}[language=bash]
sudo apt-get install docker-ce docker-ce-cli containerd.io
    \end{lstlisting}

    \item \textbf{Verify that Docker Engine is installed correctly}
    \begin{lstlisting}[language=bash]
sudo docker run hello-world
    \end{lstlisting}
\end{enumerate}

All in one:
\begin{lstlisting}[language=bash]
sudo apt-get update

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io
sudo docker run hello-world
    \end{lstlisting}

To manage the network, in the directory in which the docker-compose.yml file is located:

\begin{itemize}
    \item Run the services:
            \begin{lstlisting}[language=bash]
            sudo docker-compose up -d
            \end{lstlisting}
    This command will run the services described in the docker-compose.yml file. The first time, it will build automatically the images. If any modification to the images is done, take care of running the BUILD command.
    \item Build the services: \begin{lstlisting}[language=bash]
sudo docker-compose build
    \end{lstlisting}
    This command will build the images chosen for the services described in the docker-compose.yml file.
    \item Restart the services: \begin{lstlisting}[language=bash]
sudo docker-compose restart
    \end{lstlisting}
    This command is meant to be used in case the system get stuck, or to run another time the entrypoint of every image.  
    \item Take down the services:
    \begin{lstlisting}[language=bash]
sudo docker-compose down
    \end{lstlisting}
    \item View container logs
    \begin{lstlisting}[language=bash]
sudo docker logs CONTAINER_ID
    \end{lstlisting}
    \item Execute a command in a running container
    \begin{lstlisting}[language=bash]
sudo docker exec -it CONTAINER_ID COMMAND
    \end{lstlisting}
\end{itemize}

Specifically, after the docker and docker-compose installation run:

\begin{lstlisting}[language=bash]
sudo docker-compose up -d
\end{lstlisting}

\section{Description of the system}
The topology of the network is described by the figure \ref{fig:vn}.

\begin{figure}
    \centering
    \includegraphics[width=1\linewidth]{3VirtualNetwork/VirtualNetwork.pdf}
    \caption{Virtual network}
    \label{fig:vn}
\end{figure}

\subsubsection*{Admin-fluentd}
The node admin-fluentd has addressable to the IP address 10.200.0.2. It is in charge of managing, collecting and analysing the network. 
To enter the node:

\begin{lstlisting}[language=bash]
sudo docker exec -it newenvironment_admin-fluentd_1 /bin/bash
\end{lstlisting}

In the folder \cmd{shared-volume/prediction} there are the necessary tools to analyse the TCP information about the server of interest. 

The tool intervalModelUser.py takes in input a DoS log from the folder \cmd{/output/DoS} and look for the presence of a DoS attack in a time interval. To run the tool: 

\begin{lstlisting}[language=bash]
python3 /shared-volume/prediction/intervalModelUser.py fluentd/output/DoS/[nameofthelog.log]
\end{lstlisting}

e.g.

\begin{lstlisting}[language=bash]
python3 /shared-volume/prediction/intervalModelUser.py /output/DoS/dos.log.20240521.log
\end{lstlisting}

Producing this kind of output \ref{fig:intervalOutput}.

\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{9UserManual/intervalOutput.png}
    \caption{intervalModelUser.py example}
    \label{fig:intervalOutput}
\end{figure}

The tool manualModelUser.py instead is used to analyse a single entry. Run the program with:
\begin{lstlisting}[language=bash]
python3 /shared-volume/prediction/manualModelUser.py
\end{lstlisting}

Producing this kind of output \ref{fig:manualOutput}

\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{9UserManual/manual.png}
    \caption{manualModelUser.py example}
    \label{fig:manualOutput}
\end{figure}
The tool 1prediction.py is used in couple with the log collector Fluentd. The results of the analysis of the live predictions are available in the folder \cmd{/shared-volume/ prediction/livePrediction/}. In this directory, there are several files related to the collection of TCP performance data collected. Each file is related to a specific day (\cmd{YYYY-MM-DD.txt}) and contain entries like this:

\begin{lstlisting}
2024-06-30 22:59:22	{"TIME":"2024-06-30 22:58:19", "IP address":"10.100.0.2", "tx_mean":0, "rx_mean":0, "tx_var":0, "rx_var":0, "ms_mean":0, "ms_var":0, "open_connections":0, "closed_connections":0, "mean_time":0, "variance_time":0}
result: [[0.0051403]]NO
\end{lstlisting}
In which, the first element is the time the entry has been analysed by the tool, the second is a JSON file, the third is the result of the prediction. The JSON file is composed of the metrics extracted by the monitoring tool, the IP address of the source and the time in which the data have been extracted.
The result is composed by a numerical element between the brackets and a faster reading one. The numerical elements express the probability of the segment to be malicious, the second interprets the first by dividing the probability in 3 sections: 
\begin{itemize}
    \item NO: if the probability is less than 0.2
    \item MAYBE: if the probability is between 0.2 and 0.8
    \item YES: if the probability is more than 0.8
\end{itemize}

The directory \cmd{admin-fluentd/output/} contains the logs Fluentd collects. The logs are called: \cmd{output.log.20240405.log}. In which the number is the data of creation of the log.
The log contains entry as:

\begin{lstlisting}
2024-06-30T13:43:30+00:00	fluent.info	{"worker":0,"message":"fluentd worker is now running worker=0"}
2024-06-30T13:43:00+00:00	routerD	{"log":" * Starting system logging syslog-ng", "container_id":"9a8ecc7e0c1ebe74 9d242d74ed773b9601efb4bc8fea0e000ca2031c38dea5e3", "container_name":"/newenvironment_rd_router_1", "source":"stdout"}
\end{lstlisting}
In which the first element is the time of production of the log entry, the second is the source of the log and the third is a JSON object that contains the content of the log.

The folder \cmd{admin-fluentd/output/DoS} contains the TCP performance received by the nodes of the network. The entry are built as:

\begin{lstlisting}
2024-06-30T15:56:53+00:00	dos.tracer.logs	{"TIME":"2024-06-30 15:56:53","IP address":"10.100.0.2","tx_mean":0.0,"rx_mean":0.0,"tx_var":0.0,"rx_var":0.0,"ms_mean":53.156666666666666,"ms_var":2517.073088888889,"open_connections":872,"closed_connections":3,"mean_time":0.006899428571428575,"variance_time":4.813139591836732e-07}
\end{lstlisting}
In which, the first element is the time the log has been received, the second is the name of the TCP performance sending block (useless for the user) and the third is a JSON object that contains all the metric observed. The first field of the object is the time of data extraction, the second is the address of the source and the remaining are the performance metrics.

\subsubsection*{Servidor}
The node servidor, is a server example, that exploit \cmd{npm} to run a service on the port 3000. 

The directory \cmd{/output/DoSdetector} contains the tool necessary for the monitoring activity. To start the monitoring system run:

\begin{lstlisting}
python3 /servidor/output/DoSdetector/1clock.py
\end{lstlisting}
The tool 1clock.py is a manager of tools that provide the necessary metrics. This program is in charge of synchronising the tcpLife and tcpTracer tools of the bpftools.

TcpLife original output is:

\begin{lstlisting}[label=lst:lifeOutput, caption=tcpLife output]
TIME(s)   PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
0.000000  22970 socat      10.0.1.20       51838 10.100.0.2      80        0     0 501.50
0.000125  22971 socat      10.100.0.2      80    10.0.1.20       51838     0     0 501.58
1.646757  22973 socat      10.0.1.20       51852 10.100.0.2      80        0     0 501.51
1.646898  22974 socat      10.100.0.2      80    10.0.1.20       51852     0     0 501.61
\end{lstlisting}
In which the first field is the time relative to the starting of the program, the second is the PID of the process, the third is the name of the command in charge of the connection, the next 4 fields are related to the IP address and ports of the local node and remote node of the connection. The final three metrics are the one of interest for our prediction. TX\_KB measures the number of bytes transmitted, RX\_KB measures the number of bytes received and the MS is the duration of the connection measured in milliseconds. 

The tcpTracer original output is:

\begin{lstlisting}[label=lst:tracerOutput,caption=tcpTracer output]
TIME(s)  T  PID    COMM             IP SADDR            DADDR            SPORT  DPORT 
0.000    C  4948   Socket Thread    4  10.156.4.134     130.192.55.225   41174  443   
0.673    C  27614  socat            4  10.0.1.20        10.100.0.2       55226  80    
0.000    A  22841  socat            4  10.100.0.2       10.0.1.20        80     55226 
0.501    X  27614  socat            4  10.0.1.20        10.100.0.2       55226  80    
0.001    X  27615  socat            4  10.100.0.2       10.0.1.20        80     55226 
4.228    X  4948   Socket Thread    4  10.156.4.134     130.192.55.225   41174  443   
0.401    X  3547   geoclue          4  10.156.4.134     52.34.56.182     35948  443   
7.338    C  3547   geoclue          4  10.156.4.134     52.34.56.182     50210  443   
\end{lstlisting}
In which the field time denotes the time difference at which the event occurred, measured in seconds. The difference is computed between the current event and the previous one. The field T indicates the type of network activity or event that took place. The possible values typically include:
"C" for connection initiated or established; "A" for connection accepted or acknowledged; "X" for connection closed or terminated. The field PID is the process identifier and identifies uniquely the process or program responsible for the connection. The field COMM, short for command, specifies the name or description of the process or command that initiated the network activity. It often helps identify which application or service is responsible for the communication.
The field IP is referred to the version of the IP. The final fields are related to the IP address and port of the source and destination.

To sum up the tool 1clock, extract the metrics from the tools tcpLife and tcpTracer, and synchronise them in order to calculate the mean and variance of the aforementioned features in a time interval of 25 seconds. The final product can be described by the following table:

\begin{table}[h!]
\centering
\begin{tabular}{p{4cm} p{9cm}}
\toprule
\textbf{Column Name} & \textbf{Description} \\
\midrule
mediaBT & Average bytes transmitted \\
mediaRX & Average bytes received \\
varBT & Variance of bytes transmitted \\
varRX & Variance of bytes received \\
medialat & Average latency \\
varlat & Variance of latency \\
Open & Number of open connections \\
Close & Number of closed connections \\
mediadift & Average difference of time \\
varDifT & Variance of difference of time \\
\bottomrule
\end{tabular}
\caption{Description of features of the data entry.}
\label{tab:1clock-datadescription}
\end{table}

\subsubsection*{Attacker}
The attacker node can be used to stress the server and verify its effect on the monitoring tool, on the logs and on the live prediction.
To enter the attacker:

\begin{lstlisting}
docker exec -it newenvironment_attacker_1 /bin/bash
\end{lstlisting}

The attacker is provided of several attacking tools: HULK (HTTP Unbearable Load King), Slowhttptest, hping3 and Ping of Death.

The tool HULK allows the performing of the HTTP flood attack. Are present two versions of the tool. The original version by Barry Shteiman and a newer version called HULK-v3 that allows the performing of a distributed DoS attack (DDoS).

To attack a node with Berry Shteiman:

\begin{lstlisting}
python3 hulkBasic/1hulk.py http://10.100.0.2:3000
\end{lstlisting}
In which the argument is the target of the attack. In this case is the IP address of the server already mentioned.

To attack a node with HULK-v3, activate the attacker server (that manages the bots):
\begin{lstlisting}
python3 HULK-v3/hulk_launcher.py server http://10.100.0.2:3000
\end{lstlisting}
In which the argument server indicates the set of the server and the second argument indicates the target of the attack.
Next, it is necessary to run the client part of the attack. To do so, it has to be opened a new terminal:
\begin{lstlisting}
docker exec -it newenvironment_attacker_1 /bin/bash
\end{lstlisting}
And then run:
\begin{lstlisting}
python3 HULK-v3/hulk_launcher.py client -n 10
\end{lstlisting}
In which the first argument indicates the set of the client and the \cmd{-n 10} the use of 10 bots to perform the attack.
For further information about the tool: \href{https://github.com/Hyperclaw79/HULK-v3}{https://github.com/Hyperclaw79/HULK-v3}.

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}

For further information about the tool, consult: \href{https://github.com/shekyan/slowhttptest}{https://github.com/shekyan/slowhttptest}

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 can be 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}

For further information, run \cmd{hping3 -h} or: \href{https://linux.die.net/man/8/hping3}{https://linux.die.net/man/8/hping3}

The Ping of Death, sends oversized ICMP packets to a target. To perform it run:
\begin{lstlisting}
python3 pingOfDeath/pingOfDeath.py
\end{lstlisting}

The code is set to attack automatically the server Servidor at http://10.100.0.2:3000.

\section{Experiment example}
Run the network:
\begin{lstlisting}
docker-compose up -d
\end{lstlisting}
Enter the server container and run the monitoring tool:
\begin{lstlisting}
docker exec -it newenvironment_servidor_1 /bin/bash
python3 /servidor/output/DoSdetector/1clock.py
\end{lstlisting}
In another terminal enter the attacker:
\begin{lstlisting}
docker exec -it newenvironment_attacker_1 /bin/bash
\end{lstlisting}
Run one of the attacks described in the previous section, as example a Slowloris attack:
\begin{lstlisting}
slowhttptest -c 1000 -H -g -i 10 -r 200 -t GET -u http://10.100.0.2:3000/ -x 24 -p 3
\end{lstlisting}
After some second it is possible to stop the attack, obtaining the figure \ref{fig:mantestslowloris}
\begin{figure}[h] % htbp stands for here, top, bottom, page (order of preference for placing the figure)
    \centering
    \includegraphics[width=0.7\textwidth]{7Results/SlowSlowloris.png}
    \caption{SlowHTTPtest: Slowloris attack}
    \label{fig:mantestslowloris}
\end{figure}

In another terminal enter the admin node:
\begin{lstlisting}
docker exec -it newenvironment_admin-fluentd_1 /bin/bash
\end{lstlisting}
Finally, enter the folder \cmd{shared-volume/prediction/livePrediction} to see the live result in the file named with the current date. To do so:
\begin{lstlisting}
cat 2024-06-30.txt
\end{lstlisting}
Or directly from the host machine, open the same file in the directory \cmd{newEnvironment/ admin-fluentd/shared-volume/prediction/ livePrediction}.
The result:
\begin{lstlisting}
2024-06-30 16:32:45 {"TIME":"2024-06-30 18:32:07", "IP address":"10.100.0.2", "tx_mean":0.0, "rx_mean":0.0, "tx_var":0.0, "rx_var":0.0, "ms_mean":64.36, "ms_var":0.0, "open_connections":2, "closed_connections":1, "mean_time":4.6335, "variance_time":64.08423425}
result: [[3.7544603e-05]]NO
2024-06-30 16:32:45 {"TIME":"2024-06-30 18:32:32", "IP address":"10.100.0.2", "tx_mean":0.0, "rx_mean":0.0, "tx_var":0.0, "rx_var":0.0, "ms_mean":5.142499999999999, "ms_var":21.63334375, "open_connections":1008, "closed_connections":9, "mean_time":0.020617502458210424, "variance_time":0.03552934140457842}
result: [[1.]]YES
2024-06-30 16:34:01 {"TIME":"2024-06-30 18:32:57", "IP address":"10.100.0.2", "tx_mean":0.0, "rx_mean":0.0, "tx_var":0.0, "rx_var":0.0, "ms_mean":6.652222222222223, "ms_var":228.9606839506173, "open_connections":9, "closed_connections":9, "mean_time":1.3333888888888887, "variance_time":2.203675015432099}
result: [[0.00063743]]NO
2024-06-30 16:34:01 {"TIME":"2024-06-30 18:33:22", "IP address":"10.100.0.2", "tx_mean":0.0, "rx_mean":0.0, "tx_var":0.0, "rx_var":0.0, "ms_mean":66139.98070506456, "ms_var":34619827.50813724, "open_connections":7, "closed_connections":1007, "mean_time":0.018799802761341224, "variance_time":0.05370422323467509}
result: [[1.]]YES
2024-06-30 16:34:01 {"TIME":"2024-06-30 18:33:47", "IP address":"10.100.0.2", "tx_mean":0, "rx_mean":0, "tx_var":0, "rx_var":0, "ms_mean":0, "ms_var":0, "open_connections":0, "closed_connections":0, "mean_time":0, "variance_time":0}
result: [[0.0051403]]NO
\end{lstlisting}
As noticeable, the attack started at 18:32:08 (which is the time of ends minus the duration of the attack - 18:33:18 - 00:01:10. Observing the output of the analysis, it is possible to notice the output time on the left, and the record time in the JSON object. Studying the record time, it is possible to match the starting of the attack with the first recognition of the attack at 18:32:32 (second block). It's observable a hole of recognition at 18:32:57 and finally the recognition of the attack until its end at 18:33:18.

Playing with the attacker,  by starting and interrupting the attack, it is possible to notice the difference in the TCP connection logs.
To directly read the logs, instead of relying on the live prediction, in the folder \cmd{/output
/DoS/}
\begin{lstlisting}
cat dos.log.20240630.log
\end{lstlisting}
The content of the log:
\begin{lstlisting}
2024-06-30T16:32:07+00:00 dos.tracer.logs {"TIME": "2024-06-30 18:32:07", "IP address": "10.100.0.2", "tx_mean": 0.0, "rx_mean": 0.0, "tx_var": 0.0, "rx_var": 0.0, "ms_mean": 64.36, "ms_var": 0.0, "open_connections": 2, "closed_connections": 1, "mean_time": 4.6335, "variance_time": 64.08423425}
2024-06-30T16:32:32+00:00 dos.tracer.logs {"TIME": "2024-06-30 18:32:32", "IP address": "10.100.0.2", "tx_mean": 0.0, "rx_mean": 0.0, "tx_var": 0.0, "rx_var": 0.0, "ms_mean": 5.142499999999999, "ms_var": 21.63334375, "open_connections": 1008, "closed_connections": 9, "mean_time": 0.020617502458210424, "variance_time": 0.03552934140457842}
2024-06-30T16:32:57+00:00 dos.tracer.logs {"TIME": "2024-06-30 18:32:57", "IP address": "10.100.0.2", "tx_mean": 0.0, "rx_mean": 0.0, "tx_var": 0.0, "rx_var": 0.0, "ms_mean": 6.652222222222223, "ms_var": 228.9606839506173, "open_connections": 9, "closed_connections": 9, "mean_time": 1.3333888888888887, "variance_time": 2.203675015432099}
2024-06-30T16:33:22+00:00 dos.tracer.logs {"TIME": "2024-06-30 18:33:22", "IP address": "10.100.0.2", "tx_mean": 0.0, "rx_mean": 0.0, "tx_var": 0.0, "rx_var": 0.0, "ms_mean": 66139.98070506456, "ms_var": 34619827.50813724, "open_connections": 7, "closed_connections": 1007, "mean_time": 0.018799802761341224, "variance_time": 0.05370422323467509}
2024-06-30T16:33:47+00:00 dos.tracer.logs {"TIME": "2024-06-30 18:33:47", "IP address": "10.100.0.2", "tx_mean": 0, "rx_mean": 0, "tx_var": 0, "rx_var": 0, "ms_mean": 0, "ms_var": 0, "open_connections": 0, "closed_connections": 0, "mean_time": 0, "variance_time": 0}

\end{lstlisting}

To read the logs of the whole network, in the folder \cmd{/output}:
\begin{lstlisting}
cat output.log.20240701.log
\end{lstlisting}
An example of the log:
\begin{lstlisting}
2024-07-01T00:00:04+02:00 syslog.kern.warn {"host": "RBrouter", "ident": "kernel", "message": "kauditd_printk_skb: 2 callbacks suppressed"}
2024-07-01T00:00:04+02:00 syslog.kern.notice {"host": "RBrouter", "ident": "kernel", "message": "audit: type=1400 audit(1719784804.646:136): apparmor=\"DENIED\" operation=\"capable\" class=\"cap\" profile=\"/usr/sbin/cupsd\" pid=54364 comm=\"cupsd\" capability=12  capname=\"net_admin\""}
2024-07-01T00:00:04+02:00 syslog.kern.warn {"host": "RDrouter", "ident": "kernel", "message": "kauditd_printk_skb: 2 callbacks suppressed"}

\end{lstlisting}