RMLL 2013 - live blogging - jour2

Le réseau wifi est présent et actif, me permettant de mettre en ligne directement après les talks, merci au NOC des RMLL :-)

Peter Czanik - Logging & syslog-ng
La conférence parle de syslog-ng et de la journalisation en général. syslog-ng est développé par balabit, une compagine de 150 personnes dont
80% savent configurer un kernel linux ;)
Le logging est la science qui enregistre les évènements qui se passent sur un ordinateur. Le premier outil utilisant le logging fut sendmail. Logger est essentiel pour l'administration IT, aussi bien pour les développeurs, les administrateurs ou pour la sécurité dans des situations d'audits ou réponse à incident; mais seulement si les logs sont managés.
Syslog-ng existe depuis 1997, est appelé le couteau suisse du log, et essaye de centraliser tous les logs. La centralisation permet une collecte et une utilisation simple des logs et de permettre leur accès même si les machines sources sont down ou compromises.
La version la plus populaire de syslog-ng est la 1.6 (10 ans d'âge) qui est utilisée par les kindle d'amazon. La dernière version est la 3.4. L'orateur parle ensuite du format de log. Généralement, nous avons une date, puis une hostname et enfin du texte en anglais permettant une lecture simple du message. Lorsqu'un grand nombre de ligne de logs existe, il devient difficile de chercher les logs intéressant. Il est nécessaire alors de mieux structurer les logs afin de pouvoir les parser automatiquement.
syslog-ng utilise une méthode clé/valeur et un parseur pour pouvoir "grepper" plus facilement de l'information. Les autres features concernent une correlation facilitée, un formatage json des données, un export mongoDB et des destinations AMQP.
Dans le monde des logs, un nouveau challenger du nom de journal a fait son apparition. Journal est appareillé avec systemd. Il utilise également un système de clés/valeurs. Il peut exporter ses logs vers syslog-ng. journal dispose d'une feature intéressante d'authentification du process émetteur pour éviter qu'un attaquant ne pollue des logs avec des faux messages. Journal n'est pas un concurrent de syslog-ng, mais plutôt un allié qui concerne le log local des machines linux.
Pour revenir à sylog-ng, il apparait qu'une standardisation de ces clés valeurs devient de plus en plus important. Ce Graal du logging aurait beaucoup d'applications pratiques, mais trop d'applications continuent d'utiliser des logs non formattées.
Un outil graphique se basant sur ces systèmes clés valeur est ELSA, basé sur syslog-ng, patternDB et mySQL et permet des recherches de log tournés vers la sécurité.
En conclusion, l'orateur donne les raisons poussant à utiliser syslog-ng:
15 ans de développements, scalability, une documentation exemplaire.

Xavier Mertens - What will you investigate today

Encore une conférence sur les logs, mais plus tourné sur la sécurité et la recherche à l'intérieur de ceux-ci.
Le problème des logs n'est pas d'en manquer, le problème est plutôt de retrouver parmi les millions d'évènements ceux qui font sens. Pour des raisons de compliance, les entreprises installent des outils de logging, mais l'exploitation des résultats n'est pas forcément simple. Malgré tous ces logs, les entreprises mettent plusieurs mois pour se rendre compte des brèches: 66% des brèches sont détectées plusieurs mois après après et 69% des data breach sont remontées par des tiers!
Le premier outil de recherche dans les logs est "grep". Il permet déjà d'extraire des infos intéressantes. Toutefois, cela permet de trouver des choses connues, que l'on cherche et ne donne pas d'idée sur l'inconnu (Par exemple, grepper des logs apache sur des codes peu usités peut donner des pistes intéressantes)
Pour aider, il existe aussi la corrélation de plusieurs sources, mais la classification n'est pas forcément simple.
Certaines listes permettent de classifier les données brutes; par exemple GeoIP pour les IP, ou une liste de noms d'utilisateurs importants (admin, root, "bob", etc..). Ces listes peuvent être dynamiques: une IP effectuant un portscan devient suspicieuse et a besoin d'une plus grande attention si elle se logge sur un service particulier.
Aujourd'hui, il est très difficile de filtrer tous ces évènements, tout le bruit afin de pouvoir se concentrer sur les plus importants.

Les premiers logs à creuser sont ceux du DNS, car il est essentiel et beaucoup de canaux d'exfiltrations l'utilisent. Il est également utilisé par les malwares pour trouver l'IP de leur C&C. Une liste de domaine malveillant va permettre de cibler des machines suspicieuses. Des machines tentant d'utiliser d'autres DNS que les DNS d'entreprises doit également être surveillée.
Les seconds logs sont les logs HTTP. "HTTP est le nouveau TCP". Il est nécessaire de surveiller les domaines, de faire de l'inspection SSL et de vérifier les hashs des fichiers échangés.
Le troisième protocole à surveiller est le SMTP. Les méthodes sont identiques, les domaines de sortie, et les flux de données.
Enfin, un outil à utiliser est netflow, qui permet d'obtenir des graphes intéressants listant les IP/ports sur une échelle de temps.

L'orateur donne des ressources sur internet à connaître. Tout d'abord, le site wwww.malwaredomainlist.com donnant des IP à chercher dans les logs.
Ensuite, GeoIP donne un point de vur intéressant sur les IP circulant sur ses réseaux. La seconde liste concerne les domaines DNS malveillant: malwaredomaines.com . Une troisième ressource est liée aux URLs.
malwareurls.joxeankoret.com, ou la liste malware URL de google (une API
existe). Toutefois, certaines de ces listes ont des limites légales (pas de
redistribution commerciales, API limitée, etc..) Enfin, il faut savoir utiliser des méthodes originales propres à ses domaines d'activités.

D'autres outils sont donné: pastebin a souvent des informations de première main. Des outils de parsing ne sont pas à négliger comme d3js. Un outil
comme OSSEC est conseillé par l'orateur pour ses qualités. Une série d'outils online est fournie (donnée sur les slides de la conf) comme malwr.com ou virustotal qui peut aider à détecter des comportements ou fichiers suspicieux.

En conclusion, l'orateur indique qu'il existe beaucoup de données à investiguer et qu'il est nécessaire de bien connaitre son environnement. Le logiciel libre va vous aider, mais il reste un gros travail de recherche et de corrélation qui demande du temps.

Pendant les questions, une remarque intéressante est faite concernant pastebin. Il existe  beaucoup de surveillances sur ces sites de paste. Malheureusement, aucun outil de partage des informations sur ces "pasties" n'existe et un framework de recherche serait très intéressant, remarque que je partage pleinement.

Eric Leblond - Suricata the terminator of IDS/IPS

La conférence démarre par une présentation d'Eric Leblond, contributeur
de Suricata, Ex-CEAo d'EdenWall. Cette présentation va faire une présentation de Suricata et continuer par une démo de ses possibilités.
Eric démarre par une définition des IDS/IPS. L'ids est passif et se compare à une caméra de surveillance, l'IPS bloque et s'apparente plus à un checkpoint de sécurité. Un IDS va écouter le réseau, effectuer une reconstruction de paquet/flux et appliquer enfin une normalisation des données pour appliquer une politique de détection de flux malveillants. Les projets ressemblant à suricata sont BRO, plus orienté capture de paquets, et Snort qui a inspiré le développement de Suricata. Suricata veut devenir un "Snort meilleur que Snort". Snort souffre d'un manque de performances et de 10 ans de développement, mais à l'avantage d'être bien connu. Suricata sait utiliser les rulesets de Snort (au prix de performances faibles et d'une impossibilité d'utiliser toutes les optimisations de suricata). Suricata propose un jeu de règle open source (emerging threat) directement utilisable.

Le développement d'OISF (fondation derrière suricata) a démarré avec l'aide du gouvernement US (DHS, Navy) dans l'idée d'en faire un outil open source. Ce financement souhaite dès le début du projet pouvoir se désengager de celui-ci afin qu'il puisse vivre en open source.
Le core developpement est assuré par trois personnes, et environ 35 contributeurs poussent régulièrement du code. Suricata est multiplateformes, supporte IPv6, multithreaded, accéléré en hardware, orienté perfs, permet d'être utilisé en mode "test", en mode IPS pur, sait détecter les protocoles indépendemment des numéros de ports, extraire des fichiers des flux, et est capable d'appeler un script LUA pour effectuer des
méthodes de détection plus intelligentes, et se connecte avec GeoIP.

Suricata sait digérer plusieurs méthodes d'entrées, pcap (live & offline) AF_PACKET, PF_RING, etc... Et en output sait renvoyer du Fastlog, pcaplog, unified2log, Prelude, etc.. Un des points central de suricata est la libhtp, une bibliothèque capable de reconstruire les flux HTTP et qui donne des pointeurs vers chaque partie du flux (en-tête, cookie, url, etc..), et surtout qui sait reconnaître du HTTP quel que soit le port. La lib HTP sait aussi extraire et critériser selon les metadata (extraire un fichier, son filetype, son extension, son hash, etc..) Plusieurs exemples sont donnés, ou l'on peut surveiller le type des fichiers entrant sur un serveur web, si des clés RSA circulent sur le réseau (!!).

Un manque de temps oblige l'orateur a accélerer et nous passons sur le mode IPS. Le jeu de règles est un peu différent, car basculer d'un mode "alert" à "drop" peut surbloquer des services.

Enfin, nous passons à la démo qui consiste à ralentir au maximum les flux des personnes envoyant des documents Word sur le réseau (car "Word is heavy as hell"). Suricata sait reconnaitre les fichiers word grâce aux mots-clés de la libhtp, et peut poser des marques netfilter. iptables va utiliser la target CONNMARK pour propager le marquage sur la connection entière. L'orateur réussit ensuite le tour de force consistant à expliquer comment la QoS sous linux fonctionne en une slide et 45 secondes ;) Il pose une règle de QoS restreignant les flots portant un fichier .doc a 1ko/s (très généreux de sa part). Les utilisateurs peuvent essayer de modifier l'extension, mais suricata sait le détecter et il devient possible de mettre une règle autorisant 10ko/s pour ces gens intelligents :). Mais ces gens intelligents sont peut-être à  surveiller. Dans ce cas, iptables peut repérer ces IP grâce à suricata et les mettre dans une table pour les logger.

Pierre-olivier Vauboin et Omar Awile - mobile telecom et securité

Dernier talk de la journée. Les réseaux télécom sont bien plus complexes que les réseaux IP. Un slide montrant une infrastructure opérateur permet de bien visualiser l'hétérogénéité des équipements et des réseaux, les différences entre le réseau de "signaling" (entrée sur le réseau, sortie, payement etc..) et le réseau data (données utilisateurs clients (voix, etc.) Il y a aussi un nombre beaucoup plus grand d'équipements, depuis la femtocell jusqu'au HLR, ouvrant de fait plus de surfaces d'attaque. Les protocoles aussi sont beaucoup plus nombreux en telecom qu'en IP: SCTP, SIgtran, M3UA, MAP, GPRS, etc.. contre DNS, HTTP, etc.. Les slides montrent des stacks IP versus des stacks telecom qui permettent de se rendre compte de la jungle dans lesquels vivent ceux-ci.

Le routage en IP est relativement simple (ethernet, IP, numéros de ports) alors qu'en telecom il existe de multiples standard et de multiples données dans toutes les couches protocolaires et le routage utilise une combinaison de toutes ces données. SCTP (RFC 4960) a été développé pour remplacé TCP, qui ne convient pas très bien aux réseaux télécom (délais, stream-oriented, pas de support du multi-homing). SCTP implémente une méthode permettant de gérer des flux répondant aux contraintes télécom. La plus grosse différence repose dans les chunks: un paquet SCTP peut embarquer des paquets différents, de différentes connexions. SCTP est la glu permettant de connecter des réseaux IP avec des réseaux telecom.

La deuxième partie de la conférence traire de pysctp, une bibliothèque pour monter des flux SCTP facilement. Un serveur M3U peut s'écrire en une vingtaine de ligne de code. Un second exemple implémentant une backdoor over SCTP tient également en une vingtaine ligne de code, et comme SCTP n'est pas TCP, les méthodes de détection utilisant netstat sont aveugles (quelques patch pour netstat existent pour afficher le SCTP toutefois). Il faut alors regarder dans /proc/net/sctps/eps et assocs pour connaitre les connexions SCTP.
Cette bibliothèque permet également de scanner les serveurs SCTP. Les réponses dépendent des serveurs et de leurs implémentations, mais il en connaissant ces différences le scan est efficace. Wireshark sait disséquer les protocoles telecom, et sait dépiler le mille-feuilles des protocoles utilisés. Le problème de SCTP est qu'il est de plus en plus utilisé, alors qu'il n'a pas d'authentification et qu'il faudrait utiliser IPsec, sauf qu'IPsec n'est pas vraiment déployé. L'orateur donne des exemples d'analyse réseau passive de réseaux télécom, ou de scan actif.

Pour conclure, l'orateur redit que le monde telecom est plus compliqué que le monde IP en raison du grand nombre de technologies et protocoles. Malgré tout SCTP est ubiquitaire dans ces telecom comme interface entre l'IP et le monde telecom. Il reste encore beaucoup de sécurité à creuser
et à mettre en oeuvre dans ces réseaux.