Zusammenfassung

  • conn.log beschreibt, was ein bestimmter Zeek-Sensor aus dem empfangenen Verkehr ableitete; selbst history ist keine vollständige, chronologische Paketfolge.
  • Belastbare Feststellungen brauchen Rohlog und Schema, Zeek-Version, Skripte, Messpunkt, Filter, Zeitbasis, Verlusthinweise und die über uid verbundenen Protokolle.

Die Verdichtung war Teil des Entwurfs

Paxsons Bro-Papier von 1998 trennte zwei Aufgaben. Eine Event Engine reduzierte einen gefilterten Paketstrom auf höherwertige Netzwerkereignisse. Ein Interpreter für Richtlinienskripte bewertete diese Ereignisse nach den Bedürfnissen des jeweiligen Standorts. Beobachtungsmechanismus und lokale Reaktion blieben getrennt.

Die Verdichtung machte Echtzeitüberwachung auf stark belasteten Leitungen überhaupt praktikabel. Gleichzeitig bestimmt sie die Beweiskraft des Ergebnisses. Vor der übersichtlichen Zeile stehen Netzposition, Schnittstelle, Paketfilter, Integritätsprüfungen, Zustandsmaschine und Skriptlogik. Das Protokoll ist ein Erzeugnis dieser Kette, keine neutrale Kopie des gesamten Verkehrs.

Das frühe Papier behandelt Paketverluste als unmittelbare Gefahr. Kann der Monitor ankommende Pakete nicht schnell genug verbrauchen, läuft der Filterpuffer voll; danach gehen Pakete verloren. Gerade darin könnte das Merkmal liegen, das einen Eindringling erkennbar macht. Außerdem ging der Entwurf davon aus, dass Angreifer den Monitor verstehen und zu umgehen oder zu überlasten versuchen. Sensorzustand und Ereignisbeweis lassen sich deshalb nicht seriös trennen.

Was die Felder beobachtet haben

Die aktuelle Zeek-Dokumentation beschreibt conn.log als grundlegenden Datensatz für Aktivitäten der Schichten 3 und 4: wer mit wem sprach, wann, wie lange und über welches Protokoll. Er umfasst TCP und UDP. Bei UDP und ICMP bedeutet „connection“ einen Paketfluss, keine TCP-Sitzung. Bereits der Gegenstand der Zeile hängt also vom Protokoll ab.

ts ist der Zeitpunkt des ersten von Zeek gesehenen Pakets. Das Feld beweist nicht, dass an einer anderen Stelle oder früher kein Paket existierte. uid ist Zeeks eindeutiger Schlüssel für die Verbindung und verknüpft zugehörige DNS-, HTTP-, TLS- oder andere Logs. Die Endpunkte haben diese Kennung weder ausgehandelt noch bestätigt.

conn_state fasst den erschlossenen Zustand zusammen. S0 bedeutet, dass ein Versuch ohne Antwort gesehen wurde; SF steht für normal erscheinenden Aufbau und Abbau. Weitere Werte beschreiben Zurückweisung, Reset und unvollständige Enden. Sie sind Aussagen über die Sicht des Sensors. Ein einseitiger Messpunkt, ein verspäteter Start oder Verlust kann dieselbe Kommunikation anders klassifizieren.

history speichert Zustandsereignisse als Buchstaben. Großbuchstaben stehen für den Initiator, Kleinbuchstaben für die Gegenseite. SYN, SYN-ACK, ACK, Nutzdaten, FIN, RST, Lücken und Übertragungswiederholungen werden verdichtet. Manche Zeichen erscheinen höchstens einmal je Richtung, andere werden logarithmisch wiederholt. Das Muster hilft bei der Diagnose, enthält aber weder vollständige Reihenfolge noch genaue Anzahl aller Pakete.

Auch Zahlen beruhen auf Regeln. Bei TCP werden orig_bytes und resp_bytes aus Sequenznummern berechnet und können laut Referenz insbesondere bei großen Verbindungen ungenau sein. duration erfasst bestimmte späte Pakete ohne neue Nutzdaten nicht, obwohl history sie zeigen kann. Paket- und IP-Byte-Zähler sind nur bei aktiviertem Größenanalysator vorhanden. Die Einordnung lokal/entfernt hängt von Site::local_nets ab. Ein leeres Feld kann eine Konfigurationsaussage sein.

Die Zuverlässigkeit des Zeugen messen

missed_bytes zählt Bytes, die in Inhaltslücken fehlen. Ein Wert ungleich null lässt die Protokollanalyse normalerweise scheitern, auch wenn vor dem Verlust schon Teilergebnisse entstanden sein können. capture_loss.log erkennt Lücken in TCP-Sequenznummern und nimmt an, dass fehlender Verkehr einem Erfassungsverlust entspricht. Die Methode macht den Indikator nützlich und grenzt ihn zugleich ein.

reporter.log enthält interne Warnungen und Fehler zur Verkehrsverarbeitung und Rechenlast. Bei einer Untersuchung gehören daher Verlustschätzung, Meldungen, Prozessneustarts, Filteränderungen und Schnittstellenzustand auf dieselbe Zeitachse wie die Verbindung.

missed_bytes: 0 schließt keinen Verlust vor der Schnittstelle, keine asymmetrische Route, keinen ausschließenden Filter und keine Lücke vor Prozessstart aus. Umgekehrt vernichtet ein Verlusthinweis nicht automatisch jedes Feld. Gute Unsicherheit benennt Zeitpunkt, Richtung, Sensor und Verarbeitungsschritt.

Eine prüfbare Beweiseinheit bauen

Soll eine Feststellung Monate später in Aufarbeitung, arbeitsrechtlichen Verfahren, Gerichten, Versicherungen oder Behördenberichten bestehen, muss mehr als die Zeile erhalten bleiben: Rohlog und exaktes Schema, Zeek-Version, geladene Skripte, relevante Einstellungen, Netzposition und Schnittstelle, Erfassungsfilter, Zeitquelle und gemessene Abweichung. Hinzu kommen capture_loss.log, reporter.log und die über dieselbe uid verbundenen Anwendungsprotokolle.

Soweit Datenschutz und Aufbewahrung es erlauben, ergänzt ein unveränderlicher PCAP-Ausschnitt oder dessen Hash das Paket. Auch ein Paketmitschnitt besitzt Messpunkt, Snap Length, Verluste und Verwahrungskette. Er ist keine allwissende Wahrheit, ermöglicht aber, die verdichtete Ableitung an tieferen Beobachtungen zu prüfen.

Existiert kein PCAP, sollte das ausdrücklich im Befund stehen. „Dieser Zeek-Sensor beobachtete an diesem Ort und unter dieser Konfiguration …“ ist eine klare, überprüfbare Aussage. Eine absolute Formulierung über alle Pakete wäre schwächer, weil sie die Beleggrenze überschreitet.

Das Schema gehört ebenfalls in die Akte. Die Dokumentation nennt ip_proto als Neuerung in Zeek 7.1. Skripte können Felder hinzufügen und Protokollierung verändern. Ohne Version und Header liest ein späteres Werkzeug alte Daten möglicherweise mit neuer Semantik.

Quellen