Interview with Eric Leblond on Suricata, IDS and Security

Question : Bonjour Eric Tu viens présenter l’avancement du projet d’IDS/IPS open source Suricata pour lequel tu es un des développeurs principaux. Peux tu tout d’abord nous présenter rapidement ce projet et ses principaux éléments différentiateurs avec ses concurrents libres ou propriétaires ?

Eric Leblond : Suricata est un IDS/IPS réseau qui a été développé depuis zéro sous l’impulsion de Victor Julien qui reste développeur principal et leader du projet. Il appartient à la même famille d’IDS/IPS que snort dont il a repris le langage de signatures. L’idée derrière ce choix était de permettre de reprendre les jeux de signatures existant qui sont souvent la vraie richesse d’un IDS de ce type. Avec un développement commencé en 2008, Suricata a une base de code moderne et a pris le partie d’utiliser des technologies récentes. Une des principales conséquences a été l’utilisation du multithreading. Suricata est ainsi capable de tirer avantage des architectures multicores qui sont incontournables actuellement. Un des autres points forts de Suricata est la détection automatique de protocoles et les mots clés protocolaires. Pour donner un exemple concret, Suricata va déterminer automatiquement qu’un flux sur le port 3456 est du HTTP et il appliquera alors les signatures HTTP sur le flux. Celles-ci peuvent utiliser des mots clés comme http_body ou http_uri qui recherche des correspondances dans les versions normalisées des flux pour ce protocole. Il n’y a donc pas besoin de chercher manuellement le décalage pour ces champs dans les requêtes et toutes les subtilités du protocole HTTP (comme le chuncking) sont gérées de manière transparente.

Question : quels sont les axes sur lesquels tu interviens le plus ? quels outils et langages utilises-tu ?

Eric Leblond : Je suis responsable de la partie acquisition de paquets, ce qui signifie que je gère les modes IPS et IDS et le support des différents modules d’entrées (pcap, AF_PACKET, pf_ring, Netfilter, ipfw). J’interviens aussi sur la partie journalisation et je participe avec Pierre Chifflier au développement du support du protocole TLS. Au niveau du langage c’est exclusivement du C. L’intégralité de Suricata étant développée avec ce langage si l’on excepte la partie système de build qui utilise les autotools et leur fabuleux m4. Un des points plus mineurs et exotiques sur lesquels je sois intervenu est l’ajout de tests sur le code. Il s’agit de tests utilisant l’excellent logiciel coccinelle (http://coccinelle.lip6.fr) et qui réalise une vérification de la conformité du code à des règles de programmation définies lors du développement (non utilisation de certaines fonctions interdites, utilisation conforme de certaines structures complexes).

Question : De part tes développements précédents, tu es un développeur Netfilter expérimenté. As-tu beaucoup réinvesti de cette expérience dans Suricata ? Est-ce qu’il y a eu des échanges entre les 2 communautés ?

Eric Leblond : C’est plus mon expérience sur le projet NuFW qui m’a servi pour les développements sur Suricata qui a parfois des "problèmes" que nous avions dû régler sur NuFW. Concernant Netfilter, il y a réellement un réel échange. J’ai notamment exposé lors du dernier Netfilter Workshop certains des besoins de Suricata.

Question : De manière plus globale, toi qui est un professionnel de la sécurité depuis longtemps maintenant, penses tu que les IDS/IPS ont prouvé leur utilité en entreprises ou pour les gouvernements ? Doivent ils en partie se réinventer ? Ou le succès du déploiement d’un IDS/IPS dépend-il finalement que des objectifs que l’on fixe à ce projet (ex. : syndrome de l’outil unique qui doit tout résoudre en termes de sécurité) ?

Eric Leblond : L’IDS est bien loin de pouvoir prétendre à être un outil unique. Les informations remontées par les serveurs et notamment les journaux contiennent énormément d’informations précieuses. Je pense qu’il est nécessaire de concevoir la surveillance des systèmes de manière globale. Je suis peut-être marqué par mon expérience avec Prelude mais je ne pense pas être dans le faux. Cette façon de voir implique des coûts. Le traitement des alertes et la mise à jour des signatures (incluant l’écriture de signature dédiée) sont deux taches cruciales. Elles doivent être effectuées de manière régulière pour être vraiment utile. Sans temps et sans compétence réelles affectées sur ces taches, un IDS est complètement inutile. Il peut même être néfaste dans le cas d’un IPS mal configuré ou non maintenu.

Question : Ce projet a une particularité notable dans le fait qu’il a été fondé et est soutenu par un certain nombre d’agences gouvernementales et d’éditeurs. Peux tu nous éclairer sur ce point ainsi que sur les avantages et les inconvénients éventuels que tu y vois, toi qui est à l’intérieur du projet ?

Eric Leblond : Je trouve le financement et la gouvernance de ce projet particulièrement captivants. En arrivant dans le projet je ne pensais pas qu’ils seraient aussi indépendants. Etre dans le consortium ne donne ainsi pas de droits sur la gestion des évolutions et de la feuille de route du projet. Celle-ci est discutée lors de réunions publiques (retransmise sur internet dans la mesure du possible). Tout le monde peut y participer et apporter ses idées. Concernant le financement, l’apport initial a été fait par le projet HOST du Homeland qui sponsorise des projets Open Source. La seule exigence de cette puissante et redoutée institution a été que l’argent investi soit bien utilisé. Ils n’ont à ma connaissance jamais tenté d’influer sur des décisions techniques. Ceci s’explique en partie par la finalité de cette intervention : le Homeland a initié le projet en indiquant dès le départ qu’il souhaité qu’un éco système industriel se forme autour du projet pour assurer sa pérennité et son financement. La part relative ainsi que le montant absolu donné par le Homeland baisse ainsi régulièrement. Ce n’est que mon avis mais ce mode de financement et de développement me semble particulièrement intelligent.

Question : Enfin, toi qui à la fois est un orateur régulier aux RMLL mais aussi au SSTIC ou à CanSecWest par exemple : comment pourrais tu comparer ces différentes conférences sur les sujets de sécurité (les RMLL à la différence des 2 autres est généraliste) : apports sécurité de la conférence, échanges avec les autres intervenants et le public, relations qui en découlent à posteriori, ambiance etc ?

Eric Leblond : Pour moi, l’une des spécificités du track sécurité des RMLL est de ne convier quasi exclusivement que des développeurs de solutions, libres de surcroît, et non d’attaques ou d’exploits. Cet environnement me convient parfaitement puisqu’il correspond à mon expérience et à mes réalisations. Au niveau de l’apport en sécurité, il découle un aspect plus défensif des RMLLs par rapport aux autres conférences souvent plus axées sur l’offensif et le reverse.

Les RMLL sont un événement généraliste sur le Logiciel Libre et le public comporte donc des non spécialistes. Ce coté généraliste se ressent particulièrement lors des échanges hors track (le public de la track sécurité est généralement assez spécialisé). En étant sur un stand l’an dernier, j’ai eu des échanges très variés allant d’un discours éducatif à une discussion entre ’experts’ pour envisager une future collaboration entre projets. Celle-ci porte ses frais puisque Henri Doreau (ndr : contributeur Nmap et OpenVAS, speaker depuis 2 ans aux RMLL) est en train d’encadrer un Google Summer of Code dont une des taches est de développer dans nmap l’attaque que je viens de présenter à SSTIC et qui était encore privée à l’époque des dernières RMLL.

Interview de Eric Leblond réalisée par email en Juin 2012 par Christophe Brocas, co-responsable du thème Sécurité des RMLL 2012.