Proteger Hermes en un VPS: mi auditoría en tres capas

Un agente Hermes instalado en un VPS puede leer archivos, llamar a APIs, ejecutar comandos y completar tareas mientras duermes. Esa autonomía es útil. También amplía el impacto de un error, una cuenta robada o un contenido malicioso.

Revisé mi instalación como un sistema que necesita pruebas continuas, no como una aplicación que se despliega una vez y se olvida. La auditoría cubre tres capas: el VPS, la configuración de Hermes y los usos de riesgo. En cada capa busco una prueba visible y una ruta de recuperación.

1. El VPS: reducir la superficie expuesta

La primera pregunta no es «¿responde mi agente?», sino «¿a qué puede acceder Internet?». Una interfaz que funciona puede ocultar puertos innecesarios, un acceso SSH demasiado amplio o una consola de administración pública.

La revisión básica tiene cinco pasos:

inventariar los puertos realmente abiertos;
identificar el proceso detrás de cada puerto;
cerrar lo que no necesita acceso público;
actualizar el sistema operativo y los contenedores;
preparar una copia o snapshot antes de cualquier cambio.

Control	Prueba esperada	Recuperación
Puertos expuestos	lista de sockets y prueba externa	regla anterior del firewall
Acceso administrador	acceso permitido con clave y contraseña rechazada cuando se exigen claves	consola de recuperación
Servicios	estado y logs de los contenedores	imagen o configuración anterior
Copia	snapshot visible y fechado	restauración probada en un entorno aislado

Una regla guardada no demuestra que el firewall funcione. Hay que probar el resultado desde fuera. Una copia visible en un panel tampoco basta: debes saber dónde está y cómo restaurarla.

2. Hermes: limitar permisos sin romper el trabajo

Quitar todas las herramientas a Hermes produciría otro chatbot. La configuración útil mantiene las tareas autorizadas y bloquea el resto mediante límites técnicos.

Reviso:

quién puede enviar solicitudes al agente;
qué herramientas existen en cada contexto;
qué carpetas puede leer o modificar;
dónde se guardan los secretos;
qué acciones requieren aprobación;
qué automatizaciones continúan sin supervisión.

La comprobación debe cubrir ambos resultados. Una tarea legítima debe seguir funcionando después del endurecimiento. Una tarea prohibida debe fallar claramente. Si solo pruebas el bloqueo, un sistema roto puede parecer seguro.

Una secuencia de mantenimiento repetible

Observar el estado
→ diagnosticar la configuración
→ crear una copia
→ aplicar un cambio limitado
→ comprobar la salud
→ probar una acción autorizada
→ probar una acción prohibida
→ conservar o restaurar

Esta secuencia sustituye los cambios a ciegas por operaciones observables.

3. Usos de riesgo: tareas programadas, secretos y contenido externo

Las tareas programadas necesitan una revisión propia. Se ejecutan cuando no ves el prompt, el contexto ni la acción. Para cada tarea compruebo su objetivo, herramientas, alcance de archivos, acceso de red y aviso en caso de error.

El contenido externo plantea otro riesgo. Una página, un correo o un documento puede incluir instrucciones para desviar al agente. Pedir al modelo que tenga cuidado no crea una barrera suficiente. La prueba útil coloca una instrucción maliciosa controlada en un dato no fiable y verifica que los permisos impiden leer un secreto falso o enviar una petición prohibida.

Esta prueba mide los límites técnicos. No demuestra que todos los ataques sean imposibles. Usa un canary falso, una cuenta aislada y ningún secreto de producción.

Las seis reglas que mantengo

Exponer solo los servicios necesarios.
Dar a cada tarea los permisos mínimos útiles.
Mantener los secretos fuera del contexto activo.
Exigir aprobación para cambios sensibles.
Probar que el trabajo autorizado funciona y el prohibido falla.
Preparar la restauración antes de actualizar.

El vídeo muestra la auditoría completa, los comandos, las pruebas visibles y los límites de cada demostración: ver el vídeo.