Projet de Fin d’Etudes Pour l’Obtention du Diplôme Master en Ingénierie Informatique et Internet
Intitulé :
Gestion et centralisation des logs avec leurs corrélations Présenté par : BENZIDANE KARIM
Le, 06/07/2010
Encadrants : Moussaid Khaild , Faculté des Sciences, Sciences, Casablanca Zoubir Sami , Crédit du d u Maroc, Casablanca Ouali Youness, Crédit du Maroc, Casablanca
Membres du Jury : Mr Abghour, Faculté des Sciences, Casablanca Mr Bouzidi, Faculté des Sciences, Casablanca Mme Fetjah, Faculté des Sciences, Casablanca
Année Universitaire Universitaire 2009 2009 / 2010 2010 1
Remerciements
J’adresse mon remercîment à Mr. Zoubir sami pour sa disponibilité et écoute ainsi de m’avoir accepté dans son département et m’avoir permis le choix du sujet.
Je remercie également Mr. Youness OUALI pour ses valeureux conseils ainsi que son encadrement au cours de ce stage allant de la démarche du travail jusqu’au technique de déploiement. Je remercie également Mr Abderahim SEKKAKI pour nous avoir donnée l’opportunité d’acquérir ces connaissances, ainsi que tous les enseignants que j’ai eu au long de ces 2 années du Master.
Un grand merci à mon encadrant Mr Moussaid pour son aide et conseil pour que ce stage soit réalisé et finalisé. Je tiens aussi à remercier toute l’équip e du plateau ou j’étais à CDM, pour leur aide afin de me fournir les informations nécessaires pour le bon déroulement du projet .
Mes remerciements aux membres des jurys qui m’ont honoré en acceptant de juger ce travail.
2
Remerciements
J’adresse mon remercîment à Mr. Zoubir sami pour sa disponibilité et écoute ainsi de m’avoir accepté dans son département et m’avoir permis le choix du sujet.
Je remercie également Mr. Youness OUALI pour ses valeureux conseils ainsi que son encadrement au cours de ce stage allant de la démarche du travail jusqu’au technique de déploiement. Je remercie également Mr Abderahim SEKKAKI pour nous avoir donnée l’opportunité d’acquérir ces connaissances, ainsi que tous les enseignants que j’ai eu au long de ces 2 années du Master.
Un grand merci à mon encadrant Mr Moussaid pour son aide et conseil pour que ce stage soit réalisé et finalisé. Je tiens aussi à remercier toute l’équip e du plateau ou j’étais à CDM, pour leur aide afin de me fournir les informations nécessaires pour le bon déroulement du projet .
Mes remerciements aux membres des jurys qui m’ont honoré en acceptant de juger ce travail.
2
Table des matie ma tie res Liste des figures ................................................................................................................ 4 Introduction ..................................................................................................................... 5 Chapitre 1 : Contexte du projet ......................................................................................... 7 1.1 Crédit du Maroc .................................................................................................................................. 8 1.4 Définition du besoin ........................................................................................................................... 9 1.2 Définition d’un SIMS ......................................................................................................................... 11 1.3 Fonctionnalité : ................................................................................................................................. 11
Chapitre 2 : Etat de l’art .......................... ....................................... .......................... ........................... ........................... .......................... ................... ...... 15 2.1 Choix de la solution SIMS : ............................................................................................................... 16 2.1 Prelude-SIEM........................................................................................................................................ 17
2.2 Format standard ............................................................................................................................... 25 2.3 Compatibilité ..................................................................................................................................... 27
Chapitre 3 : Sondes et sources
d’informations
........................... ......................................... ........................... .................. ..... 29
3.1 Qualité indispensable ...................................................................................................................... 30 3.2 Intégration de sources d’information externes ............................................................................ 41
Chapitre 4 : Etude et réalisation de la maquette de test .................................................. 44 4.1 Architecture ...................................................................................................................................... 45 4.2 Fonctionnalités ................................................................................................................................. 46 4.3 Outils et sondes utilisées ................................................................................................................. 46 4.4 Stockage des informations dans une BD ............................................................................................... 48 4.5 Schéma de la structure de base adoptée .............................................................................................. 48 4.5 Enregistrement des sondes .................................................................................................................. 49
4.6 Haute disponibilité ........................................................................................................................... 51 Elaboration de Prelude en haute disponibilité ........................................................................... 52 4.7 Performance ...................................................................................................................................... 53
Chapitre 5 : Fonctionnement et test ................................................................................ 55 ....................................................................................................................................... 56 5.1 Scan de Port .......................................................................................................................................
5.2 Brute force attaque ........................................................................................................................... 58 5.3 Analyse via Prelude-LML ................................................................................................................. 60 5.4
L’interface Prewikka: ................................................................................................................. 63
Conclusion Conclusion .......................... ....................................... ........................... ........................... .......................... .......................... ........................... .......................... ............ 68 Annexe .......................... ........................................ ........................... ........................... ........................... .......................... ........................... ........................... ................ ... 69 Reference ....................................................................................................................... 83 3
Liste des figures
Figure 1 : Schéma de l'organisme l'organism e DSIG ............................................................................................................. 9 Figure 2 : Topologie analogique d'une SIEM ................................................................................................... 10 Figure 3 : Illustration des étapes du SIMS ....................................................................................................... 11 Figure 4 : Tableau comparatif des solutions SIEM .......................................................................................... 16 Figure 5 : Architecture simple ......................................................................................................................... 23 Figure 6 : Architecture à relai ......................................................................................................................... 24 Figure 7 : Architecture à relai inversé ............................................................................................................. 24 Figure 8 : Structure d'un message IDMEF ....................................................................................................... 26 Figure 9 : Tableau de compatibilité de Prelude............................................................................................... 28 Figure 10 : Modèle avec l a couche SSH ........................................................................................................... 30 Figure 11 : Fonctionnement des NIDS ............................................................................................................. 31 Figure 12 : Fonctionnement d'un HybIDS ....................................................................................................... 34 Figure 13 : Fonctionnement d'un pare-feu ..................................................................................................... 36 Figure 14 : Maquette de teste proposée......................................................................................................... 49 Figure 15 : Remonté d'une alerte corrélée (EvantScan) .................................................................................. 58 Figure 16 : Remonté d'une alerte corrélée (Brute Force) ................................................................................ 60 Figure 17 : Fichier syslog , journalisant HoneyD .............................................................................................. 61 Figure 18 : Remonté d'alerte de la sonde HoneyD via Prelude -LML ................................................................ 62 Figure 19 : Formulaire d'authentification ....................................................................................................... 63 Figure 20 : Page principale Prewikka .............................................................................................................. 64 Figure 21 : Liste des alertes ............................................................................................................................ 65 Figure 22: Détail d'une alerte ......................................................................................................................... 65 Figure 23 : Pages des alertes corrélées ........................................................................................................... 66 Figure 24 : Liste et pages des agents ............................................................................................................... 67 Figure 25 : Graphes de la page statistiques .................................................................................................... 67
4
Introduction De nos jours, les réseaux d’entreprise sont exposés à toutes sortes d’attaques informatiques qui vont du simple challenge entre hackers, aux attaques ciblées d’autres organ isations ou entreprises concurrentes en passant par le sabotage de serveurs (dénis de service) dans le but de discréditer l’entreprise en tant que fournisseur de services ou simplement en tant qu’entreprise. Les attaques indoor semblent aussi prendre de l’ampleur.
Ainsi, les problèmes de protection et préventions contre les attaques informatiques sont de plus en plus complexes et variés puisque :
Les entreprises sont de plus en plus délocalisées et donc disposent de réseaux intranet et extranet nationaux ou/et mondiaux, Les attaques peuvent être externes (outdoor) et internes (indoor), Les collaborateurs sont de plus en plus mobiles et donc les réseaux d’accès de plus en plus nombreux et variés. Donc, le responsable des services informatiques et le responsable de la sécurité doivent travailler de plus en plus en étroite collaboration pour garantir la consistance des données administratives. Pour l’administrateur réseau et sécurité, le nouveau challenge consiste donc à :
Définir et promouvoir une politique sécurité, Déployer les dispositifs de défense, Assurer par des outils d’observations performants la détection de failles éventuelles et le cas échéant, Redéfinir et redéployer rapidement de nouvelles défenses, voire même redéfinir une nouvelle politique de sécurité. Malheureusement la gestion de la sécurité consiste actuellement à superposer aux outils et données existantes celles relatives à la sécurité. Cela créé des redondances très néfastes au niveau des investissements et surtout au niveau des données avec par exemple des conséquences très fâcheuses lors de révocation de droits d’accès suite à une réaffe ctation ou au départ d’un collaborateur. Cependant, les solutions sont trop complexes et coûteuses pour répondre aux besoins des entreprises. Dans notre évaluation du marché, nous avons constaté surtout l’émergence de nouvelles plate formes de gestion de sécurité, très spécialisées et plus adaptées. Cette nouvelle génération de produits dispose d’outils d’analyse et corrélation pouvant dans une certaine mesure déterminer, parfois même en temps réel, la gravité de la menace ou la profondeur de l’intrusion en cours. Cette intelligence est cependant très
5
redevable du flux d’information provenant des différents organes à surveiller respectivement à protéger. Dans l’urgence, les entreprises investi ssent des sommes colossales dans des logiciels et des matériels sensés garantir la sécurité et l’intégrité du réseau. • Un réseau d’entreprise digne de ce nom est formé d’équipements réseau hétérogènes et d’une certaine variété de systèmes d’exploitation, chacun fournissant ses logs1 dans un format bien propriétaire. Selon le type de solution utilisé, il est souvent nécessaire de parcourir tous ces logs séparément et manuellement. • Certains de ces logs sont envoyés en clair sur le réseau ( syslog et SNMPv.1 en sont de bons exemples) vers un serveur central, offrant ainsi à des personnes malveillantes une magnifique opportunité de masquer leurs agissements en inondant ledit serveur de faux messages ou alertes. • Dans l’état actuel des choses, aucune soluti on commerciale ou Open Source ne peut prétendre garantir seule la sécurité du réseau . . . il faut avoir recours à plusieurs produits de conception et de source différentes. Chacun de ces produits possède bien sûr un format de message et une interface qui lui sont propres. • Bien que la qualité des sondes réseaux et hôtes se soit grandement améliorée, ces dernières sont toujours sujettes à un pourcentage non négligeable de faux positifs 2 et faux négatifs3. • Il existe toutefois une petite proportion d’entre prises où la surveillance du réseau ne souffre peu ou pas des points mentionnés ci-dessus. Malheureusement, le travail du responsable de la sécurité n’en est pas facilité pour autant, car il doit ” jongler” avec un flot incessant d’alertes provoquées par des comportements qui n’ont, dans 90% des cas, aucun impact sur l’intégrité du réseau(En effet, quelle est l’utilité de signaler des attaques propres à Microsoft IIS dirigées contre un serveur Apache ?). • Un dernier point noir est le fait que les réseaux 10 0% switchés ont de plus en plus la cote auprès des entreprises . . . ce qui est une bonne chose du point de vue de la (pseudo) confidentialité des données. Malheureusement, ces derniers sont plus problématiques à surveiller. En effet, suivant le nombre de postes connectés et le débit des données, le port ”monitoring” du switch devient complétement saturé, rendant soit impossible l’analyse complète des données (perte de paquets) ou ralentissa nt l’ensemble de son fonctionnement (throttling). A la vue du triste palmarès des solutions actuelles de sécurité, nous pouvons aisément constater qu’il devient impératif de trouver rapidement une solution. Force est de con stater qu’à l’heure actuelle, seuls des produits commerciaux très onéreux prétendent o ffrir une alternative viable et se destinent naturellement au marché des grandes entreprises. L’arrivée d’un produit tout aussi efficace à prix plus modéré serait extrêmement bien accueillie offrant ainsi un bon SIMS4.
1
Fichier journal Une alerte est levée sans raison 3 Aucune alerte n’a été levée alors que l’attaque a bien eu lieu 4 Security information management System 2
6
Chapitre 1 : Contexte du projet
7
1.1 Crédit du Maroc
Etablissement financier marocain de premier ordre, le Crédit du Maroc, filiale du Groupe Crédit Agricole SA (France)
1.1.1 Présentation CDM La banque Crédit du Maroc est un groupe financier marocain multi-métiers ayant une présence nationale. CDM exerce ses activités en direct et à travers plusieurs filiales spécialisées. Ses activités directes sont organisées en 2 pôles Métiers et 1 pôle transverse organisé. Ainsi, les pôles Métiers comprennent : Le pôle Banque Réseau et de Détail; Le pôle Banque de Financement et d’Investissement; Le pôle Industrialisation; Le pôle Industrialisation comprend : La Direction des Systèmes d’Information Groupe « DSIG » La Direction de l’Organisation Groupe « DOG » La Direction des Services à la Clientèle et des Flux « DSCF » La Direction des Immeubles et de Logistique « DIL »
1.1.2 Organisation et présentation DSIG La Direction des Systèmes d’Information Groupe a pour objectif de répondre aux besoins informatiques de l'ensemble des utilisateurs ou maîtrises d'ouvrage du Groupe CDM en accord avec la stratégie globale de la banque visant à améliorer la rentabilité, la qualité de service, la productivité et la sécurité. Elle assure cet objectif en veillant à la cohérence globale du système d'information.
Les départements qui constituent la DSIG veillent à :
Définir et contrôler l'application des normes et standards informatiques régissant la conduite des projets et définissant les rôles des différents acteurs,
Organiser et assurer le rôle de la maîtrise d'œuvre fonctionnelle à travers les métiers traditionnels de l'informatique à savoir la gestion cohérente de l'architecture fonctionnelle, les études et développements, la gestion des projets et la maintenance,
Organiser et assurer la gestion de l'infrastructure du système d'information et le déroulement des traitements périodiques dans les meilleures conditions de qualité de service. Cette mission comprend la gestion de l'architecture technique (informatique centrale et distribuée, télécommunications) avec comme objectifs la sécurisation des données et des traitements informatiques, la cohérence et le dimensionnement optimal de l'infrastructure technique et la pérennité des investissements.
8
Le schéma ci-dessous donne une vision globale de l’or ganisation DSIG :
Figure 1 : Schéma de l'organisme DSIG
1.4 Définition du besoin
1.4.1 Problématique : Comme cité dans la partie ci-dessus , le stage est effectué à «Crédit du Maroc »(Siège ) là où réside le système d’information central. Tous facilement constaté une banq ue requiert toujours un système d’information robuste et surtout bien sécurisé. De nos jours, le système d’information (S.I.) est devenu vital pour la majorité des entreprises. Garant de l’activité de l’entreprise pour certaines ou simple garant des donné es confidentielles pour d’autres, une interruption de service du S.I. induirait des risques majeurs pour l’entreprise Risque de perte financière Risque de perte d’image Risque d’impact juridique Face à ces risques, les entreprises n’ont pas d’autre choix que d’investir dans une pol itique de sécurité. Cependant le coût de ces investissements est loin d’être négligeable et les entreprises sont souvent confrontées aux problèmes suivants : 9
La multiplicité et la complexité croissante des technologies. L’émergence de nouvelles attaques (phishing, virus, etc …) sans cesses plus pert inentes qui imposent aux entreprises une veille permanente La spécificité. Chaque entreprise est différente, donc chaque entreprise à ses contraintes propres (au niveau stratégique comme au niveau technique). 1.4.2 Le besoin :
Le besoin de base consiste à mettre en place un manager de sécurité centralisé (Figure 1) capable de faire face au flot d’alertes et autres problèmes rapportés par les HIDS et NIDS du réseau, ainsi que différent autre composant de sécurité . Le premier but est de récolter toutes ces alertes et de les présenter dans un format unique et homogène, rendant ainsi possible l’analyse de ces informations par l’administrateur. Une fois toutes les alertes brutes récupérées, il faudrait mettre en place un mécanisme de corrélation. Ce dernier permettra de diminuer une partie des faux-positifs, sans toutefois les éradiquer totalement. Ainsi, l’administrateur de sécurité aura une vue globale sur les attaques qui ont réell ement abouties, sans devoir visualiser les unes après les autres les milliers d’alertes g énérées.
Figure 2 : Topologie analogique d'une SIEM
10
1.4.3 Cahier des charges En partant de ce qui a été énoncé au paragraphe précédent, l’étude sera faite sur l’établissement d’une solution SIMS. Cette solution semblant répondre aux problématiques précédemment citées, permettant ainsi de gérer de manière centralisée les remontées d’information de différents outils, de les stocker et les traiter afin de faciliter l’administration et la gestion de la sécurité pour l ’ administrateur. Après concertations avec l’encadrant et aux vues des besoi ns, la liste des taches sera la suivantes : Etude de la problématique. Choix d’une solution SIMS : NetForensics OSSIM Prelude Etude de la solution SIMS choisie Mise en œuvre d’une maquette de test Rapport de test
1.2 Définition d’un SIMS
Un SIMS appelés également SEM (Security Event Management) ou SEIM (Security Event Information Management) ou encore SIEM (Security Information and Event Management) est un système servant à automatiser la collecte et l’analyse des informations de tous les nœuds de sécurités dans un réseau. Mis à part les informations obtenues des logs et des alertes des firewall, IDS , Anti-virus, VPN et autre système de sécurité , un « Security Manager» peu obtenir tous ces informations dans une seul consol SIM . Il y a différent types de SIM , quelques’ un servent à faire une agrégation de tous les rapports venant des différentes composantes, et d’autre font la corrélation des logs pour a méliorer la qualité d’ensemble de la sécurité de l’information . Il y a deux avantages clés dans l’agrégation des donnés : premièrement , la réduction du cout et l’amélioration de l’efficacité de l’administration. Deuxièmement, la simplification et l’amélioration du reporting pour l’audit. 1.3 Fonctionnalité :
Figure 3 : Illustration des étapes du SIMS
11
La collecte Les logiciels de SIEM prennent en entrée les événements collectés du SI : les logs des équipements (firewalls, routeurs, serveurs, bases de données, etc.). Ils permettent de prendre en compte différents formats (syslog, Traps SNMP, fichiers plats, OPSEC, formats propriétaires, etc.). La collecte peut être de façon passive en mode écoute ou active en mettant en place des agents directement sur les équipements ou à distance. La normalisation Les logs bruts sont stockés sans modification pour garder leur valeur j uridique. On parle de valeur probante. Les logs sont généralement copiés puis normalisés sous un format plus lisible. En effet, la normalisation permet de faire des recherches multicritères, sur un champ ou sur une date. Ce sont ces évènements qui seront enrichis avec d'autres données puis envoyés vers le moteur de corrélation. L’agrégation Fait référence au processus d’acquisition de plus en plus de données .Plusieurs rè gles de filtrage peuvent être appliquées, ils sont ensuite agrégés selon les solutions, puis envoyés vers le moteur de corrélation.
La corrélation La corrélation est une méthode combinat diffèrent événement relié afin d’avoir une image précise de ce qui se passe, ainsi donc limiter les lacunes des IDS. Son but majeur est d’y mettre une bonne concentration de logs et aussi une réduction du bruit générer par les faux positives ou négatives afin de découvrir les nouvelles attaques bien construites. L’atout majeur de la corrélation est de détecter des séquences d’alertes présenté par une ou plusieurs sondes. L’analyse de ces séquences résulte une nouvelle alerte représentant ainsi la signification globale de toutes les séquences.
Il y a deux types de corrélations : – Une corrélation passive : Déduit une alerte uniquement depuis les infos que l’on a par éliminations de doublons, factorisations, ou par fusion simple ou complexe . – Une corrélation active : Dérivé de la corrélation passive pour faire générer à l’IDS de nouvelles alertes, elle va chercher les informations correspondant à des alertes émises. Par exemple, lorsqu'une personne se connecte en dehors des heures de travail, ceci a un impact élevé qui n'aurait pas été en temps normal d'activité.
Exemples : o Compression : A+B = A’ o Seuillage : A+A+A+A+A+A=A o Modification : A->B 12
o Enrichissement : A=A+CVE Après avoir fait la collecte d’un maximum d’information , on peut passer par deux étapes assurant ainsi un bon niveau de corrélation .la première étape reposant su r l’élimination des duplicata , se basant sur la suppression des alertes identiques ou similaires , la deuxième étape consiste à factoriser les alertes ; réduisant ainsi le nombre d’alerte en une seul alerte corrélée , cet alerte résume donc toutes les informations contenues dans les alertes et ajustes leurs propriétés . On trouve deux niveaux d’analyse distinct ; une corrélation simple et corrélation global.
La corrélation simple : Une séquence d’alerte ciblant le même service ou hôte peut être regroupé afin de produire une alerte corrélée. L’analyse de cette séquence d’attaque n’a pas besoins d’informations additionnelles. La corrélation globale : La corrélation simple n’est pas efficace contre une attaque bien construite ; l’attaque ne va pas attaquer le même service ou hôte ainsi que pas dans la même intervalle de temps. La corrélation global considère le contexte de tous les évènements qui nous amène à l’attaque courante et essaye de trouver des similitudes afin de recon struire les séquences de l’attaque. Il y a plusieurs éléments utiles pour un bon niveau d’analyse :
@ IP : Le lien entre le trafic entrant et le trafic sortant est important et généralement pas considérer par les NIDS, l’@ IP est une source utile pour comprendre la relation entre différente alerte et les lier à la même séquence. Comportement : Un changement soudain de comportement dans une activité régulière est considérer comme suspicieuse. Temps de travail : Une connexion hors l’intervalle de travail permise d éclenche une alerte corrélée. Règlement : La Policy de la sécurité interdit la connexion à certain serveur ou service mise à part l’administrateur, donc toute connexion est interprété comme malicieuse.
Le reporting Les SIMS permettent également de créer et générer des tableaux de bord et des rapports. Ainsi, les différents acteurs du SI, RSSI, administrateurs, utilisateurs peuvent avoir une visibilité sur le SI (Nombre d'attaques, nombre d'alertes/jour...). Archivage Les solutions SIEM sont utilisées également pour des raisons juridiques et réglementaires. Un archivage à valeur probante permet de garantir l'intégrité des traces. Les solu-
13
tions peuvent utiliser des disques en RAID, calculer l'empreinte, utiliser du chiffrement ou autre pour garantir l'intégrité des traces. Rejeu des évènements La majorité des solutions permettent également de rejouer les anciens évènements pour mener des investigations post-incidentes. Il est également possible de modifier une règle et de rejouer les évènements pour voir son comportement. Les différentes5 solutions SIM: ArcSight Solutions: ArcSight ESM; ArcSight Interactive Discovery; ArcSight Pattern Discovery
Cisco Solution: CiscoWorks Security Information Management Solution (SIMS)
Computer Associates Solution: CA Security Command Center
eIQnetworks Solution: SecureVue
Enterasys Solution: Dragon Security Command Console
High Tower Solution: SEM 3200
netForensics Solution: nFX SIM One
NitroSecurity Solution: NitroView ESM
Novell Solution: ZENworks Endpoint Security Manager
RSA Solution: enVision Platform
Symantec Solution: Symantec Security Information Manager
TriGeo Solution: TriGeo Security Information Manager
PreludeIDS Technologies Solution: Prelude-SIEM
AlienVault Slolution : OSSIM
5
Listes non exhaustives
14
Chapitre 2 : Etat de l’art
15
2.1 Choix de la solution SIMS :
Figure 4 : Tableau comparatif des solutions SIEM
Nos choix se sont focalisés sur les solutions les plus utilisées sur le marché (Open Source et commercial) ; nFX SIM one de NetForensic , OSSIM de AlienVault et Prelude-SIEM de Prelude. nFX SIM one est considéré parmi les solutions commercial les plus imposées et qui s’est répandue dans le marché d’une façon large, mais elle ne reste pas sans inconvénient car comme toute solution commercial le coté payant reste toujours un obstacle majeur , toujours dans le coté payant de la solution ou réside sa limitation pour la gestion des sondes ; c’est qu’il faut avoir une licence pour chaque sonde ajouté au-delà des dix sondes offerte au achat de la solution , nombre qui est faible pour un déploiement d ’une solution SIM dans un ré seau d’une grande entreprise ou une banque . Mise à part cet inconvénient, une solution commerciale est toujours une boite noire qui est loin d’être modelable ou personnalisable (personnalisation des règles de corrélations par exemple) en vis-à-vis ce qu’on peut faire dans une solution Open Source.
16
La deuxième solution étudié est OSSIM , l’une des première solutions SIM Open Source, mais elle reste moyennement utilisé suite à sa difficulté de déploiement due à une documentation peu abondante et rare aussi , sauf qu’elle offre une interface graphique riche et une grande modularité par rapport aux autres solutions SIM Open Source. Mais l’inconvénient majeur de OSSIM est liés au format des alertes ; une alerte OSSIM peut contenir plusieurs champs ( type, date, sensor, interface, plugin_id, plugin_sid, priority, protocol, src_ip, src_port, dst_ip, dst_port, log, snort_cid, snort_sid, data, condition, value ), le champ log chargé de contenir le log original n’est pas traité par le serveur pour une partie des plugins (NTsyslog, …), ce qui signifie que le log original est perdu et ne pourra pas être utilisé. Si on ajoute à cela le fait qu’OSSIM ne permet la transmission que d’une seule valeur du log (champ value) au moteur de corrélation, nous nous retrouvons avec une granularité insuffisante comparée à la richesse d’informations que peuvent contenir les logs originaux, et c’est là où vient la robustesse de Prelude-SIEM en sa centralisation et normalisation des données collectées, ainsi qu’une interface graphique am élioré (Prewikka) bien plus que ses précédents (piwi, perl-front end ou php-front end ) , ainsi qu’une flexibilité modulaire pour combler les différents manques par rapport au solution du marché. Prelude-SIEM est une solution de grande qualité qui peut être déployer dans un environnement de production non pas comme OSSIM qui pose passablement des problèmes au niveau des phases d’installation et test préliminaire. Après longue réflexion, nous avons décidé d’exploiter la suite Prelude-SIEM comme structure d’échange et de récolte des messages de sécurité, car elle répond à tous les critères de base qui ont été défini comme besoin. 2.1 Prelude-SIEM
2.1.1 Création Le Système de Détection d’Intrusions (IDS) open source Prelude a été créé en 1998 par Yoann Vandoorselaere. Depuis sa création, des ingénieurs et spécialistes en sécurité ont, dans l’esprit open source, contribué activement à Prelude. Ce travail mènera, quelques années plus tard, au développement d’un système de management de la sécurité (SIM) performant et universel devenu l’un des plus largement déployé au monde.
La société PreludeIDS Technologies a été co-fondée en mars 2005 par M. Yoann Vandoorselaere (Ingénieur en développement, Expert sécurité et Responsable R&D) et Mlle Audrey Girard (Ingénieur en systèmes industriels et Gérante) avec l’objectif de repousser les frontières de Prelude open source au travers d'un nouveau type de solutions commerciales. PreludeIDS Technologies a connu une croissance rapide sur le marché hautement compétitif de la sécurité informatique et plus particulièrement sur le marché des systèmes de management de la sécurité. Ils ont développé, avec succès, un portefeuille clients
17
étoffé et prestigieux, incluant certains leaders des télécoms, banques, groupes industriels ainsi que des organisations gouvernementales. 2.1.2 Définition Prelude est un SIM Universel. Prelude collecte, normalise, catégorise, agrège, corrèle et présente tous les événements sécurité indépendamment de la marque ou de la licence du produit dont ces événements sont issus : il est "Agentless". En plus d'être capable de collecter tout type de logs (journaux systèmes, syslog, fichiers plats, etc.), Prelude bénéficie d'une compatibilité native avec certains systèmes de façon à enrichir encore l'information (snort, samhain, ossec, auditd, etc.) Les événements sécurité sont normalisés grâce à un format unique : l'IDMEF (Intrusion Detection Message Exchange Format). IDMEF est une norme internationale créée à l'initiative de l'IETF avec la participation des équipes Prelude pour permettre l'interaction entre les différents outils sécurité du marché. 2.1.3 Composant : Interface Prewikka Prewikka est la console d'analyse graphique du SIM Universel Prelude. En fournissant de nombreuses fonctionnalités, Prewikka facilite le travail des utilisateurs et analystes. Cette interface permet de visualiser les alertes, que un ou plusieurs concentrateurs Prelude (“prelude -manager”) ont stocké en base de données, de façon conviviale. Prewikka fournit aussi des outils externes tels que "whois" ou "traceroute". Manager Prelude Le Manager Prelude est un concentrateur capable de prendre en charge un grand nombre de connexions et de traiter de grandes quantités d'événements. Il utilise des files d'ordonnancement par sonde afin de traiter les événements reçus de façon équitable entre les différentes sondes. Il est responsable de la centralisation, de la journalisation à travers deux fonctions : Celle de relais : un contrôleur relais va assurer le routage vers un contrôleur maître (ou un autre relais dans le cas d'architecture en cascade) d'alertes provenant des sondes qui lui sont rattachées Celle de maître : un tel contrôleur va assurer la réception des messages et alertes provenant des sondes et/ou des contrôleurs relais qui lui sont rattachés ainsi que leur journalisation dans un format unique et lisible par l’analyste. Il enregistre les événements reçus sur des médias spécifiés par l’utilisateur (base de données, journaux système, Email, etc.) et établit les priorités de traitement en fonction de la criticité et de la source des alertes.
18
Un manager Prelude assure également la remontée des tests de connexion (" heartbeats ") échangés avec les sondes réseaux et locales. Ces tests permettent de vérifier la continuité de la communication entre sondes et contrôleurs.
Libprelude La bibliothèque Libprelude permet la communication sécurisée entre les différentes sondes et un Manager Prelude. Elle fournit une interface de programmation (API 6) pour la communication avec les sous-systèmes Prelude et la génération d’alertes au format standard IDMEF. Elle automatise l’enregistrement et la retransmission des données en cas d’interruption d’un des composants du système. Libprelude facilite également la mise en compatibilité de systèmes externes qui deviennent ainsi capables de communiquer avec les composants Prelude. Cette bibliothèque fournit aussi des fonctionnalités communes et utiles à toutes les sondes. LibpreludeDB La bibliothèque PreludeDB fournit une couche d'abstraction par rapport au type et au format de la base de données utilisée pour stocker les alertes IDMEF 7. Elle permet aux développeurs d'utiliser la base de données Prelude IDMEF facilement et efficacement sans se soucier de SQL et d'accéder à la base de données indépendamment du type/format de cette dernière. Prelude-LML Cette sonde prend en charge la remontée d’alertes détectées localement sur l’hôte. Cette détection est basée sur l’application à des objets (fichiers de jour nalisation et/ou d’application) de règles construites autour d’ expressions régulières compatibles Perl (PCRE8). Prelude-LML est comparable à la façon qu’utilise Snort pour analyser des paquets via des règles. Dans le cas de Prelude-LML ses règles essayent de correspondre des données dans les fichiers de logs au lieu des paquets réseau.
Prelude-LML a deux modes de fonctionnement principaux : Monitoring des fichiers de logs Réception upd des messages Sys log
6
Application Programming Interface
7
Intrusion Detection exchange format Perl Compatible Regular Expression
8
19
Cette fonctionnalité fait de Prelude un outil extrêmement flexible et facile à mettre en œuvre dans n'i mporte quel réseau de production. Si un dispositif (machines distantes, routeurs, firewalls…) n'a pas la compatibilité natale avec Prelude, il peut être configuré pour enregistrer ses Logs vers un serveur Syslog que Prelude-LML pourra contrôler. Voici une liste presque exhaustive des formats reconnus par cette sonde : • Firewalls Checkpoint6 • Famille Cisco • Serveur SMTP exim7 • Firewall grSecurity8 • IPChains (Linux principalement) • IPFW (Familles *nix & Linux) • Firewalls utilisant IPSO (Checkpoint Firewall-1 & Nokia) • Netfilter / IPTables9 • Windows NT (via l’utilitaire NTSyslog) • Psionic PortSentry (Cisco)10 • ProFTPd • Serveur POP3 QPopper (Eudora)11 • Proxy HTTP Squid12 • SSHd • vPOPMail • Firewall Zyxel Zywall • Equipements Zyxel (modems, rou teurs, etc. . .)
Prelude-Correlator Prelude-Correlator rend possible la corrélation multiflux grâce à un langage de programmation puissant permettant l'écriture de règles de corrélation. Tout type d'alertes pouvant être corrélée, l'analyse des événements devient plus simple, plus rapide et plus pointue. La mise en évidence des scénarii d'attaque par Prelude-Correlator nous permet de pointer de façon performante les événements de sécurité importants ayant lieu sur nos infrastructures. Sa fonctionnalité est la suivante : Identification rapide des événements de sécurité importants permettant de donner une priorité d'intervention et de hiérarchiser les actions qui en découlent
Corrélation d'alertes en provenance de sondes hétérogènes déployées sur l'ensemble de l'infrastructure
Analyse en temps réel des événements reçus par le Manager Prelude
20
Prelude-Correlator permet de corréler, en temps réel, les multiples événements reçus par Prelude. Plusieurs alertes isolées, issues de sondes multiples, peuvent ainsi déclencher une seule alerte de corrélation si les événements sont liés. L'alerte de corrélation apparait alors dans l'interface Prewikka et met en évidence les informations que nous aurions choisi de pointer grâce aux règles de corrélation. La création de signature Prelude-Correlator est basée sur le puissant langage de programmation Python. Le moteur de corrélation intégré de Prelude est distribué avec des règles de corrélation pré-enregistrées mais il nous est possible de configurer n'importe quelle règle de corrélation répondant à nos besoins. Le Mail Reporting Plugin Le Mail Reporting Plugin envoie automatiquement des rapports d’événements par email à une liste de destinataires enregistrés. Le corps et le sujet de l'email généré peuvent être totalement configurés pour y faire apparaitre, par exemple, l'événement en entier ou seulement certaines parties.
Ce plugin permet aussi l'interrogation de la base de données afin de joindre aux événements entrants des événements anciens qui leur sont liés. En utilisant le Mail Reporting plugin en combinaison avec la fonctionnalité de filtrage du Manager Prelude, il est possible de générer des emails uniquement pour des événements correspondants à des critères spécifiques ou atteignant certains seuils. Prelude-PFLogger Prelude-PFlogger récupère les paquets journalisés par le firewall OpenBSD et envoie les alertes au Manager Prelude. 2.1.4 Architecture : Distribuée Le caractère distribué d'un IDS construit au-dessus de Prelude est un fait qu'il ne faut jamais perdre de vue lorsque l'on déploie des composants Prelude. A l'inverse d'un autre produit issu du libre plus célèbre, Prelude est bien une suite de composants et non un logiciel monolithique. Les composants Prelude - sondes et managers - ont été pensés et développés pour être autonomes (donc légers car dédiés à une tâche) et interactifs (les uns ne fonctionnent pas sans les autres). Ainsi les sondes - réseau comme local - n'effectuent que les opérations de surveillance et de génération des alertes. Les managers quant à eux prennent en charge la gestion des sondes et la journalisation des alertes. Dans certains cas, ils peuvent également ne prendre en charge que le routage des alertes vers d'autres managers (relay). Enfin, ils peuvent être utilisés pour déclencher des actions de contre-mesure au niveau d'un sous-réseau particulier tout en assurant la remontée des alertes vers les contrôleurs de niveau supérieur. 21
Cela se traduit en pratique par la possibilité d'installer autant de sondes et de contrôleurs que souhaité ou nécessaire, afin d'assurer la redondance des composants et/ou de s'adapter à la charge et la complexité d'un réseau, tout en ayant l'assurance d'obtenir une journalisation centralisée dans un format homogène. Sécurisée Le "modèle de sécurité" de Prelude est un des points forts du produit. Tous les composants sont construits au-dessus de la librairie libprelude qui peut être compilée avec le support SSL (utilisant les fonctions fournies par la suite openSSL). Ce support permet deux choses : - Une authentification "forte" des composants entre eux ; - Le chiffrement des communications entre composants. L'authentification des sondes par les managers est donc effectuée sur la base de certificats et le transfert des messages entre ces composants bénéficient du chiffrement. Cela signifie qu'il est possible de : - Déployer un IDS Prelude sur des sous-réseaux distants reliés entre eux par des canaux non sûrs (comme Internet) tout en conservant la possibilité de centraliser la journalisation des alertes ; - Ne pas avoir à installer un LAN dédié à la détection d'intrusions sur les réseaux concernés par l'IDS. Donc, pour être prise en compte par un manager, une sonde doit au préalable avoir été déclarée - enregistrée - auprès de celui-ci. Dans le cas de sondes et managers supportant SSL, cela se traduit par la génération d'une clef privée sur la sonde et d'un certificat sur le manager qui la prendra en compte. Fiable Si pour une raison ou une autre une sonde n'arrive plus à envoyer ses alertes à un manager auprès duquel elle est enregistrée, ces dernières sont conservées localement jusqu'à rétablissement de la connexion avec un manager. Cette fonctionnalité est fournie par la librairie libprelude, brique de base de tout composant Prelude. Extensible. A tous les niveaux ou presque il est possible d'étendre les capacités des composants Prelude à l'aide de module additionnel (plugin). Ces modules peuvent ainsi au : - Niveau des sondes : assurer le support de nouveaux protocoles ou d'applications ; - Niveau des managers : permettre un mode alternatif de journalisation. Il est également possible d'étendre les capacités et fonctionnalités de l'IDS en intégrant d'autres produits (exemple : des sondes plus performantes, des programmes plus spécifiques, etc…) toujours grâce à la librairie libprelude.
22
Exemple d’architecture possible :
Architecture simple :
Prelude est divisé en plusieurs composantes. Les capteurs sont responsables de la détection d'intrusion, et faire des rapports sur les événements d'une manière centralisée en utilisant une connexion TLS à un serveur ‘Prelude-manager '. Le serveur PreludeManager peut alors traiter les rapports des événements et les délivrer à un utilisateur d’un serveur données (base de données MySQL, base de données PostgreSQL, XML, tout format à condition qu'il y est un plugin).
La console Prelude peut alors être utilisée pour afficher les rapports d’événements. Voici un exemple simple de la façon dont les différents composants Prelude interagissent:
Figure 5 : Architecture simple
Architecture à relai:
Le relais est une fonction qui permet au programme de ‘Prelude-Manager’ de faire un Frowarding des événements reçus à un autre programme de ‘Prelude -Manager’. Dans l'exemple de la figure 6, «Branch A» de l'organisation a seulement l’accès aux événements générés par le capteur A, B et C . Toutefois, le «Security Center» peut voir les événements générés tant par ses propres capteurs (D, E et F), ainsi que les événements générés par les autres branches de l'organisation (comme A, B, C, etc.)
23
Figure 6 : Architecture à relai
Architecture Relai-Inversé :
Sur certains réseaux, il peut parfois être difficile ou gênant d’organiser des autorisations réseau afin qu'un programme peut se connecter à un serveur hors d'une zone donnée (par exemple, un pare-feu pourrait ne pas permettre aux machines de la DMZ 9 de se connecter en dehors de leur propre réseau). Dans ce cas précis, on peut configurer un ‘Prelude -Manager’ externe pour se connecter à un autre ‘Prelude -Manager’ interne situé à l'intérieur du réseau DMZ, et à lire les év énements émis par elle.
Figure 7 : Architecture à relai inversé
9
Zone démilitarisée (Demilitarized Zone)
24
2.2 Format standard Les deux principales propositions de standards allant dans le sens d’une uniformisation des échanges de messages liés à la sécurité sont le CIDF 10 et l’IDMEF11.
2.2.1CIDF Le CIDF, pour Common Intrusion Detection Framework a été une tentative du US governement’s Defense Advanced Research Project (DARPA) pour développer un langage (Protocole & format de messages) d’échange entre IDS e t manager pour leur utilisation interne en premier lieu. Cette proposition de standard a été jugée très lourde et peu utilisable par les développeurs de solutions IDS et n’a été que très rarement util isée dans des applications concrètes. Toutefois, une partie du concept et des bons points de ce langage ont été réutilisés dans IDMEF. 2.2.2 IDMEF Présentation L’Internet Engineering Task Force (IETF) est l’organis me responsable du développement de nouveaux standards Internet. Cet organisme a formé un groupe de travail, l’ Intrusion Detection exchange format Working Group (IDWG12), à qui incombe maintenant la création d’un format d’échange commun pour les alertes provenant d’IDS.
Ce groupe de travail a proposé IDMEF, un format de description des alertes basé sur XML, comme base d’échange entre les IDS et les managers ou tout autre équipement qui doit interagir avec ces derniers. Une grande attention a été portée aux besoins des applications qui analysent les alertes des IDS, afin qu’elles se voient fournir toutes les info rmations nécessaires à leur bon fonctionnement. Notons encore qu’IDMEF es t totalement indépendant du protocole de communication et que sa construction basée sur XML le rend ”compatible” avec les futurs firewalls applicatifs intelligents XML. Structure d’un message IDMEF
La structure des messages IDMEF est hiérarchique et peut s’apparenter à un modèle de classe en programmation orientée objet. La classe parente est IDMEF-Message et tous les messages IDMEF sont dérivés de cette dernière. Actuellement, il y a deux types (classes dérivées) de messages IDMEF : l’alerte ( Alert) et le Heartbeat . Nous pouvons voir les relations entre les principaux composants dans la figure 8. Cette représentation es t une version simplifiée du modèle complet, mais est suffisamment détaillée pour en comprendre le concept.
10
http://www.isi.edu/gost/cidf/
11 12
http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-10.txt http://www.ietf.org/html.charters/idwg-charter.html
25
Il est encore important de noter que ce modèle de données ne précise pas comment une alerte doit être classifiée ou identifiée. Par exemple, un port-scan peut être identifié par un analyseur comme attaque unique contre de multiples cibles, alors qu’un autre y verra une attaque multiple depuis une source unique. Toutefois, dès qu’un analyseur a déte rminé le type d’alerte qu’il souhaite envoyer, le modèle de données lui i ndique comment la formater. Contenu d’un message IDMEF Comme il existe un grand ”panorama” d’IDS (HIDS, NIDS, à détec tion basée sur les signatures ou heuristique). L’IDWG a fait grand travail afin qu’IDMEF puisse s’adapter à cette diversité, en focalisant les informations sur ”ce que l’IDS a détecté” plutôt que ”Comment il l’a détecté”. La figure 8 nous montre la construction hiérarchique en classe du message IDMEF.
Figure 8 : Structure d'un message IDMEF
26
La signification et l’utilité de ces principales propriétés : • La classe IDMEF-Message : Tous les messages IDMEF sont dérivés de cette classe. C’est le niveau supérieur du modèle IDMEF et de sa DTD 13 associée. Il y a actuellement deux types de messages IDMEF : l’alerte ( Alert ) et le Heartbeat . • La classe Alert : Généralement, chaque fois qu’un analyseur détecte un événement, il envoie une alerte à son (ses) manager(s). Suivan t le type d’analyseur, ce message peut correspondre à un événement unique ou à de multiples événements.Cette classe Alerte comporte aussi une propriété optionnelle ident , qui permet d’attribuer un identificateur à l’alerte. • La classe Classification : Elle peut être instanciée de manière unique ou multiple. Elle contient, si possible, un nom identifiant l’alerte d’après une liste standardisée (bugtraq5, cve6, etc. . .) ou un identifiant spécifique à l’implémentation, si ladite alerte n’est pas encore répertoriée. Cette propriété est intéressante, car elle permet à deux IDS n’utilisant pas le même algorithme de détection de ”rapporter” la même erreur à leur manager. • La classe Analyzer : Cette classe définit s’il s’agit d’un message d’alerte ou d’un heartbeat . Notons qu’il est impératif qu’une seule de ces classes ne soit instanciée dans un message d’alerte. • La classe AdditionalData : Cette classe peut être vide ou contenir des informations qui n’ont pas leur place ailleurs dans le message. On peut aussi i maginer utiliser cette classe pour fournir un dump complet du trafic qui a provoqué l’alerte. • La classe Heartbeat : Les analyseurs envoient périodiquement des messages heartbeat pour indiquer à leur manager qu’ils sont en fonction ( up and running). L’absence de réception de ces messages indique que la connexion réseau est défectueuse ou que l’analyseur a un problème. • La classe CreateTime : Une estampille temporelle y est placée, indiquant la date de création de l’alerte ou du heartbeat .
De par sa construction intelligente et sa gratuité d’utilisation, l’adoption d’IDMEF comme standard d’échange de messages semble incontournable. De plus, il permettrait à notre futur produit d’être compatible avec d’autres solutions.
2.3 Compatibilité
Prelude est un SIM interopérable avec tous les systèmes disponibles sur le marché. Quelle que soit notre configuration, inutile de remplacer nos équipements sécurité : Prelude s’adapte à l’infrastructure et non l’inverse.
13
Document Type Definition. C’est un fichier annexe ou une définition intégrée à tout document XML, afin de définir sa structure et de valider son contenu.
27
Lorsqu’on installe Prelude, deux solutions s'offrent à nous : Renvoyer les logs des solutions vers Prelude Connecter directement les solutions compatibles nativement avec Prelude .
Figure 9 : Tableau de compatibilité de Prelude
28
Chapitre 3 : Sondes et sources d’informations
29
3.1 Qualité indispensable
Garantir la sécurité et l’intégrité des transactions Un système de sécurité ne peut être considéré comme efficace s’il est lui -même vulnérable aux attaques et aux dénis de service. De plus, il est impératif de garantir l’authenticité et l’intégrité et l’intégrité des messages reçus des différentes sondes. Les trois notions clés ici sont confidentialité, intégrité et authentification (CIA).
Le protocole de choix pour ce travail est SSL en version 2.0, pour Secure Sockets Layers, que l’on pourrait traduire par couche de sockets sécurisée. C’est un procédé de sécuris ation des transactions effectuées via Internet mis au point par Netscape, en collaboration avec MasterCard, Bank of America, MCI et Silicon Graphics. Il repose sur un procédé de cryptographie par clef publique afin de garantir la sécurité de la transmission de données sur Internet ou sur un LAN. Le système SSL est indépendant du protocole utilisé, ce qui signifie qu’il peut aussi bien sécuriser des transactions faites sur le Web par le protocole HTTP que des connexions via le protocole FTP, POP ou autres. En effet, SSL agit telle une couche supplémentaire, permettant d’assurer la sécurité des données, située entre la couche application et la couche transport.(fig10).
Figure 10 : Modèle avec la couche SSH
Format des messages Vu que le choix s’est porté sur une plateforme de base Prelude et aussi un choix d’adopter un format de message standard, compatible avec de futures applications, il est clair que l’utilisation d’IDMEF est incontournable. On fe ra appel aux fonctions d’authentification et de cryptage fournies par LibPrelude pour garantir la sécurité des échanges.
Les IDS Les IDS14 est un mécanisme destiné à repérer des activités anormales ou suspectes sur la cible analysée (un réseau ou un hôte). Il permet ainsi d'avoir une connaissance sur les tentatives réussies comme échouées des intrusions.
14
Intrusion Detection System/système de détection d'intrusion
30
Il existe trois grandes familles distinctes d’IDS :
Les NIDS (Network Based Intrusion Detection System), qui surveillent l'état de la sécurité au niveau du réseau. Les HIDS (HostBased Intrusion Detection System), qui surveillent l'état de la sécurité au niveau des hôtes. Les HbIDS ( IDS hybrides), qui utilisent les NIDS et HIDS pour avoir des alertes plus pertinentes. NIDS
Figure 11 : Fonctionnement des NIDS
Un NIDS se découpe en trois grandes parties : La capture, les signatures et les alertes.
Capture :
La capture sert à la récupération de trafic réseau. En général cela se fait en temps réel, bien que certains NIDS permettent l'analyse de trafic capturé précédemment. La plupart des NIDS utilisent la bibliothèque standard de capture de paquet libpcap. La bibliothèque de capture de paquets Packet Capture Library est portée sur quasiment toutes les plateformes, ce qui permet en général aux IDS réseau de suivre. Le fonctionnement de la capture d'un NIDS est donc en général fortement lié à cette libpcap. Son mode de fonctionnement est de copier (sous Linux) tout paquet arrivant au niveau de la couche liaison de données du système d'exploitation. Une fois ce paquet copié, il lui est appliqué un filtre BPF (Berkley Packet Filter), correspondant à l'affinage de ce que l'IDS cherche à récupérer comme information.
31
Signatures
Les bibliothèques de signatures (approche par scénario) rendent la démarche d'analyse similaire à celle des antivirus quand ceux-ci s'appuient sur des signatures d'attaques. Ainsi, le NIDS est efficace s'il connaît l'attaque, mais inefficace dans le cas contraire. Les outils commerciaux ou libres ont évolué pour proposer une personnalisation de la signature afin de faire face à des attaques dont on ne connaît qu'une partie des éléments. Les outils à base de signatures requièrent des mises à jour très régulières. Les NIDS ont pour avantage d'être des systèmes temps réel et ont la possibilité de découvrir des attaques ciblant plusieurs machines à la fois. Leurs inconvénients sont le taux élevé de faux positifs qu'ils génèrent, le fait que les signatures aient toujours du retard sur les attaques de type 0day et qu'ils peuvent être la cible d'une attaque.
Alertes
Les alertes sont généralement stockées dans le syslog. Cependant il existe une norme qui permet d'en formaliser le contenu, afin de permettre à différents éléments de sécurité d'interopérer. Ce format s'appelle IDMEF dans la RFC4765. IDMEF est popularisé par le projet Prelude, qui offre une infrastructure permettant aux IDS de ne pas avoir à s'occuper de l'envoi des alertes. Cela permet aux IDS de n'avoir qu'à décrire les informations qu'il connaît et Prelude se charge de les stocker pour permettre une visualisation compréhensible.
Pattern matching15
Le pattern matching est ce qui permet à un NIDS de trouver le plus rapidement possible les informations dans un paquet réseau. Dans le cas d'un NIDS, le pattern matching est souvent le nœud d'étranglement. Pouvant consommer plus de quatre-vingt pourcent de temps de calcul.
Analyse
Le moteur d'analyse met ces éléments de relation en employant plusieurs techniques : la refragmentation, la dissection protocolaire ou encore l'analyse comportementale.
La refragmentation
Les paquets dépassant une certaine taille (qui en général est de 1 500 octets) sont fragmentés. La fragmentation de l'en-tête de la couche transport étant aussi possible, cela
15
La recherche de motif
32
rendait les NIDS vulnérables aux attaques de Stick et de Snot 16 car les paquets fragmentés n'étaient pas analysés. Les NIDS ont le devoir de refragmenter les paquets avant analyse, afin de ne pas manquer une attaque. Il s'agit d'une opération relativement complexe, étant donné que chaque hôte de destination ne refragmente pas de la même façon, se lon le système d'exploitation sur lequel l'attaque est visée. Il s'agit encore d'une technique d'évasion utilisable aujourd'hui car les NIDS ne sont pas forcément configurés correctement pour gérer un cas précis.
La dissection protocolaire
La dissection permet de comprendre un protocole donné, de le décoder pour l'analyser. Il s'agit de la partie la plus sensible des NIDS car c'est elle qui est le plus grand vecteur d'attaques. Cependant, la dissection est essentielle sur certains protocoles, comme RPC, afin de pouvoir détecter des attaques qui seraient invisibles sans cette indispensable dissection. Cette étape permet aussi de récupérer un champ précis d'un protocole applicatif ce qui peut simplifier l'écriture de signatures. HIDS Les HIDS, pour Host based IDS, signifiant "Système de détection d'intrusion machine" sont des IDS dédiés à un matériel ou système d'exploitation. Contrairement a un NIDS, le HIDS récupère les informations qui lui sont données par le matériel ou le système d'exploitation. Il y a pour cela plusieurs approches : signatures, comportement (statistiques) ou délimitation du périmètre avec un système d'ACL. Un HIDS se comporte comme un daemon ou un service standard sur un système hôte qui détecte une activité suspecte en s’appuyant sur une norme. Si les activités s’éloignent de la norme, une alerte est g énérée. La machine peut être surveillée sur plusieurs points :
Activité de la machine : nombre et listes de processus ainsi que d'utilisateurs, ressources consommées, ... Activité de l'utilisateur : horaires et durée des connexions, commandes utilisées, messages envoyés, programmes activés, dépassement du périmètre défini... Activité malicieuse d'un ver, virus ou cheval de Troie
16
Techniques utilisées pour tromper le moteur de l’IDS en fragmentant l’attaque dans plusieurs paquets, ainsi la reconstruction se fait après qu’ils aient traversés l’IDS
33
Le HIDS a pour avantage de n'avoir que peu de faux positifs, permettant d'avoir des alertes pertinentes. Quant à ses inconvénients il faut configurer un HIDS par poste et cela demande une configuration de chaque système.
IDS hybride
Figure 12 : Fonctionnement d'un HybIDS
Les IDS hybrides sont basés sur une architecture distribuée, où chaque composant unifie son format d'envoi d'alerte (typiquement IDMEF) permettant à des composants divers de communiquer et d'extraire des alertes plus pertinentes. Les avantages des IDS hybrides sont multiples :
Moins de faux positifs Meilleure corrélation Possibilité de réaction sur les analyseurs Les Honey Pot
Un Honeypot (littéralement pot de miel) c’ est une méthode utilisée dans le domaine de la détection d'intrusion se basant un serveur ou programme volontairement vulnérable, destiné à attirer et à piéger les pirates. Situé devant ou derrière un pare-feu, cet appât laisse croire aux intrus qu'ils se trouvent sur une machine de production « normale » alors qu'ils évoluent sur un leurre. On aura alors tout loisir d'observer leur manière de faire et d'enregistrer leurs méthodes d'attaques. Les honeypots sont des systèmes de sécurité qui n’ont aucune valeur de production. Dès lors, aucun utilisateur ni aucune autre ressource ne devrait en principe avoir à communiquer avec lui. L’activité ou le trafic attendu sur le honeypot étant nul à la base, on en déduit alors que toute activité enregistrée par cette ressource est suspecte par nature. Ainsi, tout trafic, tout flux de données envoyé à un honeypot est probablement un test, 34
un scan ou une attaque. Tout trafic initié par un honeypot doit être interprété comme une probable compromission du système et signifie que l’attaquant est en train d’effectuer des connexions par rebond. Généralement, un honeypot se comporte telle une boîte noire, enregistrant passivement toute l’activité et tout le trafic qui passe par lui. Il faut savoir que le trafic capté par les honeypots est à la fois réduit (effet microscope) et suspect par nature. Les fichiers des enregistrements d’évènements (fichiers de logs) sont donc peu volumineux et il est plus aisé d’identifier une activité malveillante. En fonction de la nature des données collectées, on pourra ainsi retracer précisément les flux échangés:
provenance, activité, date, durée, volume ... et parfois même, le contenu des données échangées (keystrokes, messages IRC par exemple).
Il existe différentes catégories de honeypot selon le niveau d’interaction que l’on so uhaite offrir aux attaquants : – Les honeypots de très faible interaction se contentent de simuler certains services notoirement connus tels que l’activité apparente d’un serveur web, d’un serveur de messagerie, d’un serveur de transfert de fichier, etc. L’objectif de ce type de honeypot est par exemple d’identifier les adresses sources de pirates et aus si et surtout les premières commandes de base. Ce type de honeypot n’apporte guère d’information précise sur les procédés et les méthodes d’attaque. – Les honeypots de moyenne interactivité fournissent un ensemble de services élaborés à l’attaquant. Ce type de honeypot est souvent déployé sur un poste hôte. – Les honeypots de très grande interactivité fournissent des systèmes d’exploitation ou un réseau tout entier à l’attaquant. Ce dernier type de honeypot est souvent dédié à la recherche comportementale et psychologique pour le profilage des pirates.
Les Firewall
Un pare-feu/firewall, est un système logiciel, reposant parfois sur un matériel réseau dédié (appliance) , constituant un intermédiaire entre le réseau local (ou la machine locale) et un ou plusieurs réseaux externes, qui a pour fonction de faire respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types de communication autorisés ou interdits . Pour cela, le pare-feu analyse les informations contenues dans les couches 3, 4 et 7 du modèle OSI et contrôle ainsi les informations en transit. C’est est un système permettant de protéger un ordinateur ou un réseau d'ordinateurs des intrusions provenant d'un réseau tiers (notamment internet), il s'agit ainsi
35
d'une passerelle filtrante comportant au minimum les interfaces réseau ; une interface pour le réseau à protéger (réseau interne) et une interface pour le réseau externe.
Figure 13 : Fonctionnement d'un pare-feu
Il a pour principale tâche de contrôler le trafic entre différentes zones de confiance, en filtrant les flux de données qui y transitent. Généralement, les zones de confiance i ncluent Internet (une zone dont la confiance est nulle), et au moins un réseau interne (une zone dont la confiance est plus importante.) Le but ultime est de fournir une connectivité contrôlée et maîtrisée entre des zones de différents niveaux de confiance, grâce à l'application de la politique de sécurité et d'un modèle de connexion basé sur le principe du moindre privilège. Le filtrage se fait selon divers critères. Les plus courants sont : l'origine ou la destination des paquets (adresse IP, ports TCP ou UDP, interface réseau, etc.) ; – les options contenues dans les données (fragmentation, validité, etc.) ; – les données elles-mêmes (taille, correspondance à un motif, etc.) ; – les utilisateurs pour les plus récents. Un pare-feu fait souvent office de routeur et permet ainsi d'isoler le réseau en plusieurs zones de sécurité appelées zones démilitarisées ou DMZ. Ces zones sont séparées suivant le niveau de confiance qu'on leur porte. –
36
Un système pare-feu contient un ensemble de règles prédéfinies permettant : – – –
D'autoriser la connexion (allow) ; De bloquer la connexion (deny) ; De rejeter la demande de connexion sans avertir l'émetteur (drop).
L'ensemble de ces règles permet de mettre en œuvre une méthode de filtrage dépendant de la politique de sécurité adoptée par l'entité. On distingue habituellement deux types de politiques de sécurité permettant : – –
soit d'autoriser uniquement les communications ayant été explicitement autorisées soit d'empêcher les échanges qui ont été explicitement interdits. Principales techniques de détection
Le filtrage de paquets
Les premiers pare-feux étaient les routeurs eux-mêmes. Ceux-ci s’appuyaient donc sur du filtrage de paquets IP, à l’aide d’une analyse des entêtes des datagrammes en transit. Les pare-feux peuvent effectuer du filtrage, sur la couche 3 du modèle OSI, basé sur les adresses IP (source ou destination), on parle de filtrage par adresse (address filtering), ou peuvent effectuer du filtrage sur les protocoles de transmission, on parle alors de filtrage par protocole (protocol filtering). Enfin le pare-feu peut être configuré pour bloquer tout le trafic arrivant sur certains ports afin d’empêcher des postes extérieurs d’accéder à des services non indispensables de l’extérieur. Un firewall possédant pl usieurs interfaces, dont une DMZ, peut affiner ces règles de blocage pour les réorienter vers l’interface réseau adéquate (ex. : le port 80 vers le serveur WEB de la DMZ).
Le filtrage dynamique
Il existe des services comme le FTP qui utilisent un port statique pour la connexion, puis des ports dynamiques (au-dessus des ports réservés pour les services standards <1024) pendant les transferts. Il existe donc un système de filtrage dynamique de paquets (stateful inspection) basé sur l'inspection des couches 3 et 4 du modèle OSI. Il permet d'effectuer un suivi des transactions entre le client et le serveur et donc d'assurer la bonne circulation des données de la session en cours. Un paquet q ui n’appartiendrait pas à une session encore a ctive sera soumis au filtrage prédéfini. Le filtrage dynamique est plus performant que le filtrage de paquets standard mais ne protège pas contre les failles applicatives (failles liées aux logiciels).
37
Le filtrage applicatif
Le dernier type de filtrage utilisé est au niveau applicatif (couche 7 du modèle OSI). Il permet de contrôler les communications au niveau des applications (analyse application par application). Ce filtrage nécessite une connaissance parfaite de la structure des données échangées par les applications. Un firewall effectuant un filtrage applicatif est appelé passerelle applicative car il permet de relayer des informations entre deux réseaux en effectuant un filtrage fin au niveau du contenu des paquets échangés. Ce type de filtrage est très performant et assure une bonne protection du réseau mais nécessite une grande puissance de calcul au niveau du firewall. Sur des réseaux de taille importante, l’utilisation d’un tel firewall est diffic ile à mettre en place et ralentit les communications. Certaines applications propriétaires ou non standards ne permettent pas la mise en place de ce type de firewalls. Les pare-feu récents embarquent de plus en plus de fonctionnalités, parmi lesquelles on peut citer : – – – – – – – – – – – – – – – –
Filtrage sur adresses IP/Protocole, Inspection stateful et applicative, Intelligence artificielle pour détecter le trafic anormal, Filtrage applicatif HTTP (restriction des URL accessibles), Courriel (Anti-pourriel) Logiciel antivirus, anti-logiciel malveillant NAT17, Tunnels IPsec, PPTP, L2TP, Identification des connexions, Serveurs de protocoles de connexion (Telnet, SSH), de protocoles de transfert de fichier, Clients de protocoles de transfert de fichier (TFTP), Serveur Web pour offrir une interface de configuration agréable, Serveur mandataire ( proxy ), Système de détection d'intrusion ( IDS ) Système de prévention d'intrusion ( IPS )
17
Traduction d'adresse réseau/ Network Address Translation
38
La corrélation
SEC SEC (Simple Event Correlator) est un programme écrit en PERL qui permet de surveiller des fichiers de logs pour y détecter des motifs. Il est aussi utilisé pour corréler certains évènements afin de diminuer le nombre de fausses alertes. SEC est un logiciel multiplateforme de corrélations d'évènements Open Source ,il accepte les entrées d'un fichier, d'un tube nommé (pipe) ou de l'entrée standard et peut donc être employer comme couche de corrélation par tous programmes écrivant leurs sorties d'évènements dans un flux de fichier. La configuration de SEC est stockée comme règles dans des fichiers texte, chaque règle décrivant l'évènement sur lequel réagir, l'action à mener. Les expressions régulières peuvent être utilisées pour définir les conditions de l'évènement. SEC peut lui-même produire des évènements en sortie en exécutant des scripts shell ou des programmes externes (snmptrap, courrier électronique, filtrage ip) et/ou en écrivant des messages vers des tubes ou des fichiers. SEC est utilisé dans des domaines aussi variés que la gestion des réseaux, le monitoring système, la sécurité des données, la détection d'intrusions, la surveillance et l'analyse de fichiers journaux, etc. SEC est utilisé ou intégré dans des produits aussi différents que HP OpenView NNM, CiscoWorks, BMC Patrol, Nagios, SNMPTT, Snort IDS, Prelude IDS, etc. Les types de règles de corrélation suivants sont implémentées dans SEC : Single : Détection d’un motif et exécution d’action parmi celles supportées par SEC. SingleWithScript : Détection d’un motif et exécution d’action parmi celle supportée par SEC en fonction du code de sortie d'un script ou programme externe. SingleWithSuppress : Détection d’un motif et exécution d’action parmi celles supportées par SEC, mais ignore les motifs détectés suivants pendant « t » secondes suivantes. Pair : Détection d’un motif et exécution d’action parmi celles supportées par SEC, ignore les motifs détectés suivants jusqu'à la détection d'un motif différent. Exécute une action à l'arrivée du deuxième motif. PairWithWindow : Détection d’un motif et attente pendant « t » sec ondes d’un motif différent. Si ce deuxième motif n'est pas détecté au bout de ce temps, exéc ution d’action. Si ce deuxième motif est détecté dans le laps de temps, exécute une autre action. SingleWithThreshold : Calcul du nombre de motifs semblables pendant « t » secondes et si un certain seuil est dépassé, exécution d’action et ignore les nouveaux motifs pendant le reste du temps. La fenêtre de temps précisée avec « t » est coulissante. SingleWith2Thresholds : La même règle que précédemment combiné à deux fenêtres de temps. Suppress : Suppression de motif détecté. Calendar : Exécution d’action à une certaine date et heure.
39
Prelude-IDS et Snort
Projet Ce sont tous les deux des outils libres. Parmi les avantages de Snort sont sa popularité et sa disponibilité sur de nombreuses plateformes. Prelude-IDS se restreint sur les plateformes POSIX18 alors qu’on peut retrouver Snort sur Windows. A cela s’ajoute l’importance de la base de données des signatures d’attaque de Snort, pour expliquer sa plus grande popularité. Mais Prelude-IDS est de plus en plus connu dans le monde des professionnels de la sécurité. Une différence importante cependant, au désavantage de Snort est sa nature , il est NIDS pur alors que Prelude-IDS intègre des fonctionnalités NIDS et HIDS. Moteur d’analyse et banque de signatures
Les deux font une analyse par recherche de similitudes avec un scénario préalablement définis. Le mode de fonctionnement est alors similaire. Autant pour Prelude -IDS que pour Snort, les solutions sont stables. Notons que même en intégrant les alertes de Snort, Prelude-IDS relève une quantité plus importante d’alertes. Prelude -NIDS archive aussi les payloads. Prelude-IDS a l’avantage d’être très modulaire de par son architecture client -serveur. Un manager peut gérer plusieurs sondes, et une sonde peut envoyer ses alertes à plusieurs managers. La remontée d’alertes
En utilisant ces outils, on se rend compte du fait que Prelude-IDS remonte un nombre plus important d’alertes que Snort. Là où Snort remonte 30 alertes de 2 types différents, Prelude-IDS remonte parfois 2000 alertes de 3 types différents. Prelude à la capacité de détection d’un plus grand nombre d’attaque. Cela est dû à l’utilisation des mêmes sign atures que Snort en plus des siennes. Intégration d’outils externes
La grande force de Prelude-IDS est de pouvoir intégrer les fonctionnalités d’autres outils de sécurité de référence. On peut, par exemple, utiliser Honeyd comme une sonde, envoyer les résultats vers le manager qui les intègrera ensuite dans la base de donées. La banque de scénario de Snort peut aussi être récupérée par Prelude-NIDS et ajoutée aux règles de Prelude-IDS. Ainsi, le nombre important de signatures reconnues par Snort (et qui participe à sa popularité) bénéficie à Prelude -IDS.
18
Portable Operating System for Computer Environment. C'est une série de standards IEEE pour Unix
40
3.2 Intégration de sources d’information externes
Firewall *BSD Packet Filter
Packet Filter (que nous appellerons désormais PF) est le système utilisé par OpenBSD pour filtrer le trafic TCP/IP et effectuer des opérations de Traduction d'Adresses IP ("NAT"). PF est aussi capable de normaliser, de conditionner le trafic TCP/IP, et de fournir des services de contrôle de bande passante et gestion des priorités des paquets. PF fait partie du noyau GENERIC d'OpenBSD depuis la version 3.0. Les précédentes versions d'OpenBSD utilisaient un ensemble logiciel pare- feu/NAT différent qui n'est plus supporté.
PFLogger est un composant utilisé pour rassembler les Logs du firewall PF d'OpenBSD. Paquet Filter (PF) est un système de filtrage pour le trafic TCP/IP d'OpenBSD et aussi la Traduction d'Adresse de Réseau NAT. Quand PFlogger est installé le plugin PreludePFlogger écoute les paquets journalisés et envoie les alertes à Prelude-Manager. Firewall Personnel Là encore, l’incorporation de différents firewalls personnels est très facilitée grâce à la structure fournie par Prelude. Ainsi, n’importe quel applicatif ou matériel de filtrage ut ilisant la journalisation NT, Syslog ou des fichiers locaux pour inscrire ses alertes est compatible avec Prelude. La seule limitation est l’existence d’une expression rég ulière Perl dans le fichier de configuration de Prelude-LML qui permet à ce dernier de parser correctement les entrées. Dans la négative, il est toujours possible d’y ajouter ses propres expressions.
IDS : Snort
SNORT est un NIDS (Network Intrusion Detection System), une création de Martin Roesh, cette solution s’est imposée dans le marché pour être parmi les IDS les plus utilisés, possédant aussi une communauté importante contribuant à son succès. Actuellement SNORT appartient à SourceFire. SNORT est capable d’effectuer en temps réel une analyse de trafic et de logger les p aquets sur un réseau IP, aussi qu’une analyse protocolaire et le pattern matching de co ntenu. Son fonctionnement en ligne de commande le laisse riche en son utilisation avec de nombreuse option en main. Les fonctionnalités de SNORT permettent de faire un ‘SNI FFING’ de réseau, effectuant une journalisation ainsi donc pour détecter d’éventuels i ntrusion. Son moteur de détection utilise une architecture modulaire de plug-in, il a aussi une grande capacité modulaire d’alertes en temps réel, incorporant des mécanismes 41
d’alertes pour SYSLog, des fichiers spécifié pour l’utilisateur , une socket UNIX, ou des messages WINPOPUP à des clients WINDOWS en utilisant smbClient de SAMBA. Sans oublier qu’il peut faire de la journalisation sous différentes format, un for mat binaire tcpdump ou aussi le format ASCII décodé de SNORT vers un ensemble hiérarchique de réponse qui sont nommés d’après l’adresse IP du système « étranger » .
SNORT utilise un langage de règle flexible lui permettant de soit collecter ou de laisser passer le trafic réseau. Il peut être considérer comme NIPS 19 via SNORT-Inline , interdisant ainsi tout trafic provenant de l’ adresse IP de l’attaquant ou bien toute une classe d’adresse IP.
Bien que l’utilisation de Snort en parallèle avec Pr elude-NIDS soit redondante (ils sont issus de sources très communes et emploient une base de signatures identique), il suffit de patcher les sources de Snort à l’aide des correctifs mis à disposition sur le site de Prelude-IDS pour que ce dernier fasse partie intégrante de la plateforme.
OSSEC Ossec (http://www.ossec.net) est une application de détection d’intrusion, et plus préc isément un HIDS (Host Intrusion Detection System). Il permet de surveil ler l’intégrité des fichiers systèmes, aussi bien sur des postes Linux que Windows.
De plus, Ossec détecte également des attaques de pirates comme les rootkits, les scans de ports, et analyse les logs du système, des applications et des services. Le logiciel propose également un système de réponses actives, c’est -à-dire d’actions à réaliser en cas d’attaque, comme par exemple changer les paramètres d’un parefeu. Tout comme Snort, il dispose de nombreuses règles lui offrant un large panel de détection d’atta ques, de problèmes sur le poste sur lequel il est installé. Ossec peut également fonctionner selon le modèle client/serveur, avec un serveur dédié Ossec, et sur tous les postes clients (serveurs) à surveiller une installation du logiciel client, qui est alors chargé d’envoyer les évènements, les alertes au serveur. Ossec fonctionne essentiellement sur Linux, mais il peut surveiller également des postes Windows grâce à une application cliente spécialement développée pour, mais pour la version serveur, seul un système d’exploitation Linux est supporté.
19
Network Intrusion Prevention System
42
Honey Pot : HoneyD
HoneyD est un projet pot de miel Open Source sous licence GNU GPL développer par Niles Provos ingénieur à Google. C’est un « Deamon » permettant de déployer des machines virtuelles sur un réseau utilisant des adresses IP non attribuées sur le réseau, ainsi donc pour détecter toute activité frauduleuse étant donné que personne n’est sensé s’y connecté voulant dire ainsi que toute tentative de connexion à une adresse IP définit « virtuellement » peut être interpréter comme non autorisée et suspecte. Son but est aussi de détecter des attaques que de découvrir de nouvelles attaques. Toutes données entrantes et sortantes de ce Honey Pot 20 est en vue d’être analyser. HoneyD regroupe deux modes de fonctionnement distincts : - Capable de simuler, sur un réseau, la présence de machines de tous types (jusqu’à 65536 machines à la fois ; PC et équipements de routages). Ces hôtes peuvent être configurés pour qu'ils paraissent fonctionner sous certains systèmes d'exploitations, et ce grâce à des Template ; afin d'accroitre l'effet de réalité, ces machines peuvent également virtuellement faire tourner certains services. Ceux-ci ne sont en fait que des scripts (développés en perl, python, ou encore en shell-script) qui simulent leur fonctionnement. - Capable de simuler un réseau entier. Créant alors un "honeynet", il est possible de configurer ce que l'on appellera des "routing topologies", véritables interconnexions virtuelles de routeurs, permettant d'obtenir de faux réseaux d'une complexité des plus élevées. HoneyD peut être intégré dans l’architecture Prelude-IDS en tant que sonde réseau et ainsi on peut disposer d’un ”Pot de miel” afin d’obtenir de nouvelles informations sur ceux qui attaquent le réseau. Les alertes sont visibles à partir du frontend de PreludeIDS. Pour cela, il suffit d’appliquer le plugin Prelude-lml sur la sonde HoneyD pourra être manipulée comme n’importe quelle autre sonde Prelude -IDS. Tout cela est expliqué en détail dans le chapitre à venir.
20
Pot de miel
43
Chapitre 4 : Etude et realisation de la maquette de test
44
Pour des raisons de clarté, on a séparé la partie technique (fonctionnement interne de la chose) de la partie utilisation (celle visible po ur l’utilisateur en final).
Partie technique Dans cette section, nous allons énumérer tous les points techniques que devra respecter notre application. Cette liste nous permettra de faire un choix éclairé sur l’architecture à adopter : Architecture client-serveur. La partie serveur tournera sur une plateforme Linux. Ce choix est obligatoire étant donné que nous avons utilisé une maquette de communication basé sur la solution Prelude et que, pour des raisons de sécurité, de disponibilité et de rapidité, le manager Prelude se trouve sur la même machine physique que le SGBD. ”Support” de l’authentification et du cryptage des communications entre client(s) et serveur ; chose qui indispensable et disponible au niveau de notre solution choisie .
Partie utilisation Cette partie recense les concepts obligatoires dont doit faire preuve Prelude, ceci en faisant abstraction à : Le frontend doit offrir une prise en main simplifiée et être conviviale pour les utilisateurs. Le fonctionnement analytique interne ne doit présenter que les événements sécuritaires ou les comportements qui méritent un réel suivi (filtrage). Un ‘real time ‘ surveillance via un serveur NTP .
4.1 Architecture
Afin de respecter les contraintes de séparation du traitement des données de la prése ntation, on a opté pour le modèle 3 tiers. Ce choix apporte son lot d’av antages :
Indépendance entre la partie traitant les informations (serveur) de celle les présentant (client). Etant donné que tous les traitements s’effectuent dès lors sur le serveur, la rapidité globale de la solution ne dépend plus de la puissance de ca lcul ou du traitement du client.
Stabilité et sécurité assurées. En effet, en installant la partie serveur en un endroit unique (DMZ privé), et aussi de préférence sur la même machine physique que la source des informations (la base de données) ; ainsi d onc il n’y aura pas une surcharge de bande passante et il devient facile de gérer les accès et d’effectuer d’éventuelles mises à jour sur le logiciel.
45
4.2 Fonctionnalités
On va maintenant reprendre les points citer précédemment afin détailler la liste des fonctionnalités qui peuvent ou vont être implantées dans notre maquette de test afin de pouvoir identifier les réelles menaces sécuritaire s de la masse d’alertes stockées dans la base de données. Le but principal du projet repose sur le déploiement d’une solution SIEM qui fera la ce ntralisation et la corrélation en premier degré, mais afin de pouvoir voir les résultats et l’efficacité de la solution, passer par une maquette de test est indispensable. La maquette de teste s’est faite via une virtualisation sur VMware Workstation 7 reposant sur la ‘team’ afin de simuler toute une architecture de production pour cette solution. Le résultat attendu repose en premier lieu sur la compatibilité et l’adaptabilité, d’où vient mon choix des différentes solutions ainsi que la diversification au niveau des OS.
4.3 Outils et sondes utilisées
Packet Filter
Le choix de ce firewall était plutôt simple reposant sur la simplicité des règles par rapport aux autres firewalls open source, et aussi sur la sécurité disponible au niveau de FreeBSD et ses performances fortement prouvée. HoneyD L’atout majeur d’un honeyPot est la leurre qu’il fait pour les attaquants, le choix de HoneyD , un honeyPot à faible interaction ,c’est pour qu’il n’y aura pas un contrôle de la machine et d’en faire un rebond sur le réseau étant donnée qu’un honeyPot c’est une machine vulnérable intentionnellement . Son placement dans le LAN est juste pour avoir une sonde d’information de plus simulant tout un réseau factice composé de poste Wi ndows et d’imprimantes au cas d’une intrusion ou une brèche au niveau du Firewall.
Ossec
Pour s’assurer le bon fonctionnement des postes informatiques à surveiller, l’installation d’un logiciel comme Ossec, un HIDS, est très utile. En effet, Ossec va nous permettre d’avoir le contrôle sur notre DMZ publique , afin d’assurer tout d’abord l’intégrité des fichiers critique au niveau du serveur ainsi que tout action frauduleuse au niveau ce serveur ,pour enfin nous en générer des alertes.
46
Snort On a opter pour l’installation de SNORT, un NIDS permettant le contrôle sur le LAN afin de détecter le trafic suspicieux, comme par exemple le scan de ports, les rootkits, les attaques brute force, mais bien sûr selon des règles bien définies pour la situation .Ainsi donc tout trafic suspect capté est envoyé au manager pour en résulter une alerte. On s’est basé sur des règles personnelle crée spécifiquement pour la maquette de teste et les intrusions subites.
Prelude-Manager Dans l’optique de pouvoir superviser l’ensemble des évènements générés par ces appl icatifs, il faut pouvoir les centraliser, rendant de cette manière l’administration et la v isualisation des alertes plus rapides. C’est ce que permet la solution Prelude, un IDS, qui utilise des applications tels qu’Ossec et Snort et autre multitude de nœud comme des sondes.
Ainsi, après avoir intégré ces applications à Prelude-Manager, leurs alertes sont transmises et donc centralisés au sein d’un seul logiciel. De plus, cette solution permet de normaliser toutes les alertes au format IDMEF et les stocke dans la base de données. Prelude-LML
Cette sonde et aussi un plugin de la solution Prelude , est un atout clé pour les sondes qui ne sont pas nativement compatible avec Prelude. Ainsi donc une configuration au niveau de ce module pour aider à la remonté des alertes au niveau de notre manager. La corrélation
Prelude-Correlator Afin de corréler des alertes, Prelude peut intégrer également un corrélateur, à savoir Prelude-Correlator, un module ou plugin de l’application, donc parfaitement et nativement compatible. Ce dernier permet ainsi de relier certaines alertes entre elles, spécifiques à une attaque par exemple, selon des règles de corrélation définies. Il intercepte alors les alertes et les corrèle (ou pas), avant de les retransmettre au Prelude. SEC Cette solution de corrélation sera int egré avec SNORT afin d’avoir une corrélation local au niveau de notre NIDS et assurer une meilleur corrélation dans Prelude . Ce logiciel de corrélation permet de définir un scénario de corrélation d’événements extraits de fichiers syslog de sortie de SNORT. Dans un premier temps, l’idée de base est d’avoir un IPS au niveau de notre NIDS, mais dû à des problèmes d’installation et de compatibilité. Mais grâce à l’étude de l’association de SEC avec notre NIDS, il nous a été possible d’entrevoir les capacités d’analyse qu’offre cet outil. Son utilisation pourrait jouer le rôle 47
d’un IPS intelligent, reposant sur la partie de corrélation qui en résulte une action offrant ainsi un système d’alerte rapide en cas de gros problèmes.
NTP Le protocole NTP 21 permet la synchronisation des horloges systèmes des machines. Son fonctionnement s’appuie sur une hiérarchie d’horloges synchronisées. Il est donc indi spensable de lui indiquer un serveur sur lequel il pourra s’appuyer ou bien juste d’une horloge en local qui nous servira de référence. Ensuite, chaque station synchronisée à l’aide de NTP pourrait jouer le rôle de serveur pour d’autres stations en demande de synchronisation. NTP nous permettra d’obtenir un timestamp synchronisée de toutes les alertes pr ésentes dans la base de données de Prelude Manager. Il est alors indispensable d’installer un applicatif s’occupant de la gestion de la synchronisation de l’heure sur toutes les m achines générant des alertes. L’utilité majeur de ce serveur ou bien juste de la sync hronisation des horloges est en premier degré le real time des alertes, afin d’avoir le temps d’intervenir ou de changer notre politique de sécurité. Prewikka ET enfin pour la visualisation des évènements stockés dans la base de données, nous allons intégrer dans Prelude-Manager son interface officiel, qui affichera en détail les alertes reçues par le corrélateur et les diverses sondes et nœuds réseaux. Cette interface sera dans la même machine comme cité précédemment que la base de données.
4.4 Stockage des informations dans une BD
Le manager Prelude dispose d’un plugin de sortie LibPreludeDB permettant de stocker les alertes dans une base de données MySQL.
4.5 Schéma de la structure de base adoptée
Le schéma suivant (fig.14) représente bien la configuration proposé pour maquette de test de la plateforme SIEM . Il est important de noter que le serveur MySQL se trouve sur la même machine physique que le manager principal pour des raisons évidentes de sécurité.
21
Network Time Protocol
48
Figure 14 : Maquette de teste proposée
4.5 Enregistrement des sondes
4.5.1 La déclaration Pour qu’un agent puisse se connecter et communiquer avec Prelude-Manager, il doit être enregistré. L'enregistrement implique des étapes à suivre : Allocation d'une identité unique pour la sonde La Création de répertoire à être utilisé par la sonde (cas de Failover)
49
Déclaration à Prelude-Manager d’obtenir un certificat X509 signé qui permettra la communication entre la sonde et le Manager en utilisant les permissions accordées. Toutes ces informations sont stockées dans une sonde 'profil'. 4.5.2 Profile Le profil d’une sonde est identifié par son nom. Quand une sonde est démarrée, il essayera de charger un profil du même nom que le programme lui-même, c'est-à-dire si notre sonde est nommée "Prelude-LML", le capteur essayera de charger un profil nommé ""Prelude-LML". Le cas d’une sur lecture (override) d’un nom de profile peut être utiliser avec la co mmande _--prelude --profile name_of_my_profile_. Elle fournit le capacité de définir un nom de profile afin de pouvoir avoir de multiple instance de la même sonde avec différentes permissions, qui exigent de différents profils. 4.5.3 Enregistrement d’agent /Création de Profile
La déclaration des agents est assurée par un seul outil nommé prelude-admin. $ prelude-admin register
--uid --gid La première fois qu'un agent est enregistré, prelude-admin devra créer une clé privée pour l'agent. Sous Linux, l'opération peut prendre une très longue période de temps en raison du système . o Exemple : Pour enregistrer la sonde snort on va procéder par suite : # prelude-admin register snort "idmef:w admin:r" 192.168.20.111 –uid 501 –gid 502 Generating 1024 bits RSA private key... This might take a very long time. [Increasing system activity will speed-up the process]. Generation in progress... X
Prelude-admin demandera après de demmarer l’instance prelude -admin sur la machine ou le serveur prelude-manager est en écoute. You now need to start "prelude-admin" registration-server on 192.168.20.111: example: "prelude-admin registration-server prelude-manager" Enter the one-shot password provided on 192.168.20.111:
50
Au niveau du manager (192.168.20.111) , on exécute la commande prelude-admin registrationserver en utilisant le nom de profile utilisé par notre manager . $ prelude-admin registration-server prelude-manager The "d0a9b7xf" password will be requested by "prelude-admin register" in order to connect. Please remove the quotes before using it. Generating 1024 bits Diffie-Hellman key for anonymous authentication...++++++++++.+++++..++++++++++ Waiting for peers install request on 0.0.0.0:5553...
Ensuite, la saisie du mot de passé généré par le manager au niveau de notre sonde Snort à enregistrer. Enter the one-shot password provided on localhost: Confirm the one-shot password provided on localhost: Connecting to registration server (192.168.20.111:5553)... Authentication succeeded. Successful registration to 192.168.20.111:5553.
Le message affiché du coté serveur est le suivant : Connection from 10.0.0.136:52507... Registration request for analyzerID="229348179011709" permission="idmef:w admin:r". Approve registration? [y/n]: y 10.0.0.136:52507 successfully registered.
4.6 Haute disponibilité
La haute disponibilité désigne le fait qu’une architecture ou service a un taux de disp onibilité convenable. La disponibilité est un enjeu important des infrastructures informatiques. On estime aujourd'hui que la non-disponibilité d'un service informatique peut avoir des coûts se chiffrant en millions. Deux moyens complémentaires sont utilisés pour améliorer la haute disponibilité : La mise en place d'une infrastructure matérielle dédiée, généralement en se basant sur de la redondance matérielle. Est alors créé un cluster de haute-disponibilité (par opposi-
51
tion à un cluster de calcul) : une grappe d'ordinateurs dont le but est d'assurer un service en évitant au maximum les indisponibilités. La mise en place de processus adaptés permettant de réduire les erreurs, et d'accélérer la reprise en cas d'erreur. ITIL contient de nombreux processus de ce type. Pour mesurer la disponibilité, on utilise souvent un pourcentage essentiellement composé de '9' :
99% désigne le fait que le service est indisponible moins de 3,65 jours par an 99,9%, moins de 8,75 heures par an 99,99%, moins de 52 minutes par an 99,999%, moins de 5,2 minutes par an 99,9999%, moins de 54,8 secondes par an 99,99999%, moins de 3,1 secondes par an etc.
L'amalgame est souvent fait, à tort, entre la haute disponibilité et le plan de reprise d'activité. Il s'agit de deux tâches différentes, complémentaires pour atteindre une disponibilité continue. Afin d’assurer une bonne disponibilité du serveur Prelude , notre configuration consiste consiste à fournir une haute disponibilité pour les services Prelude.
Heartbeat 22 prend le contrôle des Fail Over de la machine au cours des défaillances matérielles, au cas où une machine est DOWN ou une perte totale de connectivité. Les deux serveurs doivent être toujours à jour avec bases de données, et soit peut prendre en charge au pied levé le premier. La valeur ajoutée pour assurer une disponibilité assuré est l’ajout d’une solution de supervision, tels que Nagios afin de traiter une défaillance au niveau du service, ainsi donc une intervention manuelle pour le redémarrage du service. (Exemple si un service particulier est down, mais le matériel reste opérationnel et accessible ; UP). Elaboration de Prelude en haute disponibilité 1. L’installation de libprelude, LibpreludeDB, Prelude-Manager, PreludeCorrelator,Prelude-LML et Prewikka sur les deux machines.
2. La duplication des fichiers de configuration sur les deux serveurs pour tous les services centraux de Prelude.
22
Système de gestion de la haute disponibilit é sous Linux.
52
3. La communication et l’importation des schémas de Prewikka seront faites qu’au niveau d’une seule machine, et ça sera dupliqué dans l'autre automatiquement. 4. La copie des profils et leur enregistrements se fera sur une seul machine, et on copie le répertoire des profils qui se trouve dans notre installation dans /usr/local/etc/prelude/profile/ de l'autre machine centrale. 5. La mise automatique des services Web et MySQL en démarrage. Prelude-Manager et Prelude-Correlator ne doivent pas être configuré pour démarrer automatiquement au démarrage, étant donné que Heartbeat se chargera de ces deux services. 4.7 Performance
Dans notre cas où le serveur ne fait office que d’un manager principal et de serveur de base de données MySQL. Afin d’assurer une bonne performance au niveau du serveur nous allons voir désactiver les services inutiles et potentiellement dangereux ainsi qu’opérer un paramétrage plus fin du système. Suppression des services inetd inutiles La plupart des distributions linux installent par défaut avec des services anciens et dangereux comme: • lpr : Serveur d’impression UNIX • nfs-common & nfs-kernel-server : Gestion, hébergement et utilisation du système de fichiers réseau NFS (Network File System). • portmap : Mapping de ports pour les services RPC, co mplètement obsolète et potentiellement très dangereux. • pidentd : Daemon d’identification, principalement utilisé aujourd’hui lors de l’utilisation de clients IRC. • ppp, pppoe&pppconfig : Utilisé lors de connexions dial -up (modem analogique, ADSL & connexions VPN PPTP). • telnetd : Serveur Telnet, rendu obsolète depuis l’arrivée de SSH. • fingerd : Service finger, source d’information inutile. • ftpd : Serveur FTP, remplacé par le SFTP. Donc il a fallu supprimer ces services via la commande : apt-get remove nom_du_paqutage, Et ensuite désactiver encore les trois services lancés par inetd ou xinetd à l’aide des trois instructions suivantes :
53
update-inetd --disable time update-inetd --disable daytime update-inetd --disable discard Au niveau de Mysql En faisant la commande netstat -a, on a constaté que le serveur MySQL répond aussi bien aux requêtes provenant de l’extérieur (eth0) que de l’intérieur (lo). Bien que l’utilisateur ”root” ne puisse se connecter que sur l’interface lo, on a eu à modifier la confi guration de MySQL afin que son socket ne soit plus visible de l’extérieur. (Voir annexe).
54
Chapitre 5 : Fonctionnement et test
55
La phase de réalisation s’est focalisée sur des scénario de test, afin de voir la comportement de la maquette avec diverse attaque. Les deux attaques sur lesquelles cette phase repose, sont parmi les attaques les plus fréquents :
L'attaque par force brute : une méthode utilisée en cryptanalyse pour trouver un mot de passe ou une clé. Il s'agit de tester, une à une, toutes les combinaisons possibles. Cette méthode de recherche exhaustive ne réussit généralement que dans les cas où le mot de passe cherché est constitué de peu de caractères. Les programmes utilisés tentent toutes les possibilités de mot de passe dans un ordre aléatoire afin de berner les logiciels de sécurité qui empêchent de tenter tous les mots de passe dans l'ordre. Dans notre maquette nous allons faire une attaque sur des sessions ssh afin d’obtenir le mot de passe et aussi voire le comportement de Prelude (remonté d’alerte et corrélation).
Scan de port (portscan) est une technique servant à rechercher les ports ouverts sur un serveur de réseau. Cette technique est utilisée par les administrateurs des systèmes informatiques pour contrôler la sécurité des serveurs de leurs réseaux. La même technique est aussi utilisée par les pirates informatiques pour tenter de trouver des failles dans des systèmes informatiques. Un scan de port effectué sur un système tiers est généralement considéré comme une tentative d'intrusion, servant souvent à préparer une intrusion. Les balayages de ports se font habituellement sur le protocole TCP ; néanmoins, certains logiciels permettent aussi d'effectuer des balayages UDP. Cette dernière fonctionnalité est beaucoup moins fiable, UDP étant orienté sans connexion, le service ne répondra que si la requête correspond à un modèle précis variant selon le logiciel serveur utilisé. Cette attaque sera performé par l’outil Nmap qui est un scanner de ports open source créé par Fyodor et distribué par Insecure.org. Il est conçu pour détecter les ports ouverts, identifier les services hébergés et obtenir des informations sur le système d'exploitation d'un ordinateur cible.
La corrélation se base aussi sur l ’aspect comportemental ainsi, on essayera de configurer notre moteur de corrélation afin de détecté toute activité hors horaire de travail ou bien les jours fériés. 5.1 Scan de Port Lors de notre phase de test on a opté pour l’intrusion la plus facile et l a plus fréquente, qui est le scan de port . Ainsi donc on a fait un scan avec l’outil NMAP.
Le rôle du corrélateur est de détecter et de faire plus au moins une conclusion des différentes attaques. Nous avons travaillé sur la règle de corrélation suivante, écrite en Perl est se basant sur les expressions régulière.
56
5.1.1 Règle de corrélation 1. from PreludeCorrelator.context import Context 2. from PreludeCorrelator.pluginmanager import Plugin 3. class EventScanPlugin(Plugin): 4. def run(self, idmef): 5. source = idmef.Get("alert.source(*).node.address(*).address") 6. target = idmef.Get("alert.target(*).node.address(*).address") 7. if not source or not target: 8. return 9. for saddr in source: 10. for daddr in target: 11. ctx = Context(("SCAN EVENTSCAN", saddr, daddr), { "expire": 60, "threshold": 30, "alert_on_expire": True }, update = True, idmef=idmef) 12. if ctx.getUpdateCount() == 0: 13. ctx.Set("alert.correlation_alert.name", "A single host has played many events against a single target. This may be a vulnerability scan") 14. ctx.Set("alert.classification.text", "Eventscan") 15. ctx.Set("alert.assessment.impact.severity", "high")
La partie la plus importante dans ce code de corrélation est à partir de la ligne 11. La méthode context, c’est avec elle que repose le moteur de corrélation pour faire ses remonté d’alerte corrélée. ctx = Context(("SCAN EVENTSCAN", saddr, daddr), { "expire": 60, "threshold": 30, "alert_on_expire": True }, update = True, idmef=idmef)
SCAN EVENTSCAN : est l’identifiant avec le quelle en identifie un context qui sera par la suite écrit de la façon suivante: SCAN EVENTSCA_saddr et SCAN EVENT_daddr.
Expire, threshold et alert_on_expire sont des options additionnelles : Expire : comme son nom l’indique c’est l’expiration d’un contexte après x seconde
Alert_on_expire : Si notre context est expiré, et cette option est à True le message IDMEF sera envoyer.
Treshold : C’est le seuil interne pour un context .
5.1.2 Scenario de corrélation de Scan de port Après avoir fait une comparaison entre l’adresse source et destination, on entre dans une boucle imbriquée entre l’adresse source et l’adresse cible. Dans cette boucle on crée un contexte ; si le seuil interne de ce context a été atteint en moins de 60 seconde qui implique aussi un non update de ce context ( ctx.getUpdateCount() = 0 ), alors une alerte corrélée sera remonté avec les valeur qu’on lui aura assigné via la méthode Set (voir les lignes 13,14 et 15) .
57
Figure 15 : Remonté d'une alerte corrélée (EvantScan)
5.2 Brute force attaque
Cette attaque consiste à faire des connexions intensives et avec des mots de passes erronés sur une session ssh, afin de simuler qu’un attaquant essaye de cracker le mot de passe de cette session.
58
5.2.1 Règle de corrélation : 1. function brute_force(INPUT) 2. local is_failed_auth = INPUT:match("alert.classification.text", “alert.assessment.impact.completion",
"failed") 3. local result = INPUT:match ("alert.source(*).node.address(*).address", "(.+)","alert.target(*) .node.address(*).address", "(.+)"); 4. if is_failed_auth and result then 5. for i, source in ipairs(result[1]) do 6. for i, target in ipairs(result[2]) do 7. ctx = Context("BRUTE_ST_" ,source ,target,{ expire = 20, threshold = 5 "alert_on_expire": True}, update = True, idmef= local ) 8. ctx:set("alert.source(>>)", INPUT:getraw("alert.source")) 9. ctx:set("alert.target(>>)", INPUT:getraw("alert.target")) 10. ctx:set("alert.correlation_alert.alertident(>>).alertident", INPUT:getraw( "alert.messageid")) 11. if ctx:CheckAndDecThreshold() then 12. ctx:set("alert.classification.text", "Brute force attack") 13. ctx:set("alert.correlation_alert.name", "Multiple failed login") 14. ctx:set("alert.assessment.impact.severity", "high") 15. ctx:set("alert.assessment.impact.description","Multiple failed attempts have been made to login to a user account")
5.2.2 Scenario corrélation du brute force Ici le context (ligne 7) de notre règle consiste à contrôler le seuil de tentative (threshold = 5) sur les sessions SSH au bout d’une durée de temps spécifiques (expire = 20) .Cette règle de corrélation détecte aussi une attaque brute force distribué (ligne 8 et 9), plusieurs à plusieurs. Après une décrémentation du seuil jusqu’à 0, on assignera les informations de l’alerte corrélée au context créé (ligne 11 à 15).
59
Figure 16 : Remonté d'une alerte corrélée (Brute Force)
5.3 Analyse via Prelude-LML
Pour toute non compatibilité native des sondes avec Prelude, le plugin Prelude-LML est disponible pour faciliter l’analyse des logs générer via une écriture de règles perso nnelles reposant sur des expressions régulières. Dans notre maquettes on a essayé de traiter ce point avec un honeyPot , HoneyD génère des logs et les journalise dans /var/log/syslog . C’est là où vient le rôle du analyseur de log Prelude-LML . Lors de la configuration de notre HoneyD , on a essayé de faire la journalisation via SysLog , pour faire par la suite une analyse avec Prelude-LML . Dans notre analyseur il faut spécifier le format du fichier log afin de détécter chaque partie et la normaliser après pour avoir une remonté d’alert dans l’interface Prelude .
60
1. [format=syslog] 2. time-format = "%b %d %H:%M:%S" 3. prefix-regex = "^(?P.{15}) (?P\S+)(?:(?P\S+?)(?:\[(?P[0-9]+)\])?:
)?"
4. file = /var/log/messages 5. file = /var/log/auth.log
La partie la plus importante dans cette section est prefix-regex .Cette option dicte à Prelude-LML comment manipuler le fichier log via différents champs : Tableau 1 : Correspondance des valeurs de l'expression régulière.
Variable
Utilisation
Timestamp
Liaison au temps de détection de l’alerte IDMEF
Hostname
Liaison au nœud cible de l’alerte IDMEF
Process
Liaison au processus cible de l’alerte IDMEF
Pid
Liaison au pid cible de l’alerte IDMEF
Figure 17 : Fichier syslog , journalisant HoneyD
Lors du démarrage de HoneyD ,on démarre Prelude-LML afin de procédé à notre analyse des sortie SysLog du HoneyPot. Comme montrer dans la figure17 et avec la configuration faite au niveau de Prelude-LML on déduit le tableau suivant : Tableau 2 : Valeur correspondant à la capture fig 17
Variable
Value
timestamp
Jun 19 09:07:12
hostname
machine
process
honeyd
pid
5211
61
Figure 18 : Remonté d'alerte de la sonde HoneyD via Prelude-LML
Ainsi donc on aura une remonté d aletre comme quoi un utilisateur a tenter de ‘pinger’ ou d’ouvrire une session SSH dans notre HoneyPot . 62
5.4L’interface Prewikka:
Prewikka est l'interface Web de Prelude. Elle permet d'afficher les alertes reçues par Prelude-Manager. Lorsque Prelude, plus précisément Prelude-Manager, reçoit une alerte IDS, il l’ajoute dans la base de données de Prelude. Ainsi, Prewikka, lorsqu’il va réactual iser sa page d’affichage d’alertes, relancera un SE LECT sur les tables de la base de données et affichera alors cette nouvelle alerte. 5.4.1 Description et utilisation de l'interface Lancement de l'interface Etant une interface graphique web, Prewikka se lance donc dans un navigateur internet. Pour cela, il suffit d’entrer dans la barre d’adresse url du navigateur (Firefox, IE, Opera, …), cette adresse :http://adresse_ip_prewikka:8000 L’accès avec succès dans le navigateur nous mènera vers un formulaire d’authentification. Il faut entrer le login et le password en fonction de la configuration de Prewikka (définition de l’administrateur par défaut dans le fichier de configuration /etc/prewikka/prewikka.conf, avec les champs initial_admin_user et initial_admin_pass).
Figure 19 : Formulaire d'authentification
63
Une fois authentifié, la page principale de Prewikka s'affiche alors, à savoir la visualisation des alertes.
Figure 20 : Page principale Prewikka
Description de l'interface L’interface de Prewikka est composée d’une fenêtre principale, centrale où sont affichées les alertes transmises par les sondes de Prelude. Sur la gauche, on peut trouver le menu avec les différentes parties : Evénements, Agents, Paramètres statistiques et A propos.
La partie Evénements correspond donc à la visualisation des ale rtes IDS. C’est la page principale (par défaut) de Prewikka. Sur cette page, il y a 3 onglets disponibles pour spécifier, voir plutôt filtrer l’affichage des alertes. On a donc le choix entre Alertes, Alertes de Corrélation et Alertes d’outils. Le premier onglet Alertes (par défaut), affiche la totalité des alertes (corrélées, …), le second, comme l’indique son nom, sert à visualiser que les alertes corrélées par Prelude-Correlator. Quant au troisième, il affiche les alertes concernant les outils (sondes).
64
Des couleurs sont utilisées pour pouvoir en faciliter la recherche sur les niveaux de gravités, de danger de chacune d’entre elles. Ainsi, le code des couleurs est : 1 Bleu → niveau d’information « info » 2 Vert → niveau le plus faible « low » 3 Orange → niveau intermédiaire « medium » 4 Rouge → niveau d’alerte maximum « high » Les alertes sont affichées sous la forme d’un tableau, avec comme colonnes, la classific ation (nom de l’alerte, …), la source ayant provoquée l’alerte, puis la destination de l’événement, ensuite le nom de la sonde ayant fait remontée cette alerte à Prelude, et enfin le temps (heure) sur lequel l’alerte a été reçue par le Prelude-Manager. Pour chacun de ses onglets (Evénements), un bouton se trouvant en bas de page (Effacer), permet après sélection des alertes (globale, ou ciblée), de les supprimer. Quel que soit l’onglet choisi, il est possible (en général) de voir en détail les alertes en cliquant dessus, sur le titre de l’alerte ou bien, en cliquant sur le nombre à côté du titre dans le cas où il y en aurait plusieurs.
Figure 21 : Liste des alertes
Après avoir cliqué sur une alerte ( see alert), Prewikka affiche alors le contenu de l’alerte, à savoir le format IDMEF avec une mise en forme HTML, plus sympathique à lire que dans un fichier de logs.
Figure 22: Détail d'une alerte
65
Après la réception et l’ajout d’une nouvelle alerte par Prelude -Manager, le corrélateur, à savoir Prelude-Correlator va en fonction de ses règles, intercepter certaines alertes pour en générer une nouvelle, corrélée. Cette dernière sera renvoyée au Prelude-Manager, qui la verra comme une nouvelle alerte, mais corrélée. En aucun cas, le corrélateur ne supprime les alertes à partir desquelles il a généré sa corrélation. Ainsi, dans Prewikka, il sera possible de voir les nouvelles alertes reçues directement par le Prelude-Manager, avec aussi la nouvelle alerte corrélée, en général à un niveau de gravité plus élevé.
Figure 23 : Pages des alertes corrélées
Le bouton Agents permet de visualiser l’ensemble des agents constituant l’architecture réseau de notre maquette, à savoir les différentes sondes connectées au serveur Prelude, ainsi que ses composants, comme le Prelude-Manager, le Prelude-Correlator... Il est possible donc de voir l’état des sondes et des composants de Prelude en temps réel, c’est -àdire si ils sont connectées ou pas (Manquant ou Connecté).
66
Figure 24 : Liste et pages des agents
Et enfin , la page Statistique qui permet de voir les attaques au cours d'un intervalle de temps. Elle nous montre ainsi et de façon explicite des statistiques avec différents graphes et selon défirent critères.
67 Figure 25 : Graphes de la page statistiques
Conclusion Durant ces quatre mois de stage de fin d’ étude, il nous a été offert d’effectuer différentes tâches aussi variées qu’intéressantes. En effet, nous avons eu le plaisir d’effectuer les travaux suivants :
L’ étude et comparaison des différents solution SIEM. Le déploiement d’une architecture réseau complète (Firewall, NIDS , HIDS, se rveurs Web,HoneyPot) L’adaptabilité d’une solution SIEM dans une architecture réseau. Création règles personnalisées de SNORT et Prelude nous amenons a bien comprendre le trafic réseau .
Nous estimons avoir atteint notre but, puisque la quasi-totalité du cahier des charge a été remplie. Mais je ne pourrai prétendre avoir fait le tour du sujet. En effet, la corrélation d’événements reste un domaine en pleine évolut ion et en recherche de solutions efficaces. Il serait intéressant d’approfondir l’analyse et de mettre en place d’autres sc enario d’investigation permettant d’observer le comportement de l’architecture mise e n place. De plus, il serait très utile de déployer un serveur de monitoring (Nagios par exemple ) afin d’aider à assurer une haute disponibilité . La corrélation pourra aussi nous mener à considérer le data mining ,en effet pour valeur ajouté à ce travail il est envisageable d’ajouter LogHound , qui e st un outil conçu pour trouver des motifs fréquents à partir des données log des événements fixe à l'aide de l’algorithme breadth-first du data minig , chose qui n ’a pas été implémenter par faute de temps. D’un point de vue plus personnel, ce travail m’a permis d’élargir mes connaissances en sécurité réseau, configuration d’éléments réseaux et gestion de la dé tection d’intrusions . Ces différents domaines m’ont donné une forte envie d’approfondi r mes connaissances en la matière. C’est pour cela que j’envis age fortement une formation plus poussée dans le domaine...
68
Annexe Installation de Prelude Pré-requis Pour la préparation d'un environnement Prelude, il faut installer certains paquets :
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install man wget ssh build-essential checkinstall libpcap-dev flex byacc gtk-doc-tools libssl-dev libxml-dev libpcre3-dev libfam-dev gnutls-bin libgcrypt11-dev libgnutls-dev libgpg-error-dev libopencdk10-dev libxmlsec1 libxmlsec1-gnutls
Libprelude Téléchargement Récupération de la librairie de Prelude :
$ sudo wget http://www.prelude-ids.com/download/releases/libprelude/libprelude-1.0.0.tar.gz
Compilation et installation Installation de la librairie :
$ sudo tar zxf libprelude-1.0.0.tar.gz
$ cd libprelude-0.9.24.1
$ sudo ./configure --enable-easy-bindings --enable-gtk-doc
*** Dumping configuration ***
- Generate documentation
: yes
- Libtool dynamic loader
: System
- LUA binding
: no
- Perl binding
: yes
- Python binding
: yes
- Ruby binding
: no
- Easy bindings
: yes
$ sudo make
$ sudo make install
$ sudo ln /sbin/ldconfig /usr/local/lib
$ sudo export LD_LIBRARY_PATH=/usr/local/lib
69
$ sudo vim /etc/ld.so.conf
include /usr/local/lib
$ sudo ldconfig
LibpreludeDB Pré-requis L'ajout d'une base de données sur un serveur Prelude requiert des paquets supplémentaires :
$ sudo apt-get install mysql-server libmysqlclient15-dev
Téléchargement Téléchargement de la librairie de base de données de Prelude:
$ sudo wget http://www.prelude-ids.com/download/releases/libpreludedb/libpreludedb-10.0.0.tar.gz
Compilation et installation Installation de la librairie:
$ sudo tar zxf libpreludedb-1.0.0.tar.gz
$ cd libprelude-0.9.15.3
$ sudo ./configure --with-postgresql=no --enable-gtk-doc
*** Dumping configuration ***
- Generate documentation
: yes
- Enable MySQL plugin
: yes
- Enable PostgreSQL plugin
: no
- Enable SQLite3 plugin
: no
- Perl binding
: yes
- Python binding
: yes
$ sudo make
$ sudo make install
$ sudo vim /etc/ld.so.conf
include /usr/local/lib/libpreludedb/plugins/formats
include /usr/local/lib/libpreludedb/plugins/sql
$ sudo ldconfig
Création de la base de données 70
Pour stocker les alertes, création de la base de données Prelude :
$ sudo mysql -u root –p
> create database prelude;
> grant all privileges on prelude.* to prelude@localhost identified by 'prelude';
> grant all privileges on prelude.* to prelude@nagios identified by 'prelude';
> exit
$ sudo mysql -u prelude -p prelude < /usr/local/share/libpreludedb/classic/mysql.sql
Prelude-Manager Téléchargement Ensuite, il faut télécharger le paquet Prelude-Manager:
$ sudo wget http://www.prelude-ids.com/download/releases/prelude-manager/prelude-manager-1.0.0.0.tar.gz
Compilation et installation Et enfin l’installer:
$ sudo tar zxf prelude-manager-1.0.0.tar.gz
$ cd prelude-manager-0.9.15
$ sudo ./configure
*** Dumping configuration ***
- TCP wrapper support
: no
- XML plugin support
: yes
- Database plugin support: yes
$ sudo make
$ sudo make install
$ sudo vim /etc/ld.so.conf
include /usr/local/lib/prelude-manager/decodes
include /usr/local/lib/prelude-manager/filters
include /usr/local/lib/prelude-manager/reports$ sudo ldconfig
$ sudo ldconfig
Prelude-Correlator Pré-requis L'ajout de Prelude-Correlator nécessite l'installation d'un environnement python :
71
$ sudo apt-get install python
Téléchargement Téléchargement du plugin de corrélation de Prelude :
$ sudo wget http://www.prelude-ids.com/download/releases/prelude-correlator/prelude-correlator-1.0.0.tar.gz
Compilation et installation Installation du module de corrélation:
$ sudo tar zxf prelude-correlator-1.0.0.tar.gz
$ cd prelude-correlator-0.9.0-beta6
$ sudo python setup.py build
$ sudo python setup.py install
$ sudo vim /etc/ld.so.conf
include /usr/local/lib/prelude-correlator
$ sudo ldconfig
Prelude-LML Téléchargement Pour installer le module Prelude-LML, il faut récupérer le paquet:
$ sudo wget http://www.prelude-ids.com/download/releases/prelude-lml/prelude-lml-1.0.0.tar.gz
Compilation et installation Puis le compiler et l ’installer:
$ sudo tar zxf prelude-lml-0.9.15.tar.gz
$ cd prelude-lml-0.9.15
$ sudo ./configure
*** Dumping configuration ***
- Enable unsupported rulesets
: yes
$ sudo make
$ sudo make install
$ sudo vim /etc/ld.so.conf
include /usr/local/lib/prelude-lml
$ sudo ldconfig
72
Prewikka Pré-requis La mise en place de l'interface web nécessite d'installer quelques paquets supplémentaires :
$ sudo apt-get install apache2 libapache2-mod-python mysql-server python python-dev python-setuptools
Téléchargement Pour mettre en place une interface graphique de Prelude, il faut télécharger le module Prewikka:
$ sudo wget http://www.prelude-ids.com/download/releases/prewikka/prewikka-1.0.0.tar.gz
Compilation et installation Installation de l’interface Prewikka:
$ sudo tar zxf prewikka-0.9.17
$ cd prewikka-0.9.17
$ sudo apt-get install cheetah
$ sudo python setup.py build
$ sudo python setup.py install
Création de la base de données Pour l’interface Prewikka, il faut créer une base de données :
$ sudo mysql -u root –p
> create database prewikka;
> grant all privileges on prewikka.* to prewikka@localhost identified by 'prewikka';
> exit
$ sudo mysql -u prewikka -p prewikka < /usr/share/prewikka/database/mysql.sql
Configuration de Prelude Libprelude Cette partie correspond à la configuration de Prelude en général, c'est-à-dire à Libprelude installé sur un poste client ou serveur. En effet, quel que soit l'usage, et l'installation étant la même sur les deux types de postes, la configuration de base de Prelude se trouve par défaut dans le répertoire /usr/local/etc/prelude/default. Ce dossier contient plusieurs fichiers de configuration tels que:
1
client.conf
2
global.conf
3
idmef-client.conf
4
tls.conf
73
client.conf Ce fichier est à éditer que dans le cadre d'une configuration d'un agent ou d'une sonde (exemple: Prelude-Correlator, Ossec, …etc). client.conf permet notamment d'indiquer l'adresse du serveur Prelude (Prelude-Manager), et de paramétrer les différents échanges (au niveau tcp, et tls) entre le client et le serveur.
global.conf Le fichier global.conf contient la configuration pouvant servir aussi bien pour le serveur, que pour le client (agent, ou sonde). Dans ce fichier, il est possible de paramétrer certaines options pour gérer des champs à remplir lors de l'envoi d'alerte, ou encore pour préciser les informations sur le poste serveur ou client (multiples adresses ip, nom du vlan, …etc).
idmef-client.conf Quant à ce fichier, idmef-client.conf , il contient les liens vers les deux fichiers précédents, à savoir client.conf et global.conf .
tls.conf Afin de paramétrer la génération des certificats, comme la durée de vie ou la valeur de la clé de cryptage (par défaut 1024), il faut éditer le fichier tls.conf .
Prelude-Manager Pour configurer Prelude-Manager, il faut é diter le fichier prelude-manager.conf , par défaut ce dernier se trouve sous le répertoire /usr/local/etc/prelude-manager. $ sudo vim /usr/local/etc/prelude-manager/prelude-manager.conf
Configuration de base Dans prelude-manager.conf , le réseau sur lequel Prelude-Manager écoute doit être précisé, afin que ce dernier accepte les connexions des clients (sondes). Pour simplifier, ici l'adresse choisie est globale. listen = 0.0.0.0
Ensuite, il reste à indiquer les paramètres de la base de données de Prelude (LibpreludeDB) :
[db]
type = mysql
host = localhost
port = 3306
name = prelude
user = prelude
pass = manager
Avec ces paramètres, Prelude-Manager est prêt à démarrer et à fonctionner.
Optimisation Une fois la configuration de base terminée, il est possible d'optimiser Prelude-Manager dans prelude-manager.conf .
Logs L'activation du debug en mode texte se fait en ajoutant ces lignes :
74
...
[debug]
logfile = stderr
logfile = /var/log/prelude.log
...
Prelude-LML Pour configurer Prelude-LML, il faut éditer le fichier prelude-lml.conf . $ sudo vim /usr/local/etc/prelude-lml/prelude-lml.conf
Optimisation Pour prendre en compte les syslogs par exemple, y ajouter :
[format=syslog]
time-format = "%b %d %H:%M:%S"
prefix-regex = "^(?P.{15}) (?P\S+) (?:(?P\S+?)(?:\[(?P[0-9]+)\])?: )?"
file = /var/log/messages
file = /var/log/auth
file = /var/log/syslog
Prewikka Pour activer l’interface Web de Prelude, il faut commencer par configurer Prewikka. Ce dernier dispose d'un fichier de configuration, prewikka.conf . $ sudo vim /etc/prewikka/prewikka.conf
Configuration de base Dans prewikka.conf , il faut précisé les paramètres des bases de données à utiliser. Voici les champs à compléter: [idmef_database]
# if your database is a sqlite file, please use:
# type: sqlite3
# file: /path/to/your/sqlite_database
type: mysql
host: localhost
user: prelude
pass: prelude
name: prelude
75
[database]
type: mysql
host: localhost
user: prewikka
pass: prewikka
name: prewikka
La première partie correspond à la base de données de Prelude-Manager, contenant les alertes IDMEF. Quant à la seconde base de données, c'est celle de Prewikka, crée lors de l'installation de ce dernier pour ajouter une interface graphique.
Optimisation A travers le fichier prewikka.conf , il est possible d'optimiser la configuration de Prewikka.
Authentification L'authentification de Prewikka peut être modifiée, soit en la désactivant, soit en indiquant les paramètres de l'administrateur de base, initial (par défaut admin/admin).
[auth loginpassword]
expiration: 60
initial_admin_user: admin
initial_admin_pass: admin
Pour désactiver l'authentification, il suffit de commenter les lignes précédentes :
#[auth loginpassword]
#expiration: 60
#initial_admin_user: admin
#initial_admin_pass: admin
Logs Pour activer les logs de Prewikka, il faut indiquer un fichier en sortie :
[log file]
level: debug
file: /var/log/prewikka.log
[log syslog]
level: warning
Installation d'Ossec Pré-requis 76
Avant de passer à l ’installation d’Ossec, il faut au préalable installer certains paquets, à adapter selon vos besoins.
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install wget man ssh build-essential libgnutls-dev checkinstall
Ossec-HIDS Téléchargement Pour installer Ossec, il faut tout d’abord télécharger la dernière version (http://www.ossec.net/main/downloads). $ sudo wget http://www.ossec.net/files/ossec-hids-latest.tar.gz
Décompresser l’archive.
$ sudo tar –zxf ossec-hids-2.6.tar.gz
Un seul paquet est nécessaire pour l’installation sur un poste Linux. En effet ce dernier sert aussi bien pour l’installation d’un serveur que d’un agent.
Ossec Serveur Libprelude L’installation de Libprelude est obligatoire pour pouvoir enregistrer le serveur Ossec auprès du serveur Prelude. Ainsi, Ossec est considéré comme une sonde de Prelude et peut alors échanger avec ce dernier de manière sécurisé.
Ossec $ cd ossec-hids-2.1
Afin qu’Ossec prenne en charge Prelude (optionnel), c’est-à-dire, l’envoi des alertes au format IDMEF vers PreludeManager, il faut activer le service avant de lancer l'installation, sous peine, en cas d'oubli, de devoir réinstaller complétement Ossec afin de réussir à l'intégrer correctement à Prelude. $ cd src
$ sudo make setprelude
$ cd .. $ sudo ./install.sh
Ensuite, il ne reste plus qu’à suivre les instructions comme le choix de langue, le type d’installation (serveur/agent…), le répertoire d’installation, …etc.
Ossec Agent Linux Pour le client Linux, la procédure est similaire au serveur, à la seule différence qu’il faut choisir le type Agent lors de l’installation.
Ossec-WUI 77
Ossec-WUI est l'interface web d'Ossec-HIDS. Elle permet de visualiser les alertes reçues par le serveur. Cette installation n'est pas obligatoire.
Pré-requis Pour installer Ossec-WUI, il faut au préalable installer certains paquets.
$ sudo apt-get install apache2 php5
Téléchargement Le paquet Ossec-WUI est à télécharger sur le site d'Ossec (http://www.ossec.net/main/downloads). $ sudo wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz
Décompresser l’archive.
$ sudo tar –zxf ossec-wui-0.3.tar.gz
Installation Une fois le paquet téléchargé et décompressé, il faut le déplacer dans le dossier utilisé par notre serveur web (Apache).
$ sudo mv ossec-wui-0.3 /var/www/htdocs/ossec-wui
Ensuite, on peut lancer l'installation.
$ sudo cd /var/www/htdocs/ossec-wui
$ sudo ./setup.sh
www-data tmp
Configuration d'Ossec Ossec-HIDS Pour configurer Ossec, il faut éditer le fichier ossec.conf . $ sudo vim /etc/ossec/etc/ossec.conf
Configuration de base Dans ossec.conf , il faut ajouter les adresses ip autorisées à interagir avec Ossec, c'est-à-dire les postes informatiques ne pouvant être bloqués par le système de réponses-actives d'Ossec-HIDS, ces derniers étant considérés comme sûrs. Pour cela, ces adresses ip doivent être entrées dans la liste blanche.
...
127.0.0.1
^localhost.localdomain$
192.168.20.111
192.168.40.130
78
192.168.40.1
...
Libprelude Afin que notre serveur Ossec et Prelude communiquent correctement entre eux, il faut préciser l’adresse du serveur Prelude dans le fichier client.conf dans le repertoire /usr/local/etc/prelude/default. $ sudo vim /usr/local/etc/prelude/default/client.conf
server-addr = 192.168.20.111
Ensuite dans le fichier de configuration ossec.conf , il faut ajouter des paramètres Prelude.
...
yes
ossec
0
...
Le paramètre prelude_output permet d'activer l'envoi d'alerte vers Prelude, quant au paramètre prelude_profile, il sert à indiquer le profile (certificat d'inscription utilisé pour Prelude) à utiliser au démarrage d'Ossec-HIDS. Pour prelude_log_level, c'est en quelque sorte un filtre des alertes à en voyer à Prelude avec un niveau de log minimum.
Ossec Agent Linux Sur les agents, il faut comme pour la version serveur, éditer le fichier ossec.conf afin de configurer les répertoires et les fichiers vers lesquels Ossec doit pointer et surveiller. Mais le point le plus important, est d'indiquer l'adresse du serveur Ossec :
192.168.40.129
Installation d'un serveur Snort Pré-requis $ sudo apt-get update
$ sudo apt-get upgrade
79
$ sudo apt-get install build-essential checkinstall mysql-server libnet1-dev libpcap0.8-dev libpcre3-dev libmysqlclient15-dev
Snort Libprelude L’installation de Libprelude est obligatoire pour pouvoir enregistrer le serveur Snort auprès du serveur Prelude. Ainsi, Snort est considéré comme une sonde de Prelude et peut alors échanger avec ce dernier de manière sécurisé.
Snort Maintenant, l’installation de Snort peut commencer :
$ sudo cd /tmp
$ sudo wget http://dl.snort.org/snort-current/snort-2.8.6.tar.gz
$ sudo tar --zxf snort-2.8.6.tar.gz
$ sudo cd snort-2.8.6
$ sudo ./configure --with-mysql --enable-dynamicplugin --prefix=/usr/local/snort --enable-prelude
$ sudo make
$ sudo make install
$ sudo mkdir /etc/snort
$ sudo mkdir /var/log/snort
$ sudo mkdir /etc/snort/rules_backup
$ sudo mkdir /etc/snort/packages
$ sudo cp /tmp/snort-2.8.6/etc/*.conf* /etc/snort
$ sudo cp /tmp/snort-2.8.6/etc/*.map /etc/snort
Utilisateur et groupe Pour l’administration de l’application Snort, il faut créer un utilisateur d’administration et un groupe (cette étape peut être optionnelle) :
$ sudo groupadd snort
$ sudo useradd –g snort –d /usr/local/snort –m snort
$ sudo chown –R snort /var/log/snort
$ sudo chgrp –R snort /var/log/snort
Règles Snort Ajout des règles Snort:
$ sudo cd /tmp
$ sudo wget http://dl.snort.org/sub-rules/snortrules-snapshot-2.8.6_s.tar.gz
80
$ sudo tar –zxf snortrules-snapshot-2.8.6_s.tar.gz
$ sudo mv snortrules-snapshot-2.8.6/rules/* /etc/snort/rules
MySQL Création de la base de données Pour le stockage des alertes de Snort, et pour une visualisation plus claire que dans un fichier de logs, il est possible de créer une base de données:
$ sudo mysql –u root –p
> create database snort;
Création d’un utilisateur
Ajout d’un utilisateur pour administrer la base de données:
> grant all on snort.* to snort@localhost;
> set password for snort@localhost=password(‘ snort’);
> flush privileges;
> exit
Construction de la base de données Création des tables et différentes propriétés de la base de données, grâce à un script fourni dans le paquet d’installation de Snort :
$ sudo cd /tmp/snort-2.8.6/schemas
$ sudo mysql –u snort –p < create_mysql snort
Configuration d'un serveur Snort Snort Pour configurer Snort, il faut éditer le fichier snort.conf . $ sudo vim /etc/snort/snort.conf
Configuration de base Dans le fichier snort.conf , voici les paramètres de base à indiquer pour le bon fonctionnement de Snort : Déclaration des interfaces d’écoute :
var HOME_NET 10.0.0.0/8
var EXTERNAL_NET any
Ensuite, il est important d'indiquer le répertoire contenant les règles :
var RULE_PATH /etc/snort/rules
Définition de la base de données Snort :
81
output database: log, mysql, user=snort password=snort dbname=snort host=localhost
Libprelude Activation de l’envoi d’alertes vers Prelude:
$ sudo vim /etc/snort/snort.conf
Pour relayer les alertes de snort vers le serveur Prelude, il faut également ajouter cette ligne :
output alert_prelude: profile=snort
Puis, il est important pour la communication entre Snort et Prelude de configurer la librairie de Prelude. Pour cela, il faut préciser l’adresse du serveur Prelude dans le fichier client.conf dans le répertoire /usr/local/etc/prelude/default. $ sudo vim /usr/local/etc/prelude/default/client.conf
server-addr = 192.168.20.111
82
