On recommence. Ce sujet est ici un véritable marronnier. Il revient très, très régulièrement. L'ids excite beaucoup de monde.
Je me lance sur IPCop pour installer un IDS en coupure entre notre réseau local et l'Internet, sachant qu'IPCop ne sera pas en connexion directe sur le Net, il y a un autre firewall avant qui fait du load balancing sur 2 box ADSL.
Mon but avec IPCop c'est avant tout de l'utiliser comme IDS avec snort. Je l'ai installé en tests et ça tourne correctement. Par contre, j'aimerai être averti par mail des alertes remontées par snort au lieu d'avoir à jeter un oeil sur la page des logs de snort régulièrement.
Je suis désolé de vous dire cela,mais il n'y là que de fausses bonnes idées. En même temps si vous venez ici, nous n'allons pas vous répondre uniquement pour vous dire ce qui vous ferait plaisir, mais essayer de vous donner des éléments de réflexion.
un IDS en coupure entre notre réseau local et l'Internet,
En coupure ? un ids en coupure je ne comprend pas ce que cela signifie. Un IDS ne coupe rien, il observe et en fonction de certains crières, les règles activées, dans Snort, il alerte. Eventuellement, via un greffon de sortie, il peut agir sur le firewall. Prudence, prudence !!
il y a un autre firewall avant
Le vrai problème est que voulez vous observer ? Quelles sont, dans votre cas, les menaces importantes ?
Est il pertinent de regarder une porte close (ou de constater qu'elle a été forcée) plutôt que d'observer de l'extérieur qui commence à rôder autour de la porte ? je vous laisse méditer cette question qui renvoie au placement de la ou des sondes.
http://www.snort.org/docs/iss-placement.pdf et
http://snort.org/docs/100Mb_tapping1.pdfMon but avec IPCop c'est avant tout de l'utiliser comme IDS avec snort.
Intention potentiellement légitime mais si c'est le but alors Ipcop n'est pas l'outil qui convient. Ajouter un nat de plus à son réseau juste pour utiliser Snort n'est pas sérieux. Une fois résolu le problème du placement de la ou des sondes (attention le danger est aussi très souvent à 'intérieur du réseau), vous comprenez que la sonde doit se faire discrète et surtout ne pas répondre à une ip. Un switch avec un port span est un bon début. Trop facile pour un agresseur la noyer, de l'éluder, de vous submerger de fausse alertes. Que faites vous avec 500 mails d'alertes reçu à 3h00 du matin ? Si vous êtes vraiment une cible et que votre agresseur est un bon alors vous découvrirez les dégats de la nuit du vendredi au samedi en arrivant lundi matin. Et si il est très bon vous ne découvrirez rien du tout dans le config que vous envisagez. Vos informations auront été pillées depuis longtemps.
Snort est détectable contrairement à ce que l'on pourrait penser.
Utiliser snort signifie, pour moi, une sonde indépendante et une console de gestion. En pratique c'est aussi pas mal de besoin matériel comme des switchs avec la possiblité de configurer un port span où brancher la sonde. Sans compter les besoins humains pour l'exploitation de Snort.
Une base de départ c'est un port span (sur le switch) par point de surveillance, ce port est connecté à une machine comportant autant de cartes réseaux (ip 0.0.0.0) que de points à surveiller, plus une. Cette machine fera tourner Snort, une base SQL et la console Base (ça c'est une bonne idée). Avec la carte réseau qui reste vous pourrez vous connecter à la console. Le tout sur une machine dédiée avec un OS un peu durçi, sur un lan séparé, accessible via un vpn par exemple ou au moins un vlan isolé.
Je pense que coté perfs ça devrait tenir, le serveur qui fait tourner IPCop est assez puissant pour ça et j'ai peu de machines clientes derrière
Le problème n'est pas le nombre de machines derrière mais le volume de data qui va se présenter sur les interfaces surveillées. C'est ce volume là qui va déterminer la charge réelle à laquelle Snort va être confronté. Si vous manquez des paquets pour cause de saturation, autant prendre des vacances.
Tout cela n'est rien. C'est de la cuisine et en quelques heures (dizaines d'heures ) de travail c'est en place. Le vrai problème c'est l'exploitation de Snort.
Si vous ne configurez pas votre IDS avec les règles adaptées à vos systèmes (inutile de détecter les attaques visant IIS ou SQL server si vous n'avez aucun de ses produits sur votre réseau), vous aurez beaucoup d'alertes inutiles. IDS Policy manager est un bon outil de gestion des règles.
Je ne crois pas à une exploitation de Snort avec des alertes par mail, ou alors pour l'exercice. Dans les datacenter les consoles Snort et autres Nagios sont sous les yeux de personnes qualifiées 24/7, toute l'année. Exploiter Snort c'est, entre autre, analyser constament les logs. Et vite. Néanmoins SAM peut rester un outil utile. Une tentative d'intrusion n'est pas un événement binaire. Je ne parle pas de l'ado boutonneux qui tente un telnet sur votre port 23. Avant une véritable tentative, il y a des signes avant coureur mais très dilués, sur des jours voire des semaines. L'agresseur à besoin de connaitre votre réseau et de collecter des informations. Si il est un peu malin, je doute qu'il se lance bille en tête dans un scan de port. Il faut aussi écarter les faux positifs, affiner les règles, voire construire celles qui vous manquent. Les mettre à jour.
Bref il faut beaucoup de moyens humains.
Maintenant je ne sais pas ce que vous avez de si précieux à protéger. Il y a peu être mieux à faire pour améliorer votre sécurité ?
En vrac :
http://forums.ixus.fr/viewtopic.php?t=4 ... =ids+snort
http://www.oreilly.com/catalog/snortids ... T=snortids
et incontournable : snort.org
Désolé, nous sommes en Novembre et ce n'est pas encore l'heure du père Noel. Cela dit c'est un sujet passionnant et pour des raisons didactiques, si vous avez le temps, allez y, mais pas avec Ipcop. Je dois avoir un document sur l'installation de a à z d'une plateforme de ce genre. Si cela vous tente...
