Firewall UFW: configurazione iniziale

Firewall UFW: configurazione iniziale

UFW (Uncomplicated Firewall) e l'interfaccia user-friendly a iptables/nftables disponibile in Ubuntu e Debian. Permette di scrivere regole di filtraggio in modo leggibile, senza rinunciare alla potenza del firewall sottostante. E perfetto per server di produzione che richiedono una protezione di rete affidabile ma non eccessivamente complessa.

Concetti base

UFW opera sulle catene INPUT, OUTPUT e FORWARD con due policy di default: una per il traffico in entrata e una per quello in uscita. La best practice e deny incoming e allow outgoing, aprendo selettivamente solo le porte necessarie. Le regole possono essere per porta, protocollo (tcp/udp), indirizzo o subnet, e per profili applicativi già definiti (OpenSSH, Nginx Full, Postfix).

Profili applicativi

UFW legge i profili da /etc/ufw/applications.d/. Vederli con ufw app list, ispezionarne uno con ufw app info "Nginx Full". Usare i profili semplifica la lettura delle regole (ufw allow "Nginx Full") e mantiene la configurazione autodocumentata.

Procedura passo-passo

  1. Installa UFW: apt install ufw.
  2. Imposta i default: ufw default deny incoming, ufw default allow outgoing.
  3. Apri SSH PRIMA di abilitare il firewall: ufw allow OpenSSH.
  4. Apri eventuali servizi web: ufw allow "Nginx Full" o singolarmente 80/tcp e 443/tcp.
  5. Abilita rate limiting su SSH: ufw limit OpenSSH (max 6 connessioni in 30 secondi).
  6. Restringi per IP se possibile: ufw allow from 203.0.113.10 to any port 22 proto tcp.
  7. Attiva il logging: ufw logging on (livelli: low, medium, high, full).
  8. Abilita il firewall: ufw enable.
  9. Verifica lo stato: ufw status verbose.

Regole avanzate

Per scenari più articolati si modifica direttamente /etc/ufw/before.rules per regole di NAT, port forwarding o connection tracking. UFW supporta IPv6 nativamente: assicurati che IPV6=yes sia presente in /etc/default/ufw. Per integrazione con Docker, ricorda che Docker bypassa UFW di default: serve configurare la rete con --iptables=false o usare regole DOCKER-USER.

Errori comuni e come risolverli

  • Abilitare UFW con default deny senza aver permesso SSH: ti chiudi fuori; usa sempre la console del provider come fallback.
  • Ignorare IPv6: se hai indirizzi IPv6, le regole devono coprirli o disabilitalo del tutto.
  • Conflitti con Docker: Docker manipola iptables; usa la chain DOCKER-USER per regole custom.
  • Logging troppo verboso: il livello high o full puo saturare /var/log; usa medium in produzione.

Domande frequenti

D: UFW e adatto a server di produzione?
R: Si, ma per scenari complessi (load balancer, NAT, DMZ) considera nftables direttamente o pfSense.

D: Come faccio a rimuovere una regola?
R: Con ufw status numbered ottieni l'indice, poi ufw delete N.

D: UFW protegge dagli attacchi DDoS?
R: Mitiga in parte con rate limiting ma per DDoS volumetrici servono provider con scrubbing dedicato.

Approfondimento tecnico: integrazione con Docker e IPv6

L'interazione tra Docker e UFW e fonte di malintesi frequenti. Docker manipola direttamente iptables a livello più basso di UFW, bypassando le regole. Pubblicando una porta con -p 8080:80, Docker la espone su tutte le interfacce ignorando UFW. Soluzioni: avviare Docker con --iptables=false (richiede regole manuali), pubblicare solo su 127.0.0.1 (-p 127.0.0.1:8080:80), o usare la chain DOCKER-USER per regole custom precedenti a Docker.

Per IPv6, UFW gestisce regole separate in /etc/ufw/user6.rules. Imposta IPV6=yes in /etc/default/ufw e duplica le regole se necessario. Strumenti come ufw status verbose mostrano entrambe le famiglie.

Scenari d'uso reali

Un VPS WordPress apre solo 22, 80, 443. SSH limitato per IP fisso ufficio. Combinato con fail2ban riduce drasticamente i tentativi di intrusione.

Un server Docker con servizi interni usa rete bridge custom + 127.0.0.1 binding + reverse proxy Nginx come unico esposto.

Un bastion host apre SSH solo da IP ufficio e VPN; tutto il resto del traffico va attraverso il tunnel.

Checklist operativa UFW

  • Default deny incoming, allow outgoing.
  • Apri solo le porte effettivamente necessarie.
  • Rate limit su SSH e servizi sensibili.
  • IPv6 abilitato e regole duplicate dove serve.
  • Logging level medium minimo, alert su drop anomali.
  • Backup di /etc/ufw/ in configuration management.
  • Test di accesso dopo ogni modifica significativa.

Risorse e riferimenti

Documentazione Ubuntu su help.ubuntu.com/community/UFW. Per scenari avanzati, nftables e il successore di iptables con sintassi più pulita. Per ambienti container, conoscere le interazioni con la chain DOCKER-USER e essenziale. La documentazione di iptables-extensions descrive moduli avanzati (geoip, recent).

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su firewall ufw richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.

Hai trovato utile quest'articolo?