Sending Additional Information Using Syslog

SecureChange Requester This topic is intended for TOS Administrators.

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.

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

  • The Rule and Object Usage report

  • Last hit field in the Rule Viewer.

  • Accountability information 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 that a security configuration change has occurred, enabling TOS 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 either directly or by using a log forwarder.

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

Syslog Reliability

While syslogs provide TOS with valuable information, be aware that, for a variety of reasons, this information might not reach TOS. Common reasons include network and communication outages and the unreliable nature of the UDP protocol due to its lack of ability to verify data delivery and integrity. Due to the inherent nature of syslog communication of being less than 100% reliable, very low rule usage and/or distant last hit dates might not be accurate. Therefore do not rely on this information alone as a basis for rule decomissioning. Double check your firewall device logs first.

Syslog Traffic Destination

The TOS destination you configure on your devices for syslog traffic will vary according to your TOS 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 cluster to ports 30514, 31514 or 32514 for UDP, encrypted TCP, and unencrypted TCP respectively.

    For more information, see:

  • On-premises deployments: Send to a Syslog VIP. Depending on the device type, syslogs can be sent as UDP (port 514), unencrypted TCP (port 601), or TLS encrypted TCP (port 6514). All ports are defaults and can be changed.

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 Instructions

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