8. Security Considerations

8.1. UNICODE

Valid Unicode that may be maliciously malformed is an issue for syslog messages (see [UNICODE-TR36]). For example, a message may be crafted so that it appears to be a benign message but after decoding it contains malicious content. To guard against this, applications MUST encode messages in the "shortest form" as mandated in Section 6.3.3. Also, any applications decoding these messages MUST verify that the encoding is in "shortest form" before operating on any of the characters.

8.2. Control Characters

The PARAM-VALUE may contain control characters. This is a necessary feature to support the passing of any information that can be represented in Unicode. However, this also means that syslog messages can contain characters that have special meanings to some display devices. For example, carriage return characters could be used to overwrite previously displayed portions of a message on a terminal display, potentially hiding a security-relevant message or modification. Also, there exist control characters that may affect how content is displayed, which also allows for a potential for misrepresentation.

The specification RECOMMENDS that syslog applications SHOULD NOT emit control characters in PARAM-VALUE. If a syslog application uses control characters, it might not be possible to interpret the message on the collector or relay. Also, control characters MAY confuse or mislead viewers of the log messages. It is RECOMMENDED that syslog applications that receive syslog messages either filter out the control characters or replace them with an innocuous character before displaying them.

A similar risk exists with the MSG field. Although the character set for MSG is less stringent, it is RECOMMENDED that similar precautions are taken with the MSG part of a syslog message.

8.3. Message Truncation

This specification mandates that compliant transport receivers be able to accept messages of up to 480 octets in length. Transport receivers SHOULD be able to accept messages of up to 2048 octets in length. Anything beyond these minimum required lengths is acceptable but optional. Senders are always free to send messages of any length they want. However, messages may be truncated by transport receivers or may have to traverse relay chains that include devices that have lower maximum message length capabilities. This truncation may alter the meaning of a message or remove critical information. This may also make it difficult to perform meaningful log analysis.

The probability of truncation can be greatly reduced by keeping the message length under 480 octets. At the same time, implementations MUST be able to accept messages of at least 480 octets and SHOULD be able to accept messages of 2048 octets. Anything beyond that is discretionary.

8.4. Replay

Syslog message transmission, by itself, does not provide assurance that the message that is received is actually the message that was sent or, even, that the message is from the purported sender. Even if cryptographic verification is done, a malicious observer could record valid messages and replay them at a later time. This could cause a receiver to believe that a particular event had occurred at a time different from the time when the message was originally transmitted. At best, this could cause an incorrect analysis of the state of a machine. At worst, it could cause a false alarm that could trigger unneeded corrective action or mask a true alarm that should have triggered corrective action.

8.5. Reliable Delivery

Since syslog is a simplex protocol, by default it does not provide assurance of delivery. A malicious observer can simply delete messages in transit or generate so much traffic that the receiver is unable to accept all messages. While it is possible to construct syslog transports that do provide assurance of delivery, such constructs are outside the scope of this document. More information about reliable transports for syslog can be found in [RFC3195].

It is also possible for messages to be deleted or diverted while being relayed through a relay. For example, a relay might be configured or compromised to delete all messages of particular severities or from particular originators.

8.6. Congestion Control

Syslog messages may be sent using protocols that do not provide congestion control. This may lead to message loss and network congestion. To guard against this, the transport protocols used SHOULD provide congestion control. The congestion control functionality is dependent on the transport protocol.

8.7. Message Integrity

This specification does not provide native means to ensure that messages are not modified, deleted, or injected by intermediate parties. It is RECOMMENDED that security-sensitive syslog communications use a transport that provides message integrity. Message integrity can be achieved through various means, including use of cryptographic signatures. However, these mechanisms are not described in this specification and are dependent on the transport protocol.

8.8. Message Observation

By itself, this specification does not provide native confidentiality for the messages. Because of the simplex nature of syslog, it is easy for someone with physical or electronic access to the transmission to eavesdrop on the information contained in the messages. Therefore, syslog messages may be observed by malicious actors. It is RECOMMENDED that security-sensitive syslog communications use a transport that provides message confidentiality.

8.9. Inappropriate Configuration

Syslog messages can contain sensitive information. For example, syslog messages could contain information about network topology, system configuration, or user identities. This information may be useful to an attacker. Syslog messages SHOULD NOT contain sensitive information (e.g., passwords). However, it is impossible to define an exhaustive list of what constitutes sensitive information. The appropriateness of the sensitivity of the information transmitted via syslog is a local policy matter. It is important that the local administrators understand that any information in the MSG field is not protected by this specification.

Operators SHOULD NOT use syslog to convey sensitive information unless the content has been appropriately anonymized or protected through other means. This could be done through any number of methods, including:

• Sending syslog messages over a confidential channel, such as TLS
• Pre-filtering messages to remove sensitive information
• Using syslog only within a protected network environment

8.10. Forwarding Loop

In a syslog relay chain, a configuration error might result in a forwarding loop. For example, relay A might be configured to forward messages to relay B, and relay B might be configured to forward messages back to relay A. Such a loop can cause resource exhaustion or other problems. Implementations SHOULD try to detect such loops and issue a notification if one is detected. One way to detect loops is by including an originator-specific identifier in the message that can be checked at each relay. For example, the origin SD-ID may be used for this purpose.

8.11. Load Considerations

Implementors and operators need to consider the performance characteristics and load factors related to generating, transmitting, relaying, and collecting syslog messages. Because syslog is typically used as a means to convey information that is used for operational monitoring, debugging, and security analysis, it is important that the act of transmitting the syslog messages does not itself create operational problems or security vulnerabilities.

For example, excessive volumes of syslog messages may overwhelm the capacity of the transport network. Similarly, a relay or collector might be overwhelmed if it receives messages at a rate faster than it can handle them. Such resource exhaustion may result in lost messages, delayed messages, or denial of service. Syslog implementations SHOULD have appropriate controls to limit the load they impose on the system and the network.

8.12. Denial of Service

Syslog transport protocols SHOULD be able to detect and handle denial of service attacks. A receiver may be flooded with messages, either through a misconfiguration or as an attack. It is RECOMMENDED that syslog receivers have the ability to limit the rate at which they accept messages. It is also RECOMMENDED that receivers have the ability to filter messages to reject those from unauthorized senders or with suspicious content.