Cómo configurar un firewall en un VPS Linux con UFW y nftables

16 min de lectura·Matthieu·vpssecuritylinuxfirewallnftablesufw|

Configura un firewall deny-by-default en tu VPS Linux con UFW o nftables. Dos caminos, un objetivo: solo los puertos que autorices quedan abiertos.

Un VPS recién creado no tiene reglas de firewall. Todos los puertos están abiertos. Los escáneres automatizados encontrarán tu servidor a los pocos minutos de estar en línea y empezarán a probar SSH, credenciales por defecto y servicios expuestos. Un firewall deny-by-default es la primera capa de defensa.

Este tutorial cubre dos herramientas:

  • UFW -- una interfaz simplificada que genera reglas de firewall a partir de comandos cortos. Ideal para conseguir una base segura rápidamente.
  • nftables -- el framework nativo de firewall de Linux que reemplaza a iptables. Ideal para operadores que necesitan control granular, compatibilidad con Docker o limitación de tasa por IP.

Elige el camino que se ajuste a tus necesidades. Ambos terminan con el mismo resultado: un firewall deny-by-default verificado donde solo los puertos que autorices explícitamente son accesibles.

¿Deberías usar UFW o nftables en tu VPS?

UFW es una interfaz simplificada que genera reglas iptables/nftables a partir de comandos cortos como ufw allow 22. nftables es el framework nativo de firewall de Linux que reemplaza a iptables, usando tablas, cadenas y reglas con una sintaxis más limpia. UFW conviene a principiantes que quieren valores por defecto rápidos. nftables conviene a operadores que necesitan limitación de tasa con meters, sets con nombre o reglas compatibles con Docker.

Característica UFW nftables
Curva de aprendizaje Baja. Comandos de una línea. Moderada. Estructura tabla/cadena/regla.
Por defecto en Ubuntu (instalado, inactivo) Debian 12 (instalado, configuración mínima)
Soporte IPv6 Automático (dual-stack) Reglas manuales necesarias (familia inet)
Limitación de tasa ufw limit (por regla) Meters con seguimiento por IP
Compatible con Docker No. Docker ignora las reglas de UFW. Sí. nftables funciona con la cadena DOCKER-USER.
Persistencia de config Automática con ufw enable /etc/nftables.conf + systemd
Recomendado para VPS de una aplicación, primer servidor Multi-servicio, hosts Docker, producción

Si usas Docker, evita UFW o lee Docker ignora UFW: 4 soluciones probadas para tu VPS para la solución alternativa. Docker manipula iptables directamente e ignora UFW por completo, exponiendo los puertos de los contenedores a internet aunque UFW diga que están bloqueados.

Requisitos previos

Antes de cambiar reglas de firewall, confirma dos cosas:

  1. Tienes acceso SSH y funciona. Estás conectado a tu VPS por SSH ahora mismo.
  2. Tienes acceso por consola como respaldo. El panel de control de tu proveedor ofrece una consola VNC o serie. Si pierdes el acceso SSH, puedes llegar al servidor a través de la consola.

Este tutorial apunta a Ubuntu 24.04 y Debian 12. Los comandos funcionan en ambos salvo que se indique lo contrario.

Comprueba tu versión de SO:

cat /etc/os-release | grep PRETTY_NAME

Salida esperada:

PRETTY_NAME="Ubuntu 24.04.4 LTS"

o

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

¿Cómo se configura UFW en Ubuntu 24.04?

UFW viene instalado por defecto en Ubuntu 24.04 pero inactivo. En Debian 12, instálalo primero:

apt update && apt install -y ufw

Comprueba el estado actual:

ufw status

Salida esperada:

Status: inactive

¿Cómo se activa deny-by-default con UFW?

Establece las políticas por defecto para descartar todo el tráfico entrante y luego autoriza explícitamente solo los puertos que tus servicios necesiten. Con UFW: establece los valores por defecto, autoriza SSH y después activa. El orden importa. Si activas UFW antes de autorizar SSH, te quedas fuera.

Establece las políticas por defecto:

ufw default deny incoming
ufw default allow outgoing

Esto le dice a UFW que descarte todas las conexiones entrantes por defecto y permita todas las salientes. Tu servidor puede seguir accediendo a internet (para actualizaciones, DNS, etc.) pero nada del exterior entra sin una regla explícita.

¿Cómo se autoriza SSH sin quedarse fuera?

Autoriza SSH antes de activar UFW. Es el paso más importante:

ufw allow 22/tcp comment 'SSH'

Si cambiaste tu puerto SSH (por ejemplo, a 2222), usa ese número de puerto.

Ahora activa UFW:

ufw enable

Verás:

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Tu sesión SSH actual se mantiene. UFW añade la regla de permiso antes de activarse, así que las conexiones existentes no se interrumpen.

Verifica las reglas:

ufw status verbose

Salida esperada:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                   # SSH
22/tcp (v6)                ALLOW IN    Anywhere (v6)              # SSH

Fíjate: aparecen reglas tanto para IPv4 como para IPv6. UFW crea reglas dual-stack automáticamente cuando IPV6=yes está configurado en /etc/default/ufw (el valor por defecto en Ubuntu 24.04).

¿Cómo se autoriza el tráfico web con UFW?

Si tu VPS ejecuta un servidor web, autoriza HTTP y HTTPS:

ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'

Verificación:

ufw status numbered

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere                   # SSH
[ 2] 80/tcp                     ALLOW IN    Anywhere                   # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                   # HTTPS
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)              # SSH
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)              # HTTP
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)              # HTTPS

La vista numerada es útil cuando necesitas eliminar reglas específicas más adelante con ufw delete <number>.

¿Cómo se limita la tasa de conexiones SSH con UFW?

UFW tiene un limitador de tasa integrado. Deniega conexiones de una IP que intente más de 6 conexiones en 30 segundos. Reemplaza la regla de permiso simple por una regla de límite:

ufw delete allow 22/tcp
ufw limit 22/tcp comment 'SSH rate-limited'

Verificación:

ufw status verbose

La regla SSH ahora muestra LIMIT IN en lugar de ALLOW IN. Esto frena los intentos de fuerza bruta sin bloquear el acceso legítimo. Para mayor protección, combínalo con Fail2Ban Instalar y configurar Fail2Ban en un VPS Linux.

¿Cómo se autorizan IPs o subredes específicas con UFW?

Para restringir el acceso a un servicio por IP de origen:

ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH from office'

Para autorizar una sola IP a todos los puertos:

ufw allow from 198.51.100.42 comment 'Trusted admin'

Esto es útil para servicios de administración que nunca deberían estar expuestos a internet. Combina el acceso restringido con la política deny-by-default.

¿Cómo se eliminan reglas UFW?

Elimina especificando la regla exacta. Es el método más seguro porque funciona independientemente del orden de las reglas:

ufw delete allow 80/tcp

También puedes eliminar por número. Primero lista las reglas con números:

ufw status numbered

Luego elimina por número:

ufw delete 2

Ten cuidado con la eliminación por número. Los números cambian cada vez que añades o eliminas reglas. Ejecuta siempre ufw status numbered justo antes de eliminar para confirmar qué regla corresponde a cada número. Eliminar el número equivocado puede dejarte fuera de SSH.

¿Cómo se configura el logging de UFW?

Activa el logging para ver las conexiones bloqueadas:

ufw logging on

UFW soporta tres niveles de log: low, medium, high. El nivel low por defecto registra los paquetes bloqueados. Para depuración, sube temporalmente:

ufw logging medium

Ver los logs:

journalctl -k -f | grep UFW

O comprueba el archivo de log directamente:

tail -20 /var/log/ufw.log

Vuelve a poner low después de depurar. Los niveles superiores generan mucha E/S de disco en servidores con mucho tráfico.

¿Funciona UFW con IPv6?

Sí. UFW gestiona IPv4 e IPv6 simultáneamente cuando IPV6=yes está configurado en /etc/default/ufw. Está activado por defecto en Ubuntu 24.04. Verificación:

grep IPV6 /etc/default/ufw

Esperado:

IPV6=yes

Cada regla ufw allow crea automáticamente entradas IPv4 e IPv6 correspondientes. No se necesitan pasos adicionales.

Lista de verificación de UFW

Ejecuta estas comprobaciones para confirmar que tu firewall funciona:

  1. Lista todas las reglas: ufw status verbose
  2. Comprueba que UFW está activado en el arranque: systemctl is-enabled ufw
  3. Prueba SSH desde un segundo terminal (no cierres tu sesión actual)
  4. Prueba desde fuera del servidor -- desde tu máquina local:
nc -zv YOUR_SERVER_IP 22

Esperado: Connection to YOUR_SERVER_IP 22 port [tcp/ssh] succeeded!

nc -zv YOUR_SERVER_IP 25

Esperado: conexión rechazada o timeout (el puerto 25 no está autorizado).

¿Cómo se configura nftables en Debian 12?

nftables es el framework de firewall por defecto en Debian 12. Reemplaza a iptables con una sintaxis más limpia y mejor rendimiento. En Ubuntu 24.04, instálalo si quieres usarlo en lugar de UFW:

apt update && apt install -y nftables

Si UFW está activo, desactívalo primero. Ejecutar ambos crea reglas en conflicto:

ufw disable
systemctl disable --now ufw

¿Qué son las tablas, cadenas y reglas de nftables?

nftables organiza las reglas de firewall en una jerarquía:

  • Tabla (table) -- un contenedor que agrupa cadenas. La familia inet maneja tanto IPv4 como IPv6 en una sola tabla.
  • Cadena (chain) -- una lista de reglas que se engancha a un punto específico del procesamiento de paquetes. Una cadena input filtra paquetes destinados al servidor. Una cadena forward filtra paquetes en tránsito.
  • Regla (rule) -- un par condición-acción. "Si el paquete coincide con el puerto TCP 22, aceptar."

El concepto central: establece la política de la cadena a drop y luego añade reglas que hagan accept en el tráfico específico. Todo lo que no esté explícitamente autorizado se descarta silenciosamente.

¿Cómo se escribe un conjunto de reglas nftables deny-by-default?

Establece las políticas por defecto para descartar todo el tráfico entrante y luego añade reglas para SSH, HTTP y HTTPS. Con nftables, se escribe como un archivo de configuración.

Crea la configuración:

cp /etc/nftables.conf /etc/nftables.conf.bak

cat > /etc/nftables.conf << 'NFTEOF'
#!/usr/sbin/nft -f

flush ruleset

table inet firewall {

    set ssh_ratelimit {
        type ipv4_addr
        flags dynamic
        timeout 60s
    }

    set ssh_ratelimit6 {
        type ipv6_addr
        flags dynamic
        timeout 60s
    }

    chain inbound_ipv4 {
        icmp type echo-request limit rate 5/second accept
    }

    chain inbound_ipv6 {
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmpv6 type echo-request limit rate 5/second accept
    }

    chain inbound {
        type filter hook input priority filter; policy drop;

        ct state established,related accept
        ct state invalid drop

        iifname "lo" accept

        meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }

        tcp dport 22 ct state new add @ssh_ratelimit { ip saddr limit rate 3/minute burst 5 packets } accept
        tcp dport 22 ct state new add @ssh_ratelimit6 { ip6 saddr limit rate 3/minute burst 5 packets } accept

        tcp dport { 80, 443 } accept

        log prefix "[nftables] Dropped: " counter drop
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain outbound {
        type filter hook output priority filter; policy accept;
    }
}
NFTEOF

Qué hace cada sección:

  • flush ruleset -- borra todas las reglas existentes para empezar limpio.
  • table inet firewall -- crea una tabla en la familia inet (dual-stack IPv4+IPv6).
  • set ssh_ratelimit -- un set dinámico que rastrea IPs de origen para la limitación de tasa SSH. Las entradas caducan después de 60 segundos.
  • chain inbound -- la cadena de entrada principal con policy drop. Todo lo que no coincida con una regla se descarta.
  • ct state established,related accept -- permite el tráfico de retorno para conexiones que tu servidor inició. Sin esto, las conexiones salientes (actualizaciones de apt, consultas DNS) fallarían.
  • ct state invalid drop -- descarta paquetes malformados que no pertenecen a ninguna conexión conocida.
  • iifname "lo" accept -- permite el tráfico de loopback. Muchos servicios se comunican internamente a través de localhost.
  • meta protocol vmap -- salta a cadenas específicas de IPv4 o IPv6 según el protocolo. Esto gestiona ICMP e ICMPv6 por separado.
  • tcp dport 22 ... limit rate 3/minute -- permite SSH con limitación de tasa por IP. Cada IP de origen tiene 3 conexiones nuevas por minuto con un burst de 5.
  • tcp dport { 80, 443 } accept -- permite HTTP y HTTPS.
  • log prefix "[nftables] Dropped: " -- registra todos los paquetes descartados en el log del kernel para depuración.

¿Cómo se gestiona IPv6 con nftables?

La familia inet en la definición de la tabla gestiona tanto IPv4 como IPv6 en un solo conjunto de reglas. Pero IPv6 requiere tipos ICMPv6 específicos para que la red básica funcione.

La cadena inbound_ipv6 acepta tres tipos ICMPv6:

  • nd-neighbor-solicit -- el equivalente de ARP para IPv6. Sin esto, tu servidor no puede descubrir vecinos en la red local.
  • nd-router-advert -- permite a los routers anunciarse. Necesario para SLAAC (configuración automática de direcciones IPv6).
  • nd-neighbor-advert -- respuestas a las solicitudes de vecinos. Necesario para la conectividad IPv6.

Bloquear cualquiera de estos rompe la red IPv6. El conjunto de reglas anterior lo gestiona correctamente. Si solo tienes IPv4, estas reglas son inofensivas -- simplemente nunca coinciden.

¿Cómo se limita la tasa de conexiones con meters de nftables?

El conjunto de reglas anterior usa sets dinámicos (antes llamados meters) para la limitación de tasa por IP en SSH. Cuando llega una conexión, esto es lo que ocurre:

  1. Una nueva conexión TCP al puerto 22 llega desde 198.51.100.42.
  2. nftables comprueba @ssh_ratelimit buscando una entrada que coincida con esa IP.
  3. Si la IP tiene menos de 3 conexiones en el último minuto, la conexión se acepta y el contador se actualiza.
  4. Si la IP supera el límite, la regla no coincide y el paquete cae en la política drop.

El parámetro burst 5 packets permite un pico breve y luego aplica la tasa constante. El timeout 60s en el set significa que las entradas se limpian automáticamente, evitando que el set crezca indefinidamente.

Para inspeccionar el estado actual del limitador de tasa:

nft list set inet firewall ssh_ratelimit

Esto muestra qué IPs están siendo rastreadas y sus contadores.

¿Cómo se añaden reglas para servicios adicionales?

El conjunto de reglas anterior permite SSH, HTTP y HTTPS. Para añadir más servicios, inserta reglas en la cadena inbound antes de la línea final log ... drop.

Por ejemplo, para permitir una app Node.js en el puerto 3000 solo desde una IP específica:

tcp dport 3000 ip saddr 198.51.100.42 accept

Para permitir un servicio UDP como WireGuard en el puerto 51820:

udp dport 51820 accept

Para permitir un rango de puertos (por ejemplo, para FTP pasivo):

tcp dport 40000-50000 accept

Después de editar /etc/nftables.conf, valida la sintaxis sin aplicar:

nft -c -f /etc/nftables.conf

La opción -c comprueba errores y sale. Sin salida significa que la sintaxis es válida.

¿Cómo se gestionan reglas nftables en tiempo de ejecución?

Puedes añadir y eliminar reglas sin editar el archivo de configuración. Estos cambios son temporales y se pierden al reiniciar a menos que los guardes.

Añadir una regla en tiempo de ejecución:

nft add rule inet firewall inbound tcp dport 8080 accept

Listar el conjunto de reglas actual:

nft list ruleset

Eliminar una regla por su número de handle. Primero, lista las reglas con handles:

nft -a list chain inet firewall inbound

Cada regla muestra un sufijo # handle N. Elimina por handle:

nft delete rule inet firewall inbound handle 15

Para guardar los cambios en tiempo de ejecución al archivo de configuración:

nft list ruleset > /etc/nftables.conf

Añade la línea shebang de vuelta al principio del archivo:

sed -i '1i #!/usr/sbin/nft -f' /etc/nftables.conf

¿Cómo se aplican y persisten las reglas nftables?

Aplica la configuración:

nft -f /etc/nftables.conf

Verifica que las reglas se cargaron:

nft list ruleset

Deberías ver la tabla completa con todas las cadenas y reglas. Si hay errores de sintaxis, nft -f mostrará el número de línea y el error.

Activa nftables en el arranque:

systemctl enable --now nftables

enable lo hace sobrevivir a reinicios. --now lo inicia de inmediato. Verifica que el servicio está corriendo:

systemctl status nftables

La salida esperada incluye Active: active (exited). El estado exited es normal. nftables carga las reglas en el kernel y termina. Las reglas permanecen activas en el espacio del kernel.

Confirma que está activado para el próximo arranque:

systemctl is-enabled nftables

Esperado: enabled.

¿Cómo se leen los logs de nftables?

El conjunto de reglas incluye una instrucción log antes del drop final. Los paquetes descartados aparecen en el log del kernel con el prefijo [nftables] Dropped:.

Ver paquetes descartados en tiempo real:

journalctl -k -f | grep nftables

Una entrada de log típica:

Mar 19 14:23:01 vps kernel: [nftables] Dropped: IN=eth0 OUT= SRC=203.0.113.55 DST=198.51.100.1 PROTO=TCP SPT=44521 DPT=3389

Esto te indica: una IP externa (203.0.113.55) intentó alcanzar el puerto 3389 (RDP) en tu servidor y fue descartada. Es tráfico de escaneo normal. Si ves tu propia IP en el campo SRC, tienes un problema con las reglas.

Para evitar spam en los logs en servidores muy escaneados, la sección de resolución de problemas a continuación explica cómo añadir un límite de tasa a la regla de log.

Lista de verificación de nftables

  1. Lista el conjunto de reglas completo: nft list ruleset
  2. Comprueba el servicio: systemctl is-enabled nftables
  3. Prueba SSH desde un segundo terminal (mantén tu sesión actual abierta)
  4. Prueba desde tu máquina local:
nc -zv YOUR_SERVER_IP 22

Esperado: conexión exitosa.

nc -zv YOUR_SERVER_IP 25

Esperado: conexión rechazada o timeout.

  1. Comprueba los paquetes descartados en los logs:
journalctl -k | grep "nftables"

¿Cómo se evita quedarse fuera de SSH al cambiar reglas de firewall?

Quedarse fuera de SSH es el mayor riesgo al configurar un firewall. Dos salvaguardas lo previenen.

Salvaguarda 1: probar siempre en un segundo terminal

Antes de cerrar tu sesión SSH después de cambiar reglas de firewall, abre un nuevo terminal y conéctate por SSH a tu servidor. Si la nueva conexión funciona, tus reglas son correctas. Si falla, vuelve a tu sesión original y corrige las reglas.

Nunca cierres tu sesión SSH activa hasta que hayas confirmado que una segunda conexión funciona.

Salvaguarda 2: seguridad temporizada con at

Cuando pruebes cambios en nftables, programa un trabajo que borre automáticamente todas las reglas después de 5 minutos. Si tus nuevas reglas te dejan fuera, espera 5 minutos e inténtalo de nuevo.

at now + 5 minutes <<< 'nft flush ruleset'

Si at no está instalado:

apt install -y at
systemctl enable --now atd
at now + 5 minutes <<< 'nft flush ruleset'

Después de confirmar que tus reglas funcionan, cancela la seguridad:

atrm $(atq | awk '{print $1}')

Para UFW, la seguridad equivalente:

at now + 5 minutes <<< 'ufw disable'

¿Qué pasa con Docker y el firewall?

Docker manipula iptables directamente para configurar la red de contenedores. Cuando publicas un puerto con -p 8080:80, Docker crea reglas NAT que ignoran UFW por completo. Tus reglas ufw deny no tienen efecto en los puertos publicados por Docker.

Es la sorpresa de firewall más común en VPS Linux. Un puerto que creías bloqueado está completamente abierto porque Docker enrutó el tráfico alrededor de tu firewall.

Dos soluciones:

  1. Usa nftables en lugar de UFW. nftables no tiene el mismo problema de bypass porque controlas todo el conjunto de reglas.
  2. Aplica el arreglo de la cadena DOCKER-USER. Ver Docker ignora UFW: 4 soluciones probadas para tu VPS para la guía paso a paso que fuerza al tráfico Docker a pasar por UFW.

Si ejecutas Docker en producción, nftables es la opción más segura.

Referencia de puertos comunes

Servicio Puerto Protocolo Comando UFW Regla nftables
SSH 22 TCP ufw allow 22/tcp tcp dport 22 accept
HTTP 80 TCP ufw allow 80/tcp tcp dport 80 accept
HTTPS 443 TCP ufw allow 443/tcp tcp dport 443 accept
DNS 53 TCP/UDP ufw allow 53 tcp dport 53 accept; udp dport 53 accept
PostgreSQL 5432 TCP ufw allow 5432/tcp tcp dport 5432 accept
MySQL 3306 TCP ufw allow 3306/tcp tcp dport 3306 accept

No expongas puertos de base de datos a internet. Si necesitas acceso remoto a la base de datos, usa un túnel SSH o restringe a IPs específicas:

UFW:

ufw allow from 198.51.100.0/24 to any port 5432 proto tcp comment 'PostgreSQL from trusted network'

nftables (añadir antes del drop final en la cadena inbound):

tcp dport 5432 ip saddr 198.51.100.0/24 accept

Resolución de problemas

¿Algo salió mal?

Bloqueado fuera de SSH: Usa la consola VNC/serie de tu proveedor para conectarte. Después ejecuta ufw disable o nft flush ruleset para borrar todas las reglas. Vuelve a añadir tu regla de permiso SSH antes de reactivar el firewall.

Las reglas no persisten tras reiniciar (nftables): Comprueba que el servicio está activado: systemctl is-enabled nftables. Si muestra disabled, ejecuta systemctl enable nftables. Verifica también que /etc/nftables.conf es sintácticamente válido: nft -c -f /etc/nftables.conf (la opción -c comprueba la sintaxis sin aplicar).

UFW muestra reglas pero el tráfico sigue bloqueado: Comprueba si hay reglas nftables o iptables en conflicto: nft list ruleset e iptables -L -n. Dos herramientas de firewall ejecutándose simultáneamente producen resultados impredecibles.

Los logs llenan el disco: Si activaste el logging y el servidor recibe mucho tráfico de escaneo, los logs pueden crecer rápido. Baja el nivel de log (ufw logging low) o añade un límite de tasa a la regla de log de nftables:

log prefix "[nftables] Dropped: " limit rate 10/minute counter drop

No puedo conectar después de activar la limitación de tasa: El limitador puede ser demasiado estricto. Para nftables, inspecciona el set dinámico: nft list set inet firewall ssh_ratelimit. Para UFW, ufw limit usa un umbral fijo de 6 conexiones/30 segundos que no es configurable. Si es demasiado estricto, usa un simple ufw allow y apóyate en Fail2Ban Instalar y configurar Fail2Ban en un VPS Linux.

Próximos pasos

Un firewall bloquea los puertos no deseados. No detecta intentos de inicio de sesión fallidos repetidos ni ataques a nivel de aplicación. Para completar tu base de seguridad VPS:

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

¿Listo para probarlo?

Despliega tu propio servidor en segundos. Linux, Windows o FreeBSD.

Ver planes VPS