Page 1 of 1

networking type best for sandboxing the guest

PostPosted: 8. Mar 2016, 21:29
by Winxp-on-Macos
One of our V.B. usage schemes is a sandboxed machine.
Means as much isolated from the host it is running on as possible, as few connection points with host as possible.
Which type of supported networking adapters (virtualized) isolates the network traffic generated by guest in max possible extend from host?
Means if the guest and its network traffic is under control of fraudulent handling, it gets no or as few as possible chance to
propagate from guest to host.

Re: networking type best for sandboxing the guest

PostPosted: 9. Mar 2016, 14:50
by scottgus1
Ah, yes, I remember this question fondly. Was a pet subject of mine for a bit:

If you do not want internet in the guest, the easiest way to "sandbox" the guest is to have no network at all, and no Guest Additions. Use another guest to load data and programs you want for your sandbox guest onto a second virtual drive, then shut down that guest, swap the virtual drive to your sandbox guest, and start the sandbox guest.

If you do want internet, Virtualbox's NAT would allow internet but place the guest in a different IP address range. However, direct access to host network IP addresses is allowed, and all host services and shared folders can be accessed via IP address.

The only easy way that I know of to completely isolate the guest from the host network while allowing internet into the guest is with a pfSense guest acting as a NAT router and firewall between the sandbox guest and the host network. pfSense is free, Linux-based, very powerful, very small & low-impact on host resources.

The pfSense router guest has two networks. One is used as the "WAN" and connects to the host network via Virtualbox's Bridged. The other is the "LAN" port, and connects to the sandbox guest(s) via Virtualbox's internal network. Turn the pfSense router's DHCP on and serve IP addresses in a different range than the host's network. In the pfSense firewall, set an LAN outgoing block rule set to the host's IP address range. Here are my settings, credit to thetrevster:

pfsense block host lan rule.PNG
pfsense block host lan rule.PNG (48.22 KiB) Viewed 5214 times

Here's the settings to make the rule:

pfsense block host lan rule settings.PNG
pfsense block host lan rule settings.PNG (94.34 KiB) Viewed 5214 times

Put the rule as the second rule on the LAN tab, and your sandbox guest will not be able to find the host network.

Here is a picture of how the pfSense and other guests can be set up:


Re: networking type best for sandboxing the guest

PostPosted: 9. Mar 2016, 17:15
by mpack
I see no reason to avoid installing the GAs. Doing so doesn't increase network availability. If you don't want the GAs to access a shared folder, don't define any.

Re: networking type best for sandboxing the guest

PostPosted: 9. Mar 2016, 22:30
by Winxp-on-Macos
Thanks for your participation.
Actually, I were going to focus in this thread on the data pipeline connecting the guest with its outside.
Sure, sandboxing is a broader topic than this.
Yes, we are developing and applying some practices to have sandbox effect.
Of course, our concept is still far from ideal sandbox, despite the question if it will possible at all to have ideal sandbox,
we are still in development.

NAT is a piece of software. It runs and operates at level of virtualization solution and the host environment (OS, hardware).
Thus as everything else in the world it will show weak spots which malware & Co. can try to break.
That's the background of question asked.

As basically computers today make few sense if not connected with other,
our sandbox v.m. also is intended to connect with I-net. Generally in our case the use-case
read either I-net-only or LAN-only. However, as of today LAN-only case does not find application in our micro-cosmos.

Re: networking type best for sandboxing the guest

PostPosted: 10. Mar 2016, 14:17
by scottgus1
A true internet-connected sandbox will be a physical PC with its own internet connection by a separate account with the ISP, and a separate router. If you want to run as a VM and are concerned about possible attack vectors from guest to host, you'll need to sandbox the host too.

On the other hand, you could research how often a particular sandboxing software arrangement gets attacked and what the response from the software developers are.

It's all a balance. Encasing the PC in concrete and buying a separate internet path, including new telephone wires back to the ISP, would be a really secure sandbox. But it would be cumbersome to maintain and distribute. If you want a VM, you're already considering not having as much absolute security as the concrete PC. Just have to decide how much balance of security vs ease of use you are willing to have.

Re: networking type best for sandboxing the guest

PostPosted: 15. May 2018, 02:25
by mitchong
Hi, I was wondering if there's been any new developments in regards to a true sandbox in Virtualbox? I just came to realize the NAT connection from a Virtualbox on a Linux host still makes the host and LAN vulnerable to malware and hacking. You can even connect to the access point webpage if you happen to figure out the IP.

Is there a way to configure the firewall in Linux with iptables to block any connection to the host or LAN but still maintain connection to the Internet with the Virtualbox connected via NAT?

Thanks for any help you can provide.

Re: networking type best for sandboxing the guest

PostPosted: 15. May 2018, 07:38
by socratis
mitchong wrote:Hi, I was wondering if there's been any new developments in regards to a true sandbox in Virtualbox?

Not unless there have been any new developments on how networking works. Just try to "draw" in a piece of paper how you envision this thing working, and you'll realize that you can't have a "tunnel" to and from the internet without having access to your LAN. Not unless you do something in your guest like having rules for blocking traffic. But if you get a malware, it can easily rewrite the rules, so you're not getting anywhere.