Protect host (and LAN) from virtualbox guest using NAT
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 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? |
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. |
Quote:
Quote:
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... |
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 :D |
Quote:
|
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. |
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. |
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? |
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.
|
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...
|
All times are GMT -5. The time now is 03:07 PM. |