À la demande de l’ANSSI (Agence nationale de la sécurité des systèmes d’information), le cabinet d’audit Almond ITSEF a effectué un audit de sécurité du code source et de l’architecture de HAProxy, le célèbre répartiteur de charge. Le verdict est plus que favorable.
Par l’intermédiaire d’une nouvelle publication, HAProxy Technologies a partagé les résultats d’un audit de sécurité mené sur la version 3.2.5 de sa solution HAProxy. Cet audit de sécurité a été commandé par l’ANSSI. Dans quel but, me direz-vous ? Tout simplement parce qu’il s’agit d’une initiative de l’ANSSI destinée à évaluer la sécurité des briques open source les plus utilisées, dont HAProxy fait partie.
“Les résultats sont tombés. Après plusieurs semaines d’essais de résistance intensifs, d’analyse de code et de fuzzing, les auditeurs ont rendu un verdict sans appel : HAProxy 3.2.5 est un produit mature et sécurisé, fiable pour la production.”, peut-on lire. Une très bonne nouvelle pour les utilisateurs de cette excellente solution open source.
Une résilience à toute épreuve
Dans le cadre de cet audit de sécurité, les auditeurs ne se sont pas contentés d’une simple revue de code. Non, ils ont été plus loin, ils ont maltraité la solution, notamment via des techniques de “fuzzing”. L’objectif : voir comment elle réagit, notamment si elle peut planter ou non. En effet, le fuzzing consiste à bombarder le système avec des quantités de données malformées, aléatoires ou malveillantes pour tenter de le faire planter.
Le résultat mérite d’être souligné : zero bugs, zero crash. “Ils ont principalement ciblé le traitement des requêtes réseau HAProxy et les sockets internes. Ces tests ont duré plusieurs jours, voire jusqu’à 25 jours dans le cas des sockets internes.”, peut-on lire. Cela souligne la stabilité de la solution HAProxy.
Cet audit a aussi permis de confirmer les bons choix effectués par l’équipe de HAProxy en matière d’architecture logicielle. Deux points sont mis en avant :
Isolation des processus : la stratégie de “défense en profondeur” est validée. Le processus “maître” (privilégié) est strictement séparé des processus “travailleurs” (non privilégiés) qui gèrent le trafic du répartiteur de charge. Même en cas de compromission d’un worker, l’attaquant se retrouverait isolé sans être en mesure d’interagir avec le système.
Gestion mémoire personnalisée : plutôt que d’utiliser les allocations standard du système, HAProxy utilise ses propres structures pour la performance. L’analyse statique a confirmé que ce choix n’introduisait aucune vulnérabilité de corruption mémoire.
Et, puis, il y a une information très importante à souligner : sur l’ensemble du code source de HAProxy, aucune vulnérabilité n’a été découverte. Ah, si, il y en a tout de même une : dans une dépendance tierce nommée mjson, mais elle avait été corrigée en amont.
Ce qui fait la différence : la configuration
Le rapport d’Almond ITSEF insiste sur un point important : la responsabilité partagée. Cela signifie que même si l’application ne contient pas de vulnérabilités, la sécurité de la plateforme dépend de la configuration. À ce sujet, il est de la responsabilité de l’administrateur de faire les bons choix.
“L’audit a mis en évidence quelques domaines dans lesquels les comportements « par défaut » privilégient la compatibilité au détriment d’une sécurité stricte, ce qui oblige les administrateurs à être vigilants dans leurs configurations.”, peut-on lire.
Trois points, dont deux bonnes pratiques, sont mis en évidence dans la publication de HAProxy :
Contournement des ACL : les auditeurs ont noté que des règles de contrôle d’accès basées sur les chemins (par exemple : bloquer /login) pouvaient être contournées via l’encodage URL (par exemple : envoyer /log%69n).
L’explication : HAProxy est conçu pour être transparent et ne modifie pas les requêtes par défaut.
La solution : adopter un modèle de sécurité positif (autoriser uniquement ce qui est connu) plutôt que de bloquer des motifs spécifiques, ou utiliser la directive normalize-uri pour nettoyer les entrées avant le filtrage.
La page de statistiques : outil historique pour les développeurs, la page de stats utilise par défaut une authentification Basic et peut révéler la version du logiciel. Elle n’est pas conçue pour être exposée sur le web public sans protection additionnelle (TLS, tunnel SSH ou VPN).
Stabilité au démarrage : une configuration malformée pouvait provoquer un défaut de segmentation au lancement. Bien que n’affectant pas le trafic en production, ce bug a été corrigé dans la semaine suivant le rapport d’audit préliminaire.
En conclusion, vous pouvez foncer : HAProxy 3.2 est une solution mature, fiable et sécurisée prête pour la production !
Source
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.