Securing the Server Zone

In modern enterprise data centers, servers are never lumped together into a single flat broadcast domain. Public-facing web portals must interact with untrusted internet visitors every second of the day. If a hacker exploits a software vulnerability in that public web application, you cannot allow that attacker to freely pivot across the local switch into the company database containing employee payroll records or customer credit card details.

To prevent lateral attacker movement, network architects partition server environments into distinct security zones: a Demilitarized Zone (DMZ) for public-facing servers, and an Internal Server Farm for backend database repositories. In this chapter, you will build segmented access control policies that enforce strict one-way communication channels between zones.

Multi-Tier Architecture and the Principle of Least Privilege

The golden standard for enterprise web application security is the multi-tier design. In this model, external users communicate exclusively with front-end web presentation servers located in the DMZ. The front-end servers, in turn, query back-end database servers over a dedicated, highly restricted internal link.

This design enforces the Principle of Least Privilege: every device and user must possess only the bare minimum permissions necessary to perform their legitimate job function, and absolutely nothing more.

• External internet users may only connect to DMZ Web Servers on TCP port 80 and TCP port 443. All other ports (such as Telnet, SMB, or database queries) are denied.
• DMZ Web Servers may connect to Internal Database Servers exclusively on the specific database listening port (such as MySQL port 3306 or PostgreSQL port 5432). DMZ servers cannot initiate connections back to internal office workstations.
• Internal office workstations may access internal servers for administrative tasks, but cannot directly touch the raw database tables over the public internet link.

Constructing the Zone Access Lists

To defend this multi-tier architecture, the firewall or perimeter router maintains separate access lists on each interface. On the interface connecting to the DMZ web servers, the router applies an ACL that permits web traffic from anywhere, while strictly dropping all connection requests targeting internal subnets.

On the interface connecting to the internal database farm, an extended ACL is bound outbound:

# Permit DMZ web server to query MySQL database
Router(config)# access-list 120 permit tcp host 172.16.1.10 host 172.16.2.50 eq 3306

# Permit internal IT administrator to manage database via SSH
Router(config)# access-list 120 permit tcp host 192.168.10.25 host 172.16.2.50 eq 22

# Explicitly deny all other traffic (supplementing implicit deny)
Router(config)# access-list 120 deny ip any any

With this configuration active, even if an attacker completely compromises the web server at 172.16.1.10, they cannot scan internal employee laptops or launch an SSH brute force attack against the database server. The perimeter router drops every unauthorized packet before it ever reaches the database network segment.

Hands-On Lab Practice

In this lab exercise, you will audit a three-tier network consisting of an external client, a DMZ web server, and an internal database server separated by a central security router. You will verify that the external client can reach the web server, verify that the web server can reach the database server, and confirm that the external client is strictly blocked from making direct connections to the backend database.

Review the router configuration and simulation log outputs to verify how zone-based perimeter filtering protects sensitive corporate data assets.