Modificarea regulii de firewall nu funcționează: ordinea regulilor și starea conexiunii

Ați editat regula, ați reîncărcat setul de reguli, iar tunelul se comportă exact ca înainte. Acest rezultat are două cauze obișnuite, iar ele cer teste diferite. Fie regula nouă stă după o regulă anterioară care a acceptat deja pachetul, fie schimbul pe care îl urmăriți este o conexiune urmărită pe care modificarea nu o reevaluează niciodată. O regulă într-un fișier exprimă intenția; ceea ce decide pachetul este calea activă pe care o întâlnește. Parcurgeți verificările de mai jos în ordine și păstrați o cale de întoarcere în timp ce faceți asta.

Ordinea regulilor și starea conexiunii sunt defecte diferite

Lanțurile ordonate sunt evaluate de sus în jos, iar prima regulă care ajunge la un verdict final încheie parcurgerea acelui lanț. Puneți o acceptare largă deasupra unei reguli de blocare scrise cu grijă, iar regula de blocare devine documentație: este în set, contorul ei este zero și niciun pachet nu o va atinge vreodată. Același text aplicat pe alt lanț nu dovedește nici el nimic. În nftables, lanțurile de bază se atașează la hook-uri după priorități, așa că o acceptare într-un lanț nu împiedică alt lanț de pe un alt hook sau cu altă prioritate să vadă același pachet.

Urmărirea conexiunilor produce al doilea simptom, iar din exterior arată identic. Odată ce un flux este în tabela de stări, o acceptare pentru established-or-related aproape de vârful lanțului se întoarce înainte ca noua regulă să fie consultată. Mapările NAT au aceeași proprietate: traducerea a fost fixată când fluxul a început, așa că o regulă postrouting editată nu rescrie o sesiune care rulează deja. De aceea o modificare pare să funcționeze la 09:00 pentru o conexiune nouă și pare să nu facă nimic pentru sesiunea pe care cineva a deschis-o la 08:55.

Grupurile de securitate din cloud adaugă un al treilea model care prinde oamenii care au învățat pe iptables. Regulile lor de intrare sunt o listă de permisiuni evaluată ca mulțime, nu ca o parcurgere după prima potrivire, sunt stateful, iar eliminarea unei reguli de permisiune nu termină fluxurile deja urmărite. A presupune semantica primei potriviri pe o platformă care nu o are duce la concluzii încrezătoare și greșite.

Citiți setul de reguli activ, nu fișierul pe care l-ați editat

Începeți cu ceea ce impune kernelul chiar acum. O configurație salvată care nu a fost niciodată aplicată explică un număr surprinzător de comportamente neschimbate, iar excluderea ei costă o singură comandă:

nft list ruleset
iptables-save

Apoi întrebați dacă regula dumneavoastră este atinsă măcar. Contoarele de pachete răspund direct și răspund mai bine decât orice raționament despre intenție:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

O regulă de blocare cu zero pachete după o încercare reală de test nu este o problemă de politică, este o problemă de poziție. Mutarea ei este o modificare de o linie, iar sintaxa este exact ceea ce a cauzat eroarea inițială. Cu iptables, -I inserează și -A adaugă la sfârșit; cu nftables, insert plasează o regulă la începutul lanțului, în timp ce add adaugă la sfârșit. Când o regulă trebuie să câștige, spuneți-o explicit în loc să vă bazați pe ordinea care a fost încărcată din întâmplare.

Dovediți dacă fluxul este urmărit

Înainte de a da vina pe regulă, verificați dacă traficul este măcar o conexiune urmărită. Întrebați tabela de stări despre fluxul concret în loc să o vărsați întreagă:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Listarea arată starea și timpul rămas, și așa distingeți o sesiune stabilită de o încercare nouă; modul de evenimente tipărește actualizările pe măsură ce apar, ceea ce este util în timp ce reconectați un client. Dacă fluxul este prezent cu stare stabilită înainte să fi atins ceva, nicio editare a regulilor de filtrare nu îi va schimba soarta. Nu este un defect al firewall-ului, este contractul filtrării cu stare.

Rezistați tentației de a goli întreaga tabelă pe un gateway de producție. conntrack -F este disponibil, iar el distruge și fiecare flux urmărit de pe mașină, inclusiv sesiunea de administrare din care lucrați și tunelul care poartă shell-ul dumneavoastră. Intrările individuale pot fi șterse când aveți cu adevărat nevoie, dar un flux nou dintr-un port sursă nou este de obicei un experiment mai curat.

Unele căi nu sunt urmărite și se comportă invers. Traficul marcat ca notrack în tabela raw, unele tuneluri care ocolesc hook-urile normale și rutarea asimetrică ce împarte un flux între două gateway-uri produc toate pachete evaluate unul câte unul, sau o stare care nu este creată niciodată la ambele capete. Dacă contoarele se mișcă la fiecare pachet, suspectați o astfel de cale înainte de a suspecta ordinea.

Testați dintr-un flux nou cu o cale de întoarcere

Înainte de a testa o regulă care ar putea tăia accesul la distanță, stabiliți o cale de recuperare: consola furnizorului, o consolă serială, o adresă de administrare în afara benzii sau o a doua interfață pe care regula nu o poate potrivi. Un temporizator de revenire este un companion rezonabil, deoarece va restaura setul de reguli anterior chiar dacă sesiunea dumneavoastră moare la mijlocul testului.

Apoi testați cu un schimb pe care starea nu îl putea acoperi deja. Deconectați și reconectați clientul astfel încât să se creeze un nou cvintuplu, și urmăriți ambele capete în timp ce se întâmplă:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Rulați testul în ambele direcții. O regulă care blochează noul handshake de intrare poate permite totuși calea de răspuns, sau invers, iar un rezultat unidirecțional este motivul obișnuit pentru care o blocare funcționează pe jumătate. Reconectați-vă o dată după test pentru a confirma starea stabilă, și verificați dacă accesul de administrare legitim a supraviețuit; o regulă scrisă pentru un port are obiceiul de a se potrivi cu un interval mai larg decât s-a intenționat.

Înregistrați scopul și poziția împreună cu regula

O regulă fără un scop înregistrat este o regulă pe care nimeni nu îndrăznește să o elimine. Lângă fiecare intrare de blocare, păstrați fluxul pe care îl protejează, lanțul și hook-ul în care trăiește, poziția pe care trebuie să o mențină față de acceptările mai largi și testul care a dovedit-o. Când cineva editează setul de reguli din jur șase luni mai târziu, acea notă este singurul avertisment că poziția a fost deliberată.

Înainte de a închide modificarea, confirmați patru lucruri: setul de reguli care rulează corespunde fișierului, regula nouă are contoare diferite de zero după o încercare nouă, direcția inversă și accesul de administrare încă funcționează, și v-ați reconectat o dată pentru a dovedi starea stabilă, nu starea unei sesiuni mai vechi decât modificarea. Dacă ceva din acestea nu este verificat, modificarea nu este terminată, indiferent ce face tunelul.