La modifica della regola del firewall non funziona: ordine delle regole e stato della connessione

Ha modificato la regola, ricaricato il set di regole e il tunnel si comporta esattamente come prima. Quel risultato ha due cause comuni, e richiedono test diversi. O la nuova regola si trova dopo una regola precedente che ha già accettato il pacchetto, oppure lo scambio che sta osservando è una connessione tracciata che la modifica non rivaluta mai. Una regola in un file esprime un'intenzione; a decidere il pacchetto è il percorso attivo che incontra. Segua i controlli qui sotto in ordine e mantenga una via di ritorno mentre lo fa.

L'ordine delle regole e lo stato della connessione sono guasti diversi

Le catene ordinate vengono valutate dall'alto verso il basso, e la prima regola che raggiunge un verdetto definitivo termina il percorso in quella catena. Inserisca un'accettazione ampia sopra una regola di blocco scritta con cura e la regola di blocco diventa documentazione: è nel set di regole, il suo contatore è zero e nessun pacchetto la raggiungerà mai. Lo stesso testo applicato a un'altra catena non dimostra nulla. In nftables le catene base si agganciano agli hook con priorità, quindi un'accettazione in una catena non impedisce a un'altra catena su un hook o una priorità diversi di vedere lo stesso pacchetto.

Il tracciamento delle connessioni produce il secondo sintomo, e dall'esterno sembra identico. Una volta che un flusso è nella tabella degli stati, un'accettazione per established-or-related vicino alla cima della catena ritorna prima che la nuova regola venga consultata. Le mappature NAT hanno la stessa proprietà: la traduzione è stata fissata quando il flusso è iniziato, quindi una regola postrouting modificata non riscrive una sessione già in corso. Ecco perché una modifica sembra funzionare alle 09:00 per una connessione nuova e sembra non fare nulla per la sessione che qualcuno ha aperto alle 08:55.

I gruppi di sicurezza cloud aggiungono un terzo modello che coglie chi ha imparato su iptables. Le loro regole in ingresso sono un elenco di autorizzazioni valutato come insieme anziché come percorso a prima corrispondenza, sono stateful, e rimuovere una regola di autorizzazione non termina i flussi già tracciati. Presumere una semantica di prima corrispondenza su una piattaforma che non la possiede porta a conclusioni sicure e sbagliate.

Legga il set di regole attivo, non il file che ha modificato

Parta da ciò che il kernel sta applicando adesso. Una configurazione salvata che non è mai stata applicata spiega un numero sorprendente di comportamenti invariati, e escluderla costa un solo comando:

nft list ruleset
iptables-save

Poi chieda se la sua regola viene raggiunta. I contatori di pacchetti rispondono direttamente, e rispondono meglio di qualsiasi ragionamento sull'intenzione:

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

Una regola di blocco con zero pacchetti dopo un tentativo di test reale non è un problema di policy, è un problema di posizione. Spostarla è una modifica di una riga, e la sintassi è esattamente ciò che ha causato il bug originale. Con iptables, -I inserisce e -A aggiunge in fondo; con nftables, insert colloca una regola all'inizio della catena mentre add aggiunge in fondo. Quando una regola deve vincere, lo dica esplicitamente invece di fidarsi dell'ordine che è stato caricato per caso.

Dimostri se il flusso è tracciato

Prima di dare la colpa alla regola, verifichi se il traffico è davvero una connessione tracciata. Chieda alla tabella degli stati il flusso specifico invece di riversarla tutta:

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

L'elenco mostra lo stato e il timeout rimanente, ed è così che distingue una sessione stabilita da un tentativo nuovo; la modalità eventi stampa gli aggiornamenti man mano che accadono, il che è utile mentre riconnette un client. Se il flusso è presente con stato stabilito prima che lei tocchi qualsiasi cosa, nessuna modifica alle regole di filtro cambierà il suo destino. Non è un bug del firewall, è il contratto del filtraggio con stato.

Resista alla scorciatoia di svuotare l'intera tabella su un gateway di produzione. conntrack -F è disponibile, e distrugge anche ogni flusso tracciato sulla macchina, inclusa la sessione di gestione da cui sta lavorando e il tunnel che trasporta la sua shell. Le singole voci si possono eliminare quando serve davvero, ma un flusso nuovo da una nuova porta sorgente è di solito un esperimento più pulito.

Alcuni percorsi non sono tracciati, e si comportano al contrario. Il traffico marcato notrack nella tabella raw, alcuni tunnel che aggirano gli hook normali e l'instradamento asimmetrico che divide un flusso tra due gateway producono tutti pacchetti valutati uno alla volta, o uno stato che non viene mai creato a entrambe le estremità. Se i contatori si muovono per ogni pacchetto, sospetti quel tipo di percorso prima di sospettare l'ordine.

Testi da un flusso nuovo con una via di ritorno

Prima di testare una regola che potrebbe tagliare l'accesso remoto, stabilisca una via di recupero: la console del provider, una console seriale, un indirizzo di gestione fuori banda o una seconda interfaccia che la regola non può corrispondere. Un timer di ripristino è un compagno ragionevole, perché ripristinerà il set di regole precedente anche se la sua sessione muore a metà test.

Poi testi con uno scambio che lo stato non poteva già coprire. Disconnetta e riconnetta il client in modo che venga creato un nuovo quintuplo, e osservi entrambe le estremità mentre accade:

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

Esegua il test in entrambe le direzioni. Una regola che blocca il nuovo handshake in ingresso può comunque consentire il percorso di risposta, o il contrario, e un risultato unidirezionale è la ragione abituale per cui un blocco funziona a metà. Si riconnetta una volta dopo il test per confermare lo stato stazionario, e verifichi che l'accesso di gestione legittimo sia sopravvissuto; una regola scritta per una porta ha l'abitudine di corrispondere a un intervallo più ampio del previsto.

Registri scopo e posizione insieme alla regola

Una regola senza uno scopo registrato è una regola che nessuno osa rimuovere. Accanto a ogni voce di blocco, conservi il flusso che protegge, la catena e l'hook in cui vive, la posizione che deve mantenere rispetto alle accettazioni più ampie e il test che l'ha dimostrata. Quando qualcuno modificherà il set di regole circostante sei mesi dopo, quella nota sarà l'unico avvertimento che la posizione era deliberata.

Prima di chiudere la modifica, confermi quattro cose: il set di regole in esecuzione corrisponde al file, la nuova regola ha contatori diversi da zero dopo un tentativo nuovo, la direzione inversa e l'accesso di gestione funzionano ancora, e si è riconnesso una volta per dimostrare lo stato stazionario invece dello stato di una sessione precedente alla modifica. Se qualcosa di questo non è verificato, la modifica non è finita, qualunque cosa faccia il tunnel.