%\documentclass[twoside, openright]{report} \documentclass[]{report} \usepackage{breport} \usepackage{longtable} \usepackage{boxedminipage} \usepackage{alltt} \pagestyle{fancy} \renewcommand{\chaptermark}[1]{\markboth{#1}{}} \renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}} \renewcommand{\emp}[1]{\textit{#1}} \fancyhf{} \fancyhead[LE,RO]{\bfseries\thepage} \fancyhead[LO]{\bfseries\rightmark} \fancyhead[RE]{\bfseries\leftmark} \renewcommand{\headrulewidth}{0.5pt} \addtolength{\headheight}{0.5pt} \renewcommand{\footrulewidth}{0pt} \fancypagestyle{plain}{ \fancyhead{} \renewcommand{\headrulewidth}{0pt}} \title{\textbf{\Huge{Contrôle technique d'un système informatique}} \rule{\textwidth}{0.1cm}\\ \textbf{\huge{Firewall Services}} } \author{\noun{LATHUILIÈRE} Bruno} \date{Projet de stage de deuxième année\\Juin - Septembre 2005\\ \vspace{5cm} \includegraphics{images/Logo.eps} \hspace{2cm} \includegraphics[width=7cm]{images/enseirb.eps} } \begin{document} \maketitle \tableofcontents \section*{Remerciements} Je tiens particulièrement à remercier plusieurs personnes qui ont permis le bon déroulement de ce stage : \begin{description} \item[Monsieur Hervé LARDIN] sans qui rien n'aurait été possible, \item[Monsieur Serge TORIO] qui m'a permis de mieux cibler les priorités, \item[Monsieur Cyril DUMAS] qui m'a donné de bons conseils, \item[Le personnel du centre Montesquieu] qui fut toujours très accueillant, \item[Les lecteurs de Linuxfr] qui m'ont fait connaître certains projets bien utiles, \item[Mes parents] qui m'ont (entre autre) prêté une voiture, m'évitant ainsi 40 Km de vélo quotidiens. \end{description} \chapter{Introduction} Dans le cadre de mon projet professionnel, je souhaitais faire mon stage dans une Société de Service en Logiciels Libres (SSLL), afin de mieux connaître ce secteur qui m'intéresse particulièrement. Ainsi je suis rentré en contact avec la société Firewall Services qui m'a proposé plusieurs sujets : \begin{itemize} \item Développement d'une contribution pour la distribution GNU/Linux SME, pour pouvoir facilement monter un serveur miroir d'un serveur primaire et ainsi pouvoir le remplacer en cas de défaillance. \item Intégration d'un Groupware libre à SME. \item Développement d'outils permettant de faire un contrôle technique d'un système informatique. La signification de \textit{Contrôle technique} est un rapport mettant en évidence un certains nombre de points élémentaires de sécurité. \end{itemize} J'ai finalement choisi ce dernier sujet, pour son ambition, pour mon désir d'accroître mes connaissances dans le domaine de la sécurité informatique, et enfin et surtout, parce que cela correspondait au besoin le plus important formulé la société Firewall Services. Ce projet est en effet important pour Firewall Services qui est dans une phase d'agrandissement, et qui cherche donc à augmenter son offre commerciale. Ce nouveau produit est d'autant plus important qu'il va permettre d'épauler d'autres offres tel que la passerelle d'échanges sécurisés et la formation sécurité. Pour mieux comprendre le contexte, et donc l'importance du projet je vais faire une présentation de \textit{Firewall Service, l'entreprise} puis je vais exposer plus détails les \textit{objectifs de la mission technique}. Ensuite dans la \textit{Réalisation du projet}, je vais vous présenter les choix techniques et la démarche qui ont conduit ce travail. Ceci nous permettra enfin de le point dans la \textit{conclusion} Un \textit{Glossaire}, et des annexes permettront d'aider à la compréhension du rapport. \chapter{Firewall-Services, l'entreprise} \section{Raison sociale, statut juridique et actionnariat} \fws \, est une SARL (Société à Responsabilité limitée) crée en Juillet 2001 dont le gérant est Hervé \noun{LARDIN}. \section{Activité} %SME et compagnie La société \fws \, est une PME qui installe, configure, administre et surveille des serveurs polyvalents (passerelle Internet, serveur web, serveur de fichiers, messagerie..) pour des PME de la région sud-ouest. La solution logicielle utilisée est basée sur le système d'exploitation libre GNU/Linux, à travers la distribution SME Server, qui correspond parfaitement aux besoins des entreprises clientes. Une autre activité de la société se situe au niveau de la formation. \fws propose en effet plusieurs formations dont les plus importantes sont : \begin{itemize} \item Formation sécurité : Règles d'administration, bonnes pratiques. \item Formation Bureautique : OpenOffice \item Formation Internet-Intranet : Apache, MySQL, PHP, Perl, Spip \end{itemize} %\section{Marché et chiffre d'affaire} %serveur Sme + administration mensuelle \section{Concurrence} \fws occupe une niche économique et n'a donc pas vraiment de concurrents dans la région. \section{Ressources humaines et organisation} %presentation des differentes personnes Hervé \noun{Lardin}, son gérant, est le seul salarié de la société. Serge \noun{Torio}, le commercial de la société travaille pour \fws en tant que \textit{actionnaire associé} Au moment où j'ai effectué mon stage nous étions 2 stagiaires. En effet Cyril \noun{Dumas} effectuait un stage post-formation sur le thème de la téléphonie IP. \section{Recherche et développement} \fws a développé et maintient certaines contributions pour la distribution GNU/Linux SME : \begin{itemize} \item sme6admin qui permet de faciliter l'administration d'un serveur SME \item Asterisk@Home on SME Server v7 qui permet de faire de la téléphonie IP \end{itemize} Toutes ces contributions, sont publiées sous la licence GPL. Ce choix est justifié par le fait que cela permet : \begin{itemize} \item d'obtenir des correctifs, ou des ajouts de fonctionnalités de la part de développeurs ne faisant pas partie de \fws \item de raccourcir les périodes de tests, car les contributions sont testées sur un nombre plus important de machines. \end{itemize} \section{Politique de sous-traitance et d'achat} %Travailleur indépendant %materiel info : directement acheter par le client %que le service \fws \, a un certains nombre de collaborateurs, qui sous le statut de travailleurs indépendants, effectuent des missions techniques en son nom. \chapter{Objectif de la mission technique} Nous allons ici présenter dans un premier temps le cahier des charges tel qu'il a été défini après un mois de stage. Les notes en bas de page correspondent à des oublis de justification lors de la rédaction du cahier des charges \section{Le cahier des charges} \subsection{Contexte de l'étude} \fws \, est une SSLL (Société de service en logiciel libre), qui a pour clients essentiellement des PMI-PME. Elle a remarqué que la sécurité informatique est loin d'être suffisamment prise en considération dans l'administration de leur système informatique. Dans cette optique \fws \, souhaite développer des outils permettant la génération automatisée d'un audit simplifié. Ce produit permettrait un premier contact commercial intéressant en vue d'une collaboration plus poussée. \subsection{Structuration} Il faut distinguer deux parties distinctes dans ce projet : \begin{enumerate} \item \emp{La récupération d'information} qui se fera soit de l'extérieur pour des tests d'intrusions, soit à partir d'un portable muni d'un liveCD branché dans les réseaux internes et enfin par l'exécution d'un script sur chacune des machines. \item \emp{La génération du rapport} se fera à partir des informations récupérées lors de l'étape précédente. Ce rapport se veut simple et compréhensible pour des non-informaticiens\footnote{En revanche les annexes du rapport peuvent être plus complexe}. \end{enumerate} \vspace{0.5cm} Le \emp{mode opératoire} sera donc le suivant : \begin{enumerate} \item D'abord on exécutera un script sur chacune des machines du réseau, pour récupérer des informations, via un script, que l'on enregistrera dans un fichier. Dans un premier temps on laissera à l'opérateur le soin d'envoyer ce fichier sur une machine de \fws, par le moyen de son choix \footnote{Ce choix est discutable, dans la mesure où cela complexifie considérablement l'utilisation de ce script sur les gros réseaux. Mais ce système a le gros avantage d'être très souple, en effet une solution passant par le réseau risquerait de ne pas fonctionner sur certains réseaux}(https, clé USB, portable, \dots)\footnote{Voir figure \ref{conf}}. \item Ensuite on branchera un portable, avec comme système le liveCD, dans chaque réseau interne, où l'on fera tourner un script qui permettra de voir quels sont les services accessibles en internes, et les partages de fichiers\footnote{Voir figure \ref{conf}}. \item Puis on placera derrière les passerelles internet un portable en mode bridge (il ne modifiera en rien la configuration du réseau, car il se comporte comme un simple câble ethernet) pour pouvoir écouter le trafic avec l'extérieur pendant une durée de l'ordre de la journée\footnote{Voir figure \ref{sniff}}. \item Puis on fait les tests d'intrusion depuis l'extérieur via un serveur nessus tournant sur une machine de \fws . \item Enfin après avoir récupéré tous les fichiers, contenant les informations récupérées lors des 4 étapes précédentes, dans un même répertoire, on exécute un script qui génère le rapport\footnote{Voir figure \ref{repository}}. \end{enumerate} \begin{figure}[!ht] \includegraphics[width=14cm]{images/conf.eps} \caption{Schéma illustrant le mode opératoire du scan du réseau interne, et des scripts clients.} \label{conf} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/sniff.eps} \caption{Schéma illustrant le mode opératoire pour l'écoute du trafic réseau.} \label{sniff} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/repository.eps} \caption{Schéma illustrant le mode opératoire pour la génération du rapport.} \label{repository} \end{figure} \subsection{Récupération des informations} Les technologies mises en \oe uvre seront assez variées dans cette partie. Le langage de script sera le python, car c'est un langage bien adapté à l'administration système (Ce langage est préféré au Perl pour des convenances personnelles \footnote{Le fait de trouver ce langage plus lisible est subjectif, mais cet avis est néanmoins partagé par beaucoup \dots} ) On utilisera nmap comme scanneur de port et Nessus pour les tests d'intrusions. Pour l'écoute du trafic réseau on utilisera ettercap et dsniff. Le liveCd permettra donc d'avoir un système d'exploitation contenant tout l'environnement nécessaire à l'exécution des scripts. Pour la réalisation de ce liveCD, on se basera sur la distribution Knoppix, car on peut estimer qu'il s'agit d'une distribution pérenne, relativement facile à adapter. Pour les scripts fonctionnant sur toutes les machines, on ne pourra utiliser python (ou perl) car ces langages nécessitent un interpréteur, et on souhaite éviter l'installation de logiciels sur les machines auditées. On préférera donc faire des scripts batch pour machines windows et des scripts sh pour les machines unix et linux. \subsection{Génération du rapport} La génération de rapport se fera grâce à python dans le format docbook car il permettra après de générer le document au format choisi (\LaTeX, OpenOffice.org, \dots). Le plan du rapport devra se faire en 9 parties pour respecter la dimension commerciale du produit qui vend un \textit{Contrôle technique} : \begin{enumerate} \item \emp{Infrastructure du réseau :} On fera un listing des triplets (nom, ip, adresse mac) dont on aura pu découvrir l'existence. L'ordre et les groupements restent encore à définir. \item \emp{Services interne accessible :} On fera la liste des services accessibles en interne. Le groupement ne se fera pas par ip mais plutôt par service. On signalera clairement toutes les failles des sécurités que l'on aura découvertes pour chaque service. \item \emp{Partage réseau :} On fera la liste des partages, et on donnera des statistiques sur les tailles, les dates, des propriétaires des fichiers. On mettra en avant les partages accessibles sans mot de passe ou avec des mots de passe triviaux. \item \emp{Test anti-intrusion :} On fera la liste des ports ouverts et des failles de sécurité exploitables depuis l'extérieur. \item \emp{Trafic réseau :} On générera des statistiques sur le trafic réseau. Et on signalera le trafic qui pourrait permettre de suspecter un éventuel cheval de Troie \item \emp{Configurations matérielles :} On fera la liste du matériel disponible, en donnant des indications pour savoir si les machines tiennent la charge. \item \emp{Protection des données :} On fera un point sur les processus qui tournent sur les différentes machines, et en particulier sur la présence d'antivirus. On pourra également faire des statistiques sur les dates et taille des fichiers qui peuvent être un bon indicateur. \item \emp{Configurations logicielles :} On fera un point sur les versions des logiciels et en particulier sur les mises à jours sécurité. \item Le point 9 devait être à propos des procédures d'urgence. Mais ce point n'est pas automatisable, il faudrait donc trouver un point pour le remplacer. \end{enumerate} \subsection{Livrables} L'objectif de ce projet est donc de fournir : %%L'ensemble des éléments suivant doivent être livrés pour le ???DATE??? %%: \begin{itemize} \item le script à exécuter sur les machines du réseau, \item le liveCD et les scripts pour l'audit interne, \item le script pour l'audit externe, \item le script de génération du rapport, \item un exemple d'utilisation, \item un manuel d'utilisation, \item et un manuel de maintenance. \end{itemize} \vspace{5mm} \rem Les scripts seront publiés sous licence GPL v2. \section{Les évolutions du cahier des charges} %le plan fouareux Le cahier des charges au niveau du plan du rapport à générer n'étant pas très logique, a été modifié dans l'ordre et la partie sur les antivirus se trouve dans ``Configurations logicielles''. Le nouvel ordre est donc : \begin{itemize} \item \emp{Infrastructure du réseau} \item \emp{Services internes accessibles} \item \emp{Partages réseaux} \item \emp{Trafic réseau} \item \emp{Test anti-intrusion} \item \emp{Configurations matérielles} \item \emp{Configurations logicielles} \item \emp{Protection des données} \item Le point 9 \end{itemize} \section{Critère de validation du sujet} Le test final se fera sur un réseau différent de celui qui servira pour le développement. Ce test consistera simplement à générer un rapport. \section{Moyens mis à disposition du stagiaire} \begin{itemize} \item 1 portable pour le développement\footnote{sur lequel a été installé une debian sid (dont knoppix est très proche)}, \item 1 pc muni de 2 cartes réseau, \item 1 portable sous Windows XP Professionnel pour les tests, \item 1 accès plus ponctuel à d'autres systèmes (Windows 2000, Windows XP Home Edition) \item Le réseau de \fws , \item Un accès internet. \end{itemize} \section{Planification du projet} %planning Le planning n'a pas pu être défini depuis le départ, car en effet il a fallu au préalable définir le cahier des charges. Je vais donc présenter mon activité durant les 5 premières semaines avant l'établissement du planning. Les deux premières semaines ont été consacrées essentiellement à l'installation de serveurs SME et du wifi chez deux clients de \fws. Cela m'a permis de mieux comprendre l'entreprise \fws, ses besoins et ceux de ses clients. Les 2 semaines suivantes ont été utilisées à la rédaction du cahier des charges. Pendant ces deux semaines et la suivante, j'ai donc fait un rapide tour des logiciels et des outils disponibles. Une fois fait, il était possible d'établir un planning pour les 8 semaines restantes. \begin{center} \begin{tabular}{|p{8cm}|l|} \hline Tâche & Durée estimée\\ \hline La récupération d'informations et la génération du rapport pour les parties topologie, services accessibles en interne, et test d'intrusion & 2,5 semaines \\ \hline Le script windows et le parse des résultats & 1 semaine \\ \hline La génération du rapport pour les parties configurations matérielles, configurations logicielles, et partage réseau & 1,5 semaine \\ \hline Récupération et génération pour la partie trafic réseau & 1 semaine\\ \hline Intégration des scripts et génération du liveCD & 1 semaine\\ \hline Phase de test & 1 semaine\\ \hline \end{tabular} \end{center} Les deux dernières tâches faisant tourner des scripts assez long, il est possible de rédiger les rapports en parallèle. \chapter{Réalisation du projet} \section{Analyse du cahier des charges} Le cahier des charges étant relativement chargé, le problème du temps sera donc le principale. Pour les quatre premières tâches du planning, qui peuvent être plus ou moins poussées, on pourra se permettre d'arrêter le développement lorsque le temps prévus sera écoulé. En revanche pour l'intégration, la tâche devra être faite dans son intégralité. Un autre facteur de risque, est dû au nombre important de logiciels mis en \oe uvre et au fait qu'ils puissent évoluer. L'évolution est souvent une bonne chose, car on profite des améliorations, mais cela peut poser des problèmes en particulier si le format de sortie est modifié. La diversité des plates-formes pour lesquelles devront tourner les scripts clients constitue également un risque important. Cette diversité est dû et aux systèmes, à ses paramètres linguistiques\dots Le développement se fera donc par ordre de priorité. \section{Conception générale} L'ensemble du projet du point de vue du développeur se découpe en deux parties : \begin{description} \item[La partie récupération des données,] qui comprend l'exécution de programmes donnant des informations pertinentes, et le traitement de ces données pour qu'elles soit directement exploitables en python. Ce qui signifie que la partie récupération des données n'est pas celle que perçoit l'utilisateur, comme le montre la figure \ref{flow} \item[La partie génération du rapport,] qui a pour tâche, comme son nom l'indique de générer le rapport. Cette partie commence par une phase de réorganisation des données. En effet la partie précédente ne fait pas de recoupements d'informations entre les différents résultats des différents scripts. Puis elle se poursuit par la génération proprement dite du rapport. \end{description} \begin{figure}[!ht] \includegraphics[width=13cm]{images/flot.eps} \caption{Schéma illustrant les deux parties, du point de vue développeur du projet. Il montre également pour chaque partie du rapport, d'où viennent les informations récupérées} \label{flow} \end{figure} Le script que l'utilisateur lance pour la génération du rapport, est à cheval sur la partie de récupération des données et sur celle de génération du rapport. \subsection{Récupération d'informations} La partie récupération suit directement le cahier des charges. En effet elle se décompose ainsi : \begin{itemize} \item script\_interne.py \item script\_externe.py \item scripts clients \item sniff\_begin.sh \& sniff\_end.sh \end{itemize} \subsection{Génération du rapport} La génération du rapport nécessite d'abord une réorganisation des données, ensuite seulement on peut écrire le rapport en utilisant une classe générique, ce qui permettra d'en écrire une autre pour faire une exportation dans un autre format. \subsection{Configuration \& Intégration} Une autre partie importante est le fait de pouvoir configurer tous ces scripts présents sur le LiveCD. On présentera également dans Conception détaillée les choix importants qui ont été fait pour l'intégration. \section{Conception détaillée} \subsection{Récupération d'informations} \subsubsection{script\_interne.py} %detection de l interface \paragraph{Détection de l'interface réseau} Ce script a besoin, en entré, de connaître le réseau à scanner. La solution qui a été adoptée est d'utiliser la première interface donnée par \cmd{ifconfig} \footnote{l0 excepté}. Cette option a l'avantage de ne rien demander à l'utilisateur dans le script. Ceci permet d'utiliser avantageusement le dhcp et cela permet également à l'utilisateur de tester le fait que la connexion au réseau fonctionne bien. Lorsque que le dhcp ne fonctionne pas l'utilisateur doit utiliser les outils Unix classiques pour configurer le réseau, ce qui évite de devoir refaire une interface de configuration réseau et à l'utilisateur d'en apprendre une nouvelle. La classe local\_config du module scan permet de faire ce travail, en interprétant les résultats de ifconfig. La méthode utilisée pour parser est celle du découpage (voir page \pageref{parse}) %detection ping +mmap \paragraph{Détection des machines présentes sur le réseau} Maintenant que nous connaissons le réseau à scanner, il faut détecter les machines présentes sur le réseau. Cette étape est séparée de la suivante car cela permet de limiter le nombre de machines à scanner lors de l'étape suivante et donc de gagner du temps. Pour détecter les machines on utilise deux outils. D'abord on fait un ping sur l'adresse de broadcast\footnote{méthode add\_pingable\_host de la classe scan}. Mais cela n'est pas suffisant car certaines machines ne répondent pas au ping. On utilise donc nmap avec l'option -sP \footnote{méthode add\_nmapable\_host de la classe scan}. Le résultat de ping est parsé avec la méthode du découpage (voir page \pageref{parse}) et celui de nmap avec des expressions régulières (différentes selon que nous sommes dans un réseau où il y a une résolution de noms ou pas). Ensuite on peut essayer de voir si la résolution de nom est possible, pour avoir un nom plus \textit{parlant}. %nessus (choix) \paragraph{Le scan} \begin{figure}[!ht] \begin{verbatim} Security Note 11032 The following directories were discovered: /cgi-bin, /icons, /test While this is not, in and of itself, a bug, you should manually inspect these directories to ensure that they are in compliance with company security standards Other references : OWASP:OWASP-CM-006 Security Note 11213 The remote webserver supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP methods which are used to debug web server connections. It has been shown that servers supporting this method are subject to cross-site-scripting attacks, dubbed XST for "Cross-Site-Tracing", when used in conjunction with various weaknesses in browsers. An attacker may use this flaw to trick your legitimate web users to give him their credentials. Solution : Add the following lines for each virtual host in your configuration file : RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) RewriteRule .* - [F] See also http://www.kb.cert.org/vuls/id/867593 Risk factor : Medium BID : 9506, 9561, 11604 Security Note 10107 The remote web server type is : Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16 Solution : You can set the directive 'ServerTokens Prod' to limit the information emanating from the server in its response headers. \end{verbatim} \caption{Extrait de la sortie xml de nessus} \label{xml} \end{figure} Le scan \footnote{Ce scan est implémenté dans la classe scan du module scan} se fait principalement avec l'outil Nessus. Nessus n'est pas un simple scanneur de port : il possède une base de données sur les failles existantes, et une collection de plugins permettant de tester si les failles sont exploitables. Un des formats d'exportation est un fichier XML, et c'est le format qui est facilement exploitable et qui sera le plus stable dans le temps. On utilise une bibliothèque spécialisée dans la lecture du XML pour exploiter les résultats. Le fichier XML (voir figure \ref{xml}) contient pour chaque machine (chaque ip), pour chaque port, les informations suivantes : \begin{description} \item[service :] le nom du service \item[information :] cette balise correspond à une information que nessus peut donner. On notera qu'il peut en avoir plusieurs pour un seul service. Chaque information est constituée de : \begin{description} \item[severity :] contient la chaîne \textit{Security Note}, \textit{Security Warning} ou encore \textit{Security Hole}. Cela permet d'avoir pour chaque information une échelle à 3 échelons sur les failles de sécurités \item[id :] contient un nombre identifiant l'information \item[data :] contient un texte en anglais non structuré, donc non scriptable, qui explique l'éventuelle faille et le chemin à suivre pour la corriger. On signalera qu'il n'y a pas de bijection entre id et data car le texte de data peut être adapté suivant la situation. \end{description} \end{description} On fait également un scan avec nmap, pour l'instant on n'utilise que peu ses résultats, mais à terme cela permettra de faire des comparaisons de données avec celle de nessus. Actuellement l'élément le plus utilisé est tout simplement l'adresse mac. %smbtree + ... \paragraph{SMB} Pour avoir des informations sur les partages réseaux SMB on utilise smbtree avec l'option -N, qui permet d'obtenir tous les noms partages réseaux dont on peut connaître l'existence sans taper de mot de passe. Ensuite pour chaque partage on regarde si on peut s'y connecter sans taper de mot de passe avec smbclient. Comme smbtree ne permet de connaître que le nom netbios et le nom du groupe de travail, on doit utiliser la commande nmblookup pour obtenir le nom l'ip correspondante. Ceci est implémenté dans le module samba. \paragraph{transport} La partie de parse se fait avant le transport, donc au moment du scan, car cela permet \footnote{et permettra, dans des versions ultérieures} d'adapter les actions de scans au résultat de scan précédent. Mais ceci est un choix discutable, car l'objectif global du projet était de diminuer au maximum le travail effectué avant le transport, pour limiter au maximum le risque de bogue lors de la récupération des données chez le client (Un bogue lors de la génération du rapport est moins grave, car il est possible de le réparer sans refaire tourner de nouveau les scripts de récupération de données). Comme le parse est déjà fait on possède une structure dans lequel il existe déjà toutes les données. Pour le \textit{transport}, on utilise donc un module de python\footnote{Il s'agit du module pickle} qui permet d'écrire le contenu d'une variable dans un fichier. La partie récupération des données qui s'effectue après le \textit{transport}, se limite donc à récupérer la structure se trouvant dans le fichier. \subsubsection{script\_externe.py} Le script externe contient uniquement un scan nessus\footnote{On réutilise donc la classe scan du module scan}. Pour connaître l'adresse à scanner le script demande à l'utilisateur les adresses ip à scanner. L'utilisation de nessus est identique à celle du script\_interne. \subsubsection{scripts clients} \paragraph{Structure} Le principe du script client est une suite de commande dont on enregistre les résultats dans un fichier. Pour pouvoir se repérer dans le fichier par un pseudo XML: \begin{verbatim} ###nom_commande### le résultat de la commande ###/nom_commande### \end{verbatim} On utilise pas un vrai code xml pour la simple raison que les caractères < et > sont plus compliqués à obtenir dans des scripts batch et sh. Ensuite le résultat est compressé avec gzip. Le \textit{transport} est donc fait par l'utilisateur. Lors de la génération du rapport\footnote{du point de vue de l'utilisateur} on va donc commencer par décompresser le fichier. Ensuite, pour les scripts Windows, les caractères du fichier sont convertis avec dos2unix et konwert. Et le parse proprement dit peut enfin commencer. \paragraph{Parse} Le parse se déroule en deux parties. Dans un premier temps on fait une première passe pour obtenir une table de hashage \footnote{un dict en python} qui à chaque nom de commande associe son résultat. Ensuite on peut parser chaque commande, en commençant par la commande donnant la version du système car cela permet ensuite selon le système d'avoir des fonctions pour parser différemment selon le système. On utilise 3 manières de parser \label{parse} \begin{description} \item[Découpage] (ou split) : On découpe les lignes pour des caractères particuliers (généralement les espaces). On peut ensuite récupérer les mots qui nous intéressent. \item[Statique] : On récupère directement dans la ligne les caractères qui conviennent. Par exemple on récupère la chaîne de caractère commençant au caractère 15 de la ligne et finissant au 21. \item[RegExp] : Les expressions régulières permettent de savoir si une chaîne correspond à un modèle. Dans le modèle, on peut définir les données que l'on souhaite récupérer. \end{description} Le fait de parser en statique dépend essentiellement du type de la sortie, alors qu'entre la méthode du découpage, et celle des RegExp on choisit la plus pratique, mais quand l'une est possible l'autre fonctionne aussi. Tous ces résultats sont stockés dans une structure, dont on verra bientôt comment on l'utilise. Cette structure est une table de hashage qui associe à chaque commande, le résultat du parse. \paragraph{Les différentes commandes} Voici la liste des différentes commandes qui peuvent donner des informations intéressantes pour le script Windows : \begin{tabular}{|p{2cm}|p{4.5cm}|p{1.5cm}|p{4cm}|} \hline \textbf{Nom de la commande} &\textbf{ Objectif} & \textbf{type de parse} & \textbf{Remarque} \\ \hline hostname & Le nom de la machine &Rien à faire & \\ \hline psinfo & Des informations sur le hardware et sur le software (liste des programmes installés, des hotfix) \dots &Regexp \& static & Ceci est un binaire, qui doit être dans le même répertoire que le script. Ce binaire pose un autre problème : ce n'est pas un logiciel libre et il sera impossible de le publier dans l'archive et sur le liveCD. Il y aura donc, dans le script d'install, une phase de téléchargement sur le site de sysinternals\\ \hline pslist & La liste des processus tournant sur la machine et avec des informations associées comme le nombre de changements de contexte, la mémoire virtuelle, la priorité, le nombre de défauts de page \dots &Static& Comme psinfo \\ \hline ver & la version du système & Rien à faire & \\ \hline net config workstation&Obtenir le nom du workgroup &Static & \\ \hline net user & La liste des utilisateurs, et certaines propriétés (date de changement de mot de passe,\dots) &Regexp \& static & Cette commande est en pratique un peu plus complexe car il faut d'abord récupérer la liste des login et puis faire des net user login\\ \hline time \& date & Récupérer des informations sur l'heure et la date du système & Découpage \& Regexp & Le parse est compliqué car le format de la date n'est pas toujours le même, et on n'a pas trouvé de moyen simple de connaître ce format. on utilise donc la date des fichiers (commande dir) pour éliminer les formats non cohérents)\\ \hline ipconfig& La configuration réseau &Regexp \& static & \\ \hline route & La table de routage &Regexp & Parser mais non utilisé après\\ \hline dir & Liste de l'ensemble des fichiers présents dans le système de fichier &RegExp & On a le même problème que pour date et ce problème est résolu de la même façon\\ \hline ping & Possibilité de \textit{pinguer google} &Regexp & \\ %\hline %netstat & & & \\ %\hline %net use & & & \\ \hline net share &Informations sur les partages samba & Static & \\ %\hline %net accounts & & & \\ %\hline %net localgroup & & & \\ %\hline %net statistics server & & & \\ %\hline %net statistics workstation & & & \\ \hline \end{tabular} On notera qu'on n'utilise pas la commande reg, qui permet de sauvegarder la base de registre, car la taille du fichier serait trop importante. Il est également important de signaler qu'on ne peut pas récupérer la base SAM (qui contient les mots de passe cryptés) car pour ça il faudrait redémarrer la machine sous un autre système (un liveCD qui gère NTFS par exemple), et cela ne correspond plus au cahier des charges. Le script windows est fait en deux parties : \begin{itemize} \item audit\_win : ce script vérifie qu'on a les droits administrateur, et si oui qui lance le script suivant \item audit\_win\_aux : ce script lance les commandes les une après les autres \end{itemize} Le script Unix n'est, lui, pas encore implémenté. \paragraph{Les accesseurs} Comme il ne faudra surtout pas utiliser les données parsées tel quel, on va passer par des accesseurs. Par ces accesseurs, on peut cacher les fonctions de parse, et le système (Windows ou Unix). Cela permet également d'utiliser plusieurs commandes, et de les \textit{mixer}. Et enfin cela permet de changer la commande utilisée pour obtenir une même information. \subsubsection{sniff\_begin.sh \& sniff\_end.sh} %theorie : juste un fichier => analyse On suppose le bridge est déjà configuré \footnote{Il existe un script qui aide à cette configuration : bridge\_conf.sh}. La solution élégante serait de juste enregistrer tout le trafic dans un fichier au format pcap. Mais afin d'obtenir des graphiques sur le trafic, en fonction du temps on utilise ntop, qui ne fonctionne pas complètement à partir d'un fichier pcap. On doit donc faire tourner ntop \textit{en direct}. Ntop fonctionne avec une interface Web, on récupère donc les informations par wget\footnote{Programme non-interactif pour télécharger des fichiers}. Parser du html n'est pas très propre, mais ce choix a été fait afin d'avoir un développement rapide. A long terme il faudrait refaire cette partie en n'utilisant plus ntop ou en le modifiant. Le script de sniff\_begin.sh lance tcpdump et ntop. Et sniff\_end.sh met fin à la capture par tcpdump et récupère les informations en les triant dans une arborescence et enfin on compresse cette arborescence qui contient le fichier pcap et toutes les informations nécessaires (page html et images converties en eps). On signalera également un script nommé test\_space.sh, qui est lancé par sniff\_begin.sh pour couper la capture avant qu'il n'y ai plus assez de place sur le disque. Une fois le transport fait, on peut commencer le parse, on utilise ettercap pour reconnaître les mots de passe passant en clair. On parse les fichiers html afin de retrouver les informations intéressantes, et on liste le répertoire pour retrouver les graphiques. Ceci est implémenté dans le module sniff\_parse. \subsection{Génération du rapport} \subsubsection{Intégration} L'intégration consiste à intégrer les résultats des scripts clients déjà parsés à la structure issue des scans internes. On va donc présenter la structure finale nommée info. Cette structure a l'inconvénient de ne pas avoir d'api pour y accéder : on doit \textit{taper} directement dans la structure. Cela ne parait pas très propre, mais les algorithmes dépendant assez fortement des structures, cela rendrait le code encore moins lisible sachant que de toute façon une refonte importante des structures imposerait une modification des algorithmes. \paragraph{La structure info} Elle est constituée d'un tableau, de structure appelée scan. Le premier élément du tableau correspond à un réseau fictif, celui des machines non connectées. Les autres éléments du tableau, eux, correspondent à un réseau pour lequel à été effectué un scan interne. La structure scan est un dict (table de hashage) qui a 3 champs : \begin{description} \item[local\_config] qui contient les informations de la configuration du scan, comme l'ip de la machine, le réseau, l'adresse de broadcast, \dots \item[scan] qui contient toutes les informations obtenues par les scans, pour chaque adresse ip. scan est donc un dict qui à chaque adresse ip associe un dict ayant pour clé : \begin{itemize} \item[ip:] L'ip de la machine, \item[hostname:] Nom de DNS de la machine, \item[nmapable:] Booléen indiquant si nmap a découvert la machine, \item[pingable:] Booléen indiquant si un ping sur l'adresse de broadcast a découvert la machine, \item[nmap\_port:] Liste des ports découverts par nmap. Un port est un dict ayant les clés (port, protocole, service, state, version). Il existe un élément de la liste avec l'élément port qui vaut \verb+other+, ce qui permet d'avoir le statut par défaut, \item[nessus\_port:] Liste des ports découverts par nessus. Un port est un dict ayant les clés (port, protocol, service, informations). informations correspond a une liste de dict ayant pour clé severity, data et id. Une information est effectivement composé d'un identifiant id, d'un niveau de sécurité (severity) appartenant à la liste de chaîne de caractère ["Security Hole","Security Warning","Security Note"] et data qui est un long texte expliquant la faille et les éventuels remèdes. \item[addr\_mac:] L'adresse mac, \item[netwk\_card\_mark:] Marque de la carte réseau, \item[uptime:] Uptime de la machine, \item[os:] Os de la machine (donnée par nmap), \item[os\_details:] Détails sur l'os de la machine (donnée par nmap), \item[c\_scr:] Structure du script client qui sera détaillé plus bas, \end{itemize} \item[samba] Cette structure est composée de dict de dict. Les clés du premier niveau sont les Workgroups, et celles de second niveau sont les noms netbios. Avec le workgroup et le nom netbios nous obtenons donc un nouveau dict ayant les clés suivantes : \begin{itemize} \item[ip:] Ip de la machine, \item[rep:] Liste de répertoires partagés sous forme de triplet (nom,commentaire,booleen) booleen étant un booléen indiquant si ce partage est accessible sans mot de passe. \end{itemize} \end{description} Cette structure est construite presque entièrement lors du scan. Elle est modifié lors de la génération du rapport pour y ajouter, les résultats des scripts c\_scr, via la fonction group\_topology. Nous allons donc voir comment fonctionne précisément cette fonction critique dans le paragraphe suivant. \paragraph{group\_topology} On procède par étape : D'abord on associe les scripts client pour lesquels on a trouvé une association avec les adresses mac. En effet lors du scan nmap nous fournis l'adresse mac correspondant à la machine et sur la machine ipconfig (pour windows) fournit également cette information. Ensuite pour les machines restantes, on met les machines ayant une configuration réseau (couple ip/mask) leur permettant d'être dans un réseau, dans ce réseau. Cette étape est utile lorsqu'au moment du scan, la machine était déconnectée. Et enfin on intègre les machines restantes au réseau fictif des machines non-connectées. \subsubsection{Outils de rédaction du rapport} Pour rédiger le rapport on utilise une classe, et on n'utilise que ses méthodes. Ces méthodes sont conçues de façon à être assez proche du XML : à savoir que pour chaque fonctionnalité, on a une méthode de début et une méthode de fin. Pour l'instant la seule implémentation de cette classe utilise Latex, mais l'interface utilisée permettra sans problème de générer du docbook\footnote{Faute de temps elle n'a pas été implémentée : le cahier des charges n'est donc pas respecté sur ce point }. Cette classe utilise une classe utilisant mpost\footnote{programme non-interactif pour générer des images} permettant de générer des camemberts au format postscript. \subsubsection{Le rapport} Le rapport est constitué de 8 parties et des annexes. Les parties Structure du réseau, Services accessibles en interne , Partage réseau, Configurations matérielles, Configurations logicielles et enfin protection des données ont la même architecture. On structure le rapport en traitant les réseaux les uns après les autres, puis si nécessaire les machines non connectées. Pour mieux comprendre cette partie, il est conseillé de regarder en parallèle l'annexe sur les screenshots. \paragraph{Topologie} Pour chaque réseau on fait un tableau récapitulant les ip, les noms DNS, et les adresses MAC. Ensuite pour les machines non-connectées, on se contente de lister les noms de machine. \paragraph{Service accessible en interne} Pour chaque réseau on fait le même traitement. Pour ne pas avoir toujours les mêmes informations, on liste les services ouverts par service plutôt que par machine. Cette réorganisation de donnée (sans effet de bord)) est faite par la fonction \textit{getservices} du module scan\_util. Pour chaque service, on pourrait la liste des couples ip/numéro de port pour lesquels on afficherait un graphique mettant en valeur le nombre de trou de sécurité, d'avertissement, et enfin de note de sécurité. Lorsqu'il y aurait au moins un trou de sécurité, on mettrait un pictogramme indiquant un danger important. Cette solution en tant quel tel donnerait un rapport avec beaucoup de redites. Donc pour chaque service, on partitionne donc les couples ip/port suivant la relation d'équivalence \textit{avoir les mêmes informations nessus, ce qui se traduit par toutes les informations nessus ont le même champs id}. Donc pour chaque classe d'équivalence, on fait la liste des couples ip, numéro de port. Puis on affiche le graphique dont on a parlé dans le paragraphe précédent. Cette méthode est un peu complexe mais permet de factoriser un peu le rapport. Une fois ce travail fait, on fait un résumé. Ce résumé se compose d'un camembert où l'on met en valeur les 4 nombres suivants : \begin{itemize} \item Le pourcentage de machines ayant plusieurs Security Hole \item Le pourcentage de machines ayant exactement un Security Hole \item Le pourcentage de machines ayant des Security Warning sans Security Hole \item Le pourcentage de machines ayant ni Security Hole, ni Security Warning. \end{itemize} Puis pour chaque réseau on fait un tableau où on récapitule les résultats (somme des Security Hole sur les différents ports, somme des Security Warning, somme des Security Note) dans un tableau. \paragraph{Partage réseau} Pour cette partie, il n'y a pas grand chose à dire si ce n'est qu'on utilise en priorité les informations venant du script client, car cela permet d'avoir des informations supplémentaires sur les fichiers présents dans le partage. \paragraph{Test anti intrusion} Cette fois on fait une présentation classique. Le premier élément de structuration est l'ip de la machine (Ceci n'est significatif que dans les très rares cas où il y a plusieurs adresses externes. Ensuite pour chaque port on fait le point, en utilisant les même graphiques, sur les alertes que donnent Nessus. \paragraph{Trafic réseau} Pour cette partie, les screenshots parleront d'eux même. Et cette partie est temporaire, et sa conception est donc minimaliste. La seule partie qui ne soit pas temporaire est celle des mots de passe interceptés. Pour chaque service on liste les mots de passe que l'on a intercepté. Comme on peut intercepter plusieurs fois le même triplet (host, login, password), on choisi le premier de la liste, en effet celui-ci sera souvent le plus pertinent. En effet il est probable que l'adresse du site (pour le service http) sera celle de base lors de la première interception. Pour des raisons de sécurité, les mots de passes sont étoilés dans le rapport. Mais le nombre de lettre reste le bon. \paragraph{Configurations matérielles} Cette partie fait le point pour chaque machine sur le processeur (type et fréquence) la mémoire et enfin sur les disques durs. Pour chaque partition on donne la taille libre avec des couleurs différentes. En effet lorsqu'il reste beaucoup de place on utilise le vert, puis le orange et enfin le rouge lorsque le manque de place restante devient critique. \paragraph{Configurations logicielles} Pour l'instant, cette partie n'est implémentée que pour les scripts Windows. En effet si beaucoup d'informations sont récupérés par des accesseurs qui cachent le système, il existe beaucoup d'informations qui n'ont de sens que pour un système donné. On donne d'abord des informations sur le système : \begin{itemize} \item la version du système (de Windows) \item la date d'installation \item le service pack (ensemble de mises à jour système) \end{itemize} Ensuite une phrase indique s'il manque des mises à jour. Pour cela on se base sur un fichier que l'utilisateur doit mettre à jour et qui contient la liste des hotfix\footnote{mise à jour de sécurité du système} qui doivent être présents. Puis on examine un autre point important : les utilisateurs. Pour chaque utilisateur on liste les groupes dont il fait partie, puis si nécessaire on donne des avertissements. Les avertissement possibles sont dans l'ordre : \begin{itemize} \item Utilisateur jamais loggué \item Utilisateur n'ayant pas changé son mot de passe depuis plus de 1 an \item Utilisateur n'ayant pas changé son mot de passe depuis plus de 6 mois et moins de 1 an \end{itemize} Après les utilisateurs, on liste les programmes installés (auxquels on supprime les mises à jour système car on en a déjà parlé). Ensuite on fait des remarques sur les antivirus et les firewall qu'on a ainsi pu détecter (Comme pour les hotfix, l'utilisateur doit maintenir un fichier contenant la liste). En revanche pour l'instant on ne vérifie pas encore s'il est actif ou pas (On pourrait commencer par regarder s'il fait partie de la liste des processus, mais cela demande de maintenir une nouvelle base de donnée) Enfin a partir de la liste de processus, on regarde si certains peuvent être suspectés d'être un spyware (logiciel espion). \paragraph{Protection des données} Dans cette partie on affiche des statistiques sur les documents (définis par leur extension). Ces statistiques sont faites grâce à la classe pc\_fs\_stat. \paragraph{Annexe Nessus} Comme il n'était pas possible d'exploiter toutes les informations de Nessus, il était indispensable de faire un tableau pour chaque ip récapitulant tous les résultats données par Nessus. La forme du tableau est des plus traditionnelles, correspondant à un des export html de Nessus. \subsection{Configuration \& Intégration} \subsubsection{Configuration} La configuration se fait via un fichier python nommé : config.py. Une fois que config.py se trouve dans le path python, pour qu'un module python puisse accéder à une variable de configuration, il suffit de mettre : \begin{verbatim} from config import ma_variable_de_configuration \end{verbatim} Pour pouvoir accéder a une variable à partir d'un script shell, le plus simple est d'écrire un petit exécutable python qui renvoie juste la valeur : \begin{verbatim} #!/usr/bin/python import fwlive_path from config import config_dir print config_dir \end{verbatim} Le principe du fichier de configuration étant donné, il faut se reporter à la documentation utilisateur pour connaître les différentes variables permettant de configurer ces scripts. \subsubsection{Intégration} \paragraph{Petits scripts utiles} Afin d'aider l'utilisateur, il existe d'autres scripts. En effet il n'est pas forcement aisé de configurer un bridge à la main. Il existe donc un script pour monter le bridge et un pour le démonter. \paragraph{install.sh} Le script d'install permet d'installer les scripts sur un système qui possède tous les outils nécessaires à son fonctionnement. Il se charge de générer le fichier python qui se trouvera dans le path python qui permettra la modification dynamique du path python, et ainsi de pouvoir installer où l'on le souhaite les modules python. Un des problèmes rencontrés est du à un problème de licence pour psinfo et pslist, qu'on doit donc télécharger lors de l'installation, car on ne peut pas le mettre dans l'archive. \paragraph{Knoppix} Pour l'intégration des scripts sur une knoppix, l'exécution du script d'install ne suffit pas. En effet il faut un système qui possède les outils nécessaires. On va donc devoir ajouter des outils, mais comme la place est limitée sur le LiveCD, cela signifie qu'il faut également en enlever\footnote{Le fichier ou l'on voit les choix faits est chroot\_remaster}. Les scripts de génération de la Knoppix sont faits en 3 parties car cela permet ainsi à l'utilisateur de modifier les configurations qui seront par défauts sur le LiveCD. Ces scripts permettent d'ajouter de nouveau logiciels qui soit près à l'emploi dès la première utilisation (ce qui est très important sur un LiveCD), par l'intermédiaire du système de gestion de paquets apt. Parmi les modifications apportées par rapport à la knoppix on trouve : \begin{itemize} \item La page Web de démarrage est la documentation utilisateur \item Sur le serveur Web, on trouve les scripts clients et la documentation \item Un serveur ftp \end{itemize} Sinon je ne rappelle pas les étapes de la génération de la knoppix qui sont très bien expliquées sur le site de knoppix. \section{Résultats} Le projet a atteint un stade qui le rend fonctionnel. En effet on a put le faire fonctionner sur le réseau informatique d'un des clients de \fws \,. Ce fut l'occasion de correction de bogues mineurs, mais ce qu'il faut retenir c'est qu'on a pu obtenir un rapport respectant un grand nombre de critères du cahier des charges. Nous pouvons donc faire le point sur les non-conformités au cahiers des charges. puis sur les bogues connus, et enfin sur les choses qui seraient à améliorer. \subsection{Non conformité au cahier des charges} Les points du cahier des charges qui ne sont pas respectés sont les suivants : \begin{itemize} \item On ne teste que si un antivirus est installé, et non s'il fonctionne, \item On ne fait qu'un export latex et non au format docbook, \item On ne fait pas de \textit{brute force} pour tester l'existence de mots de passe triviaux, \item La partie 9 n'est pas faite. \end{itemize} \subsection{Bogues connus} La liste des bogues connus est la suivante : \begin{itemize} \item La gestion des accents est mauvaise sur les scripts Windows : la commande konwert n'est pas appelé avec les bons paramètres, mais la correction n'est pas si évidente car cela demande d'adapter le parse. \item Le script audit\_win\_aux n'est pas parfait : En effet il ne fonctionne pas correctement dans deux cas : \begin{itemize} \item On est loggué sur un domaine Windows \item On est loggué sous le compte nommé administrateur et on n'est pas administrateur. \end{itemize} \end{itemize} \subsection{Améliorations possibles} La liste des améliorations possibles est longue, mais on peut quand même en faire une petite ébauche : \begin{itemize} \item La solution basée sur ntop, n'est pas élégante, et mériterait d'être refaite. Il serait peut être intéressant de contribuer au projet ntop pour qu'il puisse travailler entièrement à partir du fichier pcap et qu'il puisse fournir des exports XML ou python convenables (L'export XML et python ne sont actuellement pas suffisants) \item Actuellement, on ne gère que les systèmes Windows ayant des locales françaises. \item Les scripts configurant les bridges ont des paramètres de configuration qu'on pourrait migrer dans config.py. \item Il manque un script d'update pour le liveCD. \end{itemize} \chapter{Conclusion} Ce stage fut l'occasion de poser une base solide et fonctionnelle à ce projet. Mais le manque de temps m'a obligé à faire des compromis entre une solution élégante mais non fonctionnelle car non terminée et une solution moins élégante mais fonctionnelle. A partir de cette base, les améliorations possibles seront nombreuses : ce projet est donc amené à vivre. Il sera publié sous peu sous Licence GPL \footnote{A l'heure où j'écris ces lignes}. Il sera donc particulièrement intéressant de suivre les réactions de la communauté. D'un point de vue plus personnel, ce projet fut très enrichissant par les connaissances à la fois dans les domaines techniques et sur le monde de l'entreprise (via \fws\, et ses clients) que cela à pu m'apporter. En effet le fait d'être dans une petite structure m'a permis de ne pas me limiter à l'aspect technique du projet. En effet, pour moi, le coté commercial d'un projet fut quelque chose de totalement nouveau et donc instructif. \chapter{Glossaire} Ce glossaire est fait essentiellement à partir des définitions présentes sur Wikipédia \footnote{http://fr.wikipedia.org} \begin{description} \item[SSLL] Une société de services en logiciels libres est une société de services en ingénierie informatique spécialisée dans la réalisation de projets informatiques basés sur des logiciels libres. En abrégé SSLL ou SS2L. A la différence des SSII classiques, ces entreprises proposent des prestations (conseil, assistance, formation) développées exclusivement avec des composants logiciel libre. \item[Groupware] « Le groupware est l'ensemble des technologies et des méthodes de travail associées qui, par l'intermédiaire de la communication électronique, permettent le partage de l'information sur un support numérique à un groupe engagé dans un travail collaboratif et/ou coopératif » Jean-Claude Courbon Les Groupware libres les plus connus sont : \begin{itemize} \item OpenGroupware \item phpGroupWare \item eGroupWare \end{itemize} \item[LiveCD] Un Live CD stocke un ensemble logiciel comprenant au moins un système d'exploitation, qu'un ordinateur adéquat animera après amorçage sans aucune installation préalable. NB : il faut entendre Live dans le sens télévisuel de \textit{direct} (et non pas de \textit{vivant}). \item[nmap] Nmap est un scanner de ports open source distribué par Insecure.Org. Il est conçu pour détecter les ports ouverts, les services hébergés et les informations sur le système d'exploitation d'un ordinateur distant. Ce logiciel est devenu une référence pour les administrateurs réseaux car l'audit des résultats de Nmap fournit des indications précieuses sur le niveau de sécurité d'un réseau. \item[nessus] Nessus est un outil de sécurité informatique distribué sous licence GPL. Il permet de scanner un poste à distance et de détecter des vulnérabilités. Nessus se divise en deux parties : nessusd qui est un daemon exécutant les requêtes ainsi que la communication avec la cible, et nessus, une application client qui récupère les données et analyse le résultat. \item[dhcp] Dynamic Host Configuration Protocol (DHCP) est un terme anglais désignant un protocole réseau dont le rôle est d'assurer la configuration automatique des paramètres TCP/IP d'une station, notamment en lui assignant automatiquement une adresse IP et un masque de sous-réseau. DHCP peut aussi configurer l'adresse de la passerelle par défaut, des serveurs de noms DNS et des serveurs de noms NBNS (connus sous le noms de serveurs WINS sur les réseaux de la société Microsoft). \item[SME Server] SME Server est une solution de serveur et de passerelle Internet tout-en-un. Elle permet à presque n'importe quel PC d'assurer les services réseaux standards d'une entreprise (serveur mail, accès Internet, etc\dots). Elle est basé sur le système d'exploitation libre GNU/Linux Red Hat 7.3, et est donc sous licence GPL comme la totalité des logiciels qui la compose. \item[docbook] DocBook est un langage de balisage conçu à l'origine pour la documentation technique informatique (matériel et logiciel). C'est à l'origine une Définition de type de document (DTD) SGML développée par l'éditeur O'Reilly pour les besoins de l'édition technique (et plus particulièrement informatique). Elle a été portée depuis sous forme de schéma XML. Actuellement maintenu et standardisé par le DocBook Technical Comittee du consortium OASIS, DocBook XML peut être utilisé pour tout type de documentation technique (rapports, normes, documentation, etc.). La grande force de DocBook est d'être un format XML totalement orienté sémantique, il n'inclut en effet aucune information de mise en forme ce qui permet d'utiliser ensuite la documentation ainsi structurée par tout type de support / lecteur. Un ensemble de feuille de styles XSLT est disponible pour transformer des documents DocBook vers de nombreux formats comme HTML, PDF, RTF, JavaDoc, etc. DocBook est en train de s'imposer comme le format standard pour la documentation logicielle (notamment dans la communauté Open Source) et commence à être utilisé dans l'industrie. La normalisation par l'OASIS devrait d'ailleurs le rendre de plus en plus prisé. \item[spyware] Un logiciel espion est un logiciel malveillant qui infecte un ordinateur dans le but de collecter et de transmettre à des tiers des informations de l'environnement sur lequel il est installé sans que l'utilisateur n'en ait conscience. \item[SMB] Le protocole SMB (Server Message Block) est l'ancien nom du protocole permettant le partage de ressources (fichiers et imprimantes) sur des réseaux locaux avec des PC sous Windows. Dans les dernières versions de Windows, il est appelé CIFS. \end{description} \appendix \chapter{Bibliographie} \begin{description} \item[http://python.org] Site officiel du langage python : La documentation du langage y est complète. (en anglais) \item[http://www.amk.ca/python/howto/regex/] Howto sur les expressions régulières en python. (en anglais) \item[http://www.yolinux.com/TUTORIALS/LinuxSecurityTools.html] Liste de liens intéressants sur les outils de sécurité. (en anglais) \item[http://www.yolinux.com/TUTORIALS/LinuxTutorialInternetSecurity.html] Howto sur la sécurité d'un serveur. (en anglais) \item[http://sysinternals.com] Site de l'éditeur de Pslist et Psinfo (en anglais) \item[http://su2.info/doc/arpspoof.php] Howto sur l'ARP spoofing (en anglais) \item[http://nwalsh.com/docs/tutorials/winwriters2001/] Introduction à docbook (en anglais) \item[http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html] Liste des outils de contrôle de réseau. (en anglais) \item[http://www.linux-france.org/prj/inetdoc/securite/tutoriel/] Présentation des différents problèmes de sécurité et les moyens de s'en protéger (en français) \item[http://www.linuxjournal.com/node/8172/print] Howto configuration d'un bridge (en anglais) \item[http://www.laas.fr/~matthieu/cours/latex2e/] La célèbre \textit{courte introduction au \LaTeX} (en français) \item[les pages man] (en anglais) \item[La base de données des paquets debian] utilisable via les commandes apt-cache search et apt-cache show. (en anglais) \item[http://www.knoppix.net/wiki/Knoppix\_Remastering\_Howto] Howto \textit{Knoppix Remastering} (en anglais) \end{description} \chapter{Les documents commerciaux} \begin{figure}[!ht] \includegraphics[width=14cm]{images/rouge1.eps} \caption{Recto du document commercial ayant servis à la rédaction du cahier des charges} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/rouge2.eps} \caption{Verso du document commercial} \end{figure} \chapter{Copie d'écran d'un exemple de rapport} \section{Début} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-page1.ps} \caption{Première page du rapport} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/tableofcontents.ps} \caption{Table des matières : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/tableofcontents2.ps} \caption{Table des matières : suite} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/tableofcontents3.ps} \caption{Table des matières : fin} \end{figure} \clearpage \section{Structure du réseau} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-topology.ps} \caption{Partie structure du réseau} \end{figure} \clearpage \section{Service accessible en interne} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-SIA.ps} \caption{Partie Services internes accessibles : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-SIA2.ps} \caption{Partie Services internes accessibles : suite} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-SIA3.ps} \caption{Partie Services internes accessibles : suite} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-SIA-resume.ps} \caption{Partie Services internes accessibles : résumé global} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-SIA-resume2.ps} \caption{Partie Services interne accessibles : résumé par machine} \end{figure} \clearpage \section{Partage réseau} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-share.ps} \caption{Partie Partage réseau : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-share2.ps} \caption{Partie Partage réseau : fin} \end{figure} \clearpage \section{Test anti-intrusion} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-extern1.ps} \caption{Partie Test anti-intrusion : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-extern2.ps} \caption{Partie Test anti-intrusion : fin} \end{figure} \clearpage \section{Trafic réseau} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-net1.ps} \caption{Partie Trafic réseau : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-net2.ps} \caption{Partie Trafic réseau : suite} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-net3.ps} \caption{Partie Trafic réseau : fin} \end{figure} \clearpage \section{Configurations matérielles} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-hard.ps} \caption{Partie Configurations Matérielles} \end{figure} \clearpage \section{Configurations logicielles} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-soft.ps} \caption{Partie Configurations logicielles : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-soft2.ps} \caption{Partie Configurations logicielles : fin} \end{figure} \clearpage \section{Protection des données} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-protec.ps} \caption{Partie Protection des données} \end{figure} \clearpage \section{Annexe Nessus} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-nessus1.ps} \caption{Annexe Nessus : début} \end{figure} \begin{figure}[!ht] \includegraphics[width=14cm]{images/screenshot/2-nessus2.ps} \caption{Annexe Nessus : suite} \end{figure} \clearpage %\chapter{Copie d'écran du liveCD} %TODO \clearpage \chapter{Documentation utilisateur} \include{aux/user} \chapter{Documentation développeur} \include{aux/devel} \chapter{L'API} \include{aux/latex/config-module} \include{aux/latex/fs_stat-module} \include{aux/latex/hotfix-module} \include{aux/latex/netraf-module} \include{aux/latex/network-module} \include{aux/latex/pc_parse-module} \include{aux/latex/prog-module} \include{aux/latex/report-module} \include{aux/latex/sniff_parse-module} \include{aux/latex/spyware-module} \end{document}