Syslog Server

Top  Previous  Next

Configures a Syslog Server service. It can be set to listen to any valid port. UDP and TCP communication is supported.

 

services_043

Syslog Server Properties

 

 

Internet Protocol Type

 

Select the desired protocol type. IPv4 and IPv6 are available. The IPv6 protocol needs to be properly installed in order to be used. Note that one Service can only handle IPv4 or IPv6, so if you want to use both protocols, you will need to create two separate services.

 

 

 

Protocol Type

 

Syslog messages can be received via UDP, TCP or RFC 3195 RAW. One listener can only listen to one of the protocols. Typically, Syslog messages are received via UDP protocol, which is the default. The syslog server also can receive Syslog messages via TCP and reliable Syslog messages via TCP using the new RFC 3195 RAW standard.

 

 

IP Address

 

The Syslog Server can now be bound to a specific IP Adress. You can either use an IPv4, an IPv6 Address or a Hostname that resolves to an IPv4 or IPv6 Address. This feature is useful for multihome environments where you want to run different Syslog Servers on different IP Addresses. Please note that the default IP Address 0.0.0.0 means ANY IP Address.

 

 

Listener Port

 

The port the Syslog server listens on. The typical (standard) value is 514. This should be changed only if there is a definite need for it. Such a need typically arises from security concerns. If the port is changed, all reporting devices (routers, printers …) must also be configured to use the non-standard port.

 

 

General Options

 

Use Original Message Timestamp

 

If this box is checked, the timestamp is retrieved from the Syslog message itself (according to RFC 3164). If left unchecked, the timestamp is generated based on the local system time. The Syslog message timestamp does not contain time zone information. Thus, we strongly recommend unchecking this box if messages from devices in multiple time zones are to be received.

 

 

Take source system from Syslog message

 

If this box is checked, the name or IP address of the source system is retrieved from the Syslog message itself (according to RFC 3164). If left unchecked, it is generated based on the address, the message was received from.

 

Please note that there are many devices, which do NOT generate RFC 3164 compliant messages. If you check this option here, you might see a very strange value as the event source!

 

 

Save original source into property

 

When this options is enabled, the original network source will be stored into the custom defined property (%sourceorig% by default). In case the original network source is needed for filtering for example.

 

 

Resolve Hostnames

 

If this box is checked, the name of the source system is retrieved via DNS reserve name resolution. If unchecked, the IP address itself is used as the name.

 

Please note that this setting does have any effect if the "Take source system from Syslog message" setting is checked. In this case, the message is always taken from the Syslog message itself.

 

 

Escape Control Characters

 

Control characters are special characters. They are used e.g. for tabulation, generating beeps and other non-printable uses. Typically, syslog messages should not contain control characters. If they do, control characters could eventually affect your logging. However, it might also be that control characters are needed.

 

With this setting, you can specify how control characters received should be handled. When checked, control characters are replaced by a 5-byte sequence with the ASCII character ID. For example, a beep is the ASCII BEL character. BEL is assigned the numerical code 7. So if a BEL is received, it would be converted to "<007>" inside your syslog message. When the box is left unchecked, no conversion takes place.

 

In any case, ASCII NULs are converted to "<000>" to prevent security issues in the log files.

 

Please note: if you used double-byte character sets, control character escaping can cause your message to become clobbered. So be sure to leave it unchecked in that case.

 

 

Enable RFC 3164 Parsing

 

If this box is checked, RFC 3164 compliant message parsing is enabled. If unchecked, "traditional" Adiscon message parsing is selected. If you experience trouble with the sender host name or the timestamp, we suggest that you turn off RFC 3164 compliant message parsing. Many existing devices do not fully comply with RFC 3164 and this can cause those issues.

 

 

Enable RFC 5424 Parsing

 

If this box is checked, RFC 5424 compliant message parsing is enabled for Syslog RFC5424 Header detection and decoding. This also involves new useable Syslog properties.

If unchecked, "traditional" Adiscon message parsing is selected. If you experience trouble with the sender host name or the timestamp, we suggest that you turn off RFC 5424 compliant message parsing. Many existing devices do not fully comply with RFC 5424 and this can cause those issues.

 

 

Appen ProcessID to SyslogTag if available

 

This option is related to RFC5424 header parsing and was default in previous versions. However the default now is off in order to separate the Syslogtag from the ProcessID.

 

 

Encoding options

 

services_044

Encoding Options

 

Automatically detect Message Encoding (UTF8, SHIFT_JIS, EUCJP)

 

If enabled, the message will be checked for different encodings. This is important if you have syslog messages with multibyte characters. Once an encoding is detected, it will automatically be converted into UTF16 internally.

 

 

Force UTF8 Decoding

 

This option forces UTF8 Decoding of all incoming messages. This is also useful for syslog messages encoded in UTF8 but missing the BOM withing the Syslog message.

 

 

UDP Options

 

services_045

UDP Options

 

UDP Options - Enable receiving from a UDP Multicast Group

 

This option supports receiving Syslog messages via multicast IP Addresses like 224.0.0.1 for example.

 

 

TCP specific options

 

services_046

TCP Options

 

 

TCP Options - Session Timeout

 

One of the TCP-specific options is the session timeout. This value declares, how long a TCP session may be kept open, after the last package of data has been sent. You can by default set values between 1 second and 1 day. Or you can use a custom value with a maximum of 2147483646 milliseconds. If you wish to disable the session timeout, you can use a custom value of 0 milliseconds to disable it.

 

 

TCP Options - Messages are separated by the following sequence

 

If this option is checked, you can use multiple messages in the same transmission and the following options are enabled:

 

Message separation sequence - determines, how you want to separate the messages. By default "\r\n" is the value for this, as most times a message ends with a carriage return and/or a line feed. But, you can choose your own separation sequence here as well.

 

Message Completion Timeout - here you can set the time that is allowed to complete a message. Is the time exceeded, but the message not yet completed, the rest will be treated as a new message. The counter is resetted each time, a new message begins. You can choose from multiple values between 1 second and 1 day, or choose a custom value in milliseconds (0 = disable, maximum = 2147483646)

 

 

Syslog TLS

 

services_047

SSL/TLS Options

 

Enable SSL / TLS Encryption

 

This option enables SSL / TLS encryption for your syslog server. Please note, that with this option enabled, the server only accepts SSL / TLS enabled senders.

 

 

TLS Mode

 

The TLS mode can be set to the following:

 

Anonymous authentication

Default option, which means any client certificate will be accepted, or even none.

 

x509/name (certificate validation and name authentication)

When this mode is selected, the subject within the client certificate will be checked against der permitted peers list. This means the Syslog Server will only accept the secured connection if it finds the permitted peer in the subject.

 

509/fingerprint (certificate fingerprint authentication)

This mode creates a SHA1 Fingerprint from the client certificate it receives, and compares it to fingerprints from the permitted peers list. You can use the debuglog to see fingerprints of client certificates which were not permitted.

 

x509/certvalid (certificate validation only)

A Syslog Sender is accepted when the client certificate is valid. No further checks are done.

 

Select common CA PEM

 

Select the certificate from the common Certificate Authority (CA), the syslog receiver should use the same CA.

 

Select Certificate PEM

 

Select the client certificate (PEM Format).

 

Select Key PEM

 

Select the keyfile for the client certificate (PEM Format).

 

Permitted Peers

This list contains all permitted peers. If x509/name is used, this can contain parts of the client certificate subject. For example if you have CN = secure.syslog.msg in the certificate subject, you can add "secure.syslog.msg" as permitted peer. When using x509/fingerprint, this list holds a list of permitted SHA1 fingerprints. The fingerprints can either be generated with OpenSSL Tools, or grabbed from the debug logfile. The format is like described in RFC 5425, for example: "SHA1:2C:CA:F9:19:B8:F5:6C:37:BF:30:59:64:D5:9A:8A:B2:79:9D:77:A0".

 

 

 

Default Ruleset Name

 

Name of the rule set to be used for this service. The Rule Set name must be a valid Rule Set.

 

 

Please Note

 

Updated the OpenSSL components and libraries with the latest Version  openssl-1.0.1j.