Network Working Group C. Lonvick
Request for Comments: 3164 Cisco Systems
Category: Informational August 2001
Network Working Group C. Lonvick
Request for Comments: 3164 Cisco Systems
Category: Informational August 2001
The BSD syslog Protocol
BSD系统日志协议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes the observed behavior of the syslog protocol. This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of California Berkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices.
本文档描述观察到的syslog协议行为。多年来，该协议一直用于跨网络传输事件通知消息。虽然该协议最初是在加利福尼亚大学伯克利软件分发（BSD）TCP/IP系统实现中开发的，但它对操作和管理的价值使它被移植到许多其他操作系统，并被嵌入到许多其他联网设备中。
Table of Contents
目录
1. Introduction....................................................2
1.1 Events and Generated Messages..................................3
1.2 Operations of the Message Receivers............................5
2. Transport Layer Protocol........................................5
3. Definitions and Architecture....................................5
4. Packet Format and Contents......................................7
4.1 syslog Message Parts...........................................8
4.1.1 PRI Part.....................................................8
4.1.2 HEADER Part of a syslog Packet..............................10
4.1.3 MSG Part of a syslog Packet.................................11
4.2 Original syslog Packets Generated by a Device.................12
4.3 Relayed syslog Packets........................................12
4.3.1 Valid PRI and TIMESTAMP.....................................13
4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
4.3.3 No PRI or Unidentifiable PRI................................14
5. Conventions....................................................14
5.1 Dates and Times...............................................15
5.2 Domain Name and Address.......................................15
1. Introduction....................................................2
1.1 Events and Generated Messages..................................3
1.2 Operations of the Message Receivers............................5
2. Transport Layer Protocol........................................5
3. Definitions and Architecture....................................5
4. Packet Format and Contents......................................7
4.1 syslog Message Parts...........................................8
4.1.1 PRI Part.....................................................8
4.1.2 HEADER Part of a syslog Packet..............................10
4.1.3 MSG Part of a syslog Packet.................................11
4.2 Original syslog Packets Generated by a Device.................12
4.3 Relayed syslog Packets........................................12
4.3.1 Valid PRI and TIMESTAMP.....................................13
4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
4.3.3 No PRI or Unidentifiable PRI................................14
5. Conventions....................................................14
5.1 Dates and Times...............................................15
5.2 Domain Name and Address.......................................15
5.3 Originating Process Information...............................15
5.4 Examples......................................................16
6. Security Considerations........................................18
6.1 Packet Parameters.............................................19
6.2 Message Authenticity..........................................19
6.2.1 Authentication Problems.....................................19
6.2.2 Message Forgery.............................................20
6.3 Sequenced Delivery............................................20
6.3.1 Single Source to a Destination..............................20
6.3.2 Multiple Sources to a Destination...........................21
6.3.3 Multiple Sources to Multiple Destinations...................21
6.3.4 Replaying...................................................22
6.4 Reliable Delivery.............................................22
6.5 Message Integrity.............................................22
6.6 Message Observation...........................................22
6.7 Message Prioritization and Differentiation....................23
6.8 Misconfiguration..............................................24
6.9 Forwarding Loop...............................................24
6.10 Load Considerations..........................................25
7. IANA Considerations............................................25
8. Conclusion and Other Efforts...................................25
Acknowledgements..................................................26
References........................................................27
Author's Address..................................................28
Full Copyright Statement..........................................29
5.3 Originating Process Information...............................15
5.4 Examples......................................................16
6. Security Considerations........................................18
6.1 Packet Parameters.............................................19
6.2 Message Authenticity..........................................19
6.2.1 Authentication Problems.....................................19
6.2.2 Message Forgery.............................................20
6.3 Sequenced Delivery............................................20
6.3.1 Single Source to a Destination..............................20
6.3.2 Multiple Sources to a Destination...........................21
6.3.3 Multiple Sources to Multiple Destinations...................21
6.3.4 Replaying...................................................22
6.4 Reliable Delivery.............................................22
6.5 Message Integrity.............................................22
6.6 Message Observation...........................................22
6.7 Message Prioritization and Differentiation....................23
6.8 Misconfiguration..............................................24
6.9 Forwarding Loop...............................................24
6.10 Load Considerations..........................................25
7. IANA Considerations............................................25
8. Conclusion and Other Efforts...................................25
Acknowledgements..................................................26
References........................................................27
Author's Address..................................................28
Full Copyright Statement..........................................29
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 interacted and created processes, this same principle 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 and also displayed on the console of the device. 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 add the message to a file, or to subsequently forward it to another machine.
区分问题通知和简单状态消息。syslog进程就是这样一种系统，在许多操作系统中已被广泛接受。此流程具有灵活性，因此操作人员能够配置从设备上运行的流程发送的消息的目的地。在一个维度中，syslog进程接收到的事件可以记录到不同的文件中，也可以显示在设备的控制台上。在另一个维度中，可以将syslog进程配置为通过网络将消息转发到另一台机器上的syslog进程。syslog进程必须构建网络感知，以实现一定程度的可伸缩性，因为众所周知，多个系统的操作员没有时间访问每个系统以查看记录在其中的消息。因此，可以将远程设备上运行的syslog进程配置为将消息添加到文件，或随后将其转发到另一台计算机。
In its most simplistic terms, the syslog protocol provides a transport to allow 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, there is little uniformity to the content of syslog messages. For this reason, no assumption is made upon the formatting or 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 made.
最简单的说法是，syslog协议提供了一种传输，允许机器通过IP网络向事件消息收集器（也称为syslog服务器）发送事件通知消息。由于每个进程、应用程序和操作系统都是独立编写的，因此系统日志消息的内容几乎没有统一性。因此，不对消息的格式或内容进行假设。该协议只是为了传输这些事件消息而设计的。在所有情况下，都有一个设备发出消息。该计算机上的syslog进程可能会将消息发送给收集器。没有确认收据。
One of the fundamental tenets of the syslog protocol and process is its simplicity. No stringent coordination is required between the transmitters and the receivers. Indeed, the transmission of syslog messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. This simplicity has greatly aided the acceptance and deployment of syslog.
syslog协议和过程的基本原则之一是它的简单性。发射机和接收机之间无需严格协调。实际上，系统日志消息的传输可以在没有配置接收器的设备上启动，甚至可以在实际存在的情况下启动。相反，许多设备最有可能在没有明确配置或定义的情况下接收消息。这种简单性极大地帮助了syslog的接受和部署。
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 to give status. These can be either at a certain period 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 those cases, either a status message or a message containing an alarm of some type may be generated. It was considered that the writers of
操作系统、流程和应用程序的编写者完全可以控制生成任何消息的环境。在某些情况下，生成消息以给出状态。这些可以是在某个特定的时间段，也可以是在某个其他的时间间隔，例如调用或退出程序。在其他情况下，可能由于满足一组条件而生成消息。在这些情况下，可能会生成状态消息或包含某种类型报警的消息。有人认为
the operating systems, processes and applications would quantify their messages into one of several broad categories. These broad categories generally consist of the facility that generated them, along with an indication of the severity of the message. This was so that the operations staff could selectively filter the messages and be presented with the more important and time sensitive notifications quickly, while also having the ability to place status or informative messages in a file for later perusal. Other options for displaying or storing messages have been seen to exist as well.
操作系统、流程和应用程序将其消息量化为几个大类别之一。这些广泛的类别通常包括生成它们的设施，以及消息严重性的指示。这样，操作人员可以有选择地过滤消息，并快速获得更重要、更具时间敏感性的通知，同时还可以将状态或信息性消息放入文件中，以供以后阅读。显示或存储消息的其他选项也被认为存在。
Devices MUST be configured with rules for displaying and/or forwarding the event messages. The rules that have been seen are generally very flexible. An administrator may want to have all messages stored locally as well as to have all messages of a high severity forwarded to another device. They may find it appropriate to also have messages from a particular facility sent to some or all of the users of the device and displayed on the system console. However the administrator decides to configure the disposition of the event messages, the process of having them sent to a syslog collector generally consists of deciding which facility messages and which severity levels will be forwarded, and then defining the remote receiver. For example, an administrator may want all messages that are generated by the mail facility to be forwarded to one particular event message collector. Then the administrator may want to have all kernel generated messages sent to a different syslog receiver while, at the same time, having the critically severe messages from the kernel also sent to a third receiver. It may also be appropriate to have those messages displayed on the system console as well as being mailed to some appropriate people, while at the same time, being sent to a file on the local disk of the device. Conversely, it may be appropriate to have messages from a locally defined process only displayed on the console but not saved or forwarded from the device. In any event, the rules for this will have to be generated on the device. Since the administrators will then know which types of messages will be received on the collectors, they should then make appropriate rules on those syslog servers as well.
设备必须配置用于显示和/或转发事件消息的规则。人们看到的规则通常都非常灵活。管理员可能希望将所有消息存储在本地，并将所有严重性高的消息转发到其他设备。他们可能会发现，将来自特定设施的消息发送给设备的部分或所有用户并显示在系统控制台上也是合适的。但是，管理员决定配置事件消息的处置，将事件消息发送到syslog收集器的过程通常包括决定转发哪些设施消息和严重性级别，然后定义远程接收器。例如，管理员可能希望将邮件设施生成的所有邮件转发到一个特定的事件邮件收集器。然后，管理员可能希望将所有内核生成的消息发送到另一个syslog接收器，同时将来自内核的严重消息也发送到第三个接收器。也可以在系统控制台上显示这些消息，并将其邮寄给一些适当的人，同时将其发送到设备本地磁盘上的文件中。相反，本地定义的进程的消息只显示在控制台上，而不保存或从设备转发可能是合适的。在任何情况下，都必须在设备上生成此操作的规则。由于管理员随后将知道收集器将接收哪些类型的消息，因此他们也应该在这些syslog服务器上制定适当的规则。
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 and some indication of the sending device and the process that originated it in the messages. However, none of those are stringently 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.
无盘工作站。在这种情况下，可能需要将事件消息传输到收集器，以便操作员可以记录并查看它们。
It is beyond the scope of this document to specify how event messages should be processed when they are received. Like the operations described in Section 1.1, they generally may be displayed to the appropriate people, saved onto disk, further forwarded, or any combination of these. The rules for determining the disposition of received messages have been seen to be identical to the rules for determining the disposition of locally generated messages.
指定接收事件消息时应如何处理这些消息超出了本文档的范围。与第1.1节中描述的操作一样，它们通常可以显示给适当的人，保存到磁盘上，进一步转发，或这些操作的任意组合。已发现用于确定接收消息的处置的规则与用于确定本地生成消息的处置的规则相同。
As a very general rule, there are usually many devices sending messages to relatively fewer collectors. This fan-in process allows an administrator to aggregate messages into relatively few repositories.
一般来说，通常有许多设备向相对较少的收集器发送消息。此扇入过程允许管理员将消息聚合到相对较少的存储库中。
syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism. The UDP port that has been assigned to syslog is 514. It is RECOMMENDED that the source port also be 514 to indicate that the message is from the syslog process of the sender, but there have been cases seen where valid syslog messages have come from a sender with a source port other than 514. If the sender uses a source port other than 514 then it is RECOMMENDED and has been considered to be good form that subsequent messages are from a single consistent port.
syslog使用用户数据报协议（UDP）[1]作为其底层传输层机制。已分配给syslog的UDP端口为514。建议源端口也为514，以指示消息来自发送方的syslog进程，但在某些情况下，有效的syslog消息来自源端口不是514的发送方。如果发送方使用514以外的源端口，则建议后续消息来自单个一致端口，这被认为是一种良好的形式。
The following definitions will be used in this document.
本文件将使用以下定义。
A machine that can generate a message will be called a "device".
能够生成消息的机器称为“设备”。
A machine that can receive the message and forward it to another machine will be called a "relay".
能够接收信息并将其转发给另一台机器的机器称为“中继”。
A machine that receives the message and does not relay it to any other machines will be called a "collector". This has been commonly known as a "syslog server".
接收消息且不将其中继到任何其他机器的机器将被称为“收集器”。这通常被称为“系统日志服务器”。
Any device or relay will be known as the "sender" when it sends a message.
任何设备或继电器在发送消息时都称为“发送者”。
Any relay or collector will be known as the "receiver" when it receives the message.
任何继电器或采集器在接收到消息时都称为“接收器”。
The architecture of the devices may be summarized as follows:
设备的架构可总结如下：
Senders send messages to relays or collectors with no knowledge of whether it is a collector or relay.
发送方将消息发送到中继或收集器，而不知道它是收集器还是中继。
Senders may be configured to send the same message to multiple receivers.
发送者可以被配置为向多个接收者发送相同的消息。
Relays may send all or some of the messages that they receive to a subsequent relay or collector. In the case where they do not forward all of their messages, they are acting as both a collector and a relay. In the following diagram, these devices will be designated as relays.
中继器可以将其接收到的全部或部分消息发送给后续中继器或采集器。在它们不转发所有消息的情况下，它们同时充当收集器和中继。在下图中，这些设备将被指定为继电器。
Relays may also generate their own messages and send them on to subsequent relays or collectors. In that case it is acting as a device. These devices will also be designated as a relay in the following diagram.
中继器还可以生成自己的消息，并将其发送给后续中继器或采集器。在这种情况下，它就像一个装置。在下图中，这些设备也将被指定为继电器。
The following architectures shown in Diagram 1 are valid while the first one has been known to be the most prevalent. Other arrangements of these examples are also acceptable. As noted above, in the following diagram relays may pass along all or some of the messages that they receive along with passing along messages that they internally generate.
图1中所示的以下体系结构是有效的，而第一个体系结构是最普遍的。这些例子的其他安排也是可以接受的。如上所述，在下图中，继电器可传递其接收的全部或部分消息以及其内部生成的消息。
+------+ +---------+
|Device|---->----|Collector|
+------+ +---------+
+------+ +---------+
|Device|---->----|Collector|
+------+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
+------+ +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
+------+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+
|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+------+ +-----+ +-----+ +---------+
+------+ +-----+ +-----+ +---------+
|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+------+ +-----+ +-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
| |-\ +-----+ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->----|Collector|
| |-\ +-----+ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +---------+
|Device|---->----|Collector|
| |-\ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +---------+
|Device|---->----|Collector|
| |-\ +---------+
+------+ \
\ +-----+ +---------+
\-->--|Relay|---->----|Collector|
+-----+ +---------+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->-------|Collector|
| |-\ +-----+ /--| |
+------+ \ / +---------+
\ +-----+ /
\-->--|Relay|-->--/
+-----+
+------+ +-----+ +---------+
|Device|---->----|Relay|---->-------|Collector|
| |-\ +-----+ /--| |
+------+ \ / +---------+
\ +-----+ /
\-->--|Relay|-->--/
+-----+
Diagram 1. Some Possible syslog Architectures
图1。一些可能的系统日志体系结构
The payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message. There MAY be differences between the format of an originally transmitted syslog message and the format of a relayed message. In essence, it is RECOMMENDED to transmit a syslog message in the format specified in this document, but it is not required. If a relay is able to recognize the message as adhering to that format then it MUST retransmit the message without making any changes to it. However, if a relay receives a
UDP目标端口为514的任何IP数据包的有效负载必须视为syslog消息。最初传输的syslog消息的格式与中继消息的格式可能有所不同。本质上，建议以本文档中指定的格式传输syslog消息，但这不是必需的。如果中继器能够识别符合该格式的消息，则它必须在不对其进行任何更改的情况下重新传输该消息。但是，如果继电器接收到
message but cannot discern the proper implementation of the format, it is REQUIRED to modify the message so that it conforms to that format before it retransmits it. Section 4.1 will describe the RECOMMENDED format for syslog messages. Section 4.2 will describe the requirements for originally transmitted messages and Section 4.3 will describe the requirements for relayed messages.
消息，但无法识别格式的正确实现，需要修改消息，使其在重新传输之前符合该格式。第4.1节将描述系统日志消息的推荐格式。第4.2节将描述原始传输消息的要求，第4.3节将描述中继消息的要求。
The full format of a syslog message seen on the wire has three discernable parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG. The total length of the packet MUST be 1024 bytes or less. There is no minimum length of the syslog message although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted.
在线上看到的syslog消息的完整格式有三个可识别的部分。第一部分称为PRI，第二部分称为标题，第三部分称为MSG。数据包的总长度必须小于等于1024字节。虽然发送没有内容的syslog数据包毫无价值，并且不应传输，但syslog消息没有最小长度。
The PRI part MUST have three, four, or five characters and will be bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character), followed by a number, which is followed by a ">" ('greater-than' character). The code set used in this part MUST be seven-bit ASCII in an eight-bit field as described in RFC 2234 [2]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [3]. In this, the "<" character is defined as the Augmented Backus-Naur Form (ABNF) %d60, and the ">" character has ABNF value %d62. The number contained within these angle brackets is known as the Priority value and represents both the Facility and Severity as described below. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
PRI部分必须有三个、四个或五个字符，并且将以尖括号作为第一个和最后一个字符进行绑定。PRI部分以一个前导“<”（“小于”字符）开头，后面是一个数字，后面是一个“>”（“大于”字符）。本部分中使用的代码集必须是RFC 2234[2]中所述八位字段中的七位ASCII码。这些是“美国信息交换标准代码”[3]中定义的ASCII码。在这种情况下，“<”字符被定义为扩展的巴科斯诺尔形式（ABNF）%d60，“>”字符的ABNF值为%d62。这些尖括号中包含的数字称为优先级值，表示如下所述的设施和严重性。优先级值由一个、两个或三个十进制整数（ABNF数字）组成，使用的值为%d48（表示“0”）到%d57（表示“9”）。
The Facilities and Severities of the messages are numerically coded with decimal values. Some of the operating system daemons and processes have been assigned Facility values. Processes and daemons that have not been explicitly assigned a Facility may use any of the "local use" facilities or they may use the "user-level" Facility. Those Facilities that have been designated are shown in the following table along with their numerical code values.
消息的设施和严重程度用十进制值进行数字编码。某些操作系统守护进程和进程已被分配设施值。未明确分配设施的进程和守护进程可以使用任何“本地使用”设施，也可以使用“用户级”设施。下表显示了指定的设施及其数字代码值。
Numerical Facility Code
数字设备代码
0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages (note 1)
0内核消息1用户级消息2邮件系统3系统守护进程4安全/授权消息（注意1）
5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon (note 2) 10 security/authorization messages (note 1) 11 FTP daemon 12 NTP subsystem 13 log audit (note 1) 14 log alert (note 1) 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7)
5由syslogd 6行打印机子系统7网络新闻子系统8 UUCP子系统9时钟守护程序（注2）10安全/授权消息（注1）11 FTP守护程序12 NTP子系统13日志审计（注1）14日志警报（注1）15时钟守护程序（注2）16本地使用0（本地0）17本地使用1（本地1）18本地使用2（本地2）19本地使用3（local3）20本地使用4（local4）21本地使用5（local5）22本地使用6（local6）23本地使用7（local7）
Table 1. syslog Message Facilities
表1。系统日志消息设施
Note 1 - Various operating systems have been found to utilize Facilities 4, 10, 13 and 14 for security/authorization, audit, and alert messages which seem to be similar. Note 2 - Various operating systems have been found to utilize both Facilities 9 and 15 for clock (cron/at) messages.
注1-已发现各种操作系统利用设施4、10、13和14执行安全/授权、审计和警报消息，这些消息似乎相似。注2-已发现各种操作系统都利用设施9和15来处理时钟（cron/at）消息。
Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values.
每个消息优先级还具有十进制严重性级别指示器。下表中描述了这些参数及其数值。
Numerical Severity Code
数字严重性代码
0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages
0紧急情况：系统不可用1警报：必须立即采取措施2严重：严重情况3错误：错误情况4警告：警告条件5通知：正常但有效的条件6信息性：信息性消息7调试：调试级别消息
Table 2. syslog Message Severities
表2。系统日志消息严重性
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" will follow the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used.
优先级值的计算方法是首先将设施编号乘以8，然后将严重性的数值相加。例如，严重性为紧急（严重性为0）的内核消息（Facility=0）的优先级值为0。此外，具有通知严重性（严重性=5）的“本地使用4”消息（设施=20）的优先级值为165。在syslog消息的PRI部分中，这些值将分别放在尖括号<0>和<165>之间。唯一在“<”之后出现值“0”的时间是优先级值“0”。否则，不得使用前导“0”。
The HEADER part contains a timestamp and an indication of the hostname or IP address of the device. The HEADER part of the syslog packet MUST contain visible (printing) characters. The code set used MUST also be seven-bit ASCII in an eight-bit field like that used in the PRI part. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).
标头部分包含时间戳和设备主机名或IP地址的指示。syslog数据包的头部分必须包含可见（打印）字符。所使用的代码集也必须是8位字段中的7位ASCII，就像PRI部分中使用的那样。在此代码集中，唯一允许的字符是ABNF VCHAR值（%d33-126）和空格（SP值%d32）。
The HEADER contains two fields called the TIMESTAMP and the HOSTNAME. The TIMESTAMP will immediately follow the trailing ">" from the PRI part and single space characters MUST follow each of the TIMESTAMP and HOSTNAME fields. HOSTNAME will contain the hostname, as it knows itself. If it does not have a hostname, then it will contain its own IP address. If a device has multiple IP addresses, it has usually been seen to use the IP address from which the message is transmitted. An alternative to this behavior has also been seen. In that case, a device may be configured to send all messages using a single source IP address regardless of the interface from which the message is sent. This will provide a single consistent HOSTNAME for all messages sent from a device.
标头包含两个名为时间戳和主机名的字段。时间戳将紧跟在PRI部分的尾随“>”之后，每个时间戳和主机名字段后面必须有单空格字符。主机名将包含它自己知道的主机名。如果它没有主机名，那么它将包含自己的IP地址。如果一个设备有多个IP地址，通常可以看到它使用的是发送消息的IP地址。人们也看到了这种行为的另一种选择。在这种情况下，可以将设备配置为使用单个源IP地址发送所有消息，而不管从哪个接口发送消息。这将为从设备发送的所有消息提供一个统一的主机名。
The TIMESTAMP field is the local time and is in the format of "Mmm dd hh:mm:ss" (without the quote marks) where:
时间戳字段是本地时间，格式为“Mmm dd hh:mm:ss”（不带引号），其中：
Mmm is the English language abbreviation for the month of the year with the first character in uppercase and the other two characters in lowercase. The following are the only acceptable values:
Mmm是一年中月份的英文缩写，第一个字符为大写，另外两个字符为小写。以下是唯一可接受的值：
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
一月、二月、三月、四月、五月、六月、七月、八月、九月、十月、十一月、十二月
dd is the day of the month. If the day of the month is less than 10, then it MUST be represented as a space and then the number. For example, the 7th day of August would be represented as "Aug 7", with two spaces between the "g" and the "7".
dd是一个月中的一天。如果月份的日期小于10，则必须先用空格表示，然后用数字表示。例如，8月7日将表示为“8月7日”，在“g”和“7”之间有两个空格。
hh:mm:ss is the local time. The hour (hh) is represented in a 24-hour format. Valid entries are between 00 and 23, inclusive. The minute (mm) and second (ss) entries are between 00 and 59 inclusive.
hh:mm:ss是当地时间。小时（hh）以24小时格式表示。有效条目介于00和23之间，包括00和23。分钟（mm）和秒（ss）条目介于00和59之间（含）。
A single space character MUST follow the TIMESTAMP field.
时间戳字段后面必须有一个空格字符。
The HOSTNAME field will contain only the hostname, the IPv4 address, or the IPv6 address of the originator of the message. The preferred value is the hostname. If the hostname is used, the HOSTNAME field MUST contain the hostname of the device as specified in STD 13 [4]. It should be noted that this MUST NOT contain any embedded spaces. The Domain Name MUST NOT be included in the HOSTNAME field. If the IPv4 address is used, it MUST be shown as the dotted decimal notation as used in STD 13 [5]. If an IPv6 address is used, any valid representation used in RFC 2373 [6] MAY be used. A single space character MUST also follow the HOSTNAME field.
主机名字段将仅包含消息发起人的主机名、IPv4地址或IPv6地址。首选值是主机名。如果使用主机名，主机名字段必须包含STD 13[4]中指定的设备主机名。应该注意的是，这不得包含任何嵌入空间。域名不得包含在主机名字段中。如果使用IPv4地址，则必须显示为STD 13[5]中使用的点十进制表示法。如果使用IPv6地址，则可以使用RFC 2373[6]中使用的任何有效表示。主机名字段后面还必须有一个空格字符。
The MSG part will fill the remainder of the syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. There is no ending delimiter to this part. The MSG part of the syslog packet MUST contain visible (printing) characters. The code set traditionally and most often used has also been seven-bit ASCII in an eight-bit field like that used in the PRI and HEADER parts. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). However, no indication of the code set used within the MSG is required, nor is it expected. Other code sets MAY be used as long as the characters used in the MSG are exclusively visible characters and spaces similar to those described above. The selection of a code set used in the MSG part SHOULD be made with thoughts of the intended receiver. A message containing characters in a code set that cannot be viewed or understood by a recipient will yield no information of value to an operator or administrator looking at it.
MSG部分将填充syslog数据包的其余部分。这通常包含生成消息的进程的一些附加信息，然后是消息的文本。此部分没有结束分隔符。syslog数据包的MSG部分必须包含可见（打印）字符。传统上和最常用的代码集也是八位字段中的七位ASCII，就像PRI和头部分中使用的那样。在此代码集中，唯一允许的字符是ABNF VCHAR值（%d33-126）和空格（SP值%d32）。但是，不需要指示MSG中使用的代码集，也不需要指示。只要MSG中使用的字符是与上述字符类似的唯一可见字符和空格，就可以使用其他代码集。选择MSG部分中使用的代码集时，应考虑预期接收者的想法。如果邮件包含收件人无法查看或理解的代码集中的字符，则查看该邮件的操作员或管理员不会收到任何有价值的信息。
The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the
MSG部分有两个字段，称为标记字段和内容字段。标记字段中的值将是生成消息的程序或进程的名称。内容包含消息的详细信息。传统上，这是一个自由形式的消息，提供了一些事件的详细信息。标签是ABNF字母数字字符的字符串，不得超过32个字符。任何非字母数字字符将终止标记字段，并将假定为内容字段的起始字符。最常见的是，内容字段的第一个字符，表示
conclusion of the TAG field has been seen to be the left square bracket character ("["), a colon character (":"), or a space character. This is explained in more detail in Section 5.3.
标记字段的结尾可以看到是左方括号字符（“[”）、冒号字符（“：”）或空格字符。第5.3节对此进行了更详细的解释。
There are no set requirements on the contents of the syslog packet as it is originally sent from a device. It should be reiterated here that the payload of any IP packet destined to UDP port 514 MUST be considered to be a valid syslog message. It is, however, RECOMMENDED that the syslog packet have all of the parts described in Section 4.1 - PRI, HEADER and MSG - as this enhances readability by the recipient and eliminates the need for a relay to modify the message.
syslog数据包的内容没有设置要求，因为它最初是从设备发送的。这里应该重申的是，发往UDP端口514的任何IP数据包的有效负载必须被视为有效的syslog消息。但是，建议syslog数据包具有第4.1节（PRI、HEADER和MSG）中所述的所有部分，因为这提高了收件人的可读性，并且不需要中继来修改消息。
For implementers that do choose to construct syslog messages with the RECOMMENDED format, the following guidance is offered.
对于选择使用推荐格式构造syslog消息的实现者，提供以下指导。
If the originally formed message has a TIMESTAMP in the HEADER part, then it SHOULD be the local time of the device within its timezone.
如果最初形成的消息在报头部分有一个时间戳，那么它应该是设备在其时区内的本地时间。
If the originally formed message has a HOSTNAME field, then it will contain the hostname as it knows itself. If it does not have a hostname, then it will contain its own IP address.
如果最初形成的消息有一个HOSTNAME字段，那么它将包含自己知道的主机名。如果它没有主机名，那么它将包含自己的IP地址。
If the originally formed message has a TAG value, then that will be the name of the program or process that generated the message.
如果最初形成的消息具有标记值，则该标记值将是生成消息的程序或进程的名称。
When a relay receives a packet, it will check for a valid PRI. If the first character is not a less-than sign, the relay MUST assume that the packet does not contain a valid PRI. If the 3rd, 4th, or 5th character is not a right angle bracket character, the relay again MUST assume that the PRI was not included in the original message. If the relay does find a valid PRI part then it must check for a valid TIMESTAMP in the HEADER part. From these rules, there will be three general cases of received messages. Table 3 gives the general characteristics of these cases and lists the subsequent section of this document that describes the handling of that case.
当中继接收到数据包时，它将检查有效的PRI。如果第一个字符不是小于号，则中继必须假定数据包不包含有效的PRI。如果第3、第4或第5个字符不是右括号字符，则中继必须再次假定原始消息中未包含PRI。如果中继器确实找到有效的PRI部分，那么它必须在报头部分中检查有效的时间戳。根据这些规则，将有三种收到消息的一般情况。表3给出了这些案件的一般特征，并列出了本文件后面描述该案件处理的章节。
Case Section Valid PRI and TIMESTAMP 4.3.1 Valid PRI but no TIMESTAMP or invalid TIMESTAMP 4.3.2 No PRI or unidentifiable PRI 4.3.3
案例部分有效PRI和时间戳4.3.1有效PRI但无时间戳或无效时间戳4.3.2无PRI或无法识别PRI 4.3.3
Table 3. Cases of Received syslog Messages
表3。收到系统日志消息的案例
If the relay does find a valid PRI and a valid TIMESTAMP, then it will check its internal configuration. Relays MUST be configured to forward syslog packets on the basis of their Priority value. If the relay finds that it is configured to forward the received packet, then it MUST do so without making any changes to the packet. To emphasize the point one more time, it is for this reason that it is RECOMMENDED that the syslog message originally transmitted adhere to the format described in Section 4.1.
如果继电器确实找到有效的PRI和有效的时间戳，则它将检查其内部配置。中继必须配置为根据其优先级值转发系统日志数据包。如果中继器发现它被配置为转发接收到的数据包，那么它必须这样做，而不对数据包进行任何更改。为了再次强调这一点，出于这个原因，建议最初传输的syslog消息遵循第4.1节中描述的格式。
It should be noted here that the message receiver does not need to validate the time in the TIMESTAMP field. The assumption may be made that a device whose date has not been correctly set will still have the ability to send valid syslog messages. Additionally, the relay does not need to validate that the value in the HOSTNAME field matches the hostname or IP address of the device sending the message. A reason for this behavior may be found in Section 4.1.2.
这里应该注意，消息接收器不需要验证时间戳字段中的时间。可以假设未正确设置日期的设备仍然能够发送有效的系统日志消息。此外，中继不需要验证主机名字段中的值是否与发送消息的设备的主机名或IP地址匹配。该行为的原因见第4.1.2节。
If a relay does not find a valid TIMESTAMP in a received syslog packet, then it MUST add a TIMESTAMP and a space character immediately after the closing angle bracket of the PRI part. It SHOULD additionally add a HOSTNAME and a space character after the TIMESTAMP. These fields are described here and detailed in Section 4.1.2. The remainder of the received packet MUST be treated as the CONTENT field of the MSG and appended. Since the relay would have no way to determine the originating process from the device that originated the message, the TAG value cannot be determined and will not be included.
如果中继在接收到的syslog数据包中找不到有效的时间戳，那么它必须在PRI部分的闭合角括号之后立即添加时间戳和空格字符。它还应该在时间戳之后添加主机名和空格字符。此处对这些字段进行了描述，并在第4.1.2节中进行了详细说明。接收到的数据包的其余部分必须视为MSG的内容字段并追加。由于中继器将无法确定来自发起消息的设备的发起进程，因此无法确定并且将不包括标签值。
The TIMESTAMP will be the current local time of the relay.
时间戳将是继电器的当前本地时间。
The HOSTNAME will be the name of the device, as it is known by the relay. If the name cannot be determined, the IP address of the device will be used.
主机名将是设备的名称，正如中继器所知道的那样。如果无法确定名称，将使用设备的IP地址。
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, then it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has been expanded beyond 1024 bytes, then the relay MUST truncate the packet to be 1024 bytes. This may cause the loss of vital information from the end of the original packet. It is for this reason that it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1.
如果中继在PRI部分之后添加时间戳或时间戳和主机名，那么它必须检查数据包的总长度是否仍然小于等于1024字节。如果数据包已扩展超过1024字节，则中继必须将数据包截断为1024字节。这可能会导致原始数据包末尾的重要信息丢失。因此，建议最初生成的系统日志数据包的PRI和头部分包含第4.1节中记录的值和字段。
If the relay receives a syslog message without a PRI, or with an unidentifiable PRI, then it MUST insert a PRI with a Priority value of 13 as well as a TIMESTAMP as described in Section 4.3.2. The relay SHOULD also insert a HOSTNAME as described in Section 4.3.2. The entire contents of the received packet will be treated as the CONTENT of the relayed MSG and appended.
如果中继接收到没有PRI的系统日志消息，或具有无法识别的PRI，则必须插入优先级值为13的PRI以及第4.3.2节所述的时间戳。继电器还应插入第4.3.2节所述的主机名。接收到的数据包的全部内容将被视为中继消息的内容并附加。
An example of an unidentifiable PRI would be "<00>", without the double quotes. It may be that these are the first 4 characters of the message. To continue this example, if a relay does receive a syslog message with the first four characters of "<00>", then it will consult its configuration. If it is configured to forward syslog messages with a Priority value of 13 to another relay or collector, then it MUST modify the packet as described above. The specifics of doing this, including the RECOMMENDED insertion of the HOSTNAME, are given below.
无法识别PRI的示例为“<00>”，不带双引号。这可能是消息的前4个字符。要继续此示例，如果中继确实收到前四个字符为“<00>”的syslog消息，则它将参考其配置。如果将其配置为将优先级值为13的syslog消息转发给另一个中继或收集器，则必须如上所述修改数据包。下面给出了执行此操作的详细信息，包括建议插入的主机名。
Originally received message <00>... Relayed message <13>TIMESTAMP HOSTNAME <00>...
最初收到的消息<00>。。。中继消息<13>时间戳主机名<00>。。。
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, then it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has been expanded beyond 1024 bytes, then the relay MUST truncate the packet to be 1024 bytes. This may cause the loss of vital information from the end of the original packet. It is for this reason that it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1.
如果中继在PRI部分之后添加时间戳或时间戳和主机名，那么它必须检查数据包的总长度是否仍然小于等于1024字节。如果数据包已扩展超过1024字节，则中继必须将数据包截断为1024字节。这可能会导致原始数据包末尾的重要信息丢失。因此，建议最初生成的系统日志数据包的PRI和头部分包含第4.1节中记录的值和字段。
Although Section 4 of this document specifies all requirements for the syslog protocol format and contents, certain conventions have come about over time for the inclusion of additional information within the syslog message. It must be plainly stated that these items are not mandated but may be considered by implementers for completeness and to give the recipient some additional clues of their origin and nature.
尽管本文件第4节规定了syslog协议格式和内容的所有要求，但随着时间的推移，在syslog消息中包含附加信息的某些约定已经形成。必须明确指出，这些项目不是强制性的，但实施者可能会考虑这些项目的完整性，并向接收者提供关于其来源和性质的额外线索。
It has been found that some network administrators like to archive their syslog messages over long periods of time. It has been seen that some original syslog messages contain a more explicit time stamp in which a 2 character or 4 character year field immediately follows the space terminating the TIMESTAMP. This is not consistent with the original intent of the order and format of the fields. If implementers wish to contain a more specific date and time stamp within the transmitted message, it should be within the CONTENT field. Implementers may wish to utilize the ISO 8601 [7] date and time formats if they want to include more explicit date and time information.
已经发现，一些网络管理员喜欢长时间归档其系统日志消息。可以看出，一些原始系统日志消息包含更明确的时间戳，其中2个字符或4个字符的年份字段紧跟在终止时间戳的空格之后。这与字段顺序和格式的原始意图不一致。如果实现者希望在传输的消息中包含更具体的日期和时间戳，那么它应该在内容字段中。如果实施者希望包含更明确的日期和时间信息，他们可能希望使用ISO 8601[7]日期和时间格式。
Additional methods to address this desire for long-term archiving have been proposed and some have been successfully implemented. One such method is that the network administrators may choose to modify the messages stored on their collectors. They may run a simple script to add the year, and any other information, to each stored record. Alternatively, the script may replace the stored time with a format more appropriate for the needs of the network administrators. Another alternative has been to insert a record into the file that contains the current year. By association then, all other records near that informative record should have been received in that same year. Neither of these however, addresses the issue of associating a correct timezone with each record.
已经提出了其他方法来满足长期存档的需求，其中一些方法已经成功实施。其中一种方法是网络管理员可以选择修改其收集器上存储的消息。他们可以运行一个简单的脚本，将年份和任何其他信息添加到每个存储的记录中。或者，脚本可以用更适合网络管理员需要的格式替换存储的时间。另一种选择是在包含当前年份的文件中插入一条记录。根据协会的规定，该信息记录附近的所有其他记录应在同一年收到。但是，这两种方法都不能解决将正确的时区与每条记录关联的问题。
To readily identify the device that originated the message, it may be a good practice to include its fully qualified domain name (FQDN) and its IP address within the CONTENT field. Traditionally, however, only the hostname has been included in the HOSTNAME field.
为了方便地识别发起消息的设备，最好将其完全限定域名（FQDN）及其IP地址包含在内容字段中。但是，传统上，只有主机名包含在主机名字段中。
It has also been considered to be a good practice to include some information about the process on the device that generated the message - if that concept exists. This is usually the process name and process id (often known as the "pid") for robust operating systems. The process name is commonly displayed in the TAG field. Quite often, additional information is included at the beginning of the CONTENT field. The format of "TAG[pid]:" - without the quote marks - is common. The left square bracket is used to terminate the TAG field in this case and is then the first character in the CONTENT field. If the process id is immaterial, it may be left off.
如果存在这样的概念，那么在设备上包含一些关于生成消息的过程的信息也被认为是一种良好的做法。对于健壮的操作系统，这通常是进程名和进程id（通常称为“pid”）。进程名称通常显示在标记字段中。通常，内容字段的开头会包含其他信息。“TAG[pid]：”的格式（不带引号）是常见的。在本例中，左方括号用于终止标记字段，然后是内容字段中的第一个字符。如果进程id不重要，则可以将其删除。
In that case, a colon and a space character usually follow the TAG. This would be displayed as "TAG: " without the quotes. In that case, the colon is the first character in the CONTENT field.
在这种情况下，冒号和空格字符通常跟在标记后面。这将显示为“TAG:”而不带引号。在这种情况下，冒号是内容字段中的第一个字符。
As examples, these are valid messages as they may be observed on the wire between two devices. In the following examples, each message has been indented, with line breaks inserted in this document for readability.
例如，这些是有效的消息，因为它们可能在两个设备之间的线路上观察到。在下面的示例中，每条消息都已缩进，为了便于阅读，在文档中插入了换行符。
Example 1
例1
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
on /dev/pts/8
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
on /dev/pts/8
This example shows an authentication error in an attempt to acquire additional privileges. It also shows the command attempted and the user attempting it. This was recorded as an original message from the device called mymachine. A relay receiving this would not make any changes before sending it along as it contains a properly formatted PRI part and TIMESTAMP field in the HEADER part. The TAG value in this example is the process "su". The colon has terminated the TAG field and is the first character of the CONTENT field. In this case, the process id (pid) would be considered transient and anyone looking at this syslog message would gain no useful information from knowing the pid. It has not been included so the first two characters of the CONTENT field are the colon and a space character.
此示例显示了在尝试获取其他权限时发生的身份验证错误。它还显示尝试执行的命令和尝试执行该命令的用户。这被记录为来自mymachine设备的原始消息。接收此消息的中继在发送之前不会进行任何更改，因为它在报头部分中包含格式正确的PRI部分和时间戳字段。本例中的标记值是进程“su”。冒号已终止标记字段，并且是内容字段的第一个字符。在这种情况下，进程id（pid）将被认为是暂时的，任何查看此syslog消息的人都不会从了解pid中获得任何有用的信息。它尚未包含在内，因此内容字段的前两个字符是冒号和空格字符。
Example 2
例2
Use the BFG!
使用BFG！
While this is a valid message, it has extraordinarily little useful information. This message does not have any discernable PRI part. It does not contain a timestamp or any indication of the source of the message. If this message is stored on paper or disk, subsequent review of the message will not yield anything of value.
虽然这是一条有效的消息，但它几乎没有有用的信息。此消息没有任何可识别的PRI部分。它不包含时间戳或消息源的任何指示。如果此消息存储在纸张或磁盘上，则后续对消息的审阅将不会产生任何有价值的结果。
This example is obviously an original message from a device. A relay MUST make changes to the message as described in Section 4.3 before forwarding it. The resulting relayed message is shown below.
此示例显然是来自设备的原始消息。转发前，中继必须按照第4.3节所述对消息进行更改。产生的中继消息如下所示。
<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!
<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!
In this relayed message, the entire message has been treated as the CONTENT portion of the MSG part. First, a valid PRI part has been added using the default priority value of 13. Next, a TIMESTAMP has been added along with a HOSTNAME in the HEADER part. Subsequent relays will not make any further changes to this message. It should be noted in this example that the day of the month is less than 10. Since single digits in the date (5 in this case) are preceded by a space in the TIMESTAMP format, there are two spaces following the month in the TIMESTAMP before the day of the month. Also, the relay appears to have no knowledge of the host name of the device sending the message so it has inserted the IPv4 address of the device into the HOSTNAME field.
在此中继消息中，整个消息被视为MSG部分的内容部分。首先，使用默认优先级值13添加了一个有效的PRI部件。接下来，在头部分添加了时间戳和主机名。后续继电器不会对此消息进行任何进一步更改。在本例中应注意，一个月的日期小于10天。由于日期中的单个数字（本例中为5）前面有一个时间戳格式的空格，因此时间戳中的月份后面有两个空格，位于该月份的前一天。此外，中继似乎不知道发送消息的设备的主机名，因此它已将设备的IPv4地址插入主机名字段。
Example 3
例3
<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's
time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK #
Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
Conveyer1=OK, Conveyer2=OK # %%
<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's
time to make the do-nuts. %% Ingredients: Mix=OK, Jelly=OK #
Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
Conveyer1=OK, Conveyer2=OK # %%
This message does have a valid PRI part with a Priority value indicating that it came from a locally defined facility (local4) with a severity of Notice. The HEADER part has a proper TIMESTAMP field in the message. A relay will not modify this message before sending it. However, the HOSTNAME and TAG fields are not consistent with the definitions in Section 4. The HOSTNAME field would be construed to be "CST" and the beginning of the MSG part would be "1987".
此消息确实有一个有效的PRI部分，其优先级值指示它来自本地定义的设施（local4），其严重性为通知。消息头部分在消息中有一个适当的时间戳字段。中继在发送前不会修改此消息。但是，主机名和标记字段与第4节中的定义不一致。主机名字段将被解释为“CST”，消息部分的开头将是“1987”。
It should be noted that the information contained in the CONTENT of this example is not telemetry data, nor is it supervisory control or data acquisition information. Due to the security concerns listed in Section 6 of this document, information of that nature should probably not be conveyed across this protocol.
应注意，本示例内容中包含的信息不是遥测数据，也不是监控或数据采集信息。由于本文件第6节中列出的安全问题，此类信息可能不应通过本协议传递。
Example 4
例4
<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
sched[0]: That's All Folks!
<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
sched[0]: That's All Folks!
This example has a lot of extraneous information throughout. A human or sufficiently adaptable automated parser would be able to determine the date and time information as well as a fully qualified domain name (FQDN) [4] and IP address. The information about the nature of the event is, however, limited. Due to the indicated severity of the event, the process may not have been able to gather or send anything more informative. It may have been fortunate to have generated and sent this message at all.
这个例子有很多无关的信息。人工或适应性强的自动解析器将能够确定日期和时间信息以及完全限定的域名（FQDN）[4]和IP地址。然而，关于事件性质的信息是有限的。由于事件的严重性，流程可能无法收集或发送更多信息。它可能很幸运地生成并发送了这条消息。
This example is obviously an original message from a device. Since the first field in the HEADER part is not a TIMESTAMP in the format defined in Section 4.1.2, it MUST be modified by a relay. A relay will add a TIMESTAMP and SHOULD add a HOSTNAME as follows and will treat the entire received packet after the PRI part from the original packet as the CONTENT field of the new packet. The value used in the HOSTNAME field is only the hostname without the domain name as it is known by the relay. A TAG value will not be added to the relayed packet. While the inclusion of the domain name and IPv4 address in the original message is a noble endeavor, it is not consistent with the use of the field as described in Section 4.1.2.
此示例显然是来自设备的原始消息。由于报头部分中的第一个字段不是第4.1.2节中定义的格式的时间戳，因此必须通过中继对其进行修改。中继将添加一个时间戳，并应添加一个主机名，如下所示，并将原始数据包的PRI部分之后的整个接收数据包视为新数据包的内容字段。主机名字段中使用的值仅为主机名，不包括中继已知的域名。标签值不会添加到中继数据包中。虽然在原始消息中包含域名和IPv4地址是一项崇高的努力，但它与第4.1.2节中描述的字段使用不一致。
<0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6
scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
<0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6
scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
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 required 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 merely from the ambiance wafting from the kitchen. Similarly, various species have been found to utilize odors to attract mates. One species of moth uses this scent to find each other. However, it has been found that bolas spiders can mimic the odor of the female moths of this species. This scent will then attract male moths, which will follow it with the expectation of finding a mate. Instead, when they arrive at the source of the scent, they will be eaten [8]. This is a case of a false message being sent out with inimical intent.
气味可被视为不需要任何确认的信息。人们倾向于避开难闻的气味，但却被与美食相关的气味所吸引。不需要确认接收到气味或气味，事实上，完全忽略某些气味可能是一种高度的自由裁量权。另一方面，人们通常认为，仅仅从厨房里飘来的气氛中承认厨师的高超技艺是一种良好的礼貌。类似地，已经发现各种物种利用气味来吸引配偶。一种蛾子利用这种气味寻找彼此。然而，人们已经发现，博拉斯蜘蛛可以模仿该物种雌蛾的气味。这种气味会吸引雄蛾，雄蛾会跟着它寻找配偶。相反，当它们到达气味的来源时，它们会被吃掉[8]。这是一种带有敌意的虚假信息。
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 a remote collector was an extension of the delivery of event notification messages and it exhibits the same trust of the network. There are several security consequences of the fundamental simplicity of syslog and 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 networked device consuming any other device.
在本地使用中，syslog进程将事件通知消息放入该系统上的文件中。这依赖于系统的完整性来保护消息。syslog进程的后续配置是使用syslog协议将消息传输到远程收集器，这是事件通知消息传递的扩展，它显示了对网络的相同信任。syslog的基本简单性会带来一些安全后果，而且在需要健壮交付的情况下，该协议的适用性也会受到一些关注。类似地，计算机事件消息可能被意外、错误甚至恶意地发送。然而，在撰写本文时，还没有任何关于任何网络设备使用任何其他设备的报告。
As was described above, the message length MUST NOT exceed 1024 bytes. Attacks have seen where syslog messages are sent to a receiver that have message lengths greater than 1024 bytes. In some older versions of syslog, the receipt of syslog packets that had a message greater than 1024 bytes caused problems. syslog message receivers must not malfunction upon the receipt of packets where the message length is greater than 1024 bytes. Various behaviors have been seen on receivers that do receive messages greater than 1024 bytes. Some have been seen to log the entire contents of the message, while others have been seen to log only portions of the message. Still others have been known to discard the message altogether. Devices MUST NOT retransmit messages whose received length exceeds 1024 bytes.
如上所述，消息长度不得超过1024字节。在攻击中，系统日志消息被发送到消息长度大于1024字节的接收器。在一些旧版本的syslog中，接收到消息大于1024字节的syslog数据包会导致问题。当收到消息长度大于1024字节的数据包时，系统日志消息接收器不得出现故障。在接收大于1024字节的消息的接收器上可以看到各种行为。有些被视为记录消息的全部内容，而另一些被视为只记录消息的一部分。还有一些人则完全放弃了这一信息。设备不得重新传输接收长度超过1024字节的消息。
Similarly, the receiver must rigidly enforce the correctness of the message body. syslog collectors must not malfunction if received messages do not have the less-than and greater-than characters around a valid Priority value. They MUST treat these messages as the unformatted CONTENT as was described in Section 4.3.3 if they relay it.
同样，接收方必须严格执行消息体的正确性。若接收到的消息在有效优先级值周围不包含小于或大于字符，则系统日志收集器不得出现故障。如第4.3.3节所述，他们必须将这些消息视为未格式化的内容，如果他们转发这些消息。
Also, received messages must contain printable text in the message as was described throughout Section 4. Devices must not malfunction if they receive a message containing characters other than the characters described above.
此外，如第4节所述，收到的消息中必须包含可打印文本。如果设备接收到包含上述字符以外的字符的消息，则设备不得出现故障。
The syslog delivery mechanism does not strongly associate the message with the message sender. 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. It should be noted here that the message receiver does not need to verify that the HOSTNAME in the HEADER part match the name of the IP address contained in the Source Address field of the IP packet.
系统日志传递机制不会将消息与消息发送者强关联。该数据包的接收者将无法确定消息是否确实是从报告的发送者发送的，或者该数据包是否是从另一个设备发送的。这里应该注意，消息接收方不需要验证报头部分中的主机名是否与IP数据包的源地址字段中包含的IP地址的名称匹配。
One possible consequence of this behavior 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.
此行为的一个可能后果是，配置错误的计算机可能会将syslog消息发送给将自身表示为另一台计算机的收集器。管理人员可能会感到困惑，因为消息的假定发送者的状态可能无法准确地反映在接收到的消息中。管理员可能无法轻易识别是否有两台或两台以上的机器将自己表示为同一台机器。
It should also be noted that some cases of filling the HOSTNAME field in the HEADER part might only have local significance and that may only be ephemeral. If the device had obtained an IP address from a DHCP pool, then any association between an identifier and an actual source would not always hold true. The inclusion of a fully qualified domain name in the CONTENT may give the administrators the best chance of identifying the source of each message if it can always be associated with an IP address or if it can always be associated with a unique machine.
还应该注意的是，在报头部分填充HOSTNAME字段的某些情况可能只具有局部意义，并且可能只是短暂的。如果设备已从DHCP池获得IP地址，则标识符和实际源之间的任何关联都不会始终为真。如果内容中包含完全限定的域名，则管理员可能会有最好的机会识别每条消息的来源，前提是它始终可以与IP地址关联，或者始终可以与唯一的计算机关联。
Malicious exploits of this behavior have also been noted. An attacker may transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a collector. In one case, an attacker may hide the true nature of an attack amidst many other messages. As an example, an attacker may start generating forged 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. Additionally, 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 forged notification that the process had been restarted. The system administrators may accept that misinformation and not verify that the process had indeed been restarted.
还注意到恶意利用此行为。攻击者可以将系统日志消息（从据称发送消息的机器或任何其他机器）传输到收集器。在一种情况下，攻击者可能会在许多其他消息中隐藏攻击的真实性质。例如，攻击者可能会开始生成伪造消息，指示某台机器上存在问题。这可能会引起系统管理员的注意，他们将花时间调查所称的问题。在此期间，攻击者可能会破坏不同的计算机或同一计算机上的不同进程。此外，攻击者可能会生成虚假的系统日志消息，以提供不真实的状态或事件指示。例如，攻击者可能会停止计算机上的关键进程，从而生成退出通知。攻击者随后可能会生成一个伪造的通知，说明进程已重新启动。系统管理员可能会接受该错误信息，而不会验证进程是否确实已重新启动。
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 the order of their 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.
一般来说，网络异常的取证依赖于事件序列的重建。在一个完美的世界中，消息将按照从其他设备生成的顺序在syslog collector上接收，任何查看这些记录的人都可以准确地了解事件的顺序。不幸的是，syslog进程和协议不能确保有序交付。本节详细介绍了由此可能遇到的一些问题。
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
系统日志记录通常按接收顺序显示（放置在文件中、显示在控制台上等）。这并不总是与它们生成的顺序一致。由于它们是通过IP网络传输的，因此可能会收到一些无序的收据。这可能会导致一些混淆
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. In this, the sending device should utilize an authoritative time source. It should be remembered, however, that not all devices are capable of receiving time updates, and not all devices can timestamp their messages.
可能会收到指示进程在启动前已停止的消息。如果发起进程在传输之前对每个消息都加上时间戳或编号，则这可能会得到某种程度的纠正。在这种情况下，发送设备应利用权威时间源。但是，应该记住，并非所有设备都能够接收时间更新，也不是所有设备都能够为其消息添加时间戳。
In syslog, there is no concept of unified event numbering. Single devices are free to include a sequence number within the CONTENT but that can hardly be coordinated between multiple devices. In such cases, multiple devices may report that each one is 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 the collector receives messages from another device first even though the messages from the first device were generated before the messages from the second. If there is no timestamp or coordinated 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.
在syslog中，没有统一事件编号的概念。单个设备可以自由地在内容中包含一个序列号，但这很难在多个设备之间进行协调。在这种情况下，多个设备可能会报告每个设备正在发送第一条消息。同样，如果发送设备在其消息中利用来自权威源的时间戳，则这可以在某种程度上得到纠正。然而，正如已经注意到的，甚至从单个设备到单个收集器的消息也可能被无序接收。当有多个设备配置为将其系统日志消息发送到单个收集器时，这种情况更加复杂。来自一个设备的消息可能会延迟，因此收集器会首先接收来自另一个设备的消息，即使来自第一个设备的消息是在来自第二个设备的消息之前生成的。如果没有时间戳或协调序列号，则消息可以按照接收它们的顺序呈现，这可能给出实际事件序列的不准确视图。
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.
网络管理员可用的过多配置选项可能会进一步扭曲对事件顺序的感知。可以将一组设备配置为向一个收集器发送状态消息（或其他信息性消息），同时向另一个收集器发送相对较高重要性的消息。此外，可以将消息发送到同一收集器上的不同文件。如果消息不包含来自源的时间戳，则如果消息保存在不同的位置，则可能很难对其进行排序。管理员可能无法确定一个文件中的记录是发生在另一个文件中的记录之前还是之后。通过在所有目标文件中放置带有时间戳的标记消息，这可能会有所缓解。如果这些消息具有协调的时间戳，那么将有一些关于接收单个消息的时间的指示。
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. Even with a TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages and their receipt would falsely indicate normal activity of the machine.
在没有任何序列指示或时间戳的情况下，可以在以后的时间记录和重放消息。攻击者可能会记录一组指示计算机正常活动的消息。稍后，该攻击者可能会将该计算机从网络中删除，并向收集器重播系统日志消息。即使在报头部分有一个时间戳字段，攻击者也可以记录数据包，并在重新传输数据包之前简单地修改数据包以反映当前时间。管理员可能在收到的消息中没有发现任何异常，收到这些消息将错误地指示机器的正常活动。
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.
由于syslog进程或协议中都没有确保传递的机制，并且由于底层传输是UDP，一些消息可能会丢失。它们可能由于网络拥塞而被丢弃，也可能被恶意拦截并丢弃。无法确定删除一个或多个系统日志消息的后果。如果消息是简单的状态更新，那么它们的未接收可能不会被注意到，或者可能会给系统操作员带来麻烦。另一方面，如果消息更重要，则管理员可能没有意识到正在发展的潜在严重问题。作为隐藏未经授权活动的一种方式，攻击者还可能截获和丢弃消息。
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 [9] and UDP protocols which may detect the damage. An intermediary router may discard a damaged IP packet [10]. 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, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities.
除了被丢弃之外，系统日志消息还可能在传输过程中受损，或者攻击者可能恶意修改它们。在包含syslog消息的数据包被损坏的情况下，链路层以及IP[9]和UDP协议中内置了各种机制，可以检测到损坏。中间路由器可以丢弃损坏的IP数据包[10]。UDP数据包的损坏可能会被接收UDP模块检测到，该模块可能会自动丢弃该数据包。在任何情况下，消息的原始内容都不会传递给收集器。此外，如果攻击者位于syslog消息的发送者和收集器之间，则他们可能能够在传输过程中拦截和修改这些消息，以隐藏未经授权的活动。
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 have mechanisms to provide confidentiality of the messages in transit. In most cases passing 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.
阅读并理解它们的含义。syslog协议和syslog应用程序都没有为传输中的消息提供保密性的机制。在大多数情况下，如果操作人员正在嗅探线路上的数据包，传递明文信息对他们来说是一种好处。操作人员可能能够读取消息，并将其与通过电线的其他数据包中看到的其他事件相关联，以跟踪和纠正问题。不幸的是，攻击者也可能能够观察到系统日志消息的可读内容。然后，攻击者可能会利用从这些消息中获得的知识危害机器或造成其他损害。
While the processes that create the messages may signify the importance of the events through the use of the message Priority value, there is no distinct association between this value and the importance of delivery of the packet. 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 Severity value 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.
虽然创建消息的过程可以通过使用消息优先级值来表示事件的重要性，但是该值与分组的交付的重要性之间没有明显的关联。作为一个例子，考虑一个生成两个事件消息的应用程序。第一条消息是正常状态消息，但第二条消息可能是表示进程出现问题的重要消息。第二条消息将具有与该事件的重要性相关联的适当更高的严重性值。如果操作员已配置将这两条消息传输到syslog收集器，则它们将依次发送给UDP进行传输。在正常情况下，它们之间不会有任何区别，它们将按顺序传送。
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.
同样，在正常情况下，接收方会在接收到syslog消息时接受它们。如果许多设备正在传输正常状态消息，但其中一个设备正在传输重要事件消息，则syslog协议中没有内在机制将重要消息优先于其他消息。
On a case-by-case basis, device operators may find some way to associate the different levels with the quality of service identifiers. As an example, the operators may elect to define some linkage between syslog messages that have a specific Priority value with a specific value to be used in the IPv4 Precedence field [9], the IPv6 Traffic Class octet [11], or the Differentiated Services field [12]. 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
在个案基础上，设备运营商可能会找到某种方式将不同级别与服务质量标识符相关联。例如，运营商可以选择在具有特定优先级值的系统日志消息与将在IPv4优先级字段[9]、IPv6通信量类八位字节[11]或区分服务字段[12]中使用的特定值之间定义某种链接。在上面的示例中，操作员可能能够将状态消息与正常传递相关联，同时将指示问题的消息与通过网络的高可靠性、低延迟队列相关联。这将影响在正常状态消息之前对基本消息进行优先级排序。即使采用这种逐跳优先级排序，这种排队机制仍可能导致发送设备上的线头阻塞以及接收设备上的缓冲区不足
device if there are many near-simultaneous messages being sent or received. This behavior is not unique to syslog but is endemic to all operations that transmit messages serially.
如果正在发送或接收许多几乎同时发送的消息，则为设备。这种行为不是syslog独有的，而是串行传输消息的所有操作特有的。
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 indiscriminately 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.
此行为存在安全问题。重要事件消息传输的线首阻塞可能会将重要消息的传输降级到不太重要的消息之后。如果队列被适当地清除，这可能只会增加重要消息传输的秒数。另一方面，如果队列未被清除，则可能不会传输重要消息。同样在接收端，如果syslog接收器由于几乎同时接收大量消息而遭受缓冲区不足，则重要消息可能与其他消息一起被不加区别地丢弃。虽然这些都是设备及其容量的问题，但协议安全问题在于，相对较重要的消息没有优先于不太重要的消息。
Since there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipient. Cases have been noted where devices were inadvertently configured to send syslog messages to the wrong receiver. In many cases, the inadvertent receiver may not be configured to receive syslog messages and it will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient [13]. If messages are not going to the intended recipient, then they cannot be reviewed or processed.
由于没有关于任何消息或配置的控制信息，因此网络管理员完全有责任确保消息实际发送给预期的收件人。已经注意到一些情况，其中设备被无意地配置为向错误的接收器发送系统日志消息。在许多情况下，意外接收器可能未配置为接收系统日志消息，它可能会丢弃这些消息。在某些其他情况下，已知接收系统日志消息会给非预期收件人造成问题[13]。如果邮件没有发送给预期的收件人，则无法对其进行审阅或处理。
As it is shown in Figure 1, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain Priority values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care to not cause such a death spiral.
如图1所示，可以将机器配置为在到达收集器之前将syslog消息中继到后续的中继。在一个特定的案例中，管理员发现他错误地配置了两个中继，将具有特定优先级值的消息转发给彼此。当这些机器中的任何一台收到或生成该类型的消息时，它会将其转发给另一个中继。接力器会反过来将其转发回去。这一周期确实导致介入网络以及两台设备上的处理可用性降级。网络管理员必须注意不要造成这样的死亡螺旋。
Network administrators must take the time to estimate the appropriate size of the syslog receivers. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but that has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a receiver or collector must have a network interface capable of receiving all messages sent to it.
网络管理员必须花时间估计系统日志接收器的适当大小。攻击者可以通过在收集器的磁盘中填充虚假消息来执行拒绝服务攻击。将记录放在循环文件中可能会缓解这一问题，但其后果是无法确保管理员将来能够查看记录。沿着这条线路，接收器或收集器必须具有能够接收发送给它的所有消息的网络接口。
Administrators and network planners must also critically review the network paths between the devices, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links.
管理员和网络规划人员还必须严格审查设备、继电器和采集器之间的网络路径。生成的系统日志消息不应覆盖任何网络链接。
The syslog protocol has been assigned UDP port 514. This port assignment will be maintained by IANA exclusively for this protocol.
系统日志协议已分配UDP端口514。IANA将专门为此协议维护此端口分配。
The syslog protocol provides for the definition of named attributes to indicate the Severity of each message and the Facility that generated the message as described in Section 4. The name space identifiers for these attributes are defined as numbers. The protocol does not define the specific assignment of the name space for these numbers; the application developer or system vendor is allowed to define the attribute, its semantics, and the associated numbers. This name space will not be controlled to prevent collisions as systems are expected to use the same attributes, semantics and associated numbers to describe events that are deemed similar even between heterogeneous devices.
syslog协议提供命名属性的定义，以指示每条消息的严重性以及生成消息的设施，如第4节所述。这些属性的名称空间标识符定义为数字。协议没有为这些数字定义名称空间的具体分配；允许应用程序开发人员或系统供应商定义属性、其语义和相关编号。此名称空间将不受控制以防止冲突，因为系统预期使用相同的属性、语义和关联的数字来描述即使在异构设备之间也被视为相似的事件。
The syslog protocol may be effectively used to transport event notification messages across a network. In all cases, it is important that the syslog message receiver embody the principle of "be liberal in what you accept". It is highly recommended that the network operators who choose to use this understand the characteristics of the protocol and its security implications.
syslog协议可以有效地用于跨网络传输事件通知消息。在所有情况下，syslog消息接收器都必须体现“接受的内容要自由”的原则。强烈建议选择使用该协议的网络运营商了解该协议的特点及其安全含义。
There have been attempts in the past to standardize the format of the syslog message. The most notable attempt culminated in a BOF at the Fortieth Internet Engineering Task Force meeting in 1997. This was the Universal Logging Protocol (ulp) BOF and the minutes of their meeting are on-line at the IETF Proceedings web site [14].
过去曾尝试将syslog消息的格式标准化。最引人注目的尝试在1997年第四十届互联网工程特别工作组会议上以BOF告终。这是通用日志协议（ulp）BOF，他们的会议记录在线在IETF会议记录网站上[14]。
Many good thoughts came from that effort and interested implementers may want to find some of the notes or papers produced from that effort.
许多好的想法来自于这项工作，感兴趣的实现者可能希望找到从这项工作中产生的一些笔记或论文。
At the time of this writing, efforts are underway to allow the usage of international character sets in applications that have been traditionally thought of as being text-only. The HOSTNAME and TIMESTAMP fields described above are representative of this. Also, the entire CONTENT field has traditionally been printing characters and spaces in the code set known as US-ASCII. It is hoped that the proponents of these internationalization efforts will find a suitable way to allow the use of international character sets within syslog messages without being disruptive. It should also be hoped that implementers will allow for the future acceptance of additional code sets and that they may make appropriate plans. Again, it must be cautioned that the simplicity of the existing system has been a tremendous value to its acceptance. Anything that lessens that simplicity may diminish that value.
在撰写本文时，人们正在努力允许在传统上被认为仅为文本的应用程序中使用国际字符集。上面描述的主机名和时间戳字段代表了这一点。此外，整个内容字段传统上一直在被称为US-ASCII的代码集中打印字符和空格。希望这些国际化努力的支持者将找到一种合适的方式，允许在syslog消息中使用国际字符集，而不会造成中断。还应该希望实现者将允许将来接受额外的代码集，并且他们可以制定适当的计划。同样，必须注意的是，现有系统的简单性对其接受具有巨大的价值。任何削弱这种简单性的东西都可能削弱这种价值。
Acknowledgements
致谢
The following people provided content feedback during the writing of this document:
以下人员在编写本文件期间提供了内容反馈：
Jon Knight <J.P.Knight@lboro.ac.uk>
Magosanyi Arpad <mag@bunuel.tii.matav.hu>
Balazs Scheidler <bazsi@balabit.hu>
Jon Callas <jon@counterpane.com>
Eliot Lear <lear@cisco.com>
Petter Reinholdtsen <pere@hungry.com>
Darren Reed <darrenr@reed.wattle.id.au>
Alfonso De Gregorio <dira@speedcom.it>
Eric Allman <eric@sendmail.com>
Andrew Ross <andrew@kiwi-enterprises.com>
George Maslyar <george.maslyar@primark.com>
Albert Mietus <albert@ons-huis.net>
Russ Allbery <rra@stanford.edu>
Titus D. Winters <titus@cs.hmc.edu>
Edwin P. Boon <Edwin.Boon@consul.com>
Jeroen M. Mostert <Jeroen.Mostert@consul.com>
Jon Knight <J.P.Knight@lboro.ac.uk>
Magosanyi Arpad <mag@bunuel.tii.matav.hu>
Balazs Scheidler <bazsi@balabit.hu>
Jon Callas <jon@counterpane.com>
Eliot Lear <lear@cisco.com>
Petter Reinholdtsen <pere@hungry.com>
Darren Reed <darrenr@reed.wattle.id.au>
Alfonso De Gregorio <dira@speedcom.it>
Eric Allman <eric@sendmail.com>
Andrew Ross <andrew@kiwi-enterprises.com>
George Maslyar <george.maslyar@primark.com>
Albert Mietus <albert@ons-huis.net>
Russ Allbery <rra@stanford.edu>
Titus D. Winters <titus@cs.hmc.edu>
Edwin P. Boon <Edwin.Boon@consul.com>
Jeroen M. Mostert <Jeroen.Mostert@consul.com>
Eric Allman is the original inventor and author of the syslog daemon and protocol. The author of this memo and the community at large would like to express their appreciation for this work and for the usefulness that it has provided over the years.
Eric Allman是syslog守护进程和协议的原始发明人和作者。本备忘录的作者和广大社区希望对这项工作以及多年来所提供的有用性表示赞赏。
A large amount of additional information about this de-facto standard operating system feature may usually be found in the syslog.conf file as well as in the man pages for syslog.conf, syslog, syslogd, and logger, of many Unix and Unix-like devices.
有关此事实上的标准操作系统功能的大量附加信息通常可以在syslog.conf文件以及许多Unix和类Unix设备的syslog.conf、syslog、syslogd和logger手册页中找到。
References
工具书类
1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
1 Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
2 Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
2 Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
3 USA Standard Code for Information Interchange, USASI X3.4-1968
3美国信息交换标准代码，USASI X3.4-1968
4 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
4 Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
5 Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987.
5 Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
6 Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
6 Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
7 Data elements and interchange formats - Information exchange - Representation of dates and times, International Organization for Standardization, Reference number ISO 8601 : 1988 (E), 1988
7数据元和交换格式.信息交换.日期和时间的表示，国际标准化组织，参考号ISO 8601:1988（E），1988
8 Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components of Moth Prey Species Sex Pheromones", Science, 1987
8 Stowe，M.等人，“化学模拟：Bolas蜘蛛释放蛾类猎物性信息素的成分”，《科学》，1987年
9 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
9 Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
10 Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
11 Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
12 Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
12 Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
13 Cisco Systems Product Security Incident Response Team (PSIRT),
"Field Notice: Cisco IOS(r) Syslog Crash", January 11, 1999
http://www.cisco.com/warp/public/707/advisory.html
13 Cisco Systems Product Security Incident Response Team (PSIRT),
"Field Notice: Cisco IOS(r) Syslog Crash", January 11, 1999
http://www.cisco.com/warp/public/707/advisory.html
14 Walker, D., IETF Secretariat, "Proceedings of the Fortieth
Internet Engineering Task Force, Washington, DC, USA, December 8-
12, 1997
http://www.ietf.org/proceedings/97dec/index.html
14 Walker, D., IETF Secretariat, "Proceedings of the Fortieth
Internet Engineering Task Force, Washington, DC, USA, December 8-
12, 1997
http://www.ietf.org/proceedings/97dec/index.html
Author's Address
作者地址
Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA
克里斯·朗维克思科系统研究大道12515号。美国德克萨斯州奥斯汀
Phone: +1.512.378.1182
EMail: clonvick@cisco.com
Phone: +1.512.378.1182
EMail: clonvick@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。