Einführung
Laut Alder hat die Buchungsseite von Lantern Room zwei Versuche verarbeitet, aber nur einer führte zu einer Reservierung. Das Supportteam besitzt eine autorisierte HTTPS-Aufzeichnung und das passende TLS-Schlüsselprotokoll. Beide Versuche verwenden dieselbe URI und TCP-Verbindung; die Datei enthält auch einen anderen Besucher.
Du identifizierst jedes Anwendungsergebnis in der echten Wireshark-Oberfläche und lieferst eine kleine Belegtabelle samt vollständigem, unabhängig lesbarem Aufzeichnungspaket. Du solltest Read Your Authorized HTTPS Session abgeschlossen haben oder TLS-Schlüsselprotokoll und Follow TLS Stream kennen. Einfache Terminaleingaben und Pfade werden ebenfalls vorausgesetzt. Dieses Lab startet unabhängig mit eigenen kontrollierten Aufzeichnungen; die geschätzte Dauer umfasst Lesen und gewöhnliche Fehler.
Jeden Versuch Seinem Fachlichen Ergebnis Zuordnen
In diesem Schritt ordnest du jedem ursprünglichen Anfrage-Frame seine eigene vollständige Antwort zu und dokumentierst beide Ergebnisse.
Beginne in Desktop → Applications → Terminal Emulator. Öffne die vorbereitete Eingabe im leeren Profil Booking:
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
Maximiere Wireshark. Die schreibgeschützten Eingaben sind casebook.pcapng und casebook.keys; alle Ergebnisse gehören unter /home/labex/project/booking/output/. Die Daten sind synthetisch, aber jeder TLS-Handshake, HTTP-Austausch und jedes TCP-Segment wurde von einer echten kontrollierten lokalen Anwendung erzeugt.
Setze unter Edit → Preferences → Protocols → TLS das Feld (Pre)-Master-Secret log filename auf:
/home/labex/project/booking/input/casebook.keys
Lasse beide TLS-Reassemblierungsoptionen eingeschaltet und klicke OK. Das Protokoll ermöglicht die Entschlüsselung dieser aufgezeichneten Sitzungen; es ist kein allgemeiner Schlüssel für beliebige HTTPS-Verbindungen.
| Besucher | Clientadresse | Umfang |
|---|---|---|
| alder | 127.0.0.22 | Beide zu erklärenden paper-lantern-Buchungsversuche |
| birch | 127.0.0.23 | Anderer Besucher; von der Übergabe ausschließen |
Wende diesen Anzeigefilter an und drücke Enter:
ip.addr == 127.0.0.22 && http
ip.addr passt auf einen der beiden Endpunkte. && verlangt beide Bedingungen. Die Ansicht zeigt dadurch Alders entschlüsselte HTTP-Nachrichten in beiden Richtungen. Erwarte zwei POST-Anfragen und zwei 200 OK-Antworten. Beide Versuche teilen sich /api/bookings und den TCP-Stream; weder URI noch Stream identifiziert allein eine Transaktion.
Wähle den ersten POST. Klappe im mittleren Detailbereich Hypertext Transfer Protocol mit dem kleinen Dreieck auf. Lies unten [Response in frame: ...]. Das erzeugte Feld verknüpft diese Anfrage mit der von Wireshark tatsächlich zugeordneten Antwort. Dort verweist [Request in frame: ...] zurück. Wähle die verknüpfte Antwort über die Paketliste. No. enthält die ursprüngliche Frame-Nummer. Zusammengesetztes HTTP kann auf dem letzten Segment erscheinen. Verwende deshalb diese Verweise auf Analyse-Frames, statt aus benachbarten TCP-Zeilen zu raten.
Betrachte [Response in frame: 21] in den aufgeklappten HTTP-Details. Dieser Verweis gehört zur ausgewählten ersten Anfrage; die zweite hat eine andere Antwort.
Rechtsklicke auf die Anfrage und wähle Follow → TLS Stream. Lies die vollständige Anfrage mit ihrer Antwort. Das Anfrage-JSON nennt attempt, workshop und slot. Die Antwort wiederholt diese Werte. Lies accepted, reason und confirmation gemeinsam. Lies anschließend die zweite Anfrage mit Antwort weiter unten im selben Stream.
Alders erster Versuch wird wegen einer vollen Veranstaltung abgelehnt: accepted ist false, reason ist "session_full" und confirmation ist null. Die Wiederholung wird angenommen und erhält eine eigene Bestätigung. Beide HTTP-Statuszeilen lauten 200 OK: Der Server verarbeitete beide Anfragen, doch die fachlichen Ergebnisse unterscheiden sich. Eine Bestätigung an anderer Stelle im Stream oder bei Birch darf nicht für einen abgelehnten Versuch übernommen werden.
Schließe Follow mit Close. Der hinterlassene Streamfilter umfasst die gesamte Verbindung. Kehre zum ursprünglichen Alder-und-HTTP-Filter zurück, um die vier ursprünglichen Frame-Nummern zu notieren. Nutze für die Tabelle immer diese Eingabedatei; exportierte Dateien nummerieren die Pakete neu.
Erstelle attempts.csv, einen kleinen Übergabeindex, den andere Analysten mit der Aufzeichnung vergleichen können. CSV bedeutet kommagetrennte Werte: Eine Kopfzeile benennt die Spalten, jede weitere Zeile steht für einen Versuch. Es gibt sieben Spalten:
| Spalte | Bedeutung |
|---|---|
| attempt | Exakter attempt-Wert der Anfrage |
| request_frame | Ursprünglicher POST-Frame in der Eingabe |
| response_frame | Eigener verknüpfter Antwort-Frame in der ursprünglichen Eingabe |
| slot | Gewünschter Termin, von der Antwort wiederholt |
| accepted | true oder false aus dem Antwort-JSON |
| reason | Exakter Begründungstext der Antwort |
| confirmation | Eigene Bestätigung des Versuchs oder leer bei null |
Wechsle über das untere Panel zum Terminal oder öffne einen weiteren Terminal Emulator, wenn der erste von Wireshark belegt ist. Starte den vorbereiteten Editor:
mousepad /home/labex/project/booking/output/attempts.csv
Gib die folgende Kopfzeile genau und danach die zwei aus der Originalaufzeichnung gelesenen Zeilen ein. Schreibe nicht null in die Bestätigungsspalte: Ein abschließendes Komma in der Ablehnungszeile stellt das leere letzte Feld dar. Diese Datenwerte enthalten keine Kommas; zitierte CSV-Felder sind daher unnötig. Zeilen- und Spaltenreihenfolge dürfen variieren, wenn Kopfzeilen und Werte zusammenpassen.
attempt,request_frame,response_frame,slot,accepted,reason,confirmation
Wähle File → Save und schließe den Editor. Prüfe genau eine Zeile pro unterschiedlichem Versuch und den Verweis auf dessen eigene Antwort. Öffne bei einem Tippfehler dieselbe Datei mit dem obigen Befehl, korrigiere und speichere. Das erfordert weder neue Aufzeichnung noch VM-Reset. Lasse Wireshark für den nächsten Schritt geöffnet.
Ein Unabhängig Lesbares Belegpaket Liefern
Du exportierst eine vollständige Zielverbindung und öffnest sie mit dem mitgelieferten Schlüsselprotokoll erneut.
Beginne in Desktop mit der ursprünglichen input/casebook.pcapng in Wireshark. Die Tabelle indexiert die Quelle; die Übergabeaufzeichnung muss nur Alders vollständige TCP-Verbindung enthalten. TLS-Handshake und frühere Segmente sind zum Entschlüsseln und Zusammensetzen der Anwendungsdaten erforderlich.
Ersetze den Anzeigefilter durch:
ip.addr == 127.0.0.22
Das behält beide Richtungen und alle Protokollschichten für Alder. Wähle einen entschlüsselten POST, rechtsklicke und wähle Follow → TLS Stream. Bestätige, dass beide Versuche Alder gehören, und schließe Follow mit Close. Behalte tcp.stream eq ... bei. Dieser Filter umfasst die gesamte gewählte Verbindung statt nur HTTP-Zeilen.
Wähle File → Export Specified Packets. Stelle pcapng, den Bereich Displayed und darin All packets ein. Speichere nach:
/home/labex/project/booking/output/evidence.pcapng
Der Dialog zeigt Displayed und All packets mit 38 Zielpaketen. Das Original enthält 65 Pakete. Captured würde daher auch den anderen Besucher einschließen.
Verwende nicht Export Packet Dissections, das nur Zusammenfassungen exportiert. Exportiere nicht ausschließlich http-Zeilen: Dabei können Handshake oder frühere TLS/TCP-Segmente für Entschlüsselung und Reassemblierung fehlen. Bette mit Inject TLS Secrets keine Geheimnisse ein; das Paket nutzt ein separates Protokoll.
Wechsle zu einem Terminal Emulator und kopiere das autorisierte Protokoll neben die Ausgabe. cp kopiert vom ersten zum zweiten Pfad; das Original bleibt erhalten und wird nicht umbenannt.
cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys
Diese Trainingsübergabe bleibt im selben autorisierten Analysebereich. Das gelieferte Protokoll enthält Geheimnisse der synthetischen Sitzungen in der Quelle; das Minimieren oder Schwärzen einzelner Einträge gehört nicht zur Übung. Die Aufzeichnung muss Birchs Pakete trotzdem ausschließen. Gleichwertige passende Schlüsselprotokolle sind zulässig, wenn sie beide Zielantworten unabhängig entschlüsseln.
Schließe das Hauptfenster und öffne die tatsächliche Exportdatei im zunächst leeren Profil BookingReview:
wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng
Setze unter Edit → Preferences → Protocols → TLS das Feld (Pre)-Master-Secret log filename auf dieses Ausgabeprotokoll und klicke OK:
/home/labex/project/booking/output/booking.keys
Wende http an und verfolge einen POST mit Follow → TLS Stream. Lies beide vollständigen Anfrage- und Antwortinhalte erneut. Der Export muss Alders Ablehnung und Bestätigung mit ihren eigenen attempt-Bezügen zeigen und darf keinen Birch-Aufruf enthalten. Er muss mit dem Ausgabe-Schlüsselprotokoll funktionieren, ohne stillschweigend den Eingabepfad zu benötigen.
Lies den wiederholten attempt neben jedem Ergebnis: Die Ablehnung hat keine Bestätigung; nur die Wiederholung hat ALDER-02-CONF. Der Titel benennt die Ausgabedatei evidence.pcapng.
Schließe Follow und leere den Filter, um Handshake und weitere TCP-Pakete zu prüfen. Diese Datei besitzt eigene Frame-Nummern; attempts.csv verweist weiter auf die ursprüngliche Eingabe. Schließe das Hauptfenster.
Ist die Ausgabe leer oder fehlt ein Inhalt, öffne die Eingabe erneut, stelle den vollständigen Alder-Verbindungsfilter wieder her und wiederhole Export Specified Packets mit Displayed → All packets, wobei du die unvollständige Ausgabe ersetzt. Bleiben Pakete verschlüsselt, korrigiere den Ausgabeschlüsselpfad in TLS. Das sind verschiedene Probleme: Ein fehlendes Schlüsselprotokoll verhindert Entschlüsselung; fehlende erfasste Segmente entstehen durch eine Einstellungskorrektur nicht neu.
Die Übergabe besteht aus drei echten Dateien: attempts.csv, evidence.pcapng und booking.keys. Aufzeichnung und Schlüssel müssen die Tabelle unabhängig belegen. Ein Screenshot oder eine eingegebene Erfolgsmeldung ersetzt keine tatsächlichen Paketbelege.
Zusammenfassung
Du hast zwei fachliche Ergebnisse mit identischem HTTP-Status unterschieden, jede Anfrage ihrer eigenen Antwort zugeordnet und die ursprünglichen Frame-Verweise in einer knappen Tabelle festgehalten. Du hast die vollständige Ziel-TCP-Verbindung exportiert und die tatsächliche Ausgabe mit separatem Schlüsselprotokoll erneut geöffnet.
Diese Übergabe aus drei Dateien lässt sich ohne dein Wireshark-Profil prüfen. Sie belegt die Aussagen dieser kontrollierten Buchungsaustausche, aber keine Zahlung im Produktivsystem, Bestandsänderung oder interne Serverursache.
