Data Center Tiers: Web, App, Database

The scenario

Client (10.0.1.10) is outside. FW-Front guards the web tier (10.0.2.0/24), FW-Mid guards the app tier (10.0.3.0/24), and FW-Back guards the database tier (10.0.4.0/24). Each firewall allows only the service the tier behind it offers: FW-Front allows TCP 80 and 443 from anywhere to Web Server (10.0.2.10); FW-Mid allows TCP 8080 from Web Server to App Server (10.0.3.10); FW-Back allows TCP 5432 (PostgreSQL) from App Server to Database (10.0.4.10). Each firewall also allows ping into its own tier from the network just before it: from anywhere into the web tier, from the web tier into the app tier, and from the app tier into the database tier. Routing is static, and the firewalls and servers have routes towards the deeper tiers, so every connection this lab shows being stopped is stopped by a firewall rule, not by a missing route.

What you will work out

Learn network segmentation with firewalls between web, app and database tiers, and how routes and least-privilege rules work together.

Why this matters

Separating web, application and data tiers with firewalls is a long-standing design for anything that holds sensitive data. PCI DSS, for example, requires network security controls between the systems that handle card data and untrusted networks, and segmentation is the usual way to keep the rest of the network out of scope. On AWS the same design is usually built with public and private subnets, route tables and security groups that allow traffic from the tier in front, rather than dedicated firewalls between every tier.

Running it

Data Center Tiers: Web, App, Database opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.