Hi Alex,
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
some versions will only accept 1024-bytes of the message. That may be
an artifact which we may be able to change 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. Is this behavior
acceptable to the group?
- What value do you use for the "chain" for the first packet generated?
- 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 delimeter 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?
- 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
---vvv--- Alex Brown's proposed ID ---vvv---
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]
Wed Jul 19 08:00:00 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; these problems are discussed and
strategies for cautious use of the service are recommended. This document is
a draft of an Internet Draft recommending a Best Common Practice for use of
syslog. Distribution of this memo is unlimited.
Chris> The charter ( http://www.ietf.org/html.charters/syslog-charter.html )
Chris> says that we're 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 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.
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 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 [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.
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.
4. Improved practice
Recommended improved practies include:
Add basic security and authentication information to message text in
syslog client implementations.
Add filtering of messages based on basic security and authentication
information in text, to syslog server implementations.
4.1 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
header or in message text.
Chris> The second one may be operationally problematic. Scaling
Chris> will be an issue if "clients" are added faster than the
Chris> access-control list can be updated. Perhaps a note of that
Chris> may be appropriate here?
4.2 Authentication filtering enhancements
A cryptographic hash in the message text using a secret shared between
client and server can provide authentication, making it possible to
filter out falsified syslog messages. (The shared secret string must
be initialized in the originating device in some secure way during
installation.) By adding chaining of hash codes 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 [CSL98], [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 hash value can be added by the
client to existing log message text, as an optional feature, and
interpreted by a syslogd filter, or by a postprocessor filter.
The following are examples of security enhancement extensions to both
client and server (or analysis filters) in a syslog environment. Syntax
of the examples follows the general approach of [ULM99]. (Long hex
string values are line-wrapped for presentation here only.)
Chris> I think that it's all messages are wrapped for presentation
Chris> here. -not just hex ones.
Authentication field within message text
If a shared secret is provided between log client and log host, a message
authentication code (MAC, e.g. HMAC-MD5) 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 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):
Nov 5 14:14:54 zorilla PAM_pwdb[509]: (login) session opened \
for user abrown by (uid=0) nonce=941841456 \
md5=227c40a6cde84f49bfad43c412490110
Chained authentication
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 prior MAC value is available. A missing or
corrupted record or a gap can be identified but not recovered.
Chris> See notes above.
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. References
[LOG00]
C. Lonvick, "Syslog Protocol."
The Internet Society, July 2000. Available from
ftp.ietf.org/internet-drafts/draft-ietf-syslog-syslog-0.3.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.
[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
7. Author's Address
Alex Brown
3Com Corporation
Three 3Com Drive
Marlborough MA 01752
Phone: (508) 323-2283
EMail: [EMAIL PROTECTED]
Table of Contents
1. Introduction
1.1 Status of this Memo
1.2 Copyright Notice
2. UNIX syslog as a de facto standard logging protocol
3. Current practice
4. Improved practice
4.1 Basic security enhancements
4.2 Authentication filtering enhancements
4.2.1 Authentication field within message text
4.2.2 Nonce field within message text
4.2.3 Chained authentication
5. Security Considerations
6. References
7. Author's Address
At 12:21 PM 7/25/00 -0400, Alex Brown wrote:
>Thanks for your comment -
>
>You're right, of course; a stronger and more compact authentication hash code
>is possible; but the intent was to establish only an authenticated predecessor
>for each line, not an authenticated stream. Each message is authenticated
>independently by concatenating a shared secret as well as the chain value in
>the hash; there is thus both an initial K(0) and the shared secret, known to
>source and sink. The explicit chain value makes it possible to resume an
>interrupted sequence (and to trace a sequence manually).
>
>This probably should be made clearer in the writeup.
>
>Alex
>
>Balazs Scheidler wrote:
>
>> On Wed, Jul 19, 2000 at 05:04:36AM -0400, Alex Brown wrote:
>> > This is not yet in proper RFC form, but it should suffice to restate the
>> > case for improved practice within an existing syslog environment. All
>> > comments are welcome.
>> >
>> > http://www.msg.com/~abrown/draft-syslog-auth.html
>>
>> This is the format you suggest:
>>
>> 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
>>
>> I don't think we need two md5 hash for each log line (chain= and md5=) We
>> could simply include the chain value implicitly in the value of md5. Here's
>> the formula to use:
>>
>> M(i) is the ith message, CK(i) is the check value to be appended to the
>> message, and K(i) is the chaining value kept private. Given a K(i) you
>> derive the values of CK(i) and K(i+1) the following way:
>>
>> (1) CK(i) = H(K(i) || M(i))
>> (2) K(i+1) = H(K(i) || CK(i))
>>
>> So CK(i) depends on the contents of the message being sent, and the private
>> chaining value which depends on all previous messages. K(i) is never sent
>> through the wire, but is recalculated on each side when verifying messages.
>> The initial value K(0) is the key, which needs to be stored at both sides,
>> and which ensures message authenticity.
>>
>> And also we may also want to seperate the hash values from the logline, for
>> instance by sending the hash values in the next line.
>>
>> --
>> Bazsi
>> PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
>> url: http://www.balabit.hu/pgpkey.txt
>
>--
>Alex Brown
>http://orbiter.ne.3com.com/abrown.html
>POB 341 Hopkinton MA 01748-0341 Two 3Com Drive - Marlborough MA
>+1 617 504 8761 +1 508 323 2283 voice 1111 fax
