RMLL live blogging - jour 3

Bruce Momjian - Securing PostgreSQL

Bruce Momjian fait partie du consortium postgreSQL et propose ce talk car il lui a semblé que la sécurisation des bases SQL peuvent être difficiles, alors que cette sécurité est importante.

La présentation démarre par les vecteurs d'attaques SQL. Concernant postgre, il s'agira des attaques externes, i.e. sans droits d'accès. Les attaques internes ne seront pas couvertes (SQL injection, application vulnerability, OS compromis, permissions etc..).

La sécurite de postgreSQL débute par le réseau, il est important de ne pas truster tout le monde, ce que fait initdb par défaut (utilisez initdb -A). La connexion par mot de passe est déconseillée, car il est envoyé en clair sur le réseau. L'authentification MD5 est préférable car un salt est envoyé du serveur, et va servir à empêcher un rejeu des credentials de connexion. Côté serveur, les mots de passe sont concaténés au login et hashé MD5. Postgre n'a pas de contremesures spécifiques contre le bruteforce de mots de passe. Les échanges sont ensuite chiffrés pour éviter les écoutes.

Mais certaines attaques restent possibles. Un scénario utilise un faux serveur écoutant sur le même port que postgre (5432, non privilégié), et attend qu'un client se connecte et lui demande son mot de passe en clair (et non MD5). Ce scénario peut s'améliorer en connectant le faux serveur au vrai et réaliser ainsi un "proxy" malicieux lisant l'ensemble des requêtes/réponses. Une mauvais réponse serait de forcer SSL côté client, mais le serveur malicieux peut l'utiliser car il n'y a pas vraiment de CA qui authentifie ces échanges. Il faut alors forcer l'usage d'une CA (Verify CA dans la conf). L'usage de Verify-full est encore meilleur, car le client vérifie également si le nom du serveur correspond à celui du certificat. Bruce parle ensuite du chiffrement des donnés pour éviter le vol de celles-ci lors du vol physique des disques (ou les bandes de sauvegardes). La première solution est le chiffrement de disque. Mais postgre propose du chiffrement de colonne. Soit réversible, à l'aide d'AES, ou one-way avec MD5 dans les cas ou il suffit de comparer une valeur et non de la lire. (mais le chiffrement peut poser des problèmes de performances dans la recherche ou la création des index). La clé de déchiffrement est stocké sur le serveur (mais qui pose problème en cas de vol physique de serveur). La clé peut également être déportée sur un serveur de déchiffrement, qui va agir comme un proxy pour déchiffrer les colonnes. Enfin, cette clé peut aussi être sur le client, sur le poste ou dans un token hardware ce qui est sans doute la méthode la plus sûre.

Alexandre Dulaunoy - CVE search : un logiciel libre de collecte, recherche et analyse des vulnérabilités et expositions logicielles publiées par NIST
Alexandre fait partie du CIRCL, un Computer Incident Response Center du Luxembourg. CVE est un bon moyen de vérifier si ses logiciels sont à jour et/ou vulnérable. Mais la recherche à l'intérieur de ces bases ne sont pas simples. L'idée est donc de créer un outil à la manière des outils unix traditionnel qui va permettre de "grepper" facilement ces bases de vulnérabilités.
cve-search a été développé au début par Wim Remes, qui se limitait à prendre la base en XML pour la pousser dans une base de données mongoDB. Les données viennent du NIST, sont parsées et remplissent la base mongoDB. Cette base contient les CVE, les CPE (liste de softs), un ranking et des  infos. La base se met à jour deux à trois fois par jour.
Des outils permettent de lire cette base (recherche, liste des dernières vulnérabilite, recherche au travers d'un bot XMPP (si, si) et des recherches full text).
Il est possible de chercher par nom de soft (joomla par exemple), par n° de CVE, ou CPE. CPE est une manière de spécifier l'OS, l'application ou le matériel (ou une combinaison) ciblé par le CVE.
Des exemples de recherches sont donnés. Par exemple, quels sont les éditeurs qui utilisent le plus souvent le mot "unknown" (oracle, puis Sun et HP).
Un autre exemple permet de calculer les moyennes et variations de score CVSS des failles java par exemple.
L'outil permet aussi de pondérer selon ses propres critères des failles, des CVE ou des softs afin de les suivre plus facilement.

La présentation continue sur l'usage de cve-search. Le logiciel libre peut être utilisé par tout le monde, pour tous les usages, mais est ce qu'un "bad guy" peut utiliser ce soft? Certainement, car cela peut lui simplifier la recherche de vulnérabilités sur un système qu'il cible.

Malgré tout, le développement de cve-search continue et l'outil restera libre.

Sebastien Deleersnyder - Mise en place d'un cycle de développement sûr avec OWASP

OWASP introduit une méthode appelé OpenSAMM pour promouvoir le développement sécurisé. Un rappel est donné sur les risques de sécurité et
indique que le software est toujours vulnérable. Une méthode permettant de sécuriser le soft devient de fait intéressante. La sécurité peut être proactive (design, build) ou reactive (test, production). La méthode proactive est meilleure pour réduire la surface d'attaque, mais les tests et scan de vulnérabilités restent nécessaire.
L'OWASP propose un modèle de dévloppement prenant ces points en compte, ainsi qu'une méthode pour l'appliquer.
Quatre business fonctions sont définies (governance, construction, verification et developpement) avec pour chacun d'entre eux trois axes de travail. Les slides suivantes précisent ces points. L'orateur conseille d'aller sur le site de l'OWASP qui contient un grand nombre de ressources, de videos, de présentations sur le sujet. La suite de la présentation effectue une revue de ces points, je renvoie donc vers les slides et le site de l'OWASP
Je note le proxy offensif https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project qui semble intéressant à essayer.

Cedric Foll - (Net|S)Flow Détection d'anomalies et d'attaques sur le campus

La dernière conférence de la matinée est donné par un des rédacteurs en chef de MISC qui va présenter comment détecter des activités malicieuses sur un réseau à l'aide de Netflow. Netflow est un protocole standard qui permet (entre autre) de visualiser de manière graphique des flots, au lieu de lire des longues de pages de logs. Netflow a été développé par Cisco, standardisé  par IPFIX, et Sflow est une version dédiée pour les switchs.
Le principe repose sur les flux contenant les informations suivantes: IP src, dst, L4 ports, heure démarrage, durée, et quantité échangée. Un flux expire après 15s d'inactivité, 30 mn d'activités, quand un RST ou FIN est envoyé. Les routeurs envoient ces infos à un collecteur qui enregistre ces données.
Ces enregistrements s'exploitent à l'aide de nfdump/nfsen et permettent de créer des représentations graphiques des flux.
La suite de la présentation va montrer comment on utilise ces outils sur des exemples réels, extraits d'enregistrements de flux de l'université de Lille. Après des exemples généraux nous arrivons à une démonstration de détection de comportement malicieux. L'exemple montre comment un pic TCP sur le port 53 est facilement repéré, puis investigué. Un second exemple tout aussi parlant montre comment un DNS en configuration open a été trouvé. Les exemples continuent, toujours aussi visuels.
Netflow permet aussi de trier les ports par usage, par exemple pour trouver les ports les scannés. D'autres types de scan horizontaux (une IP qui scan un range) sont également facilement trouvés.
Les tunnels HTTP/HTTPs se détectent facilement: long flux avec peu de data; ainsi que les tunnels DNS: beaucoup de DATA, par contre les tunnels ssh sont plus difficiles à trouver.
La présentation est très visuelle, j'invite à voir les slides qui vont être dispos sur le site des RMLL d'ici peu.

 Jonathan Clarke - Rudder

Le talk va parler d'infrastructures et de l'automatisation de certaines tâches IT. L'automatisation est une composante essentielle de l'activité d'IT pour plusieurs bonnes raisons, rapidité, reproductibilité, éviter d'oublier des points, etc.. Plusieurs outils existent, comme CFEngine, puppet ou Rudder.

Mais plus que l'automatisation, l'important est la compliance. Celle ci permet de connaitre l'état de l'IT, d'obtenir une vue d'ensemble et surtout de la prouver. Ce besoin de compliance provient de multiples endroits: les lois, les réglementations industrielles ou d'entreprises et les "best practices".
Cette compliance s'appuye sur des messages de préventions, des politiques de mots de passe, des paramétrages particuliers, etc.. L'automatisation mentionnée plus haut n'est pas forcément de la compliance. La fréquence des vérifications est importante et doit être fait le plus souvent possible. La compliance ne peut pas être faite à moitié, c'est un système all-or-nothing qui se complique vite, du fait de l'hétérogénéité des machines, OS et versions. La compliance ne peut pas être mal faite car cela touche généralement des serveurs en productions et la moindre erreur peut avoir de grandes répercussions.

L'orateur continue avec une démonstration de l'interface graphique de Rudder. Le but de Rudder est de donner un outil Plug&Play qui permet d'automatiser les tests de compliance. La conf par défaut marche out-of-the-box elle est prépackagé pour tous les OS et l'intégralité de la configuration se fait à l'aide d'une interface Web. Le workflow d'utilisation est assez simple à prendre en main.

En conclusion, l'orateur explique que la compliance en sécurité bénéficie beaucoup de l'automatisation. Mais cette automatisation n'est pas tout. Il faut croiser ces données avec celles du monitoring pour une couverture maximale.




Je ne peux rester pour les autres talk, ayant un impératif de transport.
Merci RMLL2013, merci à l'organisation, c'était encore une très bonne année.