本文档提供了互联网委员会的信息。它不指定任何一种网络规范。对本文档的发布是不受限制的。
摘要
本文描述了syslog协议的实测行为。本协议在互联网上已经使用了很多年，是用来传送事件通知信息的。最初，这个协议在University of California Berkeley Software Distribution (BSD) TCP/IP系统实现中开发，它的实现和管理价值在于，它可以让不同系统相互通信，同时可以嵌入其他网络产品中。
目录
- 概述
从一开始，生命依赖于信息的传递。对于有自我意识的有机物单位来说，这些信息可以传达很多信息。可能表示危险、食物或其他生命必需品，以及其他东西。在很多情况下，这些信息被传递到其他个体中，不需要任何应答。和人类交流和创建的过程一样，这些简单的道理同样适用于社会联系。例如，严重的气象预报可能由很多频道同时播出，一场飓风的到来将通过电视和电台以及船上的旗语同时传递。在大多数情况下，不对这些警告信息进行任何应答是需要的，或者是期望的。遵循同样的原则，操作系统、进程和应用程序都会发送自己状态的信息，或表示某种事件发生的信息。这些事件信息对于机器操作者通常是很重要的。当操作系统，进程和应用程序变得越来越复杂后，系统开始致力于将这些信息进行分类和日志记录，同时可以让操作人员更快速的从简单的状态信息中区分出问题的通知。Syslog进程是这种系统中被很多操作系统广泛接受的。这个进程的灵活性可以让操作人员配置从机器的进程中发送消息的目标。一方面，syslog进程接受到的信息可以保存在不同的文件中，同时在设备的控制台进行显示。另一方面，syslog进程可以通过配置将信息转发到网络中的另一台syslog进程中。Syslog进程对少量事件可以进行网络提醒，因为它知道很多系统操作员没有时间访问系统来查看注册在这里的信息。运行在远程设备上的Syslog进程，可以配置成为将信息加入文件中，或继续转发到其他机器中。
用最简单的话讲，syslog协议提供传输功能，以允许机器通过IP网络将事件通知消息发送到事件消息collector（也称为系统日志服务器）。因为每一个进程、应用程序和操作系统是分开开发的，syslog的信息的内容大多都是不同的。因此，不会对消息的格式或内容做出任何假设。这个协议只是简单的传递这些信息。在任何情况下，有一个设备发出消息。那台机器上的Syslog进程可能将信息发送给collector。不需要任何应答。
Syslog协议和进程的基本原则是它的简单性。在发送者和接收者之间不需要协调。实际上，syslog信息的发送者可以在接收者没有配置好或根本不存在的情况下进行发送。相反，很多设备会在没有任何配置和定义的情况下收到消息。这种简单性让syslog更容易接受和部署。
1.1. 事件和生成的消息
操作系统、进程和应用程序的编写者完全清楚他们将生成的事件。在某些情况下，生成消息用来说明状态。可以是一段时间一次，也可以由其他方式触发，例如在程序退出时。在其他情况下，消息是由遇到的条件产生的。在这些情况下，不管是状态消息或者包含一些类型的警告都可能被产生。操作系统、进程和应用程序的编写者可能会在详单中确定消息的数量。这些详单中通常包括发出消息的设备，同时包含消息的严重级别。这样，操作员可以有选择地筛选消息，可以更快的定位更加重要的和有处理时间限制的消息，同时可以将状态或消息信息放在文件中，将来阅读他们。其他显示和保存信息的方式也可以存在。
必须在设备中配置一些规则，这些规则可以告诉设备显示还是转发事件消息。这些规则是十分灵活的。管理员可能希望所有的信息都保存在本地，同时所有高优先级的消息都会转发到另一台设备中。他们可能发现，将某些设备的信息发送到一些或所有用户的设备中，同时显示在系统控制台上是很合适的。然而，管理员决定将事件信息发送到syslog collector中，在collector中包含了组成设备的信息以及发送的严重级别，同时定义了远程接收器。例如，系统管理员可能想让所有由邮件设备发出的消息被转发到一个特定的事件信息collector中。管理员还可以让所有内核生成的事件信息被发送到另一台syslog接收器中，同时，将内核产生的critical严重级别的消息发送到第三台设备中。同时，将显示在系统控制台中的信息email给部分用户，同时将他们保存在设备本地磁盘的文件中。反之，可以将本地进程产生的消息显示在控制台中，但不保存也不转发。所有事件的规则都在设备中生成。因为管理员知道collector会收集到哪种类型的事件，他们会在syslog服务器中配置相应的规则。
消息的内容因创建者而异。建议将消息按照一定格式编写，这样人们就可以阅读他们。在消息中加入时间戳和发出消息的设备以及进程的标识符是一个很好的建议。但他们都不是必须的。
假设任何进程和设备都有可能产生事件消息。可能包含没有任何本地存储空间的设备，例如打印机、路由器、集线器、交换机以及无盘工作站。在这种情况下，将事件消息传送到collector可能是必要的，以便操作者可以记录并希望看到它们。
1.2. 消息接收者的操作
定义当消息接收到之后如何处理超过了本文的范围。和1.1节的描述一样，它们通常可以显示给适当的人员，保存到磁盘上，进一步转发，或者这些的任何组合。用于确定接收到的消息的配置规则与用于确定本地生成的消息的配置规则相同。
作为一个非常普遍的规则，通常是很多设备将消息发到相关的少数collector中。这种扇入操作允许管理员在相关的少数仓库中汇总信息。
- 传输层协议
Syslog使用用户数据报（UDP）作为底层传输层协议。Syslog的UDP端口为514。如果消息是由syslog进程发出，建议源端口也是514，不是514也是合法的。如果发送者使用比514大的端口号，那么建议接下来的其他消息也由这个端口发出。
- 架构定义
本文中将使用如下定义：
l 生成消息的设备被称作“device”。
l 可以接收消息的设备又将消息转发给了其他设备，称作“relay”。
l 接收消息但不进行转发的设备称作“collector”。通常称作syslog服务器。
l 发出消息或转发消息的设备被称作“sender”。
l 任何接收消息的设备，包括转发或收集都称作“receiver”。
设备的架构可以分为以下几点：
-
发送者发出消息时不知道接收者是collector还是relay。 -
relay可以发送所有从上一个relay或collector收到的消息。某些情况下他们不转发所有信息，他们同时作为collector和relay。在下图中，一些设备被定义成relay。 -
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|-->--/
+-----+
图 1. 一些可能的系统日志架构
- 包结构和内容
所有目的端口为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 security/authorization messages (note 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)
Table 1. syslog Message Facilities
Note 1 - 已经发现各种操作系统利用设施4,10,13和14来进行
安全/授权、审核和警报消息，这似乎是类似的。
Note 2 - 已经发现各种操作系统将设备9和15用于时钟（cron / at）消息。
每个消息优先级有一个十进制的严重级别编号。如表所示：
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中使用的字符是与上述类似的可见的字符和空格。包含不可见字符集的消息不能被展示，也不能被接收者理解，不会给操作员或管理员任何信息。
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的字段。可以假设日期未正确设置的设备仍然具有发送有效的系统日志消息的能力。另外，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个字符。如果中继确实接收到前四个字符为“<00>”的系统日志消息，则会查询其配置。如果它将优先级为13的syslog消息传递到了另一个relay或collector，必须按照上述要求修改报文。做这件事的详细信息，包括插入HOSTNAME，在下面进行描述。
Originally received message
Relayed message
<13>TIMESTAMP HOSTNAME <00>...
如果relay在PRI之后添加了TIMESTAMP或TIMESTAMP和HOSTNAME，必须校验报文的长度是否超过1024个字节。如果报文超过1024个字节，必须进行截断。这样会导致丢失报文后面的重要信息。所以建议生成syslog报文时就加上PRI和HEADER部分。
- 转换
在第4部分中描述了syslog协议的格式和内容的要求，经过了长期的修改，需要进行一些转换。必须明确地指出，这些项目并不是强制性的，而是可以由执行者考虑到完整性，并向接收方提供其起源和性质的其他线索。
5.1. 日期和时间
有些网络管理员喜欢压缩保存很长一段时间的syslog消息。一些原生的syslog消息包含了明确的时间戳，它的年字段是2个或4个字符的，紧接着这个字段的是TIMESTAMP的空格结束符。这与字段的顺序和格式的原始意图不一致。如果实现者想在发送的消息中增加更详细的日期和时间戳，应该包含在CONTENT字段中。如果要包含更明确的日期和时间信息，实施者可能希望使用ISO 8601的日期和时间格式。
已经提出了解决长期归档愿望的其他方法，一些已经成功实施。一种方式是网络管理员修改collector保存的信息。可以通过运行一个简单脚本的方式为每一条记录添加年和其他信息。另外，管理员可以定义脚本替换时间的格式。另一种方法是将消息保存到文件中的时候包括当前的年份。关联的方式是，这个记录相邻的所有其他记录都保存相同的年份。以上两种方法都需要为每个记录关联当前时区。
5.2. 域名和地址
为了容易识别发起消息的设备，在CONTENT字段中包含其完全限定域名（FQDN）及其IP地址可能是一个很好的做法。通常，只有HOSTNAME字段中包含了域名。
5.3. 产生消息的进程信息
在生成消息的设备上包含有关进程的一些信息也被认为是一个很好的做法 – 如果这个概念存在的话。一个健壮的操作系统，通常都有进程名称和进程ID（pid）。通常，进程名称在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。由于日期（在这种情况下为5）的单个数字前面有一个TIMESTAMP格式的空格，所以在月份之前的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
Conveyer1=OK, Conveyer2=OK
这个消息有一个合法的PRI，优先级表示它定义了一个本地的设备，级别是提示。HEADER部分有一个合适的TIMESTAMP字段。Relay在发送这个消息之前不会进行修改。然而，HOSTNAME和TAG字段和第4部分的定义不一致。HOSTNAME字段是CST，MSG部分的开始是1987。应该注意的是，本例的内容中包含的信息不是遥测数据，也不是监控或数据采集信息。根据第6节列出的安全考虑，消息的种类不能在协议中传送。
Example 4
<0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 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.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!
- 安全考虑
气味可能被认为是不需要任何确认的信息。人们倾向于避免不良气味，而被好的食物气味吸引。收到气味不需要应答，事实上它应该更加酌情完全忽略一些气味。另一方面，对厨房里做出的美味食物进行应答是有礼貌的。类似的，很多物种使用气味吸引异性。一种蛾子使用气味找到同伴。然而，蜘蛛可以仿造这种雌性蛾子的气味。这种气味会吸引期望找到伴侣的雄性蛾子。当他们达到气味的源头时就会被吃掉。这是有敌意地发送错误消息。
在本地使用中，syslog进程将每一个事件通知保存在系统中的文件中。这依赖于系统对消息完整性的保护。使用syslog协议将消息传输到远程collector的syslog进程的后续配置是事件通知消息的传递的扩展，并且它表现出与网络相同的信任。syslog的基本简单性有几个安全性后果，并且在需要稳健传递的情况下，有一些关于此协议的适用性的问题。按照类比的方式，计算机事件消息可能被意外地，错误地甚至恶意地发送。然而，在撰写此本文时，还没有任何网络设备消耗任何其他设备的报告。
6.1. 报文变量
如上文描述，消息的长度不能超过1024个字节。已经有发送长于1024字节的报文给接受者的攻击。在一些老版本的syslog中，收到超过1024个字节的报文会出现错误。收到消息长度大于1024字节的数据包后，系统日志消息接收者不得发生故障。在收到超过1024个字节报文后可以有很多行为。一些是将整个报文记录到日志中，其他的是将一部分记录到日志中，还有的直接丢弃报文。当设备收到超过1024个字节的报文后，不能重传。
类似的，接收者必须严格的校验消息内容。如果接收到的消息在有效的优先级值周围没有小于和大于字符，系统日志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消息的报文可能被破坏的情况下，在链路层到IP层以及UDP协议中都有检测破坏的方法。路由器可以丢弃受损的IP报文。由接收UDP模块检测到UDP损坏的数据包，可能会静默地丢弃。在上述情况下，原来的消息内容不能传送到collector。同时，如果攻击者位于发送者和接收者之间，可能在消息传送的过程中解析并修改消息，用以隐藏未授权的活动。
6.6. 消息观察
没有关于时间消息格式的严格要求，大多数syslog消息都是人类可读的格式，这样管理员可以阅读他们并知道含义。Syslog协议和syslog程序都没有提供报文传送的加密特性。在大多数情况下，如果通过明文消息对操作人员进行嗅探，那么这些消息对于操作人员是有好处的。操作员可以读取消息，并且将他们和其他报文关联，定位和纠正错误。不幸的是，攻击者也可以查看syslog消息中的内容。攻击者可以使用从消息中获取的知识来攻击一个计算机或进行其他破坏。
6.7. 消息排序和区分
当进程创建消息时，会根据消息的优先级判断事件的严重性，这个值和报文发送的重要性无关。例如，假设一个应用程序生成两个事件消息。第一个是一般级别的消息，但第二个是一个严重级别的消息，表明进程出现了一个错误。第二个消息有一个关于事件的高的严重级别。如果操作员配置将两个事件都发送到syslog collector中，它们将轮流使用UDP进行发送。在一般情况下，它们之间的发送顺序没有区别。
再次，在正常情况下，接收者将接收syslog消息。如果许多设备正在发送正常的状态消息，但有一个正在发送重要的事件消息，则syslog协议中没有固有的机制来将重要消息优先于其他消息。
在具体情况下，设备运营商可能会找到某种方式将不同级别与服务质量标识符相关联。例如，操作员可以选择定义一些syslog消息和特殊优先级之间的关系，将一个特殊值放在IPv4的优先级字段中、IPv6的Traffic Class字节中或区分服务字段中。在上述例子中，操作员可以将状态信息和一般的传输优先级关联，为表示错误的消息赋予优先级更高、等待时间更少的队列中。这样优先级更高的关键消息可以在一般状态消息之前发送。即使具有这种逐跳优先级排序，如果发送或接收了许多近似同时的消息，这种排队机制仍然可能导致发送设备上的线路阻塞以及接收设备上的缓冲区缺陷。这种行为不但在syslog中出现，而且在所有的连续传输消息的操作中都会出现。
这种行为存在安全性问题。首先在线路中传送重要的事件消息，当出现更重要的消息时，会让不重要一些的消息降级。如果队列在恰当的时间清空，只会在传送重要消息的时候多几秒的延迟。另一方面，如果队列没有清空，重要的消息不能被发送。同样在接收端，如果系统日志接收器由于接收到大量消息而遭受缓冲区不足，那么重要的消息可能与其他消息一起不加区分地丢弃。虽然这些是设备及其容量的问题，但协议安全性的担忧是在不太重要的消息上没有对相对更重要的消息进行优先级排序。
6.8. 错误配置
因为没有关于消息或配置的控制消息，确保消息发送到了正确的接收者完全是管理员的责任。前面已经说明了配置错误的接收者导致的后果。在许多情况下，接收器可能无意地不被配置为接收syslog消息，并且它可能丢弃它们。在某些其他情况下，已知收到syslog消息会导致非预期收件人出现问题。如果消息没有发送到预期的接收者，那么就不能被检查和处理。
6.9. 循环转发
在图1中已经说明，可以在转发syslog消息到collector之前进行转发。在一个特殊的情况下，管理员发现一个错误配置导致两个relay互相转发某个优先级的消息。当这两个机器中的其中一个产生或收到一个消息时，它们都会将消息转发给对方，对方同样会传回消息。这种循环导致两个设备之间的网络利用率降低。管理员必须小心配置，以免出现死循环。
6.10. 加载考虑
网络管理员必须花时间估计syslog接收者的数量。攻击者可能通过向collector发送错误消息，让错误消息占满硬盘进行拒绝服务攻击。将记录放在循环文件中可以解决这个问题，但这样的话管理员就不能看到以前的消息了。这种情况下，接收者或collector的网络接口必须有可以接收所有发送给它的消息的能力。
管理员和网络计划员必须谨慎查看设备、relay和collector之间的网络路径。已发出的syslog消息不能使任何网络连接宕机。
