Platform Settings for Firepower Threat Defense

Platform settings for Firepower Threat Defense devices configure a range of unrelated features whose values you might want to share among several devices. Even if you want different settings per device, you must create a shared policy and apply it to the desired device.

Configure ARP Inspection

By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP packets by enabling ARP inspection.

ARP inspection prevents malicious users from impersonating other hosts or routers (known as ARP spoofing). ARP spoofing can enable a “man-in-the-middle” attack. For example, a host sends an ARP request to the gateway router; the gateway router responds with the gateway router MAC address. The attacker, however, sends another ARP response to the host with the attacker MAC address instead of the router MAC address. The attacker can now intercept all the host traffic before forwarding it on to the router.

ARP inspection ensures that an attacker cannot send an ARP response with the attacker MAC address, so long as the correct MAC address and the associated IP address are in the static ARP table.

When you enable ARP inspection, the FTD device compares the MAC address, IP address, and source interface in all ARP packets to static entries in the ARP table, and takes the following actions:

  • If the IP address, MAC address, and source interface match an ARP entry, the packet is passed through.

  • If there is a mismatch between the MAC address, the IP address, or the interface, then the FTD device drops the packet.

  • If the ARP packet does not match any entries in the static ARP table, then you can set the FTD device to either forward the packet out all interfaces (flood), or to drop the packet.


    Note

    The dedicated interface never floods packets even if this parameter is set to flood.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select ARP Inspection.

Step 3

Add entries to the ARP inspection table.

  1. Click Add to create a new entry, or click Edit if the entry already exists.

  2. Select the desired options.

    • Inspect Enabled—To perform ARP inspection on the selected interfaces and zones.

    • Flood Enabled—Whether to flood ARP requests that do not match static ARP entries out all interfaces other than the originating interface or the dedicated management interface. This is the default behavior.

      If you do not elect to flood ARP requests, then only those requests that exactly match static ARP entries are allowed.

    • Security Zones—Add the zones that contain the interfaces on which to perform the selected actions. The zones must be switched zones. For interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.

  3. Click OK.

Step 4

Add static ARP entries according to Add a Static ARP Entry.

Step 5

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure Banners

You can configure messages to show users when they connect to the device command line interface (CLI).

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Banner.

Step 3

Configure the banner.

Following are some tips and requirements for banners.

  • Only ASCII characters are allowed. You can use line returns (press Enter), but you cannot use tabs.

  • You can dynamically add the hostname or domain name of the device by including the variables $(hostname) or $(domain) .

  • Although there is no absolute length restriction on banners, Telnet or SSH sessions will close if there is not enough system memory available to process the banner messages.

  • From a security perspective, it is important that your banner discourage unauthorized access. Do not use the words "welcome" or "please," as they appear to invite intruders in. The following banner sets the correct tone for unauthorized access: 

    
You have logged in to a secure device. 
If you are not authorized to access this device, 
log out immediately or risk criminal charges.

Step 4

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure Fragment Handling

By default, the Firepower Threat Defense device allows up to 24 fragments per IP packet, and up to 200 fragments awaiting reassembly. You might need to let fragments on your network if you have an application that routinely fragments packets, such as NFS over UDP. However, if you do not have an application that fragments traffic, we recommend that you do not allow fragments by setting Chain to 1. Fragmented packets are often used as Denial of Service (DoS) attacks.


Note

These settings establish the defaults for devices assigned this policy. You can override these settings for specific interfaces on a device by selecting Override Default Fragment Setting in the interface configuration. When you edit an interface, you can find the option on Advanced > Security Configuration. Select Devices > Device Management, edit a Firepower Threat Defense device, and select Interfaces to edit interface properties..

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Fragment Settings.

Step 3

Configure the following options. Click Reset to Defaults if you want to use the default settings.

  • Size (Block)—The maximum number of packet fragments from all connections collectively that can be waiting for reassembly. The default is 200 fragments.
  • Chain (Fragment)—The maximum number of packets into which a full IP packet can be fragmented. The default is 24 packets. Set this option to 1 to disallow fragments.
  • Timeout (Sec)—The maximum number of seconds to wait for an entire fragmented packet to arrive. The default is 5 seconds. If all fragments are not received within this time, all fragments are discarded.

Step 4

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure HTTP

If you want to allow HTTPS connections to one or more interfaces on the Firepower Threat Defense device, configure HTTPS settings. You can use HTTPS to download packet captures for troubleshooting.

Before you begin

  • When you manage the Firepower Threat Defense using the FMC, HTTPS access to the Firepower Threat Defense is only for viewing packet capture files. The Firepower Threat Defense does not have a web interface for configuration in this management mode.

  • HTTPS local users can only be configured at the CLI using the configure user add command. By default, there is an admin user for which you configured the password during initial setup. AAA external authentication is not supported.

  • The physical management interface is shared between the Diagnostic logical interface and the Management logical interface; this configuration applies only to the Diagnostic logical interface, if used, or to other data interfaces. The Management logical interface is separate from the other interfaces on the device. It is used to set up and register the device to the FMC. It has a separate IP address and static routing.

  • To use HTTPS, you do not need an access rule allowing the host IP address. You only need to configure HTTPS access according to this section.

  • You can only use HTTPS to a reachable interface; if your HTTPS host is located on the outside interface, you can only initiate a management connection directly to the outside interface.

  • The device allows a maximum of 5 concurrent HTTPS connections.

  • You need network objects that define the hosts or networks you will allow to make HTTPS connections to the device. Select Objects > Object Management to configure objects.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select HTTP.

Step 3

Enable the HTTPS server by clicking Enable HTTP server.

Step 4

(Optional) Change the HTTPS port. The default is 443.

Step 5

Identify the interfaces and IP addresses that allow HTTPS connections.

Use this table to limit which interfaces will accept HTTPS connections, and the IP addresses of the clients who are allowed to make those connections. You can use network addresses rather than individual IP addresses.

  1. Click Add to add a new rule, or click Edit to edit an existing rule.

  2. Configure the rule properties:

    • IP Address—The network object that identifies the hosts or networks you are allowing to make HTTPS connections. Choose an object from the drop-down menu, or add a new network object by clicking +.

    • Security Zones—Add the zones that contain the interfaces to which you will allow HTTPS connections. For interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.

  3. Click OK.

Step 6

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure ICMP Access Rules

By default, you can send ICMP packets to any interface using either IPv4 or IPv6, with these exceptions:

  • The FTD does not respond to ICMP echo requests directed to a broadcast address.

  • The FTD only responds to ICMP traffic sent to the interface that traffic comes in on; you cannot send ICMP traffic through an interface to a far interface.

To protect the device from attacks, you can use ICMP rules to limit ICMP access to interfaces to particular hosts, networks, or ICMP types. ICMP rules function like access rules, where the rules are ordered, and the first rule that matches a packet defines the action.

If you configure any ICMP rule for an interface, an implicit deny ICMP rule is added to the end of the ICMP rule list, changing the default behavior. Thus, if you want to simply deny a few message types, you must include a permit any rule at the end of the ICMP rule list to allow the remaining message types.

We recommend that you always grant permission for the ICMP unreachable message type (type 3). Denying ICMP unreachable messages disables ICMP path MTU discovery, which can halt IPsec and PPTP traffic. Additionally ICMP packets in IPv6 are used in the IPv6 neighbor discovery process.

Before you begin

Ensure that the objects needed in the rules already exist. Select Objects > Object Management to configure objects. You need network objects that define the desired hosts or networks, and port objects that define the ICMP message types you want to control.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select ICMP.

Step 3

Configure ICMP rules.

  1. Click Add to add a new rule, or click Edit to edit an existing rule.

  2. Configure the rule properties:

    • Action—Whether to permit (allow) or deny (drop) matching traffic.

    • ICMP Service—The port object that identifies the ICMP message type.

    • Network—The network object that identifies the hosts or networks whose access you are controlling.

    • Security Zones—Add the zones that contain the interfaces that you are protecting. For interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.

  3. Click OK.

Step 4

(Optional.) Set rate limits on ICMPv4 Unreachable messages.

  • Rate Limit—Sets the rate limit of unreachable messages, between 1 and 100 messages per second. The default is 1 message per second.

  • Burst Size—Sets the burst rate, between 1 and 10. The system sends this number of replies, but subsequent replies are not sent until the rate limit is reached.

Step 5

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure Secure Shell

This section describes how to enable SSH connections to one or more data interfaces on the Firepower Threat Defense. SSH is not supported to the Diagnostic logical interface.


Note

SSH is enabled by default on the Management interface; however, this screen does not affect Management SSH access.

The Management interface is separate from the other interfaces on the device. It is used to set up and register the device to the FMC. SSH for data interfaces shares the internal user list with SSH for the Management interface. Other settings are configured separately: for data interfaces, enable SSH and access lists using this screen; SSH traffic for data interfaces uses the regular routing configuration, and not any static routes configured at setup or at the CLI.

For the Management interface, to configure an SSH access list, see the configure ssh-access-list command in the Firepower Threat Defense Command Reference. To configure a static route, see the configure network static-routes command. By default, you configure the default route through the Management interface at initial setup.

To use SSH, you do not also need an access rule allowing the host IP address. You only need to configure SSH access according to this section.

You can only SSH to a reachable interface; if your SSH host is located on the outside interface, you can only initiate a management connection directly to the outside interface.

The device allows a maximum of 5 concurrent SSH connections.

Before you begin

  • SSH local users can only be configured at the CLI using the configure user add command; see Creating Local User Accounts for the FTD CLI. By default, there is an admin user for which you configured the password during initial setup. AAA external authentication is not supported.

  • You need network objects that define the hosts or networks you will allow to make SSH connections to the device. Select Objects > Object Management to configure objects.


    Note

    You cannot use the system-provided any network object. Instead, use any-ipv4 or any-ipv6.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Secure Shell.

Step 3

Identify the interfaces and IP addresses that allow SSH connections.

Use this table to limit which interfaces will accept SSH connections, and the IP addresses of the clients who are allowed to make those connections. You can use network addresses rather than individual IP addresses.

  1. Click Add to add a new rule, or click Edit to edit an existing rule.

  2. Configure the rule properties:

    • IP Address—The network object that identifies the hosts or networks you are allowing to make SSH connections. Choose an object from the drop-down menu, or add a new network object by clicking +.

    • Security Zones—Add the zones that contain the interfaces to which you will allow SSH connections. For interfaces not in a zone, you can type the interface name into the field below the Selected Security Zone list and click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.

  3. Click OK.

Step 4

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure SMTP

You must identity an SMTP server if you configure email alerts in the Syslog settings. The source email address you configure for Syslog must be a valid account on the SMTP servers.

Before you begin

Ensure that the network objects that define the host address of the primary and secondary SMTP servers exist. Select Objects > Object Management to define the objects. Alternatively, you can create the objects while editing the policy.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Click SMTP Server.

Step 3

Select the network objects that identify the Primary Server IP Address and optionally, the Secondary Server IP Address.

Step 4

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure SNMP for Threat Defense

Simple Network Management Protocol (SNMP) defines a standard way for network management stations running on PCs or workstations to monitor the health and status of many types of devices, including switches, routers, and security appliances. You can use the SNMP page to configure a firewall device for monitoring by SNMP management stations.

The Simple Network Management Protocol (SNMP) enables monitoring of network devices from a central location. Cisco security appliances support network monitoring using SNMP versions 1, 2c, and 3, as well as traps and SNMP read access; SNMP write access is not supported.

SNMPv3 supports read-only users and encryption with DES, 3DES, AES256, AES192, and AES128.


Note
To create an alert to an external SNMP server, access Policies > Action > Alerts

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select SNMP.

Step 3

Enable SNMP and configure basic options.

  • Enable SNMP Servers—Whether to provide SNMP information to the configured SNMP hosts. You can deselect this option to disable SNMP monitoring while retaining the configuration information.
  • Read Community String, Confirm—Enter the password used by a SNMP management station when sending requests to the Firepower Threat Defense device. The SNMP community string is a shared secret among the SNMP management stations and the network nodes being managed. The security device uses the password to determine if the incoming SNMP request is valid. The password is a case-sensitive alphanumeric string of up to 32 characters; spaces and special characters are not permitted.
  • System Administrator Name—Enter the name of the device administrator or other contact person. This string is case-sensitive and can be up to 127 characters. Spaces are accepted, but multiple spaces are shortened to a single space.
  • Location—Enter the location of this security device (for example, Building 42,Sector 54). This string is case-sensitive and can be up to 127 characters. Spaces are accepted, but multiple spaces are shortened to a single space.
  • Port—Enter the UDP port on which incoming requests will be accepted. The default is 161.

Step 4

(SNMPv3 only.) Add SNMPv3 Users.

Step 5

Add SNMP Hosts.

Step 6

Configure SNMP Traps.

Step 7

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Add SNMPv3 Users


Note

You create users for SNMPv3 only. These steps are not applicable for SNMPv1 or SNMPv2c.

Note that SNMPv3 only supports read-only users.

SNMP users have a specified username, an authentication password, an encryption password, and authentication and encryption algorithms to use. The authentication algorithm options are MD5 and SHA. The encryption algorithm options are DES, 3DES, AES256, AES192, and AES128.


Note

When using SNMPv3 with clustering or High Availability, if you add a new cluster unit after the initial cluster formation or you replace a High Availability unit, then SNMPv3 users are not replicated to the new unit. You must remove the users, re-add them, and then redeploy your configuration to force the users to replicate to the new unit.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Click SNMP > Users.

Step 3

Click Add.

Step 4

Select the security level for the user from the Security Level drop-down list.

  • Auth—Authentication but No Privacy, which means that messages are authenticated.

  • No Auth—No Authentication and No Privacy, which means that no security is applied to messages.

  • Priv—Authentication and Privacy, which means that messages are authenticated and encrypted.

Step 5

Enter the name of the SNMP user in the Username field. Usernames must be 32 characters or less.

Step 6

Select the type of password, you want to use in the Encryption Password Type drop-down list.

  • Clear text—The Firepower Threat Defense device will still encrypt the password when deploying to the device.
  • Encrypted—The Firepower Threat Defense device will directly deploy the encrypted password.

Step 7

In the Auth Algorithm Type drop-down list, select the type of authentication you want to use: MD5, SHA.

Step 8

In the Authentication Password field, enter the password to use for authentication. If you selected Encrypted as the Encrypt Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal values.

Note

 

The length of the password will depend on the authentication algorithm selected. For all passwords, the length must be 256 characters or less.

If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.

Step 9

In the Encryption Type drop-down list, select the type of encryption you want to use: AES128, AES192, AES256, 3DES, or DES.

Note

 

To use AES or 3DES encryption, you must have the appropriate license installed on the device.

Step 10

Enter the password to use for encryption in the Encryption Password field. If you selected Encrypted as the Encrypt Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal values. For encrypted passwords, the length of the password depends on the encryption type selected. The password sizes are as follows (where each xx is one octal):

  • AES 128 requires 16 octals

  • AES 192 requires 24 octals

  • AES 256 requires 32 octals

  • 3DES requires 32 octals

  • DES can be any size

Note

 

For all passwords, the length must be 256 characters or less.

If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.

Step 11

Click OK.

Step 12

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Add SNMP Hosts

Use Host to add or edit entries in the SNMP Hosts table on the SNMP page. These entries represent SNMP management stations allowed to access the Firepower Threat Defense device.

Before you begin

Ensure that the network objects that define the SNMP management stations exist. Select Device > Object Management to configure network objects.


Note
Only IPv4 addresses are supported.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Click SNMP > Hosts.

Step 3

Click Add.

Step 4

In the IP Address field, either enter a valid IPv6 or IPv4 host or select the network object that defines the SNMP management station's host address.

Step 5

Select the appropriate SNMP version from the SNMP version drop-down list.

Step 6

(SNMPv3 only.) Select the username of the SNMP user that you configured from the User Name drop-down list.

Note

 
You can associate up to 23 SNMP users per SNMP host.

Step 7

(SNMPv1, 2c only.) In the Read Community String field, enter the community string that you have already configured, for read access to the device. Re-enter the string to confirm it.

Note

 
This string is required, only if the string used with this SNMP station is different from the one already defined in the Enable SNMP Server section.

Step 8

Select the type of communication between the device and the SNMP management station. You can select both types.

  • Poll—The management station periodically requests information from the device.
  • Trap—The device sends trap events to the management station as they occur.

Step 9

In the Port field, enter a UDP port number for the SNMP host. The default value is 162. The valid range is 1 to 65535.

Step 10

Click Add to enter or select the interface on which this SNMP management station contacts the device.

Step 11

In the Zones/Interfaces list, add the zones that contain the interfaces through which the device communicates with the management station. For interfaces not in a zone, you can type the interface name into the field below the Selected Zone/Interface list and click Add. The host will be configured on a device only if the device includes the selected interfaces or zones.

Step 12

Click OK.

Step 13

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure SNMP Traps

Use SNMP Traps to configure SNMP traps (event notifications) for the Firepower Threat Defense device. Traps are different from browsing; they are unsolicited “comments” from the Firepower Threat Defense device to the management station for certain events, such as linkup, linkdown, and syslog event generated. An SNMP object ID (OID) for the device appears in SNMP event traps sent from the device.

Some traps are not applicable to certain hardware models. These traps will be ignored if you apply the policy to one of these models. For example, not all models have field-replaceable units, so the Field Replaceable Unit Insert/Delete trap will not be configured on those models.

SNMP traps are defined in either standard or enterprise-specific MIBs. Standard traps are created by the IETF and documented in various RFCs. SNMP traps are compiled into the Firepower Threat Defense software.

If needed, you can download RFCs, standard MIBs, and standard traps from the following location:

http://www.ietf.org/

Browse the complete list of Cisco MIBs, traps, and OIDs from the following location:

SNMP Object Navigator

In addition, download Cisco OIDs by FTP from the following location:

ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Click SNMP > SNMP Traps to configure SNMP traps (event notifications) for the Firepower Threat Defense device.

Step 3

Select the appropriate Enable Traps options. You can select either or both options.

  1. Check Enable All SNMP Traps to quickly select all traps in the subsequent four sections.

  2. Check Enable All Syslog Traps to enable transmission of trap-related syslog messages.

Note

 
SNMP traps are of higher priority than other notification messages from the Firepower Threat Defense as they are expected to be near real-time. When you enable all SNMP or syslog traps, it is possible for the SNMP process to consume excess resources in the agent and in the network, causing the system to hang. If you notice system delays, unfinished requests, or timeouts, you can selectively enable SNMP and syslog traps. You can also limit the rate at which syslog messages are generated by severity level or message ID. For example, all syslog message IDs that begin with the digits 212 are associated with the SNMP class; see Limit the Rate of Syslog Message Generation.

Step 4

The event-notification traps in the Standard section are enabled by default for an existing policy:

  • Authentication – Unauthorized SNMP access. This authentication failure occurs for packets with an incorrect community string.

  • Link Up – One of the device’s communication links has become available (it has “come up”), as indicated in the notification.

  • Link Down – One of the device’s communication links has failed, as indicated in the notification.

  • Cold Start – The device is reinitializing itself such that its configuration or the protocol entity implementation may be altered.

  • Warm Start – The device is reinitializing itself such that its configuration and the protocol entity implementation is unaltered.

Step 5

Select the desired event-notification traps in the Entity MIB section:

  • Field Replaceable Unit Insert – A Field Replaceable Unit (FRU) has been inserted, as indicated. (FRUs include assemblies such as power supplies, fans, processor modules, interface modules, etc.)

  • Field Replaceable Unit Delete – A Field Replaceable Unit (FRU) has been removed, as indicated in the notification

  • Configuration Change – There has been a hardware change, as indicated in the notification

Step 6

Select the desired event-notification traps in the Resource section:

  • Connection Limit Reached – This trap indicates that a connection attempt was rejected because the configured connections limit has been reached.

Step 7

Select the desired event-notification traps in the Other section:

  • NAT Packet Discard – This notification is generated when IP packets are discarded by the NAT function. Available Network Address Translation addresses or ports have fallen below configured threshold.

Step 8

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

About Configuring Syslog

You can enable system logging (syslog) for Firepower Threat Defense devices. Logging information can help you identify and isolate network or device configuration problems. The following topics explain logging and how to configure it.

About Syslog

System logging is a method of collecting messages from devices to a server running a syslog daemon. Logging to a central syslog server helps in aggregation of logs and alerts. Cisco devices can send their log messages to a UNIX-style syslog service. A syslog service accepts messages and stores them in files, or prints them according to a simple configuration file. This form of logging provides protected long-term storage for logs. Logs are useful both in routine troubleshooting and in incident handling.

Table 1. System Logs for Firepower Threat Defense

Logs Related To

Details

Configure In

Device and system health, network configuration

This syslog configuration generates messages for features running on the data plane, that is, features that are defined in the CLI configuration that you can view with the show running-config command. This includes features such as routing, VPN, data interfaces, DHCP server, NAT, and so forth. Data plane syslog messages are numbered, and they are the same as those generated by devices running ASA software. However, Firepower Threat Defense does not necessarily generate every message type that is available for ASA Software. For information on these messages, see Cisco Firepower Threat Defense Syslog Messages at https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/b_fptd_syslog_guide.html. This configuration is explained in the following topics.

Platform Settings

Policies, rules, and events

This syslog configuration generates alerts for access control rules, intrusion rules, and other advanced services as described in Configurations Supporting Alert Responses. These messages are not numbered. For information on configuring this type of syslog, see Creating a Syslog Alert Response.

Alert Responses

You can configure more than one syslog server, and control the messages and events sent to each server. You can also configure different destinations, such as console, email, internal buffer, and so forth.

Severity Levels

The following table lists the syslog message severity levels.

Table 2. Syslog Message Severity Levels

Level Number

Severity Level

Description

0

emergencies

System is unusable.

1

alert

Immediate action is needed.

2

critical

Critical conditions.

3

error

Error conditions.

4

warning

Warning conditions.

5

notification

Normal but significant conditions.

6

informational

Informational messages only.

7

debugging

Debugging messages only.

Log at this level only temporarily, when debugging issues. This log level can potentially generate so many messages that system performance can be affected.


Note

ASA and FTD do not generate syslog messages with a severity level of zero (emergencies).

Syslog Message Filtering

You can filter generated syslog messages so that only certain syslog messages are sent to a particular output destination. For example, you could configure the FTD device to send all syslog messages to one output destination and to send a subset of those syslog messages to a different output destination.

Specifically, you can direct syslog messages to an output destination according to the following criteria:

  • Syslog message ID number

  • Syslog message severity level

  • Syslog message class (equivalent to a functional area)

You customize these criteria by creating a message list that you can specify when you set the output destination. Alternatively, you can configure the FTD device to send a particular message class to each type of output destination independently of the message list.

Syslog Message Classes

You can use syslog message classes in two ways:

  • Specify an output location for an entire category of syslog messages.

  • Create a message list that specifies the message class.

The syslog message class provides a method of categorizing syslog messages by type, equivalent to a feature or function of the device. For example, the rip class denotes RIP routing.

All syslog messages in a particular class share the same initial three digits in their syslog message ID numbers. For example, all syslog message IDs that begin with the digits 611 are associated with the vpnc (VPN client) class. Syslog messages associated with the VPN client feature range from 611101 to 611323.

In addition, most of the ISAKMP syslog messages have a common set of prepended objects to help identify the tunnel. These objects precede the descriptive text of a syslog message when available. If the object is not known at the time that the syslog message is generated, the specific heading = value combination does not appear.

The objects are prefixed as follows:

Group = groupname, Username = user, IP = IP_address

Where the group is the tunnel-group, the username is the username from the local database or AAA server, and the IP address is the public IP address of the remote access client or Layer 2 peer.

The following table lists the message classes and the range of message IDs in each class.

Table 3. Syslog Message Classes and Associated Message ID Numbers

Class

Definition

Syslog Message ID Numbers

auth

User Authentication

109, 113

—

Access Lists

106

—

Application Firewall

415

—

Botnet Traffic Filtering

338

bridge

Transparent Firewall

110, 220

ca

PKI Certification Authority

717

citrix

Citrix Client

723

—

Clustering

747

—

Card Management

323

config

Command Interface

111, 112, 208, 308

csd

Secure Desktop

724

cts

Cisco TrustSec

776

dap

Dynamic Access Policies

734

eap, eapoudp

EAP or EAPoUDP for Network Admission Control

333, 334

eigrp

EIGRP Routing

336

email

E-mail Proxy

719

—

Environment Monitoring

735

ha

Failover

101, 102, 103, 104, 105, 210, 311, 709

—

Identity-based Firewall

746

ids

Intrusion Detection System

400, 733

—

IKEv2 Toolkit

750, 751, 752

ip

IP Stack

209, 215, 313, 317, 408

ipaa

IP Address Assignment

735

ips

Intrusion Protection System

400, 401, 420

—

IPv6

325

—

Licensing

444

mdm-proxy

MDM Proxy

802

nac

Network Admission Control

731, 732

nacpolicy

NAC Policy

731

nacsettings

NAC Settings to apply NAC Policy

732

—

NAT and PAT

305

—

Network Access Point

713

np

Network Processor

319

—

NP SSL

725

ospf

OSPF Routing

318, 409, 503, 613

—

Password Encryption

742

—

Phone Proxy

337

rip

RIP Routing

107, 312

rm

Resource Manager

321

—

Smart Call Home

120

session

User Session

106, 108, 201, 202, 204, 302, 303, 304, 305, 314, 405, 406, 407, 500, 502, 607, 608, 609, 616, 620, 703, 710

snmp

SNMP

212

—

ScanSafe

775

ssl

SSL Stack

725

svc

SSL VPN Client

722

sys

System

199, 211, 214, 216, 306, 307, 315, 414, 604, 605, 606, 610, 612, 614, 615,701, 711, 741

—

Threat Detection

733

tag-switching

Service Tag Switching

779

vm

VLAN Mapping

730

vpdn

PPTP and L2TP Sessions

213, 403, 603

vpn

IKE and IPsec

316, 320, 402, 404, 501, 602, 702, 713, 714, 715

vpnc

VPN Client

611

vpnfo

VPN Failover

720

vpnlb

VPN Load Balancing

718

—

VXLAN

778

webfo

WebVPN Failover

721

webvpn

WebVPN and AnyConnect Client

716

Guidelines for Logging

This section includes guidelines and limitations that you should review before configuring logging.

IPv6 Guidelines

  • IPv6 is supported. Syslogs can be sent using TCP or UDP.

  • Ensure that the interface configured for sending syslogs is enabled, IPv6 capable, and the syslog server is reachable through the designated interface.

  • Secure logging over IPv6 is not supported.

Additional Guidelines

  • The syslog server must run a server program called syslogd. Windows provides a syslog server as part of its operating system.

  • To view logs generated by the FTD device, you must specify a logging output destination. If you enable logging without specifying a logging output destination, the FTD device generates messages but does not save them to a location from which you can view them. You must specify each different logging output destination separately.

  • It is not possible to have two different lists or classes being assigned to different syslog servers or same locations.

  • You can configure up to 16 syslog servers.

  • The syslog server should be reachable through the FTD device. You should configure the device to deny ICMP unreachable messages on the interface through which the syslog server is reachable and to send syslogs to the same server. Make sure that you have enabled logging for all severity levels. To prevent the syslog server from crashing, suppress the generation of syslogs 313001, 313004, and 313005.

  • The number of UDP connections for syslog is directly related to the number of CPUs on the hardware platform and the number of syslog servers you configure. At any point in time, there can be as many UDP syslog connections as there are CPUs times the number of configured syslog servers. This is the expected behavior. Note that the global UDP connection idle timeout applies to these sessions, and the default is 2 minutes. You can adjust that setting if you want to close these session more quickly, but the timeout applies to all UDP connections, not just syslog.

  • When the FTD device sends syslogs via TCP, the connection takes about one minute to initiate after the syslogd service restarts.

Configure Syslog Logging for FTD Devices

To configure syslog settings, perform the following steps:

Before you begin

See requirements in Guidelines for Logging.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Click Syslog from the table of contents.

Step 3

Click Logging Setup to enable logging, specify FTP Server settings, and specify Flash usage. For more information, see Enable Logging and Configure Basic Settings

Step 4

Click Logging Destinations to enable logging to specific destinations and to specify filtering on message severity level, event class, or on a custom event list. For more information, see Enable Logging Destinations

You must enable a logging destination to see messages at that destination.

Step 5

Click E-mail Setup to specify the e-mail address that is used as the source address for syslog messages that are sent as e-mail messages. For more information, see Send Syslog Messages to an E-mail Address

Step 6

Click Events List to define a custom event list that includes an event class, a severity level, and an event ID. For more information, see Create a Custom Event List

Step 7

Click Rate Limit to specify the volume of messages being sent to all configured destinations and define the message severity level to which you want to assign rate limits. For more information, see Limit the Rate of Syslog Message Generation

Step 8

Click Syslog Settings to specify the logging facility, enable the inclusion of a time stamp, and enable other settings to set up a server as a syslog destination. For more information, see Configure Syslog Settings

Step 9

Click Syslog Servers to specify the IP address, protocol used, format, and security zone for the syslog server that is designated as a logging destination. For more information, see Configure a Syslog Server

Enable Logging and Configure Basic Settings

You must enable logging for the system to generate syslog messages for data plane events.

You can also set up archiving on flash or an FTP server as a storage location when the local buffer becomes full. You can manipulate logging data after it is saved. For example, you could specify actions to be executed when certain types of syslog messages are logged, extract data from the log and save the records to another file for reporting, or track statistics using a site-specific script.

The following procedure explains some of the basic syslog settings.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Logging Setup.

Step 3

Enable logging and configure basic logging settings.

  • Enable Logging—Turns on data plane system logging for the Firepower Threat Defense device.
  • Enable Logging on the Failover Standby Unit—Turns on logging for the standby for the Firepower Threat Defense device, if available.
  • Send syslogs in EMBLEM format—Enables EMBLEM format logging for every logging destination. If you enable EMBLEM, you must use the UDP protocol to publish syslog messages; EMBLEM is not compatible with TCP.

    Note

     

    Syslog messages in RFC5424 format, typically displays the priority value (PRI). However, in FMC, if you want to display the PRI value in the syslog messages of the managed FTD, ensure to enable the EMBLEM format. For more information on PRI, see RFC5424.

  • Send debug messages as syslogs—Redirects all the debug trace output to the syslog. The syslog message does not appear in the console if this option is enabled. Therefore, to see debug messages, you must enable logging at the console and configure it as the destination for the debug syslog message number and logging level. The syslog message number used is 71101. Default logging level for this syslog is debug.
  • Memory Size of Internal Buffer—Specify the size of the internal buffer to which syslog messages are saved if the logging buffer is enabled. When the buffer fills up, it is overwritten. The default is 4096 bytes. The range is 4096 to 52428800.

Step 4

(Optional) Configure an FTP server if you want to save log buffer contents to the server before the buffer is overwritten. Specify the FTP Server information.

  • FTP Server Buffer Wrap— To save the buffer contents to the FTP server before it is overwritten, check this box and enter the necessary destination information in the following fields. To remove the FTP configuration, deselect this option.
  • IP Address—Select the host network object that contains the IP address of the FTP server.
  • User Name—Enter the user name to use when connecting to the FTP server.
  • Path—Enter the path, relative to the FTP root, where the buffer contents should be saved.
  • Password/ Confirm—Enter and confirm the password used to authenticate the user name to the FTP server.

Step 5

(Optional) Specify Flash size if you want to save log buffer contents to flash before the buffer is overwritten.

  • Flash—To save the buffer contents to the flash memory before it is overwritten, check this box.
  • Maximum flash to be used by logging (KB)—Specify the maximum space to be used in the flash memory for logging(in KB). The range is 4-8044176 kilobytes.
  • Minimum free space to be preserved (KB)—Specifies the minimum free space to be preserved in flash memory (in KB). The range is 0-8044176 kilobytes.

Step 6

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Enable Logging Destinations

You must enable a logging destination to see messages at that destination. When enabling a destination, you must also specify the message filter for the destination.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Logging Destinations.

Step 3

Click Add to enable a destination and apply a logging filter, or edit an existing destination.

Step 4

In the Logging Destinations dialog box, select a destination and configure the filter to use for a destination:

  1. Choose the destination you are enabling in the Logging Destination drop-down list. You can create one filter per destination: Console, E-Mail, Internal buffer, SNMP trap, SSH Sessions, and Syslog servers.

    Note

     

    Console and SSH session logging works in the diagnostic CLI only. Enter system support diagnostic-cli .

  2. In Event Class, choose the filter that will apply to all classes not listed in the table.

    You can configure these filters:

    • Filter on severity —Select the severity level. Messages at this level or higher are sent to the destination

    • Use Event List —Select the event list that defines the filter. You create these lists on the Event Lists page.

    • Disable Logging —Prevents messages from being sent to this destination.

  3. If you want to create filters per event class, click Add to create a new filter, or edit an existing filter, and select the event class and severity level to limit messages in that class. Click OK to save the filter.

    For an explanation of the event classes, see Syslog Message Classes.

  4. Click OK .

Step 5

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Send Syslog Messages to an E-mail Address

You can set up a list of recipients for syslog messages to be sent as e-mails.

Before you begin
Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Email Setup.

Step 3

Specify the e-mail address that is used as the source address for syslog messages that are sent as e-mail messages.

Step 4

Click Add to enter a new e-mail address recipient of the specified syslog messages.

Step 5

Choose the severity level of the syslog messages that are sent to the recipient from the drop-down list.

The syslog message severity filter used for the destination e-mail address causes messages of the specified severity level and higher to be sent. For information on the levels, see Severity Levels.

Step 6

Click OK.

Step 7

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Create a Custom Event List

An event list is a custom filter you can apply to a logging destination to control which messages are sent to the destination. Normally, you filter messages for a destination based on severity only, but you can use an event list to fine-tune which messages are sent based on a combination of event class, severity, and message identifier (ID).

Creating a custom event list is a two-step process. You create a custom list in the Event Lists, and then use the event list to define the logging filter for the various types of destination, in the Logging Destinations.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Events List.

Step 3

Configure an event list.

  1. Click Add to add a new list, or edit an existing list.

  2. Enter a name for the event list in the Name field. Spaces are not allowed.

  3. To identify messages based on severity or event class, select the Severity/Event Class tab and add or edit entries.

    For information on the available classes see Syslog Message Classes.

    For information on the levels, see Severity Levels.

    Certain event classes are not applicable for the device in transparent mode. If such options are configured then they will be bypassed and not deployed.

  4. To identify messages specifically by message ID, select the Message ID and add or edit the IDs.

    You can enter a range of IDs using a hyphen, for example, 100000-200000. IDs are six digits. For information on how the initial three digits map to features, see Syslog Message Classes.

    For specific message numbers, see Cisco ASA Series Syslog Messages.

  5. Click OK to save the event list.

Step 4

Click Logging Destinations and add or edit the destination that should use the filter.

See Enable Logging Destinations.

Step 5

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Limit the Rate of Syslog Message Generation

You can limit the rate at which syslog messages are generated by severity level or message ID. You can specify individual limits for each logging level and each Syslog message ID. If the settings conflict, the Syslog message ID limits take precedence.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Rate Limit.

Step 3

To limit message generation by severity level, click Logging Level > Add and configure the following options:

  • Logging Level—The severity level you are rate limiting. For information on the levels, see Severity Levels.
  • Number of messages—The maximum number of messages of the specified type allowed in the specified time period.
  • Interval—The number of seconds before the rate limit counter resets.

Step 4

Click OK.

Step 5

To limit message generation by syslog message ID, click Syslog Level > Add and configure the following options:

  • Syslog ID—The syslog message ID you are rate limiting. For specific message numbers, see Cisco ASA Series Syslog Messages.
  • Number of messages—The maximum number of messages of the specified type allowed in the specified time period.
  • Interval—The number of seconds before the rate limit counter resets.

Step 6

Click OK.

Step 7

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure Syslog Settings

You can configure general syslog settings to set the facility code to be included in syslog messages that are sent to syslog servers, specify whether a timestamp is included in each message, specify the device ID to include in messages, view and modify the severity levels for messages, and disable the generation of specific messages.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Syslog Settings.

Step 3

Select a system log facility for syslog servers to use as a basis to file messages in the Facility drop-down list.

The default is LOCAL4(20), which is what most UNIX systems expect. However, because your network devices share available facilities, you might need to change this value for system logs.

Step 4

Select the Enable timestamp on each syslog message check box to include the date and time a message was generated in the syslog message.

Timestamp timezone is always UTC.

Step 5

If you want to add a device identifier to syslog messages (which is placed at the beginning of the message), check the Enable Syslog Device ID check box and then select the type of ID.

  • Interface—To use the IP address of the selected interface, regardless of the interface through which the appliance sends the message. Select the security zone that identifies the interface. The zone must map to a single interface.
  • User Defined ID—To use a text string (up to 16 characters) of your choice.
  • Host Name—To use the hostname of the device.

Step 6

Use the Syslog Message table to alter the default settings for specific syslog messages. You need to configure rules in this table only if you want to change the default settings. You can change the severity assigned to a message, or you can disable the generation of a message.

By default, Netflow is enabled and the entries are shown in the table.

  1. To suppress syslog messages that are redundant because of Netflow, select Netflow Equivalent Syslogs.

    This adds the messages to the table as suppressed messages.

    Note

     

    If any of these syslog equivalents are already in the table, your existing rules are not overwritten.

  2. To add a rule, click Add.

  3. You select the message number whose configuration you want to change, from the Syslog ID drop down list and then select the new severity level from the Logging Level drop down list, or select Suppressed to disable the generation of the message. Typically, you would not change the severity level and disable the message, but you can make changes to both fields if desired.

  4. Click OK to add the rule to the table.

Step 7

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

What to do next

Configure a Syslog Server

To configure a syslog server to handle messages generated from your system, perform the following steps.

Before you begin

  • See requirements in Guidelines for Logging.

  • Make sure your devices can reach your syslog collector on the network.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Syslog > Syslog Server.

Step 3

Check the Allow user traffic to pass when TCP syslog server is down check box, to allow traffic if any syslog server that is using the TCP protocol is down.

Step 4

Enter a size of the queue for storing syslog messages on the security appliance when syslog server is busy in the Message queue size (messages) field. The minimum is 1 message. The default is 512. Specify 0 to allow an unlimited number of messages to be queued (subject to available block memory).

Step 5

Click Add to add a new syslog server.

  1. In the IP Address drop-down list, select a network host object that contains the IP address of the syslog server.

  2. Choose the protocol (either TCP or UDP) and enter the port number for communications between the Firepower Threat Defense device and the syslog server.

    UDP is faster and uses less resources on the device than TCP.

    The default ports are 514 for UDP, 1470 for TCP. Valid non-default port values for either protocol are 1025 through 65535.

  3. Check the Log messages in Cisco EMBLEM format (UDP only) check box to specify whether to log messages in Cisco EMBLEM format (available only if UDP is selected as the protocol).

    Note

     

    Syslog messages in RFC5424 format, typically displays the priority value (PRI). However, in FMC, only when you enable logging in Cisco EMBLEM format, the PRI value in the syslog messages of the managed FTD is displayed. For more information on PRI, see RFC5424.

  4. Check the Enable Secure Syslog check box to encrypt the connection between the device and server using SSL/TLS over TCP.

  5. Add the zones that contain the interfaces used to communicate with the syslog server. For interfaces not in a zone, you can type the interface name into the field below the Selected Zones/Interface list and click Add. These rules will be applied to a device only if the device includes the selected interfaces or zones.

    Note

     

    If the syslog server is on the network attached to the physical Management interface, you must type the name of that interface into the Interface Name field below the Selected Security Zones list and click Add. You must also configure this name (if not already configured), and an IP address, for the Diagnostic interface (edit the device from the Device Management page and select the Interfaces tab). For more information about the management/diagnostic interface, see Diagnostic Interface.

  6. Click OK.

Step 6

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

What to do next

Configure Global Timeouts

You can set the global idle timeout durations for the connection and translation slots of various protocols. If the slot has not been used for the idle time specified, the resource is returned to the free pool.

You can also set a time out for console sessions with the device.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Timeouts.

Step 3

Configure the timeouts you want to change.

For any given setting, select Custom to define your own value, Default to return to the system default value. In most cases, the maximum timeout is 1193 hours.

You can disable some timeouts by selecting Disable.

  • Console Timeout—The idle time until a connection to the console is closed, range is 0 to 60 minutes. The default is 0, which means the session does not time out. If you change the value, existing console sessions use the old timeout value. The new value applies to new connections only.

  • Translation Slot (xlate)—The idle time until a NAT translation slot is freed. This duration must be at least 1 minute. The default is 3 hours.

  • Connection (Conn)—The idle time until a connection slot is freed. This duration must be at least 5 minutes. The default is 1 hour.

  • Half-Closed—The idle time until a TCP half-closed connection closes. A connection is considered half-closed if both the FIN and FIN-ACK have been seen. If only the FIN has been seen, the regular connection timeout applies. The minimum is 30 seconds. The default is 10 minutes.

  • UDP—The idle time until a UDP connection closes. This duration must be at least 1 minute. The default is 2 minutes.

  • ICMP—The idle time after which general ICMP states are closed. The default (and minimum) is 2 seconds.

  • RPC/Sun RPC—The idle time until a SunRPC slot is freed. This duration must be at least 1 minute. The default is 10 minutes.

  • H.225—The idle time until an H.225 signaling connection closes. The default is 1 hour. To close a connection immediately after all calls are cleared, a timeout of 1 second (0:0:1) is recommended.

  • H.323—The idle time after which H.245 (TCP) and H.323 (UDP) media connections close. The default (and minimum) is 5 minutes. Because the same connection flag is set on both H.245 and H.323 media connections, the H.245 (TCP) connection shares the idle timeout with the H.323 (RTP and RTCP) media connection.

  • SIP—The idle time until a SIP signaling port connection closes. This duration must be at least 5 minutes. The default is 30 minutes.

  • SIP Media—The idle time until a SIP media port connection closes. This duration must be at least 1 minute. The default is 2 minutes. The SIP media timer is used for SIP RTP/RTCP with SIP UDP media packets, instead of the UDP inactivity timeout.

  • SIP Disconnect—The idle time after which SIP session is deleted if the 200 OK is not received for a CANCEL or a BYE message, between 0:0:1 and 0:10:0. The default is 2 minutes (0:2:0).

  • SIP Invite—The idle time after which pinholes for PROVISIONAL responses and media xlates will be closed, between 0:1:0 and 00:30:0. The default is 3 minutes (0:3:0).

  • SIP Provisional Media—The timeout value for SIP provisional media connections, between 1 and 30 minutes. The default is 2 minutes.

  • Floating Connection—When multiple routes exist to a network with different metrics, the system uses the one with the best metric at the time of connection creation. If a better route becomes available, then this timeout lets connections be closed so a connection can be reestablished to use the better route. The default is 0 (the connection never times out). To make it possible to use better routes, set the timeout to a value between 0:0:30 and 1193:0:0.

  • Xlate PAT—The idle time until a PAT translation slot is freed, between 0:0:30 and 0:5:0. The default is 30 seconds. You may want to increase the timeout if upstream routers reject new connections using a freed PAT port because the previous connection might still be open on the upstream device.

  • TCP Proxy Reassembly—The idle timeout after which buffered packets waiting for reassembly are dropped, between 0:0:10 and 1193:0:0. The default is 1 minute (0:1:0).

  • ARP Timeout—(Transparent mode only.) The number of seconds between ARP table rebuilds, from 60 to 4294967. The default is 14,400 seconds (4 hours).

Step 4

Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.

Configure NTP Time Synchronization for Threat Defense

Use a Network Time Protocol (NTP) server to synchronize the clock settings on your devices. We recommend you configure all Firepower Threat Defenses managed by an FMC to use the same NTP server as the FMC. The Firepower Threat Defense gets its time directly from the configured NTP server. If the Firepower Threat Defense's configured NTP servers are not reachable for any reason, it synchronizes its time with the FMC.

The device supports NTPv4.


Note

If you are deploying Firepower Threat Defense on the Firepower 4100/9300 chassis, you must configure NTP on the Firepower 4100/9300 chassis so that Smart Licensing will work properly and to ensure proper timestamps on device registrations. You should use the same NTP server for the Firepower 4100/9300 chassis and the FMC.

Before you begin

  • If your organization has one or more NTP servers that your FTD can reach, use the same NTP server or servers for your devices that you have configured for Time Synchronization on the System > Configuration page on your FMC. Copy the specified value.

  • If your device cannot reach an NTP server or your organization does not have one, you must use the Via NTP from Defense Center option as discussed in the following procedure.

Procedure

Step 1

Select Devices > Platform Settings and create or edit the Firepower Threat Defense policy.

Step 2

Select Time Synchronization.

Step 3

Configure one of the following clock options:

  • Via NTP from Defense Center—(Default). The managed device gets time from the NTP servers you configured for the FMC (except for authenticated NTP servers) and synchronizes time with those servers directly. However, if any of the following are true, the managed device synchronizes time from the FMC:

    • The FMC’s NTP servers are not reachable by the device.

    • The FMC has no unauthenticated servers.

  • Via NTP from—If your FMC is using NTP servers on the network, select this option and enter the fully-qualified DNS name (such as ntp.example.com), or IPv4 or IPv6 address, of the same NTP servers you specified in System > Configuration > Time Synchronization. If the NTP servers are not reachable, the FMC acts as an NTP server.

Step 4

Click Save.

What to do next

History for Firepower Threat Defense Platform Settings

Feature

Version

Details
External Authentication for SSH and HTML removed 6.1.0

Due to changes to support converged management access, only local users are supported for SSH and HTML to data interfaces. Also, you can no longer SSH to the logical Diagnostic interface; instead you can SSH to the logical Management interface (which shares the same physical port). Previously, only external authentication was supported for SSH and HTML access to Diagnostic and data interfaces, while only local users were supported to the Management interface.

New/Modified screen:

Devices > Platform Settings > External Authentication

Supported platforms: Firepower Threat Defense

Firepower Threat Defense support

6.0.1

This feature was introduced.

New/Modified screen:

Devices > Platform Settings

Supported platforms: Firepower Threat Defense