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

relecture et finition partie 1 et 2

Browse Source
This commit is contained in:
Etienne Ischer
2018-09-19 16:28:43 +02:00
parent c7c2f8ce2c
commit 651b4f8fc3
15 changed files with 330 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
chapitres/introduction/network.tex
View File

@@ -55,8 +55,8 @@ La longueur du masque va définir la taille du réseau et donc le nombre d'adres
\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
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}

121
chapitres/model/application.tex Normal file
View File

@@ -0,0 +1,121 @@
\chapter{Analyses applicatives}
\section{Backend API}
L'\acrshort{api} de l'application permet d'intéragir avec les différents composants de l'application. Il permet notamment d'ajouter et de gérer les équipements (\Colorbox{light-gray}{\lstinline|Device|}), les identifiants (\Colorbox{light-gray}{\lstinline|Credential|}), les taches de récupération (\Colorbox{light-gray}{\lstinline|Task|}) ainsi que les recherches. Les détails de ces requêtes sont documentées ci-après.
\subsection{Credential}
L'ensemble des actions \gls{crud} sont disponibles pour l'objet \Colorbox{light-gray}{\lstinline|Credential|}.
\vspace{3mm}
\begin{table}[H]
\centering
\caption{Actions possibles pour l'objet Credential}
\label{api-credential-crud}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Opération} & \textbf{Méthode HTTP} & \textbf{URI} \\ \hline
Création & POST & /api/credentials \\ \hline
Récupération (Toute la collection) & GET & /api/credentials \\ \hline
Récupération (Unique) & GET & /api/credentials/\textit{credential\_id} \\ \hline
Modification & PATCH/PUT & /api/credentials/\textit{credential\_id} \\ \hline
Suppression & DELETE & /api/credentials/\textit{credential\_id} \\ \hline
\end{tabular}
\end{table}
\vspace{3mm}
\subsection{Device}
L'ensemble des actions \gls{crud} sont disponibles pour l'objet \Colorbox{light-gray}{\lstinline|Device|}.
\vspace{3mm}
\begin{table}[H]
\centering
\caption{Actions possibles pour l'objet Device}
\label{api-device-crud}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Opération} & \textbf{Méthode HTTP} & \textbf{URI} \\ \hline
Création & POST & /api/devices \\ \hline
Récupération (Toute la collection) & GET & /api/devices \\ \hline
Récupération (Unique) & GET & /api/devices/\textit{device\_id} \\ \hline
Modification & PATCH/PUT & /api/devices/\textit{device\_id} \\ \hline
Suppression & DELETE & /api/devices/\textit{device\_id} \\ \hline
\end{tabular}
\end{table}
\vspace{3mm}
\subsection{Task}
La version actuelle de l'API permet uniquement de créer une nouvelle tache de récupération en précisant l'identifiant du \Colorbox{light-gray}{\lstinline|Device|} voulu.
\vspace{3mm}
\begin{table}[H]
\centering
\caption{Actions possibles pour l'objet Task}
\label{api-task-crud}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Opération} & \textbf{Méthode HTTP} & \textbf{URI} \\ \hline
Création & POST & /api/devices/\textit{device\_id}/tasks \\ \hline
\end{tabular}
\end{table}
\vspace{3mm}
\subsection{Search}
Les actions de recherches sont gérées pas le controller 'search'. La seule fonctions disponible est la recherches de règles de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}). Les filtres de la requêtes sont passées en paramètre de la requête.
\vspace{3mm}
\begin{table}[H]
\centering
\caption{Actions de recherches possibles}
\label{api-search-crud}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Opération} & \textbf{Méthode HTTP} & \textbf{URI} \\ \hline
Recherche de règles & GET & /api/search/policies \\ \hline
\end{tabular}
\end{table}
\vspace{3mm}
\noindent
Exemple de requête de recherche (le caractère '/' est remplacé dans l'URL par '\%2F', car c'est un caractère spécial HTTP):
\noindent
\Colorbox{light-gray}{\small{http://backend/api/search/policies?destination\=10.0.1.0\%2F24\&port\=3389\&protocol\=tcp\&source\=10.0.2.0\%2F24}}
\newpage
\section{Interface utilisateur}
L'interface utilisateur se présente sous la forme d'une application WEB qui permet à l'utilisateur de faire des recherches via un formulaire et qui va mettre en forme les résultats obtenus. Les champs 'Source' et 'Destination' s'attendent à recevoir une adresse réseau au format \acrshort{cidr}, le champs 'Protocol' est une liste déroulante qui propose à choix 'TCP', 'UDP' ou 'ICMP'. Pour finir, le numéro de port doit être une valeur numérique comprise entre 1 et 65535.
\vspace{3mm}
\begin{figure}[H]
\centering
\includegraphics[width=160mm]{gui_search_form}
\caption{Formulaire de recherche WEB}
\end{figure}
\vspace{3mm}
Les réponses sont sous la forme de blocs dépliants dont la couleur indique si la règle autorise ou bloque le flux, le vert signale une règle d'ouverture (accept) et le rouge une règle de fermeture ('deny'). Chaque bloc représente un équipement de sécurité différent, si un seul de ces blocs est rouge, c'est que le flux n'est pas autorisé de bout en bout.
\vspace{3mm}
\begin{figure}[H]
\centering
\includegraphics[width=160mm]{gui_policies_collapsed}
\caption{Résultat visuel d'une recherche de règle}
\end{figure}
\vspace{5mm}
En cliquant sur le bloc, on peut lire les détails de la règle en question. En cliquant à nouveau dessus, le bloc se referme.
\vspace{3mm}
\begin{figure}[H]
\centering
\includegraphics[width=160mm]{gui_policy}
\caption{Détail d'une règle}
\end{figure}
\vspace{3mm}

88
chapitres/model/classes.tex
View File

@@ -2,15 +2,17 @@
\section{Diagramme de classe}
Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \lstinline{Device}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \lstinline{Address} doit être unique, mais uniquement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \lstinline{Device} contient les autres objets qui lui sont associés.
Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \Colorbox{light-gray}{\lstinline|Device|}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \Colorbox{light-gray}{\lstinline|Address|} doit être unique, mais uniquement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \lstinline|Device| contient les autres objets qui lui sont associés.
\vspace{3mm}
\begin{figure}[h]
\centering
\includegraphics[width=80mm]{mongodb_device}
\caption{Extrait de la collection Device}
\end{figure}
\vspace{3mm}
Cette structure est possible pour les objets qui n'ont de sens que dans le contexte d'un équipement spécifique, ce qui n'est pas le cas de tous. C'est notamment le cas de la classe \lstinline{Credential}, qui sauvegarde dans la base les identifiants nécessaires pour authentifier les requêtes sur les API des équipements. Ces informations peuvent être liées à plusieurs équipements différents et doivent donc être stockées dans une collection séparée.
Cette structure est possible pour les objets qui n'ont de sens que dans le contexte d'un équipement spécifique, ce qui n'est pas le cas de tous. C'est notamment le cas de la classe \Colorbox{light-gray}{\lstinline|Credential|}, qui sauvegarde dans la base les identifiants nécessaires pour authentifier les requêtes sur les API des équipements. Ces informations peuvent être liées à plusieurs équipements différents et doivent donc être stockées dans une collection séparée.
\begin{figure}[H]
\centering
@@ -24,6 +26,7 @@ Cette structure est possible pour les objets qui n'ont de sens que dans le conte
Cette classe est utilisée pour sauvegarder les informations d'identifications pour accéder aux équipements et est identifiable par un nom unique. Le mot de passe est enregistré dans la base de donnée de façon chiffrée, mais avec un chiffrement symétrique, car il est nécessaire de pouvoir le réutiliser pour s'authentifier par la suite sur les équipements. Les fonctions pour chiffrer et déchiffrer le mot de passe sont fournit par l'attribut "password".
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/credential.rb"]
# Returns the decrypted value of the 'encrypted_password' field
def password
@@ -39,61 +42,104 @@ Cette classe est utilisée pour sauvegarder les informations d'identifications p
self.encrypted_password = @password
end
\end{lstlisting}
\vspace{3mm}
Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le module "Symmetric\-Encryption"\cite{symmetricencryption}. Ce dernier utilise un système de clés pour cela qui sont définies dans le fichier "backend/config/symmetric-encryption.yml". Ce fichier est volontairement exclu de Git afin que les clés ne se retrouve pas dans le dépot. Lors du premier développement, il faut générer un jeu de clés avec la commande précisée dans le "README.md" du projet. En production, le fichier doit être généré sur le serveur et utilise des mécanismes plus avancés pour assurer un meilleur niveau de chiffrement.
\newpage
\subsection{Address}
\label{sec:classe:address}
Il s'agit d'un élément d'une règle de sécurité (\lstinline{Policy}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexé par la base de donnée. Ainsi \lstinline{start_ip} est la représentation numérique de la première adresse IP de ce réseau, et \lstinline{end_ip} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits (cité la doc réseau au début)), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network.
Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexé par la base de donnée. Ainsi \Colorbox{light-gray}{\lstinline|start_ip|} est la représentation numérique de la première adresse IP de ce réseau, et \Colorbox{light-gray}{\lstinline|end_ip|} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits (cité la doc réseau au début)), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
# Exemples:
# Exemples:
#
# address = Address.new
# address.name = 'unique name' # => true
# address.network = '192.168.0.0/24' # => true
# address.start_ip # => 3232235520
# address.end_ip # => 3232235775
address = Address.new
address.name = 'unique name' # => true
address.network = '192.168.0.0/24' # => true
address.start_ip # => 3232235520
address.end_ip # => 3232235775
\end{lstlisting}
\vspace{3mm}
Cette classe fournit également la méthode match? (section ) qui permet de savoir si un réseau exprimé au format \acrshort{cidr} est contenu dans l'objet en question. Pour cela, il suffit de vérifier que les adresses limites du réseau en paramètre soient comprises dans l'objet en question.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
def match?(network)
ip = IPAddr.new network
start_ip = ip.to_range.first.to_i
end_ip = ip.to_range.last.to_i
((start_ip >= self.start_ip) && (end_ip <= self.end_ip))
end
\end{lstlisting}
\subsection{AddressGroup}
Un groupe d'adresse est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \lstinline{Address} qu'il contient.
Un groupe d'adresse est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Address|} qu'il contient.
\subsection{PortRange}
Un \lstinline{PortRange}, représente une plage de numéro de port et le protocol qui leur est associé. Il peut en plus également gérer une combinaison de code et type pour les communications ICMP. Il est contenu dans un \lstinline{Service}.
Un \Colorbox{light-gray}{\lstinline|PortRange|}, représente une plage de numéro de port et le protocol qui leur est associé. Il peut en plus également gérer une combinaison de code et type pour les communications ICMP. Il est contenu dans un \Colorbox{light-gray}{\lstinline|Service|}.
\subsection{Service}
\label{sec:classe:service}
Un service est un élément d'une règle de sécurité (\lstinline{Policy}) qui est composé d'un ensemble de port/protocol nécessaire au fonctionnement d'une application. Par exemple, un service qui autoriserait les flux web (HTTP/HTTPS) va autoriser les ports TCP 80 et 443. Pour cela, il aura donc deux \lstinline{PortRange} liés.
Un service est un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui est composé d'un ensemble de port/protocol nécessaire au fonctionnement d'une application. Par exemple, un service qui autoriserait les flux web (HTTP/HTTPS) va autoriser les ports TCP 80 et 443. Pour cela, il aura donc deux \Colorbox{light-gray}{\lstinline|PortRange|} liés.
Il fournit également la méthode 'match?' qui va retourner 'true' si l'ensemble port/protocol en paramètre est inclus dans les \lstinline{PortRange} liés.
Il fournit également la méthode 'match?' qui va retourner 'true' si l'ensemble port/protocol en paramètre est inclus dans les \Colorbox{light-gray}{\lstinline|PortRange|} liés.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/service.rb"]
def match?(protocol, port)
match = false
port_ranges.each do |port_range|
match = true if (protocol == port_range.protocol) &&
(port >= port_range.start_port) &&
(port <= port_range.end_port)
end
match
end
\end{lstlisting}
\subsection{ServiceGroup}
Un groupe de service est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \lstinline{Address} qu'il contient.
Un groupe de service est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Address|} qu'il contient.
\subsection{Zone}
Une zone représente un groupe d'interfaces réseaux dans un équipement. C'est surtout utilisé dans les règles de sécurité pour faciliter l'écriture de celle-ci.
\subsection{Route}
\label{sec:classe:route}
Correspond à une route dans une table de routage d'un équipement réseau. (pti cf qui va bien). Elle est notamment caractérisée par le réseau de destination, lui aussi donné avec une notation \acrshort{cidr}. Comme pour les adresses réseaux (\lstinline{Address}), la première et la dernière adresse IP du réseau sont converties en décimal pour être indexées dans la base de donnée. Chaque \lstinline{Route} est reliée a une table de routage (\lstinline{RoutingTable}).
Correspond à une route dans une table de routage d'un équipement réseau (comme décrit à la section \ref{subsec:network:ip:routing}). Elle est notamment caractérisée par le réseau de destination, lui aussi donné avec une notation \acrshort{cidr}. Comme pour les adresses réseaux (\Colorbox{light-gray}{\lstinline|Address|}), la première et la dernière adresse IP du réseau sont converties en décimal pour être indexées dans la base de donnée. Chaque \Colorbox{light-gray}{\lstinline|Route|} est reliée a une table de routage (\Colorbox{light-gray}{\lstinline|RoutingTable|}).
\subsection{RoutingTable}
\label{sec:classe:routingtable}
La table de routage est un élément des équipement réseau et est composé de routes.
Elle fournit la méthode 'crossed?' (\nameref{sec:methodes:crossed}) qui permet de savoir si un équipement (\lstinline{Device}) est traversé par un flux définit par un réseau source et de destination.
La table de routage est un élément des équipement réseaux et est composée de routes. Elle fournit la méthode 'crossed?' (section \ref{sec:methodes:crossed}) qui permet de savoir si un équipement (\Colorbox{light-gray}{\lstinline|Device|}) est traversé par un flux définit par un réseau source et de destination.
\newpage
\subsection{Policy}
Une policy représente un règle de sécurité dans un équipement réseau. Elle décrit comme ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'adresses (section \ref{sec:classe:address}-\nameref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représenté par le service (section \ref{sec:classe:service}-\nameref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée.
Une \Colorbox{light-gray}{\lstinline|Policy|} représente un règle de sécurité dans un équipement réseau. Elle décrit comment ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'\Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représenté par le \Colorbox{light-gray}{\lstinline|Service|} (section \ref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée.
La source et la destination sont deux champs qui peuvent contenir un ou plusieurs nom de \lstinline{Address} et/ou \lstinline{AddressGroup}. Le champ service peut être composé de un ou plusieurs nom de \lstinline{Service} et/ou \lstinline{ServiceGroup}. En plus de cela, la règle de sécurité peut contenir le ou les interfaces source et destination. Il s'agit de l'interface par lequel le flux doit arriver pour que la règle soit évaluée. Il se peut qu'une interface face partie d'un groupe d'interface qui s'appelle dans ce cas là, une zone.
La source et la destination sont deux champs qui peuvent contenir un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Address|} et/ou \Colorbox{light-gray}{\lstinline|AddressGroup|}. Le champ service peut être composé de un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Service|} et/ou \Colorbox{light-gray}{\lstinline|ServiceGroup|}. En plus de cela, la règle de sécurité peut contenir le ou les interfaces source et destination. Il s'agit de l'interface par lequel le flux doit arriver pour que la règle soit évaluée. Il se peut qu'une interface face partie d'un groupe d'interfaces qui s'appelle dans ce cas là, une \Colorbox{light-gray}{\lstinline|Zone|}.
Le dernier attribut d'une règle de sécurité est l'action à faire lorsqu'un flux correspond aux critères de la règle. Les deux seuls actions possibles sont "accept" ou "deny", qui vont respectivement laisser passer le flux, ou bien le bloquer.
\subsection{Device}
Les équipements de sécurité gérés dans l'application sont des objets de type \lstinline{Devices}. Il s'agit de la classe principale de l'application étant donné que la plupart des autres objets dépendent directement d'un équipement. Il fournit la méthode \nameref{sec:methodes:matched_policies} qui permet de mettre en place la feature principale de l'application, soit la recherche de règles de sécurité.
Les équipements de sécurité gérés dans l'application sont des objets de type \Colorbox{light-gray}{\lstinline|Device|}. Il s'agit de la classe principale de l'application étant donné que la plupart des autres objets dépendent directement d'un équipement. Il fournit la méthode \nameref{sec:methodes:matched_policies} qui permet de mettre en place la feature principale de l'application, soit la recherche de règles de sécurité.
\subsection{Task}
Afin que les informations de configurations des équipements puissent être récupérées régulièrement, cela se fait sous forme de tâche qui vont être exécuter de façon asynchrone par le module Sidekiq\cite{sidekiq}. Une fois une tache valide créée, l'application va l'ajouter en file d'attente pour qu'elle soit ensuite traitée par le programme d'exécution qui tourne en parallèle. Les différents files sont gérées avec le système de base de donnée en mémoire Redis\cite{redis}.
Il existe deux taches différentes, la \Colorbox{light-gray}{\lstinline|PolicyRetrievalJob|} et \Colorbox{light-gray}{\lstinline|RoutingTableRetrievalJob|}. La première va s'occuper de récupérer sur les équipements les polices de sécurité ainsi que les objets qui les composent. La seconde va obtenir l'état actuel de la table de routage de l'équipement pour mettre à la base. Ces deux tâches sont séparées afin de pouvoir les exécuter indépendament l'une de l'autre. En pratique, la table de routage d'un équipement peut évoluer sans intervention humaine, on souhaite donc pouvoir la mettre à jour plus fréquement que pour les règles de sécurité qui elles ne changent que lorsqu'une modification est faite.

6
chapitres/model/diagram.tex
View File

@@ -2,8 +2,12 @@
\section{Diagramme de séquence}
Le besoin initial de ce projet vient du fait que lorsqu'un flux n'est pas fonctionnel, l'exploitant doit parcourir à la main tous les équipements de sécurité pour découvrir si ce flux est autorisé. La mise en place de ce processus de recherche inclus un algorithme assez complexe qui va utiliser plusieurs classes différentes pour être capable de rendre une réponse proprement formattée.
Le diagramme de séquence suivant décrit donc le processus de recherche depuis la requête HTTP gérée par le controller jusqu'à la réponse. Les paramètres de la requête sont passés en attribut de la requête GET.
\begin{figure}[ht]
\centering
\includegraphics[width=145mm,height=\textheight,keepaspectratio]{tb_search_policies}
\caption{Diagram de séquence pour la recherche de règle}
\caption{Diagramme de séquence pour la recherche de règle}
\end{figure}

107
chapitres/model/methodes.tex
View File

@@ -2,9 +2,10 @@
\subsection{route}
La méthode "route" retourne la route (\lstinline{Route}), utilisée par l'équipement (\lstinline{Device}) pour atteindre le réseau spécifié.
La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|}), utilisée par l'équipement (\Colorbox{light-gray}{\lstinline|Device|}) pour atteindre le réseau spécifié. C'est une mise en application de ce qui est expliqué dans la section \ref{subsec:network:ip:routing}. Pour y arriver, il faut donc obtenir ceux dont les adresses limites du réseau comprennent celle du réseau voulu.
\begin{lstlisting}[language=Ruby]
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
# Params:
# * network: an IPv4 network to test
def route(network)
@@ -16,25 +17,103 @@ La méthode "route" retourne la route (\lstinline{Route}), utilisée par l'équi
choosed_route(candidate_routes)
end
\end{lstlisting}
\vspace{3mm}
Une fois les routes possibles obtenues, il faut encore isolé celle qui est la plus précise. Pour cela, il suffit de calculer le nombre d'adresses maximum disponibles dans le réseau et de choisir celui qui en a le moins.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
# Params:
# * candidate_routes: a list of Route
def choosed_route(candidate_routes)
network_length = 4_294_967_296
choose_route = nil
candidate_routes.each do |candidate|
network = IPAddr.new candidate.network
network_size = network.to_range.last.to_i - network.to_range.first.to_i
if network_size < network_length
network_length = network_size
choose_route = candidate
end
end
choose_route
end
\end{lstlisting}
\vspace{3mm}
\subsection{crossed?}
\label{sec:methodes:crossed}
La méthode "crossed?" est un élément essentiel pour l'analyse des règles de sécurité (\lstinline{Policy}). Elle permet de déterminer sur un équipement (\lstinline{Device}) est traversé par un flux définit par deux réseaux. Pour cela, il faut utiliser la méthode "route" de la table de routage (\lstinline{RoutingTable}) de l'équipement en question et comparer l'interface de sortie des deux routes (Route) retourné. Si elles sont différentes, cela signifique que le flux traverse ce firewall.
La méthode "crossed?" est un élément essentiel pour l'analyse des règles de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}). Elle permet de déterminer sur un équipement (\Colorbox{light-gray}{\lstinline|Device|}) est traversé par un flux définit par deux réseaux. Pour cela, il faut utiliser la méthode "route" de la table de routage (\Colorbox{light-gray}{\lstinline|RoutingTable|}) de l'équipement en question et comparer l'interface de sortie des deux routes obtenues. Si elles sont différentes, cela signifique que le flux traverse ce firewall.
\begin{lstlisting}[language=Ruby]
# Params:
# * network1: the *source* network
# * network2: the *destination* network
def crossed?(network1, network2)
return false unless routing_table
route1 = routing_table.route(network1)
route2 = routing_table.route(network2)
\begin{lstlisting}[language=Ruby, title="app/model/device.rb"]
# Params:
# * network1: the *source* network
# * network2: the *destination* network
def crossed?(network1, network2)
return false unless routing_table
route1 = routing_table.route(network1)
route2 = routing_table.route(network2)
return false unless route1 && route2
route1.interface != route2.interface
end
return false unless route1 && route2
route1.interface != route2.interface
end
\end{lstlisting}
\subsection{matched\_policies}
\label{sec:methodes:matched_policies}
Cette méthode permet de gérer la fonctionnalité principale de l'application, soit de rechercher une règle spécifique en précisant une réseau source et distination, un protocole et un numéro de port.
\begin{lstlisting}[language=Ruby, title="app/model/device.rb"]
# Params:
# * request: the PolicyRequest with all the required informations
def matched_policies(request)
policies = []
policies_found = find_policies(request)
if !policies_found.empty? && request.include_all
policies += policies_found
elsif !policies_found.empty?
policies << policies_found.first
else
policies << implicit_policy
end
policies
end
\end{lstlisting}
Le but ici est de faire la requête de recherche et de retourner toutes les règles de sécurité obtenues ou bien uniquement la première en fonction de ce qui a été demandé dans la requête. Si aucune règle de sécurité n'est trouvée, la méthode va retourner une règle qui correspond à une règle implicite de blocage (par défaut sur firewall, ce qui n'est pas explicitement autorisé est bloqué).
\begin{lstlisting}[language=Ruby, title="app/model/device.rb"]
# Params:
# * request: the PolicyRequest with all the required informations
def find_policies(request)
source = matched_addresses(request.source)
source += matched_address_groups(source)
destination = matched_addresses(request.destination)
destination += matched_address_groups(destination)
service = matched_services(request.protocol, request.port)
service += matched_service_groups(service)
source_interface = zone_name(
routing_table.route(request.source).interface
)
destination_interface = zone_name(
routing_table.route(request.destination).interface
)
policies.where(
source_interface: source_interface,
destination_interface: destination_interface
).any_in(
source: source,
destination: destination,
service: service
)
end
\end{lstlisting}
La requête sur la base de donnée qui permet d'obtenir les règles de sécurité voulues est définie dans la fonction ci-dessous. Pour cela, il faut commencer par isoler les adresses source et destination ainsi que les services. On cherche ici à comparer des tableaux de String entre eux et à savoir si au moins un des éléments de ce tableau se retrouvent dans l'autre tableau. La méthode utilisée pour cela est "any\_in"\cite{stackanyin} en lui précisant les paramètres.

10
chapitres/model/validation.tex
View File

@@ -1,7 +1,7 @@
\chapter{Tests et validations}
\label{ch:tests}
Pour valider le bon fonctionnement de l'application et mettre en place l'intégration continue, différents modules sont utiliser pour tester les objets et méthodes ainsi que pour valider la syntaxe et l'indentation du code.
Pour valider le bon fonctionnement de l'application et mettre en place le \gls{tdd}, différents modules sont utilisés pour tester les objets et méthodes ainsi que pour valider la syntaxe et la forme du code.
\section{Javascript}
@@ -19,7 +19,7 @@ ESLint\cite{eslint} est un analyseur de code JavaScript qui permet d'appliquer l
RSpec\cite{rspec} est une solution qui propose un ensemble d'outils pour tester les applications Ruby et notamment celles créées avec Rails. Il va permettre de créer des objets et de vérifier leur validité ainsi que de tester le bon fonctionnement des méthodes. Cet outil est utilisé dans le backend mais également pour valider les deux modules d'accès aux équipements (paltogem et fortigem). Les fichiers qui concernent les tests RSpec se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|spec/|} à la racine du projet.
Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec rspec spec/|} depuis la racine du projet. Il est aussi possible de ne lancer que certains tests en précisant le fichier de test dans la commande.
Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle exec rspec spec/|} depuis la racine du projet. Il est aussi possible de ne lancer que certains tests en précisant le fichier de test dans la commande.
\begin{figure}[H]
\centering
@@ -29,9 +29,9 @@ Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exe
\subsection{Rubocop}
RuboCop\cite{rubocop} est un analyseur de code et de syntaxe basé sur le \emph{A community-driven Ruby coding style guide}\cite{rubystyleguide}. Il permet de s'assurer que la syntaxe est utilisée de façon uniforme dans le projet, de remonter l'utilisation de méthodes dépréciées, de vérifier les indentations. Tous les tests effectués par le programme peuvent être personnalisés au besoin et sont tous documentés avec des exemples\cite{rubocopdoc}. RuboCop propose également des tests supplémentaires pour les projets utilisant Rails, en se basant sur le \emph{A community-driven Ruby on Rails coding style guide}\cite{railsstyleguide}.
RuboCop\cite{rubocop} est un analyseur de code et de syntaxe basé sur le \emph{"A community-driven Ruby coding style guide"}\cite{rubystyleguide}. Il permet de s'assurer que la syntaxe est utilisée de façon uniforme dans le projet, de remonter l'utilisation de méthodes dépréciées, de vérifier les indentations. Tous les tests effectués par le programme peuvent être personnalisés au besoin et sont tous documentés avec des exemples\cite{rubocopdoc}. RuboCop propose également des tests supplémentaires pour les projets utilisant Rails, en se basant sur le \emph{"A community-driven Ruby on Rails coding style guide"}\cite{railsstyleguide}.
Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec rubocop|} depuis la racine du projet.
Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle exec rubocop|} depuis la racine du projet.
\begin{figure}[H]
\centering
@@ -41,4 +41,4 @@ Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exe
\subsection{Brakeman}
Brakeman\cite{brakeman} est également un analyseur de code mais qui va plutôt chercher des vulnérabilités et des problèmes de sécurité dans le code. Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec brakeman|} depuis la racine du projet.
Brakeman\cite{brakeman} est également un analyseur de code mais qui va plutôt chercher des vulnérabilités et des problèmes de sécurité dans le code. Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle exec brakeman|} depuis la racine du projet.

1
chapitres/requis/technique.tex
View File

@@ -52,3 +52,4 @@ Les dépendances précises se trouvent dans des fichiers différents en fonction
\section{Hébergement}
Pour pouvoir fonctionner correctement l'application doit pouvoir effectué des requêtes sur l'API des équipements gérés. Pour y parvenir, la machine sur laquelle l'application est hebergée doit pouvoir atteindre les ports TCP 80 et 443 de ces équipements.