Passi fondamentali per un server Linux sicuro

Per rafforzamento di un server Linux si intende la fortificazione e la messa in sicurezza di un server Linux al fine di proteggerlo da vulnerabilità e minacce. Anche se la sicurezza totale rimarrà sempre un bersaglio mobile nella corsa agli strumenti per la sicurezza, questo articolo esplora alcuni importanti passi fondamentali che puoi compiere per mantenere i propri server sicuri e protetti.

Nessun rischio di sicurezza è troppo piccolo per essere ignorato

Purtroppo, anche le vulnerabilità più piccole possono trasformarsi in gravi minacce alla sicurezza. È importante ricordare che qualsiasi codice in esecuzione sul sistema può potenzialmente contenere falle che consentono agli intrusi di accedere ad una shell di comando o agli utenti legittimi non privilegiati di elevare il loro accesso ai diritti di superutente. Indipendentemente dal livello di rischio, è sempre meglio affrontare i rischi minori prima che si trasformino in gravi minacce alla cybersecurity seguendo un processo di hardening del server. Con il l’hardening dei server Linux, i team IT possono consolidare le proprie difese prima che si verifichino minacce gravi, evitando così che si verifichino problemi importanti. 

Aggiornamenti del sistema e patch di sicurezza

Aggiornare regolarmente il server Linux è essenziale per mantenerne la sicurezza e la salute generale, soprattutto perché il 57% delle compromissioni esterne proviene da sistemi non patchati. Il software e i sistemi operativi vengono costantemente migliorati e perfezionati per risolvere le vulnerabilità e i punti deboli. Applicando tempestivamente gli aggiornamenti, ci si assicura che le falle di sicurezza conosciute vengano patchate, riducendo il rischio di sfruttamento da parte delle minacce informatiche. Inoltre, gli aggiornamenti spesso includono correzioni di bug e miglioramenti delle prestazioni, che portano a un ambiente server più stabile ed efficiente. Il mancato aggiornamento costante può lasciare il sistema esposto a potenziali attacchi e comprometterne l’integrità.

L’utilizzo di software obsoleto e la mancata risoluzione di vulnerabilità non patchate comportano rischi significativi per i tuoi server Linux. I criminali informatici prendono attivamente di mira le vulnerabilità note per ottenere un accesso non autorizzato, compromettere i dati o interrompere i servizi. Quando le vulnerabilità vengono rese pubbliche, i soggetti malintenzionati possono sfruttarle per compromettere i sistemi che non hanno ricevuto gli aggiornamenti. Rimandare gli aggiornamenti ingrandisce la finestra di opportunità per gli aggressori di sfruttare i punti deboli nelle difese dei tuoi server, rendendo gli aggiornamenti regolari una misura di difesa fondamentale.

Scegliere le giuste strategie di patching e le best practice per il patch management del tuo server è vitale per mantenere un server Linux sicuro. Le attuali distribuzioni Linux di livello aziendale dispongono in genere di qualche tipo di servizi di patch management automatizzato, sia tramite servizi di abbonamento a pagamento che tramite iniziative della community. I servizi a pagamento spesso vanno oltre il semplice patching dei file di sistema per la sicurezza; alcuni di questi servizi includono anche una soluzione per il patching dal vivo del kernel in esecuzione, consentendo ai sistemi in esecuzione di rimanere patchati prima ancora di doverli riavviare. 

Introduzione ai gestori di pacchetti

I gestori di pacchetti distinguono tra le varie distribuzioni, ma tendono a utilizzare due formati principali di pacchetti: DEB e RPM. DEB è usato nei sistemi basati su Debian ed è gestito da apt; RPM sta per Redhat Package Manager ed è gestito tramite dnf o yum per i sistemi basati su Red Hat/Enterprise Linux o zypper per SUSE. Tutti i gestori di pacchetti facilitano l’installazione, l’aggiornamento e la rimozione dei pacchetti software, oltre a risolvere le dipendenze. Utilizza i gestori di pacchetti per amministrare efficacemente il software e semplificare il processo di aggiornamento. Tutti i principali gestori di pacchetti sono supportati anche da repository remoti, consentendo di centralizzare il controllo sugli aggiornamenti e sul rollout del software.

Configurazione degli aggiornamenti automatici per le patch di sicurezza fondamentali

La configurazione del server Linux per l’installazione automatica delle importanti patch di sicurezza assicura che gli aggiornamenti ad alta priorità vengano applicati tempestivamente senza intervento manuale, riducendo al minimo la finestra di vulnerabilità e l’onere per gli amministratori. Le distribuzioni aziendali di solito permettono di configurare questo aspetto durante l’installazione. Consulta i pacchetti di configurazione menzionati di seguito se desideri configurare ciò sul proprio sistema esistente:

Ubuntu: sudo apt install unattended-upgrades

Red Hat/CentOS: sudo yum install dnf-automatic

SUSE: sudo zypper install yast2-online-update-configuration ->  apri YaST, seleziona Software -> Online Update Configuration e configura a piacere.

Fai attenzione, tuttavia, quando attivi gli aggiornamenti automatici; questi potrebbero avere un impatto sulla stabilità del sistema o richiedere test di compatibilità. I test sono particolarmente importanti quando si utilizzano strumenti di amministrazione remota di massa come ansible o puppet per eseguire gli aggiornamenti dei server in un ambiente informatico eterogeneo.

Configurazione dell’elevazione sudo e dell’accesso alla shell

La corretta configurazione degli account utente e delle autorizzazioni è essenziale per avere un sistema sicuro che consenta comunque il giusto accesso. I permessi non configurati correttamente possono creare problemi, quindi è meglio assicurarsi che siano impostati correttamente fin dall’inizio.

L’uso del comando sudo al massimo delle sue potenzialità con la giusta configurazione di /etc/sudoers permette di limitare e consentire i diritti di accesso principale senza password su base per-app. Utilizza sempre il comando visudo per modificare/etc/sudoers, in quanto mantiene i permessi corretti su questo file importante:

sudo visudo

Apporta modifiche simili a queste, sostituendo ninja con il tuo nome utente e modificando l’elenco separato da virgole dei comandi consentiti per adattarlo al proprio caso d’uso, da:

someuser ALL=(ALL:ALL) ALL

a

someuser ALL = NOPASSWD: /bin/systemctl restart nginx, /bin/kill, /usr/sbin/reboot

Quindi salva ed esci. Si noti che sudo legge effettivamente il file /etc/sudoers dal basso verso l’alto, quindi se le modifiche non sembrano essere efficaci, prova a spostare la riga modificata vicino alla parte inferiore del file sudoers.

Una parola sulle shell

È possibile impostare la shell predefinita di un utente eseguendo il comando chsh come root, oppure modificando in massa il file /etc/passwd come root. Questo è utile e auspicabile in alcuni casi, come ad esempio la modifica della shell predefinita di un account FTP in /sbin/nologin, poiché un account di questo tipo non dovrebbe mai avere bisogno di eseguire comandi da terminale. In questo caso, l’eliminazione dell’accesso alla shell ridurrebbe la superficie di attacco potenziale del sistema.

Proteggere l’accesso SSH con le chiavi e disabilitare l’accesso di root

Secure Shell (SSH) è un protocollo di rete standard del settore che consente l’accesso remoto a livello di riga di comando ad un sistema. È convinzione diffusa tra i tecnici che l’accesso alla shell debba essere equivalente a “come se fossi in loco”, quindi è fondamentale limitare l’accesso SSH solo agli utenti necessari e assicurarsi che solo gli utenti giusti possano eseguire operazioni come root.

Le migliori pratiche per proteggere l’accesso SSH ai server Linux

In genere è una buona idea disabilitare completamente sia il login di root tramite SSH che l’accesso SSH basato su password. Mentre il testo della password nell’autenticazione basata su password viene trasmesso in forma criptata dalle chiavi host SSH che vengono scambiate durante l’handshake effettuato prima del login SSH client/server, la password viene comunque trasmessa attraverso più reti in qualche modo. Questo è un altro aspetto della superficie di attacco: se le chiavi host del server SSH sono state generate con un algoritmo vecchio/insicuro, ad esempio, le password possono essere ignorate.

I login con chiave SSH non sono vulnerabili a questo tipo di attacco; le chiavi pubbliche sono le uniche parti che vengono trasmesse in “testo normale” e sono state progettate per la distribuzione pubblica. Come per la tua chiave privata stessa, la frase di accesso utilizzata per sbloccarla durante l’accesso alla chiave SSH non viene trasmessa in rete.

Utilizza le chiavi SSH per l’autenticazione

Si noti che i frammenti di codice qui sotto sono annotati con i commenti dell’autore indicati con “##” a scopo didattico.

1. Genera una chiave SSH utilizzando il comando ssh-keygen. Per impostazione predefinita, viene utilizzato il formato di chiave di crittografia RSA, standard del settore, ma si consiglia di utilizzare lo standard di crittografia a curva ellittica ed25519, più veloce e sicuro.
   
   

   user@host:~> ssh-keygen -t ed25519   
   Generazione della coppia di chiavi ed25519, pubbliche/private. Inserisci il file dove salvare la chiave (/home/user/.ssh/id_ed25519): 
   Inserisci la frase di accesso (vuoto se non si ha la frase di accesso):
   Inserisci nuovamente la stessa frase di accesso:
   La tua identificazione è stata salvata in /home/user/.ssh/id_ed25519
   La chiave pubblica è stata salvata in /home/user/.ssh/id_ed25519.pub
   L'impronta digitale chiave è: SHA256:NjPk3GbSIL6wdITiSrEQ3U9uXqqaYJdtS62cwCahKoM user@host
   L'immagine randomart della chiave è:
   +--[ED25519 256]--+
   |.. . |
   | .. ... |
   |... .+o o |
   |..o. o+=.+ |
   | +. ooooS = |
   |o.o.o++o B |
   |=o *.=.. |
   |E.+.* + |
   |o.o. = |
   +----[SHA256]-----+ 
   user@host:~>

2. Copia la tua chiave pubblica sulla propria piattaforma di hosting online. Se disponi ancora della password di accesso al server in questione, puoi usare il comando ssh-copy-id per impostare automaticamente i file di configurazione SSH dell’account remoto con la chiave SSH appena generata e copiata nei punti giusti:
   
   

   ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@remotehost

3. Modi di utilizzo delle chiavi SSH per l’accesso:A) Direttamente nella riga di comando:
   

   ssh -i ~/.ssh/id_ed25519 remoteuser@remotehost:port

   O utilizzando il file ~/.ssh/config

4. Modifica il file ~/.ssh/config con un qualsiasi editor di testo. Esegui questa operazione come account/utente che utilizzerà la configurazione SSH per connettersi da remoto.
5.  Aggiungi i canali nel seguente formato:
   
   

   Host server1   ## Per un facile utilizzo, etichetta/gestisci a piacere
   Hostname server1.example.com   ## Nome del host reale/IP reale
   User remote_user_1  ## Nome dell’utente Linux remoto
   Port 12345  ## Porta remota, predefinita 22
   IdentityFile ~/.ssh/id_ed25519  ## NB! File della chiave privata
   ForwardX11 yes ## Opzionale, inoltra le applicazioni remote con interfaccia grafica
   
   Host server2  
   Hostname server2.example.com
   User remote_user_2
   Port 34567 
   IdentityFile ~/.ssh/id_ed25519

   
   Tra i canali devono esserci spazi bianchi verticali.

6. Ora è possibile effettuare l’SSH semplicemente digitando:
   
   

   ssh server1
   

   Poiché tutto il resto è specificato sotto l’etichetta del canale nel file .ssh/config. Suggerimento: se hai scelto il completamento con schede di Linux (alias completamento bash), sarai contento di sapere che il tuo file di configurazione SSH si inserisce automaticamente nei sistemi di completamento bash della maggior parte delle moderne distribuzioni Linux.

Disabilita l’autenticazione del login e della password di root SSH

1. Assicurati di poter accedere con la tua chiave SSH. Se il sistema non funziona correttamente, è possibile che ci si chiuda fuori dal sistema.
2. Utilizza il tuo editor preferito come root per modificare le seguenti righe in  /etc/ssh/sshd_config con le seguenti impostazioni:
   
   

   PermitRootLogin no
   
   ChallengeResponseAuthentication no
   
   PasswordAutenticazione no
   
   KbdInteractiveAuthentication no

3. Facoltativamente, fai funzionare il tuo server SSH su una porta non standard:
   
   

   Port 12345

4. Salva il file e ricarica il servizio SSH:
   
   

   sudo systemctl restart sshd

5. Ora prova ad accedere tramite SSH senza la chiave SSH:
   
   

   ssh remote_user_1@server1 [-p port]
   

   Se non è possibile accedere senza specificare una chiave SSH, il passaggio è stato eseguito correttamente.

Implementazione di un firewall su server Linux

Se stai gestendo un server Linux di produzione e la tua distribuzione è dotata di un firewall preconfigurato, sei già a buon punto. Quando i dati di un server di produzione sono esposti a Internet, è meglio proteggerli implementando un firewall. Le varianti di Enterprise Linux/Red Hat tendono a fornire firewalld, mentre Debian/Ubuntu fornisce ufw (“Uncomplicated Firewall”). Consulta man firewall-cmd o man ufw per i dettagli.

Configurazione delle regole e dei criteri del firewall

Le regole ed i criteri del firewall, una volta superati i dettagli, si riducono a “bloccare tutto tranne ciò che io permetto specificamente”; anche in questo caso, sono generalmente preconfigurate con valori validi predefiniti sui sistemi Linux moderni, specialmente sulle varianti di Linux per le aziende. Tutti i casi d’uso non coperti da queste impostazioni predefinite non rientrano nell’ambito di questo documento.

Monitoraggio e gestione del firewall

• Entrambi firewalld e ufw si collegano ai principali sistemi di registrazione journald e/o [r]syslog.
• Oltre agli strumenti di gestione del firewall a riga di comando firewall-cmd e ufw,  altre interfacce di gestione remota come Cockpit, WebMin e YaST offrono moduli che consentono la gestione del firewall. Anche altri strumenti di gestione remota come ansible e puppet dispongono di moduli per la configurazione e la gestione automatica del firewall.

Protezione dei servizi rivolti alla rete

Le best practice per la protezione dei servizi rivolti alla rete:

• Il sistema deve contenere il minor numero possibile di codici.
• Esegui il minor numero possibile di servizi.
• Non eseguire un servizio pubblico come root. 
• I server non hanno bisogno di un’interfaccia grafica. Codice estraneo e servizi in esecuzione implicano una maggiore superficie di attacco.
• I servizi Linux si basano sulla protezione del sistema con certificati di crittografia. Certbot/Let’s Encrypt offre il processo più semplice per generare certificati di crittografia gratuiti.
• La maggior parte dei servizi Linux ascolta su porte separate per le proprie connessioni sicure e non sicure; consulta le pagine del manuale dei servizi in questione per i dettagli sulla sicurezza e sulle altre opzioni di configurazione.
• È possibile utilizzare il comando netstat -tulpen per vedere le porte su cui il sistema è in ascolto (a prescindere dal fatto che siano bloccate o meno dal firewall; questo comando mostra le porte in ascolto per ogni processo) 

Il minimalismo è importante per la sicurezza dei server Linux quanto l’azione

Nessuna azione a posteriori può sostituire le scelte giuste fatte fin dall’inizio: nell’attuale mondo connesso al cloud, la scelta della distribuzione di server Linux e delle soluzioni di gestione remota è più importante che mai. Il software di gestione remota Linux incorporato di NinjaOne ti offre la libertà di utilizzare qualsiasi piattaforma di sistema operativo dell’endpoint rimanendo al contempo sicuro e protetto.

Si può affermare con certezza che la maggior parte delle infrastrutture tecnologiche delle PMI comprende alcuni server Linux come parte della loro infrastruttura fondamentale. Se hai un sito web, è probabile che sia in esecuzione su un server Linux; se utilizzi le operazioni bancarie online, è probabile che dipendano dalla sicurezza di decine di server Linux. Dato che anche lo stesso Android è (in modo chiaramente semplificato) un kernel Linux con sopra un po’ di interfaccia grafica, se stai leggendo questo articolo su uno smartphone, la questione della sicurezza di Linux potrebbe essere letteralmente più vicina al tuo cuore di quanto tu possa pensare.