Test di malware in una macchina virtuale che funziona parallelamente ad altre macchine virtuali

Domande sulla rete: Tutte le domande relative alla rete sono fondamentalmente fino al malware è stato in grado di parlare con altri computer sulla rete. Pertanto, se gli altri dispositivi all'esterno del computer guest sono vulnerabili, esponi l'intera rete. Avrai bisogno di avere NAT differenti in modo che non possano parlare con il tuo computer host o con qualsiasi altro dispositivo sulla tua rete.

Separazione dei core CPU Sì, è possibile allocare determinati core e impostare un limite di esecuzione (anche se ciò dipenderebbe dal software VM scaricato).

Quanto è sicura la mia VM È possibile che il malware eseguito all'interno della macchina guest venga eseguito all'esterno della VM. Ti darò dei riferimenti quando sono a casa. Quindi, non credere perché stai usando VM che il tuo computer host è sicuro.

Come regola generale, le macchine virtuali non possono isolare il malware in modalità kernel che è consapevole della VM. Sono davvero solo un contenimento efficace per il malware in modalità utente. Per malware in modalità utente o malware in modalità kernel che è "passivo" (cioè non tenta di schermare l'ambiente del kernel), la VM conterrà in modo affidabile così le tue misure non sono necessarie.

Se, d'altra parte, il malware opera nel kernel ed è consapevole di VM, non è possibile contenerlo in modo affidabile regolando le interfacce, perché in un modo o nell'altro sarà in grado di eseguire l'escape se lo desidera.

Ci sono diversi motivi per questo, ma la prima cosa da capire è la differenza tra emulatori e VM. Un emulatore in realtà finge di essere l'hardware vero e proprio, ad esempio, è possibile installare un nuovo driver per l'hardware sulla VM e in teoria funzionerebbe perché l'emulatore (in teoria) si comporta proprio come il dispositivo reale. In realtà, anche se l'emulazione è assolutamente PERFETTA (che non è mai), il malware può sempre dire che si tratta di dispositivo falso perché il dispositivo sarà molto lento rispetto a quello reale. Tuttavia, finché l'emulazione è perfetta e perfettamente protetta dal firewall, non c'è nulla che il malware possa fare perché l'emulazione impedisce l'accesso al dispositivo reale.

Una VM d'altra parte non emula l'hardware (tranne che in modo limitato). Per ottenere prestazioni migliori passa semplicemente i comandi al dispositivo reale, agendo come una sorta di buffer. Se il malware è in esecuzione nel kernel, non solo il malware può comunicare con il dispositivo reale, ma è facile capire che sta parlando attraverso un'interfaccia VM, perché l'interfaccia è rara. Ad esempio, Qemu emula una Cirrus Logic GD5446, una carta antica che nessuno avrebbe mai usato davvero. Se lo vedi, sai che stai parlando con Qemu. Dato che il malware è nel kernel, può fare tutto ciò che un driver del kernel può fare e può vedere tutti gli altri "driver", incluse cose come aggiunte guest che rendono ovvia la VM. Quindi, non c'è modo di simularlo con i driver sintetici usati dalle VM.

Perché non devi preoccuparti

Detto questo, non devi davvero preoccuparti dell'isolamento, perché il 99,999% del malware non farà nulla che possa influenzare il sistema host. Quasi tutti i malware VM-aware sono interessati solo a rilevare una VM in modo che possa fare una cosa: basta. Una situazione in cui il malware ha rilevato che si trovava in una VM e quindi ha tentato di spostarsi nel sistema host sarebbe così raro da non essere nulla di cui dovresti preoccuparti. E, fidati di questo, se hai a che fare con malware che sono interessati e in grado di penetrare in un sistema host, hai a che fare con un'entità ben oltre la tua capacità di controllare con una semplice misura come scherzare con gli adattatori di rete. / p>

Chiunque abbia i soldi, il tempo e le motivazioni per scrivere codice che comprometterà una VM non si scherza con i dispositivi. Scriverà un exploit per l'hypervisor e otterrà il controllo diretto del sistema. Stai parlando di una manciata di squadre nel mondo che possono farlo, e anche allora devi chiedere "perché vorrebbe?"; le persone che eseguono macchine virtuali non sono i loro obiettivi.

Versione breve: non ti preoccupare.

Quindi ho qualche consiglio riguardo al lato Networking delle cose. Ecco una piccola installazione che utilizzo:

1. La macchina del malware. Mettilo su un adattatore di rete interno e assegnagli un indirizzo IP statico. Prendi nota della maschera di rete e del gateway.

2. L'ascoltatore. Mettilo sullo stesso adattatore di rete interno del primo. Assegnare l'indirizzo IP del gateway della macchina del malware e assegnargli la stessa maschera di rete. Quindi, modificare il gateway del listener su 0.0.0.0. Questo stonewall tutti i pacchetti, quindi il malware non raggiunge effettivamente il mondo esterno. Inoltre, rimuovi tutti gli altri adattatori in modo che il traffico non sfugga accidentalmente.

Ora esegui Wireshark sull'ascoltatore per l'attività di rete. Tutto scorre verso il "gateway", quindi puoi sentire tutto. Da lì, puoi costruire il malware come facsimile di ciò che sta cercando. Sta cercando 134.123.123.xx: 8080? Aggiungi quell'indirizzo ip a un adattatore virtuale sul listener e apri una sessione di ascolto di netcat per vedere cosa farà dopo. Vuole un server IRC che accetti le sue credenziali? Nessun problema, possiamo creare un server IRC personalizzato per questo.

Questo è tutto molto noioso, ma per quanto posso dire è sicuro. Per un'assicurazione aggiuntiva, puoi eseguire Wireshark sul tuo host e ascoltare il traffico sulla tua sottorete. Se cominciano a comparire strani pacchetti, basta uccidere le macchine.