skip to content

When firewall syslog reaches a collector through a relay and events look out of order, which timestamps and fields can you trust?

level: seniorimportance: should knowfreq 22%

answer

  1. three clocks on one path
  2. who wrote this time?
  3. relays may stamp their own
  4. timeQuality speaks for the clock
  5. source address may be the relay

basics

~20 s

Trust an RFC 5424 TIMESTAMP only as far as the originator's clock was synchronised, which timeQuality can state. BSD timestamps lack year and zone and may be a relay's own time. Arrival order and the datagram's source address prove neither sequence nor origin.

solid answer

~40 s

Three clocks touch a relayed message: the originator's TIMESTAMP, any time a relay inserts, and the collector's receive time. Only the first describes the event, and only if the device clock was synchronised; an RFC 5424 originator can say so with `[timeQuality tzKnown="1" isSynced="1" syncAccuracy="..."]`. An RFC 3164 relay must forward a message with valid PRI and TIMESTAMP unchanged, but inserts its own local time when the timestamp is missing or invalid, and BSD times have no year or zone. RFC 5426 says arrival order is not authoritative and that the datagram's source IP may be a relay, so identify the originator from HOSTNAME or `origin`. Within one originator, `meta sequenceId` gives true send order; across devices, ordering needs synchronised clocks, which is NTP's job. Timestamps can also be forged or replayed without signing.

go deeper

for a junior

Know that a syslog timestamp is written by the device's own clock and that a wrong device clock means wrong log times.

for a middle

Explain the RFC 5424 timestamp format with offset and fractions, the timeQuality parameters, and why BSD timestamps without year or zone are ambiguous.

for a senior

Rebuild an incident timeline: separate originator, relay and receive times, use sequenceId within a device, read timeQuality, and distrust source addresses and unsigned times.

for a principal

Decide what timestamp evidence the estate needs: mandated clock synchronisation, timeQuality reporting, RFC 5424 end to end, and signing where logs may face legal or forensic scrutiny.

## Three clocks on one path A firewall message relayed to a collector can carry or acquire three different times: | Time | Who writes it | What it measures | |---|---|---| | Originator TIMESTAMP | the firewall, at creation | when the event was logged, by the firewall's clock | | Relay-inserted TIMESTAMP | an RFC 3164 relay, only in specific cases | when the relay handled the message | | Receive time | the collector, outside the message | when the datagram or frame arrived | Only the first describes the event. The other two describe the path and absorb every queue, retry and loss on it. ## What the RFC 5424 timestamp tells you RFC 5424's `TIMESTAMP` is an RFC 3339 date-time with a mandatory `T`, an upper-case `Z` or a numeric offset, up to six fractional-second digits, and no leap seconds. `2026-10-01T14:03:07.412+02:00` is an unambiguous instant. Two details matter in practice: - A device that cannot obtain the time must send the NILVALUE `-` rather than invent one. - RFC 5424 Appendix A.4 warns about a common bug, dropping leading zeros in the fraction: `.003` written as `.3` turns 3 milliseconds into 300. An unambiguous format is not a correct clock. RFC 5424 therefore defines the **`timeQuality`** structured-data element, which an originator should send when it is not synchronised to a reliable external source or is unsure of its time zone: - `tzKnown` is 1 if the originator knows its time zone, 0 if that is in doubt. - `isSynced` is 1 if the originator is synchronised to a reliable external time source, such as NTP. - `syncAccuracy` is the most the clock may be off, in microseconds; it must not appear when `isSynced` is 0. The RFC example `syncAccuracy="60000000"` means within 60 seconds. The RFC suggests that `[timeQuality tzKnown="0" isSynced="0"]` is a hint for the collector to use its own receive time when correlating messages from different originators. ## What a relay may change 1. **RFC 3164 relays.** If the PRI and TIMESTAMP are valid, the relay must forward the packet **without any change**. If the TIMESTAMP is missing or invalid, it must insert its **own current local time**, and should insert a HOSTNAME for the device as the relay knows it. If the PRI is missing, it also inserts `<13>`. A relayed BSD message can therefore carry a time that is not the event's. 2. **RFC 3164 timestamps** are local time in `Mmm dd hh:mm:ss` form. Converting one to RFC 5424 adds the current year and may use the relay's or collector's time zone, so the absolute time is inferred, not reported. 3. **RFC 5424** does not specify relay behaviour, but it requires that a transport never deliberately alter a message, so that end-to-end signatures still verify, and that a relay forward malformed structured data without alteration. ## Who sent it RFC 5426 says the source IP of a UDP syslog datagram should not be taken as the originator, because the sender may be a relay. The originator is named in `HOSTNAME`, preferably as an FQDN, and an `origin` element can list its addresses, for example `[origin ip="192.0.2.10" ip="192.0.2.11"]`. Over TLS, RFC 5425 states that the authenticated peer identity is not necessarily related to the HOSTNAME field either. ## Putting events in order - **Arrival order** is not authoritative; RFC 5426 says so directly, and relays and queues reorder freely. - **Within one originator**, `meta sequenceId` records the order in which messages were submitted for sending, so it orders that firewall's events even when timestamps tie. - **Across originators**, such as the two firewalls of a pair, only timestamps can order events, and only to the accuracy of each device's clock. Keeping those clocks synchronised is NTP's job; syslog merely reports whether it was done. ## Trusting the time at all RFC 5424 section 8.4 notes that syslog has no replay detection: recorded messages can be resent with current timestamps and look normal. Without RFC 5848 signing, a timestamp is the claim of whoever wrote the message, not evidence. For an incident timeline, rank the fields: 1. Signed messages, or messages over an authenticated TLS hop straight from the originator, whose timeQuality says the clock was synchronised. 2. Unsigned RFC 5424 timestamps from devices known to be synchronised. 3. Collector receive time, if the collector's own clock is synchronised, as a bound on the latest the event can have happened. 4. BSD timestamps, last, after checking whether a relay inserted them.

  • What does [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"] in an RFC 5424 message promise?
    The originator knows its time zone, is synchronised to a reliable external source, and believes its clock is within 60,000,000 microseconds, 60 seconds, of the reference. A message stamped 9:00:00 happened no earlier than 8:59:00 and no later than 9:01:00 by that claim, which the originator usually knows only from operator configuration.
  • Why should a syslog collector not identify the originator by the UDP datagram's source address?
    RFC 5426 says the source IP should not be interpreted as the originator because the sender may be a relay; the message's HOSTNAME field names the originator. UDP syslog also has no sender authentication, so the address can be forged. Use HOSTNAME, an `origin` element, or an authenticated TLS peer.

A relay-inserted syslog timestamp is like a sorting office's postmark: it tells you when the letter passed through that office, not when the writer dated it.

saying these in an interview costs you the question

  • The collector's receive time is when the event happened.
  • BSD-format syslog timestamps are in UTC.
  • The UDP source address always identifies the device that generated the message.
  • isSynced="1" means the timestamp is exact to the microsecond.
  • An RFC 3164 relay may rewrite any timestamp to its own clock.