Hi Folks, I've posted another draft for Syslog and have also attached it below. This one expands the section on Sequenced Delivery (Section 5.2) and I've added a section on Message Prioritization and Differentiation (Section 5.6). If anyone attended the BEEP meeting in Pittsburgh, I would certainly appreciate your thoughts on the applicability of running an authenticated Syslog with verifiable delivery over BEEP. I'm pulling my thoughts together on an overview of how I think that may work. I've also reviewed Alex's proposal. Unfortunately, this was with a pen on paper which doesn't 'send' well. I'll put this into an electronic format and get it out for further discussion rsn. :-) Just as a reminder, please only send text to the mailing list. There are some people who either don't have, or don't want an html-enabled mail viewer so let's be considerate and only pass around text. Many thanks, Chris The draft is also found here: http://www.employees.org/~lonvick/draft4.txt ---latest draft--- Internet Engineering Task Force Syslog Internet Draft draft-ietf-syslog-syslog-0.2.txt August 11, 2000 Expires: December, 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, these 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 to societal communications. As an example, severe weather warnings may be delivered through any number of channels - a siren blowing, warnings delivered over television and radio stations, and even through the use of flags on ships. The expectation is that people hearing or seeing these warnings would realize their significance and take appropriate action. In most cases, no responding acknowledgement of receipt of the warning is required or even desired. Along these same lines, operating systems, processes and applications were written to send messages of their own status, or messages to indicate that certain events had occurred. These event 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. Flexibility was designed into this process so the operations staff have the ability to configure the destination of messages sent from the processes running on the device. In one dimension, the events that were received by the Syslog process could be logged to different files. In another dimension, the Syslog process could be configured to forward the messages across a network to the Syslog process on another machine. The Syslog process had to be built network-aware for some modicum of scalability since it was known that the operators of multiple systems would not have the time to access each system to review the messages logged there. The Syslog process running on the remote devices could therefore be configured to either forward the message to a file, or to subsequently forward it to another machine. In its most simplistic terms, 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. Since each process, application and operating system was written somewhat independently, the messages that were generated were somewhat unique. For this reason, 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. The Syslog process on that machine may send the message to a collector. No acknowledgement of the receipt is returned. 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 is required. It should be assumed that any process on any device might 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 so that they may be recorded and hopefully viewed by an operator. 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 one of several broad categories. This was so that the operations staff could be presented with 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 messages generated by certain processes 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 other cases, they may want messages to be forwarded to another collector. In some cases, they may want messages to be both recorded locally, as well as sent to a collector. 2 Transport layer protocol Syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism. 3 Overall operation 4 Protocol parameters 5 Security Considerations An odor may be considered to be a message that does not require any acknowledgement. People tend to avoid bad odors but are drawn to odors that they associate with good food. The acknowledgement of the receipt of the odor or scent is not requires and indeed it may be the height of discretion to totally ignore some odors. On the other hand, it is usually considered good civility to acknowledge the prowess of the cook. Similarly, various species have been found to utilize odors to attract mates. One species of moths use this scent to find each other. However, it has been found that bolas spiders can mimic the odor of certain female moths. This scent will then attract male moths which will have the expectation of finding a mate. Instead, when they arrive at the source of the scent, they will be eaten. [2] This is a case of a false message being sent out with inimical intent. In its local use, 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 exhibits the same trust of the network. As such there are some concerns about the applicability of this protocol in situations that require robust delivery. Along the lines of the analogy, computer event messages may be sent accidentally, erroneously and even maliciously. At the time of this writing, however, there have not been any reports of any machine consuming any other machine. 5.1 Message authenticity The Syslog delivery mechanism 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 readily discern that there are two or more machines representing themselves as the same machine. Another consequence happens when the event messages are forwarded. Unless the identification of the device is contained within the body of the event message, the source of the message may be lost since it may only be self-identified by its IP address contained in the IP header. It should be noted that some cases of embedding the identity of a device may only have local significance and that may only be ephemeral. The inclusion of a fully qualified domain name in the message may give the Administrators the best chance of identifying the source of each message if it can always be associated with an IP address. However, if the device had obtained an IP address from a DHCP pool, then that association would not always hold true. Malicious exploits of this vulnerability have also been noted. An attacker may transmit Syslog messages (either from the machine that the messages purport from which to be sent 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 of the collector 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 may generate a notification of exit. The attacker may subsequently generate a false notification that the process had been restarted from another machine already under the control of the attacker. The system administrators may accept that misinformation and not verify that the process had indeed been restarted. 5.2 Sequenced delivery As a general rule, the forensics of a network anomaly rely upon reconstructing the sequence of events. In a perfect world, the messages would be received on the Syslog collector in their order of generation from the other devices and anyone looking at these records would have an accurate picture of the sequence of events. Unfortunately, the Syslog process and protocol do not ensure ordered delivery. This section details some of the problems that may be encountered from this. 5.2.1 Single Source to a Destination 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. This may be somewhat rectified if the originating process had timestamped or numbered each of the messages before transmission. To be as effective as possible, both the source of the message and the Syslog collector should both timestamp the messages. In this, both the sending device as well as the collector should utilize the same authoritative time source. It should be remembered, however, that not all devices are capable of receiving time updates, and not all processes timestamp their messages. 5.2.2 Multiple Sources to a Destination In Syslog, there is no concept of unified event numbering. Single devices are free to include a sequence number within the event message but that can hardly be coordinated between multiple devices. In such cases, multiple devices may report that they are each sending message number one. Again, this may be rectified somewhat if the sending devices utilize a timestamp from an authoritative source in their messages. As has been noted, however, even messages from a single device to a single collector may be received out of order. This situation is compounded when there are several devices configured to send their Syslog messages to a single collector. Messages from one device may be delayed so that messages from another device are received by the collector even though the messages from the first were generated before the messages from the second. If there is no timestamp or sequence number, then the messages may be presented in the order in which they were received which may give an inaccurate view of the sequence of actual events. 5.2.3 Multiple Sources to Multiple Destinations The plethora of configuration options available to the network administrators may further skew the perception of the order of events. It is possible to configure a group of devices to send the status messages -or other informative messages- to one collector, while sending messages of relatively higher importance to another collector. Additionally, the messages may be sent to different files on the same collector. If the messages do not contain timestamps from the source, it may be difficult to order the messages if they are kept in different places. An administrator may not be able to determine if a record in one file occurred before or after a record in a different file. This may be somewhat alleviated by placing marking messages with a timestamp into all destination files. If these have coordinated timestamps, then there will be some indication of the time of receipt of the individual messages. 5.2.4 Replaying Also, without any sequence indication or timestamp, messages may be recorded and replayed at a later time. 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 replay the Syslog messages to the collector. The administrators would find nothing unusual in the received messages and their receipt would falsely indicate normal activity of the machine. 5.3 Reliable delivery As there is no mechanism within either the Syslog process or the protocol 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 consequences of the drop of one or more Syslog messages cannot be 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. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities. 5.4 Message integrity Besides being discarded, Syslog messages may be damaged in transit, or an attacker may maliciously modify them. In the case of a packet containing a Syslog message being damaged, there are various mechanisms built into the link layer as well as into the IP [3] and UDP protocols which may detect the damage. A damaged IP packet may be discarded by an intermediary router [4]. Damage to a UDP packet may be detected by the receiving UDP module which may silently discard it. In any case, the original contents of the message will not be delivered to the collector. Additionally, if an attacker is positioned between the sender and collector of Syslog messages, then he may be able to intercept and modify those messages in transit to hide unauthorized activities. 5.5 Message observation While there are no strict guidelines pertaining to the event message format, most Syslog messages are generated in human readable form with the assumption that capable administrators should be able to read them and understand their meaning. Neither the syslog protocol nor the syslog application has any mechanism to provide confidentiality of the messages in transit. In most cases passing the clear-text messages is a benefit to the operations staff if they are sniffing the packets off of the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of Syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage. 5.6 Message Prioritization and Differentiation While the processes that create the messages may signify the importance of the events through the use of the message level there is no distinct association between the level and the priority of delivery within the protocol. As an example of this consider an application that generates two event messages. The first is a normal status message but the second could be an important message denoting a problem with the process. This second message would have an appropriately higher level associated with the importance of that event. If the operators had configured that both of these messages be transported to a Syslog collector then they would, in turn, be given to UDP for transmission. Under normal conditions, no distinction would be made between them and they would be transmitted in their order. Again, under normal circumstances, the receiver would accept Syslog messages as they are received. If many devices are transmitting normal status messages, but one is transmitting an important event message, there is no inherent mechanism within the Syslog protocol to prioritize the important message over the other messages. On a case-by-case basis, device operators may find some way to associate the different levels or facilities with the quality of service identifiers. As an example, the operators may elect to define some linkage between Syslog messages that have a specific level with a specific value to be used in the IPv4 Precedence field [2], the IPv6 Traffic Class octet [5], or the Differentiated Services field [6]. In the above example, the operators may have the ability to associate the status message with normal delivery while associating the message indicating a problem with a high reliability, low latency queue as it goes through the network. This would have the affect of prioritizing the essential messages before the normal status messages. Even with this hop-by-hop prioritization, this queuing mechanism could still lead to head of line blocking on the transmitting device as well as buffer starvation on the receiving device if there are many near- simultaneous messages being send or received. In this same line, some implementations of the Syslog application may have mechanisms for the prioritization of the more important messages within the transmission queue. This behavior is not unique to Syslog but is endemic to all operations that transmit messages serially. There are security concerns for this behavior. Head of line blocking of the transmission of important event messages may relegate the conveyance of important messages behind less important messages. If the queue is cleared appropriately, this may only add seconds to the transmission of the important message. On the other hand, if the queue is not cleared, then important messages may not be transmitted. Also at the receiving side, if the Syslog receiver is suffering from buffer starvation due to large numbers of messages being received near-simultaneously, important messages may be dropped indiscriminantely along with other messages. While these are problems with the devices and their capacities, the protocol security concern is that there is no prioritization of the relatively more important messages over the less important messages. 6 Conclusion The Syslog protocol may be effectively used to transport event notification messages across a network. It is highly recommended that the network operators who choose to use this understand the characteristics of the protocol and its security implications. 7 Acknowledgements The following people provided content feedback during the writing of this draft: Jon Knight <[EMAIL PROTECTED]> Magosanyi Arpad <[EMAIL PROTECTED]> Balazs Scheidler <[EMAIL PROTECTED]> Jon Callas <[EMAIL PROTECTED]> 8 Bibliography [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980. [2] Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components of Moth Prey Species Sex Pheromones", Science, 1987 [3] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [6] Nichols, K., S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998 A Author's Address B Full Copyright Statement Copyright (C) The Internet Society (2000). 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.
