« Previous 1 2 3 4 Next »
Secure Your KVM Virtual Machines
Jailbreak: Guard Against Breakouts on Your Virtual Machines
Very Important PC
Administrators should at least restrict access to a trusted computer. The following command tells the VNC server to accept connections from the IP address 192.168.100.30 only:
qemu-kvm -vnc 192.168.100.30:1 ...
Ideally, you also want to filter the VNC connections through the firewall. If you work with the libvirt
tools, check the settings in the /etc/libvirt/qemu.conf
configuration file. You can also specify a password there and at the command line. Unfortunately, this password is stored in the clear in the configuration file and can even pop up in the logfiles under certain circumstances. You should therefore always encrypt VNC connections with SSL/TSL or tunnel them with SSH. If the virtual machine is running as a headless server, the video output also can be completely disabled for safety reasons (e.g., via the -nographic
parameter).
Incidentally, the warnings relating to VNC also apply to graphics output via SPICE. Again, the built-in KVM SPICE server listens on the first available port above 5900. Unlike VNC, however, SPICE supports encryption in the connection [5].
Data Tombs
By default, disk images are not encrypted. If they reside on a freely accessible hard drive or (NFS) share, an attacker could create a copy and then analyze the installed system at leisure – this is particularly true for the RAW format. Administrators should thus ensure that no one gains access to the images. It also makes sense to encrypt the images. To do this, you can store the images on an filesystem encrypted by the host system and let the guest system encrypt its own (virtual) disk.
Furthermore, KVM or Qemu also encrypt an entire image with the AES algorithm. Encryption itself is completely transparent for the guest. However, the image must be in the qcow2 format, and Qemu currently only uses a 128-bit key. An encrypted image is created, for example, using qemu-img
(Figure 7).
Caught in the Net
Once a virtual machine accesses the intranet or Internet, it can fall victim to DoS attacks, port scans, and intrusion attempts, just like any physical machine. Therefore, the same security measures should be taken: The web applications or services running on the virtual machine should be always up to date.
Even if a break-in succeeds, the malware must not spread via the network to the host computer, to other physical computers on the LAN, or to other virtual machines. The latter, in particular, is easy to achieve if all virtual machines are connected to the same (virtual) network (Figure 8). Firewalls must thus check the flow of data to, and especially between, the virtual machines. This practice is supported by the libvirt
tools – in particular the nwfilter
network filter driver [6].
In the normal NAT operating mode (user mode, default network), only the guest system on the virtual machine accesses the network; remote attackers only see the host computer, which they can attempt to compromise. Conversely, however, the guest by default reaches its host on 10.0.2.2, which is also the address on which the built-in DHCP server runs. Although this setup is useful for exchanging data, malicious programs on the virtual machine can easily attack the host. The firewall on the host usually does not intervene here because the queries are running on the host system itself. It is therefore important that no vulnerable services are running on the host system. Ideally, the host only runs the virtual machines, and nothing else.
Qemu also lets you connect virtual machines via TCP and UDP sockets. However, these connections are not encrypted, and anyone who has access to the sockets can send data to the connected virtual machines. If you do use sockets, you should therefore at least choose a setup where the connections use the access restrictions offered by Qemu and only allow connections from specific IP addresses (parameters -net socket,connect=hostname,port
).
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)