DMZ hosts on Internal Datastores?

[SLCSam]

Hello All,

I hope I'm posting in the right section, and that this all makes sense.

Currently we are running  two separate clusters, managed by vcenter.  One for all of our internal servers and one for our DMZ servers.  On our DMZ hosts we have nic 1 and nic 2 combined for the service console, vmkernel, and datastores.  Both of those nics are connected to our internal network.  We then have nic 3 on dmz1 and nic 4 on dmz2.  Each set of nics is assigned its own vswitch.

The datastores for all vm guests on the DMZ cluster are NFS targets on our internal network san. Each Guest vm is only assigned 1 nic with access to it's particular DMZ.

My question is about security.  We have been functioning this way for quite a while, but my network/security guy is concerned that in some way the vm can be hacked to gain access to all nics that are connected to the host, or that the vm could be hacked and someone could potentially gain access to internal data on our SAN.

What are best practices for this scenario?  Do I currently have security holes?  Assuming this configuration is ok, is there information I can give my network guy to ease his worry?

Our san is a Netapp.

edit: typo on nic4 for dmz2

[cyclooctane]

Hi SLCSam

The way that I understand the way ESXi handles this (and someone please correct me if I am wrong)

Is that ESXi handles all of the disk traffic independent of the VM.

Hence the VM only knows how to send SCSI comarnds to the hyperviser that then re-writes the comarnds and sends them to the virtual disk files.

Hence each VM only has access to its own virtual disk, and nothing else on the data store.

Hence if one of the VMs is hacked, the data on that VM will be exposed but that is all.

The VMs that are running on these clusters are all independent computing enviroments. And have no access to each others files.

Think of them as running multiple independent servers. These can not write to each others disks unless via CIFS or alike.

From what you have written, you have nic1 and nic2 as a trunk serving disk networks and admin.

You then have nic3 and nic2 linked to 2 different DMZs

Hence nic2 appears to be linked both to the disk network and to the DMZ.

This is a major problem. Since if one of the VMs in this DMZ is hacked, said VM could talk to the SAN via NFS (since they are on the same layer 2 network) and this will expose the .vmdk files for the other (possibly internal) VMs.

This is assuming that there are no vlans involved. Because if the DMZ and the disk net are on different Vlans then this problem will not occur.

If this is a typo and the admin and disk network is on nic0 and nic1 or there is Vlans setup to separate the layer 2 traffic, then there is no issue with this setup, even if one of the DMZ VMs is hacked.

Regards

Cyclooctane

[weinstein5]

Your answer is correct - 

[SLCSam]

Thank you for the replies.  I think the only other question I have is that if someone were to gain access to our dmz, could they ever bridge the connections between the dmz ports and the internal network ports on the esx host? Basically, if the esx host was compromised on one of its dmz ports, could access be gained into one of the internal ports?

Sorry, there was a typo in my initial regarding nics.

[Josh26]

Hi,

I would be more concerned that if someone pumped a lot of traffic to a DMZ host, they could impact the datastore due to the shared NICs.

[cyclooctane]

In reply to Josh26

If your internet link and or firewall allows enough traffic to the ESX host to impact the disk preformance, then you need to have a good look at the mesures that you are taking to avoid DOS attacks.

At work I run the disk and access layer traffic on 2 different NIC groups anyway.

So that even if the traffic comes from internally there is no problem.

Regards

Cyclooctane

[cyclooctane]

In reply to SLCSam

If one of the DMZ ports is compromised it is not possible to access the internal network ports using only the ESX host.

They are 2 independent layer 2 networks and ESX can not route between them.

Regards

Cyclooctane