154 30/03/2026 07/04/2026 8 min

Firewall base su Linux: regole minime da non dimenticare

Un firewall fatto bene non serve a “chiudere tutto”, ma a fare una cosa molto più utile: lasciare passare solo ciò che serve davvero. Su un server Linux questa differenza conta parecchio, perché un blocco sbagliato può fermare SSH, web, mail, DNS o i pannelli di controllo. La regola pratica è semplice: prima capisci quali servizi devono restare raggiungibili, poi apri solo quelle porte, poi verifica.

In un ambiente da webmaster o sysadmin, il firewall base è la prima cintura di sicurezza. Non sostituisce aggiornamenti, hardening, chiavi SSH, backup o monitoraggio, ma riduce molto la superficie d’attacco. E soprattutto ti costringe a ragionare per servizi, non per abitudine.

Il principio da non dimenticare

Prima di scrivere regole, devi sapere quali flussi servono davvero. Un server web tipico non ha bisogno di porte aperte “per comodità”, ma solo di quelle necessarie al suo ruolo. La domanda giusta non è “quali porte posso aprire?”, ma “quali porte devono essere raggiungibili da chi, e da dove?”.

Le categorie più comuni sono queste:

  • Amministrazione: SSH, accesso al pannello, eventuale VPN.
  • Servizi pubblici: HTTP e HTTPS per il sito.
  • Servizi di infrastruttura: DNS, mail, FTP/SFTP se davvero usati.
  • Servizi interni: database, Redis, memcached, che spesso non devono essere esposti all’esterno.

Da qui nasce la regola numero uno: blocca di default, consenti solo il necessario.

Le regole minime che non devono mancare

Ogni firewall base su Linux dovrebbe includere almeno questi punti:

  1. Politica di default restrittiva: tutto bloccato in ingresso, salvo eccezioni esplicite.
  2. Permesso alla connessione già stabilita: per non rompere traffico legittimo e sessioni esistenti.
  3. SSH consentito solo da IP fidati, se possibile: almeno limitato, non aperto a caso su Internet.
  4. HTTP/HTTPS aperti solo se il server ospita siti web: porte 80 e 443.
  5. DNS aperto solo se il server fa da nameserver: 53 TCP/UDP, ma solo se serve davvero.
  6. Mail aperta solo se gestisci posta: 25, 465, 587, 110, 995, 143, 993 secondo il servizio usato.
  7. Pannelli di controllo protetti: porte di cPanel, Plesk, FastPanel o equivalenti solo da IP autorizzati.
  8. Database non esposto: MySQL/MariaDB e PostgreSQL di norma devono ascoltare solo in locale o su rete privata.
  9. Log e controllo: sapere cosa viene bloccato è parte della sicurezza, non un optional.

Prima regola pratica: non bloccare te stesso

L’errore più comune è applicare il firewall senza salvare la sessione SSH o senza autorizzare il proprio IP. Se lavori da remoto, questa è la prima trappola da evitare. Prima di chiudere tutto, devi verificare che il tuo accesso amministrativo resti valido.

Se usi SSH, tieni presente queste buone pratiche:

  • apri la porta SSH solo dopo aver verificato che la regola sia corretta;
  • meglio ancora, limita l’accesso al tuo IP pubblico o a una VPN;
  • se cambi porta SSH, verifica prima di disattivare la porta precedente;
  • non fare mai un reload “cieco” su una macchina remota senza piano di rollback.

Per un server in produzione, la sequenza corretta è: test in parallelo, verifica, poi attivazione definitiva.

Le porte più comuni da valutare

Non esiste una lista universale valida per tutti, ma alcune porte ricorrono spesso. Il punto non è aprirle tutte, ma sapere quali appartengono al tuo scenario.

Amministrazione

  • 22/tcp per SSH, se non è stata cambiata.
  • 2082/2083 per cPanel, se presente.
  • 8443 spesso usata da Plesk.
  • 8880/8888 in alcuni pannelli o stack specifici, da verificare caso per caso.

Web

  • 80/tcp per HTTP.
  • 443/tcp per HTTPS.

DNS

  • 53/tcp e 53/udp solo se il server è nameserver.

Mail

  • 25/tcp per SMTP server-to-server.
  • 465/tcp per SMTPS, se usato.
  • 587/tcp per submission autenticata.
  • 143/993 per IMAP e IMAPS.
  • 110/995 per POP3 e POP3S.

Database e servizi interni

  • 3306/tcp per MySQL/MariaDB, normalmente non esposto su Internet.
  • 5432/tcp per PostgreSQL, normalmente non esposto su Internet.
  • 6379/tcp per Redis, di norma locale o protetto.

Se una porta non ti serve in modo chiaro, non aprirla “per sicurezza”.

Approccio consigliato: partire dal pannello o dal tool nativo

Su molte distribuzioni e pannelli, la gestione del firewall è già integrata. Quando possibile, usa l’interfaccia del sistema o del pannello: è più chiara, più reversibile e riduce gli errori di sintassi.

Esempi comuni:

  • Ubuntu/Debian: UFW.
  • Alma/Rocky/CentOS: firewalld.
  • Plesk: estensioni o regole integrate.
  • cPanel: CSF/LFD è molto diffuso.
  • FastPanel: gestione firewall nel pannello, se disponibile nella tua versione.

Se hai un’interfaccia grafica, il vantaggio è concreto: vedi subito cosa è aperto, cosa è bloccato e su quale interfaccia agiscono le regole.

Regole base con UFW: esempio essenziale

Su Ubuntu e Debian, UFW è spesso la scelta più semplice. L’idea è: default deny in ingresso, allow in uscita, poi aperture mirate.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Questo è il minimo sindacale per un server web con SSH standard. Se gestisci mail o DNS, aggiungi solo le porte necessarie. Dopo l’attivazione, verifica sempre lo stato:

sudo ufw status verbose

Esito atteso: policy di default restrittiva e solo le porte volute in allow.

Regole base con firewalld: esempio essenziale

Su AlmaLinux, Rocky Linux e CentOS, firewalld è molto diffuso. Anche qui il concetto resta lo stesso: apri solo quello che serve.

sudo firewall-cmd --permanent --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Controllo successivo:

sudo firewall-cmd --list-all

Esito atteso: servizi autorizzati visibili nella zona attiva, senza aperture inutili.

Le eccezioni che spesso dimenticano tutti

Le regole base sono facili, ma i problemi veri arrivano con le eccezioni. Ecco quelle che vale la pena controllare sempre.

IP di amministrazione

Se puoi, limita SSH e i pannelli a pochi IP fidati. È una delle misure più efficaci che puoi applicare senza impattare il servizio pubblico. Se il tuo IP cambia spesso, valuta una VPN o un accesso tramite bastion host.

IPv6

Molti server hanno IPv4 ben filtrato ma IPv6 lasciato aperto. È un errore classico. Se il server ha IPv6 attivo, le regole devono essere replicate anche lì. Altrimenti rischi di credere di aver chiuso tutto, mentre il traffico entra da una seconda strada.

Loopback

Le comunicazioni locali su `127.0.0.1` o `::1` non devono essere bloccate. Database, cache e servizi interni spesso dipendono dal loopback. Se rompi quello, puoi causare errori difficili da interpretare.

Connessioni già stabilite

Le regole che accettano traffico `ESTABLISHED,RELATED` o equivalenti sono fondamentali. Senza di esse, il firewall può interrompere risposte legittime, sessioni attive e parte del traffico in uscita.

Cosa non va mai esposto se non serve

Ci sono servizi che, nella maggior parte dei casi, non dovrebbero essere esposti direttamente a Internet:

  • MySQL/MariaDB, salvo casi di replica o accesso remoto ben protetto;
  • PostgreSQL, per lo stesso motivo;
  • Redis e memcached;
  • porte di debug o amministrazione dei container;
  • interfacce di sviluppo, staging o test;
  • pannelli di backend accessibili solo da rete privata.

Il criterio è sempre lo stesso: se il servizio non deve essere consumato dal pubblico, non deve essere raggiungibile dal pubblico.

Firewall e hosting condiviso, VPS e server dedicati

Il contesto cambia molto. Su un hosting condiviso di solito non gestisci il firewall del nodo, quindi il tuo controllo è limitato. Su una VPS o su un dedicato, invece, sei responsabile della parte di rete e devi ragionare con più attenzione.

Su una VPS, il firewall del sistema operativo è la prima linea. Se il provider offre anche un firewall esterno, usalo come secondo livello, ma verifica che le regole siano coerenti. Il rischio più comune è aprire una porta nel sistema e dimenticare il filtro del provider, o viceversa.

Su un server dedicato, è utile avere una logica a strati:

  1. firewall del provider, se presente;
  2. firewall del sistema operativo;
  3. eventuale firewall applicativo o del pannello.

Questa stratificazione aiuta, ma solo se tieni aggiornata la mappa delle regole. Altrimenti diventa difficile capire dove si blocca davvero il traffico.

Come verificare che le regole siano corrette

Un firewall si considera fatto bene solo se è verificato. Le prove minime da fare sono queste:

  1. test di accesso SSH da una sessione separata, prima di chiudere la vecchia;
  2. test HTTP e HTTPS dal browser o con `curl`;
  3. verifica delle porte in ascolto con un controllo locale;
  4. test di eventuali servizi critici, come mail o DNS, se attivi;
  5. controllo dei log del firewall per vedere eventuali blocchi inattesi.

Se dopo il cambio una pagina non si apre più, non partire dal presupposto che sia colpa del web server. Prima verifica se la porta è filtrata, poi controlla il servizio applicativo.

Un piccolo schema mentale che evita errori

Quando configuri il firewall, pensa sempre in questo ordine:

  1. Chi deve entrare? Utenti web, amministratori, mail server, resolver DNS.
  2. Su quale porta? Solo quelle necessarie.
  3. Da quale origine? Internet intera, IP selezionati, rete privata, loopback.
  4. Con quale protocollo? TCP, UDP o entrambi.
  5. Con quale priorità? Prima servizi critici, poi eccezioni, poi ottimizzazioni.

Questo schema riduce molto il rischio di aprire troppo o di dimenticare una dipendenza importante.

Le regole minime da ricordare sempre

Se dovessi conservare solo una lista breve, sarebbe questa:

  • default deny in ingresso;
  • allow solo per servizi realmente necessari;
  • SSH protetto e, se possibile, limitato per IP;
  • HTTP/HTTPS solo se il server pubblica siti;
  • DNS e mail solo se gestiti davvero;
  • database mai esposti senza motivo;
  • IPv6 controllato come IPv4;
  • loopback e connessioni già stabilite sempre consentite;
  • test finale prima di chiudere la sessione di amministrazione.

Un firewall base non è un esercizio teorico: è una lista di scelte concrete. Ogni porta aperta è una decisione, e ogni decisione deve avere una motivazione verificabile. Se mantieni questa disciplina, il server resta più pulito, più sicuro e molto più facile da gestire nel tempo.

Il firewall migliore non è quello che blocca di più, ma quello che lascia passare solo ciò che sai spiegare.

In pratica, la sicurezza parte sempre dalla stessa domanda: quel traffico serve davvero, oggi, su questo server?