Introducción
Una regla de firewall solo es útil si produce el límite de acceso previsto conservando el servicio requerido. Añadir únicamente una regla de permiso bajo una política predeterminada ACCEPT no demuestra que se haya restringido a nadie.
Esta práctica proporciona un servicio Kali dedicado y dos clientes de práctica. Inspeccionarás su acceso inicial, aplicarás reglas ordenadas basadas en el origen en Kali, guardarás y restaurarás la política del ejercicio y probarás ambas rutas de cliente.
Observa la red de entrenamiento antes de restringir el acceso
En este paso probarás las vistas de dos clientes proporcionados e inspeccionarás el firewall que protege su servicio de entrenamiento.
Esta práctica proporciona una pequeña red dedicada dentro de la VM. El servicio Kali de entrenamiento está en 172.30.77.10:8080; el cliente permitido utiliza 172.30.77.20 y el cliente que se debe bloquear utiliza 172.30.77.30. Ambos tienen acceso inicialmente. Son direcciones de la red de práctica, no objetivos públicos.
Empieza en la Terminal inicial del host Ubuntu. El comando preparado training-client realiza una solicitud desde un cliente de práctica determinado. Se ejecuta en el host, mientras que la administración del firewall tendrá lugar dentro de Kali. Elige el espacio de trabajo compartido:
cd /home/labex/project
Guarda el estado HTTP inicial del cliente permitido:
training-client allowed > allowed-before.txt
cat allowed-before.txt
La línea de estado debe contener 200 OK. Registra el acceso inicial del otro cliente:
training-client blocked > blocked-before.txt
cat blocked-before.txt
También debe indicar 200 OK; la etiqueta nombra al cliente que bloquearás, no su estado inicial.
Ahora entra en Kali para inspeccionar su firewall:
kali
Iptables evalúa reglas de filtrado de paquetes en cadenas. INPUT gestiona paquetes destinados a este entorno, OUTPUT gestiona paquetes generados localmente y FORWARD gestiona paquetes enrutados. -L INPUT enumera la cadena de entrada; -n mantiene direcciones y puertos numéricos, mientras que -v incluye contadores:
sudo iptables -L INPUT -n -v
La cadena de práctica tiene inicialmente política ACCEPT. Una política de cadena se aplica cuando ninguna regla ha decidido ya el destino del paquete. En esta práctica añadirás reglas específicas para el servicio dedicado, dejando intactas las políticas predeterminadas y el firewall del host.
Aplica y guarda una política ordenada para el servicio
En este paso permitirás al cliente asignado antes de rechazar otras fuentes de la red de práctica para el mismo servicio.
Permanece en Kali. -A INPUT añade una regla al final de la cadena de entrada, -p tcp coincide con TCP, -s coincide con una dirección de origen, --dport selecciona el puerto de destino y -j elige la acción. Añade primero la regla de permiso específica:
sudo iptables -A INPUT -p tcp -s 172.30.77.20 --dport 8080 -j ACCEPT
A continuación rechaza otros orígenes de la subred dedicada de práctica para ese mismo puerto. El prefijo /24 identifica el rango de red 172.30.77.0:
sudo iptables -A INPUT -p tcp -s 172.30.77.0/24 --dport 8080 -j REJECT
Las reglas se evalúan en orden. El origen permitido coincide con la primera regla terminal ACCEPT; el otro cliente de práctica llega a la regla REJECT posterior. Invertir estas reglas rechazaría también al cliente permitido. Otros puertos y orígenes siguen la política predeterminada intacta.
Muestra el orden de reglas y los contadores. --line-numbers incluye la posición de cada regla:
sudo iptables -L INPUT -n -v --line-numbers
La primera regla debe permitir al cliente asignado en TCP 8080 y la regla posterior debe rechazar el tráfico restante de la subred de práctica para ese servicio.
iptables-save muestra las reglas activas en un formato que puede restaurarse. Guarda la configuración de este ejercicio en el espacio de trabajo compartido:
sudo iptables-save > /home/labex/project/training.rules
El operador < del shell proporciona un archivo como entrada estándar de un comando. iptables-restore lee esa configuración guardada; aquí restauras exactamente las reglas del ejercicio que acabas de guardar:
sudo iptables-restore < /home/labex/project/training.rules
Esto opera únicamente en el entorno de red Kali dedicado. No vacíes el firewall del host ni reemplaces las políticas predeterminadas para lograr una restricción específica de servicio.
Verifica el acceso permitido y denegado de los clientes
En este paso probarás la política desde ambos orígenes de cliente y confirmarás que el servicio de entrenamiento sigue disponible.
Vuelve de Kali a la Terminal del host Ubuntu para utilizar las vistas de los clientes proporcionados:
exit
El indicador del host nombra a labex. Registra el nuevo resultado del cliente permitido:
training-client allowed > /home/labex/project/allowed-after.txt
cat /home/labex/project/allowed-after.txt
Debe seguir indicando 200 OK.
Se espera que el siguiente comando falle con una conexión rechazada u otro error de conexión: este es el cliente que bloqueaste deliberadamente. Continúa después del fallo intencionado:
training-client blocked
Una solicitud fallida del cliente bloqueado solo es significativa mientras la ruta permitida siga funcionando. Detener el servicio web rompería ambas rutas y no demostraría la política requerida.
Vuelve a Kali e inspecciona los contadores después de las pruebas:
kali
sudo iptables -L INPUT -n -v --line-numbers
Los contadores de las reglas relevantes deben haber aumentado. Has comprobado el comportamiento real del tráfico además del texto de las reglas y la Terminal del host LabEx sigue disponible durante todo el ejercicio.
Resumen
Inspeccionaste políticas de cadenas, añadiste reglas ordenadas basadas en el origen para un servicio, guardaste y restauraste la configuración del ejercicio y probaste el acceso real desde dos clientes. El origen permitido y el servicio permanecieron disponibles mientras se denegaba el acceso al origen designado.
