Virtualization has been the best thing to happen for sysadmins in the past 10 years or so. A data center’s worth of servers can now be condensed into a single rack. Hardware can die and the servers running on it can live migrate to another host and keep running as if nothing ever happened. Building a new server no longer requires hauling and racking new hardware.
So what are the big benefits to virtualization? Reduced hardware costs, mainly. You’re buying more expensive servers, but you only need 3 or 4 instead of 50. A reduced hardware footprint also saves you in data center costs. If you colocate in a data center, you pay far less for fewer racks. If you’re running your own, you don’t have to dedicate as much space. You also gain compartmentalization. I’ll come back to that in a moment.
What about drawbacks? Peripherals can be difficult to manage, so if your server requires specialized hardware, such as a security DVR, you probably won’t be able to virtualize it. Older call accounting servers that connect with a serial cable to a phone switch could be virtualized, but generally are not worth the headache. Newer network-connected PBXs and VoIP systems can have their management and accounting virtualized with no problems. Some vendor-specific software will not run on VMs because the vendor refuses to accept that virtualization is a thing and is not going away.
So what is this compartmentalization thing I mentioned earlier? Compartmentalization is where you separate tasks so that if one goes down or is compromised, you don’t necessarily lose everything. For example, let’s say you have a physical server that’s running your email, your website, and acting as a database server for the website backend and your accounting database. Your CMS has an exploit that lets the attacker execute arbitrary code and a SQL injection vulnerability as well. (Jeez, you need a new CMS)
On that physical server, the attacker can literally do anything (execute arbitrary code) such as install backdoors, create user accounts, or trash your setup. The SQL injection vulnerability also allows them access to your DB server. An attacker honestly wouldn’t even need that for this case since they can execute Whatever They Damn Well Please, including the command line tool for your database server. They also have full access and control of your email.
What if we compartmentalize this so that one server isn’t running the entire kingdom? Email is on its own VM, the database server is on its own VM, and so is the website. Now if they compromise your web server, all they get is the web server. Sure, it’s still bad, but it’s less bad than the first scenario. But that SQL injection exploit is still lingering over our heads. Good database practices can mitigate that risk, too.
Compartmentalize your databases. Use separate users for your databases. Your CMS’s DB user has no business even being able to see the accounting DB. A SQL injection exploit’s range is limited to what the current user account can access. If you segment things so that one part being compromised doesn’t provide access to everything, you’re compartmentalizing.
Virtualization makes compartmentalization easy. You can create separate VMs for things that need to be separated without spending more money on hardware or taking the time to install it into the data center.
Compartmentalization takes a nice, fat target for attackers and separates it into little boxes so that a single exploit isn’t putting your entire infrastructure at risk. You should be doing this as much as possible, especially on any public-facing systems.
