Los cinco niveles de seguridad de un panel autohospedado

Instalé Coolify en un VPS de cinco euros al mes un martes por la tarde. Veinte minutos después tenía un panel en http://203.0.113.10:8000, un proyecto desplegado y la sensación de haber terminado la semana.

Al día siguiente, lastb | wc -l devolvía más de 300 intentos de SSH fallidos. El panel seguía ahí, escuchando en todas las interfaces, con su formulario de login visible para cualquiera que pasara por delante. Nadie había hecho nada malo: el instalador cumple lo que promete, que es ponerte a funcionar rápido. El problema es que el valor por defecto de casi cualquier panel autohospedado es “público y sin cifrar”.

Coolify es el detonante de este artículo, no su protagonista. Las capas que siguen no son exclusivas de un panel de administración: sirven para cualquier sistema que expongas a internet y que no debería estar al alcance de cualquiera. Una intranet, una web interna, la documentación de una API, un panel de métricas, una interfaz de base de datos o el CI del equipo. Cambia el envoltorio, no el problema: alguien puede llegar antes que tú y encontrar una puerta sin cerradura.

Lo que sigue es el mapa de esas capas, con el ataque que frena cada una, lo que cuesta operarla y el caso de uso en el que tiene sentido. Al final, cómo combinarlas según tu situación.

El problema real: no expones un panel, expones una llave SSH

La conversación sobre puertos y contraseñas esconde el riesgo de verdad. Un panel de administración no es una web con un formulario: es un plano de control. Guarda credenciales, lanza contenedores, conecta con servidores y, en muchos casos, almacena las claves SSH con las que se ejecutan comandos en ellos. Si alguien entra, no ha entrado en una pantalla: tiene la misma capacidad que tú sobre toda la infraestructura que ese panel gobierna.

Ese detalle cambia la prioridad. No estás decidiendo cuánto tardar en llegar al login, estás decidiendo quién puede intentarlo.

La gravedad cambia según el sistema: un panel suele ser un plano de control con claves, una intranet guarda información que no sale de la empresa, y una base de datos expuesta es la base entera. La lógica de capas es la misma en los tres casos.

Y del otro lado no hay una persona mirando: hay bots. Shodan, Censys y los crawlers de los proveedores de seguridad escanean el espacio IPv4 de forma continua y publican lo que encuentran, con puerto y versión. Un servidor recién expuesto no pasa desapercibido durante semanas; entra en el inventario de alguien en cuestión de horas.

Capas que no se pueden saltar

La seguridad de un panel se construye como un aeropuerto. Primero hay un perímetro: la valla y los accesos controlados. Después, un control donde enseñas la tarjeta de embarque. Más tarde, el control de pasaportes, que no se conforma con la tarjeta. Cada capa asume que la anterior puede fallar, y ninguna por sí sola te deja subir al avión.

Eso es defensa en profundidad: no elegir el control más fuerte, sino encadenar controles independientes para que un fallo no sea suficiente. En un panel autohospedado, la valla es el firewall, la tarjeta es HTTPS con contraseña, y el pasaporte es un certificado de cliente.

La analogía se rompe en un punto que importa: un aeropuerto tiene una sola entrada, y un servidor tiene tantas como servicios publiquen un puerto. Un contenedor puede abrir la suya sin que el firewall del host la vea. Esa es la razón por la que tanta gente cree tener el panel cerrado y lo tiene abierto.

Nivel	Qué añade	Ataque que frena	Coste operativo
1	Puerto no estándar	Bots de listas cortas	Nulo
2	Allowlist de IP	Cualquier escaneo externo	Bajo, pero rígido
3	Dominio y TLS	Interceptación y robo de sesión	Bajo
4	Red privada	Todo el tráfico de internet	Medio
5	mTLS	Fuerza bruta y dispositivos no confiables	Alto y recurrente

Nivel 1: seguridad por oscuridad

Mueves el servicio de su puerto estándar a uno alto y aleatorio. La idea es que nadie llame a una puerta que no sabe que existe.

Solo frena a los bots que prueban una lista corta de puertos conocidos, y eso ya es mucho tráfico. Pero un escaneo completo recorre los 65.535 puertos en minutos, y un atacante con un objetivo no se detiene en la primera lista. Si además publicas el panel por dominio, el nombre aparece en los registros de transparencia de certificados, así que el escondite deja de serlo el día que emites el certificado.

Tampoco aporta cifrado: si el panel no tiene TLS, la contraseña y la cookie de sesión siguen viajando en claro.

Caso de uso: ninguno como barrera. Es higiene barata para reducir ruido cuando ya tienes TLS y autenticación fuerte, y no debería aparecer en una conversación sobre seguridad como si fuera una medida.

Nivel 2: filtrado por IP

Cierras el puerto a todo internet y permites entrada solo desde direcciones de confianza. Funciona mejor en el firewall del proveedor que en el del sistema operativo: filtra antes de que el paquete llegue a la máquina y no depende de cómo esté configurado el entorno de contenedores.

Es la capa con mejor relación entre esfuerzo y resultado cuando encaja. Un escáner externo no puede probar credenciales contra algo que no puede alcanzar, ni siquiera sabe que existe.

El problema es que es rígida. Depende de tener una IP fija, y eso excluye a quien viaja, a quien tiene fibra con IP dinámica y a quien hace guardias desde el móvil. Un error en la regla del cortafuegos no te deja fuera del panel: te deja fuera del servidor.

Y hay una trampa silenciosa. Cuando un contenedor publica un puerto, crea su propia regla de redirección y el firewall del host puede no filtrarla. El resultado es una allowlist que parece correcta y un puerto que responde a todo internet. Merece la pena comprobar qué escucha y en qué interfaz después de cada cambio, con ss -tlnp, en lugar de fiarse de la configuración que uno cree haber puesto.

Caso de uso: equipos pequeños con oficina o IP fija, servidores internos, accesos de emergencia y cualquier panel que no necesite ser universal. Si tu IP cambia, esta capa te va a costar más disgustos que alegrías.

Nivel 3: dominio, proxy inverso y TLS

Pones el panel detrás de un nombre de dominio y de un proxy inverso que gestiona los certificados. El tráfico pasa a ir cifrado, el puerto de la aplicación se esconde detrás del 80 y el 443, y puedes añadir cabeceras de seguridad como HSTS.

Es la línea base de cualquier despliegue en producción, y la única capa de la lista que yo consideraría obligatoria. Sin ella, las credenciales y las cookies de sesión viajan legibles para cualquiera en la ruta.

Lo que no hace es restringir quién llega. Cualquiera que descubra el subdominio ve el formulario de login y puede intentar entrar. TLS protege el transporte, no la puerta. Y el subdominio se descubre con facilidad: los certificados emitidos quedan en registros públicos.

Una variante de este nivel que casi nadie configura y que aporta mucho: autenticación en el propio proxy, antes de que la petición llegue al panel. Un login adicional con un proveedor de identidad convierte el formulario del panel en la segunda puerta, no en la primera.

Caso de uso: todo. Incluso si el panel solo se usa desde una red privada, el TLS evita sorpresas cuando alguien lo abre desde una red que no controlas.

Nivel 4: red privada y Zero Trust

Aquí el panel deja de existir en internet. Lo atas a una red privada (Tailscale, WireGuard) o a localhost, y accedes desde dentro de esa red. No hay puerto público que escanear, porque no hay nada escuchando en la interfaz pública.

La ventaja frente al nivel 2 es que la confianza deja de depender de una IP y pasa a depender de un dispositivo autenticado. Da igual dónde estés: si el portátil está en la red, entras; si no, no. Y no necesitas abrir puertos entrantes en el cortafuegos.

Tiene dos costes. El primero es de proceso: cada máquina necesita el cliente, un alta y una baja cuando alguien deja el equipo. Con dos personas es trivial; con diez, sin un flujo claro, acabas con dispositivos huérfanos dentro de tu perímetro, que es peor que no tener perímetro. El segundo es de dependencia: confías en el plano de control de la malla (el coordinador que autentica nodos) y en que sus listas de acceso estén bien puestas.

Caso de uso: uso personal, equipos internos y administración de infraestructura. Para mí es la mejor relación entre seguridad y comodidad cuando puedes instalar un cliente y no necesitas que el panel sea universal. Es también la respuesta correcta cuando el panel no debe ser accesible desde dispositivos que no controlas.

Nivel 5: mTLS

El último nivel es mTLS, TLS mutuo. En un TLS normal, el navegador verifica al servidor. Aquí el servidor también exige al cliente un certificado firmado por una autoridad que él conoce, y lo hace durante el handshake, antes de entregar una línea de HTML.

Cliente                              Servidor
  │── ClientHello ──────────────────▶│
  │◀─ certificado del servidor ──────│
  │◀─ petición de certificado ───────│
  │── certificado de cliente ───────▶│  valida la cadena contra la CA
  │◀─ respuesta HTTP ────────────────│

La diferencia práctica es grande: sin certificado de cliente, la conexión se corta en el handshake. No hay formulario, no hay intento de contraseña que registrar, no hay fuerza bruta posible. El atacante no puede adivinar lo que no se le pide. Y como el certificado identifica un dispositivo concreto, puedes revocar el portátil perdido sin tocar las credenciales del resto.

El coste es operativo, y es el más alto de la lista: crear una autoridad certificadora interna, emitir certificados, instalarlos en cada navegador o sistema, renovarlos y revocarlos. En móviles la experiencia es incómoda: hay que instalar el perfil y confiar en la CA. Y un certificado no protege de un dispositivo comprometido: si el portátil está infectado, el certificado sigue ahí.

A eso se suma una trampa de configuración: si alguna ruta del mismo nombre de host no exige el certificado, el mTLS deja de aplicarse sin que nadie se entere. La seguridad de esta capa depende de que sea obligatoria en todas las entradas, no en la que recordabas.

Caso de uso: acceso desde cualquier red sin VPN cuando los dispositivos son tuyos y el equipo es estable; entornos regulados donde hay que demostrar verificación de dispositivo; integraciones entre empresas. Si puedes usar el nivel 4, el nivel 5 te cuesta más y no te protege mejor.

Cómo se combinan

La falacia de la solución única es creer que existe una capa que lo resuelve todo. No existe: cada una asume que la anterior puede fallar. Lo que cambia según el caso es qué combinación puedes sostener en el tiempo.

Perfil	Combinación razonable	Por qué
Panel personal, IP dinámica	TLS + red privada	Sin puertos públicos y sin depender de una IP fija
Equipo pequeño con oficina o IP fija	TLS + allowlist + 2FA	Barrera fuerte con poco mantenimiento
Servicio con usuarios externos	TLS + identidad federada + rate limiting	El login es la puerta y hay que endurecerlo, no esconderlo
Proveedores o clientes	TLS + SSO con doble factor	No puedes imponerles un cliente de VPN ni un certificado
Alta criticidad o regulado	TLS + mTLS + registro de auditoría	Verificación de dispositivo y trazabilidad
Sin capacidad de operar ni parchear	No autohospedar	Un panel sin mantenimiento es una puerta abierta con nombre

La combinación que recomiendo por defecto para un panel de administración es TLS más red privada. Cubre el transporte y elimina la exposición pública, que son los dos riesgos que de verdad importan. Añade allowlist si tu IP es fija y quieres una barrera más. Reserva mTLS para cuando el acceso desde cualquier red sea un requisito y los dispositivos estén bajo tu control.

Y en todos los casos, tres cosas que no son una capa pero pesan más que varias juntas: registro de altas desactivado (quien llega primero a la pantalla de registro no debería poder convertirse en administrador), segundo factor en todas las cuentas con privilegios y actualizaciones al día. Un panel con una vulnerabilidad sin parchear convierte cualquier capa anterior en decorado.

Lo que falla en producción

El fallo más común no es un ataque: es quedarte fuera. Una regla de cortafuegos mal puesta, un certificado caducado o un cambio de red a las once de la noche generan la misma urgencia que un incidente. Ten siempre una vía de rescate que no dependa del panel y documéntala antes de necesitarla.

El segundo es la falsa cobertura. Cierras el puerto principal y dejas abiertos los auxiliares: el de las actualizaciones en tiempo real, el de la terminal web, el del panel de métricas. La superficie de ataque no es la que configuraste, es la que escucha.

El tercero es la recuperación. Las copias del panel suelen incluir su base de datos, pero no siempre las claves con las que cifra las credenciales. Si no guardas esas claves fuera del servidor, restaurar te devuelve una base de datos ilegible. Si estás montando esto desde cero, el setup mínimo de DevOps cubre backups verificados, alertas y comprobaciones de salud.

El cuarto es la caducidad silenciosa. Certificados de cliente que expiran, reglas que nadie revisa, accesos de gente que ya no está. La seguridad de un panel no se demuestra el día que lo instalas, sino el día que alguien se va y todo sigue funcionando igual.

Cuándo NO usarlo

Cambiar el puerto como única medida: nunca. No es una barrera, es ruido.
Allowlist de IP si tu IP es dinámica, viajas a menudo o haces guardias desde el móvil. Te vas a bloquear tú, y en el peor momento.
Dominio y TLS como única defensa en un panel que da root a tus servidores. Cifra el transporte, no decide quién entra.
Red privada si tienes que dar acceso a clientes o proveedores que no puedes incorporar a tu red. Ahí el alta y la baja se convierten en un problema mayor que el que resuelves.
mTLS si los dispositivos no son tuyos, si el equipo cambia a menudo o si nadie va a mantener la revocación al día. Un certificado que no se revoca es una llave que no se recoge.
Autohospedar el panel si no vas a poder actualizarlo ni hacer copias verificadas. Un servicio gestionado cuesta más al mes y menos en guardias; los patrones de arquitectura sin Kubernetes explican cuándo esa cuenta sale a favor.

Checklist antes de dar el panel por seguro

¿Sabes qué puertos escuchan en la interfaz pública y por qué cada uno de ellos?
¿El registro de nuevas cuentas está cerrado y el administrador ya existe?
¿El segundo factor está activo en todas las cuentas con privilegios?
¿El panel responde por HTTPS con un certificado válido y redirige desde HTTP?
¿Quién puede llegar al login: todo internet, una red privada o una lista de dispositivos?
¿Tienes una vía de rescate que no dependa del panel?
¿Has probado una restauración completa, incluidas las claves de cifrado?
¿Sabes cómo revocar el acceso de una persona en menos de cinco minutos?

El 8000 abierto no era el problema. Era el síntoma de haber confundido comodidad con seguridad. La pregunta que importa no es por qué puerto se entra, sino qué hay que demostrar antes de llegar al login. Elige la capa que puedas sostener y añade la siguiente cuando el coste de no tenerla sea mayor que el de mantenerla.

Para seguir leyendo

Los tres artículos comparten la misma idea: la capa que resuelve el problema no es la más grande, sino la que entiendes y puedes mantener.