Einführung
Die Bestellanwendung von Corner Shop liest und erstellt Datensätze in einer privaten PostgreSQL-Datenbank. Die Seite funktioniert, doch auch Visitor erreicht die Datenbank direkt. Eine funktionierende Anwendung beweist daher keine sichere Netzwerkgrenze.
Du vergleichst echte Verbindungen, begrenzt die Weiterleitung auf Gateway und erhältst Bestellungen sowie einen öffentlichen Statusdienst. Grundlegende Terminalbedienung genügt. Personen und Datensätze sind synthetisch. Die drei Terminalknoten sind Container mit getrennten Netzwerk-Namensräumen und gemeinsamem Instanzkernel, keine eigenständigen VMs.
Eine Bestellung und ihren Netzwerkpfad verfolgen
In diesem Schritt erstellst du eine echte Bestellung und vergleichst zwei Datenbankpfade. Die Anwendung ist das kundenorientierte Programm, die Datenbank ihr Datenspeicher. Öffne Order Page, suche seed: Green tea, gib practice-1 unter Order reference ein und klicke Create tea order. Die neue Zeile wird in PostgreSQL gespeichert und nicht nur auf der Seite angezeigt.
Der Netzplan nennt die IP-Adresse jedes Knotens als Netzwerkziel. Ein Port bezeichnet einen Dienst an dieser Adresse. PostgreSQL lauscht auf 172.28.20.10:5432, der separate öffentliche Statusdienst auf 8001. App Client (172.28.10.20) benötigt die Datenbank. Visitor (172.28.10.30) benötigt nur den öffentlichen Status.
Wechsle zu App Client. Das vorbereitete tcp-probe öffnet eine echte TCP-Verbindung und wartet höchstens drei Sekunden. Die Argumente sind Zieladresse und Port:
tcp-probe 172.28.20.10 5432
Erwartet wird TCP OPEN. Das beweist Erreichbarkeit, keine Leseberechtigung. psql ist der PostgreSQL-Abfrageclient. Der Befehl stellt das Übungspasswort nur dieser Ausführung bereit. Die Verbindungskette in Anführungszeichen fasst Server, Port, Benutzer, Datenbank und drei Sekunden Verbindungszeitlimit zusammen. -c führt das SQL in Anführungszeichen aus; SELECT liest die benannten Spalten aus orders, ORDER BY sortiert sie. Das Semikolon beendet die SQL-Anweisung.
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Finde practice-1 und Green tea im Ergebnis. Die absichtlich bekannte Zugangsinformation bleibt unverändert, damit die Netzwerkänderung isoliert sichtbar wird.
Wechsle zu Visitor und wiederhole beide Befehle:
tcp-probe 172.28.20.10 5432
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Beide funktionieren: Der unerwünschte Client kann sich verbinden und synthetische Bestellungen lesen. Ein falsches Passwort ergäbe erst nach Erreichen von PostgreSQL einen Authentifizierungsfehler; der Port bliebe offen.
Eine Route bestimmt, wohin ein Knoten Pakete sendet. Prüfe die vorbereitete Route von Visitor zur Datenbank:
ip route get 172.28.20.10
Wichtig sind via 172.28.10.254 (Gateway) und src 172.28.10.30 (Visitor). App Client nutzt dasselbe Gateway mit anderer Quelle. Die Rückroute der Datenbank zeigt auf Gateways zweite Schnittstelle 172.28.20.254. Kein Client besitzt eine direkte Schnittstelle zum Datenbanknetz. Diese Routen sind vorbereitete Infrastruktur und bleiben unverändert. Die echte Bestellung ist der Kontrollpunkt; du gibst keinen Bericht ab.
Nur den Datenbankpfad der Anwendung erlauben
In diesem Schritt filterst du Pakete durch Gateway. Wechsle zu Gateway. iptables bearbeitet die Paketfilterregeln im Kernel. Eine Kette ist eine geordnete Liste: Die erste passende Entscheidung gilt. FORWARD verarbeitet durchgeleiteten Verkehr, INPUT den an den Knoten selbst gerichteten. Die Umgebung verbindet FORWARD mit der laboreigenen Kette LAB_FORWARD. Ihre anfängliche großzügige Regel verursacht die Offenlegung.
Sieh dir die Regeln an. -n behält numerische Adressen, -v zeigt Paketzähler, -L listet die Kette:
iptables -nvL LAB_FORWARD
Ändere nur LAB_FORWARD in diesem Terminal. Hostregeln, Routen, Zugangsdaten und Dienste bleiben bestehen. Regeln gelten sofort und für diese Labsitzung. Vier Entscheidungen ersetzen die offene Regel. Die vorbereitete übergeordnete Kette verwirft nicht zugeordnete Pakete.
-F leert die benannte Kette. Weitergeleitete Dienste sind beim Hinzufügen kurz blockiert; Terminal und Order Page bleiben erreichbar. Bei einem Tippfehler beginnst du erneut mit dem Leeren und gibst alle vier Regeln ein.
iptables -F LAB_FORWARD
Antworten müssen zurückkehren können. Eine Datenbankantwort geht beispielsweise an App Client; ihr Ziel ist daher nicht mehr der Datenbankport. -A hängt eine Regel an, -m conntrack nutzt Verbindungsverfolgung und --ctstate ESTABLISHED,RELATED erkennt Antworten oder zugehörigen Verkehr bereits erlaubter Verbindungen. -j ACCEPT erlaubt passende Pakete:
iptables -A LAB_FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Erlaube neue Anwendungsverbindungen. -s prüft die Quelle, -d das Ziel, -p tcp wählt TCP und --dport den Zielport. Eine einzelne Adresse meint genau diesen Knoten:
iptables -A LAB_FORWARD -s 172.28.10.20 -d 172.28.20.10 -p tcp --dport 5432 -j ACCEPT
Setze die allgemeine Datenbankablehnung hinter die Anwendungsausnahme. Ohne -s betrifft sie andere Quellen. REJECT --reject-with tcp-reset lehnt TCP ausdrücklich ab, statt still auf ein Zeitlimit zu warten:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 5432 -j REJECT --reject-with tcp-reset
Erhalte zuletzt den getrennten öffentlichen Statusport für beide Clients. Seine Freigabe öffnet nicht den Datenbankport:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 8001 -j ACCEPT
Liste das Ergebnis:
iptables -nvL LAB_FORWARD
Die Reihenfolge lautet: Antworten, Datenbankzugriff der Anwendung, allgemeine Datenbankablehnung, öffentlicher Status. Eine Ablehnung vor der Ausnahme würde auch den Shop blockieren. Zähler steigen nur, wenn passende Pakete Gateway tatsächlich durchqueren; die Regel allein ist kein Beweis. Aktualisiere Order Page: App Client zeigt OPEN, Visitor BLOCKED, der Status PUBLIC STATUS OK, und Bestellungen laden weiterhin.
Sicherheit und Shop erneut testen
In diesem Schritt prüfst du die Verbindungsmatrix und erstellst eine weitere echte Bestellung. Wechsle zu App Client und öffne eine neue Verbindung:
tcp-probe 172.28.20.10 5432
Erwartet wird TCP OPEN. Wiederhole die Abfrage mit denselben Zugangsdaten:
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Wechsle zu Visitor:
tcp-probe 172.28.20.10 5432
Erwartet werden TCP BLOCKED und ein Hinweis auf die abgelehnte Verbindung. Der Befehl liefert absichtlich einen Fehlerstatus. Stilles Verwerfen führt stattdessen zu einem Zeitlimit. Beides verhindert neue Verbindungen, doch ein Zeitlimit allein erklärt nicht die Ursache. Scheitert auch App Client, prüfe Reihenfolge und Antwortbehandlung auf Gateway.
curl ruft eine Webressource ab. --max-time 4 begrenzt die gesamte Anfrage auf vier Sekunden; -f wertet HTTP-Fehler als Fehlschlag, -s unterdrückt Fortschritt, -S zeigt weiterhin Fehler. Prüfe aus Visitor den anderen öffentlichen Dienst:
curl --max-time 4 -fsS http://172.28.20.10:8001/status.txt
Erwartet wird PUBLIC STATUS OK. Alle weitergeleiteten Pakete zu sperren würde diese Anforderung verletzen, auch wenn der Datenbankpfad dadurch geschlossen wäre.
Öffne Order Page, erstelle practice-2 und prüfe beide Übungsbestellungen. Damit nutzt du die echte Datenbankverbindung nach der Reparatur. Aktualisiere erneut: Visitor muss gesperrt bleiben. Gatewayzähler helfen bei Abweichungen; eine erfolgreiche Bestellung und echte Erlaubt/Gesperrt-Tests liefern den Beweis. Stoppe PostgreSQL nicht und ändere sein Passwort nicht, um eine fehlgeschlagene Besucherabfrage als Sicherheitslösung erscheinen zu lassen.
Zusammenfassung
Du hast eine Bestellung bis PostgreSQL verfolgt, zwei geroutete Clients verglichen, geordnete Weiterleitungsregeln angewendet und Sicherheit sowie Verfügbarkeit geprüft. Ein Passwortfehler unterscheidet sich von einer gesperrten TCP-Verbindung. Erhalte beim Schließen eines offenen Datenbankpfads die legitime Anwendung und andere Dienste.
