User Mode Linux (UML)has ideal security features for controlling and jailing hackers once they've taken the sweetened bait of a 'honeypot,' says User Mode Linuxauthor and project architect Jeff Dike. UML can log all terminal traffic to the host in a way that's invisible and impossible to interfere with from inside the UML unlike Xen and VMware.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Take a tour of UML with Dike as he offers best practices, explains how to boot from an empty jail, talks about jailing attackers and more.
What are some common issues encountered in server consolidation with User Mode Linux?
Jeff Dike: From my point of view, server consolidation doesn't differ greatly from any other virtualization workload. So, the advantages of UML apply here the same as in other areas.
One aspect of server consolidation that may distinguish it from other virtualization workloads is that the host administrator may not trust the UML administrators. In this case, the UML administrators won't have shell access on the host, and the host administrator will need to decide how they will be allowed to access their UMLs.
The easy solution is to allow only network access. But this will increase the support burden when UML owners make their UMLs inaccessible by misconfiguring their networks. In this case, allowing the equivalent of logging in on a hardwired terminal would be nice, so that the UML admins still have access to their UMLs and can fix the network themselves.
So how should host administrators determine access criteria for UML?
Dike: In my UML book, I describe a neat way of doing this that involves using a separate UML as a terminal concentrator. UML owners have normal, non-privileged accounts on this UML to which they can log in over the network. This UML is connected to all of the others through virtual serial lines, so that there is the equivalent of a physical terminal running from each of the other UMLs to the concentrator UML. These are accessible through terminal devices, which are protected so that a UML terminal is only usable by its owner.
This is fairly simple to set up, and it uses standard Linux mechanisms in a somewhat unusual way to do something that is fairly useful. This is one of the advantages that UML gains from being well integrated with Linux and its environment and tools.
What are some major areas of concern and some best practices for how to address them?
Dike: This is a big question that occupies two chapters in [User Mode Linux]. The two main areas of concern are resource consumption and security. To get the most from a UML host requires careful management of its resources. Memory is particularly important. Maximizing UML performance requires the user to make sure that the sum of the UML physical memory sizes is no more than the host memory size. Also, the memory hotplug used to ensure that UMLs that need memory must have it, removing it from other, idle UMLs if necessary. This second step requires a daemon on the host monitoring memory requirements and availability on the host and the UMLs, and moving memory around as needed.
Disk space and memory consumption are also affected by how the UMLs share file systems. Using COW files will ease the load on both the host disks and memory.
What are some issues with security in User Mode Linux?
Dike: With respect to security, the first thing to consider is whether the UMLs will host potentially hostile users. This is the case with a UML ISP, which doesn't know much about its customers. It's also possibly the case with an UML that's exposed to the Internet, in which case the hostile user would be someone who has broken into it. For UMLs on an intranet whose owners have accounts on the host, this likely wouldn't be an issue.
Where you might have hostile UML users, you should seriously consider jailing the UML. I know of no exploits that would allow a UML user to escape to the host, but I obviously can't guarantee that they don't exist. Putting the UML in a chroot jail adds another layer of protection to the security already provided by UML.
In the book, I describe a technique for booting a UML inside an empty jail. If someone were to find a way to break out of a UML, the next task would be to break out of the host jail. Someone who knows how to break out of both UML and chroot will presumably need something to start with, like some files or utilities. An empty jail doesn't offer any help with this, so even with the two exploits in hand, the attacker would likely be stopped by the emptiness of the jail.
What security features make UML safe from being a 'honeypot'?
Dike: All of the full virtual machine technologies (UML, VMware, Xen, etc.) provide sufficient security for use as a honeypot. Where they differ is in management and monitoring. You want to maintain sufficient control over the honeypot that, once broken into, it can't be used as a platform for attacking other systems. You also want to be able to tell, after the fact, how it was broken into and exactly what the attacker did once it was compromised.
Both of these require solid monitoring, preventing the honeypot from being used as a base for further attacks require that it be easy to shut down or taken off the network quickly. As a normal Linux process, a UML honeypot can be managed and controlled using the tools that you're already familiar with.
For example, if you need to shut it down in a hurry, that's a matter of a single kill command. Network monitoring, filtering and control are done using the normal Linux netfilter system on the host.
In addition, UML has a couple of features specifically for honeypots. It has the ability to log all terminal traffic to the host in a way that's invisible and impossible to interfere with from inside the UML. This is a consequence of UML's broad interactions with the host, as a virtual operating system rather than a virtual machine.
Making the logging invisible is a tough problem for most technologies. Normally, the logging would involve the network, making it detectable in a few ways, including by looking at the network packet counters and observing that they are increasing too quickly. The intruder could also directly observe the logging by sniffing the network. Mechanisms to avoid this, such as adjusting the counters and filtering network traffic, are complicated and error-prone.
In contrast, UML's tty logging is simple and undetectable -- it writes data to a file on the host, and there is no way to detect that from inside the UML. Currently, tty logging is in the 2.4 UML patch, but it isn't in 2.6 mainline. I have it in my development tree and will look at merging it to 2.6.18.
Another honeypot feature is the hppfs file system, which allows the contents of the UML /proc to be selectively overridden from the host. This allows you to disguise the UML as a physical machine with whatever characteristics you like. For instance, it could be made to look like the host by overriding files such as /proc/cpuinfo and /proc/meminfo with the host's versions.
These two features were sponsored by Dartmouth College's Institute for Security Technology Studies when I worked there before joining Intel.