# dmz's, vserver, vmware and security - opinions wanted

## kimmie

Hi peeple,

I have a server that I want to be internet facing. I want it to be secure, in a DMZ. But at the same time, I don't want to lose the functions it performs in my internal LAN: distcc server and squid proxy. So I want everything all at once. And I want to keep things simple. (Just joking about that last one).

The machine has two network interfaces, and I have a hardware firewall which can do the DMZ routing and packet filtering. On the LAN side, it's on a gigabit network, on the DMZ side, just 100Mbs.

I was planning on running the internet facing services in a virtual machine, but keeping the host on the internal LAN. I've got some experience with VMware, so if I use that I will bridge the guest to the DMZ network interface. I'll bring up the interface on the host, but not assign it any IP address; that way I figure the host machine will have to talk to the guest via the firewall. 

So Q1 is... is that enough isolation to be secure? Or am I just asking for trouble; should I put the lot in the DMZ and forgo my distcc/squid.

Q2 is... would a similar idea work with vserver (if I need more performance, I think that may be the way to go.)?

Q3 is a general one about DMZ machines... how do I back it up? I'd be blocking all incoming traffic DMZ->internal lan, so I figure the way to back up the DMZ machine is to do it to local disk, then connect from a machine on the internal network and copy the backup over. I can't think of another way of doing it securely.

Q4 is about sharing portage/distfiles between the host and the guests. My thought is to do this via nfs, but to manually control access; in other words have the portage filesystems on the host. When I want to update a guest, disconnect it from the internet, then manually enable the DMZ->LAN traffic to enable mounting the filesystems, do the update, then secure everything again. A bit cumbersome, but it should work.

I'd be grateful for any comments/ideas/alternatives you've got.

----------

## geforce

If I were you, i'd use some iptables rules to block any connections from the outside of my network (i.e DMZ nic  or IP range), finally, i'd setup rules to allow connections on certain ports from the outside, for example, 80, 21, 22, 25, etc.

This way you still have you distcc an squid, and you are firewalled from the net.

 *kimmie wrote:*   

> 
> 
> Q1 is... is that enough isolation to be secure? Or am I just asking for trouble; should I put the lot in the DMZ and forgo my distcc/squid. 
> 
> 

 

If you use iptables as suggested, I think yes.

 *kimmie wrote:*   

> 
> 
> Q2 is... would a similar idea work with vserver (if I need more performance, I think that may be the way to go.)?
> 
> 

 

Honnestly, a friend of mine tried a lot of virtual servers solutions in the last 6 months, and he's back on VmWare...  And personnally I've always liked VmWare.  But sorry, I don't know much of vserver.

 *kimmie wrote:*   

> 
> 
> Q3 is a general one about DMZ machines... how do I back it up? I'd be blocking all incoming traffic DMZ->internal lan, so I figure the way to back up the DMZ machine is to do it to local disk, then connect from a machine on the internal network and copy the backup over. I can't think of another way of doing it securely.
> 
> 

 

Hmm, your solution seems pretty complicated.  You still are on your LAN, why not simply use it ?

 *kimmie wrote:*   

> 
> 
> Q4 is about sharing portage/distfiles between the host and the guests. My thought is to do this via nfs, but to manually control access; in other words have the portage filesystems on the host. When I want to update a guest, disconnect it from the internet, then manually enable the DMZ->LAN traffic to enable mounting the filesystems, do the update, then secure everything again. A bit cumbersome, but it should work.
> 
> 

 

You can always use NFS safely, but you need appropriate iptables config so it's not exposed on the net.

Even more, with appropriate iptables rules, you could only use your 1Gb nic and put it DMZ...  The outsiders would only have access to the port you want to make public, and the insiders would have access to any ports, or you may restrict it as well, I don't know you setup too much...

----------

## think4urs11

 *Quote:*   

> So Q1 is... is that enough isolation to be secure? Or am I just asking for trouble; should I put the lot in the DMZ and forgo my distcc/squid.

 

Depends on your personal level of paranoia. There's always the possibility that some bad guy hacks your guest and breaks out of VMWare to enter the host underneath.

Use a hardened system, (very) tight iptables ruleset and use different passwords on the guest.

 *Quote:*   

> Q3 is a general one about DMZ machines... how do I back it up? I'd be blocking all incoming traffic DMZ->internal lan, so I figure the way to back up the DMZ machine is to do it to local disk, then connect from a machine on the internal network and copy the backup over. I can't think of another way of doing it securely.

 

Connect from a LAN-hosted box and pull the data instead of pushing them from DMZ->LAN.

Connections DMZ->LAN are always 'evil' and thus shall be avoided.

 *Quote:*   

> Q4 is about sharing portage/distfiles between the host and the guests. My thought is to do this via nfs, but to manually control access; in other words have the portage filesystems on the host. When I want to update a guest, disconnect it from the internet, then manually enable the DMZ->LAN traffic to enable mounting the filesystems, do the update, then secure everything again. A bit cumbersome, but it should work.

 

Easier to handle and probably less error-prone: Put portage/distfiles inside of this VM and have all others pulling their portage copy from there via http-replicator/rsync.

----------

## kimmie

Thanks very much for the replies. At least two people don't think I'm insane, that's reassuring enough for me to do some further research into VMware and host/guest isolation... FYI, here's what I found:http://taviso.decsystem.org/virtsec.pdf - interesting paper buy some Google guy actually hammering VM's and comparing the results.

http://honeyclient.org/trac/wiki/VMHardeningGuide - guide for hardening VM's purposely designed to run malware

http://communities.vmware.com/message/750539#750539 - VMware forums post on host/guest isolation

http://communities.vmware.com/message/55316#55316 - another forums post, talks about tuning VMware tools parameters for isolation

http://sanbarrow.com/vmx/vmx-advanced.html#isolationtools - big list of VMWare turning parameters

http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf - VMware paper on DMZ virtualisation

This seems to indicate that I don't have all that much to worry about with host/guest isolation, provided I'm careful to set things up correctly with the network and VMware tools. And keeping the whole lot (including the host) in the DMZ is wise, even if only to protect myself from my own misconfiguration. So, given that and taking your suggestions into account, here's what I'm thinking now:Forget about having the host on the internal LAN, it's sort of missing the whole point of a DMZ.

Use one NIC for the guests, and one NIC for the host (but both in the DMZ). That means that even if VMware has to put guest NIC into promiscuous mode, internal LAN<->host traffic won't appear on it.

Protect the host from the guests with IPtables rules.

I'm still going to run distcc and squid on the host; if somebody manages to break out of a guest into the host and slip me a trojan through the proxy server, good luck to them. I'll just have to up my paranoia level a bit, and not go out of the house.

Forgo my gigabit transfer speeds (my firewall has only 100Mbs ports). Thinking about it, it's not going to have that much of an impact; don't really need it for squid, slow down distcc a bit, it won't make that much of a difference.

Put portage/distfiles in inside a VM, that way there's no need for incoming traffic guest->host.

Don't use the VMware hgfs (sort of obvious, really).

Either don't use vmware tools in the guests, or restrict drastically what it can do at the host.Q. If anybody's got any further suggestions on how to backup a host in the DMZ, I'd like to hear them. I understand I have to pull the backup into the internal LAN, I'm wondering whether it's possible to do this without requiring a full backup copy within the DMZ first. I use xfsdump to do backups, so maybe I could ssh into the DMZ host and run the job to stdout, and capture the data on the internal lan that way. Except the encryption overhead for so much data is a little high... can I use ssh without encryption? Rsh? More research I guess, or just buy some more disk.

Thanks again for your input, I'm a lot closer to actually getting this done now.

----------

## think4urs11

 *kimmie wrote:*   

> Use one NIC for the guests, and one NIC for the host (but both in the DMZ). That means that even if VMware has to put guest NIC into promiscuous mode, internal LAN<->host traffic won't appear on it.

 

It would 'just' need a bit of arp flooding against the DMZ switch and the bad guy in the guest can see the traffic 'host NIC <-> any' as well.

Better separate both NICs in two different DMZ. One externally reachable DMZ for the guest(s) and the second one for the connections to/from the host.

----------

## kimmie

Thanks! I didn't know about ARP attacks.

----------

