Sécuriser Hermes sur un VPS : mon audit en 3 niveaux

Un agent Hermes installé sur un VPS peut lire des fichiers, appeler des API, lancer des commandes et exécuter des tâches pendant que tu dors. Cette autonomie est utile. Elle augmente aussi le rayon d'action d'une erreur, d'un accès volé ou d'un contenu malveillant.

J'ai donc repris mon installation comme un système à vérifier, pas comme une application qu'on déploie une fois avant de l'oublier. L'audit suit trois niveaux : le VPS, la configuration de Hermes et les usages à risque. À chaque niveau, je cherche une preuve visible et un chemin de retour.

1. Le VPS : réduire ce qui est exposé

La première question n'est pas « mon agent répond-il ? », mais « qu'est-ce qu'Internet peut atteindre ? ». Un service qui fonctionne derrière une interface peut laisser ouverts des ports inutiles, un accès SSH trop large ou une console d'administration publique.

Le contrôle de base tient en cinq points :

inventorier les ports réellement ouverts ;
identifier le processus derrière chaque port ;
fermer ce qui n'a pas besoin d'être public ;
appliquer les mises à jour du système et des conteneurs ;
préparer une sauvegarde ou un snapshot avant toute mutation.

Contrôle	Preuve attendue	Retour arrière
Ports exposés	liste des sockets et test depuis l'extérieur	règle firewall précédente
Accès administrateur	connexion autorisée, mot de passe refusé si les clés sont imposées	console de récupération
Services	état et logs des conteneurs	image ou configuration précédente
Sauvegarde	snapshot daté et visible	restauration testée sur un environnement isolé

Une règle firewall enregistrée ne suffit pas. Il faut vérifier le résultat depuis l'extérieur. Une sauvegarde affichée dans un tableau de bord ne suffit pas non plus : il faut savoir où elle se trouve et comment revenir à l'état précédent.

2. Hermes : limiter les droits sans casser l'usage

Retirer tous les outils à Hermes donnerait un chatbot de plus. Le bon réglage conserve les tâches autorisées et bloque le reste par l'architecture.

Je contrôle notamment :

qui peut envoyer des demandes à l'agent ;
quels outils sont disponibles dans chaque contexte ;
quels dossiers peuvent être lus ou modifiés ;
où sont stockés les secrets ;
quelles actions demandent une approbation ;
quelles automatisations continuent sans présence humaine.

La vérification doit montrer les deux côtés. Une tâche légitime doit encore réussir après le durcissement. Une tâche interdite doit échouer clairement. Si l'on ne teste que le blocage, on peut croire le système sécurisé alors qu'on l'a seulement rendu inutilisable.

Une séquence de maintenance reproductible

Observer l'état
→ diagnostiquer la configuration
→ créer une sauvegarde
→ appliquer un changement borné
→ vérifier la santé
→ tester une action autorisée
→ tester une action interdite
→ conserver ou restaurer

Cette séquence évite les modifications à l'aveugle. Elle transforme chaque conseil de sécurité en opération observable.

3. Les usages à risque : crons, secrets et contenus externes

Les tâches planifiées méritent une revue séparée. Elles s'exécutent sans que tu voies le prompt, le contexte ou l'action au moment où elle se produit. Pour chaque cron, je vérifie son objectif, ses outils, son périmètre de fichiers, ses accès réseau et son mode d'alerte en cas d'échec.

Les contenus externes posent un autre problème. Une page web, un email ou un document peut contenir des instructions destinées à détourner l'agent. Demander au modèle d'être prudent n'est pas une barrière suffisante. Le test utile consiste à placer une instruction malveillante contrôlée dans une donnée non fiable, puis à vérifier que les permissions empêchent l'accès à un faux secret ou l'envoi d'une requête interdite.

Ce test prouve la qualité des limites techniques, pas l'impossibilité de toute attaque. Il doit utiliser un canary factice, un compte isolé et aucun secret de production.

Les six règles que je garde

Exposer seulement les services nécessaires.
Donner à chaque tâche le minimum de droits utile.
Séparer les secrets du contexte courant.
Demander une approbation pour les mutations sensibles.
Prouver qu'une tâche autorisée fonctionne et qu'une action interdite échoue.
Préparer le rollback avant la mise à jour.

La vidéo montre l'audit complet, les commandes, les preuves visibles et les limites de chaque démonstration : voir la vidéo.