Linux è davvero IMMUNE ai malware Windows?

Una delle convinzioni più diffuse tra gli utenti Linux è che il sistema sia praticamente immune a virus e malware sviluppati per Windows. La percezione nasce da più fattori: la differente architettura dei sistemi operativi e la gestione dei permessi più rigorosa su Linux. Tuttavia, il crescente utilizzo degli strumenti di compatibilità come Wine, Proton e Bottles, l’esecuzione di Linux in ambienti misti con file condivisi con Windows e la diffusione di server Linux che ospitano file destinati a client Windows, pongono qualche interrogativo.

Un malware progettato per Windows può in qualche modo danneggiare i dati gestiti con un sistema Linux? E quanto sono affidabili strumenti di scansione come ClamAV nel rilevare queste minacce? La risposta non è immediata: la compatibilità, la configurazione del sistema, l’uso delle tecniche di sandboxing e la consapevolezza dell’utente determinano il livello di rischio reale.

Perché Wine, Proton e Bottles sono sempre più protagonisti

Strumenti come Wine, Proton e Bottles non sono una semplice curiosità per smanettoni: sono il risultato della combinazione di miglioramenti tecnici (traduzione efficiente delle API Windows, supporto grafico moderno,…), di investimenti industriali (Valve / Steam + Steam Deck) e impegno della comunità (ProtonDB, Proton-GE, Bottles) che hanno abbattuto la barriera principale, uno dei principali ostacoli per l’adozione di Linux lato desktop: la mancanza di compatibilità con app e giochi Windows.

Valve più Proton: spinta industriale e integrazione con Steam

Valve ha integrato Proton dentro Steam (Steam Play), curandone l’evoluzione e risolvendo specifici problemi di compatibilità per migliaia di titoli. Linux si è trasformato così da una soluzione di nicchia a una piattaforma praticabile per il gaming. La spinta commerciale è stata amplificata dal successo dello Steam Deck, che ha portato visibilità e interesse su larga scala.

Migliorie tecniche reali: traduzione API e grafica Vulkan (DXVK / vkd3d)

Proton e Wine non emulano: traducono le API di Windows in chiamate POSIX/Linux e usano layer come DXVK (Direct3D→Vulkan) e vkd3d per convertire Direct3D in Vulkan. È così diventato possibile ridurre l’overhead e migliorare le prestazioni in modo incisivo. Il continuo sviluppo di Wine (ultime release con aggiornamenti a vkd3d, Direct3D ecc.) ha migliorato compatibilità e resa grafica.

Comunità e riscontro degli utenti

ProtonDB raccoglie report pratici sugli esiti reali dei giochi sotto Proton; progetti come Proton-GE e fork “tuning” forniscono build con patch extra che risolvono problemi specifici. Si è così formato un ecosistema che contribuisce ad accelerare la risoluzione di bug e aumenta il numero di applicazioni che “funzionano bene” su Linux. Non soltanto giochi, quindi, ma anche programmi di qualsiasi categoria.

Migliore interfaccia utente e strumenti per i non esperti (Bottles, Lutris)

Strumenti come Bottles e Lutris rendono la gestione di Wine, di versioni multiple, di librerie e di configurazioni molto più semplice: l’interfaccia grafica (GUI), la disponibilità di installer “one-click” per i giochi, la gestione dei runtime e le opzioni di isolamento, abbassano la curva d’apprendimento e rendono l’esperienza più simile a quella su Windows.

Bottles, in particolare, facilita la separazione delle app in esecuzione dal resto del sistema e si avvale di container per ogni programma, facilitando il lavoro anche da parte degli utenti meno smaliziati.

Tessuto hardware e software migliore

Driver grafici migliori, performance ARM/AMD in crescita, Vulkan come standard e miglior supporto per scaling/hiDPI hanno ridotto i gap storici che scoraggiavano l’uso di Linux sul desktop.

Wine e Proton si sono adattati a questi cambiamenti (es. supporto Arm/ARM64, miglioramenti grafici nelle release recenti) e c’è una sempre maggiore collaborazione da parte dei produttori hardware che intervengono, con il proprio personale, sul processo di patching e ottimizzazione lato Linux.

Premessa tecnica: cosa significa “malware per Windows” rispetto a “malware per Linux”

I file binari Windows sono tipicamente file PE (Portable Executable) che tipicamente usano le API Win32. I binari Linux sono in formato ELF, compilati per ABI/Linux syscall table. Un eseguibile progettato per chiamare direttamente le API di Windows non funziona nativamente su Linux perché le chiamate di sistema, le librerie e le convenzioni sono diverse.

L’ABI (Application Binary Interface) di Linux definisce come un programma dialoga col sistema operativo: convenzioni su registri, stack, chiamate di sistema e così via; le syscall table sono l’elenco numerato delle chiamate di sistema che il kernel Linux espone. Il binario ELF usa queste informazioni e convenzioni per interagire con il kernel.

Wine/Proton implementano una compatibilità a livello di libreria/API: non si servono di macchine virtuali ma piuttosto traducono, come abbiamo visto, buona parte delle chiamate API di Windows nelle corrispondenti chiamate POSIX/Linux.

Ciò significa che se un eseguibile Windows gira sotto Wine/Proton, può eseguire azioni (I/O file, rete, process spawning) nel contesto dell’utente Linux che lo ha lanciato.

Ne consegue che non esiste un’immunità assoluta: il malware Windows di per sé NON può essere nativamente eseguito su Linux. Può esserlo nel momento in cui è avviato in un ambiente compatibile (Wine/Proton, VM, container). Inoltre, un malware per Windows presente su un server Linux può ovviamente infettare client Windows che lo dovessero scaricare ed eseguire.

L’accesso ai file da parte del codice Windows è generalmente limitato alla directory dell’unità C: virtuale creata da Wine o da Proton, ma alcuni malware possono sfruttare symlink o path mapping per accedere a $HOME/Documents o ad altre cartelle dell’utente Linux.

Di default, non esiste una sandbox di sicurezza completa in Wine: per un’esecuzione più sicura, si possono usare Firejail, Bottles o macchine virtuali dedicate.

Percorsi concreti di infezione su Linux generati da malware Windows

• Esecuzione sotto Wine/Proton: il vettore più comune. Wine mappa percorsi Windows a parti del filesystem Linux (da C:\Users\... a ~/...), quindi un eseguibile può leggere/scrivere in $HOME a seconda delle configurazioni.
• Esecuzione in VM/Container: malware che gira in una macchina virtuale Windows può sfruttare vulnerabilità dell’hypervisor o del toolkit (raro ma possibile) per superare i confini della virtual machine.
• Script multipiattaforma: malware in linguaggi interpretati (Python, PowerShell Core, Java) possono portare all’esecuzione di operazioni dannose su più sistemi operativi, compreso Linux.
• Supply chain / pacchetti: la compromissione di repository o pacchetti (npm, pip, apt mirror,…) può impattare sui sistemi Linux in modo nativo.

Quanto sono “pericolosi” i malware Windows quando girano su Linux tramite Wine?

Per rispondere sempre alla domanda iniziale, tra i possibili effetti reali un malware che si trovasse ad essere eseguito su Linux tramite Wine potrebbe portare, ad esempio, alla cancellazione o cifratura dei file in $HOME: un ransomware lanciato via Wine può cifrare file accessibili dall’utente.

Ancora, può verificarsi l’invio di credenziali su server gestiti da criminali informatici, l’esfiltrazione di altri dati personali o riservati, il download di altri payload. Di norma, i privilegi utente limitano il “raggio d’azione” del malware. Il software dannoso dovrebbe mette in atto un attacco di privilege escalation sul sistema Linux, meno probabile ma non impossibile.

Facciamo un esempio concreto: un keylogger Windows eseguito sotto Wine può intercettare input nelle finestre che gestisce (i.e. il gioco o l’app Windows) e, se riesce ad accedere a file o inviare dati in rete, trasferire a distanza ciò che ha raccolto. Per acquisire input globali su tutto il desktop da Wine servono ulteriori tecniche o privilegi, ma non è impossibile nel caso di configurazioni permissive.

Un malware progettato per cercare \Windows\System32\ (o meglio %systemroot%\System32) potrebbe fallire nell’esecuzione di molteplici operazioni. Soltanto i malware più sofisticati possono adattarsi o sfruttare l’ambiente Wine per tradurre i percorsi Windows in posizioni Linux valide.

Principi di difesa: come ridurre la superficie d’attacco

La prima regola di un approccio maturo alla sicurezza informatica consiste nell’applicazione del principio del least privilege: e questo non vale soltanto nel “caso particolare” del codice Windows eseguito su Linux ma proprio come linea guida di carattere generale.

Nel caso di specie, nessuna applicazione che interagisce con codice Windows dovrebbe essere eseguita con i privilegi dell’utente principale, tantomeno con permessi di amministratore.

Il suggerimento migliore consiste nel creare un account dedicato – ad esempio steamuser o gamesandbox – e confinare lì l’esecuzione di Wine, Proton o Steam riduce drasticamente il rischio che un eventuale malware possa accedere a documenti personali o credenziali.

La semplice separazione degli utenti, però, non basta, ed è qui che entrano in gioco le tecniche di sandboxing e containment. Strumenti come Firejail permettono di lanciare un’applicazione in un ambiente isolato con una home directory privata, così che i file creati o modificati non contaminino il sistema principale:

# Esegue Steam in un ambiente con directory home privata
firejail --private=~/steam-sandbox steam

È bene verificare le opzioni e la policy: Firejail supporta profili predefiniti per molte app.

Le distribuzioni che fanno largo uso di Flatpak o Snap offrono un primo livello di isolamento già integrato, ulteriormente gestibile con interfacce come Flatseal per limitare i permessi granulari.

Anche Bottles e Lutris, nati per semplificare la gestione dei prefix Wine (una sorta di mini-ambiente a sé stante in cui Wine crea una “installazione Windows virtuale” (con cartelle tipo drive_c, librerie, chiavi di registro, dipendenze, configurazioni, file installati), forniscono opzioni di isolamento che, combinate con un utente dedicato, rappresentano un compromesso efficace tra praticità e sicurezza.

Per attività più delicate, come l’analisi di software sospetti, il confine più robusto resta la macchina virtuale: con QEMU/KVM o VirtualBox è possibile osservare il comportamento del binario in un ambiente “sacrificabile”, senza rischio di compromettere l’host.

Mandatory Access Control (MAC)

Un ulteriore pilastro è rappresentato dal Mandatory Access Control: sistemi come AppArmor e SELinux applicano regole a livello di kernel, imponendo limiti severi alle applicazioni indipendentemente dall’utente che le esegue.

Configurare un profilo specifico per Wine o Steam significa decidere in anticipo a quali directory possono accedere, quali risorse di rete possono utilizzare e quali funzionalità dell’ambiente Linux sottostante possono effettivamente usare.

Debian e Ubuntu abilitano AppArmor di default, Fedora e RHEL si affidano a SELinux, mentre su Arch l’attivazione e la configurazione sono demandate all’utente, richiedendo un lavoro manuale che però ripaga in termini di “controllo fine”.

Hardening del sistema

Non va infine trascurato il rafforzamento generale del sistema: ridurre al minimo i binari con bit SUID attivo per tagliare le gambe a possibili escalation, mantenere kernel e pacchetti sempre aggiornati per chiudere vulnerabilità note, abilitare Secure Boot e, dove possibile, sfruttare un modulo TPM per prevenire l’installazione di rootkit persistenti a livello di boot sono soluzioni ragionevoli e più che praticabili.

Il bit SUID (Set User ID) è un flag dei permessi Unix/Linux che, quando attivo su un file eseguibile, fa sì che quel programma sia avviato con i privilegi del proprietario del file, e non con quelli dell’utente che lo lancia. In pratica, se un binario appartiene a root ed è marcato con SUID, ogni utente che lo esegue ottiene temporaneamente i privilegi di root per quel processo.

È uno strumento utile in alcuni casi (ad esempio il comando passwd deve modificare /etc/shadow anche se lanciato con un utente normale), ma rappresenta anche un potenziale rischio di sicurezza: una vulnerabilità in un binario SUID può consentire a un attaccante di ottenere privilegi elevati.

È possibile individuare i file SUID con il comando find / -perm -4000 -type f 2>/dev/null mentre l’istruzione chmod u-s /percorso/del/binario permette la rimozione del bit SUID quando non necessario.

A tutto ciò si può affiancare una strategia di resilienza operativa: filesystem con supporto per gli snapshot, come Btrfs o LVM con snapper, permettono di tornare rapidamente operativi (ripristinando una precedente configurazione) in caso di cifratura o cancellazione massiva di file.

Linee guida operative quando ClamAV segnala un trojan su Linux

Il mercato pullula di soluzioni EDR (Endpoint Detection and Response) compatibili anche con Linux. Usare lo storico ClamAV non è anacronistico: resta uno strumento valido e utile in scenari specifici (scansione di mail e file server, integrazione in pipeline di upload, scansioni su richiesta), ma oggi la protezione moderna si basa su più livelli: rilevamento comportamentale, EDR con telemetria continua, SIEM/HIDS e sandboxing dinamico.

ClamAV è un motore antimalware open source basato sull’uso di firme virali, con alcune capacità aggiuntive ed è ancora lo standard de-facto per la scansione di mail gateway e file server perché è gratuito, integrabile e capace di rilevare file PE/Macro/PDF noti prima che escano o entrino nella rete. Questo è esattamente il suo punto di forza e la sua ragion d’essere: si occupa di bloccare la diffusione di payload noti, non di bloccare exploit zero-day in memoria o attacchi fileless.

Quando si gestiscono poche macchine personali, ClamAV abbinato con l’utilizzo delle “buone pratiche” (sandboxing, least privilege, backup) può bastare. Per la sicurezza su host Linux  a livello professionale (monitoraggio di processi, rilevamento di syscall sospette, accessi ai device, attacchi da utenti locali), strumenti come Wazuh/OSSEC, Falco (Cloud Native Runtime Security), Velociraptor e le varie soluzioni EDR commerciali (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint e molte altre) coprono il gap lasciato dall’approccio basato solo sulle firme virali. Tutti questi strumenti forniscono avvisi su comportamenti anomali, raccolgono log strutturati e permettono di orchestrare risposte.

Come interpretare gli avvisi di ClamAV

Ben compreso il ruolo di ClamAV, torniamo ad analizzare questa soluzione di base.

ClamAV integra firme per malware Windows, Linux e macro: quando trova una corrispondenza segnala l’oggetto “incriminato”. Di solito ha senso non eliminare subito il file bensì copiarlo in una cartella di appoggio ed estrarne la firma digitale:

cp suspicious.exe /var/tmp/analysis/
sha256sum /var/tmp/analysis/suspicious.exe > /var/tmp/analysis/sha256.txt

Si può quindi procedere con un controllo incrociato su VirusTotal. Valori hash identici permettono di confrontare risultati pubblici e di evitare falsi allarmi dovuti a file modificati.

A questo punto, il comando file è la prima cosa da lanciare: indica formato, architettura e dettagli tecnici. Esempio:

file oggetto_sospetto.exe
# esempio output: PE32+ executable (console) x86-64, for MS Windows

Quando il comando file riporta PE/Windows nell’output, si ha la conferma che ci si trova dinanzi a un Portable Executable (PE) Windows, da trattare con strumenti specifici.

Ancora, comandi come strings ed hexdump permettono di estrarre dall’eseguibile stringhe di testo come nomi di API, URL, chiavi, path, comandi sospetti. Ma questo va oltre le finalità dell’articolo.

In generale, comunque, ClamAV è spesso usato non tanto per proteggere il desktop Linux, quanto per impedire la distribuzione di malware ai client Windows (mail gateway, file server, NAS).