Zusammenfassung
- Nach RFC 3164 setzte ein Relay bei gültigem PRI, aber fehlendem oder ungültigem TIMESTAMP seine eigene aktuelle Ortszeit ein und ergänzte möglichst die Geräteidentität, wie es sie kannte.
- Auch danach durfte das gesamte Paket höchstens 1024 Byte lang sein. Überstieg es die Grenze, musste das Relay das Ende des ursprünglichen Inhalts abschneiden.
- Spätere Standards trennten Urheber-, Relay-, Sammler- und Transportrollen genauer. Ein sauberes Headerfeld, ein vollständiger Frame oder ein authentisierter TLS-Peer wurden dadurch nicht zum lückenlosen Herkunftsnachweis.
Die Reparatur bezahlte mit Nutzinhalt
Der RFC 3164 dokumentierte 2001 bereits beobachtetes BSD-Syslog. Er unterschied das erzeugende Gerät, das empfangende und weiterleitende Relay sowie den Collector, der Nachrichten annahm, ohne sie erneut zu versenden. Ein Sender musste nicht wissen, welche Rolle sein nächster Empfänger innehatte.
Ein Relay prüfte zuerst PRI und danach die Form von TIMESTAMP. Waren beide gültig und sah seine Konfiguration die Weiterleitung dieser Priorität vor, musste es das Paket unverändert weitergeben. Es musste weder die Richtigkeit der Uhrzeit noch die Übereinstimmung von HOSTNAME mit der Netzwerkquelle prüfen. Syntaktische Gültigkeit steuerte den Pfad; sie bestätigte nicht die Behauptung.
War PRI lesbar, TIMESTAMP aber nicht vorhanden oder ungültig, musste das Relay unmittelbar hinter PRI einen Zeitstempel und ein Leerzeichen einsetzen. Das war seine eigene aktuelle Ortszeit, keine Rekonstruktion des Ereigniszeitpunkts. Nach Möglichkeit ergänzte es HOSTNAME als den Gerätenamen, den es kannte; sonst verwendete es die IP-Adresse. Der übrige Empfang wurde als CONTENT angehängt.
Nun galt weiterhin die Obergrenze von 1024 Byte. Nach seinen Einfügungen musste das Relay neu messen. War das Paket zu lang geworden, musste es auf 1024 Byte gekürzt werden. RFC 3164 weist ausdrücklich darauf hin, dass dabei lebenswichtige Informationen am Ende des ursprünglichen Pakets verloren gehen konnten.
Das Relay kaufte also Einordnung mit Inhalt. Der Collector erhielt einen Zeitpunkt der Relay-Beobachtung und eine vom Relay angenommene Geräteidentität. Dafür konnte er Fehlercode, Objektname, Ergebnis oder den letzten entscheidenden Satz verlieren.
Fehlte auch PRI, verbrauchte die Ordnung noch mehr Raum
Bei fehlendem oder nicht erkennbarem PRI setzte das Relay den Standardwert 13 ein, ergänzte TIMESTAMP und möglichst HOSTNAME und behandelte alles Empfangene als Inhalt. Danach folgte dieselbe Kürzung. Je mehr Struktur fehlte, desto mehr ursprüngliche Bytes konnten für ihre Ersetzung weichen.
Das nächste Relay sah möglicherweise bereits ein gültiges PRI und TIMESTAMP und leitete das Ergebnis unverändert weiter. In der beim Collector gespeicherten Fassung musste nicht mehr sichtbar sein, welche Felder vom Gerät und welche vom ersten Relay stammten. Eine einheitliche Syntax konnte die Veränderungsgeschichte verdecken.
Der alte TIMESTAMP enthielt außerdem weder Jahr noch Zeitzone. Eine nachträgliche Jahreszuordnung blieb bei Verzögerungen und Jahreswechseln unsicher. Die eingefügte Relay-Zeit belegte am ehesten eine Beobachtung an diesem Zwischenpunkt.
Ein exakt begrenzter Frame kann schon vorher verstümmelt worden sein
Der RFC 5424 formalisierte 2009 originator, relay, collector, transport sender und transport receiver. VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID und MSGID bilden den Header; strukturierte Daten können folgen. Die Größenunterstützung wurde dem Transport zugeordnet: Jeder Empfänger muss 480 Oktette und sollte 2048 Oktette annehmen können.
Ist eine Nachricht größer als unterstützt, sollte der Empfänger die Nutzlast kürzen oder darf sie verwerfen. Eine Kürzung muss am Ende erfolgen. Dadurch bleibt der Anfang bevorzugt erhalten, doch UTF-8 oder strukturierte Daten können ungültig enden. Der Sicherheitsteil warnt, dass Angreifer auf diese Weise wesentliche Informationen verbergen können, und empfiehlt, Wichtiges früh zu platzieren.
Beim TLS-Transport nach RFC 5425 steht vor jeder Nachricht ihre Oktettzahl und ein Leerzeichen. Die Grenze bleibt auch über mehrere TLS-Records eindeutig. Die authentisierte Identität des Transportabsenders muss jedoch nicht zu HOSTNAME passen. TLS schützt den Hop, nicht automatisch die behauptete Ursprungskette.
RFC 5426 trägt genau eine vollständige oder gekürzte Syslog-Nachricht pro UDP-Datagramm. RFC 6587 beschreibt für TCP Oktettzählung und terminatorbasiertes Framing. Beide Verfahren grenzen vorhandene Bytes ab. Sie stellen nicht wieder her, was ein früheres Relay entfernt hat.
Das IANA-Register der Syslog-Parameter ordnet Facility-, Severity-, Versions- und Structured-Data-Werte zu. Es erklärt Nummern, belegt aber weder Implementierung noch Konfiguration, Identität, Zustellung oder Vollständigkeit.
RFC 5424 kennt außerdem das optionale Structured-Data-Element timeQuality. Ein Originator kann angeben, ob er seine Zeitzone kennt, ob seine Uhr synchronisiert ist und welche Genauigkeit er annimmt. Das liefert mehr Kontext als der alte Zeitstempel ohne Jahr und Zone, bleibt aber eine Selbstauskunft. Ein Collector hat damit noch keine unabhängige Zeitmessung vorgenommen.
Auch die UDP-Mindestgrößen zeigen, warum es später nicht einfach eine neue universelle Syslog-Grenze gab. Nach RFC 5426 müssen IPv4-Empfänger 480 Oktette und IPv6-Empfänger 1180 Oktette annehmen; 2048 werden allgemein empfohlen. Diese Werte orientieren sich an der Vermeidung von Fragmentierung bei kleinen MTUs. Lokale Annahmefähigkeit, Zustellung über einen Pfad und vollständige Speicherung bleiben unterschiedliche Grenzen.
Eine archivierte Nachricht mit genau 1024 Byte beweist deshalb für sich genommen keine historische Relay-Kürzung. Sie kann so erzeugt oder an anderer Stelle verkürzt worden sein. Der RFC belegt den möglichen Mechanismus. Die Zuordnung zu einem konkreten Vorfall verlangt Kopien beider Seiten und die damals wirksame Konfiguration.
Dass RFC 3164 auch Fälschung, Wiederholung, Umordnung und Verlust behandelt, begrenzt die Aussage eines einzelnen Datensatzes zusätzlich. Ein wohlgeformtes Ereignis kann erfunden, ein echtes kann verspätet oder gar nicht angekommen sein. Die Untersuchung darf Formatkonformität, Transporterfolg und Ereigniswahrheit nicht zu einem einzigen Qualitätsmerkmal zusammenziehen.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
