Want to make a virtualbox installation more secure

[Nipperdj]

I am kind of surprised that everyone commenting so far has missed the point so I will try to explain exactly why what I want to achieve DOES work.

1) The objective is to allow remote access to Corporate Network from an employee's computer which may or may not be secure.

2) I or corporate do not care what happens to the employees computer, if it is compromised, that is the employee's problem and should not be ours.

3) right now access to the corporate network is through Corporate owned laptops only. Access is acheived via a secure VPN client (Cisco VPN client) that is preconfigured. Also access security is multi-tiered requiring RSA Token and User Password.

4) I have proposed a secure VM for access. The secure VM guest is secure because
(a) same security restrictions as exist on physical machine (domain membership required, secur VPN client, RSA Token and remote password, etc.)
(b) no network access for VM to guest (NAT'ed network interface, Host cannot ping, or use ARP to discover VM)
(c) no VM USB access to Host
(d) no VM CD/DVD Rom access to Host
(e) no VM to Host Shared Folders
(f) no Virtual Box manager. VM is started by VBoxSDL

(5) Scenarios where Host is compromised:
(a) rogue employee-- Because the rougue employee already has remote access privileges security of Corporate Domain are in effect: remove employees rights, terminate employee, burn the remote VM by removing it from remote access group. In the scenario of employee having a physical Corporate owned machine, we may lose the machine but with a VM, we just burn it.
(b) employees game playing teenage son visits malware sites and infects Host machine:
(i) teenage son couldn't invoke VM with out access password and could not access corporate network without RSA Token and remote password
(ii) infected HOST would not invoke VM unless specifically designed to log key strokes and would still fail for inability to produce correct RSA Token.
(iii) mechanisms for transferring data from HOST to VM are removed
(iv) mechanisms for transferring data from VM to HOST are removed
(v) malware not able to proprogate from Host to VM (See comments on general malware below)
(C) Host computer unable to connect to internet, or malfuntctions in some way (corrupted registry, redirected host programs, etc)-- VM is unaffected and most likely unaccessible as the HOST is unusable. Corporate can burn the VM when notified by employee.

I have learned a few things about Virus and Malware in 20 years: the mechanisms for propogation and compromise are generally quite primitive (new Registry keys, altered registry keys, added start up options, browser redirection, key logging, spam propagation, email compromise) In order for a malware to penetrate a Virtual Machine would take very specific and targeted programming that would run into the tens of thousands of line of code. It is just not feasible. If someone wanted to target our network for compromise, an out in the wild virus or malware is not going to be the method.

There seems to be the assumption that because the HOST is insecure the VM is insecure. As mpack pointed out, the Guest OS and the Host OS are two different machines. When NAT'ed, they are also two different networks. The infection or compromise of the HOST does not mean that the VM is likewise compromised. In my tests, I have been able to demonstrate that the VM remains secure when the HOST is compromised. (intentionally infected a host with a trojan, then invoked the VM to see if its browser was redirected as was the HOST. The VM was uninfected).

For my specific purpose I am satisfied that a secure VM can be used to access the corporate network. For a generalized purpose, I can see where VM's offer another level of security for everyday use.

Thank you,

nipperdj

[noteirak]

Where would the VM be running? On the employee's hardware or on a secure host (server in datacenter)?

[Nipperdj]

Where would the VM be running? On the employee's hardware or on a secure host (server in datacenter)?

VM is running on employee home computer. The scenario is a secure VM on an insecure Host. It works. As long as VM is NAT'ed, locked from Host USB, CD/DVD, Shared Folders, the setup is secure in that no unauthirzed access to Corp network, no download of data from Corp Network to Host (no avenue provided). VM access has same security protocolas as physical corp machine configured (RSA Tokan , remote access group membership, remote access pwd, network password, group policy and local security policy enforced on VM.

Unless hacker can parse the VM virtual disk file VM data not accessible. And even then corp policy enforces download encryption so parsed data would be inaccessible.

I think its a brilliant use of VM technology if I say so myself.

[noteirak]

VM is running on employee home computer.

On which he is admin I guess, so what would prevent him from actually toying with the config of the VM?

[Nipperdj]

VM is running on employee home computer.

On which he is admin I guess, so what would prevent him from actually toying with the config of the VM?

Virtual Box is started via VBoxSDL and VBoxManage GUI is disabled or removed altogether. PerryG referred me to the manual for custom configuration and the features which would allow the user on the Host machine to enable USB Access, CD/ROM access or Shared Folders (all security busters for an otherwise secure VM) can be disabled (generally by removing the option).

A determined remote user could probably re-install VBox and then gain unauthorized access but such a user could violate Corporate policy otherwise. Corp IT admin checks log for remote access multiple times per day, frequent access and file copy would be big red flags that would initiate a lockout of the account (machine and user).

I have proved the concept so far and now we are working on fine-tuning. Possibilities are very tight local policies on VM that user of VM would not be able to change as he would not be an administrator on VM. Also a custom build of Virtual Box to permanently remove the Host/VM feature for file sharing or altering the NAT'ed NIC to a Bridged NIC is being considered (we have very good programmers employed!) and perhaps introducing an authentication protocol to run VBox.

One thing I have failed to mention is that the VM is a virtualized physical machine specifically configured for secure remote access and joined to corp domain with all group and local policies in effect. The virtualized machine is then deployed to the employees home computer with VBox installation files which install and configure VBox.

The deployment part is still be experimented with and tested. But the base scenario (a secure VM on an insecure Host) has so far proven very effective. We actually gain some additional layers of security that is not otherwise possible (primarily the double NAT'ed network interface -- VBox NAT, VM NAT; the elimination of CD\DVD ROM)

[noteirak]

A determined remote user could probably re-install VBox and then gain unauthorized access but such a user could violate Corporate policy otherwise.

That was my concern yes. I am the first person convinced about the greatness of VB but there is so much you can (basically, nothing) against someone with admin access on a station.
But if you handle that from an administrative PoV, all the best.

Just my 2 cents : I would have setup some VMs in special DMZ in your corporate network, with their RDP port open to the world, given a .RDP file to your employee, totally lock down these "remote access VM" with GPO, and install all the remote access software you use on them.
So in this case, you would have all the same protection with your RSA token & all, AND you could totally lock down anything you want from VB running out of reach of your users, and via GPO.

[Nipperdj]

Just my 2 cents : I would have setup some VMs in special DMZ in your corporate network, with their RDP port open to the world, given a .RDP file to your employee, totally lock down these "remote access VM" with GPO, and install all the remote access software you use on them.
So in this case, you would have all the same protection with your RSA token & all, AND you could totally lock down anything you want from VB running out of reach of your users, and via GPO.

That's a good thought but the underlying problem is the RDP port. Even in a DMZ zone the opportunity exists to exploit a security vulnerability (usually by buffer overrun or memory leak) that cripples the corp machine or leaves it open. An exposed DMZ is still a great security risk as there is only one layer of security (the NAT firewall). So while VM is secure the DMZ with open RDP port is not so much.

The need exists for key employees to be able to access Corporate Network from home machines. Current solution is no home machines only Corp owned (and security configured) laptops. For some key individuals they do not want to carry home a laptop for sundry reasons. I have been seeking an acceptable solution and thought a secure VM might fill the bill.

They are many "secure" methods for remote access. Larger organizations (say Intel or HP) have very different remote access policies and methods. Our organization is not small and Corp Management (including IT and CTO) are very very guarded about network and information security. (IP and Patents and International Treaty provisions are key factors). I wanted to explore an thinking-out-of-the-box security model that could be implemented. So far no one has demonstrated why it (secure VM on insecure Host) wouldn't work. I am going to further test vulnerabilities by intentionally infecting Host (will try Wireshark, Trojan, and Worm) and seeing how VM is or is not infected.

Thanks for all your input and attention.

Dennis

[Martin]

I think the "secure VM on insecure host" has blocks some possible ways of infection like worms crawling through network connections or virus modifcations of program files inside the VM (if they don't find a way to understand the structure of the VM disk file).
But you still have the big problem of keyloggers and similar spy software on the host which could still grab everything entered in the guest.