Puoi installare un antivirus se vuoi. Non dovrebbe danneggiare la tua macchina, ma non aspettarti molta protezione per il tuo sistema e non considerarti completamente al sicuro . L'efficacia del software antivirus è molto relativa e sono utilizzati principalmente per evitare di propagare vecchi malware, soprattutto se si dispone di computer Windows nel proprio ecosistema. Dovresti aspettarti un calo delle prestazioni, anche se ad oggi non ci sono benchmark delle prestazioni AV su Linux, quindi non può essere quantificato.
Perché non sei al sicuro solo con un antivirus? Perché sono solo una parte dei meccanismi necessari. Al momento mancano molti strumenti per la sicurezza desktop su Linux. Quali sono i diversi meccanismi di sicurezza rilevanti per i desktop?
- Sicurezza dello stack grafico (per prevenire keylogger, clickjacking, registrazione dello schermo, sniffing degli appunti, ecc.)
- Schemi di distribuzione delle app con controlli di sicurezza (app store e repository con analisi statica sulle app) e rapidi aggiornamenti di sicurezza
- Rilevamento malware :basato sulla firma (per proteggere dalle minacce identificate) e basato sull'euristica (o almeno così dicono, non ho mai usato alcun AV basato sull'euristica e sospetto che si tratti principalmente di discorsi di marketing per dire "lanceremo tonnellate di avvisi di sicurezza in faccia quando usi una nuova app")
- Sandbox (che consiste nell'isolare le app l'una dall'altra in base alla progettazione)
- Autorizzazione contestuale all'utilizzo di dispositivi e dati utente con sicurezza per designazione / controllo degli accessi guidato dall'utente / powerbox / contratti; richiede sandbox
Attualmente l'unica cosa decente su Linux sono gli aggiornamenti di sicurezza delle app, tramite repository. Tutto il resto è scadente.
Sicurezza dello stack grafico
Facciamo tutti affidamento sul server grafico X11. X.Org esiste da 30 anni e il design originale è ancora in uso nel server. In passato non c'erano problemi di sicurezza del desktop e non sarai sorpreso di apprendere che non è affatto sicuro. Hai API pronte all'uso per implementare keylogger, eseguire sfruttamenti di codice remoto se l'utente ha una console di root aperta, sostituire l'armadietto di sessione per rubare password, ecc. Ecc.
È difficile valutare come si comportano Windows 8 e OS X su questo argomento perché non sono riuscito a trovare alcuna spiegazione dettagliata sulla loro implementazione dello stack grafico. Le loro app in modalità sandbox hanno un accesso limitato ai vettori di attacco più ovvi, ma non è davvero chiaro quanto sia ben progettato e implementato tutto questo. Mi sembra che Win 8 costringa le app dello Store a funzionare a schermo intero e una alla volta nasconda problemi nella progettazione di un gestore di finestre sicuro su vasta scala. Ci sono molti problemi da prendere in considerazione wrt. posizione e dimensionamento della finestra, uso della trasparenza e dello schermo intero, ecc. quando si implementa un gestore di finestre con in mente la sicurezza. Non ho idea di come funzioni OS X.
Linux passerà a Wayland nei prossimi anni, progettato pensando alla sicurezza. Abbiamo un modello chiaro di quali capacità dovrebbero esistere e un'idea generale di come queste saranno applicate e di come ottenere l'autorizzazione. La persona principale dietro questo lavoro è Martin Peres, anche se mi capita di essere coinvolto nella discussione dell'esperienza dell'utente e dello sviluppatore dietro le capacità. La progettazione e lo sviluppo sono in corso, quindi non aspettarti nulla a breve. Leggi questo post per maggiori informazioni. Wayland fornirà sicurezza senza soluzione di continuità se utilizzato in combinazione con il sandboxing delle app.
Distribuzione dell'app
Linux ha un sistema di repository con vari livelli di affidabilità, che ha addestrato i nostri utenti a fare affidamento solo sulle app fornite ea diffidare del codice proprietario. Questo è molto buono in teoria.
In pratica non conosco un singolo distributore che applichi anche i controlli di sicurezza più elementari sulle proprie app in pacchetto . Nessuna analisi statica di sorta per strane chiamate di sistema, e per qualsiasi comunità non è davvero chiaro se gli script pre e post installazione (che vengono eseguiti come root) siano verificati per ovvi problemi.
I controlli di sicurezza eseguiti sulle estensioni di GNOME Shell sono molto leggeri e manuali, ma almeno esistono. Non conosco le estensioni di KDE o altre app.
Un'area in cui eccelliamo è che possiamo estrarre gli aggiornamenti di sicurezza molto velocemente, di solito entro pochi giorni per qualsiasi falla di sicurezza. Fino a poco tempo fa Microsoft era molto più lenta di così, anche se ha recuperato terreno.
Rilevamento malware
L'unico software antivirus che conosco su Linux è ClamAV. Mi sembra che funzioni solo in base alle firme, ma poi, come hai sottolineato, non abbiamo alcun malware desktop identificato da cui proteggerci.
Probabilmente ci sono persone che scrivono malware per desktop Linux nel mondo delle minacce persistenti avanzate. Vedi Maschera per un esempio. È improbabile che l'AV standard possa fare qualcosa contro di loro poiché gli autori di malware APT sono generalmente abbastanza talentuosi da inventare exploit zero-day.
Ora, Microsoft pubblicizza il fuzz testing di tutto il suo software per decine di migliaia di ore, al contrario di praticamente nessuna pratica di codifica sicura nell'ecosistema Linux. Da esperimenti personali con il fuzzing sono assolutamente convinto che ci siano una manciata di exploit zero-day di basso livello in alcuni popolari software Linux . Questo ci colpirà il giorno in cui avremo una base di utenti finanziariamente sostenibile per gli autori di malware comuni, e poi vedremo quanto si rivelerà buono ClamAV, ma sospetto che il meccanismo di aggiornamento dell'app avrà un impatto maggiore nella gestione con vulnerabilità scoperte.
Inutile dire che sia Windows che OS X fanno significativamente meglio di Linux su questi criteri.
Sandboxing e autorizzazione contestuale
Sia OS X che Windows 8 forniscono il sandboxing per le app ospitate nel loro negozio. Non ho finito di esaminare le stranezze di OS X, ma le app di Windows 8 Store hanno limitazioni molto serie in termini di lingue e API supportate, funzionalità disponibili ed esperienza utente generale che possono essere fornite con esse. Ciò significa che le app desktop senza sandbox sono qui per restare e il sandboxing di Microsoft non proteggere dal malware, solo dai documenti creati nel software difettoso (Store App). OS X sembra fare molto meglio anche se qualsiasi app non in negozio non è in modalità sandbox.
Linux non ha una sandbox dell'app GUI che funzioni abbastanza senza problemi al momento. Abbiamo la tecnologia di confinamento sottostante (i migliori candidati sono i contenitori basati su spazi dei nomi Linux, vedi LXC e Docker, e i prossimi migliori sono i sistemi di imposizione MAC che dovrebbero essere sviluppati per supportare una certa quantità di dinamicità). Abbiamo quasi l'IPC e i meccanismi di gestione dei processi necessari per distribuire e gestire quelle app in modalità sandbox grazie all'incredibile lavoro su kdbus e systemd. Mancano alcune parti, con alcune proposte spinte principalmente dalla GNOME Foundation (guarda questo video su Sandboxing a GUADEC 13). Sono anche coinvolto nella discussione su come può avvenire l'accesso ai dati e l'autorizzazione, ma non c'è consenso tra le poche persone interessate e la progettazione e lo sviluppo richiedono tempo. Probabilmente ci vorranno ancora un paio di anni prima che esistano prototipi decenti e prima che il sandboxing venga implementato su Linux su qualsiasi scala rilevante.
Uno dei grandi problemi affrontati su tutte le piattaforme è scoprire come autorizzare le app ad accedere ai dati e alle funzionalità del dispositivo nella giusta scala. Ciò significa come consentire loro di fare ciò di cui hanno bisogno senza infastidire gli utenti con richieste di autorizzazione, impedendo al contempo alle app di abusare dei privilegi. Esistono gravi lacune nel modo in cui Windows 8 consente alle app dello Store di gestire i documenti recenti e il futureAccessList delle app. In questa fase garantire ulteriormente l'accesso ai documenti senza aggravare il costo della sicurezza per sviluppatori e utenti è una questione aperta, su cui stanno lavorando anche un gruppo di persone :)
Al malware non importa se stai eseguendo un "solo desktop Ubuntu con installazione standard". Il malware verrà eseguito finché il sistema supporta il set di istruzioni corretto per il quale è stato compilato il binario ELF. Ubuntu è basato su Debian e supporta i seguenti set di istruzioni:IA-32, x86-64, ARMv7, ARM64, PowerPC. Generalmente trovi che la maggior parte è basata su sistemi IA-32 o x86-64.
Dato che il mio lavoro consiste nell'invertire il malware, a volte devo eseguire il debug attraverso di esso, quindi ho VM Ubuntu Desktop Edition (sia a 32 che a 64 bit) che utilizzo per eseguire il debug remoto del malware Linux su base giornaliera tramite IDA.
Se vuoi parlare del metodo di infezione, certo, è meno probabile che tu riceva un drive-by su Linux che su Windows. Tuttavia, negli ultimi mesi ho notato che giocando con alcuni degli script PHP drive-by supportano sempre più piattaforme non Windows. Basta controllare la piattaforma che il browser sta annunciando e consegnare l'exploit pertinente.
TL;DR- Infetto le installazioni desktop di Ubuntu (VM) su base giornaliera mentre inverto il malware Linux.
La domanda è posta per Ubuntu. Se posso allargare la domanda alle edizioni desktop di Linux, SELinux digita "Walled Garden " sarebbe molto utile. In SELinux le policy di controllo degli accessi obbligatori (MAC) possono arrestare o limitare il danno nel tentativo di infezione. A differenza di AV che viene eseguito come processo separato che appesantisce il sistema operativo, SELinux ha il supporto nativo del kernel Linux e sicurezza le etichette sono memorizzate negli inode.
Pro:
Puoi implementare politiche di sicurezza molto complicate. (Cioè il browser Web non può accedere a cartelle diverse da ~/.mozilla)
Svantaggi:
Tuttavia in SELinux avrai bisogno di una buona politica di sicurezza. Lo svantaggio è che la modifica di queste norme è complicata.
Come so, Ubuntu non supporta SELinux per impostazione predefinita. Ma sistemi operativi come Fedora.
In conclusione:
In conclusione, Linux ha davvero buoni meccanismi di sicurezza (File Permission, SELinux) che rendono la vita dei malware davvero difficile a meno che tu non li abbia fatti un casino.