Bunu okuyordum CompTIA Security + SYO-201 book ve yazar David Prowse şunları iddia ediyor:
Hangi VM seçerseniz seçin, VM yerinde ayarlanan yazılım sınırlarını geçemez. Örneğin, bir virüs yürütüldüğünde ve diğer dosyalara yayıldığında bir bilgisayara bulaşabilir. Bununla birlikte, bir VM içinde yürütülen bir virüs VM) üzerinden yayılır ancak temeldeki gerçek işletim sistemini etkilemez.
VMWare oynatıcı çalıştırıp sanal makinemin işletim sisteminde bazı kötü amaçlı yazılımlar çalıştırıyorsam, all adresindeki Host sistemimin güvenliği konusunda endişelenmem gerekmez.
Sanal makine ağı Ana makine ile paylaşıyorsa ve paylaşılan klasörler etkinleştirilirse ne olur?
Bir solucanın kendisini Host makinesine bu şekilde kopyalaması hala mümkün değil mi? İşletim sistemi Windows ise ve bir USB depolama aygıtı takıyorsa kullanıcı AutoRun'a karşı hala savunmasız değil mi?
Sanal makineler gerçekten ne kadar güvenli? Host makinesini kötü amaçlı yazılımlardan ve saldırılardan ne kadar korurlar?
VM'ler kesinlikle geçebilir. Genellikle onları ağa bağlarsınız, bu nedenle bir ağ bileşenine (yani solucanlara) sahip tüm kötü amaçlı yazılımlar, adreslemelerinin/yönlendirmelerinin izin verdiği her yere yayılır. Düzenli virüsler sadece usermode çalışma eğilimindedir, bu nedenle açıkça iletişim kuramasalar da, gizli bir kanal kurabilirler. CPU'ları paylaşıyorsanız, bir VM) üzerinde yoğun bir işlem, durumu başka bir VM (prototipik zamanlama gizli kanalınızdır) ile etkili bir şekilde iletişim kurabilir.) sanal diskler üzerinde sabit bir sınırlama eğilimi gösterdiğinden, biraz daha zor olun, bu nedenle disk alanını aşırı işleyebilecek bir sisteminiz yoksa, bu bir sorun olmamalıdır.
Sanal makinelerin güvenliğini sağlamak için en ilginç yaklaşım Ayırma Çekirdeği olarak adlandırılır. John Rushby'nin 1981 belgesi bir sonucu olarak, temel olarak VM'lerin fiziksel ayırmaya eşdeğer bir şekilde izole edilmesi için bilgisayarın kaynaklarını aşağıdaki gibi belirli VM'lere vermesi gerektiğini belirtmektedir. nokta saklayabilen herhangi bir kaynak VM'ler arasında paylaşılır. Bunun temel sonuçları, altta yatan bilgisayar mimarisinin bunun atlanamayacak bir şekilde gerçekleştirilebileceği bir şekilde tasarlanmasını gerektirmesidir.
Bu makaleden 30 yıl sonra, sonunda bunu iddia eden birkaç ürünümüz var. x86, `` paylaşım yok '' fikrini tam olarak desteklemek için sanallaştırılamayan birçok talimat olduğu için bunun en büyük platformu değil. Ayrıca, dört VM'ye sahip olmak için, yaygın sistemler için çok pratik değildir, dört disk denetleyicisini, dört ekran kartını, dört fareli dört USB denetleyicisini asılı dört sabit sürücüye ihtiyacınız olacaktır.
Yıllar boyunca, araştırmacıların bir ana bilgisayar işletim sistemini bir sanal makineden istila etmenin yollarını açıklayan bazı beyaz makaleler yayınlanmıştır. Bunlar genellikle haklı olarak VM satıcılar tarafından güvenlik açıkları olarak görülür ve bu şekilde ele alınır.) Bu kağıtları ilk gördüğümden beri Intel, VM ve hipervizör.
Bu günlerde gördüğüm birkaç güvenlik açığı daha çok 'vmtools' bölümünde bulunuyor. Bu, konuk işletim sisteminin daha verimli çalışmasını sağlamak için yüklediğiniz yazılımdır (VMWare için bu, imleç yakalama işlemine ve konuk ile Host arasında ağ olmadan paylaşmaya izin veren şeydir). Bu, enfeksiyon için özel bir yazılım yoludur; araçları yüklemeyin, güvenlik açığına sahip değilsiniz.
Bazı kötü amaçlı yazılımlar, bir VM) içinde yürütüldüklerini algılama ve bu nedenle davranışlarını, VM'leri kullanmaya çalışan kötü amaçlı yazılım araştırmacılarının ağırlaştırılmasına göre değiştirebilir. Ancak, bu günlerde ne kadar yaygın olduğunu bilmiyorum.
Konuk-Ana makine kodu yürütme örneği Cloudburst açıklamasında bulunabilir. Windows Vista SP1'de VMware Workstation 6.5.0 build118166, Windows'ta VMware Workstation 6.5.1 build126130'daki başarıları gösteriliyor ve Bağışıklıktan bir makale detaylandırma var Vista SP1 ve (daha da korkunç) VMware ESX Server 4.0.0 build133495.
Bu muhtemelen çok az konfor sağlar, ancak bunun vahşi doğada kullanıldığını hiç duymadım ve istismar 2009'dan geldi. Bu kitap 2010 yılında yayınlandı, böylece yazar bu ifadeyi temizlemeli.
Sanal makine tam olarak mantıksal olarak ayrı bir makinedir, bu yüzden çıplak metal bir sistemde olduğu gibi aynı güvenlik katmanlarına sahip olmalıdır. Ana makineye ulaşmak için normal kanallar kullanıyorsa, sanal bir makine kullanmak bir vul'u durdurmaz.
Sanallaştırmadaki gerçek güzellik, VM'leri etkilenmedikleri bir duruma geri döndürme ve mevcut kaynakları daha iyi yönetme yeteneğidir.
Ana makineyi korumak için uygun adımlar atılırsa, sanallaştırma son derece güvenli olabilir. ESX/VM sunucu yönetimini farklı bir mantıksal ağda tutma ve VM-Host arabirim araçlarını kullanma gibi uygulamalar, saldırganları, Host'a nasıl ulaşılacağı gibi, bir makinenin sanal olduğu gerçeğinden çoğunlukla habersiz tutacaktır.
Ayrıca, VM ana bilgisayarlar (VMWare ve Hyper-V'de onlarla oynadım) etkileri bilinen bilinen istismarlar var. v (bkz this ), ancak eminim ufukta başka bulgular da vardır.VMWare'in de geçmişinde bazıları vardır (yani b , VMWare araçları tabanlı, ancak hala geçerlidir).
Ne yaptığınıza bağlı olarak, analizi kendi makinenizde yapma ihtiyacınızı ortadan kaldırabilecek bazı çevrimiçi araçlar vardır. İşte göz atmak için birkaç site:
- Threatexpert.com
- anubis.iseclab.org
- virustotal.com
Security + malzemesi ile kastedilen, şu ana kadar kötü amaçlı yazılımın VM = VM Paylaşılan bir ağa yayılma gibi diğer mekanizmalar, bunlar farklı fiziksel kutularmış gibi aynıdır.
Bu istismarla gösterildiği gibi mükemmel bir şekilde güvenli değiller:
VENOM, CVE-2015-3456, özellikle Xen, KVM, VirtualBox ve yerel QEMU istemcisi gibi bazı yaygın bilgisayar sanallaştırma platformlarını etkileyen bir güvenlik açığıdır.
Bu güvenlik açığı, bir saldırganın etkilenen bir sanal makine (VM) misafirinin sınırlarından kaçmasına ve Ana Bilgisayara kod yürütme erişimi almasına olanak verebilir. Güvenlik açığıyla ilgili daha fazla ayrıntı burada bulunabilir.
İlgi çekici ve ilgili olan 2016 Pwn2Own güvenlik yarışması, bir VMWare Workstation sanal makinesinden kaçan yarışmalarından biri oldu. (Diğerleri, tarayıcı sanal alanlarından kaçmayı veya fiziksel makineleri ele geçirmeyi içerir). Bu bir fikir vermek gerekir 1) en azından makul ve 2) eğer kolay o zaman biz bunu duymak için bir yol var - sadece sonucu kontrol :)
Daha genel olarak VM güvenliği teorik olarak birçok yönden kaçabilir. Örneğin -
Misafir-Host komutları ve API'ları (örn. VMware araçları)
Ana İşletim Sistemi'nin kendisinde, VM işleminde çalıştırılarak hafifletilmeyen istismar edilebilir zayıflıklar (bazı konuk işletim sistemi çağrıları yanlışlıkla "güvenli" olarak değerlendirilir ve konuk sürücü tarafından doğrudan Ana Bilgisayar İşletim Sistemine veya aygıt sürücüsüne aktarılırsa hız, ancak bir istismar var)
Satıcı sürücülerindeki veya satıcı kodundaki hatalar (örneğin, bir Ana makine sürücüsü konuk işletim sistemi için ağ köprülemesine izin verir; belki de bir hata, Ana makine üzerinde çekirdek düzeyinde aramaların veya kodların yapılmasına izin verebilir).
Ana Bilgisayardaki diğer yazılımlardan kaynaklanan güvenlik açıkları (tutarlı örnek - yerel antivirüs, Ana Bilgisayardan taranacak tüm ağ trafiğini keserse ve konuk trafiği bunun bir parçası olarak taranırsa (sanal NIC nedeniyle yok sayılmak yerine) ), ardından a/v motorunun kötü amaçlı hazırlanmış bir trafiğe veya pakete karşı güvenlik açığı, VM kaynaklı trafiğin Ana Bilgisayara kaçmasına izin verebilir)
Kullanıcı tarafından hatalı yapılandırma (Konuk dosyalarının erişebilmesi için eşlenen veya yeterince güvenli olmayan/ayrılmış ana makine dosyaları)
Kapsam vardır ve yaygınlığı göz önüne alındığında, kesinlikle istismar için aktif olarak incelenmektedir. Şüphesiz, açıklardan yararlanılmıyorsa güvenlik açıkları düzenli olarak bulunacak ve yama gerektirecektir.