Introducción
Las reglas añadidas con el comando iptables modifican el firewall activo del kernel, pero un cambio aplicado en ejecución no constituye por sí solo una configuración permanente. Los administradores suelen serializar las reglas IPv4 con iptables-save y volver a cargarlas con iptables-restore. En sistemas Debian y Ubuntu, /etc/iptables/rules.v4 es un archivo de persistencia habitual cuando hay habilitado un cargador adecuado durante el arranque.
Considera este flujo de trabajo como tres capas independientes. El conjunto de reglas activo es lo que el kernel aplica en este momento. Un archivo de reglas guardado es solo texto almacenado en disco hasta que una herramienta o un servicio lo restaura. Una copia de seguridad de referencia es un estado inicial conocido que se conserva para poder revertir los cambios. Modificar una capa no actualiza silenciosamente las otras dos, por lo que los administradores deben guardar, restaurar y verificar de forma explícita cada transición.
En este laboratorio conservarás el firewall original como punto de reversión, añadirás y guardarás una regla específica para un servicio, validarás el archivo guardado antes de aplicarlo, simularás una recarga del conjunto de reglas y, finalmente, restaurarás la configuración original. Este flujo distingue tres estados importantes: las reglas activas, el archivo de reglas guardado y la copia de reversión.
Realizar una copia de seguridad del firewall IPv4 activo
En este paso capturarás el estado inicial del firewall antes de modificarlo. Un archivo de reversión te proporciona un estado conocido y funcional si los comandos posteriores no se comportan como esperas.
Ve al directorio del proyecto.
cd /home/labex/project
Confirma que el servicio de prueba está disponible antes de modificar las reglas.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Esta es una prueba de control. 127.0.0.1 utiliza la interfaz de bucle invertido, --noproxy '*' mantiene la solicitud en local aunque haya variables de proxy configuradas, y --fail --silent proporciona una respuesta limpia con un estado de salida fiable. Establecer una referencia funcional facilita la interpretación del comportamiento posterior del firewall.
Usa iptables-save para mostrar el conjunto completo de reglas IPv4. La tubería envía esa salida a tee, que escribe baseline.v4 y, al mismo tiempo, permite ejecutar el comando con la cuenta normal del estudiante.
sudo iptables-save | tee baseline.v4 >/dev/null
La separación de privilegios es intencionada: sudo iptables-save lee el conjunto de reglas protegido del kernel, mientras que tee, sin privilegios elevados, escribe en el directorio del proyecto. La redirección final envía a /dev/null la copia de la salida que tee mostraría en pantalla; no vacía el archivo. La copia resultante contiene todas las tablas y cadenas IPv4 serializadas que informa este equipo, no solo la regla que añadirás más adelante.
Inspecciona el principio del archivo guardado.
head -n 12 baseline.v4
Los contadores exactos pueden variar, pero el archivo utiliza un formato de iptables-restore organizado en secciones de tablas. Una sección filter mínima tiene un aspecto similar a este:
*filter
:INPUT ACCEPT ...
...
COMMIT
Cada sección comienza con el nombre de una tabla, como *filter, declara sus cadenas y políticas, enumera las reglas y termina con COMMIT. iptables-restore aplica una sección de tabla únicamente cuando alcanza ese marcador. No trates el archivo como una lista arbitraria de comandos de shell independientes.
Confirma que el archivo contiene un marcador de tabla filter y un marcador de confirmación.
grep -E '^\*filter$|^COMMIT$' baseline.v4
Añadir y guardar la regla del servicio
En este paso añadirás una regla explícita de permiso al firewall activo y guardarás el conjunto de reglas resultante en la ruta de persistencia IPv4 convencional.
Inserta al principio de INPUT una regla que acepte el tráfico TCP de bucle invertido destinado al puerto 18087. Las restricciones de interfaz y puerto mantienen la regla específica para este ejercicio.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18087 -j ACCEPT
INPUT abarca el tráfico dirigido al propio equipo. -I INPUT 1 coloca la regla en primera posición, -i lo la restringe a la interfaz de bucle invertido, -p tcp --dport 18087 selecciona el servicio de prueba y -j ACCEPT permite el tráfico que coincide. Una regla explícita y limitada resulta más fácil de auditar y eliminar que una regla general que acepte muchos servicios.
Comprueba la regla activa. Un estado de salida cero significa que existen la coincidencia y el destino exactos; la implementación basada en nftables de este equipo también muestra una forma normalizada de la regla coincidente.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Guarda el conjunto completo de reglas IPv4 activas. Se utiliza sudo tee porque /etc/iptables requiere permisos administrativos de escritura.
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null
Este comando crea una nueva instantánea después de añadir la regla. Se necesita sudo en ambos lados de la tubería por motivos distintos: el lado izquierdo lee el estado del firewall y el derecho abre un archivo de destino propiedad de root. Crear rules.v4 no activa ni programa nada por sí mismo; prepara un archivo que un comando de restauración o un servicio de arranque podrá utilizar.
Busca el puerto del servicio en el archivo guardado. El -- después de grep finaliza el análisis de opciones, algo útil cuando el patrón de búsqueda podría comenzar con un guion.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
La salida debería incluir una regla de INPUT que termine en -j ACCEPT. En este punto, tanto el conjunto de reglas activo como el archivo guardado contienen la regla prevista.
Evita comparar el archivo nuevo byte a byte con la copia de referencia. Los contadores de paquetes y las reglas gestionadas por otro software pueden cambiar legítimamente. En este ejercicio, la evidencia importante es que la regla prevista existe tanto en el estado activo como en el archivo guardado.
Validar y restaurar el conjunto de reglas guardado
En este paso eliminarás la regla activa, validarás el archivo guardado sin aplicarlo y, después, lo volverás a cargar. Así simularás la parte esencial de una restauración durante el arranque, pero dentro de una única sesión del laboratorio.
Elimina la regla de la cadena INPUT activa.
sudo iptables -D INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Esta eliminación solo modifica el conjunto de reglas actual del kernel. No edita /etc/iptables/rules.v4, por lo que la regla guardada podrá restaurarse con un comando posterior. Esta discrepancia intencionada demuestra la diferencia entre el estado activo y el estado guardado.
Confirma que la regla ya no está presente. Se espera que la comprobación falle, por lo que || muestra un mensaje y permite continuar el flujo de trabajo.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Live rule is absent"
Antes de aplicar un firewall guardado, utiliza iptables-restore --test. Este comando analiza el archivo completo e informa de cualquier error de sintaxis sin sustituir el conjunto de reglas activo.
sudo iptables-restore --test < /etc/iptables/rules.v4
El operador < hace que el shell proporcione el archivo como entrada estándar a iptables-restore. Una salida silenciosa significa que la sintaxis se aceptó; no significa que el archivo ya se haya aplicado. La validación es una medida de seguridad importante, ya que un conjunto de reglas incorrecto o incompleto puede interrumpir la conectividad al restaurarse.
Una validación correcta termina sin mostrar nada. Ahora restaura las reglas guardadas en el firewall activo.
sudo iptables-restore < /etc/iptables/rules.v4
A diferencia de añadir una sola regla con iptables, iptables-restore procesa todas las secciones de tablas presentes en el archivo. Trátalo como una operación administrativa de gran impacto: valida primero, conserva una copia de reversión y verifica inmediatamente después los accesos críticos. En este laboratorio controlado, el archivo guardado se capturó del mismo equipo unos instantes antes.
Comprueba que la regla del servicio haya vuelto.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Confirma que la aplicación siga siendo accesible después de la restauración.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Volver a la configuración original
En este paso utilizarás la copia de seguridad del paso 1 para eliminar el cambio del laboratorio del firewall activo, manteniendo al mismo tiempo el conjunto de reglas objetivo guardado para inspeccionarlo.
Valida la configuración de referencia antes de aplicarla.
sudo iptables-restore --test < baseline.v4
Aquí, baseline.v4 y /etc/iptables/rules.v4 tienen propósitos distintos de forma intencionada. La copia de referencia representa el estado activo original, mientras que rules.v4 representa el estado objetivo que contiene la regla del servicio. Restaurar un archivo no modifica el otro.
Restaura el conjunto de reglas activo original.
sudo iptables-restore < baseline.v4
Confirma que la regla del laboratorio ya no esté activa.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Original firewall baseline restored"
El archivo objetivo guardado es un artefacto independiente y todavía contiene la regla cuya restauración practicaste.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Esta comprobación demuestra claramente la separación de estados: el firewall activo se ha revertido, pero el archivo de persistencia aún registra la regla objetivo. Un administrador podría restaurarla de nuevo más adelante o configurar un servicio de persistencia para cargarla durante el arranque.
Por último, verifica que volver a la configuración de referencia permisiva original mantenga accesible el servicio local.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
En producción, confirma qué servicio carga durante el arranque el archivo de persistencia de la distribución. Por ejemplo, los sistemas basados en Debian suelen utilizar un paquete como iptables-persistent junto con netfilter-persistent, aunque la disponibilidad y las políticas pueden variar según el equipo. Guardar un archivo rules.v4 correcto prepara el conjunto de reglas; que se restaure automáticamente depende de que haya un cargador instalado y habilitado.
Resumen
Realizaste una copia de seguridad del firewall IPv4 activo, añadiste y guardaste una regla específica para un servicio, validaste el conjunto de reglas serializado con iptables-restore --test, lo recargaste en el kernel y volviste a la configuración de referencia original. También distinguiste el firewall activo de sus archivos de persistencia y de reversión, un hábito esencial antes de modificar o restaurar el estado del filtrado de paquetes.
