mtr wrote: > hi. two things. first, where/what is "Alex's draft"? Here it is; sorry for the delay. Please note the limited objectives of this writeup, as reflected in title change. I will put it into final form after final comments, and, with the list members' consensus, toss it in the hopper. (I can't attend IETF 49.) > second, do you want me to submit a draft talking about syslog with reliable > delivery using beep? > > thanks, > > /mtr http://search.ietf.org/internet-drafts/draft-ietf-beep-framework-02.txt looks useful as a session layer; an application layer for logging is needed. ;) As I understand it this WG has been discouraged from discussing message formats, although there has been strong interest in XML for structured logs; but this looks like a good match to me. Chris et al: Please note that I am no longer at 3Com and can best be reached at the address and number below. Please remove [EMAIL PROTECTED] from [EMAIL PROTECTED] (I do not yet have a confirmed contact at 3Com to continue their interest in this work.) -- Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761Title: Simple authentication of syslog messages for embedded network devices
Simple authentication of syslog messages for embedded network devices
Alex Brown, [EMAIL PROTECTED]
Sun Oct 8 20:10:38 EDT 2000
Network logging is a security concern because it handles authentication and authorization event information and is itself a potential path for attack. The UNIX syslog service has become a de facto logging protocol for network systems, despite significant security flaws; strategies for cautious use of the service are recommended in this memo. This document is a draft of an Internet Draft recommending a Best Common Practice for use of UNIX syslog. Distribution of this memo is unlimited.
1. Introduction
1.1 Status of this Memo
This document is a draft of an Internet Draft. Distribution of this memo is unlimited.
1.2 Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2. UNIX syslog as a de facto standard logging protocol
As a result of the close relationship between the UNIX operating system and the Internet protocols, the UNIX syslog service has become a de facto logging protocol for network systems, despite severe deficiencies as a protocol, either for a persistent storage service or for protection of critical information about device and service status. This is because the syslog service was provided initially for local event logging within a UNIX host, and only later grew into a general network log service.
(Because of this close relationship, the following description assumes a UNIX system environment. Other system environments also have implementations of syslog, notably Microsoft Windows PCs servers, and clients in network devices such as routers, switches, and firewalls.)
UNIX syslog is both an API and a very simple protocol, for persistent storage of text messages, used throughout UNIX network service software. The protocol and its security issues are described in [LOG00].
In early UNIX and Internet practice, syslog was primarily a local UNIX logging mechanism, which provided a convenient debugging and monitoring facility for software in all parts of the system -- kernel, system applications, and user applications. Logging was often carried out only to the hard-copy system console, to capture transient events leading to a system failure that would destroy the event record before it reached a file.
Syslog is now widely used in network operations to record authentication events, originating both in the authentication agents of UNIX network server applications such as login(1), su(1M), getty(1M), ftp(1) and others, and in network devices such as remote dialup access servers. It has therefore become a security feature of UNIX networks, and is often used in supporting access from user networks of non-UNIX personal computers.
As network installation size grows, and administrators are responsible for more and more system activity, forwarding of syslog messages over more than one hop is widely used to relay event records to a central system, where scripts and other offline analysis tools can be used either periodically scheduled, or interactively, to identify attack sequences. The integrity of both the syslog configuration files, as well as the syslog output logfiles, are therefore also security concerns. Resource limitations for log message traffic on the network, and especially log storage on disk, are significant security vulnerabilities, primarily due to lack of authentication, which would permit a log server to discard bogus messages.
3. Current practice
Syslog is still the most widespread and usable tool for network event logging, and it is especially useful for embedded network devices because it is a low-cost protocol that can be easily added to even the smallest devices. While improved security event logging mechanisms such as Intrusion Alert Protocol [IAP00] can provide far better solutions in the long run, these mechanisms require more cryptographic resources in the originating device than an embedded device can easily afford, as well as coordinated deployment of analyzer and reporting facilities. The following recommendations are for cautious interim use of an existing insecure syslog infrastructure, and are not intended to provide an alternative to a fully secure network logging and intrusion alert facility.
3.1 Best common practice strategies for cautious use of syslog include:
- Provide syslog servers with CPU and disk capacity far exceeding normal needs.
- Check file permissions for all logfiles and syslog.conf at each log host.
- Design network to limit access for udp/514 syslog, and isolate syslog regions within a network as well as inside from outside.
3.2 Basic security enhancements
- Add IP address or DNS FQDN of originator to message text so it's not lost in forwarding.
- Use an IP access list for syslogd to permit receiver to filter all packets not claiming to be from a valid source address, either in IP header or in message text.
4. Improved practice
Recommended improved practies include:
- Add message authentication code (MAC) to message text in syslog client implementations.
- Add filtering of messages to syslog server implementations, based on MAC in text, added by syslog client implementations.
4.1 Authentication filtering enhancements
A cryptographic hash as a message authentication code (MAC, e.g. HMAC-MD5) in the message text using a secret shared between client and server can provide authentication, making it possible to filter out individual falsified syslog messages. (The shared secret string must be initialized in the originating device in some secure way during installation.) However, an attacker will also attempt to suppress individual valid syslog messages. By adding chaining of MAC values in a sequence of authenticated messages, missing messages can be detected and falsified messages can be dropped. Use of chained hash codes for authentication of message sequences is discussed in detail in [PEO95], [CSL98], [PEO98], [SAL99], and [RAL99].
Crypto hash functions, e.g. HMAC-MD5 [RFC1321], are fast and small, and are often present in even the smallest network devices and therefore pose little additional code burden. A MAC value can be added by the syslog client library to existing log message text, as an optional feature, and interpreted by a syslogd filter, or by a postprocessor filter. The added text impacts delivery to an unmodified server only by increasing message length.
The following are examples of security enhancement extensions to both client and server (or analysis filters) in a syslog environment. Syntax of the examples' message text follows the general approach of [ULM99]. (Long hex string values are line-wrapped for presentation here only.)
Authentication field within message text
If a shared secret is provided between log client and log host, a field can be appended to the message text by the log client as an optional extension, computed over the message text excluding the MAC field, and the shared secret (in this case the string "notobvious"):
Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
for user abrown by (uid=0) md5=02ebc80d6d165fb6cdd4cc2520e8192f
The log host syslogd can filter on this MAC in real time so that bogus messages never reach the logfiles; or filtering of logfiles can take place offline. A table of shared secrets for all log sources must be available -- this table is security critical information.
Nonce field within message text
If more than one message with the same text occurs (as is common in syslog) the authentication field can have the same value; this makes a variety of spoofing attacks possible. To reduce the likelihood of messages with identical text, a nonrepeating nonce can be placed in plaintext in the message (same secret, random nonce):
Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
for user abrown by (uid=0) nonce=941841456 \
md5=227c40a6cde84f49bfad43c412490110
This nonce may be a syslog client sequence number within message text, as an aid to identification of sequence gap lengths. However, a sequence number is predictable and may be susceptible to replay and similar attacks.
Chained authentication
To eliminate this vulnerability the nonce may be replaced with the last MAC sent from the log client, making it possible to detect an insertion or gap in the syslog stream from a client (same secret):
...
Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
for user abrown by (uid=0) chain=227c40a6cde84f49bfad43c412490110 \
md5=a6739e57964c9dec7613d663f049c0f7
Nov 5 14:14:55 zorilla PAM_pwdb[509]: (login) session closed \
for user abrown chain=a6739e57964c9dec7613d663f049c0f7 \
md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
...
Each individual record can still be authenticated independently from all others, but also can be sequenced by verifying the "chain" field. The log host syslogd or filter must retain the previous MAC value for each log source. The first record from each source will be unsequenceable, because no previous MAC value is available; however an initial "previous" MAC value can be agreed upon between client and server during security initialization. A missing or corrupted record or a gap can be identified but not recovered. A sequence number can also be added to the message text to identify the length of a gap.
4.2 Limitations
These practices provide authentication for the syslog mechanism but are intended only for cautious interim use of an existing insecure syslog infrastructure, and are not intended to provide an alternative to a fully secure network logging and intrusion alert facility.
5. Security Considerations
This document is primarily concerned with security issues in network logging. Other related issues in UNIX system and network administration are not within its scope.
6. Acknowlegements
The methods described here are a simplified use of chained hash codes for authentication of message sequences, as discussed in detail in [PEO95], [CSL98], [PEO98], [SAL99], and [RAL99]. Thanks are due to John Kelsey, Ivan Arce, Herve Schauer, and Chris Lonvick, who contributed comments.
7. References
[LOG00]
C. Lonvick, "Syslog Protocol" (draft).
The Internet Society, July 2000. Available from
http://www.employees.org/~lonvick/draft3.txt
[IAP00]
D. Gupta, "Intrusion Alert Protocol - IAP"
The Internet Society, March 2000. Available from
ftp.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
[ULM99]
J. Abela and T. Debeaupis, "Universal Format for Logger Messages."
The Internet Society, May 1999. Available from
ftp.ietf.org/internet-drafts/draft-abela-ulm-05.txt.
[PEO95]
Emiliano Kargieman and Ariel Futoransky, "PEO y VCR - Dos
protocolos simples", 25 Jornadas Argentinas de Informatica e
Investigacion Operativa, July 1995.
http://www.core-sdi.com/papers/vcr_peo.pdf
[PEO98]
Emiliano Kargieman and Ariel Futoransky, "VCR and PEO
Revised", October 1998.
http://www.core-sdi.com/papers/peo.pdf
[CSL98]
B. Schneier and J. Kelsey, "Cryptographic Support for Secure
Logs on Untrusted Machines", The Seventh USENIX Security
Symposium Proceedings, USENIX Press, January 1998, pp. 53-62.
http://www.counterpane.com/secure-logs.html
[SAL99]
B. Schneier and J. Kelsey, "Secure Audit Logs to Support
Computer Forensics", ACM Transactions on Information and
System Security, v. 1, n. 3, 1999.
http://www.counterpane.com/audit-logs.html
[RAL99]
B. Schneier and J. Kelsey, "Minimizing Bandwidth for Remote
Access to Cryptographically Protected Audit Logs", Second
International Workshop on the Recent Advances in Intrusion
Detection (RAID '99), September 1999.
http://www.counterpane.com/auditlog2.html
[RFC1321]
R. Rivest, "The MD5 Message-Digest Algorithm".
The Internet Society, April 1992. Available from
ftp://ftp.isi.edu/in-notes/rfc1321.txt
8. Author's Address
Alex Brown http://www.msg.com/~abrown Phone: +1 617 504 8761 EMail: [EMAIL PROTECTED]
