Configuración del cortafuegos local

Objetivo:

Comprender y configurar la seguridad perimetral a nivel de host en Linux mediante la gestión de UFW (Uncomplicated Firewall) como interfaz simplificada y el control avanzado de reglas de filtrado de paquetes con iptables, estableciendo políticas restrictivas por defecto y aperturas controladas de servicios.

Escenario:

  • Herramientas: Terminal Linux, comandos ufw, iptables, iptables-save, y utilidades de auditoría de puertos (ss, nmap).
  • Conceptos analizados: Filtrado de paquetes con Stateful Inspection, tablas y cadenas de iptables (INPUT, OUTPUT, FORWARD), políticas por defecto (DROP/ACCEPT), y apertura de puertos por protocolo y IP de origen.
  • Proceso clave: Endurecimiento (hardening) de un servidor aplicando una política restrictiva de denegación general, apertura controlada de servicios web y SSH, y análisis de reglas persistentes.

Escenario Real: Blindaje de un servidor expuesto a Internet

Un nuevo servidor web corporativo ha sido desplegado en la nube pública y se encuentra totalmente vulnerable ante escaneos de puertos y ataques de fuerza bruta al dejar todos sus servicios expuestos sin restricciones. Como administrador de sistemas, debes configurar un cortafuegos local perimetral que bloquee todo el tráfico entrante por defecto, permitiendo exclusivamente el acceso administrativo por SSH desde una IP segura y las peticiones web públicas hacia los puertos HTTP y HTTPS.

Por defecto, la mayoría de distribuciones de Linux vienen con los puertos de red abiertos y sin restricciones activas de filtrado. Configurar un cortafuegos local robusto es la primera línea de defensa obligatoria para mitigar accesos no autorizados antes de exponer cualquier servidor a redes públicas.

NOTA: Para realizar esta práctica de configuración de cortafuegos de forma remota (por ejemplo, mediante SSH), ten la precaución de abrir siempre el puerto de administración antes de activar el servicio para evitar bloquearte a ti mismo.

Instrucciones:

Fase 1: Instalación, estado inicial y políticas por defecto en UFW:

  • Instalar el gestor simplificado de cortafuegos UFW si no viene preinstalado: sudo apt update && sudo apt install -y ufw
  • Comprobar el estado actual del cortafuegos y sus reglas activas: sudo ufw status verbose
  • Establecer la política de seguridad estricta por defecto (denegar todo el tráfico entrante y permitir todo el tráfico saliente): 
    sudo ufw default deny incoming
sudo ufw default allow outgoing

Fase 2: Apertura controlada de servicios esenciales (SSH y Web):

  • Permitir de forma explícita el acceso remoto por SSH para no perder la conexión de administración: sudo ufw allow ssh (o especificando el puerto exacto: sudo ufw allow 22/tcp).
  • Permitir el tráfico web estándar para servidores HTTP y HTTPS: sudo ufw allow 80/tcp y sudo ufw allow 443/tcp.
  • Permitir el acceso al puerto SSH de manera restringida, limitándolo únicamente a una dirección IP de confianza de la oficina (por ejemplo, 192.168.1.100): sudo ufw allow from 192.168.1.100 to any port 22 proto tcp

Fase 3: Activación del cortafuegos y auditoría de reglas:

  • Activar el servicio de cortafuegos UFW aplicando las reglas configuradas: sudo ufw enable (confirmando la advertencia sobre posibles interrupciones de conexiones SSH si no se configuraron bien).
  • Listar las reglas activas numeradas para facilitar su gestión o borrado posterior: sudo ufw status numbered
  • Simular la eliminación de una regla errónea utilizando su número identificador: sudo ufw delete [número_de_regla]

Fase 4: Inspección de bajo nivel del filtrado de paquetes con iptables:

  • Dado que UFW es una interfaz simplificada que gestiona las reglas del kernel por debajo, inspeccionar las tablas de filtrado de paquetes de bajo nivel ejecutando: sudo iptables -L -v -n
  • Observar las cadenas principales del kernel (INPUT, FORWARD, OUTPUT) y comprobar cómo se traducen las políticas de UFW en reglas de iptables.
  • Comprobar el estado de las reglas activas de red orientadas a protocolos IPv6 mediante: sudo ip6tables -L -v -n

Verificación:

  • Comprobar mediante el comando sudo ufw status que el cortafuegos se encuentra activo (Status: active) y muestra las reglas correctas de SSH y Web.
  • Verificar desde un equipo externo de la red local mediante un escaneo rápido de puertos con nmap [IP_del_servidor] que los puertos no autorizados aparecen cerrados o filtrados.

Posibles errores y resolución de problemas:

Si tras activar el cortafuegos con el comando sudo ufw enable pierdes de forma repentina la conexión SSH y te quedas bloqueado fuera del servidor, se debe a que no se abrió previamente el puerto 22.

  • Solución: Si tienes acceso físico a la consola del servidor o mediante el panel de control del proveedor de virtualización (como una consola VNC o de hipervisor), inicia sesión localmente y ejecuta de inmediato la orden sudo ufw allow 22/tcp para restablecer el acceso.

Alternativa directa: Volcado de reglas con iptables-save

Si necesitas realizar una copia de seguridad rápida de todas las reglas de filtrado de bajo nivel aplicadas en las tablas del kernel para exportarlas o restaurarlas posteriormente en caso de emergencia, puedes volcar la configuración actual en un fichero de texto plano:

sudo iptables-save > ~/respaldo_iptables.rules

Preguntas de reflexión:

  1. ¿Qué ventaja operativa principal aporta el uso de una herramienta de alto nivel como ufw frente a la escritura directa y compleja de reglas con iptables?
  2. ¿Por qué se recomienda encarecidamente establecer una política por defecto de denegación en la cadena de entrada (default deny incoming) al asegurar un servidor en producción?
  3. ¿Qué diferencia técnica fundamental existe entre el filtrado de paquetes clásico sin estado frente al filtrado con inspección de estados (Stateful Inspection) utilizado por los cortafuegos modernos en Linux?
  4. ¿Por qué es necesario configurar y revisar de manera independiente las reglas de filtrado IPv4 (iptables) frente a las reglas IPv6 (ip6tables) en los sistemas actuales?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué ventaja operativa principal aporta el uso de una herramienta de alto nivel como ufw frente a la escritura directa y compleja de reglas con iptables?

Ufw simplifica drásticamente la sintaxis y la gestión de la seguridad perimetral mediante comandos intuitivos y directos (permitiendo abrir servicios por su nombre habitual como ssh o http), evitando la complejidad de tener que especificar manualmente las tablas, cadenas, interfaces de red y parámetros avanzados que exige la sintaxis nativa de iptables.

2. ¿Por qué se recomienda encarecidamente establecer una política por defecto de denegación en la cadena de entrada (default deny incoming) al asegurar un servidor en producción?

Porque sigue el principio de seguridad de "privilegio mínimo" o denegación por defecto. Al bloquear todo el tráfico entrante de manera global, te aseguras de que ningún puerto o servicio recién instalado quede expuesto por descuido a Internet, obligándote a abrir de forma consciente y explícita únicamente aquellos puertos que el servidor necesite ofrecer.

3. ¿Qué diferencia técnica fundamental existe entre el filtrado de paquetes clásico sin estado frente al filtrado con inspección de estados (Stateful Inspection) utilizado por los cortafuegos modernos en Linux?

El filtrado sin estado analiza cada paquete de forma aislada sin tener en contexto el flujo de la comunicación. En contraste, los cortafuegos con inspección de estados (como Netfilter/iptables) recuerdan y rastrean el contexto de las conexiones establecidas (ESTABLISHED, RELATED), permitiendo que el tráfico de respuesta a una petición legítima originada desde el interior del servidor atraviese el cortafuegos de forma automática sin necesidad de abrir reglas de entrada adicionales.

4. ¿Por qué es necesario configurar y revisar de manera independiente las reglas de filtrado IPv4 (iptables) frente a las reglas IPv6 (ip6tables) en los sistemas actuales?

Porque IPv4 e IPv6 utilizan estructuras de direccionamiento, protocolos y pilas de red completamente separadas a nivel de núcleo en el sistema operativo. Un paquete que llega encapsulado en IPv6 no es evaluado por las reglas configuradas en las tablas IPv4, por lo que desatender el filtrado IPv6 dejaría al servidor completamente desprotegido ante ataques dirigidos a través de este protocolo.