Bryan Nairn discusses security considerations for virtualization. Virtual machines are increasingly common but over 40% will be less secure than physical servers by 2014. Key risks include compromised host machines which could then control VMs, and unpatched guest operating systems. Defenses include hardening host servers, protecting virtual machine files, isolating guest networks, and using access control lists to manage permissions for VMs. Securing the virtualization platform requires attention to both host and guest security.

1. Bryan Nairn, CISSP
Senior Manager, Trustworthy Computing
Microsoft Corporation
bryan.nairn@microsoft.com

2. Why should I care?
 Server virtualization is now a given in the majority of
enterprise datacenters – source IDC
 The virtual server and virtual server management
software market is forecast to reach a market opportunity
of approximately $4.1 billion by 2014. This represents a
CAGR of 13.1%. – source IDC
 Over 40% of production virtual machines will be less
secure than their physical counterparts through 2014 –
source Gartner

3. Virtualization powers the cloud
Private Cloud Public Cloud
• Mimics public cloud • Available to anyone
• Benefits enterprise with a network
users connection
• Highly virtualized • Pay-as-you-go
• Strings together IT • Multi-tenant and
infrastructure into virtualized
resources pools • Self-service portals

4. Virtualization is a good thing!

5. Some Common VM Security Myths
 “I only have to patch my host OS / Kernel”
 “If I protect my Host machine, it will protect my
VMs.”
 “Virtual Hard Disk files are secure by default.”
 “If you expose the virtual machine, you have to
expose all virtual machines and the host.”
 “All virtual machines can see each other.”
 “I don’t need Anti-Virus with Virtualization”

6. Protection Rings

7. Virtualization Architecture- Hypervisor
Primary Partition Child Partitions
Virtualization Stack
WMI Provider
Applications
VM VM Worker
Service Processes
Ring 3
MinWin Virtualization Virtualization
Service Service
Providers Clients
Windows (VSPs) (VSCs) Guest OS
Kernel IHV Kernel
Drivers VMBus VMBus Enlightenments
Ring 0
Windows hypervisor Ring “-1”
Server Hardware

8. Hypervisor Security Assumptions
 Guests are untrusted
 Trust relationships
 Parent must be trusted by hypervisor
 Parent must be trusted by children
 Hypercall interface will be well documented and widely
available to attackers
 All hypercalls can be attempted by guests
 Can detect you are running on a hypervisor + version
 The internal design of the hypervisor will be well understood

9. Hypervisor Security Goals
 Strong isolation between partitions
 Protect confidentiality and integrity of guest data
 Separation
 Unique hypervisor resource pools per guest
 Separate worker processes per guest
 Guest-to-parent communications over unique channels
 Non-interference
 Guests cannot affect the contents of other guests, parent, hypervisor
 Guest computations protected from other guests
 Guest-to-guest communications not allowed through VM interfaces

10. Hyper-V Isolation
 No sharing of virtualized devices
 Separate VMBus per VM to the parent
 No sharing of memory
 Each has its own address space
 VMs cannot communicate with each other, except through
traditional networking
 Guests can’t perform DMA attacks because they’re never
mapped to physical devices
 Guests cannot write to the hypervisor
 Parent partition cannot write to the hypervisor

11. Hyper-V Security Hardening
 Hypervisor has separate address space
 Guest addresses != Hypervisor addresses
 No 3rd party code in the Hypervisor
 Limited number of channels from guests to
hypervisor
 No “IOCTL”-like things
 Guest to guest communication through hypervisor is
prohibited
 No shared memory mapped between guests
 Guests never touch real hardware I/O

12. Hyper-V Security Model
 Uses Authorization Manager
(AzMan)
 Fine grained authorization and access
control
 Department and role based
 Segregate who can manage groups of
VMs
 Define specific functions for
individuals or roles
 Start, stop, create, add hardware,
change drive image
 VM administrators don’t have to be
Server 2008 administrators
 Guest resources are controlled by
per VM configuration files
 Shared resources are protected
 Read-only (CD ISO file)
 Copy on write (differencing disks)

13. Virtualization Attack Vectors
Host Hardware
Virtual Machine Host OS
Virtual Machine Hard Disk Files
Virtual Machine Configuration Files
Remote Management/Control interfaces
Guest Operating System
Virtual Networks

14. Common Attacks: Host
 Host Compromise for
 Deployment, Duplication and Deletion
 Control of Virtual Machines
 Direct Code / File injection to Virtualization File
Structure
 Virtual Hard Disks
 Virtual Configuration Files
 Time Sync
 Hardware
 Rootkits / Malware
 Drivers (Attack Surface / Stability)

15. It’s all about the what’s underneath…

16. Use Remote Management
 All Virtualization Solutions include some form of remote
control.
 Access to these tools should be limited.
 Limit scope of access / control
 Protect the remote control mechanisms!
 Use limited use accounts for control
 Make sure the connections are encrypted / authenticated (SSL, RDP
over SSL)
 Use logging
VM
VM VM
VM
VM VMVM VM
VM VM VMVM VM
VM VM
VM VM
V VMVM VM
VM VM VM
M

17. File Types and Locations
.vhd disk file
– In folder you specify
in settings
.vhdd disk file
– In folder you specify
in settings
.vud disk file
– In vmc-file folder
.vsv disk file
– In vmc-file folder

18. Common Attacks: Guest
 Unpatched Virtual Machines
 Older Operating Systems
 Test or Development machines (these often are not
managed in the same way as production machines)
 Un-managed or user deployed virtual machines
 Backups and archives

19. Guest Attacks
 The Virtualization File Structure
 Virtual Hard Disks
 File / Code Injection
 Can be Directly Mounted / accessed
 Virtual Configuration Files
 Base Configuration changes
 Redirection / addition of Virtual drives / Resoures
 BIOS
<hardware>
<memory>
<ram_size type="integer">256</ram_size>
</memory>
...
<pci_bus>
<ethernet_adapter>
<controller_count type="integer">2</controller_count>
</ethernet_adapter>
</pci_bus>
</hardware>

20. VHD Redirection

21. Threat Landscape: Virtualized Attackers?
 Is this is one of the next big attack vectors on the horizon?
 The VM industry is focused on securing the VMs from attack.
Very little thought of VMs being used as the attacker.
 Cases are starting to appear where people use VMs to attack,
then shutdown the VM to remove any trace of evidence.

22. Threat Landscape: Virtualized Attackers?
 But we do write all events to the SysLog
 Things that go into drive slack are recoverable using
forensics tools
 We still have network traces…
 …and audit logs
 …and firewall and router logs
 …not to mention video cameras in the server room.

23. Defending Yourself

24. Host Attacks: Potential Solutions
 Harden the Host Servers
 Where a Hypervisor or Specialist Kernel is used, the Host attack surface is
smaller, however updating and patching is still required.
 Use single role servers and remove unwanted and un-necessary services /
attack vectors
 Use a local firewall and only allow limited host control / management ports
over encrypted and authenticated channels.
 Use limited scope admin accounts with strong passwords
 Protect the Virtual Machine files
 Access Control Lists (limited to the security context for the users who manage
them and the services that control them.
 Encryption
 Disk / Volume / Folder / File
 Auditing
 file access, creation, deletion …
 Don’t forget the backup files / archives

25. Guest Attacks: Potential Solutions
 Harden the Guest Operating Systems
 Treat the guest OS as if it was a physical machine
 Isolate the machine with Virtual Networks / VLANs
 Local Only Access
 NAT
 Segmented networks
 IPSec Isolation
 Physical Isolation (Separate NICs)

26. Use Access Control Lists
Deny Read-only Read/Write
• Cannot • See the VM in • See the VM in
modify VMC web console web console
file and VRMC and VMRC
• Will not • Can interact • Can interact
appear in with VM with the VM
web console • Cannot start, • Can start,
or VMRC stop, pause stop, pause,
or resume resume VMs
VMs

27. Deployment Considerations
 Minimize risk to the Parent Partition
 Use Server Core
 Don’t run arbitrary apps, no web surfing
 Run your apps and services in guests
 Moving VMs from Virtual Server to Hyper-V
 FIRST: Uninstall the VM Additions
 Two physical network adapters at minimum
 One for management (use a VLAN too)
 One (or more) for vm networking
 Dedicated iSCSI
 Connect to back-end management network
 Only expose guests to internet traffic

28. Anti-Virus & BitLocker…
 Parent partition
 Run AV software and exclude .vhd
 Child partitions
 Run AV software within each VM
 BitLocker
 Great for branch office
 Can be used within a VM
 http://blogs.technet.com/virtualworld/archive/2008/02/16/using-
bitlocker-under-virtual-pc-virtual-server.aspx

29. Conclusions
 Reduce the attack surface on the Host
 Use least privilege access
 Audit the deployment, maintenance, control and access to
virtual machines
 Leverage backups, snapshots and redundancy to reduce
impact of Host / Guest maintenance
 Secure your Virtual Machine Hard Disk and configuration files,
including backups and archives
 Use Virtual Networks / VLANs / IPSec to Isolate machines,
especially before they are exposed to the network.

30. Resources
 Step-by-Step Guide to Getting Started with Hyper-V
 http://technet2.microsoft.com/windowsserver2008/en/library/c513e254-
adf1-400e-8fcb-c1aec8a029311033.mspx?mfr=true
 Virtualization Team Blog
 http://blogs.technet.com/virtualization
 Microsoft Virtualization Website
 http://www.microsoft.com/virtualization
 Using BitLocker under Virtual PC / Virtual Server
 http://blogs.technet.com/virtualworld/archive/2008/02/16/using-bitlocker-
under-virtual-pc-virtual-server.aspx

31. We would all rather be doing
something else..