L’hardening di un server Linux è il processo di riduzione delle modalità con cui un attaccante può entrare in un server, operare al suo interno e mantenervi la propria presenza. Non consiste in una singola modifica di configurazione né in un prodotto che si può semplicemente attivare. È una sequenza di decisioni su ciò che il server esegue, su chi può accedervi, sulle connessioni di rete accettate, sulla registrazione delle attività e sulla rapidità con cui le vulnerabilità vengono corrette.
Per agenzie e aziende, l’hardening dovrebbe essere eseguito prima che un server entri in produzione. Un server appena installato può contenere account predefiniti, servizi in ascolto, permessi troppo ampi e interfacce di gestione che erano comode durante la configurazione, ma non sono necessarie nel normale funzionamento. Ogni componente superfluo aumenta la superficie di attacco e introduce un’ulteriore impostazione da mantenere.
Questa guida presenta una baseline pratica per l’hardening di server Linux su VPS e server dedicati controllati dal cliente. I comandi esatti cambiano tra distribuzioni come Debian, Ubuntu, Rocky Linux, AlmaLinux e altre; considera quindi gli esempi come concetti di configurazione, non come istruzioni da copiare e incollare. Testa le modifiche su un sistema non di produzione, mantieni un percorso di ripristino out-of-band e documenta ciò che è stato modificato.
Inizia da un’installazione minimale e conosciuta
Il server più sicuro è generalmente quello che fa meno cose. Inizia con una distribuzione Linux supportata e un’installazione minimale che includa solo i componenti del sistema operativo e gli strumenti necessari al carico di lavoro previsto. Un web server, un database server, un application server e un nodo di monitoraggio non necessitano di pacchetti o servizi identici.
Registra la versione del sistema operativo, le sorgenti dei repository, i pacchetti installati, i servizi abilitati, le interfacce di rete e i ruoli previsti. Questo inventario stabilisce una baseline. Senza di essa, un amministratore potrebbe non accorgersi che è stato aggiunto un pacchetto, che un servizio ha iniziato ad ascoltare o che una configurazione è cambiata nel tempo.
Rimuovi ciò che il carico di lavoro non richiede
Esamina i pacchetti installati e rimuovi il software non necessario. Tra gli esempi comuni rientrano agenti di trasferimento della posta inutilizzati, utility di rete obsolete, componenti grafici, compilatori e strumenti temporanei di amministrazione. Non rimuovere un pacchetto solo perché il suo nome non è familiare: verifica prima se un altro servizio dipende da esso e se è necessario per patch, monitoraggio o ripristino.
Disabilita i servizi che non fanno parte del ruolo del server. Un servizio installato ma non necessario può comunque esporre una porta di rete, elaborare input non attendibili o contenere una vulnerabilità. Un’interfaccia amministrativa inutilizzata è particolarmente rischiosa perché potrebbe conservare impostazioni predefinite pur ricevendo poca attenzione.
Nelle distribuzioni basate su systemd, gli amministratori esaminano comunemente lo stato dei servizi con strumenti come systemctl e controllano i socket in ascolto con ss. L’obiettivo non è ridurre al minimo l’elenco dei servizi a ogni costo. L’obiettivo è fare in modo che ogni servizio in esecuzione sia intenzionale, abbia un responsabile e sia coperto da un processo di patching e monitoraggio.
Definisci un processo tempestivo per le patch
Il software non aggiornato è uno dei modi più affidabili con cui gli attaccanti possono sfruttare una vulnerabilità nota. L’hardening dei server Linux include quindi il sistema operativo, il kernel, i pacchetti installati, i runtime dei linguaggi, i web server, i database, le immagini dei container e le applicazioni. Un server può avere un firewall configurato con grande attenzione e venire comunque compromesso tramite un servizio vulnerabile che accetta traffico di rete legittimo.
Iscriviti agli avvisi di sicurezza della distribuzione e dei principali componenti software che utilizzi. Definisci chi esamina gli avvisi, come viene valutata la gravità e con quale rapidità vengono applicati gli aggiornamenti. Le vulnerabilità critiche nei servizi esposti a Internet possono richiedere un intervento d’emergenza, mentre le modifiche a rischio inferiore possono seguire una finestra di manutenzione programmata.
Bilancia rapidità e controllo delle modifiche
Gli aggiornamenti automatici di sicurezza possono ridurre il tempo di esposizione, ma possono anche introdurre problemi di compatibilità. Sono spesso appropriati per alcuni pacchetti di sicurezza del sistema operativo, a condizione che gli amministratori dispongano di monitoraggio, procedure di rollback e un modo per gestire i riavvii. Per stack applicativi con dipendenze rigide, una pipeline di aggiornamento controllata può essere più sicura.
Documenta il compromesso. Una policy potrebbe stabilire che le patch di sicurezza vengano applicate entro un periodo definito, che i riavvii del kernel avvengano durante una finestra di manutenzione concordata e che gli aggiornamenti d’emergenza possano derogare alla normale pianificazione. Il punto importante è evitare un processo informale in cui gli aggiornamenti dipendono dal fatto che qualcuno si ricordi di accedere al server.
Dopo il patching, verifica che i servizi siano stati riavviati correttamente, che i certificati siano ancora disponibili, che le dipendenze applicative funzionino e che il server invii dati al sistema di monitoraggio. Una patch che lascia arrestato un servizio critico è tecnicamente applicata, ma operativamente fallita.
Usa utenti separati e il principio del privilegio minimo
Il principio del privilegio minimo limita i danni causati dalla compromissione di un account, di un processo o di un’applicazione. Gli utenti devono ricevere solo l’accesso necessario alle proprie responsabilità e solo per il tempo necessario. Evita gli account amministrativi condivisi, perché rendono difficile attribuire le attività e incoraggiano il riutilizzo delle credenziali.
Crea account nominativi per gli amministratori e account di servizio separati per le applicazioni. Un’applicazione web normalmente non dovrebbe essere eseguita come root e un processo database non dovrebbe avere accesso in scrittura a directory applicative non correlate. Gli account di servizio dovrebbero avere shell non interattive quando opportuno e non dovrebbero appartenere a gruppi amministrativi, salvo un requisito specifico e documentato.
Esamina regolarmente utenti, appartenenze ai gruppi, directory home, shell di accesso, chiavi SSH e dati sull’ultimo accesso. Rimuovi gli account appartenenti a persone che hanno lasciato il progetto, ruota gli accessi quando cambiano le responsabilità e assegna un responsabile a ogni account privilegiato. L’accesso temporaneo dovrebbe avere una procedura di scadenza, invece di diventare accidentalmente permanente.
Gestisci sudo con attenzione
sudo è più sicuro che fornire a ogni amministratore la password di root, ma una regola sudo troppo ampia può equivalere quasi a un accesso root senza restrizioni. Concedi i permessi amministrativi a utenti nominativi o a gruppi gestiti con rigore. Quando possibile, autorizza comandi specifici invece di un prefisso di comando senza restrizioni ed evita regole che consentano a un utente di modificare file di configurazione arbitrari o di eseguire una shell tramite un altro programma.
Richiedi l’autenticazione per le azioni privilegiate, salvo che esista una ragione operativa documentata per non farlo. Conserva le attività sudo nei log centralizzati e controllale per individuare orari, comandi o account insoliti. Presta attenzione agli script: uno script autorizzato che legge input controllato dall’utente, cerca in un percorso non sicuro o richiama un altro programma senza un percorso assoluto può offrire una via indiretta all’escalation dei privilegi.
Il privilegio minimo può rallentare la risposta agli incidenti se viene progettato senza procedure d’emergenza. Gli amministratori devono documentare come ottenere un accesso elevato durante un’interruzione, chi lo approva e come viene esaminato in seguito. I controlli di sicurezza che nessuno riesce a usare durante un incidente reale tendono a essere aggirati quando la pressione aumenta.
Metti in sicurezza SSH senza perdere l’accesso
SSH è spesso il principale percorso di gestione di un server Linux, quindi il suo hardening deve essere pianificato e testato. Prima di modificare la configurazione del demone, apri una seconda sessione amministrativa e mantieni disponibile l’accesso tramite console o a livello di provider, se la piattaforma lo offre. Convalida la nuova configurazione prima di riavviare il servizio.
Usa chiavi SSH invece dell’autenticazione tramite password per l’accesso amministrativo. Le chiavi rendono meno efficaci gli attacchi automatizzati contro password deboli, soprattutto quando sono protette da una passphrase e gestite tramite un agent o un processo approvato per i segreti. Proteggi le chiavi private come credenziali: non conservarle in cartelle condivise, repository di codice o workstation non gestite.
Per un server controllato dal cliente, una baseline SSH di base comprende generalmente:
- Disabilitare l’accesso diretto di root tramite SSH.
- Disabilitare l’autenticazione con password dopo aver testato l’accesso basato su chiavi.
- Limitare l’accesso SSH a utenti nominativi o a un gruppo amministrativo.
- Utilizzare un protocollo SSH aggiornato e algoritmi crittografici supportati.
- Limitare l’accesso tramite una rete di gestione, una VPN o indirizzi sorgente definiti in modo restrittivo, quando possibile.
- Impostare timeout ragionevoli per connessioni e autenticazione.
- Registrare gli eventi di autenticazione riusciti e falliti.
Cambiare la porta SSH può ridurre il rumore generato dagli scanner meno sofisticati, ma non costituisce un confine di sicurezza. Non deve mai sostituire l’autenticazione tramite chiavi, le restrizioni di accesso e il patching. Analogamente, gli strumenti che bloccano automaticamente i tentativi di accesso ripetuti possono aiutare contro il traffico di forza bruta, ma rischiano di bloccare amministratori legittimi se le soglie e le sorgenti attendibili sono progettate male.
Disabilita l’accesso root e testa il ripristino
L’accesso diretto a root elimina la responsabilità individuale e offre all’attaccante un obiettivo di grande valore. Imposta PermitRootLogin su no dopo aver testato un account amministrativo alternativo. Il test deve includere un nuovo accesso con la chiave prevista, l’accesso tramite sudo, l’accesso dalla normale rete di gestione e la procedura di accesso d’emergenza.
Non chiudere la sessione esistente finché il nuovo percorso non è stato confermato. Un piccolo errore di sintassi, un nome di gruppo errato o una regola AllowUsers troppo restrittiva possono bloccare l’intero team. L’hardening di SSH è efficace solo quando migliora la sicurezza senza eliminare la possibilità di amministrare e ripristinare il server.
Applica una configurazione firewall con negazione predefinita
La configurazione del firewall riduce il numero di percorsi di rete che raggiungono un servizio. Una baseline pratica consiste nel negare per impostazione predefinita il traffico in ingresso non richiesto, consentire solo le porte necessarie e autorizzare il traffico in uscita secondo il carico di lavoro e la policy aziendale. La policy corretta dipende dal servizio: un web server pubblico può avere bisogno di HTTP e HTTPS, mentre un database dovrebbe generalmente accettare connessioni solo da host applicativi definiti.
Usa il firewall dell’host come ulteriore livello, anche quando un cloud provider o il perimetro di rete forniscono già un filtraggio. Più livelli possono limitare l’impatto di un errore in una delle posizioni, ma devono essere documentati affinché gli amministratori capiscano dove una connessione viene consentita o negata. Tra gli strumenti firewall Linux più comuni vi sono nftables, firewalld e i frontend specifici delle distribuzioni.
Per ogni regola consentita, registra:
- Le reti o gli host sorgente autorizzati.
- La porta di destinazione e il protocollo.
- Il responsabile del servizio e la finalità aziendale.
- Se la regola è temporanea o permanente.
- Come verrà esaminata e rimossa la regola.
Una regola come “consenti la porta del database da ovunque” crea un’ampia via d’attacco anche se il database richiede una password. Limita i servizi amministrativi alle reti attendibili quando possibile. Se gli amministratori remoti devono accedere da posizioni variabili, valuta una VPN, un bastion host controllato o un altro percorso di accesso gestito, invece di esporre ogni porta di gestione a Internet.
Testa le modifiche al firewall da una posizione esterna autorizzata e dalla rete applicativa. Conferma che il traffico necessario funzioni e che quello non autorizzato venga rifiutato. Esegui anche un test dopo il riavvio, perché un firewall non persistente può lasciare il server esposto dopo la manutenzione.
Proteggi file, segreti e dati applicativi
Permessi sicuri sui file impediscono a un account o servizio di leggere o modificare i dati di un altro servizio. Inizia dalla proprietà. I file di sistema dovrebbero normalmente appartenere a root o all’account di sistema appropriato, mentre le directory applicative dovrebbero essere scrivibili solo nei punti in cui l’applicazione deve effettivamente scrivere.
Evita permessi troppo ampi come 777 per directory o file. Consentono a ogni utente locale e a ogni processo compromesso di leggere, modificare o eseguire i contenuti. I file di configurazione che contengono credenziali di database, chiavi API o certificati privati devono essere leggibili solo dall’account o dal gruppo che ne ha bisogno. Le chiavi SSH private devono essere protette con permessi restrittivi e non devono essere collocate in directory accessibili dal web.
Separa, quando possibile, codice, configurazione, upload, log e file temporanei. I contenuti caricati dagli utenti non devono diventare automaticamente eseguibili. Le document root dei web server non devono contenere segreti di deployment, metadati dei sistemi di controllo versione, archivi di backup o file di ambiente. Se un’applicazione deve scrivere gli upload, assegnale una directory dedicata e valuta controlli che impediscano l’esecuzione degli script caricati.
Gestisci i segreti in modo consapevole
Non inserire password nella cronologia della shell, nei ticket, nei repository di codice o in script improvvisati. Usa un secrets manager o un altro meccanismo controllato, adeguato all’organizzazione. Ruota le credenziali quando il personale lascia l’azienda, quando si sospetta un’esposizione e in base al rischio del sistema. Registra quali servizi dipendono da ogni segreto, così che la rotazione non si trasformi in un’interruzione del servizio.
I permessi dei file non sostituiscono la crittografia. Se un attaccante ottiene l’accesso root, i confini dei permessi locali potrebbero non proteggere più i dati. Restano comunque importanti perché molti incidenti iniziano con un account applicativo con privilegi ridotti, una credenziale utente rubata o un processo locale con permessi eccessivi.
Isola i servizi e riduci i movimenti laterali
L’isolamento dei servizi limita ciò che un componente compromesso può raggiungere. Esegui ogni servizio principale con un account dedicato e limita l’accesso al filesystem, alla rete e alle funzionalità Linux. A seconda del carico di lavoro, l’isolamento può utilizzare le opzioni di sandboxing di systemd, container, macchine virtuali, controlli di accesso obbligatori come SELinux o AppArmor, meccanismi simili a chroot e segmentazione di rete.
L’isolamento deve essere proporzionato alla minaccia e alle capacità operative del team. Un container non è automaticamente un confine di sicurezza completo e una policy complessa che nessuno comprende può essere, nella pratica, più debole di un design semplice e ben monitorato. Mantieni aggiornati anche l’host, il runtime dei container, le immagini e i componenti di orchestrazione.
Per le applicazioni esposte a Internet, separa il livello pubblico dai database e dai servizi interni. Consenti solo le connessioni necessarie tra applicazione e database. Impedisci a un processo web compromesso di effettuare connessioni in uscita arbitrarie quando il carico di lavoro lo consente. Ciò può limitare il traffico di comando e controllo e rendere più difficile estendere lo sfruttamento ad altri sistemi.
Documenta le dipendenze tra i servizi prima di applicare l’isolamento. Policy eccessivamente restrittive possono interrompere aggiornamenti, risoluzione DNS, sincronizzazione dell’ora, inoltro dei log o controlli di integrità. Il compromesso riguarda la scelta tra un raggio d’impatto più ridotto e lo sforzo aggiuntivo necessario per testare, gestire e risolvere i problemi dei confini.
Registra le attività e monitora le modifiche
L’hardening senza visibilità lascia gli amministratori incapaci di capire se i controlli funzionano. Abilita la registrazione di autenticazione, escalation dei privilegi, servizi e firewall. Raccogli anche i log delle applicazioni e dei web server, facendo attenzione a non registrare password, token di sessione o altri valori sensibili.
Quando possibile, inoltra i log importanti fuori dal server. Un attaccante con accesso amministrativo potrebbe cancellare o alterare le prove locali. La registrazione centralizzata facilita anche la correlazione degli eventi tra server, come un accesso sospetto seguito dalla creazione di un nuovo account e da una connessione in uscita insolita.
Definisci avvisi per gli eventi che richiedono attenzione, invece di inviare ogni messaggio a una casella di posta che nessuno legge. Segnali utili possono includere:
- Accessi falliti ripetuti seguiti da un accesso riuscito.
- Nuovi utenti privilegiati, modifiche alle appartenenze ai gruppi o chiavi SSH inattese.
- Attività dirette di root o comandi sudo insoliti.
- Modifiche alle regole del firewall, alla configurazione SSH o ai file di sistema critici.
- Porte in ascolto inattese o servizi avviati al boot.
- Utilizzo anomalo di CPU, memoria, disco o rete in uscita.
- Agenti di sicurezza, inoltro dei log o controlli di monitoraggio diventati inattivi.
Il monitoraggio deve avere un responsabile e un processo di risposta. Un avviso che non viene esaminato, classificato e collegato a un’azione è soltanto una registrazione. Stabilisci i normali schemi operativi affinché il team possa distinguere un deployment da una modifica di configurazione inspiegata.
Esegui controlli automatizzati di vulnerabilità e configurazione
Le verifiche manuali sono utili, ma incoerenti. Gli scanner automatici di vulnerabilità, gli audit dei pacchetti e i controlli di configurazione possono identificare patch mancanti, servizi esposti, impostazioni crittografiche deboli, librerie obsolete e deviazioni dalla baseline approvata. Eseguili regolarmente e dopo modifiche significative, non solo subito prima di un audit.
Usa un flusso di lavoro basato sulla gravità. Conferma prima i risultati, perché gli scanner possono segnalare falsi positivi o non riconoscere una patch della distribuzione retroportata. Poi assegna un responsabile, una scadenza per la correzione e una prova della chiusura. Una vulnerabilità che non può essere corretta immediatamente deve avere una misura compensativa documentata, come una restrizione di rete, la disabilitazione del servizio o un monitoraggio più intenso.
La gestione della configurazione può prevenire la deriva definendo lo stato desiderato per utenti, pacchetti, servizi, regole firewall e permessi. Esamina le modifiche tramite controllo versione o un processo di approvazione equivalente. Evita di conservare segreti nei normali repository di configurazione e assicurati che l’automazione utilizzi a sua volta credenziali con ambito ristretto.
Prima della produzione, convalida la baseline con una pratica checklist per l’hardening dei server Linux e adattala alla distribuzione, al carico di lavoro e al profilo di rischio. Una checklist è un punto di partenza, non una prova di sicurezza. L’amministratore deve comunque verificare che i controlli siano pertinenti e che l’azienda sia in grado di gestirli.
Comprendi le differenze tra VPS, server dedicati e hosting condiviso
Questi controlli si applicano quando il cliente controlla il sistema operativo e la configurazione del server, ad esempio su una VPS o un server dedicato gestito dal cliente. Normalmente il cliente può scegliere la distribuzione, gestire gli utenti, configurare SSH, installare un firewall sull’host, aggiornare i pacchetti, isolare i servizi e decidere come gestire log e monitoraggio.
L’hosting condiviso è diverso. Più clienti utilizzano un ambiente gestito dal provider e generalmente non possono modificare il firewall dell’host, disabilitare i servizi di sistema, configurare il demone SSH, aggiornare il sistema operativo o definire l’isolamento a livello kernel. Il provider può offrire controlli di sicurezza propri, ma questi non equivalgono all’hardening di un server Linux controllato dal cliente.
Quando confronti le opzioni di hosting, distingui tra un ambiente VPS o dedicato controllato dal cliente e hosting condiviso e altri servizi di hosting gestito. Non dare per scontato che una checklist di hardening possa essere applicata a un sito solo perché il sito funziona su Linux. Se il cliente non controlla il server, le domande rilevanti sono quali elementi protegge il provider, cosa può configurare il cliente, come vengono gestiti gli incidenti e come è possibile recuperare i dati.
Safenix protegge i server controllati dal cliente. Non fornisce un piano di backup per un sito web che funziona su hosting condiviso. Questa distinzione è importante quando si definisce l’ambito del backup: identifica il server effettivo, il suo sistema operativo e il livello di accesso disponibile prima di scegliere un approccio al ripristino.
L’hardening riduce i rischi ma non garantisce il ripristino
Anche un server ben protetto può essere compromesso. Le credenziali possono essere rubate, un’applicazione può contenere una vulnerabilità sconosciuta, un amministratore può commettere un errore distruttivo, un soggetto interno privilegiato può abusare dell’accesso oppure un ransomware può cifrare i dati tramite un account legittimo. L’hardening mira a ridurre la probabilità e l’impatto della compromissione; non rende il server indistruttibile.
Il ripristino deve quindi rientrare nello stesso piano di resilienza. Mantieni i backup separati dal server di produzione e dalle credenziali usate per amministrarlo. Se un attaccante può eliminare, modificare o cifrare sia i dati attivi sia i backup, il processo di backup potrebbe esistere sulla carta, ma fallire proprio durante l’incidente più importante.
Dopo aver messo in sicurezza il server, proteggi la possibilità di recupero con backup Safenix cifrati e off-site per server aziendali controllati dal cliente. Safenix conserva i dati di backup in Germania, li cifra utilizzando una chiave che Safenix non detiene e li mantiene immutabili per la durata della finestra di conservazione. Queste proprietà affrontano rischi diversi: lo storage off-site separa le copie di backup dai guasti locali, la crittografia protegge la riservatezza e l’immutabilità aiuta a impedire modifiche o cancellazioni durante il periodo di conservazione definito.
La progettazione del backup richiede comunque decisioni da parte del cliente. Identifica quali server e dati sono essenziali, quanta perdita di dati l’azienda può tollerare, con quale rapidità i sistemi devono tornare operativi e quali dipendenze sono necessarie per un ripristino utilizzabile. Il backup dei file applicativi senza database, configurazione, credenziali o una procedura di ricostruzione documentata potrebbe non produrre un servizio funzionante.
Testa il ripristino, non solo il completamento del backup
Un processo di backup completato con successo dimostra che i dati sono stati scritti. Non dimostra che l’azienda sia in grado di ripristinarli. Pianifica test di ripristino utilizzando un server rappresentativo o un ambiente di recupero isolato. Verifica l’integrità dei file, la consistenza del database, i permessi, l’avvio dell’applicazione, le modifiche DNS, i certificati e la possibilità per gli utenti di lavorare normalmente.
Registra il risultato di ogni test, compreso il tempo richiesto, i problemi riscontrati e le azioni assegnate. Testa sia il ripristino di un file di piccole dimensioni sia il ripristino completo del server o del servizio, quando opportuno. Includi scenari come cancellazione accidentale, guasto del server, ransomware e perdita della sede di hosting principale.
Non affidarti alla memoria di un singolo amministratore. Conserva le procedure di ripristino in un luogo in cui restino disponibili durante un incidente del server, proteggendole però dagli accessi non autorizzati. Devono indicare contatti, dipendenze, recupero delle credenziali, ordine di ripristino, controlli di convalida e autorità responsabile della decisione di tornare in produzione.
Documenta i compromessi operativi
I controlli di sicurezza interagiscono sempre con disponibilità, prestazioni, costi e impegno amministrativo. Una baseline di hardening dovrebbe spiegare queste decisioni invece di presentarle come regole universali. Ciò rende l’ambiente più semplice da gestire e aiuta l’amministratore successivo a capire perché esiste un’eccezione.
Documenta almeno:
- Quali servizi e porte sono necessari e chi è responsabile di ciascuno.
- Quali utenti e gruppi hanno accesso amministrativo, come vengono rilasciate le chiavi e come viene revocato l’accesso.
- Con quale rapidità vengono applicate le patch di sicurezza e quando sono consentiti i riavvii.
- Quali impostazioni di firewall, SSH, sudo e permessi differiscono dalla baseline standard.
- Come l’isolamento dei servizi influisce su deployment, risoluzione dei problemi e prestazioni.
- Quali log vengono conservati, dove vengono inviati e chi risponde agli avvisi.
- Come vengono valutate, definite in ordine di priorità e chiuse le vulnerabilità rilevate.
- Quali dati vengono sottoposti a backup, i requisiti di conservazione e il processo di ripristino testato.
- Cosa accade se il server principale, le credenziali o l’amministratore non sono disponibili.
Tra gli esempi di compromesso rientra la disabilitazione dell’accesso tramite password, che migliora la resistenza agli attacchi basati sulle password ma richiede una gestione affidabile delle chiavi e una procedura di accesso d’emergenza. Un firewall con negazione predefinita riduce l’esposizione, ma può interrompere una nuova integrazione appena distribuita. Un patching automatico aggressivo riduce la finestra di vulnerabilità, ma può richiedere test e rollback migliori. Un isolamento forte dei servizi limita i movimenti laterali, ma aumenta la complessità di configurazione.
Le eccezioni devono avere un responsabile, una motivazione, una data di scadenza o di revisione e misure compensative. Un accesso firewall “temporaneo” che rimane per anni non è più un’eccezione: è un’infrastruttura non documentata. Le revisioni periodiche devono rimuovere account, pacchetti, servizi, porte e permessi obsoleti.
Una sequenza pratica di hardening prima della produzione
I team spesso ottengono risultati migliori applicando i controlli in un ordine ripetibile:
- Definisci il ruolo del server, la classificazione dei dati, le dipendenze e i requisiti di ripristino.
- Installa un sistema operativo supportato utilizzando il set di pacchetti pratico più ridotto.
- Applica gli aggiornamenti correnti e registra la baseline della versione risultante.
- Crea account amministrativi nominativi e configura un accesso sudo con ambito attentamente definito.
- Installa e testa le chiavi SSH, quindi disabilita l’accesso diretto di root e l’autenticazione tramite password quando opportuno.
- Rimuovi i pacchetti non necessari e disabilita i servizi che non servono.
- Configura un firewall persistente con negazione predefinita ed eccezioni dall’ambito ristretto.
- Imposta proprietà e permessi per file di sistema, codice applicativo, segreti, upload e log.
- Isola i servizi e limita l’accesso al loro filesystem, alla rete e alle funzionalità.
- Abilita logging centralizzato, monitoraggio e avvisi per autenticazione, privilegi e modifiche alla configurazione.
- Esegui controlli di vulnerabilità e configurazione, quindi risolvi o documenta i risultati.
- Configura backup off-site ed esegui un test di ripristino prima di dichiarare il server pronto.
Ripeti la sequenza dopo le modifiche principali. L’hardening in produzione non è una procedura una tantum, perché pacchetti, applicazioni, utenti, integrazioni e requisiti aziendali cambiano. Un server sicuro al momento del lancio può assumere un profilo di rischio diverso dopo alcuni mesi.
Una baseline a supporto della resilienza
L’hardening dei server Linux funziona meglio come parte di una disciplina operativa più ampia. Le installazioni minimali riducono i percorsi di attacco non necessari. Il patching elimina le vulnerabilità note. Il privilegio minimo limita ciò che può fare un account compromesso. I controlli SSH proteggono l’amministrazione, i firewall limitano l’esposizione di rete e i permessi proteggono i dati dai processi non correlati. L’isolamento limita i movimenti laterali, mentre logging e monitoraggio migliorano il rilevamento. I controlli automatizzati aiutano il team a individuare la deriva prima dell’attaccante.
Nessuno di questi controlli elimina la necessità di un ripristino testato. Prevenzione e ripristino affrontano modalità di guasto diverse. Metti in sicurezza il server per rendere più difficile la compromissione, monitoralo per rendere visibili le attività sospette e mantieni backup off-site protetti, così che un incidente grave non si trasformi nella perdita permanente dei dati aziendali.