About syslog channels

A syslog channel allows the Palo Alto Networks 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 Palo Alto Networks 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 whatever you entered in the channel's Host setting, matched exactly as you entered it:

    • If Host is a host name, the certificate must include that name as a dNSName entry in the SAN extension.

    • If Host is an IP address, the certificate must include that address as an iPAddress entry in the SAN extension.

    A certificate that contains both the FQDN and the IP address works whether Host is set to the FQDN or to the IP address.

  • 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.

These requirements apply when the platform's Verification Mode is set to Basic or Strict. When it is set to None, Trust Protection Foundation accepts the server certificate without validating it against the names the certificate contains. For more information, see Setting up Certificate Verification for securing outbound HTTPS connections.

If the syslog server is behind a load balancer or proxy, the certificate that the load balancer or proxy presents must include the name or IP address you entered in Host. The load balancer's own IP address is not what the check uses.

NOTE  Starting in Trust Protection Foundation 26.2, the certificate is checked against the Host value exactly as you configured it, which is standard TLS behavior (RFC 5425). In earlier versions, the check used the IP address that Host resolved to, so the certificate had to contain that IP address even when Host was a host name. An iPAddress entry on its own is no longer enough when Host is a host name.

NOTE  To create new credential objects, you must have the View, Write, and Create permissions for the Credential or Policy tree where you plan to create them.

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