As usual, Notes mail has got line terminations wrong. Here's an attachment
version of the text file.
(See attached file: draft-syslog-bcp.txt)
Sent by: Alex Brown <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (Alex Brown/US/3Com)
Subject: draft-syslog-bcp
Network Working Group A. Brown
Request for Comments: nnnn 3Com MSD
Category: Best Current Practice 25 Oct 1999
Security issues in network event logging
Status of this Memo
This document is a draft Internet Best Current Practice for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Table of Contents
[tbs]
1. Overview
Network systems supporting a variety of protocols and services need to
be able to "log" or record those protocols' important events, both
locally, in persistent storage within the system where the event occurs,
and through messages to a remote system where persistent storage takes
place. This logging process has several distinct phases: detection of
the event, local storage of event record, construction of remote log
message, transmission of log message as log protocol client, reception
of log message at log protocol server,
timestamping/filtering/manipulation of log message, storage of log pro-
tocol message as event record in a file; and finally, filtering,
retrieval and analysis of events by a offline program or a human.
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 only for local event
logging within a UNIX host, and only later grew into a general network
log service.
[Historical details TBS as desired.]
Because of this close relationship, the following description assumes a
UNIX system environment. Other system environments have also imple-
mented syslog clients and servers, notably network devices such as
routers, switches, and firewalls.
2. UNIX syslog as a de facto standard logging protocol
UNIX syslog is both an API and a very simple protocol, for persistent
storage of text messages, used throughout UNIX network service software.
It is best described by reference to the syslog(3) manpage documentation
(see Appendix).
Syslog as an API provides minimal structure for an error or notification
message: a user of the API calls openlog() to set an enumerated "facil-
ity" identification number and an "options" flag indicating some proper-
ties of the UNIX domain socket connection to the local log server pro-
cess, syslogd -- including direct write to console if syslogd is una-
vailable. The syslog message is formed by the syslog() library routine
as a text string formed with sprintf(3S) with an added "%m" format
available for insertion of the message associated with the current
"errno" error number variable. The facility ID value (upper bits) and
an enumerated priority value (lower bits) are IOR'd to form a 16 bit
word value which is placed at the head of the message within angle
brackets, followed by the string output of ctime() as a timestamp. The
message text is concatenated to this header, and the resulting text mes-
sage is sent to the local "syslogd" log server process using send(3N).
This message may also be written to the user's standard error file out-
put, and/or the system console, independent of the syslogd process.
Syslog as a network message transport is an extension of local file log-
ging by syslogd, through its configuration file, syslogd.conf (see
Appendix) which is a semicolon-separated list of priority specifications
consisting of a selector followed by an action. A selector is a list of
the form "facility.level [ ; facility.level ]", where facility is a sys-
tem facility name (as used in openlog(3)) or comma-separated list of
facilities, and level is a name of one of the enumerated values (used as
first argument to syslog(3)) indicating the severity of the condition
being logged. The action is a list of one or more filenames, usernames,
or remote host names (identified by prefix "@"). If the action includes
a remote host name, the message is forwarded to the named host via UDP,
to port 514 (as assigned by IANA, and configurable). The syslogd pro-
cess (if any) at that host will receive the message and dispose of it
according to its syslogd.conf configuration, possibly including
forwarding.
Various ad hoc corrective features in this process, including loop
detection in forwarding, and filtering of improperly formed messages and
adding timestamp and priority and facility tag if not found, are present
in some but not all versions of syslog() and syslogd.
3. Past and current practice in security applications
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 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. As network installation
size grows, and administrators are responsible for more and more system
activity, forwarding 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 suspicious
activity such as continuous login attempt failures.
4. Security concerns
Syslog within a UNIX system has relatively few security problems, if
configured and managed properly, using appropriate file permission set-
tings. Network syslog messages, however, have no such access control
mechanism, and any host can attempt to send real or falsified syslog
messages to udp/514 at any other host IP address. If a UNIX system at
that address is running syslogd configured to listen to that port, the
handling of that message will take place according to its configuration,
which will typically include logging to a file, even if the message is
only partly recognizable. This leads directly to the most common sys-
logd denial of service attack, file space exhaustion. Most syslogd
implementations will simply drop log messages that can't be recorded,
and an attacker can then attempt repeated logins unobserved. To prevent
such external attack, firewalls typically filter udp/514, but internal
attack is still possible.
Even if a flood of syslog messages is not enough to exhaust file space,
the attacker can construct spoofed IP headers to create login failure
attempt messages appearing to occur at many, perhaps all, hosts in the
network, to conceal the actual location of the attack by a form of
"chaffing".
Other syslogd vulnerabilities are even more serious. The most important
is really a coding error: some early implementations of syslogd used a
relatively short buffer on the stack, and did not check for buffer over-
flow. This made it possible to kill a syslogd process with packets to
udp/514 that were simply larger than this buffer. Since UDP transport
is unreliable, log clients would have no indication that the destination
log host was no longer available, and access probing could again proceed
unobserved.
Still worse, some implementations on some processors made it possible to
use this stack overflow to capture the executing syslogd process, run-
ning with root privileges, and execute code such as shell scripts with
no restrictions.
There is also some potential of falsifying legitimate syslog messages --
e.g. following an observed alarm message from an access server with a
falsified alarm-off message.
Finally, if an attack is indeed successful and the attacker has root
privileges, the log files themselves are accessible, allowing the
attacker to modify them to conceal records of the attack and any follow-
ing entries, because each line of a log file is an independent event
record and can be deleted without affecting other event records.
[Others TBS]
5. Improved current practice
Syslog is still the most widespread and usable tool for event logging,
esp. because it is a low-cost protocol that can be easily added to net-
work and embedded devices. Strategies for cautious use include:
Examine syslog() and syslogd source code and recode as necessary if
possible to remove known vulnerabilities.
Syslogd code can be altered for improved filtering and handling of
application-specific messages. This has been widespread in the UNIX
and Open Source community, with modified versions of syslog() and
syslogd sometimes distributed with other applications -- e.g. INN.
Firewall filtering of udp/514 can isolate syslog regions within a net-
work as well as inside from outside.
Syslog hosts can be provided with disk capacity far exceeding normal
needs.
Syslog configuration can use non-IP interfaces between log hosts, e.g.
serial links, to keep the loghost out of the ARP tables of a possibly
compromised access host.
[Others TBS]
6. Cryptographic security enhancement 1: Authentication field within
message text
If a shared secret is provided between log client and log host, a mes-
sage authentication code (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, the shared secret, and a random nonce placed in plain-
text in the message. The log host syslogd may be recoded to filter on
this MAC in real time so that bogus messages never reach the logfiles,
or, if the vendor's syslogd can't be replaced, filtering may take place
offline.
7. Cryptographic security enhancement 2: Chained authentication
The nonce may be replaced with the last MAC sent from the log client,
making it possible to detect a gap in the syslog stream from a client.
8. Other security enhancements 3..n:
[TBD]
9. Replacement
Syslog should be supplemented or replaced with a more robust standard
network logging protocol as soon as is practical. This protocol should
recognize the existing prevalence of syslog but may follow a completely
different design. Security concerns including the above should be
foremost in redesign and implementation.
10. Discussion
[TBS]
11. 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.
12. References
[TBS]
13. Author's Address
Alexander S Brown
3Com Modular Systems Division
Three 3Com Drive
Marlborough MA 01752
Phone: (508) 323-2283
EMail: [EMAIL PROTECTED]
