External network (DMZ) setup in a Microsoft-heavy environment

I deal with a lot of environments which run all of or almost all of the Microsoft product suite. When it comes to external functionality, life can be made much harder by the configuration of the external network segments. This article was borne because one of the clients we are currently working with just has a whacky external network setup – which is holding up the Exchange, Lync and TMG projects. I am, as regular readers will know, not a security expert by any stretch, but I believe I have a good understanding of the trade-off between functionality, administration and security – especially for smaller organisations.

 So when it comes to the external network segment, there’s a couple of things to consider – and sometimes parts of these seem to be forgotten:

 Functionality:                     some MS products require public IP’s in order to have full functionality, additionally, other MS products need to be a member of a domain in order to have full functionality                               

Administration:                The KISS (keep it simple stupid) principle applies here as it does in everywhere else in IT and life. There are plenty of people that like to make their environments complex under the guise of security, when really all it does    is weaken security because it’s too complex to admin properly. (or keep them in work)

Security:                             Obviously a big one – what seems to be forgotten sometimes is that the level of security required for an organisation with 500 users that produces some boring product with no enemies is vastly different to the requirements for a defence organisation or a nation (or world) wide organisation with a poor public image (such as Telstra or Microsoft!)

And a few Microsoft specific articles that are useful for this discussion:

TMG workgroup vs domain considerations         http://technet.microsoft.com/en-us/library/cc995141.aspx

ISA/TMG: should it be a domain member             http://www.isaserver.org/tutorials/debunking-myth-that-isa-firewall-should-not-domain-member.html

AD and NAT:                                                                http://support.microsoft.com/kb/978772

 The most common external network we run into when implemented by cisco-focused consultancies is as follows:

•         Cisco ASA at the edge
•         Public IP’s only allocated to the external interface of the ASA
•         A NAT’ted IP range to the external interfaces of the DMZ servers
•         TMG and/or UAG located in the DMZ as workgroup members (because its more secure apparently)
•         An IP range on the “internal” interfaces of the DMZ server
•         All traffic to/from the DMZ to either the internal network or the public internet goes via the ASA

 The following diagram represents this network setup (There is only one physical ASA, but the traffic may pass through it multiple times):

 

 My main issues with this setup are:

• In order to access internal resources (such as OWA) – clients are passing through firewalls 3 times. The ASA from the outside world to the DMZ, the TMG or UAG server and then the ASA again between the DMZ and internal network.  It’s simply overkill. I know… “what if the DMZ server is owned by an attacker? That’s why we make it pass through the ASA again!”. Use google – and go find me a single example of ISA 2006 or TMG 2010 ever being owned, anywhere, ever. Whether the Cisco zealots like it or not – ForeFront TMG 2010 is a secure and stable firewall and publishing mechanism
• Having NAT’ted IP’s only available reduces functionality of products such as Lync and increases administrative complexity
• Lack of domain membership is workable – but not preferable from an administration point of view

 So – what other options are there? Well, here’s my preferences….

 A small business setup

• ForeFront TMG at the edge
• Public IP’s allocated to the external interface of the TMG, UAG, Lync Edge as required
• Forefront TMG and/or UAG reverse publishes internal resources
• All traffic from the internet hits TMG/UAG/Lync directly and these servers communicate with the internal network directly

 

 

Why I like this:

• It’s very simple and administration is simple
• All servers can have public IPs, so there no is reduction in functionality
• All servers can be domain members if required
• Reverse publishing of services is simple

 The downsides:

• You must keep your patching up to date on these servers (it bugs me that I need to mention this, but so many people don’t patch their servers regularly for some reason which I’ll never understand)
• It’s a single point of entry into your network, which, if it goes down, you’re in trouble. This, IMO, is mitigated by
  • Forefront TMG clustering
  • Forefront TMG/Windows 2008 R2 just do not crash unless you do something down-right fucking stupid to them. (MS products seem commonly to get the blame when people do dumb things with them)

 

For a slightly larger organisations:

• Cisco ASA/Checkpoint etc at the edge
• Routed public IP range into the DMZ
• No additional firewall through to the internal network
• Traffic from the internet hits the ASA and is routed/port filtered to the external interfaces of the TMG/UAG/Lync servers. These servers communicate with the internal network directly.

 

This is probably my favourite config for a small to mid-size organisation – it’s got a few more options than just TMG, but still doesn’t kill functionality.

Why I like this:

• It’s very simple and administration is simple
• All servers can have public IPs, so there is no reduction in functionality
• All server can be domain members if required
• Reverse publishing of services is simple
• The ASA/Checkpoint/Whatever is at the front end routes public IP’s through to the TMG/UAG environment but also port filters, so only 80/443 (or whatever is required) is allowed through. This simply means that an admin has to do something very stupid (a minimum of) twice, to two different devices in order to expose your network.

And for the larger orgs:

• Cisco ASA/Checkpoint etc at the edge
• Routed public IP range into the DMZ
• Cisco ASA/Checkpoint as the internal firewall
• Traffic from the internet hits the ASA and is routed/port filtered to the external interfaces of the TMG/UAG/Lync servers. These servers communicate with the internal network via a 2^nd ASA which routes and port filters traffic

 

Why I like this:

• It’s got a greater level of security but is still relatively simple thanks to the lack of NAT
• All servers can have public IPs, so there is no reduction in functionality
• All servers can be domain members if required
• Reverse publishing of services is simple
• The ASA/Checkpoint/Whatever is at the front end routes public IP’s through to the TMG/UAG environment but also port filters, so only 80/443 (or whatever is required) is allowed through
• The back ASA/Checkpoint allow services from the TMG/UAG internal DMZ interfaces into the internal network

 

So the guts of it is

1)      Don’t use NAT on your cisco/checkpoint/whatever devices. NAT not only increases complexity, some services do not support it – more to the point, the TMG server is performing this where necessary and NAT itself is not a security mechanism, stateful inspection firewalls are.

2)      TMG is a full-featured firewall, don’t let Cisco/Checkpoint or other security people tell you otherwise

3)      TMG/UAG should be a domain member by default – and there needs to be a good reason why it shouldn’t be…. Not the other way around

4)      When you reverse publish a web application via TMG, the SSL connection can be terminated at the TMG and have authentication and other checking performed on it here – before it even enters the internal network – this is a far far (far far far – yes a lot) more secure and elegant solution that port forwarding via an ASA to a server in the DMZ. This is why TMG/UAG redefine not only how you publish your applications, but whether or not a “true” DMZ is needed at all anymore (again, in context, this is talking about smaller and mid-size orgs)

Remember – this isn’t intended for everyone, but it’s just a few suggestions as how those of you out there running environments that have non-defence level security requirements can set up your publishing environment so it’s easy to admin, flexible and just plain simple. And for those of you that still think that complex = secure, you’ll never be out of work, but only because of management stupidity.