Living with syslogd (Re: udp vs. tcp)

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

Once again, I'm considering ways to live with the present syslogd ...


Darren Reed <[EMAIL PROTECTED]> wrote:

"If you showed me evidence, in court, that was based on an unreliable
source, how could you claim that what was being presented was itself,
reliable and accurate ?"
Well, not all security tools have to produce evidence that will stand up in
court.  There are different security needs as well as different threat
models, and this variety should be reflected in the proposals (plural) that
we consider.

"The next implicit problem with UDP is to do with size - you can only
fit so much in a UDP message, without causing fragmentation.  There
are a number of protocols (DNS comes to mind) which have limitations
built in because of that.  With syslog today, there is an arbitrary
limit of 1024 bytes in a syslog message.  Start adding in checksums
and you run out of room real quick."
Agreed.  It's possible that the authenticator field I've suggested should
be applied only to a limited range of security critical messages - e.g.
LOG_AUTH and LOG_AUTHPRIV facilities - and as a user option.

"If I want to do strong authentication of the server I'm sending data
to or it is going to attempt to expect strong authentication from me,
I would expect TCP to be a natural mechanism for supporting that."
The threat I'm considering is chaffing or spoofing an event stream as
received at the server, and the authentication is needed only there;  it
also might not need to be available in real time -- an offline filter tool
might be acceptable.

"However, that is different to applications sending syslog messages to
the local daemon (assuming that is the model people wish to work with).
Is there any need to change that protocol ?  An RFC covering the old
syslog protocol would do this."

Absolutely.  I think that such an RFC might be an informational description
and recommendation, which both summarizes the old UPD/514 syslog mechanism,
and describes security risks -- and then proceeds with recommendations on
how to work within its constraints, given a short list of threat models and
scenarios.

Further work should definitely result in a TCP-based secure syslog that
addresses all or most of the problems that have been mentioned on this
list, but I think we need to address the problem that exists now, and not
wait for a full solution to diffuse into all products  and become standard
practice.

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