Cet article est un aperçu de l'ensemble des composants d'un honeynet GenII. Le premier paragraphe présente le concept d'un honeywall, c'est le point d'entrée qui nous donne le moyen de superviser notre réseau. Dans le paragraphe traitant du contrôle des données, nous expliquons comment limiter les actions que les pirates peuvent entreprendre sur notre réseau. Le troisième paragraphe, "Capture de donnée", détaille les méthodes pour enregistrer de manière exhaustive l'activité de l'attaquant tant au niveau de l'hôte que du réseau. Le paragraphe "Alerter" couvre les procédés pour notifier en temps réel l'administrateur des attaques réussies. Enfin le paragraphe "Tester" présente un ensemble de moyen de vérification de la configuration mise en œuvre dans les étapes précédentes. L'installation du honeywall décrite se base sur un noyau Linux 2.4 tournant sur du matériel x86 standard. Les outils et les méthodes décrite dans cet article, sont ceux actuellement utilisés par les membres du Projet. L'utilisation de ces outils et de ces méthodes n'est pas une obligation. Vous pouvez utiliser librement les technologies que vous maîtrisez le mieux.

L'architecture
Un honeynet n'est pas un produit fini, il ne suffit pas d'installer un logiciel depuis un CD et d'y aller (quoique nous y travaillions :-). Un honeynet est une architecture, un réseau très sécurisé utilisé pour contenir et analyser le comportement des attaquants lâchés dans la nature. La manière de le déployer dépend de vous. Pour vous aider dans votre déploiement, nous avons écris le document Honeynet Definitions, Requirements, and Standards. Ce document n'est pas une notice technique, c'est plutôt une description de l'état de l'art définissant les pré-requis et la manière de construire un honeynet que les membres de la Honeynet Research Alliance sont supposés suivre. Cet article détaille une méthode de déploiement respectant ces contraintes.

Le composant crucial d'un honeynet est la passerelle, c'est elle qui sépare les systèmes composant le honeynet du reste du monde. La passerelle agit comme un sas, en fait nous l'appelons un Honeywall. Tout trafic entrant ou sortant du honeynet transite obligatoirement par ce honeywall. Cette passerelle est le quartier général de votre honeynet, tout se fait ici. Pour un honeynet GenII, notre passerelle est un pont (couche 2). Pour vous rendre compte à quoi l'architecture proposée ressemble, consultez la Figure A. Dans cet exemple notre honeynet est déployé sur le réseau 192.168.1.0/24. Par le passé, la plupart des honeynets était habituellement déployé sur des réseaux externes ou périphériques. L'utilisation d'une passerelle de couche 2, telle que la notre, permet d'intégrer les honeynets dans le réseau interne. Cela nous permet de pister et de comprendre non seulement les menaces externes, mais aussi les menaces internes.

Dans ce schéma, vous pouvez remarquer comment notre honeywall (la passerelle couche 2) sépare les systèmes en production, de notre réseau honeynet peuplé par nos cibles victimes. L'interface externe de notre passerelle (eth0) est connectée sur le réseau de production, tandis que l'interface interne (eth1) est connectée sur le réseau honeynet. Comme c'est un pont les systèmes internes et externes sont dans le même réseau IP. Nous disposons aussi d'une troisième interface (eth2). Elle est utilisée pour l'administration distante de la passerelle (ceci inclus le transfert de tous fichiers de log, ou de données capturées vers un point central. Les interfaces interne et externe étant en mode pont, on ne leur affecte pas d'adresse IP. A contrario, on affecte l'adresse 10.1.1.1 à la troisième interface eth2. Ce réseau séparé et sécurisé est notre réseau d'administration. L'avantage de cette architecture est l'extrême difficulté de détection de la passerelle, car il n'y a ni saut de routage, ni modification du TTL, ni adresse MAC associée à la passerelle. De plus nous pouvons simplifier le déploiement du honeynet en associant le contrôle et la capture des données uniquement sur la passerelle.

L'étape suivante est de construire une passerelle permettant cette architecture. Pour notre passerelle nous utilisons une installation minimale et sécurisée de Linux. Il est primordial que se soit un système de confiance, qu'aucun attaquant ne puisse accéder. Ensuite, nous devons faire en sorte que notre passerelle supporte le pontage (Ndt: bridging). La plupart des distributions Linux le supportent par défaut. Si le support du pontage est absent de notre système, il peut être récupéré sous forme de rpm ou en source depuis http://bridge.sf.net/.

gateway #rpm -q bridge-utils
bridge-utils-0.9.3-4

Malheureusement, alors que la plupart des distributions supportent le pontage, le support d'IPTables en mode pont est rarement présent. La présence d'IPTables est impérative, car non seulement il permet la sécurisation de notre passerelle, mais il est aussi utilisé pour le contrôle des données (voire le paragraphe approprié) Pour que vous puissiez utiliser IPTables dans le mode pont, vous devez d'abord patcher et recompiler le noyau pour activer cette fonctionnalité. De nouveau, ce correctif est disponible sur http://bridge.sf.net/. Une fois ceci fait, vous pouvez commencer la configuration de la passerelle. Cela est beaucoup plus simple que ça en à l'air. Le projet Honeynet a développé le script rc.firewall, qui implémente l'ensemble des éléments critiques de la passerelle. Nous y ferons référence tout au long de cet article. Pour notre passerelle, ce script défini le pontage, le pare feu, configure l'interface d'administration, contrôle qui peut administrer celle-ci, comment et où est enregistré l'activité réseau, et met en œuvre le contrôle de données. Vous remarquerez que ce script est critique, car il implémente la plupart des pré-requis du honeynet sur votre passerelle. Pour mettre en œuvre ce script (et par conséquent configurer votre honeywall) il vous suffit de renseigner les variables de celui-ci et de l'exécuter (NB: Veuillez lire l'article entièrement avant de lancer ce script) Plutôt que de vous décrire en détail chaque variable et ce qu'elle fait (C'est le travail du script), voici un lien vers le script utilisé dans l'architecture décrite ci-dessus. Une fois définit le script adapté à l'architecture de votre organisation, vous pouvez enchaîner avec le contrôle des données.

Contrôle des données
La finalité du contrôle des données est de s'assurer qu'un pirate ne puisse pas utiliser un système du honeynet pour attaquer ou casser un système extérieur à celui-ci. Le contrôle des données limite les risques. Cependant le défi est le suivant : à quel point faut-il contrôler l'activité sortante (NdT: du honeynet) ? Plus vous laissez de liberté aux pirates, plus vous pouvez en apprendre sur leurs modes opératoires, mais plus ils peuvent faire de dégâts à d'autres systèmes. Donc vous devez contenir leurs activités suffisamment pour qu'ils ne soient pas nuisibles à autrui, mais pas trop au risque de ne rien apprendre. La marge de manœuvre vers l'extérieur que vous laissez aux pirates dépend du risque que vous êtes en mesure d'assumer. Pour rendre ceci encore plus difficile, nous devons contenir l'attaquant sans qu'il ne s'en rende compte. Pour parvenir à nos fins, nous utilisons deux technologies : le dénombrement des connexions (Ndt Connection counting) et NIPS. Le dénombrement des connexions est la limitation du nombre de connexions sortantes issues du honeynet. NIPS (Système de prévention d'intrusion réseaux, Ndt Network Intrusion Prevention System) est là pour bloquer (ou déjouer) les attaques connues. La combinaison de ces technologies nous donne un mécanisme de contrôle des données puissant et flexible. Nous déployons ces technologies sur notre passerelle, car c'est le point par lequel tout trafic entrant ou sortant doit passer, c'est un point de contention de l'activité des pirates.

Une fois votre passerelle configurée de la manière décrite dans la première partie, l'étape suivante est de mettre en œuvre le bornage des connexions, pour limiter le nombre de connexions sortantes qu'un attaquant peut initier depuis un honeypot. Le but est de compter le nombre de connexions sortantes, et quand la limite définie est atteinte, de bloquer toutes connexions ultérieures. Pour cela nous utilisons IPTables, dont la configuration est définie dans le script rc.firewall mentionné précédemment. Dans le script nous définissons combien de connexions TCP, UDP, ICMP ou autre (OTHER) peuvent être établies par un pirate. Le nombre de connexions allouées dépend du risque que vous êtes prêt à prendre. En moyenne, le projet Honeynet en autorise 15 à 30 par jour. La limitation de nombre de connexions sortante empêche les attaquant de se servir du honeynet pour scanner, attaquer un grand nombre de systèmes, ou lancer des attaques de déni de service. Il est difficile de faire beaucoup de dommage dans ces conditions. Voici les valeurs par défaut utilisé dans le script rc.firewall. NB : la variable OTHER représente l'ensemble des protocoles non couvert par TCP, UDP et ICMP (par exemple : IPsec, IPv6 tunneling, Voix sur IP, etc).

C'est ainsi que le bornage des connexions est défini dans rc.firewall. Quand un attaquant a fait son trou dans le honeypot, il peut établir des connexions vers l'extérieur pour différentes raisons (téléchargement de boite à outil, configuration de robot, causerie IRC, envoie de mail, etc). Chaque connexion établie vers l'extérieur, est comptée par le pare-feu. Quand la limite est atteinte, IPTables bloque les connexions suivantes issues de cet honeypot. Puis IPTables se réinitialise une fois la période définie dans la variable SCALE écoulée, permettant alors les connexions externes dans les limites définies. Par exemple, admettons que nous avons défini la limite du nombre de connexions TCP sortantes à 25, quand un attaquant pénètre notre honeypot, il peut initier 25 connexions TCP sortantes, une fois cette limite atteinte il est coincé. Après réinitialisation d'IPTables, 25 connexions sont possibles durant la période définie, dans notre cas 24h, soit 1 connexion par heure en moyenne. Si notre période était d'une heure, nous autoriserions 25 connexions par heure ou une connexion toutes les 2,4 min en moyenne. Voici un exemple concret, dans ces journaux d'IPTables , de ce comportement pour un honeypot Win2000 infecté par le ver Code Red II qui tente un scan sortant. Une fonctionnalité intéressante d'IPTables est l'indépendance de traitement entre les divers protocoles, une fois les limites atteintes pour TCP, les autres types de trafic (UDP, ICMP, OTHER) ne sont pas impactés tant qu'ils n'ont pas atteint leur propre limite.

Une fois le bornage des connexions mis en place dans le script rc.firewall, passons à la mise en place du NIPS. Pour mémoire, le but de NIPS est d'identifier et de bloquer les attaques connues. Ceci est fait en analysant chaque paquet traversant notre passerelle. Si un paquet correspond à une règle de notre IDS (Intrusion Detection System, NdT: système de détection d'intrusion), une alerte est déclenchée (comme dans un IDS traditionnel), de plus le paquet peut être supprimé (bloquant alors l'attaque), ou modifié (la rendant inefficace). L'avantage est que cela réduit considérablement les chances de succès d'une attaque vers l'extérieur. Avec le dénombrement de connexions, nous autorisons par défaut 15 connexions TCP sortantes par jour, que se passe-t-il si nous sommes infectés par un ver, et que ces 15 connexions soit des essais de contamination d'autre systèmes ? Alors que la limitation imposée réduit le nombre de systèmes pouvant être contaminés, le risque est toujours présent. L'idée du NIPS est qu'il bloque, ou désactive, toutes attaques identifiées dans ces 15 connexions. Pour cela le projet Honeynet utilise Snort_inline, une version modifiée de Snort qui peut supprimer ou modifier les paquets.

Pour que snort_inline fonctionne comme un NIPS (en mode pont), il faut qu'il dispose d'un mécanisme lui routant les paquets, en effet snort_inline ne sait pas prendre de décision de routage (ip_forward). Donc nous utilisons un mécanisme, qui pendant le processus de routage transfère le paquet à snort_inline pour analyse. Une fois l'analyse effectuée, snort_inline rend le paquet au processus de routage. Ce processus est IPTables. Nous configurons IPTables pour envoyer les paquets qu'il traite vers snort_inline pour analyse, puis IPTables continue le routage des paquets. Cette fonction d'IPTables est appelée "user-space queuing", car elle nécessite le chargement du module ip_queue dans le noyau. Pour mettre en place cette fonctionnalité, nous autorisons QUEUE dans notre script rc.firewall (Cela permet aussi le chargement du module ip_queue). En combinant snort_inline et les possibilités de comptage d'IPTables, il faut garder à l'esprit qu'IPTables compte les connexions sortantes indépendamment des décisions de snort_inline concernant les paquets. Cela est du au fait que les paquets transitent d'abord par l'interface interne avant d'être analysés par snort_inline. La connexion est comptée avant que snort_inline aie eu le temps de l'analyser.

Pour notre déploiement, nous utiliserons la base de règles drop-rules et notre fichier de configuration snort_inline.conf dans /etc/snort_inline. Nous utilisons un répertoire différent de /etc/snort pour éviter les confusions. Pour démarrer snort_inline, nous utilisons le script suivant : snort_inline.sh. Ce script est pré configuré pour un démarrage facile de snort_inline. Pour vous simplifier la vie, l'ensemble des fichiers de configuration, des scripts et des binaires sont disponibles dans la boite à outils Snort_Inline de Honeynet. L'utilisation de cette boite à outils doit GRANDEMENT vous faciliter la mise en place de snort_inline. Gardez à l'esprit que la combinaison de ces technologies réduit drastiquement les risques, mais qu'elle ne les élimine pas. Chaque fois que vous laissez la porte ouverte aux pirates, cela peut mal tourner. C'est pourquoi dans la dernière partie nous expliquons comment tester ces technologies. Malgré cela, l'évolution des outils et des techniques des pirates, fait que l'on n'est jamais complètement en sécurité.

Capture de données
Une fois le contrôle de données mis en place, nous pouvons déployer la capture de données. Le but de la capture de données est de tracer l'activité des pirates. La collecte d'information est la raison d'être du Honeynet. Sans la capture de données, notre Honeynet n'a aucune valeur ajoutée. La clé de la capture de données est de collecter l'information dans autant de couches que possible. Chaque niveau nous apporte son lot d'informations. Par exemple, beaucoup de monde pense qu'il suffit d'avoir le journal des saisies clavier de l'attaquant, hélas ce n'est pas vrai. Que se passe-t-il si le pirate lance un programme, comment saurez vous ce qu'il fait, si vous ne capturez pas le programme ou le trafic réseau qu'il génère ? Le projet honeynet a identifié trois couches critiques de capture de données : les journaux des pares-feux, le trafic réseau, et l'activité sur le système. Nous détaillons comment mettre en place les trois dans la suite de ce chapitre.

Pour les journaux de pare feux, le travail a déjà été fait. De part la mise en place du script rc.firewall, nous journalisons l'ensemble du trafic entrant et sortant dans /var/log/messages. Cette information est vitale, car c'est la première piste dont nous disposons pour savoir ce que fait un attaquant. C'est aussi de là que viennent les premiers signes d'une tentative d'attaque sortante. L'expérience acquise lors du Projet nous enseigne que les journaux des pare feux sont précieux pour identifier rapidement les attaques nouvelles ou les comportements inhabituels. Le script défini quatre types de trafic : TCP, UDP, ICMP, et OTHER. De la même manière que dans le contrôle des données, OTHER rassemble les trafics IP de type 1, 6 ou 17 non couvert par les protocoles précédents. C'est aussi le type le plus intéressant, car si ce type de trafic IP non standard est utilisé, il est fortement probable que ce soit pour essayer de nouvelles techniques d'attaque (comme dans le cas de la porte dérobée (NdT : backdoor) NVP employée dans Scan of the Month 22).

La deuxième étape est la capture complète de chaque paquet entrant ou sortant du honeynet. Il est concevable d'utiliser snort_inline pour cette tâche, cependant pour ne pas mettre tout nos œufs dans le même panier, nous utiliserons snort à la place. Nous mettons en place la configuration standard du Projet décrite dans le fichier de configuration snort.conf. Avec ce fichier de configuration, tout le trafic IP est capturé vers un fichier de log au format tcpdump pour analyse ultérieure. Nous voulons aussi assurer la rotation de ces fichiers de log, pour cela nous utilisons le script de démarrage snort.sh. Ce script est lancé chaque jour par l'intermédiaire de la crontab. Notez que nous activons la capture sur l'interface interne eth1. Ce point est important, car si par erreur la capture est activée sur l'interface externe (eth0) vous enregistrez non seulement les données relatives au honeynet, mais aussi tous les trafics vers le réseau externe, ce qui pollue la capture. En se positionnant sur l'interface interne, vous ne capturez que le trafic concernant le honeynet, ce qui est exactement ce que vous voulez. L'utilisation de ce script a un autre avantage, il standardise la manière avec laquelle les données capturées sont loguées, ce qui est extrêmement important si vous avez plusieurs honeynets capturant les données vers un dépôt central. (voir la suite de l'article).

La troisième phase, qui est aussi la plus difficile, est de capturer l'activité du pirate directement sur le système. Il y a quelques années cela était simple, la plupart des interactions se faisant alors par l'intermédiaire de protocoles en clair tel que FTP, HTTP ou telnet. Il suffisait de tracer la connexion pour identifier les saisies clavier. Cependant les pirates ont adopté l'utilisation de protocole crypté tout comme vous. Aujourd'hui il est probable qu'il utilise des canaux SSH ou 3DES pour communiquer avec les ordinateurs compromis. Nous ne pouvons donc plus déduire les commandes utilisées des traces réseaux, nous devons donc les capturer directement depuis le système. Pour résoudre ce problème le Projet a développé Sebek2. C'est un module noyau qui peut tracer les saisies clavier d'un attaquant et capturer les fichiers téléchargés via scp. Une fois installé sur un honeypot, ce module se cache, le rendant presque impossible à détecter et à désactiver. Les informations rassemblées par Sebek2 ne sont pas stockées sur le honeypot, où elles pourraient être découvertes par l'attaquant. Sebek2 transmet ces informations via UDP vers une machine à l'écoute (tel que notre passerelle ou un système distant de centralisation des logs) Les pirates ne peuvent ni voir, ni capturer ces paquets, car le module noyau installé sur le honeypot se charge de les cacher. Même si un attaquant télécharge ses propres outils de capture, l'activité de Sebek2 lui est cachée. Cela est fait en modifiant le honeypot de telle manière qu'il ne puisse ni voir ni capturer les paquets avec une adresse MAC source pré configurée. Sebek2 envoie alors les données capturées vers la passerelle avec l'adresse MAC source spécifiée. Comme l'ensemble des honeypots est contrôlé avec Sebek2, aucun d'entre eux ne peut être utilisé pour capturer les saisies clavier envoyées sur le réseau. Attention, si l'un de vos honeypots n'utilise pas Sebek2, un attaquant peut alors l'utiliser pour capturer les paquets générés par Sebek2 en provenance des autres systèmes.

Sebek2 étant un module noyau, il faut le compiler pour prendre en compte les spécificités de versions de noyau et d'OS de votre honeypot. L'installation de Sebek2 est relativement simple, il suffit de configurer cinq options dans le script d'installation. Voici ci-dessous les paramètres que nous utilisons. Leur signification est la suivante : les saisies clavier capturées sont envoyées dans des paquets UDP à destination de l'IP 192.168.1.254 (notre routeur) et du port 34557. Cependant, un attaquant ne les verra pas, car le noyau cache les paquets en provenance des adresses MAC commençant par 0A:0B:0C: (Sebek2 n'analyse que les trois premiers octets de l'adresse MAC) Cette configuration doit être identique pour l'ensemble des honeypots, afin qu'ils ne puissent pas voir le trafic de leurs voisins. Le Projet travaille actuellement au portage de Sebek2 vers Solaris, OpenBSD et Win32. Ces paquets n'arriveront jamais jusqu'au routeur, car notre passerelle les intercepte. Vous pouvez adapter ces options de telle sorte qu'elles correspondent à votre Honeynet. Par exemple, si vous voulez loguer les paquets vers un système distant sur un autre réseau, vous indiquerez l'adresse IP du système distant et l'adresse MAC du routeur local. Veillez à utiliser le script d'installation sebek.sh, car après l'installation du module sebek, il déploie un module de nettoyage dont le rôle est de cacher la présence de sebek.

Une fois configuré, Sebek2 envoie toute activité système vers le réseau. Ces paquets, qui ne peuvent être vus par les honeypots, sont collectés par la passerelle sur l'interface interne eth1. Ils sont alors utilisés pour reconstruire les saisies clavier de l'attaquant ou les fichiers que celui-ci peut avoir transférés. Notre honeynet dispose d'un avantage supplémentaire, grâce à son interface sur le réseau d'administration, il peut directement envoyer les données vers un serveur dédié. Cela est extrêmement avantageux si vous avez plusieurs honeynets. La combinaison des données provenant de systèmes multiples peut être utilisée à des fins d'alertes précoces, de prédictions, d'analyses statistiques, d'identification de nouveaux outils ou de nouvelles tendances. Le Projet Honeynet utilise ce script pour envoyer automatiquement les données quotidiennes.

Alerter
Le dernier élément à prendre en compte avant d'achever votre Honeynet est l'envoi automatique d'alertes. Voir quelqu'un à l'œuvre dans votre Honeynet est une expérience pleine d'enseignements, sauf si vous n'avez pas conscience de l'événement. S'assurer d'être prévenu d'une intrusion réussie (et y répondre) est indispensable pour le succès d'un Honeynet. Idéalement, vous disposeriez d'une supervision 24/24 par un administrateur confirmé. Avec les outils adéquats correctement configurés, cela ne sera pas nécessaire. Nous avons eu de grande satisfaction en utilisant Swatch, the Simple Watcher, pour superviser nos Honeynets. Swatch est un outil de supervision automatique complet capable de notifier les administrateurs lors d'une attaque potentiellement réussie. Swatch surveille les fichiers de log à la recherche de motif décrit dans un fichier de configuration. Quand un motif est identifié, Swatch propage nativement l'alerte par mail, bip système, appel téléphonique et peut être étendu pour lancer d'autres commandes ou programmes. Un fichier de configuration simple de Swatch contient, le motif à rechercher, suivi d'une liste d'actions à entreprendre. L'exemple de configuration suivant est basé sur Swatch 3.0.

L'action "mail=" contient la liste des adresses de messagerie, auxquelles envoyer l'alerte. La commande throttle limite le nombre de fois où l'action de la règle est effectuée par Heure:Minute:Seconde. Cela est utile pour éviter la saturation de votre boîte aux lettres lors du déclenchement d'une règle. La configuration ci-dessus supervise le fichier /var/log/messages, où IPTables enregistre l'ensemble des connexions entrantes et sortantes. Notre fichier de configuration recherche les connexions sortantes, ce qui est un indicateur performant de la compromission d'un Honeynet. Quand cette signature est repérée, un mail est envoyé à l'administrateur du honeynet. Dans ce cas, les messages d'alerte sont limités à 10 par heure. Les motifs recherchés et les actions entreprises peuvent varier d'un honeynet à l'autre. L'important n'est pas de maîtriser les rouages des fichiers de configuration de Swatch, mais de comprendre les événements qu'un administrateur de honeynet ne doit pas rater et l'information qu'il faut associer à chaque alerte. Les sources d'information les plus utiles pour rechercher les activités hostiles sont les journaux du pare feu et ceux de snort_inline.

Depuis le pare feu :
Les connexions sortantes d'un honeypot sont un bon indicateur d'une intrusion sur une machine. Comme il n'y a pas d'utilisateur autorisé dans le honeynet, un trafic sortant de ce réseau vient probablement d'un intrus. Il peut y avoir parfois de faux positifs (tel qu'une connexion Ident issue de votre serveur FTP). Cependant, en général, c'est l'un des meilleurs indices de la compromission d'un honeynet et qu'une activité malicieuse potentielle y prend place. Vous ne voudrez peut être pas limiter le nombre d'alertes sur connexions sortantes. Le nombre d'alertes que vous pouvez recevoir est en lui-même un indice du type d'activité tentée par un pirate. Une autre option est de surveiller aussi l'activité générée par Sebek2 dans les journaux de votre pare feu. Les paquets Sebek2, logués sur le Honeywall, indiquent clairement que quelqu'un est dans votre honeypot.

Depuis le NIPS :
Ainsi que décrit précédemment, l'objectif du NIPS (nous utilisons snort_inline) est de détecter et de bloquer les attaques sortantes. Il peut être très important de remonter cette information. Vous pouvez configurer votre mécanisme d'alerte (tel que Swatch) pour surveiller les journaux de snort_inline en plus des journaux de votre pare feu. Si une attaque sortante est détectée (et bloquée), vous serez prévenu immédiatement.

Le but de l'automatisation des alertes est de fournir autant d'informations que possible à l'administrateur pour que celui-ci puisse intervenir dans le cas d'une attaque fructueuse. Toute alerte envoyée depuis Swatch doit au minimum contenir les adresses source, destination et le port du paquet reconnu, la date et l'heure de l'évènement, et suffisamment d'informations pour que l'administrateur puisse intervenir immédiatement. Par défaut, Swatch inclus la ligne du journal ayant déclenchée la règle dans le message. Voici un exemple de mail généré par la règle ci-dessus:

Même avec les outils automatiques décris dans le paragraphe "Contrôle des données", un honeynet doit être constamment supervisé pour être efficace. Correctement configuré, Swatch peut être utilisé pour avertir rapidement les administrateurs des événements affectant sur leur réseau.

Tester
Maintenant que nous avons configuré le contrôle et la capture des données, il nous reste à tester la passerelle. Pour la tester, nous utilisons un système extérieur, appelé système de test. En se basant sur la Figure A, nous utilisons le système 192.168.1.20 comme système de test. Pour commencer, nous testons le contrôle des données : notre honeynet réussit-il à contenir l'activité entrante et sortante? Premièrement, initions une connexion vers un des honeypots du honeynet. Au vu de notre base de règles, cette connexion devrait être autorisée. Dans ce cas, vous observez une ligne similaire à la suivante dans /var/log/messages.

Une fois la connectivité entrante vérifiée, testons les flux sortants. Connectez vous a l'un des honeypots protégés par la passerelle (nous recommandons une connexion depuis la console, car le honeypot trace l'ensemble des connexions distantes, telle que SSH). De là, initiez plusieurs connexions sortantes vers le système de test. Cela simule le fait qu'un des honeypots soit compromi, et qu'un pirate essaye de se connecter vers l'extérieur et tente potentiellement une attaque. Ces connexions doivent être loguées dans /var/log/messages sur le Honeywall. Dans notre cas, nous essayons des connexions FTP sortantes vers le système de test sur le réseau de production. Quand la limite de 15 connexions TCP est atteinte, une entrée "Drop TCP" est loguée. Vous observez probablement des lignes similaires à celles-ci :

Ensuite, vérifions le fonctionnement de notre NIPS snort_inline. Heureusement, notre base de règles drop-rules contient une règle de test spécialement prévue à cet effet. Vérifiez que ces règles sont actives avant de tester snort_inline. La base de règles utilisée détermine les tests à passer. Si vous utilisez la base de règles drop-rules, activez simplement la règle de test "drop" et redémarrez snort_inline avec le script snort_inline.sh, puis essayez une connexion telnet sortante. Snort_inline doit détecter, supprimer et loguer la tentative. Votre connexion telnet ne fonctionne pas et se termine en timeout. Si vous utilisez la base de règles replace-rules, activez la règle de test "replace" et redémarrez snort_inline, puis essayez une commande HTTP GET. Snort_inline doit détecter, modifier et loguer la tentative. Pour vérifier que la modification est effective, analysez le trafic de l'interface EXTERNE eth0, en effet la modification du paquet intervient après le passage par l'interface interne et avant le passage par l'interface externe. Une fois les tests terminés, remettez en place la base de règles prévue et désactivez les règles de test. (sans quoi les pirates pourraient eux aussi utiliser ces règles de test).

Une fois le contrôle des données vérifié, passons à la capture de données. Rappelez vous que si notre honeynet ne logue pas toutes activités alors il ne sert à rien. Nous vérifions la capture de données en inspectant les journaux : le honeynet a-t-il capturé les tests que nous venons de faire sur le contrôle des données ? Commençons par les journaux du pare feu. Ce test est simple, toutes nos connexions doivent être loguées dans /var/log/messages. Premièrement, nous devrions voir la connexion entrante depuis le système de test vers le honeypot. Deuxièmement, nous devrions voir les connexions sortantes du honeypot vers le système de test. Finalement, nous devrions voir un message d'alerte indiquant que la limite de connexions sortantes est atteinte, et les connexions suivantes sont supprimées. Ceci a déjà été testé lors de la vérification du contrôle des données.

Ensuite passons en revue les journaux réseau. Nous voulons vérifier que nous avons bien capturé complètement chaque paquet de chaque connexion entrante et sortante. Ces journaux doivent être dans /var/log/snort/$DAY comme indiqué dans notre script de démarrage, la variable $DAY désignant le jour en cours. En se basant sur notre expérience, le jour est la période la plus pratique pour la rotation des fichiers de log. En ce qui nous concerne, les logs se trouvent dans /var/log/snort/Mar_23. Le fichier qui nous intéresse ici, est la capture binaire stockée dans le fichier "snort.log.*". Vous pouvez trouver accessoirement divers répertoires nommés d'après les adresses IP. Ils contiennent les textes ASCII, tels que commandes FTP, pages html, se trouvant dans les paquets capturés. Pour confirmer que snort a correctement capturé tous les paquets, procédez à l'analyse du log binaire comme suit :

Enfin, contrôlons les journaux de Sebek2. Ils contiennent les saisies clavier capturées par le module noyau Sebek2 et envoyées sur le réseau. Ces paquets doivent aussi être capturés par notre analyseur réseau (Snort) et se trouvent par conséquent dans le fichier de log que nous venons d'analyser. Voir ci-dessous les commandes pour récupérer et analyser les données. Nous utilisons en premier sebeksniff pour la récupération des données. Sebeksniff crée un fichier séparé pour chaque honeypot (en se basant sur l'adresse IP) dans /var/log/sebek. Ensuite, nous pouvons analyser chaque honeypot pour identifier les saisies ou les transferts scp.

Et voilà ! Si vous avez pu analyser les données collectées, votre capture de données fonctionne correctement ! Vérifiez aussi votre boîte aux lettres, vous devriez avoir reçu les alertes (envoyées par Swatch) correspondant aux tests effectués. Maintenant et comme vous êtes un vrai professionnel de la sécurité, nous savons que vous allez rebooter votre passerelle honeynet et vérifier le contrôle et la capture des données une fois de plus, ceinture et bretelle :-)

Conclusion
Nous avons terminé la construction et le déploiement pas à pas d'un honeynet GenII, basé sur une passerelle filtrante sous Linux. Ce déploiement est l'une des fonctions les plus en pointe de la technologie des honeynets. Dans le futur, nous souhaitons développer et fournir des interfaces graphiques pour l'administration du honeynet et l'analyse des données qu'il collecte. Nous envisageons aussi de fournir une distribution Honeywall sur CD bootable contenant l'ensemble des fonctionnalités que nous venons de présenter.