AT
Téléchargé parAlaaeddine Tlich
21,054 vues

Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Système et Réseau

Ce document est un rapport de projet de fin d'études pour obtenir un diplôme en informatique, axé sur la création d'une plateforme de supervision et de détection d'intrusion. Il présente une étude comparative des solutions open-source, ainsi que les méthodologies de supervision et de détection d'intrusion mises en œuvre. Le rapport inclut également une discussion détaillée sur les tests d'intrusion et les résultats obtenus.

Intégrer la présentation

Téléchargé 1 222 fois
République Tunisienne Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et de la Technologie -- Université de Carthage CODE: P-TRT-2 Rapport de Projet de Fin d'Etudes Pour l’obtention du diplôme de Licence appliquée en Réseaux de l’Informatique Spécialité: Technologies de l’Informatique et de Télécommunication Intitulé: Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Système et Réseau Réalisé par: Alaadine Tlich Nabil Kherfani Au sein de: Hexabyte Encadré par: M. Nizar Ben Neji Faculté des Sciences de Bizerte M. Rached Ben Hassine Hexabyte Présenté devant le jury composé de: M. Tarek Ben Mena Président Mme. Rim Haddad Rapporteur Année Universitaire 2015 / 2016
Remerciements Merci Dieu de nous avoir donner la force et le courage d’aller jusqu’au bout sans dou- ter de nos compétences. D’abord, nos remerciements les plus sincères à l’encadrant pédagogique M.Nizar Ben Neji pour ses efforts et ses interventions inestimables qui nous ont bien aidé à avancer et aller de l’avant. Nos remerciements s’adressent également à M.Mohamed Ould Lhassan, qui a veillé au bon déroulement du projet et nous a aidé à ameloirer nos compétences grâce aux forma- tions durant la période du stage. Tous nos remerciements vont également à l’encadrant de la société M.Rached Ben Hassin, qui nous a soutenu et guidé tout au long du projet. Un Merci à tous nos amis et surtout l’équipe Cod4Squad qui nous ont bien fait perdre du temps à jouer au lieu de s’occuper de notre travail. Et bien évidemment, merci aux juris qui ont accépté d’évaluer notre travail. _____________________Alâa Eddine Tlich & Nabil Kherfani A.U 2015-2016 1
Table des matières Introduction 9 1 Présentation générale du projet 11 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.2 Composants du réseau . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.1 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.2 Principales attaques et menaces . . . . . . . . . . . . . . . 15 1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.3 Travail à faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Étude Comparative des solutions Open-Source . . . . . . . . . . . . . . . . 17 1.4.1 Outils de supervision . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4.1.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 18 1.4.1.2 Récapitulatif des outils de supervision . . . . . . . . . . . 21 1.4.1.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 22 1.4.2 Outils de détection d’intrusion . . . . . . . . . . . . . . . . . . . . 22 1.4.2.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 22 1.4.2.2 Récapitulatif des IDS . . . . . . . . . . . . . . . . . . . . . 25 1.4.2.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 26 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2 Supervision réseau 27 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Introduction à la supervision réseau . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2 Superviser quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Méthodes de supervisions . . . . . . . . . . . . . . . . . . . . . . . 28 2.3 Installation et configuration de Zabbix . . . . . . . . . . . . . . . . . . . . 28 2.3.1 Installation du serveur Zabbix . . . . . . . . . . . . . . . . . . . . . 28 2.3.2 Configuration du serveur Zabbix . . . . . . . . . . . . . . . . . . . 29 2.3.3 Configuration de la base de données de Zabbix . . . . . . . . . . . . 29 2.3.4 Configuration du serveur apache2 . . . . . . . . . . . . . . . . . . . 30 2.4 Ajout d’une station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.1 Installation d’un agent Zabbix . . . . . . . . . . . . . . . . . . . . . 32 2
TABLE DES MATIÈRES 2.4.1.1 Sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.1.2 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.2 Ajout du nouveau hôte dans le serveur . . . . . . . . . . . . . . . . 33 2.5 Amélioration et Optimisation de la supervision . . . . . . . . . . . . . . . . 33 2.5.1 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.2 Alerte par Courriel électronique . . . . . . . . . . . . . . . . . . . . 36 2.5.3 Supervision des serveur VOIP . . . . . . . . . . . . . . . . . . . . . 37 2.5.4 Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.5.5 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.5.6 Activation de SSL dans apache2 . . . . . . . . . . . . . . . . . . . . 40 2.5.7 Mise à jour de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.5.7.1 installation des packages de la release 3 de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.5.7.2 Installation de Zabbix 3 . . . . . . . . . . . . . . . . . . . 43 2.5.8 Centralisation des logs . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3 Détection d’intrusion 46 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Systèmes de détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.1 Mode de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.2 Types des IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.2.1 Les HIDS (Host-based IDS) . . . . . . . . . . . . . . . . . 47 3.2.2.2 Les NIDS (Network-based IDS) . . . . . . . . . . . . . . 47 3.3 Installation et mise en place de Prelude-IDS . . . . . . . . . . . . . . . . . 48 3.3.1 Installation de Prelude . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1.1 Libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1.2 LibpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.1.3 Base de données Prelude-admin . . . . . . . . . . . . . . . 50 3.3.1.4 Prelude-Manager . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1.5 Prelude-Correlator . . . . . . . . . . . . . . . . . . . . . . 51 3.3.1.6 Prelude-LML . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.1.7 Prewikka . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3.2 Installation des agents de surveillance . . . . . . . . . . . . . . . . . 54 3.3.2.1 Profil Prelude-Manager . . . . . . . . . . . . . . . . . . . 54 3.3.2.2 Sonde Prelude-Correlator . . . . . . . . . . . . . . . . . . 55 3.4 Optimisation de la détection d’intrusion . . . . . . . . . . . . . . . . . . . 56 3.4.1 Utilisation de Prewikka en tant que service . . . . . . . . . . . . . . 56 3.4.2 Utilisation de Prelude-manager en tant que service . . . . . . . . . 58 3.4.3 Utilisation de Prelude-lml en tant que service . . . . . . . . . . . . 58 3.4.4 Démarrage de Prelude lors du « boot » . . . . . . . . . . . . . . . . 58 3.4.5 Ajout d’une sonde HIDS : OSSEC . . . . . . . . . . . . . . . . . . . 58 3.4.6 Ajout d’une Sonde NIDS : Suricata . . . . . . . . . . . . . . . . . . 60 3.4.7 Gestion des règles de Suricata avec Oinkmaster . . . . . . . . . . . 61 3.4.8 Mise en place du HoneyPot Kippo . . . . . . . . . . . . . . . . . . . 62 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 A.U 2015-2016 3
TABLE DES MATIÈRES 4 Exploitation et tests 64 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2 Tests d’intrusion : Pentest . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.1 Méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.2 Plateforme de test d’intrusion . . . . . . . . . . . . . . . . . . . . . 65 4.2.3 Simulations d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.4 Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.3 Interpretation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.4 Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Conclusion général 77 Annexe A 80 A.U 2015-2016 4
Table des figures 1.1 Organigramme d’Hexabyte . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 les motivations des attaques informatiques . . . . . . . . . . . . . . . . . . 14 1.3 Évolution du nombre d’événements détectés par l’ANSI en 2015 . . . . . . 15 1.4 Répartition IP par continent en 2015 . . . . . . . . . . . . . . . . . . . . . 15 1.5 Les techniques de piratage les plus utilisées . . . . . . . . . . . . . . . . . . 15 1.6 Architecture de Centreon et sa relation avec Nagios . . . . . . . . . . . . . 19 1.7 Architecture de Shinken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Liste des scripts développés . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2 démo : “Check Services Status” . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3 Démo : “Disk : Bad Blocks” . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4 Démo : “TopCpu Consumers” . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.5 Démo : “Last Activities” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.6 Exemple d’un message reçu . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.7 Exemple d’un tableau de bord (screen) . . . . . . . . . . . . . . . . . . . . 38 2.8 exemple d’une “map” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.9 Formulaire de création d’une “map” . . . . . . . . . . . . . . . . . . . . . . 39 2.10 GrayLog 2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1 Configuration de libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Configuration de libpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Configuration de Prelude-manager . . . . . . . . . . . . . . . . . . . . . . . 50 3.4 Fichier de configuration de Prelude-manager . . . . . . . . . . . . . . . . . 51 3.5 Configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.6 Fichier de configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . 53 3.7 Fichier de configuration de prewikka . . . . . . . . . . . . . . . . . . . . . 54 3.8 Ajout d’un profil Prelude-manager . . . . . . . . . . . . . . . . . . . . . . 55 3.9 Enregistrement de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.10 l’uid et le gid de Prelude-correlator . . . . . . . . . . . . . . . . . . . . . . 56 3.11 Installation d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.12 Fichier de configuration d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . 59 3.13 ID de l’utilisateur “OSSEC” . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.14 Fichier de configuration de Suricata . . . . . . . . . . . . . . . . . . . . . . 61 3.15 Liste des Sondes Actives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1 Machines VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Réseau de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3 Commande traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4 Scénario Httrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5
TABLE DES FIGURES 4.5 scénario Zenmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.6 Ettercap attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.7 scénario ARP poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.8 Scénario Armitage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.9 Alerte : service web attaqué . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.10 Notifications de niveau bas . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.11 Scanne NMAP détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.12 Scanne détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.13 Fausse alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.14 Prewikka : Graphe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.15 Prewikka : Graphe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.16 Prewikka : Graphe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.17 Prewikka : Graphe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.18 Prewikka : Graphe 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.19 Prewikka : Graphe 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.20 Prewikka : Graphe 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.21 Prewikka : Graphe 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.22 Interface Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.23 Fichier de configuration de Knockd . . . . . . . . . . . . . . . . . . . . . . 81 4.24 Fichier de configuration du lancement automatique de Knockd . . . . . . . 81 4.25 Connexion au serveur via PuTTY . . . . . . . . . . . . . . . . . . . . . . . 82 4.26 Connexion refusé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.27 Scénario d’accès SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.28 Connexion etablie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.U 2015-2016 6
Liste des tableaux 1.1 liste des serveurs et leurs services . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 Tableau comparatif des outils de supervision . . . . . . . . . . . . . . . . . 21 1.3 Tableau comparatif des solutions de détection d’intrusion . . . . . . . . . . 25 7
Abréviations & Acronymes IDS : Intrusion Detection System HIDS : Host-based Intrusion Detection System NIDS : Network-based Intrusion Detection System IPS : Intrusion Prevention System LAN : Local Area Network XDSL : x Digital Subscriber Line ADSL : Asymmetric Digital Subscriber Line VSAT : Vulnerability Self Assessment Tool WIMAX : Worldwide Interoperability for Microwave Access RTC : Réseau Téléphonique Commuté GPS : Global Positioning System ANSI : Agence Nationale de la Sécurité Informatique DOS : Deny Of Service SET : Social Engeneering Toolkit SNMP : Simple Network Management Protocol API : Application Program Interface USM : Unified Security Management SSH : Secure Shell TTY : Terminal Type SSL : Secure Sockets Layer SMTP : Simple Mail Transfer Protocol VOIP : Voice over Internet Protocol TLS : Transport Layer Security IDMEF : Intrusion Detection Message Exchange Format TCP : Transport Control Protocol LML : Log Monitoring Lacke UID : User Identifier GID : Group Identifier DVWA : Damn Vulnerable Web App 8
Introduction A l’heure actuelle, les systèmes d’information ne cesse d’évoluer et leur utilisation de- vient de plus en plus importante. Cependant, la complexité de la maintenance et de la gestion de ces systèmes augmente de jour en jour et le garantie de leur sécurité est de plus en plus difficile. Ces systèmes ont bien mérité leur place au sein des entreprises dans lesquels ils sont devenus indispensables. Un bon réseau est un réseau bien sécurisé. Il est donc favorable de suivre certaines règles afin de garantir l’intégrité des données, la confidentialité, la disponibilité des ser- vices, la non-répudiation et l’authentification des utilisateurs : – Intégrité : Vérifier si les données n’ont pas été modifiées durant la communication de manière intentionnelle ou fortuite. – Confidentialité : Assurer que seules les personnes autorisées aient accès à une res- source quelconque. – Disponibilité : S’assurer qu’un service ou une ressource soit disponible à la demande. – Non-répudiation : S’assurer qu’aucun des correspondants ne pourra nier les tran- sactions qui ont eu lieu. – Authentification : Assurer l’identité d’un utilisateur, c’est à dire garantir à chacun des correspondants que son partenaire est bien celui qu’il croit être. Ceci dit, garantir la sécurité d’un système informatique n’est pas évidente. C’est une tâche compliquée et difficile à gérer. L’administrateur du système doit concevoir le réseau de manière à prendre en compte tous les scénarios possibles. Dans ce cadre s’inscrit notre projet de fin d’étude qui consiste à réaliser une étude sur les solutions libres des supervisions réseaux et des systèmes de détection d’intrusions et de les installer au sein du réseau d’Hexabyte. Ce travail a été réalisé en vue d’obtenir le diplôme en technologies de l’informatique et de Télécommunication à la faculté des sciences de Bizerte. Le présent rapport sera composé de quatre chapitres : Dans le premier chapitre, l’organisme d’accueil, qui nous a accueilli durant notre pé- riode de stage, sera présenté en rappelant les produits et les services qu’il offre. Par la suite, nous rappellerons les problématiques qui se posent dans le réseau de l’entreprise. Enfin, une étude comparative sera réalisée sur les systèmes de supervision et les systèmes de détection d’intrusion. Le second chapitre sera dédié à la supervision. Il aura pour objectif de rappeler le concept de supervision et d’administration des réseaux. Nous allons installer la solution choisie dans le réseau et la configurer. Il y aura aussi des configurations avancées afin 9
LISTE DES TABLEAUX d’optimiser la supervision et la sécurité du réseau. Le troisième chapitre sera consacré à la détection des intrusions. Il aura pour objectif de rappeler les méthodes de détection des intrusions et de définir les types des IDS. Nous allons voir les étapes de l’installation et la configuration du système de détection d’intru- sion choisi. Dans le dernier chapitre, nous présenterons notre plate-forme finale. Une démons- tration de son fonctionnement et des tests relatifs aux divers scénarios possibles seront effectués. A.U 2015-2016 10
Chapitre 1 Présentation générale du projet 1.1 Introduction Dans ce chapitre nous présenterons en premier lieu notre organisme d’accueil Hexa- byte et les différents composants de son réseau. En second lieu, nous présenterons le cadre générale de notre projet suivi par la problématique rencontrée, les objectifs visés et la solution proposée. Une étude comparative fera le sujet de la dernière partie de ce chapitre dans laquelle les caractéristiques des systèmes de supervision et de détection d’intrusion seront traitées. 1.2 Organisme d’accueil 1.2.1 Présentation La société HEXABYTE a été créée en 2001 sous la forme d’une Société Anonyme de droit tunisien avec un capital social initial de 280.000 DT. A la suite d’une opération d’incorporation de réserves et d’une autre d’apports en numéraire le dit capital est passé à la fin de 2010 à 1.750.000 DT réparti en 1 750 000 actions de nominal 1 dinar. Le siège social de la société est situé à Béja, où se trouve aussi l’essentiel de son maté- riel d’exploitation.La société HEXABYTE a pour objectif principal de fournir des services à valeur ajoutée de télécommunication de type internet ainsi que la conception, la pro- duction et la commercialisation de tous logiciels, matériels et équipements informatiques. La société dispose des différentes autorisations suivantes : – Autorisation triennale d’exercice de l’activité de Fournisseur de Service Internet « FSI » délivrée par le Ministère des technologies de la communication, ayant toujours fait l’objet de renouvèlements périodiques, – Autorisation TR2 d’exercice de l’activité d’installation et de maintenance de tout équipement de transmission et de réception radio, – Autorisation TM2 d’exercice de l’activité d’installation et de maintenance de tout équipement de transmission de données numériques. 11
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Le renouvèlement de ces autorisations est quasiment systématique tant que la société res- pecte les dispositions légales et règlementaires régissant son activité. La société Hexabyte s’est toujours distinguée par ses offres innovantes sur le marché tunisien à travers le lancement de produits (p.ex. : tablettes PC, caméras de surveillance) ou de services (p.ex. : streaming vidéo ) répondant aux attentes de sa clientèle. La société est gérée par un jeune Directeur Général en la personne de M. Naceur HIDOUSSI. Celui-ci est sorti major de l’École Supérieure des Postes et Télécommunica- tions de Tunis (ESPTT) en 1998 et a obtenu, deux ans plus tard, son master en génie électrique à la California State Polytechnic University, aux États-Unis. Il a travaillé dans un premier temps en Californie de janvier 2000 à janvier 2001 pour la compagnie Hu- ghes and Space Communication, puis dans un deuxième temps, il a mis ses compétences au service du projet Thuraya : un satellite réalisé pour le compte des Émirats Arabes Unis. Puis, jusqu’en août 2001, il a loué ses services à Boeing Satellites Systems où il a par- ticipé à la conception d’un logiciel de gestion d’embauche pour le compte du département des ressources humaines de l’entreprise, et au développement de l’interface de commande et de télémétrie du satellite américain Spaceway. De retour à Tunis, M. Hidoussi s’est occupé d’HEXABYTE, société qu’il a fondée quelques mois plus tôt avec l’ambition de devenir fournisseur de services Internet pour toutes les régions du pays. En peu de temps, la société est devenue un incubateur d’idées en matière de nouvelles technologies et a développé plusieurs produits. L’activité d’HexaByte est essentiellement basée sur la vente des produits et services suivants : – Internet Dial up : connexion via une ligne téléphonique au réseau Internet, – XDSL Entreprises : Lignes spécialisées/ Lignes « Fibre optique » / VSAT/ WIMAX, etc... – ADSL Résidentielle : Pour les particuliers, – Noms de domaines & hébergement de sites web – Solutions de surveillance IP & Réseaux – Packs ordinateurs et connexions RTC (connexions à bas débit) A.U 2015-2016 12
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Figure 1.1 – Organigramme d’Hexabyte 1.2.2 Composants du réseau Le parc informatiques que nous allons superviser est composé d’un ensemble de postes de travail, d’imprimantes, de serveurs de marque « DELL RACK power Edge » et de routeurs Cisco. Les serveurs fonctionnent avec des systèmes d’exploitations différents et offrent des services tel que le service web, GPS ou la voie sur IP. Ci_dessous, plus de détails sur les serveurs concernés : Table 1.1 – liste des serveurs et leurs services Système d’exploitation Service offert CentOS release 6.5 VOIP (asterisk) Ubuntu 12.04 LTS VOIP (asterisk) Debian 5.0.3 Web (apache) “ www.hexabyte.tn” Windows server 2003 web (apache) “www.hexavideo.tn” Ubuntu 14.04 LTS GPS 1.3 Cadre général Ce travail s’inscrit dans le cadre du projet de fin d’études à la Faculté des sciences de Bizerte pour l’obtention du diplôme de «licence appliquée en Réseaux Informatique et Télécommunications». Il a été réalisé au local de l’Hexabyte de Elmanzah 1 pendant une durée de 4 mois s’étalant du 01/02/2016 jusqu’au 30/05/2016. A.U 2015-2016 13
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.3.1 État de l’art 1.3.1.1 Statistiques D’après une statistique faite par “Hackmageddon” en janvier 2016, les motivations des attaques informatiques sont principalement la Cybercriminalité, le “Hacktivism”, le Cyber Espionnage et le “Cyber Warfare”. – La Cybercriminalité : il s’agit de pirater un système informatique en but de détruire des données et de gagner un accès à des ressources quelconques. Ce genre d’activité est souvent pratiqué par des pirates de type “black hat”. – Le “Hacktivism” : Les activités militantes des altermondialistes ne se développent pas seulement dans la rue, mais aussi sur internet, notamment avec ce qu’on appelle le « hacktivism ». Il est souvent pratiqué par des groupes de “hackers” et en même temps des activistes. – Le Cyber Espionnage : il s’agit de pénétrer des systèmes informatiques afin de gagner un accès à des documents confidentiels. Il peut s’effectuer entre 2 entreprises rivales ou même entre des pays. – Le “Cyber Warfare” : « Une cyberguerre est une guerre dont au moins une des composantes, dans la réalisation, les motivations et les outils (armes au sens large du terme) s’appuie sur le champ informatique ou numérique. Ces composantes sont dénommées des cyber attaques ». Cyberguerre et guerre de l’information (éditions Lavoisier, 2010). Figure 1.2 – les motivations des attaques informatiques En Tunisie, L’ANSI (Agence Nationale de la Sécurité Informatique) a réalisé une étude statistique sur le nombre des tentatives d’attaques informatiques. Et on a enregistrer 20 millions d’évènements qui ont été détectés par les services de l’ANSI à l’aide du système SAHER© en cours de l’année 2015. A.U 2015-2016 14
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Figure 1.3 – Évolution du nombre d’événements détectés par l’ANSI en 2015 « Géographiquement, la majorité des adresses IP sources d’évènements est issue de la Tunisie. Celles provenant de l’étranger sont issues essentiellement du continent asiatique contribuant à 37%, suivies par le continent européen 31% puis par le continent africain 21%. » Figure 1.4 – Répartition IP par continent en 2015 1.3.1.2 Principales attaques et menaces D’après les statistiques faites par Hackmageddon en janvier 2016, 34.0% des techniques utilisées par les “hackers” sont inconnues : Figure 1.5 – Les techniques de piratage les plus utilisées A.U 2015-2016 15
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Déni de service (DOS) : Le but de cette attaque n’est pas de gagner un accès à des données hébergées sur une machine distante, mais d’encombrer un service ou même la totalité du réseau. Donc les ressources ne seront pas disponibles. La commande la plus utilisée dans cette attaque est : ping . Le firewall est la solution la plus qualifiée pour se protéger d’une telle attaque. Écoute de réseau (Sniffing) : Il s’agit d’une attaque passive, qui permet d’intercepter certaines informations qui circule sur un réseau local, en assemblant les trames dans un format plus lisible. Cette attaque est difficile à détecter. Il existe des logiciels qui permettent cela, nous en citons : “ wireshark”, “tcpdump” et “Ettercap”, Il est recommandé d’utiliser des commutateurs afin de limiter les possibilités d’écoute. “Social Engeneering” : Cette attaque est utilisée par des pirates qui possèdent des compétences bien avancées. A l’aide des moyens de télécommunication usuels le “hacker” cherche à obtenir des données confidentielles auprès du personnel de l’entreprise en visant une tentative d’intrusion. Afin de faciliter la réalisation de cette attaque les pirates utilise le “framework” “Social Engeneering Toolkit” (SET). Se protéger d’une telle attaque ne se limite pas à des solutions “hardware” ou “soft- ware”, il faut offrir une formation au personnel. “Backdoor” : Un “ Backdoor ” est une entrée caché à une machine qui peut être utiliser afin de contourner les politiques de sécurité. C’est une manière d’accéder à une machine supposé être secrète. L’exemple principal, est le “ shell upload ” qui s’agit d’installer un script malveillant souvent écrit en langage PHP(c99,r57), PERL ou Ruby afin de pouvoir exécuter des commandes sur une machine distante et y avoir accès. Injection SQL : C’est l’une des attaques web les plus utilisées. Il s’agit d’une technique qui vise à modifier la requête SQL dans une application web afin d’accéder à des données confidentielles modifier ces données ou créer un utilisateur privilégié. C’est possible d’in- jecter le code SQL dans l’URL ou dans un formulaire. Un exemple d’un outil qui utilise cette technique “SQLmap”, “Havij”, “SQLninja”, etc. Pour proteger une application de ce genre d’attaque il faut bien sécurisé les formulaires en utilisant des fonctions spécifiques tel que “ mysql_real_escape_string () ;”. 1.3.2 Problématique La majorité des ressources informatique est installée dans le réseau que nous allons protéger. Hexabyte utilise l’outil Nagios comme un système de supervision de réseau, sans l’avoir configuré d’une manière avancée et personnalisée. Du coup, la supervision existante est très limitée, peu efficace et n’apporte pas assez d’informations à propos du réseau. En 2013, L’entreprise a installé Suricata comme système de détection d’intrusion réseau. Ce dernier est très bien connu et efficace en tant que IDS réseau mais seul il ne permet pas A.U 2015-2016 16
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET d’assurer la détection d’intrusion assez efficace. En décembre 2015, nous avons détecté une faille dans une application web hébergé sur l’un des serveurs de l’entreprise, c’est dans ce contexte que nous avons proposé à Hexabyte d’améliorer la sécurité du réseau. En effet, Si un “black hat” avait détecté cette faille il aurait pu avoir accès à la base de données et réaliser des actions malveillantes. Il est donc obligatoire d’améliorer la sécurité du réseau de l’entreprise. 1.3.3 Travail à faire Pendant le déroulement du projet, nous allons veiller à satisfaire les besoins de l’entre- prise. La solution de surveillance à mettre en place doit assurer les besoins fonctionnels suivants. – Surveiller l’état physique des machines et des équipements réseaux. – Surveiller la charge des machine : nombre d’utilisateurs connectés, de requêtes, l’usage de la CPU, le débit réseau, etc. – Surveiller la disponibilité des applications, des services et des composants systèmes par simple surveillance des fichiers logs. – Surveiller les performances du réseau : débit, latence, taux d’erreur, QoS ... – Surveiller les modifications et l’intégrité des fichiers critiques. La solution qui sera mise en place doit fournir un ensemble de mesures qui vont nous assister à optimiser l’infrastructure réseau et les systèmes utilisés à savoir : – La mesure de performance, en termes de temps de réponse. – La mesure de disponibilité des systèmes pour le calcul d’impact en cas de dysfonc- tionnement. – La mesure d’efficacité qui va permettre de connaitre l’usage de la bande passante et des ressources réseau. – La mesure de la qualité des services fournis. 1.4 Étude Comparative des solutions Open-Source 1.4.1 Outils de supervision Dans cette partie du chapitre, nous allons étudier quatre solutions libres (Open source) de supervision, en présentant chaque solution et en mentionnant leurs avantages et leurs inconvénients.[URL_N1] A.U 2015-2016 17
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.4.1.1 Présentation des solutions Nagios – Langage : C/PHP – URL : https ://www.nagios.org/downloads Nagios est un système de supervision réseau, développé par Ethan Galstad dès 1999 et est actuellement en sa version 4.1.1. Ce logiciel fonctionne sous linux et la plupart des système UNIX. Il se décompose en trois parties : – Le moteur de l’application qui s’occupe de l’ordonnancement des tâches de super- vision. – L’interface Web, qui permet la visualisation des informations . – Les plugins, une ensemble des mini programmes qui complètent Nagios Il possède plusieurs fonctionnalités, nous en citons quelques unes : – Envoi des avertissements et des alarmes par courrier électroniques ou par sms. – Récupération des informations du réseau et des équipements. – Surveillance des services réseaux (HTTP/ ICMP/SMTP...). – Surveillance des ressources matérielles ( stations / équipements réseaux . . .). – Génération des rapports de fonctionnement des services, etc. Zabbix – Langage : C/C++/PHP – URL : http ://www.zabbix.com/download.php Zabbix[AND_13] est un logiciel open source de supervision des réseaux développée en C en 2002 . Son interface web est développée en php et en javascript. Il se compose de quatre parties : – Zabbix Server, c’est le composant principal. Il s’occupe de la supervision distance ou local. – Zabbix Frontend, c’est l’interface web de Zabbix. Il permet de visualiser les évène- ments. – Zabbix Proxy, c’est le collecteur des informations – Zabbix Agent, offre un supervision active es ressources locales de la machine ou il est installé. Ces principales fonctionnalités : – Récolte des informations Via SNMP, tests services et agents Zabbix . – Supervision répartie du réseau et surveillance des stations et des serveurs web, mail„, A.U 2015-2016 18
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET – Récolte des informations depuis les agents installés sur les machines à superviser. – Visualisation de l’état du réseau et de ces équipements à l’aide d’une interface graphique web. – Création et visualisation de la cartographie du réseau. – Découverte des serveurs et des équipements réseau d’une manière automatique, etc. Centreon – Langage : PHP – URL : https ://download.centreon.com Centreon est une application libre ( open source ), Elle est basé sur Nagios. Depuis 2012 Centreon utilise son propre moteur de collecte et gestionnaire d’événement .Il est plus simple à installer et à configurer que Nagios et il offre une interface graphique avancé et claire. Ces principaux fonctionnalités : – Mêmes fonctionnalités que Nagios . – Configuration en ligne via une API. – Gestion des dépendances entre les services – Visualisation des graphes et des données avancée En dessous, un schéma qui explique la relation entre Nagios et centreon : Figure 1.6 – Architecture de Centreon et sa relation avec Nagios A.U 2015-2016 19
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Shinken – Langage : Python – URL : http ://www.shinken-monitoring.org/download.php Shinken[URL_N2] est un système de supervision open source, il s’agit du cœur de Nagios réécrit en python. On lui a apporté une nouvelle architecture plus souple et plus facile a maintenir. Il se compose de plusieurs daemons qui coopèrent entre eux afin de fournir les mêmes fonctionnalités que Nagios . Shinken se constitue de plusieurs daemons qui ont chacun son rôle. Le maitre de ces daemons est l’Arbiter, il lit la configuration, la découpe et l’envoie vers les autres dae- mons. Il est aussi responsable de la disponibilité des autres daemons. Les daemons de type pollers ont le rôle de l’ordonnanceur ils ordonnassent la supervision. Ils existe d’autres daemons comme les Reactionners, Broker et Schedulers . Figure 1.7 – Architecture de Shinken A.U 2015-2016 20
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.4.1.2 Récapitulatif des outils de supervision Table 1.2 – Tableau comparatif des outils de supervision Avantages Inconvénients Nagios +Très bien documenté. +Extensible. +Fiable et robuste. +Une large communauté. +Un très grand nombre de plugins à disposition . -Complexité de paramétrage : il faut passer par la configuration textuelle. -Interface web non ergonomique et manque de visualisation graphique. -Évolution lente du logiciel. Zabbix +Une application complète. +Très bien documenté. +L’interface de supervision et de configuration sont plus claires et plus intuitive que celui de Nagios. +L’agent peut lancer des scripts afin de collecter de l’information. +Dessiner les graphe en temps réel (mise à jours toute les 30secondes). +Gestion des droits d’accès des utilisateurs . +Configuration des notifications et des alértes facile à l’aide de shell scripts. -L’agent zabbix envoie par défaut en claire les informations. -Pas facile à utiliser pour un simple utilisateur. -Interface web compliqué et plein de fonctionnalités. - - - - - Centreon +Interface Web très ergonomique. +Une Solution complète de supervision. +Très performant. -Possibilité de rencontrer des problèmes de compatibilité. -Moins rapide que Nagios. Shinken +Compatible avec Nagios. +Interface web ergonomique et moderne. +Très performant . +Développé en python ce qui permet la séparation des taches. +Haute disponibilité des services. +Monitoring via : WMI , NSClient++ pour les machines windows. +Monitoring via SNMP, SSH,local agent,ICMP,.. -Shinken utilise beaucoup de ressources par rapport à Nagios. -Il dispose d’une architecture compliquée. -Une installation et une configuration difficile et avancée par rapport aux autres logiciels. - - A.U 2015-2016 21
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.4.1.3 Choix de la solution adoptée Après avoir établi une étude comparative sur les quatre solutions libres de supervision proposées ci-dessus, nous étions hésités entre Zabbix et Shinken.Au final, nous avons décidé de mettre en place la solution Zabbix. C’est la solution la plus convenable parce qu’elle répond fidèlement aux besoins de l’entreprise. 1.4.2 Outils de détection d’intrusion Dans cette partie du chapitre nous allons réaliser une étude de cinq systèmes de détec- tion d’intrusion libres, en présentant chaque solution et en mentionnant leurs avantages et leurs inconvénients. 1.4.2.1 Présentation des solutions SNORT – URL : https ://www.snort.org/downloads Snort est un système de détection et de prévention d’intrusion open source conçu en 1997 par Marty Roesh et racheté par SourceFire. Il a le pouvoir d’interagir avec le pare-feu pour bloquer les intrusions en jouant le rôle d’un IPS (Intrusion Prevention System) en ajoutant des plugins dédiés spécifiques tels que Snort natif et Snort-inline. Il utilise des règles basées sur les signatures, les protocoles et l’inspection d’anomalie. Il offre aussi la possibilité de créer ses propres règles et plugins. C’est le NIDS le plus déployé, il est même devenu un standard des NIDS et des IPS. Il joue cinq principaux rôles : – Packet sniffer : Il effectue l’écoute de réseau dans les différents niveaux. – Packet logger : Il enregistre les logs dans une fichier texte. – Alarm correlator : Il gére les notifications et les alertes. – Detection engine : Il s’occupe de la détection des menaces. – Pre-processor/Packet decoder : Il prépare les informations afin qu’ils soient lisibles. Il posséde un ensemble de caractéristques, nous en citons : – Open source – Petite taille : ~800K – Portable : Fonctionne sur plusieur OS : linux, Windows, MacOS X, etc) – Rapide : Il dispose d’une vitesse de détection trés rapide( ~100MBps) – Configurable : Son configuration est facile et la language de ses règles est simple. A.U 2015-2016 22
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET Prelude IDS – URL :https ://www.prelude-siem.org/projects/prelude/files Prélude-IDS est un IDS hybride conçu en 1998. Il joue le rôle d’un : – NIDS :Network IDS – HIDS :Host Based IDS – LML : Log Monitoring Lackey Il permet de stocker les logs dans une base de données (mysql/PostgreSQL). Il est com- patible avec Snort, Nessus et plusieurs analyseurs de logs. Il se compose de plusieurs sous-ensembles : – La librairie libprélude, – La sonde réseau Prelude-nids, – La sonde locale Prelude-lml, – Le contrôleur Prelude-manager, – L’interface web Prelude-php-frontend. prelude dispose de plusieurs fonctionnalités, nous en citons : – Détection d’intrusion réseau, – Détection d’intrusion machine, – Correlation d’événements, – Vérification d’intégrité des fichiers, – Scanner les vulnérabilités, etc. AlienVault OSSIM – URL : https ://www.alienvault.com/products/ossim AlienVault OSSIM[URL_N3] ( Open Source Security Information Management ) est un IDS hybride qui regroupe des outils garantissant la sécurité du réseau, des machines, et des équipements réseaux en détectant les intrusions et les bloquant . Ossim se compose d’un ensemble de logiciel Open-source : Snort : Détection d’intrusion réseau. Suricata : Détection d’intrusion réseau, c’est le NIDS qui est configuré par défaut. Ossec : Détection d’intrusion machine. Prads : Identification des machines et des services. Nagios : Utilisé pour la supervision du réseau. Nessus : Analyseur de vulnerabilités. A.U 2015-2016 23
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET BRO IDS – URL : https ://www.bro.org/download/ Bro ids est un système de détection d’intrusion destiné aux réseaux à fort trafic. Cette application a été lancée en 1998. Il a été conçu pour : – Minimiser/éviter toute perte de paquet – Minimiser/éviter tout faux positif – Optimiser la défense de la sonde contre les attaques – Envoyer des alertes en temps réel – Accepter des nouvelles fonctionnalités Bro c’est : – Un capteur de packet – Analyseur de trafic – Système de détection d’intrusion réseau – Enregistreur de logs AlienVault USM – URL : https ://www.alienvault.com/products AlienVault[URL_N3] USM (Unified Security Management) est une solution payante pro- posée par AlienVault. Cette plate-forme enveloppe 5 grandes tâches de sécurité réseaux : – Détecter les intrusions – Analyser les comportements des trafics et des services – Scanner les vulnérabilités et les tester – Déclencher des activités après l’incident (Alerte, gestion de logs, prévention d’un événement.) – Scanner et découvrir les machines qui sont connectées au réseau A.U 2015-2016 24
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.4.2.2 Récapitulatif des IDS Table 1.3 – Tableau comparatif des solutions de détection d’intrusion Avantages Inconvénients Snort +Une très grande communauté. +Mise à jour régulière de la base de signatures. +Nombreux plugins documentations riches. +Logiciel libre. -Les sondes nids peuvent être vulnérable. -Nécessite une étude avant le placement des sondes. -Nombreuses fonctionnalités payantes. . . Prelude IDS +Compatible avec plusieurs autres outils. +Il intègre les fonctionnalités NIDS e HIDS. +Scanne de vulnérabilités. +Format normalisé. +Logiciel libre. -La base de données des signatures est moins riche que celle de snort. -Besoin de connaissances en sécurité. . . . . OSSIM +Interface web très claire et ergonomique. +Une très grande entreprise derrière cette solution. +Gestion des événements simple +Logiciel libre. -Documentation faibles -Collection de logs limité -Modèles des rapports limités -Moins de fonctionnalités par rapport à USM , . Bro IDS +Faux positifs réduits +Extensible +Analyses graphiques avancées. +Compatible avec d’autres outil. +Compatible avec les règles de snort grâce à snort2bro. -Documentations faibles -Absence d’une interface graphique -Manque d’informations dans les rapports d’alerte. . USM +Mise à jour hebdomadaire. +Application riche en fonctionnalités. +Support professionnelle -Logiciel payant. . . A.U 2015-2016 25
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET 1.4.2.3 Choix de la solution adoptée Aprés avoir étudié les différentes solutions de détection d’intrusion, nous avons opté pour Prelude-IDS. Il s’agit d’une solution compléte et facile à personnaliser et qui répond aux besoins de l’organisme d’accueil. 1.5 Conclusion Au cours de ce chapitre, nous avons présenté l’organisme d’accueil qui a adopté ce projet. Puis un rappel du cadre général à été introduit. Pour finir, nous avons effectué une étude comparative des solutions libres de supervision et de détection d’intrusion. Dans le chapitre qui suit nous allons entamer la partie supervision. Dans cette dernière une introduction à la supervision sera incluse suivi par l’installation de Zabbix. A.U 2015-2016 26
Chapitre 2 Supervision réseau 2.1 Introduction Dans ce chapitre, nous rappellerons en premier lieu le principe de la supervision réseau. Par la suite, une description détaillée de l’installation de zabbix sera introduite suivi par des configurations basiques et avancées. 2.2 Introduction à la supervision réseau 2.2.1 Principe Dans un système informatique, la supervision réseau[URL_N4] est devenue une opéra- tion indispensable qui peut économiser beaucoup d’argent en améliorant les performances du réseau, le cout de l’infrastructure et la productivité des employés. Un système de super- vision réseau a comme tâche principale de trouver les problèmes dans un réseau local tel que : station non connectée, serveurs hors service, modification d’un fichier important, etc. La supervision réseau ne peut être réalisée qu’en utilisant une variété de logiciels ou une combinaison de solutions “software” et “hardware”. N’importe quel réseau peut être supervisé, que ça soit filaire, sans fil, VPN ou même WAN. Il est possible de réaliser la supervision des machines sous n’importe quel système d’exploitation (Windows, Linux, Cisco IOS. . .) Les systèmes de supervision réseau différent des systèmes de détection d’intrusion (IDS) ou des systèmes de prévention d’intrusions (IPS). Ces derniers détectent et bloquent les activités des utilisateurs non autorisés dans le réseau. Par ailleurs, il s’agit d’une opération complexe et composée de plusieurs activités complémentaires : – Surveiller (l’état des machines, les statut des services. . .), – Analyser ( des logs), – Visualiser ( des graphes), – Agir ( actions, scripts . . . ), – Alerter (par SMS / mail ), etc. 27
CHAPITRE 2. SUPERVISION RÉSEAU 2.2.2 Superviser quoi ? Un système de supervision réseau permet de superviser un ensemble de composants physique et logique d’un système d’information : – Le réseau et ses équipements : Commutateurs, routeurs, serveurs, onduleurs, impri- mantes.. – Systèmes : Utilisations des ressources (CPU, mémoires . . . ). – Applications : Disponibilité des services, performances . . . 2.2.3 Objectifs L’objectif de la supervision se résume principalement en : – Être réactif en envoyant une notification à l’administrateur du réseau en cas de problème technique dans une partie du réseau. – Être proactif en anticipant les pannes et les scénario possibles – Viser les évènements dés leurs apparitions afin d’agir avec pertinence. 2.2.4 Méthodes de supervisions Pour effectuer une supervision sur un système d’information, on utilise plusieurs mé- thodes : – Analyse des fichiers logs : Il s’agit de collecter des informations sur un système, un service ou une application à partir de son fichier log. – Commandes : Il s’agit de récupérer le résultat d’une commande (ping,traceroute..) ou d’un script. Ça peut être des scripts locaux ou distants. – A l’aide d’un agent ( Zabbix-agent, shinken-agent . . .). – Via SNMP . 2.3 Installation et configuration de Zabbix Il est préférable d’utiliser l’outil « Putty » pendant l’installation et la configuration du serveur Zabbix et ses agents[URL_N5]. Cet outil utilise le protocole SSH afin d’exécuter les commandes à distance. On doit alors configurer le service SSH sur le serveur.[URL_N4] 2.3.1 Installation du serveur Zabbix Afin d’installer « zabbix-server » (version 2.2) on doit ajouter les dépôt de Zabbix dans la liste des dépôts de ubuntu. # sudo nano /etc/apt/sources.list Puis copier les lignes ci-dessous dans le fichier , et taper CTRL+x pour enregistrer la modification du fichier . # Zabbix repos deb http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main deb-src http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main A.U 2015-2016 28
CHAPITRE 2. SUPERVISION RÉSEAU Pour que l’outil apt-get aie confiance en ces nouveaux dépôts, on exécute cette com- mande. # sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C407E17D5F76A32B Tout d’abord il faut mettre à jours la liste des dépôts en exécutant la commande sui- vante. # sudo apt-get update En suivant les commandes en dessous on installera Zabbix-server , le serveur apache2 et l’interface web de Zabbix . # sudo apt-get install Zabbix-server-mysql php5-mysql Zabbix-frontend-php En cour de l’installation nous allons être demandé de saisir le nouveau mot de passe de l’utilisateur « root » de MySQL. Il faut bien mémoriser ce mot de passe. 2.3.2 Configuration du serveur Zabbix Le serveur Zabbix a été installé avec succès, mais il est loin d’être prés à l’utilisation. Nous allons maintenant commencer la configuration des outils installé. Tout d’abord il faut configurer le fichier de configuration principale de Zabbix. Pour cela il faut ouvrir le fichier avec les privilèges "root" : # sudo nano /etc/zabbix/zabbix_server.conf Il faut chercher les lignes suivants et les modifier comme ci-dessous : – DBName=zabbix // Nom de la base de donnée que Zabbix va utiliser – DBUser=zabbix // Nom de l’utilisateur MySQL . – DBPassword=MOT_DE_PASSE //Mot de passe de l’utilisateur MySQL Il faut sauvegarder et fermer le fichier . 2.3.3 Configuration de la base de données de Zabbix Pour rendre la création des tables dans la base de donnée de Zabbix plus facile, les fichier SQL sont mis en disposition et sont compressés dans ce chemin " /usr/share/zabbix- server-mysql/" . Pour les importer dans la base de données on doit tout d’abord les dé- compresser : # cd /usr/share/zabbix-server-mysql/ # sudo gunzip *.gz Puis nous nous connectons à MySQL en tant que " root ". # mysql -u root -p A.U 2015-2016 29
CHAPITRE 2. SUPERVISION RÉSEAU Maintenant nous sommes connectés, il faut ensuite créer un utilisateur de nom de "zab- bix" qui correspond à la configuration que nous avons mis dans le fichier zabbix_server.conf. Pour cela il faut exécuter les requêtes SQL ci_dessous : mysql > CREATE USER ’zabbix’@’localhost’ IDENTIFIED BY ’MOT_DE_PASS’; Ensuite il faut créer la base de donnée "zabbix" , en exécutant cette requête mysql > CREATE DATABASE Zabbix; Puis, nous allons donner à l’utilisateur "zabbix" le contrôle sur la base de donnée "zab- bix". mysql > GRANT ALL PRIVILEGES ON Zabbix.* TO ’zabbix’@’localhost mysql > FLUSH PRIVILEGES; Nous avons finit avec la configuration initial de MySQL, revenons au terminal shell. mysql > EXIT; Maintenant que nous avons crée l’utilisateur et la base de donnée, il faut importer les fichier SQL que Zabbix a besoin pour son fonctionnement. # mysql -u Zabbix -p Zabbix < schema.sql # mysql -u Zabbix -p Zabbix < images.sql # mysql -u Zabbix -p Zabbix < data.sql La base de données de Zabbix est maintenant prête à être utilisé. 2.3.4 Configuration du serveur apache2 Il faut ajuster quelques valeurs pour que php gére parfaitement les données de su- pervision. Nous allons donc accéder au fichier de configuration de php en exécutant la commande suivante. # sudo nano /etc/php5/apache2/php.ini Et changer les valeurs suivantes. post_max_size = 16M max_execution_time = 300 max_input_time = 300 date.timezone = Africa/Tunis Puis enregistrer et fermer le fichier. Ensuite nous allons copier le fichier de la configu- ration php de Zabbix dans le répertoire de configuration de Zabbix. # sudo cp /usr/share/doc/zabbix-frontend-php/examples/zabbix.conf.php. example/etc/zabbix/zabbix.conf.php A.U 2015-2016 30
CHAPITRE 2. SUPERVISION RÉSEAU Il faut configurer le fichier Zabbix.conf.php comme suivant. # sudo nano /etc/zabbix/zabbix.conf.php Il faut configurer ce fichier avec les paramètres de connexion mysql qu’on a fait récem- ment. $DB[’DATABASE’] = ’zabbix’; $DB[’USER’] = ’zabbix’; $DB[’PASSWORD’] = ’MOT_DE_PASSE’; Enregistrer et fermer le fichier. Pour rendre apache et Zabbix fonctionnent ensembles, on doit copier l’exemple de configuration d’apache dans " /etc/apache2/conf-available/". # sudo cp /usr/share/doc/zabbix-frontend-php/examples/apache.conf /etc/apache2/conf- available/zabbix.conf Pour activer la nouvelle configuration de Zabbix sous sur apache, on exécute la com- mande suivante. # sudo a2enconf Zabbix.conf # sudo a2enmod alias La configuration d’apache est maintenant terminé. nous redémarrons le service. # sudo service apache2 restart Maintenant nous allons modifier la valeur "START" de "no" à "yes" dans le fichier /etc/default/zabbix-server pour que le service Zabbix se lance en démarrage du système. # sudo nano /etc/default/zabbix-server ... START=yes ... On lance le service " Zabbix-server ". # sudo service Zabbix-server start Si nous voulons que l’interface web de Zabbix s’exécute dans la racine au lieu de "/zab- bix" on doit modifier la valeur "DocumentRoot" à "/usr/share/zabbix". # sudo nano /etc/apache2/sites-available/000-default.conf ... DocumentRoot /usr/share/zabbix ... A.U 2015-2016 31
CHAPITRE 2. SUPERVISION RÉSEAU 2.4 Ajout d’une station 2.4.1 Installation d’un agent Zabbix 2.4.1.1 Sous Linux l’installation des agents se fait par l’outil apt-get. # sudo apt-get update # sudo apt-get install Zabbix-agent Maintenant nous allons commencer à configurer l’agent. # nano /etc/zabbix/zabbix_agentd.conf Il faut changer 127.0.0.1 par l’adresse du serveur, et la valeur de "remotecommand" par "1". ... Server = 127.0.0.1 ... remotecommand=1 ... Après, on aura besoin d’exécuter des commandes sur les machines agents, c’est pour- quoi on a activer l’option "remotecommand ". L’agent maintenant est bien installé sur la machine linux. Il faut redémarrer le service. # sudo service Zabbix-agent restart 2.4.1.2 Sous Windows Tout d’abord il faut télécharger l’agent windows de Zabbix qui peut être obtenu à partir du site officiel[URL_N6]. Par la suite on extrait l’archive zip dans un dossier, soit C :Downloadszabbix_agent maintenant on execute la commande ci_dessous dans l’in- vite de commande. C:Userstlich1337>c:Downloadszabbix_agentbinwin32zabbix_agentd.exe –config C:Downloadszabbix_agentsconfzabbix_agentd.win.conf --install Après qu’on a installer le service dans la machine windows, on ouvre le fichier Zab- bix_agentd.win.conf et on modifie les valeures suivantes : – Server= l’adresse ip du serveur Zabbix – ServerActive=l’adresse ip du serveur Zabbix – Hostname=le « FQDN » de la machine windows Nous sauvegardons la modification et on démarre le service. D:Userstlich1337>D:Downloadszabbix_agentsbinwin32zabbix_agentd.exe --start A.U 2015-2016 32
CHAPITRE 2. SUPERVISION RÉSEAU Le service est maintenant disponible, il ne reste plus que de donner au service Zabbix- agent le droit de passer le « firewall » si il y en a un. 2.4.2 Ajout du nouveau hôte dans le serveur Il faut maintenant ajouter l’agent dans la liste des hôtes supervisionnés. Dans la barre d’adresse du navigateur on met l’adresse ip du serveur Zabbix suivis par "/zabbix". Puis on se connecte avec le compte par défaut de Zabbix. Username = admin Password = Zabbix On clique sur l’onglet "configuration", "hosts" puis sur "Create host". On remplit le formulaire d’ajout d’hôte comme suit : – Hostname : Nom de la machine – Visible name : Nom Affiché ajouter la machine dans "Linux Servers" – Ajouter l’adresse ip de la machine – Cocher l’option « enabled » pour activer la supervision sur cette nouvelle machine On clique maintenant sur l’onglet "Template"ensuite on suit les étapes ci-dessous : 1. Cliquer sur "Select" pour ajouter une nouvelle "Template" 2. Choisir "Template OS Linux" puis cliquer sur "Select" 3. On peut choisir le template « SNMP Template » si on veut utiliser la supervision avec snmp. 4. Cliquer sur "add" pour ajouter le "Template" dans le nouveau hôte. 5. Cliquer sur "update" 2.5 Amélioration et Optimisation de la supervision 2.5.1 Scripts Un script est un ensemble de lignes de code, il s’agit d’une suite d’instructions simples permettant d’automatiser certaine tâches. Il est souvent écrit en langage non compilé (bash / perl / ruby / python). Pour créer un script qui fonctionne sous Zabbix, on suit les étapes suivantes : 1. Se connecter sur l’interface web de Zabbix. 2. Sélectionner l’onglet « Administration » puis le menu « Scripts ». 3. Cliquer sur « Create script ». 4. Remplire les champs du formulaire comme ci_dessous. – Name : Nom Du Script – Type : Sélectionner « Script » – Execute on : Choisir si le script va être exécuter sur la machine serveur ou l’hôte supervisé. – Commands :Le code du script – Description : Une bref description de la fonctionnalité qui offre le script pour. A.U 2015-2016 33
CHAPITRE 2. SUPERVISION RÉSEAU – User groups : Choisir le groupe d’utilisateurs qui peut executer le script. – Host groups : Choisir le groupe d’hôtes où le script s’exécutera – Required host permission : Read ( Si le script va seulement lire des données) /write (Si le script va effectuer des modifications au niveau d’un fichier ) . – Enabled confirmation : à cocher pour pouvoir utiliser le script. Cliquer sur « Save » pour enregistrer le script. À ce niveau, nous avons réaliser un ensemble de scripts qui sont indispensables dans le domaine d’administration réseau. Ci_dessous une liste de quelques scripts que nous avons ajouté. Figure 2.1 – Liste des scripts développés « Check Services Status » : un script qui permet d’afficher les états des services de la machine sélectionné. Figure 2.2 – démo : “Check Services Status” A.U 2015-2016 34
CHAPITRE 2. SUPERVISION RÉSEAU « Disk :Bad Blocks » : ce script vérifie l’état des disques dure de la machine sélectionné. En utilisant l’outil Crontab de linux, le script BadBlocks va s’exécuter toutes les 24h et enregistrera le résultat dans un fichier texte. Quand on exécute ce script il affichera la dernière version du fichier texte donc le dernier résultat . Figure 2.3 – Démo : “Disk : Bad Blocks” « TopCpu consumers » : Ce script affiche les processus qui utilisent plus de ressources. Il se base sur la commande ‘top’ . Figure 2.4 – Démo : “TopCpu Consumers” « Last Activities » : Ce script affiche les activités récente du système ( démarrage, redémarrage, connexion des utilisateurs sur les interface TTY . . . ). A.U 2015-2016 35
CHAPITRE 2. SUPERVISION RÉSEAU Figure 2.5 – Démo : “Last Activities” « Check SSL Expiration » : C’est une fonctionnalité très importante et peut utilisé dans l’administration système. Ce script permet de surveiller l’expiration du certificat SSL. 2.5.2 Alerte par Courriel électronique Dans cette partie nous allons voir comment configurer Zabbix pour qu’on reçoit des notifications par email. Ainsi, il sera possible de savoir tous les changements des « items » grâces aux « triggers ». Commençons par créer un média de type email. Pour cela, il faut se rendre dans l’in- terface web de Zabbix en accédant au menu « administration » puis « media type ». Ensuite on clique sur « create media type » et on remplit le formulaire ce cette façon : – Description : Une description bref du media ou bien le nom du media. – Type : On selectionne « Email » – SMTP server : L’adresse ip ou le nom de domaine du serveur SMTP – SMTP helo : Nom de domaine du serveurs – SMTP email : L’email qui va émettre les messages Puis on clique sur « Save ». Le media est maintenant prêt. Il est nécessaire de créer une action Afin de déclencher l’envoi d’email à chaque fois qu’un « trigger » se lance. On clique sur l’onglet « Confi- guration » puis « Actions » puis sur « create Action » pour la création d’une action. Maintenant on remplit le formulaire comme suit : – Name : Nom de l’action – Event source : Sélectionner « triggers » – Default subject : {TRIGGER.NAME} : {STATUS} – Default message : {TRIGGER.NAME} : {STATUS} – Status : Sélectionner « Enabled » – Aller à la fenétre « Action operations » puis cliquer sur « new » – Operation type : Selectionner « Send message » A.U 2015-2016 36
CHAPITRE 2. SUPERVISION RÉSEAU – Send message to : Choisir l’utilisateur qui va recevoir l’email – User medias : Sélectionner le media qu’on vient de créer – Cocher l’option Default message On clique sur « add » puis « save ». L’alerte par email est maintenant mise en place et active. Un exemple d’email reçue dans la figure suivante : Figure 2.6 – Exemple d’un message reçu 2.5.3 Supervision des serveur VOIP La supervision d’un serveur VOIP nécessite plus de configuration que celle d’un ser- veur, on a pas seulement besoin de savoir les information générales du systèmes et de ses applications. On aura besoin de savoir plus d’informations que prévue, exemple. Appels actifs. # sudo /usr/sbin/asterisk -rvvvvvx ’show channels’|grep --text -i ’active call’|awk ’{print $1}’ Messages fax reçu/envoyé avec succée. # sudo -u Zabbix sudo /usr/sbin/asterisk -rvvvvvx ’fax show stats’ | grep ’Completed’ | awk ’{print $NF}’ Nous avons utilisé un ensemble de commandes de ce genre dans des scripts pour ef- fectuer la supervision sur les serveurs VOIP de l’entreprise. Nous avons réussi à réaliser les fonctionnalités cité ci-dessous : – Nombre d’appels actif, – Nombre de sessions courante des fax, – Nombre et pourcentage des erreurs de transmission des appels, – Nombre et pourcentage des erreurs de transmission des messages par fax, – Nombre de fax et de téléphones disponibles, etc. A.U 2015-2016 37
CHAPITRE 2. SUPERVISION RÉSEAU 2.5.4 Screen Un « screen » est une vue composée de plusieurs graphes, champs de textes et d’autres forme de données qui facilite la supervision d’un système informatique. Ci_dessous un exemple sur un des screen que nous avons crée. Figure 2.7 – Exemple d’un tableau de bord (screen) Pour créer un « screen » personnalisé, il faut passer par les étapes suivantes : – Se connecter sur l’interface web de Zabbix – Sélectionner l’onglet « Configuration » puis « Screens ». – Cliquer sur « Create screen ». – Donner un nom à la nouvelle vue, préciser le nombre des colonnes et des lignes. – Puis remplir les champs par les graphes et les données qu’on veut ajouter. Notre nouvelle vue est maintenant prête à être utilisé. Pour l’exploiter il faut aller à l’onglet « Monitoring » puis « Screens » et choisir la vue qu’on veut à partir de la liste affiché. 2.5.5 Maps Une « Map » est une carte composée de plusieurs machines interconnectées. Ça per- met de visualiser l’état de la connexion entre les machines qu’y existent et d’exécuter des scripts sur une machine quelconque. Ci_dessous un exemple de carte que nous avons crée. A.U 2015-2016 38
CHAPITRE 2. SUPERVISION RÉSEAU Figure 2.8 – exemple d’une “map” Pour créer une « map » personnalisé il faut suivre les étapes suivantes : – Se connecter sur l’interface web de Zabbix. – Sélectionner l’onglet « configuration » puis « Maps ». – Cliquer sur « create map ». – Remplir les champs suivants comme nous le souhaitons. Figure 2.9 – Formulaire de création d’une “map” – Ajouter un icône. – Cliquer sur l’icône. – Définir le type de l’objet que l’icône représentera(Host,Map,image. . .) dans notre cas , une machine. – On remplit le champ « label » par une bref description de la machine, pour ceci nous allons utiliser des macros qui vont chercher les informations d’une façon dynamique. Par exemple. A.U 2015-2016 39
CHAPITRE 2. SUPERVISION RÉSEAU {HOST.NAME} {HOST.CONN} (CPU: {{HOST.HOST}:system.cpu.load[percpu,avg1].last(0)} ) {HOST.NAME} : Retourne le nom de la machine. {HOST.CONN} : Retourne l’adresse ip de la machine. {{HOST.HOST} :system.cpu.load[percpu,avg1].last(0)} : Retourne l’usage du pro- cesseur de la machine (une pourcentage). – Sélectionner l’emplacement de la libelle ,par défaut c’est « bottom » . – Sélectionner l’hôte que l’icône va présenter dans le champs « Host ». – Choisir l’icône et sa dimension . – Cliquer sur « apply » pour effectuer le changement. Afin d’améliorer améliorer la « map ». Nous allons ajouter une liaison entre deux ma- chines. Cette liaison présentera la connexion physique ou logique entre les 2 terminaux. Nous suivrons donc les étapes ci_dessous : – Sélectionner les deux machines que nous allons les relier. – Cliquer sur le bouton d’ajout d’un lien. – Cliquer sur l’icône d’un des terminaux. – Aller à la fenêtre « Links for the selected element » et cliquer sur « edit » afin de configurer la liaison. – Pour afficher le débit montant et descendant de la station nous utilisons des macros spécifique dans le champ « label ». In : {zabbixServer:net.if.in[eth0].last(0)} Out : {zabbixServer:net.if.out[eth0].last(0)} – Choisir le type du lien ( ligne continue, ligne continue gras. . .) – Choisir le couleur du lien (vert par défaut) – Pour que la ligne devienne rouge si la machine n’est pas connectée, nous allons activer un « trigger » qui va surveiller la connectivité entre les 2 machines. Dans notre cas ce trigger est intitulé « zabbixServer : Zabbix agent on ZabbixServer is unreachable for 5 minutes » puis nous sélectionnons la couleur rouge si le trigger s’active. – Cliquer sur « apply » Notre « Map » est maintenant bien configurée. Il ne reste qu’à sauvegarder le changement. Pour exploiter la « map » nous sélectionnons l’onglet « monitoring » puis « maps » . 2.5.6 Activation de SSL dans apache2 L’interface web de Zabbix fonctionne avec le protocole http. Ce protocole n’est pas sécurisé car il transfère le trafic sans le crypter. Parfois le serveur envoie au client web des données confidentielles, et il se peut qu’un intrus intercepte les messages et les exploite pour effectuer des actions non désirées. C’est pourquoi nous avons activé le module SSL dans apache2 pour sécuriser le trafic.[URL_N7] A.U 2015-2016 40
CHAPITRE 2. SUPERVISION RÉSEAU D’abord il faut activer le module SSL puis redémarrer le service apache2. # sudo a2enmod ssl # sudo service apache2 restart Pour la configuration nous aurons besoin d’une certificat ssl. Nous utiliserons donc l’outil « OpenSSL ». # sudo mkdir /etc/apache2/ssl # cd /etc/apache2/ssl # sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt Après avoir entrer la commande ci_dessus, on nous demande de saisir quelques infor- mations. Country Name (2 letter code) [AU]:TN State or Province Name (full name) [Some-State]:Tunis Locality Name (eg, city) []:Menzah Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hexabyte Organizational Unit Name (eg, section) []:IT Department Common Name (e.g. server FQDN or YOUR name) []: Zabbix.hexabyte.tn Email Address []: Zabbix@hexabyte.tn Deux fichier ont été créer dans le dossier « /etc/apache2/ssl » : apache.crt et apache.key. Maintenant que nous avons la certificat et la clé nous allons configurer apache2 pour qu’il utilise ces deux fichiers.La configuration se fait dans sur le fichier « default-ssl.conf ». # sudo nano /etc/apache2/sites-available/default-ssl.conf Sans les commentaires le fichier sera comme suit. A.U 2015-2016 41
CHAPITRE 2. SUPERVISION RÉSEAU <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@hexabyte,tn DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key <FilesMatch ".(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule> Maintenant il ne reste qu’a activer le « SSL-enabled virtual host » et redémarrer le service apache. # sudo a2ensite default-ssl.conf # sudo service apache2 restart Maintenant que tout est mise en place nous pouvons accéder à l’interface de Zabbix via HTTPS. Il est nécessaire d’accepter le certificat pour que l’échange des données sera effectué. 2.5.7 Mise à jour de Zabbix L’un des plus grands défauts de Zabbix est que ses composants envoient les données non cryptées d’où le manque de sécurité. Un pirate peut facilement écouter le trafic et en savoir d’avantage sur le réseau. Dans la version 3.0 de Zabbix sortie le 16 février 2016, dont le développement a pris deux ans, on a inclus le chiffrement du trafic. Cette version apporte encore plus de fonctionnalités et d’améliorations graphiques. Il s’agit d’une ver- sion riche et complète. Le chiffrement du trafique échangé entre l’ensemble des composants est basé sur le protocole TLS . Il y a d’autres nouveautés offerte dans cette version, nous en citons : – les fonctions « prévision » et « temps restant » qui utilise des algorithmes de prédic- tion qui permettent de savoir dans combien de temps nous allons passer en dessous du seuil critique ou de savoir où on en sera de notre espace disque dans 1 heure, – L’utilisation du processeur par processus ou par utilisateurs, – Amélioration de la visualisation des graphes en offrant la possibilité de zoomer sur A.U 2015-2016 42
CHAPITRE 2. SUPERVISION RÉSEAU les graphiques, – L’ajout d’une fonctionnalité similaire à « Crontab » de linux, qui permet de lancer un script ou un évènement à une heure précise. etc Cette mise à jour est disponible à partir de Zabbix 2.2 ou à partir d’une version ultérieur. Il faut aussi vérifier si la version de php est 5.4.x . Avant de démarrer la mise à jour[URL_N8] il est préférable de créer un « backup » des fichiers de configuration et de la base de donnée. # cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup # cp /etc/httpd/conf.d/zabbix.conf /opt/zabbix-backup # cp /usr/share/doc/zabbix-* /opt/zabbix-backup # sudo mysqldump -uroot -p Zabbix > Zabbixdb.sql Afin d’effectuer la mise a jour nous allons suivre les étapes qui suivent. 2.5.7.1 installation des packages de la release 3 de Zabbix . # wget http://repo.zabbix.com/zabbix/3.0/ubuntu/pool/main/z/zabbix-release/ zabbix-release_3.0-1+trusty_all.deb # dpkg -i Zabbix-release_3.0-1+trusty_all.deb # sudo apt-get update 2.5.7.2 Installation de Zabbix 3 Installation du serveur Zabbix # sudo service Zabbix-server stop # sudo apt-get install –only-upgrade Zabbix-server-mysql Installation de la dernière version de l’interface web Zabbix # sudo apt-get install –only-upgrade Zabbix-frontend-php Notre serveur Zabbix est maintenant à son version 3 et prés à être utilisé. Il ne reste que de lancer le service et d’accéder à l’interface via un navigateur. # sudo service Zabbix-server start 2.5.8 Centralisation des logs Un log ou journal est une simple notification d’une importance plus ou moins élevée envoyée par l’OS, un équipement du réseau ou un service. Ces données permettent à l’ad- ministrateur du système de suivre les éventements et retracer les actions. Collecter les logs c’est très important, mais pouvoir les centraliser, les traiter et les analyser c’est encore plus ! C’est pour cette raison que nous avons décidé de mettre un A.U 2015-2016 43
CHAPITRE 2. SUPERVISION RÉSEAU place un centralisateur de logs qui va s’occuper du traitement des logs de tous le réseau. Nous avons donc choisis d’installer “GrayLog” [URL_N9]. Graylog est un logiciel de centralisation et d’analyse de logs très puissant. Il possède une interface web très ergonomique. Cet outil nécessite la mise en place des logiciels sui- vants. – Nxlog : Collecteur de logs. – Elasticsearch : Un serveur de recherche et d’indexation. – MangoDB : Base de données pour y stocker les informations. Qu’est ce que nous allons gagner de la centralisation des logs ? – Recherche et statistique : Centraliser les logs dans une seul machine va nous per- mettre d’effectuer des recherches trais précises sur l’activité des systèmes et des utilisateurs tout en étant connecté à partir d’une seule machine. – Détection d’intrusion : Les plus part des IDS se servent des fichiers de logs afin de détecter des comportements suspicieux sur une réseau. Dans ce cas l’IDS aura une source d’information de plus. – Garantir la disponibilité des logs : Si par malheur un pirate a attaqué notre réseau et pour éliminer ses traces, il a supprimé les fichiers logs. Dans ce cas, la centralisation est la solution idéal pour garantir la survie des logs en envoyant des copies au serveur. Comment la centralisation fonctionne ? 1. Tout d’abord il faut créer les logs, ils sont souvent générés par les services et les applications. 2. Ensuite, transférer les log dans le serveur de centralisation via des agents. 3. Puis, organiser les logs dans des répertoire ( Exemple : répertoire par machine) et les filtrer par des critères choisis. 4. Enfin, exploiter les logs : utilisation des Graphes, création des rapports et envoie des alertes. Ci-dessous, l’interface web du centralisateur des logs “GrayLog”. A.U 2015-2016 44
CHAPITRE 2. SUPERVISION RÉSEAU Figure 2.10 – GrayLog 2 GUI 2.6 Conclusion Au cours de ce chapitre, nous avons vu une introduction au domaine de supervision ré- seau, suivis par les étapes de l’installation, configuration et optimisation de la supervision. L’IDS sera le sujet du prochain chapitre. Ce dernier, couvrira le principe et les diffé- rentes caractéristiques des IDS suivi par l’installation et la configuration de la plateforme de détection d’intrusion. A.U 2015-2016 45
Chapitre 3 Détection d’intrusion 3.1 Introduction Les systèmes de détection d’intrusion, ou souvent appelés IDSs, sont devenus des composants essentiels dans les offices de sécurité et de l‘administration réseau. Cependant beaucoup d’experts en sécurité réseaux ignorent les avantages qu’offrent ces systèmes. Dans ce chapitre nous allons rappeler l’importance des IDSs dans un système d’infor- mation d’une entreprise et leurs différents types. Une description détaillée des étapes de l’installation sera par la suite introduite suivi par des configurations et des optimisations. 3.2 Systèmes de détection d’intrusion 3.2.1 Mode de fonctionnement Comme son nom l’indique un système de détection d’intrusion est fait pour détecter les intrusions, c’est à dire qu’il a pour but de détecter les attaques ciblant les équipements du réseau et alerter les personnes concernées. Un IDS installé dans un réseau peut être comparé à un système d’alarme installé dans une maison. À travers les différentes mé- thodes, ces deux systèmes détectent les intrusions et envoient une sorte de signal d’alarme spécifique. Un IDS peut être configuré afin de pouvoir travailler en coopération avec un firewall qui vise à contrôler le trafic. Il ne faut pas confondre ces deux outils de sécurité. Un firewall essaye de stopper les attaques et les accès interdits, il est souvent placé dans la première ligne de défense. Alors que l’IDS détecte si oui ou non le réseau est attaqué. C’est sûr que la mise en place d’un IDS va améliorer la sécurité d’un réseau mais il n’offre pas une garantie totale de la sécurité. En générale, l’IDS utilise deux techniques de détection[THI_04] : détection d’anoma- lies et détection par signatures. Détection d’anomalie C’est une technique utilisée afin de surveiller le comportement du réseau et de ses équipements. A chaque fois qu’il détecte un comportement anormal d’une machine, il le classe en tant que tentative d’intrusion : par exemple, si l’IDS détecte qu’un certain utilisateur s’est connecté sur une machine 15 fois alors que d’habitude il 46
CHAPITRE 3. DÉTECTION D’INTRUSION ne se connecte qu’une ou deux fois quotidiennement ou si un ordinateur a été utilisé à 3 :00am alors que personne n’est censé être sur son poste. Tout comportement suspicieux similaire aux exemples cités précédemment sera alerté. Détection par signatures Cette méthode utilise les signatures des comportements suspects les plus répandus dans le domaine des intrusions afin de prédire et détecter les tentatives d’attaques. Prenons l’exemple d’un échec de trois tentatives d’authentification d’un utilisateur sur une machine, il s’agit d’un cas suspect et doit être alerté afin de vérifier si c’est bien une tentative d’intrusion ou un simple accident. Dans le cas des attaques réseaux l’IDS vérifie l’intégrité des paquets et calculera leurs « checksums » pour les comparer aux signatures suspectes, si ils sont compatibles l’IDS va alerter l’administrateur de cet incident. 3.2.2 Types des IDS 3.2.2.1 Les HIDS (Host-based IDS) Les HIDS[THI_04] sont les tous premier IDS à avoir été développés et implémentés. Ce système collecte et analyse les données d’un hôte qui offre un service tel que service web ou base de données. Une fois que les données sont collectées, elles seront analysées par un agent localement ou elles seront envoyées vers une autre machine dédiée à cette tâche. Le HIDS peut être sous la forme d’un programme qui est installé sur un système d’exploitation afin d’analyser les fichiers logs ou les fichiers des résultats d’audit. Ce pro- gramme est très efficace contre les différentes attaques connues sur les machines, il est capable de détecter les « backdoors » et les « rootkits ». Aussi, il est capable de détecter les modifications interdites des fichiers importants. Cependant, il ne s’agit pas d’un système idéal. Le HIDS a un grand inconvénient, il peut être détecté facilement par le « hacker » et il peut lui bloquer la collection des données, il deviendra alors inutile. Exemple : OSSEC-HIDS : Il s’agit un HIDS open-source, il est capable d’analyser les logs, vérifier l’intégrité des fichiers, détecter les « rootkits » et envoyer des alertes en temps réels. C’est le HIDS open-source le plus utilisé. 3.2.2.2 Les NIDS (Network-based IDS) C’est un type d’IDS qui est capable d’écouter sur le réseau, sniffer le trafic et analyser les paquets. Ces paquets seront examinés par le NIDS[THI_04] et comparés avec des don- née suspectes pour vérifier s’ils sont malicieux ou bien non. Les NIDS sont responsables de la sécurité de tout un réseau et non pas d’une seule machine comme le cas d’un HIDS. Ils sont plus distribués. Au lieu de collecter les données depuis les machines, les NIDS les collectent depuis les paquets sniffés sur le réseau. Cette surveillance des connexions entre les terminaux rend le NIDS efficace en détection des tentatives des intrusions et des accès interdits. Il est A.U 2015-2016 47
CHAPITRE 3. DÉTECTION D’INTRUSION capable de détecter les accès non autorisés dans le réseau. Comme tout système, le NIDS a ses propres défauts : il ne peut pas sniffer tous les paquets si le débit du réseau est trop élevé. Aussi, il ne peut pas détecter les intrusions si les paquets contenant les « payloads » sont très bien chiffrés. Exemples : Snort : C’est un NIDS Open-Source, il a été développé par « sourcefire ». C’est le père des NIDS. Il peut aussi jouer le rôle d’un IPS (Intrusion Prevention system). Il est le plus utilisé. Suricata : C’est un NIDS de nouvelle génération, il est moins connu que Snort mais c’est un jeune rival Il a été développé par « Open Information Security Foundation » (OISF) . 3.3 Installation et mise en place de Prelude-IDS 3.3.1 Installation de Prelude Pour commencer l’installation de prélude manager[URL_N10] nous devons tout d’abord installer les librairies pré-requises pour le bon fonctionnement de Prelude. 3.3.1.1 Libprelude Avant tout nous installons les pré-requises de Libprelude :libgnutls-dev, python2.7- dev, libpcre3-dev, swig, pkg-config. Ces paquets sont installés par défaut dans le dépôt de Ubuntu. # sudo apt-get install libgnutls-dev python2.7-dev libpcre3-dev swig pkg-config Ensuite nous téléchargeons l’archive libprelude à l’aide de l’outil WGET et nous le compilerons. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/351/ libprelude-1.2.5.tar.gz # tar -xzf libprelude-1.2.5.tar.gz # cd libprelude-1.2.5 Avant de compiler Libprelude nous devons le configurer. # ./configure --without-lua –with-python=/usr/bin/python2.7 Il faut vérifier que le support de python est activé. A.U 2015-2016 48
CHAPITRE 3. DÉTECTION D’INTRUSION Figure 3.1 – Configuration de libprelude Pour lancer l’installation nous exécutons la commande suivante. # make & make install 3.3.1.2 LibpreludeDb Tout d’abord nous installerons le paquet de support MySQL. # sudo apt-get install libmysqlclient-dev Nous installons libprelude en suivant les étapes ci_dessous . # cd /tmp # wget https://www.prelude-siem.org/attachments/download/352/ libpreludedb-1.2.5.tar.gz # tar -xzf libpreludedb-1.2.5.tar.gz # cd libpreludedb-1.2.5 Afin que le « linker » trouve Prelude, nous configurons la variable d’environnement concerné comme suit. # sudo export LD_LIBRARY_PATH=/usr/local/lib Nous lancerons ensuite la configuration. # ./configure Il faut vérifier que le plugin MySQL est activé : Figure 3.2 – Configuration de libpreludeDb A.U 2015-2016 49
CHAPITRE 3. DÉTECTION D’INTRUSION Ensuite nous lançons l’installation. # sudo make & make install 3.3.1.3 Base de données Prelude-admin Prelude a besoin d’une base de données pour y stocker les données des alertes et des évènements. Nous allons donc créer une base de données avec MySQL. # mysql -u root -p« password » mysql> CREATE DATABASE Prelude; mysql> CREATE USER ’prelude’@’localhost’ IDENTIFIED BY ’OPPASSWORD’; mysql> GRANT USAGE ON *.* TO ’prelude’@’localhost’; mysql> GRANT ALL PRIVILEGES ON Prelude.* TO ’prelude’@’localhost’; mysql> exit; # mysql -u Prelude -pOPPASSWORD Prelude < /usr/local/share/ libpreludedb/classic/mysql.sql 3.3.1.4 Prelude-Manager Afin d’activer le module IDMEF(Intrusion Detection Message Exchange Format) nous devons installer les paquets d’XML et de support de la technique d’emballage TCP. # sudo apt-get install libxml2-dev libwrap0-dev Maintenant nous pouvons commencer l’installation de Prelude. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/356/ prelude-manager-1.2.5.tar.gz # tar -xzf Prelude-manager-1.2.5.tar.gz # cd Prelude-manager-1.2.5 # ./configure Il faut s’assurer que le support libCU est activé. Figure 3.3 – Configuration de Prelude-manager # sudo make & make install Prelude manager est maintenant installé, nous passons à sa configuration. A.U 2015-2016 50
CHAPITRE 3. DÉTECTION D’INTRUSION # sudo nano /usr/local/etc/prelude-manager/prelude-manager.conf Figure 3.4 – Fichier de configuration de Prelude-manager Il faut saisir les données de connexion dans la base de données : type (MySQL, Post- greSQL, Oracle), host (l’adresse IP/ nom de domaine du serveur de base de données), port (3306 par défaut pour MySQL), Name(nom de la base de données), user( nom de l’utilisateur de la base de données) et le passe(mot de passe de l’utilisateur). 3.3.1.5 Prelude-Correlator l’installation de Prelude-correlator se fait par l’outil apt-get. # sudo apt-get install Prelude-correlator Nous allons configurer la corrélation avec le démarrage du système. # sudo nano /etc/default/prelude-correlator Il faut changer la valeur de la variable « RUN » de «no» en «yes». 3.3.1.6 Prelude-LML il faut d’abord installer libicu-dev, c’est une librairie pré-requise. # sudo apt-get install libicu-dev Puis suivre les étapes suivantes. A.U 2015-2016 51
CHAPITRE 3. DÉTECTION D’INTRUSION # cd /tmp # wget https://www.prelude-siem.org/attachments/download/354/ prelude-lml-1.2.5.tar.gz # tar -xzf Prelude-lml-1.2.5.tar.gz # cd Prelude-lml-1.2.5 #./configure Il faut s’assurer que le support liblCU est bien activé : Figure 3.5 – Configuration de Prelude-lml # sudo make & make install Prelude-lml est maintenant installé avec succès, nous passons à l’ajout de règles pour cette sonde. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/355/ prelude-lml-rules-1.2.5.tar.gz # tar -xzf Prelude-lml-rules-1.2.5.tar.gz # cd Prelude-lml-rules-1.2.5 # cp -r ruleset /usr/local/etc/prelude-lml/ Il ne reste qu’à configurer Prelude-lml via son fichier de configuration. # sudo nano /usr/local/etc/prelude-lml/prelude-lml.conf A.U 2015-2016 52
CHAPITRE 3. DÉTECTION D’INTRUSION Figure 3.6 – Fichier de configuration de Prelude-lml Dans ce fichier, nous indiquons l’adresse IP du serveur et les fichiers log que Prelude- lml va analyser et superviser. 3.3.1.7 Prewikka Prewikka est l’interface web de Prelude, il permet de visualiser les évènements et les alertes. Nous allons maintenant installer et configurer cette interface. Pour garantir le bon fonctionnement de prewikka nous devons d’abord installer des logiciels prérequis. # sudo apt-get install python-cheetah python-setuptools python-cairo python-netaddr gettext Nous allons commencer l’installation de prewikka, en suivant les étapes ci-dessous. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/357/ prewikka-1.2.5.tar.gz # tar -xzf prewikka-1.2.5.tar.gz # cd prewikka-1.2.5 Puis nous l’installons avec python 2.7 . # sudo python2.7 setup.py install --record prewikka_files.txt --prefix /usr/local Maintenant nous allons configurer la base de données de prewikka. A.U 2015-2016 53
CHAPITRE 3. DÉTECTION D’INTRUSION # mysql -u root -p mysql> CREATE database prewikka; mysql> CREATE USER ’prewikka’@’localhost’ IDENTIFIED BY ’prewikkaPassword’; mysql> GRANT USAGE ON *.* TO ’prewikka’@’localhost’; mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prewikka’@’localhost’; mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prelude’@’localhost’; mysql> exit; # mysql -u prewikka -pprewikkaPassword prewikka < /usr/local/share/prewikka/database/ mysql.sql Nous allons modifier le fichier de configuration de prewikka avec les coordonnées de la base de données récemment crées. # sudo nano /usr/local/etc/prewikka/prewikka.con Figure 3.7 – Fichier de configuration de prewikka 3.3.2 Installation des agents de surveillance 3.3.2.1 Profil Prelude-Manager Pour créer un profil Prelude-Manager[URL_N10] , nous allons utiliser la commande « prelude-admin ». L’« uid » et le « gid » doivent passer en arguments pour pouvoir crée le profil. # sudo Prelude-admin add Prelude-manager --uid 0 --gid 0 A.U 2015-2016 54
CHAPITRE 3. DÉTECTION D’INTRUSION Figure 3.8 – Ajout d’un profil Prelude-manager Sondes Prelude-LML Pour que Prelude enregistre une sonde, il faut exécuter deux commandes en parallèle comme ci_dessous. TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register Prelude-lml "idmef:rw admin:r" 127.0.0.1 --uid 0 --gid 0 Figure 3.9 – Enregistrement de Prelude-lml 3.3.2.2 Sonde Prelude-Correlator L’utilisateur Prelude-Correlator a déjà été créé pendant l’installation. Nous aurons besoin de savoir l’« uid » et le « gid » de l’utilisateur, pour cela on exécute la commande ci-dessous. A.U 2015-2016 55
CHAPITRE 3. DÉTECTION D’INTRUSION # id Prelude-correlator Figure 3.10 – l’uid et le gid de Prelude-correlator Dans notre cas : uid=116 & gid=126. C’est avec ces variables que nous allons pouvoir installer correctement la sonde Prelude-correlator en suivant les étapes suivantes. TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register Prelude-correlator "idmef:rw admin:r" 127.0.0.1 --uid 116 --gid 126 La sonde Prelude-correlator est maintenant installée. 3.4 Optimisation de la détection d’intrusion 3.4.1 Utilisation de Prewikka en tant que service Pour simplifier l’utilisation de prewikka et rendre son démarrage et son arrêt plus fa- ciles, nous avons utilisé un script « bash » que nous avons trouvé après quelques recherches sur internet. Ce dernier va transformer prewikka en un service qu’on peut démarrer et arrêter avec des simples commandes. # sudo service prewikka start|stop ( restart|status ) Il faut tout d’abord copier le code source du script dans un fichier que nous allons nommer « prewikka » et l’enregistrer dans le répertoire /etc/init.d/ pour, enfin, lui attri- buer le droit de l’exécution. # sudo chmod +x /etc/init.d/prewikka A.U 2015-2016 56
CHAPITRE 3. DÉTECTION D’INTRUSION #!/bin/bash ### BEGIN INIT INFO # Provides: prewikka # Required-Start: $local_fs $remote_fs $network $syslog $named # Required-Stop: $local_fs $remote_fs $network $syslog $named # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Prewikka est l’interface officielle de Prelude-IDS ### END INIT INFO # Variables couleurs CSI="033[" CEND="${CSI}0m" -CGREEN="${CSI}1;32m" # PID du processus PID=$(netstat -tlnp | awk ’/:8000 */ {split($NF,a,"/"); print a[1]}’) # Variable d’environnement PYTHONPATH export PYTHONPATH=/usr/local/lib/python2.7/dist-packages: /usr/local/bin/prewikkahttpd start() { echo -n "Démarrage de Prewikka by Hexabyte..." /usr/local/bin/prewikka-httpd & echo -e " ${CGREEN}[OK]${CEND}" } stop() { echo -n "Arrêt de Prewikka by Hexabyte..." kill -9 $PID echo -e " ${CGREEN}[OK]${CEND}" } status() { if [[ $PID -gt 0 ]]; then echo -e "Prewikka est actuellement en service ${CGREEN}[OK]${CEND}" else echo "Prewikka n’est pas en service..." fi } case "$1" in start ) start;; stop) stop ;; restart ) stop start ;; status ) status ;; *) echo "Utilisation: $0 {start|stop|restart|status}" exit 1 ;; esac exit 0 A.U 2015-2016 57
CHAPITRE 3. DÉTECTION D’INTRUSION 3.4.2 Utilisation de Prelude-manager en tant que service Dans cette partie nous allons installer un script afin de simplifier le démarrage et l’ar- rêt de Prelude-manager, tout comme nous avons fait pour prewikka. Commençons par télécharger le scripte dans le répertoire /etc/init.d/. # wget https://gist.githubusercontent.com/hardware/92ffda173ed4db68be6f/ raw/89e146a5869b09f53863a13f90f146b5d76a408f/prelude-manager # sudo chmod +x Prelude-manager Pour lancer le service Prelude-manager nous lançons la commande suivante. # sudo service Prelude-manager start 3.4.3 Utilisation de Prelude-lml en tant que service Dans cette partie nous allons installer un script afin de simplifier le démarrage et l’arrêt de Prelude-lml, tout comme nous l’avons fait pour prewikka et Prelude-manager. Commençons par télécharger le scripte dans le répertoire /etc/init.d/. # wget https://gist.githubusercontent.com/hardware/e21731a31e03721a4633/ raw/72eb18e8da30c8972def826e35f520f5d8926f46/prelude-lml # sudo chmod +x Prelude-lml Pour lancer le service Prelude-lml nous lançons la commande suivante. # sudo service Prelude-lml start 3.4.4 Démarrage de Prelude lors du « boot » Pour que les services de Prelude se lancent en démarrage du système, nous allons exé- cuter quelque instruction simple. # sudo update-rc.d Prelude-manager defaults # sudo update-rc.d Prelude-lml defaults # sudo update-rc.d prewikka defaults 3.4.5 Ajout d’une sonde HIDS : OSSEC Nous avons installé Prelude et ses sondes officielles. Mais nous pouvons encore amélio- rer ses performances en ajoutant une sonde HIDS. Nous allons donc utiliser OSSEC[URL_N11]. L’installation d’OSSEC est très simple à effectuer. Suivons ces étapes. # cd /tmp # wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz # tar zxvf ossec-hids-2.6.tar.gz # cd ossec-hids-2.6/src # make setprelude # ./install.sh A.U 2015-2016 58
CHAPITRE 3. DÉTECTION D’INTRUSION Après la dernière commande nous serons amenés à saisir quelques informations comme le montre la figure ci_dessous : Figure 3.11 – Installation d’OSSEC Les paramètres de l’installation : – La langue de l’installation : en – Le type d’installation : server – Choix du répertoire d’installation : /etc/ossec. – Envoi de mail : « no » .C’est possible de la modifier après dans le fichier de confi- guration (/etc/ossec/etc/ossec.conf). – Pour le reste on laisse par défaut. L’installation est terminée, nous passons à la configuration de la sonde via son fichier de configuration. # sudo nano /etc/ossec/etc/ossec.conf Figure 3.12 – Fichier de configuration d’OSSEC Il ne reste qu’à enregistrer Ossec en tant que sonde HIDS pour Prelude, pour cela il faut chercher l’« uid » et le « gid » de l’utilisateur « OSSEC » : A.U 2015-2016 59
CHAPITRE 3. DÉTECTION D’INTRUSION Figure 3.13 – ID de l’utilisateur “OSSEC” Comme tout enregistrement de sonde sous Prelude, nous aurons besoin d’utiliser deux terminaux : TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register OSSEC "idmef:rw" 127.0.0.1 - -uid 1001 - -gid 1001 Nous avons terminé l’installation la sonde Ossec. 3.4.6 Ajout d’une Sonde NIDS : Suricata Bien que notre plate-forme possède des sondes officielles de Prelude et une sonde HIDS Ossec, il lui manque encore une sonde NIDS pour la surveillance au niveau du réseau. Pour cela nous avons choisi d’utiliser Suricata[URL_N12]. En premier lieu, nous allons installer les pré-requis. #sudo apt-get -y install libpcre3 libpcre3-dbg libpcre3-dev build-essential autoconf automake libtool libpcap-dev libnet1-dev libyaml-0-2 libyaml-dev zlib1g zlib1g-dev libcap-ng-dev libcap-ng0 make libmagic-dev Ensuite, nous aurons besoin de télécharger la dernière version de Suricata à partir du site officiel : http ://suricata-ids.org/download/ # tar -xzfv Suricata* Puis, la configuration du paquet avant la compilation. # ./configure --enable-prelude --with-libprelude-prefix=/usr/local --prefix=/usr --sysconfdir=/etc –localstatedir=/var # make && make install-full Une fois Suricata installée, nous effectuons le paramétrage de son fichier de configura- tion, mais avant cela il faut remplacer le fichier de configuration par défaut par le fichier de configuration dedié aux distributions qui sont basées sur Debian. Ce fichier se trouve ci-dessous. https://wiki.zentyal.org/wiki/Suricata-debian.yaml A.U 2015-2016 60
CHAPITRE 3. DÉTECTION D’INTRUSION # sudo nano /etc/suricata/suricata.yaml Figure 3.14 – Fichier de configuration de Suricata Enfin, pour lancer Surricata, la commande suivante doit être exécutée. # sudo suricata -c /etc/suricata/suricata.yaml -i eth0 3.4.7 Gestion des règles de Suricata avec Oinkmaster Chaque jour, nous découvrons un ensemble de nouvelles attaques. C’est pour cela qu’il faut mettre à jour les règles des IDS afin de protéger notre réseau. Il est possible d’installer ces nouvelles règles manuellement mais il existe des méthodes plus faciles et plus rapide parmi lesquelles “Pulled Pork” et “Oinkmaster”[URL_N13]. Dans notre cas nous allons opter pour “Oinkmaster”. Nous commençons par l’installation. # sudo apt-get install oinkmaster Oinkmaster doit savoir la source ou il peut extraire les nouvelles règles. Elles se trouvent ici. http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz Nous allons ajouter cette source dans le fichier de configuration d’Oinkmaster. # sudo nano /etc/oinkmaster.conf Nous commentons l’URL qui existe déjà et on ajoute la nouvelle source de la façons ci_dessous. url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz On sauvegarde le fichier. Ensuite nous allons créer un dossier afin d’y mettre les nouvelle règles. A.U 2015-2016 61
CHAPITRE 3. DÉTECTION D’INTRUSION # sudo mkdir /etc/suricata/rules # cd /etc # sudo oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules Dans le nouveau dossier des règles, nous devons les déclarer dans le fichier de configu- ration de Suricata. # sudo nano /etc/suricata/suricata.yaml Et nous insérons les lignes ci_dessous. classification-file: /etc/suricata/rules/classifcation.config reference-config-file: /etc/suricata/rules/reference.config Pour vérifier que la nouvelle configuration, on lance cette commande. # Suricata -c /etc/suricata/suricata.yaml -i eth0 Il est recommandé d’effectuer la mise à jour des règles fréquemment. C’est pour ça nous avons utiliser l’outil Crontab pour lancer la mise à jour quotidiennement 3.4.8 Mise en place du HoneyPot Kippo Un HoneyPot[URL_N14] ( Pot de miel ) est un faux service (ou parfois une machine virtuelle) installé sur une machine dans le but d’attirer l’attention des “hackers” et les piéger en envoyant leur identité. Kippo est un HoneyPot SSH. Il va prendre la place du service SSH en l’effectuant une configuration qui va le rendre non sécurisé. Pour cela nous devons changer le port de standard du protocole concerné. De cette façon, toute connexion au port 22 sur la machine protégée sera loggé et analyser ultérieurement par l’administrateur. Avant de commencer l’installation de Kippo, nous effectuons le changement du numéro de port du protocole SSH. # sudo nano /etc/ssh/sshd_config Il est possible de choisir n’importe quel port, il faut qu’il soit libre. (par exemple 13125). Commençons l’installation de Kippo. # sudo apt-get install python-twisted Il faut créer un utilisateur qui va exploiter le service. # sudo adduser kippo A.U 2015-2016 62
CHAPITRE 3. DÉTECTION D’INTRUSION Ensuite, télécharger et installer le package de Kippo (version 0.8). # cd/opt # wget http://kippo.googlecode.com/files/kippo-0.8.tar.gz # tar -zxvf kippo-0.8.tar.gz # sudo chown kippo:kippo kippo-0.8 -Rf Par défaut Kippo écoute sur le port 2222. Nous allons effectuer une configuration afin que iptables redirige les flux arrivant sur le port 22 vers le port 2222. # sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222 Il ne reste que de lancer le piège. # cd Kippo-0.8 # su kippo # ./start.sh Il est possible de sécuriser le service SSH en utilisant la technique PortKnocking. Pour en savoir plus, voir l’annexe A. 3.5 Conclusion Dans ce chapitre nous avons présenté une brève introduction à la détection d’intrusion en rappelant ses principes et ses méthodes de fonctionnement suivi par les étapes de l’installation et de la configuration de prelude et ses sondes. Figure 3.15 – Liste des Sondes Actives Dans ce qui suit nous allons entamer le dernier chapitre qui sera consacré pour la présentation de la solution finale suivis par des tests d’intrusion. A.U 2015-2016 63
Chapitre 4 Exploitation et tests 4.1 Introduction Dans ce présent chapitre, une brève démonstration de la solution finale sera présentée afin de montrer comment les logiciels installés ont été exploités et tester les performances du système de détection d’intrusion (IDS). 4.2 Tests d’intrusion : Pentest 4.2.1 Méthodologies Il existe deux principaux idéologies de test de pénétration : “Black Box Testing” et “White Box Testing”. Black box testing La société qui contracte une équipe de test de pénétration n’offre pas d’informations. Ce test est semblable à un boxeur confronté à un adversaire dont il ne connait rien. Ces deux boxeurs doivent apprendre à se connaitre pendant le combat. Pour ce faire, ils com- menceront par se tourner autour, pour connaitre les faiblesses de l’autre. Le combat peut progresser lentement étant donné que chacun d’eux rassemble des informations sur son adversaire pendant la rencontre. De même, Dans ce test, toutes les informations que les testeurs détiennent sont des informations collectées par eux-mêmes. Ce type de test s’ap- parente à une véritable attaque de pirates. Cela pourrait être utile si la société voulait savoir quels sont les informations qu’un “hacker” pouvait collecter sur elle. White box testing Ce type de test est à l’autre bout du spectre. Contrairement au boxeur qui ne sait rien de son adversaire, dans ce scénario le boxeur a bien préparé son combat. Il a visualisé les matches de son adversaire. Il a cherché ses faiblesses pour qu’il puisse les exploiter. Le “white box testing” est similaire à cette approche. Ici l’équipe de test de pénétration peut accéder aux codes source et à toutes les autres informations que la société peut lui offrir. Ce type de test est utile car les testeurs peuvent trouver et exploiter les vulnérabilités sans avoir à chercher l’information d’abord. Bien qu’il soit couteux, ce test peut faire gagner de l’argent à l’entreprise en permettant à l’équipe d’audit de se concentrer sur la détection et 64
CHAPITRE 4. EXPLOITATION ET TESTS l’exploitation des vulnérabilités sans perdre beaucoup de temps dans la phase de collecte d’informations. Ce que nous allons faire c’est de tester quelques méthodes d’attaques les plus connus et voir comment l’IDS va réagir. 4.2.2 Plateforme de test d’intrusion Afin de tester l’IDS nous avons réalisé quelques attaques dans un réseau virtuelle en utilisant le logiciel “Oracle VM VirtualBox”. Dans la machine serveur qui est représenté dans la figure qui suit, nous avons installé les sondes mentionnées dans le chapitre précédent. Une application web vulnérable à été hébergé sur le serveur. Il s’agit de DVWA(Damn Vulnerable Web App), c’est application web écrite avec PHP/MySQL qui contient des failles de sécurité. Elle a comme objectif de permettre aux professionnels de tester leurs compétences en matière de détection et d’exploitation des vulnérabilités. Dans un scénario de test que nous allons provoquer ultérieurement, une machine vir- tuelle sera installée et ajoutée dans le réseau afin de jouer le rôle d’une machine Linux vulnérables à un ensemble d’attaques. Nous y installerons un OS dédié pour cette tâche particulière connu sous le nom de “ Exploitable”. Figure 4.1 – Machines VirtualBox A.U 2015-2016 65
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.2 – Réseau de teste 4.2.3 Simulations d’attaques Dans ce qui suit nous allons montrer les scénarios que nous avons réalisé. En premier lieu, nous allons lancer une simple commande “traceroute”. il n’y a pas une méthode plus simple que celle-ci afin de commencer le collecte des informations à propos du réseau. Figure 4.3 – Commande traceroute Comme le montre la figure 4.4, nous avons utiliser l’outil “Httrack”. Cet outil permet de copier tout le contenue d’un site web ciblé dans la machine du “hacker” afin qu’il puisse analyser, scanner l’application sans qu’il soit détecté. A.U 2015-2016 66
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.4 – Scénario Httrack Puis nous allons Utiliser l’outil Zenmap afin de scanner le serveur. Zenmap est l’inter- face graphique du fameux Nmap. La commande Nmap executé dans la figure 4.5 permet de verifier l’etat de tous les ports TCP( 1-65535 ). Cet étape est trés critique, c’est la oû le “hacker” aura une vision plus claire sur l’état de la machine ciblée et sur les services qu’elle offre. Figure 4.5 – scénario Zenmap A.U 2015-2016 67
CHAPITRE 4. EXPLOITATION ET TESTS Dans la figure 4.6, une liste des techniques d’attaque disponibles sur l’outil Ettercap. Figure 4.6 – Ettercap attaques À l’aide d’Ettercap nous avons simulé une attaque de type “Man in the middle”. Cette technique consiste à effectuer un sniff de trafic entre deux terminaux choisis. Cela permet de capturer les données et même de les modifiées. Figure 4.7 – scénario ARP poisoning Pour terminer, nous avons utiliser Armitage pour Scanner le serveur. Armitage est l’interface graphique de l’outil “ Metasploit ”. A.U 2015-2016 68
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.8 – Scénario Armitage 4.2.4 Alertes Nous allons maintenant voir les notifications et les alertes qui ont été causées par les scénarios d’attaque cités dans la partie précedente. Comme le montre la figure 4.9, Suricata à bien été en garde afin de détecter les attaques web que le serveur Ubuntu à subit. A.U 2015-2016 69
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.9 – Alerte : service web attaqué Dans la figure 4.10, un ensemble d’alertes et de notifications, nous en citons : “Promiscious mode detected” : L’IDS a détecté une machine qui a activé le mode écoute du trafic dans un des ses interfaces. “SSHD authentification failed” : une personne à essayé de se connecter au serveur via SSH mais il n’a pas réussi. Si cela se répète encore, ça peut générer une alerte de niveau plus élevé. Figure 4.10 – Notifications de niveau bas Les alertes qui sont affichées dans la figure 4.11 ont été enclenché après un scanne fait A.U 2015-2016 70
CHAPITRE 4. EXPLOITATION ET TESTS par Nmap. Figure 4.11 – Scanne NMAP détecté Dans la figure 4.12, nous pouvons voir les alertes enclenchées après une attaque effectué à l’aide de metasploit. Figure 4.12 – Scanne détecté Un exemple d’une fausse alerte est affiché dans la figure 4.13. Les resultats de détection d’intrusion ne sont pas toujours fiables. A.U 2015-2016 71
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.13 – Fausse alerte 4.3 Interpretation des statistiques L’effort de Prewikka ne s’arrête pas à la visualisation des alertes, il peut aussi générer des graphes de statistiques. Ci-dessous un exemple de graphe. Ce dernier affiche le taux des alertes classées par niveau d’urgence sur un échelle temporel. Figure 4.14 – Prewikka : Graphe 1 Dans ce qui suit un graphe qui représente les alertes les plus rencontrées sur un échelle temporel. A.U 2015-2016 72
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.15 – Prewikka : Graphe 2 Les pourcentages des notifications classées par leurs descriptions sont affichées dans le graphe qui se trouve dans la figure 4.16. Figure 4.16 – Prewikka : Graphe 3 Ensuite, un graphe qui montre le taux des notification classées par leurs groupes de référence se trouve dans la figure ci-dessous. A.U 2015-2016 73
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.17 – Prewikka : Graphe 4 La figure 4.18 présente le taux des notifications groupés par niveau d’importance. Figure 4.18 – Prewikka : Graphe 5 La figure 4.18 présente les utilisateurs qui ont été ciblés en mentionnant le nombres d’attaques qu’ils ont subis. Figure 4.19 – Prewikka : Graphe 6 A.U 2015-2016 74
CHAPITRE 4. EXPLOITATION ET TESTS Dans le figure suivante, les taux des adresses IP qui ont été derrière l’enclenchement de l’alerte. Figure 4.20 – Prewikka : Graphe 7 Nous avons aussi la possibilité de surveiller les performances des sondes connectées à prelude via le graphe présenté dans la figure suivante. Figure 4.21 – Prewikka : Graphe 8 4.4 Hexadef Afin d’utiliser les outils que nous avons mise en place dans le réseau, l’administrateur doit consulter plusieurs interfaces : Prewikka (interface web de prelude), Zabbix frontend (interface web de zabbix), nessus et Graylog. Dans l’intention de rendre l’accès à ces interfaces plus facile, nous avons développé une application web qui regroupe ces quatre interfaces en une seule. Nous l’avons intitulé « HexaDef » ; “Hexa” comme “Hexabyte” et “Def” comme “Defender”. A.U 2015-2016 75
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.22 – Interface Hexadef A.U 2015-2016 76
CHAPITRE 4. EXPLOITATION ET TESTS Conclusion général Notre projet de fin d’étude a eu pour objectif l’installation, la configuration et la mise en place d’un outil de supervision réseau et d’un autre de détection d’intrusion réseau. Pour atteindre le but fixé, nous avons d’abord commencé par récolter des informations sur le réseau de l’entreprise et sur les outils Open d’administration réseau et de détection d’intrusions réseau. Ensuite, une étude comparative entre les nombreux outils open source a été menée et nous a permis de faire notre choix. Nous avons en effet choisi d’installé Zabbix en tant que logiciel de supervision principal suivi par des configurations avancées. Pour ce qui est du choix d’une solution IDS, nous nous sommes tournés vers Prelude- IDS et ses sondes. Nous sommes, juste après, passés à l’installation et à la configuration de ces différentes solutions. Pour finir, Un ensemble de tests d’intrusion a été réalisé afin de déterminer les performances de la plateforme de détection d’intrusion ; nous avons pré- senté un ensemble des statistiques que Prelude peut générer suivi par l’application web que nous avons commencé à développer. Nous avons, à travers ce stage, découvert le domaine de la supervision et de la détection d’intrusion réseaux et systèmes. Ce projet nous a également permis d’appliquer et d’amé- liorer nos connaissances du domaine de l’administration réseau et la sécurité informatique. En perspective, bien que notre projet ait satisfait les besoins de l’organisme d’accueil, des améliorations vont être ajoutées pour élargir la supervision et la surveillance du réseau et des systèmes mises en question. A.U 2015-2016 77
Bibliographie [URL_N1] WorkAroud, URL : https ://workaround.org/article/tired-of-nagios-and-cacti- try-zabbix [ dernière consultation : 10/05/2016] [AND_13] Andrea Dalle Vacche , Stefano Kewan Lee « Master Zabbix », packt publi- shing, 2013, ISBN : 9781783283491, 337 [URL_N2] ReadTheDocs, URL https ://shinken.readthedocs.io/en/latest/ [ dernière consultation : 25/05/2016 ] [URL_N3] AlienVault, URL : https ://www.alienvault.com/docs/whitepapers/OSSIM_vs_Commercial_White_Paper.pdf [URL_N4] MonitoringFR, URL : http ://wiki.monitoring-fr.org/zabbix/start#ii-installation [ dernière consultation : 25/05/2016 ] [THI_04] Thierry Evangelista « IDS : Les systèmes de détection des intrusions infor- matiques », InfoPro, 2004, ISBN : 9782100072576, 261 [URL_N5] TheDutchLab, URL : https ://thedutchlab.com/blog/installing-zabbix-on- ubuntu-1404 [ dernière consultation : 25/05/2016 ] [URL_N6] TecMint, URL : http ://www.tecmint.com/install-zabbix-agent-and-add-windows- host-to-zabbix-monioring/ [ dernièreconsultation : 25/05/2016 ] [URL_N7] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how- to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04 [ dernière consultation : 25/05/2016 ] [URL_N8] 2DayGeek, URL : http ://www.2daygeek.com/zabbix-upgrade-from-2-4-x- to-3-0-network-monitoring-tool-on-centos-rhel-debian-mint-ubuntu/ [ dernière consul- tation : 20/05/2016 ] [URL_N9] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how- to-install-graylog2-and-centralize-logs-on-ubuntu-14-04 [ dernière consultation : 24/05/2016 ] [URL_N10] Prelude-Siem, URL : https ://www.prelude-siem.org/projects/prelude/wiki [ dernière consultation : 25/05/2016 ] [URL_N11] ReadTheDocs, URL : http ://ossec-docs.readthedocs.io/en/latest/index.html [ dernière consultation : 5/05/2016 ] [URL_N12] OpenInfoSecFoundation, URL : https ://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation [ dernière consultation : 20/05/2016 ] [URL_N13] WZDFTPD, URL : https ://www.wzdftpd.net/blog/installing-suricata-with- oinkmaster-on-debian.html [ dernière consultation : 22/05/2016 ] 78
CHAPITRE 4. EXPLOITATION ET TESTS [URL_N14] IT-Connect, URL : http ://www.it-connect.fr/honey-pot-ssh-avec-kippo/#III_Test_et_visualisation_des_logs [ dernière consultation : 28/05/2016 ] A.U 2015-2016 79
Annexe A Principe Port-Knocking est une méthode qui permette une communication machine à machine dans laquelle les informations passent à travers des ports qui apparaissent à la première vue fermés. Pour avoir accès à un port spécifique, il faut d’abord saisir une séquence de connexions précise. L’utilisateur doit atteindre différents ports distincts dans un ordre bien précis afin d’ouvrir le port voulu. Les ports sont fermer par un pare-feu tant que la séquence Knock-Port n’a pas été effectué. Dans le cas d’un scanne des ports sur un serveur, touts les ports apparaissent fermés bien que le service qui fonctionne sur ce port soit en actif. C’est le pare-feu qui effectue un rejet (DROP). Prenons l’exemple du service SSH qui écoute sur le port 22 sachant que nous l’avons attribué la séquence de knock-port suivante : 2212 → 2213 → 2214. Si une personne se connecte au serveur via ssh sans avoir saisi la séquence effectué, le port 22 restera fermé et l’événement sera loggé. Si un utilisateur a bien saisie la séquence , le port 22 s’ouvrera pour une durée de temps limitée . . . les logs générés suite à ces événements peuvent être exploités par les outils de supervision et de détection d’intrusion. Installation et configuration de Knockd Commençons l’installation. # sudo apt-get install konckd # sudo nano /etc/knockd.conf 80
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.23 – Fichier de configuration de Knockd Knockd utilise le pare-feu Iptable. Ce dernier est disponible par défaut dans la majorité des distribution linux. Afin de lancer le service Knockd automatiquement au démarrage du système il faut modifier la valeur : START_KNOCKD=1. # nano /etc/default/knockd Figure 4.24 – Fichier de configuration du lancement automatique de Knockd Le lancement du service se fait par l’exécution de la commande suivante. # sudo service knockd start Une démonstration de demande de connexion directe au port 22 est présentée ci- dessous. A.U 2015-2016 81
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.25 – Connexion au serveur via PuTTY Le scénario des connexions n’a pas été respecté, ce qui résulte à l’erreur affiché dans la figure suivante. Figure 4.26 – Connexion refusé Dans l’exemple suivant, nous allons suivre les règles d’accès que Knockd propose. Figure 4.27 – Scénario d’accès SSH Après la réalisation de ce scenario nous nous connectons au port 22. A.U 2015-2016 82
CHAPITRE 4. EXPLOITATION ET TESTS Figure 4.28 – Connexion etablie Comme c’est affiché dans la figure précédente la connexion s’est établie avec succès . Remarque Cela dit cette technique n’est pas pratique avec les services publiques tel que le web. Par contre elle est utilisable avec les services ftp, ssh et telnet. A.U 2015-2016 83

Contenu connexe

PDF
siem.pdf
partomtestsecurite
 
PDF
Rapport finiale
parmarwenbencheikhali
 
PDF
Mise en place d'une solution du supérvision réseau
parRabeb Boumaiza
 
PDF
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
parTidiane Sylla
 
PDF
sécurité informatique
parMohammed Zaoui
 
PDF
Etude et mise en place d’une solution open source de gestion de la sécurité d...
parMohammed LAAZIZLI
 
DOCX
mémoire de projet de fin d'études
parMortadhaBouallagui
 
PDF
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
parSalmen HITANA
 
siem.pdf
partomtestsecurite
 
Rapport finiale
parmarwenbencheikhali
 
Mise en place d'une solution du supérvision réseau
parRabeb Boumaiza
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
parTidiane Sylla
 
sécurité informatique
parMohammed Zaoui
 
Etude et mise en place d’une solution open source de gestion de la sécurité d...
parMohammed LAAZIZLI
 
mémoire de projet de fin d'études
parMortadhaBouallagui
 
Mise en place d’une solution de tests de sécurité pour les passerelles réside...
parSalmen HITANA
 

Tendances

PDF
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
parMELLAH MOULOUD Sorbonne Université - Sciences et Ingénierie
 
PDF
Le Pare-feu: Limites, Performances et Meilleures Pratiques
parMohamed Sabra
 
PDF
MONITORING APPLICATIF
parYoussef NIDABRAHIM
 
DOCX
Rapprot de satge supervision de résau par EyesOfNetwok
parAbdessamad IDRISSI
 
PDF
Mini projet Zabbix
parSamiMessaoudi4
 
PDF
Mise En Place d'une Solution de Supervision Réseau
parYaya N'Tyeni Sanogo
 
PPTX
Wazuh Pre.pptx
paremnabenamor3
 
PPSX
Supervision de réseau informatique - Nagios
parAziz Rgd
 
PPTX
Sécurité Réseau à Base d'un Firewall Matériel (fortigate)
parSakka Mustapha
 
PPTX
Etude et mise en place d'une solution d'administration et de supervision Open...
parChiheb Ouaghlani
 
PDF
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
parCharif Khrichfa
 
PDF
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
parAbdallah YACOUBA
 
PPTX
Supervision V2 ppt
parjeehane
 
PPTX
supervision réseau (snmp netflow)
parmedalaa
 
PPTX
ZABBIX ET PRTG
parAichétou Djimé Gallédou
 
PPTX
Wazuh Pre.pptx
paremnabenamor3
 
PPTX
Moussasambe projet de securite zabbix
parmoussa sambe
 
PDF
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
parBorel NZOGANG
 
PDF
Pfe master fst_final_decembre2015
parGhali Rahma
 
DOCX
Rapport mise en place d'un sevrer VPN .
parMouad Lousimi
 
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
parMELLAH MOULOUD Sorbonne Université - Sciences et Ingénierie
 
Le Pare-feu: Limites, Performances et Meilleures Pratiques
parMohamed Sabra
 
MONITORING APPLICATIF
parYoussef NIDABRAHIM
 
Rapprot de satge supervision de résau par EyesOfNetwok
parAbdessamad IDRISSI
 
Mini projet Zabbix
parSamiMessaoudi4
 
Mise En Place d'une Solution de Supervision Réseau
parYaya N'Tyeni Sanogo
 
Wazuh Pre.pptx
paremnabenamor3
 
Supervision de réseau informatique - Nagios
parAziz Rgd
 
Sécurité Réseau à Base d'un Firewall Matériel (fortigate)
parSakka Mustapha
 
Etude et mise en place d'une solution d'administration et de supervision Open...
parChiheb Ouaghlani
 
Mise en place de la solution d’authentification Radius sous réseau LAN câblé
parCharif Khrichfa
 
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
parAbdallah YACOUBA
 
Supervision V2 ppt
parjeehane
 
supervision réseau (snmp netflow)
parmedalaa
 
ZABBIX ET PRTG
parAichétou Djimé Gallédou
 
Wazuh Pre.pptx
paremnabenamor3
 
Moussasambe projet de securite zabbix
parmoussa sambe
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
parBorel NZOGANG
 
Pfe master fst_final_decembre2015
parGhali Rahma
 
Rapport mise en place d'un sevrer VPN .
parMouad Lousimi
 

Similaire à Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Système et Réseau

PDF
Conception et Développement d'un Network Management System ATM Nortel
parTidiane Sylla
 
PDF
Supervision d'un réseau informatique avec Nagios
parchristedy keihouad
 
PDF
Rapport de stage : Développement d’une application web de vidéosurveillance I...
parAbderahman Ouzzani chahdie
 
PPTX
Installation et configuration d'un système de Détection d'intrusion (IDS)
parCharif Khrichfa
 
PPTX
IDS,SNORT ET SÉCURITÉ RESEAU
parCHAOUACHI marwen
 
PDF
Report Master
parBilel Trabelsi
 
PDF
anssi-guide-passerelle_internet_securisee-v3.pdf
parBadr Belhajja
 
PDF
Ids
parEthan King
 
PDF
Installation et Configuration d_un systeme de Detection d_intrusion (IDS).pdf
parngombeemmanuel
 
PPT
maintenance et surveillance du réseau LAN.ppt
parjulodg
 
PDF
Preparation tpcisco reseaux
parBaudosky Konnigui
 
PDF
Réseaux-et-Sécurité.pdf
parMoufidaHajjaj
 
PDF
Algorithmique et programmation Algorithmique et programmation
parISMAILNEGABI1
 
PPTX
839310339-Cours-surveillance-des-reseaux.pptx
parIbrahimaCisse28
 
PPTX
Presentation Of indfra network du PFE.pptx
paryassinqattib
 
PPTX
Présentation du projet de fin d'année PowerPoint.pptx
parharounamamadouabdoul
 
PPTX
securisation inormatiquepourlaformation.pptx
parMahRandriamitsiry
 
PPTX
présentation PFE1231231231231231231321.pptx
paryoussefbb2003
 
PDF
Guide de sécurité_réseau
parMoussa Touré LÔ , ITIL®V3
 
PDF
Cy9808 formation-les-fondamentaux-de-la-securite-informatique
parCERTyou Formation
 
Conception et Développement d'un Network Management System ATM Nortel
parTidiane Sylla
 
Supervision d'un réseau informatique avec Nagios
parchristedy keihouad
 
Rapport de stage : Développement d’une application web de vidéosurveillance I...
parAbderahman Ouzzani chahdie
 
Installation et configuration d'un système de Détection d'intrusion (IDS)
parCharif Khrichfa
 
IDS,SNORT ET SÉCURITÉ RESEAU
parCHAOUACHI marwen
 
Report Master
parBilel Trabelsi
 
anssi-guide-passerelle_internet_securisee-v3.pdf
parBadr Belhajja
 
Ids
parEthan King
 
Installation et Configuration d_un systeme de Detection d_intrusion (IDS).pdf
parngombeemmanuel
 
maintenance et surveillance du réseau LAN.ppt
parjulodg
 
Preparation tpcisco reseaux
parBaudosky Konnigui
 
Réseaux-et-Sécurité.pdf
parMoufidaHajjaj
 
Algorithmique et programmation Algorithmique et programmation
parISMAILNEGABI1
 
839310339-Cours-surveillance-des-reseaux.pptx
parIbrahimaCisse28
 
Presentation Of indfra network du PFE.pptx
paryassinqattib
 
Présentation du projet de fin d'année PowerPoint.pptx
parharounamamadouabdoul
 
securisation inormatiquepourlaformation.pptx
parMahRandriamitsiry
 
présentation PFE1231231231231231231321.pptx
paryoussefbb2003
 
Guide de sécurité_réseau
parMoussa Touré LÔ , ITIL®V3
 
Cy9808 formation-les-fondamentaux-de-la-securite-informatique
parCERTyou Formation
 

Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Système et Réseau

  • 1.
    République Tunisienne Ministère del’Enseignement Supérieur, de la Recherche Scientifique et de la Technologie -- Université de Carthage CODE: P-TRT-2 Rapport de Projet de Fin d'Etudes Pour l’obtention du diplôme de Licence appliquée en Réseaux de l’Informatique Spécialité: Technologies de l’Informatique et de Télécommunication Intitulé: Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Système et Réseau Réalisé par: Alaadine Tlich Nabil Kherfani Au sein de: Hexabyte Encadré par: M. Nizar Ben Neji Faculté des Sciences de Bizerte M. Rached Ben Hassine Hexabyte Présenté devant le jury composé de: M. Tarek Ben Mena Président Mme. Rim Haddad Rapporteur Année Universitaire 2015 / 2016
  • 2.
    Remerciements Merci Dieu denous avoir donner la force et le courage d’aller jusqu’au bout sans dou- ter de nos compétences. D’abord, nos remerciements les plus sincères à l’encadrant pédagogique M.Nizar Ben Neji pour ses efforts et ses interventions inestimables qui nous ont bien aidé à avancer et aller de l’avant. Nos remerciements s’adressent également à M.Mohamed Ould Lhassan, qui a veillé au bon déroulement du projet et nous a aidé à ameloirer nos compétences grâce aux forma- tions durant la période du stage. Tous nos remerciements vont également à l’encadrant de la société M.Rached Ben Hassin, qui nous a soutenu et guidé tout au long du projet. Un Merci à tous nos amis et surtout l’équipe Cod4Squad qui nous ont bien fait perdre du temps à jouer au lieu de s’occuper de notre travail. Et bien évidemment, merci aux juris qui ont accépté d’évaluer notre travail. _____________________Alâa Eddine Tlich & Nabil Kherfani A.U 2015-2016 1
  • 3.
    Table des matières Introduction9 1 Présentation générale du projet 11 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.2 Composants du réseau . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.1 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.2 Principales attaques et menaces . . . . . . . . . . . . . . . 15 1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.3 Travail à faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Étude Comparative des solutions Open-Source . . . . . . . . . . . . . . . . 17 1.4.1 Outils de supervision . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4.1.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 18 1.4.1.2 Récapitulatif des outils de supervision . . . . . . . . . . . 21 1.4.1.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 22 1.4.2 Outils de détection d’intrusion . . . . . . . . . . . . . . . . . . . . 22 1.4.2.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 22 1.4.2.2 Récapitulatif des IDS . . . . . . . . . . . . . . . . . . . . . 25 1.4.2.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 26 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2 Supervision réseau 27 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Introduction à la supervision réseau . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2 Superviser quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Méthodes de supervisions . . . . . . . . . . . . . . . . . . . . . . . 28 2.3 Installation et configuration de Zabbix . . . . . . . . . . . . . . . . . . . . 28 2.3.1 Installation du serveur Zabbix . . . . . . . . . . . . . . . . . . . . . 28 2.3.2 Configuration du serveur Zabbix . . . . . . . . . . . . . . . . . . . 29 2.3.3 Configuration de la base de données de Zabbix . . . . . . . . . . . . 29 2.3.4 Configuration du serveur apache2 . . . . . . . . . . . . . . . . . . . 30 2.4 Ajout d’une station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.1 Installation d’un agent Zabbix . . . . . . . . . . . . . . . . . . . . . 32 2
  • 4.
    TABLE DES MATIÈRES 2.4.1.1Sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.1.2 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.2 Ajout du nouveau hôte dans le serveur . . . . . . . . . . . . . . . . 33 2.5 Amélioration et Optimisation de la supervision . . . . . . . . . . . . . . . . 33 2.5.1 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.2 Alerte par Courriel électronique . . . . . . . . . . . . . . . . . . . . 36 2.5.3 Supervision des serveur VOIP . . . . . . . . . . . . . . . . . . . . . 37 2.5.4 Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.5.5 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.5.6 Activation de SSL dans apache2 . . . . . . . . . . . . . . . . . . . . 40 2.5.7 Mise à jour de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.5.7.1 installation des packages de la release 3 de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.5.7.2 Installation de Zabbix 3 . . . . . . . . . . . . . . . . . . . 43 2.5.8 Centralisation des logs . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3 Détection d’intrusion 46 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Systèmes de détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.1 Mode de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.2 Types des IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.2.1 Les HIDS (Host-based IDS) . . . . . . . . . . . . . . . . . 47 3.2.2.2 Les NIDS (Network-based IDS) . . . . . . . . . . . . . . 47 3.3 Installation et mise en place de Prelude-IDS . . . . . . . . . . . . . . . . . 48 3.3.1 Installation de Prelude . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1.1 Libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1.2 LibpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.1.3 Base de données Prelude-admin . . . . . . . . . . . . . . . 50 3.3.1.4 Prelude-Manager . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1.5 Prelude-Correlator . . . . . . . . . . . . . . . . . . . . . . 51 3.3.1.6 Prelude-LML . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.1.7 Prewikka . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3.2 Installation des agents de surveillance . . . . . . . . . . . . . . . . . 54 3.3.2.1 Profil Prelude-Manager . . . . . . . . . . . . . . . . . . . 54 3.3.2.2 Sonde Prelude-Correlator . . . . . . . . . . . . . . . . . . 55 3.4 Optimisation de la détection d’intrusion . . . . . . . . . . . . . . . . . . . 56 3.4.1 Utilisation de Prewikka en tant que service . . . . . . . . . . . . . . 56 3.4.2 Utilisation de Prelude-manager en tant que service . . . . . . . . . 58 3.4.3 Utilisation de Prelude-lml en tant que service . . . . . . . . . . . . 58 3.4.4 Démarrage de Prelude lors du « boot » . . . . . . . . . . . . . . . . 58 3.4.5 Ajout d’une sonde HIDS : OSSEC . . . . . . . . . . . . . . . . . . . 58 3.4.6 Ajout d’une Sonde NIDS : Suricata . . . . . . . . . . . . . . . . . . 60 3.4.7 Gestion des règles de Suricata avec Oinkmaster . . . . . . . . . . . 61 3.4.8 Mise en place du HoneyPot Kippo . . . . . . . . . . . . . . . . . . . 62 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 A.U 2015-2016 3
  • 5.
    TABLE DES MATIÈRES 4Exploitation et tests 64 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2 Tests d’intrusion : Pentest . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.1 Méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.2 Plateforme de test d’intrusion . . . . . . . . . . . . . . . . . . . . . 65 4.2.3 Simulations d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.4 Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.3 Interpretation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.4 Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Conclusion général 77 Annexe A 80 A.U 2015-2016 4
  • 6.
    Table des figures 1.1Organigramme d’Hexabyte . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 les motivations des attaques informatiques . . . . . . . . . . . . . . . . . . 14 1.3 Évolution du nombre d’événements détectés par l’ANSI en 2015 . . . . . . 15 1.4 Répartition IP par continent en 2015 . . . . . . . . . . . . . . . . . . . . . 15 1.5 Les techniques de piratage les plus utilisées . . . . . . . . . . . . . . . . . . 15 1.6 Architecture de Centreon et sa relation avec Nagios . . . . . . . . . . . . . 19 1.7 Architecture de Shinken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Liste des scripts développés . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2 démo : “Check Services Status” . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3 Démo : “Disk : Bad Blocks” . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4 Démo : “TopCpu Consumers” . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.5 Démo : “Last Activities” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.6 Exemple d’un message reçu . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.7 Exemple d’un tableau de bord (screen) . . . . . . . . . . . . . . . . . . . . 38 2.8 exemple d’une “map” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.9 Formulaire de création d’une “map” . . . . . . . . . . . . . . . . . . . . . . 39 2.10 GrayLog 2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1 Configuration de libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Configuration de libpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Configuration de Prelude-manager . . . . . . . . . . . . . . . . . . . . . . . 50 3.4 Fichier de configuration de Prelude-manager . . . . . . . . . . . . . . . . . 51 3.5 Configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.6 Fichier de configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . 53 3.7 Fichier de configuration de prewikka . . . . . . . . . . . . . . . . . . . . . 54 3.8 Ajout d’un profil Prelude-manager . . . . . . . . . . . . . . . . . . . . . . 55 3.9 Enregistrement de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.10 l’uid et le gid de Prelude-correlator . . . . . . . . . . . . . . . . . . . . . . 56 3.11 Installation d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.12 Fichier de configuration d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . 59 3.13 ID de l’utilisateur “OSSEC” . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.14 Fichier de configuration de Suricata . . . . . . . . . . . . . . . . . . . . . . 61 3.15 Liste des Sondes Actives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1 Machines VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Réseau de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3 Commande traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4 Scénario Httrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5
  • 7.
    TABLE DES FIGURES 4.5scénario Zenmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.6 Ettercap attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.7 scénario ARP poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.8 Scénario Armitage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.9 Alerte : service web attaqué . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.10 Notifications de niveau bas . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.11 Scanne NMAP détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.12 Scanne détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.13 Fausse alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.14 Prewikka : Graphe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.15 Prewikka : Graphe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.16 Prewikka : Graphe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.17 Prewikka : Graphe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.18 Prewikka : Graphe 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.19 Prewikka : Graphe 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.20 Prewikka : Graphe 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.21 Prewikka : Graphe 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.22 Interface Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.23 Fichier de configuration de Knockd . . . . . . . . . . . . . . . . . . . . . . 81 4.24 Fichier de configuration du lancement automatique de Knockd . . . . . . . 81 4.25 Connexion au serveur via PuTTY . . . . . . . . . . . . . . . . . . . . . . . 82 4.26 Connexion refusé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.27 Scénario d’accès SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.28 Connexion etablie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.U 2015-2016 6
  • 8.
    Liste des tableaux 1.1liste des serveurs et leurs services . . . . . . . . . . . . . . . . . . . . . . . 13 1.2 Tableau comparatif des outils de supervision . . . . . . . . . . . . . . . . . 21 1.3 Tableau comparatif des solutions de détection d’intrusion . . . . . . . . . . 25 7
  • 9.
    Abréviations & Acronymes IDS: Intrusion Detection System HIDS : Host-based Intrusion Detection System NIDS : Network-based Intrusion Detection System IPS : Intrusion Prevention System LAN : Local Area Network XDSL : x Digital Subscriber Line ADSL : Asymmetric Digital Subscriber Line VSAT : Vulnerability Self Assessment Tool WIMAX : Worldwide Interoperability for Microwave Access RTC : Réseau Téléphonique Commuté GPS : Global Positioning System ANSI : Agence Nationale de la Sécurité Informatique DOS : Deny Of Service SET : Social Engeneering Toolkit SNMP : Simple Network Management Protocol API : Application Program Interface USM : Unified Security Management SSH : Secure Shell TTY : Terminal Type SSL : Secure Sockets Layer SMTP : Simple Mail Transfer Protocol VOIP : Voice over Internet Protocol TLS : Transport Layer Security IDMEF : Intrusion Detection Message Exchange Format TCP : Transport Control Protocol LML : Log Monitoring Lacke UID : User Identifier GID : Group Identifier DVWA : Damn Vulnerable Web App 8
  • 10.
    Introduction A l’heure actuelle,les systèmes d’information ne cesse d’évoluer et leur utilisation de- vient de plus en plus importante. Cependant, la complexité de la maintenance et de la gestion de ces systèmes augmente de jour en jour et le garantie de leur sécurité est de plus en plus difficile. Ces systèmes ont bien mérité leur place au sein des entreprises dans lesquels ils sont devenus indispensables. Un bon réseau est un réseau bien sécurisé. Il est donc favorable de suivre certaines règles afin de garantir l’intégrité des données, la confidentialité, la disponibilité des ser- vices, la non-répudiation et l’authentification des utilisateurs : – Intégrité : Vérifier si les données n’ont pas été modifiées durant la communication de manière intentionnelle ou fortuite. – Confidentialité : Assurer que seules les personnes autorisées aient accès à une res- source quelconque. – Disponibilité : S’assurer qu’un service ou une ressource soit disponible à la demande. – Non-répudiation : S’assurer qu’aucun des correspondants ne pourra nier les tran- sactions qui ont eu lieu. – Authentification : Assurer l’identité d’un utilisateur, c’est à dire garantir à chacun des correspondants que son partenaire est bien celui qu’il croit être. Ceci dit, garantir la sécurité d’un système informatique n’est pas évidente. C’est une tâche compliquée et difficile à gérer. L’administrateur du système doit concevoir le réseau de manière à prendre en compte tous les scénarios possibles. Dans ce cadre s’inscrit notre projet de fin d’étude qui consiste à réaliser une étude sur les solutions libres des supervisions réseaux et des systèmes de détection d’intrusions et de les installer au sein du réseau d’Hexabyte. Ce travail a été réalisé en vue d’obtenir le diplôme en technologies de l’informatique et de Télécommunication à la faculté des sciences de Bizerte. Le présent rapport sera composé de quatre chapitres : Dans le premier chapitre, l’organisme d’accueil, qui nous a accueilli durant notre pé- riode de stage, sera présenté en rappelant les produits et les services qu’il offre. Par la suite, nous rappellerons les problématiques qui se posent dans le réseau de l’entreprise. Enfin, une étude comparative sera réalisée sur les systèmes de supervision et les systèmes de détection d’intrusion. Le second chapitre sera dédié à la supervision. Il aura pour objectif de rappeler le concept de supervision et d’administration des réseaux. Nous allons installer la solution choisie dans le réseau et la configurer. Il y aura aussi des configurations avancées afin 9
  • 11.
    LISTE DES TABLEAUX d’optimiserla supervision et la sécurité du réseau. Le troisième chapitre sera consacré à la détection des intrusions. Il aura pour objectif de rappeler les méthodes de détection des intrusions et de définir les types des IDS. Nous allons voir les étapes de l’installation et la configuration du système de détection d’intru- sion choisi. Dans le dernier chapitre, nous présenterons notre plate-forme finale. Une démons- tration de son fonctionnement et des tests relatifs aux divers scénarios possibles seront effectués. A.U 2015-2016 10
  • 12.
    Chapitre 1 Présentation généraledu projet 1.1 Introduction Dans ce chapitre nous présenterons en premier lieu notre organisme d’accueil Hexa- byte et les différents composants de son réseau. En second lieu, nous présenterons le cadre générale de notre projet suivi par la problématique rencontrée, les objectifs visés et la solution proposée. Une étude comparative fera le sujet de la dernière partie de ce chapitre dans laquelle les caractéristiques des systèmes de supervision et de détection d’intrusion seront traitées. 1.2 Organisme d’accueil 1.2.1 Présentation La société HEXABYTE a été créée en 2001 sous la forme d’une Société Anonyme de droit tunisien avec un capital social initial de 280.000 DT. A la suite d’une opération d’incorporation de réserves et d’une autre d’apports en numéraire le dit capital est passé à la fin de 2010 à 1.750.000 DT réparti en 1 750 000 actions de nominal 1 dinar. Le siège social de la société est situé à Béja, où se trouve aussi l’essentiel de son maté- riel d’exploitation.La société HEXABYTE a pour objectif principal de fournir des services à valeur ajoutée de télécommunication de type internet ainsi que la conception, la pro- duction et la commercialisation de tous logiciels, matériels et équipements informatiques. La société dispose des différentes autorisations suivantes : – Autorisation triennale d’exercice de l’activité de Fournisseur de Service Internet « FSI » délivrée par le Ministère des technologies de la communication, ayant toujours fait l’objet de renouvèlements périodiques, – Autorisation TR2 d’exercice de l’activité d’installation et de maintenance de tout équipement de transmission et de réception radio, – Autorisation TM2 d’exercice de l’activité d’installation et de maintenance de tout équipement de transmission de données numériques. 11
  • 13.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Le renouvèlement de ces autorisations est quasiment systématique tant que la société res- pecte les dispositions légales et règlementaires régissant son activité. La société Hexabyte s’est toujours distinguée par ses offres innovantes sur le marché tunisien à travers le lancement de produits (p.ex. : tablettes PC, caméras de surveillance) ou de services (p.ex. : streaming vidéo ) répondant aux attentes de sa clientèle. La société est gérée par un jeune Directeur Général en la personne de M. Naceur HIDOUSSI. Celui-ci est sorti major de l’École Supérieure des Postes et Télécommunica- tions de Tunis (ESPTT) en 1998 et a obtenu, deux ans plus tard, son master en génie électrique à la California State Polytechnic University, aux États-Unis. Il a travaillé dans un premier temps en Californie de janvier 2000 à janvier 2001 pour la compagnie Hu- ghes and Space Communication, puis dans un deuxième temps, il a mis ses compétences au service du projet Thuraya : un satellite réalisé pour le compte des Émirats Arabes Unis. Puis, jusqu’en août 2001, il a loué ses services à Boeing Satellites Systems où il a par- ticipé à la conception d’un logiciel de gestion d’embauche pour le compte du département des ressources humaines de l’entreprise, et au développement de l’interface de commande et de télémétrie du satellite américain Spaceway. De retour à Tunis, M. Hidoussi s’est occupé d’HEXABYTE, société qu’il a fondée quelques mois plus tôt avec l’ambition de devenir fournisseur de services Internet pour toutes les régions du pays. En peu de temps, la société est devenue un incubateur d’idées en matière de nouvelles technologies et a développé plusieurs produits. L’activité d’HexaByte est essentiellement basée sur la vente des produits et services suivants : – Internet Dial up : connexion via une ligne téléphonique au réseau Internet, – XDSL Entreprises : Lignes spécialisées/ Lignes « Fibre optique » / VSAT/ WIMAX, etc... – ADSL Résidentielle : Pour les particuliers, – Noms de domaines & hébergement de sites web – Solutions de surveillance IP & Réseaux – Packs ordinateurs et connexions RTC (connexions à bas débit) A.U 2015-2016 12
  • 14.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Figure 1.1 – Organigramme d’Hexabyte 1.2.2 Composants du réseau Le parc informatiques que nous allons superviser est composé d’un ensemble de postes de travail, d’imprimantes, de serveurs de marque « DELL RACK power Edge » et de routeurs Cisco. Les serveurs fonctionnent avec des systèmes d’exploitations différents et offrent des services tel que le service web, GPS ou la voie sur IP. Ci_dessous, plus de détails sur les serveurs concernés : Table 1.1 – liste des serveurs et leurs services Système d’exploitation Service offert CentOS release 6.5 VOIP (asterisk) Ubuntu 12.04 LTS VOIP (asterisk) Debian 5.0.3 Web (apache) “ www.hexabyte.tn” Windows server 2003 web (apache) “www.hexavideo.tn” Ubuntu 14.04 LTS GPS 1.3 Cadre général Ce travail s’inscrit dans le cadre du projet de fin d’études à la Faculté des sciences de Bizerte pour l’obtention du diplôme de «licence appliquée en Réseaux Informatique et Télécommunications». Il a été réalisé au local de l’Hexabyte de Elmanzah 1 pendant une durée de 4 mois s’étalant du 01/02/2016 jusqu’au 30/05/2016. A.U 2015-2016 13
  • 15.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.3.1 État de l’art 1.3.1.1 Statistiques D’après une statistique faite par “Hackmageddon” en janvier 2016, les motivations des attaques informatiques sont principalement la Cybercriminalité, le “Hacktivism”, le Cyber Espionnage et le “Cyber Warfare”. – La Cybercriminalité : il s’agit de pirater un système informatique en but de détruire des données et de gagner un accès à des ressources quelconques. Ce genre d’activité est souvent pratiqué par des pirates de type “black hat”. – Le “Hacktivism” : Les activités militantes des altermondialistes ne se développent pas seulement dans la rue, mais aussi sur internet, notamment avec ce qu’on appelle le « hacktivism ». Il est souvent pratiqué par des groupes de “hackers” et en même temps des activistes. – Le Cyber Espionnage : il s’agit de pénétrer des systèmes informatiques afin de gagner un accès à des documents confidentiels. Il peut s’effectuer entre 2 entreprises rivales ou même entre des pays. – Le “Cyber Warfare” : « Une cyberguerre est une guerre dont au moins une des composantes, dans la réalisation, les motivations et les outils (armes au sens large du terme) s’appuie sur le champ informatique ou numérique. Ces composantes sont dénommées des cyber attaques ». Cyberguerre et guerre de l’information (éditions Lavoisier, 2010). Figure 1.2 – les motivations des attaques informatiques En Tunisie, L’ANSI (Agence Nationale de la Sécurité Informatique) a réalisé une étude statistique sur le nombre des tentatives d’attaques informatiques. Et on a enregistrer 20 millions d’évènements qui ont été détectés par les services de l’ANSI à l’aide du système SAHER© en cours de l’année 2015. A.U 2015-2016 14
  • 16.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Figure 1.3 – Évolution du nombre d’événements détectés par l’ANSI en 2015 « Géographiquement, la majorité des adresses IP sources d’évènements est issue de la Tunisie. Celles provenant de l’étranger sont issues essentiellement du continent asiatique contribuant à 37%, suivies par le continent européen 31% puis par le continent africain 21%. » Figure 1.4 – Répartition IP par continent en 2015 1.3.1.2 Principales attaques et menaces D’après les statistiques faites par Hackmageddon en janvier 2016, 34.0% des techniques utilisées par les “hackers” sont inconnues : Figure 1.5 – Les techniques de piratage les plus utilisées A.U 2015-2016 15
  • 17.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Déni de service (DOS) : Le but de cette attaque n’est pas de gagner un accès à des données hébergées sur une machine distante, mais d’encombrer un service ou même la totalité du réseau. Donc les ressources ne seront pas disponibles. La commande la plus utilisée dans cette attaque est : ping . Le firewall est la solution la plus qualifiée pour se protéger d’une telle attaque. Écoute de réseau (Sniffing) : Il s’agit d’une attaque passive, qui permet d’intercepter certaines informations qui circule sur un réseau local, en assemblant les trames dans un format plus lisible. Cette attaque est difficile à détecter. Il existe des logiciels qui permettent cela, nous en citons : “ wireshark”, “tcpdump” et “Ettercap”, Il est recommandé d’utiliser des commutateurs afin de limiter les possibilités d’écoute. “Social Engeneering” : Cette attaque est utilisée par des pirates qui possèdent des compétences bien avancées. A l’aide des moyens de télécommunication usuels le “hacker” cherche à obtenir des données confidentielles auprès du personnel de l’entreprise en visant une tentative d’intrusion. Afin de faciliter la réalisation de cette attaque les pirates utilise le “framework” “Social Engeneering Toolkit” (SET). Se protéger d’une telle attaque ne se limite pas à des solutions “hardware” ou “soft- ware”, il faut offrir une formation au personnel. “Backdoor” : Un “ Backdoor ” est une entrée caché à une machine qui peut être utiliser afin de contourner les politiques de sécurité. C’est une manière d’accéder à une machine supposé être secrète. L’exemple principal, est le “ shell upload ” qui s’agit d’installer un script malveillant souvent écrit en langage PHP(c99,r57), PERL ou Ruby afin de pouvoir exécuter des commandes sur une machine distante et y avoir accès. Injection SQL : C’est l’une des attaques web les plus utilisées. Il s’agit d’une technique qui vise à modifier la requête SQL dans une application web afin d’accéder à des données confidentielles modifier ces données ou créer un utilisateur privilégié. C’est possible d’in- jecter le code SQL dans l’URL ou dans un formulaire. Un exemple d’un outil qui utilise cette technique “SQLmap”, “Havij”, “SQLninja”, etc. Pour proteger une application de ce genre d’attaque il faut bien sécurisé les formulaires en utilisant des fonctions spécifiques tel que “ mysql_real_escape_string () ;”. 1.3.2 Problématique La majorité des ressources informatique est installée dans le réseau que nous allons protéger. Hexabyte utilise l’outil Nagios comme un système de supervision de réseau, sans l’avoir configuré d’une manière avancée et personnalisée. Du coup, la supervision existante est très limitée, peu efficace et n’apporte pas assez d’informations à propos du réseau. En 2013, L’entreprise a installé Suricata comme système de détection d’intrusion réseau. Ce dernier est très bien connu et efficace en tant que IDS réseau mais seul il ne permet pas A.U 2015-2016 16
  • 18.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET d’assurer la détection d’intrusion assez efficace. En décembre 2015, nous avons détecté une faille dans une application web hébergé sur l’un des serveurs de l’entreprise, c’est dans ce contexte que nous avons proposé à Hexabyte d’améliorer la sécurité du réseau. En effet, Si un “black hat” avait détecté cette faille il aurait pu avoir accès à la base de données et réaliser des actions malveillantes. Il est donc obligatoire d’améliorer la sécurité du réseau de l’entreprise. 1.3.3 Travail à faire Pendant le déroulement du projet, nous allons veiller à satisfaire les besoins de l’entre- prise. La solution de surveillance à mettre en place doit assurer les besoins fonctionnels suivants. – Surveiller l’état physique des machines et des équipements réseaux. – Surveiller la charge des machine : nombre d’utilisateurs connectés, de requêtes, l’usage de la CPU, le débit réseau, etc. – Surveiller la disponibilité des applications, des services et des composants systèmes par simple surveillance des fichiers logs. – Surveiller les performances du réseau : débit, latence, taux d’erreur, QoS ... – Surveiller les modifications et l’intégrité des fichiers critiques. La solution qui sera mise en place doit fournir un ensemble de mesures qui vont nous assister à optimiser l’infrastructure réseau et les systèmes utilisés à savoir : – La mesure de performance, en termes de temps de réponse. – La mesure de disponibilité des systèmes pour le calcul d’impact en cas de dysfonc- tionnement. – La mesure d’efficacité qui va permettre de connaitre l’usage de la bande passante et des ressources réseau. – La mesure de la qualité des services fournis. 1.4 Étude Comparative des solutions Open-Source 1.4.1 Outils de supervision Dans cette partie du chapitre, nous allons étudier quatre solutions libres (Open source) de supervision, en présentant chaque solution et en mentionnant leurs avantages et leurs inconvénients.[URL_N1] A.U 2015-2016 17
  • 19.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.4.1.1 Présentation des solutions Nagios – Langage : C/PHP – URL : https ://www.nagios.org/downloads Nagios est un système de supervision réseau, développé par Ethan Galstad dès 1999 et est actuellement en sa version 4.1.1. Ce logiciel fonctionne sous linux et la plupart des système UNIX. Il se décompose en trois parties : – Le moteur de l’application qui s’occupe de l’ordonnancement des tâches de super- vision. – L’interface Web, qui permet la visualisation des informations . – Les plugins, une ensemble des mini programmes qui complètent Nagios Il possède plusieurs fonctionnalités, nous en citons quelques unes : – Envoi des avertissements et des alarmes par courrier électroniques ou par sms. – Récupération des informations du réseau et des équipements. – Surveillance des services réseaux (HTTP/ ICMP/SMTP...). – Surveillance des ressources matérielles ( stations / équipements réseaux . . .). – Génération des rapports de fonctionnement des services, etc. Zabbix – Langage : C/C++/PHP – URL : http ://www.zabbix.com/download.php Zabbix[AND_13] est un logiciel open source de supervision des réseaux développée en C en 2002 . Son interface web est développée en php et en javascript. Il se compose de quatre parties : – Zabbix Server, c’est le composant principal. Il s’occupe de la supervision distance ou local. – Zabbix Frontend, c’est l’interface web de Zabbix. Il permet de visualiser les évène- ments. – Zabbix Proxy, c’est le collecteur des informations – Zabbix Agent, offre un supervision active es ressources locales de la machine ou il est installé. Ces principales fonctionnalités : – Récolte des informations Via SNMP, tests services et agents Zabbix . – Supervision répartie du réseau et surveillance des stations et des serveurs web, mail„, A.U 2015-2016 18
  • 20.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET – Récolte des informations depuis les agents installés sur les machines à superviser. – Visualisation de l’état du réseau et de ces équipements à l’aide d’une interface graphique web. – Création et visualisation de la cartographie du réseau. – Découverte des serveurs et des équipements réseau d’une manière automatique, etc. Centreon – Langage : PHP – URL : https ://download.centreon.com Centreon est une application libre ( open source ), Elle est basé sur Nagios. Depuis 2012 Centreon utilise son propre moteur de collecte et gestionnaire d’événement .Il est plus simple à installer et à configurer que Nagios et il offre une interface graphique avancé et claire. Ces principaux fonctionnalités : – Mêmes fonctionnalités que Nagios . – Configuration en ligne via une API. – Gestion des dépendances entre les services – Visualisation des graphes et des données avancée En dessous, un schéma qui explique la relation entre Nagios et centreon : Figure 1.6 – Architecture de Centreon et sa relation avec Nagios A.U 2015-2016 19
  • 21.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Shinken – Langage : Python – URL : http ://www.shinken-monitoring.org/download.php Shinken[URL_N2] est un système de supervision open source, il s’agit du cœur de Nagios réécrit en python. On lui a apporté une nouvelle architecture plus souple et plus facile a maintenir. Il se compose de plusieurs daemons qui coopèrent entre eux afin de fournir les mêmes fonctionnalités que Nagios . Shinken se constitue de plusieurs daemons qui ont chacun son rôle. Le maitre de ces daemons est l’Arbiter, il lit la configuration, la découpe et l’envoie vers les autres dae- mons. Il est aussi responsable de la disponibilité des autres daemons. Les daemons de type pollers ont le rôle de l’ordonnanceur ils ordonnassent la supervision. Ils existe d’autres daemons comme les Reactionners, Broker et Schedulers . Figure 1.7 – Architecture de Shinken A.U 2015-2016 20
  • 22.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.4.1.2 Récapitulatif des outils de supervision Table 1.2 – Tableau comparatif des outils de supervision Avantages Inconvénients Nagios +Très bien documenté. +Extensible. +Fiable et robuste. +Une large communauté. +Un très grand nombre de plugins à disposition . -Complexité de paramétrage : il faut passer par la configuration textuelle. -Interface web non ergonomique et manque de visualisation graphique. -Évolution lente du logiciel. Zabbix +Une application complète. +Très bien documenté. +L’interface de supervision et de configuration sont plus claires et plus intuitive que celui de Nagios. +L’agent peut lancer des scripts afin de collecter de l’information. +Dessiner les graphe en temps réel (mise à jours toute les 30secondes). +Gestion des droits d’accès des utilisateurs . +Configuration des notifications et des alértes facile à l’aide de shell scripts. -L’agent zabbix envoie par défaut en claire les informations. -Pas facile à utiliser pour un simple utilisateur. -Interface web compliqué et plein de fonctionnalités. - - - - - Centreon +Interface Web très ergonomique. +Une Solution complète de supervision. +Très performant. -Possibilité de rencontrer des problèmes de compatibilité. -Moins rapide que Nagios. Shinken +Compatible avec Nagios. +Interface web ergonomique et moderne. +Très performant . +Développé en python ce qui permet la séparation des taches. +Haute disponibilité des services. +Monitoring via : WMI , NSClient++ pour les machines windows. +Monitoring via SNMP, SSH,local agent,ICMP,.. -Shinken utilise beaucoup de ressources par rapport à Nagios. -Il dispose d’une architecture compliquée. -Une installation et une configuration difficile et avancée par rapport aux autres logiciels. - - A.U 2015-2016 21
  • 23.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.4.1.3 Choix de la solution adoptée Après avoir établi une étude comparative sur les quatre solutions libres de supervision proposées ci-dessus, nous étions hésités entre Zabbix et Shinken.Au final, nous avons décidé de mettre en place la solution Zabbix. C’est la solution la plus convenable parce qu’elle répond fidèlement aux besoins de l’entreprise. 1.4.2 Outils de détection d’intrusion Dans cette partie du chapitre nous allons réaliser une étude de cinq systèmes de détec- tion d’intrusion libres, en présentant chaque solution et en mentionnant leurs avantages et leurs inconvénients. 1.4.2.1 Présentation des solutions SNORT – URL : https ://www.snort.org/downloads Snort est un système de détection et de prévention d’intrusion open source conçu en 1997 par Marty Roesh et racheté par SourceFire. Il a le pouvoir d’interagir avec le pare-feu pour bloquer les intrusions en jouant le rôle d’un IPS (Intrusion Prevention System) en ajoutant des plugins dédiés spécifiques tels que Snort natif et Snort-inline. Il utilise des règles basées sur les signatures, les protocoles et l’inspection d’anomalie. Il offre aussi la possibilité de créer ses propres règles et plugins. C’est le NIDS le plus déployé, il est même devenu un standard des NIDS et des IPS. Il joue cinq principaux rôles : – Packet sniffer : Il effectue l’écoute de réseau dans les différents niveaux. – Packet logger : Il enregistre les logs dans une fichier texte. – Alarm correlator : Il gére les notifications et les alertes. – Detection engine : Il s’occupe de la détection des menaces. – Pre-processor/Packet decoder : Il prépare les informations afin qu’ils soient lisibles. Il posséde un ensemble de caractéristques, nous en citons : – Open source – Petite taille : ~800K – Portable : Fonctionne sur plusieur OS : linux, Windows, MacOS X, etc) – Rapide : Il dispose d’une vitesse de détection trés rapide( ~100MBps) – Configurable : Son configuration est facile et la language de ses règles est simple. A.U 2015-2016 22
  • 24.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET Prelude IDS – URL :https ://www.prelude-siem.org/projects/prelude/files Prélude-IDS est un IDS hybride conçu en 1998. Il joue le rôle d’un : – NIDS :Network IDS – HIDS :Host Based IDS – LML : Log Monitoring Lackey Il permet de stocker les logs dans une base de données (mysql/PostgreSQL). Il est com- patible avec Snort, Nessus et plusieurs analyseurs de logs. Il se compose de plusieurs sous-ensembles : – La librairie libprélude, – La sonde réseau Prelude-nids, – La sonde locale Prelude-lml, – Le contrôleur Prelude-manager, – L’interface web Prelude-php-frontend. prelude dispose de plusieurs fonctionnalités, nous en citons : – Détection d’intrusion réseau, – Détection d’intrusion machine, – Correlation d’événements, – Vérification d’intégrité des fichiers, – Scanner les vulnérabilités, etc. AlienVault OSSIM – URL : https ://www.alienvault.com/products/ossim AlienVault OSSIM[URL_N3] ( Open Source Security Information Management ) est un IDS hybride qui regroupe des outils garantissant la sécurité du réseau, des machines, et des équipements réseaux en détectant les intrusions et les bloquant . Ossim se compose d’un ensemble de logiciel Open-source : Snort : Détection d’intrusion réseau. Suricata : Détection d’intrusion réseau, c’est le NIDS qui est configuré par défaut. Ossec : Détection d’intrusion machine. Prads : Identification des machines et des services. Nagios : Utilisé pour la supervision du réseau. Nessus : Analyseur de vulnerabilités. A.U 2015-2016 23
  • 25.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET BRO IDS – URL : https ://www.bro.org/download/ Bro ids est un système de détection d’intrusion destiné aux réseaux à fort trafic. Cette application a été lancée en 1998. Il a été conçu pour : – Minimiser/éviter toute perte de paquet – Minimiser/éviter tout faux positif – Optimiser la défense de la sonde contre les attaques – Envoyer des alertes en temps réel – Accepter des nouvelles fonctionnalités Bro c’est : – Un capteur de packet – Analyseur de trafic – Système de détection d’intrusion réseau – Enregistreur de logs AlienVault USM – URL : https ://www.alienvault.com/products AlienVault[URL_N3] USM (Unified Security Management) est une solution payante pro- posée par AlienVault. Cette plate-forme enveloppe 5 grandes tâches de sécurité réseaux : – Détecter les intrusions – Analyser les comportements des trafics et des services – Scanner les vulnérabilités et les tester – Déclencher des activités après l’incident (Alerte, gestion de logs, prévention d’un événement.) – Scanner et découvrir les machines qui sont connectées au réseau A.U 2015-2016 24
  • 26.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.4.2.2 Récapitulatif des IDS Table 1.3 – Tableau comparatif des solutions de détection d’intrusion Avantages Inconvénients Snort +Une très grande communauté. +Mise à jour régulière de la base de signatures. +Nombreux plugins documentations riches. +Logiciel libre. -Les sondes nids peuvent être vulnérable. -Nécessite une étude avant le placement des sondes. -Nombreuses fonctionnalités payantes. . . Prelude IDS +Compatible avec plusieurs autres outils. +Il intègre les fonctionnalités NIDS e HIDS. +Scanne de vulnérabilités. +Format normalisé. +Logiciel libre. -La base de données des signatures est moins riche que celle de snort. -Besoin de connaissances en sécurité. . . . . OSSIM +Interface web très claire et ergonomique. +Une très grande entreprise derrière cette solution. +Gestion des événements simple +Logiciel libre. -Documentation faibles -Collection de logs limité -Modèles des rapports limités -Moins de fonctionnalités par rapport à USM , . Bro IDS +Faux positifs réduits +Extensible +Analyses graphiques avancées. +Compatible avec d’autres outil. +Compatible avec les règles de snort grâce à snort2bro. -Documentations faibles -Absence d’une interface graphique -Manque d’informations dans les rapports d’alerte. . USM +Mise à jour hebdomadaire. +Application riche en fonctionnalités. +Support professionnelle -Logiciel payant. . . A.U 2015-2016 25
  • 27.
    CHAPITRE 1. PRÉSENTATIONGÉNÉRALE DU PROJET 1.4.2.3 Choix de la solution adoptée Aprés avoir étudié les différentes solutions de détection d’intrusion, nous avons opté pour Prelude-IDS. Il s’agit d’une solution compléte et facile à personnaliser et qui répond aux besoins de l’organisme d’accueil. 1.5 Conclusion Au cours de ce chapitre, nous avons présenté l’organisme d’accueil qui a adopté ce projet. Puis un rappel du cadre général à été introduit. Pour finir, nous avons effectué une étude comparative des solutions libres de supervision et de détection d’intrusion. Dans le chapitre qui suit nous allons entamer la partie supervision. Dans cette dernière une introduction à la supervision sera incluse suivi par l’installation de Zabbix. A.U 2015-2016 26
  • 28.
    Chapitre 2 Supervision réseau 2.1Introduction Dans ce chapitre, nous rappellerons en premier lieu le principe de la supervision réseau. Par la suite, une description détaillée de l’installation de zabbix sera introduite suivi par des configurations basiques et avancées. 2.2 Introduction à la supervision réseau 2.2.1 Principe Dans un système informatique, la supervision réseau[URL_N4] est devenue une opéra- tion indispensable qui peut économiser beaucoup d’argent en améliorant les performances du réseau, le cout de l’infrastructure et la productivité des employés. Un système de super- vision réseau a comme tâche principale de trouver les problèmes dans un réseau local tel que : station non connectée, serveurs hors service, modification d’un fichier important, etc. La supervision réseau ne peut être réalisée qu’en utilisant une variété de logiciels ou une combinaison de solutions “software” et “hardware”. N’importe quel réseau peut être supervisé, que ça soit filaire, sans fil, VPN ou même WAN. Il est possible de réaliser la supervision des machines sous n’importe quel système d’exploitation (Windows, Linux, Cisco IOS. . .) Les systèmes de supervision réseau différent des systèmes de détection d’intrusion (IDS) ou des systèmes de prévention d’intrusions (IPS). Ces derniers détectent et bloquent les activités des utilisateurs non autorisés dans le réseau. Par ailleurs, il s’agit d’une opération complexe et composée de plusieurs activités complémentaires : – Surveiller (l’état des machines, les statut des services. . .), – Analyser ( des logs), – Visualiser ( des graphes), – Agir ( actions, scripts . . . ), – Alerter (par SMS / mail ), etc. 27
  • 29.
    CHAPITRE 2. SUPERVISIONRÉSEAU 2.2.2 Superviser quoi ? Un système de supervision réseau permet de superviser un ensemble de composants physique et logique d’un système d’information : – Le réseau et ses équipements : Commutateurs, routeurs, serveurs, onduleurs, impri- mantes.. – Systèmes : Utilisations des ressources (CPU, mémoires . . . ). – Applications : Disponibilité des services, performances . . . 2.2.3 Objectifs L’objectif de la supervision se résume principalement en : – Être réactif en envoyant une notification à l’administrateur du réseau en cas de problème technique dans une partie du réseau. – Être proactif en anticipant les pannes et les scénario possibles – Viser les évènements dés leurs apparitions afin d’agir avec pertinence. 2.2.4 Méthodes de supervisions Pour effectuer une supervision sur un système d’information, on utilise plusieurs mé- thodes : – Analyse des fichiers logs : Il s’agit de collecter des informations sur un système, un service ou une application à partir de son fichier log. – Commandes : Il s’agit de récupérer le résultat d’une commande (ping,traceroute..) ou d’un script. Ça peut être des scripts locaux ou distants. – A l’aide d’un agent ( Zabbix-agent, shinken-agent . . .). – Via SNMP . 2.3 Installation et configuration de Zabbix Il est préférable d’utiliser l’outil « Putty » pendant l’installation et la configuration du serveur Zabbix et ses agents[URL_N5]. Cet outil utilise le protocole SSH afin d’exécuter les commandes à distance. On doit alors configurer le service SSH sur le serveur.[URL_N4] 2.3.1 Installation du serveur Zabbix Afin d’installer « zabbix-server » (version 2.2) on doit ajouter les dépôt de Zabbix dans la liste des dépôts de ubuntu. # sudo nano /etc/apt/sources.list Puis copier les lignes ci-dessous dans le fichier , et taper CTRL+x pour enregistrer la modification du fichier . # Zabbix repos deb http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main deb-src http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main A.U 2015-2016 28
  • 30.
    CHAPITRE 2. SUPERVISIONRÉSEAU Pour que l’outil apt-get aie confiance en ces nouveaux dépôts, on exécute cette com- mande. # sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C407E17D5F76A32B Tout d’abord il faut mettre à jours la liste des dépôts en exécutant la commande sui- vante. # sudo apt-get update En suivant les commandes en dessous on installera Zabbix-server , le serveur apache2 et l’interface web de Zabbix . # sudo apt-get install Zabbix-server-mysql php5-mysql Zabbix-frontend-php En cour de l’installation nous allons être demandé de saisir le nouveau mot de passe de l’utilisateur « root » de MySQL. Il faut bien mémoriser ce mot de passe. 2.3.2 Configuration du serveur Zabbix Le serveur Zabbix a été installé avec succès, mais il est loin d’être prés à l’utilisation. Nous allons maintenant commencer la configuration des outils installé. Tout d’abord il faut configurer le fichier de configuration principale de Zabbix. Pour cela il faut ouvrir le fichier avec les privilèges "root" : # sudo nano /etc/zabbix/zabbix_server.conf Il faut chercher les lignes suivants et les modifier comme ci-dessous : – DBName=zabbix // Nom de la base de donnée que Zabbix va utiliser – DBUser=zabbix // Nom de l’utilisateur MySQL . – DBPassword=MOT_DE_PASSE //Mot de passe de l’utilisateur MySQL Il faut sauvegarder et fermer le fichier . 2.3.3 Configuration de la base de données de Zabbix Pour rendre la création des tables dans la base de donnée de Zabbix plus facile, les fichier SQL sont mis en disposition et sont compressés dans ce chemin " /usr/share/zabbix- server-mysql/" . Pour les importer dans la base de données on doit tout d’abord les dé- compresser : # cd /usr/share/zabbix-server-mysql/ # sudo gunzip *.gz Puis nous nous connectons à MySQL en tant que " root ". # mysql -u root -p A.U 2015-2016 29
  • 31.
    CHAPITRE 2. SUPERVISIONRÉSEAU Maintenant nous sommes connectés, il faut ensuite créer un utilisateur de nom de "zab- bix" qui correspond à la configuration que nous avons mis dans le fichier zabbix_server.conf. Pour cela il faut exécuter les requêtes SQL ci_dessous : mysql > CREATE USER ’zabbix’@’localhost’ IDENTIFIED BY ’MOT_DE_PASS’; Ensuite il faut créer la base de donnée "zabbix" , en exécutant cette requête mysql > CREATE DATABASE Zabbix; Puis, nous allons donner à l’utilisateur "zabbix" le contrôle sur la base de donnée "zab- bix". mysql > GRANT ALL PRIVILEGES ON Zabbix.* TO ’zabbix’@’localhost mysql > FLUSH PRIVILEGES; Nous avons finit avec la configuration initial de MySQL, revenons au terminal shell. mysql > EXIT; Maintenant que nous avons crée l’utilisateur et la base de donnée, il faut importer les fichier SQL que Zabbix a besoin pour son fonctionnement. # mysql -u Zabbix -p Zabbix < schema.sql # mysql -u Zabbix -p Zabbix < images.sql # mysql -u Zabbix -p Zabbix < data.sql La base de données de Zabbix est maintenant prête à être utilisé. 2.3.4 Configuration du serveur apache2 Il faut ajuster quelques valeurs pour que php gére parfaitement les données de su- pervision. Nous allons donc accéder au fichier de configuration de php en exécutant la commande suivante. # sudo nano /etc/php5/apache2/php.ini Et changer les valeurs suivantes. post_max_size = 16M max_execution_time = 300 max_input_time = 300 date.timezone = Africa/Tunis Puis enregistrer et fermer le fichier. Ensuite nous allons copier le fichier de la configu- ration php de Zabbix dans le répertoire de configuration de Zabbix. # sudo cp /usr/share/doc/zabbix-frontend-php/examples/zabbix.conf.php. example/etc/zabbix/zabbix.conf.php A.U 2015-2016 30
  • 32.
    CHAPITRE 2. SUPERVISIONRÉSEAU Il faut configurer le fichier Zabbix.conf.php comme suivant. # sudo nano /etc/zabbix/zabbix.conf.php Il faut configurer ce fichier avec les paramètres de connexion mysql qu’on a fait récem- ment. $DB[’DATABASE’] = ’zabbix’; $DB[’USER’] = ’zabbix’; $DB[’PASSWORD’] = ’MOT_DE_PASSE’; Enregistrer et fermer le fichier. Pour rendre apache et Zabbix fonctionnent ensembles, on doit copier l’exemple de configuration d’apache dans " /etc/apache2/conf-available/". # sudo cp /usr/share/doc/zabbix-frontend-php/examples/apache.conf /etc/apache2/conf- available/zabbix.conf Pour activer la nouvelle configuration de Zabbix sous sur apache, on exécute la com- mande suivante. # sudo a2enconf Zabbix.conf # sudo a2enmod alias La configuration d’apache est maintenant terminé. nous redémarrons le service. # sudo service apache2 restart Maintenant nous allons modifier la valeur "START" de "no" à "yes" dans le fichier /etc/default/zabbix-server pour que le service Zabbix se lance en démarrage du système. # sudo nano /etc/default/zabbix-server ... START=yes ... On lance le service " Zabbix-server ". # sudo service Zabbix-server start Si nous voulons que l’interface web de Zabbix s’exécute dans la racine au lieu de "/zab- bix" on doit modifier la valeur "DocumentRoot" à "/usr/share/zabbix". # sudo nano /etc/apache2/sites-available/000-default.conf ... DocumentRoot /usr/share/zabbix ... A.U 2015-2016 31
  • 33.
    CHAPITRE 2. SUPERVISIONRÉSEAU 2.4 Ajout d’une station 2.4.1 Installation d’un agent Zabbix 2.4.1.1 Sous Linux l’installation des agents se fait par l’outil apt-get. # sudo apt-get update # sudo apt-get install Zabbix-agent Maintenant nous allons commencer à configurer l’agent. # nano /etc/zabbix/zabbix_agentd.conf Il faut changer 127.0.0.1 par l’adresse du serveur, et la valeur de "remotecommand" par "1". ... Server = 127.0.0.1 ... remotecommand=1 ... Après, on aura besoin d’exécuter des commandes sur les machines agents, c’est pour- quoi on a activer l’option "remotecommand ". L’agent maintenant est bien installé sur la machine linux. Il faut redémarrer le service. # sudo service Zabbix-agent restart 2.4.1.2 Sous Windows Tout d’abord il faut télécharger l’agent windows de Zabbix qui peut être obtenu à partir du site officiel[URL_N6]. Par la suite on extrait l’archive zip dans un dossier, soit C :Downloadszabbix_agent maintenant on execute la commande ci_dessous dans l’in- vite de commande. C:Userstlich1337>c:Downloadszabbix_agentbinwin32zabbix_agentd.exe –config C:Downloadszabbix_agentsconfzabbix_agentd.win.conf --install Après qu’on a installer le service dans la machine windows, on ouvre le fichier Zab- bix_agentd.win.conf et on modifie les valeures suivantes : – Server= l’adresse ip du serveur Zabbix – ServerActive=l’adresse ip du serveur Zabbix – Hostname=le « FQDN » de la machine windows Nous sauvegardons la modification et on démarre le service. D:Userstlich1337>D:Downloadszabbix_agentsbinwin32zabbix_agentd.exe --start A.U 2015-2016 32
  • 34.
    CHAPITRE 2. SUPERVISIONRÉSEAU Le service est maintenant disponible, il ne reste plus que de donner au service Zabbix- agent le droit de passer le « firewall » si il y en a un. 2.4.2 Ajout du nouveau hôte dans le serveur Il faut maintenant ajouter l’agent dans la liste des hôtes supervisionnés. Dans la barre d’adresse du navigateur on met l’adresse ip du serveur Zabbix suivis par "/zabbix". Puis on se connecte avec le compte par défaut de Zabbix. Username = admin Password = Zabbix On clique sur l’onglet "configuration", "hosts" puis sur "Create host". On remplit le formulaire d’ajout d’hôte comme suit : – Hostname : Nom de la machine – Visible name : Nom Affiché ajouter la machine dans "Linux Servers" – Ajouter l’adresse ip de la machine – Cocher l’option « enabled » pour activer la supervision sur cette nouvelle machine On clique maintenant sur l’onglet "Template"ensuite on suit les étapes ci-dessous : 1. Cliquer sur "Select" pour ajouter une nouvelle "Template" 2. Choisir "Template OS Linux" puis cliquer sur "Select" 3. On peut choisir le template « SNMP Template » si on veut utiliser la supervision avec snmp. 4. Cliquer sur "add" pour ajouter le "Template" dans le nouveau hôte. 5. Cliquer sur "update" 2.5 Amélioration et Optimisation de la supervision 2.5.1 Scripts Un script est un ensemble de lignes de code, il s’agit d’une suite d’instructions simples permettant d’automatiser certaine tâches. Il est souvent écrit en langage non compilé (bash / perl / ruby / python). Pour créer un script qui fonctionne sous Zabbix, on suit les étapes suivantes : 1. Se connecter sur l’interface web de Zabbix. 2. Sélectionner l’onglet « Administration » puis le menu « Scripts ». 3. Cliquer sur « Create script ». 4. Remplire les champs du formulaire comme ci_dessous. – Name : Nom Du Script – Type : Sélectionner « Script » – Execute on : Choisir si le script va être exécuter sur la machine serveur ou l’hôte supervisé. – Commands :Le code du script – Description : Une bref description de la fonctionnalité qui offre le script pour. A.U 2015-2016 33
  • 35.
    CHAPITRE 2. SUPERVISIONRÉSEAU – User groups : Choisir le groupe d’utilisateurs qui peut executer le script. – Host groups : Choisir le groupe d’hôtes où le script s’exécutera – Required host permission : Read ( Si le script va seulement lire des données) /write (Si le script va effectuer des modifications au niveau d’un fichier ) . – Enabled confirmation : à cocher pour pouvoir utiliser le script. Cliquer sur « Save » pour enregistrer le script. À ce niveau, nous avons réaliser un ensemble de scripts qui sont indispensables dans le domaine d’administration réseau. Ci_dessous une liste de quelques scripts que nous avons ajouté. Figure 2.1 – Liste des scripts développés « Check Services Status » : un script qui permet d’afficher les états des services de la machine sélectionné. Figure 2.2 – démo : “Check Services Status” A.U 2015-2016 34
  • 36.
    CHAPITRE 2. SUPERVISIONRÉSEAU « Disk :Bad Blocks » : ce script vérifie l’état des disques dure de la machine sélectionné. En utilisant l’outil Crontab de linux, le script BadBlocks va s’exécuter toutes les 24h et enregistrera le résultat dans un fichier texte. Quand on exécute ce script il affichera la dernière version du fichier texte donc le dernier résultat . Figure 2.3 – Démo : “Disk : Bad Blocks” « TopCpu consumers » : Ce script affiche les processus qui utilisent plus de ressources. Il se base sur la commande ‘top’ . Figure 2.4 – Démo : “TopCpu Consumers” « Last Activities » : Ce script affiche les activités récente du système ( démarrage, redémarrage, connexion des utilisateurs sur les interface TTY . . . ). A.U 2015-2016 35
  • 37.
    CHAPITRE 2. SUPERVISIONRÉSEAU Figure 2.5 – Démo : “Last Activities” « Check SSL Expiration » : C’est une fonctionnalité très importante et peut utilisé dans l’administration système. Ce script permet de surveiller l’expiration du certificat SSL. 2.5.2 Alerte par Courriel électronique Dans cette partie nous allons voir comment configurer Zabbix pour qu’on reçoit des notifications par email. Ainsi, il sera possible de savoir tous les changements des « items » grâces aux « triggers ». Commençons par créer un média de type email. Pour cela, il faut se rendre dans l’in- terface web de Zabbix en accédant au menu « administration » puis « media type ». Ensuite on clique sur « create media type » et on remplit le formulaire ce cette façon : – Description : Une description bref du media ou bien le nom du media. – Type : On selectionne « Email » – SMTP server : L’adresse ip ou le nom de domaine du serveur SMTP – SMTP helo : Nom de domaine du serveurs – SMTP email : L’email qui va émettre les messages Puis on clique sur « Save ». Le media est maintenant prêt. Il est nécessaire de créer une action Afin de déclencher l’envoi d’email à chaque fois qu’un « trigger » se lance. On clique sur l’onglet « Confi- guration » puis « Actions » puis sur « create Action » pour la création d’une action. Maintenant on remplit le formulaire comme suit : – Name : Nom de l’action – Event source : Sélectionner « triggers » – Default subject : {TRIGGER.NAME} : {STATUS} – Default message : {TRIGGER.NAME} : {STATUS} – Status : Sélectionner « Enabled » – Aller à la fenétre « Action operations » puis cliquer sur « new » – Operation type : Selectionner « Send message » A.U 2015-2016 36
  • 38.
    CHAPITRE 2. SUPERVISIONRÉSEAU – Send message to : Choisir l’utilisateur qui va recevoir l’email – User medias : Sélectionner le media qu’on vient de créer – Cocher l’option Default message On clique sur « add » puis « save ». L’alerte par email est maintenant mise en place et active. Un exemple d’email reçue dans la figure suivante : Figure 2.6 – Exemple d’un message reçu 2.5.3 Supervision des serveur VOIP La supervision d’un serveur VOIP nécessite plus de configuration que celle d’un ser- veur, on a pas seulement besoin de savoir les information générales du systèmes et de ses applications. On aura besoin de savoir plus d’informations que prévue, exemple. Appels actifs. # sudo /usr/sbin/asterisk -rvvvvvx ’show channels’|grep --text -i ’active call’|awk ’{print $1}’ Messages fax reçu/envoyé avec succée. # sudo -u Zabbix sudo /usr/sbin/asterisk -rvvvvvx ’fax show stats’ | grep ’Completed’ | awk ’{print $NF}’ Nous avons utilisé un ensemble de commandes de ce genre dans des scripts pour ef- fectuer la supervision sur les serveurs VOIP de l’entreprise. Nous avons réussi à réaliser les fonctionnalités cité ci-dessous : – Nombre d’appels actif, – Nombre de sessions courante des fax, – Nombre et pourcentage des erreurs de transmission des appels, – Nombre et pourcentage des erreurs de transmission des messages par fax, – Nombre de fax et de téléphones disponibles, etc. A.U 2015-2016 37
  • 39.
    CHAPITRE 2. SUPERVISIONRÉSEAU 2.5.4 Screen Un « screen » est une vue composée de plusieurs graphes, champs de textes et d’autres forme de données qui facilite la supervision d’un système informatique. Ci_dessous un exemple sur un des screen que nous avons crée. Figure 2.7 – Exemple d’un tableau de bord (screen) Pour créer un « screen » personnalisé, il faut passer par les étapes suivantes : – Se connecter sur l’interface web de Zabbix – Sélectionner l’onglet « Configuration » puis « Screens ». – Cliquer sur « Create screen ». – Donner un nom à la nouvelle vue, préciser le nombre des colonnes et des lignes. – Puis remplir les champs par les graphes et les données qu’on veut ajouter. Notre nouvelle vue est maintenant prête à être utilisé. Pour l’exploiter il faut aller à l’onglet « Monitoring » puis « Screens » et choisir la vue qu’on veut à partir de la liste affiché. 2.5.5 Maps Une « Map » est une carte composée de plusieurs machines interconnectées. Ça per- met de visualiser l’état de la connexion entre les machines qu’y existent et d’exécuter des scripts sur une machine quelconque. Ci_dessous un exemple de carte que nous avons crée. A.U 2015-2016 38
  • 40.
    CHAPITRE 2. SUPERVISIONRÉSEAU Figure 2.8 – exemple d’une “map” Pour créer une « map » personnalisé il faut suivre les étapes suivantes : – Se connecter sur l’interface web de Zabbix. – Sélectionner l’onglet « configuration » puis « Maps ». – Cliquer sur « create map ». – Remplir les champs suivants comme nous le souhaitons. Figure 2.9 – Formulaire de création d’une “map” – Ajouter un icône. – Cliquer sur l’icône. – Définir le type de l’objet que l’icône représentera(Host,Map,image. . .) dans notre cas , une machine. – On remplit le champ « label » par une bref description de la machine, pour ceci nous allons utiliser des macros qui vont chercher les informations d’une façon dynamique. Par exemple. A.U 2015-2016 39
  • 41.
    CHAPITRE 2. SUPERVISIONRÉSEAU {HOST.NAME} {HOST.CONN} (CPU: {{HOST.HOST}:system.cpu.load[percpu,avg1].last(0)} ) {HOST.NAME} : Retourne le nom de la machine. {HOST.CONN} : Retourne l’adresse ip de la machine. {{HOST.HOST} :system.cpu.load[percpu,avg1].last(0)} : Retourne l’usage du pro- cesseur de la machine (une pourcentage). – Sélectionner l’emplacement de la libelle ,par défaut c’est « bottom » . – Sélectionner l’hôte que l’icône va présenter dans le champs « Host ». – Choisir l’icône et sa dimension . – Cliquer sur « apply » pour effectuer le changement. Afin d’améliorer améliorer la « map ». Nous allons ajouter une liaison entre deux ma- chines. Cette liaison présentera la connexion physique ou logique entre les 2 terminaux. Nous suivrons donc les étapes ci_dessous : – Sélectionner les deux machines que nous allons les relier. – Cliquer sur le bouton d’ajout d’un lien. – Cliquer sur l’icône d’un des terminaux. – Aller à la fenêtre « Links for the selected element » et cliquer sur « edit » afin de configurer la liaison. – Pour afficher le débit montant et descendant de la station nous utilisons des macros spécifique dans le champ « label ». In : {zabbixServer:net.if.in[eth0].last(0)} Out : {zabbixServer:net.if.out[eth0].last(0)} – Choisir le type du lien ( ligne continue, ligne continue gras. . .) – Choisir le couleur du lien (vert par défaut) – Pour que la ligne devienne rouge si la machine n’est pas connectée, nous allons activer un « trigger » qui va surveiller la connectivité entre les 2 machines. Dans notre cas ce trigger est intitulé « zabbixServer : Zabbix agent on ZabbixServer is unreachable for 5 minutes » puis nous sélectionnons la couleur rouge si le trigger s’active. – Cliquer sur « apply » Notre « Map » est maintenant bien configurée. Il ne reste qu’à sauvegarder le changement. Pour exploiter la « map » nous sélectionnons l’onglet « monitoring » puis « maps » . 2.5.6 Activation de SSL dans apache2 L’interface web de Zabbix fonctionne avec le protocole http. Ce protocole n’est pas sécurisé car il transfère le trafic sans le crypter. Parfois le serveur envoie au client web des données confidentielles, et il se peut qu’un intrus intercepte les messages et les exploite pour effectuer des actions non désirées. C’est pourquoi nous avons activé le module SSL dans apache2 pour sécuriser le trafic.[URL_N7] A.U 2015-2016 40
  • 42.
    CHAPITRE 2. SUPERVISIONRÉSEAU D’abord il faut activer le module SSL puis redémarrer le service apache2. # sudo a2enmod ssl # sudo service apache2 restart Pour la configuration nous aurons besoin d’une certificat ssl. Nous utiliserons donc l’outil « OpenSSL ». # sudo mkdir /etc/apache2/ssl # cd /etc/apache2/ssl # sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt Après avoir entrer la commande ci_dessus, on nous demande de saisir quelques infor- mations. Country Name (2 letter code) [AU]:TN State or Province Name (full name) [Some-State]:Tunis Locality Name (eg, city) []:Menzah Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hexabyte Organizational Unit Name (eg, section) []:IT Department Common Name (e.g. server FQDN or YOUR name) []: Zabbix.hexabyte.tn Email Address []: Zabbix@hexabyte.tn Deux fichier ont été créer dans le dossier « /etc/apache2/ssl » : apache.crt et apache.key. Maintenant que nous avons la certificat et la clé nous allons configurer apache2 pour qu’il utilise ces deux fichiers.La configuration se fait dans sur le fichier « default-ssl.conf ». # sudo nano /etc/apache2/sites-available/default-ssl.conf Sans les commentaires le fichier sera comme suit. A.U 2015-2016 41
  • 43.
    CHAPITRE 2. SUPERVISIONRÉSEAU <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@hexabyte,tn DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key <FilesMatch ".(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> </IfModule> Maintenant il ne reste qu’a activer le « SSL-enabled virtual host » et redémarrer le service apache. # sudo a2ensite default-ssl.conf # sudo service apache2 restart Maintenant que tout est mise en place nous pouvons accéder à l’interface de Zabbix via HTTPS. Il est nécessaire d’accepter le certificat pour que l’échange des données sera effectué. 2.5.7 Mise à jour de Zabbix L’un des plus grands défauts de Zabbix est que ses composants envoient les données non cryptées d’où le manque de sécurité. Un pirate peut facilement écouter le trafic et en savoir d’avantage sur le réseau. Dans la version 3.0 de Zabbix sortie le 16 février 2016, dont le développement a pris deux ans, on a inclus le chiffrement du trafic. Cette version apporte encore plus de fonctionnalités et d’améliorations graphiques. Il s’agit d’une ver- sion riche et complète. Le chiffrement du trafique échangé entre l’ensemble des composants est basé sur le protocole TLS . Il y a d’autres nouveautés offerte dans cette version, nous en citons : – les fonctions « prévision » et « temps restant » qui utilise des algorithmes de prédic- tion qui permettent de savoir dans combien de temps nous allons passer en dessous du seuil critique ou de savoir où on en sera de notre espace disque dans 1 heure, – L’utilisation du processeur par processus ou par utilisateurs, – Amélioration de la visualisation des graphes en offrant la possibilité de zoomer sur A.U 2015-2016 42
  • 44.
    CHAPITRE 2. SUPERVISIONRÉSEAU les graphiques, – L’ajout d’une fonctionnalité similaire à « Crontab » de linux, qui permet de lancer un script ou un évènement à une heure précise. etc Cette mise à jour est disponible à partir de Zabbix 2.2 ou à partir d’une version ultérieur. Il faut aussi vérifier si la version de php est 5.4.x . Avant de démarrer la mise à jour[URL_N8] il est préférable de créer un « backup » des fichiers de configuration et de la base de donnée. # cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup # cp /etc/httpd/conf.d/zabbix.conf /opt/zabbix-backup # cp /usr/share/doc/zabbix-* /opt/zabbix-backup # sudo mysqldump -uroot -p Zabbix > Zabbixdb.sql Afin d’effectuer la mise a jour nous allons suivre les étapes qui suivent. 2.5.7.1 installation des packages de la release 3 de Zabbix . # wget http://repo.zabbix.com/zabbix/3.0/ubuntu/pool/main/z/zabbix-release/ zabbix-release_3.0-1+trusty_all.deb # dpkg -i Zabbix-release_3.0-1+trusty_all.deb # sudo apt-get update 2.5.7.2 Installation de Zabbix 3 Installation du serveur Zabbix # sudo service Zabbix-server stop # sudo apt-get install –only-upgrade Zabbix-server-mysql Installation de la dernière version de l’interface web Zabbix # sudo apt-get install –only-upgrade Zabbix-frontend-php Notre serveur Zabbix est maintenant à son version 3 et prés à être utilisé. Il ne reste que de lancer le service et d’accéder à l’interface via un navigateur. # sudo service Zabbix-server start 2.5.8 Centralisation des logs Un log ou journal est une simple notification d’une importance plus ou moins élevée envoyée par l’OS, un équipement du réseau ou un service. Ces données permettent à l’ad- ministrateur du système de suivre les éventements et retracer les actions. Collecter les logs c’est très important, mais pouvoir les centraliser, les traiter et les analyser c’est encore plus ! C’est pour cette raison que nous avons décidé de mettre un A.U 2015-2016 43
  • 45.
    CHAPITRE 2. SUPERVISIONRÉSEAU place un centralisateur de logs qui va s’occuper du traitement des logs de tous le réseau. Nous avons donc choisis d’installer “GrayLog” [URL_N9]. Graylog est un logiciel de centralisation et d’analyse de logs très puissant. Il possède une interface web très ergonomique. Cet outil nécessite la mise en place des logiciels sui- vants. – Nxlog : Collecteur de logs. – Elasticsearch : Un serveur de recherche et d’indexation. – MangoDB : Base de données pour y stocker les informations. Qu’est ce que nous allons gagner de la centralisation des logs ? – Recherche et statistique : Centraliser les logs dans une seul machine va nous per- mettre d’effectuer des recherches trais précises sur l’activité des systèmes et des utilisateurs tout en étant connecté à partir d’une seule machine. – Détection d’intrusion : Les plus part des IDS se servent des fichiers de logs afin de détecter des comportements suspicieux sur une réseau. Dans ce cas l’IDS aura une source d’information de plus. – Garantir la disponibilité des logs : Si par malheur un pirate a attaqué notre réseau et pour éliminer ses traces, il a supprimé les fichiers logs. Dans ce cas, la centralisation est la solution idéal pour garantir la survie des logs en envoyant des copies au serveur. Comment la centralisation fonctionne ? 1. Tout d’abord il faut créer les logs, ils sont souvent générés par les services et les applications. 2. Ensuite, transférer les log dans le serveur de centralisation via des agents. 3. Puis, organiser les logs dans des répertoire ( Exemple : répertoire par machine) et les filtrer par des critères choisis. 4. Enfin, exploiter les logs : utilisation des Graphes, création des rapports et envoie des alertes. Ci-dessous, l’interface web du centralisateur des logs “GrayLog”. A.U 2015-2016 44
  • 46.
    CHAPITRE 2. SUPERVISIONRÉSEAU Figure 2.10 – GrayLog 2 GUI 2.6 Conclusion Au cours de ce chapitre, nous avons vu une introduction au domaine de supervision ré- seau, suivis par les étapes de l’installation, configuration et optimisation de la supervision. L’IDS sera le sujet du prochain chapitre. Ce dernier, couvrira le principe et les diffé- rentes caractéristiques des IDS suivi par l’installation et la configuration de la plateforme de détection d’intrusion. A.U 2015-2016 45
  • 47.
    Chapitre 3 Détection d’intrusion 3.1Introduction Les systèmes de détection d’intrusion, ou souvent appelés IDSs, sont devenus des composants essentiels dans les offices de sécurité et de l‘administration réseau. Cependant beaucoup d’experts en sécurité réseaux ignorent les avantages qu’offrent ces systèmes. Dans ce chapitre nous allons rappeler l’importance des IDSs dans un système d’infor- mation d’une entreprise et leurs différents types. Une description détaillée des étapes de l’installation sera par la suite introduite suivi par des configurations et des optimisations. 3.2 Systèmes de détection d’intrusion 3.2.1 Mode de fonctionnement Comme son nom l’indique un système de détection d’intrusion est fait pour détecter les intrusions, c’est à dire qu’il a pour but de détecter les attaques ciblant les équipements du réseau et alerter les personnes concernées. Un IDS installé dans un réseau peut être comparé à un système d’alarme installé dans une maison. À travers les différentes mé- thodes, ces deux systèmes détectent les intrusions et envoient une sorte de signal d’alarme spécifique. Un IDS peut être configuré afin de pouvoir travailler en coopération avec un firewall qui vise à contrôler le trafic. Il ne faut pas confondre ces deux outils de sécurité. Un firewall essaye de stopper les attaques et les accès interdits, il est souvent placé dans la première ligne de défense. Alors que l’IDS détecte si oui ou non le réseau est attaqué. C’est sûr que la mise en place d’un IDS va améliorer la sécurité d’un réseau mais il n’offre pas une garantie totale de la sécurité. En générale, l’IDS utilise deux techniques de détection[THI_04] : détection d’anoma- lies et détection par signatures. Détection d’anomalie C’est une technique utilisée afin de surveiller le comportement du réseau et de ses équipements. A chaque fois qu’il détecte un comportement anormal d’une machine, il le classe en tant que tentative d’intrusion : par exemple, si l’IDS détecte qu’un certain utilisateur s’est connecté sur une machine 15 fois alors que d’habitude il 46
  • 48.
    CHAPITRE 3. DÉTECTIOND’INTRUSION ne se connecte qu’une ou deux fois quotidiennement ou si un ordinateur a été utilisé à 3 :00am alors que personne n’est censé être sur son poste. Tout comportement suspicieux similaire aux exemples cités précédemment sera alerté. Détection par signatures Cette méthode utilise les signatures des comportements suspects les plus répandus dans le domaine des intrusions afin de prédire et détecter les tentatives d’attaques. Prenons l’exemple d’un échec de trois tentatives d’authentification d’un utilisateur sur une machine, il s’agit d’un cas suspect et doit être alerté afin de vérifier si c’est bien une tentative d’intrusion ou un simple accident. Dans le cas des attaques réseaux l’IDS vérifie l’intégrité des paquets et calculera leurs « checksums » pour les comparer aux signatures suspectes, si ils sont compatibles l’IDS va alerter l’administrateur de cet incident. 3.2.2 Types des IDS 3.2.2.1 Les HIDS (Host-based IDS) Les HIDS[THI_04] sont les tous premier IDS à avoir été développés et implémentés. Ce système collecte et analyse les données d’un hôte qui offre un service tel que service web ou base de données. Une fois que les données sont collectées, elles seront analysées par un agent localement ou elles seront envoyées vers une autre machine dédiée à cette tâche. Le HIDS peut être sous la forme d’un programme qui est installé sur un système d’exploitation afin d’analyser les fichiers logs ou les fichiers des résultats d’audit. Ce pro- gramme est très efficace contre les différentes attaques connues sur les machines, il est capable de détecter les « backdoors » et les « rootkits ». Aussi, il est capable de détecter les modifications interdites des fichiers importants. Cependant, il ne s’agit pas d’un système idéal. Le HIDS a un grand inconvénient, il peut être détecté facilement par le « hacker » et il peut lui bloquer la collection des données, il deviendra alors inutile. Exemple : OSSEC-HIDS : Il s’agit un HIDS open-source, il est capable d’analyser les logs, vérifier l’intégrité des fichiers, détecter les « rootkits » et envoyer des alertes en temps réels. C’est le HIDS open-source le plus utilisé. 3.2.2.2 Les NIDS (Network-based IDS) C’est un type d’IDS qui est capable d’écouter sur le réseau, sniffer le trafic et analyser les paquets. Ces paquets seront examinés par le NIDS[THI_04] et comparés avec des don- née suspectes pour vérifier s’ils sont malicieux ou bien non. Les NIDS sont responsables de la sécurité de tout un réseau et non pas d’une seule machine comme le cas d’un HIDS. Ils sont plus distribués. Au lieu de collecter les données depuis les machines, les NIDS les collectent depuis les paquets sniffés sur le réseau. Cette surveillance des connexions entre les terminaux rend le NIDS efficace en détection des tentatives des intrusions et des accès interdits. Il est A.U 2015-2016 47
  • 49.
    CHAPITRE 3. DÉTECTIOND’INTRUSION capable de détecter les accès non autorisés dans le réseau. Comme tout système, le NIDS a ses propres défauts : il ne peut pas sniffer tous les paquets si le débit du réseau est trop élevé. Aussi, il ne peut pas détecter les intrusions si les paquets contenant les « payloads » sont très bien chiffrés. Exemples : Snort : C’est un NIDS Open-Source, il a été développé par « sourcefire ». C’est le père des NIDS. Il peut aussi jouer le rôle d’un IPS (Intrusion Prevention system). Il est le plus utilisé. Suricata : C’est un NIDS de nouvelle génération, il est moins connu que Snort mais c’est un jeune rival Il a été développé par « Open Information Security Foundation » (OISF) . 3.3 Installation et mise en place de Prelude-IDS 3.3.1 Installation de Prelude Pour commencer l’installation de prélude manager[URL_N10] nous devons tout d’abord installer les librairies pré-requises pour le bon fonctionnement de Prelude. 3.3.1.1 Libprelude Avant tout nous installons les pré-requises de Libprelude :libgnutls-dev, python2.7- dev, libpcre3-dev, swig, pkg-config. Ces paquets sont installés par défaut dans le dépôt de Ubuntu. # sudo apt-get install libgnutls-dev python2.7-dev libpcre3-dev swig pkg-config Ensuite nous téléchargeons l’archive libprelude à l’aide de l’outil WGET et nous le compilerons. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/351/ libprelude-1.2.5.tar.gz # tar -xzf libprelude-1.2.5.tar.gz # cd libprelude-1.2.5 Avant de compiler Libprelude nous devons le configurer. # ./configure --without-lua –with-python=/usr/bin/python2.7 Il faut vérifier que le support de python est activé. A.U 2015-2016 48
  • 50.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Figure 3.1 – Configuration de libprelude Pour lancer l’installation nous exécutons la commande suivante. # make & make install 3.3.1.2 LibpreludeDb Tout d’abord nous installerons le paquet de support MySQL. # sudo apt-get install libmysqlclient-dev Nous installons libprelude en suivant les étapes ci_dessous . # cd /tmp # wget https://www.prelude-siem.org/attachments/download/352/ libpreludedb-1.2.5.tar.gz # tar -xzf libpreludedb-1.2.5.tar.gz # cd libpreludedb-1.2.5 Afin que le « linker » trouve Prelude, nous configurons la variable d’environnement concerné comme suit. # sudo export LD_LIBRARY_PATH=/usr/local/lib Nous lancerons ensuite la configuration. # ./configure Il faut vérifier que le plugin MySQL est activé : Figure 3.2 – Configuration de libpreludeDb A.U 2015-2016 49
  • 51.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Ensuite nous lançons l’installation. # sudo make & make install 3.3.1.3 Base de données Prelude-admin Prelude a besoin d’une base de données pour y stocker les données des alertes et des évènements. Nous allons donc créer une base de données avec MySQL. # mysql -u root -p« password » mysql> CREATE DATABASE Prelude; mysql> CREATE USER ’prelude’@’localhost’ IDENTIFIED BY ’OPPASSWORD’; mysql> GRANT USAGE ON *.* TO ’prelude’@’localhost’; mysql> GRANT ALL PRIVILEGES ON Prelude.* TO ’prelude’@’localhost’; mysql> exit; # mysql -u Prelude -pOPPASSWORD Prelude < /usr/local/share/ libpreludedb/classic/mysql.sql 3.3.1.4 Prelude-Manager Afin d’activer le module IDMEF(Intrusion Detection Message Exchange Format) nous devons installer les paquets d’XML et de support de la technique d’emballage TCP. # sudo apt-get install libxml2-dev libwrap0-dev Maintenant nous pouvons commencer l’installation de Prelude. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/356/ prelude-manager-1.2.5.tar.gz # tar -xzf Prelude-manager-1.2.5.tar.gz # cd Prelude-manager-1.2.5 # ./configure Il faut s’assurer que le support libCU est activé. Figure 3.3 – Configuration de Prelude-manager # sudo make & make install Prelude manager est maintenant installé, nous passons à sa configuration. A.U 2015-2016 50
  • 52.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # sudo nano /usr/local/etc/prelude-manager/prelude-manager.conf Figure 3.4 – Fichier de configuration de Prelude-manager Il faut saisir les données de connexion dans la base de données : type (MySQL, Post- greSQL, Oracle), host (l’adresse IP/ nom de domaine du serveur de base de données), port (3306 par défaut pour MySQL), Name(nom de la base de données), user( nom de l’utilisateur de la base de données) et le passe(mot de passe de l’utilisateur). 3.3.1.5 Prelude-Correlator l’installation de Prelude-correlator se fait par l’outil apt-get. # sudo apt-get install Prelude-correlator Nous allons configurer la corrélation avec le démarrage du système. # sudo nano /etc/default/prelude-correlator Il faut changer la valeur de la variable « RUN » de «no» en «yes». 3.3.1.6 Prelude-LML il faut d’abord installer libicu-dev, c’est une librairie pré-requise. # sudo apt-get install libicu-dev Puis suivre les étapes suivantes. A.U 2015-2016 51
  • 53.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # cd /tmp # wget https://www.prelude-siem.org/attachments/download/354/ prelude-lml-1.2.5.tar.gz # tar -xzf Prelude-lml-1.2.5.tar.gz # cd Prelude-lml-1.2.5 #./configure Il faut s’assurer que le support liblCU est bien activé : Figure 3.5 – Configuration de Prelude-lml # sudo make & make install Prelude-lml est maintenant installé avec succès, nous passons à l’ajout de règles pour cette sonde. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/355/ prelude-lml-rules-1.2.5.tar.gz # tar -xzf Prelude-lml-rules-1.2.5.tar.gz # cd Prelude-lml-rules-1.2.5 # cp -r ruleset /usr/local/etc/prelude-lml/ Il ne reste qu’à configurer Prelude-lml via son fichier de configuration. # sudo nano /usr/local/etc/prelude-lml/prelude-lml.conf A.U 2015-2016 52
  • 54.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Figure 3.6 – Fichier de configuration de Prelude-lml Dans ce fichier, nous indiquons l’adresse IP du serveur et les fichiers log que Prelude- lml va analyser et superviser. 3.3.1.7 Prewikka Prewikka est l’interface web de Prelude, il permet de visualiser les évènements et les alertes. Nous allons maintenant installer et configurer cette interface. Pour garantir le bon fonctionnement de prewikka nous devons d’abord installer des logiciels prérequis. # sudo apt-get install python-cheetah python-setuptools python-cairo python-netaddr gettext Nous allons commencer l’installation de prewikka, en suivant les étapes ci-dessous. # cd /tmp # wget https://www.prelude-siem.org/attachments/download/357/ prewikka-1.2.5.tar.gz # tar -xzf prewikka-1.2.5.tar.gz # cd prewikka-1.2.5 Puis nous l’installons avec python 2.7 . # sudo python2.7 setup.py install --record prewikka_files.txt --prefix /usr/local Maintenant nous allons configurer la base de données de prewikka. A.U 2015-2016 53
  • 55.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # mysql -u root -p mysql> CREATE database prewikka; mysql> CREATE USER ’prewikka’@’localhost’ IDENTIFIED BY ’prewikkaPassword’; mysql> GRANT USAGE ON *.* TO ’prewikka’@’localhost’; mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prewikka’@’localhost’; mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prelude’@’localhost’; mysql> exit; # mysql -u prewikka -pprewikkaPassword prewikka < /usr/local/share/prewikka/database/ mysql.sql Nous allons modifier le fichier de configuration de prewikka avec les coordonnées de la base de données récemment crées. # sudo nano /usr/local/etc/prewikka/prewikka.con Figure 3.7 – Fichier de configuration de prewikka 3.3.2 Installation des agents de surveillance 3.3.2.1 Profil Prelude-Manager Pour créer un profil Prelude-Manager[URL_N10] , nous allons utiliser la commande « prelude-admin ». L’« uid » et le « gid » doivent passer en arguments pour pouvoir crée le profil. # sudo Prelude-admin add Prelude-manager --uid 0 --gid 0 A.U 2015-2016 54
  • 56.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Figure 3.8 – Ajout d’un profil Prelude-manager Sondes Prelude-LML Pour que Prelude enregistre une sonde, il faut exécuter deux commandes en parallèle comme ci_dessous. TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register Prelude-lml "idmef:rw admin:r" 127.0.0.1 --uid 0 --gid 0 Figure 3.9 – Enregistrement de Prelude-lml 3.3.2.2 Sonde Prelude-Correlator L’utilisateur Prelude-Correlator a déjà été créé pendant l’installation. Nous aurons besoin de savoir l’« uid » et le « gid » de l’utilisateur, pour cela on exécute la commande ci-dessous. A.U 2015-2016 55
  • 57.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # id Prelude-correlator Figure 3.10 – l’uid et le gid de Prelude-correlator Dans notre cas : uid=116 & gid=126. C’est avec ces variables que nous allons pouvoir installer correctement la sonde Prelude-correlator en suivant les étapes suivantes. TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register Prelude-correlator "idmef:rw admin:r" 127.0.0.1 --uid 116 --gid 126 La sonde Prelude-correlator est maintenant installée. 3.4 Optimisation de la détection d’intrusion 3.4.1 Utilisation de Prewikka en tant que service Pour simplifier l’utilisation de prewikka et rendre son démarrage et son arrêt plus fa- ciles, nous avons utilisé un script « bash » que nous avons trouvé après quelques recherches sur internet. Ce dernier va transformer prewikka en un service qu’on peut démarrer et arrêter avec des simples commandes. # sudo service prewikka start|stop ( restart|status ) Il faut tout d’abord copier le code source du script dans un fichier que nous allons nommer « prewikka » et l’enregistrer dans le répertoire /etc/init.d/ pour, enfin, lui attri- buer le droit de l’exécution. # sudo chmod +x /etc/init.d/prewikka A.U 2015-2016 56
  • 58.
    CHAPITRE 3. DÉTECTIOND’INTRUSION #!/bin/bash ### BEGIN INIT INFO # Provides: prewikka # Required-Start: $local_fs $remote_fs $network $syslog $named # Required-Stop: $local_fs $remote_fs $network $syslog $named # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Prewikka est l’interface officielle de Prelude-IDS ### END INIT INFO # Variables couleurs CSI="033[" CEND="${CSI}0m" -CGREEN="${CSI}1;32m" # PID du processus PID=$(netstat -tlnp | awk ’/:8000 */ {split($NF,a,"/"); print a[1]}’) # Variable d’environnement PYTHONPATH export PYTHONPATH=/usr/local/lib/python2.7/dist-packages: /usr/local/bin/prewikkahttpd start() { echo -n "Démarrage de Prewikka by Hexabyte..." /usr/local/bin/prewikka-httpd & echo -e " ${CGREEN}[OK]${CEND}" } stop() { echo -n "Arrêt de Prewikka by Hexabyte..." kill -9 $PID echo -e " ${CGREEN}[OK]${CEND}" } status() { if [[ $PID -gt 0 ]]; then echo -e "Prewikka est actuellement en service ${CGREEN}[OK]${CEND}" else echo "Prewikka n’est pas en service..." fi } case "$1" in start ) start;; stop) stop ;; restart ) stop start ;; status ) status ;; *) echo "Utilisation: $0 {start|stop|restart|status}" exit 1 ;; esac exit 0 A.U 2015-2016 57
  • 59.
    CHAPITRE 3. DÉTECTIOND’INTRUSION 3.4.2 Utilisation de Prelude-manager en tant que service Dans cette partie nous allons installer un script afin de simplifier le démarrage et l’ar- rêt de Prelude-manager, tout comme nous avons fait pour prewikka. Commençons par télécharger le scripte dans le répertoire /etc/init.d/. # wget https://gist.githubusercontent.com/hardware/92ffda173ed4db68be6f/ raw/89e146a5869b09f53863a13f90f146b5d76a408f/prelude-manager # sudo chmod +x Prelude-manager Pour lancer le service Prelude-manager nous lançons la commande suivante. # sudo service Prelude-manager start 3.4.3 Utilisation de Prelude-lml en tant que service Dans cette partie nous allons installer un script afin de simplifier le démarrage et l’arrêt de Prelude-lml, tout comme nous l’avons fait pour prewikka et Prelude-manager. Commençons par télécharger le scripte dans le répertoire /etc/init.d/. # wget https://gist.githubusercontent.com/hardware/e21731a31e03721a4633/ raw/72eb18e8da30c8972def826e35f520f5d8926f46/prelude-lml # sudo chmod +x Prelude-lml Pour lancer le service Prelude-lml nous lançons la commande suivante. # sudo service Prelude-lml start 3.4.4 Démarrage de Prelude lors du « boot » Pour que les services de Prelude se lancent en démarrage du système, nous allons exé- cuter quelque instruction simple. # sudo update-rc.d Prelude-manager defaults # sudo update-rc.d Prelude-lml defaults # sudo update-rc.d prewikka defaults 3.4.5 Ajout d’une sonde HIDS : OSSEC Nous avons installé Prelude et ses sondes officielles. Mais nous pouvons encore amélio- rer ses performances en ajoutant une sonde HIDS. Nous allons donc utiliser OSSEC[URL_N11]. L’installation d’OSSEC est très simple à effectuer. Suivons ces étapes. # cd /tmp # wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz # tar zxvf ossec-hids-2.6.tar.gz # cd ossec-hids-2.6/src # make setprelude # ./install.sh A.U 2015-2016 58
  • 60.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Après la dernière commande nous serons amenés à saisir quelques informations comme le montre la figure ci_dessous : Figure 3.11 – Installation d’OSSEC Les paramètres de l’installation : – La langue de l’installation : en – Le type d’installation : server – Choix du répertoire d’installation : /etc/ossec. – Envoi de mail : « no » .C’est possible de la modifier après dans le fichier de confi- guration (/etc/ossec/etc/ossec.conf). – Pour le reste on laisse par défaut. L’installation est terminée, nous passons à la configuration de la sonde via son fichier de configuration. # sudo nano /etc/ossec/etc/ossec.conf Figure 3.12 – Fichier de configuration d’OSSEC Il ne reste qu’à enregistrer Ossec en tant que sonde HIDS pour Prelude, pour cela il faut chercher l’« uid » et le « gid » de l’utilisateur « OSSEC » : A.U 2015-2016 59
  • 61.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Figure 3.13 – ID de l’utilisateur “OSSEC” Comme tout enregistrement de sonde sous Prelude, nous aurons besoin d’utiliser deux terminaux : TERMINAL_1 # sudo Prelude-admin registration-server Prelude-manager TERMINAL_2 # sudo Prelude-admin register OSSEC "idmef:rw" 127.0.0.1 - -uid 1001 - -gid 1001 Nous avons terminé l’installation la sonde Ossec. 3.4.6 Ajout d’une Sonde NIDS : Suricata Bien que notre plate-forme possède des sondes officielles de Prelude et une sonde HIDS Ossec, il lui manque encore une sonde NIDS pour la surveillance au niveau du réseau. Pour cela nous avons choisi d’utiliser Suricata[URL_N12]. En premier lieu, nous allons installer les pré-requis. #sudo apt-get -y install libpcre3 libpcre3-dbg libpcre3-dev build-essential autoconf automake libtool libpcap-dev libnet1-dev libyaml-0-2 libyaml-dev zlib1g zlib1g-dev libcap-ng-dev libcap-ng0 make libmagic-dev Ensuite, nous aurons besoin de télécharger la dernière version de Suricata à partir du site officiel : http ://suricata-ids.org/download/ # tar -xzfv Suricata* Puis, la configuration du paquet avant la compilation. # ./configure --enable-prelude --with-libprelude-prefix=/usr/local --prefix=/usr --sysconfdir=/etc –localstatedir=/var # make && make install-full Une fois Suricata installée, nous effectuons le paramétrage de son fichier de configura- tion, mais avant cela il faut remplacer le fichier de configuration par défaut par le fichier de configuration dedié aux distributions qui sont basées sur Debian. Ce fichier se trouve ci-dessous. https://wiki.zentyal.org/wiki/Suricata-debian.yaml A.U 2015-2016 60
  • 62.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # sudo nano /etc/suricata/suricata.yaml Figure 3.14 – Fichier de configuration de Suricata Enfin, pour lancer Surricata, la commande suivante doit être exécutée. # sudo suricata -c /etc/suricata/suricata.yaml -i eth0 3.4.7 Gestion des règles de Suricata avec Oinkmaster Chaque jour, nous découvrons un ensemble de nouvelles attaques. C’est pour cela qu’il faut mettre à jour les règles des IDS afin de protéger notre réseau. Il est possible d’installer ces nouvelles règles manuellement mais il existe des méthodes plus faciles et plus rapide parmi lesquelles “Pulled Pork” et “Oinkmaster”[URL_N13]. Dans notre cas nous allons opter pour “Oinkmaster”. Nous commençons par l’installation. # sudo apt-get install oinkmaster Oinkmaster doit savoir la source ou il peut extraire les nouvelles règles. Elles se trouvent ici. http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz Nous allons ajouter cette source dans le fichier de configuration d’Oinkmaster. # sudo nano /etc/oinkmaster.conf Nous commentons l’URL qui existe déjà et on ajoute la nouvelle source de la façons ci_dessous. url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz On sauvegarde le fichier. Ensuite nous allons créer un dossier afin d’y mettre les nouvelle règles. A.U 2015-2016 61
  • 63.
    CHAPITRE 3. DÉTECTIOND’INTRUSION # sudo mkdir /etc/suricata/rules # cd /etc # sudo oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules Dans le nouveau dossier des règles, nous devons les déclarer dans le fichier de configu- ration de Suricata. # sudo nano /etc/suricata/suricata.yaml Et nous insérons les lignes ci_dessous. classification-file: /etc/suricata/rules/classifcation.config reference-config-file: /etc/suricata/rules/reference.config Pour vérifier que la nouvelle configuration, on lance cette commande. # Suricata -c /etc/suricata/suricata.yaml -i eth0 Il est recommandé d’effectuer la mise à jour des règles fréquemment. C’est pour ça nous avons utiliser l’outil Crontab pour lancer la mise à jour quotidiennement 3.4.8 Mise en place du HoneyPot Kippo Un HoneyPot[URL_N14] ( Pot de miel ) est un faux service (ou parfois une machine virtuelle) installé sur une machine dans le but d’attirer l’attention des “hackers” et les piéger en envoyant leur identité. Kippo est un HoneyPot SSH. Il va prendre la place du service SSH en l’effectuant une configuration qui va le rendre non sécurisé. Pour cela nous devons changer le port de standard du protocole concerné. De cette façon, toute connexion au port 22 sur la machine protégée sera loggé et analyser ultérieurement par l’administrateur. Avant de commencer l’installation de Kippo, nous effectuons le changement du numéro de port du protocole SSH. # sudo nano /etc/ssh/sshd_config Il est possible de choisir n’importe quel port, il faut qu’il soit libre. (par exemple 13125). Commençons l’installation de Kippo. # sudo apt-get install python-twisted Il faut créer un utilisateur qui va exploiter le service. # sudo adduser kippo A.U 2015-2016 62
  • 64.
    CHAPITRE 3. DÉTECTIOND’INTRUSION Ensuite, télécharger et installer le package de Kippo (version 0.8). # cd/opt # wget http://kippo.googlecode.com/files/kippo-0.8.tar.gz # tar -zxvf kippo-0.8.tar.gz # sudo chown kippo:kippo kippo-0.8 -Rf Par défaut Kippo écoute sur le port 2222. Nous allons effectuer une configuration afin que iptables redirige les flux arrivant sur le port 22 vers le port 2222. # sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222 Il ne reste que de lancer le piège. # cd Kippo-0.8 # su kippo # ./start.sh Il est possible de sécuriser le service SSH en utilisant la technique PortKnocking. Pour en savoir plus, voir l’annexe A. 3.5 Conclusion Dans ce chapitre nous avons présenté une brève introduction à la détection d’intrusion en rappelant ses principes et ses méthodes de fonctionnement suivi par les étapes de l’installation et de la configuration de prelude et ses sondes. Figure 3.15 – Liste des Sondes Actives Dans ce qui suit nous allons entamer le dernier chapitre qui sera consacré pour la présentation de la solution finale suivis par des tests d’intrusion. A.U 2015-2016 63
  • 65.
    Chapitre 4 Exploitation ettests 4.1 Introduction Dans ce présent chapitre, une brève démonstration de la solution finale sera présentée afin de montrer comment les logiciels installés ont été exploités et tester les performances du système de détection d’intrusion (IDS). 4.2 Tests d’intrusion : Pentest 4.2.1 Méthodologies Il existe deux principaux idéologies de test de pénétration : “Black Box Testing” et “White Box Testing”. Black box testing La société qui contracte une équipe de test de pénétration n’offre pas d’informations. Ce test est semblable à un boxeur confronté à un adversaire dont il ne connait rien. Ces deux boxeurs doivent apprendre à se connaitre pendant le combat. Pour ce faire, ils com- menceront par se tourner autour, pour connaitre les faiblesses de l’autre. Le combat peut progresser lentement étant donné que chacun d’eux rassemble des informations sur son adversaire pendant la rencontre. De même, Dans ce test, toutes les informations que les testeurs détiennent sont des informations collectées par eux-mêmes. Ce type de test s’ap- parente à une véritable attaque de pirates. Cela pourrait être utile si la société voulait savoir quels sont les informations qu’un “hacker” pouvait collecter sur elle. White box testing Ce type de test est à l’autre bout du spectre. Contrairement au boxeur qui ne sait rien de son adversaire, dans ce scénario le boxeur a bien préparé son combat. Il a visualisé les matches de son adversaire. Il a cherché ses faiblesses pour qu’il puisse les exploiter. Le “white box testing” est similaire à cette approche. Ici l’équipe de test de pénétration peut accéder aux codes source et à toutes les autres informations que la société peut lui offrir. Ce type de test est utile car les testeurs peuvent trouver et exploiter les vulnérabilités sans avoir à chercher l’information d’abord. Bien qu’il soit couteux, ce test peut faire gagner de l’argent à l’entreprise en permettant à l’équipe d’audit de se concentrer sur la détection et 64
  • 66.
    CHAPITRE 4. EXPLOITATIONET TESTS l’exploitation des vulnérabilités sans perdre beaucoup de temps dans la phase de collecte d’informations. Ce que nous allons faire c’est de tester quelques méthodes d’attaques les plus connus et voir comment l’IDS va réagir. 4.2.2 Plateforme de test d’intrusion Afin de tester l’IDS nous avons réalisé quelques attaques dans un réseau virtuelle en utilisant le logiciel “Oracle VM VirtualBox”. Dans la machine serveur qui est représenté dans la figure qui suit, nous avons installé les sondes mentionnées dans le chapitre précédent. Une application web vulnérable à été hébergé sur le serveur. Il s’agit de DVWA(Damn Vulnerable Web App), c’est application web écrite avec PHP/MySQL qui contient des failles de sécurité. Elle a comme objectif de permettre aux professionnels de tester leurs compétences en matière de détection et d’exploitation des vulnérabilités. Dans un scénario de test que nous allons provoquer ultérieurement, une machine vir- tuelle sera installée et ajoutée dans le réseau afin de jouer le rôle d’une machine Linux vulnérables à un ensemble d’attaques. Nous y installerons un OS dédié pour cette tâche particulière connu sous le nom de “ Exploitable”. Figure 4.1 – Machines VirtualBox A.U 2015-2016 65
  • 67.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.2 – Réseau de teste 4.2.3 Simulations d’attaques Dans ce qui suit nous allons montrer les scénarios que nous avons réalisé. En premier lieu, nous allons lancer une simple commande “traceroute”. il n’y a pas une méthode plus simple que celle-ci afin de commencer le collecte des informations à propos du réseau. Figure 4.3 – Commande traceroute Comme le montre la figure 4.4, nous avons utiliser l’outil “Httrack”. Cet outil permet de copier tout le contenue d’un site web ciblé dans la machine du “hacker” afin qu’il puisse analyser, scanner l’application sans qu’il soit détecté. A.U 2015-2016 66
  • 68.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.4 – Scénario Httrack Puis nous allons Utiliser l’outil Zenmap afin de scanner le serveur. Zenmap est l’inter- face graphique du fameux Nmap. La commande Nmap executé dans la figure 4.5 permet de verifier l’etat de tous les ports TCP( 1-65535 ). Cet étape est trés critique, c’est la oû le “hacker” aura une vision plus claire sur l’état de la machine ciblée et sur les services qu’elle offre. Figure 4.5 – scénario Zenmap A.U 2015-2016 67
  • 69.
    CHAPITRE 4. EXPLOITATIONET TESTS Dans la figure 4.6, une liste des techniques d’attaque disponibles sur l’outil Ettercap. Figure 4.6 – Ettercap attaques À l’aide d’Ettercap nous avons simulé une attaque de type “Man in the middle”. Cette technique consiste à effectuer un sniff de trafic entre deux terminaux choisis. Cela permet de capturer les données et même de les modifiées. Figure 4.7 – scénario ARP poisoning Pour terminer, nous avons utiliser Armitage pour Scanner le serveur. Armitage est l’interface graphique de l’outil “ Metasploit ”. A.U 2015-2016 68
  • 70.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.8 – Scénario Armitage 4.2.4 Alertes Nous allons maintenant voir les notifications et les alertes qui ont été causées par les scénarios d’attaque cités dans la partie précedente. Comme le montre la figure 4.9, Suricata à bien été en garde afin de détecter les attaques web que le serveur Ubuntu à subit. A.U 2015-2016 69
  • 71.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.9 – Alerte : service web attaqué Dans la figure 4.10, un ensemble d’alertes et de notifications, nous en citons : “Promiscious mode detected” : L’IDS a détecté une machine qui a activé le mode écoute du trafic dans un des ses interfaces. “SSHD authentification failed” : une personne à essayé de se connecter au serveur via SSH mais il n’a pas réussi. Si cela se répète encore, ça peut générer une alerte de niveau plus élevé. Figure 4.10 – Notifications de niveau bas Les alertes qui sont affichées dans la figure 4.11 ont été enclenché après un scanne fait A.U 2015-2016 70
  • 72.
    CHAPITRE 4. EXPLOITATIONET TESTS par Nmap. Figure 4.11 – Scanne NMAP détecté Dans la figure 4.12, nous pouvons voir les alertes enclenchées après une attaque effectué à l’aide de metasploit. Figure 4.12 – Scanne détecté Un exemple d’une fausse alerte est affiché dans la figure 4.13. Les resultats de détection d’intrusion ne sont pas toujours fiables. A.U 2015-2016 71
  • 73.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.13 – Fausse alerte 4.3 Interpretation des statistiques L’effort de Prewikka ne s’arrête pas à la visualisation des alertes, il peut aussi générer des graphes de statistiques. Ci-dessous un exemple de graphe. Ce dernier affiche le taux des alertes classées par niveau d’urgence sur un échelle temporel. Figure 4.14 – Prewikka : Graphe 1 Dans ce qui suit un graphe qui représente les alertes les plus rencontrées sur un échelle temporel. A.U 2015-2016 72
  • 74.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.15 – Prewikka : Graphe 2 Les pourcentages des notifications classées par leurs descriptions sont affichées dans le graphe qui se trouve dans la figure 4.16. Figure 4.16 – Prewikka : Graphe 3 Ensuite, un graphe qui montre le taux des notification classées par leurs groupes de référence se trouve dans la figure ci-dessous. A.U 2015-2016 73
  • 75.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.17 – Prewikka : Graphe 4 La figure 4.18 présente le taux des notifications groupés par niveau d’importance. Figure 4.18 – Prewikka : Graphe 5 La figure 4.18 présente les utilisateurs qui ont été ciblés en mentionnant le nombres d’attaques qu’ils ont subis. Figure 4.19 – Prewikka : Graphe 6 A.U 2015-2016 74
  • 76.
    CHAPITRE 4. EXPLOITATIONET TESTS Dans le figure suivante, les taux des adresses IP qui ont été derrière l’enclenchement de l’alerte. Figure 4.20 – Prewikka : Graphe 7 Nous avons aussi la possibilité de surveiller les performances des sondes connectées à prelude via le graphe présenté dans la figure suivante. Figure 4.21 – Prewikka : Graphe 8 4.4 Hexadef Afin d’utiliser les outils que nous avons mise en place dans le réseau, l’administrateur doit consulter plusieurs interfaces : Prewikka (interface web de prelude), Zabbix frontend (interface web de zabbix), nessus et Graylog. Dans l’intention de rendre l’accès à ces interfaces plus facile, nous avons développé une application web qui regroupe ces quatre interfaces en une seule. Nous l’avons intitulé « HexaDef » ; “Hexa” comme “Hexabyte” et “Def” comme “Defender”. A.U 2015-2016 75
  • 77.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.22 – Interface Hexadef A.U 2015-2016 76
  • 78.
    CHAPITRE 4. EXPLOITATIONET TESTS Conclusion général Notre projet de fin d’étude a eu pour objectif l’installation, la configuration et la mise en place d’un outil de supervision réseau et d’un autre de détection d’intrusion réseau. Pour atteindre le but fixé, nous avons d’abord commencé par récolter des informations sur le réseau de l’entreprise et sur les outils Open d’administration réseau et de détection d’intrusions réseau. Ensuite, une étude comparative entre les nombreux outils open source a été menée et nous a permis de faire notre choix. Nous avons en effet choisi d’installé Zabbix en tant que logiciel de supervision principal suivi par des configurations avancées. Pour ce qui est du choix d’une solution IDS, nous nous sommes tournés vers Prelude- IDS et ses sondes. Nous sommes, juste après, passés à l’installation et à la configuration de ces différentes solutions. Pour finir, Un ensemble de tests d’intrusion a été réalisé afin de déterminer les performances de la plateforme de détection d’intrusion ; nous avons pré- senté un ensemble des statistiques que Prelude peut générer suivi par l’application web que nous avons commencé à développer. Nous avons, à travers ce stage, découvert le domaine de la supervision et de la détection d’intrusion réseaux et systèmes. Ce projet nous a également permis d’appliquer et d’amé- liorer nos connaissances du domaine de l’administration réseau et la sécurité informatique. En perspective, bien que notre projet ait satisfait les besoins de l’organisme d’accueil, des améliorations vont être ajoutées pour élargir la supervision et la surveillance du réseau et des systèmes mises en question. A.U 2015-2016 77
  • 79.
    Bibliographie [URL_N1] WorkAroud, URL: https ://workaround.org/article/tired-of-nagios-and-cacti- try-zabbix [ dernière consultation : 10/05/2016] [AND_13] Andrea Dalle Vacche , Stefano Kewan Lee « Master Zabbix », packt publi- shing, 2013, ISBN : 9781783283491, 337 [URL_N2] ReadTheDocs, URL https ://shinken.readthedocs.io/en/latest/ [ dernière consultation : 25/05/2016 ] [URL_N3] AlienVault, URL : https ://www.alienvault.com/docs/whitepapers/OSSIM_vs_Commercial_White_Paper.pdf [URL_N4] MonitoringFR, URL : http ://wiki.monitoring-fr.org/zabbix/start#ii-installation [ dernière consultation : 25/05/2016 ] [THI_04] Thierry Evangelista « IDS : Les systèmes de détection des intrusions infor- matiques », InfoPro, 2004, ISBN : 9782100072576, 261 [URL_N5] TheDutchLab, URL : https ://thedutchlab.com/blog/installing-zabbix-on- ubuntu-1404 [ dernière consultation : 25/05/2016 ] [URL_N6] TecMint, URL : http ://www.tecmint.com/install-zabbix-agent-and-add-windows- host-to-zabbix-monioring/ [ dernièreconsultation : 25/05/2016 ] [URL_N7] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how- to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04 [ dernière consultation : 25/05/2016 ] [URL_N8] 2DayGeek, URL : http ://www.2daygeek.com/zabbix-upgrade-from-2-4-x- to-3-0-network-monitoring-tool-on-centos-rhel-debian-mint-ubuntu/ [ dernière consul- tation : 20/05/2016 ] [URL_N9] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how- to-install-graylog2-and-centralize-logs-on-ubuntu-14-04 [ dernière consultation : 24/05/2016 ] [URL_N10] Prelude-Siem, URL : https ://www.prelude-siem.org/projects/prelude/wiki [ dernière consultation : 25/05/2016 ] [URL_N11] ReadTheDocs, URL : http ://ossec-docs.readthedocs.io/en/latest/index.html [ dernière consultation : 5/05/2016 ] [URL_N12] OpenInfoSecFoundation, URL : https ://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation [ dernière consultation : 20/05/2016 ] [URL_N13] WZDFTPD, URL : https ://www.wzdftpd.net/blog/installing-suricata-with- oinkmaster-on-debian.html [ dernière consultation : 22/05/2016 ] 78
  • 80.
    CHAPITRE 4. EXPLOITATIONET TESTS [URL_N14] IT-Connect, URL : http ://www.it-connect.fr/honey-pot-ssh-avec-kippo/#III_Test_et_visualisation_des_logs [ dernière consultation : 28/05/2016 ] A.U 2015-2016 79
  • 81.
    Annexe A Principe Port-Knocking estune méthode qui permette une communication machine à machine dans laquelle les informations passent à travers des ports qui apparaissent à la première vue fermés. Pour avoir accès à un port spécifique, il faut d’abord saisir une séquence de connexions précise. L’utilisateur doit atteindre différents ports distincts dans un ordre bien précis afin d’ouvrir le port voulu. Les ports sont fermer par un pare-feu tant que la séquence Knock-Port n’a pas été effectué. Dans le cas d’un scanne des ports sur un serveur, touts les ports apparaissent fermés bien que le service qui fonctionne sur ce port soit en actif. C’est le pare-feu qui effectue un rejet (DROP). Prenons l’exemple du service SSH qui écoute sur le port 22 sachant que nous l’avons attribué la séquence de knock-port suivante : 2212 → 2213 → 2214. Si une personne se connecte au serveur via ssh sans avoir saisi la séquence effectué, le port 22 restera fermé et l’événement sera loggé. Si un utilisateur a bien saisie la séquence , le port 22 s’ouvrera pour une durée de temps limitée . . . les logs générés suite à ces événements peuvent être exploités par les outils de supervision et de détection d’intrusion. Installation et configuration de Knockd Commençons l’installation. # sudo apt-get install konckd # sudo nano /etc/knockd.conf 80
  • 82.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.23 – Fichier de configuration de Knockd Knockd utilise le pare-feu Iptable. Ce dernier est disponible par défaut dans la majorité des distribution linux. Afin de lancer le service Knockd automatiquement au démarrage du système il faut modifier la valeur : START_KNOCKD=1. # nano /etc/default/knockd Figure 4.24 – Fichier de configuration du lancement automatique de Knockd Le lancement du service se fait par l’exécution de la commande suivante. # sudo service knockd start Une démonstration de demande de connexion directe au port 22 est présentée ci- dessous. A.U 2015-2016 81
  • 83.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.25 – Connexion au serveur via PuTTY Le scénario des connexions n’a pas été respecté, ce qui résulte à l’erreur affiché dans la figure suivante. Figure 4.26 – Connexion refusé Dans l’exemple suivant, nous allons suivre les règles d’accès que Knockd propose. Figure 4.27 – Scénario d’accès SSH Après la réalisation de ce scenario nous nous connectons au port 22. A.U 2015-2016 82
  • 84.
    CHAPITRE 4. EXPLOITATIONET TESTS Figure 4.28 – Connexion etablie Comme c’est affiché dans la figure précédente la connexion s’est établie avec succès . Remarque Cela dit cette technique n’est pas pratique avec les services publiques tel que le web. Par contre elle est utilisable avec les services ftp, ssh et telnet. A.U 2015-2016 83