Secure and fast communication between 2 VM's

Question

I'm posed with a situation where i am uncertain which way to go. We have 2 Virtual Machines set up at a host that'll act as a webserver and a database server. Obviously, both will have to communicate with eachother. Now currently the way that it's set up is that they both communicate over their ext. ip's. (so we query the ip of the database server from our webserver). However we feel like this isn't very secure.

So far what i came up with is to set up a OpenVPN server on the Database server and a OpenVPN client on the webserver. Set OpenVPN up to use private IP adresses and reroute all traffic through the VPN tunnel. I think it's fairly secure but quite honestly i don't really know. Also i don't really know how this would turn out in performance. We don't want to sacrifice too much performance on this.

Anyone have any ideas if this is a good set up ? Or anyone have any other ideas how to achieve a better result ?

Thank you.

Answer 1

If two machines (virtual or not) must be made to communicate with each other, then establishing a VPN between them cannot harm; by definition, the VPN aims at emulating an isolated set of wires between your two hosts (hence presumably free from hostile eavesdropping and interference) so that arbitrary traffic between the two machine becomes "secure". OpenVPN has good reputation and is free, so using it is not a bad idea. Alternatively, if the applications which must talk to each other can handle their own security (say, SSL), then that is also applicable; the VPN, though, is probably simpler to set up, and more comprehensive.

As others have said, if your machines are VM, then the cloud provider is God: if he wishes so, he can technically see all your secrets and alter them at will. The provider is thus trusted. So the provider cannot be an attacker, and must be assumed not to fall under hostile control. Under these conditions, if the provider can set up a "private link" between your two machines (a VLAN, indeed), then that's fine. The security of the VLAN is strong as long as the actual wires and routers of the provider's network are clean and honest, which is, as I just wrote, a core assumption of the Cloud model.

Now, of course, there can be a subtle difference between "the service provider is honest" and "the service provider is honest and competent". A small configuration mistake (the dreaded human error) can put third party systems onto your VLAN. There again, running your own VPN can add protection against the provider's vagaries (it would not stand against provider's malice, but incompetence is much more common than wickedness).

Edit: I forgot the classic argument about performance. It goes thus:

1. Performance issues do not exist.
2. Performance issues do not exist until duly measured.

So if you fear performance issues, then the only sane way is to try, and see if the fears were justified or not. One can make a priori estimates but this requires some intimate knowledge of both the behaviour of involved algorithms and of network protocols and latencies; you cannot realistically hope to get decently accurate estimates unless you are highly competent in cryptography, low-level programming and TCP/IP internals. Trying out and quantifying issues is a much better way; more often than not, alleged performance issues happen to be non-existent (but other, unpredicted performance issues may unexpectedly appear). If you want to make benchmarks on OpenVPN, you should first read what has already been done on the subject, namely this page.

Answer 2

What is your threat model? What are you protecting against? Where are the VMs located?

Assuming that the VMs in question are ones you host on machines you own instead of cloud instances like EC2, encryption between the web server and database server is almost definitely overkill. You can simply place the servers in your internal network and only allow the web server to query the database. Sure, an attacker that manages to crack your defences and gain access into your internal network can sniff the traffic, so you will have to weigh that threat against the cost of encrypting the data and decide if it's worth it.