Re: Living with existing syslogd

[by way of "Chris M. Lonvick" <[EMAIL PROTECTED]>]

Thanks for your comment --

Robert Webber <[EMAIL PROTECTED]>   wrote:    "... 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. ...
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)."

This is exactly what I had in mind, as my complete (corrected) message
below indicates.  (Sorry -- I'm still fighting with Notes mail!)

The numerical encoding I had in mind was hex or base64, identified
appropriately, so that the authentication code would in fact simply be part
of the message text string.   An HMAC-MD5 hash produces a 128-bit value
encoded in 16 bytes binary, 32 bytes hex, or 22 bytes base64.  I am
suggesting that the previous message's authentication code be used as a
nonce, and repeated in the present message, so that two such fields (or a
field twice as long) would be necessary, for a total of 44 (base64) to 64
bytes (hex) additional message text.  With appropriate tagging of the
field, the total might be 48 to around 72 bytes maximum.

Because past syslogd security vulnerabilities have included a stack buffer
overflow attack, I know there is concern about the size of syslog messages
beyond simple network traffic load.  I believe that an additional 64 byte
(say) authentication field in the text could have enough benefit to justify
any risk, but I'd like to know if there is any experience with this problem
that would rule out adding this much to message text.

BTW:  This question about syslog message size applies to any UDP-based
mechanism -- and, of course, I believe there will have to be a UDP
mechanism available in the syslog replacement or enhancement.


Alex Brown <[EMAIL PROTECTED]> +1 508 323 2283



Please respond to [EMAIL PROTECTED]

Sent by:  [EMAIL PROTECTED]



To:   [EMAIL PROTECTED]
cc:    (Alex Brown/US/3Com)
Subject:  Living with today's syslog (sorry for garbled prior msg...)








I'm interested in finding even a partial solution that can work with the
existing population of UNIX syslog daemons.
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
other devices on the network.    I'm considering adding an optional
authentication field to the syslog message that's an MD5 hash of the
message and a secret shared between log client and log server, making it
possible to filter the log for device level authentication.  Because there
may be log messages with identical content there should be a nonce present
in the message text.  I suggest that this nonce be the value of the
[authentication hash field of the]
preceding log message from this client -- which should make it possible to
independently serialize the stream from this client, without reference to
timestamps at the server, and to detect missing or bogus log reports.
This does of course add to the message size.
Alex Brown