Introducción
En los laboratorios anteriores, abrió y cerró «puertas» (puertos) para todos. Pero ¿qué ocurre si quiere abrir la puerta solo para un amigo o cerrarla específicamente para alguien que sabe que causa problemas?
Aquí entran en juego las reglas enriquecidas. En lugar de limitarse a abrir o cerrar un servicio de forma general, las reglas enriquecidas permiten expresar políticas más detalladas, como hacer coincidir direcciones de origen, registrar eventos o rechazar tráfico específico.
Son importantes porque las políticas de firewall reales suelen depender de condiciones. Las decisiones de seguridad rara vez se reducen únicamente a «puerto abierto» o «puerto cerrado».
Nota sobre el entorno del laboratorio: Para evitar que se bloquee accidentalmente el acceso a la terminal web, usaremos la zona trusted de forma predeterminada. Esto significa que se permite todo el tráfico, a menos que lo bloqueemos explícitamente. En un entorno de producción real, usaría una zona más restrictiva, como public o drop.
En este laboratorio, aprenderá a:
- Bloquear personas específicas: Rechazar conexiones desde una dirección IP concreta.
- Conservar registros: Registrar los intentos para saber quién trató de entrar.
- Restringir el acceso: Configurar una regla que permita el control remoto (SSH) únicamente desde una red específica.
- Auditar: Guardar las reglas en un archivo para revisarlas.
Bloquear una IP específica
Primero, aprenderá a bloquear a alguien que esté causando problemas. Suponga que observa que el equipo con la dirección 192.168.1.100 intenta atacarle. Quiere bloquearlo por completo.
Para hacerlo, usará una «regla enriquecida». Aunque la zona predeterminada es trusted (permite todo), una regla específica de Reject tendrá prioridad para esta IP.
Las reglas enriquecidas son importantes porque las políticas de firewall reales suelen depender de condiciones. Es posible que necesite comportamientos distintos según la dirección de origen, el servicio, las necesidades de registro u otros criterios que los comandos simples para abrir o cerrar servicios no pueden expresar adecuadamente.
La sintaxis se parece a la construcción de una oración: rule family="ipv4" source address="192.168.1.100" reject
Ejecute el siguiente comando para añadir esta regla de forma permanente.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" reject'
Analicemos esta «oración»:
rule family="ipv4": Se refiere a direcciones IP estándar.source address="...": Es la dirección del equipo que causa problemas.reject: Es la acción que se ejecutará.
Reject frente a Drop:
- Reject es cortés: informa al remitente «Aléjese, no tiene permiso».
- Drop es brusco: ignora por completo al remitente, como si el equipo no existiera.
La elección entre ambas opciones no es solo una cuestión de estilo. reject proporciona una respuesta más rápida a los clientes legítimos y facilita la resolución de problemas, mientras que drop puede revelar menos información a un atacante, aunque puede provocar tiempos de espera más largos.
Como usamos --permanent, la regla se ha guardado, pero todavía no está activa. Recargue el firewall para aplicarla.
sudo firewall-cmd --reload
Ahora, compruebe que la regla existe.
sudo firewall-cmd --list-rich-rules
Debería ver la nueva regla en la lista.
Registrar paquetes descartados
Bloquear a alguien es útil, pero a veces también necesita pruebas. Puede añadir «registro» a una regla, como si instalara una cámara de seguridad que graba cada vez que se activa la regla.
Esta combinación de filtrado y registro es habitual en las operaciones de seguridad. El bloqueo del tráfico protege el sistema, mientras que los registros generan evidencias que puede investigar más adelante.
Bloquearemos otra IP, 10.0.0.5, pero esta vez registraremos el intento antes de rechazarlo.
Ejecute este comando:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.5" log prefix="BLOCKED_IP: " level="info" reject'
¿Qué hay de nuevo aquí?
log: Activa la cámara.prefix="BLOCKED_IP: ": Al escribir en los registros del sistema, inicia la línea con este texto. Esto facilita mucho la búsqueda posterior de estos eventos mediante herramientas de búsqueda.
Aplique los cambios.
sudo firewall-cmd --reload
Compruebe el resultado.
sudo firewall-cmd --list-rich-rules
Ahora debería ver dos reglas: la primera (rechazo simple) y la segunda (registro y rechazo).
Restringir el acceso a un servicio
En un entorno reforzado, bloquearía SSH desde cualquier ubicación y solo permitiría el acceso desde una red de confianza, como su VPN.
Nota educativa: Como usamos la zona trusted para mantener activa la conexión, este paso es parcialmente simbólico. Añadir una regla de «Allow» cuando todo ya está permitido no cambia el comportamiento. Sin embargo, aprender esta sintaxis es fundamental para trabajar con zonas restrictivas como public o drop.
El objetivo es crear una regla que indique: «Permitir SSH si el origen es 192.168.0.0/24».
Este es un buen ejemplo del principio de mínimo privilegio aplicado a las políticas de red. En lugar de exponer el acceso administrativo a todo el mundo, lo limitará a la red que debe administrar legítimamente el servidor.
Primero, elimine el servicio SSH general.
sudo firewall-cmd --permanent --remove-service=ssh
Nota: Es posible que vea una advertencia como Warning: NOT_ENABLED: ssh. Esto es normal y esperado. Como la zona predeterminada es trusted (permite todo de forma predeterminada, pero no tiene servicios específicos habilitados), intentar eliminar un servicio que no aparece explícitamente genera esta advertencia inofensiva.
A continuación, añada la regla enriquecida específica para la subred.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.0.0/24" service name="ssh" accept'
Recargue el firewall para activar estos cambios.
sudo firewall-cmd --reload
Ahora, verifique la configuración. Primero, compruebe la lista de servicios.
sudo firewall-cmd --list-services
Aquí ya no debería aparecer ssh (se eliminó de la lista general de servicios).
Después, compruebe las reglas enriquecidas.
sudo firewall-cmd --list-rich-rules
Debería ver una regla que acepta service name="ssh" desde el origen especificado.
Auditar las reglas
En un entorno de producción, se recomienda auditar las reglas del firewall y crear una copia de seguridad antes de cerrar la sesión. Así se asegura de que las reglas se aplican en el orden correcto y de que dispone de un archivo de recuperación.
En este paso, exportará las reglas enriquecidas a un archivo de texto para auditarlas.
Primero, liste todas las reglas enriquecidas y redirija la salida a un archivo llamado rules_list.txt en la carpeta de su proyecto.
sudo firewall-cmd --list-rich-rules > ~/project/rules_list.txt
Ahora, lea el archivo para confirmar que el contenido es correcto.
cat ~/project/rules_list.txt
Debería ver la lista de reglas que creó en este laboratorio. Este archivo sirve ahora como una copia de seguridad sencilla de la configuración de sus reglas enriquecidas.
Resumen
En este laboratorio, mejoró sus conocimientos sobre firewalls mediante las reglas enriquecidas. Aprendió a:
- Bloquear IP específicas (la regla «Reject»).
- Registrar eventos de seguridad (la regla de la «cámara»).
- Restringir servicios sensibles, como SSH, únicamente a redes de confianza.
- Auditar la configuración exportando las reglas a un archivo.
Estas técnicas avanzadas le proporcionan la precisión necesaria para proteger entornos complejos.
