Ir al contenido 
Cortafuegos iptables y UFW controlan qué conexiones acepta un servidor web y cuáles bloqueo - esto determina la superficie de ataque y los fallos. En este artículo práctico, muestro reglas claras, valores predeterminados seguros y comandos probados para SSH, HTTP(S), bases de datos, registro, IPv6 y Docker - directamente aplicables en hosts productivos.
Puntos centrales
Los siguientes puntos clave me dan una orientación rápida antes de empezar con la configuración.
- Restrictivo Inicio: Denegación por defecto para entrantes, abierto específicamente
- SSH Permitir primero: no arriesgar el acceso
- UFW como interfaz: sintaxis sencilla, iptables en segundo plano
- Registro activar: Comprobar reglas, reconocer ataques
- Persistencia garantizar: Mantener las normas sobre reinicios
Conceptos básicos: iptables y UFW de un vistazo
Confío en iptablescuando necesito un control detallado sobre paquetes, cadenas y coincidencias. Uso UFW cuando quiero aplicar rápidamente reglas fiables que acaban internamente como reglas iptables [1]. Esto me permite combinar comandos simples con la potencia del netfilter de Linux sin perderme en los detalles. Para servidores web, esto significa: construyo un filtro claro delante de Apache, Nginx o Node para que sólo llegue el tráfico deseado [2]. Esta separación reduce las superficies de ataque y permite que los ataques fallen más a menudo.
Ambas herramientas se complementan y yo decido cuál se adapta mejor a la situación. UFW destaca por su legibilidad, especialmente en Ubuntu y Debian [3]. iptables me ofrece opciones ampliadas, por ejemplo para NAT, interfaces específicas y coincidencias complejas. Importante: Yo documento mis reglas de forma concisa para que el mantenimiento sea fácil más adelante. Si quieres saber más sobre el concepto de seguridad, puedes encontrar una introducción clara aquí: El cortafuegos como escudo protector.
Iniciar la configuración: establecer políticas por defecto de forma segura
Empiezo con Por defecto-Políticas: Bloquear entrantes, permitir salientes. Así evito que nuevos servicios sean accesibles involuntariamente. Siempre permito loopback para que los procesos internos funcionen de forma estable. Acepto las conexiones existentes para evitar cancelaciones. Esta secuencia minimiza los errores al activar el cortafuegos [2][5].
Utilizo UFW para establecer la base con unos pocos comandos. Después compruebo el estado en detalle para darme cuenta inmediatamente de los errores de escritura. Para los hosts especialmente sensibles, también restrinjo los puertos de salida. Esto reduce el riesgo de fugas de datos si un servicio se ha visto comprometido. Utilizo los siguientes comandos con frecuencia:
# UFW: Reglas por defecto
sudo ufw por defecto denegar entrantes
sudo ufw por defecto permitir salientes
# Política de salida alternativa más estricta
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 80
sudo ufw allow out 443
# Comprobar estado
sudo ufw status verbose
Filtrado por estados: estados y secuencia
Una parcela limpia fluye con Conntrack declara. Acepto primero las conexiones establecidas, descarto antes los paquetes no válidos y dejo abierto el loopback. Esto reduce la carga y evita efectos secundarios debidos a caídas tardías. Para iptables, establezco deliberadamente el orden:
# iptables: base sólida
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Permitir siempre loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Permitir conexiones existentes/asociadas
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Descartar paquetes no válidos antes de tiempo
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Con UFW, ESTABLISHED/RELATED ya se tienen en cuenta internamente. También presto atención a si prefiero DROP (silencio) o RECHAZAR (activo, conmutación por error más rápida). Para redes internas prefiero REJECT, en la red pública normalmente DROP.
Reglas esenciales para servidores web: SSH, HTTP y HTTPS
Cambio SSH primero, de lo contrario me bloqueo fácilmente. Luego permito HTTP y HTTPS para que el servidor web sea accesible. Sólo configuro los puertos que realmente necesito. Más tarde, opcionalmente, añado limitación de velocidad o Fail2ban para frenar los intentos brutales de inicio de sesión. Compruebo cada cambio inmediatamente con los comandos status o list.
Mantengo los comandos para esto simples. UFW ofrece alias parlantes para los puertos web, lo que aumenta la legibilidad. Con iptables, puedo establecer puertos y protocolos precisos. Después guardo las reglas iptables para que sobrevivan al reinicio. Estos son los pasos mínimos:
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
SSH seguro: Restringir y abrir selectivamente
Además de la liberación, amortiguo los ataques con Limitación de velocidad o listas blancas. UFW proporciona una protección sencilla:
# Limitación de velocidad SSH (UFW)
sudo ufw limit 22/tcp comment "Límite de velocidad SSH"
Establezco límites más finos con iptables. Esto evita la adivinación masiva de contraseñas sin excluir a los administradores legítimos:
# SSH: Limitar los intentos de conexión por fuente
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP
En la medida de lo posible, sólo permito SSH desde Direcciones IP de administración y trabajar con claves SSH. Cambiar los puertos no sustituye a la seguridad, pero puede reducir el ruido. Yo documento las excepciones y las compruebo regularmente.
Proteger las bases de datos y restringir las fuentes de IP
Nunca abro los puertos de la base de datos globalmente, sino sólo local o para direcciones IP de origen definidas. Esto evita que los escáneres encuentren puertos abiertos de MySQL, PostgreSQL o MongoDB. Para aplicaciones locales, 127.0.0.1 es suficiente como objetivo; controlo el acceso de administradores externos estrictamente vía IP. Documento los cambios brevemente, por ejemplo en la wiki del servidor. Esto me ahorra tiempo durante las auditorías.
Suelo utilizar los siguientes ejemplos en los proyectos. Compruebo de antemano la corrección de cada IP permitida. UFW permite una notación limpia "de-a", iptables implementa la misma lógica técnicamente. Uso reglas adicionales de permiso para ventanas temporales de mantenimiento y las borro después. Esto mantiene la interfaz pequeña:
# Sólo local: MySQL
sudo ufw permitir desde 127.0.0.1 a cualquier puerto 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Permitir IP única
sudo ufw allow desde 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Permitir puerto para IP específica
sudo ufw allow desde 10.1.2.3 a cualquier puerto 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Bloquear atacantes conocidos
sudo ufw deny desde 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Gestión limpia de registros, interfaces e IPv6
Cambio Registro para verificar reglas y reconocer tráfico llamativo. El nivel "on" en UFW es suficiente para la mayoría de los hosts, sólo utilizo niveles más altos de forma selectiva. Analizo los registros con journalctl, fail2ban o herramientas SIEM. Esto me permite reconocer patrones de escaneos o intentos de fuerza bruta. En caso de anomalías, ajusto las reglas rápidamente [2].
Suelo vincular las normas a un Interfazcomo eth0 en redes públicas. Esto evita que las redes internas se vean afectadas innecesariamente. UFW puede "permitir la entrada en eth0 a cualquier puerto 80", iptables usa -i para interfaces de entrada. Para IPv6, compruebo la activación en /etc/default/ufw para "IPV6=yes" y uso ip6tables para reglas nativas [2]. Esta separación evita lagunas con hosts dual-stack.
ICMP e ICMPv6: accesibilidad sin lagunas
Dejo necesario ICMP-tipos para que funcionen el descubrimiento de MTU de ruta, los tiempos de espera y los diagnósticos. ICMP no es un enemigo, sino el núcleo del protocolo IP. Sólo limita los ecos excesivos.
# IPv4: Limitar eco, permitir tipos ICMP importantes
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/segundo --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: Permitir ICMP en general (posibilidad de ajuste fino en before.rules)
sudo ufw allow en proto icmp
En IPv6 ICMPv6 es absolutamente necesario (Neighbour Discovery, Router Advertisement). Permito los tipos de núcleo y limito las solicitudes de eco:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Uso correcto de la restricción de salida y NAT/masquerading
Limito el tráfico saliente cuando Perfil de riesgo y el cumplimiento. Permito DNS y HTTPS y bloqueo todo lo demás excepto los objetivos definidos. Esto reduce la filtración de datos si se secuestra un servicio. Creo excepciones definidas para aplicaciones que requieren actualizaciones o API. Documento estas excepciones con claridad y las compruebo con regularidad.
Para las configuraciones de enrutamiento, utilizo NAT/Masquerading mediante UFW-Before-Rules o raw con iptables. Presto atención al orden de las cadenas para que los paquetes se reescriban correctamente. Tras los cambios, pruebo la conectividad y las latencias. Para los sistemas de producción, planifico una ventana de mantenimiento y hago una copia de seguridad de la configuración. Esto me permite mantener la trazabilidad de las rutas de red [7].
Detalles de salida: servicios y protocolos del sistema
Con una estricta política de salida, permito específicamente DNS (53/udp), HTTPS (443/tcp) y si es necesario NTP (Para los servidores de correo, añado 25/tcp y 587/tcp. No resuelvo las excepciones basadas en dominio a nivel de paquete, sino a través de proxies o lógica de aplicación.
# UFW: servicios típicos del sistema
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - sólo si servidor de correo
sudo ufw allow out 587/tcp # Envío - sólo si es necesario
# iptables: específico Permitir
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker y cortafuegos: evitar escollos
Docker establece su propio iptables-reglas que pueden influir en mi política. Por lo tanto, compruebo las cadenas NAT y FORWARD después de cada composición o inicio de demonio. Libero deliberadamente los puertos expuestos y evito "-p 0.0.0.0:PORT". En su lugar, los enlazo a la IP de gestión o al proxy inverso. Esto mantiene el vector de ataque más pequeño y más visible [1].
Mantengo los cortafuegos del host activos a pesar de Docker. También controlo los grupos de seguridad a nivel de infraestructura, si están disponibles. En caso de conflictos entre UFW y Docker, utilizo soluciones documentadas o establezco reglas en DOCKER-USER. Es importante tener claras las responsabilidades: el host siempre bloquea, los contenedores sólo se abren explícitamente. Este orden evita liberaciones inconscientes.
# DOCKER-USER: aplicar la política global de host antes que las reglas de Docker
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Ajustes finos de UFW: Secuencia, perfiles y tráfico enrutado
Cuando la precisión cuenta, utilizo "insertar", "numerado" y perfiles de aplicación. Así mantengo limpia la secuencia de reglas y utilizo definiciones de servicio probadas.
# Secuencia de control
sudo ufw insert 1 deny in from 198.51.100.0/24
# Vista numerada y borrado dirigido
sudo ufw estado numerado
sudo ufw delete 3
# Perfiles de aplicación (por ejemplo, Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full" (Nginx Completo)
sudo ufw allow "Nginx Completo"
# Bloquear el tráfico enrutado por defecto (reenvío)
sudo ufw default deny routed
Las excepciones más complejas las almaceno en antes.reglas respectivamente después.de.las.reglas. Allí puedo colocar el ajuste fino ICMP o NAT precisamente sin perder la legibilidad de las reglas estándar.
Reglas persistentes: Guardar y restaurar
Con las normas UFW son persistente y sobreviven automáticamente a los reinicios. Esto simplifica enormemente la administración en hosts Debian/Ubuntu. Con iptables, guardo las reglas después de los cambios y las restauro al arrancar. Para ello uso iptables-save/restore o netfilter-persistent. Sin estos pasos, pierdo los cambios tras un reinicio [5].
Pruebo la persistencia sistemáticamente: programo un reinicio y compruebo el estado. Si los contadores y las cadenas son correctos, la configuración es sólida. Si faltan reglas, corrijo la ruta de carga en el contexto init o systemd. Esta rutina evita sorpresas durante el mantenimiento. La documentación y la copia de seguridad de los archivos de reglas completan el procedimiento.
# Debian/Ubuntu: Persistencia para iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save
# Copia de seguridad manual
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
# Restaurar (si es necesario)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Rendimiento y protección: límites, conjuntos y ajuste del núcleo
Cuando la carga es alta, reduzco el número de controles y utilizo controles específicos. Límites de tarifa. Para las listas de bloques grandes, trabajo con ipset para reducir los tiempos de búsqueda. También utilizo mecanismos de protección basados en el sistema:
# Contain SYN flood (kernel)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Limitar la tasa de conexiones HTTP por IP de origen (ejemplo)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Mantengo el tamaño del Mesa Conntrack de un vistazo. Si hay muchas conexiones simultáneas, aumento nf_conntrack_max, pero pruebo antes los efectos.
Gestión, pruebas y prevención de errores
Dejo SSH antes de activar "denegar entrantes". Luego pruebo desde una segunda sesión si el acceso se mantiene estable. Compruebo cada nueva regla con "ufw status verbose" o "iptables -L -v". Esto me permite reconocer los contadores de visitas y ver si los paquetes están aterrizando en la cadena esperada. Hago una copia de seguridad de los archivos del cortafuegos antes de realizar cambios importantes.
Para una seguridad completa, combino el cortafuegos con medidas de refuerzo del sistema. Entre ellas, configuración segura de SSH, gestión de parches y servicios mínimos. Me gusta utilizar una guía práctica como lista de comprobación: Fortalecimiento de servidores Linux. Repito estas comprobaciones con regularidad y cumplo las ventanas de mantenimiento fijadas. Así mantengo mis servidores en forma.
Pruebas avanzadas y observación
Compruebo el impacto externo con Exploración de puertos desde una red externa y verificar los sockets abiertos internamente. Superviso los registros de cerca al principio para reconocer conclusiones falsas desde el principio.
# Tomas abiertas
ss -lntup
# visión general de iptables compact
sudo iptables -S
sudo iptables -L -v -n
# UFW: estado detallado y logs
sudo ufw status verbose
journalctl -k | grep -i ufw
# Comprobación externa (desde otro host/red)
nmap -Pn -p 22,80,443
Para los cambios de alto riesgo, estoy planeando un Nivel de repliegue en. Trabajo en Screen/Tmux y, si es necesario, establezco un reinicio controlado por tiempo si me bloqueo. Tras una prueba satisfactoria, vuelvo a cancelar la acción de reposición.
# Ejemplo: desactivación automática como ancla de emergencia (usar con cuidado)
echo "ufw disable" | en ahora + 2 minutos
# Borrar de nuevo después de la prueba con éxito: atrm
Comparación de proveedores de alojamiento: Integración de cortafuegos
Para el alojamiento confío en Seguridad cerca de la plataforma. Las políticas personalizadas, el rápido despliegue de reglas y la buena supervisión merecen la pena. En las comparaciones actuales, webhoster.de impresiona con opciones de cortafuegos bien integradas y un soporte rápido. Los que prefieren las configuraciones de panel se benefician de instrucciones claras para Cortafuegos de Plesk. El siguiente cuadro clasifica los criterios clave.
| Proveedor | Integración de cortafuegos | Actuación | Apoyo | Colocación |
|---|---|---|---|---|
| webhoster.de | configurar individualmente. | Muy alta | top | 1 |
| Proveedor B | Estándar | alta | bien | 2 |
| Proveedor C | Estándar | bien | Satisfactorio | 3 |
Ejemplos prácticos: De la prueba a la norma de producción
Comienzo cada conjunto de reglas en Pantalla o en una segunda sesión SSH. De este modo, aún puedo salvarme en caso de error de funcionamiento. Sólo cuando un host de prueba funciona correctamente aplico reglas en producción. Las reglas de ruta de retorno y un plan de reversión me aportan seguridad adicional. Al final, documento los cambios de forma concisa en el registro de cambios.
Utilizo bloques de construcción recurrentes para los servidores web: permitir SSH, liberar HTTP/S, enlazar puertos internos localmente, iniciar sesión, limitar ICMP, bloquear protocolos superfluos. Luego me ocupo de las reglas de duplicación IPv6 para que no queden lagunas. Siempre compruebo las cadenas Docker por separado porque establecen sus propias rutas. Por último, valido el acceso mediante comprobaciones y supervisión externas. Esto mantiene la interfaz limpia y rastreable [1][2].
Resumen para administradores
Con claridad Reglas y unos pocos comandos, aseguro servidores web de forma fiable. Incoming default deny, SSH first, release HTTP/S - esto forma la base estable. Puertos de base de datos sólo localmente o a través de lista blanca, registro activo, observar IPv6, comprobar docker chains. El almacenamiento persistente y las pruebas regulares evitan sorpresas desagradables. Esta rutina mantiene los servicios accesibles y reduce significativamente los riesgos.
Tanto si utilizo UFW como iptables directamente, una política clara y económica es crucial. La documento brevemente, la verifico con regularidad y reduzco al mínimo las excepciones. La restricción de las salidas detiene las conexiones innecesarias y limita los daños en caso de compromiso. Con un ojo puesto en los registros, reconozco más rápidamente las anomalías y reacciono adecuadamente. Así mantengo la resistencia del servidor web y reduzco la superficie de ataque.
