Introduction

This guide covers external syslog configuration for the Secure Firewall platform, via the Secure Firewall Management Center (FMC). For information on different event types, event logging settings, calculating events per second (EPS), eStreamer vs. syslog, and other logging considerations, please see the Logging Best Practices guide, which was written as a companion document to this one. Because connection event volume on firewalls can be very high, it is strongly recommended to do a careful assessment of both event volume and the needed storage capacity on a SIEM or other log ingesting platform before configuring syslog.

Primary Syslog Configuration

Configuring an external syslog server can be done in two primary areas of the FMC GUI: policies > actions > alerts, and in platform settings. The configuration in platform settings is recommended for Threat Defense firewalls. For this guide, we will configure syslog in platform settings.

Navigate to devices > platform settings.

Click on the pencil icon to edit the desired policy.

Click on syslog in the left menu.

In the top menu, click on syslog servers, then click the add button.

Enter an IP address or hostname for the syslog server and specify TCP or UDP protocol. TCP can be used for encrypted syslog, while UDP 514 is the most common port and protocol used for syslog. Configure what interface the firewall will use to send logs to the syslog server and verify that the necessary routing and network access is in place for the connection from the interface specified. Click OK.

Click on syslog settings.

Check the box to ‘enable timestamp on syslog messages’. Click the timestamp format box and verify that the preferred format is selected. Check the box for ‘enable syslog device ID’ and select the preferred identifier from the dropdown—interface, hostname, or user defined.

Click save.

The changes will need to be deployed before they take effect.

Access Control Policy Log Settings & Syslog

The access control policy can set syslog for intrusion events, file and malware events, security intelligence events, and connection events. Syslog for policies linked to the access control policy can also be set, including the DNS, prefilter, and decryption policies. As covered in the Logging Best Practices guide, it is recommended to prioritize syslog for threat events (intrusion, file and malware, and security intelligence). Connection events should only be sent to syslog after making a careful assessment of event volume and data ingest capacity. Events aside from threat events and connection events should only be sent to syslog if there is a defined use case or need.

Configuring Threat Event Syslog via the Access Control Policy

Navigate to policies > access control.

Locate the policy you want to configure syslog for (or create a new one) and click the pencil icon to edit.

Let’s now review the default syslog configuration for our access control policy. At the top of the access control policy, click more > logging.

This shows the default syslog configuration for the access control policy. The screenshot below shows the blank configuration.

We can set several areas of config from this page. First, we’ll check the box to use the syslog configuration from the FTD platform settings. This configuration instructs the firewalls which have this access control policy applied to use the syslog configuration in their platform settings to send logs.

Next, we can configure syslog for the Intrusion and file policies associated with this access control policy, sending syslog events for any intrusion, malware, or file events that are generated. Below is the full configuration. Click save when finished.

The above configuration instructs the system to generate syslogs for Intrusion, file, and malware events, and send them to the specified syslog server. We can also configure syslog for the DNS policy and security intelligence by clicking on the security intelligence tab. This will generate logs every time a DNS request, IP, or URL is matched against a threat blocklist.

We can configure syslog settings for the DNS policy, the IP blocklist, and the URL blocklist from this page. Note that logging isn’t available for configurations that are integrated with Umbrella for DNS, as Umbrella does the malicious DNS check in that configuration. If using a local DNS policy, click the logging icon to configure.

From here we can configure the system to log events and send them to the FMC, a syslog server, or both. After setting the desired configuration, click OK.

Next, we can configure syslog for the IP and URL blocklists. Note that these lists must be populated by selecting network and URL categories on the left and adding them to the blocklist on the right. If you are configuring this for the first time, you should first establish an event rate baseline before configuring syslog. In the screenshot below, block list categories have already been added to the list on the right.

To enable syslog for the IP blocklist, click the logging icon next to networks.

As with the DNS policy, we can enable logging and configure logs to be sent to the FMC, syslog, or both. Click OK when finished.

Scroll down the block list to the URLs section, then click the logging icon.

Configure the desired settings, then click OK.

With these settings, syslog is configured for all of the threat event categories of intrusion, file and malware, and security intelligence. Save the access control policy, then deploy changes when ready.

Configuring Connection Event Syslog via the Access Control Policy

Connection Events

Connection events are by far the highest volume log for any firewall, and should only be enabled after a careful assessment of event rates and SIEM data ingest capacity.

Each rule in the access control policy has a customizable logging configuration. Within the access control policy, click the pencil icon next to any rule to edit.

This example rule has logging turned off. Click the text next to Logging (OFF or ON) to configure.

The logging options for each access control rule include beginning and end of connection logging (covered in the Logging Best Practices guide), and options to send the logs to the FMC, a syslog server, or both. There are also options for overrides and sending SNMP traps. For this example, we will use end of connection logging and send the logs to both the FMC and the default syslog server for this access control policy. When finished, click confirm.

Click apply.

Rules with logging enabled will display the log icon in black. Mousing over the log icon will show the logging configuration for the rule.

Logging can also be configured for the default action of the access control policy. At the bottom of the access control policy, click the gear icon.

Because our default action is set to block all traffic (implicit deny, a best practice) we only have the option to log at beginning of connection, because the connection is immediately terminated upon rule match. All log settings are the same as an access control rule. Click apply when finished.

After logging for the access control rules and default action has been configured, we can review the default syslog configuration for our access control policy by clicking more > logging (this configuration was set previously in the threat events section).

This page shows the specified syslog server and settings to send syslogs for intrusion, file, and malware events.

Click Save when finished, then deploy changes if ready.

Logging & Syslog Configuration for Other Traffic Event Types

Threat events have immediate security benefits for syslog ingestion, and connection events provide a wealth of traffic information for organizations who ingest them at scale. Other traffic related events can serve smaller use cases, and are covered in this section. It is generally recommended not to export these logs to syslog unless there is an understood business use case.

Prefilter Policy Traffic Events

Logging for the prefilter policy can be ignored for any organizations that are using the default prefilter policy settings, which send all traffic to the access control policy for analysis. For organizations who are using prefilter rules to block or fastpath traffic, prefilter events can server as a complement to connection event logging to provide a full picture of network traffic.

Syslog for the prefilter policy can be configured either by navigating to policies > prefilter > edit a policy, or by clicking on the prefilter rules link in the access control policy and then editing the linked prefilter policy, as shown below.

The three rule actions available in the prefilter policy are block, fastpath, and analyze. By default, the prefilter policy has a default action of analyze.

Clicking the log icon next to the default action will show the logging settings greyed out. This is because the analyze action sends any matched connections to the access control policy, where more granular logging can be captured.

However, logging can be enabled for any rules with the fastpath or block action, as these are not sent to the access control policy. Click the log icon next to any fastpath or block rule to configure.

As with Access Control rules, any prefilter rule set to block does not have end of connection logging available, as the connection is immediately terminated. Fastpath rules allow both beginning and end of connection logging. The Prefilter policy inherits the syslog configuration from its associated access control policy. Click save when finished with the configuration.

The policy must be deployed before the changes to logging will take effect.

Decryption Policy Traffic Events

Decryption events are generated when traffic is decrypted using a configured decryption policy. Organizations that are not performing traffic decryption will not have this event type. For organizations that are performing traffic decryption, decryption events should only be sent to syslog after assessing event volume and identifying use cases for the decryption event data.

Syslog for the decryption policy can be configured via policies > decryption > edit, or by clicking the decryption policy link in the access control policy, as shown below.

From within the decryption policy, click the pencil icon to edit a rule.

Click on logging.

Because decryption occurs after the beginning of a connection, only end of connection logging is available for decryption events. As with other event types the logs can be sent to the FMC, syslog, or both. Click save when done.

As with other policies, the decryption policy has a default action. Click the log icon to configure.

Click OK when configuration is complete.

Save the decryption policy, then deploy the changes when ready.

Logging & Syslog Configuration for Audit Logs

While audit events can be easily accessed on the FMC, organizations may opt to export them to comply with regulations or as a best practice. FMC admins can delete audit events, but deleting an audit event will create a new audit event that includes the action and the details on the user who initiated the action, creating a record of non-repudiation. While this is an acceptable level of control for some, storing audit logs in a remote location with more controlled data retention is preferable.

Audit logs are sent directly from the FMC to a syslog server, and require separate configuration from the platform settings configuration set earlier. By default, audit logs will be sent over UDP port 514, which is the configuration covered in this guide. However, audit logs can also be sent via encrypted TCP, which is a best practice when a compatible syslog destination is available. For steps to configure encrypted syslog for audit events, see the Audit Log Certificate section of the configuration guide.

Configuring Audit Event Syslog

In the FMC, navigate to system > configuration.

Click on audit log.

Set ‘send audit log to syslog’ to enabled. Specify the host or IP address of the syslog server. Leave the facility and severity on the default values unless other values are preferred. A tag can also be set, if desired.

The above configuration also has an option for ‘send configuration changes’. This setting includes granular change data to supplement the audit logs, and can be configured if desired.

By default, the FMC uses ICMP (or ARP for a local network syslog server) and TCP SYN packets to verify connectivity to the syslog server. You can verify connectivity using the Test Syslog Server button. Click save when finished.