Nftables su Linux, verifica le regole prima di aprire una porta

Un porto può sembrare chiuso dall’esterno, poi si finisce per cercare nell’applicazione o nel router. Prima di modificare qualsiasi cosa, controlla le regole effettivamente caricate da nftables. Il file /etc/nftables.conf può essere diverso dallo stato attivo, e un firewall locale non spiega da solo tutto il percorso di rete.

Questo metodo consente di leggere il ruleset, identificare la catena che gestisce il traffico in ingresso e testare una modifica senza perdere una sessione SSH. Tieni aperta una seconda connessione se stai operando da remoto.

Inizia leggendo il firewall caricato

Il comando seguente non cambia nulla. Mostra le tabelle, le catene, le regole e gli eventuali contatori attualmente presenti nel kernel:

sudo nft list ruleset

Se l’output è lungo, elenca prima le tabelle e poi punta a quella di tuo interesse:

sudo nft list tables
sudo nft list table inet filter

La famiglia inet può contenere regole IPv4 e IPv6. Una tabella può appartenere anche a ip, ip6, bridge o netdev. Non sostituire una regola IPv6 con una regola IPv4 supponendo che il problema sia risolto.

In una tabella di filtraggio, cerca soprattutto una catena di base con type filter hook input. È questa che riceve il traffico destinato alla macchina. La sua riga policy drop significa che i pacchetti che non incontrano alcuna regola accept verranno rifiutati.

Per vedere gli identificativi delle regole, utili se devi rimuovere una regola specifica in seguito, aggiungi -a:

sudo nft -a list chain inet filter input

Non confondere input, forward e output. Un server che riceve una connessione SSH utilizza generalmente input. Una macchina che instrada traffico verso un altro host può bloccare il pacchetto in forward. Un’applicazione che esce verso Internet passa per output.

Controlla la porta e l’ordine delle regole

Le regole di una catena vengono valutate in ordine. Una regola di rifiuto posizionata prima dell’autorizzazione della porta prevale. Cerca il protocollo, la porta e lo stato della connessione:

sudo nft list chain inet filter input
sudo ss -lntup

Per SSH, una regola attesa somiglia spesso a tcp dport 22 accept. La porta può essere diversa se il demone ascolta altrove. L’output di ss -lntup permette di verificare che un programma stia realmente ascoltando sulla porta e sull’indirizzo attesi. Un firewall aperto non rende disponibile un servizio fermo.

Guarda anche le regole ct state established,related accept e l’interfaccia loopback iif lo accept. Queste evitano di interrompere le risposte alle connessioni già stabilite e gli scambi locali. Se il ruleset contiene contatori, confrontali prima e dopo un test di connessione per sapere quale regola vede il traffico.

Un rifiuto può rimanere al di fuori della macchina: gruppo di sicurezza cloud, router, reindirizzamento NAT, VLAN, firewall aziendale o servizio legato solo a 127.0.0.1. Da un altro host, verifica la porta con nc -vz indirizzo_del_server 22 o con il tuo client SSH. Sul server, controlla l’ascolto con ss prima di intervenire su nftables.

Identifica la regola che blocca davvero

Una catena può richiamare un’altra catena con jump o goto. L’autorizzazione della porta non è quindi necessariamente visibile nella prima catena visualizzata. Rileggi le chiamate alle catene, i set nominati e le regole che portano un prefisso di registrazione. Una regola di tipo counter drop o reject posizionata prima della porta spiega spesso il risultato.

Puoi seguire un pacchetto mirato con nft monitor trace, ma questo comando produce molti dati su una macchina attiva. Riserva questo comando per una breve finestra di diagnostica e filtra il traffico per indirizzo o porta in una regola temporanea. Rimuovi quindi questa regola con il suo handle mostrato da nft -a list ruleset.

Non lasciare una regola di tracciamento o registrazione ampia su un server esposto. Può riempire i registri o aggiungere rumore alla diagnosi. Per un primo controllo, i contatori della catena e un test da un altro host sono spesso sufficienti.

Il ruleset attivo e il file persistente possono divergere

nft list ruleset legge lo stato attivo. Non dice quale servizio ha caricato le regole, né quale file sarà ripreso al riavvio. Su Debian e Ubuntu, guarda solitamente /etc/nftables.conf e lo stato del servizio:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

Su una distribuzione che utilizza firewalld, UFW, Docker o uno strumento di hosting, diversi componenti possono scrivere regole. Non copiare un ruleset visto in un tutorial in /etc/nftables.conf se un altro servizio lo gestisce già. Identifica prima il gestore dichiarato dalla tua macchina e rileggi le regole dopo il suo ricaricamento.

Le regole aggiunte da riga di comando scompaiono spesso al successivo riavvio o al successivo ricaricamento del servizio. Al contrario, modificare il file persistente non cambia nulla finché non viene caricato. È esattamente il motivo per cui controllare entrambi i lati prima di concludere che una porta è aperta.

Salva e testa prima di applicare una regola

Conserva lo stato corrente prima di qualsiasi scrittura. Il file di backup deve rimanere leggibile solo dall’amministratore:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Prepara poi la modifica in un file temporaneo. nft -c verifica la sintassi senza caricare le regole:

sudo nft -c -f /etc/nftables.conf

Questa verifica non prova che il nuovo ruleset ti lascerà entrare. Tieni una seconda sessione SSH connessa, applica il file nella prima, poi prova una nuova connessione da un altro terminale. Se perdi l’accesso, la sessione di backup consente di ripristinare il backup:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# In caso di interruzione o regola errata:
sudo nft -f /root/nftables-before-change.nft

Evita flush ruleset lanciato da solo su un server remoto. Rimuove tutte le regole correnti prima che tu possa confermare il file di sostituzione. Carica un file completo e verificato, poi controlla immediatamente il ruleset attivo.

Controlli dopo la modifica

• Riavvia sudo nft list ruleset e verifica che la tabella e la catena attese siano ancora presenti.
• Testa il servizio da un’altra macchina con la porta realmente utilizzata.
• Controlla sudo ss -lntup se la porta rimane inaccessibile.
• Verifica il registro del kernel con sudo journalctl -k -b se le tue regole registrano i pacchetti rifiutati.
• Dopo un riavvio, verifica che il servizio nftables ricarichi correttamente il file persistente della tua distribuzione.

Per i casi semplici, l’articolo su UFW sotto Linux rimane più adatto. Se devi diagnosticare la disponibilità di un servizio prima di modificare il firewall, controlla anche i porzione aperti con ss. La documentazione nft(8) dettaglia le famiglie, le catene e l’opzione -c.