Perché la sicurezza SSH richiede un approccio strutturato
SSH rimane uno degli strumenti più importanti per amministrare server Linux e Unix. È anche una delle vie più interessanti per un attaccante. Una chiave privata rubata, una password esposta, un servizio SSH senza patch o un account amministratore con privilegi eccessivi possono fornire un accesso diretto ai sistemi sensibili.
L’accesso sicuro ai server non si ottiene modificando una sola impostazione in sshd_config. Il rafforzamento di SSH funziona quando identità, accesso di rete, autorizzazioni del sistema operativo, monitoraggio e controlli di ripristino si supportano a vicenda. Una chiave robusta è utile, ma non compensa una chiave lasciata su un laptop non gestito. Una lista di indirizzi IP consentiti riduce l’esposizione, ma non impedisce l’uso improprio da una rete approvata.
L’obiettivo è rendere difficile l’accesso non autorizzato, limitare ciò che un account compromesso può fare, rilevare rapidamente le attività sospette e conservare un percorso sicuro per l’amministrazione legittima durante un incidente.
Inizia dalle due modifiche SSH più importanti
Disabilita l’accesso diretto a root
L’accesso diretto a root rende più difficile attribuire le responsabilità e contenere un incidente. Ogni amministratore appare come lo stesso utente e un accesso riuscito dispone immediatamente di privilegi illimitati. Imposta PermitRootLogin no quando è compatibile con le esigenze operative, quindi richiedi agli amministratori di collegarsi con account nominativi e di usare sudo per le azioni privilegiate.
Possono esistere eccezioni per procedure di ripristino progettate con attenzione, ma devono essere deliberate e non costituire l’impostazione predefinita. Se una piattaforma richiede un percorso di emergenza con privilegi root, proteggilo con una chiave separata, una rete di origine limitata, un monitoraggio rigoroso e un processo di approvazione documentato.
Disabilita l’autenticazione tramite password
L’autenticazione tramite password è esposta a tentativi di indovinare le credenziali, credential stuffing, phishing e riutilizzo delle password. Sui server che lo supportano, disabilitala con PasswordAuthentication no dopo aver verificato che l’accesso approvato tramite chiave funzioni. Esamina anche le impostazioni correlate, come l’autenticazione keyboard-interactive, perché alcune configurazioni possono ancora consentire un accesso simile a quello tramite password attraverso questo metodo.
Non apportare questa modifica senza testare una sessione amministrativa attiva e una nuova sessione separata. Un errore operativo comune consiste nel chiudere l’unica connessione funzionante prima di aver verificato il metodo di accesso sostitutivo. Mantieni disponibile una console controllata o un percorso di ripristino fuori banda per le modifiche che potrebbero bloccare l’accesso al team.
Usa correttamente una solida autenticazione a chiave pubblica
L’autenticazione a chiave pubblica è generalmente più sicura e gestibile delle password, ma la sicurezza del sistema dipende da entrambe le parti della coppia di chiavi. La chiave pubblica deve essere inserita nella configurazione delle chiavi autorizzate del server. La chiave privata deve rimanere segreta e non dovrebbe mai essere copiata in ticket, script, unità condivise o messaggi di chat.
Preferisci i tipi di chiave moderni supportati dal sistema operativo e dalla versione di OpenSSH in uso. Le chiavi di sicurezza con protezione hardware possono offrire una protezione particolarmente forte, perché l’operazione sulla chiave privata avviene sul dispositivo e la chiave è più difficile da estrarre. Quando le chiavi con protezione hardware non sono praticabili, usa una passphrase robusta e archivia le chiavi private in un archivio di chiavi crittografato del sistema operativo o in un sistema affidabile di gestione dei segreti.
Ogni amministratore dovrebbe avere una chiave individuale, invece di condividere una chiave del team. Le chiavi individuali permettono di identificare la persona responsabile di una connessione, rimuovere l’accesso di una persona senza influire su tutti gli altri e verificare l’età e lo scopo di ogni credenziale. Il commento associato a una chiave pubblica non è un controllo di sicurezza, ma commenti utili possono chiarire la titolarità e le date di scadenza durante un audit.
Proteggi la chiave privata
Una chiave privata senza passphrase equivale di fatto a una credenziale riutilizzabile basata sul possesso. Se un laptop viene rubato o un malware legge il file della chiave, un attaccante potrebbe collegarsi immediatamente. Usa una passphrase robusta e univoca e carica le chiavi in un agent solo per il tempo necessario. Proteggi la workstation con la crittografia completa del disco, il blocco dello schermo, gli aggiornamenti supportati del sistema operativo e la protezione degli endpoint.
Limita i permessi sui file delle chiavi private. Sui sistemi Unix-like, una chiave dovrebbe normalmente essere leggibile solo dal proprietario. I backup delle chiavi private richiedono la stessa cura degli originali: una copia non crittografata in un repository di backup vanifica la protezione del dispositivo di lavoro. Quando un amministratore lascia l’organizzazione, perde un dispositivo o sospetta una compromissione, considera la chiave privata compromessa finché non viene revocata o rimossa da ogni server autorizzato.
Applica il principio del privilegio minimo e separa le identità amministrative
L’accesso SSH dovrebbe garantire solo l’autorità minima necessaria per il ruolo di una persona. Uno sviluppatore web potrebbe dover consultare i log dell’applicazione e riavviare un servizio, mentre un ingegnere dei sistemi potrebbe aver bisogno di privilegi più ampi sul sistema operativo. Queste responsabilità non dovrebbero tradursi automaticamente in un accesso root senza restrizioni.
Usa account nominativi e regole sudo controllate per concedere comandi specifici quando possibile. Verifica se i comandi possono essere combinati per eludere le restrizioni. Ad esempio, il permesso di eseguire come root un editor, un interprete o un’utilità di backup potrebbe fornire di fatto un accesso illimitato. Un’architettura basata sul privilegio minimo deve considerare l’impatto pratico di ogni comando consentito, non solo il suo nome.
Separa l’amministrazione quotidiana dalle attività ad alto rischio. Un amministratore può usare un account standard per email, navigazione e attività ordinarie, quindi utilizzare un account privilegiato distinto solo quando necessario. Questo riduce la possibilità che un attacco di phishing o la compromissione del browser acquisisca immediatamente i diritti di amministrazione del server. Inoltre, crea log più chiari e rende più semplice esaminare le attività privilegiate.
Gli account di servizio non dovrebbero essere usati per l’amministrazione interattiva. Assegna all’automazione una propria identità, chiave e autorizzazioni e limitala agli host e ai comandi necessari. Un account di distribuzione non dovrebbe essere anche l’account utilizzato per la manutenzione del database o il ripristino di emergenza.
Scegli il secondo fattore e il perimetro di rete più adatti
MFA per SSH
L’autenticazione a più fattori può ridurre l’impatto di una chiave privata rubata, soprattutto quando il secondo fattore è indipendente dalla workstation dell’amministratore. Gli approcci comuni includono l’integrazione di SSH con un sistema di password monouso, una richiesta basata su PAM, un provider centralizzato di identità o un bastion host che impone l’MFA prima di consentire l’accesso ai sistemi successivi.
La progettazione dell’MFA comporta compromessi. Un codice monouso generato sullo stesso laptop compromesso che contiene la chiave SSH può offrire meno protezione di un token hardware separato. Un servizio di autenticazione centralizzato può migliorare il controllo, ma introduce una dipendenza che deve essere monitorata e supportata durante un’interruzione. Alcune automazioni non possono completare una richiesta MFA interattiva, quindi i processi non interattivi richiedono un’architettura diversa, non un bypass MFA permanente su un account potente.
Quando supportate, le chiavi di sicurezza SSH FIDO2 o simili con protezione hardware possono offrire una forte resistenza al phishing. Testa la compatibilità con il client scelto, il sistema operativo e il processo di ripristino prima di renderle obbligatorie. Mantieni una procedura controllata per sostituire un token perso senza lasciare una backdoor permanente nascosta.
Liste di indirizzi IP consentiti, VPN e bastion host
Limitare SSH a indirizzi IP di origine conosciuti può ridurre le scansioni e gli attacchi opportunistici. Un firewall, un security group o una lista di controllo degli accessi di rete può consentire la porta 22 solo da un intervallo dell’ufficio, una rete di gestione o una VPN. È utile, ma non offre una protezione completa: le reti approvate possono essere compromesse, gli indirizzi possono cambiare e un attaccante potrebbe trovarsi già all’interno dell’ambiente autorizzato.
Una VPN crea un perimetro amministrativo separato e può semplificare la gestione delle regole del firewall. Deve comunque essere aggiornata, autenticata in modo robusto e monitorata. Un bastion host, talvolta chiamato jump host, concentra l’accesso amministrativo in un sistema controllato. Può imporre l’MFA, registrare le sessioni e fornire un unico punto per le liste di indirizzi consentiti e il logging. Diventa però anche un bersaglio di grande valore, quindi richiede una configurazione rafforzata, pochi software, patch rapide e un percorso di ripristino testato.
Non esporre ampiamente SSH a Internet solo perché è abilitata l’autenticazione tramite chiave. Allo stesso tempo, non considerare lo spostamento di SSH su un’altra porta una misura di sicurezza. Una porta non standard può ridurre il rumore, ma non sostituisce autenticazione, patch, restrizioni di rete o monitoraggio.
Comprendi i rischi del forwarding dell’agent SSH
Il forwarding dell’agent SSH è comodo quando un amministratore si collega a un server e deve poi raggiungerne un altro senza copiare una chiave privata. L’host remoto può chiedere all’agent locale di eseguire un’operazione di autenticazione. La chiave privata non viene trasferita, ma un server remoto compromesso potrebbe usare l’agent inoltrato mentre la connessione è attiva.
Questo rischio è importante quando ci si collega attraverso server meno affidabili della destinazione. Evita di inoltrare un agent per impostazione predefinita. Usalo solo per un’attività specifica e compresa, valutando invece i vincoli sulla destinazione, chiavi separate o un’architettura con bastion host. Gli amministratori devono sapere quali host possono raggiungere il loro agent e chiudere rapidamente le sessioni inoltrate.
Per l’automazione, preferisci credenziali di breve durata, chiavi di distribuzione con ambito ristretto, identità dei workload o un gestore dei segreti, quando la piattaforma lo supporta. Non inserire mai una chiave privata amministrativa di lunga durata in un repository di codice sorgente o in un’immagine di build. Se una pipeline deve usare SSH, limita la chiave per origine, comando e destinazione quando possibile e genera avvisi in caso di uso imprevisto.
Ruota, revoca e verifica l’accesso in modo consapevole
La rotazione delle chiavi non è solo un’attività annuale da calendario. Crea un inventario con il titolare di ogni chiave, lo scopo, i sistemi, la data di creazione, l’ultimo utilizzo e la scadenza prevista. Rimuovi le chiavi inutilizzate da authorized_keys e dai sistemi centrali di accesso. Una chiave senza un titolare noto deve essere trattata come un rischio di accesso, non come una configurazione storica innocua.
La revoca deve essere praticabile anche sotto pressione. Documenta come rimuovere una chiave dai singoli server, dai sistemi di gestione della configurazione, dai bastion host e dai piani di controllo cloud. Se usi certificati o un’autorità di certificazione SSH centrale, definisci durate brevi e mantieni un processo di revoca affidabile. Verifica che la revoca dell’accesso di un amministratore non rimuova accidentalmente quello necessario al team di risposta agli incidenti.
Esegui una revisione degli accessi dopo cambiamenti nel personale, cambiamenti dei fornitori, grandi progetti infrastrutturali e incidenti di sicurezza. Controlla:
- Accesso diretto a root e impostazioni dell’autenticazione tramite password.
- Account utente sconosciuti, condivisi o inattivi.
- Chiavi pubbliche senza titolare, chiavi obsolete e chiavi senza scadenza o data di revisione.
- Autorizzazioni sudo troppo ampie e comandi consentiti rischiosi.
- Account di servizio che consentono l’accesso interattivo.
- Interfacce in ascolto, regole del firewall o esposizioni SSH pubbliche inattese.
- Appartenenza a VPN, bastion host e MFA, inclusi gli account dormienti.
- Forwarding dell’agent, port forwarding e altre funzionalità SSH non necessarie.
- Copertura dei log, sincronizzazione dell’orologio e conservazione degli eventi di autenticazione.
Per una checklist pratica, confronta la configurazione attuale con le attuali best practice per il rafforzamento dei server SSH, quindi convalida ogni raccomandazione rispetto al tuo modello operativo. Le indicazioni generiche non possono stabilire quali eccezioni di emergenza siano realmente necessarie per la tua azienda.
Aggiorna il servizio e rendi visibili gli accessi sospetti
SSH fa parte del sistema operativo e dovrebbe seguire la stessa disciplina di aggiornamento del resto del server. Applica gli aggiornamenti di sicurezza all’implementazione SSH, al sistema operativo, alle librerie, alla VPN, al bastion host e agli strumenti di gestione. Dai priorità ai sistemi esposti a Internet e definisci come testare e distribuire gli aggiornamenti urgenti senza lasciare irrisolta un’esposizione critica.
Abilita il logging delle connessioni e delle autenticazioni a un livello che supporti le indagini senza creare un rumore ingestibile. Registra gli accessi riusciti e falliti, gli indirizzi di origine, i nomi utente, l’identità della chiave o del certificato quando disponibile, l’escalation dei privilegi e le modifiche alla configurazione dell’autenticazione. Invia i log importanti a un sistema separato, in modo che un attaccante che ottenga l’accesso al server non possa cancellare silenziosamente le prove.
Gli avvisi dovrebbero concentrarsi su segnali utili. Tra gli esempi rientrano ripetuti errori su un account valido, un accesso riuscito da un Paese o una rete insoliti, una nuova chiave pubblica, attività a livello root al di fuori di una finestra di manutenzione, un servizio di logging disabilitato o una modifica improvvisa alle regole del firewall. Gli avvisi devono avere un responsabile e un percorso di escalation; un flusso illeggibile di notifiche di bassa qualità offre poca protezione.
Il rate limiting e gli strumenti che bloccano temporaneamente i tentativi ripetuti possono ridurre il rumore e il consumo di risorse causati dagli attacchi brute force. Possono però anche bloccare utenti legittimi dietro indirizzi condivisi o non riuscire a fermare un attacco lento e distribuito. Usali come un livello aggiuntivo insieme ad autenticazione robusta, controlli di rete, monitoraggio e un processo di risposta testato.
Proteggi l’automazione e l’accesso di emergenza
L’automazione spesso richiede l’accesso SSH senza la presenza di una persona, rendendo particolarmente importante una progettazione rigorosa. Crea un account dedicato per ogni flusso di lavoro significativo. Limita l’ambiente di origine, gli host di destinazione e i comandi consentiti. Archivia la credenziale in un archivio controllato dei segreti o in un runner protetto, limita la sua durata quando possibile e impedisci ai log di build di stampare chiavi private o dettagli delle connessioni.
Verifica se il processo ha davvero bisogno di SSH. Una piattaforma di distribuzione, un sistema di gestione della configurazione o un’API del provider possono offrire autorizzazioni più specifiche e una migliore tracciabilità. Quando SSH è necessario, separa le credenziali di produzione da quelle di sviluppo e richiedi un’approvazione esplicita per le modifiche in produzione.
L’accesso di emergenza dovrebbe essere disponibile, ma raro. Conserva un account documentato di break-glass o un percorso tramite console sotto custodia controllata, con autenticazione robusta, appartenenza limitata e requisiti di approvazione chiari. Monitora ogni utilizzo e analizzalo in seguito. Testa la procedura prima di un’interruzione: un account di emergenza mai utilizzato potrebbe non funzionare a causa di una chiave scaduta, di una rotta di rete modificata o di una dipendenza dimenticata.
Non risolvere la resilienza mantenendo una backdoor permanente e senza restrizioni. Il percorso di ripristino dovrebbe essere protetto con più attenzione rispetto all’accesso ordinario, utilizzando quando appropriato informazioni di recupero offline o controllate separatamente.
Adatta i controlli SSH al server che gestisci realmente
Il livello di rafforzamento SSH disponibile dipende dal modello di hosting. Con un VPS o un server dedicato gestito dall’azienda, il cliente controlla generalmente il sistema operativo, la configurazione del demone SSH, le regole del firewall, gli account utente, le chiavi, gli aggiornamenti e il logging. Le responsabilità esatte possono essere condivise con un provider gestito, quindi verifica chi apporta le modifiche e chi risponde agli avvisi.
Nel caso dell’hosting condiviso, i clienti generalmente non controllano la configurazione SSH a livello server. È il gestore dell’hosting a decidere se SSH è disponibile, quali metodi di autenticazione sono supportati, se l’accesso shell è limitato e come viene aggiornato il sistema sottostante. Il cliente può riuscire a caricare una chiave o usare una shell limitata, ma normalmente non può disabilitare l’accesso root, modificare sshd_config o applicare policy di accesso a livello organizzativo. La differenza tra infrastrutture VPS gestite dal cliente e ambienti di hosting condiviso è quindi importante: i controlli SSH dipendono da chi gestisce il server.
Non presumere che un piano di hosting condiviso offra gli stessi controlli amministrativi di un VPS o di un server dedicato. Se l’azienda necessita di accesso al sistema operativo, account amministrativi nominativi, regole firewall personalizzate, un bastion host, log SSH dettagliati o controlli di backup a livello server, scegli un modello infrastrutturale in cui queste responsabilità siano assegnate chiaramente.
Collega la sicurezza degli accessi al ripristino
Controlli SSH solidi riducono la probabilità di un’amministrazione non autorizzata, ma non possono garantire che un account, un server o una workstation di gestione non vengano mai compromessi. La pianificazione del ripristino deve presupporre che le credenziali possano essere rubate e che un attaccante possa modificare o crittografare i dati.
Per i server controllati dal cliente, Safenix offre backup fuori sede progettati per il ripristino dei server aziendali. I dati di backup sono crittografati con una chiave che Safenix non possiede, archiviati in Germania e resi immutabili per la durata della finestra di conservazione selezionata. Questa separazione è importante: l’accesso al server di produzione non dovrebbe consentire automaticamente di riscrivere ogni backup protetto.
I backup non sostituiscono il rafforzamento di SSH e il rafforzamento di SSH non sostituisce i backup. Verifica che le credenziali di backup siano separate dagli account amministrativi ordinari, che il processo di backup non possa essere disabilitato facilmente da una sessione compromessa e che l’accesso al ripristino sia documentato. Testa il ripristino, non solo il completamento del backup, e registra chi può approvare ed eseguire un ripristino.
Un ciclo di revisione pratico per agenzie e team IT
Rendi la sicurezza SSH parte dell’amministrazione ordinaria, invece di considerarla una pulizia da eseguire una sola volta. Un ciclo di revisione utile può includere un controllo mensile degli accessi falliti e insoliti, una revisione trimestrale di account, chiavi e privilegi e una revisione attivata da eventi dopo cambiamenti del personale, migrazioni infrastrutturali o sospette compromissioni.
- Fai l’inventario di ogni server, endpoint SSH, amministratore, identità di automazione e percorso di emergenza.
- Conferma la titolarità e lo scopo aziendale di ogni account e chiave pubblica.
- Convalida le impostazioni di accesso root e tramite password, l’MFA, i perimetri di rete e le opzioni di forwarding.
- Esamina le regole sudo, le autorizzazioni degli account di servizio e l’automazione della produzione.
- Controlla lo stato degli aggiornamenti, il logging, l’instradamento degli avvisi e la sincronizzazione dell’orario.
- Testa la revoca delle chiavi, l’accesso break-glass, l’isolamento dei backup e il ripristino.
- Documenta le eccezioni indicando un responsabile, la motivazione, la data di scadenza e i controlli compensativi.
Il risultato più solido nasce dalla combinazione di controlli piccoli e verificabili: identità nominative invece di account condivisi, chiavi invece di password, privilegio minimo invece di accesso root permanente, reti limitate invece di esposizione aperta e ripristino testato invece della speranza. Questo approccio rende più resiliente l’accesso sicuro ai server senza fingere che una singola impostazione SSH possa eliminare il rischio.