Linux è davvero invulnerabile a virus e malware?

Per una volta, partiamo dalla conclusione: no, Linux non è immune ai malware. Tuttavia, la sua architettura, i modelli di permessi e l’approccio basato su distribuzioni aperte (molte distro differenti riducono l’efficacia delle campagne malware “one-size-fits-all“), rendono infezioni e attacchi più difficili rispetto ad altri sistemi. Eppure, considerando la sua ubiquità nell’infrastruttura digitale globale, Linux rappresenta un bersaglio strategico e massivo per gli aggressori (threat actors).

Linux come bersaglio massivo

Spesso si sostiene che Linux sia sicuro semplicemente perché è meno diffuso sui desktop rispetto ad altri sistemi operativi. Tale visione, tuttavia, è profondamente sbagliata perché ignora il ruolo cruciale a livello server.

“Il pinguino” di fatto alimenta il 90% dei sistemi che compongono la parte infrastrutturale della rete Internet; la maggioranza dei server Web esposti sulla rete pubblica eseguono Linux; l’enorme mole di dispositivi IoT (Internet of Things) basa il suo funzionamento proprio su kernel Linux, ampliando ulteriormente la superficie di attacco.

L’esistenza di una minaccia concreta è dimostrata da alcuni esperimenti regolarmente posti in essere. Ad esempio, è stato possibile raccogliere una lista di malware Linux perfettamente funzionanti semplicemente esponendo un honeypot su Internet per qualche giorno.

Il punto debole: le configurazioni degli utenti

L’analisi dei vettori di infezione rivela un dato cruciale: la più grande debolezza nei sistemi Linux non risiede nelle vulnerabilità intrinseche del codice, ma piuttosto nelle misconfigurazioni ovvero nelle configurazioni scorrette, non sicure, adottate dagli utenti.

Gli attori delle minacce ottengono l’accesso iniziale non tanto sfruttando vulnerabilità sconosciute o utilizzando exploit complessi, quanto piuttosto facendo leva su problematiche di sicurezza introdotte dagli utenti.

C’è poi il problema della mancata applicazione degli aggiornamenti software, comunque ad esempio anche ai sistemi Windows. Kernel, servizi e applicazioni hanno vulnerabilità: se non vengono corrette mediante l’applicazione delle patch correttive, un exploit locale o remoto può portare a escalation di privilegi e all’esecuzione di codice dannoso.

Ogni distribuzione, utilizzata sia lato client che lato server, ha il suo meccanismo di aggiornamento che fa leva sul package manager. L’aggiornamento dei componenti “core” del sistema operativo e di tutte le applicazioni installate è essenziale per scongiurare buona parte degli attacchi. Ad esempio, la recente scoperta di una vulnerabilità nel comando sudo fa capire quanto sia fondamentale l’applicazione tempestiva delle patch.

Alcuni esempi di vettori di attacco

Oltre all’esposizione su Internet (se un sistema Linux è raggiungibile attraverso la rete pubblica, l’amministrazione deve preoccuparsi di proteggerlo evitando attacchi remoti e accessi non autorizzati), esistono vettori di attacco specifici che sfruttano abitudini operative non sicure o difetti nei meccanismi di distribuzione del software.

• Esecuzione di script non attendibili. Uno dei vettori di attacco più significativi e preoccupanti è l’abitudine di tanti utenti a eseguire comandi e script trovati online senza pensarci troppo sopra. La pratica di eseguire il comando curl reindirizzato (pipe) a bash (curl | bash) è considerata estremamente rischiosa. Eseguire script di terze parti è in generale una pessima idea e rappresenta un grande vettore di attacco. È vero che alcuni software legittimi utilizzano il curl reindirizzato per semplificare l’installazione (uno a caso è l’ottimo CasaOS, come documentano le opzioni di installazione), tuttavia prima di eseguire comandi simili bisognerebbe riflettere con la massima attenzione e analizzare nel dettaglio il codice eseguito sul sistema.
• Pacchetti maligni Flatpak e Snap. I moderni formati di pacchettizzazione universale come Flatpak e Snap possono rappresentare un rischio se gestiti senza cautela, poiché possono ospitare componenti dannosi.
• Uso di software caricati da terze parti: Chiunque può caricare app su store come lo Snap Store. Spesso, le app disponibili in questi store non sono caricate direttamente dallo sviluppatore originale, ma da una terza parte. È fondamentale interrogarsi sull’affidabilità di queste terze parti. Un esempio di minaccia reale si è verificato circa un anno fa, quando lo Snap Store fu colpito da app che rubavano criptovalute.
• Debolezze nel sandboxing di Flatpak: La sicurezza di Flatpak non è considerata ottimale. Molti pacchetti Flatpak sono distribuiti con permessi ampi: se un’applicazione malevola possiede tali permessi, fuoriuscire dalla sandbox (sandbox escaping) diventa un gioco da ragazzi. È essenziale applicare le stesse precauzioni che si userebbero per qualsiasi altra app: scaricare software solo da sviluppatori verificati e ben noti, evitando installazioni casuali di software che potrebbero risultare dannosi.

Una forma di attacco che sta purtroppo diventando popolare e che non dipende direttamente dagli utenti, ha a che fare con la supply chain. Negli ultimi anni si stanno registrando aggressioni che puntano ad attaccare pacchetti terzi o immagini di container. Se un aggressore riesce a introdursi nella “filiera” della distribuzione software e a inserire codice malevolo, tutte le installazioni ne risulteranno automaticamente infettate.

Attacco al server SSH

Un server Linux di solito si controlla collegandosi al server SSH locale. Gli aggressori remoti avviano continuamente campagne di brute‑forcing o di credential stuffing contro il servizio SSH, provando automaticamente combinazioni di username/password.

Se viene scoperta una credenziale valida — specialmente di un account con permessi elevati o con accesso diretto — l’attaccante esegue uno script remoto che scarica ed esegue un cryptominer o un agente persistente. Il payload è spesso offuscato (es. payload in Base64 o inline‑bash) e viene eseguito in background con meccanismi come nohup, screen o “daemonizzazione” via & per sopravvivere alla chiusura della sessione.

Comandi diagnostici

# processi che consumano più CPU (controlla anomalie, non solo il consumo)
ps -eo pid,user,pcpu,pmem,comm --sort=-pcpu | head -n 20

# processi o script che risiedono in /tmp (spesso usata dai dropper)
lsof +D /tmp | egrep 'bash|sh|python|perl' || true

# cercare chiavi SSH aggiunte (scansiona gli home degli utenti)
grep -R "ssh-(rsa|ed25519|dss)" /root/.ssh /home/*/.ssh 2>/dev/null

# log SSH: login falliti/riusciti (adattare filtro a distro)
journalctl -u ssh.service --since "48 hours ago" | tail -n 200

Web application RCE e webshell

Una vulnerabilità di Remote Code Execution (RCE) o un meccanismo per il caricamento di file che non esercita una validazione corretta, può consentire a un aggressore remoto di caricare una webshell (es. cmd.php, shell.py, s.aspx) nella webroot.

La webshell è eseguita con i permessi del processo webserver (es. www-data), permettendo all’attaccante di eseguire comandi sul file system, leggere file di configurazione (contenenti credenziali), scaricare altri tool e tentare aggressioni verso sistemi adiacenti. Le webshell possono essere offuscate e mascherate con nomi innocui.

Comandi diagnostici

# file modificati di recente nella webroot (verificare autori e hash)
find /var/www -type f -mtime -14 -ls

# cercare pattern tipici delle webshell (adattare alle tecnologie usate)
grep -R --exclude-dir=cache -nE "eval\\(|base64_decode\\(|shell_exec\\(|passthru\\(|system\\(" /var/www || true

# processi associati al webserver (controllare child process inattesi)
ps -u www-data -o pid,ppid,cmd --forest

Rootkit utente e kernel

Un rootkit in userspace può essere installato aggiungendo una libreria malevola in /etc/ld.so.preload; un rootkit kernel può essere caricato come modulo (se Secure Boot non blocca moduli non firmati). Questi componenti intercettano chiamate di sistema per nascondere file, processi, e connessioni.

Comandi utili

cat /etc/ld.so.preload
lsmod | grep -v "^$"
dmesg | tail -n 100
# controllare con rootkit scanner
sudo rkhunter --check

Persistenza tramite systemd, cron, file di login e autostart

Gli attaccanti che riescono a ottenere accesso a un host Linux cercano di garantire sopravvivenza del payload dopo logout e reboot. Le tecniche più comuni consistono nella creazione di unità systemd malevole, l’inserimento di cron job (sia utente che di sistema), la modifica degli script di login (~/.bashrc, /etc/profile, /etc/profile.d/*) o l’aggiunta di script a punti di avvio tradizionali (/etc/rc.local, /etc/init.d nei sistemi legacy). Queste modifiche permettono l’esecuzione automatica di downloader, backdoor o script che ripristinano componenti rimossi dall’operatore.

Comandi diagnostici

# vedere unità recenti e rispettive proprietà
ls -la /etc/systemd/system /lib/systemd/system
# elenca unità abilitate (stato enable = persistente al boot)
systemctl list-unit-files --state=enabled

# esamina il contenuto di unità sospette
sudo sed -n '1,200p' /etc/systemd/system/<unità_sospetta>.service

# cron di root e di tutti gli utenti
sudo crontab -l -u root
for u in /var/spool/cron/crontabs/*; do echo "---- $u"; sudo cat "$u"; done

# cercare comandi di rete/remote in cron e init
grep -R --line-number -E "wget|curl|bash|nc|perl|python -c" /etc/cron* /var/spool/cron /etc/systemd/system 2>/dev/null

# file di login modificati recentemente
find /home /root /etc -type f -name ".bashrc" -o -name "profile" -mtime -7 -ls

Escalation di privilegi via SUID/SGID vulnerabili

I bit SUID/SGID, come abbiamo ricordato in altri nostri articoli, consentono a un eseguibile di avviarsi con i permessi del proprietario (spesso root). Se un programma SUID contiene una vulnerabilità (buffer overflow, possibilità di lanciare una shell o eseguire comandi arbitrari), un utente sprovvisto di privilegi può sfruttarla per lanciare un’escalation e acquisire diritti più elevati. Spesso gli attaccanti cercano SUID legati a file poco noti, binari obsoleti o wrapper che invocano /bin/sh in modo non sicuro.

Comandi diagnostici

# lista SUID/SGID su tutto il filesystem (l'output può essere grande)
sudo find / -xdev -perm /6000 -type f -exec ls -l {} \; 2>/dev/null

# SUID creati o modificati di recente (ultimi 7 giorni)
sudo find / -xdev -perm /6000 -type f -mtime -7 -exec stat --format '%n %y %s' {} \;

# utenti con UID 0
awk -F: '$3==0 {print $1":"$3":"$6":"$7}' /etc/passwd

In generale, è opportuno ridurre al minimo indispensabile i file binari con bit SUID/SGID. La rimozione del bit SUID è consigliata quando non strettamente necessario.

Prima di usare l’istruzione sudo chmod u-s /path/to/suid-binary per l’eliminazione del bit, è opportuno verificare l’impatto delle modifiche avvalendosi di un ambiente di test.

Conclusioni

L’idea che Linux sia “immune ai malware” è ormai un mito da sfatare. Sebbene la sua architettura modulare, i modelli di permessi e la varietà delle distribuzioni garantiscano un livello di sicurezza intrinseco superiore rispetto ad altri sistemi, nessun ambiente può dirsi realmente esente da rischi.

La minaccia è concreta, soprattutto nei contesti server e IoT poiché Linux rappresenta la spina dorsale dell’infrastruttura digitale globale. La sicurezza non è determinata solo dalla robustezza del kernel, ma dalla consapevolezza e dalla disciplina dell’amministratore: aggiornamenti tempestivi, gestione attenta dei permessi, verifica delle fonti software e monitoraggio continuo sono le vere barriere contro gli attacchi. La resilienza di un sistema Linux non dipende quindi tanto dal codice, ma piuttosto dalle persone che lo configurano, lo mantengono e lo difendono.