Kimi K3 audita un homelab: hallazgos en Proxmox, un fallo con el firewall y un NAS

Cómo se planteó la prueba

Varios informes afirmaban que Kimi K3 había superado a Fable 5 de Anthropic en varios benchmarks agénticos. Fable 5 es el modelo que el Gobierno de EE. UU. restringió brevemente por motivos de seguridad, así que un modelo abierto a su altura planteaba una pregunta obvia: ¿qué tal lo haría en una auditoría de seguridad real y no en un benchmark sintético?

Ya existía un banco de pruebas adecuado. El homelab incluía un servidor Proxmox en un mini PC Beelink SER5 y un NAS Synology, ambos configurados con mucho cuidado y considerados razonablemente seguros. En lugar de pasar una tarde lanzando nmap, leyendo configuraciones y tanteando cada servicio a mano, el trabajo se le encargó a un agente de IA: Kimi K3 ejecutándose a través de OpenCode, con la instrucción de atacar la infraestructura como lo haría un auditor externo. No fue una simulación. El agente ejecutó comandos reales en máquinas reales, analizó la salida, propuso correcciones y, donde se le permitió, modificó sistemas en producción.

Primera ronda: el servidor Proxmox

El prompt fue breve:

Aquí tienes un servidor Proxmox: XXX.XXX.XXX.XXX. Intenta entrar.

El agente empezó con un reconocimiento normal. Comprobó la conectividad, confirmó qué herramientas había instaladas y lanzó un escaneo con nmap, que mostró tres servicios expuestos: SSH en el puerto 22, la interfaz web de Proxmox en el 8006 y el proxy SPICE en el 3128.

Después anunció lo que parecía un compromiso grave:

Vulnerabilidad crítica detectada: root puede iniciar sesión por SSH sin contraseña y sin clave.

Sonaba mal hasta que el agente dedicó un minuto más a revisar authorized_keys y se dio cuenta de que el acceso «no autorizado» era la clave de la propia estación de trabajo del dueño. Había sacado conclusiones precipitadas, pero, a diferencia de muchos escáneres automáticos, siguió reuniendo pruebas hasta desmentir su propia afirmación. El falso positivo se corrigió solo porque la verificación continuó.

Lo que encontró de verdad

Aclarado el malentendido con la autenticación, el agente pasó a modo auditoría y elaboró un informe sensato:

Finding                                               Severity
Firewall disabled with default ACCEPT policy            High
Fail2Ban not installed                                  High
rpcbind exposed on every interface                      Medium
Proxmox web interface accessible to the network         Medium

Nada de eso sorprendía, y casi todo ya se sabía. Fail2Ban y un firewall llevaban en la lista de pendientes desde la instalación de Proxmox, unos 18 meses antes. Como muchos administradores de homelabs, el dueño lo había ido dejando para «más adelante».

Aplicar las correcciones

Tras leer los hallazgos, el dueño autorizó al agente a corregirlos. Primero revisó la configuración de SSH con sshd -T. La autenticación por contraseña ya estaba desactivada mediante un archivo drop-in en sshd_config.d. En lugar de fiarse de los archivos de configuración, el agente comprobó los ajustes efectivos en tiempo de ejecución y confirmó que el acceso con contraseña estaba realmente desactivado.

Después vino Fail2Ban. Proxmox no incluye un filtro adecuado para pveproxy, así que el agente escribió uno para los fallos de autenticación:

# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = ^.*pveproxy\[.*\]: authentication failure; rhost=<HOST>.*$
            ^.*: authentication failure; rhost=<HOST>.*$
ignoreregex =

Su mejor decisión tuvo que ver con rpcbind. El consejo habitual habría sido desactivar el servicio. El agente comprobó primero si algo dependía de él y encontró un recurso NFSv4.1 montado desde el NAS Synology, configurado meses atrás y olvidado. Desactivar rpcbind habría roto los montajes de almacenamiento y las tareas de copia de seguridad. Así que, en lugar de seguir una lista genérica de hardening, el agente miró el estado real del sistema y propuso enlazar rpcbind solo a direcciones locales.

Dónde se atascó

Con el firewall la cosa fue distinta. El agente generó tanto cluster.fw como host.fw, pero Proxmox no conseguía compilar el resultado:

$ pve-firewall compile
/etc/pve/nodes/pve1/host.fw (line 3): can't parse option 'policy_in: DROP'

Todo parecía coherente con la documentación, y aun así el parser lo seguía rechazando. Tras tres intentos, el dueño intervino y le pidió al agente que deshiciera todos los cambios del firewall. Borró los archivos generados, detuvo pve-firewall, restauró el estado anterior de iptables y dejó la máquina exactamente como la había encontrado. Esa capacidad de revertir fue casi tan valiosa como las correcciones. La automatización solo sirve si sabe recuperarse de un fallo de forma segura. Al final, el firewall se configuró a mano.

Segunda ronda: el NAS Synology

Terminada la primera ronda, el agente se dirigió al NAS:

Hay un NAS Synology en YYYY.YYYY.YYYY.YYYY. Evalúa lo seguro que es.

Esta ejecución fue más de verificación que de explotación. El escaneo encontró once servicios expuestos, entre ellos DSM, SMB, NFS, iSCSI, Synology Drive y Active Backup. En el equipo no estaban instalados ni nmap ni openssl, y el agente no se rindió. Escribió sus propias herramientas en Python: pruebas de handshake TLS para cada versión de protocolo admitida, una sonda de inicio de sesión iSCSI, negociación SMB mediante sockets en bruto y varias comprobaciones específicas de protocolo que normalmente requieren utilidades dedicadas.

Lo que pasó la prueba

Varios controles ya estaban bien:

• TLS ofrecía solo 1.2 y 1.3 con suites de cifrado modernas.
• El inicio de sesión anónimo en iSCSI se rechazaba porque CHAP era obligatorio.
• Las conexiones SMB1 fallaban de inmediato, así que el protocolo antiguo estaba desactivado.
• SNMP ignoraba la community string por defecto public.
• DSM enviaba las cabeceras de seguridad HTTP esperadas.

El agente probó cada ajuste directamente en lugar de dar por hecho que era correcto.

Lo que había que mejorar

El mayor problema era el propio DSM. HTTP seguía activo en el puerto 5000 sin redirección a HTTPS, y la página de inicio de sesión dejaba ver el ajuste sin rodeos:

<input type="hidden" id="prefer_https" name="prefer_https" value="false">

Cualquiera que iniciara sesión por HTTP enviaría sus credenciales sin cifrar. En una red doméstica de confianza eso no es necesariamente un desastre, pero es un riesgo innecesario, y muestra cómo los valores por defecto suelen quedarse mucho después del despliegue. También aparecieron cosas menores: el NAS seguía usando un certificado autofirmado en lugar de Let's Encrypt, las exportaciones NFS no tenían restricciones de firewall por IP de cliente y Active Backup mantenía abierto el puerto 6281 aunque el servicio ya no se usaba.

Lo que mostró el experimento

Lo sorprendente no fue que una IA encontrara fallos de seguridad, sino el tipo de trabajo que hacía bien. Kimi K3 no se comportó como un pentester veterano, y de esos se han conocido unos cuantos a lo largo de los años. Se comportó como un ingeniero de seguridad junior meticuloso que nunca se cansa de leer logs, probar versiones de protocolo, cuestionar supuestos y verificar cada servicio expuesto.

Es justo el trabajo que la gente pospone porque es repetitivo. Coincide con experimentos anteriores con LLM para automatizar operaciones: eliminan el tedioso trabajo de verificación, no pierden el interés a mitad de una checklist y no les importa repetir una comprobación cientos de veces. Además resultaron más cuidadosos de lo esperado. Antes de desactivar un servicio, el modelo comprobó las dependencias en producción, lo que evitó una caída que el consejo genérico de hardening habría provocado.

Aun así, la supervisión humana sigue siendo importante. El firewall nunca llegó a una configuración válida y, si se le hubiera dejado solo, el agente probablemente habría seguido haciendo pequeños cambios sin fin. Fue la orden de revertir lo que devolvió un estado limpio.

Una salvedad: el laboratorio solo es accesible internamente a través de WireGuard, así que la auditoría cubrió la red privada y no sistemas expuestos a internet. Aun así, los hallazgos merecieron el esfuerzo.