About syslog channels

A syslog channel allows the CyberArk Log server to send log messages to any log aggregation or analyzer solution that supports the syslog protocol. Instead of a local timezone, log messages contain the GMT/UTC timestamp from the Trust Protection Foundation server.

Trust Protection Foundation version 19.3 introduced two new message formats—Common Event Format (CEF) and JSON—and can now support encrypted (TLS) connections to remote syslog servers. The legacy BSD format remains available.

All CyberArk Log server messages include a severity code, which aligns with standard syslog severity codes. For example, 3 represents an error, 4 represents a warning, etc. Also, channel configuration settings lets administrators specify syslog facility codes.

About the CEF format

CEF, or Common Event Format, is a standardized logging format used by many network devices and applications. CEF logs contain information like the source and destination of an event, its severity, its event ID, and the message.

If the Syslog server records messages in the CEF format, the timestamps are recorded as local server time. If you are working with servers in multiple timezones, you need to be aware that per the CEF specification, dates are recorded in UTF format.

About the JSON format

If the Syslog server records messages in the JSON format, the timestamps are local time. When you select JSON as the message body format, it uses the following pattern:

{
   "time_stamp":"<Event.ClientTime>",
   "name":"<Event Description from Log Schema>",
   "event_id":"<Event.ID>",
   "severity":"<Event.Severity>",
   "dvc_ip":"<Event.SourceIP>",
   "object":"<Event.Component>",
   "object_id":"<Event.ComponentId>",
   "object_subsystem":"<Event.ComponentSubsystem>",
   "text1":{
      "name":<Text1 Title from Log Schema>,
      "value":<Event.Text1>
   },
   "text2":{
      "name":<Text2 Title from Log Schema>,
      "value":<Event.Text2>
   },
   "value1":{
      "name":<Value1 Title from Log Schema>,
      "value":<Event.Value1>
   },
   "value2":{
      "name":<Value2 Title from Log Schema>,
      "value":<Event.Value2>
   },
   "grouping":{
      "name":"<Grouping Title from Log Schema>",
      "value":"<Event.Grouping>"
   },
   "data":{
      "name":"<Data Title from Log Schema>",
      "value":"<Event.Data>"
   }
}

About the BSD format

The legacy Berkeley Software Distribution (BSD) format continues to be supported. If the Syslog server records messages in the BSD format, the timestamps are GMT/UTC time. For more information about BSD, see https://tools.ietf.org/html/rfc3164.

About the TLS format

Syslog channel driver can establish secure (encrypted) connection over TLS to the remote destination. When configuring a syslog channel with TLS, the server certificate must meet the following requirements:

• Subject Alternative Name (SAN): The certificate MUST include an iPAddress entry in the SAN extension that matches the IP address used by the syslog channel to connect to the server. This requirement applies even if the syslog channel is configured with a hostname (FQDN). The certificate must still contain the IP address in the SAN, because the connection is established using the resolved IP. If the syslog server is behind a load balancer, the certificate presented must include the IP address of the load balancer as seen by the client.

• Common Name (CN) and dNSName: The Common Name and dNSName entries are not sufficient for validation in this context. The SAN IP is required.

• Key Usage and Extended Key Usage: The certificate must have the following X.509 extensions: Key Usage: Digital Signature, Key Encipherment and Extended Key Usage: Server Authentication

• Validity and Algorithm: The certificate must be valid (not expired or revoked). The certificate must use a key length and signing algorithm compliant with current security standards (e.g., RSA 2048+ bits, SHA-256 or stronger).

• Certificate Authority: The certificate must be issued by a trusted Certificate Authority (CA) configured in your environment.

• No Wildcards for IPs: Wildcard entries are not supported for IP addresses in SANs.

If the syslog channel is configured with a load balancer or proxy, ensure the certificate presented matches the IP address used by the client to connect, not the backend server address.

For specific instructions for configuring a syslog channel, see To configure a syslog channel object.