At 10:35 PM 10/8/00 -0400, Alex Brown wrote:
---remainder deleted for brevity---
Hi Alex and group,
I have some additional thoughts about this. In no particular order:
- You assume that this will be an extension of the existing syslog protocol
rather than defining a new format (with new udp port). I support this
but I'd like to see it articulated in the ID. I'll also accept any
discussion of this on the list if anyone sees any problems with this.
- We discussed the length field and I think that we all have found that
current versions will only accept 1024-bytes of the message. That is
defined in the current syslog ID but it may be that this can be changed
with this ID. I would still like to see a maximum length described in
this ID for this new-style message format.
- I'd like to see a discussion of the acceptable behaviors of the
receiver. I think that there will be some cases which need exploring.
A new style receiver may accept old-style or new-style messages or both.
It may reject new-style messages that don't have a correct MAC or it
may accept them for later study but not place them in the repository
with other acceptable messages. (It may place incorrect messages in a
lifo file with a fixed and unexpandable size.)
- The thought of using the chain works well in a system with sequenced
delivery. However UDP won't ever provide that so we may see a behavior
of the following:
msg1 --------------------> received as A
msg2 --------\ /---------> received as B
msg3 --------/ \---------> received as C
msg4 --------------------> received as D
The receiver would find the "chain" for A and cache it. It would find
B but find that the "chain" indicates that it did not come immediately
after A. It would cache the "chain" value from B and then receive C.
If would find that the "chain" value indicates that C did not come
after B but it would cache the "chain" value for C and then receive D.
Again, D did not come after C. This could be re-ordered with a bunch
of post processing. However, let's take this case:
msg1 --------------------> received as A
msg2 --------------------> received as B
msg3 ----X-dropped
msg4 --------------------> received as C
msg5 ----X-dropped
msg6 --------------------> received as D
msg7 ----X-dropped
msg8 --------------------> received as E
msg9 --------------------> received as F
There would be nothing to confirm the order of C relative to D. The
indication would be that there were gaps between B and F and that
both C and D were received in that time period however, it could not
be reliably said that C was generated before D. Your note about the
sequence number could change this behavior and I'd like to see that
explored.
- The names that you have in the extended format will probably collide
with values found in normal Syslog messages. Such as:
Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
the values of chain=link md5=type_5_molybdenum \
chain=a6739e57964c9dec7613d663f049c0f7 \
md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
Is it important that the names don't collide or should it be specified
that the processing of the extended format be done from R->L and the
last field must be md5=* and the prior field must be chain=*? Or
should a delimiter be placed after the end of the traditional message
but before the beginning of the extended fields? If we don't use
a delimiter, then what might happen to the receipt of a traditional
syslog message such as:
Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
the values of chain=link md5=type_5_molybdenum
Would it be interpreted to have a bad MAC?
- Would it be acceptable to use some of the unused or reserved values of
the current syslog priority values to differentiate between this "new"
format and the "traditional" format?
- Is this going to be limited to md5 or are other hash algorithms going
to be accepted?
- You note that the FQDM or IP address should be used in the message
but your example only lists it in hostname format. Would it be
better to just rely upon whatever current information is held
within the traditional message, or would it be better to have this
as an additional field in the extended format? For example:
Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
the values of chain=link md5=type_5_molybdenum \
FQDM=zorilla.example.com \ chain=a6739e57964c9dec7613d663f049c0f7 \
md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
or
Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
the values of chain=link md5=type_5_molybdenum |
IPV4=10.1.1.1 \ chain=a6739e57964c9dec7613d663f049c0f7 \
md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
or
Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
the values of chain=link md5=type_5_molybdenum |
IPV6=bigaddressstuff \ chain=a6739e57964c9dec7613d663f049c0f7 \
md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
- Should the ID note that any attempt to perform NAT address conversions
in the extended format fields will mess up the md5 value. It would be
a good practice to not share the key with any NATificators.
- All of this may be somewhat interesting (which may or may not be a
problem but should be discussed in the ID ;-). Let's say that Device
A is configured as follows:
*.emerg @server1
*.alert @server1
*.alert;auth.warning @auth-server
So let's say that daemon fires off an emergency level message to
server1 and then lpr also sends an emergency message to server1.
To further complicate things, let's say that server1 was configured
as such:
lpr.emerg /var/log/lpr-emerg
*.emerg /var/log/real-emerg
The messages will be sent to their order but not filed in the same
file. Post processing will not be able to sequence them correctly
unless the two files are merged. Is this OK? If so, then it would
be good to note that.
- From that, what happens in this case. Machine A has the following
configuration:
*.emerg @server1
And the machine server1 has the following configuration:
*.emerg @server2
Should an additional chain and md5 be placed at the end of the
whole message which already has the chain and md5 from machine A?
I would vote that server1 should discard the chain and md5 received
from machine A and append its own chain and md5. Both the chain
and MD5 seem to have local significance only. It should be noted
that received messages that don't authenticate properly should not
be forwarded as if they were received with proper authentication.
Some of these questions come from parts of the discussions in RFCs 2082
- RIP-2 MD5 Authentication - 2328 - OSPF Version 2 - and 2385 - Protection
of BGP Sessions via the TCP MD5 Signature Option.
ftp://ftp.isi.edu/in-notes/rfc2082.txt
ftp://ftp.isi.edu/in-notes/rfc2328.txt
ftp://ftp.isi.edu/in-notes/rfc2385.txt
The RIPv2 messages are somewhat similar to this case of trying to
authenticate the messages without verification of receipt. From these
works, I'd ask if it would be better to use a "chain" or to have a
"sequence number"?
I've reformatted your draft to text-only and have added some other
comments below. All replies and additional comments will be
graciously received. I've also changed my "reply to:" address to
be this list. If anyone wants to communicate directly with me,
please use my real address of [EMAIL PROTECTED]
Thanks,
Chris
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Simple authentication of syslog messages for embedded network devices
Chris> I'd recommend changing the title to "Simple Authentication of
Chris> Syslog Messages". We shouldn't relegate the use of this to
Chris> only 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.
Chris> The charter ( http://www.ietf.org/html.charters/syslog-charter.html )
Chris> says that this ID is going for PROPOSED STANDARD. :-)
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.)
Chris> I'd recommend dropping this paragraph. The rest of your paper
Chris> is not that closely associated with Unix environments and the
Chris> proposals are non-OS specific.
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.
Chris> I don't see the point of that paragraph.
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.
Chris> Change "attack sequences" to "problems". The use of syslog is
Chris> not to detect attacks but to record activities. Analysis of the
Chris> records may indicate an attack or some other problem.
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.
Chris> I don't think this matters as we're trying to address all devices; not
Chris> just small/underpowered ones.
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.)
Chris> All the lines are wrapped.
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.
Chris> I don't think that we need to go through the thought process
Chris> examples. An explanation of the reasoning should suffice.
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.
Chris> What is the "security initialization"? Should the administrators
Chris> install an "initial previous MAC value" when they install the
Chris> shared secret? What's going to happen when the client reboots?
Chris> Will it use the "previous MAC value" from the last transmitted
Chris> message, or will it use the "initial previous MAC value"?
Chris>
Chris> Are you suggesting adding a sequence number? If so, where would
Chris> this go in the packet and what would designate it? What would be
Chris> the field length of the value and what would happen upon rollover?
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.
Chris> Don't make excuses for it. :-) When this is fleshed-out, this
Chris> can provide great enhancements over the current syslog.
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.
Chris> This should be expanded to show the potential problems of the
Chris> mechanisms.
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]
