Gli attacchi brute force sono tra le minacce più comuni contro i server esposti su Internet. Sono generalmente automatizzati, persistenti ed economici da eseguire. Un attaccante non deve conoscere molto di un’azienda prima di testare un demone SSH, un endpoint RDP, un pannello di controllo, un database o un’interfaccia di amministrazione remota con migliaia di credenziali rubate o indovinate.
Molti tentativi falliscono e nell’immediato creano pochi rischi. Il pericolo è che uno abbia successo, soprattutto quando una password è stata riutilizzata, un vecchio account è ancora attivo o un servizio è esposto senza autenticazione a più fattori. I ripetuti errori di accesso dovrebbero quindi essere considerati dati utili per la sicurezza, non semplice rumore di fondo proveniente da Internet.
Questa guida spiega come riconoscere gli attacchi brute force ai server, quali controlli possono ridurli, dove le strategie di blocco possono fallire e cosa fare quando un attaccante riesce a entrare.
Come si presenta un attacco brute force a un server
Un attacco brute force è un tentativo di ottenere l’accesso provando molte password, nomi utente o combinazioni di credenziali. Le campagne moderne utilizzano spesso il credential stuffing invece di tentativi casuali: l’attaccante verifica coppie di nome utente e password raccolte da precedenti violazioni. Il password spraying segue un approccio diverso, provando una password comune su molti account e aiutando l’attaccante a evitare i blocchi applicati ai singoli account.
SSH e RDP sono obiettivi frequenti perché forniscono accesso amministrativo diretto. Anche altri servizi esposti possono essere altrettanto importanti:
- Pannelli di hosting web e di controllo dei server
- Gateway VPN e portali di accesso remoto
- Interfacce di amministrazione della posta e webmail
- Listener di database come MySQL, PostgreSQL o Microsoft SQL Server
- Pagine di accesso delle applicazioni ed endpoint API
- Console di virtualizzazione, backup e monitoraggio
L’attività può provenire da un singolo indirizzo, da un elenco variabile di server cloud o da un’ampia gamma di indirizzi IP. Un attacco distribuito può produrre solo pochi tentativi per indirizzo, generando però un numero complessivo elevato di errori. Per questo, osservare una singola regola del firewall o il log di un solo server è spesso insufficiente.
Come rilevare i tentativi di accesso automatizzati
Inizia dai log di autenticazione
I log di autenticazione sono il primo punto da esaminare. Su Linux, gli eventi SSH compaiono generalmente nel journal di sistema o nel log di autenticazione. Gli amministratori Windows dovrebbero controllare gli eventi RDP e gli altri eventi pertinenti nel Visualizzatore eventi o in una piattaforma centralizzata di logging Windows. I pannelli di controllo, i prodotti VPN e i database gestiscono generalmente i propri log di audit.
Cerca degli schemi ricorrenti invece di eventi isolati:
- Decine o centinaia di accessi non riusciti in un breve periodo
- Tentativi contro numerosi nomi utente, compresi nomi inesistenti
- Tentativi ripetuti contro account privilegiati come root, amministratore o account di servizio
- Connessioni che arrivano a intervalli regolari da indirizzi variabili
- Autenticazione riuscita subito dopo una lunga sequenza di errori
- Accessi in orari insoliti, da Paesi insoliti o attraverso reti sconosciute
- Nuovi account, password modificate, chiavi SSH cambiate o appartenenza ai gruppi alterata
Un singolo accesso non riuscito non costituisce un incidente. Uno schema di errori su più sistemi, soprattutto se seguito da un accesso riuscito, merita un’indagine. I team che valutano strumenti di rilevamento e blocco possono confrontare gli approcci usando queste risorse sul rilevamento del brute force ai server e su Fail2ban, ma dovrebbero convalidare qualsiasi strumento nel proprio ambiente prima di attivare i blocchi automatici.
Usa gli avvisi e i segnali del traffico
La raccolta dei log è utile solo se qualcuno, o qualcosa, li esamina. Gli avvisi possono basarsi su soglie, come dieci accessi SSH falliti in cinque minuti, ma le regole basate esclusivamente sulle soglie possono non rilevare un password spraying lento. Un monitoraggio migliore combina gli eventi di autenticazione con indirizzi di origine, nomi utente, geolocalizzazione, criticità delle risorse e accessi riusciti.
I dati telemetrici di rete possono aggiungere contesto. Controlla l’aumento improvviso dei tentativi di connessione alle porte di gestione, i ripetuti handshake TCP che non vengono mai completati, le scansioni su più servizi o il traffico in uscita insolito dopo un accesso sospetto. Un server compromesso potrebbe iniziare a connettersi a infrastrutture di comando e controllo, scansionare i sistemi interni o trasferire dati.
Il monitoraggio centralizzato è particolarmente importante per le agenzie che gestiscono diversi ambienti dei clienti. Un’unica dashboard o una piattaforma SIEM facilita l’individuazione dello stesso intervallo IP, dello stesso schema di nomi utente o della stessa campagna di password spraying su più server. Gli avvisi dovrebbero raggiungere una persona in grado di intervenire e contenere dettagli sufficienti a evitare che i responsabili debbano cercare nei log grezzi durante un incidente.
Proteggere SSH e gli altri servizi esposti
Usa un’autenticazione robusta
Quando possibile, disabilita l’autenticazione SSH tramite password e richiedi chiavi crittografiche individuali. Ogni amministratore dovrebbe avere un account e una chiave separati, ottenendo l’accesso privilegiato tramite un’elevazione controllata invece di usare credenziali root condivise. Proteggi le chiavi private con passphrase e conservale in modo sicuro. Rimuovi tempestivamente le chiavi quando un dipendente o un fornitore non ha più bisogno di accedere.
Per RDP, VPN e pannelli di controllo, usa l’MFA quando il prodotto la supporta. Quando disponibile, preferisci metodi resistenti al phishing, soprattutto per gli account amministrativi. L’MFA non rende innocuo un servizio vulnerabile, ma riduce significativamente il valore di una password rubata.
Le policy sulle password restano importanti per i servizi che le richiedono. Usa credenziali lunghe e uniche, un password manager e account separati per amministrazione, applicazioni e database. Non lasciare mai attive le credenziali predefinite del fornitore. Disabilita gli account inattivi e verifica che gli account di servizio non dispongano di accesso interattivo non necessario.
Riduci l’esposizione
L’interfaccia di gestione più sicura è quella non raggiungibile pubblicamente. Quando possibile dal punto di vista operativo, limita l’accesso a SSH, RDP e ai database a una VPN, a una rete privata, a un bastion host o a intervalli IP amministrativi definiti. In genere, un listener di database non ha alcun motivo per accettare connessioni dalla rete Internet pubblica.
Cambiare la porta SSH predefinita può ridurre le scansioni opportunistiche, ma non è di per sé un controllo di sicurezza. Gli attaccanti possono scoprire rapidamente le porte non standard. Consideralo una riduzione del rumore, non una protezione. I controlli più efficaci sono la restrizione di rete, l’autenticazione moderna, l’applicazione delle patch e il monitoraggio.
Applica gli aggiornamenti di sicurezza ai sistemi operativi, ai pannelli di controllo, alle VPN e alle applicazioni. Rimuovi i servizi non più necessari e verifica che le interfacce amministrative non siano state esposte accidentalmente dopo migrazioni o modifiche al firewall. Proteggi l’host secondo una baseline documentata e riesaminala periodicamente, invece di presumere che una configurazione eseguita una sola volta rimanga corretta.
Tecniche di blocco e limitazione della velocità
Firewall e filtri a livello di provider
I firewall dell’host possono limitare le porte di gestione, restringere le reti di origine e rifiutare il traffico prima che raggiunga l’applicazione. I firewall di rete o i filtri a livello di provider possono assorbire o scartare il traffico indesiderato prima, cosa utile quando un attacco genera un numero di connessioni sufficiente a consumare le risorse del server.
I controlli a livello di provider non sostituiscono gli account sicuri. Possono inoltre essere meno precisi dei controlli consapevoli dell’applicazione, soprattutto quando molti clienti legittimi condividono un intervallo di indirizzi. Definisci le reti amministrative autorizzate e mantieni un percorso di accesso di emergenza, così una regola errata non bloccherà le persone responsabili della risoluzione del problema.
Blocco in stile Fail2ban
Strumenti come Fail2ban controllano i log e aggiungono regole temporanee al firewall dopo un numero definito di errori. Sono pratici per SSH e per altri servizi con formati di log coerenti. Il periodo di blocco, la soglia degli errori e l’elenco degli indirizzi esclusi dovrebbero essere scelti in base al comportamento osservato, non copiati senza una verifica.
I blocchi temporanei offrono generalmente un equilibrio migliore rispetto ai blocchi permanenti. Rallentano i tentativi ripetuti, riducono il rumore nei log e danno agli amministratori il tempo di intervenire senza creare una denylist in continua espansione. Assicurati che lo strumento di monitoraggio continui a funzionare dopo la rotazione dei log, il riavvio dei servizi e le modifiche al sistema di autenticazione.
Limitazione della velocità e controlli sugli account
La limitazione della velocità può essere implementata in un reverse proxy, nel firewall, nell’applicazione o nel provider di identità. È particolarmente utile per le pagine di accesso web e le API, dove un servizio deve rimanere pubblicamente disponibile. Ritardi progressivi, CAPTCHA e MFA basata sul rischio possono ridurre l’automazione senza negare l’accesso a ogni utente dopo un solo errore.
Il blocco degli account richiede maggiore attenzione. Un blocco rigido può fermare i tentativi contro un account, ma un attaccante può bloccare deliberatamente ogni dipendente durante una campagna di password spraying. Preferisci blocchi brevi e progressivi o la limitazione della velocità, e crea una procedura di recupero amministrativo verificata. Non considerare mai una policy di blocco l’unica difesa per un account privilegiato.
Compromessi e punti ciechi comuni
Il blocco degli IP è facile da comprendere, ma presenta dei limiti. Gli indirizzi possono essere condivisi da uffici, reti mobili, piattaforme cloud o sistemi NAT di livello carrier. Bloccare un intero intervallo può colpire utenti legittimi, mentre bloccare singoli indirizzi può avere un effetto minimo contro una campagna distribuita. Anche le regole basate sulla geolocalizzazione possono generare falsi positivi per il personale in viaggio e i fornitori remoti.
I falsi positivi sono più di un semplice inconveniente. Un sistema di monitoraggio, un operatore dei backup o un amministratore di emergenza bloccato può ritardare il ripristino. Mantieni, quando appropriato, un allowlist per i percorsi di gestione affidabili, ma proteggilo con attenzione e riesaminalo regolarmente. Non inserire in allowlist un ampio intervallo dinamico solo perché in passato era associato a un utente legittimo.
Gli attacchi distribuiti richiedono controlli incentrati sull’identità. Se lo stesso account è preso di mira da molte reti, il blocco delle origini non risolverà il problema. MFA robusta, credenziali uniche, autenticazione tramite password disabilitata e rilevamento centralizzato sono risposte più durature. Cerca schemi basati su nome utente, dispositivo, applicazione e tempistiche, oltre che sull’indirizzo IP.
Come indagare su un attacco sospetto
Inizia preservando le prove. Registra l’host interessato, il fuso orario, le voci di log pertinenti, gli indirizzi di origine, gli account presi di mira e gli eventuali blocchi automatici già applicati. Esporta i log prima che vengano sovrascritti. Evita di riavviare o ripulire prematuramente il server se esiste una possibilità concreta di compromissione: le prove volatili e le connessioni attive potrebbero essere importanti.
Successivamente, stabilisci se l’attività non ha avuto successo o se un account è stato utilizzato. Cerca gli accessi riusciti in prossimità dei tentativi falliti e verifica origine, metodo di autenticazione e orario. Controlla poi:
- Nuovi account locali o di dominio e appartenenze ai gruppi inattese
- Nuove chiavi autorizzate SSH, attività pianificate, cron job o voci di avvio
- Modifiche alle regole del firewall, alle impostazioni di accesso remoto o alle policy di sicurezza
- Processi, porte in ascolto e connessioni in uscita inattesi
- File web, binari, script e file di configurazione modificati
- Accessi ai dati, download, upload o escalation dei privilegi insoliti
Confronta l’host con una configurazione o uno standard di build noto e affidabile. Esamina i log del provider di identità, della VPN, del firewall, degli endpoint e del cloud, oltre a quelli del server. Ruota le credenziali e revoca le sessioni quando esiste un ragionevole sospetto che siano state esposte. Se il sistema gestisce dati soggetti a normative, informazioni sui clienti o operazioni critiche, segui la procedura di gestione degli incidenti dell’organizzazione e valuta gli obblighi di notifica legali, normativi e contrattuali.
Bloccare un tentativo non significa rispondere a una compromissione
Una regola del firewall o un blocco Fail2ban gestisce una connessione osservata. Non rimuove un attaccante che si è già autenticato. Un accesso riuscito trasforma il traffico molesto in un potenziale incidente di sicurezza.
Quando si sospetta una compromissione, isola il server dalla rete preservando le prove necessarie e mantenendo un percorso di gestione controllato. Non limitarti a eliminare un account sospetto e a riportare l’host online. Un attaccante potrebbe aver creato meccanismi di persistenza, rubato credenziali o modificato binari. La risposta più sicura consiste nel determinare l’ambito dell’incidente, ricostruire il sistema da una fonte affidabile quando opportuno, correggere la vulnerabilità originaria, ruotare i segreti e monitorare attentamente i servizi ripristinati.
Il ripristino dipende anche dalla disponibilità di backup integri e utilizzabili. I backup dovrebbero essere isolati dalle normali credenziali e dal piano di gestione del server, perché un attaccante con accesso amministrativo potrebbe tentare di eliminarli o cifrarli. Safenix offre backup off-site per i server aziendali controllati dal cliente. I dati sono cifrati con una chiave che Safenix non possiede, archiviati in Germania e mantenuti immutabili per la durata del periodo di conservazione selezionato. Questo è un controllo di ripristino, non un sostituto della messa in sicurezza o della risposta agli incidenti: il cliente rimane responsabile del controllo del server protetto e delle decisioni relative al ripristino.
Ambienti VPS, server dedicati e hosting condiviso
I controlli disponibili dipendono fortemente da chi controlla il sistema operativo e il confine di rete. Un VPS normalmente gestito dal cliente offre accesso al sistema operativo, al firewall e alla configurazione dei servizi. Ciò consente all’amministratore di imporre l’uso di chiavi SSH, disabilitare l’accesso tramite password, installare il monitoraggio dell’host e limitare il traffico di gestione, nel rispetto dei limiti della piattaforma del provider.
Un server dedicato offre generalmente un controllo più diretto sull’host, sulla progettazione della rete e sulla separazione dei carichi di lavoro, anche se le responsabilità esatte dipendono ancora dal contratto e dal modello di gestione. Un server gestito può limitare alcune modifiche fornendo al contempo supporto operativo. Documenta questa divisione delle responsabilità prima che si verifichi un incidente.
L’hosting condiviso è diverso. Il provider controlla l’host, il sistema operativo, la configurazione del server web e il confine di sicurezza tra i clienti. I clienti possono modificare le impostazioni dell’applicazione, ma generalmente non possono installare Fail2ban, modificare le regole del firewall dell’host, disabilitare SSH per la piattaforma o ispezionare tutti i log di autenticazione. Le indicazioni sui controlli di sicurezza nell’infrastruttura VPS gestita dal cliente rispetto all’hosting condiviso devono quindi essere lette tenendo conto dell’accesso effettivamente fornito.
Safenix protegge i server controllati dal cliente. Non vende un piano di backup per un sito web che funziona su hosting condiviso, e un sito su hosting condiviso non dovrebbe essere presentato come se fosse coperto da un servizio di backup server Safenix. Per l’hosting condiviso, il cliente deve utilizzare le opzioni di backup ed esportazione disponibili presso l’host oppure spostare il carico di lavoro su un’infrastruttura in cui l’organizzazione disponga del controllo necessario.
Una procedura operativa pratica
La difesa dagli attacchi brute force funziona meglio come procedura operativa, non come singola impostazione. Come minimo, esamina regolarmente i servizi esposti e gli account privilegiati. Verifica gli avvisi con simulazioni autorizzate, conferma che i blocchi scadano come previsto e assicurati che gli amministratori possano ancora raggiungere un percorso di accesso di emergenza.
- Mantieni un inventario dei servizi esposti su Internet, dei responsabili e delle reti di gestione autorizzate.
- Esamina le tendenze degli accessi riusciti e non riusciti, non solo l’ultimo avviso.
- Usa chiavi SSH, MFA, account unici e privilegi minimi per l’amministrazione.
- Applica le patch ai sistemi operativi e alle applicazioni esposte e rimuovi i servizi non necessari.
- Centralizza i log e fai in modo che gli avvisi siano utilizzabili dal team responsabile della risposta.
- Verifica il ripristino dei backup e conferma che i dati di recupero siano isolati dalle credenziali del server.
- Documenta i contatti per l’escalation, le procedure di conservazione delle prove e i processi di ricostruzione.
Gli attacchi automatizzati continueranno a sondare i servizi esposti, ma non devono trasformarsi in una crisi. Riduci prima l’esposizione, rendi l’autenticazione difficile da abusare, usa il blocco come livello ponderato e monitora i segnali che indicano che un tentativo si è trasformato in un accesso riuscito. Quando il confine viene superato, passa senza indugio dal blocco alla risposta agli incidenti e al ripristino.