Protect host (and LAN) from virtualbox guest using NAT

joe_2000 · 01-09-2015, 02:57 PM

I am running a Debian guest on a Debian host in virtualbox. The guest is running a webserver, and ports 80 and 443 of my home router are forwarded to non-standard ports on the host. The host in turn forwards these ports to the guest ports 80 and 443 using virtual box port forwarding with a NAT type networking mode.

In my security concept I am considering the guest as "untrusted". So in the event where it gets compromised through a security hole in apache or my own website code I want to make sure that the guest is completely isolated for the host (and other clients in the host's network).

I understand that if anything, the guest sees the host on the default gateway ip 10.0.2.2. After reading the virtualbox documentation's NAT section I decided to run virtualbox with a dedicated usergroup called vdebian and to set up the following iptables rules on the host to protect it from the guest. (Simplified for clarity)

Code:

#!/bin/sh

# Iptables
FW="/sbin/iptables"
$FW -F
$FW -X

$FW -P INPUT   ACCEPT
$FW -P FORWARD ACCEPT
$FW -P OUTPUT  ACCEPT

############################################### Chain for Handling of virtual debian traffic #####################################################
$FW -N VDEBIAN_OUT
$FW -A VDEBIAN_OUT -d 127.0.0.1 -j DROP -m comment --comment "Disallow traffic from guest to host" 
$FW -A VDEBIAN_OUT -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "Allow guest to answer all inbound traffic"
$FW -A VDEBIAN_OUT -p tcp -m multiport --dports 80,443 -j ACCEPT -m comment --comment "Allow guest outbound http and https"
$FW -A VDEBIAN_OUT -p udp -m multiport --dports 53,123 -j ACCEPT -m comment --comment "Allow guest outbound dns and ntp"
$FW -A VDEBIAN_OUT -j DROP

################################################################ INPUT ###########################################################################
$FW -A INPUT -i lo -j ACCEPT 
$FW -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$FW -A INPUT -p tcp -m multiport --dports 20022,20080,20443 -m state --state NEW -j ACCEPT -m comment --comment "Forwarded Ports to guest"
$FW -A INPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT -m comment --comment "Inbound http (only for testing purposes)"
$FW -A INPUT -j DROP

################################################################ FORWARD #########################################################################

$FW -A FORWARD -j DROP

################################################################ OUTPUT ##########################################################################

# Jump to virtual debian chains
$FW -A OUTPUT -m owner --gid-owner vdebian -j VDEBIAN_OUT

... Other stuff

I tested this and it seems to behave as intended. The guest cannot open a web page on the host, but any other LAN client can. Nor can the guest access anything else on the host.

Now my question is: Can I reasonably assume that the host (and the rest of the LAN) is protected from the guest machine in case it gets compromised?

vincix · 01-09-2015, 06:58 PM

I am not sure if I have the necessary knowledge to help you, but I do have one question: why do you think that disallowing traffic to 127.0.0.1 means disallowing traffic from host to guest? Doesn't 127.0.0.1 have a local meaning of loop (virtual network interface)? I don't understand the connection.

There are some services dependent on the loopback, such as rndc (the software that controls the dns daemon), but it still has a local significance. So I don't understand how restricting access to loop affects the connection itself between the host and the guest.

joe_2000 · 01-09-2015, 07:05 PM

Quote:

Originally Posted by vincix

I am not sure if I have the necessary knowledge to help you, but I do have one question: why do you think that disallowing traffic to 127.0.0.1 means disallowing traffic from host to guest? Doesn't 127.0.0.1 have a local meaning of loop (virtual network interface)? I don't understand the connection.

There are some services dependent on the loopback, such as rndc (the software that controls the dns daemon), but it still has a local significance. So I don't understand how restricting access to loop affects the connection itself between the host and the guest.

Yeah, it took me a while to figure that out. If you take a look at the virtualbox documentation (I linked to the relevant section in my previous post) you'll find this statement:

Quote:

To an application on the host, or to another computer on the same network as the host, it looks like the data was sent by the VirtualBox application on the host, using an IP address belonging to the host.

So I created a logging rule in iptables for all traffic and loaded a webpage on the host from within the guest. Both the source and the destination addresses were shown as 127.0.0.1.

So I am using the gid rule to differentiate the virtualbox traffic from the other traffic to lo that you mentioned. Seems to work, but I am wondering if I missed anything...

vincix · 01-10-2015, 02:42 AM

Another question: why didn't you not impose the same states in OUTPUT (VDEBIAN_OUT) as you did in INPUT? I'm referring to 80, 443 and 50, 123 respectively and to the NEW state. But, in my opinion, it probably doesn't make too much of a difference, unless you want to be a little bit more strict.

As you can see, I'm probably going to learn more from you than you'll learn from this thread

joe_2000 · 01-10-2015, 05:36 AM

Quote:

Originally Posted by vincix

Another question: why didn't you not impose the same states in OUTPUT (VDEBIAN_OUT) as you did in INPUT? I'm referring to 80, 443 and 50, 123 respectively and to the NEW state. But, in my opinion, it probably doesn't make too much of a difference, unless you want to be a little bit more strict.

As you can see, I'm probably going to learn more from you than you'll learn from this thread

Not something I did deliberately for a good reason. My real rules are a bit longer and I simplified them for clarity. That involved some copy pasting....

vincix · 01-10-2015, 08:53 AM

Ok, I have a more significant question now:
I see you have the special ports permitted in INPUT. But how does the host actually know how to forward those ports (so basically change them) to 80/443 if you don't use dnat? (PREROUTING)

Maybe I didn't understand it well - are those special ports open on the guest too? Meaning are ports 80/443 changed to those special ports (in apache, if that's what you're using). From what you're saying, they are not, because you say that the host forwards http(s) to 80/443. And if that is so, my main question stands.

273 · 01-10-2015, 09:21 AM

I think I would do this differently and set VB to use a bridged adaptor so that the guest gets a separate IP address from the router. Then the ports will just be forwarded to the guest. If your router has a DMZ you could even put the guest in there though I've never figured out exactly what the benefit of that set-up is.
That way you could set up any firewall rules on the guest to disallow communication with the host IP if you wish or vice versa without having to use 127.0.0.1 and the like which I would consider to be confusing.

joe_2000 · 01-11-2015, 09:26 AM

That was actually what I tried first, but I was struggling to set it up in the router. And then I also thought that theoretically, if the vm got compromised, it could just connect to the trusted vlan. I obviously cannot physically separate it since it uses the same network interface as the host.

Does that make sense or am I missing something?

273 · 01-11-2015, 11:18 AM

I am not sure it really matters which way you do it I just find having the VM have it's own IP address from the router the easiest to comprehend.

joe_2000 · 01-11-2015, 11:44 AM

Agreed. But getting the VLAN stuff to run on my router seems to be a pain in the butt. I tried for a day or two and gave up...