Securing Your Cloud with Xen Projects Advanced Security Features - PowerPoint PPT Presentation

Introduction Network path Bootloader Device model Xen Conclusion Securing Your Cloud with Xen Project’s Advanced Security Features Russell Pavlicek, Xen Project Evangelist CloudOpen North America 2013

Introduction Network path Bootloader Device model Xen Conclusion Who is the Old, Fat Geek Up Front? ◮ Xen Project Evangelist ◮ Employed by Citrix, focused entirely on the Xen Project ◮ History with Open Source begins in 1997 ◮ Former columnist with Infoworld, Processor magazines ◮ Former panelist on The Linux Show webcast, repeat guest on The Linux Link Tech Show ◮ Over 150 pieces published, plus one book on Open Source development and several blogs CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 2 / 32

Introduction Network path Bootloader Device model Xen Conclusion Introduction: Xen Project and Security ◮ Xen Project is an enterprise-grade Type I hypervisor ◮ Built for the Cloud before it was called the Cloud ◮ A number of advanced security features ◮ Driver Domains, Stub Domains, FLASK, and more ◮ Most of them are not (or cannot) be turned on by default ◮ Although they are simple to use, sometimes they can appear to be complicated CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 3 / 32

Introduction Network path Bootloader Device model Xen Conclusion Presentation Goals ◮ Introduce you to key Xen Project Security Tools ◮ Discuss some key Xen security features ◮ Get you started in the right direction toward securing your Xen installation CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 4 / 32

Introduction Network path Bootloader Device model Xen Conclusion Presentation Outline ◮ A few thoughts on the problem of securing the Cloud ◮ Overview of the Xen architecture ◮ Brief introduction to principles of security analysis ◮ Consider some attack surfaces and Xen features we can use to mitigate them: ◮ Driver Domains ◮ PVgrub ◮ Stub Domains ◮ Paravirtualization (PV) mode vs Hardware Virtualization (HVM) mode ◮ FLASK example policy CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 5 / 32

Introduction Network path Bootloader Device model Xen Conclusion The Cloud Security Conundrum ◮ Security: The 800 pound gorilla of the Cloud world ◮ Nothing generates more fear in specific, and FUD in general ◮ Probably the single greatest barrier to Cloud adoption ◮ Immediately behind it is the inability to get out of a 20th century IT mindset (i.e., ”Change is Bad”) ◮ The good news: we don’t need to fear it – we just need to solve it CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 6 / 32

Introduction Network path Bootloader Device model Xen Conclusion Cloud Security: New Visibility to Old Problem ◮ Security has always been an issue ◮ Putting a truly secure system in the open does not reduce its security, just increases the frequency of attack ◮ Unfortunately, system security behind the firewall has not always been comprehensive ◮ Having solutions in Clouds forces us to solve the security issues we should have already solved ◮ Security through obscurity is no longer sufficient CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 7 / 32

Introduction Network path Bootloader Device model Xen Conclusion Security by Design, not by Wishful Thinking ◮ Security by Wishful Thinking is Officially Dead ◮ Merely hoping that your firewall holds off the marauding hordes is NOT good enough ◮ Addressing security in one area while ignoring others is NOT good enough ◮ Saying, ”We’ve never had a problem before” is NOT good enough ◮ Comprehensive security starts with design ◮ It needs to planned and carefully thought through ◮ It needs to be implemented at multiple levels ◮ It needs components which are themselves securable CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 8 / 32

Introduction Network path Bootloader Device model Xen Conclusion Xen Project: Security by Design ◮ Xen Project was designed for Clouds before the term ”Cloud” was coined in the industry ◮ Designers foresaw the day of an ”infrastructure for wide-area distributed computing” which we now call ”the Cloud” ◮ http://www.cl.cam.ac.uk/research /srg/netos/xeno/publications.html ◮ Xen is designed to thwart attacks from many attack vectors, using different defensive techniques CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 9 / 32

Introduction Network path Bootloader Device model Xen Conclusion Xen Architecture: A Basic Picture dom 0 device model (qemu) toolstack Paravirtualized Fully (PV) Virtualized Domain (HVM) Hardware netback netfront Domain Drivers blkback blkfront Xen Hypervisor Hardware I/O Devices CPU Memory CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 10 / 32

Introduction Network path Bootloader Device model Xen Conclusion Security Overview ◮ Threat Models: ◮ Attacker can access network ◮ Attacker controls one Guest VM ◮ Security considerations to evaluate: ◮ How much code is accessible? ◮ What is the interface like? (e.g., pointers vs scalars) ◮ Defense-in-depth ◮ Then combine security tactics to secure the installation ◮ There is no single ”magic bullet” ◮ Individual tactics reduce danger; combined tactics go even farther CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 11 / 32

Introduction Network path Bootloader Device model Xen Conclusion Example System, for our Discussion ◮ Hardware setup ◮ Two networks: one Control network, one Guest network ◮ IOMMU with interrupt remapping (AMD or Intel VT-d v2) to allow for full Hardware Virtualization (HVM) ◮ Default configuration ◮ Network drivers in the Control Domain (aka ”Domain 0” or just ”Dom0”) ◮ Paravirtualized (PV) guests using PyGrub (grub-like boot utility within context of Guest Domain) ◮ Hardware Virtualized (HVM) guests using Qemu (as the device model) running in the Control Domain CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 12 / 32

Introduction Network path Bootloader Device model Xen Conclusion Attack surface: Network path dom 0 toolstack Domain netfront bridge iptables Rogue Domain NIC netback netfront Driver Xen Hypervisor Hardware Control NIC Guest NIC ◮ Where might an exploit focus? ◮ Bugs in hardware driver ◮ Bugs in bridging / filtering ◮ Bugs in netback (via the ring protocol) CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 13 / 32

Introduction Network path Bootloader Device model Xen Conclusion Attack surface: Network path dom 0 toolstack Domain netfront bridge iptables Rogue Domain NIC netback netfront Driver Xen Hypervisor Hardware Control NIC Guest NIC ◮ What could a successful exploit yield? ◮ Control of Domain 0 kernel ◮ Pretty much control of the whole system CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 14 / 32

Introduction Network path Bootloader Device model Xen Conclusion Security feature: Driver Domains dom 0 Domain toolstack netfront Driver Domain iptables bridge Rogue Domain NIC netfront NIC netback Driver Driver Xen Hypervisor Hardware Control NIC Guest NIC ◮ What is a Driver Domain? ◮ Unprivileged VM which drives hardware, provides access to guests CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 15 / 32

Introduction Network path Bootloader Device model Xen Conclusion Security feature: Driver Domains dom 0 Domain toolstack netfront Driver Domain iptables bridge Rogue Domain NIC netfront NIC netback Driver Driver Xen Hypervisor Hardware Control NIC Guest NIC ◮ Now a successful exploit could yield: ◮ Control of the Driver Domain (PV hypercall interface) ◮ Control of that guest’s network traffic ◮ Control of NIC ◮ An opportunity to attack netfront of other guests CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 16 / 32

Introduction Network path Bootloader Device model Xen Conclusion HowTo: Driver Domains ◮ Create a VM with appropriate drivers ◮ Use any distribution suitable as a Control Domain ◮ Install the Xen-related hotplug scripts ◮ Just installing the Xen tools in the VM is usually good enough ◮ Give the VM access to the physical NIC with PCI pass-through ◮ Configure the network topology in the Driver domain ◮ Just like you would for the Control Domain ◮ Configure the guest Virtual Network Interface (vif) to use the new domain ID ◮ Add backend=domnet to vif declaration vif = [ ’type=pv, bridge=xenbr0, backend=domnet’ ] ◮ http://wiki.xenproject.org/wiki/Driver Domain CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 17 / 32