VMWare - configured in DMZ and protected network

Firstly, i'm fairly new to VMWare so apology's if this is a dumb question.

We have a couple of new boxes that will be carved up into VM's, some of these VM's will need to sit in the DMZ and others in the protected network.

I'm thinking of having one machine operating on both networks, setting up 2 virtual switches within the box, one for DMZ and the other for the protected NW, assigning them to unique NIC's then assigning the VM's to their respective virtual switches. Naturally, the management shit would be in the protected network etc

A guy here who's had experience in VMWare says it's against best practice to do this, but i'm not convinced. On the surface, it would seem he'd be right but I suspect that's a bit of old school thinking.

Whats the current thinking out there from a network admin and security admin POV?

 

I use multiple networks on VMWare vSphere.

It works nicely. You'd just have to ensure your vCenter/Host security is locked down so that people can't change the network that the individual guest is bound to - this may or may not be feasible within your security/access model however.

(I'm not even sure if you can lock down that specific feature).

 

It does work and a lot of places run such a setup; personally I'm OK with it. It doesn't mean your friend is wrong - a dedicated VM host that sits only in the DMZ is still more secure and probably still best practice. I've read papers on VMs being able to access network traffic meant for other VMs (in a separate VLAN). I'm not sure if having separate physical NICs for each VLAN mitigated this though.

 

why do you need to have the admin interface in the lan and the machine in the DMZ? can't you admin it via the vClient ?

 

depends how many hosts you have / how many ESX processor licenses you have and whether you want HA or not, it all comes back to how much your security is worth and or if you should be doing virtualisation in the DMZ

how secure is the VMWare host/guest separation layer, probably more secure than firewalls that don't do DPI/IPS, I know what my attack vector would be.

for the OP: http://www.vmware.com/resources/techresources/10109

 

I overlap my DMZ into my production environment and I have hardened my ESX environment, I have also hardened my DMZ environment and would consider it safer than my corporate LAN/WAN

 

was accepted prior to being deployed.

 

Thanks for the replies guys. I read the VMWare SHG provided in Doc-of-FC's link and it certainly looks secure enough.

Also, a bit of reading around on the net and I can find people who say it's acceptable and visa versa - just like here

Certainly, best practice say not to do this sort of thing in an uncontrolled manner, but it's obviously been done out there and it's obviously not uncontrolled so what really is best practice when it comes to this?

Seems something like this is doable -
http://www.networkworld.com/community/node/39307
I'd be looking at the second scenario.

Best practice I guess is to do an RA as IACSecurity suggested, then pass the findings off to someone higher up the chain who will read and accept without knowing the real issues and your arse is protected

 

The "best practice" approach is not to do it. Security best practices denote to have physical separation at all layers. Obviously money, skill levels, liabilities and requirements denote implementation.

In past lives we'll always maintained complete separation including fireproof walls within the data centers. Incidentally I'm in the middle of an identical argument with my fellow UNIX team where a subset of resources and there cowboy pasts find it hard to fathom such segregation. I'm willing to accept System and IO board separation within the same chassis (not ideal, but $1m M9's aren't super easy to procure) but the gloves came off when they tried to push Solaris Zones with dedicated NIC's assigned to local zones from the Global.

 

Though you guys might like to know, spoke with a VMWare expert on this, he said it's definitely best practice within VMWare from both a security and VMWare POV. In fact he recommends to do this in order to simplify a VM environment.

This guy is responsible for many of the larger VMWare installation's in Perth, including financial institutions whom have no issue with it, one exception he mentioned was Westpac who wanted physical seperation.

Basically, the trick is to create 2 x vSwitches, one for enterprise and one for the DMZ then allocated physical nics to each vSwitch.

 

It's definitely not security best practice. It's nice to hear Westpac have a decent InfoSec team.

I think everyone understands 'the trick'. The security concepts it violates is based on theory not implementation. Even if the vSwitches are split over separate physical NIC's (and separate IO Boards) it would still be valid to object to the configuration due to that fact that the NIC seperate is irrelavent once the OS is compromised.

 

You mean hypervisor.

Guest OS's can fall.

 

Having suffered the ills of VMWare for two years now, I advise anyone to tread carefully, particularly when given advice by "VMWare Experts". Much like Microsoft MVPs, their goal is to sell VMWare (either directly or indirectly, as it still lines their pockets either way). And you will be told VMWare can solve all your problems no matter what.

For the record we run VMWare in a DMZ configuration, and neither myself nor our security team are happy with it. Ultimately it was a business decision that trumped both security and sysadmins, but I'll be honest when I say it keeps me up at night. The continual stream of AusCERT alerts piling into my inbox every day and limited windows to perform patching on public facing kit does not make for an ulcer-free existence.

Amen to that.

 

Can you point me to something that says this in concrete? Given this guys credentials and experience (15 odd years with IT in financial/stock broking industry), i'm inclined to accept what he says at the moment.

The feeling i'm getting is the thinking behind physical security is a legacy and akin to the old saying 'you won't get fired if you buy IBM'.

I'll try and get further information, including any evidence of breaches in this kind of setup.

 

http://www.google.com/search?q=vmware+DMZ+best+practice+guide

try the first link.

look at it this way, you don't see the water utility saying you shouldn't drink tap water.... why? it reduces their sales.
the same reason you won't see VMWare say, don't overlap production and DMZ

 

damn straight - there are products geared towards providing security for hypervisors....how effective? hmm

http://www2.catbird.com/
http://www.hytrust.com/

personally i still think its premature to virtualize in the dmz given all the "unknowns" around hypervisor security, but there are good guides provided by certain foreign defence orgs that are unclass'd which can help you with best practice around virtualization full stop.

 

Thanks for all the discussions and links guys, it's been extremely helpful.

The guy i'm speaking to doesn't sell any products, he's an independent consultant, contracted in by the likes of Dell and HP after the sale.

IAC, VMWares best practice doesn't actually list the configurations in order of preference, they are simply 3 options that are best practice within the VMWare sphere.
I think it's clear that misconfiguration is the major culprit in security breaches, regardless of weather it's physically or virtually separated, but in the virtual environment, it's easy to screw up.

I hear what your saying and appreciate your pov, especially given your credentials mate, but i'm still not convinced as I havn't seen anything that has provided proven breeches of security, only theory and i'm not sure that theory is based on real knowledge of the workings within VMWare.

When it comes down to it, even firewalls are just software within a metal box, some based on Linux which is exactly the same as VMWare and they ultimately straddle networks so is there much difference, am I missing something?

 

You're missing a lot. Luckily for us I don't think anyone here has the patience to continue and try to teach you otherwise. Feel free to directly connect your vSwitch to your outside nets. We honestly don't care.

Just remember to bookmark this thread so in six years time you can come back to it and remind yourself how much you've learned over the years.

 

physical seperation is best practice. but that doesnt meant that what you want to setup will get hacked or comprimised as soon as its up infact the chances are it will never be comprimised.

Ive setup plenty of esx enviroments with similar requirements and it generally comes down to cost vs risk.

keep the service console on a seperate vswitch and physical netowrk to the dmz make sure permissions are locked down so people dont go changing vnics or networks and i dont really see an issue.

You should also check out vshield which is a newish product from vmware suited for this very issue, its is basically a firewall appliance that sits between the physical nic and the vswitch and works pretty well from the playing around ive done.

 

This is an important point.

I get these arguments all the time: "If it was insecure, we'd read about it". In the US, financial and public institutions are required by law to disclose public data loss. Outside of that, nobody has to say anything.

Security breeches are embarrassing. They are bad publicity, and in the most extreme case lead to lost customers and profits. If given the choice, companies will rarely disclose security breeches - that goes for both end users and vendors.

The best way to hear about real security issues is to talk to people on the ground. I'm sure there's a dozen or more people on these forums who've witnessed some scary security incidents (myself included). But chances are we're not going to tell you the worst of them on a public forum (nor without a few beers under our belts). Any way you slice it, you're not going to read the really scary stuff on ZDNet.