Sécurité
Un outil de sécurité doit d’abord être sûr lui-même.
Les choix de conception de VDR partent d’une question : que peut faire un attaquant devenu root sur un serveur surveillé, ou qui aurait volé un accès à la console ?
Côté serveurs surveillés
- Aucun port ouvertTous les échanges partent de l’agent vers la console, en HTTPS. La console ne peut pas joindre un agent.
- Certificat toujours vérifiéAucune option ne permet de désactiver la vérification TLS. Les redirections ne sont pas suivies : le jeton ne part que vers la console configurée.
- Décisions bornéesLa console ne peut publier que des bans et des levées. L’agent les vérifie lui-même : format de l’IP, liste blanche, 28 jours au plus.
- Résistant aux rootkits courantsL’agent est lancé sans LD_PRELOAD et lit /proc directement pour comparer avec ce que voient les outils du système.
Côté console
- Alertes hors d’atteinteLa console tourne sur une autre machine : un attaquant root sur un serveur ne peut pas effacer ce qui a déjà été envoyé.
- Double authentification obligatoireMot de passe de 14 caractères au moins (Argon2id) et code TOTP. Un code ne sert qu’une fois. Blocage après 5 échecs.
- Secrets jamais stockés en clairJetons d’agents et sessions hachés, secrets TOTP chiffrés avec une clé hors de la base.
- Données d’agent jamais interprétéesTout ce qui vient d’un serveur est échappé : un nom d’utilisateur forgé dans un journal ne peut pas injecter de code. Requêtes SQL toujours paramétrées.
- Politique de contenu stricteAucun script ni style externe ou en ligne, cadres interdits, sessions limitées à 30 minutes d’inactivité.
Une question technique ?
La documentation détaille l’architecture, le protocole agent-console et l’exploitation.