Hi Everyone,
I havn't heard back from the IESG about the status of us becoming a working
group, but I think we may as well get things going.
I've written part of the first Internet Draft for the Syslog protocol.
That's the first part of the deliverables from the charter. I've handed
this off to someone who will be able to complete all of the technical bits
of the protocol. The important part of what's below is the security
concerns. Our work is to first discuss these and make sure that we can
identify each of these concerns. Once we have that nailed down, then we
can move on to the next two parts. The draft can also be found online
at:
http://www.employees.org/~lonvick/draft.txt
Alex Brown has been working on a plan for authenticated event notification
since before the DC IETF. I've asked him to monitor this discussion
closely so his plan can address the appropriate security concerns to which
we agree. Once we get agreement on the security concerns of this draft,
then I'll ask him to post his proposal to the group and we can start
discussing that.
The Intrusion Detection Working Group (idwg) has proposed a protocol to
transport their messages. I talked about this with Mike Erlinger, one of
the chairs of that working group. He asked that we keep this in mind
when we start discussing a protocol that will carry authenticated event
messages with verifiable delivery. That draft is the Intrusion Alert
Protocol (IAP) and is posted at:
http://www.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt
I said that we would look at this when the time comes. That won't, however,
be until after we fully agree to the concerns that we have in the current
Syslog protocol and get some agreement on how those concerns need to be
addressed. If we can use their work, that will be great. We are not at
a point now to look at it properly. I bring this up now so that we can
keep this in our minds as we go forward.
As I said, let's get the ball rolling on this. I would appreciate your
comments on the draft below. This is rough -and I'll spend some time
polishing it- so please be somewhat forgiving. :-)
Thanks,
Chris
------ Draft of Syslog Internet Draft ----------------------------------
Internet Engineering Task Force Syslog
Internet Draft
draft
May 8, 2000 Expires: September, 2000
Syslog Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1 Introduction
Since the beginning, life has relied upon the transmission of
messages. For the self-aware organic unit, the messages can relay
many different things. The messages may signal danger, the presence
of food or the other necessities of life, and many other things.
In many cases, these messages are informative to other units and
require no acknowledgement. As people created processes and
machines, this same principal was applied. As an example, a whistle
from a locomotive alerted people that the train was nearby. The
assumption was that people in the vicinity would be able to hear the
sound and that they would be able to realize its significance. No
responding acknowledgement was required or even desired.
Along these same lines, operating systems, processes and
applications were programmed to send messages of their own status.
These messages generally had local significance to the machine
operators. As the operating systems, processes and applications grew
ever more complex, systems were devised to categorize and log these
diverse messages and allow the operations staff to more quickly
differentiate the notifications of problems from simple status
messages. The Syslog process was one such system that has been widely
accepted in many operating systems. It's design was to allow some
flexibility to the operations staff so that they may configure the
destination of messages sent from the processes running on the device.
The Syslog process was also built to be network aware since it was
realized that the operators of the machines on the network would not
be able to access each machine in their domain to review the logged
messages. The Syslog process on one machine required the ability to
transmit these messages generated by the processes on that machine
to a machine that could collect those messages. The operators would
then be able to review the messages from multiple machines on a
single machine.
The Syslog protocol is an event notification protocol that allows
a machine to send event notification messages across IP networks
to event message collectors -also known as Syslog servers. No
assumption is made upon the contents of the messages. The protocol
is simply designed to transport these event messages. In all cases,
there is one device that originates the message and, if appropriate,
sends the message to a collector. If it is configured to do so, the
collector may subsequently also forward it to a further downstream
collector.
1.1 Events and Generated Messages
The writers of the operating systems, processes and applications
have had total control over the circumstances that would generate
any message. In some cases, messages are generated periodically to
give status. These can be either of a certain periodicity of time,
or at some other interval such as the invocation or exit of a
program. In other cases, the messages may be generated due to a
set of conditions being met. In that case, either a status message
or a message containing an alarm of some type may be generated.
The contents of a message have also been at the discretion of its
creator. It has been considered to be good form to write the
messages so that they are informative to the person who may be
reading them. It has also been considered good practice to
include a timestamp in the messages. However, neither of those
are required.
Just about any process can generate an event message. This may
include processes on machines that do not have any local storage
- e.g. printers, routers, hubs, switches, and diskless
workstations. In that case, it may be imperative that event
messages are transported to a collector.
1.2 Operations of the Message Collector
It is beyond the scope of this Internet Draft to specify how
event messages should be treated, handled or processed. It
was considered that the writers of the operating systems, processes
and applications would quantify their messages into broad
categories so that the operations staff could receive the more
important and time sensitive messages quickly, while also having
the ability to place status or informative messages in a file for
later perusal.
The Syslog process on the collecting machine should have the
ability to specify the disposition of received messages. In many
cases, the administrative staff may want the messages to be sorted
based upon some criteria in the message, such as the level or
facility. They may want certain messages that have local
importance to be sent to a file. In other cases, they may want
very important messages sent to a device such as the console. In
certain cases, they may want messages to be forwarded to another
collector.
2 Transport layer protocol
Syslog uses the user datagram protocol (UDP) [1] as its underlying
transport layer mechanism. <more would be better - convenience and
portability?>
3 Overall operation
<need input>
4 Protocol parameters
<need input>
5 Security Considerations
The Syslog protocol is intended to be used for carrying event
notification messages quickly and simply. In its initial
configuration, the Syslog process places event notification messages
into files on that system. This relies upon the integrity of the
system for the protection of the messages. The subsequent
configuration of the Syslog process to use the Syslog protocol to
transport the messages to another collector was an extension of the
delivery of event notification messages and exhibited the same trust
of the network. As such there are some concerns about the
applicability of this protocol in situations that require robust
delivery.
5.1 Message authenticity
The Syslog protocol does not strongly associate the message with
the message sender. Any device can generate any Syslog message
and send it to any other machine through the Syslog protocol. The
receiver of that packet will not be able to ascertain that the
message was indeed sent from the reported sender, or if the packet
was sent from another device.
One possible consequence of this is that a misconfigured machine
may send Syslog messages to a collector representing itself as
another machine. The administrative staff may become confused
that the status of the supposed sender of the messages may not
be accurately reflected in the received messages. The
administrators may not be able to discern that there are two
machines representing themselves as the same machine unless they
view the packets on the wire.
Malicious exploits of this vulnerability have also been noted. An
attacker may transmit Syslog messages (either from the machine that
the messages purport to be sent from, or from any other machine) to
a collector. The attacks that have been noted run along these
lines:
- An attacker may perform a Denial of Service attack by filling the
disk with false messages, or otherwise overwhelming the collector
by sending more messages than it can receive or process.
-An attacker may hide the true nature of an attack amidst many other
messages. As an example, an attacker may start generating messages
indicating a problem on some machine. This may get the attention of
the system administrators who will spend their time investigating
the alleged problem. During this time, the attacker may be able to
compromise a different machine, or a different process on the same
machine.
-An attacker may generate false Syslog messages to give untrue
indications of status or of events. As an example, an attacker may
stop a critical process on a machine which will generate a
notification of exit. The attacker may subsequently generate a
false notification that the process had been restarted. The system
administrators may accept that misinformation and not verify that
the process had indeed been restarted.
5.2 Sequenced delivery
The Syslog records are usually presented (placed in a file,
displayed on the console, etc.) in the order in which they are
received. This is not always in accordance with the sequence in
which they were generated. As they are transported across an IP
network, some out of order receipt should be expected. This may
lead to some confusion as messages may be received that would
indicate that a process has stopped before it was started.
Also, without any sequence indication, messages may be recorded
and replayed. An attacker may record a set of messages that
indicate normal activity of a machine. At a later time, that
attacker may remove that machine from the network and resend
the Syslog messages to the collector. The administrators would
find nothing unusual in the received messages and their receipt
would again indicate normal activity of the machine.
5.3 Reliable delivery
As there is no mechanism within the Syslog process to ensure
delivery, and since the underlying transport is UDP, some messages
may be lost. They may either be dropped through network
congestion, or they may be maliciously intercepted and discarded.
The possible consequences of the drop of one or more Syslog
messages cannot be easily determined. If the messages are
simple status updates, then their non-receipt may either not be
noticed, or it may cause an annoyance for the system operators.
If the messages are more critical, then the administrators may
not become aware of a developing and potentially serious
problem. Messages may be intercepted and discarded by an
attacker as a way to hid unauthorized activities.
5.4 Message integrity
Besides being discarded, Syslog messages may be damaged in
transit, or they may be maliciously modified by an attacker.
In either case, the original contents of the message will not
be delivered to the collector. If an attacker is positioned
between the sender and collector of Syslog messages, then he
may be able to modify those messages to hide unauthorized
activities.
5.5 Message observation
The Syslog messages are generated in human readable form and
capable administrators should be able to understand their
meaning. Unfortunately, as they are passed across a network,
an attacker will also be able to observe the message
contents of Syslog messages. The attacker may then use the
knowledge gained from those messages to compromise a
machine.
6 Acknowledgements
8 Bibliography
[1] J. Postel, "User Datagram Protocol," Request for Comments
768 (STD0006), Internet Engineering Task Force, Aug., 1980.
A Author's Address
B Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
