Come configurare fail2ban per fermare gli attacchi brute-force

Per raggiungere un database engine, una dashboard di monitoraggio o un pannello di gestione sul tuo server, non è necessario esporre le relative porte di rete sul web pubblico.

In breve: Un tunnel SSH (Local Port Forwarding) consente di accedere in modo sicuro a un servizio remoto privato incanalando il traffico all'interno di una connessione SSH cifrata. Questa tecnica permette di mantenere PostgreSQL, Redis, un'interfaccia di amministrazione o un contenitore Docker non accessibili da Internet, rendendoli comunque raggiungibili dal proprio client come se fossero eseguiti in locale. Il servizio rimane segregato; il tunnel SSH agisce da canale cifrato temporaneo tra il computer locale e l'infrastruttura remota.

Che cos'è un tunnel SSH?

Un tunnel SSH sfrutta il meccanismo di port forwarding integrato nel protocollo Secure Shell (SSH) per incanalare il traffico di un servizio arbitrario all'interno di un flusso di comunicazione cifrato.

In un'architettura di rete standard, le porte pubbliche come la 80 (HTTP) e la 443 (HTTPS) sono configurate per accettare connessioni da qualsiasi host esterno. Al contrario, i servizi interni di amministrazione o i database engine devono rimanere confinati all'interfaccia di loopback (127.0.0.1) o a reti private.

Configurando un tunnel SSH locale, il client SSH mappa un socket locale (es. localhost:15432) e reindirizza in modo trasparente e cifrato i pacchetti verso la porta di destinazione del server remoto (es. 127.0.0.1:5432). In questo modo, l'applicazione remota riceve le chiamate direttamente dall'interfaccia locale dell'host, mantenendo la propria porta del tutto nascosta a Internet.

L'adozione dei tunnel SSH consente di accedere alle risorse di rete interne senza dover esporre porte aggiuntive o modificare le policy del firewall di rete.

Quando utilizzare un tunnel SSH?

I tunnel SSH sono indicati in tutte le circostanze in cui un servizio di rete debba essere fruibile esclusivamente dagli amministratori di sistema o dagli sviluppatori, rimanendo del tutto inaccessibile agli host esterni.

I casi d'uso principali includono:

• Interfaccia e client per Database: Connessione tramite tool desktop (es. DBeaver, PGAdmin, DataGrip) a database engine come PostgreSQL, MySQL o MariaDB senza dover esporre le porte 5432 o 3306 su IP pubblico.
• Dashboard e strumenti di amministrazione: Fruizione di pannelli di monitoraggio, interfacce di queuing, dashboard di metriche o console di ricerca interne sprovviste di meccanismi complessi di autenticazione integrata.
• Ambienti di containerizzazione (Docker): Esposizione dei servizi erogati dai container esclusivamente sull'interfaccia locale dell'host (127.0.0.1). Per una panoramica dettagliata sull'architettura dei container, consulta la nostra guida a Docker su server.

Come regola di sicurezza generale: se un servizio non è destinato a servire traffico pubblico, non deve essere esposto direttamente in rete, ma raggiunto esclusivamente tramite tunnel cifrato o VPN.

Analisi comparativa della sicurezza: Port Forwarding vs Esposizione Diretta

L'esposizione diretta di una porta di rete aumenta la superficie d'attacco del server, esponendo il servizio a scansioni automatizzate, attacchi di forza bruta e tentativi di exploit di vulnerabilità zero-day.

L'incanalamento del traffico all'interno di un tunnel SSH applica un livello di autenticazione e cifratura rigoroso a monte del servizio stesso, richiedendo il possesso delle chiavi SSH autorizzate prima di poter stabilire la connessione.

L'efficacia di questa architettura presuppone l'adozione delle best practice di Hardening SSH e l'uso di un firewall di rete per il filtraggio del traffico. Se non hai ancora definito le regole perimetrali, fa' riferimento alla guida su come configurare un firewall sul tuo server.

Problemi frequenti e misconfigurazioni dei tunnel SSH

Durante l'impostazione di un tunnel SSH possono verificarsi errori di configurazione o conflitti di rete:

• Mancata distinzione delle porte locali e remote: Confusione tra il socket locale configurato sul client e l'host/porta di destinazione definiti lato server.
• Binding del servizio su interfacce pubbliche: Se un database o un servizio esegue il binding sull'indirizzo 0.0.0.0 anziché su 127.0.0.1, il servizio risulterà comunque accessibile dall'esterno, vanificando la segregazione offerta dal tunnel.
• Conflitti di porta sul client locale: Se la porta locale scelta sul client (es. 5432) è già occupata da un processo locale, la creazione del tunnel fallirà. Occorre specificare una porta locale differente (es. 15432).
• Persistenza indebita del tunnel: Mantenere attivi tunnel SSH indefinitamente senza tracciamento può generare falle di sicurezza nell'architettura di rete locale.

Se la problematica riguarda l'irraggiungibilità di un'applicazione web pubblica, la diagnosi deve orientarsi sul livello di routing e configurazione del web server. Consulta la nostra guida completa su perché il mio sito non si carica per la risoluzione dei problemi web.

FAQ

È possibile utilizzare un tunnel SSH per connettersi a un database remoto? Sì. Riconfigurando il gestore di database per la connessione tramite porta locale reindirizzata via SSH, l'applicazione client comunicherà con l'istanza remota di PostgreSQL, MySQL o MariaDB in piena sicurezza.

Un tunnel SSH richiede la presenza di un FQDN o nome di dominio? No. Il tunnel SSH viene instradato verso l'indirizzo IP pubblico dell'host o verso l'hostname definito nel file di configurazione SSH locale (~/.ssh/config).

Qual è la differenza tra un tunnel SSH e una connessione VPN? Una VPN (Virtual Private Network) opera a livello di rete (Layer 3) estendendo la connettività per l'intero stack di rete del client, mentre un tunnel SSH opera a livello applicativo (Layer 7) inoltrando unicamente i flussi di dati inviati a uno specifico socket.

È corretto mantenere un tunnel SSH indefinitamente attivo? È preferibile aprire il tunnel SSH all'occorrenza e chiuderlo al termine dell'attività amministrativa. In alternativa, per connessioni persistenti si consiglia l'impiego di daemon dedicati (es. autossh) o di soluzioni VPN/Overlay Network.

La soluzione intermedia

Server Manager consente di gestire l'esposizione dei servizi applicativi riducendo la necessità di configurare manualmente porte di rete pubbliche. L'architettura permette di definire il livello di visibilità di ciascun servizio, isolando i database e le interfacce interne direttamente a livello di configurazione.

L'adozione di un pannello di gestione centralizzato previene le errate configurazioni di binding sugli indirizzi IP pubblici, fornendo chiarezza sulle porte esposte e garantendo la tracciabilità dei servizi nel tempo.

La segregazione delle risorse interne si considera configurata correttamente quando i servizi non pubblici eseguono il binding unicamente sulle interfacce locali (127.0.0.1), il firewall di rete blocca qualsiasi tentativo di connessione diretta alle porte riservate e l'accesso amministrativo avviene esclusivamente attraverso canali cifrati SSH o reti private.

In presenza di anomalie gravemente visibili su un'applicazione web — quali reindirizzamenti automatici verso domini esterni, invio massivo di email di spam o presenza di script e file malevoli non autorizzati — è necessario applicare una procedura di risposta agli incidenti (Incident Response) tempestiva e strutturata.

In breve: A fronte di una confermata compromissione del server, la procedura corretta si articola in tre fasi sequenziali: contenimento dell'incidente, acquisizione delle evidenze forensi e ricostruzione dell'infrastruttura a partire da un backup sicuramente integro. Non occorre fare affidamento sui sistemi di pulizia automatizzati da eseguire sull'ambiente compromesso. L'obiettivo primario consiste nel fermare l'esfiltrazione dei dati o le attività malevoli outbound, individuare il vettore d'attacco iniziale e ripristinare i servizi su un'istanza pulita ed esente da backdoor.

Azioni immediate di contenimento dell'incidente

Quando si riscontra una compromissione, la priorità assoluta è il contenimento dei danni e la segregazione dell'ambiente affetto.

La procedura di emergenza prevede i seguenti passaggi:

1. Isolamento dell'infrastruttura di rete: Interrompere l'esposizione pubblica del server applicando regole restrittive sul firewall, disattivando l'interfaccia di rete o reindirizzando temporaneamente i record DNS su una pagina di manutenzione esterna. Se l'host compromesso viene impiegato per attacchi botnet, esfiltrazione dati o phishing, la velocità di isolamento è prioritaria rispetto all'uptime del servizio.
2. Preservazione delle evidenze (Forensic Snapshot): Evitare la cancellazione diretta di file o la reinstallazione affrettata di pacchetti sul sistema in uso. Prima di ogni intervento, effettuare uno snapshot o un'immagine di backup dello stato attuale della macchina (Rescue Mode). Tali evidenze permetteranno di analizzare la sequenza dell'intrusione ed effettuare la relativa analisi dei log.
3. Rotazione delle credenziali da un endpoint sicuro: Modificare tutte le password, i token API, le credenziali del database engine e le chiavi SSH autorizzate (authorized_keys). La rotazione deve essere eseguita esclusivamente da un dispositivo client sicuro e non infetto, partendo dal presupposto che qualsiasi segreto presente sul server compromesso sia stato intercettato dall'attaccante.

Valutazione dell'impatto e identificazione del vettore d'attacco

Per determinare l'estensione dell'incidente è necessario individuare la causa radice (root cause) e comprendere quali risorse o dati siano stati potenzialmente compromessi.

I vettori d'attacco più comuni includono:

• Autenticazione SSH debole: Utilizzo di credenziali vulnerabili o chiavi private compromesse.
• Vulnerabilità ad alto livello applicativo: Plugin, temi o dipendenze non aggiornati (es. exploit Remote Code Execution su CMS o framework web).
• Misconfigurazione dei servizi esposti: Database engine (MySQL, PostgreSQL, Redis) in ascolto su interfacce di rete pubbliche (0.0.0.0) privi di autenticazione o regole di firewalling.
• Presenza di Web Shell e Backdoor: Script malevoli (PHP, Python, JS) posizionati nella web root per consentire l'esecuzione remota di comandi tramite browser.
• Container ed Execution Environment non segregati: Container Docker eseguiti con privilegi elevati o con montaggio del socket di sistema (docker.sock).

L'analisi dei file di log (/var/log/auth.log, log di accesso e di errore di NGINX/Apache, log dei database) consente di risalire al momento esatto del primo accesso non autorizzato.

Se l'incidente ha interessato database contenenti dati personali, credenziali di accesso cifrate o dati sensibili degli utenti, è indispensabile valutare gli obblighi normativi legati alla notifica di Data Breach (es. adempimenti GDPR).

Ripristino del server: Bonifica manuale o Ricostruzione da zero?

Il ripristino di un sistema compromesso tramite la sola eliminazione manuale dei file malevoli presenta elevati margini di rischio: gli attaccanti inseriscono frequentemente backdoor secondarie o modificano i binari di sistema a livello di kernel.

Confronto tra le strategie di ripristino:

Per la maggior parte delle infrastrutture, la procedura più sicura consiste nell'infrastruttura di un nuovo server pulito (fresh instance), nella correzione della vulnerabilità originale, nel ripristino dei soli dati e contenuti verificati e nella contestuale rotazione di tutti i segreti.

L'efficacia di questa strategia dipende dalla qualità della pianificazione iniziale: consulta la nostra guida su come configurare ed eseguire il backup del server per definire un piano di Disaster Recovery efficiente.

Prevenzione delle intrusioni ricorsive

Completato il ripristino dei servizi, è necessario applicare controlli di sicurezza stringenti per prevenire il ripresentarsi del medesimo incidente:

• Hardening del sistema operativo e delle applicazioni: Installare tempestivamente le patch di sicurezza per il sistema operativo, i runtime e i moduli applicativi. Rimuovere i pacchetti inutilizzati.
• Segregazione delle interfacce di rete: Limitare il binding dei servizi interni (es. database) sull'interfaccia di loopback locale (127.0.0.1).
• Controllo degli accessi ed eliminazione delle password: Abilitare esclusivamente l'autenticazione SSH tramite chiavi cifrate, disabilitando il login diretto per l'utente root e l'autenticazione via password.
• Implementazione di un Firewall Perimetrale: Applicare regole di filtraggio perimetrale per chiudere tutte le porte non strettamente necessarie. Per i dettagli operativi, fa' riferimento alla nostra guida su come configurare un firewall sul tuo server.
• Isolamento dei progetti applicativi: Separare gli ambienti di staging, test e produzione utilizzando container separati o utenti di sistema dedicati.

FAQ

È sufficiente eliminare i file malevoli rilevati per considerare il server sicuro? No. I file identificati costituiscono spesso solo la componente visibile dell'attacco. Gli attaccanti possono aver installato backdoor aggiuntive, task di Cron o modificato utenze di sistema per riottenere l'accesso in seguito.

È indispensabile spegnere immediatamente il server compromesso? Se il server sta effettuando attacchi outbound, esfiltrando dati o inviando spam, occorre isolarlo immediatamente dalla rete. Se possibile, è opportuno effettuare prima uno snapshot della memoria e del disco per l'analisi forense.

I backup esistenti sono sempre utilizzabili per il ripristino? Non automaticamente. Se il backup è stato creato quando la vulnerabilità o la backdoor erano già presenti sul server, il ripristino reprodurrà la medesima falla di sicurezza. Occorre selezionare un punto di ripristino precedente all'intrusione ed applicare le opportune patch prima della rimessa in produzione.

Quando è necessario notificare un incidente di sicurezza agli utenti? Qualora sussista il ragionevole dubbio che l'intrusione abbia comportato l'accesso o l'esfiltrazione di dati personali, credenziali o dati di pagamento degli utenti, la normativa vigente (es. GDPR) impone la notifica tempestiva agli interessati e alle autorità di controllo preposte.

La soluzione intermedia

Server Manager offre un quadro visivo e centralizzato dell'intera infrastruttura, consentendo di monitorare in tempo reale i servizi attivi, i container applicativi, i certificati e i domini associati.

In caso di incidenti di sicurezza, la visibilità centralizzata offerta da una dashboard di gestione facilita l'individuazione di disallineamenti di configurazione, la presenza di porte aperte non necessarie o l'esistenza di ambienti di test non segregati, velocizzando le operazioni di analisi e bonifica.

La procedura di gestione dell'incidente si considera conclusa quando il server viene ricostruito a partire da un ambiente privo di compromissioni, la causa radice della vulnerabilità è stata eliminata, le credenziali sono state ruotate e l'infrastruttura è protetta da regole di firewalling e meccanismi di monitoraggio attivo.

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:

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:

1. 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.

2. 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).

3. 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.

4. 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.

Anche dopo aver configurato un certificato SSL/TLS sul web server, possono sorgere dubbi sulla corretta fruizione del sito da parte degli utenti esterni: i visitatori visualizzeranno l'icona del lucchetto o un avviso di sicurezza lato browser?

In breve: Per verificare che un certificato SSL/TLS funzioni correttamente, è necessario testare il nome di dominio pubblico dall'esterno dell'infrastruttura, utilizzando sia un browser in modalità incognito che strumenti di analisi remota come SSL Labs. La validazione si articola su quattro controlli essenziali: la validità della catena di certificazione, la corrispondenza esatta tra l'Hostname e il Common Name (o Subject Alternative Name), la data di scadenza e la raggiungibilità della porta 443 da parte dei client esterni.

La verifica di un certificato SSL/TLS non deve basarsi unicamente sullo stato dei servizi locali del server, ma su ciò che viene effettivamente negoziato dal client durante il TLS Handshake.

Perché effettuare la verifica del protocollo HTTPS dall'esterno della rete?

Interrogare lo stato del web server dall'interno dell'host (ad esempio tramite curl su 127.0.0.1) non garantisce che i client remoti riescano a instaurare una connessione cifrata corretta.

Il corretto funzionamento del protocollo HTTPS dipende dall'allineamento di molteplici elementi dell'infrastruttura di rete:

• Risoluzione DNS: Il record DNS A/AAAA deve instradare il traffico verso l'indirizzo IP pubblico corretto.
• Accessibilità di rete: Il server deve accettare le connessioni sulla porta 443 (HTTPS) attraverso il Cloud Firewall e il Server Firewall locale.
• Integrità del certificato: Il certificato SSL/TLS deve essere valido e non superare la data di scadenza.
• Corrispondenza dell'Hostname: Il certificato deve includere espressamente il nome di dominio visitato nel campo Common Name (CN) o tra i Subject Alternative Names (SAN).
• Catena di Certificazione (Certificate Chain): Il browser deve poter ricostruire la catena di fiducia dall'entità finale (End-Entity Certificate) fino alla Certification Authority (CA) Radice tramite i certificati intermedi (Intermediate Certificates).

La presenza di un disallineamento anche in uno solo di questi componenti compromette la fruizione dell'applicazione web per l'utente finale.

Per le fasi propedeutiche di configurazione, fa' riferimento alle nostre guide su come collegare un dominio al tuo server e su come ottenere HTTPS gratis sul tuo server.

Procedura operativa per la verifica del certificato SSL/TLS

Per effettuare una verifica completa, occorre simulare il percorso di connessione di un utente esterno:

1. Test tramite Browser in modalità Incognito:

Accedere all'URL pubblico https://yourdomain.com da una finestra privata o da un endpoint esterno alla rete locale (es. da rete mobile) per evitare l'interferenza della cache del browser o del resolver DNS locale. Cliccando sull'icona di sicurezza accanto alla barra degli indirizzi, ispezionare i dettagli del certificato per confermarne la validità, l'emittente e la finestra temporale.

2. Analisi mediante Tool di Scansione Esterni:

Utilizzare uno strumento di analisi approfondita come Qualys SSL Labs (SSL Server Test). Inserire il Fully Qualified Domain Name (FQDN) per eseguire un'ispezione completa delle suite di cifratura (Cipher Suites), della versione del protocollo (TLS 1.2, TLS 1.3), dell'eventuale presenza di certificati intermedi mancanti (Incomplete Chain) e delle vulnerabilità note del server.

3. Verifica analitica per ciascun Hostname e Sottodominio:

Il test va ripetuto esplicitamente per ogni FQDN associato al servizio:

• example.com - www.example.com - subdomain.example.com

I certificati SSL standard coprono esclusivamente l'Hostname per il quale sono stati emessi; la copertura di più sottodomini richiede un certificato Multi-Domain (SAN) o un certificato Wildcard (*.example.com).

Diagnosi degli errori HTTPS e codici del browser

Gli avvisi generati dai browser indicano cause precise di malfunzionamento durante la negoziazione TLS:

• NET::ERR_CERT_DATE_INVALID: Il certificato è scaduto o non è ancora entrato nella finestra di validità. Indica solitamente il fallimento del processo di rinnovo automatico del certificato (es. via Certbot).
• NET::ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN: L'Hostname inserito nella barra degli indirizzi non corrisponde ad alcun nome (CN o SAN) presente nel certificato presentato dal server.
• Your connection is not private (La connessione non è privata): Errore generico che segnala l'impossibilità di validare la catena di fiducia, la presenza di un certificato Self-Signed non riconosciuto o un'incompatibilità nel protocollo TLS.

Se la connessione restituisce un timeout invece di un avviso sul certificato, l'anomalia è solitamente imputabile a regole di firewalling o al mancato binding del web server sulla porta 443. Consulta la guida su perché il mio sito non si carica per l'analisi dei diversi livelli di rete.

Cause di discrepanza nella validazione (Funzionamento asimmetrico)

Se il sito web risulta accessibile tramite HTTPS ad alcuni utenti ma restituisce errori ad altri, le cause principali includono:

• Propagazione e Caching DNS: Presenza di record DNS obsoleti memorizzati nei resolver locali di alcuni client, che indirizzano il traffico verso un server non aggiornato o dismesso.
• Configurazione parziale degli Hostname: Assenza del certificato per una specifica variante del dominio (ad esempio, presenza del certificato per example.com ma assenza per www.example.com).
• Conflitti Server Name Indication (SNI): Errore nella gestione del Virtual Hosting sul web server (NGINX, Apache) quando più domini condividono il medesimo indirizzo IP pubblico. In assenza di una corretta mappatura SNI, il server può presentare il certificato del dominio predefinito anziché quello richiesto dal client. Per approfondire la gestione di più applicazioni, consulta la guida su come ospitare più siti web su un server.

FAQ

Qual è la differenza tra SSL e TLS? SSL (Secure Sockets Layer) è il protocollo di cifratura oramai obsoleto e deprecato. TLS (Transport Layer Security) è il suo successore moderno. Il termine "certificato SSL" rimane in uso commerciale, ma le connessioni cifrate attuali utilizzano le specifiche TLS 1.2 o TLS 1.3.

La verifica HTTPS deve essere effettuata sull'indirizzo IP o sul nome di dominio? Esclusivamente sul nome di dominio (FQDN). I certificati di cifratura pubblicamente riconosciuti vengono emessi e convalidati per nomi di dominio e non per indirizzi IP individuali.

La presenza del lucchetto nel browser garantisce l'assenza di altri problemi? Garantisce che il canale di comunicazione attuale è cifrato e che il certificato è valido per quel specifico FQDN. È comunque opportuno verificare la scadenza temporale e la corretta configurazione di tutti i sottodomini o reindirizzamenti.

Con quale frequenza è consigliabile testare i certificati SSL/TLS? La verifica va effettuata a seguito di modifiche ai record DNS, migrazioni di hosting, aggiornamenti delle configurazioni del web server e prima dei rilasci in produzione, verificando periodicamente il corretto funzionamento dei job di rinnovo automatico.

La soluzione intermedia

Server Manager centralizza il tracciamento dei certificati SSL/TLS, la gestione dei domini e l'associazione dei Virtual Host in una singola interfaccia.

L'adozione di una dashboard di controllo elimina le incertezze legate alle scadenze dei certificati, previene gli errori di configurazione del protocollo SNI e garantisce visibilità immediata sul livello di sicurezza applicato a ciascun dominio ospitato.

La configurazione del protocollo HTTPS si considera corretta quando le chiamate dirette all'Hostname pubblico completano il TLS Handshake senza avvisi, il certificato copre tutti i domini gestiti, la catena di certificazione è completa e i test esterni confermano la validità della configurazione.

L'analisi dei log di autenticazione del sistema operativo (/var/log/auth.log o journalctl) rivela spesso un volume elevato e costante di tentativi di accesso non autorizzati tramite SSH, generati da botnet e scanner automatici distribuiti su scala globale.

In breve: L'implementazione di fail2ban consente di mitigare gli attacchi automatizzati tramite l'analisi in tempo reale dei log di sistema. L'infrastruttura di fail2ban individua i pattern di fallimento ripetuto delle credenziali e applica dinamicamente regole di filtraggio sul firewall del server (tramite iptables o nftables), bloccando temporaneamente o permanentemente gli indirizzi IP sorgente responsabile degli attacchi.

Architettura e principio di funzionamento di Fail2ban

Fail2ban è un servizio di prevenzione delle intrusioni (Host-based Intrusion Prevention System - HIPS) che opera monitorando i log delle applicazioni esposte in rete (come SSH, web server, server FTP e database).

In una configurazione di sicurezza standard:

• Il Firewall definisce quali porte di rete sono aperte o chiuse all'esterno.
• Fail2ban analizza il comportamento del traffico autorizzato in ingresso. Se un host remoto supera la soglia tollerabile di errori di autenticazione, Fail2ban istruisce il firewall di sistema affinché scarti (DROP) i pacchetti provenienti da quell'indirizzo IP.

Questa tipologia di attacco, definita Brute-Force, tenta di indovinare le credenziali di accesso tramite dizionari automatizzati. L'impiego di Fail2ban riduce drasticamente il carico computazionale e il traffico di rete generato da questi attacchi.

Fail2ban costituisce un livello di protezione integrativo e non sostituisce l'adozione di chiavi SSH, la disattivazione dell'accesso via password per l'utente root, l'applicazione periodica delle patch di sicurezza o la corretta configurazione del firewall perimetrale. Per le impostazioni di base della rete, consulta la nostra guida su come configurare un firewall sul tuo server.

Guida alla configurazione di Fail2ban per il servizio SSH

Sulle distribuzioni basate su Debian o Ubuntu, l'installazione del servizio si esegue tramite il gestore pacchetti:

bashsudo apt update
sudo apt install fail2ban