Linux è un sistema operativo abbastanza sicuro ma non è certo invulnerabile, soprattutto nella configurazione iniziale di molte distro, forzatamente generica per venire incontro alle necessità ed esigenze del più ampio spettro di utenti; possiamo sicuramente migliorare la sicurezza del nostro sistema con un valido aiuto per scovare qualche falla. Lynis è uno script per shell, rilasciato con licenza open source, creato dalla società CISOfy (che offre anche una versione a pagamento per le aziende) per il controllo della sicurezza dei sistemi Unix (Linux, quindi ma anche MacOS, BSD, ... ) che effettua una scansione del sistema in cerca di vulnerabilità note o configurazioni deboli e può essere utilizzato su computer Desktop che su server.
Il primo passo è, ovviamente, quello di installare Lynis sul sistema da controllare; potete cercarlo nei repository della vostra distro e quasi sicuramente ne troverete una versione ma assicuratevi che sia l'ultima disponibile. Nel caso non lo fosse (o non fosse proprio presente), potete ottenere l'ultima versione, aggiungendo il repository di Lynis alla vostra distro (come descritto sul sito ufficiale) o, per chi utilizza git, può scaricarlo direttamente dal Github di CISOfy, oppure, opzione consigliata, è possibile scaricare il tarball, un file compresso con estensione .tar.gz, scompattarlo dove ci torna più comodo ed eseguire lo script da lì. Per questa guida seguiremo quest'ultima via.
» Leggi: Come si installa un programma su Linux?
Se siamo su un computer Desktop, apriamo un emulatore di terminale oppure connettiamoci via SSH al nostro server e digitiamo i seguenti comandi (avendo cura di sostituire a <version> il numero di versione disponibile, controllandolo prima sulla pagina di download):
wget https://cisofy.com/files/lynis-<version>.tar.gz
A questo punto, dato che si tratta di un programma inerente la sicurezza del nostro sistema (ma vale per tutti i programmi!!) controlliamo l'autenticità e l'integrità del pacchetto appena scaricato. Per prima cosa, annotiamo il fingerprint della chiave GPG di CISOfy, che possiamo trovare qui (nel momento in cui scrivo è C2FDE6C4) e procuriamoci la chiave GPG pubblica di CISOfy con il comando:
gpg --keyserver keyserver.ubuntu.com --search-key C2FDE6C4
Confermiamo digitando il numero della chiave identificato dalla dizione software signing, in questo caso 1. Adesso procuriamoci l'hash firmato del pacchetto contenente lynis, prima scaricato, sempre disponibile nella pagina di download (anche in questo caso, sostituire <version> con il numero di versione!):
wget https://downloads.cisofy.com/lynis/lynis-<version>.tar.gz.asc
E infine passiamo alla verifica con il comando
gpg --verify lynis-<versione>.tar.gz{.asc,}
L'output del comando sopra deve restituire Firma valida da CISOfy.
Se è così possiamo scompattare il pacchetto digitando:
tar xvzf lynis-*.tar.gz
Il lungo output mostrerà tutti i file che vengono scompattati dall'archivio
A questo punto possiamo portarci nella cartella contenente l'eseguibile e lanciare lynis!
cd lynis
./lynis
Dato che l'eseguibile non si trova nei percorsi contenuti nella variabile $PATH, dovremo indicare il percorso relativo (o assoluto) all'eseguibile lynis: ci verrà così mostrato una piccola guida con i possibili comandi e le principali opzioni e questo è già un buon segno perché significa che lynis funziona perfettamente. Come suggerito possiamo vedere tutte le altre possibili opzioni da passare ai vari comandi con ./lynis show options.
Adesso che tutto funziona, possiamo passare al test vero e proprio impartendo il comando
./lynis audit sistem --quick
Aggiungiamo l'opzione --quick per evitare che lynis si fermi dopo ogni sezione del test e vada avanti in automatico fino alla fine così che possiamo lasciarlo lavorare e nel frattempo dedicarci ad altro. Al termine della scansione possiamo scorrere la schermata per vedere tutti i risultati del test (oppure potremo controllare il file lynis.log creato nella home del nostro utente), ma già la sezione finale della schermata di test ci da un'idea di come siamo messi; vediamo un po' in dettaglio l'output completo partendo proprio dalla sezione finale
L'indicatore principale è quello contrassegnato da Hardening index che restituisce un valore da 1 a 100 per indicare il livello di sicurezza complessivo del nostro sistema (sul mio sistema di test, 60... bene ma non benissimo!); subito sotto altre due importanti notizie: il numero di test effettuati (Test performed: 230) e i plugin attivati (Plugin enabled: 0). Questi ultimi sono dei test particolari per provare la sicurezza di determinati programmi o configurazioni e possono essere creati seguendo le linee guida.
Ancora sotto la verifica dei componenti di sicurezza firewall e antivirus (V verde significa che è stato rilevato mentre la X rossa significa assente o non trovato), il tipo di scansione effettuato Pentest (come utente normale), i moduli di Lynis attivi, test di sicurezza (Security audit) e scansione di vulnerabilità (Vulnerability scan) mente lo stato di conformità (Compliance status, funziona dedicata soprattutto alle aziende) è sconosciuto ovviamente perché non dichiarato e il percorso ai file contenenti il risultato della scansione appena eseguita.
Ancora più sotto i test saltati perché il test è stato eseguito come utente normale piuttosto che come root e proprio in fondo un suggerimento (tip): possiamo creare una scansione personalizzata aggiungendo le nostre impostazioni al file custom.prf.
Saltiamo adesso all'inizio della schermata, dove un banner ci informa nuovamente che la scansione viene fatta come utente normale; più sotto siamo informati che in questa modalità verranno saltati tutti quei test che richiedono i permessi di root e che altri test potrebbero fallire o dare un risultato diverso dal vero.
Più sotto sono presenti tutte le informazioni di base del nostro sistema: distro, versione, kernel, architettura del processore. Infine notiamo che non sono stati abilitati i plugin (perché non presenti nella cartella dedicata!).
Nella successiva sessione Boot and services viene controllato il Service Manager (systemd), la presenza di GRUB2 e se questo è protetto da password o meno, i servizi in esecuzione e quelli che sia avviano al boot e poi si controlla lo stato di sicurezza dei servizi in esecuzione tramite la funzione di analisi propria di systemd.
Ad una prima occhiata questa sezione sembra proprio tragica visto l'abbondanza di UNSAFE (non sicuro) rossi presenti ma, in realtà, questo è bene o male lo standard di qualunque distro che utilizzi systemd come sistema di init.
Per prima cosa dobbiamo chiarire che il risultato di ogni servizio si basa solo sull'applicazione o meno delle funzioni di sandbox proprie di systemd (e che nessun altro sistema di init ha!!) e non prende in considerazione nessun altro meccanismo attivo per limitare i servizi come eseguirli come utente dedicato, sistemi MAC (Mandatory Access Control come AppArmour o SELinux), Access Control List o il fatto che il servizio stesso non sia proprio exploitable... Per di più, per il corretto funzionamento di alcuni servizi è assolutamente necessario che questi non siano limitati dalla sandbox di systemd!! In definitiva, quella che sembra una pagina tragica non deve invece far preoccupare!!
Proseguendo ancora vediamo lo stato delle configurazioni riguardanti Kernel (versione, configurazione, moduli caricati,... ); in questa sezione possiamo vedere anche il runlevel (dal quale possiamo capire se il sistema ha un display manager o meno). Seguono Memoria e processi, Utenti, Gruppi e Autenticazione (controllando tra l'altro diversi aspetti che riguardano la sicurezza della password) e Shell. Ricordiamo che i risultati di colore verde sono indice di una buona configurazione, quelli bianchi sono neutri (ne troppo bene, ne troppo male) mentre quelli gialli sono quelli che possono essere migliorati e in queste sezioni vediamo anche dei risultati con la scritta SUGGERIMENTO: significa che al termine del report (ci arriveremo a breve) troveremo dei consigli su come rendere più sicuri questi punti.
Prestate attenzione: i suggerimenti se applicati in blocco, senza nessuna riflessione, possono portare ad un sistema tanto sicuro quanto impossibile da utilizzare!! Applicate solo i suggerimenti che riguardano funzioni che non utilizzate mai e se non siete sicuri, meglio chiedere (anche qui sul forum) o lasciar perdere!
Ancora vediamo che l'analisi di lynis ha controllato il File system (con i punti e le opzioni di mount), i dispositivi USB (USB Devices), lo Spazio di archiviazione anche esterno (come il Network File System o NFS), la configurazione del hostname, dei DNS, del file /etc/hosts e dei nomi di dominio quindi gestori pacchetti e port (quest'ultimo tipico più che altro dei sistemi BSD).
Un esempio di quanto poco sopra detto è usb-storage driver che è segnato come NOT DISABLED (non disabilitato) (non a caso in bianco!): tra i suggerimenti in fondo c'è quello di disabilitare questo driver ma se lo facciamo ci sarà impossibile connettere qualunque dispositivo USB di archiviazione dati (chiavette, hard disk ma anche lettori esterni di CD/DVD). Questo può essere utile forse per rendere più sicuro un server ma limiterebbe tantissimo l'utilizzo "Desktop" dove gli utenti normalmente utilizzano sistemi di archiviazione esterni.
Vengono poi controllati la configurazione della rete, delle stampanti, di programma per mail e messaggi (non i client ma proprio i servizi per gestire i protocolli di questi sistemi di comunicazione!), la presenza di un firewall e il suo stato e altri programmi molto spesso in esecuzione su server piuttosto che computer Desktop.
Successivamente vengono controllati se è presente un sistema di registro degli eventi (Logging and files) e se sono presenti alcuni servizi conosciuti per essere insicuri (ma, in alcuni ambienti, sempre fondamentali). Interessante (ma forse non tanto utile... ) il fatto che si controlla il messaggio che appare come intestazione nella shell di login (Banner e identification) e che sia marcato come DEBOLE se non sono presenti avvisi o ammonimenti...
Si controllano poi se sono presenti operazioni programmate (Schduled tasks), se presente un sistema di registrazione dei comandi e dei processi (Accounting), se presente un metodo di sincronizzazione dell'orario e quando è stato sincronizzato l'ultima volta (elementi molto più importanti di quanto si pensi!) e infine, sotto Cryptography, si controllano se ci sono certificati SSL scaduti, se il kernel ha sufficiente entropia per generare numeri casuali (essenziali quando si parla di crittografia) e se sono presenti soluzioni hardware o software sempre per la generazione casuale di stringhe numeriche.
Sempre proseguendo nell'analisi dell'output di lynis, possiamo vedere che cerca sistemi di virtualizzazione (o macchine virtuali) e container e vari sistemi di sicurezza, tra cui: i già menzionati sistemi di Mandatory Access Control, sistemi per la verifica dell'integrità dei file, sistemi per la prevenzione e rilevazione delle intrusioni e per il rilevamento di malware.
» Leggi: ClamAV: antivirus open-source, "on demand" e con protezione residente, per il nostro Linux Mint
Vengono anche controllati i permessi di determinati file di sistema (tra cui la configurazione di grub, i file contenenti utenti e gruppi e quelli per le operazioni programmate) e della home dell'utente.
Nella successiva sezione si controllano alcuni parametri del kernel, modificabili tramite sysctl: anche in questo caso possiamo trovare diverse voci in rosso con la dizione DIFFERENT perché differenti da quelli che lynis si aspetterebbe di trovare ma anche in questo caso non è detto che siamo di fronte a qualcosa di cui preoccuparsi (almeno, non troppo) ed è segno evidente di questo l'ultima riga di questa schermata dove si può leggere, in verde: Great, no warnings.
Si controllano poi se sono presenti compilatori, programmi per la scansione di malware e programmi in formato non direttamente eseguibile (Non-native binary formats) come ad esempio i programmi scritti in java che vengono compilati al momento dell'esecuzione.
Concludono la schermata informazioni riguardanti (ancora una volta) i plugin e i Test su misura (Custom).
Per finire i Suggerimenti: per ogni test con un risultato diverso da quello aspettato da lynis (ma non necessariamente preoccupante) viene indicato un suggerimento, seguito dal codice del test posto dentro parentisi quadre([TEST-ID]) e un link al sito di CISOfy (e raggiungibili tutti partendo da questa pagina) che contiene una breve descrizione del test e, solo in alcuni casi, informazioni più o meno dettagliate sulle modifiche da fare per rendere più sicuro il nostro sistema.
Concludono i suggerimenti altre operazioni da poter fare, come controllare i dettagli di un test (con il comando ./lynis show details TEST-ID) e leggere il log per tutti i dettagli dei test; quest'ultima è un operazione interessante perché consente di vedere quanti punti vengono assegnati per ogni test e quanti ne abbiamo ricevuti con la nostra configurazione, permettendo di identificare facilmente i punti sul quale possiamo lavorare per aumentare velocemente l'Hardening index già visto all'inizio.
CONCLUSIONI
Un valido aiuto per capire meglio come fare sicurezza su Linux, facile da utilizzare e, nel complesso, abbastanza chiaro nel risultato della scansione. Può salvare un server da una configurazione maldestramente sbagliata ma in genere richiede un'accurata valutazione dei risultati per ottenere il massimo senza compromettere l'usabilità del sistema. Ho trovato strano che ancora non prenda in considerazione l'utilizzo di programmi isolati dal sistema (come Flatpak, Snap o AppImage) e l'esecuzione del server grafico X, come root o come utente non privilegiato, piuttosto che Wayland.
