C'è un vantaggio in termini di sicurezza nell'utilizzo di una macchina virtuale oltre il doppio avvio?

Se prevedi di eseguire malware o almeno binari non attendibili, ti consigliamo di eseguirlo in VM (o anche in hardware segmentato).

Non ti puoi fidare di ciò che il sistema "sporco" sta facendo con altre partizioni, settori di avvio o BIOS, quando viene avviato.

Un ulteriore vantaggio è che la maggior parte del software di virtualizzazione può fornire una sorta di istantanea. È possibile utilizzare le istantanee come:

1. prendi uno snapshot
2. esegui software / malware non attendibili
3. ripristina lo stato del sistema su stato attendibile prima di eseguire il malware

Va notato che anche l'esecuzione in Virtual Machine non è sicura al 100% dei problemi. Di volta in volta, vengono trovate le modalità di escape della sandbox della macchina virtuale. Ad esempio CVE-2014-0983

Oltre a ciò che @Michal Ambroz ha detto, sarebbe molto saggio non solo eseguire in una VM, ma anche in una VM che non utilizza direttamente il kernel del sistema principale o ha accesso per modificare detto kernel. La virtualizzazione basata su KVM fornisce questo tipo di ambiente in quanto consente alla macchina virtuale di utilizzare il proprio kernel.

Il vantaggio di sicurezza generale è che una macchina virtuale suddivide in compartimenti il software che viene eseguito nel proprio ambiente, il che nella maggior parte dei casi impedisce al software della VM di accedere al server principale.

Il dual boot, d'altro canto, coinvolge partizioni separate, ma non impedisce loro di accedere l'un l'altro e di modificare i file.

se per "dual boot" si intende un SO per HDD, con un HDD scollegato: è più vicino a un traferro, che potrebbe essere più sicuro di una VM. tuttavia, come suggerisce l'altro, ciascun sistema operativo avrebbe accesso al BIOS, che potrebbe essere pericoloso.

se con 'dual boot' intendi due SO sullo stesso HDD: questo è decisamente meno sicuro rispetto ai dischi rigidi separati. immagina che entrambi i sistemi operativi siano stati completamente crittografati su un HDD: il sistema operativo non funzionante potrebbe caricare i contenuti crittografati completi su un server Web e quindi sovrascrivere quel buon sistema operativo con un bootloader dall'aspetto equivalente che richiede la password di crittografia, che viene quindi caricata sul server Web . quindi un utente malintenzionato avrebbe sia il tuo sistema operativo completo crittografato che la password di crittografia, senza aver mai eseguito un eseguibile sul sistema operativo che stavi cercando di proteggere.

come per le macchine virtuali non so altrettanto!

Questa è una grande domanda:

Secondo me ci sono alcuni motivi per usare Dual Boot su VM. Il più grande problema con le Macchine Virtuali sta tentando di eseguire campioni di malware che hanno funzionalità per verificare specifiche impostazioni hardware nel dispositivo prima dell'esecuzione. Ad esempio:

 Checks for BIOS
 Checks for CD Drive

Nota a margine: E, in alcuni casi controllano movimenti specifici dal tuo cursore per essere sicuro di essere umano. Quali motori Malware come gli ibridi-anali hanno contromisure per.

Se il malware non rileva entrambi quelli che non verranno eseguiti, come una sorta di rilevamento di VM. Ma ci sono modi per aggirare questo!

Attivo per motivi di sicurezza:

Di solito eseguo l'analisi malware in modo dinamico, quindi mi piace avere un client remnux e un altro client Windows. In questo modo ho potuto eseguire fakeDNS su remnux e impostare il DNS per la mia macchina Windows come remnux IP, mentre eseguivo wireshark su di esso. Questo mi dà capacità di analisi di rete robuste. Ecco una buona guida per questo:

link

Inoltre, come originariamente detto da Michal Ambroz, è estremamente importante poter scattare istantanee. Non solo solo per ripristinare la macchina in uno stato pulito, ma l'analisi può richiedere una preparazione e mi piace salvare gli scatti in alcune fasi durante la mia analisi.

La tua più grande preoccupazione, quando usi la configurazione di cui sopra sono due opzioni; trovare un modo per avere l'accesso a Internet SICURO e, in secondo luogo, il rilevamento di VM da malware e come prevenirlo. Se stai eseguendo questo laboratorio da casa, ti consiglio di acquistare un Internet secondario economico come precauzione.

Hai 3 scenari:

Dual Boot

Se si dispone di una sola unità HDD o di unità diverse per ogni SO ma non si scollegano quelle non utilizzate, un SO compromesso può accedere ai dati nelle partizioni degli altri SO. Supponiamo che l'OS A sia compromesso, quindi un utente malintenzionato può montare la partizione dal SO B, modificare l'OS B e comprometterlo anche tu (ricorda che la protezione sui file è data solo dal sistema operativo in esecuzione, poiché il sistema operativo A non deve proteggere i file dal SO B l'attaccante può cambiarli)

Per proteggersi da questo, è possibile crittografare entrambi i volumi in modo che un utente malintenzionato non possa montare l'altra partizione del sistema operativo, ma l'autore dell'attacco potrebbe comunque danneggiarlo

Se si dispone di un'unità HDD per sistema operativo e si disconnettono fisicamente quelli non necessari, un utente malintenzionato ha bisogno di una sorta di malware del firmware per passare dal sistema operativo OS al sistema operativo B. Ciò è estremamente improbabile, non solo perché i malware del firmware sono molto rari e difficile da sviluppare, inoltre l'attaccante dovrebbe in precedenza conoscere le informazioni sull'OS B per sviluppare un malware del firmware che può comprometterlo correttamente

Macchine virtuali

Qui l'attaccante ha due approcci posible: Ospite in host o host in guest

Ospite nell'host: se il tuo SO guest viene compromesso, ti darà un po 'di sandbox. Il sistema operativo guest non dovrebbe conoscere il sistema operativo host né l'hardware sottostante, ma tenere presente che i sistemi come VMware o VirtualBox non sono focalizzati sulla sicurezza, sono fatti per comodità e quindi esistono alcuni modi per aggirare la sua sandbox e ottenere il controllo su il sistema operativo host, per fare questo l'utente malintenzionato dovrebbe essere altamente qualificato (supponendo che non si stia utilizzando una versione del software di virtualizzazione vulnerabile conosciuta)

Host in guest: in questo caso l'utente malintenzionato può controllare il sistema operativo host e modificare direttamente i file utilizzati dal programma di virtualizzazione, il disco virtualizzato o persino utilizzare il programma di virtualizzazione come faresti. Anche l'ospite viene compromesso se l'host è

Hypervisor Type 1

Non l'hai menzionato, ma penso che sia qualcosa che dovrebbe essere valutato. Nella tua domanda parli di virtualizzazione, il modo più utilizzato per virtualizzare i sistemi operativi è l'utilizzo di software come VMware o VirtualBox che funziona su un sistema operativo host e virtualizza le risorse da esso prelevate per essere utilizzato da un SO guest. In questo caso le risorse gestite dal sistema operativo host vengono fornite al software di virtualizzazione (a.k.a. hypervisor) che le gestisce per il SO guest che le gestisce per le applicazioni in esecuzione su di esso

Esiste un altro tipo di hypervisor che viene eseguito direttamente sull'hardware e lo segmenta per eseguire più SO su di esso. Nelle immagini è questo:

In questo caso i sistemi operativi dovrebbero essere completamente isolati. Il sistema operativo A non sa nulla di OS B e non può accedere al suo hardware virtualizzato. Esistono alcune vulnerabilità note che possono consentire a un utente malintenzionato di uscire dalla sandbox dell'hypervisor per danneggiare la memoria degli altri sistemi operativi, ma per fare ciò al fine di compromettere l'OS B dal sistema operativo A, un utente malintenzionato dovrebbe essere altamente qualificato e avere conoscenza del proprio configurazione e lo stato corrente della memoria in OS B per modificarlo correttamente senza arrestarlo semplicemente