Use syslog-sign with changing structured data elements
The structured data (SD) in syslog-protocol offers some interesting possibilities when it comes to modifying a message in transit. What would be necessary to enable rewriting in transit while still be able to authenticate by syslog-sign?
One example where one might rewrite syslog messages is to preserve multiple sending and receiving timestamps. This is useful because a wrong system clock makes the sending timestamp mostly worthless, so you want the logserver to write its own time into the mesage. But if there is a network outage and the client buffers its messages for some time, then sending and receiving timestamps are also different but in this case the sending timestamp is the accurate one. — Thus simply replacing the messages’ timestamp is no general solution, but having multiple timestamps is.
With SD every syslogd could just write its local time into every message, not unlike a Received: line in e-mails (in theory it could do so with BSD Syslog as well, but the important difference is that a new SD element will not mess up later parsing and analysis).
Consider these examples:
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com logger - - [transport relay1="relay.example.com" timestamp1="2003-10-11T24:14:16.000-02:00" relay2="logserver.example.com" timestamp2="2003-10-11T18:14:16.702+04:00"] Hello World
<34>1 2003-10-11T22:14:15.009Z mymachine.example.com logger - - [transport relay1="relay.example.com" timestamp1="2003-10-11T24:14:15.840-02:00" relay2="logserver.example.com" timestamp2="2003-10-11T18:54:16.702+04:00"] Hello World
The first message shows a clean transport; but the second message indicates a network problem between the relays because logserver.example.com received it 40 minutes after relay.example.com, so it might have been buffered for that time.
But now enter syslog-sign: Once you sign your messages on one device you most not alter them on their way to their destination as every changes invalidates the signature!
But what if we really really want to add routing information? Would it be feasible to define a structured data element that might be inserted at will and had to be removed before checking signatures?
I think the following specification would suffice for this:
- Define some SD element with SD-ID “transport” to be used to track transport of syslog messages across different relays.
- Every device might insert a transport SD element into the SD field. If other SD elements are present then their order must not be changed; otherwise the new SD element replaces the dash (
-). - All parameters get natural numbers as suffixes. Every device that writes transport information has to check whether a transport SD element is already present. It has to use the parameters with the lowest unused number as suffixes.
- Before signing or signature checking the transport SD element is removed from the message. If it is the only SD element, then it is replaced by a dash (
-) to keep the message well-formed.
Using the example above, we start with this message which might be signed at the originating device:
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com logger - - - Hello World
This gets submittet to relay.example.com which inserts the transport SD element:
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com logger - - [transport relay1="relay.example.com" timestamp1="2003-10-11T24:14:16.000-02:00"] Hello World
and later logserver.example.com which adds additional parameters to the transport SD element, yielding the message as above:
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com logger - - [transport relay1="relay.example.com" timestamp1="2003-10-11T24:14:16.000-02:00" relay2="logserver.example.com" timestamp2="2003-10-11T18:14:16.702+04:00"] Hello World
Now say logserver.example.com checks the messages’ signature with syslog-sign. Then it would remove the transport SD element before doing so, thus calculating the hash over
<34>1 2003-10-11T22:14:15.003Z mymachine.example.com logger - - - Hello World
which would be valid and match the signature as it is the same message as was sent from mymachine.example.com in the first place.