Une sonde IDS ne voit pas le TLS
Les labs IDS ont une vraie valeur pédagogique. On monte Suricata, on branche DVWA, on rejoue quelques attaques web et l’on voit les règles se déclencher en direct, ce qui aide beaucoup à comprendre comment fonctionne une sonde. Le problème n’est pas le lab, il est dans la transposition en production, où un détail structurant change tout : le TLS.
Pourquoi le lab fonctionne
Si le lab marche aussi bien, c’est précisément parce que DVWA tourne en HTTP. Le trafic circule en clair, la sonde le lit octet par octet et les signatures peuvent inspecter les requêtes comme les réponses sans la moindre difficulté. C’est d’ailleurs le même confort qu’on retrouve lorsqu’on sort tcpdump sur un flux non chiffré ou qu’on bricole un sniffeur maison pour regarder passer les paquets : tant que la charge utile est lisible, tout va bien.
En environnement réel, ce confort disparaît. Le trafic web est chiffré et une sonde posée en mode promiscuous, qui se contente d’observer une copie du trafic, ne voit plus que des flux TLS. Elle constate qu’il se passe quelque chose, elle peut lire des métadonnées d’enveloppe, mais le contenu applicatif lui reste fermé, de sorte que Suricata ne peut plus inspecter ce qui compte vraiment.
Pourquoi on ne déchiffre pas à la volée
La tentation serait de vouloir déchiffrer le flux au passage, sur la sonde, sans toucher ni au client ni au serveur. C’est un problème fondamentalement difficile et il l’est par conception. TLS a précisément été conçu pour empêcher un tiers placé au milieu de lire ou d’altérer la conversation, donc tout dispositif qui prétendrait inspecter le contenu depuis une simple copie du trafic se heurterait à ce pour quoi le protocole a été pensé.
Autrement dit, le mirroring réseau, qui reste une excellente approche sur du trafic en clair, se vide d’une grande partie de son intérêt dès lors que la charge utile est chiffrée de bout en bout.
Inspecter là où le TLS est terminé
La solution ne consiste pas à forcer le chiffrement, mais à se placer là où il s’arrête de lui-même.
Pour du web en production, l’approche complémentaire consiste à poser l’inspection au niveau du reverse proxy, c’est-à-dire à l’endroit précis où le TLS est terminé et où le trafic redevient lisible. On peut y intégrer un WAF ou exporter les logs applicatifs vers un collecteur du type Wazuh pour les corréler ailleurs.
Cette approche a plusieurs vertus. Elle ne touche pas davantage aux serveurs cibles, elle s’insère dans une brique qui existe généralement déjà dans l’architecture et surtout elle voit le trafic en clair sans imposer toute une infrastructure de mirroring. C’est le même esprit que lorsqu’on place un terminateur TLS en amont d’infrastructures sensibles, facile à maintenir et à auditer, plutôt que de multiplier les technologies propriétaires peu auditables et quasi impatchables à chaud. Pour aller plus loin sur ce placement en bordure, voir le hardening de l’ingress et sur un cas concret de reverse proxy devant une application fermée, nginx devant Perforce .
Votre sonde est aveugle
- Un lab IDS en HTTP clair est excellent pour apprendre, mais il masque l’angle mort de la production.
- En réel, le trafic web est chiffré et une sonde en mode promiscuous ne voit que du TLS.
- Déchiffrer à la volée sans toucher au client ni au serveur est fondamentalement difficile, TLS est fait pour cela.
- On inspecte là où le TLS est terminé : reverse proxy, WAF, logs applicatifs expédiés vers Wazuh.
- Cette approche ne touche pas les serveurs cibles, réutilise une brique existante et évite tout mirroring.