Seguridad del servidor Linux: Parte 1 — Cortafuegos UFW

Cortafuegos — lo primero que se configura en un servidor nuevo, incluso antes de Fail2ban, CrowdSec y de la auditoría. Su objetivo es sencillo: permitir solo el tráfico que necesitan los servicios en funcionamiento y descartar todo lo demás. Cuantos menos puertos abiertos, menos puntos por los que se puede atacar el servidor.

En Debian y Ubuntu para esto se suele usar UFW (Uncomplicated Firewall). No es un cortafuegos independiente, sino una utilidad que convierte comandos cortos en reglas del kernel de Linux. UFW invoca iptables, y en las versiones modernas de Debian y Ubuntu iptables funciona sobre nftables, por lo que las reglas acaban en nftables.

Política predeterminada

El punto de partida correcto es denegar todas las conexiones entrantes y permitir las salientes:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Después de esto se abren solo los puertos necesarios. Todo lo que no esté permitido explícitamente será descartado.

Primero SSH, luego activar

El error más frecuente es activar UFW en un servidor remoto sin haber permitido SSH. La conexión se cortará y solo se podrá acceder al servidor a través de la consola del proveedor. La documentación de UFW recomienda explícitamente añadir la regla para SSH antes de activar: las reglas se pueden añadir mientras el cortafuegos está apagado.

sudo ufw allow 22/tcp          # o su puerto SSH no estándar
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Si SSH escucha en otro puerto, abra ese puerto. Si al servidor solo se conectan desde la oficina, es mejor restringir el acceso por dirección:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Limitación de la frecuencia de conexiones

El comando limit permite conexiones, pero bloquea una dirección que intenta abrir 6 o más conexiones en 30 segundos. Para SSH es una protección simple contra intentos rápidos de fuerza bruta de contraseñas:

sudo ufw limit 22/tcp

limit no sustituye a Fail2ban: no lee los registros ni sabe si el inicio de sesión fue exitoso o no. Es un filtro burdo, pero útil como primera defensa.

Orden de las reglas

UFW comprueba las reglas de arriba abajo y se aplica la primera que coincida. Si primero está allow 22 y más abajo deny from 198.51.100.0/24, la denegación para esa red sobre SSH no funcionará. Ver el orden e insertar una regla en la posición adecuada:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 3

IPv6

Por defecto UFW crea reglas tanto para IPv4 como para IPv6 — eso lo controla el parámetro IPV6=yes en /etc/default/ufw. Si el servidor tiene una dirección IPv6 pero se desactivó el soporte, los servicios en IPv6 pueden quedar expuestos sin ninguna filtración. Compruebe que la salida de ufw status incluya líneas marcadas con (v6).

Perfiles de aplicaciones

Los paquetes de muchos servicios instalan en el sistema perfiles con la lista de sus puertos. Lista de perfiles disponibles y ejemplo de uso:

sudo ufw app list
sudo ufw allow "OpenSSH"
sudo ufw allow "Nginx Full"

Un perfil es útil porque abre exactamente los puertos que necesita el servicio, sin enumerarlos manualmente.

Docker elude UFW

La principal trampa en servidores con contenedores. La documentación de Docker dice claramente: al publicar el puerto de un contenedor, el tráfico se redirige antes de que lo vean las reglas de UFW, y Docker y UFW son incompatibles en ese sentido. La línea -p 5432:5432 en docker run o ports: - "5432:5432" en Compose hace que la base de datos sea accesible desde Internet, incluso si el puerto está cerrado en UFW.

Qué hacer al respecto:

• publicar los puertos de servicio solo en la dirección local: -p 127.0.0.1:5432:5432, y exponer el servicio al exterior mediante un proxy inverso;
• para la comunicación entre contenedores usar una red Docker común y no publicar el puerto en absoluto;
• si es necesario abrir el puerto hacia el exterior con restricciones, añadir reglas en la cadena DOCKER-USER, que Docker comprueba antes que sus propias reglas;
• después del despliegue comprobar los puertos abiertos desde el exterior, por ejemplo desde otro servidor con nmap.

Registro

Para ver las conexiones rechazadas, active el registro:

sudo ufw logging on

Las entradas van al registro del sistema con la etiqueta [UFW BLOCK]. En un servidor expuesto a Internet habrá muchas: es el ruido del escaneo continuo, no un ataque dirigido personalmente a usted.

Cuando UFW no es suficiente

UFW cubre bien las tareas típicas de un servidor único. Para enrutamiento complejo, NAT entre varias redes o trabajo fino con conjuntos de direcciones es más conveniente escribir reglas nftables directamente. No conviene mezclar reglas manuales de nftables y UFW en el mismo servidor: será difícil averiguar qué regla se aplicó.

Errores típicos

• UFW activado sin regla para SSH — se pierde el acceso al servidor.
• La regla de denegación está por debajo de la permisiva y no se aplica.
• IPv6 desactivado en UFW, y los servicios escuchan en direcciones IPv6.
• Los puertos de los contenedores están publicados en todas las interfaces y son accesibles por Internet eludiendo UFW.
• Se dejó un puerto abierto “para depuración” y se olvidó.

El cortafuegos es solo la primera capa. Qué más hacer en un servidor nuevo está recopilado en la lista de comprobación «Compré un VPS — ¿y ahora?» y en el artículo «Un servidor nuevo — no es una hoja en blanco».