Nova regra de UFW, conexión vella: gaña o estado establecido

Engadir unha regra de denegación e ver que unha descarga aberta continúa non é un fallo de UFW. A regra que engadiu queda despois de regras que xa aceptaran o fluxo, e unha conexión establecida antes segue coincidindo con elas. Corrixilo esixe inserila na posición correcta e entender que prometen as regras anteriores. A versión restrinxida dese cambio é a que segue.

Manda a orde, non a existencia da regra

UFW é unha interface que escribe regras de netfilter por etapas: unha sección de marco que se executa antes das regras de usuario, despois as regras de usuario propiamente ditas e logo unha sección que se executa tras elas. As regras previas estándar aceptan o tráfico de conexións establecidas e relacionadas, e esas regras avalíanse antes que calquera cousa que engada cun allow ou un deny normal. A referencia de comandos de UFW documenta a sintaxe de inserción e a vista numerada de estado da que depende este cambio.

Esa orde explica a sorpresa. A súa regra nova é real e está na táboa correcta, pero non é a primeira decisión que atopa o paquete. Unha conexión que xa se seguía como establecida nunca chega ata ela.

Use regras route para esta tarefa, porque o paquete reenvíase a través da pasarela en lugar de dirixirse aos seus propios servizos. Unha regra de entrada filtraría o tráfico equivocado e parecería non facer nada.

Insírea por riba do permiso amplo

Previsualice a inserción antes de aplicala e confirme que a regra non existe xa noutro punto da lista. Duplicar unha política idéntica volve ambigua a retirada posterior, e quen elimine a copia equivocada non o 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

Se a previsualización mostra exactamente unha regra na posición que espera, aplique o mesmo comando sen a opción dry-run. A posición 1 colócaa por riba dos permisos de usuario máis amplos, non por riba das regras de marco revisadas antes. Confirme que o nome da interface coincide co dispositivo de túnel desta pasarela, porque unha regra limitada a unha interface que xa non existe ficará na lista con aspecto correcto mentres non coincide con nada. Cambie a referencia do dispositivo antes de aplicala, non despois de que falle a proba.

Nesa regra non aparece ningún porto de destino, así que denega todos os portos TCP desa dirección e non só HTTPS. Se a intención é un só servizo, nomee o porto; unha regra máis ampla que a política é un incidente futuro que espera o seu primeiro lector.

Restrinxa a orixe a unha soa dirección só se esa dirección está ligada á identidade prevista. Un conxunto de VPN con asignación dinámica pode entregar a mesma dirección a outro cliente mañá, e a denegación seguiría a dirección en lugar da persoa.

Os fluxos establecidos sobreviven á regra nova

O seguimento de conexións é a razón de que a sesión existente continúe. Unha vez que un fluxo queda rexistrado como establecido, as regras previas aceptan os seus paquetes antes de que se consulte a súa denegación, e a transferencia remata como se nada cambiase. Por iso, probar cun navegador que reutiliza unha conexión aberta non lle di nada sobre a política nova. Unha denegación pode parecer inútil minutos despois do despregamento e totalmente eficaz para o seguinte usuario que se conecte.

Se o requisito inclúe cortar tráfico en vivo, este cambio de regra de usuario non pode conseguilo. Revogar o estado seguido é unha acción aparte co seu propio radio de impacto, e corresponde ao propietario da devasa e non a quen engadiu a regra. Baleirar todas as conexións dunha pasarela para que desapareza unha sesión é o tipo de arranxo que xera un segundo incidente.

Lembre tamén os límites. Esta regra non di nada sobre ICMP, UDP nin IPv6, así que un ping correcto non é proba de que a denegación fallase. Unha dirección IPv4 tampouco é un sitio web: un nome pode resolverse en varias direccións e só queda cuberta a que vostede nomeou.

Probe cun fluxo novo

Lea as regras de usuario numeradas e a vista crúa efectiva, e logo abra unha conexión nova desde o 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

A vista crúa importa porque status omite regras de marco escritas a man, así que pode facer que a orde pareza distinta da que impón o núcleo. Compare as dúas antes de concluír que unha regra está no lugar equivocado.

Despois comprobe os dous controis que demostran que a regra é restrinxida e non ampla: un destino permitido desde o mesmo cliente segue funcionando, e un segundo cliente segue chegando ao destino denegado se a súa política o permite. Unha denegación que rompe ambas as probas é un cambio de política, non unha medida dirixida.

Cando remate a proba, elimine só a regra que engadiu, repetíndoa exactamente. Se a política é permanente, entréguea ao propietario da devasa coa identidade do cliente, o propietario do destino e unha data de revisión, para que unha dirección de túnel reasignada non deixe atrás unha denegación obsoleta.