Esmalt vastake, siis miks: virtuaalne masin võib olla turvalisem.

Praktilisest seisukohast on olemas kood ja pahavara, mis võivad nakatada nii alglaadimispartitsioone, BIOS-i, ja ka riistvara. Niisiis, VM-il on vähendatud rünnakupinnal üldisest vaatepunktist veidi rohkem eeliseid - potentsiaalne VM-i hüppekood on VM-ile spetsiifiline suurim. See kood on tõenäoliselt spetsiifiline kasutatava VM-i tüübile, nagu hiljutine http://www.kb.cert.org/vuls/id/649219 probleem. Pange tähele, et selleks on vaja konkreetset virtuaalset masinat (kvm või xen), rõngast jne.

Nii et vaenuliku koodi vaatenurgast on virtualiseeritud turvalisem.

Lähenedes võrgu nurga alt, on paljudel virtualiseerimislahenduste kasutajatel võrgu tasemel NATi, PAT-i või muude funktsioonide kaudu paindlikkus NAT-i, PAT-i või muude funktsioonide kaudu, mida operatsioonisüsteem ei pruugi omakeelne toetada, või kasutavad VM-ide abil oma paremat turvalisust. Turvalise poosi suurendamine konkreetse virtuaalse masina abil on kogu triviaalse liikluse kontrollimiseks virtualiseerimine üsna tühine.

Nii et võrgu turvalisuse seisukohalt on virtualiseeritud turvalisem. tugev>

Külaliste toimingutele. Operatsioonisüsteemide kloonimise ilu sekundis ... Sõltuvalt kasutatava virtualiseerimislahenduse tüübist saab välja lülitatud VM-i lappida läbipaistvalt, ilma et kasutaja seda teeks. On triviaalne võtta üldotstarbeline VM ja lukustada see erinevate kõvenemisjuhendite abil sinna, kus funktsionaalsus on minimaalne, välja arvatud konkreetsetest rakendustest. VM-id hõlbustavad ekstreemsete karastamistasemete sooritamist, näiteks sertifikaatide usalduse poodides vähima privileegi sooritamine (nt kustutan enamiku sertifikaate kommerts-CA-dest, välja arvatud need, mida ma kasutan) Seda tüüpi toimingud võivad VM-iga olla palju kiiremad tänu võimalusele katastroofiliste muutuste hetkepilt ja taastumine. Lisaks saab VM-i tervikuna hõlpsasti pakendada faili ja salvestada kuhugi, USB-le jne. Mõeldes ka kompromissidele, mõelge, et virtualiseerimisel võib kompromiss olla palju vähem privilegeeritud kui regulaarselt. Näiteks 1. tüüpi hüpervisoris on hüpervisor ise arvuti kõige privilegeeritum eksemplar. Ründaja kõõlusetasemete suurenemine. Seda saab kasutada ka arendajatele administraatori- / juurjuurdepääsu andmiseks, ilma et arendaja domeeni administraatoreid või ettevõtte LDAP-i privileege annaks.

Nii et külalisoperatsioonide vaatenurgast on virtualiseeritud turvalisem .

Keskendun siiski sekundiks eeldusele - et virtualiseeritud ja alglaaditud natiivtüüpi OS-id on kas või valikud. Need ei ole, kuna saate virtualiseeritud operatsioonisüsteemi käivitada kolmanda osapoole lahenduste abil, nagu oleks see olnud topeltbuutimisvalik. Tarkvara nagu vboot võimaldab VHD / VMDK / VDI / toores vormingus käivitamist.

Mis puutub virtualiseerimise tüüpidesse, siis on mõned antud juhul sobivad. Need on 1. tüüpi virtualiseerimine (paljas metall), 2. tüüpi virtualiseerimine (hostitud OS) ja ma arvan, et osaline operatsioonisüsteemi & paravirtualiseerimine ei kuulu reguleerimisalasse. Juhtiv x86 1. tüüpi virtualiseerimislahendus VMware vsphere hypervisor kasutab minimaalse rünnakupinnaga mikrotuumalist lähenemist. 2. tüüpi virtualiseerimisel on suuremad rünnakupinnad, kuna need tuginevad täielikult aluseks olevale operatsioonisüsteemile. Nii et Theo kommentaarid täielike operatsioonisüsteemide kohta on VMware'ile rakendamisel valed.

Siin on mõni VMware'i propaganda sellel teemal

http://www.vmware.com/ tehnilised ressursid / turvalisus / ülevaade.html

Muidugi on turvalisus enamasti kompromiss kasutatavuse ja turvalisuse vahel. Oluline on kaaluda ohuolukorda, millega kasutaja tõenäoliselt kokku puutub, ja kes paigutab teie vastu ründamiseks ressursse. Kui olete rahvusriik või pank, vajate ulatuslikku kaitset. Ettevõtted, rohkemgi veel. Individuaalsed vähetuntud kasutajad - piisavalt hea kaitse. Pidage meeles, et hea turvalahendus kaitseb teid piisavalt, kuid ei mõjuta kasutatavust negatiivselt nii palju kui takistuseks. Üldine riskijuhtimine on teine ​​teema, mis väärib ülevaadet mujal.

Ma ei rääkinud eksootilisematest turbemeetoditest, nagu õhukesed kliendid, mida saaks kasutada virtualiseerimise turvalisuse laiendamiseks, vähendades veelgi rünnakupindu, või TPM-i lukustamine koos 1. tüüpi hüpervisoriga.

Mõlemad on seoses sellega turvalisemad.

Kui soovite luua "liivakasti" keskkonna, kus saaksite katsetada ohtlike koodidega, on see virtuaalmasinas turvalisem kui dual-boot keskkond. See näib teie küsimuselt olevat see, mida te küsite. Põhjus on selles, et virtuaalsel masinal puudub otsene juurdepääs teie riistvarale, see töötab programmina jäljendatud programmina, nii et kogu käituskeskkond eksisteerib ainult ulatuses, mida virtualiseerimissüsteem lubab (eeldades, et teie hüpervisoril pole turvavigu). Kui teie VM-süsteem deklareerib, et juurdepääs kõvakettale on võimatu, ei pääse sees töötav programm kõvakettale.

Kui soovite seevastu tavapärasest keskkonnast pääseda ja luua teada-turvaline keskkond, siis on topeltbuutimine ainus viis sinna pääseda. Põhjus on see, et kuna VM eksisteerib programmina teie tavalisel töölaual, võivad kõik teie tavalise töölaua turvaprobleemid laieneda ka VM-ile endale - töölaud võib kinni pidada liiklust, klahvivajutusi, kettale juurdepääsu jne. VM. Nii et kui teie töölaud pole turvaline, ei saa teie virtuaalne masin olla kindel. Paistab, et see pole see, mida te vajasite, kuid võib olla kasulik sellest tulevikus aru saada.

Isiklikult tundub see olevat paranoiaga piiritletud inimestele, kes ei tee pahavara uurimist.

Kui kasutate 2 erinevat operatsioonisüsteemi, vajate pahavara, mis teab, kuidas kahte erinevat failisüsteemi lugeda.

Kui see töötab VM-is, vajate pahavara olema suunatud spetsiaalselt hüpervisorile, et see saaks liivakastist välja murda.

Kergendate juba mõningaid ilmseid viise, kuidas miski teid nakatab, joostes madalamate õigustega ja muuga. Vastasel juhul oleksid teie parimad leevendamisülesanded tavalised varukoopiad, pahavara otsimine või minu jaoks UNIX-põhise süsteemi käitamisel võite käivitada failide kontrollijaid, mis kasutavad kontrollimissummasid failimuudatuste jälgimiseks, ja siis, kui leiate kahtlased failid / muudatused, meilisõnumeid.

Kuigi turvalisus peab olema kihiline, et see oleks tõhus, ei võta see palju tee tavalise hoolduse jaoks tavalist hooldust. Isiklikult, kui kardate, et mõni tegevus eriti põhjustab probleeme, siis ma lihtsalt pildistaksin ja veereksin selle töö ajal tagasi. Erinevate OS-ide ja failide kontrollsumma jälgimine peaks teile teatama, kas midagi on juhtunud, siis oleks varukoopiatest taastamine tõenäoliselt enam kui piisav, kuna kõik, mis VM-i rikkub ja mõjutab erinevaid OS-e, peaks olema just teie jaoks suunatud.

On mõningaid teoreetilisi riske (mida pole veel tõestatud), mis muudaksid topeltboot-lähenemise vähem turvaliseks. Need hõlmavad Trooja laadimist mittestandardsele riistvarale. Näiteks nakatades aku püsivara millegagi, mis seejärel ajab tuuma toitehalduri üle. See võib ületada piiride taaskäivitamise ja teil pole selle üle tegelikult mingit sõnaõigust. VM-i lähenemisviis seda nõrkust ei kannataks.

Minu teada on need parimal juhul ideekindlad, kuid jällegi, see on whitehat maailmas. Ma ei imestaks, kui NSA-l see töötab.