8. Security Considerations (安全考虑)
8.1. UNICODE (统一码)
本文档对 PARAM-VALUE 和 MSG 字段使用 UTF-8 编码。UNICODE 存在许多安全问题。建议任何实施者和操作员查看 UNICODE TR36 [UNICODE-TR36] (UTR36) 以了解这些问题。本文档通过要求 (REQUIRING) Syslog 应用程序使用 "最短形式" 编码来防范 UTR36 中概述的技术问题。但是，由于字符混淆导致的视觉欺骗 (Visual Spoofing) 仍然存在。本文档试图通过仅在预期和需要本地脚本的地方允许 UNICODE 来最小化视觉欺骗的影响。在所有其他字段中，要求 (REQUIRED) 使用 US-ASCII。此外，PARAM-VALUE 和 MSG 字段不应该是标识信息的主要来源，进一步降低了与视觉欺骗相关的风险。
8.2. Control Characters (控制字符)
本文档不对 MSG 或 PARAM-VALUE 内容施加任何强制性限制。因此，它们可能 (MAY) 包含控制字符 (Control Characters)，包括 NUL 字符。
在某些编程语言（最著名的是 C 和 C++）中，NUL 字符（ABNF %d00）传统上作为字符串终止符 (String Terminator) 具有特殊意义。这些语言的大多数实现假设字符串不会超出第一个 NUL 字符。这主要是支持运行时库的限制。这种限制通常被延续到用这些语言编写的程序和脚本语言中。因此，必须非常小心地考虑 NUL 字符并正确处理它们。攻击者可能故意包含 NUL 字符以隐藏其后的信息。对 NUL 字符的不正确处理也可能使消息内传输的加密校验和 (Cryptographic Checksums) 无效。
许多流行的文本编辑器也是用具有此限制的语言编写的。写入文本文件时建议对 NUL 字符进行编码。如果在没有编码的情况下存储它们，文件可能会变得无法读取。
其他控制字符也可能有问题。例如，攻击者可能故意包含退格字符以使日志消息的部分内容无法读取。几乎所有控制字符都存在类似的问题。
最后，无效的 UTF-8 序列可能被攻击者用来注入 ASCII 控制字符。
本规范允许 Syslog 应用程序重新格式化接收到的控制字符。除其他外，与控制字符相关的安全风险是此限制背后的重要驱动力。建议发起者，如果使用除 ASCII 和 UTF8 之外的任何编码，接收器可能会在尝试过滤 ASCII 控制字符时破坏消息。
8.3. Message Truncation (消息截断)
攻击者可能滥用消息截断 (Message Truncation) 来隐藏重要的日志信息。超过最小支持大小的消息可能会被传输接收器丢弃或截断。因此，重要的日志信息可能会丢失。
为了防止信息丢失，消息不应该长于第 6.1 节要求的最小最大大小。为了获得最佳性能和可靠性，消息应尽可能小。重要信息应尽早放置在消息中，因为消息开头的信息不太可能被大小受限的传输接收器丢弃。
发起者应该限制 Syslog 消息中任何用户提供数据的大小。如果不这样做，攻击者可能会提供大量数据，希望利用潜在的弱点。
8.4. Replay (重放)
Syslog 协议中没有机制来检测消息重放 (Message Replay)。攻击者可能记录一组指示机器正常活动的消息。在稍后的时间，该攻击者可能将该机器从网络中移除，并将 Syslog 消息重放到中继或收集器。即使使用 HEADER 部分中的 TIMESTAMP 字段，攻击者也可能记录数据包，并且只需在重新传输之前修改它们以反映当前时间。管理员可能不会发现接收到的消息有任何异常，它们的接收会错误地指示机器的正常活动。
对消息进行加密签名 (Cryptographically Signing) 可以防止 TIMESTAMP 的更改，从而防止重放攻击。
8.5. Reliable Delivery (可靠传输)
由于本文档中没有描述确保传递的机制，并且底层传输可能不可靠（例如，UDP），因此某些消息可能会丢失。它们可能通过网络拥塞而丢失，或者它们可能被恶意拦截和丢弃。无法确定丢弃一个或多个 Syslog 消息的后果。如果消息是简单的状态更新，那么它们的未接收可能不会被注意到，或者可能会给系统操作员造成烦恼。另一方面，如果消息更关键，那么管理员可能不会意识到正在发展的潜在严重问题。消息也可能被攻击者拦截和丢弃，作为隐藏未经授权活动的一种方式。
在 Syslog 发起者和中继中包含速率限制功能 (Rate-Limiting Features) 也可能是可取的。这可以减少消息突发时的潜在拥塞问题。
可靠传递可能并不总是可取的。可靠传递意味着当中继或收集器无法接受更多消息时，Syslog 发起者或中继必须阻塞。在某些操作系统中，即 Unix/Linux，Syslog 发起者或中继在高优先级系统进程（syslogd）内运行。如果该进程阻塞，整个系统就会停滞。如果 syslogd 和例如 DNS 服务器之间存在死锁情况，也会发生同样的情况。
为了防止这些问题，可以实现可靠传递，当 Syslog 应用程序否则会阻塞时故意丢弃消息。在这种情况下，可靠传递的优势在于 Syslog 发起者或中继有意识地丢弃消息，并能够通知中继或收集器这一事实。因此，中继或收集器接收到某些内容丢失的信息。使用不可靠传递，消息将简单地丢失，而没有任何指示发生了丢失。
8.6. Congestion Control (拥塞控制)
由于 Syslog 可以生成无限量的数据，通过 UDP 传输此数据通常是有问题的，因为 UDP 缺乏拥塞控制机制 (Congestion Control Mechanisms)。通过降低流量速率来响应拥塞并在共享同一路径的流之间建立一定程度的公平性的拥塞控制机制对于互联网的稳定运行至关重要 [RFC2914]。这就是为什么要求 (REQUIRED) 实现 Syslog TLS 传输，并推荐 (RECOMMENDED) 一般使用。
只有在受管理网络 (Managed Networks) 中，Syslog UDP 传输才可以 (MAY) 用作 TLS 传输的替代方案，在这些网络中，网络路径已通过流量工程机制（如速率限制或容量预留）明确为 UDP Syslog 流量提供了资源。在所有其他环境中，应该 (SHOULD) 使用 TLS 传输。
在任何实现中，可能会出现发起者或中继需要阻止发送消息的情况。一个常见的情况是内部队列已满。这可能由于速率限制或 Syslog 应用程序的性能缓慢而发生。在任何情况下，强烈推荐 (RECOMMENDED) 不要丢弃任何消息，而应该临时存储它们，直到可以传输。但是，如果必须丢弃它们，推荐 (RECOMMENDED) 发起者或中继优先丢弃较低严重性的消息，而不是较高严重性的消息。具有较低数字 SEVERITY 值的消息比数字较高的消息具有更高的实际严重性。在这种情况下，应该 (SHOULD) 简单地丢弃要丢弃的消息。Syslog 应用程序可以通知收集器或中继它已丢弃消息的事实。
8.7. Message Integrity (消息完整性)
除了被丢弃之外，Syslog 消息可能在传输过程中受损，或者攻击者可能恶意修改它们。在这种情况下，消息的原始内容将不会传递到收集器或中继。此外，如果攻击者位于 Syslog 消息的传输发送器和传输接收器之间，他们可能能够拦截和修改在传输中的消息，以隐藏未经授权的活动。
8.8. Message Observation (消息监测)
虽然没有关于 MSG 格式的严格指南，但大多数 Syslog 消息都以人类可读的形式生成，假设有能力的管理员应该能够阅读它们并理解它们的含义。Syslog 协议没有为传输中的消息提供机密性 (Confidentiality) 的机制。在大多数情况下，如果操作人员从网络上嗅探数据包 (Sniffing the Packets)，传递明文消息对他们是有益的。操作人员可能能够读取消息并将它们与从网络上传递的其他数据包中看到的其他事件相关联，以跟踪和纠正问题。不幸的是，攻击者也可能能够观察到 Syslog 消息的人类可读内容。然后，攻击者可能会利用从这些消息中获得的知识来危害机器或造成其他损害。
建议操作员使用安全传输映射 (Secure Transport Mapping) 来避免此问题。
8.9. Inappropriate Configuration (不当配置)
由于没有关于任何消息或配置的控制信息分发，因此网络管理员完全有责任确保消息实际发送到预期的收件人。已经注意到一些情况，其中 Syslog 应用程序被无意中配置为将 Syslog 消息发送到错误的中继或收集器。在许多情况下，无意的中继或收集器可能未配置为接收 Syslog 消息，并且可能会丢弃它们。在某些其他情况下，已知接收 Syslog 消息会给无意的收件人造成问题。如果消息没有发送到预期的收件人，那么它们就无法被审查或处理。
使用可靠的传输映射可以帮助识别其中一些问题。例如，它可以识别消息被发送到未配置为接收消息的系统的问题。它无法识别将消息发送到正在接受消息的错误机器。
8.10. Forwarding Loop (转发循环)
如图 2 所示，机器可以配置为在到达收集器之前将 Syslog 消息中继到后续中继。在一个特定情况下，管理员发现他错误地配置了两个中继，使它们将具有某些 SEVERITY 值的消息彼此转发。当这些机器中的任何一台接收或生成该类型的消息时，它会将其转发到另一个中继。然后该中继将其转发回来。这个循环确实导致了中间网络以及两个设备上的处理可用性的降级。网络管理员必须注意不要造成这种死亡螺旋 (Death Spiral)。
8.11. Load Considerations (负载考虑)
网络管理员必须花时间估算 Syslog 收集器的适当容量。攻击者可能通过用虚假消息填充收集器的磁盘来执行拒绝服务攻击 (Denial of Service Attack)。将记录放在循环文件 (Circular File) 中可能会缓解这一问题，但后果是无法确保管理员将来能够查看记录。沿着这条线，传输接收器必须有一个能够接收发送给它的消息的网络接口。
管理员和网络规划者还必须严格审查发起者、中继和收集器之间的网络路径。生成的 Syslog 消息不应该压倒任何网络链路。
为了减少此问题的影响，建议使用具有保证传递的传输。
8.12. Denial of Service (拒绝服务)
与任何系统一样，攻击者可能只是通过向传输接收器发送超过基础设施或设备本身所能处理的更多消息来压倒它。实施者应该尝试提供最小化此威胁的功能，例如仅接受来自已知 IP 地址的 Syslog 消息。