Testare modifiche al firewall senza chiudersi fuori

La regola entra, il terminale che hai già continua a rispondere e il login successivo viene rifiutato. Quel varco è tutta la difficoltà di testare una modifica al firewall sulla connessione che stai cambiando. Il connection tracking decide una volta e poi smette di guardare, quindi un flusso stabilito è l'unica sonda che non può vedere la nuova politica. Quanto segue confronta le tre vie di ritorno, poi fissa l'ordine in cui cambiare e controllare le regole.

Perché la sessione sopravvissuta è la prova più debole

Un firewall stateful valuta il primo pacchetto di un flusso e conserva quel verdetto finché l'entry vive. Le regole aggiunte dopo si applicano ai flussi che iniziano più tardi, ed è per questo che la finestra in cui stai digitando resta utilizzabile mentre tutti gli altri vengono rifiutati. Ciò che ne impari descrive la politica in vigore qualche minuto fa. Persino una cattura presa su quel flusso mostra una decisione che la macchina ha già preso.

Tratta la sessione funzionante come una via di fuga e non come una misura. Ogni verifica che valga la pena deve aprire un nuovo flusso da una sorgente che la nuova regola valuterà, e la prima verifica dovrebbe essere quella il cui fallimento farebbe più male. Quando quella sessione è la tua unica via d'ingresso, la modifica non è pronta per essere fatta.

Tre vie di ritorno, ordinate secondo ciò da cui ciascuna dipende

Ordina le opzioni in base a quanto dipendono dal dispositivo in prova, perché è quell'ordine che raggiungi quando la regola si rivela sbagliata. Una console che non passa mai dal firewall è indipendente, un rollback provato lo è quasi, e la sessione già aperta non lo è.

Prima della modifica, accedi dalla console e dimostra che funziona, perché una via fuori banda che non hai mai usato è uno schema e non un piano B. Un rollback si guadagna il suo posto solo dopo una prova su quella piattaforma, con quel set di regole, seguendo la procedura approvata invece di improvvisare su una macchina viva. Scrivi i passaggi e fai rileggerli a qualcun altro. Se la sequenza ha bisogno della tua memoria per concludersi, non è un piano.

Una modifica, poi una connessione che deve essere valutata

Salva il set di regole attivo e il file che lo possiede, poi fai una sola modifica ristretta. Una modifica per test mantiene l'esito attribuibile; due insieme ti lasciano una macchina che funziona e nessuna idea di quale modifica abbia fatto il lavoro. Dove la piattaforma può analizzare una configurazione senza caricarla, fallo prima, così un errore di battitura fallisce mentre nulla è in gioco.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Poi avvia una nuova sessione da una sorgente a cui la regola modificata corrisponderà, mentre la console è ancora collegata. Ripetila una volta se riesce, perché il primo tentativo può finire su un'entry che la tabella già teneva. Se fallisce, hai ancora una via d'ingresso e una decisione da annullare, che è il peggior esito economico disponibile.

I contatori, lo stato e il file rispondono a domande diverse

Ognuna delle tre osservazioni può sembrare convincente da sola e ingannarti sulle altre due. I contatori mostrano se il flusso appena creato ha raggiunto la regola che hai modificato. La tabella di stato mostra quali flussi la macchina ritiene già stabiliti, ed è così che una regola rotta può ancora sembrare sana. Il file salvato mostra cosa farà il dispositivo dopo il prossimo ricaricamento, e forse non è ciò che il set di regole in esecuzione fa adesso.

ss -tn state established

Leggi i contatori come delta e non come totale, perché l'unico numero che conta è quello che il tuo flusso di test ha spostato. Una regola il cui contatore non sale mai non corrisponde, per quanto giusta sembri sulla carta. Conferma anche il caso di rifiuto: una politica che non ha mai rifiutato nulla non ha mai dimostrato di rifiutare ciò che volevi bloccare. Passa da un'interfaccia in ogni famiglia che la distribuzione porta davvero, perché una regola v4 non dice nulla di un flusso v6.

Ripristina dal set di regole salvato, poi allinea il file

Quando la modifica fallisce, carica il set di regole salvato invece di aggiungere regole permissive finché i login non funzionano di nuovo. Ogni permesso in più calma il sintomo e lascia un buco che sopravvive all'incidente e al ricordo che ne resta. Ripristina, riconnetti, poi conserva il confronto fallito accanto al registro di ciò che hai provato.

Dopo una modifica riuscita, fai in modo che il file su disco descriva il set di regole in esecuzione, e conferma che un ricaricamento lo riproduca. Un set di regole vivo che si è allontanato dal proprio file di configurazione è una trappola tesa per il prossimo riavvio.