At 02:33 PM 10/20/1999 -0400, [EMAIL PROTECTED] wrote:
>
>I'd like to see some consideration of partial solutions that can be
>implemented rapidly and widely, now, without waiting for the world's
>responsible OS vendors to implement a new log protocol that we're now
>inventing. From
>
>I have been most concerned about authentication of log reports, and
>scenarios in which an attacker interested in a particular device is able to
>"chaff" the event logging system with bogus reports that claim to be from
If you have a key exchange mechanism, you can simply insert an HMAC or
other authentication code in the message as part of the existing syslog()
call (or equivalent). It could be part of the free-form text string that
is currently used for the message field. If you like, syslogd could refuse
to accept messages without this field, or with a field that didn't verify a
permitted log sender. This code could then be stored in the receiving
host's log file and be available for later message verification (there are
some issues here about the way numeric codes are translated by syslogd into
text strings, but nothing terrible).
You could also require IPsec AH on all packets to the logging host's syslog
UDP port and achieve the same goal, though without it being so easy to
record the authentication data in the log file. However, this works
without modification to syslogd or syslog().
I would think that the biggest problem for adding authentication to
existing syslog is extending the systems to do key management. The longer
the keying material identifying the remote system linger on that host, the
less secure your logging operations are, so you probably need to add some
kind of key distribution mechanism, probably over the network, in which
case you end up implementing a chunk of something like IPsec or SSH just to
be able to do secure key updates.
If you already have a host key on the system generating the logs, adding
authentication to existing syslog could be pretty easily be done _ad hoc_.
Note, though, that a secure syslog implementation could probably be
distributed without manufacturer involvement, by replacing existing
function calls in syslog.c and modifying the code in syslogd.c. If you had
to, you could even wedge the authentication codes in at the syslogd.c level
and add them only when a syslog message is forwarded from the local host
doing the log generation to a remote host doing log collection.
Bob
