[kwlug-disc] Networking on libvirt vs. VirtualBox

[unsolicited]

On 14-08-02 01:28 PM, Khalid Baheyeldin wrote:
> On Sat, Aug 2, 2014 at 10:02 AM, unsolicited <unsolicited at swiz.ca
>
>     2. How to make this safe in one's own network? In a provided cloud,
>     presumably they're guaranteeing absolute machine isolation - it's
>     their back end networking. At 'home' everything must inherently
>     participate in the local network, else you could not maintain it,
>     yet how to otherwise isolate it for the world, to run LAMP plus
>     favourite serving applications?
>
>
> See that 0.0.0.0? This means VNC will listen on the all interfaces, and
> hence anyone (on the LAN) will be able to connect to the console of the
> VM (but will still need the password to get it).

That's no biggie, because you wouldn't port forward to that from the 
outside world, on your provider facing router.

But this is still only dealing with / facilitating local access for 
maintenance.

It does not address the outside world coming in and leaking out to your 
local network. For example, for Charles situation of running a small 
LAMP server from home.

So, he will port forward, say, 80 to his local machine (vm or 
otherwise). No restrictions (yet) at that machine as to what it can talk 
to, so local network maintenance activities can proceed full steam ahead.

The question is, once someone attaches / attacks on 80, and manages to 
find an unclosed security loophole, what's prudent protection to prevent 
access to the rest of your local net? A provider will segment off your 
web server to prevent access to any other local machine, the question is 
of appropriate ways to do so with little hardware - since you're now the 
provider.

I could see an ip tables rule to reject non-established non-80 TCP 
connects to the local subnet (so you could ssh in, and it could respond, 
but it can't initiate), but nothing else is striking me off the top of 
my head.

> The reason I had to use this is that I was using KRDC from the laptop

But that would be to the desktop, not the vm itself.

> Then I discovered virt-viewer, and that it can tunnel over ssh. So the
> listen can be changed to 127.0.0.1, or omitted altogether, then from the
> laptop use virt-viewer directly to the instance you are interested in
> without knowing port numbers and such.
 >
 > $ virt-viewer -c qemu+ssh://your-host/system t1
 >
 > This means your consoles for the VMs are protected via ssh, and only
 > those who have keys can view it.

Right, but as I said, no real benefit - those ports wouldn't be exposed 
to the outside world, anyways. You'd only set 80 and/or 443. 5590 would 
not be inherently exposed. Let alone vnc will let you put ip address 
restrictions on it within itself, and/or local password authentication 
of one form or another. (Be it vnc only user/password lists, or local 
machine/pam authentication. The latter something I also noticed in vbox 
for rdp use. [Not to be confused with rfb.])

> That too. I just assign a unique MAC address to each VM, and assign it
> an IP address in the router.

But must still be an IP on the local net, thus a hacked machine will 
still leak out to your local net.

vs., say, local net of 192.168.0.1, one vm per other 192.168.0.128+x 
net, and a rule on the router of route 192.168.0.128/25 on it to the 
server. Or, more likely, 192.168.128+x:80 to the server ip.

Not so sure there's benefit to fiddling with MAC addresses over IP 
subnets. Maintenance wise, anyways.

> No, all the setup I talked about is not meant to run any real load, nor
> stay up all the time. Just for testing.

Right, but this entire thread equally applies to Charles or anyone else 
interested in running a small LAMP server from home, especially if not 
'big' enough yet for one to be interested in paying $120 each and every 
year for a trial balloon.