Pengerasan lapisan virtualisasi¶
Pada awal bab ini, kami membahas penggunaan perangkat keras fisik dan virtual secara instan, risiko keamanan terkait, dan beberapa rekomendasi untuk mengurangi risiko tersebut. Kemudian kami membahas bagaimana teknologi Secure Encrypted Virtualization dapat digunakan untuk mengenkripsi memori VM pada mesin berbasis AMD yang mendukung teknologi tersebut. Kami menyimpulkan bab ini dengan diskusi sVirt, sebuah proyek open source untuk mengintegrasikan kontrol akses wajib SELinux dengan komponen virtualisasi.
Perangkat keras fisik (passthrough PCI)¶
Banyak hypervisor menawarkan fungsionalitas yang dikenal sebagai passthrough PCI. Hal ini memungkinkan sebuah instance untuk memiliki akses langsung ke perangkat keras pada node. Misalnya, ini bisa digunakan untuk mengizinkan instance mengakses kartu video atau GPU yang menawarkan compute unified device architecture (CUDA) untuk perhitungan kinerja tinggi. Fitur ini membawa dua jenis risiko keamanan: akses memori langsung dan infeksi perangkat keras.
Direct memory access (DMA) adalah fitur yang memungkinkan perangkat keras tertentu mengakses alamat memori fisik secara acak di komputer host. Seringkali kartu video memiliki kemampuan ini. Namun, sebuah instance tidak boleh diberikan akses memori fisik yang acak karena ini akan memberikan tampilan penuh dari kedua sistem host dan instance lainnya yang berjalan pada node yang sama. Vendor perangkat keras menggunakan input/output memory management unit (IOMMU) untuk mengelola akses DMA dalam situasi ini. Kami merekomendasikan arsitek awan harus memastikan bahwa hypervisor dikonfigurasi untuk memanfaatkan fitur perangkat keras ini.
Catatan
Fitur IOMMU dipasarkan sebagai VT-d oleh Intel dan AMD-Vi oleh AMD.
Sebuah infeksi perangkat keras terjadi ketika sebuah instance membuat modifikasi berbahaya ke firmware atau bagian lain dari perangkat. Karena perangkat ini digunakan oleh instance lain atau host OS, kode berbahaya dapat menyebar ke sistem tersebut. Hasil akhirnya adalah satu instance dapat menjalankan kode di luar domain keamanannya. Ini adalah pelanggaran yang signifikan karena lebih sulit untuk mengatur ulang keadaan perangkat keras fisik daripada perangkat keras virtual, dan dapat menyebabkan pembukaan (exposure) tambahan seperti akses ke jaringan manajemen.
Solusi untuk masalah infeksi perangkat keras adalah domain yang spesifik. Strateginya adalah untuk mengidentifikasi bagaimana sebuah instance dapat memodifikasi keadaan perangkat keras kemudian menentukan bagaimana mengatur ulang modifikasi apa pun bila instance dilakukan dengan menggunakan perangkat keras. Sebagai contoh, satu pilihan bisa untuk re-flash firmware setelah digunakan. Ada kebutuhan untuk menyeimbangkan umur panjang hardware dengan keamanan karena beberapa Firmwares akan gagal setelah sejumlah besar penulisan. Teknologi TPM, dijelaskan dalam :ref: management-secure-bootstrapping, adalah solusi untuk mendeteksi perubahan firmware yang tidak sah. Terlepas dari strategi yang dipilih, penting untuk memahami risiko yang terkait dengan pembagian perangkat keras semacam ini sehingga dapat dimitigasi dengan benar untuk skenario penerapan tertentu.
Karena risiko dan kompleksitas yang terkait dengan PCI passthrough, harus dinonaktifkan secara default. Jika diaktifkan untuk kebutuhan tertentu, Anda harus memiliki proses yang sesuai untuk memastikan perangkat keras bersih sebelum diterbitkan ulang.
Virtual hardware (QEMU)¶
Saat menjalankan mesin virtual, perangkat keras virtual adalah lapisan perangkat lunak yang menyediakan antarmuka perangkat keras untuk mesin virtual. Instance menggunakan fungsi ini untuk menyediakan jaringan, penyimpanan, video, dan perangkat lain yang mungkin diperlukan. Dengan pemikiran ini, sebagian besar Instance di lingkungan Anda secara eksklusif akan menggunakan perangkat keras virtual, dengan minoritas yang memerlukan akses perangkat keras langsung. Penggunaan hypervisor utama open source :term: QEMU <Quick EMUlator (QEMU)> untuk fungsi ini. Sementara QEMU memenuhi kebutuhan penting akan platform virtualisasi, namun terbukti menjadi proyek perangkat lunak yang sangat menantang untuk ditulis dan dipelihara. Sebagian besar fungsi di QEMU diimplementasikan dengan kode tingkat rendah yang sulit dipahami oleh sebagian besar pengembang. Perangkat keras yang di virtualisasi oleh QEMU mencakup banyak perangkat lawas yang memiliki kebiasaan mereka sendiri. Menempatkan semua ini bersama-sama, QEMU telah menjadi sumber banyak masalah keamanan, termasuk serangan pembobolan hypervisor.
Penting untuk mengambil langkah proaktif untuk mengeras QEMU. Kami merekomendasikan tiga langkah spesifik:
Meminimalkan basis kode.
Menggunakan kompilator pengerasan.
Menggunakan kontrol akses wajib seperti sVirt, SELinux, atau AppArmor.
Pastikan iptables Anda memiliki kebijakan default yang memfilter lalu lintas jaringan, dan pertimbangkan untuk memeriksa peraturan yang ada agar dapat memahami setiap peraturan dan menentukan apakah kebijakan tersebut perlu diperluas.
Meminimalkan basis kode QEMU¶
Kami merekomendasikan untuk meminimalkan basis kode QEMU dengan melepaskan komponen yang tidak terpakai dari sistem. QEMU menyediakan dukungan untuk berbagai perangkat perangkat keras virtual yang berbeda, namun hanya sejumlah kecil perangkat yang dibutuhkan untuk instance tertentu. Perangkat perangkat keras yang paling umum adalah perangkat virtio. Beberapa instance lawas memerlukan akses ke perangkat keras tertentu, yang dapat ditentukan dengan menggunakan metadata sekilas:
$ glance image-update \
--property hw_disk_bus=ide \
--property hw_cdrom_bus=ide \
--property hw_vif_model=e1000 \
f16-x86_64-openstack-sda
Arsitek awan harus menentukan perangkat apa yang tersedia bagi pengguna cloud. Apa pun yang tidak dibutuhkan harus dihapus dari QEMU. Langkah ini memerlukan rekam ulang QEMU setelah memodifikasi opsi yang dilewatkan ke skrip konfigurasi QEMU. Untuk daftar opsi up-to-date yang lengkap, cukup jalankan ./configure --help dari dalam direktori sumber QEMU. Tentukan apa yang dibutuhkan untuk penerapan Anda, dan nonaktifkan opsi yang tersisa.
Pengerasan kompilator¶
Harden QEMU menggunakan opsi pengerasan kompiler. Kompiler modern menyediakan berbagai opsi waktu kompilasi untuk meningkatkan keamanan binari yang dihasilkan. Fitur-fitur ini termasuk relocation read-only (RELRO), stack canaries, never execute (NX), position independent executable (PIE), dan address space layout randomization (ASLR).
Banyak distribusi Linux modern yang sudah membangun QEMU dengan pengerasan kompilator, kami sarankan untuk memverifikasi executable yang ada sebelum melanjutkan. Salah satu alat yang dapat membantu Anda dengan verifikasi ini disebut checksec.sh
- RELocation Read-Only (RELRO)
Hardens bagian data dari executable. Baik mode RELRO penuh maupun parsial didukung oleh gcc. Untuk QEMU full RELRO adalah pilihan terbaik anda. Ini akan membuat tabel offset global hanya bisa dibaca dan menempatkan berbagai bagian data internal sebelum bagian data program dieksekusi.
- Stack canaries
Tempatkan nilai pada stack dan verifikasi keberadaan mereka untuk membantu mencegah serangan buffer overflow.
- Never eXecute (NX)
Juga dikenal sebagai Data Execution Prevention (DEP), memastikan bahwa bagian data executable tidak dapat dijalankan.
- Position Independent Executable (PIE)
Menghasilkan posisi independent executable, yang diperlukan untuk ASLR.
- Address Space Layout Randomization (ASLR)
Ini memastikan penempatan kedua kode dan data daerah akan diacak. Diaktifkan oleh kernel (semua kernel Linux modern mendukung ASLR), saat eksekusi dilakukan dengan PIE.
Pilihan kompilator berikut direkomendasikan untuk GCC saat mengkompilasi QEMU:
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"
Kami merekomendasikan untuk menguji file eksekusi QEMU Anda setelah dikompilasi untuk memastikan bahwa pengerasan kompilator bekerja dengan benar.
Sebagian besar penyebaran awan tidak akan membangun perangkat lunak, seperti QEMU, dengan tangan. Lebih baik menggunakan kemasan untuk memastikan prosesnya berulang dan untuk memastikan bahwa hasil akhirnya dapat dengan mudah digunakan di seluruh awan. Referensi di bawah ini memberikan beberapa rincian tambahan tentang penerapan opsi pengerasan kompiler ke paket yang ada.
- DEB packages:
- Paket RPM:
Secure Encrypted Virtualization (Virtualisasi Terenkripsi yang Aman)¶
Secure Encrypted Virtualization (SEV) adalah teknologi dari AMD yang memungkinkan memori untuk VM dienkripsi dengan kunci unik untuk VM. SEV tersedia dalam rilis Train sebagai pratinjau teknis dengan tamu KVM pada mesin berbasis AMD tertentu untuk tujuan mengevaluasi teknologi.
The KVM hypervisor section of the nova configuration guide berisi informasi yang diperlukan untuk mengonfigurasi mesin dan hypervisor, dan mencantumkan beberapa batasan SEV.
SEV memberikan perlindungan untuk data dalam memori yang digunakan oleh VM yang sedang berjalan. Namun, sementara fase pertama integrasi SEV dengan OpenStack memungkinkan memori terenkripsi untuk VM, yang penting itu tidak memberikan kemampuan LAUNCH_MEASURE atau LAUNCH_SECRET yang tersedia dengan firmware SEV. Ini berarti bahwa data yang digunakan oleh VM yang dilindungi SEV dapat terkena serangan dari musuh termotivasi yang memiliki kendali atas hypervisor. Misalnya, administrator jahat pada mesin hypervisor dapat memberikan image VM untuk penyewa dengan backdoor dan spyware yang mampu mencuri rahasia, atau mengganti proses server VNC untuk mengintai data yang dikirim ke atau dari konsol VM termasuk kata sandi yang membuka kunci enkripsi disk penuh solusi.
Untuk mengurangi peluang bagi administrator jahat untuk mendapatkan akses tidak sah ke data, praktik keamanan berikut ini harus menyertai penggunaan SEV:
Solusi enkripsi disk lengkap harus digunakan oleh VM.
Sandi bootloader harus digunakan pada VM.
Selain itu, praktik terbaik keamanan standar harus digunakan dengan VM termasuk yang berikut:
VM harus dijaga dengan baik, termasuk pemindaian dan patch keamanan berkala untuk memastikan postur keamanan yang kuat dan terus-menerus untuk VM.
Koneksi ke VM harus menggunakan protokol terenkripsi dan terotentikasi seperti HTTPS dan SSH.
Alat dan proses keamanan tambahan harus dipertimbangkan dan digunakan untuk VM yang sesuai dengan tingkat sensitivitas data.
Kontrol akses wajib (Mandatory Access Control)¶
Pengerasan kompilator membuatnya lebih sulit untuk menyerang proses QEMU. Namun, jika penyerang berhasil, Anda ingin membatasi dampak serangan tersebut. Kontrol akses wajib melakukan hal ini dengan membatasi hak istimewa pada proses QEMU hanya dengan apa yang dibutuhkan. Hal ini bisa dilakukan dengan menggunakan sVirt, SELinux, atau AppArmor. Saat menggunakan sVirt, SELinux dikonfigurasi untuk menjalankan setiap proses QEMU di bawah konteks keamanan yang terpisah. AppArmor dapat dikonfigurasi untuk menyediakan fungsionalitas serupa. Kami memberikan rincian lebih lanjut tentang isolasi sVirt dan instance di bagian di bawah ini sVirt: SELinux and virtualization.
Kebijakan SELinux khusus tersedia untuk banyak layanan OpenStack. Pengguna CentOS dapat meninjau kebijakan ini dengan installing the selinux-policy source package. Kebijakan yang paling mutakhir muncul di repositori 'selinux-policy`_ Fedora. The rawhide-contrib branch memiliki file yang diakhiri dengan .te, seperti cinder.te, yang dapat digunakan pada sistem yang menjalankan SELinux.
Profil AppArmor untuk layanan OpenStack saat ini tidak ada, namun proyek OpenStack-Ansible menangani hal ini dengan applying AppArmor profiles to each container yang menjalankan layanan OpenStack.
sVirt: SELinux and virtualization¶
Dengan arsitektur kernel-level yang unik dan National Security Agency (NSA) mengembangkan mekanisme keamanan, KVM menyediakan teknologi isolasi fondasi untuk multi-tenancy. Dengan asal mula perkembangan sejak tahun 2002, teknologi Secure Virtualization (sVirt) adalah aplikasi SELinux melawan virtualisasi modern. SELinux, yang dirancang untuk menerapkan kontrol pemisahan berdasarkan label, telah diperluas untuk memberikan isolasi antara proses mesin virtual, perangkat, file data dan proses sistem yang bertindak atas nama mereka.
Implementasi OpenStack's sVirt bercita-cita untuk melindungi host hypervisor dan mesin virtual terhadap dua vektor ancaman utama:
- Ancaman hypervisor
Aplikasi yang disusupi yang berjalan di dalam mesin virtual menyerang hypervisor untuk mengakses sumber daya yang mendasarinya. Misalnya, ketika mesin virtual mampu mengakses hypervisor OS, perangkat fisik, atau aplikasi lainnya. Vektor ancaman ini merupakan risiko yang cukup besar karena kompromi pada hypervisor dapat menginfeksi perangkat keras fisik serta membeberkan mesin virtual dan segmen jaringan lainnya.
- Ancaman Virtual Machine (multi-tenant)
Aplikasi yang disusupi yang berjalan di dalam VM menyerang hypervisor untuk mengakses atau mengendalikan mesin virtual lain dan sumber dayanya. Ini adalah vektor ancaman yang unik untuk virtualisasi dan merupakan risiko yang cukup besar karena banyak image file mesin virtual dapat dikompromikan karena kerentanan dalam satu aplikasi. Serangan jaringan virtual ini menjadi perhatian utama karena teknik administratif untuk melindungi jaringan sebenarnya tidak langsung diterapkan ke lingkungan virtual.
Setiap mesin virtual berbasis KVM adalah proses yang diberi label oleh SELinux, yang secara efektif menetapkan batas keamanan di sekitar setiap mesin virtual. Batas keamanan ini dipantau dan diterapkan oleh kernel Linux, membatasi akses mesin virtual ke sumber daya di luar batasnya, seperti file data mesin host atau VM lainnya.
Isolasi sVirt disediakan terlepas dari sistem operasi guest yang berjalan di dalam mesin virtual. Linux atau Windows VMs dapat digunakan. Selain itu, banyak distribusi Linux menyediakan SELinux dalam sistem operasi, memungkinkan mesin virtual melindungi sumber daya virtual internal dari ancaman.
Label dan kategori¶
Instance mesin virtual berbasis KVM diberi label dengan tipe data SELinux mereka sendiri, yang dikenal sebagai svirt_image_t. Perlindungan tingkat kernel mencegah proses sistem yang tidak sah, seperti perangkat lunak perusak, dari memanipulasi file image mesin virtual pada disk. Saat mesin virtual dimatikan, image disimpan sebagai svirt_image_t seperti di bawah ini:
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
Label svirt_image_t secara unik mengidentifikasi file image pada disk, memungkinkan kebijakan SELinux membatasi akses. Saat image komputasi berbasis KVM diaktifkan, sVirt menambahkan pengenal numerik acak ke image. SVirt mampu menugaskan pengenal numerik (numeric identifier) ke maksimum 524.288 mesin virtual per node hypervisor, namun sebagian besar penerapan OpenStack sangat tidak mungkin untuk menghadapi keterbatasan ini.
Contoh ini menunjukkan pengenal kategori sVirt:
system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2
Pengguna dan peran SELinux¶
SELinux mengelola peran pengguna. Ini dapat dilihat melalui flag -Z, atau dengan perintah :command: semanage. Pada hypervisor, hanya administrator yang harus dapat mengakses sistem, dan harus memiliki konteks yang sesuai di seputar pengguna administratif dan pengguna lain yang berada di sistem. Untuk informasi lebih lanjut, lihat `SELinux users documentation <http://selinuxproject.org/page/BasicConcepts#Users> `_.
Booleans¶
Untuk memudahkan beban administrasi pengelolaan SELinux, banyak platform perusahaan Linux memanfaatkan SELinux Boolean untuk segera mengubah postur keamanan dari sVirt.
Pengerahan KVM berbasis Linux Red Hat Enterprise memanfaatkan boolean sVirt berikut:
sVirt SELinux Boolean |
Deskripsi |
|---|---|
virt_use_common |
Izinkan virt untuk menggunakan port komunikasi serial atau paralel. |
virt_use_fusefs |
Izinkan virt untuk membaca file yang dipasang FUSE. |
virt_use_nfs |
Izinkan virt untuk mengelola file yang dipasang NFS. |
virt_use_samba |
Izinkan virt untuk mengelola file yang dipasang CIFS. |
virt_use_sanlock |
Biarkan virtual gues terbatas untuk berinteraksi dengan sanlock. |
virt_use_sysfs |
Izinkan virt untuk mengatur konfigurasi perangkat (PCI). |
virt_use_usb |
Izinkan virt untuk menggunakan perangkat USB. |
virt_use_xserver |
Biarkan mesin virtual berinteraksi dengan X Window System. |
