Nuova regola UFW, vecchia connessione: vince lo stato stabilito

Aggiungere una regola di rifiuto e vedere un download aperto continuare non è un bug di UFW. La regola che avete aggiunto si trova dopo regole che hanno già accettato il flusso, e una connessione stabilita prima continua a corrispondervi. Correggere significa inserirla nella posizione giusta e capire cosa promettono le regole precedenti. La versione ristretta di quella modifica è quella che segue.

Decide l’ordine, non l’esistenza della regola

UFW è un’interfaccia che scrive le regole di netfilter per fasi: una sezione di framework che gira prima delle regole utente, poi le regole utente stesse, poi una sezione che gira dopo. Le regole precedenti predefinite accettano il traffico delle connessioni stabilite e correlate, e quelle regole vengono valutate prima di qualunque cosa aggiungiate con un allow o un deny normale. Il riferimento ai comandi di UFW documenta la sintassi di inserimento e la vista numerata dello stato da cui dipende questa modifica.

Quest’ordine spiega la sorpresa. La vostra nuova regola è reale ed è nella tabella giusta, ma non è la prima decisione che il pacchetto incontra. Una connessione già tracciata come stabilita non la raggiunge mai.

Usate regole route per questo lavoro, perché il pacchetto viene inoltrato attraverso il gateway invece di essere indirizzato ai suoi stessi servizi. Una regola di input filtrerebbe il traffico sbagliato e sembrerebbe non fare nulla.

Inseritela sopra il permesso ampio

Visualizzate l’inserimento prima di applicarlo e confermate che la regola non esista già altrove nell’elenco. Duplicare una politica identica rende ambigua la rimozione successiva, e chi elimina la copia sbagliata non se ne accorgerà per settimane.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Se l’anteprima mostra esattamente una regola nella posizione attesa, applicate lo stesso comando senza il flag dry-run. La posizione 1 la mette sopra i permessi utente più ampi, non sopra le regole di framework esaminate prima. Confermate che il nome dell’interfaccia corrisponda al dispositivo tunnel su questo gateway, perché una regola limitata a un’interfaccia che non esiste più resterà nell’elenco sembrando corretta mentre non corrisponde a nulla. Rinominare il riferimento al dispositivo prima di applicare, non dopo che il test è fallito.

In quella regola non compare alcuna porta di destinazione, quindi rifiuta tutte le porte TCP su quell’indirizzo e non solo HTTPS. Se l’intento è un solo servizio, nominate la porta; una regola più ampia della politica è un futuro incidente che attende il suo primo lettore.

Limitate l’origine a un solo indirizzo solo se quell’indirizzo è legato all’identità prevista. Un pool VPN con assegnazione dinamica può consegnare lo stesso indirizzo a un altro client domani, e il rifiuto seguirebbe l’indirizzo invece della persona.

I flussi stabiliti sopravvivono alla nuova regola

Il tracciamento delle connessioni è il motivo per cui la sessione esistente continua. Una volta che un flusso è registrato come stabilito, le regole precedenti accettano i suoi pacchetti prima che il vostro rifiuto venga consultato, e il trasferimento termina come se nulla fosse cambiato. Per questo provare con un browser che riutilizza una connessione aperta non vi dice nulla sulla nuova politica. Un rifiuto può sembrare inutile minuti dopo la distribuzione ed essere del tutto efficace per il prossimo utente che si connette.

Se il requisito include tagliare il traffico in tempo reale, questa modifica alla regola utente non può fornirlo. Revocare lo stato tracciato è un’azione separata con il proprio raggio d’impatto, e appartiene al proprietario del firewall e non a chi ha aggiunto la regola. Svuotare tutte le connessioni di un gateway per far sparire una sessione è il tipo di correzione che genera un secondo incidente.

Ricordate anche i limiti. Questa regola non dice nulla su ICMP, UDP o IPv6, quindi un ping riuscito non è prova che il rifiuto abbia fallito. Un indirizzo IPv4 non è nemmeno un sito web: un nome può risolversi in più indirizzi, e solo quello che avete nominato è coperto.

Provate con un flusso nuovo

Leggete le regole utente numerate e la vista grezza effettiva, poi aprite una nuova connessione dal client scelto:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

La vista grezza conta perché status omette le regole di framework scritte a mano, quindi può far sembrare l’ordine diverso da quello imposto dal kernel. Confrontate le due prima di concludere che una regola è nel posto sbagliato.

Poi verificate i due controlli che dimostrano che la regola è circoscritta e non ampia: una destinazione consentita dallo stesso client funziona ancora, e un secondo client raggiunge ancora la destinazione rifiutata se la sua politica lo consente. Un rifiuto che rompe entrambi i test è un cambio di politica, non una misura mirata.

Quando il test è finito, rimuovete solo la regola che avete aggiunto, ripetendola esattamente. Se la politica è permanente, consegnatela al proprietario del firewall con l’identità del client, il proprietario della destinazione e una data di revisione, così che un indirizzo del tunnel riassegnato non lasci dietro un rifiuto obsoleto.