UFW vs nftables: cómo configurar el firewall de un VPS Linux
Publicado el 2026-10-26 por frfrand
Reglas de acceso Ubuntu, SSH y puertos de API con mínimo privilegio

Te preguntan qué firewall configurar en un VPS Ubuntu: UFW o nftables. No son rivales exactos. UFW es una interfaz sencilla para gestionar reglas; nftables es una infraestructura de filtrado más flexible dentro de Linux.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa UFW vs nftables y cuándo lo necesitás
Las capas y backends dependen de la distribución. Lo importante es entender las reglas efectivas y no combinar cambios sin saber qué sistema las administra. Un firewall controla tráfico, pero no corrige permisos de una API ni contraseñas inseguras.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
sudo ufw status verbose
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Antes de habilitar reglas: verificar SSH desde otra sesión
sudo ufw enable
# Diagnóstico de reglas nftables
sudo nft list ruleset
Los dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Listá puertos realmente necesarios: para una web suelen ser 80/443 y acceso administrativo restringido.
- Paso 2. Confirmá que SSH seguirá permitido ANTES de activar un firewall remoto.
- Paso 3. Elegí un mecanismo de gestión coherente con el sistema y documentalo.
- Paso 4. Probá desde fuera los puertos autorizados y confirmá que la base permanece cerrada.
- Verificación. Revisá reglas tras instalar Docker u otras herramientas que cambian la red.
Cuando termines, comprobá la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecutá una petición de lectura, una escritura en una base de prueba y consultá los logs del proceso.
Ejemplo de un proyecto de verdad
Un VPS sirve tres dominios por Nginx. Necesita exponer HTTPS, no los puertos internos de Django, Redis o PostgreSQL. El firewall limita superficies, mientras Nginx envía tráfico al servicio interno correcto.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
Activar UFW en remoto sin permitir SSH puede dejarte sin acceso. Docker y otras herramientas pueden introducir reglas que alteran el comportamiento esperado: comprobá el filtrado efectivo, no sólo la pantalla del panel.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
En ArduMaker, combinar reglas de red del VPS con acceso por equipos y servicios evita exponer bases por accidente. Registrá qué puertos pertenecen a cada aplicación.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que podés explicar, verificar y recuperar cuando algo falla.