syslog协议

RFC3164 - The BSD Syslog Protocol

文档状态

本文档提供了互联网委员会的信息。它不指定任何一种网络规范。对本文档的发布是不受限制的。

摘要

本文描述了syslog协议的实测行为。本协议在互联网上已经使用了很多年，是用来传送事件通知信息的。最初，这个协议在University of California Berkeley Software Distribution (BSD) TCP/IP系统实现中开发，它的实现和管理价值在于，它可以让不同系统相互通信，同时可以嵌入其他网络产品中。

目录

1. 概述

从一开始，生命依赖于信息的传递。对于有自我意识的有机物单位来说，这些信息可以传达很多信息。可能表示危险，食物或其他生命的必需品，以及其他东西。在很多情况下，这些信息被传递到其他个体中，不需要任何应答。和人类交流和创建的过程一样，这些简单的道理同样适用于社会联系。例如，严重的气象预报可能由很多频道同时播出，一场飓风的将保通过电视和电台以及船上的旗语同时传递。在大多数情况下，不对这些警告信息进行任何应答是需要的，或者是期望的。遵循同样的原则，操作系统，进程和应用程序都会发送自己状态的信息，或表示某种事件发生的信息。这些事件信息对于机器操作者通常是很重要的。当操作系统，进程和应用程序变得越来越复杂后，系统开始致力于将这些信息进行分来和日志记录，同时可以让操作人员更快速的从简单的状态信息中区分出问题的通知。Syslog进程是这种系统中被很多操作系统广泛接受的。这个进程的灵活性可以让操作人员配置发送从哪台机器的进程中发出。从一个方面来说，syslog进程接受到的信息可以保存在不同的文件中，同时在设备的控制台进行显示。从另一个方面来说，syslog进程可以通过配置将信息转发到网络中的另一台syslog进程中。Syslog进程对少量事件可以进行网络提醒，因为它知道很多系统操作员没有时间访问系统来查看注册在这里的信息。运行在远程设备上的Syslog进程，可以配置成为将信息加入文件中，或继续转发到其他机器中。

用最简单的话将，syslog协议提供了一种让机器通过IP网络将信息发送通知信息到事件接收器（syslog服务器）的功能。因为每一个进程，应用程序和操作系统是分开开发的，syslog的信息的内容大多都是不同的。正因为这个原因，组成信息的内容没有任何假设。这个协议只是简单的传递这些信息。在任何情况下，有一个设备发出消息。那台机器上的Syslog进程可能将信息发送给收集器。不需要任何应答。

Syslog协议和进程的基本原则是它的简单性。在发送者和接收者之间不需要协调。实际上，syslog信息的发送者可以在接收者没有配置好或根本不存在的情况下进行发送。相反，很多设备会在没有任何配置和定义的情况下收到消息。这种简单性让syslog更容易接受和部署。

1.1. 事件和生成的消息

操作系统，进程和应用程序的编写者完全清楚他们将生成的事件。在某些情况下，生成消息用来说明状态。可以是一段时间一次，也可以由其他方式触发，例如在程序退出时。在其他情况下，消息是由遇到的条件产生的。在这些情况下，不管是状态消息或者包含一些类型的警告都可能被产生。操作系统、进程和应用程序的编写者可能会在详单中确定消息的数量。这些详单中通常包括发出消息的设备，同时包含消息的严重级别。这样，操作员可以有选择的筛选消息，可以更快的定位更加重要的和有处理时间限制的消息，同时可以将状态或消息信息放在文件中，将来阅读他们。其他显示和保存信息的方式也可以存在。

必须在设备中配置一些规则，这些规则可以告诉设备显示还是转发事件消息。这些规则是十分灵活的。管理员可能希望所有的信息都保存在本地，同时所有高优先级的消息都会转发到另一台设备中。他们可能发现，将某些设备的信息发送到一些或所有用户的设备中，同时显示在系统控制台上是很合适的。然而，管理员决定将事件信息发送到syslog收集器中，在收集器中包含了组成设备的信息以及发送的严重级别，同时定义了远程接收器。例如，系统管理员可能想让所有由邮件设备发出额消息被转发到一个特定的事件信息收集器中。管理员还可以让所有内核生成的事件信息被发送到另一台syslog接收器中，同时，将内核产生的critical严重级别的消息发送到第三天设备中。同时，将显示在系统控制台中的信息email给部分用户，同时将他们保存在设备本地磁盘的文件中。反之，可以将本地进程产生的消息显示在控制台中，但不保存也不转发。所有事件的规则都在设备中生成。因为管理员知道收集器会收集到哪种类型的事件，他们会在syslog服务器中配置相应的规则。

消息的内容因创建者而异。建议将消息按照一定格式编写，这样人们就可以阅读他们。在消息中加入时间戳和发出消息的设备以及进程的标识符是一个很好的建议。但他们都不是必须的。

假设任何进程和设备都有可能产生事件消息。可能包含没有任何本地存储空间的设备，例如，打印机，路由器，集线器，交换机以及无盘工作站。在这种情况下，事件消息必须被发送到收集器中，同时必须别记录这样操作员就可以查看了。

1.2. 消息接收者的操作

定义当消息接收到之后如何处理超过了本文的范围。和1.1节的描述一样，他们通常展示被部分用户，保存在磁盘中，再次转发或是上述操作的组合。决定接收到消息如何处理的配置和本地生成消息如何处理的配置是同样的。

作为一个非常普遍的规则，通常是很多设备将消息发到相关的少数收集器中。这种扇入操作允许管理员在相关的少数仓库中汇总信息。

2. 传输层协议

Syslog使用用户数据报（UDP）作为底层传输层协议。Syslog的UDP端口为514。如果消息是由syslog进程发出，建议源端口也是514，不是514也是合法的。如果发送者使用比514大的端口号，那么建议接下来的其他消息也由这个端口发出。

3. 架构定义

本文中将使用如下定义：

l 生成消息的设备被称作“device”。

l 可以接收消息的设备又将消息转发给了其他设备，称作“relay”。

l 接收消息但不进行转发的设备称作“collector”。通常称作syslog服务器。

l 发出消息或转发消息的设备被称作“sender”。

l 任何接收消息的设备，包括转发或收集都称作“receiver”。

设备的架构可以分为以下几点：

1. 发送者发出消息时不知道接收者是collector还是relay。

2. 发送者可以配置成将同一个消息发送给多个接收者。

3. relay可以发送所有从上一个relay或collector收到的消息。某些情况下他们不转发所有信息，他们同时作为collector和relay。在下图中，一些设备被定义成relay。

4. relay可以生成自己的消息，同时将他们发送给下一个relay或collector。这种情况下，他们作为device。这些device同时被定义为下图中的relay。

图1中描述的架构在第一个知道最后一个的时候是合法的。这些例子的其他组都是可接受的。在下图中，所有的relay都可以透传一些或所有他们接收到的消息。

+------+ +---------+

|Device|---->----|Collector|

+------+ +---------+

+------+ +-----+ +---------+

|Device|---->----|Relay|---->----|Collector|

+------+ +-----+ +---------+

+------+ +-----+ +-----+ +---------+

|Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|

+------+ +-----+ +-----+ +---------+

+------+ +-----+ +---------+

|Device|---->----|Relay|---->----|Collector|

| |-\ +-----+ +---------+

+------+ \

\ +-----+ +---------+

\-->--|Relay|---->----|Collector|

+-----+ +---------+

+------+ +---------+

|Device|---->----|Collector|

| |-\ +---------+

+------+ \

\ +-----+ +---------+

\-->--|Relay|---->----|Collector|

+-----+ +---------+

+------+ +-----+ +---------+

|Device|---->----|Relay|---->-------|Collector|

| |-\ +-----+ /--| |

+------+ \ / +---------+

\ +-----+ /

\-->--|Relay|-->--/

+-----+

Diagram 1. Some Possible syslog Architectures

4. 包结构和内容

所有目的端口为514的UDP报文都是syslog消息。原来的syslog消息和转发的syslog消息可以不同。其实，建议按照本文中描述的格式发送syslog消息报文，但不是必须的。如果relay可以识别消息，在转发时不能进行任何修改。然而，如果relay收到消息后不能正确解析消息，那么它可以在重传之间按照自己的格式进行修改。4.1节中将会描述syslog消息推荐的格式。4.2节将描述源消息，4.3结描述relay的消息的需求。

4.1. Syslog消息部分

Syslog的完整格式由三个可识别的部分组成。第一部分是PRI，第二部分是HEADER，第三部分是MSG。报文的总长度必须是1024字节之内。Syslog消息的最小长度没有定义，但发送一个长度为空的消息是没有意义的。

4.1.1. PRI

PRI必须是三个，四个或五个字符，并且第一个和最后一个字符是尖括号。PRI部分以“<”开始，接着是数字，最后是“>”。数字的编码必须是7位ASCII格式。这里的ASCII码是“USA Standard Code for Information Interchange”。在这里，“<”字符被定义成（ABNF）格式“%d60”，同时，“>”字符定义成ABNF “%d62”。尖括号中间的数字是优先级，表示前文描述的设备和严重级别。优先级由1，2或3个数字组成，使用%d48表示0到%d57表示9。

消息的设备和优先级都编码成十进制数字。一些操作系统守护进程和进程已经有设备编号了。没有可用显示编号的进程和守护进程使用本地设备或用户级别的设备。这些设备的编号如下表所示。

Numerical Facility

Code

0 kernel messages

1 user-level messages

2 mail system

3 system daemons

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21 security/authorization messages (note 1) messages generated internally by syslogd line printer subsystem network news subsystem UUCP subsystem clock daemon (note 2) security/authorization messages (note 1) FTP daemon NTP subsystem log audit (note 1) log alert (note 1) clock daemon (note 2) local use 0 (local0) local use 1 (local1) local use 2 (local2) local use 3 (local3) local use 4 (local4) local use 5 (local5)

22 local use 6 (local6)

23 local use 7 (local7)

Table 1. syslog Message Facilities

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.

每个消息优先级有一个十进制的严重级别编号。如表所示：

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

Table 2. syslog Message Severities

优先级是设备编号乘以8，然后加上严重级别。例如，内核消息（设备编号为0），和紧急严重级别（级别0）的优先级是0。这样，本地用户消息（设备编号20）和通知级别（级别5），得到的优先级是165。在syslog消息的PRI部分中，这些值被包含在尖括号中，例如<0>和<165>。只有一种情况，当0跟着<时，表示优先级为0。其他情况，不能以0开头。

4.1.2. Syslog报文的HEADER部分

HEADER部分包含时间戳以及设备的主机名或IP地址。Syslog的HEADER部分必须使用可见（可打印）的字符。字符集必须使用PRI中的ASCII字符集。在这些字符集中，唯一允许的字符集是ABNF VCHAR值(%d33-126)，以及空格(%d32)。

HEADER中包含连个字符安，称作TIMESTAMP和HOSTNAME。TIMESTAMP紧跟着PRI中的“>”。TIMESTAMP和HOSTNAME之间用一个空格分隔。HOSTNAME包含主机名。如果没有主机名，将会包含主机的IP地址。如果设备有多个IP地址，将会使用发送数据的IP地址。两者可以选一个发送。在这种情况下，device可能被配置成使用一个源IP发送所有的消息，不管消息实际从哪个接口发出。这种方式为所有的消息的HOSTNAME字段提供了一致性。

TIMESTAMP是本地事件，格式是“Mmm dd hh:mm:ss”：

Mmm是月份的英文缩写，以一个大写的M开始，两个小写的m结束。取值如下：

Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec。

dd是一个月中的天数。如果小于10，必须表示成空格然后是数字。例如8月的第七天表示成为“Aug 7”，其中g和7之间有两个空格。

hh:mm:ss是本地时间。小时表示成为24小时的格式，合法值是00到23。分钟和秒是00到59。

在TIMESTAMP之后需要有一个空格。

HOSTNAME字段包含发送者的主机名或IP地址。最好的名称是主机名。如果使用主机名，HOSTNAME字段必须包含STD 13中描述的主机名。其中不能包含任何空格主机名不能包含在HOSTNAME字段中。如果使用IPv4地址，必须是点分十进制。如果是IPv6格式，使用RFC 2373中的格式。HOSTNAME字段之后也必须有一个空格。

4.1.3. Syslog报文的MSG部分

MSG部分是syslog报文的剩余部分。通常它包含生成这个消息进程的其他信息，以及消息

的文本内容。这部分没有结束分隔符。Syslog报文的MSG部分必须包含可见的（可打印）的字符。通常使用和PRI以及HEADER部分一样的ASCII字符集。在这个字符集中，允许的字符是ABNF VCHAR(%d33-126)以及空格(SP value %d32)。然而，在MSG中使用的字符集既没有指定，也不是期待的。可以使用其他的字符集，只要这些字符集中的包含上文描述的可见字符和空白字符即可。包含不可见字符集的消息不能被展示，也不能被接收者理解，不会给操作员或管理员任何信息。

MSG部分有两个字段，分别是TAG和CONTENT。TAG字段的值是产生消息的程序或进程名称。CONTENT部分包含消息的湘西信息。通常是开放格式的消息，包含事件的一些详细信息。TAG是32个字符之内的ABNF数字字母字符集。任何非数字字母的字符会被当作TAG字段的结束标记，并且这个字符会当作CONTENT字段的开始。CONTENT字段的第一个字符表示TAG字段的结束，通常是方括号“[”，冒号“:”或者空格。在5.3节中有详细描述。

4.2. 设备原生的syslog报文

从设备发出syslog报文时，对内容没有任何需求。需要重申的是，任何UDP 514端口的IP报文，都要当作合法的syslog报文。建议syslog报文有4.1节描述的所有部分－PRI，HEADER以及MSG，这样可以让接收者更容易读懂，并且减少了relay修改消息的需要。

要生成推荐格式的syslog消息，请遵循下述指导：

l 如果最初的消息的HEADER部分含TIMESTAMP，这个字段的内容应该是device时区的本地时间。

l 如果最初的消息有HOSTNAME字段，需要包含它自己知道的主机名。如果没有主机名，需要包含自己的IP地址。

l 如果最初的消息有TAG字段，这个字段应该是生成消息的程序或进程的名称。

4.3. 转发的syslog报文

转发一个报文时，需要校验PRI是否合法。如果第一个字符不是小于号，这个relay必须认为这个报文没有包含合法的PRI。如果第三个，第四个或第五个字符不是友尖括号，relay必须认为原生报文中不包含PRI字段。如果relay找到了合法的PRI，那么它必须校验HEADER报文中的TIMESTAMP字段。按照上述规则，对于收到的消息，有三种处理方式。表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

Table 3. Cases of Received syslog Messages

4.3.1. 合法的PRI和TIMESTAMP

如果relay发现了合法的PRI和合法的TIMESTAMP，那么会校验它自己内部的配置。Relay必须配置成根据syslog报文的优先级进行转发。如果relay根据配置发现需要转发报文，那么必须在不对报文进行任何修改的情况下进行转发。为了强调这一点，建议原生的syslog消息遵循4.1节中描述的格式。

需要注意的是，消息接收者不需要校验TIMESTAMP的字段。这种假设在一个设备没有正确设置时间的时候仍然可以发送合法的syslog消息。另外，relay不需要校验HOSTNAME字段的主机名和IP地址是否和发送消息的主机一直。原因可以在4.1.2节中找到。

4.3.2. 合法的PRI但没有TIMESTAMP或TIMESTAMP不合法

如果relay在syslog报文中没有发现合法的TIMESTAMP，它必须在PRI之后添加一个TIMESTAMP以及空格。同时应该在TIMESTAMP之后加上HOSTNAME和空格。这些字段在

4.1.2节中有描述。收到报文的剩下部分必须当作MSG部分的CONTENT字段以及填充字符。因为relay不知道设备中发出报文的进程，所以不需要包含TAG字段。

TIMESTAMP字段必须是relay的本地时间。

HOSTNAME字段是relay知道的设备名称。如果不知道，就使用设备的IP地址。

如果relay在PRI部分之后添加了TIMESTAMP或者是TIMESTAMP和HOSTNAME，必须检查报文的长度是否小于或等于1024字节。如果报文超过1024字节，必须截断到1024字节。这样可能丢失原有报文中的重要信息。所以建议在原生的syslog报文中就加上PRI和HEADER部分，这些字段在4.1节中描述。

4.3.3. 没有PRI或没有可识别的PRI

如果relay收到了没有PRI或不可识别PRI的报文，必须插入优先级为13的PRI以及4.3.2节中定义的TIMESTAMP。Relay中应该同时插入4.3.2节中描述的HOSTNAME。收到的整个报文的内容都被当作MSG部分的CONTENT字段以及填充字符。

例如，一个不可识别的PRI可能是“<00>”。可能是消息的头4个字符。继续这个例子，如果relay收到一个syslog消息，前4个字符是<00>，那么将会使用这种配置。如果它将优先级为13的syslog消息传递到了另一个relay或collector，必须按照上述要求修改报文。做这件事的详细信息，包括插入HOSTNAME，在下面进行描述。

Originally received message

<00>...

Relayed message

<13>TIMESTAMP HOSTNAME <00>...

如果relay在PRI之后添加了TIMESTAMP或TIMESTAMP和HOSTNAME，必须校验报文的长度是否超过1024个字节。如果报文超过1024个字节，必须进行截断。这样会导致丢失报文后面的重要信息。所以建议生成syslog报文时就加上PRI和HEADER部分。

5. 转换

在第4部分中描述了syslog协议的格式和内容的要求，经过了长期的修改，需要进行一些转换。这些条目不是强制的，但最好作为实现的补充，给与接收者一些额外的补充。

5.1. 日期和时间

有些网络管理员喜欢压缩保存很长一段时间的syslog消息。一些原生的syslog消息包含了明确的时间戳，它的年字段是2个或4个字符的，紧接着这个字段的是TIMESTAMP的空格结束符。排序和格式化这个字段会遇到这个一致性的问题。如果实现者想在发送的消息中增加更详细的日期和时间戳，应该包含在CONTENT字段中。实现者可能希望使用ISO 8601的日期和时间格式，如果您想包含更精确的日期和时间信息。

已经提出了其他的长期压缩方法，其中的一部分有成功的案例。一种方式是网络管理员修改collector保存的信息。可以通过运行一个简单脚本的方式为每一条记录添加年和其他信息。另外，管理员可以定义脚本替换时间的格式。另一种方法是将消息保存到文件中的时候包括当前的年份。关联的方式是，这个记录相邻的所有其他记录都保存相同的年份。以上两种方法都需要为每个记录关联当前时区。

5.2. 域名和地址

要容易的识别产生消息的device，一个好的方法是在CONTENT字段中包含完整的域名（FQDN）和IP地址。通常，只有HOSTNAME字段中包含了域名。

5.3. 产生消息的进程信息

一个很好的方法是当设备产生消息时，包含一些关于进程的信息，如果这个概念存在的话。一个健壮的操作系统，通常都有进程名称和进程ID。通常，进程名称在TAG字段中展示。通常，附加信息被存放在CONTENT字段的开始。格式是TAG[pid]。左边的方括号用来结束TAG字段，这种情况下，第一个字符在CONTENT字段中。如果进程ID不重要，就忽略。这种情况下，在TAG字段后面通常是一个冒号和空格，例如“TAG: ”。这种情况下，冒号就是CONTENT字段的开始。

5.4. 示例

例如，在两个连接的机器之间发现了一个合法的消息。在下面的例子中，每一个消息都是犬牙交错的，文档中使用行分隔符使得消息更可读。

Example 1

<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick

on /dev/pts/8

这个例子展示了在尝试得到额外信息时出现了一个认证错误。同时展示了用户尝试的命令。这是从mymachine这台机器中发出的一个简单消息。如果relay收到这个消息，将在发送前不会做任何修改，只要它包含合适的PRI部分，HEADER 部分中包含TIMESTAMP字段。这个例子中TAG值是进程名称“su”。冒号结束了TAG字段，它是CONTENT字段的开始。在这种情况下，进程id认为是短暂的，并且任何查看这个syslog消息的用户不会从进程id中的得到任何有用的信息。正因为没有包含进程id，所以CONTENT字段的前两个字符是冒号和空格。

Example 2

Use the BFG!

这也是一个合法的消息，很不寻常，也没有用处。这个消息没有任何可辨识的PRI部分。没有包含时间戳和任何关于消息源的信息。当这个消息保存在纸上或磁盘中时，以后再看这个消息时将不会从中了解任何东西。

这个例子显然是从device中发出的原生消息。Relay必须在转发之前对消息进程修改，修改的方法在4.3节中描述。最终relay转发的消息如下：

<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!

在relay的消息中，整个报文被当作MSG部分的CONTENT字段。首先，添加一个合法的PRI，优先级是13。然后，加入一个时间戳，之后是HEADER部分的HOSTNAME字段。最后，relay

不会再对消息进行任何深入的修改。注意，每月的天数小于10。因为，TIMESTAMP的格式中，单独的5之前有一个空格，所以在TIMESTAMP中月份后面有两个空格。同时，relay不知道发出消息的主机的任何信息，所以在HOSTNAME字段中添加了设备的IP地址。

Example 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 # %%

这个消息有一个合法的PRI，优先级表示它定义了一个本地的设备，级别是提示。HEADER部分有一个合适的TIMESTAMP字段。Relay在发送这个消息之前不会进行修改。然而，HOSTNAME和TAG字段和第4部分的定义不一致。HOSTNAME字段是CST，MSG部分的开始是1987。包含在这个例子中CONTENT字段不是遥感勘测额数据，也不是管理或获得数据。根据第6部分列出的安全考虑，消息的种类不能在协议中传送。

Example 4

<0>1990 Oct 22 10:52:01 TZ-6 scapegoat. 10.1.2.3

sched[0]: That's All Folks!

这个例子中有许多额外的信息。人和自动化的解析器可以识别其中的日期和时间，一个完全的域名和IP地址。这个信息中包含的事件的实质是很少的。根据这个事件的严重级别，进程不能收集和发送更详细的信息。收集和发送出这些信息已经很不错了。

这个例子很显然是从一个设备中产生的。因为HEADER部分的第一个字段不是4.1.2节中定义的TIMESTAMP，它会被relay修改。Relay会添加TIMESTAMP并且应该随后添加HOSTNAME，

同时将PRI部分的之后的整个部分从原有报文中取出，封装在新报文中。HOSTNAME字段使用的主机名，relay不知道域名。TAG值不会添加在转发的报文中。在原有报文中包含域名和IP地址是一个很好的尝试，但和4.1.2节中描述的格式不符。

<0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6

scapegoat. 10.1.2.3 sched[0]: That's All Folks!

6. 安全考虑

名声可以看作是一个消息，不需要任何应答。人们避免坏名声，被好的名声吸引。收到名声或气味不需要应答，事实上它应该更加谨慎，完全忽略一些名声。另一方面，对从厨房里飘出来美味的食物进行应答是有礼貌的。类似的，很多五种使用气味吸引异性。一种蛾子使用气味找到同伴。然而，蜘蛛可以仿造这种雌性蛾子的气味。这种气味会吸引雄性蛾子。当他们达到气味的源头时，会被吃掉。这是有敌意的发送错误消息。

在本地使用中，syslog进程将每一个事件通知保存在系统中的文件中。这依赖于系统对消息完整性的保护。随后，将syslog进程配置成为向远程collector发送消息作为事件通知的一部分，这样显示了网络同样的信任情况。由于syslog的简单性，会产生很严重的后。，同时，在需要可信传输的过程中，需要考虑一些适用性。根据以上类比，计算机事件消息是突然的，错误的，甚至是有敌意的。最后，到现在为止，没有报道着一台设备吃了另一台设备。

6.1. 报文变量

如上文描述，消息的长度不能超过1024个字节。攻击者发送长于1024字节的报文。在一些老版本的syslog中，收到超过1024个字节的报文会出现错误。Syslog消息接收者在收到超过1024字节的报文后不能出现故障。在收到超过1024个字节报文后可以有很多行为。一些是将整个报文记录到日志中，其他的是将一部分记录到日志中，还有人直接丢弃报文。当设备收到超过1024个字节的报文后，不能重传。

类似的，接收者必须严格的校验消息内容。Syslog collector不能在收到小于或大于一个合法的优先级值后出现问题。如果要转发，必须将报文当作没有格式的CONTENT字段。

同时，消息中必须包含第4节中描述的可打印文本。收到其他字符时，不能出错。

6.2. 消息真实性

Syslog发送机制在发送者和接收者之间没有强制关联。接收者不知道消息是不是确实是从发送者那里发出的还是从另一台机器中恶意伪造的。注意，接收者不需要校验HEADER部分的HOSTNAME是否和报文源IP地址中的IP地址一直。

6.2.1. 认证错误

这种行为的一个后果就是一台配置错误的机器向collector发送syslog消息，而这个消息被认为是另一台机器发出的。管理员会因为消息没有反应精确的状态而感到疑惑。管理员不能立即发现有两个或两个以上的机器被当作了同样的机器。

同时值得注意的是，有时填充HEADER部分的HOSTNAME字段可能只在本地有意义，并且只是短暂的。如果设备使用DHCP协议获得IP地址，那么这个标识符和实际的发送源的关联关系不一定是真的。在CONTENT部分中包含完整的域名可以让管理员更容易的知道每一个消息的源头，如果每台机器都有唯一的IP地址，也可以关联IP地址。

6.2.2. 伪造消息

还要注意恶意的伪造情况。一个攻击者可能向collector发送syslog消息。这种情况下，攻击者可能隐藏在许多真实消息之间攻击。例如，攻击者可以在伪造消息中指明一些主机的一些错误信息。系统管理员会花费精力去处理这些所谓的错误。在这段时间里，攻击者可能攻击另一台机器或这台机器上的另一个进程。同时，攻击者可能生成错误的syslog消息，包含不真实的状态和事件。例如，攻击者可以终止机器中的关键进程，但生成一个通知级别的消息。攻击者接下来可以生成进程被重启的虚假消息。系统管理员会收到错误的信息，不能确定进程是否真的被重启了。

6.3. 有序传送

作为一般规则，辨别网络异常需要依赖于事件序列的重建。在理想世界中，syslog collector收到其他设备发送的消息都有正确的顺序。不幸的是，syslog进程和协议不能确保按顺序传送。本节讨论这种情况带来的可能问题。

6.3.1. 单一源和单一目的地

Syslog记录通常以接收到的顺序记录。这通常不是消息发生的顺序。因为他们在IP网络中传送，可能发生顺序的变化。这可能导致一些误解，例如先收到进程终止的消息，然后再收到进程启动的消息。如果消息源在消息中加入时间戳或序号，可以解决这个问题。这种情况下，发送设备需要使用官方的时间。需要注意的是，不是所有设备都可以收到时间更新，不是所有设备在消息中添加时间戳。

6.3.2. 多个源一个目的地

在syslog中，没有统一的事件编号概念。单一设备可以自由的在CONTENT中加入序列号，但多个设备不能这样。在这种情况下，多个设备可能都发送编号为1的消息。再一次的，这种问题可以通过在报文中包含使用官方源的时间戳解决。即使这样，单一设备和单一接收器的顺序都有可能出错。这种情况是在有多个设备被配置成为向单一collector发送消息时出现。一个设备发出的消息可能被延迟，这样collector先收到第二台设备的消息，但实际上，是第一台设备先发出消息的。如果没有时间戳或序列号，消息只能以收到的时间进行排序，这样得到的结果就不是正确的。

6.3.3. 多个源和多个目的

网络管理员可以的过多配置可能导致事件的顺序出错。可能可以配置一组设备，向一个collector发送info级别的消息，于此同时向另一个collector发送更高级别的消息。同时，消息可以记录在一个collector的不同文件中。如果消息中没有包含源头的时间戳，那么如果消息的顺序不正确，就不能为消息进行排序。管理员不能确定一个文件中的一条记录是否早于另一个文件中的另一条记录。在所有的目标文件中加入时间戳可以在一定程度上缓解这个问题。如果有相关的时间戳，每一个消息就有接收到的时间记录。

6.3.4. 转发

没有任何表示或记录，消息会被记录，并随后被转发。攻击者可以记录一组消息，了解机器的活动情况。然后，攻击者可以从网络中删除这台机器，但向collector转发syslog消息。计算在HEADER部分有TIMESTAMP字段，攻击者也可以记录报文，并且在重传之前轻易的修改它，用以反映现在的时间。管理员在收到报文后不会发现任何问题。

6.4. 可信传输

Syslog进程和协议中都不确保可信传输，因为传输层是UDP，所以一些报文会丢失。他们可能在网络阻塞时被丢弃，也可能因为受损被丢弃。丢失一个或多个消息不能被检测出来。如果消息是简单的状态更新，那么没有接收到也不会有什么影响，或者会造成系统操作员疑惑。另一方面，如果消息很重要，管理员就不能知道潜在的问题。消息可能被攻击者解析并丢弃，用来隐藏未授权的活动。

6.5. 消息完整性

除了丢弃之外，syslog消息可能在传输过程中被损坏，攻击者可能恶意的修改。在包含syslog消息的报文可能被破坏的情况下，在链路层到IP层以及UDP协议中都有检测破坏的方法。路由器可以丢弃受损的IP报文。UDP接收模块可以丢弃受损的UDP报文，他们都是静默的丢弃。在上述情况下，原来的消息内容不能传送到collector。同时，如果攻击者位于发送者和接收者之间，可能在消息传送的过程中解析并修改消息，用以隐藏未授权的活动。

6.6. 消息观察

没有关于时间消息格式的严格要求，大多数syslog消息都是人类可读的格式，这样管理员可以阅读他们并知道含义。Syslog协议和syslog程序都没有提供报文传送的加密特性。大多数情况下使用明文对于操作员来说是合适的，如果管理员使用嗅探器。操作员可以读取消息，并且将他们和其他报文关联，定位和纠正错误。不幸的是，攻击者也可以查看syslog消息中的内容。攻击者可以使用从消息中获取的知识来攻击一个计算机或进行其他破坏。

6.7. 消息排序和区分

当进程创建消息时，会根据消息的优先级判断事件的严重性，这个值和报文发送的重要性无关。例如，假设一个应用程序生成两个事件消息。第一个是一般级别的消息，但第二个是一个严重级别的消息，表明进程出现了一个错误。第二个消息有一个关于事件的高的严重级别。如果操作员配置将两个事件都发送到syslog收集器中，它们将轮流使用UDP进行发送。在一般情况下，它们之间的发送顺序没有区别。

再次，在一般的情况下，接收者将会接收它收到额消息。如果设备发出了一般状态消息，但其中一个是重要的事件信息，在syslog没有办法让高优先级的消息在其他消息之前发送。

在case-by-case的情况下，设备操作者可以找到一些使用服务标识符关联不同级别的方法。例如，操作员可以选择定义一些syslog消息和特殊优先级之间的关系，将一个特殊值放在IPv4的优先级字段中，IPv6的Traffic Class字节中或区分服务字段中。在上述例子中，操作员可以将状态信息和一般的传输优先级关联，为表示错误的消息赋予更高的优先级，等待时间更少的队列中。这样优先级更高的关键消息可以在一般状态消息之前发送。即使有这种相对的优先级，这些队列操作也会收到传输时线路阻塞的影响。如果有很多相关的消息发送或接收，接收端的缓冲区也会占满。这种行为不但在syslog中出现，而且在所有的连续传输消息的操

作中都会出现。

这种行为有安全考虑。首先在线路中传送重要的事件消息，当出现更重要的消息时，会让不重要一些的消息降级。如果队列在其当的时间清空，只会在传送重要消息的时候多几秒的延迟。另一方面，如果队列没有清空，重要的消息不能被发送。对于接收端来说，如果syslog接收器的缓冲区已近因为同时收到很多报文而耗尽，那么重要的消息会和其他消息一起被丢弃。虽然这是设备和他容量的问题，这个协议的安全考虑是对于在消息之间没有相对优先级。

6.8. 错误配置

因为没有关于消息或配置的控制消息，确保消息发送到了正确的接收者完全是管理员的责任。前面已经说明了配置错误的接收者导致的后果。在很多情况下，接收者接收到没有配置的syslog消息后会丢弃它。在其他情况下，syslog接收者知道未期待的接收会引发错误。如果消息没有发送到关注它的接收者，那么就不能被看到和处理。

6.9. 循环转发

在图1中已经说明，可以在转发syslog消息到collector之前进行转发。在一个特殊的情况下，管理员发现一个错误配置导致两个relay互相转发某个优先级的消息。当这两个机器中的其中一个发生或收到一个消息时，它们都会将消息转发给对方，对方同样，会传回消息。这种循环导致两个设备之间的网络利用率降低。管理员必须小心配置，以免出现死循环。

6.10. 加载考虑

网络管理员必须花时间估计syslog接收者的数量。攻击者可能通过向collector发送错误消息，让错误消息占满硬盘进行拒绝服务攻击。将记录放在循环文件中可以解决这个问题，但这样的话管理员就不能看到以前的消息了。这种情况下，接收者或collector的网络接口必须有可以接收所有发送给它消息的能力。

管理员和网络计划员必须谨慎额查看设备，relay和collector之间的网络路径。已发出的syslog消息不能将任何网络连接宕机。