Date: Mon, 28 Jul 1997 11:48:46 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Dug Song <dugsong@monkey.org> Cc: David Holland <dholland@eecs.harvard.edu>, freebsd-security@freebsd.org Subject: Re: secure logging (was: Re: security hole in FreeBSD) Message-ID: <Pine.BSF.3.95q.970728113214.3342C-100000@cyrus.watson.org> In-Reply-To: <Pine.NEB.3.95.970728093724.5120A-100000@naughty.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, Dug Song wrote: > i've looked for years for a secure syslog/d replacement, and the only > thing i've heard of that even comes close is a redirection through an SSH > tunnel. I've been experimenting with SSH as a generic tunneling tool, but have had problems maintaining connections, and determining correct behavior in various situations. It seems like the overhead involved here may be a problem. IPsec might offer some solutions, but isn't generally available just now. DNSsec as a means of IPsec SPI keying sounds good as a general security tool. :) > in our case, we're looking at a Kerberized solution, but this carries way > too much overhead to be useful. what we really want from syslog is Someone else suggested kerberos as a solution, but it has somewhat more limited application than a general-purpose security architecture for syslog. I use Kerberos for my own machines, as well as at Carnegie Mellon, and the overhead seems significant. It also brings up some questions about the identities of the various syslog participants. As an individual, must I have a kerberos principal associated with me to be able to log? Do I need a ticket (probably)? Does this mean storing passwords for the keys on systems that require it (presumably a srvtab of some kind), which might cause additional concerns? In some ways, it would be great to have Kerberos authenticate all log messages -- I could know that this log message can from proto@WATSON.org, or robert.admin@WATSON.ORG, etc. But not everyone runs Kerberos, and there are enough complications to suggest an unkerberized answer might work best. Perhaps we can work in a named-keying system that allows DNSsec keys to be used, IPsec, etc. I'd rather not use a session mechanism, as reinitializing a session can be time-consuming, hard to identify, not to mention inappropriate in some circumstances. Using a set key-name and key is more efficient and easier to design. General-purpose key management is still in the wings, so maybe a short term solution involving just a shared secret is the answer for now? > 1. some degree of auditability, such as local UIDs in each message, to > deter the local denial-of-service attack. this is the best i've come > up with, because syslog() really needs to be available to j. random > process. I'm tempted to disassociate the network security issues and local security issues for now. This is hard to do in a Kerberos environment (and not really useful in a Kerberos environment), but for most people there is a benefit. I was envisioning more of a host-to-host security mechanism for syslog, and then allowing syslog daemons on hosts to do what they wished. Servers would stored the identity of the host based on the keyname (usually of a shared secret) that authenticated the message, and clients could store additional information at their option in the message. In this case, a username or uid. If greater security is needed, keynames can be in the context of a more diversified namespace, such as that of DNS/DNSsec. a log message could come from FQDN, or from identity.FQDN, if a key is configured on the server, and permitted to send the type of log message in question. Use of the DNSsec keyspace isn't really established, yet, though. > 2. some degree of authentication/authorization, as provided by a shared > key between loghost and client machines. session key establishment is > too much overhead, i think. a long-term shared secret is a bad idea > in general but is probably reasonable to consider for this application. > either that, or hourly rekeying, or something else that takes less > work than generating/distributing a new session key for every message. > maybe one of the EKE variants would be appropriate for this (is there > an EKE-like protocol that doesn't do modular exponentiation, BTW)? I agree, and also raises questions if a system reboots, moves, etc. keyname/shared secret pairs are probably the answer unless public/private keying gets a bit faster. Then one could authenticate messages using DNSsec to a name, and a set of names would be permitted to send log messages by a syslog.conf file. E.g., permit fledge.watson.org/145 permit cyrus.watson.org/145 <-- /145 indicates the key footprint to use I retrieve the pub key and verify the packet against it for the first packet, and cache the key for future packets. In a high-volume logging environment, this might be too heavy, in which case a shared secret could be used: permit fledge.watson.org.local HMAC-MD5 xxxxxkeyxxxxxxxxxx permit cyrus.watson.org.local HMAC-MD5 xxxxxkeyxxxxxxxxxx Some form of chunking/clustering of log messages would be especially useful in the pub/private key case. > 3. message integrity, and maybe privacy. HMACs are good, but maybe > something like rc5 would be okay. i just don't want to incur the > overhead of DES or IDEA (maybe this could be configurable?). > > i guess 2 and 3 are only really applicable in the loghost (as opposed to > local logging) scenario. anyhow, i'm just brainstorming here, let me know > if you have any other thoughts on this. Is privacy an issue for logging? It would appear to be for authentication information, as security of logs is important for protecting a host. Especially things like login retries where the username is listed, and might be the password typed at the login: prompt :). I've been thinking only in terms of integrity, but privacy might be important too.. A similar key naming system may work, but choice of algorithms is an issue (not to mention export control :). small keys are probably ok since logs aren't all-that-sensitive? 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.970728113214.3342C-100000>