From owner-freebsd-security Mon Jul 28 07:56:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA10815 for security-outgoing; Mon, 28 Jul 1997 07:56:48 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA10808 for ; Mon, 28 Jul 1997 07:56:46 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id KAA03275; Mon, 28 Jul 1997 10:56:30 -0400 (EDT) Date: Mon, 28 Jul 1997 10:56:29 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Adam Shostack cc: security@FreeBSD.ORG Subject: Re: secure logging (was: Re: security hole in FreeBSD) In-Reply-To: <199707281340.JAA03478@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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/