Introduzione a IPtables per principianti

IPtables: cosa fa davvero e dove si innesta nel flusso del traffico

IPtables è il punto in cui Linux decide se un pacchetto può entrare, uscire o attraversare la macchina. Non è un firewall “magico”: è un sistema di regole che lavora dentro il kernel e applica logica molto concreta su pacchetti, porte, indirizzi, interfacce e stati di connessione. Se lo imposti male, blocchi servizi legittimi; se lo lasci troppo aperto, esponi troppo. Il vantaggio è che il comportamento è leggibile e prevedibile, purché tu ragioni per catene, policy e stati, non per tentativi casuali.

Per un principiante la parte importante è questa: IPtables non filtra “il sito” o “l’applicazione”, filtra traffico di rete. Quindi prima si capisce quale porta usa il servizio, da quale interfaccia arriva il traffico e se la macchina deve accettare connessioni in ingresso, inoltrarle verso un altro host o semplicemente far uscire richieste verso Internet.

Le tre catene che devi conoscere subito: INPUT, OUTPUT e FORWARD

Le catene base sono tre. INPUT gestisce i pacchetti destinati alla macchina locale. OUTPUT gestisce i pacchetti generati dalla macchina. FORWARD entra in gioco quando il server fa da router o gateway e inoltra traffico da una rete a un’altra.

Se stai proteggendo un web server classico, quasi sempre lavori su INPUT e OUTPUT. FORWARD diventa rilevante su firewall, router, VPN gateway, container host e nodi che fanno NAT o bridging tra segmenti di rete.

La seconda distinzione utile è tra policy di default e regole esplicite. La policy è il comportamento predefinito della catena quando nessuna regola combacia. Le regole esplicite sono i criteri che aggiungi per consentire o bloccare traffico. In sicurezza operativa, la logica più pulita è spesso “deny by default, allow what you need”, ma va applicata con attenzione: se imposti DROP sulla catena sbagliata senza aver consentito SSH, perdi l’accesso remoto.

Come leggere una regola senza confondersi

Una regola IPtables tipica combina diverse condizioni: interfaccia, protocollo, porta sorgente o destinazione, indirizzo IP, stato della connessione. L’ordine conta molto: il pacchetto viene confrontato dall’alto verso il basso e si ferma alla prima regola che corrisponde. Questo dettaglio da solo spiega molti “non funziona più niente” dopo un cambio superficiale.

Esempio mentale: se inserisci una regola che accetta SSH da una rete di amministrazione, ma sopra hai una DROP generale per tutta la INPUT, la regola di allow non verrà mai raggiunta. In IPtables non vince la regola più “giusta”, vince la regola incontrata per prima.

Comandi base per vedere la situazione reale

Prima di cambiare qualcosa, guarda cosa c’è già. Su un sistema Linux moderno puoi usare questi comandi per leggere le regole attive e capire se stai lavorando su iptables legacy o su una compatibilità con nftables.

Controllo rapido delle regole:

sudo iptables -L -n -v --line-numbers

Il risultato utile non è solo l’elenco delle regole, ma anche i contatori di pacchetti e byte. Se una regola ha contatori a zero, probabilmente non viene mai colpita. Se una regola di DROP aumenta di colpo, hai trovato traffico che viene tagliato davvero, non solo ipotizzato.

Per vedere la tabella completa in formato più adatto a backup e ripristino:

sudo iptables-save

Questo output è prezioso perché puoi salvarlo prima di un cambio e confrontarlo dopo. In ambienti gestiti bene, il backup delle regole non è opzionale: è la tua rete di sicurezza quando una modifica ti taglia fuori dalla macchina.

Il modello più semplice per iniziare senza fare danni

Per un server esposto, la sequenza ragionevole è: consentire il traffico già stabilito, consentire SSH dalla tua rete di amministrazione, consentire i servizi pubblici necessari, poi mettere una policy restrittiva per il resto. Questo approccio riduce gli errori rispetto a partire subito con DROP totale e poi inseguire eccezioni a tentativi.

Le connessioni già avviate vanno preservate con il modulo state/conntrack. Senza questo passaggio, rischi di interrompere risposte legittime a richieste che il server ha già accettato. La regola tipica è semplice e quasi sempre la prima da inserire.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Questa riga dice: se il pacchetto appartiene a una connessione già esistente o correlata, lascialo passare. È una delle basi del firewall stateful e, nella pratica, evita di dover scrivere eccezioni inutili per ogni pacchetto di ritorno.

Aprire SSH senza regalare il server al mondo

SSH è il caso più delicato perché è il canale con cui amministri la macchina. Se lo chiudi male, perdi accesso. Se lo apri troppo, aumenti la superficie d’attacco. La scelta corretta è limitare per sorgente, non solo per porta.

Esempio: consenti SSH solo dalla tua rete di management, ad esempio 203.0.113.0/24:

sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT

Se hai un accesso d’emergenza da console out-of-band, tienilo pronto prima di cambiare policy. In pratica: verifica che la console provider, KVM remota o sessione fisica funzioni davvero. È il tuo rollback operativo se sbagli la regola SSH.

Consentire un web server in modo essenziale

Per un server web classico devi aprire almeno HTTP e, spesso, HTTPS. Anche qui conviene evitare aperture generiche non motivate. Se il server serve contenuti pubblici, consenti solo le porte richieste e non tutto il resto.

sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

Se il server usa anche un reverse proxy locale o un backend su porta privata, valuta se quella porta debba essere accessibile solo da localhost o da una rete interna. Esporre Redis, Memcached, MySQL o pannelli di amministrazione direttamente su Internet è una cattiva idea molto comune.

Politiche di default: quando usare ACCEPT e quando DROP

Per capire IPtables devi smettere di trattare la policy di default come un dettaglio. Se la policy è ACCEPT, il firewall diventa una lista di eccezioni: funziona, ma protegge poco. Se la policy è DROP, il firewall diventa una whitelist: più sicuro, ma richiede ordine e test.

Su una macchina esposta in produzione, la scelta prudente è spesso DROP su INPUT e FORWARD, mentre OUTPUT può restare ACCEPT se non hai esigenze particolari di egress filtering. Se vuoi filtrare anche le uscite, devi essere molto più rigoroso perché rischi di bloccare aggiornamenti, DNS, NTP, API esterne e notifiche.

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Queste tre righe non vanno eseguite alla cieca su una sessione remota senza prima aver garantito SSH e traffico già stabilito. Il rischio pratico è il lockout immediato. Il rollback minimo è avere una console di emergenza o un comando già pronto da eseguire localmente che ripristini la policy precedente.

Logging: utile solo se non ti riempie il disco

Loggare ogni pacchetto bloccato è una tentazione classica. Il problema è che, in caso di scansioni o rumore di rete, ti riempi i log e perdi segnale utile. Il logging va usato con criterio: meglio limitare il rate o loggare solo eventi importanti.

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "IPT INPUT DROP: " --log-level 4
sudo iptables -A INPUT -j DROP

Il prefisso nel log ti aiuta a filtrare rapidamente in /var/log/kern.log, /var/log/messages o nel journal, a seconda della distro. Se stai diagnosticando un problema, i log del kernel ti dicono molto più di un “non va internet” generico: porta, protocollo, origine e spesso il punto in cui il pacchetto viene respinto.

NAT e forwarding: quando il server fa da passaggio

Se la macchina deve inoltrare traffico, ad esempio tra una rete privata e Internet, entri nella parte di NAT e FORWARD. Qui IPtables non si limita a filtrare: può anche riscrivere gli indirizzi sorgente o destinazione. È il caso classico di un gateway che permette a una LAN privata di uscire con un solo IP pubblico.

Per abilitare il forwarding IP a livello kernel, il parametro deve essere attivo. Senza quello, le regole di FORWARD non servono a nulla.

sudo sysctl -w net.ipv4.ip_forward=1

Per renderlo persistente, si usa un file in /etc/sysctl.conf o in /etc/sysctl.d/*.conf. Poi si applica la configurazione con sysctl --system. Se il forwarding non è abilitato, il sintomo tipico è traffico che entra ma non torna indietro, spesso interpretato male come problema DNS o problema del servizio a monte.

Per NAT di uscita, un esempio comune è il masquerade su interfaccia pubblica:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Questa regola ha senso solo se il traffico inoltrato viene realmente instradato attraverso eth0. Se l’interfaccia cambia, la regola va aggiornata. In ambienti con nomi prevedibili delle interfacce, conviene verificare con ip link prima di scrivere la regola.

Ordine delle regole: il dettaglio che decide tutto

Molti problemi con IPtables nascono dall’ordine sbagliato. Se vuoi inserire una regola in testa alla catena, usa -I invece di -A. -A appende in fondo; -I inserisce prima. Questa differenza cambia completamente il risultato su una catena già popolata.

sudo iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

In un firewall ben strutturato, le regole più generali e sicure stanno in alto: traffico già stabilito, loopback, management consentito, servizi pubblici, poi blocco finale. Se metti prima una regola troppo ampia, rischi di vanificare il resto.

La loopback è spesso trascurata, ma è fondamentale per il funzionamento locale di molte applicazioni.

sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT

Bloccare lo può rompere servizi che comunicano in locale, resolver, socket interni e applicazioni che si aspettano un canale locale funzionante. È un errore che sembra banale finché non trovi un servizio “morto” senza motivo apparente.

Salvare e ripristinare le regole senza improvvisare

IPtables va trattato come configurazione critica. Prima di modificare, esporta lo stato corrente. Dopo la modifica, verifica che il servizio atteso risponda e che il ripristino sia possibile. Il backup delle regole è parte del cambio, non un extra.

sudo iptables-save > ~/iptables-backup-$(date +%F-%H%M).rules

Ripristino manuale, se necessario:

sudo iptables-restore < ~/iptables-backup-YYYY-MM-DD-HHMM.rules

Se stai facendo un cambio remoto, il rollback deve essere pronto prima di premere invio. In pratica: tieni una sessione secondaria aperta, usa at o un meccanismo equivalente per ripristinare automaticamente dopo pochi minuti se perdi l’accesso, oppure lavora da console locale. Il punto non è essere paranoici: è evitare di trasformare un firewall in un fermacarte remoto.

Persistenza dopo reboot: perché le regole spariscono

Le regole inserite a mano con il comando iptables non sono persistenti di default. Dopo un riavvio, il sistema torna allo stato gestito dal servizio di boot o dai file di configurazione. Questo è normale, non un bug.

Il metodo cambia a seconda della distribuzione. Su molte macchine si usa un pacchetto o un servizio dedicato che carica le regole salvate all’avvio. In altri casi si integra il restore in systemd o in uno script di provisioning. L’obiettivo è sempre lo stesso: avere una fonte unica di verità per la policy, non una collezione di comandi lanciati a mano mesi fa.

Prima di affidarti alla persistenza, verifica quale stack stai usando davvero. Su sistemi recenti, iptables può essere un frontend compatibile che appoggia su nftables. Non è un problema, ma devi saperlo per non cercare il file sbagliato o applicare comandi che non corrispondono al backend effettivo.

Errori tipici da principianti che in produzione costano tempo

Il primo errore è bloccare tutto e poi cercare di riaprire ciò che serve. Meglio partire da una baseline chiara. Il secondo è dimenticare il traffico di ritorno: senza ESTABLISHED,RELATED molte connessioni sembrano “rotte” quando in realtà hai solo impedito le risposte. Il terzo è non considerare le interfacce: una regola giusta su eth0 non aiuta se il traffico arriva da ens18 o da una VPN.

Un altro errore classico è confondere filtraggio e routing. Se il problema è che il traffico non passa da una rete all’altra, non basta aprire una porta. Devi verificare forwarding, route, NAT e policy della catena FORWARD. Se invece il problema è un servizio che non ascolta, IPtables non è il primo sospettato: controlla prima il demone con ss -lntp e i log applicativi.

Mini checklist operativa per usare IPtables con metodo

1. Identifica il traffico da proteggere: ingresso, uscita o inoltro.
2. Salva lo stato corrente con iptables-save.
3. Verifica interfacce, porte e subnet reali con ip a e ss -lntp.
4. Inserisci prima la regola per ESTABLISHED,RELATED.
5. Aggiungi solo le aperture necessarie, idealmente limitate per sorgente.
6. Imposta la policy di default solo dopo aver testato le eccezioni.
7. Controlla i contatori con iptables -L -n -v --line-numbers.
8. Prepara sempre un rollback con iptables-restore o console di emergenza.

Quando IPtables basta e quando conviene passare oltre

IPtables resta utile per firewall host-based, ambienti piccoli, server singoli, VM e gateway semplici. Se però l’infrastruttura cresce, se vuoi policy più leggibili o se stai già lavorando in un contesto nftables-first, ha senso valutare lo strato più moderno del kernel. Questo non rende IPtables “vecchio” nel senso pratico del termine: significa solo scegliere lo strumento che riduce l’errore operativo.

Per un principiante la priorità non è imparare dieci sintassi, ma capire il modello mentale: una regola è una condizione, una catena è una sequenza, una policy è il comportamento finale, e il rollback è parte del lavoro. Se questi quattro punti sono chiari, IPtables smette di sembrare ostico e diventa uno strumento leggibile, controllabile e adatto a proteggere davvero un host Linux.