Regla nueva de UFW, conexión antigua: gana el estado establecido

Añadir una regla de denegación y ver que una descarga abierta continúa no es un fallo de UFW. La regla que añadió queda después de reglas que ya habían aceptado el flujo, y una conexión establecida antes sigue coincidiendo con ellas. Corregirlo exige insertarla en la posición correcta y entender qué prometen las reglas anteriores. La versión acotada de ese cambio es la que sigue.

Manda el orden, no la existencia de la regla

UFW es una interfaz que escribe reglas de netfilter por etapas: una sección de marco que se ejecuta antes de las reglas de usuario, luego las reglas de usuario propiamente dichas y después una sección que se ejecuta tras ellas. Las reglas previas estándar aceptan el tráfico de conexiones establecidas y relacionadas, y esas reglas se evalúan antes que cualquier cosa que añada con un allow o un deny normal. La referencia de comandos de UFW documenta la sintaxis de inserción y la vista numerada de estado de la que depende este cambio.

Ese orden explica la sorpresa. Su regla nueva es real y está en la tabla correcta, pero no es la primera decisión que encuentra el paquete. Una conexión que ya se seguía como establecida nunca llega hasta ella.

Use reglas route para esta tarea, porque el paquete se reenvía a través de la puerta de enlace en lugar de dirigirse a sus propios servicios. Una regla de entrada filtraría el tráfico equivocado y parecería no hacer nada.

Insértela por encima del permiso amplio

Previsualice la inserción antes de aplicarla y confirme que la regla no existe ya en otro punto de la lista. Duplicar una política idéntica vuelve ambigua la retirada posterior, y quien elimine la copia equivocada no lo notará durante semanas.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Si la previsualización muestra exactamente una regla en la posición que espera, aplique el mismo comando sin la opción dry-run. La posición 1 la coloca por encima de los permisos de usuario más amplios, no por encima de las reglas de marco revisadas antes. Confirme que el nombre de la interfaz coincide con el dispositivo de túnel de esta puerta de enlace, porque una regla limitada a una interfaz que ya no existe se quedará en la lista con aspecto correcto mientras no coincide con nada. Cambie la referencia del dispositivo antes de aplicarla, no después de que falle la prueba.

En esa regla no aparece ningún puerto de destino, así que deniega todos los puertos TCP de esa dirección y no solo HTTPS. Si la intención es un solo servicio, nombre el puerto; una regla más amplia que la política es un incidente futuro que espera a su primer lector.

Restrinja el origen a una sola dirección solo si esa dirección está ligada a la identidad prevista. Un grupo de VPN con asignación dinámica puede entregar la misma dirección a otro cliente mañana, y la denegación seguiría a la dirección en lugar de a la persona.

Los flujos establecidos sobreviven a la regla nueva

El seguimiento de conexiones es la razón de que la sesión existente continúe. Una vez que un flujo queda registrado como establecido, las reglas previas aceptan sus paquetes antes de que se consulte su denegación, y la transferencia termina como si nada hubiera cambiado. Por eso, probar con un navegador que reutiliza una conexión abierta no le dice nada sobre la política nueva. Una denegación puede parecer inútil minutos después del despliegue y totalmente eficaz para el siguiente usuario que se conecte.

Si el requisito incluye cortar tráfico en vivo, este cambio de regla de usuario no puede conseguirlo. Revocar el estado seguido es una acción aparte con su propio radio de impacto, y corresponde al propietario del cortafuegos y no a quien añadió la regla. Vaciar todas las conexiones de una puerta de enlace para que desaparezca una sesión es el tipo de arreglo que genera un segundo incidente.

Recuerde también los límites. Esta regla no dice nada sobre ICMP, UDP ni IPv6, así que un ping correcto no es prueba de que la denegación haya fallado. Una dirección IPv4 tampoco es un sitio web: un nombre puede resolverse en varias direcciones y solo queda cubierta la que usted nombró.

Pruebe con un flujo nuevo

Lea las reglas de usuario numeradas y la vista cruda efectiva, y luego abra una conexión nueva desde el cliente seleccionado:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

La vista cruda importa porque status omite reglas de marco escritas a mano, así que puede hacer que el orden parezca distinto del que impone el núcleo. Compare las dos antes de concluir que una regla está en el lugar equivocado.

Después compruebe los dos controles que demuestran que la regla es acotada y no amplia: un destino permitido desde el mismo cliente sigue funcionando, y un segundo cliente sigue llegando al destino denegado si su política lo permite. Una denegación que rompe ambas pruebas es un cambio de política, no una medida dirigida.

Cuando termine la prueba, elimine solo la regla que añadió, repitiéndola exactamente. Si la política es permanente, entréguela al propietario del cortafuegos con la identidad del cliente, el propietario del destino y una fecha de revisión, para que una dirección de túnel reasignada no deje atrás una denegación obsoleta.