Want to make a virtualbox installation more secure

[Nipperdj]

My objectives are this:
* GUEST OS Machine is secure for remote access to corporate network
* No access to Host USB or CD/DVD
* No access or enabling Shared Folders

Is there a way to create a custom installation that would ensure that the features could not be enabled? In other words, can I remove the option of those features?

I am thinking of a script based installation (PowerShell for instance or VB Script).

Could a scripted installation of Guest Additions be accomplished either from the Host or from the Guest (VM)?

I have proved the concept of a VM as a remote machine joined to our Corporate domain. Now I need to be able to better secure the VM. Intellectual Property protection as well as malware protection are the motivating factors.

Thanks for any ideas or suggestions.

[noteirak]

I guess you want to use a Windows as guest OS and get people to connect to the Remote Desktop via the standart Windows RDP client?
If so, all these can be disabled in the AD via GPO.

If a person has access to the Virtualbox installation and rw access to the VM files (which is mandatory to run a VM), it cannot be done - Virtualbox doesn't support any kind of authentication/authorization system.

Or maybe I understood wrong what you want to do and you should explain in a bit more details what you want to put in place, and what you alread have in place.

[Nipperdj]

No connections to Guest OS via Remote Desktop.

The Guest OS (VM afterwards) resides on a Host Machine which is offsite from Corporate network. The VM needs to be secure from Host Machine in that there is no shared folders (VM to Host) no Host Drives (USB, CD/DVD) accessible from VM (Guest OS). VM will use VPN Client to connect to Corporate domain. VM is already joined to Corporate domain.

I have not been able to find any situation where these were the parameters. I want to completely disable VM to Host interaction other than the starting up and running the Guest OS.

Thank you.

[Nipperdj]

Additional Notes on this scenario:

VM was preconfigured for access to Corporate network while still a physical machine, then it was virtualized with the VMware conversion utility. Then loaded into Virtualbox as a .vmdk disk.

The VM connects via VPN client to Corporate Network and runs superbly. I can disable CD/DVD Rom and disaable USB drive and disable shared folders. But I could also enable them. What I wish to do is to remove the option to re-enable those features. I want them permanently disabled. By doing such I have completely secured the VM from the host (all except the NAT'ed NIC interface that is)

[Perryg]

Perhaps you should read this http://www.virtualbox.org/manual/ch09.html#guitweaks
It is possible to cripple the GUI and even the hot keys. But I suggest you test each feature change before you go to production.

[noteirak]

How will your users use the VM? What is the purpose of the VM?
You do not give any information on how the VM will be used or accessed for that matter, so it's hard to give you a proper answer.
Perry's answer fits if your users are allowed to see the VM console via one of the Virtualbox GUI, but it doesn't prevent them from actually modifying parameters.

[Nipperdj]

To noteirak:

I thought I was fairly explicit on how the VM is to be used. But I will give it a shot again

• The user has an instance of Virtual box on home or remote machine (ie. not at Corporate Site]
• The user will use the VM to connect securely to Corporate network via VPN Client which is installed on VM
• Corp objective is to protect and secure
[list=]
• 1) intellectual property
• 2) prevent deliberate or inadvertant introduction of malware into Corp network (such as by an insecure Host -- no anti-virus anti malware, not up-to-date Windows security fixes, active malware on Host --keyloggers trojans etc. --, no firewall, etc.
• 3) prevent copy/download Corp data to foreign system (ie. Host)

[*] User can access Corp files for remote work needs from VM[/*]
[*] User can run Corp software (proprietery technical) from VM[/*][/list]

The scenario remains as explained: to secure the instance of Virtualbox by removing options such as access to Host USB, CD/DVD Rom and Shared folders. I believe Perryg gave me the information I needed. We might possibly compile our own version of Virtualbox to remove such features but that might be overkill.

I am still investigating automated logon to Guest OS. Thank you for your thoughts and comments

[Nipperdj]

Perhaps you should read this /ch09.html#guitweaks
It is possible to cripple the GUI and even the hot keys. But I suggest you test each feature change before you go to production.

This is pretty much what I was looking for. I will continue to experiment and test.

I have been investigating this scenario (making a secure VM for use as a remote access workstation) for a couple of months and have found next to nothing on this sort of use for a Virtual Machine. The typical scenario is to use Terminal Services or Remote Desktop or just simply a VPN client. But each of these have certain drawbacks and costs (licensing, speed, functionality, security, etc.)

My testing so far of the VM for secure remote access is working superbly. All I need to do now is to secure the VM to Host aspects and to automate the starting of the Guest Machine (Scripted file to start VirtualBox and autologon to Guest OS). When I can accomplish that we will then create an installation file to 1. install Virtual Box, Load vmdk file, and configure secured settings (as discussed in this thread). Anyway thats the big picture.

Thanks,

Dennis

[mirkt]

My testing so far of the VM for secure remote access is working superbly. All I need to do now is to secure the VM to Host aspects

How can we talk about security, when host system isn't secured? As you wrote:

2) prevent deliberate or inadvertant introduction of malware into Corp network (such as by an insecure Host -- no anti-virus anti malware, not up-to-date Windows security fixes, active malware on Host --keyloggers trojans etc. --, no firewall, etc.

If your host is not up-to-date, has trojans, keyloggers, etc., how can you call your guest secure?

[mpack]

If your host is not up-to-date, has trojans, keyloggers, etc., how can you call your guest secure?

That would rather depend on how exposed the host is to threats wouldn't it? It's perfectly possible for the host to have no internet connection but for the guest to have one. Therefore the host would not need internet precautions, but the guest would. These are two separate PCs, their exposures need to be considered separately - and not by those with a vested interest in selling malware snake oil. Understanding the risks is a far more reliable route to security.

[Nipperdj]

My testing so far of the VM for secure remote access is working superbly. All I need to do now is to secure the VM to Host aspects

How can we talk about security, when host system isn't secured? As you wrote:

2) prevent deliberate or inadvertant introduction of malware into Corp network (such as by an insecure Host -- no anti-virus anti malware, not up-to-date Windows security fixes, active malware on Host --keyloggers trojans etc. --, no firewall, etc.

If your host is not up-to-date, has trojans, keyloggers, etc., how can you call your guest secure?

Mpack makes the correct point: the Guest and the Host are two separate PC's. My purpose in virtualizing the PC Workstation that is used for remote access to Corporate network, is to put a firewall between the Host (insecure) and the VM (Secure). The only access to the VM from the Host is via Virtual Box which I will lockdown (using VBoxSDL, not providing access to Host USB, CD/DVD, Shared Folders). The VM is NAT'd, the VM secures WAN network communications (via VPN Client).

Just exactly how would a trojan or virus penetrate Virtual Box? How would a infected/compromised Host then infect or compromise the VM? And the HOST could be nuked (OS cleanly reinstalled) with no affect or consequence to the Corporate network as the VM could be burned and reinstalled later. The Corporate IT Admin could unilaterally burn the VM by removing it from Active Directory.

This is a use of a VM that I have not seen advocated or documented. I put this thread up for some input from the community. I don't think many have fully contemplated this scenario. I believe it to be a superior method for remote access to a secure and protected Corporate network (as ours is!). It has many advantages over Terminal Services (lower licensing costs, far greater security) and is hands down a better solution than Remote Desktop or other tunnelled remote access programs (logmein, VNC, etc.). In every tunnelling scenario a compromised Host would immediately expose the Corp Network to risk.

Thanks for your comments

[f456]

if i understand you correcltly, there is no way to archive what you want.


If the guest is compromised, the host caanot be declared secure. Assuming malware has root at the host, it can, for example, crash the VM and infect the vmdk disk.
You may be able to prevent the user from seing the optoions for shared clipboard, shared folder, etc. But given enough privileges (or an exploit), the user or any malware can change these settings.

[mpack]

If the guest is compromised, the host caanot be declared secure.

? Of course it can. People use VMs all the time as a secure sandbox in which to probe malware. Protecting the host is trivially easy, and needs no additional software, just an understanding of how such malware propagates.

[f456]

Yes, you're of course right. I meant the other way around:

If the host is compromised, the guest cannot be declared secure.

Which, i believe, also makes more sense in this context.

[mirkt]

as I understand, Nipperdj HOST systems are going to have Internet:

The user has an instance of Virtual box on home or remote machine (ie. not at Corporate Site]

he is afraid, that they are not secure enough so he is going to use a secure GUEST on insecure HOST.. I think, if your HOST will be compromised, your GUEST will be unprotected. If it's possible to lock „VirtualBox“ (as you intend to do), it will be possible to unlock it also..

mpack, I am using „VirtualBox“ GUESTs for browsing Internet on HOSTs without Internet, but that's different story..