This manual is intended to be read after the User manual, because it provides additional information, useful to understand the functioning and possibly the editing of the platform.

This project consists in a virtual network that allows the testing and recognising of several DoS attacks from a forensic point of view. The network routing is managed by a tool called FRRouting, installed on every router node. The log collection is performed with a data collector called Fluentd, installed on the admin-fluentd node. The data are extracted on the server node by means of the tools tcpLife and tcpTracer, provided by bpftools, which have been slightly modified and synchronised by means of the script 1clock.py. 
At first, it will be presented a brief explanation of the virtual network. Next, how it has been realised by means of docker-compose, specifying the detail of each container by referring to their dockerfile and entrypoint. Then a synthetic explanation of how FRR and Fluentd work and how it have been configured in the project. Finally, the necessary information to understand the prediction tools.
\section{Virtual network}
The network \ref{fig:vnDev} is built over a tree topology, in which as root is positioned a router called routerB and as leafs client representative nodes, which include an attacker node.
On top of routerB there is the routerA, which connects the tree to the server network and an administrator node. The network routing is handled by FRRouting (FRR), an open-source IP routing protocol suite, designed to facilitate routing protocols like BGP, OSPF and RIP. It ensures efficient data packet routing across the network, mimicking the routing behaviours of real-world network. The administrator node, instead, is employed as a log collector and is meant to monitor the entire network. In fact, every node of the net sends its log to the administrator
node. The log collection and aggregation activity is performed in the admin node, by means of the open-source data collector Fluentd. Together with the logs of the net, Fluentd collects the necessary information to understand if a DoS attack happened.
\begin{figure}
    \centering
    \includegraphics[width=1\linewidth]{3VirtualNetwork/VirtualNetwork.pdf}
    \caption{Virtual network}
    \label{fig:vnDev}
\end{figure}

\section{Docker}
\subsection{Docker-compose}
The docker-compose file is composed of three section: the version of docker-compose, the services and the networks. 
With services are meant the container that run an image. This virtual network has several types of nodes: administrator, server, router, client and attacker.
The networks instead define the network space available. 
\subsection*{Networks}
The ``network" keyword, is a top-level key in the Docker Compose file that defines custom networks. Docker Compose allows you to create and manage networks that your services can use to communicate. For example \ref{lst:neteg}, the network ``servidor-system" is configured to provide $2^8 - 2$ (the 10.100.0.0 is used to address the network and 10.100.0.0 for broadcasting) IPv4 addresses.
\begin{lstlisting} [caption=Network example, label=lst:neteg]   
networks:
 servidor-system:
    driver: bridge
    ipam:
      config:
        - subnet: 10.100.0.0/24
\end{lstlisting}

The line ``driver: bridge" specifies the network driver to use. Docker has several network drivers, and bridge is the default driver for creating networks. A bridge network is an internal network within a single Docker host that containers connected to it can use to communicate with each other.
IPAM stands for IP Address Management. This section allows you to configure how IP addresses are assigned within the network.
The key ``config" is used to specify the configuration settings for IPAM. It expects a list of configurations. Finally, the range of the subnet is written.
The networks present in the figure \ref{fig:vnDev} are defined in the same way.
\subsection*{Services}

The services: key is a top-level key in a Docker Compose file. It is used to define the services that make up the multi-container application. Each service corresponds to a container that will be run by Docker.
As anticipated the services used in this network can be divided in admin, router, server, client and attacker.
Analysing as example the service ``admin-fluentd" \ref{lst:compose-admin}, it is possible to observe several keywords.
``build:" specifies the build context and Dockerfile for the service. The directory containing the build context is specified by ``context: ./admin-fluentd". This is where Docker looks for the Dockerfile and any other files needed for the build. The field ``dockerfile: Dockerfile\_admin-fluentd" specifies the name of the Dockerfile to use. In this case, it is Dockerfile\_admin-fluentd. If not provided, the default name of the dockerfile must be set to ``Dockerfile". The custom name choice is recommended.
The line ``entrypoint: entrypoints/ep\_fluentd.sh" overrides the default entrypoint of the Docker image, specifying a script ep\_fluentd.sh in the ``entrypoints" directory to be run when the container starts. The entrypoints directory, will be located in te ``context" previously defined.
\begin{lstlisting} [caption={Service example, admin-fluetd}, label=lst:compose-admin]   
admin-fluentd:
    build: 
      context: ./admin-fluentd
      dockerfile: Dockerfile_admin-fluentd
    privileged: true
    #the container as first instruction executes the entrypoint (since the image doesn't support bash it's used sh)
    #entrypoint: sh -c "entrypoints/ep_fluentd.sh" alpine version
    entrypoint: entrypoints/ep_fluentd.sh
    #-volumes between fluentd and the host
    volumes:
      - ./admin-fluentd/conf/fluent.conf:/fluentd/etc/fluent.conf 
      - ./admin-fluentd/-volume:/-volume
      - ./admin-fluentd/output:/fluentd/output/
    #hostPort:containerPort
    #indicates a connection between these 2 ports
    ports:
      - "24224:24224"
      - "24224:24224/udp"
      - "5140/tcp"
    command: 
      - "/bin/sleep"
      - "infinity"
    networks:
      professor-system:
        ipv4_address: 10.200.0.2
\end{lstlisting}

The ``volumes:" defines  volumes between the host and the container. Docker offers the possibility to mount  volumes between the container and the host. The property \cmd{volumes} allows data persistence and the chance of sharing data between containers and the host. Indeed, it has been used for data sharing, to allow easy updates and to make persistent a storage, since by restarting the containers the image is set at the entrypoint instead of the last state. With this option, it is possible to change the scripts needed and test them without stopping and rebuilding the container images. To avoid the use of -volume, it may be preferred at the final stage of a project, to copy the script inside the image and make it definitive. 
The syntax of the command:
\begin{lstlisting}   
./admin-fluentd/conf/fluent.conf:/fluentd/etc/fluent.conf
\end{lstlisting}
indicate that the file ``fluent.conf" of the relative path ./admin-fluentd/conf/ belonged to the host, will be mapped as the file ``fluent.conf" in the absolute path ``/fluentd/etc/" of the service.

The ``ports:" mapping indicates the relationship between host port and service port. In this case \ref{lst:compose-admin}, the port 24224 of the host will consultable to examine the port 24224 and 24224/udp of the container. The third example is equivalent to ``5140/tcp:5140/tcp".
The ``command:" section overrides the default command for the container. In this case, it runs /bin/sleep infinity to keep the container running indefinitely without doing anything. This is often used for debugging or keeping a container running for other reasons.
``networks:" specifies the custom network configuration for the service. In this case \ref{lst:compose-admin}, ``professor-system:" is the name of the custom network to connect to.  The line ``ipv4\_address: 10.200.0.2" assigns the static IP address 10.200.0.2 to the container within the professor-system network. 

The field ``privileged: true" will be covered in the next services to be compared with other keywords.

The node admin-fluentd is the administrator node and it is advisable to not add any equal node.

Observing the service ``servidor", that stands for server in Spanish, it is possible to notice some keywords not present or analysed with the service ``admin-fluentd" \ref{lst:compose-admin}.

\begin{lstlisting} [caption={Service example, admin-fluetd}, label=lst:compose-admin]   
admin-fluentd:
    build: 
      context: ./admin-fluentd
      dockerfile: Dockerfile_admin-fluentd
    privileged: true
    #the container as first instruction executes the entrypoint (since the image doesn't support bash it's used sh)
    #entrypoint: sh -c "entrypoints/ep_fluentd.sh" alpine version
    entrypoint: entrypoints/ep_fluentd.sh
    #-volumes between fluentd and the host
    volumes:
      - ./admin-fluentd/conf/fluent.conf:/fluentd/etc/fluent.conf 
      - ./admin-fluentd/-volume:/-volume
      - ./admin-fluentd/output:/fluentd/output/
    #hostPort:containerPort
    #indicates a connection between these 2 ports
    ports:
      - "24224:24224"
      - "24224:24224/udp"
      - "5140/tcp"
    command: 
      - "/bin/sleep"
      - "infinity"
    networks:
      professor-system:
        ipv4_address: 10.200.0.2
\end{lstlisting}

To allow a service to perform a task with high privileges, it is possible to set the option ``privileged: true". This option provides full access to devices on the host and grants access to a set of instruction that otherwise would not be accessible, useful when the node needs to perform low-level system tasks. However, this option exposes the host to security risks breaking the principle of isolation, typical of the containers. Example of these operations could be mounting a host file-system, set network configuration or obtain hardware access to manage USB devices or control GPUs. 

Another possibility is to use the option ``cap\_add" that stands for additional capabilities. In this way, the privileges are more granular and specific purposes compared to ``privileged: true". Linux divides the privileges of the user root into distinct units of capabilities. The list of the capabilities can be found in Linux manual.
Use cases of ``cap\_add" can be:
\begin{itemize}
    \item``NET\_ADMIN": allows administration task, like configuring the network interfaces, managing routing tables and setting up firewall.
    \item``SYS\_ADMIN": enables operations such as mounting filesystems and setting up of namespaces
    \item``KILL": bypass the permission checks for sending signals
    \item``BPF": also included in ``SYS\_ADMIN", is weaker and allows BPF operations. If the aim is to set up performance monitoring, it's also necessary to set ``PERFMON"
\end{itemize}

To make the implementation easier and permissions free, has been chosen to proceed with the option ``privileged: true". This makes the addition of ``cap\_add" useless, but it has been left in the code for future improvements, as a reminder and example.

The ``logging:" section specifies the logging driver and its options for the container. ``driver: "fluentd"" sets the logging driver to fluentd, which means that the container will send its log output to a Fluentd service for aggregation and processing. The field ``options:" provides specific options for the Fluentd logging driver, in this case:
\begin{lstlisting}
    fluentd-address: 10.200.0.2:24224
    tag: servidor
    #makes the execution non-blocking
    fluentd-async: 'true'
\end{lstlisting}
``fluentd-address: 10.200.0.2:24224" specifies the address of the Fluentd service to which the logs should be sent. In this case, it is the IP address 10.200.0.2 on port 24224. The ``tag: servidor" sets a tag for the logs, which can be used by Fluentd to filter and categorize the log entries. The flag ``fluentd-async: 'true'" makes the logging execution non-blocking. This means the container can continue running even if Fluentd is slow or unavailable, preventing potential bottlenecks or crashes due to logging issues.
This entire group of option, ``logging", resulted not trustable. To address the logging problem has been chosen a simpler way, by means of other commands inserted in the Dockerfile and entrypoint. It has been decided to keep the option to offer a possibility of improvement for the future. Its malfunctioning does not add any problem or risk for the network.

The ``depends\_on:" field defines dependencies between services. It ensures that the specified services are started before the current service, in this case the service ``admin-fluentd". Docker Compose will ensure that admin-fluentd is started before servidor. Note that depends\_on does not wait for the admin-fluentd service to be ``ready" (e.g., responding to network requests); it only ensures that it has been started.

The service ``servidor" can be copied and pasted in the docker-compose.yml to add more server services. An example could be the addition of ``servidor2". 

The principles exposed for ``admin-fluentd" and ``servidor" are valid also for the other nodes of the network and for the other categories: router, client and attacker.

\subsection{Dockerfiles}
As noticeable from the router service, they share the same options but most importantly the same Dockerfile but a different entrypoint.

Dockerfile is a text file that contains the instructions on how to build a Docker image, in which each instruction corresponds to a new layer.
Dockerfile uses a set of commands to define the layer of the image:
\begin{itemize}
    \item \cmd{FROM}: Specifies the base image
    \item \cmd{RUN}: Executes a command in the shell. Usually used to install packages, clone repositories, build scripts and so on.
    \item \cmd{COPY}: Copies a file from a local repository to the container repository
    \item \cmd{WORKDIR}: The Dockerfile correspondent of \cmd{cd}
    \item \cmd{EXPOSE}: Specifies the port of the container that listens for connections
    \item \cmd{USER}: Set the username or UID to use when running the image
    \item others...
\end{itemize}

Let's focus now on some important details of the dockerfiles used in this project. The easy or immediate understandable lines will be left to the reader.

The admin-fluentd node starts from a Fluentd image based on Debian.
Attention deserving are the next line of the Dockerfile\_admin-fluentd:
\begin{lstlisting}[caption=Dockerfile\_admin-fluentd, label=lst:dockadmin]
RUN apt install -y python3-venv   
RUN python3 -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
# Install packages within the virtual environment
RUN pip install tensorflow scikit-learn numpy joblib

RUN ln -fs /usr/share/zoneinfo/Europe/Madrid /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 systemctl cron
RUN echo "00 00 * * * /bin/bash /shared-volume/prediction/livePrediction/liveLogfileCreator.sh" | crontab -
\end{lstlisting}

The first block defines a virtual environment and install the packages TensorFlow, scikit-learn, NumPy and joblib, which are necessary for the node. They are used to importing and make the AI model to work. The reason why, it has been done by means of the virtual environment, is because during the installation of TensorFlow, appeared a compatibility problem of the package with the operative system of the container. The node in question is the admin-fluent, whose image uses \cmd{fluent/fluentd:v1.17.0-debian-amd64-1.0}. To solve the issue, it has been decided to use a Virtual Environment for the installing of the python libraries required. A virtual environment is an isolated Python environment that allows to manage dependencies for different projects separately, so as to avoid conflicts between project dependencies and system-wide packages. When activated, the virtual environment, modifies the shell's 'PATH' variable so that the virtual environment's python and pip are used instead of the system-wide versions.

The second block, repeated in the dockerfiles of the other nodes, allow the container to be set on the same time zone, in order to make the logs consistent. 

The third block creates, by means of cron, a routine that run a bash script every day at midnight. The bash script simply creates a file .txt that is used to store the live prediction (later will be explained better).

The Dockerfile\_servidor, installs a series of packages for IP routing and logging and others necessary to functioning of eBPF features. To be more precise, the packages used to load and attach the eBPF programs and the packages needed to install libbpf and bpftools. Libbpf is a library for interacting with BPF programs. It is designed to simplify the process of loading, configuring, and managing BPF programs in user space. The BPF tool is a command-line utility that provides various capabilities to interact with BPF programs and maps from user space. It is built on top of libbpf and is part of the Linux kernel's BPF infrastructure. Moreover, these packages allow the use of BCC, which is a set of powerful tools and libraries for creating, loading, and managing BPF (Berkeley Packet Filter) programs on Linux systems.

A line for the installing of fluent-logger for python is added. This library is used to allow the communication of a python script with a Fluentd instance.

The Dockerfile\_attacker, contains the necessary instruction for the installation of the tools Slowhttppost, HULK-v3 and hping3. In the case of hping3, the timezone block is also useful to avoid the build to get blocked by the input request of its installation. To better relate, the reader can try to install hping3 in its system.

Finally, the Dockerfile\_router is mainly used to set the tool in charge of the routing system in the network: FRRouting. Its functioning together with the instruction inserted in the dockerfile will be covered later. Finally, the ipforwarding flag is set to true to allow the router to forward the packets and the configuration of the syslog-ng tool are change in order to send the logs straight to the port associated to Fluentd of the administrator node. The logs are sent by means of a TCP connection to ensure the integrity of the packets.

All of the mentioned dockerfile have as last instruction a similar command:
\begin{lstlisting}
COPY entrypoints/ep_routerA.sh entrypoints/ep_routerA.sh
COPY entrypoints/ep_routerB.sh entrypoints/ep_routerB.sh
COPY entrypoints/ep_routerC.sh entrypoints/ep_routerC.sh
COPY entrypoints/ep_routerD.sh entrypoints/ep_routerD.sh
#make the scripts executable 
RUN chmod +x /entrypoints/ep_routerA.sh /entrypoints/ep_routerB.sh /entrypoints/ep_routerC.sh /entrypoints/ep_routerD.sh
\end{lstlisting}

To be more precise, the entrypoint located on the host machine is copied in a directory of the imager. To avoid confusion,it has been chosen a path with the same name. After copying the entrypoint script in the image, it is set to be executable by the container. The snippet exposed is related to the Dockerfile\_router. The reason why it has been chosen this as example, is because this dockerfile is shared among different router. Being all routers, they all have a similar base, but they differ for their routing configuration. For this reason, they have a different entrypoint. This example is meant to be used in case it is necessary to replicate other services and avoid the creation of custom Dockerfile for each duplicate. Of course, this implies the creation of a copy of each entrypoint in every image.

\subsection{Entrypoints}
It will follow now a brief analysis of the entrypoint of each node.

The first node to be considered is the admin-fluentd. At first a bash script is made executable. This is the bash script responsible for the creation of a file .txt with the name of the current date in the folder \cmd{shared-volume/prediction/ livePrediction/}. This file is used by fluentd to store the live prediction about the data collected. This is the same script the cron routine triggers. In order to start the service cron, it needs at run time to be enabled and started.
To be sure of not having compatibility problems, TensorFlow is being updated every time the network is started.
Finally, the log collector Fluentd is started by using the executable and adding as argument the fluentd configuration file. 
\begin{lstlisting}
chmod +x shared-volume/prediction/livePrediction/liveLogFileCreator.sh
/shared-volume/prediction/livePrediction/liveLogFileCreator.sh

systemctl enable cron
systemctl start cron

pip install --upgrade tensorflow

# Start fluentd with a specific configuration file
/usr/local/bundle/gems/fluentd-1.17.0/bin/fluentd -c /fluentd/etc/fluent.conf & 
\end{lstlisting}

Server side, it is important to start the npm server, used as basic server example in this project, and most importantly terminate the configuration of eBPF. To allow the use of the tool BCC it is mandatory the installing of the package \cmd{apt-get install -y linux-headers-\$(uname -r)}. In which ``uname -r" prints the kernel release version. Particularly this is the command it cannot work with Windows distribution used as host, because the Windows Subsystem for Linux (WSL) does not provide this kind of header. The last command to run is \cmd{mount -t debugfs none /sys/kernel/debug} that allows the mounting of the debugfs at /sys/kernel/debug. This allows user space programs and tools to access and manipulate kernel debugging information and interfaces that are exposed through debugfs. Debugfs is a virtual filesystem that exposes kernel debugging interfaces to user space. It provides a way to interactively debug and trace kernel code, inspect kernel data structures, and retrieve debug messages and statistics.

The router entrypoint is specific for each router. This is because in this bash script it is setted the configuration of FRR (the routing tool). Moreover, the service of FRR and syslog-ng are started. The setting of FRR will be covered in the next paragraph.

A common operation, among the nodes, to be performed in the entrypoints, is the setting of the router as default route. Initially, the proximity router has been set as default router, however this led to the lost of the connection with the host internet connection, making impossible any update at runtime. The problem have been solved by using a wider network as destination for the path going through the proximity router.
Here is an example:
\begin{lstlisting}
# Rather then using a default route is inserted the whole
# interval of address as a static route. This is done to allow
# the node a connection to internet.
#ip route change default via 10.200.0.10
ip route add 10.0.0.0/8 via 10.200.0.10   
\end{lstlisting}
Finally, all the entrypoint have as last operation the \cmd{/bin/sleep infinity} that ensures the container not to stop its execution, making impossible to log in, by means of the command
\cmd{docker exec -it newenvironment\_[service\_name]\_1\\ /bin/bash}.
This last command, solve the same purpose of the option ``command" of the docker-compose file. 

\section{FRRouting}
FRRouting (FRR) is an open-source routing software forked from the Quagga project. Its modular design allows the integration and customisation of protocols, by simply enabling or disabling the required daemons.
The Zebra Daemon acts as central manager and behave like an interface between the other protocol daemons and the routing table. Each supported protocol has its own daemon. Example of protocols are the BGP (Border Gateway Protocol), used for large-scale inter-domain routing, OSPF (Open Shortest Path First), used for intra-domain routing, RIP (Routing Information Protocol), a distance vector protocol.
The routers have been configured so that the protocol OSPF is used as routing protocol and zebra is activated in order to allow its intermediate role. Moreover, the IP-forwarding option is set to true, to allow the node to act as a router and forward the traffic to the right destination. 
The daemon configuration happens by setting the configuration file of FRR in the dockerfile (\ref{lst:frrconf}) because it is common with every router of the network. 
\begin{lstlisting}[caption=Dockerfile\_router, label=lst:frrconf]
# Configure frr enabling daemon and setting ports
RUN sed -i 's/^bgpd_options=.*/bgpd_options="  --daemon -A 127.0.0.1"/' /etc/frr/daemons && \
    sed -i 's/^zebra_options=.*/zebra_options=" -s 90000000 --daemon -A 127.0.0.1"/' /etc/frr/daemons && \    
    sed -i 's/^bgpd=.*/zebra=yes\nbgpd=yes/' /etc/frr/daemons && sed -i 's/^ospfd=.*/ospfd=yes/' /etc/frr/daemons &&\
    sed -i 's/^zebra=.*/zebra=yes/' /etc/frr/daemons && \
    sed -i 's/^ospfd_options=.*/ospfd_options="  --daemon -A 127.0.0.1"/' /etc/frr/daemons    
RUN echo "zebrasrv 2600/tcp" > /etc/services && echo "zebra 2601/tcp" >> /etc/services && echo "bgpd 2605/tcp" >> /etc/services \
    && echo "ospfd 2604/tcp" >> /etc/services    
\end{lstlisting}
The command sed is used to modify the /etc/frr/daemons configuration file. Precisely
\begin{itemize}
    \item bgpd\_options: Configures the BGP daemon (bgpd) to run as a daemon and listen on 127.0.0.1.
    \item zebra\_options: Configures the Zebra daemon (zebra) to run as a daemon with specific options and listen on 127.0.0.1.
    \item ospfd\_options: Configures the OSPF daemon (ospfd) to run as a daemon and listen on 127.0.0.1.
    \item The lines set zebra=yes, bgpd=yes, and ospfd=yes to enable these daemons to start.
\end{itemize}


The service is enabled and activated at runtime by means of the entrypoint bash script. Moreover, the script is also used to configure differently each router and instruct them about their neighbour. To do so, the software is provided with a command-line interface, called VTYSH (Virtual TeletYpe SHell), allowing an easy configuration and management of the daemons.

\begin{lstlisting}[caption= Topology configuration routerA, label= lst:routerA]
service syslog-ng start                     #start the syslog
service frr start                           #start frr (routing service)

#set frr and set the frrRouter log
vtysh << EOF
conf t
router ospf
network 10.100.0.0/24 area 0
network 10.200.0.0/24 area 0
network 10.1.0.0/24 area 0
end
EOF
\end{lstlisting}

To configure the topology of the routerA \ref{lst:routerA}, it has been fed the VTYSH with a heredoc. It allows passing a block of text as input to a command. The general syntax is: \cmd{command <<EOF text EOF}. The first command \cmd{conf t}, short for configure terminal, is used to enter the configuration mode in VTYSH. Once in the configuration mode, ``router ospf" is used to enter the OSPF router configuration mode. Finally, the router is instructed with the  neighbour areas. To exit and save, the command ``end" is inserted as the final line.

The configuration of the other routers follow the same mechanism.\\
For further information about FRR consult: \\\href{https://docs.frrouting.org/en/latest/setup.html}{https://docs.frrouting.org/en/latest/setup.html}

\section{Fluentd}
Fluentd offers a complete solution to simplify the handling of logs from different source, which were complex and coming from fragmented source, forcing the use of different tools for different type of logs.
Fluentd is based on 4 core blocks:
\begin{itemize}
    \item Input: component responsible for the  data collection from sparse sources. Thanks to different plugins it is possible to ingest data from logs, databases and more, allowing Fluentd to manage whatever type of log data making it a universal data collector.
    \item Buffer: is used to temporarily store data. Different buffer mechanism are supported, including in-memory, file-based and others.
    \item Filter: can modify, enrich or exclude log data based on predefined rules. 
    \item Output: is the block responsible for the formatting of data in exit and the delivery to different destinations like databases, other services, files.
\end{itemize}

The configuration file, used to run the tool (explained in the paragraph Entrypoints), is located in the folder conf as fluent.conf and mapped in the container as ``/fluentd/etc/fluent.conf", has been set as it follow.
The explanation of the configuration file can be referred to \ref{par:fluentdconfFile}

For further information about Fluentd: \href{https://docs.fluentd.org/}{https://docs.fluentd.org/}

\section{Data extracting tools mechanic}

As explained in the User Manual, to reach the final data shape it is necessary to perform some changes to the output data by tcpTracer, merge and synchronise the tools data and perform the computation of the mean and variance of the metrics.

To remind the reader, the structure of the data is shown in \ref{tab:dataset-description}.

The analysis of the TCP tools, tcpLife and tcpTracer can be found at \ref{par:tools-eBPF}.

The analysis of the synchronisation mechanic can be found at \ref{par:synchron}

The figure \ref{fig:dataCollectorDiagram} summarise the synchronisation mechanism.



\section{Prediction programs}
In order to make use of the model, it is necessary to import both the scaler and the model. To do so, it is used the function \cmd{load()} of the library \cmd{joblib} for the scaler and the function \cmd{load\_model()} from the Keras module of TensorFlow library.

\begin{lstlisting}[language=Python]
classifierLoad = tf.keras.models.load_model( '/shared-volume/prediction/MLP_11agosto.keras', compile=False)

# Load the StandardScaler
scaler = joblib.load('/shared-volume/prediction/std_scaler.bin')
\end{lstlisting}

The compile parameter is set as false to indicate that the model is not going to be trained, but just fed with prediction entries.

This lines of code are used in all the three possible script for the data analysis. The intervalModelUser.py and manualModelUser.py are banal and are left to the reader.

The complexity of the 1prediction.py tool, the one used for the live prediction, using Fluentd, lays in how the data arrive are input. The argument the tool usually takes in input is provided by Fluentd. By studying the Fluentd configuration it may seem that the tool directly pass the log line, however, because of the use of the buffer as intermediate station, the buffer is the argument passed to the software. To be precise, the buffer collects one or more log line and when it's ready is given as input to the tool. This mean that it needs to be opened as a file, and that it will contain several lines. To verify, it is advised to run the command \cmd{ls /var/lib/fluentd/} while the 1clocl.py is running in the server node. The result will highlight the existence of the buffer ``predictor\_dos\_logs\_buffer" (the same defined in the fluent.conf file). Inside the buffer will be present several log files as buffer.q61891f6d1063321b01b57f8c324c1388.log, that can be opened as a text file. With the command \cmd{cat buffer.q61891f6d1063321b01b57f8c324c1388.log} it is possible to read the log lines passed by 1clock.py, collected by the buffer and that will be used as input in the 1prediction.py tool.
For further experiment and better understand the functioning, it is also advised to modify the 1prediction.py script and print the argument received.
\section{AI models}
The explanation of the dataset analysis, in the script  ``4.5\_multilayer\_perceptron", is available here: \ref{par:datasetAnalysis}.\\
An analysis of the Random Forest script is here: \ref{par:ranfomF}.\\
The analysis of the MLP is referenced here: \ref{par:MLP}.\\

