Virtualizáció Elfedése

1. Stratégiai áttekintés¶

1.1. A Virtualizáció felismerés fenyegetési modellje¶

A modern biztonsági ellenőrző rendszerek és automatizációs keretrendszerek, mint például az Ansible, gyakran használják a rendszerinformációkat a célpont környezetének hitelesítésére és kategorizálására. Amennyiben a cél egy virtuális gép (VM) elfedése, a fenyegetési modell középpontjában azok a szubjektív és objektív nyomok állnak, amelyek leleplezik a virtualizált állapotot. Ezek a nyomok nem csupán egyszerű szoftveres azonosítók, hanem a hardveremuláció mélyebb szintjein rejlő anomáliák.

A virtualizáció felismerésének kritikus pillérei közé tartozik az alacsony szintű CPU utasítások és flagek ellenőrzése (különösen a CPUID-ben), a rendszer firmware adatok vizsgálata (SMBIOS/DMI mezők) , a virtuális I/O eszközök jelenléte (mint a VirtIO vagy VMXNET3 eszközazonosítók), a hálózati MAC címek Vendor/Organizationally Unique Identifier (OUI) tartományai , valamint a vendég operációs rendszerbe telepített integrációs kernel modulok vagy felhasználói térbeli ügynökök (VMware Tools, VBox Guest Additions, QEMU Guest Agent).

Az elfedési stratégia végső célja a teljes rendszerparitás elérése. Ez azt jelenti, hogy a standard rendszerelemző parancsok, mint a Linuxon futtatott dmidecode vagy a Windows PowerShellben futó systeminfo, olyan kimenetet kell eredményezniük, amely hitelesen megegyezik egy fizikai hardverével, és hiányoznak belőle a virtualizációra utaló explicit karakterláncok (például "QEMU", "VMware", vagy "VirtualBox"). Amennyiben a rendszer egy olyan környezetbe kerül, ahol pl. Ansible fut, úgy ez a rendszer gyakran a könnyen hozzáférhető metaadatokra támaszkodik a hardver azonosításához. E metaadatok konzisztens hamisítása létfontosságú az elfedés sikere érdekében.

1.2. A Hipervizor elfedés réteges megközelítése¶

A hatékony hipervizor elérése rétegelt megközelítést igényel, mivel egyetlen konfigurációs változtatás sem tudja kezelni az összes felismerési vektort. Az elfedésnek mind a négy kritikus rétegre ki kell terjednie:

Hardver emuláció: A CPUID parancs viselkedésének manipulálása a hipervizor jelenlétére utaló bit és aláírás eltávolításához.
Firmware (DMI/SMBIOS): A rendszer metaadatainak (Manufacturer, Product Name) felülírása a fizikai adatokkal.
Virtuális eszközök: A paravirtualizált hardver és hálózati azonosítók elfedése vagy cseréje.
Vendég operációs rendszer (OS): A hipervizorhoz kötődő agent-ek, kernel modulok és fájlrendszeri nyomok teljes eltávolítása.

1.3. A DMI/SMBIOS Szerepe a rendszer leltározásában¶

A DMI (Desktop Management Interface) vagy SMBIOS (System Management BIOS) szabványosított metaadatokat biztosít a rendszer hardverkomponenseiről és firmware-éről. A DMI lemezek strukturált információkat tartalmaznak a BIOS-ról (Type 0), a Rendszerről (Type 1), és az alaplapról (Type 2). Ezeket a mezőket használják az olyan rendszerek, mint például az Ansible, a hardver egyedi azonosítására.

Különösen kritikusak a Type 1 (System Information) mezői, beleértve a Manufacturer, Product Name, Version, és UUID elemeket. A nem módosított VM-ekben ezek a mezők gyakran tartalmaznak explicit virtualizációs karakterláncokat (pl. "QEMU", "VMware", vagy a hipervizor menedzsment eszközének nevét, mint a "Virt-Manager"). Ezen értékek hiteles fizikai hardver adatokkal történő felülírása a virtualizációs elfedés alapvető lépése. A legtöbb automatizált felismerő script ezzel kezdi az ellenőrzést, mivel a DMI adatok könnyen lekérdezhetők.

2. CPUID és hipervizor aláírás maszkolása (1. Réteg)¶

A CPUID utasítás a legalacsonyabb szintű és legmegbízhatóbb mechanizmus a hipervizor jelenlétének ellenőrzésére. A hipervizorok elfogják ezt az utasítást, és manipulált eredményeket adnak vissza a vendég operációs rendszernek, jelezve a virtualizációs környezetet. Az elfedés megköveteli a speciális virtualizációs flagek és aláírások eltávolítását.

2.1. A CPUID mechanizmus és a hipervizor identitás flag¶

A modern CPU-architektúrák támogatják a virtualizációs kiterjesztéseket (pl. Intel VT-x, AMD-V). Amikor egy vendég operációs rendszer végrehajtja a CPUID utasítást, a hipervizor elfogja azt, és beállít egy speciális bitet (Hypervisor Present bit, ECX regiszter 31. bitje), jelezve, hogy a gazdagép virtualizálva van. Emellett minden főbb hipervizor rendelkezik egy egyedi aláírással (Signature Leaf), amelyet a 0x40000000 tartományban tesz közzé (pl. "KVMKVMKVM" vagy "VMwareVMware").

Ez az aláírás az a vektor, amelyet az érzékeny szoftverek (pl. hardver licenc ellenőrző mechanizmusok, vagy grafikus kártya illesztőprogramok) használnak a virtualizációs környezet felismerésére. A klasszikus példa erre az NVIDIA illesztőprogramok viselkedése volt a 465-ös verzió előtt, amelyek megtagadták a működést (Code 43 hibát eredményeztek Windows alatt), amennyiben a KVM hipervizor aláírását detektálták. A maszkolás tehát nem csupán biztonsági szempontból, hanem hardverfüggő szoftverek futtatásához is létfontosságú.

2.2. KVM/QEMU (Libvirt) CPU konfiguráció¶

A KVM-alapú virtuális gépek (amelyeket jellemzően Libvirten keresztül kezelnek) konfigurációja a tartomány XML fájljának módosítását igényli. Ez a manuális beavatkozás általában a virsh edit <vmname> parancs segítségével történik, mivel a grafikus kezelőfelületek (pl. virt-manager) nem mindig teszik lehetővé a szükséges mélységű CPU-szabályozást.

2.2.1. Egyéni CPU Modell Beállítása¶

Az elfedési folyamat megkezdése előtt elengedhetetlen, hogy ne a libvirt "Hypervisor default" CPU modelljét használja a rendszer. A QEMU alapértelmezett beállítása a "QEMU Virtual CPU version 2.5+" jelzést eredményezi, és nem engedi meg a hipervizor flag eltávolítását a <cpu> blokkban.

A tartomány XML-ben a <cpu> szekciót módosítani kell, például a gazdagép CPU modelljét kell használni (host-model), majd ezt tovább finomítani.

2.2.2. Kétlépéses CPUID maszkolás a maximális elfedés érdekében¶

A teljes elfedéshez két különálló mechanizmust kell aktiválni: a KVM-specifikus aláírás elrejtését, és a generikus hipervizor jelenléti bit eltávolítását.

A KVM aláírás elrejtése: A <features> blokkot módosítani kell a libvirt XML-ben. A <kvm><hidden state='on'/></kvm> konfiguráció hozzáadása elrejti a KVM hipervizor aláírást (HVC flag) a vendég operációs rendszertől. Ez kifejezetten a 0x40000000-as tartományban közzétett KVM-specifikus aláírási levelet célozza meg.
A generikus hipervizor flag eltávolítása: A valós fizikai gép illúziójához azonban nem elég a KVM-aláírást elrejteni; a CPUID utasítás által visszaadott generikus hipervizor jelenléti bitet (az ECX regiszter 31. bitje) is le kell tiltani. Ezt a <cpu> definíció alatt lehet elérni, a policy='disable' attribútummal:

<cpu mode='custom' match='exact'>
    <feature name='hypervisor' policy='disable'/>
</cpu>

A két technika együttes alkalmazása biztosítja, hogy sem a KVM-specifikus, sem a generikus virtualizációra utaló nyomok ne jelenjenek meg a vendég OS számára.

2.3. VMware (VMX) CPU konfiguráció¶

A VMware platformon (Workstation, ESXi) az elfedési konfiguráció a VMX konfigurációs fájl manuális szerkesztésén alapul.

2.3.1. CPUID flag és aláírás eltávolítása¶

A VMware aláírásának elrejtése a CPUID-ben kulcsfontosságú. Ezt a VMX fájlban a következő sor hozzáadásával vagy módosításával lehet elérni:

hypervisor.cpuid.v0 = "FALSE"

Ez a beállítás megakadályozza a VMware-specifikus aláírás megjelenítését a CPUID lekérdezéseknél.

2.3.2. A hipervizor hátsó ajtó enyhítése¶

A VMware, más hipervizorokhoz hasonlóan, egy speciális I/O portot használ (úgynevezett "backdoor"), amely lehetővé teszi a vendég-gazda rendkívül gyors kommunikációját. Ez az egyik legmegbízhatóbb detektálási vektor. Ennek a funkciónak a korlátozása vagy letiltása kritikus:

monitor_control.restrict_backdoor = "TRUE"

2.3.3. Időzítési anomáliák kezelése¶

A fejlettebb felismerő scriptek kihasználhatják az időzítési különbségeket (pl. a Time-Stamp Counter, TSC, virtualizált olvasási sebességét) a fizikai és a virtuális környezet között. Bár a teljes időzítési paritás elérése szinte lehetetlen, a következő beállítás segít valószerűbb TSC emulációt biztosítani:

monitor_control.virtual_rdtsc = "FALSE"

2.4. VirtualBox CPUID maszkolás¶

A VirtualBox esetében a paravirtualizációs felület beállításai befolyásolják, hogy a vendég milyen hipervizor azonosítókat lát. Alapértelmezés szerint a VirtualBox megpróbálja emulálni a Hyper-V vagy a KVM felületeket a jobb teljesítmény érdekében.

A virtualizációs nyomok minimalizálása érdekében ajánlott a paravirtualizációs interfész letiltása vagy "None" értékre állítása a VBoxManage parancssori eszköz segítségével:

VBoxManage modifyvm <VM-név> --paravirtprovider none

Ez a lépés csökkenti az esélyét annak, hogy a VirtualBox nem kívánt hipervizor aláírásokat tegyen közzé a vendég OS felé, bár a VirtualBox azonosító nyomokat a DMI rétegben is elhelyez.

3.Rendszerinformáció hamisítása (SMBIOS/DMI) (2. Réteg)¶

A DMI/SMBIOS adatok manipulálása a leginkább alapvető és leggyakrabban ellenőrzött rétege a virtualizációs elfedésnek. Ha ezeket a mezőket nem módosítják, a VM azonnal felismerhetővé válik a legtöbb leltárrendszer számára.

3.1. SMBIOS adat hamisításának jelentősége¶

A SMBIOS Type 1 (System Information) adatai magukban foglalják a rendszergyártó nevét, a termék nevét (alaplap/modell), a verziószámot és a UUID-t. Az alapértelmezett beállítások tipikusan "QEMU", "VMware", vagy a menedzsment eszközök nevét ("Virt-Manager", "Fedora") tartalmazzák. A cél ezeknek az értékeknek a lecserélése olyan adatokra, amelyek hiteles fizikai hardverre utalnak (pl. "Dell Inc.", "OptiPlex 7010").

3.2. KVM/QEMU (Libvirt) SMBIOS adat manipuláció¶

Libvirt alatt az SMBIOS adatok beállításához két kritikus lépés szükséges: az SMBIOS mód aktiválása, majd a részletes mezők definiálása.

3.2.1. Alapkonfiguráció és adatdefiniálás¶

Először is, a vendég operációs rendszernek jelezni kell, hogy a bemeneti SMBIOS adatokat a <sysinfo> blokkból vegye át, nem pedig a hipervizor alapértelmezett értékeiből:

<os>
    <smbios mode='sysinfo'/>
</os>

Ezt követően a részletes DMI mezőket a <sysinfo type='smbios'> blokkban lehet definiálni. A <bios>, <system>, és <baseBoard> alblokkok lehetővé teszik a Type 0, Type 1 és Type 2 SMBIOS struktúrák hamisítását.

3.2.2. Részletes DMI mezők módosítása¶

A virsh edit parancs szükséges e blokk kézi definiálásához. Az alábbi példa bemutatja, hogyan lehet felülírni az alapértelmezett "Fedora" vagy "Virt-Manager" értékeket.

<sysinfo type='smbios'>
    <bios>
        <entry name='vendor'>American Megatrends Inc.</entry>
        <entry name='version'>1.20</entry>
    </bios>
    <system>
        <entry name='manufacturer'>Dell Inc.</entry>
        <entry name='product'>OptiPlex 7010</entry>
        <entry name='version'>01</entry>
        <entry name='serial'>B27T8V1</entry>
    </system>
    <baseBoard>
        <entry name='manufacturer'>Dell Inc.</entry>
        <entry name='product'>0CRG4F</entry>
    </baseBoard>
</sysinfo>

3.2.3. UUID konzultencia a hardverazonosítókban¶

Az univerzálisan egyedi azonosító (UUID) kritikusan fontos a rendszerintegritás szempontjából. A meglévő, nyilvános, vagy véletlenszerűen generált UUID-t ki kell cserélni egy konzisztens, de nem virtualizációra utaló, kézzel beállított RFC 4122 kompatibilis UUID-re. Ez a <uuid> elem a tartomány gyökerében található:

<domain type='kvm'>
    <name>MyStealthGuest</name>
    <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
<domain>

Fontos megjegyezni, hogy a vendég OS nem csak a DMI struktúrákból, hanem bizonyos eszközökön keresztül is lekérdezheti a hardver UUID-t, különösen PCI passthrough környezetben. A libvirt 11.7.0-tól QEMU/KVM esetén elérhető a hwuuid elem. Ennek használata biztosítja, hogy minden eszköz ugyanazt az UUID-t tegye közzé, ezzel maximalizálva a fizikai konzisztencia illúzióját a fejlettebb detektáló szkriptekkel szemben.

VMware (VMX) SMBIOS adat hamisítás: A VMware esetében az SMBIOS adatok kezelése a VMX fájl szintjén történik.

Gazdagép tükrözés tiltása: A VMware alapértelmezés szerint képes átadni vagy "tükrözni" a gazdagép SMBIOS adatait a vendég számára, ami katasztrófális következményekkel jár az elfedés szempontjából. Ezt a funkciót le kell tiltani:

SMBIOS.reflectHost = "FALSE"

Firmware aláírás felülírása: A VMware (és más hipervizorok) gyakran beágyazzák a nevüket a BIOS firmware fájljába (pl. BIOS.440). Az elfedés legmélyebb szintjének eléréséhez a BIOS fájlt manuálisan kell javítani (például egy külső BIOS szerkesztővel) a virtualizációra utaló karakterláncok eltávolítására. A javított fájl betöltése ezután a VMX-ben történik:

bios440.filename = "G:<path_to_your_bios_file>\BIOS.440.PATCH.ROM"

Ez a módszer kiküszöböli a VMware-re utaló nyomokat a legalacsonyabb, firmware szinten.

VirtualBox DMI konfiguráció: A VirtualBox a DMI mezőinek konfigurálására a VBoxManage setextradata parancsot használja. Ez a módszer lehetővé teszi, hogy egyedi, nem virtualizációra utaló értékeket adjon meg a rendszeradatokhoz.

A kulcspath elhelyezkedése a használt firmware-től függ (PCBIOS vagy EFI).[13] A PCBIOS-t használva a DMI mezők a következő módon módosíthatók:

# Rendszer sorozatszámának (Serial Number) módosítása
$ VBoxManage setextradata VM-name "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial" "string:B27T8V1"

# Termék nevének (Product Name) módosítása
$ VBoxManage setextradata VM-name "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "string:OptiPlex 7010"

# BIOS gyártójának módosítása
$ VBoxManage setextradata VM-name "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "string:American Megatrends Inc."

4. Eszköz- és illesztőprogram nyomok eltávolítása (3. Réteg)¶

A virtualizált hardvereszközök jelenléte és aláírása azonnal leleplezi a VM környezetet, még akkor is, ha a CPUID és a DMI adatok hamisítva vannak.

4.1. Virtualizált hardver aláírások¶

4.1.1. MAC cím hamisítása¶

Minden főbb hipervizor (KVM, VMware, VirtualBox) saját OUI (Organizationally Unique Identifier) tartományt használ a virtuális hálózati kártyákhoz. Például a VMware gyakran a 00:50:56 előtagot használja. Ezek az OUI-k könnyen ellenőrizhetők.

A megoldás az, hogy manuálisan egy olyan MAC címet kell beállítani, amely egy hiteles fizikai gyártóhoz tartozó OUI-t használ (például Intel vagy HP). Ezt a MAC címet a VM konfigurációs fájljában kell beállítani (libvirt XML-ben a <mac address='...'/> alatt, VMX fájlban a ethernet0.address alatt).

4.1.2. PCI vendor/device ID evasion¶

A paravirtualizált eszközök, mint a VirtIO (KVM/QEMU esetén) vagy a VMXNET3 (VMware esetén), PCI buszon egyedi Vendor ID-ket és Device ID-ket tesznek közzé. Ezek az ID-k nyilvánosan ismertek, és kifejezetten a virtualizációs környezetekhez vannak rendelve.

KVM/QEMU: Kerülni kell a virtio alapú eszközök használatát a hálózathoz, lemezekhez és balooning-hoz. Bár ez teljesítménycsökkenéssel jár, elengedhetetlen a felismerés elkerülésére. Helyette emulált, de kevésbé leleplező hardvert kell használni, mint például a standard e1000 hálózati kártya emuláció vagy a standard sata/scsi lemezvezérlő emuláció.
A QEMU aláírás eltávolítása: Még az emulált eszközök esetén is, ha az Asnible a PCI eszközök illesztőprogramjait vizsgálja, megjelenhet a "QEMU Virtual PCI Host Bridge" vagy hasonló felirat. Ha a teljesítmény nem kritikus, érdemes megfontolni a hardverátengedés (passthrough) használatát is. Ha nincs lehetőség passthrough-ra, a legtöbb emulált hardver használata ajánlott a VirtIO helyett.

5. Vendég OS tisztítás és ügynök vezérlés (4. Réteg)¶

Még ha a hardveres rétegeket is sikerül elfedni, a vendég operációs rendszerbe telepített integrációs ügynökök (Guest Agents) és kernel modulok azonnal leleplezik a VM állapotot.

5.1. Vendég ügynökök és eszközök semlegesítése¶

5.1.1. VMware tools és elszigetelési beállítások¶

A VMware Tools egy sor kritikus funkciót nyújt (pl. óraszinkronizálás, egér/billentyűzet integráció), de beágyazott mechanizmusokat is tartalmaz, amelyeket a detektáló scriptek ellenőrizhetnek.

A VMX fájlban a korábban említett isolation.tools.* beállítások segítenek letiltani a VMware Tools azon funkcióit, amelyek a felismerés alapját képezik. Például:

isolation.tools.getVersion.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.hgfs.disable = "TRUE"

A teljes eltávolítás követelménye: Az iparági tapasztalatok azt mutatják, hogy még az összes ismert VMX flag beállítása után is lehetséges a detektálás. Ez azt jelenti, hogy a fejlettebb felismerési szkriptek a fizikai és virtuális hardver teljesítménybeli különbségeit (pl. L1/L2 cache viselkedés, I/O késleltetés) vagy a Windows API-k apró anomáliáit használják ki. A legmagasabb szintű elfedés érdekében a VMware Tools-t nem szabad telepíteni, vagy ha már telepítve van, az ügynök összes binárisának, szolgáltatásának és kernel moduljának teljes, mélyreható eltávolítása szükséges, ahelyett, hogy csak a VMX fájlban tiltanánk le a funkciókat.

5.1.2. VirtualBox guest additions eltávolítása¶

A VirtualBox Guest Additions kernel moduljai (pl. vboxguest, vmw_vmci a VMware-nél) szintén azonnali detektálási vektorok, ha a Linux vendég OS-ben a lsmod paranccsal ellenőrzik a futó modulokat.

A megoldás az, hogy nem elegendő csak a szolgáltatást leállítani. A modulokat véglegesen el kell távolítani a rendszerről, tipikusan a DKMS (Dynamic Kernel Module Support) rendszeren keresztül. A fennmaradó modulokat manuálisan kell törölni, és a dkms status paranccsal ellenőrizni kell, hogy nem maradtak-e VirtualBox-ra utaló kernel illesztőprogramok a rendszerben.

5.1.3. QEMU vendég ügynök (QEMU-GA) kezelése¶

A QEMU-GA egy felhasználói térbeli szolgáltatás, amely a gazdagéppel való kommunikációt szolgálja. Ha ez fut a vendég OS-ben, különösen Windows alatt, könnyen felismerhető.

Művelet (Windows): A QEMU-GA szolgáltatás elindításának megakadályozására Windows-ban a szolgáltatás registry kulcsának módosítása a legmélyebb beavatkozás. A SYSTEM\CurrentControlSet\Services\QEMU-GA alatt az ImagePath (útvonal) értékét kell módosítani annak érdekében, hogy a szolgáltatás ne induljon el, vagy ne futtasson veszélyes funkcionalitást (például a jelszó-állítást letiltva, ha a cél csak a menedzsment korlátozása). A legbiztosabb megoldás azonban a QEMU-GA eltávolítása a vendég OS-ből.

5.2. Fájlrendszer és környezeti nyomok¶

5.2.1. Kernel modulok és feketelista¶

A Linux rendszereken a virtualizációra utaló összes kernel modult (pl. virtio_blk, virtio_net, vmw_vmci) feketelistára kell tenni, vagy teljesen el kell távolítani a vendég OS-ből. Ez garantálja, hogy ezek a modulok ne legyenek betöltve, még akkor sem, ha a hipervizor megpróbálja azokat felajánlani.

5.2.2. Kernel paraméterek szanálása¶

Bár a kernel paraméterek ritkán közvetlen detektálási vektorok, az a tipikus beállítások utalhatnak virtualizált környezetre. Például Red Hat Enterprise Linux 8-ban a softlockup_panic és nmi_watchdog paraméterek engedélyezése nem ajánlott VM-ekben. A konfiguráció célja, hogy a kernel paraméterek konzisztensek legyenek egy fizikai gazda beállításaival, minimalizálva az eltéréseket.

5.2.3. Konténerizációs nyomok eltávolítása (Nested Evasion)¶

Egyre gyakoribb, hogy a felismerő scriptek konténerizált környezetben futnak (pl. Docker vagy Kubernetes) a VM-en belül. Ha a VM-felismerés sikertelen, a script konténer detektálásra válthat. Ezért a VM-en belüli operációs rendszer konfigurációjának meg kell tisztítania a konténer-specifikus artifaktumokat is.

A leggyakoribb konténer detektálási vektorok a következők:

A /proc/1/cgroup vizsgálata a konténeres cgroup struktúrák jelenlétére.
A /dev/shm/.dockerenv vagy a .dockerenv fájl jelenlétének ellenőrzése a fájlrendszer gyökerében.

A megelőzéshez elengedhetetlen a cgroup struktúrák ellenőrzése, és annak biztosítása, hogy a Docker által használt cgroup konfiguráció ne utaljon konténer környezetre. A rendszergazdának kerülnie kell a nyilvánvaló konténer-specifikus környezeti változók vagy fájlok beállítását. A cgroup mechanizmus, ha rosszul van konfigurálva, súlyos biztonsági kockázatot is jelenthet (pl. konténerből gazdagéphez való kitörés, "Container Escape").

6. Automatizálás, ellenőrzés és korlátok¶

6.1 Ellenőrzési protokollok (Audit)¶

A sikeres elfedés csak akkor igazolható, ha a rendszer alapos ellenőrzésen esik át, amely igazolja a fizikai paritást.

6.1.1. Linux Audit¶

SMBIOS ellenőrzés: A dmidecode -t 1 parancs használata kulcsfontosságú. A kimenetnek kizárólag a hamisított, fizikai gyártóra és modellre vonatkozó adatokat kell tartalmaznia, és hiányozniuk kell belőle a "QEMU", "VMware", vagy "VirtualBox" karakterláncoknak.
CPU flag llenőrzés: Az lscpu parancs kimenetét át kell vizsgálni. A Vendor ID mezőnek a fizikai CPU gyártóját kell mutatnia (pl. GenuineIntel vagy AuthenticAMD), és a Flags szekciónak nem szabad tartalmaznia az olyan explicit hipervizor flageket, mint a hypervisor.
Kernel modulok ellenőrzése: Az lsmod parancs használatával ellenőrizni kell, hogy nincsenek-e betöltve virtualizációs illesztőprogramok (pl. virtio_pci, vboxguest).

6.1.2. Windows audit¶

Rendszerinformációk lekérdezése: A PowerShell Get-WmiObject -Class Win32_ComputerSystem | Select-Object Manufacturer, Model parancsai biztosítják a DMI Type 1 adatok gyors ellenőrzését. A standard systeminfo parancs szintén gyors áttekintést nyújt, különösen a "System Manufacturer" és "System Model" mezőknél.
Registry és szolgáltatások: A QEMU-GA vagy VMware Tools futó szolgáltatásait és kapcsolódó registry bejegyzéseit ellenőrizni kell a 4. rétegbeli tisztítás megerősítésére.

6.2. Korlátok és Fejlett Detektálási Technikák¶

A fenti konfigurációs rétegek sikeresen kezelik a felismerés ismert és dokumentált szoftveres vektorait (CPUID, DMI, eszközazonosítók). A 100%-os elfedés azonban, különösen egy dedikált, fejlett támadóval szemben, rendkívül nehéz, ha nem lehetetlen.

6.2.1. Időzítés és mikroszintű analízis¶

A virtualizáció elfedésének végső határát az alacsony szintű időzítési és hardveres viselkedésbeli különbségek jelentik. A VM-ekben a memória hozzáférési idők, az I/O késleltetés és a CPU parancsok végrehajtási ideje (különösen a teljesítménymérő számlálók, Performance Counters, használatával) eltér a fizikai hardverétől. Ezek a mikroszintű anomáliák a legfejlettebb detektálási technikák alapját képezik. A szoftveres konfiguráció nem tudja áthidalni a hardveremuláció és a natív hardver közti elvi teljesítménybeli különbségeket. A VMX-be beállított időzítési korrekciók, mint a monitor_control.virtual_rdtsc = "FALSE", csak mérséklik, de nem szüntetik meg ezt a problémát.

7. Következtetések és ajánlások¶

A virtuális gép fizikai gépként történő hiteles érzékelése a detektáló rendszerek, mint az Ansible, és a célzott felismerő scriptek számára, egy összetett és rétegelt biztonsági feladat. A rendelkezésre álló technikai megoldások (CPUID maszkolás, DMI/SMBIOS hamisítás, agent-ek eltávolítás) lehetővé teszik a virtualizáció leggyakoribb, dokumentált nyomainak sikeres elfedését.

Azonban a legnagyobb hatékonyság elérése a platformtól függő, precíz végrehajtást követeli meg:

KVM/QEMU környezetben a kulcs a libvirt XML kétlépcsős CPUID maszkolása (<kvm><hidden state='on'/> és feature name='hypervisor' policy='disable') a maximalitás érdekében, kombinálva a részletes, konzisztens <sysinfo> blokk definiálásával (beleértve a hwuuid használatát az eszköz konzisztencia érdekében).
VMware környezetben a VMX fájlban a hypervisor.cpuid.v0 = "FALSE" és monitor_control.restrict_backdoor = "TRUE" beállítások kritikusak a legalacsonyabb szintű kommunikációs vektorok és aláírások letiltására.
Minden platformon elengedhetetlen a Guest Agents (VMware Tools, QEMU-GA, VBox Guest Additions) teljes eltávolítása a vendég OS-ből, nem pusztán a letiltása. A fejlett detektáló scriptek képesek lehetnek az inaktív binárisok és maradványfájlok detektálására is.

A végső megállapítás az, hogy míg a szoftveres nyomok (CPUID, DMI) 99%-ban eltávolíthatók, a rendszer teljesítménybeli és időzítési viselkedésének abszolút paritása a fizikai hardverrel elérhetetlen marad. A sikeres elfedési stratégia ezen a szinten a legkisebb ismert anomália elvét követi: minden lehetséges nyomot el kell távolítani a szoftveres rétegekből, ami elegendő a legtöbb automatizált és egyszerűbb felismerő script megtévesztéséhez.