Firewall Linux: porte, UFW e controllo del traffico di rete - Orvieto Linux User Group

Firewall e Linux: cosa sono le porte e come controllare il traffico di rete

Quando utilizziamo Linux come sistema desktop o come server, c’è una domanda che vale la pena porsi: quali servizi sono raggiungibili attraverso la rete e chi può collegarsi al nostro computer?

Potremmo avere un server SSH per amministrare la macchina da remoto, un servizio web per ospitare un sito oppure un’applicazione che utilizza una porta di rete per comunicare con altri dispositivi. Ogni servizio ha uno scopo, ma non tutti devono necessariamente essere accessibili dall’esterno.

È qui che entrano in gioco le porte di rete e il firewall. Con pochi strumenti possiamo verificare quali applicazioni sono in ascolto, capire su quali indirizzi accettano connessioni e stabilire quali comunicazioni consentire.

L’obiettivo non è bloccare tutto indiscriminatamente, ma lasciare accessibile ciò che serve e ridurre le connessioni non necessarie.

Che cosa sono le porte di rete?

Abbiamo già visto che un indirizzo IP identifica un’interfaccia all’interno di una rete IP. Ma un indirizzo, da solo, non basta a distinguere i diversi servizi eseguiti sullo stesso computer.

Immaginiamo un server Linux che ospita un sito web e permette anche l’accesso remoto tramite SSH. Entrambi i servizi utilizzano lo stesso indirizzo IP, ma devono essere raggiungibili attraverso punti di accesso logici differenti: le porte.

Nel caso dei protocolli TCP e UDP, le porte sono numeri a 16 bit, compresi tra 0 e 65535. Possiamo quindi immaginare un indirizzo di rete accompagnato da una porta, come in questi esempi:

192.168.1.50:22    → servizio SSH
192.168.1.50:80    → servizio HTTP
192.168.1.50:443   → servizio HTTPS

Sono esempi di associazioni comuni, non una garanzia: un amministratore può configurare un servizio per utilizzare una porta diversa da quella abituale.

Dobbiamo anche distinguere le porte TCP da quelle UDP. Sono spazi di numerazione separati: la porta TCP 53 e la porta UDP 53, per esempio, non identificano necessariamente la stessa comunicazione. Approfondiremo le differenze tra questi protocolli nell’articolo dedicato a TCP e UDP.

Una porta aperta non significa necessariamente un rischio

Quando sentiamo parlare di porte aperte, potremmo pensare subito a una vulnerabilità. In realtà, una porta è spesso semplicemente il punto attraverso il quale un servizio riceve comunicazioni.

Un server web deve poter ricevere richieste HTTP o HTTPS; un server SSH deve accettare le connessioni di amministrazione previste. Il problema nasce quando un servizio non necessario rimane accessibile, oppure quando un’applicazione espone più di quanto ci aspettiamo.

Per questo è importante capire due aspetti distinti:

Il servizio è in esecuzione e in ascolto?
La rete e il firewall permettono di raggiungerlo?

Sono domande collegate, ma non equivalenti. Un servizio può essere in ascolto e tuttavia non essere raggiungibile da un altro computer, per esempio perché il firewall blocca la connessione. Al contrario, una regola firewall permissiva non avvia automaticamente un servizio che non esiste o non è in ascolto.

La prima operazione, quindi, è osservare il sistema prima di modificarlo.

Come controllare le porte in ascolto su Linux

Su Linux possiamo utilizzare ss, uno strumento che mostra informazioni sui socket di rete. Se vogliamo individuare i servizi in ascolto attraverso TCP e UDP, possiamo eseguire:

sudo ss -tulpen

Le opzioni ci aiutano a leggere il risultato:

-t mostra i socket TCP;
-u mostra quelli UDP;
-l limita la visualizzazione ai socket in ascolto;
-p mostra i processi associati, quando disponibili;
-e aggiunge informazioni estese;
-n mostra gli indirizzi e le porte in formato numerico.

Potremmo trovare righe simili a queste:

tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 127.0.0.1:631 0.0.0.0:*

Sono esempi illustrativi: l’output reale dipende dai servizi installati e dalla configurazione della macchina.

Nel primo caso, il servizio TCP è in ascolto sulla porta 22 su tutti gli indirizzi IPv4 locali. Nel secondo, il servizio è associato a 127.0.0.1, cioè all’indirizzo di loopback: in condizioni normali, è raggiungibile soltanto dal computer stesso attraverso quell’indirizzo.

Questa distinzione è fondamentale. Un servizio associato a 0.0.0.0 può ricevere connessioni attraverso le interfacce IPv4 disponibili, mentre uno associato a un indirizzo specifico è limitato a quell’indirizzo. Per IPv6 possiamo incontrare indirizzi come ::, il cui significato dipende anche dalla configurazione del sistema.

Non dobbiamo però concludere che ogni servizio associato a tutti gli indirizzi sia automaticamente esposto a Internet: il firewall, il router, il routing e gli altri livelli di rete possono comunque impedirne il raggiungimento.

Che cosa fa davvero un firewall?

Un firewall applica regole al traffico di rete. In base alla configurazione può consentire o bloccare connessioni in ingresso, in uscita oppure traffico che attraversa il sistema.

Su Ubuntu è disponibile UFW, acronimo di Uncomplicated Firewall, un’interfaccia progettata per rendere più semplice la gestione delle regole del firewall Linux. La documentazione ufficiale di Ubuntu presenta proprio UFW come uno strumento pratico per gestire il filtraggio del traffico.

Prima di cambiare qualsiasi regola, controlliamo lo stato attuale:

sudo ufw status verbose

Se UFW è attivo, il comando mostra le regole gestite dallo strumento e le politiche predefinite. Se è inattivo, significa che UFW non sta applicando le proprie regole; non possiamo però dedurne automaticamente che il sistema sia completamente privo di filtraggio, perché potrebbero esistere altre regole o altri firewall.

Su una macchina personale può essere utile verificare anche quali servizi siano effettivamente necessari. Su un server, invece, il controllo dovrebbe partire dai servizi che devono essere raggiungibili per svolgere il loro compito.

Configurare UFW senza aprire più del necessario

Immaginiamo di avere un server Linux che deve ospitare un sito web. Vogliamo consentire le connessioni HTTP e HTTPS, ma non lasciare accessibili porte che non servono.

Possiamo aggiungere le regole per il traffico web con:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

La prima regola consente il traffico TCP in ingresso destinato alla porta 80; la seconda fa lo stesso per la porta 443. Non avviano un server web e non garantiscono da sole che il sito sia raggiungibile: il servizio deve essere in esecuzione e anche la rete deve permettere il passaggio delle connessioni.

Per controllare le regole dopo le modifiche, possiamo utilizzare:

sudo ufw status numbered

La numerazione è utile se in seguito vogliamo eliminare una regola specifica. Per esempio, per rimuovere una regola che avevamo aggiunto per HTTP, possiamo utilizzare:

sudo ufw delete allow 80/tcp

Prima di applicare modifiche a un server già operativo, è sempre meglio verificare che le regole corrispondano ai servizi realmente necessari.

Attenzione se amministriamo il server tramite SSH

C’è un caso in cui dobbiamo procedere con particolare cautela: quando siamo collegati al server da remoto.

Se attiviamo un firewall senza consentire prima il servizio SSH sulla porta effettivamente utilizzata, rischiamo di interrompere la nostra possibilità di amministrare la macchina. In una configurazione standard che utilizza la porta 22, possiamo predisporre la regola con:

sudo ufw allow 22/tcp

Se SSH utilizza una porta diversa, dobbiamo naturalmente adattare la regola. Solo dopo aver verificato la configurazione possiamo valutare l’attivazione del firewall:

sudo ufw enable

È preferibile avere accesso alla console della macchina o un altro metodo di recupero prima di intervenire su un server remoto. Inoltre, consentire la porta 22 a qualsiasi indirizzo non è sempre la scelta migliore: se possibile, possiamo restringere l’accesso agli indirizzi o alle reti da cui amministriamo il server.

Perché non conviene aprire tutte le porte

A volte si è tentati di consentire tutto il traffico per risolvere rapidamente un problema di connessione. È una scorciatoia da evitare, soprattutto sui server esposti a reti non fidate.

Una regola ampia può rendere raggiungibili servizi che non avevamo intenzione di pubblicare. È preferibile identificare la porta necessaria, verificare il protocollo utilizzato e creare una regola specifica.

Anche le politiche predefinite meritano attenzione. Una configurazione comune per un server prevede di bloccare le nuove connessioni in ingresso non autorizzate e consentire quelle in uscita, ma la scelta corretta dipende dal ruolo del sistema. Un router Linux, per esempio, ha esigenze diverse da quelle di un portatile.

Non dobbiamo confondere questa impostazione con una protezione assoluta: il firewall è soltanto uno dei livelli della sicurezza. Aggiornamenti, autenticazione, configurazione dei servizi e controllo dei log restano altrettanto importanti.

Come capire perché un servizio non è raggiungibile

Se un’applicazione non risponde, conviene procedere per gradi anziché aggiungere regole casualmente.

Per prima cosa controlliamo se il servizio è in ascolto:

sudo ss -tulpen

Verifichiamo poi le regole del firewall:

sudo ufw status verbose

Se il servizio ascolta soltanto su 127.0.0.1, una connessione proveniente da un altro computer non potrà raggiungerlo tramite l’indirizzo di rete della macchina. Se invece ascolta sull’indirizzo corretto ma la connessione fallisce, dobbiamo considerare anche il firewall, la configurazione di rete e gli eventuali filtri presenti sul router o su altri dispositivi intermedi.

È utile ricordare anche che, quando un’applicazione è eseguita in un container Docker, la pubblicazione di una porta aggiunge un ulteriore livello da controllare. Non basta guardare soltanto UFW: occorre verificare anche la configurazione del container e le regole di rete che Docker gestisce.

Questo approccio ci aiuta a distinguere un problema del servizio da uno di filtraggio o di connettività, evitando di indebolire inutilmente la sicurezza del sistema.

Un firewall efficace parte dalla conoscenza del sistema

Gestire le porte di rete non significa chiuderle tutte, ma sapere perché una porta è utilizzata e da chi deve poter essere raggiunta.

Con ss possiamo individuare i servizi in ascolto; con UFW possiamo verificare e gestire le regole del firewall; con una buona configurazione possiamo limitare le connessioni a quelle necessarie per il funzionamento della macchina.

È un’abitudine semplice, ma preziosa soprattutto quando Linux diventa un server, ospita applicazioni o fa parte di un homelab.

Il passo successivo sarà approfondire il funzionamento di TCP e UDP, per comprendere meglio cosa succede dietro le connessioni che abbiamo appena imparato a controllare.