The scenario
Attacker (10.0.1.99) is on the internet side of DMZ-FW. Behind DMZ-FW is the DMZ (10.0.2.0/24), where Web-Server (10.0.2.10) serves HTTP and also runs SSH. DB-FW (10.0.2.50) connects the DMZ to the database network, where Database (10.0.3.10) runs PostgreSQL on 5432 and also SSH. Web-Server's application talks to Database on 5432 through DB-FW. The logs show SSH sessions on Database. The cause is one rule on each firewall: DMZ-FW allows TCP 22 to anywhere (priority 15), and DB-FW allows TCP 22 from anywhere (priority 15). Together they let Attacker SSH straight to Web-Server and straight to Database, and they let anyone already on Web-Server SSH on to Database.
What you will work out
Practise incident investigation: trace the attack path, identify which rule on which firewall allowed each step, remediate, and prove the fix with traces.
Why this matters
Many breaches start with a rule that was more permissive than anyone intended: a port opened 'temporarily', or a rule written without a source or destination. Incident response follows the same loop you just did: trace what an attacker could reach, find the rule that allowed each step, remove it at every layer, and prove that the legitimate traffic still flows. A good follow-up here would be to narrow DB-FW's PostgreSQL rule to Web-Server's address, so the database network no longer depends on DMZ-FW alone to keep port 5432 private.
Running it
Incident Response: Database Breach 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.
Open Incident Response: Database Breach
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →