dainii/heig-rapport-tb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Corrections diverses

Browse Source
This commit is contained in:
Etienne Ischer
2018-09-21 17:33:52 +02:00
parent c16079f60e
commit 61109bf65f
10 changed files with 42 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
chapitres/introduction/introduction.tex
View File

@@ -2,9 +2,9 @@
\section{Le CHUV}
Le \gls{chuv} emploie environ 11'000 personnes\cite{rapportActiviteChuv} dans des domaines divers et variés. Les trois missions qui lui sont confiées par l'État sont; les soins, la recherche et la formation. Chacune de ces entités a des besoins différents que ce soit d'un point de vue logistique, d'infrastructure ou d'informatique. Ce dernier est celui qui va évidemment nous intéresser le plus dans le cadre de ce travail de Bachelor et pour commencer dans cette pré-étude.
Le \gls{chuv} emploie environ 11'000 personnes\cite{rapportActiviteChuv} dans des domaines divers et variés. Les trois missions qui lui sont confiées par l'État sont; les soins, la recherche et la formation. Chacune de ces entités a des besoins différents que ce soit d'un point de vue logistique, d'infrastructure ou d'informatique. Ce dernier est celui qui va évidemment nous intéresser le plus dans le cadre de ce travail de Bachelor.
Le profil des utilisateurs du système d'information sont bien différents et le niveau de confidentialité des données l'est aussi. Dans le milieu académique, les étudiants travaillent avec leur propre matériel et ne sont pas des employés du \acrshort{chuv}. A l'inverse, dans le secteur hospitalier, les équipements informatiques sont tous gérés et administrés en interne. De plus, les informations échangées sont par exemple des dossiers de patients dont la confidentialité doit être assurée. Pour pouvoir y arriver, l'équipe en charge de l'infrastructure réseau et de la sécurité (équipe dont je fais partie) a mis en place de la segmentation pour maintenir le meilleur niveau de sécurité possible entre les différents environnements de travail.
Le profil des utilisateurs du système d'information sont bien différents et le niveau de confidentialité des données l'est aussi. Dans le milieu académique, les étudiants travaillent avec leur propre matériel et ne sont pas des employés du \acrshort{chuv}. A l'inverse, dans le secteur hospitalier, les équipements informatiques sont tous gérés et administrés en interne. De plus, les informations échangées sont par exemple des dossiers de patients dont la confidentialité doit être assurée. Pour pouvoir y arriver, l'équipe en charge de l'infrastructure réseau et de la sécurité (dont je fais partie) a mis en place de la segmentation pour maintenir le meilleur niveau de sécurité possible entre les différents environnements de travail.
\section{La problématique}
@@ -14,11 +14,11 @@ Lorsqu'une nouvelle application doit être mise en production, l'équipe réseau
\section{L'analyse du besoin}
Pour définir précisément les besoins du projet, une série de cas d'utilisation ont été rédigées avec l'équipe qui sera amener à l'utiliser. Toutes ces \emph{User Stories} ont été formalisées et sont décrites dans la pré-étude de ce projet dans la partie 2 "Analyses et planification". Elles ont été ensuite priorisée par la personne responsable de l'équipe qui est également le mandant de ce projet. Il a été convenu qu'une séance de revue sur l'avancement du projet soit faite toutes les deux semaines tout au long de la durée de la réalisation du projet. Les détails sur le déroulement du projet se trouvent au chapitre "Dossier de gestion".
Pour définir précisément les besoins du projet, une série de cas d'utilisation a été rédigé avec l'équipe qui sera amené à l'utiliser. Toutes ces \emph{User Stories} ont été formalisées et sont décrites dans la pré-étude de ce projet dans la partie 2 "Analyses et planification". Elles ont été ensuite priorisée par la personne responsable de l'équipe qui est également le mandant de ce projet. Il a été convenu qu'une séance de revue sur l'avancement du projet soit faite toutes les deux semaines tout au long de la durée de la réalisation du projet. Les détails sur le déroulement du projet se trouvent au chapitre "Dossier de gestion".
\section{Découpage du projet}
La réalisation de ce projet est découpée en plusieurs sous-projets différents qui correspondent à une partie de développement spécifique. Ce découpage permet notamment de tester ces différentes parties de façon indépendantes les unes des autres et d'être gérés dans des dépôts Git différents. Ce découpage correspond également à la structure des dossiers dans le CD annexe qui contient les codes sources.
La réalisation de ce projet est découpée en plusieurs sous-projets distincts qui correspondent à une partie de développement spécifique. Ce découpage permet notamment de tester ces différentes parties de façon indépendantes les unes des autres et d'être gérés dans des dépôts Git isolé. Ce découpage correspond également à la structure des dossiers dans le CD annexe qui contient les codes sources.
\begin{itemize}
\item \textbf{backend:} Projet principal de l'application, c'est là qu'est écrit la partie métier du projet.
@@ -27,6 +27,6 @@ La réalisation de ce projet est découpée en plusieurs sous-projets différent
\item \textbf{paltogem:} Module d'extension pour faire des requêtes sur les équipements PaloAlto$^{\mbox{\scriptsize{\textregistered}}}$
\end{itemize}
\section{Acronymes et définition}
\section{Acronymes et définitions}
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.

18
chapitres/introduction/network.tex
View File

@@ -6,9 +6,9 @@ Pour être en mesure de comprendre le fonctionnement de l'analyse des règles de
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.
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 n\oe{}ud indépendamment 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 \acrshort{vlan}), ce qui permet d'établir 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 sont 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}.
@@ -137,11 +137,11 @@ Dans ce contexte là, pour qu'une machine du réseau Client 1 puisse communiquer
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 10.0.1.10, si on reprend la table de routage précédente, on peut voir qu'il existe une route vers le réseau 0.0.0.0/0 via le router 172.16.255.30 et une autre route pour le réseau 10.0.1.0/24 via le router 172.16.255.22. Ces deux routes sont valables pour l'adresse 10.0.1.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 quelle est la route la plus précise. Admettons que l'on souhaite envoyer un paquet vers l'adresse 10.0.1.10, si on reprend la table de routage précédente, on peut voir qu'il existe une route vers le réseau 0.0.0.0/0 via le router 172.16.255.30 et une autre route pour le réseau 10.0.1.0/24 via le router 172.16.255.22. Ces deux routes sont valables pour l'adresse 10.0.1.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}} de l'objet \Colorbox{light-gray}{\lstinline{RoutingTable}}.
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.
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 un 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.
La dernière caractéristique importante d'une route est son interface de sortie. C'est le port logique 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}
@@ -150,7 +150,7 @@ La dernière caractéristique importante d'une route est son interface de sortie
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éfini par le programme utilisé.
\vspace{3mm}
\begin{figure}[H]
@@ -164,12 +164,12 @@ Lorsqu'un n\oe{}ud "client" ouvre une connexion vers un n\oe{}ud "serveur", il v
\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|}.
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 analysant les échanges basé sur leurs ports de 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}
\label{sec: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
@@ -181,6 +181,6 @@ Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des
\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".
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ègle 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{sec: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.