Sanallaştırma katmanlarını sıkılaştırma¶
In the beginning of this chapter we discuss the use of both physical and virtual hardware by instances, the associated security risks, and some recommendations for mitigating those risks. Then we discuss how the Secure Encrypted Virtualization technology can be used to encrypt the memory of VMs on AMD-based machines which support the technology. We conclude the chapter with a discussion of sVirt, an open source project for integrating SELinux mandatory access controls with the virtualization components.
Fiziksel donanım (PCI ile)¶
Birçok hipervizör, PCI geçidi olarak bilinen bir işlevsellik sunar. Bu, bir örneğin düğüm üzerindeki bir donanıma doğrudan erişmesini sağlar. Örneğin, bu, örneklerin yüksek performanslı hesaplama için birleştirilmiş cihaz mimarisi (CUDA) hesaplayan ekran kartlarına veya GPU’lara erişmesine izin vermek için kullanılabilir. Bu özellik iki tür güvenlik riski taşır: doğrudan bellek erişimi ve donanım enfeksiyonu.
Doğrudan bellek erişimi (DMA), belirli donanım aygıtlarının ana bilgisayardaki rastgele fiziksel bellek adreslerine erişmesine izin veren bir özelliktir. Genellikle video kartları bu yeteneğe sahiptir. Bununla birlikte, bir örneğe rastgele fiziksel bellek erişimi verilmemelidir, çünkü bu hem ana sistem hem de aynı düğümde çalışan diğer örneklerin tam olarak görülebilmesini sağlar. Donanım üreticileri bu durumlarda DMA erişimini yönetmek için bir giriş / çıkış bellek yönetim birimi (IOMMU) kullanmaktadır. Bulut mimarlarının, hipervizörün bu donanım özelliğini kullanacak şekilde yapılandırıldığından emin olmasını öneririz.
Not
IOMMU özelliği Intel tarafından VT-d, AMD tarafından AMD-Vi olarak pazarlanmaktadır.
Bir donanımsal bozulma, bir örnek donanım yazılımında veya bir aygıtın bazı bölümlerinde kötü amaçlı bir değişiklik yaparsa oluşur. Bu aygıt, başka örneklerle veya ana bilgisayar işletim sistemi tarafından kullanıldığı için, kötü niyetli kod bu sistemlere yayılabilir. Sonuçta, bir örnek güvenlik alanının dışında bir kod çalıştırabilir. Fiziksel donanımın durumunu sanal donanımdan daha zor hale getirdiği için bu durum önemli bir ihlaldir ve yönetim ağına erişim gibi ilave riske neden olabilir.
Donanım bozulması sorununun çözümleri, alana özgüdür. Strateji, bir örneğin donanım durumunu nasıl değiştirebileceğini belirlemek ve ardından donanım donanım kullanılarak örneği tamamladığında tüm değişiklikleri nasıl sıfırlayacağını belirlemektir. Örneğin, bir seçenek kullanıldıktan sonra üretici yazılımı yeniden başlatmak olabilir. Donanımların ömrünü güvenlikle dengelemek için bir ihtiyaç var, çünkü bazı yazılımlar çok sayıda yazdıktan sonra başarısız olacak. TPM teknolojisi, :ref: management-secure-bootstrapping bölümünde açıklanan, yetkisiz yazılım değişikliklerini tespit etmek için bir çözümdür. Seçilen strateji ne olursa olsun, bu tür bir donanım paylaşımıyla ilişkili riskleri anlamak, belirli bir dağıtım senaryosu için uygun şekilde hafifletilebilmesi önemlidir.
PCI passthrough ile ilgili risk ve karmaşıklıklar nedeniyle, varsayılan olarak devre dışı bırakılmalıdır. Belirli bir ihtiyaç için etkinleştirildiyse, yeniden çıkmadan önce donanımın temiz olduğundan emin olmak için uygun işlemleri yapmanız gerekir.
Sanal donanım (QEMU)¶
Sanal makine çalıştırırken, sanal donanım, sanal makine için donanım arayüzü sağlayan bir yazılım katmanıdır. Örnekler, ağ, depolama, video ve ihtiyaç duyulabilecek diğer cihazları sağlamak için bu işlevi kullanıyor. Bunu göz önünde bulundurarak, çevrenizdeki çoğu örnek, yalnızca doğrudan donanım erişimi gerektiren bir azınlıkla sanal donanım kullanır. Büyük açık kaynaklı hypervisors şu işlevleri kullanır :term:`QEMU <Quick EMUlator (QEMU)> `. QEMU, sanallaştırma platformları için önemli bir ihtiyacı karşılamakla birlikte, yazmak ve korumak için çok zorlu bir yazılım projesi olduğu kanıtlanmıştır. QEMU’daki işlevselliğin çoğu, geliştiricilerin çoğu tarafından anlaşılması zor olan düşük düzey koduyla uygulanmaktadır. QEMU tarafından sanallaştırılan donanım, kendi tiksinti grubuna sahip birçok eski aygıtı içerir. Bunların hepsini bir araya getiren QEMU, hipervizör koparma saldırıları da dahil olmak üzere birçok güvenlik sorununun kaynağı olmuştur.
QEMU’nun sıkılaştırılması için proaktif adımlar atmanız önemlidir. Üç özel adım önermekteyiz:
Kod tabanını küçültmek.
Derleyici sıkılaştırması kullanmak.
sVirt, SELinux ya da AppArmor gibi zorunlu erişim kontrolü kullanmak.
Iptables’in varsayılan ağ filtresi trafik süzme politikasına sahip olduğundan emin olun ve her kuralın anlaşılması ve mevcut politikanın genişletilmesi gerekip gerekmediğinin belirlenmesi için mevcut kural kümesini incelemeyi düşünün.
QEMU kod tabanını küçültmek¶
Kullanılmayan bileşenleri sistemden kaldırarak QEMU kod tabanını küçültmenizi etmenizi öneririz. QEMU, birçok farklı sanal donanım aygıtı için destek sağlar, ancak belirli bir örnek için yalnızca ufak sayıda aygıt gereklidir. En yaygın donanım aygıtları Virtio aygıtlarıdır. Bazı eski örneklerin, bakış meta verileri kullanılarak belirlenebilen belirli donanıma erişimi olması gerekir:
$ glance image-update \
--property hw_disk_bus=ide \
--property hw_cdrom_bus=ide \
--property hw_vif_model=e1000 \
f16-x86_64-openstack-sda
Bir bulut mimarının bulut kullanıcılarına hangi cihazları sunacaklarına karar vermeleri gerekir. Gerekli olmayan her şey QEMU’dan kaldırılmalıdır. Bu adım, QEMU yapılandırma komut dosyasına iletilen seçenekleri değiştirdikten sonra QEMU’yu yeniden derlemeyi gerektirir. Güncel opsiyonların tam listesi için: komutu: ./configure –help QEMU kaynak dizininden çalıştırın. Dağıtımınız için neyin gerekli olduğuna karar verin ve kalan seçenekleri devre dışı bırakın.
Derleyici sıkılaştırması¶
Derleyici sıkılaştırma seçeneklerini kullanarak QEMU’yu sıkılaştırın. Modern derleyiciler, oluşturulan ikili dosyaların güvenliğini artırmak için çeşitli derleme zamanı seçenekleri sunar. Bu özelliklere salt okunur yer değiştirme (RELRO), yığın kanaryaları, asla çalıştırma (NX), konumdan bağımsız yürütülebilir (PIE) ve adres alanı düzenini rasgeleliği (ASLR) dahildir.
Birçok modern Linux dağıtımı zaten derleyici sıkılaştırma etkin QEMU oluşturur, devam etmeden önce varolan çalıştırılabilir dosyanın doğrulanmasını öneririz. Bu doğrulamayla size yardımcı olabilecek bir araç checksec.sh olarak adlandırılır
- Salt-Okunur yer değiştirme (RELRO)
Bir yürütülebilir dosyanın veri bölümlerini sıkılaştırır. Tam ve kısmi RELRO modları gcc tarafından desteklenir. QEMU için tam RELRO en iyi seçimdir. Bu, genel ofset tablosunu salt okunur hale getirecek ve çeşitli iç veri bölümlerini sonuçtaki yürütülebilir dosyanın program veri bölümünden önce yerleştirecektir.
- Yığın kanaryaları
Arabellek taşması saldırılarını önlemeye yardımcı olması için değerleri yığına yerleştirir ve varlığını doğrular.
- Asla Çalıştırma (NX)
Veri Çalıştırma Engellemesi (DEP) olarak da bilinen, yürütülebilir dosyanın veri bölümlerinin çalıştırılmamasını sağlar.
- Konum Bağımsız Çalıştırılabilir (PIE)
ASLR için gerekli olan konum bağımsız çalıştırılabilir üretir.
- Adres Uzayı Düzen Rastgeleleştirilmesi (ASLR)
Bu, hem kod hem de veri bölgelerinin yerleşiminin rastgele seçilmesini sağlar. Çalıştırılabilir dosya PIE ile kurulduğunda çekirdek tarafından etkinleştirilir (tüm modern Linux çekirdeği ASLR’yi destekler).
Aşağıdaki derleyici seçenekleri GCC için, QEMU derlenirken önerilir:
CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector \
--param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 \
-Wl,-z,relro,-z,now"
Derleyici sıkılaştırmasının düzgün şekilde çalıştığından emin olmak için QEMU çalıştırılabilri dosyanızı, derledikten sonra test etmenizi öneririz.
Çoğu bulut dağıtımı elle QEMU gibi bir yazılım oluşturmaz. İşlemin tekrarlanabilir olmasını sağlamak ve sonuçların bulut boyunca kolayca dağıtılmasını sağlamak için paket kullanmak daha iyidir. Aşağıdaki referanslar, mevcut paketlere derleyici sıkılaştırma seçeneklerinin uygulanmasıyla ilgili ek ayrıntılar sunmaktadır.
- DEB paketleri:
- RPM paketleri:
Secure Encrypted Virtualization¶
Secure Encrypted Virtualization (SEV) is a technology from AMD which enables the memory for a VM to be encrypted with a key unique to the VM. SEV is available in the Train release as a technical preview with KVM guests on certain AMD-based machines for the purpose of evaluating the technology.
The KVM hypervisor section of the nova configuration guide contains information needed to configure the machine and hypervisor, and lists several limitations of SEV.
SEV provides protection for data in the memory used by the running VM.
However, while the first phase of SEV integration with OpenStack enables
encrypted memory for VMs, importantly it does not provide the
LAUNCH_MEASURE or LAUNCH_SECRET capabilities which are available with
the SEV firmware. This means that data used by an SEV-protected VM may be
subject to attacks from a motivated adversary who has control of the
hypervisor. For example, a rogue administrator on the hypervisor machine could
provide a VM image for tenants with a backdoor and spyware capable of stealing
secrets, or replace the VNC server process to snoop data sent to or from the
VM console including passwords which unlock full disk encryption solutions.
To reduce the chances for a rogue administrator to gain unauthorized access to data, the following security practices should accompany the use of SEV:
A full disk encryption solution should be used by the VM.
A bootloader password should be used on the VM.
In addition, standard security best practices should be used with the VM including the following:
The VM should be well maintained, including regular security scanning and patching to ensure a continuously strong security posture for the VM.
Connections to the VM should use encrypted and authenticated protocols such as HTTPS and SSH.
Additional security tools and processes should be considered and used for the VM appropriate to the level of sensitivity of the data.
Sorunlu erişim kontrolleri¶
Derleyici sıkılaştırması, QEMU işlemine saldırmanın daha zor olmasını sağlar. Ancak, bir saldırgan başarılı olursa saldırının etkisini sınırlamak istersiniz. Zorunlu erişim denetimleri, QEMU işlemindeki ayrıcalıkların yalnızca ihtiyaç duyulan şeye kısıtlanmasıyla bunu başarır. Bu, sVirt, SELinux veya AppArmor kullanılarak başarılabilir. SVirt’i kullanırken, SELinux her QEMU işlemini ayrı bir güvenlik bağlamında yürütmek üzere yapılandırılmıştır. AppArmor, benzer işlevler sağlamak üzere yapılandırılabilir. Aşağıdaki bölümde sVirt ve örnek izolasyonu hakkında daha fazla ayrıntı var sVirt: SELinux ve sanallaştırma.
Birçok OpenStack servisi için belirli SELinux ilkeleri mevcuttur. CentOS kullanıcıları bu politikaları selinux ilke kaynak paketini kurarak gözden geçirebilirler. En güncel politikalar Fedora’nın selinux-policy deposunda görünür. rawhide-contrib dalında, .te ile biten, örneğin cinder.te gibi, SELinux çalıştıran sistemlerde kullanılabilen dosyalar bulunur.
OpenStack servisleri için AppArmor profilleri henüz mevcut değildir, ancak OpenStack-Ansible projesi bunu bir ‘OpenStack servisi çalıştıran her kapsayıcıya AppArmor profilleri uygulayarak gerçekleştirir.
sVirt: SELinux ve sanallaştırma¶
Benzersiz çekirdek düzeyinde mimari ve Ulusal Güvenlik Ajansı (NSA) tarafından geliştirilen güvenlik mekanizmaları ile KVM, çoklu kiracılık için temel izolasyon teknolojileri sağlar. Gelişimsel kökenleri 2002 yılına dayanan Secure Virtualization (sVirt) teknolojisi, SELinux’u modern sanallaştırmaya karşı uyguluyor. Etiketlere dayalı ayırma denetimini uygulamak üzere tasarlanan SELinux, sanal makine işlemleri, aygıtlar, veri dosyaları ve kendi adına hareket eden sistem işlemleri arasında izolasyon sağlamak üzere genişletildi.
OpenStack’ın sVirt uygulaması, iki ana tehdit vektörüne karşı hipervizör ana makine ve sanal makineleri korumayı hedeflemektedir:
- Hipervizör tehditleri
Bir sanal makine içinde çalışan ve güvenliği ihlal edilmiş bir uygulama, alttaki kaynakları erişmek için hipervizöre saldırır. Örneğin, bir sanal makine, hipervizör işletim sistemine, fiziksel aygıtlara veya diğer uygulamalara erişebildiğinde. Bu tehdit vektörü, bir hypervisor üzerinde uzlaşmanın fiziksel donanıma bulaşabileceği ve diğer sanal makinelerin ve ağ bölümlerinin ortaya çıkmasının ciddi risk oluşturduğunu belirtir.
- Sanal Makine (çok kiracılı) tehditler
Bir VM içinde çalışan ve tehlike altındaki bir uygulama, başka bir sanal makineye ve kaynaklarına erişmek veya kontrol etmek için hipervizöre saldırır. Bu, sanallaştırmaya özgü bir tehdit vektörüdür ve tek bir uygulamadaki savunmasızlıktan ötürü çok sayıda sanal makine dosyası görüntüsü tehlikeye atılacağı için önemli risk oluşturmaktadır. Gerçek ağları korumaya yönelik yönetim teknikleri doğrudan sanal ortama uygulanmadığından, bu sanal ağ saldırısı büyük bir endişe kaynağıdır.
Her bir KVM tabanlı sanal makine, SELinux tarafından etiketlenen ve her sanal makinenin etrafında bir güvenlik sınırı oluşturan bir süreçtir. Bu güvenlik sınırı, Linux çekirdeği tarafından izlenir ve uygulanır ve sanal makinenin, ana makine veri dosyaları veya diğer VM’ler gibi kendi sınırlarının dışındaki kaynaklara erişimini kısıtlar.
Sanal makine içinde çalışan konuk işletim sisteminden bağımsız olarak sVirt izolasyonu sağlanır. Linux veya Windows VM’leri kullanılabilir. Buna ek olarak, birçok Linux dağıtımı, sanal makinenin dahili sanal kaynakları tehditlerden korumasına izin veren işletim sistemi içinde SELinux’u sağlar.
Etiketler ve kategoriler¶
KVM tabanlı sanal makine örnekleri svirt_image_t olarak bilinen kendi SELinux veri türüne göre etiketlenmiştir. Çekirdek düzeyinde koruma, kötü amaçlı yazılım gibi yetkisiz sistem işlemlerinin disk üzerindeki sanal makine resim dosyalarını manipüle etmesini engeller. Sanal makineler kapalı olduğunda, görüntüler aşağıda gösterildiği gibi svirt_image_t olarak depolanır:
system_u:object_r:svirt_image_t:SystemLow image1
system_u:object_r:svirt_image_t:SystemLow image2
system_u:object_r:svirt_image_t:SystemLow image3
system_u:object_r:svirt_image_t:SystemLow image4
svirt_image_t etiketi, görüntü dosyalarını disk üzerinde benzersiz şekilde tanımlar ve SELinux ilkesinin erişimi kısıtlamasına izin verir. Bir KVM tabanlı hesaplama görüntüsü açıldığında, sVirt, görüntüye rastgele sayısal bir tanımlayıcı ekler. sVirt, hypervisor düğüm başına maksimum 524.288 sanal makineye sayısal tanımlayıcı atayabilir, ancak OpenStack dağıtımlarının çoğunda bu kısıtlamayla karşılaşma ihtimali çok düşüktür.
Bu örnek sVirt kategori tanımlayıcısını gösterir:
system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2
SELinux kullanıcılar ve roller¶
SELinux kullanıcı rollerini yönetir. Bunlar -Z bayrağı veya semanage komutu ile görülebilir. Hipervizörde, yalnızca yöneticiler sisteme erişebilir olmalı ve hem yönetici kullanıcılar hem de sistemdeki diğer kullanıcılar için uygun bir bağlam içermelidir. Daha fazla bilgi için, SELinux kullanıcı belgelerine bakın..
Booleanlar¶
SELinux’u idare etmenin yükünü hafifletmek için birçok kurumsal Linux platformu, SELinux Booleanlarını kullanarak sVirt’in güvenlik durumunu hızla değiştirir.
Red Hat Kurumsal Linux tabanlı KVM dağıtımları aşağıdaki sVirt booleanlarını kullanır:
sVirt SELinux Boolean |
Açıklama |
|---|---|
virt_use_common |
Sanallaştırmanın seri ya da paralel haberleşme bağlantı noktalarını kullanmasına izin ver. |
virt_use_fusefs |
Sanallaştırmanın FUSE ile bağlanmış dosyaları okumasına izin ver. |
virt_use_nfs |
Sanallaştırmanın NFS ile bağlanmış dosyaları yönetmesine izin ver. |
virt_use_samba |
Sanallaştrmanın CIFS ile bağlanmış dosyaları yönetmesine izin ver. |
virt_use_sanlock |
Kapatılan sanal konukların sanlock ile etkileşime girmesine izin ver. |
virt_use_sysfs |
Sanallaştırmanın aygıt yapılandırmasını (PCI) yönetmesine izin ver. |
virt_use_usb |
Sanallaştırmanın USB cihazları kullanmasına izin ver. |
virt_use_xserver |
Sanal makinenin X Pencere Sistemi ile etkileşime geçmesine izin ver. |
