Le regole del firewall solo NEW non chiudono ogni percorso WAN

Rifiutare le nuove connessioni in uscita sul WAN sembra una politica di chiusura in caso di errore, ma è una promessa più stretta di quanto appaia. I pacchetti che appartengono a flussi già esistenti non vi corrispondono, e nemmeno molte risposte. Questo divario è facile da mancare perché la regola si legge come se coprisse l’interfaccia e non un solo stato di connessione su di essa. E leggere la corrispondenza di stato come un verdetto è ciò che produce un falso senso di chiusura.

Lo stato è una condizione di corrispondenza, non un verdetto

Il tracciamento delle connessioni classifica i pacchetti in base a ciò che il firewall ha già visto, non a ciò che crede l’applicazione. Un flusso osservato in entrambe le direzioni è stabilito, e i suoi pacchetti successivi restano stabiliti anche quando la rotta sottostante passa da un tunnel al collegamento in uscita ordinario. Anche la risposta a una connessione in ingresso può essere traffico stabilito. Quei pacchetti non tornano mai nuovi.

Per questo una regola limitata alle nuove connessioni non può dimostrare che ogni pacchetto protetto è bloccato. Lascia gli altri stati a ciò che fa con essi il resto dell’insieme di regole, che può essere un’accettazione collocata prima nella catena.

Leggi la regola nel suo contesto

Un’accettazione ampia per il traffico stabilito e correlato collocata prima del blocco fa passare un pacchetto prima che il blocco venga valutato. Rimuovere la condizione di stato da una regola successiva non cambierà nulla, perché la valutazione non la raggiunge mai. L’ordine decide l’esito, e la corrispondenza di stato decide quali pacchetti raggiungono quell’ordine.

Ispeziona l’insieme di regole effettivo e non il file che hai modificato, inclusi i salti verso altre catene e tutto ciò che la piattaforma genera. Su un router gestito con iptables, l’elenco della catena mostra le definizioni delle regole, e anche le catene a cui fa riferimento vanno seguite. Un sistema nftables nativo richiede l’esame del proprio insieme di regole e delle priorità degli hook, perché il firmware raramente genera catene identiche.

I contatori dicono quale regola ha realmente corrisposto, e di solito sono più informativi di una cattura di pacchetti presa dopo la decisione. Una regola con contatore a zero non è stata raggiunta, qualunque cosa suggerisca la sua posizione.

Esprimi il divieto indipendentemente dallo stato

Se un gruppo di clienti non deve mai raggiungere internet fuori dal tunnel, dillo direttamente invece di approssimarlo con un solo stato. La regola deve selezionare su origine, uscita e destinazione senza dipendere dallo stato della connessione, e deve stare dove nessuna accettazione precedente può aggirarla. Allora l’accesso di gestione e le eccezioni della rete locale ricevono regole esplicite proprie, così l’intento è visibile nella politica.

Scegliere reject invece di drop cambia come fallisce il traffico corrispondente, e non amplia l’insieme dei pacchetti che la regola seleziona. Una connessione rifiutata e un timeout silenzioso sono sintomi diversi che indicano la stessa selezione.

Una politica che consente deliberatamente risposte a un accesso avviato da remoto sul WAN è difendibile. Va solo descritta così invece di essere presentata come isolamento totale unicamente tramite tunnel.

Verifica chi è davvero nel gruppo

L’esempio copre il traffico IPv4 inoltrato da un prefisso su un’interfaccia. Non dice nulla su IPv6, su un secondo collegamento in uscita né sul traffico che il router stesso origina. Un router che agisce come resolver DNS invia le proprie query a monte, e queste non passano affatto per la catena forward.

Conferma che i client protetti abbiano ancora indirizzi dentro il prefisso scelto, perché un dispositivo che ne è uscito è diretto per caso e non per politica. Estendere il blocco all’intera LAN senza rivedere il progetto delle eccezioni tende anche a rimuovere il tuo percorso amministrativo.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Poi prova un flusso vecchio accanto a uno nuovo. Un nuovo tentativo di connessione e un trasferimento bidirezionale già attivo si comportano diversamente con questa regola, e solo testare entrambi mostra quale politica hai davvero.