firewall
Firewall cloud vs firewall del server: perché la tua porta è ancora bloccata
Una guida semplice per capire perché una porta aperta può essere ancora irraggiungibile quando entrano in gioco sia il firewall cloud sia il firewall del server.
In presenza di errori di rete quali "Connection timed out" durante il tentativo di accesso a un'applicazione web o a un servizio appena pubblicato, la causa risiede frequentemente in una configurazione non allineata tra i diversi livelli di sicurezza di rete.
In breve: Nell'analisi delle regole di filtraggio del traffico tra Cloud Firewall e Server Firewall, occorre considerare che il flusso di rete deve attraversare due barriere di protezione distinte prima di raggiungere l'applicazione target. Il Cloud Firewall opera a livello di infrastruttura di rete del provider provider (esterno all'host), mentre il Server Firewall viene eseguito all'interno del sistema operativo (interno all'host). Il blocco del traffico su una porta di rete da parte di uno qualsiasi di questi due livelli si traduce nell'irraggiungibilità del servizio verso l'esterno.
Differenza tra Cloud Firewall e Server Firewall
Per comprendere l'architettura di protezione, è utile analizzare i livelli di sicurezza dell'infrastruttura server tramite un modello a strati.
Il Cloud Firewall (Security Groups, Network ACL o Firewall di rete del provider) costituisce la protezione perimetrale esterna. Agisce prima che il traffico di rete raggiunga l'interfaccia di rete virtuale (vNIC) dell'istanza e viene gestito tramite la console o la API del cloud provider.
Il Server Firewall opera direttamente nel kernel del sistema operativo dell'host. Su ambienti Linux, viene gestito tramite astrazioni quali ufw, firewalld o tramite l'interfaccia diretta di iptables/nftables. Anche nell'ipotesi in cui il Cloud Firewall autorizzi il traffico in ingresso, il firewall locale può scartare i pacchetti se non sono presenti regole esplicite.
Matrice dei livelli di filtraggio del traffico:
| Livello | Ubicazione | Ambito di Controllo | Sintomo di Errore Tipico |
|---|---|---|---|
| Cloud Firewall | Infrastruttura del Cloud Provider | Ingress/Egress a livello di rete virtuale (VPC) | Porta di rete filtrata/chiusa dall'esterno (Timeout) |
| Server Firewall | Sistema Operativo (Kernel Linux) | Politiche di accettazione dei pacchetti sull'interfaccia locale | Il servizio risponde localmente (127.0.0.1), ma rifiuta la connessione da IP esterno |
| Servizio / Applicazione | Daemon o Container (es. NGINX, Docker) | Binding del socket di rete e ascolto sulla porta | Regole del firewall corrette, ma l'applicazione restituisce Connection Refused |
Oltre ai livelli di filtraggio, occorre verificare che il servizio applicativo sia effettivamente in stato di ascolto (LISTEN) sull'interfaccia corretta. L'apertura delle porte sui firewall non produce alcun effetto se nessun processo è in esecuzione sulla porta target.
Per approfondire i concetti di configurazione del firewall di sistema, consulta la nostra guida su come configurare un firewall sul tuo server.
Cause frequenti di blocco sulle porte di rete
L'impossibilità di raggiungere un servizio applicativo deriva spesso dalla mancata sincronizzazione delle regole di rete lungo il percorso del pacchetto.
Se un'applicazione viene eseguita sulla porta 8080 e tale porta viene aperta unicamente sul firewall locale via ufw, ma il Cloud Firewall del provider autorizza esclusivamente i flussi sulle porte 22, 80 e 443, la connessione verrà bloccata alla periferia della rete senza mai raggiungere il server.
Contrariamente, se la porta 443 viene aperta sul pannello del cloud provider ma il servizio firewalld locale la mantiene nello stato di blocco, il traffico verrà scartato dal sistema operativo dell'host.
Principali anomalie di configurazione:
- Apertura della porta di rete configurata unicamente sul Cloud Firewall.
- Regole perimetrali definite unicamente sul Server Firewall locale.
- Disallineamento del protocollo di trasporto selezionato (es. configurazione di una regola UDP in luogo di TCP).
- Regole di filtraggio ristrette ad un singolo indirizzo IP sorgente o CIDR obsoleto.
- Binding dell'applicazione configurato esclusivamente sull'interfaccia di loopback (
127.0.0.1), rendendola inaccessibile dall'IP pubblico. - Assenza di mapping delle porte (Port Publishing) all'interno di un container Docker.
L'ultimo punto si verifica con frequenza in ambienti containerizzati. Un container può risultare attivo, ma privo di reindirizzamento delle porte verso l'host esterno. Per comprendere la gestione dei container, fa' riferimento alla guida su Docker su server per principianti.
Metodologia di diagnosi del traffico di rete
La risoluzione dei problemi di connettività richiede un'analisi sequenziale dall'esterno verso l'interno dell'architettura:
- Verifica della raggiungibilità esterna (Cloud Firewall):
Effettuare una scansione remota delle porte o un test di connessione via socket (es. nc -zv IP_SERVER PORTA). Se la risposta restituisce Connection timed out, la connessione viene scartata dal filtraggio perimetrale del Cloud Provider.
- Verifica delle regole interne (Server Firewall):
Verificare le tabelle attive sul server tramite i comandi dedicati (sudo ufw status, sudo firewall-cmd --list-all o sudo iptables -L -n -v). Assicurarsi che la porta target sia espressamente autorizzata in ingresso (ACCEPT).
- Verifica dello stato del processo e del Binding:
Ispezionare i socket di rete in ascolto sull'host tramite sudo ss -tulpn. Verificare che il processo sia associato all'indirizzo 0.0.0.0 o :: (tutte le interfacce) e non unicamente a 127.0.0.1.
- Verifica della risoluzione DNS:
Accertarsi che il record DNS associato al dominio punti correttamente all'IP pubblico dell'istanza su cui sono state applicate le regole. La gestione dell'associazione dei nomi a dominio è descritta nella nostra guida su come collegare un dominio al tuo server.
FAQ
L'adozione di un Cloud Firewall rende superfluo il Server Firewall locale? No. La difesa in profondità (Defense in Depth) raccomanda l'uso di entrambi i livelli. Il Cloud Firewall filtra il traffico non autorizzato a monte, riducendo il carico di elaborazione del server, mentre il Server Firewall protegge il sistema da eventuali riconfigurazioni errate o da traffico proveniente dalla rete interna della VPC.
È consigliabile mantenere attivi entrambi i firewall? Sì. L'impiego sinergico di un Cloud Firewall e di un Server Firewall garantisce la massima sicurezza e previene l'esposizione accidentale di servizi qualora una regola perimetrale venga modificata erroneamente.
Perché la connessione SSH (porta 22) funziona regolarmente mentre il servizio web non risponde? Perché le regole di filtraggio sono definite per singola porta e protocollo. La porta 22 (SSH) è correttamente autorizzata sia a livello cloud che locale, mentre le porte 80 e 443 possono risultare bloccate in uno dei due firewall o il web server può non essere in esecuzione.
L'errore "Connection timed out" è sempre riconducibile a un problema di firewall? Sebbene il filtraggio tramite firewall sia la causa primaria, un timeout di connessione può essere originato anche da routing errato a livello di rete, IP pubblico non corretto o dall'assenza di risposta del gateway.
La soluzione intermedia
Server Manager semplifica la gestione della sicurezza perimetrale fornendo una visione unificata dei servizi esposti, dei domini associati e del mapping delle porte di rete.
L'impiego di una dashboard di controllo elimina la necessità di dover tracciare manualmente le regole su molteplici interfacce, riducendo l'insorgenza di errori di configurazione tra porte pubbliche, container e regole di filtraggio del firewall.
La diagnosi dei problemi di connettività di rete si considera conclusa quando le regole del Cloud Firewall autorizzano il traffico sulla porta target, il Server Firewall permette l'ingresso dei pacchetti, l'applicazione esegue il binding corretto sulle interfacce pubbliche e la risoluzione DNS instrada le chiamate all'indirizzo IP corretto.