Die Berichtsdatenbank schützen

Einführung

Eine Berichtsanwendung liest synthetische Shopbestellungen aus einer weiteren PostgreSQL-Datenbank. External Probe erreicht diese Datenbank ebenfalls. Während du diesen unerwünschten Verbindungsweg schließt, muss die Berichtsseite verfügbar bleiben.

Diese Challenge beginnt in einer unabhängigen Umgebung. Übertrage Verbindungstests, Routenprüfung und geordnete Gatewayregeln aus dem Guided Lab auf einen anderen Adressplan und Datenbankport.

Die Berichtsdatenbank schützen

Aktuelle Situation

Öffne Order Page für Bestellungen, Netzplan und aktuelle Verbindungsbeobachtungen. Report Client ist der legitime Anwendungsknoten; External Probe steht für einen unerwünschten Client. Gateway kontrolliert deren weitergeleiteten Verkehr. Die Container haben getrennte Netzwerk-Namensräume und teilen den Kernel einer Instanz.

Umfang

Ändere nur die laufende Gatewaykette LAB_FORWARD. Routen, Adressen, Zugangsdaten, Datenbankkonfiguration, Anwendungscode und Dienste bleiben unverändert. Die übergeordnete Kette FORWARD ist bereits verbunden und sperrt nicht zugeordneten Verkehr. Regeln müssen diese Sitzung überstehen; Neustartpersistenz gehört nicht zur Aufgabe.

Quelle	Ziel	Gefordertes Ergebnis
Report Client `172.29.10.40`	Datenbank `172.29.20.15:5544`	Echte PostgreSQL-Abfragen erlauben
External Probe `172.29.10.50`	Datenbank `172.29.20.15:5544`	Neue TCP-Verbindungen sperren
Beide Clients	Öffentlicher Status `172.29.20.15:8001`	Erlauben

Der nächste Hop der Clients ist 172.29.10.254; die Datenbank antwortet über 172.29.20.254. Die festen Verbindungsdaten sind Benutzer shopapp, Passwort training-only, Datenbank shop, Tabelle orders mit Spalten id und item. tcp-probe ADDRESS PORT, ip route get ADDRESS, psql und curl funktionieren wie gelernt. Die Anwendung nutzt dieselben Zugangsdaten.

Regelreferenz: -A hängt an, -s prüft Quelle, -d Ziel, -p tcp Protokoll, --dport Zielport und -j wählt die Aktion. -F CHAIN leert nur diese Kette; -nvL CHAIN zeigt numerische Regeln und Zähler. Antworten benötigen Verbindungsverfolgung. Eine breite Sperre vor einer engen Ausnahme gewinnt.

Dein Ziel

Die Berichtsdatenbank akzeptiert den legitimen Client und verweigert neue TCP-Verbindungen von External Probe. Berichtsseite und öffentlicher Status bleiben funktionsfähig. Datenbank und Zugangsdaten bleiben unverändert.

Erfolgskriterien

Report Client liest echte Zeilen über PostgreSQL auf 5544 mit den festen Zugangsdaten.
External Probe kann keine neue TCP-Verbindung zu diesem Port herstellen.
External Probe erhält weiterhin PUBLIC STATUS OK von 8001; die Berichtsbestellungen laden weiterhin.
Die Bestellung practice-2 mit Artikel Green tea existiert und wurde nach der Änderung über Order Page erstellt. Bericht und Screenshot sind nicht erforderlich.

Hinweise

Welche Quelle gehört in die Ausnahme?

Nutze den Client, der die Datenbankverbindung tatsächlich öffnet, nicht die Browser- oder Gatewayadresse. Netzplan und ip route get zeigen diese Quelle.

Warum ist legitimer Verkehr ausgefallen?

Vergleiche die erste passende Regel, ihren Zielport und die Antwortbehandlung. Der Datenbankport unterscheidet sich vom Guided Lab. Bei Tippfehlern kannst du die Laborkette neu aufbauen.

Beweist ein Authentifizierungsfehler die Absicherung?

Eine Passwortablehnung bedeutet, dass PostgreSQL erreichbar war. Prüfe den verbotenen Weg mit TCP und den erlaubten mit einer echten Abfrage. Teste den öffentlichen Status separat.

Zusammenfassung

Du hast Gatewayfilter auf neue Clients und einen anderen Port übertragen und dabei datenbankgestützte Berichte und öffentlichen Status erhalten. Funktionale Erlaubt/Gesperrt-Tests beweisen das Ergebnis; ein offenes Gateway, eine gestoppte Datenbank oder ein falsches Passwort tun dies nicht.