\section{Introduction} Fwlive est un ensemble de script présent sur un liveCD permettant de faire un mini-audit de sécurité. Le liveCD a le grand avantage d'avoir un environnement qui soit toujours le même. Et vu le nombre de logiciels qui sont utilisés, cela représente un avantage considérable. Dans ce rapport nous ne développerons pas l'api : en effet celle-ci est générée automatiquement via les docstring et epydoc. \section{Structure global du projet} %remarque sur les langages Le langage principalement utilisé pour ce projet est le python. En effet il existe 2 langages particulièrement adaptés à la récupération d'informations et au traitement de celles-ci (spécialement sous forme de texte) qui sont le perl et le python. Le python étant plus facilement lisible et étant plus à l'aise avec ce langage, le choix s'est porté sur le python. Pour certains scripts, il était plus commode de faire de simples scripts shell. Nous avons donc parfois utilisé le sh. Tous les fichiers sh ou python ont respectivement l'extension .sh ou .py (exécutable compris) car cela donne des facilités aux développeurs (l'éditeur de texte peut charger automatiquement le mode adapté suivant le type de script). \subsection{L'arborescence} \subsubsection{Fichier} \begin{description} \item[archive.sh] script permettant aux développeurs de créer rapidement une archive du projet, \item[install.sh] script permettant l'installation des scripts, \item[config.py] fichier contenant la configuration par défaut, \item[script\_interne.py, script\_externe.py, audit.py] script python : dont le rôle est détaillé dans la doc utilisateur. Il pourrait se trouver dans un répertoire tel que bin, mais pour pouvoir utiliser l'astuce du fwlive\_path on les place ici, \item[sniff\_begin.sh, test\_space.sh, sniff\_end.sh] scripts shell utilisés pour la partie d'écoute du réseau. test\_space permet de stopper le dump quand il n'y a plus assez de place sur le disque. Il sont dans ce répertoire uniquement car il se place au même niveau que les scripts python du point précédent, \item[bridge\_conf.sh, bridge\_del.sh] script sh permettant la configuration du bridge. Il se place ici pour la même raison que le point précédent, \item[fwlive\_path.py] fichier qui une fois adapté et copié dans le path python permet aux développeurs de tester les scripts python au sein de ce répertoire sans avoir à faire une install. \end{description} \subsubsection{Répertoire} \begin{description} \item[audit] contient les modules permettant la génération du rapport (une par partie), \item[client\_script] contient les scripts clients, et les lib permettant de parser les résultats et d'en tirer des résultats intéressants, \item[report] contient la lib permettant de générer un rapport, \item[sniff] contient la lib permettant de parser le résultat du script de sniff \item[getinfo] contient la lib permettant de lancer des scans (nessus, nmap, smbtree, \dots) et de travailler avec les structures de données du scan (en particulier info), \item[common] contient les lib utilisables par tous le monde, \item[data] contient les données comme la liste des hotfix, \item[bin] contient des petits scripts permettant de récupérer en shell, la configuration du config.py \item[knoppix] contient les scripts et les fichiers nécessaires à la génération du liveCD \item[doc] contient la doc utilisateur, la doc développeur, et l'api python qui a été dévéloppée. \end{description} \section{Structure de données} Python offre la possibilité d'utiliser très simplement des tables de hashage. Nous les utilisons beaucoup car cela permet, si nécessaire, d'ajouter très facilement des champs à nos structures de donnée. Un simple \cmd{print ma\_variable} ou un \cmd{print [ma\_variable]}\footnote{Cette deuxième version peut être très pratique car elle permet de voir comment sont codé les chaînes de caractères} permettra ainsi d'avoir une rapide vu de la structure. Nous allons ici détailler les structures les plus importantes. \subsection{info} Cette structure a l'inconvénient de ne pas avoir d'api pour y accéder : On doit 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 et réciproquement . La structure info est un tableau, de structure appelée scan. Le première é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 a 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} 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. \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} \subsection{c\_scr} La structure permettant de collecter les informations des scripts clients étant susceptible de beaucoup bouger, il est indispensable de tous interfacer entre le résultat des commandes et son utilisation. La structure est un dict (table de hashage) dont les clés associent le nom des commandes du script client au résultat déjà parsé. Ensuite les accesseurs utilisés lors de la génération du rapport (fonction commençant par get et une lettre en majuscule font appel à un ou plusieurs éléments de cette structure. \section{Les communications} %Par fichier %dump python Les communications inter-script se font par l'intermédiaire de fichiers. L'utilisateur se charge récupérer tous les fichiers pour les mettre dans le même répertoire. Ce système a l'avantage d'être le plus souple dans la mesure où il permet de faire face à toute les situations, mais cela peu s'avérer fastidieux, en présence d'un grand nombre de poste client. Les noms de fichier utilisés font soit appel à la date soit à un nombre aléatoire : l'objectif étant d'avoir une faible probabilité d'avoir 2 noms de fichier égaux. \subsection{script\_interne.py $\to$ audit.py} Le fichier contient un dump de la structure python scan. En effet python propose un module permettant d'écrire le contenue d'une variable python dans un fichier et de le récupérer. Cette méthode permet ne pas avoir à se soucier de cette étape. \subsection{script\_extern.py $\to$ audit.py} La même méthode est utilisé. \subsection{script client $\to$ audit.py} Chaque script client écrit dans un fichier le résultat des différentes commandes séparées par des balises. Ce fichier est compressé via gzip. Après le transfert du fichier, celui-ci est décompressé et est convertit en fichier texte Unix. Seulement à ce moment commence le travail de parse. \subsection{sniff\_end $\to$ audit.py} sniff\_end permet de récupérer les pages de l'interface web de ntop. Les fichiers sont triés dans une arborescence avec un répertoire par ip et un répertoire total. Les images sont stockées au format eps. A la racine de cette arborescence se trouve le fichier export\_sniff. Toute cette arborescence est compressée. C'est cette archive qui doit être transférée. Le script audit.py le décompressera et le parsera. \section{Les mises à jours} \subsection{Nessus} La mise à jour du serveur nessus se fait par les commandes : \begin{itemize} \item \cmd{apt-get update} \item \cmd{apt-get install nessus-plugins} \end{itemize} Cela doit se faire connecté au net et à chaque utilisation du liveCD, sinon pour que la modification soit prise en compte il faut regénérer un liveCD. \subsection{Le répertoire data} Le répertoire data contient un certain nombre de données utilisées pour générer le rapport. \subsubsection{prog.py} \begin{verbatim} firewall_list = ["zonealarm", "firewall"] antivirus_list = ["avg", "panda", "kaspersky", "mcafee", "bitdefender", "pc-cillin", "f-secure", "symantec antivirus"] \end{verbatim} Ces deux listes sont à maintenir. Pour ce faire il est indispensable d'en connaître le fonctionnement. Pour savoir s'il existe un antivirus d'installé (respectivement un firewall), on regarde si parmi la liste des programmes installés (Pour windows, visible dans le menu Ajout/suppression de programmes), si certains contiennent (sans tenir compte de la casse) une des chaînes de caractère de cette liste. \subsubsection{hotfix.py} \begin{verbatim} Xphotfixlist = ["Q147222", "KB823182", ..... ,"Q823980"] W2000hotfixlist = ["KB870669", "KB896727", ......, "Q147222"] \end{verbatim} Le fichier hotfix.py contient 2 listes à maintenir. Il existe une liste par version de l'os. Pour obtenir cette liste il suffit de mettre à jour l'os et de récupérer les mises à jours via \cmd{psinfo -h} Pour ajouter une liste pour un nouvel os, il faut la créer dans ce fichier, et y faire référence dans audit/software.py, en l'important dans un premier temps et ensuite en y faisant appel dans la fonction gethotfix\_missing. \subsubsection{spyware.py} Ce fichier contient la liste des processus susceptibles d'être un spyware. \section{Dépendance logiciel} \subsection{client script} Les dépendances importantes sont : PsInfo et PsList que l'on peut télécharger au adresses suivante : \begin{description} \item[psinfo] http://www.sysinternals.com/Files/PsInfo.zip \item[pslist] http://www.sysinternals.com/Files/PsList.zip \end{description} Sinon les commandes utilisées sont normalement standard. \subsection{liveCD} Voici la liste des outils utilisés par les différents scripts \begin{description} \item[nessus et nessud] pour tester la sécurité d'une machine, \item[nmap] scanneur de port, pour détecter les machines présentes sur un réseau, \item[ping] pour faire un ping, \item[ifconfig] pour récupérer la configuration des interfaces réseaux, \item[smbtree] pour récupérer des informations sur les partages samba, \item[smbclient] pour se connecter aux partages samba, \item[nmblookup] pour récupérer l'ip connaissant le nom netbios, \item[gunzip] pour décompresser les fichiers générer par les scripts clients, \item[mpost] pour générer des graphes en ps (le camembert), \item[ettercap] pour sniffer les mots de passe, \item[tcpdump] pour capturer le traffic réseau, \item[latex,dvips,ps2pdf] pour générer le rapport, \item[ntop] pour analyser le traffic réseau, \item[wget] pour récupérer les résultats de ntop sur son interface web, \item[convert] qui fait partie du package imageMagic, pour convertir les formats d'images, \item[dos2unix,konwert] pour convertir les fichiers textes venant de Windows, \item[commandes unix standard] cp, mv, rm, tar, find, rename, pkill, mkdir, rmdir, df, sed, tail, head, sleep, echo, nice\dots \item[python et sh] pour pouvoir faire tourner les scripts. \end{description} Voici la liste des outils utilisés par l'utilisateur : \begin{description} \item[tzconfig, uptime, ntpdate] pour mettre à l'heure le système, \item[mount] pour monter des partitions, \item[apt-get] pour faire des mises-à-jour. \end{description} Voici la liste des outils supplémentaires pour générer le liveCD : \begin{description} \item[dd, mkswap,swapon] pour créer du swap supplémentaire, \item[md5sum] pour calculer des md5, \item[mkisofs] pour créer des isos. \end{description} \section{Installation} \subsection{Le script d'install} Le script d'install install.sh est paramétrable via quelques variables qui se trouvent au début du fichier : \begin{verbatim} dir_in_python_path="/usr/local/lib/python2.3/site-packages" install_bin="/usr/local/bin" install_lib="/usr/local/lib/fwlive" config_dir="/etc/fwlive" apache_path="/var/www" \end{verbatim} \begin{description} \item[dir\_in\_python\_path] Cette variable correspond au répertoire dans lequel on placera le fichier permettant de savoir où seront installées les libs. Ce répertoire doit faire partie du path python. \item[install\_bin] Cette variable correspond au répertoire où seront installés les exécutables. \item[install\_lib] Cette variable correspond au répertoire où seront installées les bibliothèques. \item[config\_dir] Cette variable correspond au répertoire où seront installés les fichiers de configuration (dont le fichier config.py) \end{description} Une fois configuré, il suffit d'exécuter le script : \cmd{./install.sh} \subsection{Génération du live CD} \subsubsection{Pré-requis} Les pré-requis de cette partie sont : \begin{itemize} \item Un ordinateur muni d'un disque dur \item Un CD Knoppix (version testé 3.9) \item L'archive fwlive.tgz doit projet \item Du temps (Une petite demi-journée) \end{itemize} \subsubsection{Howto} Cette partie est assez fastidieuse, car elle fait appel à plusieurs scripts. Ce choix a été fait car cela permet plus de liberté et cela permet en cas de problème de ne pas repartir à zéro à chaque fois. La méthode à employé est de booter sur la knoppix avec l'option ``knoppix 2''au démarrage. Une fois que l'on a un shell root, il est conseillé de charger le mappage azerty pour le clavier avec la commande \cmd{loadkeys fr}. On récupère ensuite l'archive que l'on place dans /root et que l'on décompresse sur place avec la commande \cmd{cd /root \&\& tar xvfz fwlive.tgz}. Ensuite on se place dans le bon répertoire : \cmd{cd fwlive/knoppix} On va donc exécuter le premier script qui va préparer la remasterisation de la knoppix. On va donc le paramétrer en éditant le fichier : \cmd{emacs pre-remaster.sh}. Il y a deux variables à configurer : \begin{itemize} \item partition : Cette variable correspond à la partition sur laquelle on va travailler. On a besoin de 5Giga. \item base : Si on travaille sur une partition non vide et que l'on veut pas travailler à la racine de la partition, on peut grâce à cette variable dire dans quel répertoire on veut travailler. \end{itemize} Nous pouvons maintenant lancer le script : \cmd{sh pre-remaster.sh} Ce script est assez long ... Maintenant on va passé à la partie chrooté. On se place sur la partition puis le répertoire que l'on a configuré, par exemple : /mnt/hda3/myrep Ensuite on fait \cmd{cd knx/source/KNOPPIX}. Enfin on se chroot \cmd{chroot .} Maintenant on fait \cmd{cd tmpdir/fwlive/knoppix}, et on va exécuter le script interactif chroot-remaster via la commande \cmd{sh chroot-remaster}\footnote{si vous voulez plus latitude, vous pouvez dans ce script déactiver l'option --yes}. Ce script va d'abord installer fwlive puis va se connecter pour modifier ses paquets. Il va poser un certain nombre de questions auxquel il faut répondre. Pour snort et ntop c'est pas la peine de réfléchir : il faut laisser les choix par défaut. Par contre pour la configuration de la localisation il faut absolument répondre y alors que le défaut est non. Pour le password de ntop on peut mettre ce qu'on veut, en revanche pour celui de nessus et celui du système il est conseillé de mettre en username fwlive et fwlive en password et de laisser les autres paramètres à leur valeur par défaut. Il faut faire attention lors de cette partie car en se basant sur debian sid il se peut qu'au moment où vous exécuter ce script les dépendances soit rompues. Vous pouvez maintenant ressortir du chroot avec exit ou Control D Nous voilà enfin prêt à créer l'iso. Avec les commandes suivantes : \begin{itemize} \item \cmd{cd /root/fwlive/knoppix} \item On modifie le script remaster.sh de la même façon que pre-remaster \item \cmd{sh remaster.sh} \end{itemize} Vous pouvez récupérer l'iso en allant dans le répertoire que vous avez défini puis dans le sous-répertoire knx. L'iso s'appelle fwlive.iso \subsection{Mise à jour} Pour mettre à jour un liveCD, il faut le regénérer, mais cela est assez coûteux. Il existe une solution permettant de se débrouiller quand même. On modifie l'archive (où les données ont été mises à jour), pour les configurations par défaut soit les bonnes (modification des fichiers config.py, install.sh et sniff\_begin.sh). Puis on transforme le script d'install en script d'update en enlevant les lignes suivantes du script qui vont télécharger PsInfo.exe et PsList.exe : \begin{verbatim} mkdir "$apache_path/user_doc" mkdir "$apache_path/dev_doc" cp doc/user_documentation/doc/* "$apache_path/user_doc" -r cp doc/devel_documentation/doc/* "$apache_path/dev_doc" -r cd client_script/win wget http://www.sysinternals.com/Files/PsInfo.zip wget http://www.sysinternals.com/Files/PsList.zip unzip PsInfo.zip rm README.TXT unzip PsList.zip rm README.TXT PsList.zip PsInfo.zip cd .. zip -r audit_win.zip win cp -r win $apache_path cp audit_win.zip $apache_path cd .. \end{verbatim} Il suffit donc de laisser cette archive sur le disque dur, et à chaque boot du liveCD, de faire l'update en réexécutant l'install. \section{TODO} \subsection{La partie trafic réseau} La partie réseau utilise ntop et cela pose plusieurs problèmes : \begin{itemize} \item Le travail effectué par sniff\_begin.sh et sniff\_end.sh n'est pas minimal. Ce qui était un objectif pour limiter au maximum le risque d'erreur chez le client, et pour pouvoir faire tourner les nouvelles versions du programme sur d'ancien projet (ensemble des résultats des scripts). Un autre problème est qu'on ne peut pas du tout modifier les graphes car ils sont repris tel quel de ntop. Il faudrait donc ne plus utiliser ntop et uniquement se baser sur la capture faite par tcpdump. \item Regarder s'il est possible et dans quel mesure de ne plus se baser sur les ports pour connaître le service associé à un trafic. \end{itemize} \subsection{Script Unix} Créer le script unix, signifie également faire les parses correspondant à ce script et les fonctions d'accès. Cela demande également de modifier les partie de génération du rapport concernant le software. \subsection{Script Windows} \begin{itemize} \item Corriger le bogue sur les accents \item Mieux tirer parties des résultats, par exemples les groupes globaux, pour les machines gérant un domaine \end{itemize} \subsection{Script update} Le problème du liveCD est que les mises à jour sont assez pénible, et doivent être faites à chaque boot. Il conviendrait donc de créer un script d'update qui soit assez simple pour résoudre ce problème. Il existe actuellement une solution \textit{proche du bricolage} qui consiste à prendre la nouvelle archive et réinstaller au dessus de ce qui existe, en enlevant dans le script d'install la partie la partie correspondant à la récupération de sysinternal. Cette archive avec le script d'install modifié peut être stocké sur le disque dur. Pour faire quelque chose de propre il faudrait inclure l'option d'update au script d'install, ce qui permettrai une factorisation du code. La partie d'update devrait repérer là où cela a été installé la première fois. Dans l'archive pourrai également figurer la dernière version du paquet debian de nessus-plugins, ce qui permettrai lors de l'update (rappel : à exécuter à chaque boot) de mettre également à jour ce paquet. \subsection{La partie 9} Un système de notation pourrait être pas mal \dots \subsection{Export} Un export autre que le latex : Cela demande de réécrire une classe avec les mêmes méthodes que celle du latex. \