Perché conta

Il firewall blocca ciò che non vuoi raggiungibile, ma la difesa migliore è che il servizio non ascolti affatto dove non deve. Un database, una cache, un pannello di amministrazione interni spesso non hanno alcun bisogno di essere raggiungibili dalla rete: devono parlare solo con processi sullo stesso host. La differenza tra legarli a 0.0.0.0 (tutte le interfacce) o a 127.0.0.1 (solo loopback) è enorme — e si risolve con una riga di configurazione.

Vedere cosa ascolta

ss (il moderno sostituto di netstat) mostra i socket in ascolto, su quale indirizzo e di quale processo.

1
2
3
4
5

ss -tulpn
# Netid  State   Local Address:Port    Process
# tcp    LISTEN  0.0.0.0:5432          postgres   ← ESPOSTO a tutta la rete!
# tcp    LISTEN  127.0.0.1:6379        redis      ← solo locale, bene
# tcp    LISTEN  *:443                 nginx      ← pubblico: ok se è un web server

La colonna da leggere è Local Address:

1
2
3

0.0.0.0  o  *    → ascolta su TUTTE le interfacce = raggiungibile da fuori
127.0.0.1 / ::1  → ascolta solo su loopback = SOLO processi locali
10.0.0.5         → ascolta su una specifica interfaccia (es. rete interna)

Un 0.0.0.0 su un servizio che dovrebbe essere interno è il bersaglio da correggere.

Legare al loopback

La correzione sta nella configurazione del servizio. Esempi tipici:

1
2
3
4
5
6
7
8

# PostgreSQL — postgresql.conf
listen_addresses = 'localhost'      # invece di '*'

# Redis — redis.conf
bind 127.0.0.1 ::1                   # invece di 0.0.0.0

# un'app che espone una porta di gestione
# avviala con --host 127.0.0.1 invece di --host 0.0.0.0

Dopo il riavvio del servizio, ss -tulpn deve mostrare 127.0.0.1 al posto di 0.0.0.0. Se un processo esterno deve comunque raggiungerlo, la via corretta non è aprirlo al mondo ma esporlo tramite un reverse proxy o un tunnel, controllando l’accesso a monte.

Il ragionamento completo

1
2
3
4
5

Per ogni porta in ascolto, in ordine:
  1. serve il servizio?           NO → spegnilo (cap. 8)
  2. deve essere in rete?         NO → bind su 127.0.0.1
  3. deve essere pubblico?        NO → bind su interfaccia interna + firewall per sorgente
  4. è pubblico davvero?          SÌ → firewall lo consente + servizio indurito

Questo intreccia i tre strumenti: spegnere (systemd), legare bene (binding), filtrare (nftables). Nessuno dei tre, da solo, copre tutto; insieme riducono la superficie di rete al minimo reale.

Verifica dall’esterno

Il modo più onesto di sapere cosa è esposto è guardare da fuori, come farebbe un attaccante:

1
2

# da un ALTRO host (con autorizzazione!): quali porte vede dall'esterno?
nmap -Pn -p- nome-o-ip-del-server

Ciò che nmap vede aperto dall’esterno è la tua vera superficie di rete pubblica. Idealmente coincide con la manciata di porte che intendi pubblicare, e nient’altro.

Conclusione

Scoprire cosa ascolta con ss, legare al loopback tutto ciò che è interno, e verificare dall’esterno: la superficie di rete si riduce al minimo con poche modifiche di binding. Un sistema sicuro va però anche mantenuto sicuro nel tempo: il software invecchia e le vulnerabilità emergono. La manutenzione è il prossimo tema — aggiornamenti e gestione pacchetti.