Exploiting live migration
Apparently at this year's BlackHat, someone presented a paper about attacking live migration traffic. The paper describes a tool called Xensploit which uses a man-in-the-middle attack on live migration traffic to do all sorts of bad things. The core problem is that Xen live migration is not encrypted. Neither is VMotion traffic so the exploits are equally applicable.
While there's already been a lot of commentary suggesting that live migration shouldn't happen over insecure networks, that's not good enough for me. If you are sending the memory of a VM over the network unencrypted, you might as well not have any passwords on any of your machines since you are exposing all of the VM's sensitive data to anyone on the network.
For IBM Director Virtualization Manager, we go to great lengths to always ensure that Xen live migration traffic is always encrypted. As far as I know, no other Xen management tool is capable of encrypting live migration traffic. If you are using Virtualization Manager, you are protected from Xensploit style attacks.
For KVM, we were careful not to make the same mistakes that had been made for Xen. KVM supports live migration over SSH by default and provides a mechanism for third-parties to encrypt migration traffic in anyway they please.
posted by Anthony Liguori at 8:40 AM
25 Comments:
Interesting!
Wonder how Xen and VMotion failed to address the simple requirement of securely transferring the critical data! Man-in-middle attack is not something new.
I dread imagining a scenario where we're live migrating a Xen VM hosting a Finance App Server with some hundred open files! That's highly sensitive data :D
Thanks for pointing this out :)
Important to note that SSH is not by itself a defense against a man-in-the-middle attack. SSH needs to be configured to use the known_hosts file and the authorized_keys file, not to allow host-based authentication, and other options (don't want to make this an ssh HOWTO).
In hindsight it is pretty extraordinary that both VMWare and Xen do not protect the migration traffic. Your work on the robust migration tool for Director seems obvious in hindsight but it is still the only protection customers can get!
Anthony,
Very interesting, I was unaware of the enhanced capabilities of IBM's Virt Manager.
I've seen the SSH support in KVM but have yet to have a chance to play with it. A few questions:
- Is key management handled manually or through some automated management mechanism?
- Are RSA/DSA key pairs used or are x509 certs supported?
- What sort of policies are available in the face of invalid keys, either in the case of misconfiguration or an actual SSH MITM attack? Will a migration abort, notify an administrator, attempt to correct itself?
Regards,
Jon Oberheide
jon,
Key manager is not handled by KVM. It's up to the end-user to manage that.
That is not the case with Virtualization Manager though. Within Virtualization Manager, all the key management is done by the Director framework.
interesting to read this... :)
to be honest i never assumed there was even the slightest layer of security in xen's sensitive bits.
You don't need to be man-in-the-middle, either, a simple mirrorport on the switch in question will probably let you read so much sensitive information. :(
I have been thinking about how to implement a secured network for the dom0 crosstraffic, but so far i haven't really looked into how to actually tell xen to do that the way i want it.
I also wanna second the point about SSH being not the right thing for this job, first of all, because the encryption ought to be handled where the data is sent, not somewhere later on it's way to the wire, second because this is just one stream of traffic and i feel even stunnel would be more elegant.
still i'm glad to see the security piece of finally getting some real attention beyond noting "this will be an issue if it's not firewalled but we don't know anyone who actually did firewall it and as devs we don't care enough"
Is this not why things like machine identification and verification DO NOT BELONG in applications, but in the OS? We already have ipsec and VPN solutions to handle this. It's merely a question of your data center and network engineers having a grounding in security and just how much you trust your operating environment. :p
Live migration is in the risk of encryption and other possible attacks.
Those are indeed the problems that most programmers do encounter with Live Migration. I am interested on reading more probable solutions and things to consider.
I encountered the same problem which cannot join cluster due to network issue but I'm still find ways to get this things fixed as soon as possible.
Working with our expertise in Internet Marketing & SEO we can easily carry out a technique intended to move your web sites positions to the first page on Google. Thank for your post.
Cheers!
Digital Organics Web Design
It's much better not to do live migrating. Thank you very much.
usa vpn
Excellent. We can prevent hacking attacks if we apply this code.
Thanks for providing informative post. I am going to share and bookmark. Finally I am going to subscribe your rss feeds to check coming update on your blog.
Live migration shouldn't happen over insecure networks. You have to make sure the data you are sending is encrypted to make your files safe.
web design Perth
The data you send are probably not secured. It's important to use tools that can help prevent malware or intruders.
long island advertising agencies
Live migration shouldn't really happen over unsecured networks. It would pose a lot of threats for its users.
Your work is very good and i appreciate your work and hopping for some more informative posts. Thanks for sharing this..!!!
A very great article you wrote it mate. I found some blogs whose content is good. And I think you are doing a great job. Continue your work. This message was really a beautiful piece of your work.
Security is always the issue here and they should consider it. I hope they can deal with that problem.
cleveland marketing firm
I am extremely impressed thanks for sharing all information. It is a great post for the people to get the proper information.
How was your migration?
virtual office
Oh this is PERFECT! Thank you so much. I wanted to do SOMETHING, but not too much and this is FAB! Your the best!
You can't make mistakes when your migrating servers.
Which is better when you run it on VMWare? I think the best one would probably the one who can handle multiple migration at the same time.
first of all, because the encryption ought to be handled where the data is sent, not somewhere later on it's way to the wire.
Post a Comment
<< Home