Compte-rendu de la réunion du 29 mars 2004 ------------------------------------------ - Présentation du Greylisting (www.greylisting.org), Fabrice Prigent Initialement prévu pour la lutte anti-spam, le greylisting se révèle aussi intéressant pour la lutte anti-virus. Le principe repose sur la supposition que les spammeurs (et moteurs SMTP des virus) ne respectent pas totalement le protocole SMTP : lors d'un rejet temporaire d'un message, ledit message (spam/virus) est perdu et non pas mis en file d'attente pour une tentative ultérieure. Quand un message (triplet [IP relais, @émetteur, @destinataire]) arrive sur le MX faisant du greylisting, s'il s'agit d'un nouveau triplet (absent d'une base de données locale), le message est rejeté temporairement (erreur 450, retry later). Si le message est reçu de nouveau après un certain délai configurable, il est accepté. Cela signifie qu'un véritable serveur SMTP se situe à l'autre extrémité de la communication. La mise en place du Greylisting doit se faire sur le MX frontal de l'organisation. Elle demande une dizaine d'heures de travail, et des réglages assez fréquents. Du fait du principe même (rejet temporaire de messages), le greylisting ajoute un véritable temps de latence dans la transmission des messages. Attention donc à la supposition de l'acheminement instantané des messages, souvent faite par les utilisateurs. Toutefois, ce délai de latence n'apparaît que pour les "nouveaux" messages (triplet IP, émetteur, destinataire absent de la base locale). Les communications courantes ne sont donc que faiblement impactées. Documents fournis par Fabrice Prigent ===================================== http://www.ossir.org/resist/supports/cr/20040329/actualites.pdf http://www.ossir.org/resist/supports/cr/20040329/greylisting.tar.gz Présentations sur les systèmes de détection / prévention d'intrusions. ====================================================================== Un peu de vocabulaire (utilisé par Fabrice Prigent et/ou Benjamin Marandel) : IDS : le système fonctionne sur une copie du trafic. Il ne peut générer que des alertes, la détection est donc a posteriori. IDS actif : le système fonctionne sur une copie du trafic. Au mieux, il peut émettre un TCP/RST (donc uniquement sur TCP) et, dans tous les cas, le paquet "litigieux" a déjà atteint la cible. Si ce paquet suffit en lui-même pour déclencher une faille, c'est trop tard. IPS en coupure : l'outil est à même d'agir avant de transmettre le paquet, sur tous les protocoles. Cependant, le suivi des sessions nécessite des tables d'état en mémoire, et donc un bon dimensionnement de l'UC et de la mémoire vive du système. - Présentation de SNORT, Fabrice Prigent Un reproche qui remonte de la présentation est la grande quantité de faux positifs remontée par l'outil, ainsi qu'une forme d'instabilité des règles entre les versions. Les faux positifs obligent à un travail important de "nettoyage" des règles, et à une configuration fine de l'outil d'analyse des résultats. Si ces deux opérations ne sont pas faites correctement, l'utilisateur peut rapidement être noyé sous les alertes - et n'en traiter aucune. Comme tout système de détection/prévention d'intrusion, l'emplacement de la sonde est très important. Cet emplacement influe aussi directement sur le nombre des alertes relevées par SNORT. Il s'agit d'un choix qui doit être bien réfléchi. Documents fournis par Fabrice Prigent ==================================== http://www.ossir.org/resist/supports/cr/20040329/Snort.pdf - Présentation de l'analyse protocolaire dans ISS, Benjamin Marandel La présentation met l'accent sur la politique de détection d'ISS, qui vise à mettre à jour les signatures d'attaques dès qu'une faille ou vulnérabilité est signalée, et non pas lors de l'apparition d'une utilisation d'une faille/vulnérabilité. Cette manière de procéder permet de détecter (sans être capable de les qualifier de manière fine) toute nouvelle attaque reposant sur une vulnérabilité connue. Lorsqu'un outil exploitant une telle faille apparaît, la base de signatures est alors affinée, ne serait-ce que pour fournir l'information quant au vecteur précis utilisé. Toutefois, le délai entre l'information d'une vulnérabilité (et la mise à jour préemptive de la base de signatures d'ISS) et l'apparition d'un outil exploitant cette vulnérabilité tend à diminuer de manière importante (plusieurs mois pour Slammer; à peine deux semaines pour Blaster). URLs transmises par M. Marandel : Documents techniques ==================== FAQ IDS de Robert Graham http://www.robertgraham.com/pubs/network-intrusion-detection.html Document sur l'écriture d'un IDS par Robert Graham http://www.robertgraham.com/pubs/ids/how-to-detect-intrusions.html Outils de test d'IDS avec evasion par Robert Graham http://www.robertgraham.com/tmp/sidestep.html Documents techniques ISS ======================== Rapport IRIS https://gtoc.iss.net/documents/summaryreport.pdf Le disclosure agreement http://documents.iss.net/literature/vulnerability_guidelines.pdf Les whitepapers de la XForce http://www.iss.net/support/documentation/whitepapers/xforce.php Documents marketing =================== http://www.iss.net/support/documentation -- Pierre-Yves Bonnetain B&A Consultants - Sécurité informatique - www.ba-cst.com