1

I'm using Linux Virtual Machines (Wheezy, Linux Vserver), each with a desktop environment including Firefox.

If a Virtual Machine where to be compromised (e.g., SQL injection) so the kernel is hacked and control has been seized of the VM (not the host), it is possible to rebuild the VM, and move the data over to the rebuilt VM to fix the problem.

Q: This may be a dumb question, but is it possible instead as an alternative to copy some files into the compromised VM (e.g., a clean version of everything in the /boot partition)? The VMs are pretty tightly locked down to begin with.

The argument here being this might be quite a bit faster than rebuilding the VM. Or, the "right answer" may be "nope, you need to rebuild the VM to be sure it hasn't been compromised". If the alternative approach were worth considering, what would need to be overwritten and replaced to have a "fresh" kernel?

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
user185637
  • 11
  • 2

2 Answers2

0

First, you need to know exactly what has changed without your permission. If I were to design a system like you want, I would:

  • Maintain cryptographic hashes of the running kernel files, which consists of the contents of /boot on my Ubuntu system
  • Maintain hashes of all installed libraries, applications, binaries, etc. on the system that are not part of deployed in-house written applications.
  • Have those hashes maintained off-machine and compared frequently.
  • Know that upgrades will trigger alerts, and resolve them manually.

Or, I would take what is to me the far simpler approach of having a way to recreate a new VM quickly, without manual configuration (Chef, Puppet, etc) and then deploy my custom apps (mostly web apps in my case and database contents) quickly and easily to the new VM.

I think while it is possible to do all the stuff above, and it may help you detect when something has changed which is critical to knowing you have been compromised, it is much harder to be able to undo those changes in a reproducible, middle-of-disaster way. Keeping all the machine config in some machine-creating system like Chef lets you spin up a new VM fast enough that it will likely safe you a lot of time in the end.

Michael Graff
  • 6,668
  • 1
  • 24
  • 36
  • Thanks Michael - appreciate the response. Figured that might be the case, Right now, to replace a vserver guest takes about 10min which isn't bad, but was hoping for something faster. But sounds like the approach to stick with - thanks again! – user185637 Jan 28 '14 at 16:30
  • Many admin use the "nuke it from orbit, it's the only way to be sure" approach to security breaches anyway. Also, this lets you keep the old VM around for forensics as it remains mostly untouched, other than to disable remote logins perhaps while you move the data over. – Michael Graff Jan 28 '14 at 16:32
0

I disagree. I suspect that it's the VM guest's userspace that's been compromised, rather than the kernel.

Either way, you'll probably never know which it was, so the safest thing to do is to nuke it from orbit.

You could restore an earlier snapshot to a last-known-good-configuration state..

Community
  • 1
Tom O'Connor
  • 27,480
  • 10
  • 73
  • 148