Einführung
Die Support-Website von Northstar stellt Hilfeseiten und freigegebene Downloads bereit. Ein ungewöhnlicher Archivdownload deutet darauf hin, dass ein internes Backup versehentlich zwischen öffentlichen Dateien gespeichert wurde. Du bist der Bereitschaftsingenieur mit Wartungszugriff auf die Website.
Du verfolgst die Anfrage, ordnest ihre URL einer Datei auf dem Webserver zu, verschiebst das Backup in einen privaten Speicherbereich und prüfst, ob die Support-Website weiter funktioniert. Grundkenntnisse im Terminal genügen; HTTP-Statuscodes und die Zuordnung zum Webroot werden hier erklärt. Alle Datensätze und der gesamte Datenverkehr sind synthetisch.
Den verdächtigen Download untersuchen
In diesem Schritt verfolgst du einen verdächtigen Download, rufst das Archiv ab und prüfst, ob es interne Daten enthält.
Deine Umgebung ist bereit. Workstation ist dein Client-Terminal und befindet sich bereits in /home/labex/project. Web Server ist ein Wartungsterminal, das bereits mit dem Website-Server verbunden ist. Wechsle nach Anweisung zwischen diesen Tabs. Topology zeigt ihre Beziehung und die aktuelle Erreichbarkeit der Website.
Öffne Topology, um Client und Server zuzuordnen, und kehre zu Workstation zurück. Der Status zeigt, ob die Startseite antwortet; er sagt nicht aus, ob private Dateien geschützt sind.
Den normalen Zugriff prüfen
Verwende Workstation. curl sendet eine HTTP-Anfrage und gibt die Antwort aus. -sS blendet den Fortschritt aus, zeigt aber Verbindungsfehler weiterhin an. Über 127.0.0.1:8081 ist die Website von Workstation aus erreichbar. 127.0.0.1 bezeichnet den lokalen Rechner: In Web Server verweist dieselbe Adresse auf den Server selbst und nicht auf Workstation.
curl -sS http://127.0.0.1:8081/
Die Antwort enthält Northstar Support sowie Links zur Hilfe und zum Produkthandbuch. Ein öffentliches Verzeichnis, auch Webroot genannt, ist das Dateisystemverzeichnis, dessen Inhalt der Server über URLs bereitstellt.
Das Produkthandbuch ist absichtlich öffentlich. Rufe es ab, bevor du etwas änderst:
curl -sS http://127.0.0.1:8081/downloads/product-guide.txt
Die erste Zeile lautet Northstar Product Guide. Auch der freigegebene Beispieldownload unter /downloads/public-examples.tar ist öffentlich und muss verfügbar bleiben, obwohl sein Name auf ein Archiv hinweist.
Den Download verfolgen
Wechsle zu Web Server. cat gibt eine Textdatei aus:
cat /var/log/nginx/site-access.log
Nginx ist der Webserver, der diese Anfragen verarbeitet. Jede Zeile des Zugriffsprotokolls enthält Client-Adresse, Zeitpunkt, Anfrage, Statuscode, Antwortgröße in Byte und User-Agent. GET fordert eine Ressource an; der User-Agent bezeichnet die anfragende Software. 200 bedeutet, dass der Server eine erfolgreiche Antwort zurückgegeben hat; 404 bedeutet, dass die angeforderte Ressource nicht gefunden wurde. Netzwerkweiterleitungen können die protokollierte Client-Adresse beeinflussen. Gehe deshalb nicht davon aus, dass sie eine bestimmte Person identifiziert. Einträge mit TopologyHealth/1.0 stammen von den eigenen Zustandsprüfungen der Umgebungsansicht.
Suche nach fehlgeschlagenen Anfragen wie /admin, gefolgt von einer erfolgreichen Anfrage für /backups/support-backup.tar. Mit grep kannst du das Protokoll eingrenzen: Es gibt Zeilen aus, die den angegebenen Text enthalten.
grep 'support-backup.tar' /var/log/nginx/site-access.log
Die passende Zeile sollte GET /backups/support-backup.tar und den Status 200 enthalten. Das deutet auf einen Download hin. Bevor du jedoch von offengelegten internen Daten ausgehst, musst du die Antwort prüfen. Die stabilen Felder der relevanten Zeile sehen beispielsweise so aus:
... "GET /backups/support-backup.tar HTTP/1.1" 200 10240 ... "ExternalClient/1.0"
Adresse und Zeitstempel variieren. Pfad, erfolgreiche Antwort und Archivinhalt sind die hilfreichen Hinweise.
Das offengelegte Backup bestätigen
Kehre zu Workstation zurück. -o schreibt die Antwort in die benannte Datei, statt sie auszugeben:
curl -sS -o /home/labex/project/support-backup.tar http://127.0.0.1:8081/backups/support-backup.tar
tar liest Archivdateien. -t listet die enthaltenen Dateien auf und -f wählt das Archiv aus:
tar -tf /home/labex/project/support-backup.tar
Du solltest internal-customers.txt sehen. -x extrahiert einen Archiveintrag; -O gibt dessen Inhalt im Terminal aus, ohne eine entpackte Datei zu schreiben:
tar -xOf /home/labex/project/support-backup.tar internal-customers.txt
Der Inhalt beginnt mit INTERNAL ONLY und beschreibt synthetische Kundendatensätze. Damit ist bestätigt, dass die erfolgreiche Antwort interne Daten enthielt und kein freigegebenes öffentliches Archiv.
Das Backup in einen privaten Speicherbereich verschieben
In diesem Schritt entfernst du das interne Backup von der öffentlichen Website und bewahrst seinen Inhalt für Wartungszwecke auf. Verwende Web Server, um die öffentliche Datei zu finden und das Problem zu beheben.
Die öffentliche Datei finden
Wechsle zu Web Server und lies die Website-Konfiguration:
cat /etc/nginx/conf.d/default.conf
root /srv/site; ordnet /backups/support-backup.tar der Datei /srv/site/backups/support-backup.tar zu. autoindex off; deaktiviert Verzeichnisauflistungen, verhindert aber keinen direkten Zugriff auf einen bekannten Dateinamen. Dateien ohne Verlinkung sind nicht automatisch privat.
Die Option -l zeigt eine ausführliche Auflistung mit Größe, Eigentümer und Zugriffsrechten. Prüfe damit die öffentliche Datei:
ls -l /srv/site/backups/support-backup.tar
Der angezeigte Pfad bestätigt, dass sich das Archiv unterhalb des konfigurierten Webroots befindet.
Das Backup außerhalb der Website aufbewahren
Das private Verzeichnis /srv/private-backups liegt bereits außerhalb von /srv/site. Innerhalb dieses Zielcontainers hast du Wartungsrechte. mv verschiebt eine Datei und erhält ihren Inhalt:
mv /srv/site/backups/support-backup.tar /srv/private-backups/support-backup.tar
Die Website kann diese Datei nicht mehr über ihre normale Zuordnung zum öffentlichen Verzeichnis ausliefern. So bleibt das Backup für berechtigte Wartungsarbeiten erhalten, statt gelöscht zu werden. Nginx muss nicht neu geladen werden, weil sich der Dateipfad geändert hat und nicht die Serverkonfiguration.
Prüfe in Web Server, ob die private Kopie noch lesbar ist:
tar -xOf /srv/private-backups/support-backup.tar internal-customers.txt
Du solltest dieselben internen Testdatensätze sehen.
Vertraulichkeit und Website-Verfügbarkeit prüfen
In diesem Schritt testest du die abschließende Zugriffsgrenze und bestätigst, dass freigegebene öffentliche Ressourcen weiterhin funktionieren.
Kehre zu Workstation zurück. -o /dev/null verwirft den Antwortinhalt und -w gibt die angeforderten Antwortinformationen aus. %{http_code} wählt den HTTP-Status; \n fügt einen Zeilenumbruch ein:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/backups/support-backup.tar
Erwarte 404. Der curl-Befehl endet trotzdem erfolgreich: Eine HTTP-Fehlerantwort ist etwas anderes als ein Verbindungsfehler. Würdest du den Server anhalten, würden die Verfügbarkeitsprüfungen des Kurses fehlschlagen.
Prüfe die normalen Seiten und freigegebenen Downloads mit derselben Methode:
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/help.html
curl -sS http://127.0.0.1:8081/downloads/product-guide.txt
curl -sS -o /home/labex/project/public-examples.tar http://127.0.0.1:8081/downloads/public-examples.tar
tar -xOf /home/labex/project/public-examples.tar example.txt
Die Seiten liefern 200. Das Handbuch beginnt mit Northstar Product Guide und der Eintrag im Beispielarchiv enthält Public support examples. In Topology bestätigt Website reachable, dass die Startseite antwortet, nicht dass das Leck behoben wurde. Die abschließenden Prüfungen testen Vertraulichkeit und Verfügbarkeit unabhängig voneinander.
Zusammenfassung
Du hast einen öffentlichen Download bis zur zugehörigen Serverdatei verfolgt, interne Daten aus dem Webroot verschoben und geprüft, dass private Downloads fehlschlagen, während öffentliche Dienste weiterhin funktionieren.
