Skip to content

Quali sono i criteri per scegliere un sistema operativo sicuro?

Vi portiamo la soluzione a questa domanda, almeno lo speriamo. Se continui con le domande puoi scriverlo nella sezione domande e ti aiuteremo senza esitazione

Soluzione:

Ci sono molti criteri da utilizzare per scegliere un sistema operativo sicuro. Questi includono tutto, dalle funzionalità esplicitamente supportate all'obiettivo generale del sistema stesso. Anche se questa risposta è risultata piuttosto lunga, in realtà tocca solo un piccolo sottoinsieme di considerazioni.

Se questo è un tl;dr e volete un rapido riassunto con le raccomandazioni, saltate all'ultima sezione. Altrimenti, quanto segue vi darà una comprensione di base di come i diversi sistemi operativi differiscono per quanto riguarda la sicurezza. Non è assolutamente esaustivo, ma dovrebbe essere adatto a una domanda così ampia.

Irrigidimento dello spazio utente

Uno spazio utente protetto è importante nei modelli di minaccia in cui l'avversario è in grado di inviare dati controllati dall'aggressore al sistema, dove saranno analizzati da codice potenzialmente insicuro. Questo può manifestarsi come qualsiasi cosa, dai file multimediali all'HTML e al CSS visualizzati nel browser web. Dovete valutare se sarete esposti a tali dati e in quali circostanze. L'avversario è in grado di farvi visitare un sito web dannoso? Può farvi visualizzare un file video o un file immagine dannoso? Può comunicare con i servizi remoti del vostro computer? ecc.

Un sistema operativo protetto fa uso di funzioni di sicurezza integrate per ridurre la probabilità di successo o l'impatto complessivo degli exploit. Un sistema operativo che fornisce software precompilato (una distribuzione binaria, nella terminologia *nix) deve applicare questo hardening al momento della compilazione. L'indurimento comporta in genere la strumentazione del codice eseguibile per ridurre la quantità di informazioni che un aggressore ha sul layout della memoria o per complicare gli exploit più comuni.

  • ASLR (Address Space Layout Randomization) è una funzione di sicurezza onnipresente in quasi tutti i sistemi operativi moderni. In generale, funziona per randomizzare il layout della memoria, costringendo un attaccante a sfruttare anche una fuga di informazioni prima di poter sfruttare qualsiasi vulnerabilità che richieda la conoscenza del layout della memoria. Diversi tipi di ASLR randomizzano aspetti diversi della memoria. Più completo è l'ASLR, maggiore è la sicurezza. L'ASLR è fornito dal kernel del sistema operativo e si applica a tutti gli eseguibili caricati. ASLR è apparso per la prima volta in PaX, un componente della patch di hardening grsecurity.

  • PIE (Eseguibile indipendente dalla posizione) è una funzione a tempo di compilazione che consente a un'applicazione di eseguire una funzione senza conoscerne l'indirizzo assoluto. Se PIE non è supportato, ASLR sarà significativamente più limitato nelle sue capacità, consentendo di fatto solo la randomizzazione della base. Quando PIE è supportato, anche le singole librerie possono essere posizionate con offset casuali. Poiché PIE riduce leggermente le prestazioni, alcuni sistemi operativi compilano solo applicazioni sensibili in questo modo. Debian ne è un esempio, con un supporto PIE molto limitato. Fedora, invece, compila tutto con PIE per massimizzare la sicurezza.

  • SSP (Protettore di Pila) è un'altra caratteristica a tempo di compilazione che aggiunge controlli prima del ritorno delle funzioni per verificare la presenza di stack overflow. Può essere implementato in diversi modi, ma uno dei più comuni è lo stack canary. Si tratta di un valore randomizzato e unico per ogni thread. Questo valore viene controllato al ritorno di una funzione e, se è stato modificato, il programma si interrompe. A meno che un attaccante non riesca a sfruttare un'infoleak per ottenere il valore effettivo del canary, qualsiasi overflow lo sovrascriverà alla cieca e farà scattare la protezione SSP.

  • NX (Nessuna esecuzione), chiamata anche DEP (Data Execution Prevention) su Windows, è una funzione di sicurezza hardware che deve essere abilitata a tempo di compilazione per essere supportata da una determinata applicazione. Quando NX è attivo, la memoria contrassegnata come leggibile da non eseguibile non può essere eseguita. Senza NX, la leggibilità implica l'eseguibilità. La maggior parte dei sistemi operativi utilizza NX a livello globale, prevenendo i buffer overflow ingenui. L'aggiramento di NX richiede solitamente tecniche di sfruttamento più avanzate, come la ROP (una tecnica per eseguire codice esistente fuori ordine).

Esistono altre tecniche di hardening comuni, come RELRO, BIND_NOW, FORTIFY_SOURCE, oltre a tecniche meno comuni come UBSAN, CFI e SafeStack. La popolare utility checksec è in grado di verificare la presenza di diverse caratteristiche di hardening in qualsiasi eseguibile o processo. Funziona su quasi tutti i sistemi Linux. Nessuna di queste soluzioni è perfetta, ma possono alzare significativamente la posta in gioco per un aggressore. Sistemi operativi diversi, e persino distribuzioni diverse all'interno dello stesso sistema operativo, possono applicare livelli diversi di hardening.

Irrigidimento del kernel

L'hardening del kernel tende a essere più importante quando un aggressore sta eseguendo un processo dannoso sul sistema. Ciò può accadere sia nel caso in cui si consenta legittimamente l'esecuzione di un processo non attendibile (ad esempio in una macchina virtuale o in un container), sia nel caso in cui l'utente abbia sfruttato un'applicazione con privilegi bassi e desideri elevarsi a privilegi più elevati, come quello di root. In genere è più difficile che un aggressore si trovi in una posizione tale da poter attaccare il kernel, ma se ci riesce, l'impatto è significativo (perdita completa dell'integrità).

Il kernel è l'attività di livello più basso e più privilegiata di qualsiasi sistema operativo. I processi dello spazio utente comunicano con il kernel attraverso le syscall per richiedere varie risorse (come la memoria) o azioni (come l'I/O). Il kernel ha il compito di decidere se il processo userspace chiamante ha o meno i permessi sufficienti. Purtroppo, l'interfaccia con il kernel è molto complessa e qualsiasi bug in questa interfaccia può invalidare completamente l'integrità del sistema operativo in esecuzione. Il kernel deve quindi proteggersi. Questa operazione è chiamata "kernel hardening".

Sui sistemi Linux, la sicurezza del kernel può essere aumentata notevolmente utilizzando i patchset grsecurity. Purtroppo, al momento della stesura di questo articolo, i patchset sono commerciali. Tuttavia, se si acquistano, si possono ottenere miglioramenti che sono molto probabilmente decenni avanti rispetto alle tecniche di sicurezza pubbliche, se ci si può fidare della storia (ASLR e NX, per esempio, provengono dalla ricerca fatta per PaX, uno dei componenti principali di grsecurity che si concentra sulla resistenza agli attacchi di corruzione della memoria).

Differenze tra categorie di sistemi operativi

Sistemi operativi diversi possono avere priorità diverse per la sicurezza del kernel. Ad esempio, Debian è progettato per funzionare praticamente su tutto l'hardware e con tutto il software, anche quello obsoleto. In quanto tale, permette di utilizzare funzioni legacy potenzialmente insicure che hanno una storia di sfruttamento. OpenBSD, invece, rimuove rapidamente qualsiasi caratteristica che ritiene troppo rischiosa per essere mantenuta in modo sicuro.

Un riassunto di alcune categorie comuni di sistemi operativi sicuri:

  • Linux ha un kernel che spesso è configurato in modo diverso dalle diverse distro. Un kernel Linux ridotto e minimale può essere incredibilmente sicuro, mentre un kernel ricco di funzionalità e gonfio può eseguire molti driver sfruttabili. Il kernel è open source, quindi le diverse distribuzioni hanno anche le proprie patch per il kernel. Il kernel Linux non ha molte funzioni di autoprotezione, ma vengono lentamente aggiunte a monte e queste funzioni sono tipicamente basate (leggi: copiate) dagli ultimi sorgenti di grsecurity disponibili pubblicamente.

    1. Un kernel personalizzato ha il potenziale per essere il più sicuro. Può essere compilato con un sistema di hardening e le funzionalità extra possono essere eliminate. I driver non utilizzati possono essere rimossi, riducendo la superficie di attacco. È possibile abilitare le funzioni di sicurezza che vengono erroneamente etichettate come funzioni di debug (come il controllo della sanità delle credenziali). Un kernel personalizzato è il più difficile da mantenere, poiché richiede una conoscenza della configurazione e della sicurezza del kernel. Anche una panoramica di base delle opzioni di configurazione relative alla sicurezza richiederebbe un'intera risposta.

    2. Il team di Fedora prende la sicurezza più seriamente di molti altri, a quanto pare. Abilitano le nuove funzionalità di sicurezza quando escono e disabilitano le vecchie funzionalità. SELinux è abilitato di default, sfruttando la capacità del kernel di limitare anche l'utente root.

    3. Ubuntu era piuttosto insicuro, ma negli ultimi tempi ha migliorato la sicurezza. Il loro kernel supporta alcune caratteristiche tradizionali, ma ne disabilita altre che possono entrare in conflitto con le politiche di sicurezza. Ubuntu è basato su Debian, ma utilizza il proprio kernel. Lo spazio utente ha una discreta quantità di hardening, con PIE e altre tecniche applicate a un certo numero di utility.

    4. Debian, purtroppo, privilegia la compatibilità rispetto alla sicurezza. Il loro kernel supporta un gran numero di funzionalità legacy potenzialmente rischiose (uselib, vsyscalls, ecc.) in nome della compatibilità con il software legacy. Ha tutti i tipi di driver per molti tipi di hardware, alcuni dei quali possono essere sfruttati. L'hardening in fase di compilazione per il kernel è praticamente inesistente ed è limitato ai soli programmi sensibili per userland. Tuttavia, il team di sicurezza di Debian è abbastanza veloce con i backport di sicurezza.

  • BSD è una classe di sistemi operativi derivati dall'originale Berkeley Software Distribution. A differenza delle distro Linux, le distro BSD non utilizzano lo stesso kernel. La loro unica somiglianza è il loro antenato, BSD 4.4. La sicurezza dei BSD varia notevolmente:

    1. OpenBSD è un sistema operativo BSD che si vanta della sicurezza e della stabilità. Molte caratteristiche che potrebbero essere insicure vengono eliminate e molte nuove tecniche di sicurezza vengono aggiunte regolarmente. È stato progettato per essere sicuro per impostazione predefinita, con quasi tutto il territorio utente che si auto-sabota e viene compilato con protezioni estese. Il kernel stesso non è perfetto e il fuzzing può rivelare risultati spaventosi. Il sistema non ha le migliori prestazioni, in parte a causa della sua attenzione alla sicurezza. Questo è particolarmente evidente sui sistemi multiprocessore, dove la maggior parte del kernel è costretta in un singolo thread dal blocco gigante per ridurre il rischio di condizioni di gara.

    2. FreeBSD è più simile a Linux in quanto spesso si allontana dalla filosofia Unix originale. Supporta una grande quantità di hardware e ha un ottimo supporto software. Il kernel non è così pulito come quello di OpenBSD e il suo userland non è ideale (utilizza l'allocatore di memoria jemalloc, che limita l'ASLR, per esempio), ma nel complesso è un sistema abbastanza solido. Esiste una versione modificata di FreeBSD chiamata HardenedBSD che si concentra sull'hardening dello spazio utente, anche se il suo kernel presenta alcuni miglioramenti, soprattutto per quanto riguarda l'ASLR. L'ultima volta che ho controllato è ancora piuttosto sperimentale, ma per il resto è molto solido.

    3. NetBSD e DragonflyBSD non sono granché. I kernel, specialmente lo stack di rete di NetBSD, sono pieni di bug. DragonflyBSD era così indietro sulla sicurezza che ha aggiunto il supporto NX (una caratteristica hardware che impedisce l'esecuzione di codice non eseguibile) al kernel solo di recente, cosa che Linux ha ottenuto nel 2004! Questi sono sistemi di nicchia ed è improbabile che dobbiate usarli.

  • Windows, soprattutto il 10, è in realtà sorprendentemente sicuro. Il kernel è forse il kernel monolitico più analizzato staticamente che esista e supporta un gran numero di funzioni di sicurezza e tecniche di autoprotezione. Le vecchie versioni di Windows erano talmente arretrate dal punto di vista della sicurezza (su Vista si poteva persino mappare un indirizzo su NULL, se ricordo bene) che si è fatto una pessima reputazione. Al giorno d'oggi, il kernel è in realtà abbastanza protetto. La complessità del kernel porta ad altri bug, ma dal punto di vista dello sfruttamento è probabilmente più sicuro di un kernel Linux altrettanto ricco di funzionalità, come quello di Debian. Il problema principale di Windows è che non è possibile compilare le funzioni non necessarie o verificare il codice sorgente. Inoltre, le fughe di notizie di Snowden hanno dimostrato che Microsoft concede alla comunità dei servizi segreti l'accesso anticipato a 0days prima vengano patchati.

Caratteristiche di sicurezza (controlli di accesso, ecc.)

Un kernel sicuro non significa nulla se non può essere usato per applicare le politiche di sicurezza per lo spazio utente. A cosa serve un genitore che non può essere manipolato se non sa come tenere in riga i propri figli? La maggior parte dei kernel fornisce varie interfacce che gli utenti privilegiati possono impostare per limitare gli utenti minori. Alcune di queste funzioni sono abilitate per impostazione predefinita e costituiscono una parte fondamentale della sicurezza del sistema (come i controlli di accesso standard di Unix, detti anche DAC), mentre altre sono opzionali e possono essere configurate per fornire protezioni a grana fine e sandboxing.

Caratteristiche di sicurezza come queste sono utili quando c'è il rischio che un aggressore sfrutti un'applicazione in esecuzione, come un browser web o un visualizzatore di file multimediali. Se l'indurimento dei singoli binari non è sufficiente a impedire lo sfruttamento, le restrizioni di sicurezza fornite dal kernel possono limitare i danni che possono essere causati. Ad esempio, un browser che sia limitato ad accedere solo alla propria directory di configurazione, a una directory pubblica e alla directory dei download non sarà in grado di leggere i file delle password.

Un piccolo elenco di funzioni di sicurezza comuni del kernel:

  • DAC (Controlli di accesso discrezionali) sono permessi standard di Unix, supportati su tutti i sistemi Unix e Unix-like. Ogni singolo file può essere dotato di attributi per limitare la lettura, la scrittura e l'esecuzione. Ci sono attributi separati che si applicano all'utente (diciamo fred) che possiede il file (nel qual caso può annullarlo a suo piacimento, da qui "discrezionale"), al gruppo di cui il file è proprietario (diciamo localusers) e tutti gli altri utenti del sistema. Ad esempio, un file può essere reso leggibile e scrivibile per il suo utente, leggibile solo dal gruppo e completamente illeggibile e non scrivibile per qualsiasi altro processo sul sistema. Questo esempio di autorizzazione sarebbe fred:localusers 640con 640 come permessi in ottale.

  • MAC (Controlli di accesso obbligatori) sono presenti in molti sistemi operativi incentrati sulla sicurezza. A differenza del DAC, nemmeno il proprietario di un criterio può annullarlo. Un sistema MAC limita tipicamente il risorse (come un file o un'interfaccia di rete) che un dato soggetto (come un processo, un programma o un utente) è consentito l'accesso. Esempi comuni sono SELinux, un framework difficile da configurare ma altamente estensibile, fornito di default su Fedora e CentOS, e AppArmor, un sistema più semplice da usare che si concentra sulla limitazione dell'accesso ai file, fornito di default su Debian e Ubuntu, oltre che su OpenSUSE.

  • Sandbox e jail possono essere utilizzate per limitare un processo non attendibile, riducendone le capacità e impedendogli di danneggiare il resto del sistema. Le implementazioni, i progetti e gli scopi variano notevolmente. Si tratta di un argomento abbastanza complesso da solo, per cui posso solo rimandare a un'altra risposta che ho scritto e che riguarda le sandbox e tecnologie simili.

Servizi predefiniti

Le applicazioni installate di default e i servizi che vengono eseguiti di default sono molto importanti per la sicurezza. Un sistema ridotto con pochissime funzionalità non necessarie sarà più sicuro di un sistema gonfio con applicazioni per ogni formato possibile. Un maggior numero di servizi in esecuzione significa una maggiore superficie di attacco. Alcuni sistemi operativi, come Windows, vogliono eseguire il maggior numero possibile di servizi, mentre OpenBSD non ha praticamente nulla in esecuzione per impostazione predefinita. Poiché ha un'installazione predefinita così scarna con così pochi servizi in esecuzione, può vantarsi con orgoglio:

Solo due buchi remoti nell'installazione predefinita, da molto tempo a questa parte!

Esistono innumerevoli guide online per disabilitare i servizi non necessari su ogni tipo di sistema operativo. Poiché le applicazioni di base determinano la quantità di superficie di attacco che il sistema operativo ha per impostazione predefinita, un sistema con una base enorme può presentarsi come un frutto a portata di mano per potenziali aggressori. Ubuntu, ad esempio, è caduto il primo giorno nel concorso Pwn2Own a causa della sua userland ricca di funzionalità. Un sistema ChromeOS, con il suo sistema più limitato, avrebbe resistito!

Raccomandazioni

Non avete chiesto raccomandazioni, ma non si sa mai:

  • ChromeOS è un sistema basato su Linux sviluppato da Google. È incentrato sulla navigazione web e quindi ci si deve aspettare di passare la maggior parte del tempo nel browser. È forse il sistema Linux più sicuro in assoluto, oltre che uno dei più facili da usare. Utilizza un TPM incorporato per fornire un avvio misurato, impedendo al sistema di entrare in funzione se è stato manomesso (sia in un attacco di evil-maid, sia da un malware). Dal punto di vista della privacy, non è ovviamente il massimo.

  • QubesOS è un sistema basato su Xen che utilizza Fedora internamente. Si concentra sull'isolamento di default e cerca di essere facile da usare. È stato sviluppato principalmente da Joanna Rutkowska. Xen utilizza l'isolamento IOMMU che impedisce a periferiche hardware dannose o compromesse (ad esempio la scheda di rete) di compromettere il sistema. Può utilizzare un TPM installato per fornire un avvio misurato utilizzando ciò che definisce AEM. Qubes prende alcune strane decisioni in materia di sicurezza, come l'uso di Xen (che ha una scarsa reputazione in termini di sicurezza) e l'assegnazione a tutte le AppVM dell'accesso root, affidandosi interamente a Xen per la sicurezza. L'uso massiccio della virtualizzazione può renderlo lento e non funziona su sistemi senza virtualizzazione con accelerazione hardware.

  • Whonix o Tails possono essere usati se ci si vuole concentrare sull'anonimato. Entrambi forzano tutte le connessioni attraverso la rete di anonimato Tor, ma differiscono leggermente nei loro obiettivi. Whonix è progettato per utilizzare l'isolamento fisico, eseguendo il processo Tor su un altro sistema operativo (il "gateway") in modo che, anche se la stazione di lavoro principale è compromessa, il processo Tor non venga danneggiato. Per impostazione predefinita, Whonix consiglia di utilizzare la virtualizzazione per ottenere questo risultato, ma questa raccomandazione non dovrebbe essere presa in considerazione. Invece, il gateway e la workstation dovrebbero essere installati su macchine fisicamente separate. Tails è simile, ma utilizza un firewall software per l'isolamento. Inoltre, si concentra sull'anti-forensics, mantenendo tutto in memoria e perdendolo al riavvio del sistema. Per ottenere questo risultato, Tails è un DVD live.

  • Fedora è una distribuzione Linux che si concentra sulla sicurezza e sulla facilità d'uso. Le attuali versioni di Fedora utilizzano Wayland per impostazione predefinita per migliorare l'isolamento grafico. Fedora utilizza anche eseguibili abbastanza ben temprati e un kernel che viene mantenuto aggiornato e sicuro. Utilizza anche SELinux, con politiche preconfigurate. Per una distribuzione Linux generica, Fedora è tra le più sicure, pur essendo facile da usare.

  • OpenBSD è un sistema operativo derivato da Unix che si concentra su semplicità, sicurezza e stabilità. Ha un eccellente sistema di documentazione, che fornisce probabilmente i riferimenti più completi e utili di qualsiasi altro sistema operativo. Le pagine man sono infatti considerate la documentazione ufficiale del sistema. OpenBSD è un'ottima scelta se vi trovate bene con il sistema di base e le altre applicazioni disponibili attraverso il suo gestore di pacchetti binari. Nel complesso, OpenBSD è molto... confortevole. È ciò che un sistema operativo dovrebbe essere, anche se ha i suoi svantaggi (minore compatibilità software e hardware, non scala bene sui sistemi SMP).

  • Windows è il sistema operativo desktop più diffuso al mondo. Le versioni più recenti migliorano la sicurezza, come già detto. Windows può essere utile se non vi interessa la privacy e volete un sistema ben supportato che abbia una discreta resistenza allo sfruttamento.

A prescindere dal sistema operativo, l'elemento più pericoloso per la sicurezza del computer si trova tra la tastiera e lo schienale della sedia. Nei casi d'uso che descrivete, ciò che mi fa immediatamente accendere una lampadina rossa è: uso ricreativo per il 95% del tempo... - con tutti i rischi connessi, soprattutto per navigare su internet: ... dove ci sono tutti questi annunci sconci che non riesco a bloccare - Il 5% è costituito da operazioni bancarie online o da accessi remoti al mio computer di lavoro, eventualmente tramite VPN. - che dovrebbero richiedere una sicurezza maggiore.

Non conosco un modo per mantenere qualcosa di semplicemente sicuro - abbastanza sicuro da fidarmi di esso per le mie operazioni bancarie - e allo stesso tempo abbastanza tollerante da scaricare e testare ogni possibile sexy media o software sexy da Internet.

La regola è che ogni volta che si lascia entrare nel computer un file creato da un malintenzionato, è possibile che si apra una trappola per la sicurezza, e anche in questo caso nessun sistema operativo vi proteggerà da questo. Il modo più semplice è quello di definire i livelli di sicurezza e garantire che nulla dei livelli di sicurezza bassi possa accedere ai dati memorizzati in quelli alti. Questo è possibile con qualsiasi sistema operativo, ma ad oggi nessun sistema operativo lo prevede in modo trasparente e fuori dalla scatola.

Detto questo, ci sono alcuni suggerimenti:

  • utilizzare utenti diversi per serio attività e ricreativa uno. Ma fate molta attenzione a qualsiasi richiesta di elevazione dei privilegi! Al momento dell'installazione (di un gioco o di qualsiasi software), spesso si vede qualcosa come (nel mondo di Windows) Un programma chiede i privilegi di amministratore, sei d'accordo? o (nel mondo Unix-Linux) L'installazione di questo programma richiede i privilegi di super-utente. Usate su o sudo e riavviate l'installazione.. In entrambi i casi d'uso, vi restano 2 opzioni:

    • consentire il privilegio di amministratore - che permette al codice di installazione di fare qualsiasi cosa sulla macchina
    • non consentirlo - e non si può installare quel dannato file così sexy
  • utilizzare una macchina virtuale dedicata per le operazioni ricreative. Può sembrare bello, ma le macchine virtuali non offrono tutta la potenza di una macchina reale e la vostra macchina nuova di zecca si comporterà come una macchina di 10 anni fa. Non è molto utile per i giochi e nemmeno per la navigazione multimediale.

  • utilizzate una macchina virtuale dedicata per le operazioni serie. La maggior parte dei malware non cerca di guardare all'interno delle macchine virtuali (per ora e per quello che so, non so come evolverà la situazione perché le macchine virtuali diventano sempre più comuni). Per quanto riguarda la triade riservatezza, integrità e disponibilità, ci si può fidare di C e I, ma A è ancora ad alto rischio...

Quindi, IMHO, il modo migliore è cercare di capire le possibili conseguenze di ciò che si fa sulla propria macchina e se è accettabile per la sicurezza di cui si ha bisogno. E nessun sistema operativo, né nessun altro software può farlo per voi.

Detto questo, un buon antivirus, un firewall e l'isolamento dei privilegi sono un must, e le macchine virtuali possono aiutare. Ma non ci si può semplicemente affidare a loro...

E tutto quanto detto sopra si applica a qualsiasi sistema operativo.

Se ritieni che questo post ti sia stato utile, vorremmo che lo condividessi con altri programmatori in questo modo ci aiuti a spargere la voce su questo contenuto.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.