Réalisation d'un prototype de validation d'un système de détection d'intrusion réseau

Résumé du document

De nos jours, les réseaux sont devenus l'un des meilleurs moyens de communiquer rapidement et à moindre coût aussi bien pour les particuliers que dans les entreprises. Que se soit par le biais de l'Internet ou par l'utilisation d'un LAN dans une administration, de plus en plus d'utilisateurs de l'outil informatique se servent de réseaux pour faciliter les communications.

Cependant, très peu d'utilisateurs des réseaux prennent en compte le volet sécuritaire. Ainsi qu'à travers les différentes communications réseau, beaucoup de systèmes sont victimes d'attaques venant de l'extérieur comme de l'intérieur.

Ces attaques peuvent être des emails piégés, des virus ou alors des intrusions de tout genre non autorisées dans un réseau informatique. Pour pallier à ces attaques, il revient aux informaticiens et particulièrement aux administrateurs réseaux de protéger leurs systèmes. Plusieurs systèmes de protection ont été développés au fil des années dans ce sens. Le prototype que nous proposons de mettre sur pied se situe au niveau des SDI et SPI réseau (SDIR et SPIR).

Le présent projet vient donc proposer une étude de faisabilité d'un tel raisonnement en présentant un modèle de vérification basé sur les notions de sécurité informatique et d'interface homme-machine. Les points fondamentaux que traite le système de détection d'intrusion étant donc :
- la représentation des connaissances ;
- l'interopérabilité (échange et partage des connaissances) entre systèmes ;
- la réduction du taux de faux positifs ;
- la réduction du taux de faux négatifs ;
- limitation de la durée de l'action et de l'impact d'une intrusion dans un SI.

Il est important de définir pour chaque relation, une relation inverse. Il est en effet redondant de stocker l'information dans les deux sens, toutefois, du point de vue de l'acquisition des connaissances, il est plus commode que les deux termes de l'information restent explicitement accessibles.

Ceci donne des possibilités diverses aux mécanismes d'inférence qui s'exécutent par chaînage avant, chaînage arrière, chaînage bidirectionnel ou encore chaînage mixte. De plus, cette approche donne la possibilité à l'utilisateur de renseigner, dans un cas, le concept en amont et dans un autre le concept en aval. Ces relations constituent les prédicats et les concepts constituent les classes que nous utiliserons pour l'expression formelle des axiomes et règles.

Extraits

[...] - Un agent Manager : regroupe les fonctionnalités du SPMA et du EMA. - Un agent Detector : s'assimilant aux IMA. - Un agent Collector : LA. Snort est l'IDS qui la scanne la carte réseau et analyser tous les paquets. Dans le cas où un paquet à vérifié une règle, Snort log ses informations dans une base de données MySQL. SNORT joue le rôle d'agent Sensor. Non seulement il capte les intrusions, il les collecte et les log dans une base de données MySQL. [...]

[...] En outre, il réalise la distribution des attaques à détecter et des LA aux IMAs. L'IMA : surveille les activités au sein du réseau local, détecte les attaques complexes à ce niveau et analyse les rapports envoyés par les LAs qu'il contrôle. Les LA : ont pour principale fonction de surveiller les activités du réseau. Le SO : spécifie les politiques de sécurité et assure la maintenance de la BC. Le prototype que nous avons réalisé contracte ses 5 agents en 3 agents réalisant les tâches des 5. [...]

[...] Cependant, avant d'entrer dans la phase d'analyse et de conception de notre prototype de vérification, disons quelques mots pour resituer sur le système à vérifier, à savoir le Système. Trois catégories de problèmes ont été détectées durant l'analyse ayant conduit a la conception du système : ceux liés à la Base de connaissances les faux négatifs et les faux positifs. Voici ci-dessus présentés les problèmes liés à ces trois aspects d'après les recherches des concepteurs du système : 1 Problèmes liés à la base de connaissances Les informations journalisées présentent généralement des descriptions différentes en fonction de la source d'audit. [...]

[...] Lorsque l'attaque survient, elle est alors considérée comme une action légale et aucune alerte n'est émise. Si un individu mal intentionné usurpe l'adresse IP d'un nœud important du réseau (routeur, serveur Web les conséquences peuvent être graves puisqu'il ne sera pas bloqué par l'IPS qui utilise en général une White-list précisant les adresses critiques à ne bloquer en aucune situation En conclusion, les problèmes liés à la gestion des connaissances sont de trois types: réutilisation des connaissances, interopérabilité des systèmes et capitalisation des processus d'ingénierie des connaissances. [...]

[...] La figure suivante est une architecture complète de gestion d'une alerte par le système. Figure 13: Système Alert Management Snort joue ici le rôle d'analyseur ou de sniffer. Étant donnée une connexion une fois que Snort l'a repérée comme une attaque possible, cette dernière d'après le schéma conceptuel du système passe par un filtre afin de déterminer si oui ou non l'attaque fait partir d'une catégorie enregistrée par les règles chargées dans Snort. Âpres être filtré, l'attaque peut immédiatement être ignorée ou bien passer par l'ontologie du système ce afin de rendre compréhensible les champs du paquet attrapé afin de l'étudier. [...]