Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jul 1997 10:56:29 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Adam Shostack <adam@homeport.org>
Cc:        security@FreeBSD.ORG
Subject:   Re: secure logging (was: Re: security hole in FreeBSD)
Message-ID:  <Pine.BSF.3.95q.970728095550.3000G-100000@cyrus.watson.org>
In-Reply-To: <199707281340.JAA03478@homeport.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, Adam Shostack wrote:

> | I don't know of any; if you run across one or are thinking about
> | designing one, please post or mail... absent any other readily
> | available secure mechanism probably the best bet is to carry log data
> | over ssh. Of course, this doesn't solve the denial of service issue as
> | anyone with a login can spam the local syslog.
> 
> I've been working on a draft set of requirements--very drafty, but
> since the subject came up, I'll share & ask for feedback.
> 
> 
> Requirements
> 
>       Reliability: The system must make substantial efforts to not
> 	lose information.  
> 
>             Network Requirements 
>             TCP based 
>             Application sequencing with explicit ack before sender deletes 
>             Application Reliability 
>             NO data discarding 
>             Solid message handling locally-messages kept until discard
>             Repeated message management (?) 
> 
>       Portability 
>       External Alerting 
>       External Intrusion Detection linking 

My initial thought on the matter was a simple MD5 hash/signature on it
based on a shared secret.  Also, as I thought a bit on it, I became
concerned with reliable delivery, sequencing, replay protection, etc.  TCP
indeed becomes the transport of choice for secured syslog messages, as
well as some simple authenticity function.  Is MD5 too heavy-weight to use
in this environment?  Olafur Gudmundsson (TIS) and myself (also TIS) have
recently been working with the Transaction Signature draft for DNS (TSIG),
and maybe some similar function could be applied.  In the new TSIG draft
(due out relatively soon), there is a description of a TCP-based signature
system where signatures are made over the concatenation of previous
seignature, new data, and timing information.  This doesn't allow for your
specific ACK, which I agree is needed.  TSIG provides signatures over the
body of a transaction, and in the case of TCP aborts the transaction,
which may not be appropriate.

As a loghost, I wish to be able to verify the following:

1. Network log data comes from an entity I wish to accept log data for
(probably determined using a DNS FQDN of some type, possibly a hostname,
possibly some other entity name.)

2. Network data has not been modified, inserted, lost, or spoofed in any
nasty way.  Retransmission should be requested if data is modified.

This prevents logs from being flooded with spoofed or false data by hosts
or entities that are inappropriate, and provides reliable transmission.
This doesn't address log management, which is an on-host issue.  Changing
current syslog behavior is desirable here: authenticated log entries
should be stored with some indication of how they were authenticated, and
what identity against.  Changing the behavior of syslog concerning
accepting arbitrary log messages from arbitrary entities on a host would
also be nice.  All log entries submitted by logger (etc) should be
associated with a user ID; types and levels of log entries submitted
should be restricted/able.

Hopefully, the authentication system will allow forwarding of log messages
to a log host indirectly.  How this is managed may vary on the needs.
Should the behavior be:

Forward all messages, let the log host sort out which to keep
or
Forward only authenticated messages from a host

The first means only the server has to be configured in order to restrict
host entries, the seconds requires that intermediate servers also do
authentication checking.  On the other hand, a flood of bogus log messages
would take out the forwarder, but not the server in the forwarder
verification case?  Some thought may be required here.

Just some thoughts -- I haven't really given the issue much thought other
than the decision to ask if anyone else had worked on it :).  Secure
logging is clearly desirable, though.

  Robert N Watson 

Junior, Logic+Computation, Carnegie Mellon University  http://www.cmu.edu/
Network Security Research, Trusted Information Systems http://www.tis.com/
Network Administrator, SafePort Network Services  http://www.safeport.com/
robert@fledge.watson.org   rwatson@tis.com  http://www.watson.org/~robert/




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970728095550.3000G-100000>