Date: Mon, 28 Jul 1997 13:08:43 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Adam Shostack <adam@homeport.org> Cc: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>, dholland@eecs.harvard.edu, security@FreeBSD.ORG Subject: Re: secure logging (was: Re: security hole in FreeBSD) Message-ID: <Pine.BSF.3.95q.970728123328.3342D-100000@cyrus.watson.org> In-Reply-To: <199707281604.MAA04611@homeport.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, Adam Shostack wrote: > Rodney W. Grimes wrote: > > | How are you going to handle the log server going away and coming back?? > > The client will have to queue messages. Its possible that TCP > message queueing will handle this, its also possible that the > application will need some retransmit smarts, which would be > unfortunate, since it adds a good deal of complexity. I doubt TCP queuing will be sufficient -- if the TCP connection is severed for some reason, I don't want my data to be quietly eaten. The specific ACK'ing of all data before clearing it from the queue seems to be a must. It also adds an additional level of data insertion checking. The added complexity is unfortunatee, but seems necessary. To decrease load on forwarding syslog daemons, the daemon should only retain for forwarding log messages that are authenticated. What should be the behavior of syslog if its queue gets extremely large, and it has lost contact with the loghost? Ideally, only the loghost itself should make decisions regarding discarding data, as it would have the policy stored in its .conf file. However, hosts choosing to use network logging may only want to exports certain types of log messages from their own logger. Is it acceptable to have a forwarder filter log messages according to its own logging rules? Should this be a best-effort arrangement? It is not desirable for me to be able to shut down a site by severing its forwarding connection somehow, and then filling up the forwarding host, but I shouldn't lose messages unless absolutely necessary. I'd rather have the forwarder save them in a file and delivery them later, which is sounding increasing sendmail-like. Perhaps we should add another field that has bits to define the requirement that a given log message be transmitted using authenticity, confidentiality, and whether it is worth being stored. In any situation where there was significant doubt, the message would be discarded for security reasons, or logged locally and a message passed later to indicate the problem. Also, should authenticity by against a global name space (DNSsec), and then permission to store messages from a given identity by defined against that name space, or should it be for transaction-level only? I'd almost be tempted to define a wrapper packaging for syslog messages like so: u_int16_t sl_flags u_int8_t sl_prot_type u_int8_t sl_entity_len u_int8_t sl_entity[] u_int32_t sl_timesigned u_int16_t sl_type u_int16_t sl_priority u_int16_t sl_msglen u_int8_t sl_message[] u_int8_t sl_signature_len u_int8_t sl_signature[] Where the signature is over all values present except for the signature+length itself. Type of protection used would be in the protection type field. This would allow storage of complete log entry entities, including the signing identity, signature that proves it signed the data, priority, etc. This would not provide for guarunteed delivery- -- that would be the responsibility of the transport mechanism used by syslog. This could actually by the stored log entry used on syslog servers. To prevent replay (if not provided by the transport), perhaps a sl_log_id (u_int16_t?) could be provided, which would also indicate jumps in the sequence, etc. > Should there be a capability for multiple log servers (like > mail?) Hmm. Multiple destinations yes, but I'm not sure about choosing log servers for load balancing, or backup purposes. Maybe we are looking at an alternate LH RR-type in DNS? A single name, loghost.watson.org would have loghost IN LH 10 loghost.watson.org. IN LH 20 logback.watson.org. A TCP session would remain established as long as it could, and if further connections failed, would bounce to the next in the sequence? I'm not sure how to rectify the split log arrangement where bits of log end up all over the place. On the other hand, I don't want to lose log entries when my main loghost reboots or loads a new syslog version. Load balancing could be arranged using two LH entries with the same level...? This benefits here seem spotty, but it would be a useful function if a more elegant mechanism can be devised -- preferably one not this complicated? :) The more complicated it is, the more likely it will have a problem and be required to log its errors :) > | > Application Reliability > | > NO data discarding > | > Solid message handling locally-messages kept until discard > | > Repeated message management (?) > | > > | > Portability > | > External Alerting > | > External Intrusion Detection linking > | > | Security: The data over the network must be unreadable > | unless a secret is known. Syslog data can contain > | confidential information. > > Is confidentiality or authenticity important? For my > purposes, its authentication. Should we simply allow the use of IPsec > or SSH port forwarding for confidentiality and authentication? It > cuts complexity substantially. Confidentiallity should be option, but available. Authentication errors, as well as serious debugging errors (etc), should not pass unencrypted on the line. It might even be ideal to be able to specify whether a particular log level or type required confidentiality -- I could lower the cost of logging by not requiring mail.* entries to be confidential. Correct me if I'm wrong, but I don't believe UDP over IPsec does not provide replay protection, retransmission, etc. I think it just provides authenticity and integrity protection, as well as confidentiality. It doesn't provide TCP-esque ordering, etc. IPsec protecting TCP would provide this feature. IPsec seems like a good tool, but it is not widely available yet, so I'd rather not rely on its being there, for now. It also doesn't provide a keying mechanism, relying on some key distribution system, as well as ISAKMP/Oakley. I'm not sure what the current implementations look like, so I don't know how simple it would be to implement. SSH may offer too much overhead, providing some but not all of the features required? I haven't work with SSH on the programming side, only on the application side, so am not familiar with it as a tool for this type of activity. Could someone provide an evaluation of SSH in terms of providing the requirements we've discussed? > > | How about just converting syslog/syslogd to handle a kerberized > | t/tcp connection?? > > Syslog still discards data when its local daemon cache gets too full. > It discards data when forwarding messages from host a via host B to > host C. (Yes, real case.) It loses priority and type when putting > messages into files I feel that, in file format, log data should retain all of the features it had when generated, in addition to authenticity information attached by the loghost. > Not that kerberizing a TCP based syslog would be bad, I just don't > think its sufficient. I suspect there are a number of other complications in kerberizing syslog, including the identities taken on by various parties generating the log messages? 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.970728123328.3342D-100000>