Regla nova d’UFW, connexió vella: guanya l’estat establert

Afegir una regla de denegació i veure que una descàrrega oberta continua no és un error d’UFW. La regla que heu afegit se situa després de regles que ja havien acceptat el flux, i una connexió establerta abans continua encaixant-hi. Per corregir-ho cal inserir-la a la posició correcta i entendre què prometen les regles anteriors. La versió estreta d’aquest canvi és la que segueix.

L’ordre decideix, no l’existència de la regla

UFW és una interfície que escriu regles de netfilter per etapes: una secció de marc que s’executa abans de les regles d’usuari, després les regles d’usuari mateixes i després una secció que s’executa després. Les regles prèvies estàndard accepten el trànsit de connexions establertes i relacionades, i aquestes regles s’avaluen abans que res que afegiu amb un allow o un deny normal. La referència de comandes d’UFW documenta la sintaxi d’inserció i la vista numerada d’estat de què depèn aquest canvi.

Aquest ordre explica la sorpresa. La vostra regla nova és real i és a la taula correcta, però no és la primera decisió que troba el paquet. Una connexió que ja es seguia com a establerta no hi arriba mai.

Feu servir regles route per a aquesta feina, perquè el paquet es reenvia a través de la passarel·la en lloc d’adreçar-se als serveis propis de la passarel·la. Una regla d’entrada filtraria el trànsit equivocat i semblaria que no fa res.

Inseriu-la per sobre del permís ampli

Previsualitzeu la inserció abans d’aplicar-la i confirmeu que la regla no existeix ja en un altre lloc de la llista. Duplicar una política idèntica fa ambigua la retirada posterior, i qui elimini la còpia equivocada no ho notarà durant setmanes.

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 previsualització mostra exactament una regla a la posició que espereu, apliqueu la mateixa comanda sense el flag dry-run. La posició 1 la col·loca per sobre dels permisos d’usuari més amplis, no per sobre de les regles de marc revisades abans. Confirmeu que el nom de la interfície coincideix amb el dispositiu de túnel d’aquesta passarel·la, perquè una regla limitada a una interfície que ja no existeix quedarà a la llista amb bon aspecte mentre no coincideix amb res. Canvieu la referència del dispositiu abans d’aplicar-la, no després que falli la prova.

En aquesta regla no hi apareix cap port de destinació, així que denega tots els ports TCP d’aquella adreça i no només HTTPS. Si la intenció és un sol servei, anomeneu el port; una regla més àmplia que la política és un incident futur que espera el seu primer lector.

Limiteu l’origen a una sola adreça només si aquesta adreça està lligada a la identitat prevista. Un pool de VPN amb assignació dinàmica pot donar la mateixa adreça a un altre client demà, i la denegació seguiria l’adreça en lloc de la persona.

Els fluxos establerts sobreviuen a la regla nova

El seguiment de connexions és la raó per la qual la sessió existent continua. Un cop un flux es registra com a establert, les regles prèvies accepten els seus paquets abans que es consulti la vostra denegació, i la transferència acaba com si res no hagués canviat. Per tant, provar amb un navegador que reutilitza una connexió oberta no us diu res sobre la política nova. Una denegació pot semblar inútil minuts després del desplegament i completament efectiva per al següent usuari que es connecti.

Si el requisit inclou tallar trànsit en viu, aquest canvi de regla d’usuari no ho pot fer. Revocar l’estat seguit és una acció separada amb el seu propi radi d’impacte, i pertany al propietari del tallafoc i no a qui va afegir la regla. Buidar totes les connexions d’una passarel·la per fer desaparèixer una sessió és el tipus de solució que genera un segon incident.

Recordeu també els límits. Aquesta regla no diu res sobre ICMP, UDP ni IPv6, així que un ping correcte no és prova que la denegació hagi fracassat. Una adreça IPv4 tampoc no és un lloc web: un nom pot resoldre’s a diverses adreces i només queda coberta la que heu anomenat.

Proveu amb un flux nou

Llegiu les regles d’usuari numerades i la vista crua efectiva, i després obriu una connexió nova des del client seleccionat:

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 crua importa perquè status omet regles de marc escrites a mà, així que pot fer que l’ordre sembli diferent del que aplica el nucli. Compareu les dues abans de concloure que una regla és al lloc equivocat.

Després comproveu els dos controls que demostren que la regla és estreta i no àmplia: una destinació permesa des del mateix client encara funciona, i un segon client encara arriba a la destinació denegada si la seva política ho permet. Una denegació que trenca totes dues proves és un canvi de política, no una mesura dirigida.

Quan la prova s’hagi acabat, elimineu només la regla que heu afegit, tornant-la a escriure exactament. Si la política és permanent, lliureu-la al propietari del tallafoc amb la identitat del client, el propietari de la destinació i una data de revisió, perquè una adreça de túnel reassignada no deixi enrere una denegació obsoleta.