Vai al contenuto 
Firewall iptables e UFW controllano quali connessioni un server web accetta e quali blocca: questo determina la superficie di attacco e i fallimenti. In questo articolo pratico, mostro regole chiare, impostazioni predefinite sicure e comandi testati per SSH, HTTP(S), database, logging, IPv6 e Docker, direttamente applicabili agli host produttivi.
Punti centrali
I seguenti punti chiave mi forniscono un rapido orientamento prima di iniziare la configurazione.
- Restrittivo Avvio: Negazione predefinita per le entrate, aperta in modo specifico
- SSH Consentire prima: non rischiare l'accesso
- UFW come interfaccia: sintassi semplice, iptables in background
- Registrazione attivare: Controllare le regole, riconoscere gli attacchi
- Persistenza garantire: Mantenere le regole sui riavvii
Nozioni di base: iptables e UFW in sintesi
Mi affido a iptablesquando ho bisogno di un controllo a grana fine su pacchetti, catene e corrispondenze. Uso UFW quando voglio applicare rapidamente regole affidabili che finiscono internamente come regole di iptables [1]. Questo mi permette di combinare comandi semplici con la potenza del netfilter di Linux senza perdermi nei dettagli. Per i server web, questo significa: costruisco un filtro chiaro davanti ad Apache, Nginx o Node in modo che arrivi solo il traffico desiderato [2]. Questa separazione riduce le superfici di attacco e consente agli attacchi di fallire più spesso.
Entrambi gli strumenti si completano a vicenda e sono io a decidere quale si adatta alla situazione. UFW si distingue per la facilità di lettura, soprattutto su Ubuntu e Debian [3]. iptables mi offre opzioni estese, ad esempio per NAT, interfacce specifiche e corrispondenze complesse. Importante: documento le mie regole in modo conciso, in modo che la manutenzione sia facile in seguito. Se volete saperne di più sul concetto di sicurezza, potete trovare una chiara introduzione qui: Il firewall come scudo protettivo.
Avviare la configurazione: impostare in modo sicuro i criteri predefiniti
Inizio con Predefinito-Politiche: bloccare le entrate, consentire le uscite. In questo modo impedisco che nuovi servizi siano accessibili involontariamente. Consento sempre il loopback, in modo che i processi interni funzionino in modo stabile. Accetto le connessioni esistenti per evitare cancellazioni. Questa sequenza riduce al minimo gli errori di attivazione del firewall [2][5].
Uso UFW per impostare la base con pochi comandi. Poi controllo lo stato in dettaglio per notare immediatamente gli errori di digitazione. Per gli host particolarmente sensibili, limito anche le porte in uscita. Questo riduce il rischio di fughe di dati se un servizio è stato compromesso. Uso spesso i seguenti comandi:
# UFW: regole predefinite
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Politica alternativa più rigida in uscita
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw permette l'uscita 80
sudo ufw consente l'uscita 443
# Controllare lo stato
sudo ufw status verbose
Filtraggio stateful: stati e sequenza
Un flusso di pacchi puliti si alza e si abbassa con Dichiarazioni di Conntrack. Accetto prima le connessioni stabilite, scarto presto i pacchetti non validi e lascio aperto il loopback. Questo riduce il carico e previene gli effetti collaterali dovuti alle cadute tardive. Per iptables, ho impostato deliberatamente l'ordine:
# iptables: basi solide
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P USCITA ACCETTATA
# Consente sempre il loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Consentire connessioni esistenti/associate
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Eliminare precocemente i pacchetti non validi
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Con UFW, ESTABLISHED/RELATED sono già presi in considerazione internamente. Faccio anche attenzione se preferisco GETTARE (silenzioso) o RIFIUTO (attivo, failover più veloce). Per le reti interne preferisco REJECT, nella rete pubblica di solito DROP.
Regole essenziali per i server web: SSH, HTTP e HTTPS
Accendo SSH altrimenti mi blocco facilmente. Poi permetto HTTP e HTTPS in modo che il server web sia accessibile. Imposto solo le porte che mi servono davvero. In seguito, aggiungo facoltativamente il rate limiting o Fail2ban per limitare i tentativi di accesso brutali. Verifico immediatamente ogni modifica con i comandi status o list.
I comandi sono semplici. UFW offre alias parlanti per le porte web, il che aumenta la leggibilità. Con iptables, posso impostare porte e protocolli precisi. Salvo poi le regole di iptables in modo che sopravvivano al riavvio. Ecco i passaggi minimi:
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
SSH sicuro: Limitare e aprire in modo selettivo
Oltre al rilascio, smorzo gli attacchi con Limitazione del tasso o whitelist. UFW offre una protezione semplice:
# Limitazione della velocità SSH (UFW)
sudo ufw limit 22/tcp commento "Limite di velocità SSH"
Ho impostato limiti più sottili con iptables. In questo modo si evita di indovinare massicciamente le password senza escludere gli amministratori legittimi:
# SSH: limitare i tentativi di connessione per fonte
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP
Dove possibile, permetto solo SSH da Indirizzi IP dell'amministratore e lavorare con le chiavi SSH. La modifica delle porte non sostituisce la sicurezza, ma può ridurre il rumore. Documento le eccezioni e le controllo regolarmente.
Proteggere i database e limitare le fonti IP
Non apro mai le porte del database in modo globale, ma solo locale o per indirizzi IP di origine definiti. Questo impedisce agli scanner di trovare porte aperte per MySQL, PostgreSQL o MongoDB. Per le applicazioni locali, 127.0.0.1 è sufficiente come obiettivo; controllo l'accesso dell'amministratore esterno rigorosamente tramite IP. Documento brevemente le modifiche, ad esempio nel wiki del server. Questo mi fa risparmiare tempo durante le verifiche.
Nei progetti utilizzo spesso i seguenti esempi. Verifico in anticipo la correttezza di ogni IP consentito. UFW consente una notazione pulita "da-a", iptables implementa tecnicamente la stessa logica. Uso regole di autorizzazione aggiuntive per le finestre di manutenzione temporanea e le cancello in seguito. In questo modo mantengo l'interfaccia piccola:
# Solo locale: MySQL
sudo ufw allow da 127.0.0.1 a qualsiasi porta 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Consentire un singolo IP
sudo ufw allow da 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Consentire la porta per un IP specifico
sudo ufw allow da 10.1.2.3 a qualsiasi porta 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Bloccare gli aggressori noti
sudo ufw nega da 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Gestione pulita di log, interfacce e IPv6
Accendo Registrazione per verificare le regole e riconoscere il traffico più evidente. Il livello "on" in UFW è sufficiente per la maggior parte degli host, uso solo livelli più alti in modo selettivo. Analizzo i log con journalctl, fail2ban o strumenti SIEM. Questo mi permette di riconoscere gli schemi delle scansioni o dei tentativi di brute force. In caso di anomalie, modifico tempestivamente le regole [2].
Spesso lego le regole a uno specifico Interfacciacome eth0 nelle reti pubbliche. In questo modo si evita che le reti interne vengano influenzate inutilmente. UFW può "consentire l'accesso su eth0 a qualsiasi porta 80", iptables usa -i per le interfacce di ingresso. Per IPv6, controllo l'attivazione in /etc/default/ufw di "IPV6=yes" e uso ip6tables per le regole native [2]. Questa separazione evita le lacune con gli host dual-stack.
ICMP e ICMPv6: accessibilità senza lacune
Lascio il necessario ICMP-in modo che la scoperta della MTU del percorso, i timeout e la diagnostica funzionino. ICMP non è un nemico, ma il cuore del protocollo IP. Limito solo gli echi eccessivi.
# IPv4: Limitare l'eco, consentire i tipi ICMP più importanti
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: Consentire ICMP in generale (è possibile una regolazione fine in before.rules)
sudo ufw allow in proto icmp
All'indirizzo IPv6 ICMPv6 è assolutamente necessario (Neighbour Discovery, Router Advertisement). Consento i tipi principali e limito le richieste di eco:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Utilizzare correttamente la restrizione in uscita e il NAT/masquerading
Limito il traffico in uscita quando Profilo di rischio e la conformità. Consento DNS e HTTPS e blocco tutto il resto, tranne gli obiettivi definiti. In questo modo si riduce l'esfiltrazione di dati in caso di dirottamento di un servizio. Creo eccezioni definite per le applicazioni che richiedono aggiornamenti o API. Documento chiaramente queste eccezioni e le controllo regolarmente.
Per le configurazioni di routing, utilizzo NAT/Masquerading tramite UFW-Before-Rules o raw con iptables. Faccio attenzione all'ordine delle catene in modo che i pacchetti vengano riscritti correttamente. Dopo le modifiche, verifico la connettività e le latenze. Per i sistemi di produzione, pianifico una finestra di manutenzione ed eseguo il backup della configurazione. Questo mi permette di mantenere la tracciabilità dei percorsi di rete [7].
Dettagli in uscita: servizi e protocolli di sistema
Con una politica rigorosa in uscita, permetto specificamente di DNS (53/udp), HTTPS (443/tcp) e se necessario NTP (123/udp). Per i server di posta, aggiungo 25/tcp e 587/tcp. Non risolvo le eccezioni basate sul dominio a livello di pacchetto, ma tramite proxy o logica applicativa.
# UFW: servizi tipici del sistema
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - solo se server di posta elettronica
sudo ufw allow out 587/tcp # Submission - solo se necessario
# iptables: specifico Consenti
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker e firewall: evitare le insidie
Docker imposta il proprio iptables-che possono influenzare la mia politica. Pertanto controllo le catene NAT e FORWARD dopo ogni avvio di composizione o demone. Rilascio deliberatamente le porte esposte ed evito "-p 0.0.0.0:PORT". Invece, le lego all'IP di gestione o al reverse proxy. In questo modo il vettore di attacco rimane più piccolo e visibile [1].
Mantengo attivi i firewall dell'host nonostante Docker. Controllo anche i gruppi di sicurezza a livello di infrastruttura, se disponibili. In caso di conflitti tra UFW e Docker, utilizzo soluzioni documentate o imposto regole in DOCKER-USER. È importante che le responsabilità siano chiare: l'host blocca sempre, i container aprono solo in modo esplicito. Questo ordine impedisce rilasci inconsapevoli.
# DOCKER-USER: applicare la politica globale sugli host prima delle regole Docker
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Impostazioni fini UFW: Sequenza, profili e traffico instradato
Quando la precisione conta, uso "inserto", "numerato" e i profili delle applicazioni. In questo modo mantengo pulita la sequenza di regole e utilizzo definizioni di servizio testate.
# Sequenza di controllo
sudo ufw insert 1 deny in from 198.51.100.0/24
# Visualizzazione numerata e cancellazione mirata
sudo ufw status numbered
sudo ufw delete 3
# Profili delle applicazioni (ad esempio Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw allow "Nginx Full"
# Bloccare il traffico instradato per impostazione predefinita (inoltro)
sudo ufw default deny routed
Memorizzo le eccezioni più complesse in prima.regole rispettivamente dopo.regole. Lì posso inserire il fine-tuning ICMP o il NAT senza perdere la leggibilità delle regole standard.
Regole persistenti: Salvataggio e ripristino
Le regole dell'UFW sono persistente e sopravvivono automaticamente ai riavvii. Questo semplifica notevolmente l'amministrazione sugli host Debian/Ubuntu. Con iptables, salvo le regole dopo le modifiche e le ripristino all'avvio. A tale scopo uso iptables-save/restore o netfilter-persistent. Senza questi passaggi, altrimenti perdo le modifiche dopo un riavvio [5].
Verifico sistematicamente la persistenza: pianifico un riavvio, poi controllo lo stato. Se i contatori e le catene sono corretti, la configurazione è solida. Se mancano delle regole, correggo il percorso di caricamento nel contesto di init o systemd. Questa routine previene le sorprese durante la manutenzione. La documentazione e il backup dei file delle regole completano la procedura.
# Debian/Ubuntu: persistenza per iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save
# Backup manuale
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
Ripristino # (se necessario)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Prestazioni e protezione: limiti, set e messa a punto del kernel
Quando il carico è elevato, riduco il numero di controlli e utilizzo un sistema di controllo mirato. Limiti tariffari. Per gli elenchi di blocchi di grandi dimensioni, lavoro con ipset per ridurre i tempi di ricerca. Utilizzo anche meccanismi di protezione basati sul sistema:
# Contiene SYN flood (kernel)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Limitare la velocità di connessione HTTP per IP sorgente (esempio)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Mantengo la dimensione del Tavolo di collegamento a colpo d'occhio. Se ci sono molte connessioni simultanee, aumento nf_conntrack_max, ma ne verifico prima gli effetti.
Gestione, test e prevenzione degli errori
Me ne vado SSH prima di attivare "deny incoming". Poi verifico da una seconda sessione se l'accesso rimane stabile. Controllo ogni nuova regola con "ufw status verbose" o "iptables -L -v". Questo mi permette di riconoscere i contatori di hit e di vedere se i pacchetti arrivano nella catena prevista. Eseguo il backup dei file del firewall prima di apportare modifiche importanti.
Per una sicurezza completa, combino il firewall con le misure di hardening del sistema. Queste includono impostazioni SSH sicure, gestione delle patch e servizi minimi. Mi piace utilizzare una guida pratica come lista di controllo: Hardening dei server per Linux. Ripeto regolarmente questi controlli e mi attengo a finestre di manutenzione fisse. In questo modo i miei server si mantengono in forma in modo affidabile.
Test e osservazioni avanzate
Controllo l'impatto esterno con Scansione delle porte da una rete esterna e verificare i socket aperti internamente. All'inizio monitoro attentamente i log per riconoscere subito le false conclusioni.
Prese aperte #
ss -lntup
# Panoramica di iptables compatto
sudo iptables -S
sudo iptables -L -v -n
# UFW: stato dettagliato e registri
sudo ufw status verbose
journalctl -k | grep -i ufw
# Controllo esterno (da un altro host/rete)
nmap -Pn -p 22,80,443
Per le modifiche ad alto rischio, sto pianificando una Livello di fallback su. Lavoro in Screen/Tmux e, se necessario, imposto un reset temporizzato se mi blocco. Dopo un test riuscito, annullo nuovamente l'azione di ripiego.
# Esempio: disattivazione automatica come ancoraggio di emergenza (usare con attenzione)
echo "ufw disable" | at now + 2 minuti
# Cancellare di nuovo dopo il test: atrm
Confronto tra i fornitori di hosting: Focus sull'integrazione del firewall
Per l'hosting mi affido a Sicurezza vicino alla piattaforma. Le politiche personalizzate, la rapidità di implementazione delle regole e il buon monitoraggio danno i loro frutti. Nel confronto attuale, webhoster.de colpisce per le opzioni firewall perfettamente integrate e per il supporto rapido. Chi preferisce le configurazioni a pannello beneficia di istruzioni chiare per Firewall di Plesk. La tabella che segue classifica i criteri chiave.
| Fornitore | Integrazione del firewall | Prestazioni | Supporto | Posizionamento |
|---|---|---|---|---|
| webhoster.de | configurare individualmente. | Molto alto | top | 1 |
| Fornitore B | Standard | alto | buono | 2 |
| Fornitore C | Standard | buono | Soddisfacente | 3 |
Esempi pratici: Dal test alla produzione
Inizio ogni set di regole nella cartella Schermo o in una seconda sessione SSH. In questo modo, posso ancora salvarmi in caso di errore operativo. Solo quando un host di prova funziona correttamente, applico le regole in produzione. Le regole del percorso di ritorno e un piano di rollback mi danno ulteriore sicurezza. Alla fine, documento le modifiche in modo conciso nel registro delle modifiche.
Per i server web utilizzo blocchi ricorrenti: consentire SSH, rilasciare HTTP/S, vincolare localmente le porte interne, effettuare il login, limitare ICMP, bloccare i protocolli superflui. Mi occupo poi delle regole di mirroring IPv6 in modo che non rimangano lacune. Controllo sempre separatamente le catene Docker perché impostano i propri percorsi. Infine, convalido l'accesso tramite controlli e monitoraggi esterni. Questo mantiene l'interfaccia pulita e tracciabile [1][2].
Riepilogo per gli amministratori
Con chiaro Regole e alcuni comandi, proteggo in modo affidabile i server web. Negazione predefinita in entrata, SSH prima, rilascio HTTP/S: questa è la base stabile. Porte del database solo localmente o tramite whitelist, logging attivo, osservare IPv6, controllare le catene docker. L'archiviazione persistente e i test regolari evitano brutte sorprese. Questa routine mantiene i servizi accessibili e riduce significativamente i rischi.
Sia che utilizzi UFW o iptables direttamente, una politica chiara ed economica è fondamentale. Documento brevemente, verifico regolarmente e mantengo le eccezioni al minimo. La restrizione in uscita blocca le connessioni non necessarie e limita i danni in caso di compromissione. Con un occhio attento ai log, riconosco più rapidamente le anomalie e reagisco in modo appropriato. In questo modo il server web rimane resistente e la superficie di attacco ridotta.
