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…
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 DMZ
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.
Read the rest of the story here: http://blog.algosec.com/2013/10/ideal-network-security-perimeter-design-part-3-examining-dmz-continued.html
This prevents allowing complete control over these systems at any given time. godaddy coupons
ReplyDelete