| ||
As stated in the introduction to this chapter, the concept of a DMZ is just too limited with respect to securing critical systems. Simply deploying hardened systems in a traditional DMZ outside the firewall doesn't give you much depth in security. In this chapter, we cover the following components related to securing any type of DMZ system, building on what we covered in earlier chapters:
Defining "security zones" throughout your entire network infrastructure
Allowing strict border router access control lists (ACLs)
Hardening the operating system of DMZ hosts
Providing secure authentication and authorization mechanisms to access DMZ systems
Ensuring strict trust relationships between DMZ systems and both internal and external systems
Extending specific segments of your network through VPN mechanisms
What is a "security zone"? If you think of the DMZ as a moat between two perimeter walls, this may be one of your zones. Additionally, your border router may be considered another zone, and your firewall may be considered a zone. When taken as a whole, the area from your border router, through the DMZ and firewall, to an internal system may be another zone. We can't define security zones for you, because defining a zone is dependent upon each organization's networks, systems, and security policies. However, you should think in terms of the end-to-end "zone" that encompasses securing critical systems, as well as smaller zones that encompass the whole. For example, if you deploy a system in a traditional DMZ (on the LAN between a border router and firewall), the security zone for that system might consist of the following components:
Border router access control lists
Layer 2 infrastructure connecting border router, DMZ, and firewall
DMZ system (hardening the operating system, securing local data, securing authorization and authentication)
Firewall access control lists, permitting/ denying specific protocols/ports between the DMZ system and internal systems (trust relationships)
These zones are depicted by the shaded area of the network diagram in Figure 6-3. In addition, the firewall may be a subzone since it forms the perimeter between your internal network and all external networks.
Alternatively, let us assume that the DMZ system has localized authentication/authorization data and a database accessed by customers. The system never contacts backend systems within your internal network, and you manage the system from the console only. The security zone is now smaller, as depicted in Figure 6-4.
We could give many more examples, but they may or may not be relevant to your particular infrastructure. We simply want you to start thinking about all network "pieces" associated with securing a critical system. Then define your security zone once you have identified the following components related to the system you're securing from end to end:
All network elements
All protocols and services accessed
External access policies (what is allowed between the Internet and DMZ system)
Internal access policies
Will the DMZ system be managed from internal systems?
Will the DMZ system access data stores on the internal network?
Who needs access, when do they need access, and what level of access do they need (read-only, modify, super- user )?
| ||