Testarea modificărilor de firewall fără a te bloca afară
Ordonează-ți căile de recuperare înainte de a intra regula, apoi verifică cu un flux pe care noua politică trebuie să îl evalueze, nu cu sesiunea care a supraviețuit.
Regula intră, terminalul pe care îl ai deja continuă să răspundă, iar următoarea autentificare este refuzată. Exact acest gol este toată dificultatea testării unei modificări de firewall prin conexiunea pe care o schimbi. Urmărirea conexiunilor decide o dată și apoi nu mai privește, așa că un flux deja stabilit este singura probă care nu poate vedea noua politică. În cele ce urmează sunt comparate cele trei căi de întoarcere, apoi este stabilită ordinea în care se schimbă și se verifică regulile.
De ce sesiunea supraviețuitoare este cea mai slabă dovadă
Un firewall cu stare evaluează primul pachet al unui flux și păstrează acel verdict cât timp intrarea este vie. Regulile adăugate după aceea se aplică fluxurilor care încep mai târziu, de aceea fereastra în care tastați rămâne utilizabilă în timp ce toți ceilalți sunt refuzați. Ce înveți din ea descrie politica valabilă acum câteva minute. Chiar și o captură făcută pe acel flux arată o decizie pe care mașina a luat-o deja.
Tratează sesiunea funcțională ca pe o ieșire de urgență, nu ca pe o măsurătoare. Fiecare verificare care merită trebuie să deschidă un flux nou dintr-o sursă pe care noua regulă o va evalua, iar prima verificare ar trebui să fie cea al cărei eșec ar durea cel mai mult. Când acea sesiune este singura ta cale de intrare, modificarea nu este gata să fie făcută.
Trei căi de întoarcere, ordonate după de ce depinde fiecare
Ordonează opțiunile după cât de mult depind de dispozitivul testat, pentru că la această ordine apelezi când regula se dovedește greșită. O consolă care nu trece niciodată prin firewall este independentă, o revenire exersată este aproape la fel, iar sesiunea deja deschisă nu este.
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
Înainte de modificare, autentifică-te prin consolă și dovedește că funcționează, pentru că o cale în afara benzii pe care nu ai folosit-o niciodată este o schemă, nu o soluție de rezervă. O revenire își merită locul doar după un exercițiu pe acea platformă, cu acel set de reguli, urmând procedura aprobată în loc să improvizezi pe o mașină live. Scrie pașii și roagă pe altcineva să ți-i citească. Dacă secvența are nevoie de memoria ta ca să se termine, nu este un plan.
O modificare, apoi o conexiune care trebuie evaluată
Salvează setul de reguli activ și fișierul care îl deține, apoi fă o singură editare îngustă. O modificare pe test păstrează rezultatul atribuibil; două deodată te lasă cu o mașină funcțională și fără nicio idee care editare a făcut treaba. Acolo unde platforma poate analiza o configurație fără a o încărca, fă asta mai întâi, ca o greșeală de tastare să eșueze când nimic nu este în joc.
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
Apoi pornește o sesiune nouă dintr-o sursă cu care regula modificată se va potrivi, în timp ce consola este încă conectată. Repetă o dată dacă reușește, pentru că prima încercare poate ajunge pe o intrare pe care tabelul o avea deja. Dacă eșuează, ai încă o cale de intrare și o decizie de anulat, iar acesta este cel mai ieftin rezultat prost disponibil.
Contoarele, starea și fișierul răspund la întrebări diferite
Fiecare dintre cele trei observații poate părea convingătoare singură și te poate înșela în privința celorlalte două. Contoarele arată dacă fluxul tocmai creat a ajuns la regula pe care ai editat-o. Tabelul de stare arată ce fluxuri consideră mașina că sunt deja stabilite, și astfel o regulă stricată poate încă părea sănătoasă. Fișierul salvat arată ce va face dispozitivul după următoarea reîncărcare, iar aceasta poate să nu fie ce face acum setul de reguli în execuție.
ss -tn state established
Citește contoarele ca pe o deltă, nu ca pe un total, pentru că singurul număr care contează este cel pe care fluxul tău de test l-a mișcat. O regulă al cărei contor nu crește niciodată nu se potrivește, oricât de corectă ar părea pe hârtie. Confirmă și cazul de respingere: o politică ce nu a respins niciodată nimic nu a dovedit niciodată că respinge ceea ce voiai să blochezi. Parcurge o interfață din fiecare familie pe care implementarea chiar o transportă, pentru că o regulă v4 nu spune nimic despre un flux v6.
Restaurează din setul de reguli salvat, apoi adu fișierul în acord
Când modificarea eșuează, încarcă setul de reguli salvat în loc să adaugi reguli permisive până când autentificările funcționează din nou. Fiecare permisiune în plus calmează simptomul și lasă o gaură care supraviețuiește incidentului și amintirii lui. Restaurează, reconectează, apoi păstrează comparația eșuată lângă evidența a ceea ce ai încercat.
După o modificare reușită, fă ca fișierul de pe disc să descrie setul de reguli care rulează și confirmă că o reîncărcare îl reproduce. Un set de reguli viu care s-a îndepărtat de propriul fișier de configurare este o capcană întinsă pentru următoarea repornire.