Sending Additional Information Using Syslog

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

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

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 varies 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, and Azure deployments
Send to the IP or domain name of your external load balancer, over:
- Unencrypted TCP (port 6514),
- TLS encrypted TCP (port 6514)
- UDP (port 514)
For more information, see:
- Prepare an AWS Instance
- Prepare an Azure VM
GCP deployments

Send UDP syslogs directly to the node instead of to the load balancer.
The external load balancer reroutes the syslogs to the TOS cluster to ports 30514, 31514 or 32514 for UDP, encrypted TCP, and unencrypted TCP respectively.

For more information, see Prepare a GCP VM Instance
On-premises deployments
Send to a Syslog VIP. Depending on the device type, send syslogs as:
- UDP (port 514)
- Unencrypted TCP (port 601)
- 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

Instead of sending syslogs directly from the devices themselves, you can send them 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: