¡ ¡ ¡¡ ¡ ¡¡ ¡ ¡¡ ¡ ¡IDSPolicy EnginePolicy Modules¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢¡ ¡ ¡¡ ¡ ¡Monitored Host¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢¢ ¢ ¢£ £ £ £¤ ¤ ¤ ¥ ¥ ¥ ¢Config FilePolicy FrameworkCommandGuest AppsGuest OSMetadataQuery ResponseGuest OSOS Interface Library<strong>Virtual</strong> <strong>Machine</strong>Hardware Statecallback orResponse<strong>Virtual</strong> <strong>Machine</strong> MonitorFigure 1. A High-Level View of our VMI-<strong>Based</strong> IDS <strong>Architecture</strong>: On the right is the virtual machine (VM) thatruns the host being monitored. On the left is the VMI-based IDS with its major components: the OS interfacelibrary that provides an OS-level view of the VM by interpreting the hardware state exported by the VMM, the policyengine consisting of a common framework <strong>for</strong> building policies, and policy modules that implement specific intrusiondetection policies. The virtual machine monitor provides a substrate that isolates the IDS from the monitored VM andallows the IDS to inspect the state of the VM. The VMM also allows the IDS to interpose on interactions between theguest OS/guest applications and the virtual hardware.INSPECTION COMMANDS are used to directly examineVM state such as memory and register contents, and I/Odevices’ flags.MONITOR COMMANDS are used to sense when certainmachine events occur and request notification through anevent delivery mechanism. For example, it is possible <strong>for</strong>a VMI to get notified when a certain range of memorychanges, a privileged register changes, or a device statechange occurs (e.g. Ethernet interface address is changed).ADMINISTRATIVE COMMANDS allow the VMI IDS tocontrol the execution of a VM. This interface allows theVMI IDS to suspend a VM’s execution, resume a suspendedVM, checkpoint the VM, and reboot the VM.These commands are primarily useful <strong>for</strong> bootstrappingthe system and <strong>for</strong> automating response to a compromise.A VMI IDS is only given administrative control over theVM that it is monitoring.The VMM can reply to commands synchronously(e.g. when the value of a register is queried) or asynchronously(e.g. to notify the VMI IDS that there has beena change to a portion of memory).4.3 The VMI IDSThe VMI IDS is responsible <strong>for</strong> implementing intrusiondetection policies by analyzing machine state and machineevents through the VMM interface. The VMI IDSis divided into two parts, the OS interface library and thepolicy engine. The OS interface library’s job is to providean OS-level view of the virtual machine’s state in orderto facilitate easy policy development and implementation.The policy engine’s job is purely to execute IDS policiesby using the OS interface library and the VMM interface.4.3.1 The OS Interface LibraryVMMs manage state strictly at the hardware level, butprefer to reason about intrusion detection in terms of OSlevelsemantics. Consider a situation where we want todetect tampering with our sshd process by periodicallyper<strong>for</strong>ming integrity checks on its code segment. A VMMcan provide us access to any page of physical memory ordisk block in a virtual machine, but discovering the contentsof sshd’s code segment requires answering queriesabout machine state in the context of the OS running inthe VM: “where in virtual memory does sshd’s code segmentreside?”, “what part of the code segment is in memory?”,and “what part is out on disk?”We need to provide some means of interpreting lowlevelmachine state from the VMM in terms of the higherlevelOS structures. We would like to write the code todo this once and provide a common interface to it, instead
of having to re implement this functionality <strong>for</strong> each newpolicy in our IDS. Our solution must also take into accountvariations in OS structure such as differences in OSversions, configurations, etc.The OS interface library solves this problem by usingknowledge about the guest OS implementation to interpretthe VM’s machine state, which is exported by the VMM.The policy engine is provided with an interface <strong>for</strong> makinghigh-level queries about the OS of the monitored host.The OS interface library must be matched with the guestOS; different guest OSes will have different OS interfacelibraries.Some examples of the type of queries that the OS interfacelibrary facilitates are: “give me a list of all the processescurrently running on the system,” or “tell me all theprocesses which are currently holding raw sockets.” TheOS interface library also facilitates queries at the level ofkernel code, similar to the queries that one might give togdb like “show me the contents of virtual memory fromx to y in the context of the login process,” or “display thecontents of task structure <strong>for</strong> the process with PID 231.”4.3.2 The Policy EngineAt the heart of any intrusion detection system is the policyengine. This component interprets system state and eventsfrom the VMM interface and OS interface library, and decideswhether or not the system has been compromised.If the system has been compromised, the policy engine isresponsible <strong>for</strong> responding in an appropriate manner. Forexample, in case of a break-in, the policy engine can suspendor reboot the virtual machine, and report the breakin.Since the focus of our work has been studying VMIas a plat<strong>for</strong>m <strong>for</strong> IDS, we have focused on implementingvariations on mainstream HIDS style policies [37] such asburglar alarms, misuse detectors and integrity checkers. Apolicy engine implementing complex anomaly detectionand other, more exotic techniques can also be supportedin this architecture.5 ImplementationTo better understand the implementation difficulties,per<strong>for</strong>mance overhead, usability, and practical effectivenessof our VMI architecture, we built Livewire, a prototypeVMI IDS. For our VMM we used a modified versionof VMware Workstation [49] <strong>for</strong> Linux x86. OurOS library was built by modifying Mission Critical’scrash [30] program. Our policy engine consists of aframework and modules written in the Python programminglanguage [17]. Each of these components runs in itsown process in Linux, our host OS.5.1 VMMWe used a modified version of VMware Workstation <strong>for</strong>Linux to provide us with a virtual machine monitor capableof running common x86-based operating systems. Inorder to support VMI, we added hooks to VMware to allowinspection of memory, registers, and device state. Wealso added hooks to allow interposition on certain events,such as interrupts and updates to device and memory state.The virtual machine monitor supports virtual I/O devicesthat are capable of doing direct memory access(DMA). These virtual devices can use DMA to read anymemory location in the virtual machine. We used this virtualDMA capability to support direct physical memoryaccess in the VMM interface. We accomplished this withminimal changes to the VMM.As part of this virtualization process, the VMM shadowsthe page tables of the physical machine, allowing themonitor to en<strong>for</strong>ce more restrictive protection of certainmemory pages. An example of how this functionality canbe applied is the copy-on-write page sharing of the Discovirtual machine monitor [5]. We used this mechanism towrite protect pages and provide notification if the VM attemptedto modify a protected page.Interactions with virtual I/O devices such as Ethernetinterfaces are intercepted by the VMM and mapped actualhardware devices in the course of normal VMM operation.We easily added hooks to notify us when the VMattempted to change this state. Hooks to inspect the stateof virtual devices such as the virtual Ethernet card werealso added.Adding anything to a VMM is worrisome as it meanschanging low-level code that is critical to both the correctnessand per<strong>for</strong>mance of the system. However, we foundwe could support the required interposition and inspectionhooks with only minor changes to VMware by leveragingfunctionality required to support basic virtualization.The functionality that we leveraged is common to mostVMMs, thus, we believe that adding interposition supportto other VMMs should be straight<strong>for</strong>ward.5.2 VMM InterfaceThe VMM interface provides a channel <strong>for</strong> the VMIIDS processes to communicate with the VMware VMMprocess. This interface is composed of two parts: first,a Unix domain socket that allows the VMI IDS to sendcommands to, and receive responses and event notificationsfrom, the VMM; and second, a memory-mapped filethat supports efficient access to the physical memory ofthe monitored VM.In Livewire, when an event occurs, the VM’s executionis suspended until the VMI IDS responds with an administrativecommand to continue. We opted <strong>for</strong> this model