Je suis aux RMLL 2012 en train de suivre le track sécurité. Voici un live blogging des trois premières conférences.
1/ Suricata Eric Leblond
Suricata est une sonde IDS/IPS. La conférence est présentée par Eric Leblond développeur de Suricata, contributeur netfilter et membre de la fondation suricata au sein de l'OISF (www.openinfosecfoundation.org , organisation "non-profit"). Suricata est né de la lourdeur des 400000 lignes de codes de Snort. Il a été décidé de réécrire une nouvelle lib d'analyse plutôt que de continuer à modifier Snort. La Fondation est financée à l'orgine par le gouvernement US, mais les décisions restent communautaires. Le but de l'OISF est d'obtenir de nouvelles technologies d'IDS: performances accrues, utilisation de l'accélération hardware et multi OS (linux BSD, windows). Les challengers sont BRO et Snort. (Et l'orateur précise que même si suricata dérive de Snort, il est bien plus performant que son aîné :) )
Dans les fonctionnalités, Suricata fait nativement de l'IPv6, multi-thread, sait monter à 40GBp/s, et reconnait les flux indépendamment des ports. Suricata reconnaît les modes captures classiques, pcap, AF_PACKET, PF_RING pour l'IDS. Concernant l'IPS NFQUEUE, et ipfw. Les sorties sont en fastlog, unified log, prelude. De manière très simplifiée, Suricata fait le lien entre ce qui se passe sur le réseau et l'ajout d'une ligne dans les logs. La configuration de Suricata se fait par des règles inspirées par la syntaxe de Snort.
Suricata possède une librairie HTTP (libHTP )dont le rôle est de parser facilement les flux HTTP qui représentent la grande majorité du trafic réseau. Un exemple donné présente un parsing permettant de bloquer le chat de facebook. Pour ce faire, Suricata sait reconstruire les flux afin de les normaliser pour les parser en évitant les problèmes réseaux (fragmentation, etc.. ) Suricata sait poser des variables, les incrémenter et faire des choix en relation à leurs valeurs.
La version 1.3 sortie le week-end précédent les RMLL (bravos aux développeurs, même s'il s'agit plus d'un hasard :) ) amène plusieurs nouveautés. Tout d'abord, la libHTP permet une axtraction des fichiers téléchargés. Ceci permet une analyse plus fine dans les règles. Par exemple prévenir lors du download d'un fichier exe windows, ou le stocker pour analyse ultérieure. L'extraction de fichiers est à ce jour limité à HTTP, même si le mail devrait être supporté. Ensuite, Suricata sait analyser les handshakes SSL à l'aide d'une base de code maison, openssl étant trop gros pour être audité. Le parser SSL vient de l'ANSSI (Pierre Chifflier). Les règles permettent de trier selon le DN ou l'ISSUER, bientôt le fingerprint du certificat, ou les tailles de clés. Le parser ne gère actuellement que le premier certificat de la chaîne SSL. Les certificats ne peuvent pas non plus encore être stockés à la manière de HTTP. Enfin, la 1.3 vient avec des perfs accrues, notamment dans le cas de multicores.
La conférence finit par la roadmap, dans laquelle vient l'IP et la DNS reputation, SCADA et le geoip. C'est un produit librement utilisable, il existe des liveCD, et
des infos, voir le site de suricata.
2/ nmap v6 Henri DOREAU
On ne présente plus nmap (15 ans déjà!) qui est un scanner de port dans lequel est ajouté un système de reconnaissance d'applications et d'OS. Il intègre aussi un moteur de script et des outils compagnons. La communauté est très vivante et remonte beaucoup de statistiques et de scripts NSE (aujourd'hui plus de 400 scripts). nmap est aussi une star du cinéma ! le site contient la liste (longue) dans lequel nmap apparaît :).
Les scripts NSE sont des scripts LUA. 4 modes d'exécutions sont présent. Les prerules, qui est lancé avant le scan nmap, le service, lié au service, host, lié à l'host, et les postrules qui servent surtout à réaggréger les résultats. Un script a deux fonctions de base: la rule qui renvoie un booléen indiquant s'il doit se lancer ou non, et une action qui est lancée si le booléen est vrai. les scripts ont plusieurs bibliothèques permettant des renormalisations des résultats ou des modes d'affichages. NSE est monothread, avec différentes manières pour simuler du parrallélisme afin de faciliter la vie des scriptwriters. Les scripts sont écrits pour ne pas avoir de dépendances. Exemple:
nmap --script samba-vuln-cve-2012-1182 <target>
nmap --script "http-* and not brute" <target>
le site http://nmap.org/nsedoc listes les scripts actuels, par catégorie.
La seconde amélioration concerne IPv6. Toutes les fonctionnalités de nmap sont portées en IPv6 (si tant que ça ait du sens) et toutes les plateformes ont cette amélioration. Certains points ont été simples à porter, comme le scan TCP, d'autres ont du être entièrements réécrits comme la détection d'OS. IPv6 devient important et nmap a voulu le supporter, surtout par le fait que tous les OS majeurs sont dual stacks. Il existe des scripts de découvertes d'hôtes pour éviter de scanner des plages entières IPv6. Le passage a IPv6 a été l'occasion de plusieurs nettoyages de codes et améliorations.
Les autres améliorations concernent plusieurs points de moindres importances (en terme de nombre de slides :) ). Tout d'abord la plage des 1000 ports classiques a évolué suite aux remontées utilisateurs. Une autre amélioration concerne nping qui ressemble à hping2 en plus évolué. nmap signifie network mapper, mais il ne fait des cartes que depuis la version 6 :) Zenmap propose d'afficher une carte représentant les réseaux scannés (15 ans pour mériter son nom, bel effort de nmap :) ). Une autre grosse amélioration concerne le web, grâce au Gsoc. C'est une première implémentation, pas encore au niveau des scanners webs habituels, mais c'est un début..
La roadmap du produit concerne la lib HTTP qui doit évoluer (SPDY?). L'outil compagnon ncat doit aussi être revu. NSE va continuer d'évoluer pour être de plus en plus puissant, les outils compagnons devraient s'y voir adjoints. Une combinaison des scans IPv4 et IPv6 est à l'étude. Un travail est en cours pour scanner au travers de relais, ou SSH. Et NSE pourrait se voir adjoindre un Updater pour synchroniser l'ensemble des scripts, leur base évoluant très vite.
3/ NAXSI Didier CONCHAUDRON Sébastien BLOT
D'une part le web est partout. D'autre part, les vulnérabilités web existent en plus grand nombre. Ces failles touchent tout le monde, aussi bien les petits hébergeurs que les grosses compagnies. Ces failles modifient l'aspect du site jusqu'à l'exfiltration de données. On constate que le niveau moyen des développements webs n'est pas très bon, et cet état de fait persiste, d'où l'augementation des attaques. Les statistiques fournies montrent bien l'étendue du problème. La première cause de ces failles vient généralement de la faiblesse du code, ainsi que de la non connaissance des mécanismes de sécurité des
développeurs. (Je rappelle que la conférence est faite par une équipe de pentesteurs)
La solution classique consiste à corriger le code. Et lorsque le patch du code est impossible, il faut alors mettre un WAF. "WAF est à HTTP ce qu'un firewall à OSI layer2".
NAXSI vient d'une idée de Thibault Koechlin, de NBS systems. Le problème des WAF classiques sont le prix trop elevés pour les WAF commerciaux, et mod_security est trop faible en performances. Enfin, il faut du temps pour garder les signatures à jour. NAXSI est basé sur nginx, bonne performances, sans mise à jour (que de la reconfiguration).
NAXSI a un ruleset de base sur lesquelles seront construites les règles pour protéger un site. NAXSI contient 35 règles (SQLi, XSS, etc..) qui ont une pattern, un score, des matchs zones et un Id. Ce set réduit de règles et une naïveté dans les regexp (pas de reconstructions, pas de sessions, etc) permet de grandes perfs, mais oblige à un apprentissage pour une création de liste blanche. NAXSI a un très faible overhead en terme de perfs comparés à un nginx 'brut'. NAXSI fonctionne aussi seulement en mode IPS ou il logge uniquement les attaques.
NAXSI est connu pour avoir protégé le site de Charlie Hebdo alors qu'il était massivement attaqué. Cela lui a permis un test haute performance puisqu'à l'époque 80% du trafic était malveillant.
4/ Lemon LDAP Clément OUDOT.
Je ne suis pas cette conférence.
Aucun commentaire:
Enregistrer un commentaire