\chapter{Les réseaux informatiques}

\section{Introduction}

Pour être en mesure de comprendre le fonctionnement de l'analyse des règles de sécurité des réseaux informatiques, il est d'abords nécessaire de définir ce que sont ces dernières. Les classes et objets du projet utilisent les terminologies réseaux expliquées ici. 

Le but d'un réseau informatique et d'acheminer des données sous forme de paquets \acrshort{ip} d'un n\oe{}ud A vers un ou plusieurs autres n\oe{}uds. Ces réseaux sont composés de plusieurs sortes d'équipements différents comme des routers, switches (commutateurs en français) mais aussi des équipements plus orienté sur la sécurité tels que des \glspl{firewall} ou \gls{proxy}. Tous ces équipements sont reliés ensemble via du câblages cuivre ou bien par du réseau optique. Ils forment ensemble le réseau physique. Son rôle est de faire transiter des trames ethernet d'un équipements à un autre, sans s'assurer qu'ils soient arrivés à destination.

Contacter un n\oe{}ud réseau par son adresse physique (l'adresse \acrshort{mac}) peut vite s'avérer être un problème. Il faut être sur quelle soit unique dans l'entier du réseau, faute de quoi, la transmission ne pourra être faite. De plus, chaque changement d'équipement s'accompagne forcément d'un changement d'adresse matériel. Il n'est pas non plus possible d'isoler une machine d'une autre, ce qui rend impossible la mise en place de sécurité réseau. C'est notamment pour ces raisons qu'un réseau virtuel ou logique est configuré au dessus du réseau physique, réseau qui utilise les protocoles IP en version 4 ou 6. Ce système permet d'attribuer manuellement ou à la demande des adresses sur un no\oe{}ud indépandemment de son matériel. Il est également possible de créer plusieurs réseaux logiques sur un seul réseau physique (avec l'utilisation de VLAN), ce qui permet d'établier des règles de sécurité pour limiter les communications.

Bien que le protocole \acrshort{ip} amène un système d'adressage plus souple et modulaire, il ne s'assure pas que le paquet arrive correctement à destination. Il ne fournit pas non plus d'identifiant permettant à la machine distante de savoir quel processus doit traiter le paquet. Pour cela, deux protocoles principaux osnt utilisés aujourd'hui, il s'agit de \acrshort{tcp} et \acrshort{udp}. Ces deux protocoles vont attribuer un numéro de port aux segments échangés, afin que les systèmes d'exploitation soient en mesure de savoir quel programme doit traiter la requête.

Cette construction en couche superposée est standardisée par une structure connue sous le nom de modèle \acrshort{osi}\cite{wikiosi}.

\newpage
\section{Le modèle OSI}

Le modèle \gls{osi} est un découpage en  sept couches écrit par l'\gls{iso}, représentant les différents acteurs nécessaires à l'échange et la compréhension de l'information.

\vspace{3mm}
\begin{figure}[h]
  \centering
  \includegraphics[width=100mm]{OSI_Model_v1.png}
  \caption{Le modèle OSI}
\end{figure}
\vspace{3mm}
  
Ce qui va particulièrement nous intéresser ici sont les couches trois et quatres. La couche trois, réseau, décrit l'adressage logique des n\oe{}uds du réseau et la façon dont ils vont communiquer. C'est à ce niveau qu'est définit le protocole IPv4 est avec lui son système d'adressage et de routage qui sont essentiels pour comprendre le fonctionnement de certains objets (\Colorbox{light-gray}{\lstinline|Address|}, \Colorbox{light-gray}{\lstinline|Route|}).

La couche quatre, elle, décrit les protocoles de transport de l'information avec notamment \acrshort{tcp} et \acrshort{udp}. Le modèle \Colorbox{light-gray}{\lstinline|Service|} contient un ou plusieurs \Colorbox{light-gray}{\lstinline|PortRange|} dont les attributs sont basés sur ces protocoles.

\newpage
\section{Couche 3 - les réseaux IP}

\subsection{IPv4}

Un n\oe{}ud dans un réseau IPv4 est définit par une adresse réseau ainsi qu'un masque. Ensemble, ils vont définir l'identifiant de la machine ainsi que le sous-réseau dans lequel il appartient. Ces deux propriétés sont représentées sous la forme de 4 blocs de 8 bits au format décimal, séparé par des points (exemple: 192.168.0.10). Le masque lui, représente des valeurs binaires continues (par exemple 255.255.128.0) qui définissent quels sont les bits qui font partie du sous-réseau et lesquels définissent l'hôte. En appliquant l'opération "AND" logique sur ces deux valeurs, on obtient l'identifiant du sous-réseau dans lequel l'adresse IP fait partie. Dans le cadre de l'application, un n\oe{}ud réseau est représenté par la classe \Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}).

\vspace{3mm}
\begin{figure}[h]
  \centering
  \includegraphics[width=150mm]{comparaison_binaire.png}
  \caption{Comparaison binaire d'adresse IPv4}
\end{figure}
\vspace{3mm}

La longueur du masque va définir la taille du réseau et donc le nombre d'adresses IP unique utilisable. Une adresse IPv4 étant codée sur 32 bits, si l'on décide d'utiliser un masque de 24 bits (255.255.255.0), il va rester 8 bits disponibles pour identifier les hôtes soit 256 adresses. Il faudra encore soustraire à celle-ci la première et la dernière adresse qui représentent respectivement l'identifiant du réseau et son adresse dite de "broadcast". Dans le cadre de ce projet, ce genre de calcul est utilisé pour savoir si l'adresse IP d'une machine donnée est comprise dans une liste de réseau.

\vspace{3mm}
\begin{table}[H]
    \centering
    \caption{Exemples de réseaux IP}
    \label{net-tab-network}
    \begin{tabular}{|l|l|l|l|l|}
    \hline
                                        &                                   & \multicolumn{3}{c|}{\textbf{Adresses IPv4}}               \\ \cline{3-5}
    \multirow{-2}{*}{\textbf{Réseau}}   & \multirow{-2}{*}{\textbf{Masque}} & Première      & Dernière          & Disponible            \\ \hline
    10.0.0.0                            & 255.0.0.0                         & 10.0.0.1      & 10.255.255.254    & $2^24 - 2 = 16777214$ \\ \hline
    172.16.0.0                          & 255.255.0.0                       & 172.16.0.1    & 172.16.255.254    & $2^16 - 2 = 65534$    \\ \hline
    192.168.1.0                         & 255.255.255.0                     & 192.168.1.1   & 192.168.1.254     & $2^8 - 2 = 254$       \\ \hline
    10.0.1.0                            & 255.255.255.224                   & 10.0.1.1      & 10.0.1.30         & $2^5 - 2 = 30$        \\ \hline
    \end{tabular}
\end{table}
\vspace{3mm}

Dans les tables de routage (section \ref{subsec:network:ip:routing}) ainsi que dans les règles de sécurité (section \ref{subsec:network:ip:firewall}), on retrouve souvent le réseau "0.0.0.0/0", ce cas un peu particulier décrit le réseau qui va comprendre toutes les adresses IPv4 possibles. Si on applique la même logique que précédemment, un masque de 0 bit signifie bien que les 32 bits définissent l'adresses, donc n'importe quelle adresse sera forcément contenue dans ce réseau. Il est utilisé pour définir un object \Colorbox{light-gray}{\lstinline|Address|} qui s'appelle souvent "any". Dans le cas d'une \Colorbox{light-gray}{\lstinline|Route|}, il représente la route par défaut, celle qui sera prise si aucune autre n'est disponible.

\subsection{CIDR}
\label{subsec:network:ip:cidr}

La notation \acrshort{cidr} est beaucoup utilisée dans cette application, il s'agit d'une façon différente de décrire le masque d'un réseau. Il indique le nombre de bits à 1 dans le masque de sous-réseau et est donc plus court à écrire.

\vspace{3mm}
\begin{table}[H]
    \centering
    \caption{Notation CIDR}
    \label{net-tab-cidr}
    \begin{tabular}{|l|l|l|l|}
    \hline
    \textbf{Masque} & \textbf{CIDR} & \textbf{Masque} & \textbf{CIDR}\\ \hline
    0.0.0.0         & /0    &   -               & -     \\ \hline
    128.0.0.0       & /1    &   255.255.128.0   & /17   \\ \hline
    192.0.0.0       & /2    &   255.255.192.0   & /18   \\ \hline
    224.0.0.0       & /3    &   255.255.224.0   & /19   \\ \hline
    240.0.0.0       & /4    &   255.255.240.0   & /20   \\ \hline
    248.0.0.0       & /5    &   255.255.248.0   & /21   \\ \hline
    252.0.0.0       & /6    &   255.255.252.0   & /22   \\ \hline
    254.0.0.0       & /7    &   255.255.254.0   & /23   \\ \hline
    255.0.0.0       & /8    &   255.255.255.0   & /24   \\ \hline
    255.128.0.0     & /9    &   255.255.255.128 & /25   \\ \hline
    255.192.0.0     & /10   &   255.255.255.192 & /26   \\ \hline
    255.224.0.0     & /11   &   255.255.255.224 & /27   \\ \hline
    255.240.0.0     & /12   &   255.255.255.240 & /28   \\ \hline
    255.248.0.0     & /13   &   255.255.255.248 & /29   \\ \hline
    255.252.0.0     & /14   &   255.255.255.252 & /30   \\ \hline
    255.254.0.0     & /15   &   255.255.255.254 & /31   \\ \hline
    255.255.0.0     & /16   &   255.255.255.255 & /32   \\ \hline
    \end{tabular}
\end{table}
\vspace{3mm}

Ainsi le réseau \emph{192.168.1.0 255.255.255.0} peut s'écrire plus simplement \emph{192.168.1.0/24}. Cette notation est notamment utilisée dans les objets \Colorbox{light-gray}{\lstinline{Address}} et \Colorbox{light-gray}{\lstinline{Route}}, pour l'attribut "network".

\newpage
\subsection{Le routage}
\label{subsec:network:ip:routing}

Pour qu'un n\oe{}ud d'un sous réseau soit capable de communiquer avec un n\oe{}ud se trouvant dans un autre, il faut que le paquet soit \emph{routé} du sous réseau source vers celui de destination. Cette action est effectuée par des équipements qui s'appellent "router" et qui utilisent pour cela les tables de routage. Pour comprendre cela, il faut reprendre le schéma réseau de l'infrastructure de test.

\vspace{3mm}
\begin{figure}[H]
  \centering
  \includegraphics[width=\textwidth]{reseau_test}
  \caption{Schéma réseau de l'environnement de test}
\end{figure}
\vspace{3mm}

Dans ce contexte là, pour qu'une machine du réseau Client 1 puisse communiquer avec un serveur du réseau DC 1, le paquet devra être routé par le router R1 ainsi que par le firewall FW1. Voici à quoi ressemble la table de routage du router R1.

\vspace{3mm}
\begin{table}[H]
    \centering
    \caption{Table de routage R1}
    \label{net-tab-routing}
    \begin{tabular}{|l|l|l|l|c|l|}
    \hline
    \textbf{Type} & \textbf{Réseau} & \textbf{AD} & \textbf{Metric} & \textbf{Next-Hop} & \textbf{Interface} \\ \hline
    OSPF      & 0.0.0.0/0       & 110 & 1   & 172.16.255.30 & Vlan28    \\ \hline
    OSPF      & 10.0.1.0/24     & 110 & 10  & 172.16.255.22 & Vlan20    \\ \hline
    OSPF      & 10.0.2.0/24     & 110 & 10  & 172.16.255.14 & Vlan12    \\ \hline
    Connected & 192.168.1.0/24  & 0   & 0   & -             & Vlan100   \\ \hline
    Connected & 192.168.1.1/32  & 0   & 0   & -             & Vlan100   \\ \hline
    OSPF      & 192.168.2.0/24  & 110 & 3   & 172.16.255.14 & Vlan12    \\ \hline
    \end{tabular}
\end{table}
\vspace{3mm}

Chaque entrée dans une table de routage indique un réseau (au format \acrshort{cidr}) et quel est le router suivant à qui envoyer le paquet afin de s'y rendre. En plus de cela, il existe des données supplémentaires qui permettent de déterminer quel est le meilleur chemin possible lorsque plusieurs route sont possibles. Dans le contexte de cette application, la table de routage correspond à la classe \Colorbox{light-gray}{\lstinline{RoutingTable}} (section \ref{sec:classe:routingtable}) et une route à la classe \Colorbox{light-gray}{\lstinline{Route}} (section \ref{sec:classe:route}).

Dans les réseaux informatiques, les routers ont très souvent plusieurs liens vers d'autres routers afin d'assurer de la redondance en cas de perte de liens. Pour être capable de définir quel est le meilleur chemin possible, le router commence par déterminer quel est la route la plus précise. Admettons que l'on souhaite envoyer un paquet vers l'adresse 192.168.0.10, si on reprend la table de routage précédente, on peut voir qu'il existe une route vers le réseau 192.168.0.0/16 via le router 10.0.0.1 et une autre route pour le réseau 192.168.0.0/24 via le router 10.0.1.1. Ces deux routes sont valables pour l'adresse 192.168.0.10, mais la seconde route est plus précise dans le sens où le réseau de la route est plus petit. Au niveau du code, l'algorithme du choix de la route est fait avec la méthode \Colorbox{light-gray}{\lstinline{choosed\_route}}.

Les routes peuvent avoir plusieurs types qui définissent une caractéristique propre aux routes qui s'appelle l'\emph{Administrative Distance}. Cet attribut définit la priorité d'un protocole sur un autre. Plus la valeur est basse, plus le type est prioritaire. Une route directement connectée (par exemple une adresse IP définie sur une interface du router), sera forcément prioritaire sur une route apprise par un quelconque protocole. Les routes moins prioritaires ne se voient pas dans la table de routage et il n'y a donc pas besoin de gérer cette partie là. Si deux routes ont la même \acrshort{ad}, c'est l'attribut \emph{Metric} qui sera utilisé pour évalué laquelle est la plus pertinente. Le calcul du metric et différent en fonction du protocole de routage utilisé, il s'agit souvent d'algorithmes assez complexes dont la compréhension n'est pas nécessaire dans le cadre du projet.

La dernière caractéristique importante d'une route est son interface de sortie. C'est le port physique de l'équipement que le paquet va utiliser pour rejoindre le prochain router. Cette information est notamment utilisée par la méthode \Colorbox{light-gray}{\lstinline{crossed?}} (section \ref{sec:methodes:crossed}) afin de savoir si un flux va traverser le router. La logique utilisée dans ce cas découle directement de cet attribut, car un flux est définit par un réseau source et destination. Si l'interface de sortie pour ces deux réseaux est la même, cela signifie que l'équipement réseau ne sera jamais traversé par ce flux.

\newpage
\section{Couche 4 - Transport}

\subsection{TCP \& UDP}

Si la couche trois définit l'adressage logique qui fournit les outils pour acheminer les paquets dans un réseau, la couche quatre va permettre de définir comment ces communications sont gérées par les n\oe{}uds. Il existe plusieurs protocoles de transport différent mais en pratique, \acrshort{tcp} et \acrshort{udp} sont ceux qui sont le plus utilisés dans les réseaux internes d'entreprise. Ces deux protocoles ont comme point commun le fait d'utiliser un numéro de port pour identifier leurs communications. De la même façon qu'il y a une adresse IP source et destination, il y a aussi un port source et destination. Le port de destination est utilisé par le n\oe{}ud de destination pour savoir quel processus doit traiter cette requête. Le numéro de port est codé sur 16bits et bien que n'importe quel programme peut utiliser un port, les 1024 premiers sont considérés comme "well-known" et sont identifiés\cite{wellknownports} par l'\acrshort{iana}. Par exemple, le protocol HTTP utilisé pour les applications web utilisent le port 80 et sa version chiffrée, le HTTPS, le 443. Ces éléments s'appellent des services et correspondent dans cette application à la classe \Colorbox{light-gray}{\lstinline{Service}} (section \ref{sec:classe:service}) qui sont composés d'une liste de port \acrshort{tcp} et \acrshort{udp} qui sont représentés par la classe \Colorbox{light-gray}{\lstinline{PortRange}}.

Lorsqu'un n\oe{}ud "client" ouvre une connexion vers un n\oe{}ud "serveur", il va utiliser un port source aléatoire géré par le système d'exploitation et le port de destination est définis par le programme utilisé. 

\vspace{3mm}
\begin{figure}[H]
    \centering
    \includegraphics[width=100mm]{echanges_http}
    \caption{Requête HTTP}
\end{figure}
\vspace{3mm}

\newpage
\subsection{Firewall}
\label{subsec:network:ip:firewall}

Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des routers qui sont également capable de gérer les protocoles de la couche quatre. Ils sont utilisés pour filtrer les communications entre les réseaux en filtrant les échanges basé sur les ports destinations. Ces équipements de sécurité permettent donc de n'autoriser que les paquets à destination d'un n\oe{}ud spécifique et sur un ou plusieurs ports. Ces filtres sont représentés par des règles de sécurité qui correspondent ici à la classe \Colorbox{light-gray}{\lstinline|Policy|}.

\begin{table}[H]
    \centering
    \caption{Exemples de règles de sécurité}
    \label{rules-tab}
    \begin{tabular}{|l|l|l|l|l|l|l|}
        \hline
        \small{\textbf{Id}} &\small{\textbf{Int. source}} &\small{\textbf{Int. destination}} &\small{\textbf{Source}} &\small{\textbf{Destination}} &\small{\textbf{Service}} &\small{\textbf{Action}}   \\ \hline
        1 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.1/32}    & \small{tcp/22}           & \cellcolor[HTML]{FE0000}\small{Deny}     \\ \hline
        2 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.2/32}    & \small{tcp/80, tcp/443}  & \cellcolor[HTML]{009901}\small{Accept}   \\ \hline
        3 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.0/24}    & \small{tcp/3389}         & \cellcolor[HTML]{009901}\small{Accept}   \\ \hline
        4 & \small{server} & \small{client} & \small{10.0.1.2/24}    & \small{192.168.1.0/24} & \small{any}              & \cellcolor[HTML]{009901}\small{Accept}   \\ \hline
        5 & \small{server} & \small{client} & \small{10.0.1.2/24}    & \small{0.0.0.0/0}      & \small{any}              & \cellcolor[HTML]{FE0000}\small{Deny}     \\ \hline
    \end{tabular}
\end{table}

Les polices de sécurité sont analysées et évaluées de façon séquentielle, dès que les critères d'une règles sont tous respectés, l'action est effectuée. Par exemple, si un poste de travail avec une adresse IP 192.168.1.57 essaie de se connecter en HTTPS (port TCP/443) sur le serveur 10.0.1.2, sa requête va passé au travers du firewall qui va analyser le flux pour définir s'il doit être accepté ou non, en utilisant la liste de règles du tableau \refname{rules-tab} et en admettant que le réseau 192.168.1.0/24 est bien connu par l'interface "client" et le réseau 10.0.1.0/24 par l'interface "server".

La première règle décrit bien un flux provenant de l'interface "client" vers "server", la source est le réseau "192.168.1.0/24" dans lequel l'adresse IP source "192.168.1.57" se trouve, cependant la destination indique un réseau "10.0.1.1/32" qui ne correspond pas à notre serveur "10.0.1.2". Les conditions n'étant pas toutes validées, le firewall va passer à la seconde règle et recommencer la même analyse. Dans la seconde règle, la destination est "10.0.1.2/32" qui est bien la destination du flux analysé, il ne reste donc que le service à valider. Notre communication utilise le port de destination tcp/443 qui est bien dans la liste de la règle. Les conditions étant toutes validées, l'action est appliquée, ce qui correspond dans ce cas à laisser le flux passer. Ce processus est ainsi répété pour chaque nouvelle connexion passant au travers du firewall.
