Somewhat OT: DirectAccess choices

  • Last Post 07 March 2016
kurtbuff posted this 04 March 2016


I'm not sure where to ask this question, but I have to believe that
some of you here have some experience and opinions with DirectAccess,
so will ask here first, while I'm doing my STFW work.

Please feel free to direct me elsewhere if you know somewhere better.

Does anyone have thoughts or concrete (referenceable?) recommendations
on placement for a DA server?

We currently are using UAG 2010 SP1 for DirectAccess (and only for DA,
nothing else).

We're looking to move to DirectAccess on 2012R2. One of the major
design goals is to enable "manage out". I'll be doing a parallel
install, and migrating current users to the new facility.

We have a choice to make regarding placement of the new DA server - I
know my preference, but I'm getting pushed to implement in a way I'm
not comfortable with.

The way we have it now: one NIC exterior, one NIC interior on its own
VLAN - basically it straddles the perimeter, and bypasses our
firewall. AFAICT, it was the best way to implement it at the time.

With DA 2012R2, I can do that, or I can do a 2 NIC setup behind the
firewall or I can do a single NIC behind the firewall. I'm not too
concerned about that part of it.

What I'm unhappy about is being pushed to put the DA server on the
same VMware cluster as the rest of our production servers. It seems
like a fairly major sin to mix security domains like that. I don't
care that it would have its own VLAN, etc. - it just seems wrong to be
mixing a security device that's supposed to be at the perimeter in
with the soft gooey production servers.

Forum info:
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx

Order By: Standard | Newest | Votes
gkirkpatrick posted this 04 March 2016

Not really my area of expertise, but a rough threat analysis would seem to come down to two questions: How much do you trust VMWare to provide isolation between virtual networks and virtual machines, and how much do you trust your VMWare administrators?

There have been several hypervisor vulnerabilities over the years. Reaching into your squishy bits would require an attacker to exploit vulnerabilities in the guest OS as well as the hypervisor. Not impossible, but seems pretty unlikely.

I'd be more concerned about your VMWare admins and their standards of practice.



kurtbuff posted this 04 March 2016

There are three of us on the infrastructure team - we handle all of
VMware, AD, PKI, servers, routers, switches, firewalls, etc. - and
it's not in my nature to trust anyone on the team (including myself).

It's not that we aren't competent, but mistakes happen, and attacks
never get harder, only easier.



ken posted this 05 March 2016

Do you have separate storage for your DMZ? If not, you're already running risks of having data or a VM presented to the wrong security zone. How are you handling that today?


kurtbuff posted this 05 March 2016

Yes, separate environment for the DMZ - separated from production by
our firewall. We're actually running multiple HyperV hosts in the DMZ.


ken posted this 07 March 2016

Firewall would be Layer 3 - you are running your storage over layer 3 aka iSCSI or something? Or you're using local storage, so the FW doesn't come into the picture?

FWIW we have strict separation between DMZ and internal zones, but no general compute DMZ (it's all appliances - proxies, hygiene appliances, VPN gateways etc.) The storage is generally all SAN or NAS, but physically separate SAN/NAS from internal zones. That way, even though we have FC etc. for storage, DMZ data storage runs over separate fabrics and networks to internal. If you're not doing that today, you already run risks - how are you managing those? Can they be reused to manage the risk of shared hosts?

I assumed you were running ESX, but if you are running Hyper-V, then perhaps wait for Win 2016 which has some SDN capabilities apparently. Not sure they're going to match NSX, but if they do, that might provide a bit more comfort that simple VLAN separation.



danj posted this 07 March 2016

When I was looking at doing a vmware consolidation exercise for a government client a couple of years back I checked the CESG guidance (UK government IT security department), there is a doc somewhere on their site (for some reason only for version 4.x but you get the picture):

Mixing security domains on the same vmware cluster had recently been approved for lower rated environments (which would definitely be comparable to most commercial environments). They describe it in terms of 'red' and 'black' servers for data classification but the security team at that client was happy that this also applied to security zones.



kurtbuff posted this 07 March 2016

On Mon, Mar 7, 2016 at 2:39 AM, Ken Schaefer wrote:


kurtbuff posted this 07 March 2016


I shall take a look at that site when I get back to work - I'm home
with a fever and cough today, and will be spending the day in bed.