Open source et architecture logicielle

Au début du siècle, les fichiers de configuration étaient encore une collection de clé/valeur
Dans les années 2010 le XML s’est progressivement imposé comme format standard de configuration. C’est en particulier vrai dans le monde des serveurs JEE où les fichiers ont d’ailleurs une extension.xml
En ce début de décennie, il apparait comme important de pouvoir exploiter automatiquement ces fichiers de configurations. En effet le DEVOPS et l’offre Cloud imposent de pouvoir les lire et les modifier à travers des outils. Sur ce point de nombreux outils graphiques d’orchestration (déploiement – monitoring…) permettent de configurer et lire les fichiers de configuration XML.

Malheureusement, tout n’est pas si droit de l’œil et certains fichiers, s’ils ont adopté le balisage XML n’en pont pas pour autant renoncé à le mélanger avec les listes de propriétés et leurs valeurs. Un bon exemple de ces déviants est le fichier de configuration Apache httpd.conf
Pour beaucoup d’acteurs du DEVOPS ils se contentent de ne lire et configurer que les fichiers XML en partant du principe que qu’ils surchargent les fichiers historiques. Et pour bien d’autres, ils n’exploitent que la portion répondant à la syntaxe XML de ces fichiers. Et d’un point de vue purement fonctionnel, ce comportement semble à première vue payant puisque les serveurs d’applications ainsi configurées fonctionnent avec les performances exigées et les facilités d’exploitation attendues.
Néanmoins, ces fichiers mixtes sont des sources de vulnérabilités exploitables par des cyber-attaquants. Un exemple, toujours dans le fichier httpd.conf, est la valeur attribuée derrière la directive Include. La Valeur * devant être bannie pour éviter le hijacking.
Il devient donc utile de pouvoir lire et modifier ces fichiers mixtes afin de réaliser des audits et des hardenings. Ces vulnérabilités sont aujourd’hui trackées et remédiées manuellement, mais le SecDevOps impose de pouvoir le faire automatiquement.
L’objet de ce billet sera donc de poser les bases de l’exploitation de ces fichiers mixtes. Deux questions prégnantes se posent :
1/Quelle méthode adopter pour parser ces fichiers ?
2/Quel(s) langage(s) utiliser ?

1/ L’idée de manœuvre pour le parsing
De nombreux langages offrent la possibilité de traiter facilement un DOM XML mais également de traiter une liste de propriétés. Malheureusement les bibliothèques ne sont pas les mêmes, et les fichiers doivent être pur XML ou pur clé/valeur
L’idée serait alors de spliter le fichier à analyser en deux sous fichiers, en expurgeant l’original du XML pour l’un et des lignes clé valeur pour l’autre. On serait ainsi en mesure de mener un parsing sur des fichiers uniformes.

2/ Les Langages
Traditionnellement les langages utilisés pour écrire des outils d’audit et de hardening sont dépendant des plate-formes à analyser. On retrouve donc traditionnellement du Bash sur les systèmes Unix et du PowerShell sur les serveurs Windows. Cette dichotomie possède l’avantage de pouvoir executer systématiquement car tous les unix possèderont un interpréteur shell (Bash KornShell…) et les Windows un interpréteur Powershell. En revanche le traitement du XML pur en Bash est difficile car il se fera à grands coups de sed ou hawk sans certitude de bien analyser la syntaxe XML. De plus, cela impose de développer 2 fois un outil si le serveur d’application est réparti sur des Unix et des Windows. Pour cette raison, certains ont opté pour des scripts python. Mais le python va requérir que l’interpréteur soit ajouté à la configuration du serveur.
On voit que l’idéal serait d’utiliser un langage unique sur les 2 plateforme mais déjà présent nativement. Pour cette raison, si on suppose que les serveurs d’application sont JEE ou.Net, il parait intéressant de développer les scripts avec les langages qui portent ces technologies. Par exemple, pour les serveurs d’application JEE, le langage Java permettra de faire le job quel que soit l’OS support et on aura la garantie que la JVM sera toujours présente.

Aussi dans le prochain post, je vais parser un fichier httpd.conf en java afin de valider l’efficacité de la méthode naïve décrite d’une part, et la capacité de Java pour ce genre de tache dans une optique d’industrialisation d’autre part.