Elegir entre UFW, iptables y nftables puede parecer una decisión secundaria cuando estás configurando un servidor Linux. Sin embargo, cuando necesitas resolver una incidencia de seguridad, abrir un puerto urgentemente o revisar por qué una conexión está siendo bloqueada, descubres lo importante que resulta tener un firewall bien configurado.
En mi experiencia administrando servidores Linux, he trabajado con situaciones muy diferentes. Desde pequeños VPS que únicamente necesitan permitir conexiones SSH, HTTP y HTTPS, hasta servidores de alojamiento que gestionan cientos de páginas web, servicios de correo electrónico, bases de datos y numerosas conexiones simultáneas.
Y hay algo que tengo bastante claro: no existe un firewall que sea la mejor elección para todos los servidores.
UFW destaca por su facilidad de uso, iptables continúa siendo válido en numerosos entornos y nftables ofrece una arquitectura moderna y flexible para configuraciones avanzadas.
Pero ¿cuál deberías utilizar realmente?
En esta comparativa de UFW vs iptables vs nftables vamos a analizar sus diferencias, ventajas, inconvenientes, ejemplos de configuración y, sobre todo, en qué situaciones recomiendo cada uno.
UFW, iptables o nftables: ¿cuál es mejor para tu servidor?
Si buscas una respuesta rápida, mi recomendación es bastante sencilla: UFW para administrar un VPS sin complicaciones, nftables para nuevas configuraciones avanzadas e iptables cuando existen motivos técnicos para mantenerlo.
Eso no significa que UFW sea exclusivamente para principiantes, que iptables haya dejado de ser útil o que nftables sea obligatorio en todos los servidores modernos.
La elección depende del sistema operativo, los servicios que se ejecutan, las herramientas que gestionan las reglas y la complejidad real de la infraestructura.
Comparativa rápida de características
| Característica | UFW | iptables | nftables |
|---|---|---|---|
| Facilidad de uso | Alta | Baja | Media |
| Curva de aprendizaje | Baja | Alta | Media-alta |
| Configuraciones sencillas | Excelente | Buena | Buena |
| Reglas complejas | Limitadas en su interfaz habitual | Muy flexible | Muy flexible |
| IPv4 e IPv6 | Sí, con configuración adecuada | Herramientas separadas en su interfaz clásica | Familia inet para reglas conjuntas |
| Conjuntos de IP | Depende del backend y la configuración | Mediante herramientas adicionales como ipset | Integrados |
| Actualizaciones atómicas de reglas | Depende del backend | Limitadas en su modelo tradicional | Sí, mediante transacciones |
| Servidores antiguos | Depende del entorno | Habitual | Requiere comprobar compatibilidad |
| Mi recomendación | VPS sencillos | Sistemas heredados compatibles | Nuevos proyectos avanzados |
Hay una diferencia importante que conviene conocer desde el principio: UFW no es exactamente una alternativa tecnológica del mismo nivel que iptables y nftables.
UFW es una herramienta de administración que simplifica la configuración del firewall. iptables y nftables son interfaces con las que se gestionan reglas de filtrado del subsistema Netfilter de Linux.
Además, en muchas distribuciones actuales, los comandos de iptables pueden utilizar internamente el backend nf_tables mediante la capa de compatibilidad iptables-nft. Por eso, comparar únicamente los nombres de las herramientas no siempre refleja qué tecnología está procesando realmente las reglas.
Mi recomendación según el tipo de servidor
VPS Ubuntu con una web o pocos servicios
UFW
Reglas sencillas, administración rápida y menos complejidad.
Servidor nuevo con filtrado avanzado
nftables
Adecuado para conjuntos de direcciones IP, políticas detalladas y configuraciones complejas.
Servidor existente con reglas heredadas
iptables
Mantenerlo puede ser razonable cuando las reglas están documentadas y las dependencias funcionan correctamente.
Por ejemplo, si tengo que configurar un VPS con Ubuntu para alojar una página web, normalmente elegiría UFW. No necesito una arquitectura compleja para permitir únicamente conexiones por los puertos 22, 80 y 443.
Sin embargo, si estoy diseñando un servidor con diferentes redes, listas de direcciones IP y políticas de filtrado avanzadas, nftables me parece una opción más interesante.
Y si encuentro un servidor que lleva años funcionando correctamente con iptables, no veo ninguna necesidad de migrarlo simplemente porque exista una herramienta más reciente.
Lo que realmente importa es que el firewall proteja el sistema, que sus reglas puedan entenderse y que cualquier administrador autorizado sea capaz de mantenerlas.
Cómo funcionan los firewalls en Linux
Antes de comparar sus comandos, conviene entender qué ocurre realmente cuando una conexión llega a un servidor Linux.
Un firewall permite establecer reglas para aceptar, rechazar o descartar determinados paquetes de red. De esta manera, podemos controlar qué servicios reciben conexiones, desde qué direcciones IP y bajo qué condiciones.
Por ejemplo, un servidor web público normalmente necesita aceptar tráfico HTTP y HTTPS desde Internet, mientras que su base de datos podría estar disponible únicamente para aplicaciones internas.
Ambos servicios pueden funcionar en el mismo servidor, pero no deberían tener necesariamente las mismas reglas de acceso.
Qué es Netfilter y cómo se relaciona con las tres herramientas
Netfilter es el subsistema del kernel Linux que proporciona funciones de filtrado y tratamiento de paquetes de red.
iptables y nftables permiten configurar diferentes mecanismos relacionados con ese subsistema.
UFW, por su parte, simplifica la administración de reglas sin que tengamos que escribir directamente todas las instrucciones de bajo nivel.
Herramientas de administración
UFW
iptables
nftables
Interfaces y backends de reglas
La ruta concreta depende de la herramienta, la versión y la configuración
Netfilter — kernel Linux
Filtrado, seguimiento de conexiones y tratamiento de paquetes
Este esquema es conceptual: UFW suele gestionar reglas mediante mecanismos compatibles con iptables, mientras que iptables puede utilizar el backend tradicional o el de nftables. No todas las herramientas siguen una única ruta idéntica.
Entender esta diferencia evita un error frecuente: pensar que instalar varios gestores de firewall proporciona automáticamente varias capas independientes de seguridad.
En realidad, varias aplicaciones pueden estar modificando reglas que terminan interactuando dentro del mismo sistema de filtrado.
Diferencias entre UFW, iptables y nftables
UFW significa Uncomplicated Firewall. Su objetivo es ofrecer una interfaz sencilla para configurar políticas habituales, especialmente en servidores Ubuntu.
Con iptables trabajamos directamente con comandos que permiten añadir reglas a tablas y cadenas de filtrado. Su sintaxis ofrece un control detallado, aunque las configuraciones grandes pueden resultar difíciles de mantener.
nftables utiliza una estructura más moderna que permite administrar tablas, cadenas, reglas, conjuntos y otros elementos mediante una sintaxis más uniforme.
Una diferencia importante es que nftables puede gestionar IPv4 e IPv6 en una misma tabla de familia inet, mientras que la interfaz tradicional de iptables utiliza comandos separados como iptables e ip6tables.
También incorpora conjuntos de datos que facilitan la gestión de grandes grupos de direcciones IP sin necesidad de crear una regla individual por cada dirección.
Qué son iptables-legacy e iptables-nft
Cuando utilizamos iptables en un servidor moderno, conviene comprobar qué variante está ejecutándose.
Existen dos posibilidades habituales:
- iptables-legacy: utiliza la interfaz tradicional de iptables con el kernel.
- iptables-nft: permite utilizar comandos con sintaxis iptables sobre la infraestructura nf_tables mediante una capa de compatibilidad.
Podemos comprobar la versión con:
sudo iptables --versionDependiendo del sistema, la salida puede mostrar una indicación como legacy o nf_tables.
Esto resulta especialmente importante cuando una aplicación añade reglas automáticamente. Dos servidores que utilizan comandos aparentemente idénticos podrían estar trabajando con backends diferentes.
Mi consejo es revisar siempre la configuración existente antes de instalar o activar otro gestor. Saber qué herramienta administra realmente las reglas puede evitar bastantes problemas posteriores.
UFW: el firewall más sencillo para un VPS Ubuntu
Cuando alguien contrata su primer servidor VPS y necesita establecer unas reglas básicas de seguridad, UFW suele ser una de las herramientas que más recomiendo.
Su principal ventaja es que permite expresar reglas de forma sencilla, sin necesidad de conocer todos los detalles de las tablas y cadenas de Netfilter.
Para permitir conexiones SSH, por ejemplo, podemos utilizar un comando fácil de interpretar:
sudo ufw allow 22/tcpY para consultar las reglas activas:
sudo ufw status numberedEsta facilidad puede parecer poco importante cuando administramos un único servidor, pero adquiere más valor cuando tenemos que revisar configuraciones, explicar cambios a otro administrador o resolver rápidamente una incidencia.
Ventajas e inconvenientes de UFW
Entre sus principales ventajas destacaría la facilidad de instalación, la claridad de sus comandos y la posibilidad de establecer políticas predeterminadas sin crear archivos extensos.
También admite reglas por dirección IP, interfaces, puertos y perfiles de aplicaciones.
Por ejemplo, podemos limitar el acceso SSH a una IP concreta:
sudo ufw allow from 203.0.113.10 \
to any port 22 proto tcpLa dirección utilizada es un ejemplo y debe sustituirse por una dirección real autorizada.
Sin embargo, UFW también tiene limitaciones.
Su interfaz simplificada no siempre resulta la más conveniente para escenarios que necesitan elementos avanzados de filtrado, conjuntos dinámicos o reglas complejas.
Además, no debemos asumir que gestiona automáticamente todas las modificaciones realizadas por otras aplicaciones. Servicios que manipulan directamente el filtrado de red pueden introducir reglas que requieran una revisión adicional.
Por tanto, UFW es sencillo, pero eso no significa que podamos olvidarnos de cómo funciona la red del servidor.
Cuándo recomiendo utilizar UFW
En mi caso, lo elegiría especialmente para un VPS Ubuntu o Debian con unos pocos servicios expuestos.
Imaginemos un servidor destinado a alojar WordPress, una aplicación web o una pequeña tienda online.
Normalmente necesitaremos conexiones HTTP y HTTPS, además del acceso SSH para administrarlo.
En una instalación así, crear una configuración demasiado sofisticada puede introducir más posibilidades de error que ventajas reales.
También considero UFW una buena opción cuando la administración recae en una persona que no trabaja diariamente con reglas avanzadas de firewall.
Prefiero un conjunto de reglas sencillo, correctamente documentado y revisado periódicamente que una configuración compleja que nadie se atreva a modificar.
Ejemplo de configuración básica con SSH, HTTP y HTTPS
En Ubuntu podemos instalar UFW, si todavía no está disponible, mediante:
sudo apt update
sudo apt install ufwAntes de activar reglas, es importante comprobar el puerto SSH real y si existen restricciones adicionales en el proveedor cloud.
Para una instalación nueva, sin reglas previas ni otros gestores interfiriendo, la configuración habitual sería:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcpLas tres reglas permiten conexiones SSH, HTTP y HTTPS respectivamente.
Si el servidor utiliza otro puerto SSH, debemos permitir ese puerto en lugar del 22.
Una vez comprobadas las reglas, podemos activar UFW:
sudo ufw enableY revisar su estado:
sudo ufw status verbosePrecaución antes de activar UFW por SSH
En un servidor remoto, mantendría una sesión administrativa abierta, prepararía un acceso de recuperación desde la consola del proveedor y comprobaría una segunda conexión SSH antes de cerrar la sesión original. También revisaría IPv6 y cualquier regla previa.
En definitiva, UFW permite proteger configuraciones habituales con pocos comandos. Es precisamente lo que busco cuando el servidor no necesita un filtrado especialmente elaborado.
iptables: control avanzado y compatibilidad con servidores existentes
iptables ha sido durante muchos años una de las herramientas más utilizadas para configurar firewalls en Linux.
Si llevas tiempo administrando servidores, probablemente te hayas encontrado con sus comandos en alguna ocasión, especialmente en instalaciones antiguas, scripts de administración o herramientas de seguridad desarrolladas cuando iptables era la opción predominante.
Su principal característica es que permite definir reglas detalladas para controlar el tráfico de red.
Podemos establecer condiciones basadas en direcciones IP de origen y destino, protocolos, puertos, interfaces y estados de conexión, entre otros criterios.
El inconveniente es que su sintaxis resulta menos intuitiva que la de UFW.
Ventajas e inconvenientes de iptables
La principal ventaja de iptables es su amplia trayectoria dentro del ecosistema Linux.
Existen numerosas configuraciones, scripts, herramientas y procedimientos que utilizan su interfaz. Esto facilita mantener sistemas heredados sin necesidad de modificar componentes que ya funcionan correctamente.
También ofrece un control muy detallado del filtrado de paquetes y permite construir políticas complejas mediante diferentes tablas y cadenas.
Sin embargo, tiene algunos inconvenientes importantes.
Por un lado, las reglas se administran mediante una sintaxis que puede resultar complicada cuando necesitamos combinar numerosas condiciones.
Por otro, las configuraciones tradicionales con muchas reglas individuales pueden dificultar su revisión y mantenimiento.
Además, la distinción entre iptables-legacy e iptables-nft puede introducir cierta confusión cuando diferentes herramientas utilizan backends distintos.
Conviene aclarar que iptables no ha dejado de funcionar simplemente porque nftables sea más moderno.
De hecho, muchas distribuciones mantienen herramientas compatibles con iptables, aunque internamente utilicen nftables como backend.
El verdadero problema aparece cuando no sabemos qué variante estamos utilizando o cómo interactúa con los demás componentes del servidor.
Cuándo sigue teniendo sentido utilizarlo
En HostingTG trabajamos con diferentes configuraciones de servidores Linux, y una de las lecciones más importantes que he aprendido es que no conviene cambiar un sistema que funciona correctamente sin estudiar antes sus dependencias.
Esto se aplica especialmente a servidores que utilizan scripts personalizados, aplicaciones antiguas o herramientas de seguridad que esperan encontrar una interfaz compatible con iptables.
Imaginemos un servidor de alojamiento que lleva años funcionando de manera estable.
Sus reglas están documentadas, los administradores conocen su funcionamiento y los servicios dependen de determinados scripts.
¿Merece la pena migrarlo inmediatamente a nftables?
No necesariamente.
Primero comprobaría qué ventajas concretas obtendríamos con la migración, qué aplicaciones podrían verse afectadas y si existe algún requisito técnico o de soporte que justifique el cambio.
Si el sistema sigue siendo compatible, está actualizado y sus reglas funcionan correctamente, mantener iptables puede ser una decisión perfectamente razonable.
Eso sí, también revisaría la evolución de la distribución Linux utilizada y planificaría la transición antes de llegar a un escenario sin soporte.
Ejemplo de reglas básicas con iptables
Podemos consultar las reglas actuales mediante:
sudo iptables -L -n -vPara verlas con una sintaxis similar a la utilizada al crearlas:
sudo iptables -SUna regla para permitir conexiones SSH entrantes podría ser:
sudo iptables -A INPUT -p tcp \
--dport 22 -j ACCEPTPara HTTP:
sudo iptables -A INPUT -p tcp \
--dport 80 -j ACCEPTY para HTTPS:
sudo iptables -A INPUT -p tcp \
--dport 443 -j ACCEPTEstas instrucciones añaden reglas a la cadena INPUT, pero no constituyen por sí solas una política de seguridad completa.
Su resultado depende del orden de las reglas existentes, las políticas predeterminadas y otras cadenas que puedan intervenir. Una regla añadida al final puede no llegar a evaluarse si otra anterior ya ha decidido qué hacer con el paquete.
En un firewall restrictivo normalmente también hay que contemplar el tráfico de loopback y las conexiones establecidas:
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT \
-m conntrack \
--ctstate ESTABLISHED,RELATED \
-j ACCEPTEl orden debe adaptarse a la configuración existente.
Además, las reglas de IPv6 se gestionan mediante ip6tables en la interfaz clásica, y la persistencia de los cambios requiere mecanismos adicionales que dependen de la distribución.
No recomiendo copiar estas reglas directamente en un servidor de producción sin revisar antes su política actual. Tampoco cambiaría la política de INPUT a DROP durante una sesión SSH remota sin disponer de un plan de recuperación comprobado.
Esta es precisamente una de las razones por las que prefiero UFW para configuraciones sencillas. iptables ofrece mucho control, pero también exige entender exactamente qué estamos modificando.
nftables: la alternativa moderna para configuraciones avanzadas
nftables es el sucesor moderno del sistema tradicional de reglas de iptables dentro del ecosistema Netfilter.
Su desarrollo busca proporcionar una forma más uniforme y flexible de administrar el filtrado de paquetes en Linux.
Una de sus características más interesantes es que permite trabajar con tablas, cadenas, conjuntos, mapas y reglas utilizando una arquitectura común.
Esto simplifica determinadas configuraciones que con iptables tradicional pueden requerir numerosos comandos o herramientas complementarias.
En mi caso, si tuviera que diseñar desde cero un servidor Linux con necesidades avanzadas de filtrado y sin dependencias heredadas, nftables sería mi primera opción.
Ventajas e inconvenientes de nftables
Una de sus principales ventajas es la posibilidad de gestionar reglas de IPv4 e IPv6 dentro de una tabla de familia inet.
Esto evita duplicar parte de la configuración cuando queremos aplicar políticas equivalentes a ambos protocolos.
Otra ventaja importante es su compatibilidad con conjuntos de datos.
Imaginemos que necesitamos permitir conexiones administrativas únicamente desde varias direcciones IP.
Con nftables podemos agruparlas dentro de un conjunto y utilizar ese conjunto en nuestras reglas.
También destaca por la posibilidad de aplicar cambios mediante transacciones atómicas, evitando determinados estados intermedios durante las actualizaciones del conjunto de reglas.
Esto resulta especialmente útil cuando administramos sistemas con políticas de filtrado complejas.
Por supuesto, nftables también presenta inconvenientes.
Su sintaxis exige aprendizaje, especialmente cuando empezamos a utilizar conjuntos, mapas, hooks o diferentes familias de tablas.
Además, no siempre es conveniente administrarlo directamente si el servidor ya utiliza un panel de control o una herramienta que genera y modifica reglas automáticamente.
Una configuración avanzada de nftables puede ser elegante desde el punto de vista técnico, pero no servirá de mucho si introduce conflictos con otros componentes del sistema.
Conjuntos de IP, IPv4, IPv6 y reglas atómicas
Supongamos que queremos permitir conexiones SSH desde tres direcciones IP concretas.
En nftables podemos definir un conjunto como este:
set administradores {
type ipv4_addr
elements = {
203.0.113.10,
203.0.113.20,
203.0.113.30
}
}Y utilizarlo posteriormente en una regla de una cadena apropiada:
ip saddr @administradores tcp dport 22 acceptEs un fragmento ilustrativo que debe integrarse en una tabla, cadena y política de filtrado válidas.
La ventaja es que podemos mantener las direcciones autorizadas dentro de un mismo elemento lógico, en lugar de crear reglas independientes para cada una.
Las direcciones del ejemplo pertenecen a un rango reservado para documentación; deben reemplazarse por las IP reales.
Otro aspecto interesante es la gestión conjunta de IPv4 e IPv6.
Mediante una tabla inet, nftables permite escribir reglas que se aplican a ambos protocolos cuando los criterios utilizados son compatibles.
Eso no significa que ambos protocolos deban tratarse siempre de forma idéntica. Por ejemplo, para utilizar conjuntos de direcciones IPv4 e IPv6 debemos tener en cuenta sus respectivos tipos.
Respecto a las actualizaciones atómicas, nftables permite preparar cambios y aplicarlos como una transacción. Así se reduce el riesgo de exponer temporalmente el sistema a estados intermedios entre varias operaciones.
Esta capacidad resulta especialmente atractiva en infraestructuras donde las políticas cambian con frecuencia.
Ejemplo de configuración básica con nftables
Para comprender su sintaxis, podemos partir del siguiente archivo ilustrativo:
table inet filtro_web {
chain input {
type filter hook input priority 0;
policy drop;
iifname "lo" accept
ct state established,related accept
meta l4proto icmp accept
meta l4proto ipv6-icmp accept
tcp dport { 22, 80, 443 } accept
}
chain output {
type filter hook output priority 0;
policy accept;
}
}En este ejemplo definimos una tabla de familia inet llamada filtro_web.
Dentro de ella creamos una cadena input con política predeterminada drop. Esto significa que los paquetes entrantes que alcancen esa política sin coincidir con una regla de aceptación serán descartados.
A continuación permitimos el tráfico de loopback, las conexiones establecidas o relacionadas, determinados protocolos de control y las conexiones TCP entrantes a los puertos 22, 80 y 443.
La cadena output permite el tráfico saliente.
Importante: este ejemplo muestra la estructura de un firewall básico, pero no debe aplicarse sin adaptación a un servidor real.
No incluye reglas de reenvío de tráfico, NAT, particularidades de contenedores ni todas las necesidades posibles de una infraestructura. Además, permitir ICMP e ICMPv6 de forma general es una decisión didáctica; las políticas concretas deben ajustarse a los requisitos del servidor.
Para consultar las reglas administradas mediante nftables podemos utilizar:
sudo nft list rulesetY para comprobar la sintaxis de un archivo antes de aplicarlo:
sudo nft -c -f /etc/nftables.confLa comprobación sintáctica no garantiza que las reglas sean seguras ni que permitan conservar el acceso remoto.
También hay que tener especial cuidado con archivos que incluyen instrucciones como flush ruleset, ya que pueden eliminar reglas gestionadas por otras herramientas.
Cuando administro servidores con necesidades complejas, esta capacidad para organizar reglas me parece una ventaja importante de nftables. Pero siempre acompañada de documentación, pruebas y un mecanismo para recuperar el acceso si algo sale mal.
Diferencias entre UFW, iptables y nftables: comparación completa
Hasta ahora hemos visto cómo funciona cada herramienta y qué posibilidades ofrece.
Sin embargo, para elegir correctamente un firewall hay que valorar algo más que su sintaxis.
La facilidad de mantenimiento, la compatibilidad con otras aplicaciones y la capacidad para resolver incidencias son factores tan importantes como las funciones avanzadas.
De hecho, he visto cómo una configuración aparentemente sencilla termina siendo complicada de mantener porque diferentes herramientas modifican las reglas sin una organización clara.
Facilidad de uso y mantenimiento
UFW destaca especialmente en este apartado.
Sus comandos son fáciles de interpretar, permite consultar las reglas configuradas y evita tener que trabajar directamente con muchos detalles internos de Netfilter.
Esto resulta útil en servidores que únicamente ofrecen unos pocos servicios.
iptables ofrece un control más detallado, pero las reglas complejas pueden llegar a ser difíciles de seguir, especialmente cuando intervienen numerosas cadenas personalizadas.
nftables permite organizar configuraciones avanzadas con una estructura que puede resultar más clara una vez que conocemos su sintaxis.
Por tanto, la elección dependerá también de quién va a administrar el servidor.
Si la persona responsable apenas necesita abrir y cerrar puertos, probablemente obtenga más ventajas utilizando UFW.
Si hablamos de un equipo de administradores acostumbrado a diseñar políticas de red complejas, nftables puede ofrecer una mayor flexibilidad.
Rendimiento, flexibilidad y escalabilidad
Es habitual encontrar comparativas que presentan nftables como una herramienta automáticamente más rápida que iptables.
Sin embargo, conviene matizar esa afirmación.
El rendimiento real depende de numerosos factores: la cantidad de reglas, su organización, los tipos de coincidencia, el tráfico recibido y las versiones del kernel y del sistema.
Una configuración sencilla con unas pocas reglas no necesariamente mostrará diferencias relevantes entre las distintas alternativas.
La ventaja arquitectónica de nftables aparece especialmente cuando necesitamos utilizar conjuntos, mapas y estructuras que permiten representar determinadas políticas de forma más eficiente.
Por ejemplo, administrar miles de direcciones IP con conjuntos puede resultar más práctico que crear una regla individual para cada dirección.
Eso no significa que cualquier instalación de nftables supere automáticamente a cualquier configuración de iptables.
Tampoco sería correcto presentar una comparación de rendimiento entre UFW y nftables sin conocer el backend utilizado por UFW.
Mi recomendación es no elegir un firewall únicamente por supuestas diferencias de velocidad.
Para un VPS convencional, la facilidad de administración probablemente tenga más importancia que cualquier mejora teórica de rendimiento.
Para una infraestructura de filtrado intensivo, en cambio, sí estudiaría con detalle las capacidades avanzadas de nftables y realizaría pruebas representativas del tráfico real.
Compatibilidad con distribuciones y otras herramientas
Este es uno de los aspectos que más importancia tiene en servidores de producción.
Ubuntu y Debian ofrecen diferentes herramientas para administrar el firewall, incluyendo UFW y los comandos tradicionales de iptables.
En distribuciones del ecosistema Red Hat es habitual encontrar firewalld como herramienta de administración, frecuentemente sobre nftables.
También existen aplicaciones que crean o modifican sus propias reglas.
Es el caso de determinados sistemas de contenedores, herramientas de seguridad y paneles de administración de servidores.
Por eso, antes de decidir qué firewall instalar, comprobaría siempre qué herramientas están activas.
Algunos comandos útiles son:
sudo ufw statussudo iptables -Vsudo nft list rulesetEstos comandos permiten consultar información, pero no identifican por sí solos todos los gestores que están administrando el filtrado.
También conviene comprobar los servicios del sistema y la documentación del software instalado.
Mi principal preocupación no es encontrar un servidor que siga utilizando iptables. Me preocupa mucho más encontrar un servidor donde nadie sabe qué aplicación está modificando las reglas del firewall.
Qué firewall elegir según el tipo de servidor
La mejor manera de elegir entre UFW, iptables y nftables es analizar cómo se utiliza realmente el servidor.
No tiene las mismas necesidades un VPS que aloja una única página web que una máquina dedicada con múltiples servicios de alojamiento, redes privadas y aplicaciones que administran sus propias reglas.
En HostingTG trabajamos con diferentes configuraciones de servidores Linux, y esa variedad me ha enseñado que la complejidad del firewall debe responder a las necesidades del proyecto, no al deseo de utilizar la herramienta más avanzada.
VPS Ubuntu para una página web
Para un VPS con Ubuntu destinado a alojar una página web, mi primera recomendación suele ser UFW.
En una instalación habitual, el servidor necesita aceptar conexiones HTTP y HTTPS y permitir el acceso administrativo mediante SSH.
La configuración es sencilla, resulta fácil comprobar las reglas y podemos modificar los puertos autorizados cuando cambia el proyecto.
También permite aplicar restricciones adicionales, como limitar el acceso SSH a determinadas direcciones IP.
Para muchas páginas web, blogs y pequeñas aplicaciones, estas funcionalidades son suficientes.
Eso sí, antes de utilizarlo comprobaría que el servidor no tenga otro gestor activo y que la configuración sea compatible con los servicios instalados.
Por ejemplo, un VPS que utiliza Docker puede necesitar precauciones adicionales, ya que la publicación de puertos de los contenedores puede interactuar con reglas gestionadas fuera de UFW.
También revisaría la configuración de IPv6 para evitar que un servicio quede expuesto por una vía que no hemos contemplado.
Servidores de hosting con cPanel, Plesk o DirectAdmin
La situación cambia bastante cuando administramos servidores de alojamiento con paneles de control.
Herramientas como cPanel, Plesk o DirectAdmin pueden coexistir con sistemas adicionales de seguridad que administran reglas, bloquean direcciones IP o protegen determinados servicios.
En estos entornos no recomendaría instalar UFW, nftables o cualquier otro gestor sin estudiar primero la configuración existente.
Lo importante es comprobar qué herramientas son compatibles con el panel, qué componentes modifican Netfilter y cómo se gestionan las reglas.
Un servidor de hosting puede necesitar permitir conexiones SMTP, IMAP, DNS, FTP, HTTP, HTTPS y otros protocolos, dependiendo de los servicios habilitados.
Bloquear uno de esos puertos por desconocimiento puede provocar incidencias que inicialmente parecen problemas del propio servicio.
He aprendido que en estos casos resulta especialmente importante mantener una administración coherente del firewall.
No se trata simplemente de utilizar una herramienta más potente, sino de evitar que varios sistemas interfieran entre sí.
Por eso, mi recomendación es seguir la arquitectura de seguridad compatible y documentada para el panel y sus componentes instalados, en lugar de imponer un gestor diferente.
Servidores con múltiples servicios y reglas complejas
Cuando hablamos de servidores que necesitan controlar diferentes redes, conjuntos de direcciones IP, interfaces o políticas de acceso específicas, nftables empieza a ofrecer ventajas más interesantes.
Por ejemplo, imaginemos una infraestructura con aplicaciones web públicas, bases de datos privadas y servicios administrativos accesibles únicamente desde una VPN.
En este escenario necesitamos algo más que abrir los puertos 80 y 443.
Debemos definir qué sistemas pueden comunicarse entre sí, qué conexiones están autorizadas y cómo se mantienen las reglas cuando cambia la infraestructura.
nftables permite organizar este tipo de políticas mediante conjuntos, cadenas y otros elementos que facilitan su mantenimiento.
También resulta interesante para configuraciones nuevas en las que queremos administrar IPv4 e IPv6 de forma coordinada.
Si tuviera que diseñar una infraestructura así desde cero, estudiaría nftables como primera alternativa.
Pero no lo elegiría únicamente por ser moderno. Antes comprobaría su integración con los servicios, el sistema operativo y las herramientas de automatización previstas.
Servidores antiguos con configuraciones heredadas
Este es un escenario en el que no recomiendo realizar cambios innecesarios.
Si tenemos un servidor que utiliza iptables, funciona correctamente y mantiene unas reglas documentadas, no existe una obligación universal de migrarlo inmediatamente.
Primero analizaría el sistema operativo, las aplicaciones instaladas y las dependencias de seguridad.
También comprobaría si el servidor está utilizando iptables-legacy o iptables-nft.
A partir de ahí valoraría si merece la pena preparar una migración a nftables.
Por supuesto, mantener iptables no significa ignorar las actualizaciones de seguridad ni conservar indefinidamente un sistema operativo sin soporte.
Una cosa es mantener una herramienta compatible y otra muy diferente seguir utilizando una infraestructura obsoleta.
Mi criterio sería conservar la configuración mientras resulte segura, compatible y mantenible, y planificar la migración cuando existan razones técnicas suficientes.
Errores habituales al configurar un firewall en Linux
Una mala configuración del firewall puede provocar tantos problemas operativos como una ausencia de filtrado adecuado.
He visto que muchas incidencias no tienen su origen en la herramienta elegida, sino en cómo se modifican las reglas y en la falta de revisión de los servicios que realmente necesitan conectividad.
Por eso, antes de configurar UFW, iptables o nftables, conviene conocer algunos errores frecuentes.
Bloquear accidentalmente el acceso SSH
Probablemente sea uno de los errores más delicados cuando administramos un VPS remoto.
Imaginemos que activamos una política predeterminada que bloquea las conexiones entrantes, pero olvidamos permitir el puerto SSH utilizado por el servidor.
Si la nueva configuración impide establecer sesiones administrativas y cerramos la conexión actual, podemos quedarnos sin acceso remoto.
Para evitarlo, recomiendo comprobar el puerto SSH real, preparar las reglas de acceso antes de activar restricciones y disponer de una consola de recuperación proporcionada por el alojamiento.
También conviene mantener una sesión abierta mientras comprobamos que es posible iniciar otra nueva.
En servidores críticos, utilizaría además un mecanismo probado de reversión automática que restaure la configuración anterior si no confirmamos que el acceso funciona.
Mezclar gestores de firewall sin revisar las reglas
Este es uno de los problemas que más me preocupan cuando reviso la seguridad de un servidor.
Instalar UFW en una máquina que ya utiliza firewalld, scripts personalizados, reglas generadas por contenedores o herramientas del panel de hosting puede provocar resultados inesperados.
El hecho de que podamos instalar varias aplicaciones no significa que sea conveniente utilizarlas simultáneamente sin coordinación.
Por ejemplo, una regla que acepta tráfico en una cadena no garantiza necesariamente que otra cadena o hook independiente vaya a permitirlo. Del mismo modo, una herramienta podría modificar o eliminar reglas que otra necesita.
La solución no consiste en elegir a ciegas cuál de los gestores es mejor.
Primero hay que identificar quién administra las reglas, qué dependencias existen y qué procedimiento recomienda el fabricante o la distribución.
Olvidar IPv6, Docker o la persistencia de las reglas
Otro error frecuente es comprobar únicamente las reglas IPv4.
Si el servidor dispone de conectividad IPv6, debemos revisar también qué servicios están expuestos mediante ese protocolo.
Una aplicación puede estar correctamente restringida en IPv4 y seguir siendo accesible a través de IPv6 si las políticas no son equivalentes.
También conviene prestar atención a Docker y otros sistemas de contenedores, ya que pueden modificar reglas de filtrado y NAT al publicar puertos.
No debemos asumir que una política definida con UFW controla automáticamente todo el tráfico publicado por contenedores.
Finalmente, hay que comprobar la persistencia de las reglas.
Una configuración puede funcionar perfectamente hasta el siguiente reinicio y perderse si no se ha guardado mediante el mecanismo correspondiente.
En UFW, la herramienta administra su configuración persistente. Con iptables tradicional suelen utilizarse procedimientos adicionales, mientras que nftables puede cargar un archivo de configuración mediante el servicio correspondiente.
El procedimiento concreto depende de la distribución y de las herramientas instaladas.
No revisar las reglas tras cambios en el servidor
Un firewall no es algo que configuremos una vez y podamos olvidar para siempre.
Cuando añadimos servicios, cambiamos direcciones IP, instalamos aplicaciones o modificamos la arquitectura, es necesario revisar las reglas.
También puede ocurrir que un puerto que necesitábamos hace meses ya no tenga ninguna utilidad.
Mantenerlo abierto innecesariamente aumenta la superficie de exposición del servidor.
Por eso recomiendo revisar periódicamente qué servicios escuchan conexiones y cuáles necesitan realmente acceso externo.
En Linux podemos consultar los sockets en escucha con:
sudo ss -tulpenDespués debemos relacionar esa información con las reglas del firewall y con la exposición real del servidor.
Un servicio escuchando en una interfaz no implica necesariamente que sea accesible desde Internet; también intervienen el firewall local, el proveedor, el direccionamiento y otros controles de red.
Checklist antes de modificar el firewall
0 de 6 comprobacionesReiniciar
Identificar el gestor de firewall activo y sus dependencias
Guardar una copia de la configuración actual
Comprobar el puerto SSH y disponer de acceso de recuperación
Revisar los servicios expuestos mediante IPv4 e IPv6
Comprobar si Docker, el panel de hosting u otras aplicaciones gestionan reglas
Validar los cambios, su persistencia y la posibilidad de revertirlos
Una revisión de este tipo puede evitar problemas mucho más costosos que los minutos necesarios para realizarla.
¿Conviene migrar de iptables a nftables?
La transición de iptables a nftables es una cuestión que aparece con frecuencia cuando administramos servidores Linux.
La respuesta depende del entorno.
nftables es una tecnología más moderna y ofrece ventajas importantes para gestionar reglas complejas. Sin embargo, eso no significa que tengamos que migrar automáticamente todas las instalaciones existentes.
Para mí, la pregunta correcta no es si nftables es más reciente, sino qué problema vamos a resolver con la migración y qué riesgos implica realizarla.
Cuándo merece la pena la migración
Plantearía una migración especialmente cuando necesitamos nuevas capacidades que resultan más cómodas de administrar con nftables.
Por ejemplo, cuando tenemos grandes conjuntos de direcciones IP, queremos centralizar reglas de IPv4 e IPv6 o necesitamos reorganizar configuraciones tradicionales demasiado extensas.
También puede tener sentido cuando estamos renovando la infraestructura, actualizando distribuciones o sustituyendo herramientas heredadas.
En esos casos, aprovechar el cambio para adoptar nftables puede simplificar el mantenimiento futuro.
Sin embargo, no migraría un servidor únicamente porque alguien afirme que iptables está obsoleto.
Primero verificaría qué backend utiliza realmente, qué soporte ofrece la distribución y si las herramientas instaladas son compatibles con el nuevo enfoque.
En determinados sistemas, los comandos de iptables ya utilizan internamente nf_tables. Eso significa que pasar a escribir reglas nativas de nftables no siempre equivale a sustituir completamente una tecnología por otra.
Qué revisar antes de cambiar de firewall
Antes de preparar una migración, empezaría por recopilar la configuración actual.
En sistemas que utilizan iptables podemos consultar las reglas mediante:
sudo iptables-saveTambién revisaría la configuración correspondiente a IPv6:
sudo ip6tables-saveY comprobaría qué reglas existen en nftables:
sudo nft list rulesetEstas consultas ayudan a realizar un inventario, aunque hay que interpretarlas según el backend y los gestores activos.
No intentaría convertir las reglas sin más y ejecutarlas directamente sobre un servidor en producción.
Prepararía una configuración equivalente, identificaría las dependencias, revisaría qué aplicaciones modifican las reglas y realizaría pruebas en un entorno controlado.
También tendría en cuenta la persistencia de la nueva configuración tras reinicios.
Cuando el servidor utiliza cPanel, DirectAdmin, Plesk u otras herramientas de administración, comprobaría especialmente los mecanismos de seguridad compatibles con cada instalación.
Finalmente, establecería un procedimiento de reversión para recuperar la configuración anterior si surge algún problema.
No hay ninguna razón para convertir una mejora de seguridad en una incidencia de disponibilidad.
Mi recomendación es abordar estas migraciones como cualquier otro cambio importante de infraestructura: con documentación, pruebas, ventana de mantenimiento cuando corresponda y posibilidad de recuperación.
Qué firewall recomiendo para un servidor Linux
Después de comparar UFW, iptables y nftables, mi recomendación sigue siendo la misma: no elegiría un firewall únicamente por su popularidad o porque utilice la tecnología más reciente.
En mi trabajo administrando servidores Linux he comprobado que cada entorno tiene necesidades diferentes.
Un pequeño VPS que aloja una página web no necesita necesariamente las mismas políticas que un servidor de hosting con cientos de dominios y numerosos servicios funcionando simultáneamente.
Por eso, si tuviera que resumir mi elección, sería esta:
- UFW: mi primera opción para un VPS Ubuntu con pocos servicios y necesidades de filtrado sencillas.
- nftables: mi preferencia para nuevas configuraciones avanzadas que requieren mayor flexibilidad y control.
- iptables: una alternativa que mantendría en servidores existentes cuando sus reglas funcionan correctamente y las dependencias justifican conservarla.
También creo que resulta importante no confundir complejidad con seguridad.
Un firewall con decenas de reglas que nadie entiende no es necesariamente más seguro que uno con unas pocas reglas bien diseñadas.
Lo fundamental es establecer una política adecuada, permitir únicamente las conexiones necesarias y revisar periódicamente la configuración.
Tampoco debemos olvidar que ningún firewall sustituye las actualizaciones de seguridad, una configuración correcta de SSH, el control de los servicios expuestos o la monitorización del servidor.
El firewall es una capa de protección importante, pero debe formar parte de una estrategia de seguridad más amplia.
Si estás preparando un nuevo proyecto, los servidores VPS de HostingTG ofrecen un entorno donde puedes configurar las medidas de seguridad adecuadas para tus aplicaciones y necesidades de alojamiento.
Mi consejo es empezar con una configuración sencilla, documentar las reglas y aumentar su complejidad únicamente cuando el proyecto lo necesite.
Porque, al final, el mejor firewall para tu servidor Linux es el que ofrece la protección adecuada y puedes administrar con confianza cuando realmente importa.
Dudas de la Comunidad
¿Qué es mejor, UFW o iptables?
Para un servidor Linux con necesidades sencillas, normalmente recomiendo UFW porque facilita la administración de las reglas. iptables ofrece una interfaz más detallada que puede resultar útil en entornos heredados o con requisitos específicos. No obstante, UFW puede utilizar mecanismos basados en iptables, por lo que no son tecnologías completamente independientes.
¿Es nftables mejor que iptables?
nftables ofrece ventajas arquitectónicas, como conjuntos integrados, reglas conjuntas de IPv4 e IPv6 mediante tablas inet y actualizaciones transaccionales. Esto lo convierte en una alternativa atractiva para configuraciones avanzadas. Sin embargo, no significa que cualquier servidor con iptables necesite migrar inmediatamente.
¿Qué firewall utiliza Ubuntu por defecto?
Ubuntu proporciona UFW como herramienta habitual de administración simplificada del firewall, aunque su disponibilidad no significa que esté activado en todas las instalaciones. El estado inicial depende de la imagen, la versión y la configuración del servidor. Podemos comprobarlo mediante sudo ufw status.
¿Puedo utilizar UFW y nftables al mismo tiempo?
Técnicamente pueden coexistir diferentes herramientas que interactúan con Netfilter, pero no recomiendo administrarlas simultáneamente sin conocer su integración. Las reglas pueden interferir entre sí o producir resultados difíciles de diagnosticar. Es preferible definir claramente qué gestor controla cada parte del filtrado.
¿Qué firewall consume menos recursos en Linux?
No existe una respuesta universal. El consumo y rendimiento dependen de las reglas, los tipos de coincidencia, la cantidad de conexiones y el backend utilizado. Para un VPS con pocas reglas, las diferencias pueden ser poco relevantes. En configuraciones complejas, nftables ofrece estructuras que pueden facilitar un tratamiento más eficiente del filtrado.
¿Es seguro utilizar UFW en un servidor de producción?
Sí, siempre que esté correctamente configurado y sea compatible con los servicios del servidor. UFW puede ser perfectamente adecuado para entornos de producción. Lo importante es revisar las reglas, controlar el acceso administrativo, comprobar IPv4 e IPv6 y evitar conflictos con otras herramientas.
¿Debo desinstalar iptables para utilizar nftables?
No necesariamente. Algunas distribuciones utilizan herramientas compatibles con iptables sobre el backend nftables. Antes de desinstalar paquetes o modificar servicios, conviene comprobar las dependencias y cómo se administran las reglas en el sistema.
¿Qué firewall recomiendo para un servidor con Docker?
Depende del entorno y de cómo Docker esté configurado para gestionar la red. Docker puede instalar reglas de filtrado y NAT mediante distintos backends, según su versión y configuración. Antes de activar UFW o administrar directamente nftables, revisaría la documentación correspondiente y comprobaría cómo se publican los puertos de los contenedores.
¿Qué ocurre si bloqueo el puerto SSH con el firewall?
Puedes perder la posibilidad de establecer nuevas conexiones remotas. Si dispones de una sesión todavía funcional, una consola de recuperación del proveedor o un mecanismo de reversión, podrás recuperar el acceso según la situación. Por eso es fundamental probar las reglas antes de cerrar la sesión de administración.
Opinión Personal
Después de años administrando servidores Linux, tengo bastante claro que elegir entre UFW, iptables y nftables no debería convertirse en una competición por utilizar la herramienta más moderna. Lo verdaderamente importante es contar con un firewall que proteja correctamente el servidor, que podamos administrar sin complicaciones y que no termine provocando más problemas de los que pretende solucionar.
En mi caso, cuando configuro un VPS Ubuntu para alojar una página web, normalmente prefiero UFW. Es sencillo, rápido de configurar y permite controlar los puertos abiertos sin necesidad de complicarse demasiado. Si el servidor únicamente necesita SSH, HTTP y HTTPS, ¿para qué montar una configuración compleja que después será más difícil de mantener?
Ahora bien, cuando hablamos de infraestructuras más exigentes, mi opinión cambia. nftables me parece la alternativa más interesante para nuevas configuraciones avanzadas. Su flexibilidad, la posibilidad de trabajar con conjuntos de direcciones IP y su capacidad para gestionar reglas de forma más organizada son ventajas que valoro especialmente.
¿Y qué pasa con iptables? Pues sinceramente, no creo que haya que enterrarlo antes de tiempo. En HostingTG trabajamos con diferentes configuraciones de servidores Linux y sabemos que cambiar algo que funciona correctamente, sin comprobar antes sus dependencias, puede acabar generando problemas innecesarios. Si un servidor utiliza iptables, tiene unas reglas bien documentadas y todo funciona como debería, no veo motivos para migrarlo precipitadamente.
De hecho, hay algo que me preocupa bastante más que encontrar un servidor utilizando una tecnología antigua: encontrar uno donde varios sistemas de filtrado están interfiriendo entre sí y nadie sabe exactamente qué herramienta está gestionando las reglas.
Para mí, la facilidad de mantenimiento es tan importante como las capacidades técnicas del firewall. Porque cuando aparece una incidencia de seguridad, lo último que necesitas es perder tiempo intentando entender una configuración que alguien dejó funcionando hace años.
Por eso, mi recomendación sigue siendo bastante clara: UFW para quienes buscan sencillez, nftables para proyectos nuevos con necesidades avanzadas e iptables para aquellos entornos donde todavía tiene sentido mantenerlo.
Y, por supuesto, nunca olvidaría que un firewall es solo una parte de la seguridad del servidor. Mantener el sistema actualizado, proteger el acceso SSH, controlar los servicios expuestos y revisar periódicamente la configuración sigue siendo imprescindible.
¿Y tú, qué firewall prefieres?
Ahora me gustaría conocer tu experiencia. ¿Utilizas UFW, iptables o nftables en tus servidores Linux? ¿Has migrado de iptables a nftables y has notado alguna mejora? ¿O eres de los que prefieren la sencillez de UFW para evitar complicaciones?
Seguro que más de uno se ha encontrado con alguna regla que terminó bloqueando una conexión importante o con un firewall que parecía estar correctamente configurado hasta que surgió un problema.
¡Te leo en los comentarios! Cuéntame qué firewall utilizas, por qué lo elegiste y si has tenido alguna experiencia que merezca la pena compartir. Tu opinión puede ayudar a otros administradores a elegir la herramienta más adecuada para sus servidores.
