1. Shohei Miyama Kenichi Kourai Kyushu Institute of Technology, Japan
Secure IDS Offloading with Nested Virtualization and Deep VM Introspection
I'm Kenichi Kourai from Kyushu Institute of Technology.
I'm gonna talk about secure IDS offloading with nested virtualization and deep VM introspection.
This is joint work with my student, who has graduated.
Shohei Miyama
Kenichi Kourai
Kyushu Institute of Technology, Japan

2. Intrusion Detection in Clouds
IaaS clouds
Users can run their services in virtual machines (VMs)
They need intrusion detection systems (IDSes) to protect their systems
IDSes suffer from external attacks
Intruders can disable IDSes easily
intruder
In Infrastructure-as-a-Service clouds, users can run their services in virtual machines.
They can set up their systems in provided VMs and use the VMs as necessary.
To protect the systems inside VMs from external attackers, they need intrusion detection systems.
IDSes are used to monitor the system states, filesystems, and network packets.
But IDSes also suffer from external attacks.
After attackers intrude into a VM and take sufficient privileges, they can disable IDSes easily. VM VM
IDS
IDS

3. IDS Offloading Run IDSes outside target VMs securely
E.g., in the management VM
Using VM introspection (VMI) [Garfinkel+'03]
Directly obtain information inside VMs
E.g., memory, storage, and networks
Intruders cannot disable offloaded IDSes
To prevent IDSes from being compromised by intruders, IDS offloading has been proposed.
IDS offloading enables securely running IDSes outside target VMs, for example, in a privileged VM called the management VM.
Offloaded IDSes can directly obtain information inside VMs using a technique called VM introspection.
For example, they can read kernel data in VM's memory, check the integrity of the storage, and capture all the packets from and to VMs.
Even if attackers intrude into a VM, they cannot disable offloaded IDSes.
Offloaded IDSes running in the management VM are strongly protected by clouds.
management VM
user VM
offloaded
IDS
IDS
VMI

4. Semi-trusted Clouds Some of the system admins may be untrusted
28% of cyber crimes are caused by insiders [PwC'14]
An engineer in Google violated user's privacy [TechSpot News'10]
35% of admins access sensitive information [CyberArk'09]
Offloaded IDSes can be disabled by insiders
In clouds, system administrators manage the management VM.
But, in semi-trusted clouds, some of them may be untrusted.
It is reported that 28% of cyber crimes are caused by insiders.
For example, a site reliability engineer in Google violated user's privacy in 2010.
In addition, it is revealed that 35% of system administrators access sensitive information without authorization.
As a result, offloaded IDSes can be disabled by such insiders.
management VM
user VM
offloaded
IDS
insider

5. Previous Approaches Assume trusted hypervisors
Run IDSes in the hypervisor [Oyama+'12]
Run IDSes in secure VMs provided by the hypervisor [Butt+'12]
Run IDSes in remote hosts and monitor user VMs via the hypervisor [Kourai+'16]
secure VM
user VM
Previous approaches to securing IDS offloading assume trusted hypervisors.
The hypervisor is privileged software running below the management VM and user VMs.
For example, some systems run IDSes in the trusted hypervisor and protects them from untrusted administrators in the management VM.
Anther system runs IDSes in secure VMs provided by the trusted hypervisor.
The secure VMs are managed by users themselves and untrusted administrators cannot interfere with them.
Our previous work runs IDSes in trusted remote hosts and monitors user VMs via the trusted hypervisor.
IDS
IDS
trusted hypervisor
IDS
remote host

6. Issue 1: Vulnerable Interfaces
The hypervisor can be easily compromised by untrusted admins
Tightly coupled with the untrusted management VM
Provide rich interfaces to the management VM
Broad attack surface
untrusted
management VM
user VM
But there are several issues in trusting the hypervisor.
One is vulnerable interfaces between the management VM and the hypervisor.
The hypervisor is tightly coupled with the management VM because it delegate many management tasks to the management VM.
To enable this, it provides rich interfaces to the management VM.
Such interfaces can be abused using vulnerabilities in specification and implementation and become a broad attack surface.
So, the hypervisor can be compromised by untrusted administrators relatively easily.
trusted hypervisor

7. Issue 2: Poor Management
It is not allowed that untrusted admins manage the hypervisor
They can manage only part of the virtualized system
Cannot use the traditional package management system
Need to change the current management method
untrusted
management VM
user VM
Another issue is poor management of the virtualized system.
The virtualized system consists of the hypervisor, the management VM, and user VMs.
Traditionally, system administrators manage the entire virtualized system.
But it is not allowed that untrusted administrators manage the trusted hypervisor.
If this were allowed, the hypervisor would become untrusted.
So, system administrators can manage only part of the virtualized system.
As a result, they cannot use the traditional package management system to update the virtualized system including the hypervisor.
To enable the hypervisor and the management VM to be updated separately, they need to largely change the current management method.
virtualized
system
trusted hypervisor

8. V-Met Enable secure IDS offloading outside the virtualized system
Use nested virtualization [Ben-Yuhuda+'10]
Virtualize the virtualized system
Use deep VMI
Securely monitor user VMs in an untrusted virtualized system
To resolve these issues, we propose a system called V-Met for enabling secure IDS offloading outside the virtualized system.
V-Met uses a technique called nested virtualization to achieve this.
Nested virtualization further virtualizes the entire virtualized system and enables IDSes to run outside it.
No special hardware is needed.
In addition, V-Met uses a new technique called deep VMI to securely monitor user VMs running in an untrusted virtualized system.
Deep VMI doesn't rely on the virtualized system to obtain information on the memory, storage, and networks of user VMs.
management VM
user VM
deep
VMI
offloaded
IDS
untrusted
virtualized
system
hypervisor

9. Nested Virtualization
Run a virtualized system in a VM
IDSes are offloaded outside the cloud VM
They run on the cloud hypervisor
The overhead is acceptable
6-8% for common workloads [Ben-Yuhuda+'10]
Recent hardware support
Nested virtualization enables running a virtualized system in a VM.
We call this VM the cloud VM.
IDSes are offloaded outside the cloud VM.
Offloaded IDSes and the cloud VM run on top of the hypervisor called the cloud hypervisor.
In terms of performance, using nested virtualization is acceptable.
It is reported that the overhead in a user VM is 6 to 8% for common workloads.
Recently, hardware support for nested virtualization has been added.
For example, Intel VMCS Shadowing can reduce interaction between the guest hypervisor in the cloud VM and the cloud hypervisor.
management VM
user VM
cloud VM
offloaded
IDS
guest hypervisor
cloud hypervisor

10. Assumptions Untrusted Trusted
The virtualized system and its system admins
Trusted
Cloud providers
Components outside the virtualized system
The cloud hypervisor, offloaded IDSes, and hardware
We assume that the entire virtualized system is untrusted because some of the system administrators may be untrusted.
The hypervisor and the management VM in the virtualized system can be abused by untrusted administrators.
On the other hand, we assume that cloud providers are trusted.
This assumption is widely accepted because a bad reputation is critical for them.
We also assume that the components outside the cloud VM are managed correctly.
These components include the cloud hypervisor, offloaded IDSes, and hardware.
cloud VM
untrusted
virtualized
system
offloaded
IDS
cloud hypervisor

11. Issues Resolved Insider attacks become difficult
The TCB is strictly separated from untrusted parts
Narrower interfaces between the cloud VM and hypervisor
Untrusted admins can manage the hypervisor
The responsibility of admins is clearly separated at the boundary of virtualization
V-Met can resolve the issues on IDS offloading in semi-trusted clouds.
First, insider attacks against offloaded IDSes become difficult by running the virtualized system in the cloud VM.
This is because the trusted computing base is more strictly separated from untrusted parts.
The interfaces between the cloud VM and the cloud hypervisor are hardware level.
So, they are narrower than the rich interfaces between the management VM and the hypervisor in the virtualized system.
Second, untrusted administrators can manage the entire virtualized system including the hypervisor.
They can use the traditional management method.
This advantage comes from the fact that the responsibility of administrators is more clearly separated at the boundary of virtualization.
cloud VM
untrusted
virtualized
system
offloaded
IDS
boundary
cloud hypervisor

12. Deep VMI
Enable offloaded IDSes to directly monitor user VMs inside the cloud VM
Independent of the virtualized system
Prevent untrusted admins from interfering with monitoring
deep
VMI
Deep VMI is key to offloading IDSes outside the virtualized system.
It enables offloaded IDSes to directly monitor user VMs inside the cloud VM.
This technique is independent of the virtualized system.
A naive approach is to obtain necessary information from the hypervisor and the management VM in the cloud VM.
For example, memory information can be obtained from the hypervisor and data in virtual disks and virtual NICs can be obtained from the management VM.
But we cannot trust information obtained from an untrusted virtualized system.
Deep VMI prevents untrusted administrators from interfering with monitoring.
It supports introspection of memory, networks, and storage.
cloud VM
management VM
user VM
offloaded
IDS
guest hypervisor
cloud hypervisor

13. Deep Memory Introspection (1/2)
Monitor data of a user VM in the memory of the cloud VM
Need address translation 3 times with page tables (PT)
virtual
memory
guest physical
memory
host physical
memory
machine
memory
For deep memory introspection, V-Met monitors data of a user VM in the memory of the cloud VM.
Memory introspection is used to obtain information on processes, network sockets, and so on.
To identify data of a target user VM inside the cloud VM, V-Met needs to perform address translation three times using three page tables.
First, V-Met translates a virtual address into a guest physical address used in a user VM using the traditional page tables.
Then, it translates the obtained physical address into a host physical address used in the cloud VM using the extended page tables.
This is an extra step specific to deep memory introspection.
Finally, it translates the obtained physical address into a machine address used by the cloud hypervisor using other extended page tables. PT
EPT
EPTc
user VM
cloud VM

14. Deep Memory Introspection (2/2)
Identify the page tables (PT) and extended page tables (EPT)
Trap to the cloud hypervisor when PT is switched
Obtain the address of EPT from virtual CPUs
VM exit
cloud VM
user VM PT
To securely perform such address translation, V-Met identifies the page tables in a user VM and the extended page tables in the guest hypervisor without help of the virtualized system.
V-Met configures the cloud VM so that a user VM causes a trap to the cloud hypervisor when the page tables are switched in the user VM.
The cloud hypervisor can obtain the address of the new page tables by analyzing the CPU instruction used for the switch.
At the same time, it obtains the address of EPT from virtual CPUs of the cloud VM.
Offloaded IDSes obtains necessary information from the cloud hypervisor using a hypercall, which is similar to a system call issued to the operating system.
offloaded
IDS
guest hypervisor
EPT
hypercall
cloud hypervisor
EPTc

15. Deep Network Introspection (1/2)
VM-level packet capture is done at the boundary of a user VM
Can capture exact packets sent/received by a user VM
Pass packets directly to the cloud hypervisor
Issuing ultracalls in a user VM
For deep network introspection, V-Met captures packets at both boundaries of a user VM and the virtualized system.
Packet capture at the boundary of a user VM is called VM-level packet capture.
Using this capture method, V-Met can capture exact packets sent and received by a user VM.
It can also capture packets between user VMs in the same virtualized system.
When a user VM sends or receives a packet, its network driver passes the packet directly to the cloud hypervisor.
To prevent the virtualized system from interfering with this packet capture, we have developed a mechanism called an ultracall for directly communicating between a user VM and the cloud hypervisor.
Offloaded IDSes can obtain packets stored in the cloud hypervisor using a hypercall.
cloud VM
user VM
ultracall
packet
offloaded
IDS
guest hypervisor
hypercall
cloud hypervisor

16. Deep Network Introspection (2/2)
System-level packet capture is done at the boundary of the virtualized system
Can inspect exact communication with the outside
Obtain packets from the virtual network switch outside the virtualized system
Packet capture at the boundary of the virtualized system is called system-level packet capture.
Using this capture method, V-Met can inspect exact communication of a user VM with the outside world.
V-Met can also compare communication logs of VM-level and system-level packet capture.
All the packets sent and received by user VMs are processed by the virtual network switch outside the cloud VM.
So, offloaded IDSes can obtain packets from the switch.
Since they obtain packets of all the user VMs in the cloud VM, V-Met provides a mechanism for classifying the packets.
cloud VM
user VM
packet
network
switch
offloaded
IDS
guest hypervisor
cloud hypervisor

17. Deep Storage Introspection
For local virtual disks
Mount a snapshot of the virtual disk of the cloud VM
Prevent disk corruption on filesystem repair
Mount the virtual disk of a user VM in the snapshot
For remote virtual disks
Mount the virtual disk of a user VM using NFS
For deep storage introspection, V-Met supports local and remote virtual disks.
When a local virtual disk is used for a user VM, it is located in the virtual disk of the cloud VM.
That virtual disk of the cloud VM is located outside the cloud VM.
V-Met first creates a snapshot of the virtual disk of the cloud VM and mounts the snapshot.
Then, it mounts the virtual disk of a user VM in the snapshot.
The reason for using a snapshot is to prevent disk corruption when its filesystem is repaired on the disk mount operation.
For remote virtual disks, V-Met can directly mount the virtual disk of a user VM using NFS.
cloud VM
user VM
offloaded
IDS
guest hypervisor
virtual disks
cloud hypervisor

18. Transcall with Deep VMI
Legacy IDSes can be transparently offloaded in cooperation with Transcall [Iida+]
Transcall provides an execution environment for legacy IDSes
System call emulator, shadow filesystem, and shadow network devices
Using Deep VMI, legacy IDSes can be transparently offloaded in cooperation with Transcall, which we have developed.
Transcall provides an execution environment for legacy IDSes to introspect a user VM without any modification.
It consists of the system call emulator, the shadow filesystem, and shadow network devices.
The system call emulator traps system calls issued by offloaded IDSes and returns information of a user VM if necessary, using deep memory introspection.
The shadow filesystem provides the same filesystem view as that inside a user VM, using deep storage introspection.
A shadow network device provides a network interface for capturing packets of a user VM, using deep network introspection.
user VM
legacy
IDS
cloud VM
deep
VMI
guest hypervisor
Transcall
cloud hypervisor

19. VM Tags V-Met identifies a user VM with a VM tag
Each user VM registers a unique VM tag
Directly to the cloud hypervisor using an ultracall
Offloaded IDSes specify the VM tag when they issue hypercalls to the cloud hypervisor
V-Met identifies a target user VM inside the cloud VM using a VM tag.
Traditionally, offloaded IDSes specify the ID of a target user VM to monitor it.
But V-Met cannot securely specify such an ID because the ID is managed inside an untrusted virtualized system.
In V-Met, each user VM registers a unique VM tag in advance directly to the cloud hypervisor using an ultracall.
Offloaded IDSes specify the registered VM tag when they issue hypercalls to the cloud hypervisor to obtain information on the user VM.
cloud VM
user VM
ultracall
VM tag
offloaded
IDS
guest hypervisor
VM tag
cloud hypervisor

20. Experiments
We examined the performance of deep VMI and offloaded IDSes
Comparison: Xen-Single
Single-level virtualization
IDSes were offloaded to the management VM PC
cloud VM
user VM
We conducted several experiments to examine the performance of deep VMI and offloaded IDSes.
We used Xen modified for V-Met as the cloud hypervisor.
We ran unmodified Xen in the cloud VM and ran Linux in the user VM.
For comparison, we used the traditional, single-level virtualized system without nested virtualization.
IDSes were offloaded to the management VM.
This is called Xen-Single.
CPU: Intel Xeon E3-1270v3
Memory: 16 GB
HDD: 2 TB
NIC: Gigabit Ethernet
Xen 4.4 (modified for V-Met)
vCPU: x2
Memory: 3 GB
vDisk: 40 GB
vNIC: Gigabit Ethernet
Xen 4.4 (unmodified)
vCPU: x1
Memory: 1 GB
vDisk: 8 GB
vNIC: Gigabit Ethernet
Linux 3.13

21. Memory Introspection We read the memory of the user VM
The throughput was 41% higher in V-Met
Thanks to a faster hypercall for monitoring page tables
First, we examined the performance of memory introspection by reading data in the memory of the user VM.
The benchmark repeated address translation, memory mapping, and data copy.
The left figure shows the throughput in V-Met and Xen-Single.
Surprisingly, the throughput was 41% higher in V-Met although V-Met needed extra address translation.
To clarify the reason, we measured the execution time of the hypercalls used for address translation.
As shown in the right figure, the hypercall for obtaining the address of the page tables was much faster in V-Met.
This is because V-Met provides a tailored hypercall but Xen-Single used a general-purpose hypercall.

22. Storage/Network Introspection
We executed IOzone and tcpdump
Access to the local disk was 20% higher in V-Met
Thanks to more effective read-ahead of two virtual disks
The packet capture rate was 8-10% lower in V-Met
Next, we examined the performance of storage introspection using the IOzone benchmark.
We measured the throughput of sequential file read.
The left figure shows the results for both local and remote virtual disks.
In V-Met, access to the local virtual disk was 20% higher.
This is because read-ahead for the two virtual disks of the cloud VM and the user VM was more effective than that for only one virtual disk used in Xen-Single.
Also, we examined the performance of network introspection using tcpdump with the iperf benchmark.
As shown in the right figure, the packet capture rate was 10% lower in VM-level packet capture and 8% lower in system-level packet capture.

23. Offloaded chkrootkit/Tripwire
We ran chkrootkit and Tripwire with Transcall
The execution time was almost the same
Regardless of faster deep memory/storage introspection
Thanks to optimization in Transcall
We examined the performance of legacy IDSes offloaded with Transcall.
First, we ran offloaded chkrootkit and Tripwire.
chkrootkit is an IDS for detecting installed rootkits by inspecting processes, files, and sockets.
Tripwire is an IDS for checking the integrity of filesystems.
These figures show the execution time of chkrootkit and Tripwire.
The execution time was almost the same bewteen V-Met and Xen-Single although deep memory and storage introspection was more efficient than traditional VMI.
One reason is that Transcall is optimized so that the overhead of VMI is minimized, for example, by caching the results of address translation.

24. Offloaded Snort We measured the detection time of a port scan
The time increased only by 6-7 ms in V-Met
We examined the CPU utilization under iperf
Increased largely in VM-level capture due to hypercalls
Next, we mounted a TCP port scan against the user VM and measured the detection time using offloaded Snort.
The left figure shows the result.
In V-Met, the detection time increased only by 6 to 7 ms, compared with Xen-Single.
Finally, we examined the increase in CPU utilization when we sent many UDP packets using iperf.
The result is shown in the right figure.
In VM-level packet capture, the CPU utilization largely increased.
This is not because of ultracalls issued by the user VM for VM-level packet capture, but because of the overhead of obtaining packets from the cloud hypervisor using hypercalls.

25. Related Work IDS offloading with trusted hypervisors
Self-service cloud [Butt+'12] trusts a VM called DomB
RemoteTrans [Kourai+'16] trusts remote hosts
IDS offloading with special hardware
Copilot [Petroni+'04], HyperGuard [Rutkowska+'08]
More secure, but slow and restricted
Difficult to run legacy IDSes
CloudVisor [Zhang+'11]
Run user VMs securely in an untrusted virtualized system using nested virtualization
As explained before, there are several systems for secure IDS offloading with trusted hypervisors.
Many systems have to trust not only the hypervisor but also other components.
For example, self-service cloud trusts a VM called DomB as well.
RemoteTrans also trusts remote hosts running offloaded IDSes.
Several systems have been proposed for running IDSes outside the virtualized system using special hardware.
For example, Copilot uses a PCI add-in card and HyperGuard uses the system management mode of processors.
These approaches may be more secure, but slow and restricted.
So, it is difficult to run feature-rich legacy IDSes.
CloudVisor runs user VMs securely in an untrusted virtualized system using nested virtualization.
It can be used together with V-Met.

26. Conclusion
We proposed V-Met for secure IDS offloading outside the virtualized system
Using nested virtualization
Strict and clear separation of untrusted parts
Using deep VMI
The overhead was comparable to IDS offloading inside the virtualized system
Future work
Monitor the hypervisor and the management VM
Run other virtualized systems, e.g., KVM
In conclusion, we proposed V-Met for secure IDS offloading outside the virtualized system.
V-Met uses nested virtualization to run an untrusted virtualized system in a VM and offload IDSes outside the VM.
Nested virtualization achieves strict and clear separation between the TCB and untrusted parts.
In V-Met, user VMs are introspected using deep VMI.
The overhead was comparable to traditional IDS offloading inside the virtualized system.
Our future work is to monitor not only user VMs but also the hypervisor and the management VM in the cloud VM.
Currently, V-Met supports Xen as a virtualized system, but we are planning to run other virtualized systems such as KVM.