Proteger un servidor Coolify

La página sobre el firewall de Coolify enumera los puertos del servidor en el que se ejecuta el propio Coolify:

Los servidores que Coolify solo gestiona necesitan 22, 80 y 443. El puerto 8000 importa sobre todo justo después de instalar: la guía de instalación de Coolify advierte que quien llegue primero a la página de registro puede convertirse en administrador de la instancia y obtener acceso root al servidor. Crea la cuenta de administrador en cuanto termine la instalación.

Asigna un dominio al panel de Coolify, servido por el proxy de Coolify con HTTPS. Cuando funcione ahí, el panel, la conexión en tiempo real y el terminal pasan todos por los puertos 80 y 443, y puedes cerrar el acceso público a 8000, 6001 y 6002.

• Lo más sencillo es el firewall de tu proveedor, si tiene uno: Coolify lo recomienda, porque descarta el tráfico no deseado antes de que llegue al servidor.
• O bien vincula los tres puertos a 127.0.0.1, o elimínalos, con un override de Compose en /data/coolify/source/docker-compose.custom.yml, y vuelve a ejecutar el script de instalación. La página sobre el firewall de Coolify tiene el archivo exacto. No edites el archivo Compose base: las actualizaciones de Coolify lo reemplazan.

Comprueba que el panel funciona en su dominio antes de cerrar los puertos. Si los eliminas antes, puedes quedarte sin acceso a Coolify.

Un puerto publicado por un contenedor Docker no lo filtran tus reglas INPUT. La documentación de Docker es tajante sobre ufw: los paquetes se enrutan antes de que se puedan aplicar las reglas del firewall. La página sobre el firewall de Coolify dice lo mismo: bloquear un puerto con ufw no garantiza que un puerto publicado por Docker quede bloqueado.

El tráfico hacia un contenedor se reenvía, no se entrega al host, así que pasa por la ruta FORWARD. Docker deja ahí una cadena para tus propias reglas, DOCKER-USER, que evalúa antes que las suyas. Una regla que cierra un puerto publicado tiene que estar ahí, y tiene que comprobar el puerto que pidió el cliente: tras la traducción de direcciones de Docker, el paquete ya lleva el puerto del contenedor, y para eso sirve --ctorigdstport.

# Descarta las conexiones nuevas desde internet al puerto publicado 8000 (eth0 = la interfaz pública).
iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctstate NEW --ctorigdstport 8000 -j DROP

Las reglas añadidas con iptables se pierden al reiniciar si no las guardas (por ejemplo con iptables-persistent o netfilter-persistent). Un firewall en tu proveedor evita la cuestión, y Coolify menciona también la herramienta de la comunidad ufw-docker para servidores que no lo tienen.

Traefik es el proxy predeterminado de Coolify (la alternativa es Caddy), en los puertos 80 y 443: consulta la descripción general del proxy. Las configuraciones nuevas del proxy no exponen el dashboard de Traefik. La página sobre el dashboard de Coolify advierte que --api.insecure=true lo expone sin autenticación en el puerto de la API de Traefik, y también a través del firewall si la configuración del proxy publica el puerto 8080.

• En la configuración del proxy de cada servidor en Coolify, comprueba que el proxy no publica el 8080 y no usa --api.insecure=true.
• Si necesitas el dashboard de Traefik, sigue la página de Coolify para ponerlo detrás de un dominio con autenticación.

Coolify gestiona cada servidor por SSH, incluido aquel en el que se ejecuta, como root y con una clave que genera él mismo. Un usuario que no sea root es experimental y sigue necesitando sudo sin contraseña. La página sobre OpenSSH de Coolify recomienda la autenticación por clave, con root permitido solo con clave:

# /etc/ssh/sshd_config (o un archivo en /etc/ssh/sshd_config.d/)
PubkeyAuthentication yes
PermitRootLogin prohibit-password
PasswordAuthentication no

PasswordAuthentication no desactiva el acceso con contraseña para todos los usuarios, no solo para root: comprueba antes que cada persona que entra tiene una clave. Después prueba la configuración y recarga SSH desde la sesión que ya tienes abierta:

sshd -t && systemctl reload ssh    # en los sistemas de la familia RHEL el servicio se llama "sshd"

• En los servidores que gestiona Coolify, permite SSH solo desde la dirección del servidor de Coolify cuando puedas, como sugiere la página sobre el firewall de Coolify.
• La clave de Coolify no tiene frase de contraseña, por necesidad. Está en /data/coolify/ssh/keys, y /data/coolify/source/.env guarda los secretos de la instalación: trata ambos, y sus copias de seguridad, como contraseñas de root.

Solo Coolify 4.x recibe actualizaciones de seguridad. Coolify publica sus correcciones en los avisos de seguridad de GitHub y sus versiones en la página de releases. Actualizar pronto importa aún más en un servidor cuyo panel puede ejecutar comandos como root.

Con los pasos anteriores hechos, el agente cubre lo que un firewall por sí solo no cubre: los ataques que llegan por los puertos que tienes que dejar abiertos.

• Reconoce Coolify (por /data/coolify) y lo muestra en el panel. Donde una plataforma como Coolify gestiona el servidor web, el agente nunca edita su configuración.
• Los bloqueos llegan a los contenedores. Cuando hay Docker, el agente salta a su propia cadena desde DOCKER-USER además de desde INPUT, y mantiene ese salto en primer lugar. Sus bloqueos, listas de amenazas y bloqueos por país se aplican así también a los puertos publicados por contenedores. Si una recarga del firewall elimina el salto, el agente lo vuelve a poner.
• Cierra los puertos de bases de datos expuestos, también los de contenedores. Una base de datos publicada en un puerto público (MySQL, PostgreSQL, Redis, MongoDB y los demás puertos de bases de datos, caché y administración que conoce el agente) se puede cerrar a internet desde el panel, comprobando el puerto que pidió el cliente. Loopback, las redes privadas y tu lista de permitidos conservan el acceso, y el cambio se verifica y se deshace si SSH o un sitio dejan de responder. No cierra los puertos 8000, 6001 ni 6002 del propio Coolify: hazlo como en el paso 1.
• Lista los dominios de tus aplicaciones. Desde el agente 1.0.35 los lee, solo en lectura, de las etiquetas que Coolify escribe para su proxy (reglas de router de Traefik o direcciones de sitio de Caddy), así que puedes dar a cada sitio el distintivo de monitorización, verificado con un registro DNS TXT. Nunca ejecuta nada en el contenedor del proxy. El firewall web lee logs de acceso en formato common o combined, por ejemplo uno indicado con la etiqueta infrafence.log-path; el proxy de Coolify escribe logs JSON (solo con la analítica de tráfico activada), que el agente no lee.
• Detiene la fuerza bruta SSH en el firewall, puntúa el riesgo de las sesiones SSH y vigila el tráfico saliente, el DNS, el malware y la integridad de archivos como en cualquier servidor Linux.
• No se interpone con ufw. Sus reglas viven en sus propias cadenas INFRAFENCE, y nunca edita las tuyas.

El agente no sustituye los pasos 1 a 5: crear la cuenta de administrador enseguida, cerrar el 8000 y mantener Coolify actualizado siguen siendo cosa tuya. Qué lee y qué envía el agente está documentado por completo.