relecture reseau, intro et technique

This commit is contained in:
2018-09-18 17:33:29 +02:00
parent e151a01e11
commit c7c2f8ce2c
8 changed files with 56 additions and 33 deletions

BIN
.DS_Store vendored

Binary file not shown.

View File

@@ -22,6 +22,8 @@
\newacronym{ad}{AD}{Administrative Distance} \newacronym{ad}{AD}{Administrative Distance}
\newacronym{mac}{MAC}{Media Access Control} \newacronym{mac}{MAC}{Media Access Control}
\newacronym{vlan}{VLAN}{Virtual Local Area Network} \newacronym{vlan}{VLAN}{Virtual Local Area Network}
\newacronym{iso}{ISO}{Organisation Internationale de Normalisation}
\newacronym{iana}{IANA}{Internet Assigned Numbers Authority}
\newglossaryentry{firewall}{ \newglossaryentry{firewall}{
name=firewall, name=firewall,

View File

@@ -26,3 +26,7 @@ La réalisation de ce projet est découpée en plusieurs sous-projets différent
\item \textbf{fortigem:} Module d'extension pour faire des requêtes sur les équipements Fortinet$^{\mbox{\scriptsize{\textregistered}}}$ \item \textbf{fortigem:} Module d'extension pour faire des requêtes sur les équipements Fortinet$^{\mbox{\scriptsize{\textregistered}}}$
\item \textbf{paltogem:} Module d'extension pour faire des requêtes sur les équipements PaloAlto$^{\mbox{\scriptsize{\textregistered}}}$ \item \textbf{paltogem:} Module d'extension pour faire des requêtes sur les équipements PaloAlto$^{\mbox{\scriptsize{\textregistered}}}$
\end{itemize} \end{itemize}
\section{Acronymes et définition}
Par expérience, le milieu des réseaux informatiques utilisent beaucoup d'acronymes. Il existe surtout beaucoup de standards et de protocoles qui font partie du vocabulaire courant lorsqu'on parle d'infrastructure réseau. Pour améliorer la compréhension de ce rapport, un glossaire de définitions et d'acronymes se trouvent à la fin de ce rapport.

View File

@@ -4,9 +4,9 @@
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. 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 arriver à destination. 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 \gls{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. 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. 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.
@@ -15,28 +15,36 @@ Cette construction en couche superposée est standardisée par une structure con
\newpage \newpage
\section{Le modèle OSI} \section{Le modèle OSI}
Le modèle \gls{osi} est un découpage en sept couches, représentant les différents acteurs nécessaires à l'échange et la compréhension de l'information. 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] \begin{figure}[h]
\centering \centering
\includegraphics[width=100mm]{OSI_Model_v1.png} \includegraphics[width=100mm]{OSI_Model_v1.png}
\caption{Le modèle OSI} \caption{Le modèle OSI}
\end{figure} \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|}). 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}. Ces protocoles se voient notamment dans le modèle \Colorbox{light-gray}{\lstinline|Service|}. 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 \newpage
\section{Couche 3 - les réseaux IP} \section{Couche 3 - les réseaux IP}
\subsection{IPv4} \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 un AND logique des 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 \refname{sec:classe:address} (section \ref{sec:classe:address}). 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}).
Exemple tableau binaires et tout. \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 32bits, si décide d'utiliser un masque de 24 bits (255.255.255.0), il va rester 8bits 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". 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} \vspace{3mm}
\begin{table}[H] \begin{table}[H]
@@ -46,7 +54,7 @@ La longueur du masque va définir la taille du réseau et donc le nombre d'adres
\begin{tabular}{|l|l|l|l|l|} \begin{tabular}{|l|l|l|l|l|}
\hline \hline
& & \multicolumn{3}{c|}{\textbf{Adresses IPv4}} \\ \cline{3-5} & & \multicolumn{3}{c|}{\textbf{Adresses IPv4}} \\ \cline{3-5}
\multirow{-2}{*}{\textbf{Réseau}} & \multirow{-2}{*}{\textbf{Masque}} & Première & Dernière & Nombre disponible \\ \hline \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 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 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 192.168.1.0 & 255.255.255.0 & 192.168.1.1 & 192.168.1.254 & $2^8 - 2 = 254$ \\ \hline
@@ -55,16 +63,12 @@ La longueur du masque va définir la taille du réseau et donc le nombre d'adres
\end{table} \end{table}
\vspace{3mm} \vspace{3mm}
Dans le cadre de cette application, cela est important pour comprendre comment fonctionne la méthode \Colorbox{light-gray}{\lstinline|match?|} de la classe \Colorbox{light-gray}{\lstinline|Address|}. Pour savoir si une adresse se trouve dans un réseau donné, on applique donc un "AND" logique avec l'adresse et son masque. Si les bits restant correspondent à ceux du réseau, c'est qu'il en fait partie. 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.
Petit schéma de comparaison.
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'appellent 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} \subsection{CIDR}
\label{subsec:network:ip:cidr} \label{subsec:network:ip:cidr}
La notation 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. 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} \vspace{3mm}
\begin{table}[H] \begin{table}[H]
@@ -97,18 +101,21 @@ La notation CIDR est beaucoup utilisée dans cette application, il s'agit d'une
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". 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} \subsection{Le routage}
\label{subsec:network:ip:routing} \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. 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.
\begin{figure}[h] \vspace{3mm}
\begin{figure}[H]
\centering \centering
\includegraphics[width=\textwidth]{reseau_test} \includegraphics[width=\textwidth]{reseau_test}
\caption{Schéma réseau de l'environnement de test} \caption{Schéma réseau de l'environnement de test}
\end{figure} \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. 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} \vspace{3mm}
\begin{table}[H] \begin{table}[H]
@@ -128,32 +135,36 @@ Dans ce contexte là, pour qu'une machine du réseau Client\_1 puisse communique
\end{table} \end{table}
\vspace{3mm} \vspace{3mm}
Chaque entrée dans une table de routage indique un réseau (au format \refname{subsec:network:ip: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}). 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 routeurs 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}}. 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éristiques 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ées (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. 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 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. 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.
Les routes peuvent avoir plusieurs types qui définissent une caractéristiques 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ées (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à.
La dernière caractéristique importante d'une route est son interface de sortie. C'est le port que le paquet va utiliser pour rejoindre le prochain router. Cette information est notamment utilisée par la méthode \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} \section{Couche 4 - Transport}
\subsection{TCP \& UDP} \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, TCP et UDP sont ceux qui sont le plus utilisé 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 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 TCP et UDP qui sont représentés par la classe \Colorbox{light-gray}{\lstinline{PortRange}}. 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é. 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é.
schéma ouverture de connexion. \vspace{3mm}
\begin{figure}[H]
\centering
\includegraphics[width=100mm]{echanges_http}
\caption{Requête HTTP}
\end{figure}
\vspace{3mm}
\newpage
\subsection{Firewall} \subsection{Firewall}
\label{subsec:network:ip:firewall} \label{subsec:network:ip:firewall}
Les firewall 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}}. 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] \begin{table}[H]
\centering \centering

View File

@@ -4,15 +4,21 @@
L'application est construite selon une architecture trois tiers qui va séparer la partie interface utilisateur de la partie traitement et des données. La couche de présentation sera appelée par la suite \emph{frontend} et celle de traitement \emph{backend}. Pour échanger des informations entre eux, ces tiers doivent utiliser des protocoles et un formatage précis. L'application est construite selon une architecture trois tiers qui va séparer la partie interface utilisateur de la partie traitement et des données. La couche de présentation sera appelée par la suite \emph{frontend} et celle de traitement \emph{backend}. Pour échanger des informations entre eux, ces tiers doivent utiliser des protocoles et un formatage précis.
Schéma architecture \vspace{3mm}
\begin{figure}[h]
\centering
\includegraphics[width=150mm]{application_architecture}
\caption{Architecture de l'application}
\end{figure}
\vspace{3mm}
La communication entre le frontend et le backend se fait au travers d'un API \gls{restful} basé sur des échanges HTTP. Son implémentation du coté backend est assuré par le framework RubyOnRails et du coté frontend par EmberJS. Pour se comprendre, ces deux librairies respectent le même standard pour sérialiser l'information. Il s'agit de la spécification json:api\cite{jsonapi} dont l'implémentation coté backend est faite grâce au module ActiveModelSerializer\cite{activemodelserializer} et du coté frontend par la classe DS.JSONApiSerializer\cite{dsjsonapiserializer}. Cette convention décrit un ensemble de règles qui définissent comment les informations doivent être mises en forme dans une API qui utilise le JSON comme format de donnée. Cette structure force donc le développeur à structurer correctement les données et est une mise en application supplémentaire du paradigme "Convention plutôt que configuration". La communication entre le frontend et le backend se fait au travers d'un API \gls{restful} basé sur des échanges HTTP. Son implémentation du coté backend est assuré par le framework RubyOnRails\cite{railssite} et du coté frontend par EmberJS\cite{emberjssite}. Pour se comprendre, ces deux librairies respectent le même standard pour sérialiser l'information. Il s'agit de la spécification \emph{json api}\cite{jsonapi} dont l'implémentation coté backend est faite grâce au module ActiveModelSerializer\cite{activemodelserializer} et du coté frontend par la classe DS.JSONApiSerializer\cite{dsjsonapiserializer}. Cette convention décrit un ensemble de règles qui définissent comment les informations doivent être mises en forme dans une API qui utilise le JSON comme format de donnée. Cette structure force donc le développeur à structurer correctement les données et est une mise en application supplémentaire du paradigme "Convention plutôt que configuration".
Les échanges entre le backend et MongoDB sont assurés par le module Mongoid\cite{mongoid}. Cette extension applique le \emph{Data mapper pattern} en gérant la correspondance entre les objets définit en Ruby et les collections d'objets de la base de donnée. Elle va également fournir les méthodes pour interagir avec ces collections, comme par exemple les requêtes de recherche sur les objets. Les échanges entre le backend et MongoDB sont assurés par le module Mongoid\cite{mongoid}. Cette extension applique le \emph{Data mapper pattern} en gérant la correspondance entre les objets définit en Ruby et les collections d'objets de la base de donnée. Elle va également fournir les méthodes pour interagir avec ces collections, comme par exemple les requêtes de recherche sur les objets.
\section{Technologies et versions} \section{Technologies et versions}
L'ensemble de la solution utilisent différentes technologies qui doivent toutes être supportées pour assurer son bon fonctionnement. Les programmes principaux sont listés dans le tableau ci-dessous: L'ensemble de la solution utilisent différentes technologies qui doivent toutes être supportées pour assurer son bon fonctionnement. Les programmes principaux sont listés dans le tableau ci-dessous:
\vspace{3mm} \vspace{3mm}
\begin{table}[H] \begin{table}[H]
@@ -26,10 +32,10 @@ L'ensemble de la solution utilisent différentes technologies qui doivent toutes
Bundler & 1.16.1 & Gestionnaire de dépendances pour Ruby \\ \hline Bundler & 1.16.1 & Gestionnaire de dépendances pour Ruby \\ \hline
Rails & 5.1.6 & Framework pour l'application backend \\ \hline Rails & 5.1.6 & Framework pour l'application backend \\ \hline
NodeJS & 8.1 & Moteur pour application Javascript \\ \hline NodeJS & 8.1 & Moteur pour application Javascript \\ \hline
NPM & ? & Gestionnaire de dépendance de NodeJS \\ \hline NPM & 6.2.0 & Gestionnaire de dépendance de NodeJS \\ \hline
Ember-CLI & 3.3.0 & Framework pour l'application frontend \\ \hline Ember-CLI & 3.3.0 & Framework pour l'application frontend \\ \hline
MongoDB & ? & Système de base de donnée non-relationnel \\ \hline MongoDB & 4.0.2 & Système de base de donnée non-relationnel \\ \hline
Redis & ? & Base de donnée en mémoire \\ \hline Redis & 4.0.11 & Base de donnée en mémoire \\ \hline
\end{tabular} \end{tabular}
\end{table} \end{table}
\vspace{3mm} \vspace{3mm}

Binary file not shown.

After

Width:  |  Height:  |  Size: 67 KiB

BIN
images/comparaison_binaire.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

BIN
images/echanges_http.png Executable file

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.7 KiB