The Ideal Network Security Perimeter Design: Part 3 – Examining the DMZ (Cont.)

Following our last blog on creating and securing the DMZ, we will take a look at how to safeguard the DMZ from within. But first, let’s quickly recap our journey throughout this “Ideal Network Security Perimeter Design” series…

Part 1 – How to harden the perimeter and understand what outsiders can see

Part 2 – What layers make up a sound network security perimeter design and how to enable access for authorized personnel

Part 3 – How to create the DMZ

Ok, now let’s dig into how to layer security within the DMZ. Sometimes people are sure to lock down the DMZ from an external perspective, but forget to put that level of security on access to the DMZ from an internal perspective. Of course you’ll have to access, manage and monitor these systems too, but you’ll do so in a slightly different manner than you would with systems living on your internal LAN. Access to the DMZ from an internal perspective should be locked down as tightly as possible. These are systems that can potentially be holding sensitive data or have access to other systems that have sensitive data. If a DMZ server is compromised and the internal LAN is wide open, attackers suddenly have a way into your network.

Limiting Access to Systems within the Firewall DMZ Architecture Design

From an internal perspective we should limit who can access systems within the DMZ. Creating firewall rules to only allow the source IP addresses and port to the specific server is a start to security, but we should really go further than that with other filters. Creating proxies or jump points in the network from which administrators are allowed access the systems ensures stronger security. You can also place authentication on the LAN before access to the DMZ is even attempted. This prevents allowing complete control over these systems at any given time.

Authenticate

There should NEVER EVER be a domain controller sitting in a DMZ to assist with authentication to these systems. Any information that’s considered sensitive, especially internal data shouldn’t be stored in the DMZ or have DMZ systems relying on it. Authentication within the DMZ systems should be based off either a separate DMZ domain or local access to these systems. There are many issues with both of these, especially when it comes to large DMZs with hundreds of servers, but the ability to have authentication that’s easily changeable without the ability to rely on internal authentication is a must.

Segment within the DMZ

The creation and segmentation of systems within the DMZ also is also something to consider. We should never see a web server that’s also running a database server – a database server should never be in the DMZ. Here’s where we get into multi-tiered DMZs that have backend systems isolated from being hit externally, but yet the externally available systems rely on them for a service. A good example of this is a web server passing data to an application or database server. These should not all be in the “public DMZ” because it’s too risky to keep this data within that zone, but many times we don’t want them installed in the LAN either. This is more of a business decision, but the ability to have these servers accessed by both the DMZ and internally needs to be discussed. The data is too important to be in the DMZ and the placement of these systems needs to be considered carefully since the DMZ systems have access to them.

Configuring systems within different VLANs (with a layer 3 switch) will assist with isolating incidents if a server in a DMZ is compromised. By having all your DMZ systems on the same VLAN, without filtering at the switch level, will allow the incident to spread across multiple systems and applications. Being able to isolate a threat to a particular system or system type will make it easier for the incident response team to contain and eradicate the breach (I’m sure your public relations team will agree too, since once they’re brought into the picture it’s never a good sign.).

DMZ Network Security Best Practice

Having a DMZ is a necessary part of your security architecture. You need a way to have services displayed to the world, but yet at the same time secure from the rest of your network. Configuring a DMZ with proper access, both internally and externally, is also an essential configuration point of creating a successfully DMZ. Not only should we be concerned with security getting into the DMZ, but we should isolate systems and applications within the DMZ to assist with isolating a threat if it was to be compromised.