Projet technique Philippe DUMONT. Logs de firewall. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 1 / 36

Transcription

1 Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 1 / 36

2 Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 2 / 36

3 SOMMAIRE Introduction Etat de l'art Traitement des logs Affichage des logs Concrétisation du projet Des objectifs en changement constant Iptables n'est pas l'outil ultime Iptables ne logge pas le contenu des paquets Des attaques bien cachées Certains paquets ne sont pas loggés Faux positifs et vraies attaques non signalées Notre logiciel Les premières études Le codage Le résultat final Conclusion...29 Annexes...30 A.1. Fichier de configuration de notre logiciel...30 A.2. Création des tables de la base de données...34 A.2.1. Table "done" A.2.2 Table full_logs Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 3 / 36

4 INTRODUCTION La sécurité d'un réseau passe non seulement par la prise de mesures déjouant les attaques (patches...), mais également par sa surveillance. Pour ce faire, on a besoin de consulter ce qu'on appelle communément les fichiers de logs des logiciels de sécurité, c'est-à-dire les rapports d'activité des dits logiciels. Pour notre projet technique, nous avons choisi de réaliser un logiciel capable de mettre en forme les logs du firewall natif Linux Iptables et de détecter les traces suspectes présentes dans celui-ci. Ce logiciel a donc un double rôle : celui de traitement des logs, mais également celui de leur présentation. Dans un premier temps, nous expliquerons toute la phase d'approche du projet, à savoir l'étude de l'existant. La deuxième partie concerne le projet lui-même, et notamment les changements d'objectifs successifs et les problèmes rencontrés. Une conclusion terminera ce dossier. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 4 / 36

5 1. ETAT DE L'ART Comme dans tout projet, nous avons effectué des recherches pour connaître l'existant concernant le traitement des logs d'iptables. De telles recherches, lorsqu'elles se révèlent positives, permettent de s'en inspirer, voire d'en repartir pour développer autour TRAITEMENT DES LOGS La recherche a été rapide concernant le traitement des logs proprement dit : il n'existe à l'heure actuelle aucun logiciel permettant de traiter les logs Iptables afin d'y chercher des enregistrements ou des séquences d'enregistrements suspects. Nous y reviendrons dans la deuxième partie de ce dossier. Il existe bien des outils plus génériques tel que LogSurfer 1, mais ils sont justement trop génériques et ne correspondent pas à nos besoins exprimés. Nous passerons également sur les produits professionnels, comme par exemple NetSecure Log 2. Les fonctionnalités sont très étendues. C'est un logiciel très adaptable, puissant, souple. Cependant, il fait partie de cette série de logiciels dont on dit que le prix est à hauteur de ses capacités : il faut compter environ euros pour une licence ; et en outre le produit nommé paraît maintenant abandonné. Il appartient à ces logiciels professionnels efficaces, dont le prix en limite très fortement la propagation. Ceci ne fait que renforcer l'attrait de notre projet, à savoir : accomplir la même tâche en libre. 1 LogSurfer : 2 NetSecure Log : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 5 / 36

6 1.2. AFFICHAGE DES LOGS La deuxième partie de la recherche s'est faite sur ce qui existait déjà en matière de parsing et d'affichage des logs d'iptables L'exemple parfait du logiciel qui fonctionne sans toutefois être satisfaisant est Fwanalog 3. Il se base sur un logiciel appelé Analog 4. Le FW signifie "firewall". Fwanalog est un outil de mise en forme de logs de différents firewalls, sous différents systèmes. Il n'est pas exclusif et peut traiter les logs de firewalls sous freebsd par exemple. Pour ce faire, il se base sur un outil de traitement des logs de serveurs web. Il procède en deux étapes : il transforme tout d'abord les logs du firewall concerné en logs de serveur web. Il envoie ensuite le résultat à Analog, qui se charge de mettre en forme les résultats obtenus, en ajoutant des graphiques, des statistiques, etc. Outre le fait que les rapports ne soient pas vraiment "navigables" : une seule page, couverte de graphiques et de statistiques, le mécanisme de fonctionnement est de loin le moins pratique que nous ayons pu trouver parmi tous les logiciels de parsing. Une autre piste que nous avons explorée est un outil traitant des logs de serveurs pour un jeu en ligne appelé "Ennemy Territory". Le serveur génère des logs, et le logiciel les met en forme de manière convaincante. Nous pensions pouvoir repartir de cet outil pour l'adapter à nos besoins. Cependant, les outils utilisés et la complexité du code auraient demandé un travail bien plus conséquent que de le recréer totalement. C'est donc un outil exclusif, très bon pour sa fonction de base mais non extensible ni adaptable. Nous avons également découvert bon nombre de "petits" parsers de logs Iptables. Manifestement, entre les années 2000 et 2004, c'est un domaine qui a suscité beaucoup de recherches. Cependant, tous les logiciels que nous avons trouvés développés sous licence libre sont maintenant abandonnés. On peut citer par exemple Incident, Securitylog2html, entre autres. Il suffit d'aller sur Freshmeat 5 pour trouver beaucoup de parsers inachevés dont la dernière modification date de 3 ou 4 ans. Arrivés à ce point, nous avons constaté qu'en libre il n'existait rien de réellement solide pour le traitement des logs d'iptables. Cependant, deux projets ont attiré notre attention, et plus particulièrement le second. Il est à noter que ces deux dernières solutions n'ont pas été trouvées lors de la phase de recherche de l'existant. Nous les avons remarquées lors de recherches ultérieures. 3 Fwanalog : 4 Analog : 5 Freshmeat : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 6 / 36

7 Le premier logiciel intéressant est Ulog php 6 duquel on aurait pu repartir aussi... Même si l'esthétique de base laisse un peu à désirer (cf la capture d'écran ci-dessous), il dispose de fonctionnalités "avancées" telles que l'interfaçage avec une base de données. La mise en forme telle que montrée ci-dessus est spartiate. Cependant, Ulog possède des caractéristiques très intéressantes : monitoring en temps réel (les logs vont directement dans la base de données), possibilités d'effectuer des requêtes ciblées pour trouver des paquets précis, entre autres. La seule chose qui nous ait empêché de repartir de cette base pour notre logiciel est le fait que nous ne l'ayons découverte que très tardivement! A environ un mois de la fin du projet, il devenait très difficile de l'utiliser comme nouvelle base. 6 Ulog php : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 7 / 36

8 Cependant, même sans considérer Ulog php, il existe un projet très récent (fin décembre 2004) que l'on a découvert juste après sa sortie : Firewall Eyes 7. Il s'agit d'un outil passé récemment en libre par une entreprise de sécurité. Il présente les logs Iptables qu'on lui donne en entrée, à condition que ces logs soient dans un format pré-établi, pour les ressortir sous la forme d'un site PHP. Les fonctionnalités intéressantes sont montrées sur la capture ci-dessous : Outre la présentation intéressante, Firewall Eyes dispose d'une multitude d'outils accessibles via un simple clic sur une des flèches situées à côté des informations. Chacune entraîne sur une page particulière où l'on peut utiliser sur chaque information une série d'outils afin de récolter un maximum de précisions. Par exemple, pour une adresse IP, on pourra lancer automatiquement une recherche sur Google, vérifier si un serveur web se cache derrière cette adresse, faire un whois... Firewall Eyes propose donc une bonne solution pour traiter des logs. Cependant, ce n'est pas réellement le produit que nous recherchons. La présentation, comme on peut le voir, n'est guère attrayante, il n'y a pas d'interactions avec une quelconque base de données, et surtout aucun traitement n'est effectué sur les logs proprement dits (affichage en brut). Vu la base existante, nous avons quand 7 Firewall Eyes : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 8 / 36

9 même décidé de repartir de ce logiciel pour fabriquer notre outil. Un avantage indéniable est qu'il est écrit en php, et qu'il est donc hautement portable. Ce projet technique trouve toute sa justification ici : il n'existe à l'heure actuelle aucune solution libre performante de traitement et de mise en forme des logs de Iptables. Il existe bien quelques logiciels. Cependant ceux-ci ne sont guère satisfaisants, que ce soit à cause de la présentation inadéquate, ou des mécanismes de mise en forme codés sans rigueur. Ces programmes sont ni évolutifs ni optimisés. Il n'existe pas encore de programme achevé et performant. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 9 / 36

10 2. CONCRETISATION DU PROJET Maintenant que nous avons dressé un état de l'art, nous pouvons aborder le sujet du projet proprement dit. A l'origine, il s'agissait non seulement d'un outil de présentation, mais également de traitement des logs d'iptables. Ces traitements devaient nous permettre de retrouver des schémas d'attaques connues, afin d'effectuer toute sorte d'action, notamment préventives : alerte de l'administrateur par différents moyens (mails, voire flux RSS) Seulement, au fur et à mesure que le sujet a avancé, nous avons rencontré certains problèmes remettant en cause le sujet lui-même DES OBJECTIFS EN CHANGEMENT CONSTANT L'objectif initial était un outil complet de reporting. Seulement, au fur et à mesure des recherches effectuées sur le sujet, nous avons constaté que certaines dispositions techniques limitaient nos possibilités d'actions, et nous empêchaient de remplir tous les objectifs initiaux IPTABLES N'EST PAS L'OUTIL ULTIME Il s'agit avant tout, il faut le rappeler, d'un firewall. Son rôle est de bloquer ou d'autoriser la réception, l'émission ou la transmission des paquets selon certaines règles établies. Ses rapports sont assez "bruts" et ne contiennent pas forcément toutes les informations voulues. A ce point, Iptables se comporte plus comme un élément "inactif" qui ne fait que filtrer selon les règles qui lui sont imposées. Ses logs ne font donc que recenser ce qui passe par lui, sans rien faire d'autre. Ce qui nous amène au deuxième point. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 10 / 36

11 IPTABLES NE LOGGE PAS LE CONTENU DES PAQUETS C'est sûrement le plus gros problème relatif à Iptables rencontré dans l'enveloppe de notre projet Hormis les attaques classiques, telles que les paquets malformés évoqués ultérieurement, la grosse majorité des attaques ou du trafic suspect est repérable d'après son contenu et non son contenant. En clair, il est impossible de repérer les paquets dangereux en ne considérant que leurs entêtes. Hors Iptables ne logge pas le contenu et se contente des en-têtes de paquets. Par contre en considérant le contenu des paquets, les "offensifs" deviennent visibles. Il existe bien un module à Iptables permettant de logger le contenu des paquets. Cependant, il ne s'agit pas d'un additif officiel émanant de l'équipe de développement, mais d'un module provenant d'une tierce personne. Bien entendu, il est tout à fait possible d'utiliser ce module. Mais, n'étant qu'une annexe non officielle à Iptables, nous ne pouvons baser notre logiciel sur un élément successible de disparaître brutalement, ou d'évoluer de telle sorte que notre projet devienne incompatible avec les nouvelles versions. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 11 / 36

12 DES ATTAQUES BIEN CACHEES Notre question après la réflexion précédente a été de savoir ce qu'il était alors possible de détecter sans examiner l'intérieur des paquets. Pour ce faire, la solution retenue a été empirique : regardons toutes les règles qu'un IDS utilise et voyons ce que les IDS peuvent logger sans regarder le contenu des paquets. Nous nous sommes basés sur Snort 8, qui possède une série de règles très claires et très bien faites, lisibles et couvrant la grande majorité des attaques possibles sur un réseau (et plus généralement couvrant tous les trafics suspects, entrant ou sortant). Exemple de règle Snort, tiré du fichier multimedia.rules, détectant l'utilisation de programmes de visionnage de contenu audio et/ou vidéo : alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"multimedia Quicktime User Agent access"; flow:to_server,established; content:"user-agent 3A Quicktime"; nocase; classtype:policy-violation; sid:1436; rev:5;) Le champ qui nous intéresse tout particulièrement est le champ "Content". Comme sa traduction l'indique, il s'agit du champ indiquant à Snort qu'il doit logger les paquets contenant cette chaîne de caractères. Une fois que l'on connaît cette particularité, il suffit de chercher dans les fichiers de règles tous les enregistrements ne contenant pas ce champ "Content". Et c'est là que se pose le problème. Sur plusieurs milliers d'attaques et autres trafics suspects détectables par Snort, il n'en existe pas plus d'une vingtaine se basant sur autre chose que le contenu de paquets. Une vingtaine sur plusieurs milliers, le rendement est très faible. Du strict point de vue de la détection, Iptables ne peut donc pas faire grand chose. Nous avons donc demandé à notre professeur de sécurité, Nicolas MONIER, si nous n'avions pas laissé échapper une possibilité. Il s'est donc avéré qu'il n'est possible de détecter que des scans au niveau des logs d'iptables. Au-delà de ce problème, un autre plus important s'est imposé CERTAINS PAQUETS NE SONT PAS LOGGES Un certain nombre de paquets reçus ne sont pas loggés. Dans certaines situations rejet d'un paquet trop long Iptables ne logge tout simplement pas les paquets. Ceci crée un déficit d'information assez important, étant donné qu'il peut s'agir de paquets forgés intentionnellement. 8 Snort : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 12 / 36

13 FAUX POSITIFS ET VRAIES ATTAQUES NON SIGNALEES Le dernier point sur lequel nous avons buté est le problème du trafic qui peut être suspect aussi bien qu'il peut être normal. Prenons un exemple concret : ICMP. C'est un protocole dont les paquets sont indispensables au maintien du réseau. Il faut donc les laisser passer. Cependant, il a été recensé près de 6000 attaques possibles avec ICMP... dont des attaques possibles avec des paquets considérés comme sûrs en temps normal. On ne peut donc pas les bloquer. Sur le trafic ICMP, il est tout juste possible de bloquer de manière sûre entre 5 et 8 attaques. Le reste est trop incertain pour qu'il soit pertinent d'appliquer cette méthode. Bref, un firewall n'est pas un IDS. Ce constat peut sembler évident, mais à première vue on peut penser qu'il est possible d'effectuer des actions et des recherches sur les logs alors que l'on est très limité. Pour effectuer ce travail de détection de trafic suspect, il faudrait transformer Iptables et ses logs en IDS et logs d'ids. Cela n'est pas le but de notre projet. En conséquence, le sujet a bien évolué entre nos premiers pas et aujourd'hui. Plus que le traitement des logs proprement dits pour en tirer des informations, nous avons préféré combler une lacune, celle de la présentation. Comme indiqué dans la première partie, il n'existe pas de solution libre viable présentant les logs de manière convaincante et claire. Nous avons décidé de l'entreprendre. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 13 / 36

14 2.2. NOTRE LOGICIEL Le sujet était clair : réaliser un parser de logs Iptables, propre visuellement et syntaxiquement. Il devait être portable, facilement configurable et modifiable. Partant de ce principe, nous avons lancé notre réflexion LES PREMIERES ETUDES Quelle est la première chose à laquelle nous avons réfléchi? Les technologies que nous allions utiliser. A la base, nous étions partis sur du xhtml (de type transitional) afin d'assurer un maximum de compatibilité sur les systèmes que nous voulions toucher (Linux et Windows). Avec tout ce qui est technologies des feuilles de style, la compatibilité avec tous les navigateurs du marché est assurée. On doit noter deux choses : dès le début nous nous sommes orientés vers une présentation des données typées "page web" et présentables avec un navigateur. Secondo, le schéma xhtml était "à notre charge" : libre à nous de créer notre propre schéma. La seule contrainte imposée est qu'il devait être conforme aux standards établis par le W3C. Un inconvénient majeur de cette solution apparaît immédiatement : la conception est lourde. Nous étions obligés de concevoir un schéma xhtml. Le temps à y consacrer eut été important. Nous nous sommes dirigés vers une autre technologie, portable, facile à mettre en œuvre, standard, compatible avec toutes plates-formes : PHP. PHP implique une complète interopérabilité, une compatibilité avec tous les navigateurs, et tous les systèmes (exception faite des clients en mode texte tels que Lynx par exemple). PHP était donc un passage obligatoire. Mais il existait déjà sûrement des templates de sites web modifiables selon nos exigences. Ce genre de template, maquette où il suffit de rajouter un contenu comme une structure de site web, existe déjà. Entre autres, PWSphp 9 propose une panoplie de modules très étendue, dont un analysant les logs de visite de site Web. 9 PWSphp : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 14 / 36

15 Vous trouverez ci-dessous une capture d'écran de ce module. Cette présentation n'est peut-être pas très adaptée à notre projet, mais la souplesse de ce système fait que l'on peut créer des sites aussi dépouillés que complets, avec juste ce dont on a besoin. Entre autres, il gère nativement les flux RSS (utile pour regarder à distance les résultats du traitement), est très modifiable (grande souplesse dans la mise en page)... Cependant, nous sommes partis sur cette solution avant de trouver Firewall Eyes. Non seulement nous disposons du contenant, un site en PHP, mais également d'une partie du contenu, puisque Firewall Eyes met en forme des logs Iptables de forme prédéfinie. De même, nous nous étions plutôt orientés vers Perl afin d'extraire en brut les informations des fichiers. Firewall Eyes venant avec son propre moteur de parsing intégré à sa structure PHP, plus aucune technologie extérieure n'est nécessaire. Le 100 % PHP est donc possible. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 15 / 36

16 La question suivante concerne l'incorporation d'une base de données dans l'application. Le problème est, que si nous voulons nous en passer, nous avons à réinventer le principe du parcours d'une base de données, puisque nous devons effectuer des recherches dans les fichiers. Mais d'autre part, le système en serait considérablement alourdi, nous évoquerons ce problème ultérieurement. Le second problème lié à l'absence d'une base de données concerne d'avantage l'utilisation du logiciel. Sans base de données, il devient difficile de produire un logiciel réellement performant. La raison en est simple : les fichiers de logs Iptables sont d'une longueur assez importante, et d'un poids pouvant atteindre plusieurs dizaines de Mega-octets. En les traitant "en brut", nous pouvons remarquer qu'il est difficile de savoir jusqu'où le traitement des logs a été effectué, d'une exécution à l'autre du programme. Comment marquer l'avancement du traitement dans le fichier? Ce procédé n'est pas le meilleur puisque de toute façon nous serions obligés de parcourir à nouveau tout le fichier pour le retrouver. Autre solution examinée : effectuer des manipulations sur les fichiers afin de déplacer dans un autre fichier tous les logs déjà traités, les différenciant ainsi "physiquement" des non encore parsés. Cette solution paraît simple, mais la réutilisabilité des fichiers n'est pas vraiment bonne : on arriverait à une somme conséquente de fichiers de logs déjà utilisés. Notamment, pour revérifier les logs parsés une semaine auparavant, il aurait fallu choisir le fichier sur lequel relancer tout le logiciel! La perte de temps aurait été considérable. La mise en place d'une base de données ne présenterait que des avantages. En la remplissant avec les logs parsés, les recherches d'informations seraient rendues beaucoup plus aisées et rapides. Le tri des logs, pour connaître ceux déjà traités, pourrait simplement se faire sur la date ; ainsi une recherche dans les logs antérieurs, ne demanderait que quelques requêtes. Pour traiter de nouveaux logs, on les ajoute à la base de données. Elle devient alors un élément incontournable. Sa structure est décrite en annexe. Avec PHP et une base de données, nous tenons notre solution. Il faut maintenant définir la présentation des données, en essayant de ne pas retomber dans les travers des produits existants. Le principe de base est qu'un graphe complet est préférable à une série de chiffres, dont il est complexe de tirer des informations. De même, la présentation globale devait être lisible, il fallait alors oublier la présentation de Fwanalog, avec une seule page couverte de chiffres et graphiques. Une présentation plus "atomique" et plus concise est souhaitable. Tous les outils que nous avons vus proposent au mieux une longue liste de diagrammes et de chiffres comme en témoigne la capture suivante. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 16 / 36

17 Le problème exposé sur l'image ci-dessous est aisé à comprendre : on remarque immédiatement la barre de défilement à droite, d'une taille significative. Ce principe régit l'ensemble du rapport : une suite de graphiques et de chiffres complexes à lire. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 17 / 36

18 Nous avons cependant été interrompus dans nos recherches, par la découverte de Firewall Eyes, qui propose une présentation bien plus évoluée. On a toujours les listes de logs comme montré dans l'état de l'art. Un clic sur une des flèches renvoie à un écran tel que celui-ci : La flèche à côté de chaque adresse IP conduit à un menu permettant d'exécuter des services : whois, nmap, test d'un site Web... Cliquer sur un bouton affiche les résultats dans le cadre du dessous. Exemple avec un ping : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 18 / 36

19 Les flèches présentes à côté des ports et services amènent à une page quasi-identique, proposant des services adaptés aux ports : Le premier bouton amène à la description du port sur un site de sécurité informatique, le deuxième donne la liste complète des ports et le troisième lance une recherche avec Google. L'ergonomie de cette solution semble correspondre à ce que nous recherchons : une page d'informations globales à partir desquelles on peut obtenir plus de renseignements sur un point précis. Cependant, si la base est bonne, il manque encore beaucoup de fonctionnalités recherchées : des graphiques de moyennes, des chiffres significatifs La base est excellente, on doit maintenant la compléter. Enfin, nous devons décider de quelle manière réaliser les graphes. PHP fournit des primitives assez basiques de traçage de lignes et points, à partir desquelles il est théoriquement possible de tracer tous les graphiques imaginables. Nous avons par ailleurs trouvé nombre de tutoriaux indiquant comment procéder. Le principal inconvénient est la masse de code nécessaire pour tracer ne serait-ce que le plus simple des graphiques : plusieurs dizaines de lignes. Trouver une "surcouche" à ces fonctions graphiques est indispensable. Il en existe de très nombreuses. Il est à noter que malgré la facilité induite par l'utilisation d'une telle bibliothèque, les graphiques restent difficiles à générer. Nous y reviendrons ultérieurement dans ce dossier. A l'issue de cette phase de réflexion sur l'existant et sur les moyens à mettre en œuvre pour achever notre projet, nous étions prêts à passer à la phase la plus importante : la concrétisation. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 19 / 36

20 LE CODAGE Le logiciel se présentant sous la forme d'un site en PHP, et au vu de nos moyens personnels, nous avons opté pour un système Windows XP. Il a donc fallu prendre un serveur web capable de gérer le PHP. Nos exigences en termes de fonctionnalités n'étant pas très poussées, nous nous sommes tournés vers EasyPHP, incluant Apache et MySQL pré-configurés. Travailler sous Windows pose également quelques contraintes évoquées ultérieurement. Nous disposons d'une base de données. Quelle peut en être la structure? Au début, nous avions pensé constituer une unique table contenant toutes les informations du fichier non triées. C'est la possibilité la plus simple, mais également la moins évidente du point de vue des avantages. Avec cette unique table, nous n'aurions qu'un gain de vitesse de traitement, par rapport à la solution comprenant plusieurs tables de données prétraitées. Cependant, nous nous sommes heurtés à un problème indépendant de notre volonté, ce que nous croyons être un problème d'implémentation. En multipliant le nombre de tables, nous multiplions également le nombre de requêtes par log, lors de l'insertion. Un fichier de logs de Iptables peut contenir jusqu'à plusieurs dizaines voire centaines de milliers de lignes pour les plus gros. Or, ce volume à traiter, sous Windows, provoque un plantage de la base de données. Un message d'erreur nous indique la fermeture de la socket. Il semblerait que ce problème vienne de Windows lui-même, puisque des tests sous Linux montrent que ce problème ne se pose pas. Les conditions matérielles sont pourtant relativement similaires : la machine de développement est un portable avec un processeur Centrino à 1.4GHz et 512Mo de mémoire, la machine de test est un Athlon XP avec 512Mo de mémoire. Nous nous sommes alors intéressés à la consommation de ressources de ce logiciel, et le constat est assez intéressant : sous Windows, EasyPHP consomme toutes les ressources disponibles sans les libérer. Ceci n'est pas un problème dans le sens où il devra tourner principalement la nuit, mais il faudra le tester sur la machine cible afin de tester la robustesse de notre application. Au final, nous avons opté pour une base mélangeant les concepts de table unique et de tables multiples. Nous obtenons deux tables, une contenant les logs en brut (table full_logs) et une contenant ce qui a déjà été inséré dans la première (table done). Le cœur du travail nous attendait encore, puisque nous n'avions que Firewall Eyes. Nous pensions à l'origine que les modifications à apporter ne seraient que superficielles par rapport à ce qui existait déjà. Cependant, au fur et à mesure de l'avancement du projet, nous aurons à apporter de plus en plus de modifications. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 20 / 36

21 Les modifications à apporter sont importantes : interfaçage avec la base de données, calculs en tout genre pour les moyennes, ajouts de fonctionnalités, intégration de graphiques Au final, la structure même du code de Firewall Eyes a complètement été refondue et adaptée à nos besoins. Le seul point commun entre ce que nous avions à l'origine et notre solution est le fichier de configuration dans lequel on indique les champs à afficher et une expression régulière donnant la forme globale des lignes de logs d'iptables, et la feuille de style. Cependant il ne persiste qu'une partie du fichier de configuration. Il est à signaler qu'au cours de notre développement, nous avons quand même eu un certain nombre de difficultés avec le code PHP de Firewall Eyes : celui-ci générait une quantité d'erreurs et de warnings très importante. Si nous pensions au début pouvoir régler ce problème par les réglages de PHP, il nous a été justement signalé qu'un administrateur ne devrait pas avoir à modifier sa configuration logicielle pour que notre application fonctionne. Nous avons alors ajouté une commande pour ne pas afficher ces messages d'alerte. Ce problème réglé, il faut maintenant insérer dans le logiciel tout ce dont nous avions besoin, et principalement les statistiques. Les modifications du code étant parfois vraiment lourdes, et le langage PHP n'étant pas l'objet du dossier, nous passerons sur cet aspect pour en venir directement au résultat obtenu. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 21 / 36

22 LE RESULTAT FINAL Commençons tout d'abord par présenter le résultat obtenu. Pour se rendre compte des changements effectués, nous pouvons nous fier aux captures de Firewall Eyes présentées précédemment. La première étape d'utilisation est d'ajouter les logs à la base de données. On choisit le fichier à ajouter et on clique sur "Add to DB", ce qui amène à cet écran : Si les logs, pour le mois donné, sont déjà présents dans la base, on obtient le message suivant : Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 22 / 36

23 Pour visionner les logs, il suffit de cliquer sur "Read". Il est possible de filtrer les résultats en utilisant les champs prévus à cet effet. Si aucun log ne correspond à ce filtre, l'affichage reste vide. Les logs s'affichent alors en bas de page. On remarque que par rapport aux informations fournies dans Firewall Eyes, on obtient beaucoup plus de champs. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 23 / 36

24 En cliquant par exemple sur un protocole, on obtient la page de services disponibles pour le protocole. Le bouton "stats" nous permettra alors d'afficher les statistiques par protocole. Il en est ainsi pour tous les types d'informations affichées. Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 24 / 36

25 Maintenant, intéressons nous aux conséquences des filtres sur les graphes affichés. Prenons un exemple concret : voici les statistiques des TTL sans filtre : On y voit un graphe par année, ici 2003 et Master TIIR 2 LILLE BARBIEU FRANCK & GARDON ROMAIN 25 / 36