Regulă UFW nouă, conexiune veche: câștigă starea stabilită

Adăugarea unei reguli de refuz și vederea unei descărcări deschise care continuă nu este un bug UFW. Regula pe care ați adăugat-o stă după reguli care au acceptat deja fluxul, iar o conexiune stabilită mai devreme continuă să li se potrivească. Remedierea înseamnă inserarea în poziția corectă și înțelegerea a ceea ce promit regulile anterioare. Versiunea îngustă a acestei schimbări este următoarea.

Ordinea decide, nu existența regulii

UFW este o interfață care scrie regulile netfilter în etape: o secțiune de cadru care rulează înaintea regulilor utilizatorului, apoi regulile utilizatorului înseși, apoi o secțiune care rulează după ele. Regulile anterioare standard acceptă traficul conexiunilor stabilite și înrudite, iar acele reguli sunt evaluate înaintea oricărui lucru pe care îl adăugați cu un allow sau deny obișnuit. Referința comenzilor UFW documentează sintaxa de inserare și vizualizarea numerotată a stării de care depinde această schimbare.

Această ordine explică surpriza. Noua regulă este reală și se află în tabelul corect, dar nu este prima decizie pe care o întâlnește pachetul. O conexiune deja urmărită ca stabilită nu ajunge niciodată la ea.

Folosiți reguli route pentru această sarcină, deoarece pachetul este redirecționat prin gateway în loc să fie adresat serviciilor proprii ale acestuia. O regulă de intrare ar filtra traficul greșit și ar părea că nu face nimic.

Inserați-o deasupra permisiunii largi

Previzualizați inserarea înainte de a o aplica și confirmați că regula nu există deja altundeva în listă. Duplicarea unei politici identice face eliminarea ulterioară ambiguă, iar persoana care elimină copia greșită nu va observa săptămâni întregi.

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

Dacă previzualizarea arată exact o regulă în poziția așteptată, aplicați aceeași comandă fără indicatorul dry-run. Poziția 1 o plasează deasupra permisiunilor de utilizator mai largi, nu deasupra regulilor de cadru discutate anterior. Confirmați că numele interfeței corespunde dispozitivului de tunel de pe acest gateway, deoarece o regulă legată de o interfață care nu mai există va sta în listă și va părea corectă fără să se potrivească cu nimic. Redenumiți referința dispozitivului înainte de aplicare, nu după ce testul eșuează.

În acea regulă nu apare niciun port de destinație, așa că refuză toate porturile TCP de la acea adresă, nu doar HTTPS. Dacă intenția este un singur serviciu, numiți portul; o regulă mai largă decât politica este un incident viitor care își așteaptă primul cititor.

Restrângeți sursa la o singură adresă doar dacă acea adresă este legată de identitatea dorită. Un pool VPN cu alocare dinamică poate da aceeași adresă altui client mâine, iar refuzul ar urma adresa, nu persoana.

Fluxurile stabilite supraviețuiesc noii reguli

Urmărirea conexiunilor este motivul pentru care sesiunea existentă continuă. Odată ce un flux este înregistrat ca stabilit, regulile anterioare acceptă pachetele lui înainte ca refuzul vostru să fie consultat, iar transferul se termină ca și cum nimic nu s-ar fi schimbat. De aceea, testarea cu un browser care reutilizează o conexiune deschisă nu vă spune nimic despre noua politică. Un refuz poate părea inutil la câteva minute după implementare și complet eficient pentru următorul utilizator care se conectează.

Dacă cerința include întreruperea traficului în direct, această modificare a regulii de utilizator nu o poate oferi. Revocarea stării urmărite este o acțiune separată, cu raza ei de impact, și aparține proprietarului firewallului, nu celui care a adăugat regula. Golirea tuturor conexiunilor de pe un gateway pentru ca o sesiune să dispară este genul de remediere care generează un al doilea incident.

Țineți cont și de limite. Această regulă nu spune nimic despre ICMP, UDP sau IPv6, așa că un ping reușit nu este dovada că refuzul a eșuat. Nici o adresă IPv4 nu este un site web: un nume se poate rezolva în mai multe adrese, iar doar cea pe care ați numit-o este acoperită.

Testați cu un flux nou

Citiți regulile de utilizator numerotate și vizualizarea brută efectivă, apoi deschideți o conexiune nouă de la clientul ales:

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

Vizualizarea brută contează pentru că status omite regulile de cadru scrise manual, așa că ordinea poate părea diferită de cea impusă de kernel. Comparați-le pe amândouă înainte de a concluziona că o regulă este în locul greșit.

Apoi verificați cele două controale care dovedesc că regula este îngustă, nu largă: o destinație permisă de la același client funcționează în continuare, iar un al doilea client ajunge în continuare la destinația refuzată dacă politica lui permite. Un refuz care strică ambele teste este o schimbare de politică, nu o măsură țintită.

Când testul s-a terminat, eliminați doar regula pe care ați adăugat-o, repetând-o exact. Dacă politica este permanentă, predați-o proprietarului firewallului împreună cu identitatea clientului, proprietarul destinației și o dată de revizuire, ca o adresă de tunel realocată să nu lase în urmă un refuz învechit.