Sending Additional Information Using Syslog

Overview

To get full accountability details (who made policy changes and when) and to utilize rule and object usage reporting, you must get your monitored devices to send syslogs to TOS Aurora.

These monitored devices can be set up to send additional information to TOS Aurora, such as:

  • Rule and object usage information that can be seen in SecureTrack, such as the rules that were invoked or 'hit'

  • Accountability information that can be seen in SecureTrack, such as the users who made policy changes and the computer used to make the change

  • Details of the applications that pass traffic through the device - can be seen in SecureApp

  • Notifications to TOS Aurora that a security configuration change has occurred, enabling TOS Aurora to fetch the updated policy (revision) from the device immediately, rather than wait for the periodic polling

To get this additional information, you must configure your devices to send syslogs to TOS Aurora either directly or by using a log forwarder.

Certain devices can also use syslogs to collect traffic information that you can use for the Automatic Policy Generator (APG).

You can also configure devices to send non-default syslogs to SecureTrack. See Configuring non-default syslogs.

Syslog Traffic Destination

The TOS Aurora destination you configure on your devices for syslog traffic will vary according to your TOS Aurora deployment platform and the protocol you want to use. If you have remote clusters, you must send to the cluster that monitors the device.

  • AWS, Azure, and GCP deployments: Send to the IP or domain name of your external load balancer. Syslogs can be sent over unencrypted TCP (port 6514), TLS encrypted TCP (port 6514), or UDP (port 514). With GCP, UDP syslogs cannot be sent to the load balancer and should instead be sent directly to the node. The external load balancer will reroute the syslogs to the TOS Aurora cluster to ports 30514, 31514 or 32514 for UDP, encrypted TCP, and unencrypted TCP respectively.

    For more information, see:

  • GCP deployments: Send over TCP to the IP or domain name of your external load balancer, port 514 and/or send over UDP to the nodeport IP, port 30516. This is different from the other cloud platforms because load balancers in GCP can be configured for either TCP or UDP, but not both, For TOS Aurora, we create the GCP load balancer for TCP and send UDP syslogs to the data node instance IP address (nodeport). Port 30514 must be In open to receive traffic from the monitored devices. In high availability deployments, any data node can be used but if the node fails, syslogs will not be received until repaired or replaced with the same instance IP.

  • On-premises deployments: Send to a Syslog VIP, to port 514.

The firewalls in the organization must be configured to allow the relevant traffic.

Use a Log Forwarder

You can send syslogs directly from the devices themselves or from an incident management tool such as ArcSight, Splunk or QRADAR. These tools are sometimes referred to as log forwarder/log aggregator tools or SEM (Security Event Management)/SIEM (Security Incident and Event management) systems. The syslogs must be sent to the TOS cluster in exactly the same format as they would be sent from the original device, including the IP address of the firewall device if specified.

Vendor-Specific Syslog Configuration

Syslog Priorities by Vendor

The table below lists syslog priorities by vendor and device type.

Vendor

Default priority code

JunOS

14, 70, 181, 189

Checkpoint

134

Netscreen

188, 189, 190

NSM

185

Fortinet

187, 188, 189, 190, 191

Palo-Alto

14, 134, 142, 150, 158, 166, 174, 182, 190

Cisco FW

186, 188, 189, 190

Cisco Router

189

Cisco Nexus

189

Cisco FMC

189(change log), 041, 042, 043, 044, 045, 046, 047, 048

NSX

13, 14

Syslog Configuration by Vendor

For more information on sending syslogs for supported devices, see the following related topics: