Protect the Reporting Database

Introduction

A reporting application reads synthetic shop orders from another PostgreSQL database. An External Probe currently reaches that database too. The reporting page must remain available while you close this unintended connection path.

This challenge starts in an independent environment. Apply the connection probes, route inspection and ordered Gateway rules practiced in the guided lab to a different address map and database port.

Protect the Reporting Database

Current Situation

Open Order Page to see the reporting application's orders, network map and live connection observations. Report Client is the legitimate application node; External Probe represents an unintended client. Gateway controls their forwarded traffic. These are separate container network namespaces sharing the instance kernel.

Scope

Change only the running Gateway's LAB_FORWARD chain. Do not change routes, addresses, credentials, database settings, application code or services. The parent FORWARD chain is already connected and denies unmatched traffic. Rules need to last for this lab session; reboot persistence is outside scope.

Source	Destination	Required result
Report Client `172.29.10.40`	Database `172.29.20.15:5544`	Allow real PostgreSQL reads
External Probe `172.29.10.50`	Database `172.29.20.15:5544`	Block new TCP connections
Both clients	Public status `172.29.20.15:8001`	Allow

The clients' next hop is 172.29.10.254; the database returns through 172.29.20.254. The fixed database connection facts are user shopapp, password training-only, database shop, and table orders with columns id and item. tcp-probe ADDRESS PORT, ip route get ADDRESS, psql and curl work as taught. The report application uses the same database credential.

Rule-field reference: -A appends, -s matches source, -d destination, -p tcp protocol, --dport destination port, -j selects the action. -F CHAIN clears only that chain; -nvL CHAIN lists numeric rules and counters. Replies need connection tracking. A broad deny before a narrow allow wins.

Your Goal

The reporting database must accept the legitimate client and refuse new External Probe TCP connections while the reporting page and public status service remain functional. The database and its credential must remain unchanged.

Acceptance Criteria

Report Client reads actual rows through PostgreSQL on port 5544 using the fixed credential.
External Probe cannot establish a new TCP connection to that port.
External Probe still receives PUBLIC STATUS OK from port 8001; reporting orders still load.
The order practice-2 exists with item Green tea, created through Order Page after your change. No report or screenshot is required.

Hints

Which source belongs in the exception?

Use the client that actually opens the database connection, not the browser's address or Gateway's address. The map and ip route get identify this source.

Why did legitimate traffic stop?

Compare the first matching rule, its destination port and reply handling. The database port differs from the guided lab. You can rebuild the lab-owned chain after a typo.

Does an authentication error prove containment?

A password rejection means PostgreSQL was reachable. Use the TCP probe for the prohibited path and a real query for the permitted one. Test public status separately.

Summary

You transferred gateway filtering to a new client and port, preserving database-backed reporting and public status. Functional allow/deny tests establish the result; an unchanged permissive gateway, a stopped database or an invalid password does not.