Professional Documents
Culture Documents
2
First Published: 2017-09-05
Last Modified: 2017-09-11
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
CHAPTER 27 Transparent or Routed Firewall Mode for Firepower Threat Defense 549
About the Firewall Mode 549
About Routed Firewall Mode 549
About Transparent Firewall Mode 550
Using the Transparent Firewall in Your Network 550
Diagnostic Interface 551
CHAPTER 33 Firepower Threat Defense Cluster for the Firepower 9300 Chassis 683
About Clustering on the Firepower 9300 Chassis 683
Performance Scaling Factor 684
Bootstrap Configuration 684
Cluster Members 684
Primary and Secondary Unit Roles 684
Primary Unit Election 684
Cluster Interfaces 685
Connecting to a VSS or vPC 685
Cluster Control Link 685
Cluster Control Link Network 686
High Availability Within the Cluster 686
Chassis-Application Monitoring 686
Unit Health Monitoring 686
Interface Monitoring 686
CHAPTER 35 Static and Default Routes for Firepower Threat Defense 713
About Static and Default Routes 713
Default Route 713
Static Routes 713
Route to null0 Interface to “Black Hole” Unwanted Traffic 714
Route Priorities 714
Transparent Firewall Mode and Bridge Group Routes 714
Static Route Tracking 714
Guidelines for Static and Default Routes 715
Add a Static Route 715
CHAPTER 52 Network Address Translation (NAT) for Firepower Threat Defense 1023
Why Use NAT? 1023
NAT Basics 1024
NAT Terminology 1024
NAT Types 1024
NAT in Routed and Transparent Mode 1025
NAT in Routed Mode 1025
NAT in Transparent Mode or Within a Bridge Group 1026
Auto NAT and Manual NAT 1027
Auto NAT 1028
Manual NAT 1028
Comparing Auto NAT and Manual NAT 1028
NAT Rule Order 1029
NAT Interfaces 1031
Configuring Routing for NAT 1031
Addresses on the Same Network as the Mapped Interface 1032
Addresses on a Unique Network 1032
The Same Address as the Real Address (Identity NAT) 1032
Guidelines for NAT 1033
Firewall Mode Guidelines for NAT 1033
IPv6 NAT Guidelines 1033
IPv6 NAT Recommendations 1034
PART XIV 7000 and 8000 Series Advanced Deployment Options 1129
PART XVII Advanced Malware Protection (AMP) and File Control 1381
CHAPTER 72 File and Malware Inspection Performance and Storage Tuning 1411
About File and Malware Inspection Performance and Storage Tuning 1411
File and Malware Inspection Performance and Storage Options 1411
Tuning File and Malware Inspection Performance and Storage 1414
CHAPTER 83 Advanced Access Control Settings for Network Analysis and Intrusion Policies 1695
About Advanced Access Control Settings for Network Analysis and Intrusion Policies 1695
The Default Intrusion Policy 1695
Setting the Default Intrusion Policy 1696
Advanced Settings for Network Analysis Policies 1697
Setting the Default Network Analysis Policy 1698
Network Analysis Rules 1698
Configuring Network Analysis Rules 1699
Managing Network Analysis Rules 1699
gui 2485
hostname 2485
hosts 2486
hyperthreading 2486
inline-sets 2486
interfaces 2487
ifconfig 2487
lcd 2487
link-aggregation Commands 2488
configuration 2488
statistics 2488
link-state 2489
log-ips-connection 2489
managers 2489
memory 2490
model 2490
mpls-depth 2490
NAT Commands 2491
active-dynamic 2491
active-static 2491
allocators 2491
config 2492
dynamic-rules 2492
flows 2492
static-rules 2492
netstat 2493
network 2493
network-modules 2493
network-static-routes 2494
ntp 2494
perfstats 2494
portstats 2495
power-supply-status 2495
process-tree 2496
processes 2496
route 2496
routing-table 2497
serial-number 2497
ssl-policy-config 2497
stacking 2498
summary 2498
syslog 2499
time 2499
traffic-statistics 2499
user 2500
users 2500
version 2501
virtual-routers 2502
virtual-switches 2502
vmware-tools 2502
VPN Commands 2503
config 2503
config by virtual router 2503
status 2504
status by virtual router 2504
counters 2504
counters by virtual router 2504
Configuration Commands 2505
audit_cert Commands 2505
delete 2505
import 2505
bypass 2506
high-availability 2506
gui 2507
lcd 2507
log-ips-connections 2507
manager Commands 2508
add 2508
delete 2508
mpls-depth 2509
maxfailedlogins 2521
password 2521
strengthcheck 2521
unlock 2522
vmware-tools 2522
System Commands 2522
access-control Commands 2523
archive 2523
clear-rule-counts 2523
rollback 2523
compliance Commands 2524
enable cc 2524
enable ucapl 2524
show 2524
disable-http-user-cert 2525
file Commands 2525
copy 2525
delete 2526
list 2526
secure-copy 2526
generate-troubleshoot 2526
ldapsearch 2527
lockdown-sensor 2527
nat rollback 2528
reboot 2528
restart 2528
support Commands 2529
ssl-client-hello-display 2529
ssl-client-hello-enabled 2529
ssl-client-hello-force-reset 2531
ssl-client-hello-reset 2532
ssl-client-hello-tuning 2532
shutdown 2534
Managers provide a centralized management console with graphical user interface that you can use to perform
administrative, management, analysis, and reporting tasks.
This guide focuses on the Firepower Management Center managing appliance. For information about the
Firepower Device Manager or ASA with FirePOWER Services managed via ASDM, see the guides for those
management methods.
• Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager
• ASA with FirePOWER Services Local Management Configuration Guide
Procedure
Install and perform initial setup on all physical appliances using the documentation for your appliance:
• Firepower Management Center: Cisco Firepower Management Center Getting Started Guide
• 7000 Series managed device: Cisco Firepower 7000 Series Getting Started Guide
• 8000 Series managed device: Cisco Firepower 8000 Series Getting Started Guide
• ASA FirePOWER Services managed device: Cisco ASA FirePOWER Module Quick Start Guide
• Firepower Threat Defense for the ASA 5500-X: Cisco Firepower Threat Defense for the ASA 5512-X,
ASA 5515-X, ASA 5525-X, ASA 5545-X, and ASA 5555-X Using Firepower Management Center Quick
Start Guide
• Firepower Threat Defense for the ASA 5506-X: Cisco Firepower Threat Defense for the ASA 5506-X
Series Using Firepower Management Center Quick Start Guide
• Firepower Threat Defense for the ASA 5508-X/5516-X: Cisco Firepower Threat Defense for the ASA
5508-X and ASA 5516-X Using Firepower Management Center Quick Start Guide
• Firepower Threat Defense for the 4100: Cisco Firepower Threat Defense for Firepower 4100 Quick
Start Guide
• Firepower Threat Defense for the 9300: Cisco Firepower Threat Defense for Firepower 9300 Quick
Start Guide
• Firepower Threat Defense for the 2100: Cisco Firepower Threat Defense for the Firepower 2100 Series
Using Firepower Management Center Quick Start Guide
Procedure
Step 1 Deploy virtual Firepower Management Centers using the documentation for your environment:
• Firepower Management Center Virtual running on VMware: Cisco Firepower Management Center
Virtual for VMware Deployment Quick Start Guide
• Firepower Management Center Virtual running on AWS: Cisco Firepower Management Center Virtual
for AWS Deployment Quick Start Guide
• Firepower Management Center Virtual running on KVM: Cisco Firepower Management Center Virtual
for KVM Deployment Quick Start Guide
Step 2 Deploy virtual devices using the documentation for your appliance:
• NGIPSv running on VMware: Cisco Firepower NGIPSv Quick Start Guide for VMware
• Firepower Threat Defense Virtual running on VMware: Cisco Firepower Threat Defense for the ASA
5508-X and ASA 5516-X Using Firepower Management Center Quick Start Guide
• Firepower Threat Defense Virtual running on AWS: Cisco Firepower Threat Defense Virtual for AWS
Deployment Quick Start Guide
• Firepower Threat Defense Virtual running on KVM: Cisco Firepower Threat Defense Virtual for KVM
Deployment Quick Start Guide
• Firepower Threat Defense Virtual running on Azure: Cisco Firepower Threat Defense Virtual for Azure
Deployment Quick Start Guide
Procedure
Step 1 Log in to the Firepower Management Center web interface with admin as the username and Admin123 as the
password. Change the password for this account as described in the Quick Start Guide for your appliance.
Step 2 Set a time zone for this account as described in Setting Your Default Time Zone, on page 38.
Step 3 Add licenses as described in Licensing the Firepower System, on page 109.
Step 4 Register managed devices as described in Adding Devices to the Firepower Management Center, on page
473.
Step 5 Configure your managed devices as described in:
• Introduction to IPS Device Deployment and Configuration, on page 507, to configure passive or inline
interfaces on 7000 Series or 8000 Series devices
• About Firepower Threat Defense Interfaces, on page 561, to configure transparent or routed mode on
Firepower Threat Defense devices
• About Firepower Threat Defense Interfaces, on page 561, to configure interfaces on Firepower Threat
Defense devices
What to Do Next
• Begin controlling and analyzing traffic by configuring basic policies as described in Setting Up Basic
Policies and Configurations, on page 4.
Note This is not a full discussion of policy or feature capabilities. For guidance on other features and more
advanced configurations, see the rest of this guide.
Procedure
Step 1 Configure an access control policy as described in Creating a Basic Access Control Policy, on page 1220.
• In most cases, Cisco suggests setting the Balanced Security and Connectivity intrusion policy as your
default action. For more information, see Access Control Policy Default Action, on page 1216 and
System-Provided Network Analysis and Intrusion Policies, on page 1471.
• In most cases, Cisco suggests enabling connection logging to meet the security and compliance needs
of your organization. Consider the traffic on your network when deciding which connections to log so
that you do not clutter your displays or overwhelm your system. For more information, see About
Connection Logging, on page 2231.
Step 2 Apply the system-provided default health policy as described in Applying Health Policies, on page 232.
Step 3 Customize a few of your system configuration settings:
• If you want to allow inbound connections for a service (for example, SNMP or the syslog), modify the
ports in the access list as described in Configuring the Access List for Your System, on page 898.
• Understand and consider editing your database event limits as described in Configuring Database Event
Limits, on page 873.
• If you want to change the display language, edit the language setting as described in Specifying a Different
Language, on page 910.
• If your organization restricts network access using a proxy server and you did not configure proxy
settings during initial configuration, edit your proxy settings as described in Configure Firepower
Management Center Management Interfaces, on page 880.
Step 4 Customize your network discovery policy as described in Configuring the Network Discovery Policy, on
page 1932. By default, the network discovery policy analyzes all traffic on your network. In most cases, Cisco
suggests restricting discovery to the addresses in RFC 1918.
Step 5 Consider customizing these other common settings:
• If you do not want to display message center pop-ups, disable notifications as described in Configuring
Notification Behavior, on page 269.
• If you want to customize the default values for system variables, understand their use as described in
Variable Sets, on page 364.
• If you want to update the Geolocation Database, update manually or on a scheduled basis as described
in Geolocation Database Update, on page 158.
• If you want to create additional locally authenticated user accounts to access the appliance, see Creating
a User Account, on page 66.
• If you want to use LDAP or RADIUS external authentication to allow access to the appliance, see
External Authentication, on page 76.
Step 6 Deploy configuration changes; see Deploying Configuration Changes, on page 288.
What to Do Next
• Review and consider configuring other features described in Firepower System Features, on page 6
and the rest of this guide.
Firepower Devices
In a typical deployment, multiple traffic-handling devices installed on network segments monitor traffic for
analysis and report to either a physical or virtual Firepower Management Center. The Firepower Management
Center provides a centralized management console with graphical user interface that you can use to perform
administrative, management, analysis, and reporting tasks.
This section describes the Firepower implementations you can install on traffic-handling devices and manage
with the Firepower Management Center.
For details on manager-device compatibility, including the software compatible with specific device models,
virtual hosting environments, operating systems, and so on, see the Cisco Firepower Compatibility Guide,
available on the documentation roadmap: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
firepower-roadmap.html.
Blacklist or whitelist connections to or Security Intelligence within your About Security Intelligence, on
from IP addresses, URLs, and/or domain access control policy page 1257
names
Control the websites that users on your URL filtering within your policy URL Conditions (URL
network can access rules Filtering), on page 321
Monitor malicious traffic and intrusions an intrusion policy Intrusion Policy Basics, on page
on your network 1497
Rate limit network traffic that is allowed a Quality of Service (QoS) About QoS Policies, on page
or trusted by access control policy 613
Allow or block files (including malware) a file policy File Policies, on page 1389
on your network
Operationalize data from threat the Cisco Threat Intelligence Cisco Threat Intelligence
intelligence sources Director (TID) Director (TID) Overview, on
page 1417
Query a public or private cloud for a connection to the public AMP AMP Cloud Connections, on
continuous file analysis cloud or an AMP Private Cloud page 1400
(AMPv)
Configure passive or active user identity sources, realms, and About User Identity Sources,
authentication to perform user awareness identity policies on page 1913
and user control Introduction: Realms and
Identity Policies, on page 1957
Collect host, application, and user data Network Discovery policies Overview: Network Discovery
from traffic on your network to perform Policies, on page 1931
user awareness
Manage user accounts for logging in to internal and/or external Firepower System User
your appliances authentication Authentication, on page 74
Monitor the health of system hardware a health monitoring policy About Health Monitoring, on
and software page 223
Back up data on your appliance backup and restore Backup and Restore
Introduction, on page 161
Update your system to a new version of system updates Firepower System Software
the Firepower System Updates, on page 133
Firepower System Release Notes
Update the VDB, intrusion rule updates, Vulnerability Database (VDB) Vulnerability Database
or GeoDB on your appliance updates, intrusion rule updates, Updates, on page 147
or Geolocation Database Intrusion Rule Updates, on page
(GeoDB) updates 149
Geolocation Database Update,
on page 158
Apply licenses in order to take advantage Classic licensing or Smart About Firepower Feature
of license-controlled functionality licensing Licenses, on page 109
Ensure continuity of appliance operations managed device high About 7000 and 8000 Series
availability and/or Firepower Device High Availability, on
Management Center high page 521
availability About Firepower Threat
Defense High Availability, on
page 657
About Firepower Management
Center High Availability, on
page 457
Configure packet switching between two device switching Virtual Switches, on page 1131
or more networks Configure Bridge Group
Interfaces, on page 581
Establish a secure tunnel between Site-to-Site virtual private VPN Overview, on page 785
managed Firepower Threat Defense or network (VPN)
7000/8000 Series devices
Establish secure tunnels between remote Remote Access VPN VPN Overview, on page 785
users and managed Firepower Threat
Defense devices
Segment user access to managed devices, multitenancy using domains Introduction to Multitenancy
configurations, and events Using Domains, on page 279
View and manage appliance REST API and REST API REST API Preferences, on page
configuration using a REST API client explorer 926
Firepower REST API Quick
Start Guide
Stream event data from a Firepower eStreamer integration eStreamer Server Streaming, on
Management Center to a page 1869
custom-developed client application
Firepower System eStreamer
Integration Guide
Query database tables on a Firepower external database access External Database Access
Management Center using a third-party Settings, on page 871
client
Firepower System Database
Access Guide
Augment discovery data by importing host input Host Input Data, on page 1861
data from third-party sources
Firepower System Host Input
API Guide
Related Topics
About 7000 and 8000 Series Device High Availability, on page 521
About Firepower Threat Defense High Availability, on page 657
About Firepower Management Center High Availability, on page 457
You can find additional documentation related to the Firepower using the documentation roadmap: http://
www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-roadmap.html.
Related Topics
About Firepower Feature Licenses, on page 109
Users with custom roles may have permission sets that differ from those of the predefined roles. When a
predefined role is used to indicate access requirements for a procedure, a custom role with similar permissions
also has access. Some users with custom roles may use slightly different menu paths to reach configuration
pages. For example, users who have a custom role with only intrusion policy privileges access the network
analysis policy via the intrusion policy instead of the standard path through the access control policy.
For more information about user roles, see Predefined User Roles, on page 44 and Custom User Roles, on
page 45.
Note Because the system audits user activity based on user accounts, make sure that users log into the system
with the correct account.
Caution On all appliances, users with shell access (whether obtained through external authentication or through
using the CLI expert command) have sudoers privileges in the shell, which can present a security risk.
If you establish external authentication, make sure that you restrict the list of users with shell access
appropriately. Similarly, when granting CLI access privileges, restrict the list of users with Configuration
level access.
Caution We strongly recommend that you do not access Firepower appliances using the shell or CLI expert mode,
unless directed by Cisco TAC.
Different appliances support different types of user accounts, each with different capabilities.
Caution For system security reasons, Cisco strongly recommends that you not establish additional shell users on
the Firepower Management Center. If you accept that risk, you can use external authentication to grant
any user shell access to the Firepower Management Center.
The Firepower System supports external authentication for users logging into 7000 & 8000 Series devices.
NGIPSv Devices
NGIPSv devices support the following user account types: The Firepower System does not support external
authentication for users logging in to NGIPSv devices.
• A pre-defined admin account which can be used for all forms of access to the device.
• Custom user accounts, which admin users and users with Configuration access can create and manage.
• A pre-defined admin account which can be used for all forms of access to the device.
• Custom user accounts, which admin users and users with the administrator role can create and manage.
The Firepower System does not support external authentication for users logging into Firepower Threat
Defense devices.
The Firepower System does not support external authentication for users logging into ASA FirePOWER
devices. Accessing ASA devices via the ASA CLI and ASDM is described in the Cisco ASA Series General
Operations CLI Configuration Guide and the Cisco ASA Series General Operations ASDM Configuration
Guide.
Note You can use the Firepower Management Center to manage multiple devices and correlate data from those
devices. If you prefer to manage a single device directly, you can use Firepower Device Manager to manage
policies and device configuration on some Firepower Threat Defense devices and use Adaptive Security
Device Manager (ASDM) to manage the same functionality on ASA FirePOWER Services devices. Note
that, after you select a management tool for an appliance, you cannot switch to a different management
tool without losing the current configuration. The local web interface for 7000 & 8000 Series devices
provides limited system configuration functionality, but you cannot use it to manage policies; you must
manage those devices using the Firepower Management Center.
Firepower Threat
Defense and • Firepower Device Manager, • supported for • supported for
supported for Firepower predefined predefined admin
Firepower Threat
Threat Defense running on: admin user and user and custom user
Defense Virtual
devices custom user accounts
◦ASA 5506-X
accounts
• accessible by CLI
◦ASA 5506H-X
• accessible using users with
◦ASA 5506W-X an SSH Configuration
connection access using the
◦ASA 5508-X expert command
• can be used for
◦ASA 5516-X setup and • should be used only
◦ASA 5512-X troubleshooting for administration
directed by and troubleshooting
◦ASA 5515-X Cisco TAC directed by Cisco
◦ASA 5525-X TAC
◦ASA 5545-X
◦ASA 5555-X
Note For more information about managing ASA FirePOWER modules using ASDM, see the Cisco ASA Series
General Operations Configuration Guide.
• The menus and menu options listed at the top of the default home page are based on the privileges for
your user account. However, the links on the default home page include options that span the range of
user account privileges. If you click a link that requires different privileges from those granted to your
account, the system displays a warning message and logs the activity.
• Some processes that take a significant amount of time may cause your web browser to display a message
that a script has become unresponsive. If this occurs, make sure you allow the script to continue until it
finishes.
Related Topics
Specifying Your Home Page, on page 33
Session Timeout
By default, the Firepower System automatically logs you out of a session after 1 hour of inactivity, unless
you are otherwise configured to be exempt from session timeout.
Users with the Administrator role can change the session timeout interval for an appliance via the following
settings:
Appliance Setting
Firepower Management Center System > Configuration > Shell Timeout
7000 & 8000 Series devices Devices > Platform Settings > Shell Timeout
Related Topics
Configuring Session Timeouts, on page 918
Logging Into the Firepower Management Center via the Web Interface
Smart License Classic License Supported Devices Supported Domains Access
N/A Any Management Center Any Any
Users are restricted to a single active session. If you try to log in with a user account that already has an active
session, the system prompts you to terminate the other session or log in as a different user.
Procedure
Step 1 Direct your browser to https://hostname/, where hostname corresponds to the host name of the Firepower
Management Center.
Step 2 In the Username and Password fields, enter your user name and password. Pay attention to the following
guidelines:
• User names are not case-sensitive.
• In a multidomain deployment, prepend the user name with the domain where your user account was
created. You are not required to prepend any ancestor domains. For example, if your user account was
created in SubdomainB, which has an ancestor DomainA, enter your user name in the following format:
SubdomainB\username
• If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and
use that as your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222,
enter 1111222222. You must have already generated your SecurID PIN before you can log into the
Firepower System.
Related Topics
Session Timeout, on page 21
Users are restricted to a single active session. If you try to log in with a user account that already has an active
session, the system prompts you to terminate the other session or log in as a different user.
Procedure
Step 1 Direct your browser to https://hostname/, where hostname corresponds to the host name of the managed
device you want to access.
Step 2 In the Username and Password fields, enter your user name and password. Pay attention to the following
guidelines:
• User names are not case-sensitive.
• If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and
use that as your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222,
enter 1111222222. You must have already generated your SecurID PIN before you can log into the
Firepower System.
Related Topics
Session Timeout, on page 21
Caution Do not remove a CAC during an active browsing session. If you remove or replace a CAC during a session,
your web browser terminates the session and the system logs you out of the web interface.
Procedure
Related Topics
CAC Authentication, on page 78
Session Timeout, on page 21
Caution Do not remove a CAC during an active browsing session. If you remove or replace a CAC during a session,
your web browser terminates the session and the system logs you out of the web interface.
Procedure
Related Topics
CAC Authentication, on page 78
Session Timeout, on page 21
You can log directly into the command line interface on Classic managed devices (7000 & 8000 Series,
NGIPSv, and ASA FirePOWER).
Procedure
Step 1 Use SSH to connect to the hostname or IP address of the management interface. Alternatively, you can connect
to the console port.
Step 2 At the login as: command prompt, enter your user name and press Enter.
Step 3 At the Password: prompt, enter your password and press Enter.
If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use
that as your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, enter
1111222222. You must have already generated your SecurID PIN before you can log into the Firepower
System.
Step 4 At the CLI prompt, use any of the commands allowed by your level of command line access.
Logging Into the Command Line Interface on Firepower Threat Defense Devices
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat N/A CLI Basic
Defense Configuration
You can log directly into the command line interface on Firepower Threat Defense managed devices.
Procedure
Step 1 Connect to the Firepower Threat Defense CLI, either from the console port or using SSH.
You can SSH to the management interface of the Firepower Threat Defense device. You can also connect to
the address on a data interface if you open the interface for SSH connections. SSH access to data interfaces
is disabled by default. See Configure Secure Shell, on page 965 to allow SSH connections to specific data
interfaces.
You can directly connect to the Console port on the device. Use the console cable included with the device
to connect your PC to the console using a terminal emulator set for 9600 baud, 8 data bits, no parity, 1 stop
bit, no flow control. See the hardware guide for your device for more information about the console cable.
The initial CLI you access on the Console port differs by device type.
• ASA Series devices—The CLI on the Console port is the regular Firepower Threat Defense CLI.
• Firepower Series devices—The CLI on the Console port is FXOS. You can get to the Firepower Threat
Defense CLI using the connect ftd command. Use the FXOS CLI for chassis-level configuration and
troubleshooting only. Use the Firepower Threat Defense CLI for basic configuration, monitoring, and
normal system troubleshooting. See the FXOS documentation for information on FXOS commands.
Example:
> system support diagnostic-cli
firepower> enable
Password:
firepower#
The About page displays information about your appliance, including the model, serial number, and version
information for various components of the Firepower System. It also includes Cisco copyright information.
Procedure
In a multidomain deployment, user role privileges determine which domains a user can access and which
privileges the user has within each of those domains. You can associate a single user account with multiple
domains and assign different privileges for that user in each domain. For example, you can assign a user
read-only privileges in the Global domain, but Administrator privileges in a descendant domain.
Users associated with multiple domains can switch between domains within the same web interface session.
Under your user name in the toolbar, the system displays a tree of available domains. The tree:
• Displays ancestor domains, but may disable access to them based on the privileges assigned to your user
account.
• Hides any other domain your user account cannot access, including sibling and descendant domains.
Procedure
From the drop-down list under your user name, choose the domain you want to access.
When you are no longer actively using a Firepower System web interface, Cisco recommends that you log
out, even if you are only stepping away from your web browser for a short period of time. Logging out ends
your web session and ensures that no one can use the interface with your credentials.
Procedure
From the drop-down list under your user name, choose Logout.
Related Topics
Session Timeout, on page 21
On pages or locations that do not support the Firepower System context menu, the normal context menu for
your browser appears.
Policy Editors
Many policy editors contain hotspots over each rule. You can insert new rules and categories; cut, copy,
and paste rules; set the rule state; and edit the rule.
Event Viewer
Event pages (drill-down pages and table views) contain hotspots over each event, IP address, URL,
DNS query, and certain files’ SHA-256 hash values. While viewing most event types, you can:
• View related information in the Context Explorer.
• Drill down into event information in a new window.
• View the full text in places where an event field contains text too long to fully display in the event
view, such as a file’s SHA-256 hash value, a vulnerability description, or a URL.
While viewing connection events, you can add items to the default Security Intelligence whitelists and
blacklists:
• An IP address, from an IP address hotspot.
• A URL or domain name, from a URL hotspot.
• A DNS query, from a DNS query hotspot.
While viewing captured files, file events, and malware events, you can:
• Add a file to or remove a file from the clean list or custom detection list.
• Download a copy of the file.
• View nested files inside an archive file.
• Download the parent archive file for a nested file.
• View the file composition.
• Submit the file for local malware and dynamic analysis.
While viewing intrusion events, you can perform similar tasks to those in the intrusion rules editor or
an intrusion policy:
• Edit the triggering rule.
• Set the rule state, including disabling the rule.
• Configure thresholding and suppression options.
• View rule documentation.
Dashboard
Many dashboard widgets contain hotspots to view related information in the Context Explorer. Dashboard
widgets can also contain IP address and SHA-256 hash value hotspots.
Context Explorer
The Context Explorer contains hotspots over its charts, tables, and graphs. If you want to examine data
from graphs or lists in more detail than the Context Explorer allows, you can drill down to the table
views of the relevant data. You can also view related host, user, application, file, and intrusion rule
information.
The Context Explorer uses a left-click context menu, which also contains filtering and other options
unique to the Context Explorer.
Related Topics
Security Intelligence Lists and Feeds, on page 381
All user accounts are protected with a password. You can change your password at any time, and depending
on the settings for your user account, you may have to change your password periodically.
If password strength checking is enabled, passwords must be at least eight alphanumeric characters of mixed
case and must include at least one numeric character. Passwords cannot be a word that appears in a dictionary
or include consecutive repeating characters.
If you are an LDAP or a RADIUS user, you cannot change your password through the web interface.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Enter your Current Password, and click Change.
Step 3 In the New Password and Confirm fields, enter your new password.
Step 4 Click Change.
Depending on the settings for your user account, your password may expire. Note that the password expiration
time period is set when your account is created and cannot be changed. If your password has expired, the
Password Expiration Warning page appears.
Procedure
You can specify a page within the web interface as your home page for the appliance. The default home page
is the Summary Dashboard (Overview > Dashboards), except for user accounts with no dashboard access.
In a multidomain deployment, the home page you choose applies to all domains where your user account has
access. When choosing a home page for an account that frequently accesses multiple domains, keep in mind
that certain pages are constrained to the Global domain.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Home Page.
Step 3 Choose the page you want to use as your home page from the drop-down list.
The options in the drop-down list are based on the access privileges for your user account. For more information,
see User Account Privileges, on page 47.
Use the Event View Settings page to configure characteristics of event views on the Firepower Management
Center. Note that some event view configurations are available only for specific user roles. Users with the
External Database User role can view parts of the event view settings user interface, but changing those settings
has no meaningful result.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Event View Settings.
Step 3 In the Event Preferences section, configure the basic characteristics of event views; see Event View
Preferences, on page 34.
Step 4 In the File Preferences section, configure file download preferences; see File Download Preferences, on
page 35.
Step 5 In the Default Time Windows section, configure the default time window or windows; see Default Time
Windows, on page 36.
Step 6 In the Default Workflow sections, configure default workflows; see Default Workflows, on page 37.
Step 7 Click Save.
• The Expand Packet View field allows you to configure how the packet view for intrusion events appears.
By default, the appliance displays a collapsed version of the packet view:
◦None - collapse all subsections of the Packet Information section of the packet view
◦Packet Text - expand only the Packet Text subsection
◦Packet Bytes - expand only the Packet Bytes subsection
◦All - expand all sections
Regardless of the default setting, you can always manually expand the sections in the packet view to view
detailed information about a captured packet.
• The Rows Per Page field controls how many rows of events per page you want to appear in drill-down
pages and table views.
• The Refresh Interval field sets the refresh interval for event views in minutes. Entering 0 disables the
refresh option. Note that this interval does not apply to dashboards.
• The Statistics Refresh Interval controls the refresh interval for event summary pages such as the
Intrusion Event Statistics and Discovery Statistics pages. Entering 0 disables the refresh option. Note
that this interval does not apply to dashboards.
• The Deactivate Rules field controls which links appear on the packet view of intrusion events generated
by standard text rules:
◦All Policies - a single link that deactivates the standard text rule in all the locally defined custom
intrusion policies
◦Current Policy - a single link that deactivates the standard text rule in only the currently deployed
intrusion policy. Note that you cannot deactivate rules in the default policies.
◦Ask - links for each of these options
To see these links on the packet view, your user account must have either Administrator or Intrusion Admin
access.
Related Topics
Management Interfaces, on page 875
Caution Cisco strongly recommends you do not download malware, as it can cause adverse
consequences. Exercise caution when downloading any file, as it may contain malware.
Ensure you have taken any necessary precautions to secure the download destination
before downloading files.
Note that you can disable this option any time you download a file.
• When you download a captured file, the system creates a password-protected .zip archive containing
the file. The Zip File Password field defines the password you want to use to restrict access to the .zip
file. If you leave this field blank, the system creates archive files without passwords.
• The Show Zip File Password check box toggles displaying plain text or obfuscated characters in the
Zip File Password field. When this field is cleared, the Zip File Password displays obfuscated characters.
Note that, regardless of the default time window setting, you can always manually change the time window
for individual event views during your event analysis. Also, keep in mind that time window settings are valid
for only the current session. When you log out and then log back in, time windows are reset to the defaults
you configured on this page.
There are three types of events for which you can set the default time window:
• The Events Time Window sets a single default time window for most events that can be constrained
by time.
• The Audit Log Time Window sets the default time window for the audit log.
• The Health Monitoring Time Window sets the default time window for health events.
You can only set time windows for event types your user account can access. All user types can set event
time windows. Administrators, Maintenance Users, and Security Analysts can set health monitoring time
windows. Administrators and Maintenance Users can set audit log time windows.
Note that because not all event views can be constrained by time, time window settings have no effect on
event views that display hosts, host attributes, applications, clients, vulnerabilities, user identity, or white list
violations.
You can either use Multiple time windows, one for each of these types of events, or you can use a Single
time window that applies to all events. If you use a single time window, the settings for the three types of
time window disappear and a new Global Time Window setting appears.
There are three types of time window:
• static, which displays all the events generated from a specific start time to a specific end time
• expanding, which displays all the events generated from a specific start time to the present; as time
moves forward, the time window expands and new events are added to the event view
• sliding, which displays all the events generated from a specific start time (for example, one day ago) to
the present; as time moves forward, the time window “slides” so that you see only the events for the
range you configured (in this example, for the last day)
The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM
on January 19, 2038 (UTC).
The following options appear in the Time Window Settings drop-down list:
• The Show the Last - Sliding option allows you configure a sliding default time window of the length
you specify.
The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to
the present. As you change event views, the time window “slides” so that you always see events from
the last hour.
• The Show the Last - Static/Expanding option allows you to configure either a static or expanding
default time window of the length you specify.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from a specific start time (for example, 1 hour ago) to the time when you first viewed the
events. As you change event views, the time window stays fixed so that you see only the events that
occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from a specific start time (for example, 1 hour ago) to the present. As you change event
views, the time window expands to the present time.
• The Current Day - Static/Expanding option allows you to configure either a static or expanding default
time window for the current day. The current day begins at midnight, based on the time zone setting for
your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight to the present. As you change event views, the time window expands
to the present time. Note that if your analysis continues for over 24 hours before you log out, this time
window can be more than 24 hours.
• The Current Week - Static/Expanding option allows you to configure either a static or expanding
default time window for the current week. The current week begins at midnight on the previous Sunday,
based on the time zone setting for your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight Sunday to the present. As you change event views, the time window
expands to the present time. Note that if your analysis continues for over 1 week before you log out,
this time window can be more than 1 week.
Default Workflows
A workflow is a series of pages displaying data that analysts use to evaluate events. For each event type, the
appliance ships with at least one predefined workflow. For example, as a Security Analyst, depending on the
type of analysis you are performing, you can choose among ten different intrusion event workflows, each of
which presents intrusion event data in a different way.
The appliance is configured with a default workflow for each event type. For example, the Events by Priority
and Classification workflow is the default for intrusion events. This means whenever you view intrusion
events (including reviewed intrusion events), the appliance displays the Events by Priority and Classification
workflow.
You can, however, change the default workflow for each event type. The default workflows you are able to
configure depend on your user role. For example, intrusion event analysts cannot set default discovery event
workflows.
You can change the time zone used to display events from the standard UTC time that the appliance uses.
When you configure a time zone, it applies only to your user account and is in effect until you make further
changes to the time zone.
Caution The Time Zone function assumes that the default system clock is set to UTC time. If you have changed
the system clock on the appliance to use a local time zone, you must change it back to UTC time in order
to view accurate local time on the appliance.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click the Time Zone Preference tab.
Step 3 From the left list box, choose the continent or area that contains the time zone you want to use.
Step 4 From the right list box, choose the zone (city name) that corresponds with the time zone you want to use.
Step 5 Click Save.
The default dashboard appears when you choose Overview > Dashboards. Unless changed, the default
dashboard for all users is the Summary dashboard.
In a multidomain deployment, the default dashboard you choose applies to all domains where your user
account has access. When choosing a dashboard for an account that frequently accesses multiple domains,
keep in mind that certain dashboard widgets are constrained by domain.
Procedure
Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Dashboard Settings.
Step 3 Choose the dashboard you want to use as your default from the drop-down list. If you choose None, when
you select Overview > Dashboards, you can then choose a dashboard to view.
Step 4 Click Save.
Related Topics
Viewing Dashboards, on page 221
User Roles
The Firepower System lets you allocate user privileges based on the user’s role. For example, you can grant
analysts predefined roles such as Security Analyst and Discovery Admin and reserve the Administrator role
for the security administrator managing the Firepower System. You can also create custom user roles with
access privileges tailored to your organization’s needs.
In the platform settings policy for a managed device, you set a default access role for all users from that device
who are externally authenticated. After an externally authenticated user logs in for the first time, you can add
or remove access rights for that user on the User Management page. If you do not modify the user’s rights,
the user has only the rights granted by default. Because you create internally authenticated users manually,
you set the access rights when you create them.
If you configured management of access rights through LDAP groups, the access rights for users are based
on their membership in LDAP groups. They receive the default access rights for the group that they belong
to that has the highest level of access. If they do not belong to any groups and you have configured group
access, they receive the default user access rights configured in the authentication object for the LDAP server.
If you configure group access, those settings override the default access setting in the platform settings policy.
Similarly, if you assign a user to specific user role lists in a RADIUS authentication object, the user receives
all assigned roles, unless one or more of those roles are mutually incompatible. If a user is on the lists for two
mutually incompatible roles, the user receives the role that has the highest level of access. If the user does not
belong to any lists and you have configured a default access role in the authentication object, the user receives
that role. If you configure default access in the authentication object, those settings override the default access
setting in the platform settings policy.
In a multidomain deployment, you can assign users roles in multiple domains. For example, you can assign
a user read-only privileges in the Global domain, but Administrator privileges in a subdomain.
Administrator
Provides access to analysis and reporting features, rule and policy configuration, system management,
and all maintenance features. Administrators can also deploy configuration changes, including policies,
to devices. Administrators have access to all menu options; their sessions present a higher security risk
if compromised, so you cannot make them exempt from login session timeouts.
You should limit use of the Administrator role for security reasons.
Discovery Admin
Provides access to network discovery, application detection, and correlation features in the Policies
menu. Discovery Admins cannot deploy policies.
Intrusion Admin
Provides access to all intrusion policy, intrusion rule, and network analysis policy features in the Policies
and Objects menus. Intrusion Admins cannot deploy policies.
Maintenance User
Provides access to monitoring and maintenance features. Maintenance Users have access to
maintenance-related options in the Health and System menus.
Network Admin
Provides access to access control, SSL inspection, DNS policy, and identity policy features in the
Policies menu, as well as device configuration features in the Devices menus. Network Admins can
deploy configuration changes to devices.
Security Analyst
Provides access to security event analysis features, and read-only access to health events, in the
Overview, Analysis, Health, and System menus.
Security Approver
Provides limited access to access control and associated policies and network discovery policies in the
Policies menu. Security Approvers can view and deploy these policies, but cannot make policy changes.
Externally authenticated users, if assigned no other roles, have minimum access rights based on the settings
in LDAP or RADIUS authentication objects and in platform settings. You can assign additional rights to these
users, but to remove or change minimum access rights, you must perform the following tasks:
• Move the user from one list to another in the authentication object or change the user's attribute value
or group membership on the external authentication server.
• Update platform settings.
• Use the User Management page to remove the access from that user account.
Related Topics
User Account Privileges, on page 47
Tip For pages or features not included in the menu structure, privileges are granted by parent or related pages.
For example, the Modify Intrusion Policy privilege also allows you to modify network analysis policies.
You can apply restricted searches to a custom user role. These constrain the data a user may see in the event
viewer. You can configure a restricted search by first creating a private saved search and selecting it from the
Restricted Search drop-down menu under the appropriate menu-based permission.
When you configure a custom user role on a Firepower Management Center, all menu-based permissions are
available for you to grant. When you configure a custom user role on a managed device, only some permissions
are available — those relevant to device functions.
The selectable options under System Permissions allow you to create a user role that can make queries to the
external database or escalate to the permissions of a target user role.
Optionally, instead of creating a new custom user role, you can export a custom user role from another
appliance, then import it onto your appliance. You can then edit the imported role to suit your needs before
you apply it.
Related Topics
User Account Privileges, on page 47
External Database Access Settings, on page 871
Custom Role Permission Example: Access Example: Intrusion & Example: Policy Approver
Control Editor Network Analysis Editor
Access Control yes no yes
Overview Menu
The following table lists, in order, the user role privileges required to access each option in the Overview
menu and whether the user role has access to the sub-permissions within. The Security Approver, Discovery
Admin, Intrusion Admin, Access Admin, Network Admin, and External Database User roles have no
permissions in the Overview menu.
Appliance Status Widget (Management Center only) yes yes yes yes
White List Events Widget (Management Center only) yes no yes yes
Analysis Menu
The following table lists, in order, the user role privileges required to access each option in the Analysis menu
and whether the user role has access to the sub-permissions within. Permissions that appear multiple times
under different headings will be listed on the table only where they first appear, except to indicate submenu
headings. The Security Approver, Intrusion Admin, Access Admin, Network Admin, and External Database
User roles have no permissions in the Analysis menu. The Analysis menu is only available on the Firepower
Management Center.
Policies Menu
The following table lists, in order, the user role privileges required to access each option in the Policies menu
and whether the user roles has access to the sub-permissions within. The External Database User, Maintenance
User, Security Analyst, and Security Analyst (Read Only) roles have no permissions in the Policies menu.
The Policies menu is only available on the Firepower Management Center.
Note that the Intrusion Policy and Modify Intrusion Policy privileges also allow you to create and modify
network analysis policies.
Correlation no yes no no no no
no yes yes no no no
Modify Rule Management
White List no yes no no no no
Groups no yes no no no no
Modules no yes no no no no
Instances no yes no no no no
Devices Menu
The Devices menu table lists, in order, the user role privileges required to access each option in the Devices
menu and the sub-permissions within. The Discovery Admin, External Database User, Intrusion Admin,
Maintenance User, Security Analyst, and Security Analyst (Read Only) have no permissions in the Devices
menu. The Devices menu is only available on the Firepower Management Center.
Security
Menu Access Admin Admin Network Admin Approver
Device Management no yes yes yes
Security
Menu Access Admin Admin Network Admin Approver
Modify FlexConfig Policy no yes no no
Cisco AMP
The Cisco AMP permission is available only to the Administrator user role. This permission is available only
on the Firepower Management Center.
Intelligence Menu
The Intelligence permission contains the user role privileges required to access the Intelligence menus for
TID configuration and analysis.
The Intelligence permission is available to the Administrator user role and the Threat Intelligence Director
(TID) User user role. It is available only on the Firepower Management Center.
System Menu
The following table lists, in order, the user role privileges required to access each option in the System menu
and whether the user role has access to the sub-permissions within. The External Database User role has no
permissions in the System Menu.
Menu Access Admin Discovery Intrusion Maint Network Security Security Security
Admin Admin Admin User Admin Approver Analyst Analyst
(RO)
Configuration no yes no no no no no no no
Domains no yes no no no no no no no
eStreamer no yes no no no no no no no
Users no yes no no no no no no no
Menu Access Admin Discovery Intrusion Maint Network Security Security Security
Admin Admin Admin User Admin Approver Analyst Analyst
(RO)
Updates no yes no no no no no no no
Licenses no yes no no no no no no no
Menu Access Admin Discovery Intrusion Maint Network Security Security Security
Admin Admin Admin User Admin Approver Analyst Analyst
(RO)
Restore Backup no yes no no yes no no no no
Import/Export no yes no no no no no no no
Help Menu
The Help menu and its permissions are accessible to all user roles. You cannot restrict Help menu options.
Each Firepower System user is associated with a user access role or roles. These user roles are assigned
permissions that determine access to menus and other options in the system. For example, an analyst needs
access to event data to analyze the security of your network, but might not require access to administrative
functions for the Firepower System itself. You can grant Security Analyst access to analysts while reserving
the Administrator role for the user or users managing the Firepower System.
The Firepower System includes ten predefined user roles designed for a variety of administrators and analysts.
These predefined user roles have a set of predetermined access privileges.
You can also create custom user roles with more granular access privileges.
You can also restrict the data that a user role can view in the event viewer by applying a restricted search to
that role. To create a custom role with restricted access, you must choose the tables you want to restrict from
the Menu Based Permissions list, then choose private saved searches from the Restrictive Search drop-down
lists.
You cannot delete predefined user roles, but you can delete custom roles that are no longer necessary. If you
want to disable a custom role without removing it entirely, you can deactivate it instead. Note that you cannot
delete your own user role or a role that is set as a default user role in a platform settings policy.
Procedure
You cannot delete predefined user roles, but you can deactivate them. Deactivating a role removes that role
and all associated permissions from any user who is assigned that role.
In a multidomain deployment, the system displays custom user roles created in the current domain, which
you can edit. It also displays custom user roles created in ancestor domains, which you cannot edit. To view
and edit custom user roles in a lower domain, switch to that domain.
Caution If a deactivated role is the only role assigned to a given user, that user can log in and access the User
Preferences menu, but is otherwise unable to access the Firepower System.
Procedure
Procedure
Step 7 Optionally, set database access permissions for the new role by checking or unchecking the External Database
Access checkbox.
Step 8 Optionally, on Firepower Management Centers, set escalation permissions for the new user role as described
in Configuring a Custom User Role for Escalation, on page 64.
Step 9 Click Save.
You can copy an existing role to use as the basis for a new custom role. This preselects the existing role’s
permissions in the User Role Editor so you can model one role on another.
You can copy any existing role, including predefined user roles and custom user roles inherited from ancestor
domains.
Procedure
Step 6 Optionally, modify the menu-based permissions inherited from the original user role.
When you choose a permission, all of its children are chosen, and the multi-value permissions use the first
value. If you clear a high-level permission, all of its children are cleared also. If you choose a permission but
not its children, the permission appears in italic text.
Step 7 Optionally, set the database access permissions for the new role by checking or unchecking the External
Database Access checkbox.
Step 8 Optionally, set escalation permissions for the new user role as described in Configuring a Custom User Role
for Escalation, on page 64.
Step 9 Click Save.
Procedure
Step 6 Optionally, set the database access permissions for the role by checking or unchecking the External Database
Access checkbox.
Step 7 Optionally, on Firepower Management Centers, set escalation permissions for the user role as described in
Configuring a Custom User Role for Escalation, on page 64.
Step 8 Click Save.
You can assign any of your user roles, predefined or custom, to act as the system-wide escalation target role.
This is the role to which any other role may escalate, if it has the ability.
Procedure
Consider the needs of your organization when you configure the escalation password for a custom role. If
you want to easily manage many escalating users, you may want to choose another user whose password
serves as the escalation password. If you change that user’s password or deactivate that user, all escalating
users who require that password are affected. This allows you to manage user role escalation more efficiently,
especially if you choose an externally authenticated user that you can manage centrally.
Procedure
Step 1 Begin configuring your custom user role as described in Creating Custom User Roles, on page 61.
Step 2 In System Permissions, choose the Set this role to escalate to: check box.
The current escalation target role is listed beside the check box.
Step 3 Choose the password that this role uses to escalate. You have two options:
• If you want users with this role to use their own passwords when they escalate, choose Authenticate
with the assigned user’s password.
• If you want users with this role to use the password of another user, choose Authenticate with the
specified user’s password and enter that username.
Note When authenticating with another user’s password, you can enter any username, even that of a
deactivated or nonexistent user. Deactivating the user whose password is used for escalation
makes escalation impossible for users with the role that requires it. You can use this feature to
quickly remove escalation powers if necessary.
When a user has an assigned custom user role with permission to escalate, that user may escalate to the target
role’s permissions at any time. Note that escalation has no effect on user preferences.
Procedure
Step 1 From the drop-down list under your user name, choose Escalate Permissions.
Step 2 Enter the authentication password.
Step 3 Click Escalate. You now have all permissions of the escalation target role in addition to your current role.
Note Escalation lasts for the remainder of your login session. To return to the privileges of your base role
only, you must log out, then begin a new session.
User Accounts
The admin account and optional, custom user accounts on a Firepower Management Center or Firepower
7000 and 8000 Series device allow users to log into these. For internally-authenticated users, accounts must
be created manually. For externally-authenticated users, accounts are created automatically.
For Firepower Threat Defense, you can create separate CLI users. These users can access the device through
SSH to do additional troubleshooting and system monitoring. However, you must create these users in the
CLI, you cannot create them in Firepower Management Center.
Related Topics
Firepower System User Accounts
Firepower System User Interfaces
Procedure
Related Topics
Lights-Out Management User Access Configuration, on page 921
Predefined User Roles, on page 44
Custom User Roles, on page 45
When you set up a new user account, you can control which parts of the system the account can access. You
can set password expiration and strength settings for the user account during creation. For a local account on
a 7000 or 8000 Series device, you can also configure the level of command line access the user will have.
In a multidomain deployment, you can create user accounts in any domain in which you have been assigned
Admin access. You can also create accounts in a higher-level domain and assign the users lower-level access
only. For example, you might want a single user to be an administrator of two domains, but deny them access
to the ancestor domain. This kind of user account can only be modified by switching to a subdomain in which
access is assigned.
Procedure
Step 6 If you are creating a user account on a 7000 or 8000 Series device, assign the appropriate level of
Command-Line Interface Access as described in Command Line Access Levels, on page 71.
Step 7 Assign user roles:
• Check or uncheck the check box next to the user role(s) you want to assign the user.
• In a multidomain deployment, if you are adding a user account to a domain with descendant domains,
click the Add Domains button that displays instead of the user role check boxes. Continue as described
in Assigning User Roles in Multiple Domains, on page 68.
Note User roles determine the user's access rights. For more information, see Managing User Roles, on
page 59.
Step 8 Click Save.
After adding user accounts to the system, you can modify access privileges, account options, or passwords at
any time. Note that password management options do not apply to users who authenticate to an external
directory server. You manage those settings on the external server. However, you must configure access rights
for all accounts, including those that are externally authenticated.
Note For externally authenticated users, you cannot remove the minimum access rights through the Firepower
System user management page for users assigned an access role because of LDAP group or RADIUS list
membership or attribute values. You can, however, assign additional rights. When you modify the access
rights for an externally authenticated user, the Authentication Method column on the User Management
page provides a status of External - Locally Modified.
If you change the authentication for a user from externally authenticated to internally authenticated, you must
supply a new password for the user.
Procedure
In a multidomain deployment, you can assign users roles in ancestor and descendant domains. For example,
you can assign a user read-only privileges in the Global domain, but Admin privileges in a descendant domain.
Procedure
Note When you convert a user from internal to external authentication, the user account retains the permissions
already present in that account. The existing permissions override any permissions associated with the
associated authentication object group or the default user role set in the platform settings policy.
Procedure
Step 1 Enable LDAP (with or without CAC) or RADIUS authentication. For more information, see LDAP
Authentication, on page 76 or RADIUS Authentication, on page 98.
Step 2 Instruct the user to log in with the password stored for that user on the external server.
Note • Password management options do not apply to users who authenticate to an external directory server.
You manage those settings on the external authentication server. After you enable Use External
Authentication Method, the system removes password management options from the display.
• If you enable security certifications compliance or Lights-Out Management (LOM) on an appliance,
different password restrictions apply. For more information on security certifications compliance,
see Security Certifications Compliance, on page 989 .
Option Description
Use External Authentication Method Select this check box if you want this user's credentials to be externally authenticated. If you
enable this option, the password management options are no longer displayed.
Note • For users to authenticate to an external directory server, you must also create
an authentication object for the server you want to use, and deploy a platform
settings policy with authentication enabled.
• Note that for externally authenticated users, if the authentication object for the
server is disabled, the Authentication Method column in the Users list displays
External (Disabled).
• If you select this option for the user and the external authentication server is
unavailable, that user can log into the web interface but cannot access any
functionality.
Maximum Number of Failed Logins Enter an integer, without spaces, that determines the maximum number of times each user can
try to log in after a failed login attempt before the account is locked. The default setting is five
tries; use 0 to allow an unlimited number of failed logins. The admin account is exempt from
being locked out after a maximum number of failed logins unless you have enabled security
certification compliance.
Minimum Password Length Enter an integer, without spaces, that determines the minimum required length, in characters,
of a user’s password. The default setting is 8. A value of 0 indicates that no minimum length
is required.
If you enable the Check Password Strength option, and set a value for Minimum Password
Length that exceeds 8 characters, the higher value applies.
Days Until Password Expiration Enter the number of days after which the user’s password expires. The default setting is 0,
which indicates that the password never expires. If you set this option, the Password Lifetime
column of the Users list indicates the days remaining on each user’s password.
Days Before Password Expiration Enter the number of warning days users have to change their password before their password
Warning actually expires. The default setting is 0 days.
Note The number of warning days must be less than the number of days before the password
expires.
Force Password Reset on Login Select this option to force users to change their passwords the next time they log in.
Check Password Strength Select this option to require strong passwords. A strong password must be at least eight
alphanumeric characters of mixed case and must include at least one numeric character and
one special character. It cannot be a word that appears in a dictionary or include consecutive
repeating characters.
Exempt from Browser Session Select this option if you do not want a user’s login sessions to terminate due to inactivity.
Timeout Users with the Administrator role cannot be made exempt.
Configuration
The user can access any of the command line options. Exercise caution in assigning this level of access
to users.
Caution Command line access granted to externally authenticated users defaults to the
Configuration level of command line access, granting rights to all command
line utilities.
Basic
A specific set of commands can be run by the user, listed below.
end lcd
exit link-state
help log-ips-connection
history managers
logout memory
? model
?? mpls-depth
access-control-config NAT
alarms network
arp-tables network-modules
audit-log ntp
bypass perfstats
high-availability portstats
cpu power-supply-status
database process-tree
device-settings processes
disk routing-table
disk-manager serial-number
dns stacking
expert summary
fan-status time
fastpath-rules traffic-statistics
gui version
hostname virtual-routers
hyperthreading virtual-switches
inline-sets
Procedure
Step 1 Log into the device CLI using an account with config privileges.
The admin user account has the required privileges, but any account with config privileges will work. You
can use an SSH session or the Console port.
For certain device models, the Console port puts you into the FXOS CLI. Use the connect ftd command to
get to the Firepower Threat Defense CLI.
Example:
The following example adds a user account named joecool with config access rights. The password is not
shown as you type it.
Note Tell users they can change their passwords using the configure password command.
Step 3 (Optional.) Adjust the characteristics of the account to meet your security requirements.
You can use the following commands to change the default account behavior.
• configure user aging username max_days warn_days
Sets an expiration date for the user's password. Specify the maximum number of days for the password
to be valid followed by the number of days before expiration the user will be warned about the upcoming
expiration. Both values are 1 to 9999, but the warning days must be less than the maximum days. When
you create the account, there is no expiration date for the password.
• configure user forcereset username
Forces the user to change the password on the next login.
• configure user maxfailedlogins username number
Sets the maximum number of consecutive failed logins you will allow before locking the account, from
1 to 9999. Use the configure user unlock command to unlock accounts. The default for new accounts
is 5 consecutive failed logins.
• configure user minpasswdlen username number
Sets a minimum password length, which can be from 1 to 127.
• configure user strengthcheck username {enable | disable}
Enables or disables password strength checking, which requires a user to meet specific password criteria
when changing their password. When a user’s password expires or if the configure user forcereset
command is used, this requirement is automatically enabled the next time the user logs in.
When you create a user account, you specify either internal or external authentication for that user.
Internal Authentication
In internal authentication, user credentials are verified against records in the internal Firepower System
database. This is the default authentication type.
You set the access rights for internal authentication users when you create the user's account.
Note When an internally authenticated user is converted to external authentication, you cannot revert to internal
authentication.
External Authentication
In external authentication, the Firepower Management Center or managed device retrieves user credentials
from a repository on an external server. External servers can be either a Lightweight Directory Access Protocol
(LDAP) directory server or a Remote Authentication Dial In User Service (RADIUS) authentication server.
You enable external authentication via the platform settings policy and settings in individual user accounts.
You can only use one form of external authentication for an appliance.
When the user logs into an appliance for the first time, the appliance associates the external credentials with
a set of permissions by creating a local user record. The user is assigned permissions based on either:
• the group or access list they belong to
• the default user access role you set in the platform settings policy for the appliance
If permissions are granted through group or list membership, they cannot be modified. However, if they are
assigned by default user role, you can modify them in the user account, and the modifications you make
override the default settings. For example:
• If the default role for externally authenticated user accounts is set to a specific access role, users can log
into the appliance using their external account credentials without any additional configuration by the
system administrator.
• If an account is externally authenticated and by default receives no access privileges, users can log in
but cannot access any functionality. You (or your system administrator) can then change the permissions
to grant the appropriate access to user functionality.
You cannot manage passwords for externally authenticated users or deactivate externally authenticated users
through the Firepower System interface. For externally authenticated users, you cannot remove the minimum
access rights through the Firepower System user management page for users assigned an access role because
of LDAP group or RADIUS list membership or attribute values. On the Edit User page for an externally
authenticated user, rights granted because of settings on an external authentication server are marked with a
status of Externally Modified.
You can, however, assign additional rights. When you modify the access rights for an externally authenticated
user, the Authentication Method column on the User Management page provides a status of External - Locally
Modified.
Related Topics
LDAP Authentication, on page 76
RADIUS Authentication, on page 98
LDAP Authentication
LDAP, or the Lightweight Directory Access Protocol, allows you to set up a directory on your network that
organizes objects, such as user credentials, in a centralized location. Multiple applications can then access
those credentials and the information used to describe them. If you ever need to change a user's credentials,
you can change them in one place.
You must create LDAP authentication objects on a Firepower Management Center, but you can use the external
authentication object on any managed devices that have a web interface (that is, on 7000 and 8000 Series
devices) by deploying a platform settings policy where the object is enabled to the device. When you deploy
the policy, the object is copied to the device.
Note Before enabling external authentication on 7000 and 8000 Series devices, remove any
internally-authenticated shell or CLI users that have the same user name as externally-authenticated users
included in your shell access filter.
Note that you can use LDAP naming standards for address specification and for filter and attribute syntax in
your authentication object. For more information, see the RFCs listed in the Lightweight Directory Access
Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure.
Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you
can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of
ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For
example, to refer to a user object, you might type JoeSmith@security.example.com rather than the equivalent
user distinguished name of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active
Directory Server.
Note Currently, the Firepower System supports LDAP external authentication on LDAP servers running
Microsoft Active Directory on Windows Server 2008, Oracle Directory Server Enterprise Edition 7.0 on
Windows Server 2008, or OpenLDAP on Linux. However, the Firepower System does not support external
authentication for NGIPSv or ASA FirePOWER devices.
Note You must have TCP/IP access from your local appliance to the authentication server where you want to
connect.
Tip You can use a third-party LDAP client to browse the LDAP tree and see base DN and attribute descriptions.
You can also use that client to confirm that your selected user can browse the base DN you select. Ask
your LDAP administrator to recommend an approved LDAP client for your LDAP server.
Depending on how you plan to customize your advanced LDAP authentication object configuration, you
might also need the information in the following table.
filter the users who can access your appliance the attribute-value pair to filter by
based on an attribute value
use an attribute as a UI access attribute rather than the name of the attribute
checking the user distinguished name
use an attribute as a shell login attribute rather the name of the attribute
than checking the user distinguished name
filter the users who can access your appliance via the attribute-value pair to filter by
the shell based on an attribute value
associate groups with specific user roles the distinguished name of each group, as well as the group
member attribute if the groups are static groups or the
group member URL attribute if the groups are dynamic
groups
use CACs for authentication and authorization your CAC, a server certificate signed by the same CA
that issued your CAC, and the certificate chain for both
certificates
CAC Authentication
If your organization uses Common Access Cards (CACs), you can configure LDAP authentication to
authenticate users logging into the web interface and authorize access to specific functionality based on group
membership or default access rights. With CAC authentication and authorization configured, users have the
option to log in directly without providing a separate username and password for the appliance.
Note You must have a valid user certificate present in your browser (in this case, a certificate passed to your
browser via your CAC) to enable user certificates as part of the CAC configuration process. After you
configure CAC authentication and authorization, users on your network must maintain the CAC connection
for the duration of their browsing session. If you remove or replace a CAC during a session, your web
browser terminates the session and the system logs you out of the web interface.
CAC-authenticated users are identified in the system by their electronic data interchange personal identifier
(EDIPI) numbers. After users log in using their CAC credentials for the first time, you can manually add or
remove access privileges for those users on the User Management page. If you did not preconfigure a user’s
privileges using group-controlled access roles, the user has only the privileges granted by default in the
platform settings policy.
Tip The system purges manually configured access privileges when it purges CAC-authenticated users from
the User Management page after 24 hours of inactivity. The users are restored to the page after each
subsequent login, but you must reconfigure any manual changes to their access privileges.
Before users on your network can log into Firepower Management Centers and 7000 and 8000 Series devices
using their CAC credentials, a user with appropriate permissions must complete the multi-step configuration
process for CAC authentication and authorization.
Procedure
Step 6 Navigate to System > Users and click the External Authentication tab.
Step 7 Create an LDAP authentication object exclusively for CAC authentication and authorization, following the
procedure in and Creating Advanced LDAP Authentication Objects, on page 83. You must configure the
following:
• the User Name Template in the advanced options of the LDAP-Specific Parameters section.
• the UI Access Attribute in the Attribute Mapping section.
• the distinguished names for existing LDAP groups in the Group Controlled Access Roles section, if
you want to preconfigure access rights through LDAP group membership.
Tip Note that you cannot configure both CAC authentication and shell access in the same authentication
object. If you also want to authorize users for shell access, create and enable separate authentication
objects.
Step 8 Click Save.
Step 9 Enable external authentication and CAC authentication as described in Enabling External Authentication, on
page 945.
Caution Your changes do not take effect until you deploy the configuration changes.
What to Do Next
• After the user logs in for the first time, you can manually add or remove the user's access rights. If you
do not modify the rights, the user has only the rights granted by default. For more information, see
Editing a User Account, on page 67.
Related Topics
LDAP Group Fields, on page 92
LDAP-Specific Fields, on page 88
Logging Into a Managed Device with CAC Credentials, on page 24
Logging Into a Firepower Management Center with CAC Credentials, on page 23
You can set up an LDAP authentication object where you customize many of the values. However, if you just
want to authenticate all the users in a particular directory, you can create a basic authentication object with
the base DN for that directory. If you set defaults to those for your server type and supply authentication
credentials for the account used to retrieve user data from the server, you can quickly create an authentication
object. Follow the procedure below to do so.
Note If you prefer to consider and possibly customize each authentication setting when creating the authentication
object (to grant shell access, for example), use the advanced procedure to create the object. You should
also use the advanced procedure if you plan to encrypt your connection to the server, set user timeouts,
customize the user name template, or assign Firepower System user roles based on LDAP group
membership.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Procedure
Example
The following figures illustrate a basic configuration of an LDAP login authentication object for a Microsoft
Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4. The connection
uses port 389 for access.
However, because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to
store user names rather than the uid attribute. Choosing the MS Active Directory server type and clicking Set
Defaults sets the UI Access Attribute to sAMAccountName. As a result, the Firepower System checks the
sAMAccountName attribute for each object for matching user names when a user attempts to log into the
Firepower System.
In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to be checked
for all objects in the directory for matches when a user logs into a shell or CLI account on the appliance.
Note that because no base filter is applied to this server, the Firepower System checks attributes for all objects
in the directory indicated by the base distinguished name. Connections to the server time out after the default
time period (or the timeout period set on the LDAP server).
What to Do Next
• If you want to enable LDAP authentication, enable the authentication object as described in Enabling
External Authentication, on page 945.
• If you want to refine the list of users retrieved, see Troubleshooting LDAP Authentication Connections,
on page 97 for more information.
When you create a basic authentication object, you define basic settings that let you connect to an authentication
server. When you create an advanced authentication object, you define basic settings and you also choose the
directory context and search criteria you want to use to retrieve user data from the server. Optionally, you can
configure shell access authentication.
Although you can use the default settings for your server type to quickly set up an LDAP configuration, you
can also customize advanced settings to control whether the appliance makes an encrypted connection to the
LDAP server, the timeout for the connection, and which attributes the server checks for user information.
For the LDAP-specific parameters, you can use LDAP naming standards and filter and attribute syntax. For
more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical
Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you
set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address
specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text
Messages) specification when referencing a user name that contains a domain. For example, to refer to a user
object, you might enter JoeSmith@security.example.com rather than the equivalent user distinguished name
of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server.
Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove
the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user
certificates.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Procedure
Example
This example illustrates an advanced configuration of an LDAP login authentication object for a Microsoft
Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4. The connection
uses port 636 for access.
The connection to the server is encrypted using SSL and a certificate named certificate.pem is used for the
connection. In addition, connections to the server time out after 60 seconds because of the Timeout setting.
Because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to store user
names rather than the uid attribute. Note that the configuration includes a UI Access Attribute of
sAMAccountName. As a result, the Firepower System checks the sAMAccountName attribute for each object for
matching user names when a user attempts to log into the Firepower System.
In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to be checked
for all objects in the directory for matches when a user logs into a shell account on the appliance.
This example also has group settings in place. The Maintenance User role is automatically assigned to all
members of the group with a member group attribute and the base domain name of
CN=SFmaintenance,DC=it,DC=example,DC=com.
The shell access filter is set to be the same as the base filter, so the same users can access the appliance through
the shell or CLI as through the web interface.
What to Do Next
• If you want to enable LDAP authentication, enable the authentication object in Enabling External
Authentication, on page 945.
CAC
Select this checkbox if you want to use CAC for authentication and authorization.
Name
A name for the authentication server.
Description
A description for the authentication server.
Server Type
The type of LDAP server you plan to connect to. You have the following options when selecting a type:
• If you are connecting to a Microsoft Active Directory server, select MS Active Directory.
• If you are connecting to a Sun Java Systems Directory Server or Oracle Directory Server, select Oracle
Directory.
• If you are connecting to an OpenLDAP server, select OpenLDAP.
• If you are connecting to a LDAP server other than those listed above and want to clear default settings,
select Other.
Tip If you click Set Defaults, the system populates the User Name Template, UI Access Attribute, Shell
Access Attribute, Group Member Attribute, and Group Member URL Attribute fields with default
values.
Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the
host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.
When you create an authentication object, you first specify the primary and backup server and server port
where you want the managed device or Firepower Management Center to connect for authentication.
Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove
the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user
certificates.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Procedure
Step 6 Enter a name and description for the authentication server in the Name and Description fields.
Step 7 Choose a Server Type from the drop-down list as described in LDAP Authentication Server Fields, on page
86. Optionally, click Set Defaults.
Step 8 Enter a Primary Server Host Name/IP Address.
Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match
the host name used in this field. In addition, IPv6 addresses are not supported for encrypted
connections.
Step 9 Optionally, enter a Primary Server Port.
Step 10 Optionally, enter a Backup Server Host Name/IP Address.
Step 11 Optionally, enter a Backup Server Port.
What to Do Next
• Continue creating your LDAP authentication object as described in Creating Advanced LDAP
Authentication Objects, on page 83.
LDAP-Specific Fields
The following table describes each of the LDAP-specific parameters.
Base Filter Focuses your search by only retrieving objects in the base DN that have the To filter for only users with a
specific attribute-value pair set in the filter. The base filter is an attribute common name starting with F, use
type, a comparison operator, and the attribute value you want to use as a the filter (cn=F*).
filter enclosed in parentheses.
User Name/ Allows the local appliance to access the user objects. Supplies user The user name for the admin user in
Password credentials for a user with appropriate rights to the authentication objects the Security organization of the
you want to retrieve. The distinguished name for the user you specify must Example company might have a user
be unique to the directory information tree for the LDAP server. Server user name of cn=admin, ou=security,
names associated with a Microsoft Active Directory Server cannot end with dc=example,dc=com
the $ character.
SSL Certificate Indicates the path on your local computer to the certificate to be used for c:/server.crt
Upload Path encryption.
User Name Indicates how user names entered on login should be formatted, by mapping %s@security.example.com,
Template the string conversion character (%s) to the value of the UI Access Attribute
%s@mail.com,
for the user. The user name template is the format for the distinguished name
used for authentication. When a user enters a user name into the login page, %s@mil,
the appliance substitutes the name for the string conversion character and %s@smil.mil,
uses the resulting distinguished name to search for the user credentials.
If you want to use this object for CAC authentication and authorization, you
must enter a User Name Template.
Timeout Sets a timeout for the connection attempt to the primary server, so the If the primary server has LDAP
connection rolls over to the backup server. If the number of seconds indicated disabled, the appliance queries the
in this field (or the timeout on the LDAP server) elapses without a response backup server.
from the primary authentication server, the appliance then queries the backup
server.
However, if LDAP is running on the port of the primary LDAP server and
for some reason refuses to service the request, the failover to the backup
server does not occur.
UI Access Tells the local appliance to match the value of a specific attribute rather than sAMAccountName,
Attribute the value of the user distinguished name. You can use any attribute, if the
userPrincipalName,
value of the attribute is a valid user name for the Firepower System web
interface. If one of the objects has a matching user name and password, the mail
user login request is authenticated.
Selecting a server type and setting defaults prepopulates the UI Access
Attribute with a value typically appropriate for that type of server.
If you leave this field blank, the local appliance checks the user distinguished
name value for each user record on the LDAP server to see if it matches the
user name.
If you want to use this object for CAC authentication and authorization, you
must enter a value that corresponds with your User Name Template value.
The settings in the LDAP-specific parameters section determine the area of the LDAP directory where the
appliance searches for user names, and control details of how the appliance connects to the LDAP server.
Valid user names are unique, and can include underscores (_), periods (.), hyphens (-), and alphanumeric
characters.
In addition for most LDAP-specific settings, you can use LDAP naming standards and filter and attribute
syntax. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical
Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you
set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address
specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text
Messages) specification when referencing a user name that contains a domain. For example, to refer to a user
object, you might enter JoeSmith@security.example.com rather than the equivalent user distinguished name
of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server.
Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove
the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user
certificates.
Procedure
Step 1 In the LDAP-Specific Parameters section of the Create External Authentication Object page, you have two
options for setting the base DN:
• Click Fetch DNs, and choose the appropriate base distinguished name from the drop-down list.
• Enter the base distinguished name for the LDAP directory you want to access in the Base DN field. For
example, to authenticate names in the Security organization at the Example company, enter
ou=security,dc=example,dc=com.
Example:
For example, if the user objects in a directory tree have a physicalDeliveryOfficeName attribute and users in
the New York office have an attribute value of NewYork for that attribute, to retrieve only users in the New
York office, enter (physicalDeliveryOfficeName=NewYork).
Step 3 Enter a distinguished name as the User Name and the Password for a user who has sufficient credentials to
browse the LDAP server.
Example:
For example, if you are connecting to an OpenLDAP server where user objects have a uid attribute and the
object for the administrator in the Security division at our example company has a uid value of NetworkAdmin,
you might enter uid=NetworkAdmin,ou=security,dc=example,dc=com.
Caution If you are connecting to a Microsoft Active Directory Server, you cannot provide a server user
name that ends with the $ character.
Step 4 Re-enter the password in the Confirm Password field.
Step 5 After you configure the basic LDAP-specific parameters, you have several options:
• To access advanced options, click the arrow next to Show Advanced Options and continue with the
next step.
• If you want to configure user default roles based on LDAP group membership, continue with Configuring
Access Rights by Group, on page 93.
• If you are not using LDAP groups for authentication, continue with Configuring LDAP Shell Access,
on page 95.
Example:
For example, to authenticate all users who work in the Security organization of our example company by
connecting to an OpenLDAP server where the UI access attribute is uid, you might enter
uid=%s,ou=security,dc=example,dc=com in the User Name Template field. For a Microsoft Active Directory
server, you could enter %s@security.example.com.
Note If you want to use CAC credentials for authentication and authorization, you must enter a value in
the User Name Template field.
Step 9 Optionally, in the Timeout field, enter the number of seconds that should elapse before rolling over to the
backup connection.
Step 10 Optionally, to retrieve users based on an attribute instead of the Base DN and Base Filter, you have two
options:
• Click Fetch Attrs to retrieve a list of available attributes, and choose the appropriate attribute.
• Enter a UI Access Attribute. For example, on a Microsoft Active Directory Server, you may want to
use the UI Access Attribute to retrieve users, because there may not be a uid attribute on Active Directory
Server user objects. Instead, you can search the userPrincipalName attribute by typing
userPrincipalName in the UI Access Attribute field.
Note If you want to use CAC credentials for authentication and authorization, you must enter a value in
the UI Access Attribute field.
What to Do Next
• Continue creating your LDAP authentication object as described in Creating Advanced LDAP
Authentication Objects, on page 83.
You cannot use the Firepower System user management page to remove the minimum access rights for users
assigned an access role because of LDAP group membership. You can, however, assign additional rights.
When you modify the access rights for an externally authenticated user, the Authentication Method column
on the User Management page provides a status of External - Locally Modified.
Note If you use a dynamic group, the LDAP query is used exactly as it is configured on the LDAP server. For
this reason, the Firepower System limits the number of recursions of a search to four to prevent search
syntax errors from causing infinite loops. If a user’s group membership is not established in those recursions,
the default access role defined in the Group Controlled Access Roles section is granted to the user.
If you prefer to base default access rights on a user’s membership in an LDAP group, you can specify
distinguished names for existing groups on your LDAP server for each of the access roles used by your
Firepower System. When you do so, you can configure a default access setting for those users detected by
LDAP that do not belong to any specified groups. When a user logs in, the Firepower System dynamically
checks the LDAP server and assigns default access rights according to the user’s current group membership.
If you do not configure a user’s privileges using group-controlled access roles, a user has only the privileges
granted by default in the platform settings policy.
If you plan to use an object for CAC authentication and authorization, Cisco recommends configuring LDAP
groups to manage access role assignments for CAC-authenticated users.
Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove
the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user
certificates.
Procedure
Step 1 On the Create External Authentication Object page, click the down arrow next to Group Controlled Access
Roles.
Step 2 Optionally, in the DN fields that correspond to Firepower System user roles, enter the distinguished name for
the LDAP groups that contain users who should be assigned to those roles.
Example:
For example, you might enter the following in the Administrator field to authenticate names in the information
technology organization at the Example company:
cn=itgroup,ou=groups, dc=example,dc=com
Step 3 Choose a Default User Role.
Step 4 If you use static groups, enter a Group Member Attribute.
Example:
For example, if the member attribute is used to indicate membership in the static group you reference for default
Security Analyst access, enter member.
Step 5 If you use dynamic groups, enter a Group Member URL Attribute.
Example:
For example, if the memberURL attribute contains the LDAP search that retrieves members for the dynamic
group you specified for default Admin access, enter memberURL.
What to Do Next
• Continue creating your LDAP authentication object as described in Creating Advanced LDAP
Authentication Objects, on page 83.
Tip Selecting a server type and setting defaults prepopulates this field with an attribute typically appropriate
for that type of server.
You can use the LDAP server to authenticate accounts for shell access on your managed device or Firepower
Management Center. Specify a search filter that retrieves entries for users you want to grant shell access.
You cannot configure CAC authentication and authorization and shell access in the same authentication
object. Instead, create and enable separate authentication objects.
The authentication object for shell access must be the first authentication object on the Firepower Management
Center.
Cisco does not support external authentication for NGIPSv devices or ASA FirePOWER devices. In addition,
IPv6 is not supported for shell access authentication.
Caution On all appliances, users with shell access (whether obtained through external authentication or through
using the CLI expert command) have sudoers privileges in the shell, which can present a security risk.
If you establish external authentication, make sure that you restrict the list of users with shell access
appropriately. Similarly, when granting CLI access privileges, restrict the list of users with Configuration
level access. Cisco strongly recommends that you do not establish additional shell users on the Firepower
Management Center.
You cannot configure CAC authentication and authorization and shell access in the same authentication
object. Checking the CAC check box disables the shell access configuration options on the page. Instead,
create and enable separate authentication objects.
Procedure
Step 1 On the Create External Authentication Object page, if you want to use a shell access attribute other than the
user distinguished type a Shell Access Attribute.
Example:
For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve
shell access users by typing sAMAccountName in the Shell Access Attribute field.
Step 2 Set a shell access account filter. You have multiple options:
• To retrieve administrative user entries based on attribute value, enter the attribute name, a comparison
operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Shell Access
Filter field. For example, if all network administrators have a manager attribute which has an attribute
value of shell, you can set a base filter of (manager=shell).
• To use the same filter you specified when configuring authentication settings, choose Same as Base
Filter.
• To prevent LDAP authentication of shell access, leave the field blank.
What to Do Next
• Continue creating your LDAP authentication object as described in Creating Advanced LDAP
Authentication Objects, on page 83.
After you configure LDAP server and authentication settings, you can specify user credentials for a user who
should be able to authenticate to test those settings.
For the User Name, you can enter the value for the uid attribute for the user you want to test with. If you are
connecting to a Microsoft Active Directory Server and supplied a UI access attribute in place of uid, use the
value for that attribute as the user name. You can also specify a fully qualified distinguished name for the
user.
Use the Password for the same user.
The test output lists valid and invalid user names. Valid user names are unique, and can include underscores
(_), periods (.), hyphens (-), and alphanumeric characters.
Note that testing the connection to servers with more than 1000 users only returns 1000 users because of web
interface page size limitations.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is
correct. Test the server configuration without the additional test parameters first. If that succeeds supply
a user name and password to test with the specific user.
Procedure
Step 1 On the Add External Authentication Object page, enter a User Name and Password.
Example:
For example, to test to see if you can retrieve the JSmith user credentials at the Example company, enter
JSmith and password.
Step 2 Click Test. You have two options:
• If the test succeeds, the test output appears at the bottom of the page. Click Save.
• If the test fails, see Troubleshooting LDAP Authentication Connections, on page 97 for suggestions
for troubleshooting the connection.
What to Do Next
• If you want to enable LDAP authentication, enable the authentication object as described in Enabling
External Authentication, on page 945.
• If you typed in your base distinguished name, click Fetch DNs to retrieve all the available base
distinguished names on the server, and select the name from the list.
• If you are using any filters, access attributes, or advanced settings, check that each is valid and typed
correctly.
• If you are using any filters, access attributes, or advanced settings, try removing each setting and testing
the object without it.
• If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses
and that you are using a valid comparison operator.
• To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve
just that user.
• If you are using an encrypted connection:
◦Check that the name of the LDAP server in the certificate matches the host name that you use to
connect.
◦Check that you have not used an IPv6 address with an encrypted server connection.
• If you are using a test user, make sure that the user name and password are typed correctly.
• If you are using a test user, remove the user credentials and test the object.
• Test the query you are using by connecting to the LDAP server via the command line on the appliance
you want to connect from using this syntax:
ldapsearch -x -b 'base_distinguished_name'
-h LDAPserver_ip_address -p port -v -D
'user_distinguished_name' -W 'base_filter'
For example, if you are trying to connect to the security domain on myrtle.example.com using the
domainadmin@myrtle.example.com user and a base filter of (cn=*), you could test the connection using
this statement:
ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'
-h myrtle.example.com -p 389 -v -D
'domainadmin@myrtle.example.com' -W '(cn=*)'
If you can test your connection successfully but authentication does not work after you deploy a platform
settings policy, check that authentication and the object you want to use are both enabled in the platform
settings policy that is applied to the appliance.
If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or
change a base filter or shell access filter or use a more restrictive or less restrictive base DN.
RADIUS Authentication
The Remote Authentication Dial In User Service (RADIUS) is an authentication protocol used to authenticate,
authorize, and account for user access to network resources. You can create an authentication object for any
RADIUS server that conforms to RFC 2865.
When a user authenticated on a RADIUS server logs in for the first time, the user receives the roles specified
for that user in the authentication object. If the user is not listed for any of the user roles, they receive the
default access role you selected in the authentication object. If no default access role is selected in the
authentication object, they receive the default access role set in the platform settings policy. You can modify
a user’s roles, if needed, unless the settings are granted through the user lists in the authentication object. Note
that when a user authenticated on a RADIUS server using attribute matching attempts to log in for the first
time, the login is rejected as the user account is created. The user must log in a second time.
Note Before enabling external authentication on 7000 or 8000 Series devices, remove any internally-authenticated
CLI users that have the same user name as externally-authenticated users included in your shell access
filter.
The Firepower System implementation of RADIUS supports the use of SecurID® tokens. When you configure
authentication by a server using SecurID, users authenticated against that server append the SecurID token
to the end of their SecurID PIN and use that as their password when they log into a Cisco system. As long as
SecurID is configured correctly to authenticate users outside the Firepower System, those users can log into
a Firepower Management Center or 7000 or 8000 Series device using their PIN plus the SecurID token without
any additional configuration.
When you create a RADIUS authentication object, you define settings that let you connect to an authentication
server. You also grant user roles to specific and default users. If your RADIUS server returns custom attributes
for any users you plan to authenticate, you must define those custom attributes. Optionally, you can also
configure CLI or shell access authentication.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Procedure
Example
The following figure illustrates a sample RADIUS login authentication object for a server running FreeRADIUS
with an IP address of 10.10.10.98. Note that the connection uses port 1812 for access, and note that connections
to the server time out after 30 seconds of disuse, then retry three times before attempting to connect to a backup
authentication server.
This example illustrates important aspects of RADIUS user role configuration:
Users ewharton and gsand are granted administrative access to appliances where this authentication object
is enabled.
The user cbronte is granted Maintenance User access to appliances where this authentication object is enabled.
The user jausten is granted Security Analyst access to appliances where this authentication object is enabled.
The user ewharton can log into the appliance using a shell account.
The following graphic depicts the role configuration for the example:
Example
You can use an attribute-value pair to identify users who should receive a particular user role. If the attribute
you use is a custom attribute, you must define the custom attribute.
The following figure illustrates the role configuration and custom attribute definition in a sample RADIUS
login authentication object for the same FreeRADIUS server as in the previous example.
In this example, however, the MS-RAS-Version custom attribute is returned for one or more of the users because
a Microsoft remote access server is in use. Note the MS-RAS-Version custom attribute is a string. In this
example, all users logging in to RADIUS through a Microsoft v. 5.00 remote access server should receive the
Security Analyst (Read Only) role, so you enter the attribute-value pair of MS-RAS-Version=MSRASV5.00 in
the Security Analyst (Read Only) field.
What to Do Next
• If you want to enable RADIUS authentication, enable the authentication object as described in Enabling
External Authentication, on page 945.
When you create a RADIUS authentication object, you first specify the primary and backup server and server
port where you want the local appliance (managed device or Firepower Management Center) to connect for
authentication.
Note For RADIUS to function correctly, you must open its authentication and accounting ports (by default,
1812 and 1813) on your firewall.
If you specify a backup authentication server, you can set a timeout for the connection attempt to the primary
server. If the number of seconds indicated in the Timeout field (or the timeout on the LDAP server) elapses
without a response from the primary authentication server, the appliance then re-queries the primary server.
After the appliance re-queries the primary authentication server the number of times indicated by the Retries
field and the number of seconds indicated in the Timeout field again elapses without a response from the
primary authentication server, the appliance then rolls over to the backup server.
If, for example, the primary server has RADIUS disabled, the appliance queries the backup server. If RADIUS
is running on the port of the primary RADIUS server and for some reason refuses to service the request (due
to misconfiguration or other issues), however, the failover to the backup server does not occur.
Procedure
What to Do Next
• Continue creating your RADIUS authentication object as described in Creating RADIUS Authentication
Objects, on page 99.
When a user logs in, the Firepower System checks the RADIUS server and grants access rights depending on
the RADIUS configuration:
• If specific access rights are not configured for a user and a default access role is not specified, when a
new user logs in, the Firepower System authenticates the user against the RADIUS server and then
grants user rights based on the default access role (or roles) set in the platform settings policy.
• If a new user is not specified on any lists and default access roles are specified in the Default User Role
list of the authentication object, the user is assigned those access roles.
• If you add a user to the list for one or more specific role, that user receives all assigned access roles.
You can also use attribute-value pairs, rather than user names, to identify users who should receive a particular
user role. For example, if you know all users who should be Security Analysts have the value Analyst for
their User-Category attribute, you can enter User-Category=Analyst in the Security Analyst List field to
grant that role to those users.
You can assign a default user role (or roles) to be assigned to any users that are authenticated externally but
not listed for a specific role. You can specify multiple roles in the Default User Role list.
You cannot remove the minimum access rights for users assigned an access role because of RADIUS user
list membership through the Firepower System user management page. You can, however, assign additional
rights.
Caution If you want to change the minimum access setting for a user, you must not only move the user from one
list to another in the RADIUS Specific Parameters section or change the user’s attribute on the RADIUS
server, you must redeploy the configuration to the managed device and remove the assigned user right on
the user management page.
Procedure
Step 1 On the Create External Authentication Object page, in the fields that correspond to Firepower System user
roles, enter the name of each user or identifying attribute-value pair that should be assigned to those roles.
Example:
For example, to grant the Administrator role to the users jsmith and jdoe, enter jsmith, jdoe in the
Administrator field. As another example, to grant the Maintenance User role to all users with a User-Category
value of Maintenance, enter User-Category=Maintenance in the Maintenance User field.
Step 2 Choose the default minimum access role for users that do not belong to any of the specified groups from the
Default User Role list.
What to Do Next
• Continue creating your RADIUS authentication object as described in Creating RADIUS Authentication
Objects, on page 99.
You can also use the RADIUS server to authenticate accounts for CLI or shell access on your local appliance
(managed device or Firepower Management Center). Specify user names for users you want to grant CLI or
shell access.
Note IPv6 addresses are not supported for shell authentication. If you configure a primary RADIUS server with
an IPv6 address and also configure administrative shell access, the shell access settings are ignored. To
allow shell authentication when using an IPv6 address for your primary RADIUS server, set up another
authentication object using an IPv4 address for the server and use that object as the first authentication
object on the Firepower Management Center.
With the exception of the admin account, the shell access list you set on the RADIUS authentication object
entirely controls CLI or shell access on the appliance. CLI or shell users are configured as local users on the
appliance when you deploy the platform settings policy. Note that when a user authenticated on a RADIUS
server using attribute matching attempts to log in for the first time, the login is rejected as the user account is
created. The user must log in a second time.
Note that a home directory for each CLI or shell user is created on login, and when an RADIUS shell access
user account is disabled (by disabling the RADIUS connection), the directory remains, but the user shell is
set to /bin/false in /etc/password to disable the shell. If the user then is re-enabled, the shell is reset, using
the same home directory.
CLI or shell users can log in using user names with lowercase, uppercase, or mixed case letters. Login
authentication for the CLI or shell is case sensitive.
Caution On all appliances, users with shell access (whether obtained through external authentication or through
using the CLI expert command) have sudoers privileges in the shell, which can present a security risk.
If you establish external authentication, make sure that you restrict the list of users with shell access
appropriately. Similarly, when granting CLI access privileges, restrict the list of users with Configuration
level access. Cisco strongly recommends that you do not establish additional shell users on the Firepower
Management Center.
Procedure
On the Create External Authentication Object page, enter the user names, separated by commas, in the
Administrator Shell Access User List field.
Note If you choose not to specify a shell access filter, a warning displays when you save the authentication
object to confirm that you meant to leave the filter blank.
What to Do Next
• Continue creating your RADIUS authentication object as described in Creating RADIUS Authentication
Objects, on page 99.
If your RADIUS server returns values for attributes not included in the dictionary file in /etc/radiusclient/
and you plan to use those attributes to set user roles for users with those attributes, you need to define those
attributes in the login authentication object. You can locate the attributes returned for a user by looking at the
user’s profile on your RADIUS server.
When you define an attribute, you provide the name of the attribute, which consists of alphanumeric characters.
Note that words in an attribute name should be separated by dashes rather than spaces. You also provide the
attribute ID, which should be an integer and should not conflict with any existing attribute IDs in the
etc/radiusclient/dictionary file. You also specify the type of attribute: string, IP address, integer, or date.
When you create a RADIUS authentication object, a new dictionary file for that object is created on the
appliance in the /var/sf/userauth directory. Any custom attributes you add to the authentication object are
added to the dictionary file.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.
Procedure
Step 1 On the Add External Authentication Object page, click the arrow to expand the Define Custom RADIUS
Attributes section.
Step 2 Enter an attribute name in the Attribute Name field.
Step 3 Enter the attribute ID, in integer form, in the Attribute ID field.
Step 4 Choose the type of attribute from the Attribute Type drop-down list.
Step 5 Click Add to add the custom attribute to the authentication object.
Tip You can remove a custom attribute from an authentication object by clicking Delete next to the attribute.
Example
If a RADIUS server is used on a network with a Cisco router, you might want to use the
Ascend-Assign-IP-Pool attribute to grant a specific role to all users logging in from a specific IP address
pool. Ascend-Assign-IP-Pool is an integer attribute that defines the address pool where the user is allowed
to log in, with the integer indicating the number of the assigned IP address pool.
To declare that custom attribute, you create a custom attribute with an attribute name of
Ascend-IP-Pool-Definition, an attribute ID of 218, and an attribute type of integer.
You could then enter Ascend-Assign-IP-Pool=2 in the Security Analyst (Read Only) field to grant read-only
security analyst rights to all users with an Ascend-IP-Pool-Definition attribute value of 2.
What to Do Next
• Continue creating your RADIUS authentication object as described in Creating RADIUS Authentication
Objects, on page 99.
After you configure RADIUS connection, user role, and custom attribute settings, you can specify user
credentials for a user who should be able to authenticate to test those settings.
For the user name, you can enter the user name for the user you want to test with.
Note that testing the connection to servers with more than 1000 users only returns 1000 users because of UI
page size limitations.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is
correct. To verify that the server configuration is correct, click Test without entering user information in
the Additional Test Parameters field first. If that succeeds, supply a user name and password to test with
the specific user.
Procedure
Step 1 On the Add External Authentication Object page, in the User Name and Password fields, enter the user name
and password for the user whose credentials should be used to validate access to the RADIUS server.
Example:
For example, to test to see if you can retrieve the jsmith user credentials at our example company, enter
jsmith.
Step 2 Choose Show Details, and click Test.
Step 3 If the test succeeds, click Save.
What to Do Next
• If you want to enable RADIUS authentication, enable the authentication object as described in Enabling
External Authentication, on page 945.
Note You cannot login with single sign-on if your organization uses CACs for authentication.
Related Topics
STIG Compliance
Configuring SSO
Smart License Classic License Supported Devices Supported Domains Access
Any Any ASA FirePOWER Any Admin
You must set up a one-way, encrypted authentication path from CSM to the Firepower Management Center
before you configure Single sign-on.
In NAT environments, the Firepower Management Center and CSM must reside on the same side of the NAT
boundary. You must provide specific criteria to enable communications between CSM and the Firepower
Management Center.
Note You cannot login with single sign-on if your organization uses CACs for authentication.
Procedure
Step 1 From CSM, generate an SSO shared encryption key that identifies the connection. See your CSM documentation
for more information.
Step 2 From the Firepower Management Center, choose System > Users.
Step 3 Choose CSM Single Sign-on.
Step 4 Enter the CSM hostname or IP address and the server Port.
Step 5 Enter the Shared key that you generated from CSM.
Step 6 Optionally, if you want to use the Firepower Management Center’s proxy server to communicate with CSM,
choose the Use Proxy For Connection check box.
Step 7 Click Submit.
Step 8 Click Confirm Certificate to save the Certificate.
You can now log in from CSM to the Firepower Management Center without an additional login.
Related Topics
Configure Management Interfaces, on page 879
Note The Firepower Management Center manages feature licenses for your devices, but you do not need a
feature license to use a Firepower Management Center.
A single Firepower Management Center can manage both Classic and Smart Licenses.
notifies you that you must renew the subscription. If a subscription expires for a Classic device, you might
not be able to use the related features, depending on the feature type. If a subscription expires for a Firepower
Threat Defense device, you can continue to use the related features.
Service subscriptions correspond to the licenses you assign to managed devices in the Firepower System, as
follows:
Your purchase of a managed device that uses Classic Licenses automatically includes Control and Protection
licenses. These licenses are perpetual, but you must also purchase a TA service subscription to enable system
updates. Service subscriptions for additional features are optional.
TM Threat + Malware
Your purchase of a managed device that uses Smart Licenses automatically includes a Base license. This
license is perpetual and enables system updates. All service subscriptions are optional for Firepower Threat
Defense devices.
Note For NGIPSv or ASA FirePOWER, the Control license allows you to perform user and application control,
but these devices do not support switching, routing, stacking, or 7000 and 8000 Series device high
availability.
There are a few ways you may lose access to licensed features in the Firepower System:
• You can remove Classic Licenses from the Firepower Management Center, which affects all of its
managed devices.
• You can disable licensed capabilities on specific managed devices.
Though there are some exceptions, you cannot use the features associated with an expired or deleted license.
The following table summarizes Classic Licenses in the Firepower System.
Protection TA (included with 7000 and 8000 Series intrusion detection and none no
device) prevention
ASA FirePOWER
file control
NGIPSv
Security Intelligence
filtering
Control none (included with 7000 and 8000 Series user and application control Protection no
device) switching and routing
7000 and 8000 Series device
high availability
7000 and 8000 Series
network address translation
(NAT)
Control none (included with ASA FirePOWER user and application control Protection no
device) NGIPSv
Malware TAM, TAMC, or 7000 and 8000 Series AMP for Firepower Protection yes
AMP (network-based Advanced
ASA FirePOWER
Malware Protection)
NGIPSv
URL Filtering TAC, TAMC, or 7000 and 8000 Series category and Protection yes
URL reputation-based URL
ASA FirePOWER
filtering
NGIPSv
VPN none (contact Sales 7000 and 8000 Series deploying virtual private Control yes
for more networks
information)
Protection Licenses
A Protection license allows you to perform intrusion detection and prevention, file control, and Security
Intelligence filtering:
• Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and,
optionally, drop offending packets.
• File control allows you to detect and, optionally, block users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. AMP for Firepower, which requires
a Malware license, allows you to inspect and block a restricted set of those file types based on their
dispositions.
• Security Intelligence filtering allows you to blacklist—deny traffic to and from—specific IP addresses,
URLs, and DNS domain names, before the traffic is subjected to analysis by access control rules. Dynamic
feeds allow you to immediately blacklist connections based on the latest intelligence. Optionally, you
can use a “monitor-only” setting for Security Intelligence filtering.
A Protection license (along with a Control license) is automatically included in the purchase of any Classic
managed device. This license is perpetual, but you must also purchase a TA subscription to enable system
updates.
Although you can configure an access control policy to perform Protection-related inspection without a license,
you cannot deploy the policy until you first add a Protection license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
If you delete your Protection license from the Firepower Management Center or disable Protection on managed
devices, the Firepower Management Center stops acknowledging intrusion and file events from the affected
devices. As a consequence, correlation rules that use those events as a trigger criteria stop firing. Additionally,
the Firepower Management Center will not contact the internet for either Cisco-provided or third-party Security
Intelligence information. You cannot re-deploy existing policies until you re-enable Protection.
Because a Protection license is required for URL Filtering, Malware, and Control licenses, deleting or disabling
a Protection license has the same effect as deleting or disabling your URL Filtering, Malware, or Control
license.
Control Licenses
A Control license allows you to implement user and application control by adding user and application
conditions to access control rules. For 7000 and 8000 Series devices only, this license also allows you to
configure switching and routing (including DHCP relay and NAT) and device high-availability pairs. To
enable a Control license on a managed device, you must also enable a Protection license. A Control license
is automatically included (along with a Protection license) in the purchase of any Classic managed device.
This license is perpetual, but you must also purchase a TA subscription to enable system updates.
If you do not enable a Control license for a Classic managed device, you can add user and application conditions
to rules in an access control policy, but you cannot deploy the policy to the device. If you do not enable a
Control license for 7000 or 8000 Series devices specifically, you also cannot:
• create switched, routed, or hybrid interfaces
• create NAT entries
• configure DHCP relay for virtual routers
• deploy a device configuration that includes switch or routing to the device
• establish high availability between devices
Note Although you can create virtual switches and routers without a Control license, they are not useful without
switched and routed interfaces to populate them.
If you delete a Control license from the Firepower Management Center or disable Control on individual
devices, the affected devices do not stop performing switching or routing, nor do device high-availability
pairs break. You can continue to edit and delete existing configurations, but you cannot deploy those changes
to the affected devices. You cannot add new switched, routed, or hybrid interfaces, nor can you add new NAT
entries, configure DHCP relay, or establish 7000 or 8000 Series device high-availability. Finally, you cannot
re-deploy existing access control policies if they include rules with user or application conditions.
Tip Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block.
This gives you granular, custom control over web traffic, but does not allow you to use URL category and
reputation data to filter network traffic.
Although you can add category and reputation-based URL conditions to access control rules without a URL
Filtering license, the Firepower Management Center will not download URL information. You cannot deploy
the access control policy until you first add a URL Filtering license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
You may lose access to URL filtering if you delete the license from the Firepower Management Center or
disable URL Filtering on managed devices. Also, URL Filtering licenses may expire. If your license expires
or if you delete or disable it, access control rules with URL conditions immediately stop filtering URLs, and
your Firepower Management Center can no longer download updates to URL data. You cannot re-deploy
existing access control policies if they include rules with category and reputation-based URL conditions.
Note 7000 and 8000 Series managed devices with Malware licenses enabled attempt to connect periodically to
the AMP cloud even if you have not configured dynamic analysis. Because of this, the device’s Interface
Traffic dashboard widget shows transmitted traffic; this is expected behavior.
You configure AMP for Firepower as part of a file policy, which you then associate with one or more access
control rules. File policies can detect your users uploading or downloading files of specific types over specific
application protocols. AMP for Firepower allows you to use local malware analysis and file preclassification
to inspect a restricted set of those file types for malware. You can also download and submit specific file types
to the AMP Threat Grid cloud for dynamic and Spero analysis to determine whether they contain malware.
For these files, you can view the network file trajectory, which details the path the file has taken through your
network. The Malware license also allows you to add specific files to a file list and enable the file list within
a file policy, allowing those files to be automatically allowed or blocked on detection.
Before you can deploy an access control policy that includes AMP for Firepower configurations, you must
add a Malware license, then enable it on the devices targeted by the policy. If you later disable the license on
the devices, you cannot re-deploy the existing access control policy to those devices.
If you delete all your Malware licenses or they all expire, the system stops querying the AMP cloud, and also
stops acknowledging retrospective events sent from the AMP cloud. You cannot re-deploy existing access
control policies if they include AMP for Firepower configurations. Note that for a very brief time after a
Malware license expires or is deleted, the system can use existing cached file dispositions. After the time
window expires, the system assigns a disposition of Unavailable to those files.
A Malware license is required only if you deploy AMP for Firepower and AMP Threat Grid. Without a
Malware license, the Firepower Management Center can receive AMP for Endpoints malware events and
indications of compromise (IOC) from the AMP cloud.
Related Topics
File Control and Cisco AMP Basics, on page 1384
VPN Licenses
VPN allows you to establish secure tunnels between endpoints via a public source, such as the Internet or
other network. You can configure the Firepower System to build secure VPN tunnels between the virtual
routers of 7000 and 8000 Series devices. To enable VPN, you must also enable Protection and Control licenses.
To purchase a VPN license, contact Sales.
Without a VPN license, you cannot configure a VPN deployment with your 7000 and 8000 Series devices.
Although you can create deployments, they are not useful without at least one VPN-enabled routed interface
to populate them.
If you delete your VPN license from the Firepower Management Center or disable VPN on individual devices,
the affected devices do not break the current VPN deployments. Although you can edit and delete existing
deployments, you cannot deploy your changes to the affected devices.
Use the Classic Licenses page to view the Classic Licenses that you have added to the Firepower Management
Center. For each type of managed device in your deployment, the page lists the total number of licenses you
have as well as the portion of those licenses that are in use.
The Licenses page also provides details on each of your licenses. For each model, you can see how many
licenses of each type you have, and how many managed devices you can license with each type of license.
For licenses that expire, the page provides you with the expiration date.
You can also view licenses and license limits as follows:
• The Product Licensing dashboard widget provides an at-a-glance overview of your licenses.
• The Device Management page (Devices > Device Management) lists the licenses applied to each of
your managed devices.
• The Classic License Monitor health module communicates license status when used in a health policy.
Procedure
The license key uniquely identifies the Firepower Management Center in the Cisco License Registration
Portal. It is composed of a product code (66) and the MAC address of the Firepower Management Center; for
example, 66:00:00:77:FF:CC:88.
You must use the license key in the Cisco License Registration Portal to obtain the license text required to
add licenses to the Firepower Management Center.
Procedure
What to Do Next
• Add a license to the Firepower Management Center; see Add a Classic License to the Firepower
Management Center, on page 117.
Note If you add licenses after a backup has completed, these licenses will not be removed or overwritten if this
backup is restored. To prevent a conflict on restore, remove those licenses before restoring the backup,
noting where the licenses were used, and add and reconfigure them after restoring the backup. If a conflict
occurs, contact Support.
Tip You can also request licenses on the Licenses tab after you log into the Support Site.
Procedure
Step 4 Click Get License to open the Cisco License Registration Portal.
Note If you cannot access the Internet using your current computer, switch to a computer that can, and
browse to http://cisco.com/go/license.
Step 5 Generate a license from the PAK in the License Registration Portal. For more information, see
https://www.cisco.com/web/fw/tools/swift/xui/html/help.html.
This step requires the PAK you received during the purchase process, as well as the license key for the
Firepower Management Center.
Step 6 Copy the license text from either the License Registration Portal display, or the email the License Registration
Portal sends you.
Step 7 Return to the Add Feature License page in the Firepower Management Center’s web interface.
Step 8 Paste the license text into the License field.
Step 9 Click Verify License.
If the license is invalid, make sure that you correctly copied the license text.
What to Do Next
• Assign the license to a managed device; see Assign Licenses to Managed Devices, on page 128. You
must assign licenses to your managed devices before you can use licensed features on those devices.
although it will be renewed every six months. If an ID certificate expires (usually in nine months or a year
with no communication, the Firepower Management Center reverts to a deregistered state and licensed features
usage become suspended.
The Firepower Management Center communicates with the License Authority on a periodic basis. If you
make changes in the Smart Software Manager, you can refresh the authorization on the Firepower Management
Center so the changes immediately take effect. You also can wait for the appliance to communicate as scheduled.
If necessary, you can configure a Smart Software Satellite Server to communicate with the License Authority.
Your Firepower Management Center must have either direct Internet access to the License Authority through
the Cisco Smart Software Manager or access through the Smart Software Satellite Server at scheduled time
periods. Normal license communication occurs every 30 days, but with the grace period, your appliance will
operate for up to 90 days without calling home. You must contact the License Authority before 90 days have
passed.
For more information about setting up a Smart Software Satellite Server, see the Smart Software Manager
Satellite User Guide.
Usage Authorization
Specifies the Smart License Agent status. Possible values are:
• Authorized — The Firepower Management Center has contacted and registered successfully with the
License Authority, which has authorized the license entitlements for the appliance.
• Out-of-Compliance — The License Authority could not identify an available license entitlement for
the Firepower Management Center. Licensed features continue to work. However, you must either
purchase or free up additional entitlements for the status to display as Authorized.
• Authorization Expired — The Firepower Management Center has not communicated with the Licensing
Authority in 90 or more days. Licensed features continue to work. In this state, the Smart License Agent
retries its authorization requests. If a retry succeeds, the agent enters either an Out-of-Compliance or
Authorized state, and begins a new authorization period.
Product Registration
Specifies the last date when the Firepower Management Center contacted the License Authority and registered.
Export-Controlled Features
Specifies whether you have enabled export-controlled functionality for the Firepower Management Center in
the Smart Software Manager. If this option is enabled, you can deploy software features that are subject to
national security, foreign policy, and anti-terrorism laws and regulations. Export-controlled features include
Firepower Threat Defense Remote Access VPN or security certifications compliance.
You cannot modify the export-controlled option on the Firepower Management Center. The option is set when
you create a Product Instance Registration Token for the Firepower Management Center in the Smart Software
Manager.
Export-Controlled Features none (product instance Perpetual features that are subject to
registration option) national security, foreign policy,
and anti-terrorism laws and
regulations; see Smart License
Status, on page 119
Remote Access VPN: Based on license type. Term-based or Remote access VPN
perpetual configuration. Your base license
• AnyConnect Apex based on must allow export-controlled
• AnyConnect Plus license type. functionality to configure
Remote Access VPN. You
• AnyConnect VPN Only select whether you meet export
requirements when you register
the device. Firepower Threat
Defense can use any valid
AnyConnect license. The
available features do not differ
based on license type.
Base Licenses
The Base license allows you to:
• implement user and application control by adding user and application conditions to access control rules
• configure your Firepower Threat Defense devices to perform switching and routing (including DHCP
relay and NAT)
• configure Firepower Threat Defense devices as a high availability pair
• configure security modules as a cluster within a Firepower 9300 chassis (intra-chassis clustering)
• configure Firepower 9300 or Firepower 4100 series devices running Firepower Threat Defense as a
cluster (inter-chassis clustering)
Your purchase of a Firepower Threat Defense device or Firepower Threat Defense Virtual automatically
includes a Base license. All additional licenses (Threat, Malware, or URL Filtering) are optional.
A Base license is added to the Firepower Management Center for every Firepower Threat Defense device you
register.
Note Firepower Threat Defense managed devices with Malware licenses enabled periodically attempt to connect
to the AMP cloud even if you have not configured dynamic analysis. Because of this, the device’s Interface
Traffic dashboard widget shows transmitted traffic; this is expected behavior.
You configure AMP for Firepower as part of a file policy, which you then associate with one or more access
control rules. File policies can detect your users uploading or downloading files of specific types over specific
application protocols. AMP for Firepower allows you to use local malware analysis and file preclassification
to inspect a restricted set of those file types for malware. You can also download and submit specific file types
to the AMP Threat Grid cloud for dynamic and Spero analysis to determine whether they contain malware.
For these files, you can view the network file trajectory, which details the path the file has taken through your
network. The Malware license also allows you to add specific files to a file list and enable the file list within
a file policy, allowing those files to be automatically allowed or blocked on detection.
If you disable all your Malware licenses, the system stops querying the AMP cloud, and also stops
acknowledging retrospective events sent from the AMP cloud. You cannot re-deploy existing access control
policies if they include AMP for Firepower configurations. Note that for a very brief time after a Malware
license is disabled, the system can use existing cached file dispositions. After the time window expires, the
system assigns a disposition of Unavailable to those files.
Note that a Malware license is required only if you deploy AMP for Firepower and AMP Threat Grid. Without
a Malware license, the Firepower Management Center can receive AMP for Endpoints malware events and
indications of compromise (IOC) from the AMP cloud.
Threat Licenses
A Threat license allows you to perform intrusion detection and prevention, file control, and Security Intelligence
filtering:
• Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and,
optionally, drop offending packets.
• File control allows you to detect and, optionally, block users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. AMP for Firepower, which requires
a Malware license, allows you to inspect and block a restricted set of those file types based on their
dispositions.
• Security Intelligence filtering allows you to blacklist—deny traffic to and from—specific IP addresses,
URLs, and DNS domain names, before the traffic is subjected to analysis by access control rules. Dynamic
feeds allow you to immediately blacklist connections based on the latest intelligence. Optionally, you
can use a “monitor-only” setting for Security Intelligence filtering.
You can purchase a Threat license as a stand-alone subscription (T) or in combination with URL Filtering
(TC), Malware (TM), or both (TCM).
If you disable Threat on managed devices, the Firepower Management Center stops acknowledging intrusion
and file events from the affected devices. As a consequence, correlation rules that use those events as a trigger
criteria stop firing. Additionally, the Firepower Management Center will not contact the internet for either
Cisco-provided or third-party Security Intelligence information. You cannot re-deploy existing policies until
you re-enable Threat.
Tip Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block.
This gives you granular, custom control over web traffic, but does not allow you to use URL category and
reputation data to filter network traffic.
Although you can add category and reputation-based URL conditions to access control rules without a URL
Filtering license, the Firepower Management Center will not download URL information. You cannot deploy
the access control policy until you first add a URL Filtering license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
You may lose access to URL filtering if you disable the URL Filtering license on managed devices. If your
license expires or if you disable it, access control rules with URL conditions immediately stop filtering URLs,
and your Firepower Management Center can no longer download updates to URL data. You cannot re-deploy
existing access control policies if they include rules with category and reputation-based URL conditions.
AnyConnect Licenses
You can use Firepower Threat Defense device to configure remote access VPN using the Cisco AnyConnect
Secure Mobility Client (AnyConnect) and standards-based IPSec/IKEv2.
To enable the Firepower Threat Defense Remote Access VPN feature, you must purchase and enable one of
the following licenses: AnyConnect Plus, AnyConnect Apex, or AnyConnect VPN Only. You can use any
of the AnyConnect licenses: Plus, Apex, or VPN Only. You can select AnyConnect Plus and AnyConnect
Apex if you have both licenses and you want to use them both. The Any Connect VPN only license cannot
be used with Apex or Plus. The AnyConnect license must be shared with the Smart Account. For more
instructions, see http://www.cisco.com/c/dam/en/us/products/collateral/security/anyconnect-og.pdf.
You cannot deploy the Remote Access VPN configuration to the Firepower Threat Defense device if the
specified device does not have the entitlement for a minimum of one of the specified AnyConnect license
types. If the registered license moves out of compliance or entitlements expire, the system displays licensing
alerts and health events.
The maximum VPN sessions are governed by platform-specific limits and have no dependency on the license.
There is a maximum limit to the number of concurrent remote access VPN sessions allowed on a device based
on the device model. This limit is designed so that system performance does not degrade to unacceptable
levels. Use these limits for capacity planning.
Note The Firepower Threat Defense device denies the VPN connections once the maximum session limit per
platform is reached. The connection is denied with a syslog message. Refer the syslog messages
%ASA-4-113029 and %ASA-4-113038 in the syslog messaging guide. For more information, see http://
www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs.html
While using Remote Access VPN, your Smart License Account must have the export controlled features
(strong encryption) enabled. The Firepower Threat Defense requires stronger encryption (which is higher
than DES) for successfully establishing Remote Access VPN connections with AnyConnect clients. When
you register the device, you must do so with a Smart Software Manager account that is enabled for
export-controlled features. For more information about export-controlled features, see Smart License Types
and Restrictions, on page 120.
You cannot deploy Remote Access VPN if the following are true:
• Smart Licensing on the Firepower Management Center is running in evaluation mode.
• Your Smart Account is not configured to use export-controlled features (strong encryption).
To prevent use of ciphers greater than DES, pre-deployment checks are available at the following locations
in the Firepower Management Center:
Devices > Platform Settings > SSL Settings
Devices > VPN > Remote Access > Advanced > IPsec
For more information about SSL settings and IPsec, see Configure SSL Settings , on page 961 and Firepower
Threat Defense Remote Access VPN IPsec/IKEv2 Parameters Page, on page 839
Register the Firepower Management Center with the Cisco Smart Software Manager
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Global only Admin
Defense
Procedure
What to Do Next
• Register your Firepower Threat Defense device; see Adding Devices to the Firepower Management
Center, on page 473.
• Assign licenses to your Firepower Threat Defense; see Assign Licenses to Managed Devices, on page
128.
Use the Smart Licenses page to view the Smart Licenses for a Firepower Management Center and its managed
Firepower Threat Defense devices. For each type of license in your deployment, the page lists the total number
of managed devices currently using that license, whether the license is in compliance or out of compliance,
the device type, and the domain and group where the device is deployed. You can also view the Firepower
Management Center's Smart License Status.
Other than the Smart Licenses page, there are a few other ways you can view licenses:
• The Product Licensing dashboard widget provides an at-a-glance overview of your licenses.
• The Device Management page (Devices > Device Management) lists the licenses applied to each of
your managed devices.
• The Smart License Monitor health module communicates license status when used in a health policy.
Procedure
You can enable and disable Smart Licenses on multiple Firepower Threat Defense devices at once. You cannot
use the features associated with a license if you disable it on a managed device.
Procedure
Deregister a Firepower Management Center from the Cisco Smart Software Manager
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Global only Admin
Defense
Deregistering a Firepower Management Center from the Cisco Smart Software Manager removes the
Management Center from your virtual account. All license entitlements associated with the Firepower
Management Center release back to your virtual account. After deregistration, the Firepower Management
Center enters Enforcement mode where no update or changes on licensed features are allowed.
Procedure
Synchronize a Firepower Management Center with the Cisco Smart Software Manager
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Global only Admin
Defense
If you make changes in the Cisco Smart Software Manager, you can refresh the authorization on the Firepower
Management Center so the changes immediately take effect.
Procedure
The Cisco Smart Software Manager communicates with the License Authority to manage your licenses. If
your Firepower Management Center has Internet connectivity, it connects directly to the Smart Software
Manager. Alternatively, you can connect to the Smart Software Manager through a Smart Software Satellite
Server.
The Smart Software Satellite Server maintains periodic communication with the License Authority and allow
you to schedule synchronization or manually synchronize Smart License authorization with the Smart Software
Manager.
You might want to use the Smart Software Satellite Server if:
• Your Firepower Management Center is offline or otherwise has limited or no connectivity.
• Your Firepower Management Center has permanent connectivity, but you want to manage your Smart
Licenses via a single connection from your network.
For more information about setting up a Smart Software Satellite Server, see the Smart Software Manager
Satellite User Guide.
Procedure
Although there are some exceptions, you cannot use the features associated with a license if you disable it on
a managed device.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
For most update types, you can schedule their download and installation.
Caution This chapter contains general information on updating the Firepower System. Before you update any part
of the Firepower System, including the VDB, GeoDB, or intrusion rules, you must read the release notes
or advisory text that accompanies the update. The release notes provide important information, including
supported platforms, compatibility, prerequisites, warnings, and specific installation and uninstallation
instructions.
feature updates to Feature updates are more yes yes Product Updates Global only
the Firepower comprehensive than patches and
System generally include new features
(and usually change the third
digit in the version number; for
example, 6.0.1).
Vulnerability VDB updates affect the yes no Product Updates Global only
Database (VDB) vulnerabilities reported by the
Firepower System as well as the
detected operating systems,
applications, and clients.
Note that while you can uninstall patches and other minor updates to the Firepower System, you cannot
uninstall major updates or return to previous versions of the VDB, GeoDB, or intrusion rules. If you updated
your appliance to a new major version of the Firepower System, and you need to revert to an older version,
contact Support.
Unless otherwise documented in the release notes or advisory text, updating an appliance does not modify its
configuration; the settings on the appliance remain intact.
Caution Because the update process may affect traffic inspection, traffic flow, and link state, and because the Data
Correlator is disabled while an update is in progress, Cisco recommends you perform the update in a
maintenance window or at a time when the interruption will have the least impact on your deployment.
Order of Update
You must update your Firepower Management Centers before you can update the devices they manage.
Tip For patches and feature updates, you can take advantage of the automated update feature.
Updating managed devices is a two-step process. First, download the update from the Support Site and upload
it to the managing Firepower Management Center: http://www.cisco.com/cisco/web/support/index.html.
Next, install the software.
Caution Traffic inspection, traffic flow, and link state may be affected during the update, depending on how your
devices are configured and deployed, the components that the update affects, and whether the update
reboots the devices. For specific information on how and when network traffic is affected for a particular
update, see the release notes for that update.
applies it to the standby device or stack, which goes into maintenance mode until any necessary processes
restart and the device or stack is processing traffic again. The system then applies the update to the active
device or stack, which follows the same process.
To update devices in stacks in a high-availability pair, you must perform the update from the managing
Firepower Management Center on all members of a high-availability pair at once; you cannot perform the
upgrade directly from the devices.
The Data Correlator does not run during system updates. It resumes when the update is complete.
The manner and duration of network traffic interruption depends on the components of the Firepower System
that the update affects, how your devices are configured and deployed, and whether the update reboots the
device. For specific information on how and when network traffic is affected for a particular update, see the
release notes.
Tip When you update 7000 or 8000 Series devices in a high-availability pair, the system performs the updates
one at a time to avoid traffic interruption.
Tip To monitor updates to its managed devices, use the Message Center on the Firepower Management Center.
Even for minor updates, the web interface on the updating appliance may become unavailable during the
update process, or the appliance may log you out. This is expected behavior. If this occurs, log in again to
view the Message Center (for minor updates) or the Update Status page (for major updates). If the update is
still running, you must continue to refrain from using the web interface until the update has completed. Note
that while updating, managed devices may reboot a second time; this is also expected behavior.
Caution If you encounter issues with the update (for example, if the web interface indicates that the update has
failed or if the Message Center or Update Status page shows no progress), do not restart the update. Instead,
contact Support.
Caution You must deploy configurations after you update the Firepower Management Center and again after you
update its managed devices.
Note Use one the above methods to obtain the update. If you transfer an update file by email, it may become
corrupted.
The Product Updates page (System > Updates) shows the version of each update, as well as the date and time
it was generated. It also indicates whether a reboot is required as part of the update.
When you upload updates obtained from Support to your appliance, they appear on the page. Uninstallers for
patch and feature updates also appear. On the Firepower Management Center, the page can list VDB updates.
For major updates, updating the Firepower Management Center removes uninstallers for previous updates.
Beginning with Version 6.2.1, Firepower appliances do not accept software updates that do not have a valid
digital signature applied by Cisco. This restriction does not apply to updates of the vulnerability database
(VDB), intrusion rules, or geolocation database (GeoDB).
Procedure
Step 1 Read the release notes, and complete any required pre-update tasks.
Step 2 Make sure that the devices in your deployment are successfully communicating and that there are no issues
being reported by the health monitor.
Step 3 Choose System > Updates.
Step 4 Click the install icon next to the update you uploaded.
Step 5 Choose the Firepower Management Center, and click Install. If prompted, confirm that you want to install
the update and reboot the Firepower Management Center.
Step 6 Optionally, monitor the update status:
• For minor updates, see Viewing Task Messages, on page 268.
• For major updates, see Monitor Major Firepower System Software Updates, on page 144.
Caution Regardless of the update type, do not use the web interface to perform tasks other than monitoring
the update until the update has completed and, if necessary, the Firepower Management Center
reboots.
If you encounter issues with the update (for example, if the Message Center indicates that the
update has failed or if the messages show no progress), do not restart the update. Instead, contact
Support.
Step 7 After the update finishes, if necessary, log back into the Firepower Management Center.
Step 8 If you are the first user to log in after a major update, review and accept the End User License Agreement
(EULA) to continue.
Step 9 Clear your browser cache, and force a reload of the browser. Otherwise, the user interface may exhibit
unexpected behavior.
Step 10 Choose Help > About to view system information.
Step 11 On the system information page, confirm that the software version is listed correctly, and note the versions
the rule update and VDB on the Firepower Management Center, which you will need later.
Step 12 Verify that all managed devices are successfully communicating with the Firepower Management Center.
What to Do Next
• Import an intrusion rule update if a new one exists; see Intrusion Rule Updates, on page 149.
• Install a VDB from the Support Site if it is newer than the VDB on your Firepower Management Center;
see Vulnerability Database Updates, on page 147.
• Update the system software on managed devices; see Update 7000 and 8000 Series Devices, NGIPSv,
and ASA FirePOWER Modules Using the Firepower Management Center, on page 140 and Update
Firepower Threat Defense Devices Using the Firepower Management Center, on page 142.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can download software updates to the Firepower Management Center for all except major updates. To
do so, your Firepower Management Center must have access to the Internet.
Procedure
Procedure
Step 1 Manually download the update from the Cisco Support Site (http://www.cisco.com/cisco/web/support/
index.html).
Step 2 Choose System > Updates.
Step 3 Click Upload Update.
Step 4 Browse to the update, and click Upload.
What to Do Next
• Install the update. See Update Software on a Firepower Management Center, on page 138 and Updating
the Vulnerability Database, on page 148 for more information.
Update 7000 and 8000 Series Devices, NGIPSv, and ASA FirePOWER Modules Using the
Firepower Management Center
Smart License Classic License Supported Devices Supported Domains Access
Any Any 7000 and 8000 Global only Admin
Series
NGIPSv
ASA FirePOWER
If your appliance is in a high availability configuration, see the update sequence guidelines in the Firepower
System Release Notes for the update before continuing.
If you are locally managing the ASA FirePOWER module through ASDM, do not update the ASA FirePOWER
module using the Firepower Management Center. For more information, see Cisco ASA with FirePOWER
Services Local Management Configuration Guide.
Caution Do not reboot or shut down your appliance during the update until you see the login prompt. The system
may appear inactive during the pre-checks; this is expected behavior and does not require you to reboot
or shut down your appliance.
Procedure
Step 3 Use the managing Firepower Management Center to deploy configuration changes to the managed devices.
Otherwise, the eventual update may fail.
Step 4 If you are updating an ASA device with an FXOS chassis, update to the appropriate version of FXOS before
continuing with the Firepower update.
Step 5 If you are updating an ASA device, update to the appropriate ASA/ASDM version before continuing with
the Firepower update.
For more information, see the ASA/ASDM release notes, available here: http://www.cisco.com/c/en/us/td/
docs/security/asa/roadmap/asaroadmap.html .
Step 6 If you are updating an ASA device with an FXOS chassis, update to the appropriate version of FXOS before
continuing with the Firepower update.
For more information, see the FXOS release notes, available here: http://www.cisco.com/c/en/us/td/docs/
security/firepower/fxos/roadmap/fxos-roadmap.html.
Caution Regardless of the update type, do not use the web interface to perform tasks other than monitoring
the update until the update has completed and, if necessary, the managed device reboots.
Step 14 After the update process completes, choose Devices > Device Management and confirm that the devices you
updated have the correct software version.
Step 15 Verify that the appliances in your deployment are successfully communicating and that there are no issues
reported by the health monitor.
Step 16 Redeploy policies to all managed devices.
Click the Deploy button and choose all available devices, then click Deploy.
Step 17 If a later patch is available on the Support site, update to the latest patch as described in the Firepower System
Release Notes for that version. You must update to the latest patch to take advantage of product enhancements
and security fixes.
What to Do Next
• If you experience unexpected behavior in the user interface after the update process completes, clear
your browser cache, and force a reload of the browser.
• Optionally, after a major update to a 7000 or 8000 Series device, log in to the device’s local web interface.
If you are the first user to log in after a major update, the End User License Agreement (EULA) may
appear. You must review and accept the EULA to continue. Note that the EULA also appears, and must
be accepted, if your first login is via the command line interface rather than the web interface.
Update Firepower Threat Defense Devices Using the Firepower Management Center
Smart License Classic License Supported Devices Supported Domains Access
Any Any Firepower Threat Global only Admin
Defense
Firepower Threat
Defense Virtual
If your Firepower Threat Defense device is in a high availability or clustered configuration, see the update
sequence guidelines in the Firepower System Release Notes for the update before continuing.
You cannot update an ASA with FirePOWER Services device directly to Firepower Threat Defense. You
must reimage your ASA device to deploy Firepower Threat Defense. For more information, see Reimage the
Cisco ASA or Firepower Threat Defense Device.
If you are directly managing the Firepower Threat Defense device through the Firepower Device Manager,
do not update the device using the Firepower Management Center. For more information, see Cisco Firepower
Threat Defense Configuration Guide for Firepower Device Manager.
Caution Do not reboot or shut down your appliance during the update until you see the login prompt. The system
may appear inactive during the pre-checks; this is expected behavior and does not require you to reboot
or shut down your appliance.
To update Firepower Threat Defense devices using the Firepower Management Center:
Procedure
Step 1 Update to the minimum required version as specified in the appropriate Firepower release notes.
Step 2 Read the Firepower System Release Notes and complete any required pre-update tasks; see Firepower System
Software Update Notes, on page 137 and Firepower System Software Update Preparation, on page 133.
Step 3 Update the Firepower System software on the Firepower Management Center that manages the devices. See
Firepower System Software Update Notes, on page 137 for more information.
Step 4 Use the managing Firepower Management Center to deploy configuration changes to the managed devices.
Otherwise, the eventual update may fail.
Step 5 If you are updating Firepower Threat Defense on a Firepower 9300 appliance or a Firepower 4100 Series
device, update to the appropriate version of FXOS before continuing with the Firepower update.
For more information, see the FXOS release notes, available here: http://www.cisco.com/c/en/us/td/docs/
security/firepower/fxos/roadmap/fxos-roadmap.html.
Note • Updating FXOS on the Firepower 9300 appliance or a Firepower 4100 series device causes a
disruption in traffic. This is expected.
• Updating FXOS reboots the Firepower 9300 appliance chassis, dropping traffic on clustered
Firepower Threat Defense security modules until the primary security module comes back
online.
Step 12 Click Install. Confirm that you want to install the update and reboot the devices.
The update process begins. Managed devices may reboot twice during the update; this is expected behavior.
Caution If you encounter issues with the update (for example, if messages in the Tasks tab of the Message
Center show no progress for several minutes or indicate that the update has failed), do not restart
the update. Instead, contact TAC Support.
Step 13 Optionally, monitor the update status:
• For minor updates, see Viewing Task Messages, on page 268.
• For major updates, see Monitor Major Firepower System Software Updates, on page 144.
Caution Regardless of the update type, do not use the web interface to perform tasks other than monitoring
the update until the update has completed and, if necessary, the managed device reboots.
Step 14 After the update process completes, choose Devices > Device Management and confirm that the devices you
updated have the correct software version.
Step 15 Verify that the appliances in your deployment are successfully communicating and that there are no issues
reported by the health monitor.
Step 16 Redeploy policies to all managed devices.
Click the Deploy button and choose all available devices, then click Deploy.
Step 17 If a later patch is available on the Support site, update to the latest patch as described in the Firepower System
Release Notes for that version. You must update to the latest patch to take advantage of product enhancements
and security fixes.
What to Do Next
• If you experience unexpected behavior in the user interface after the update process completes, clear
your browser cache, and force a reload of the browser.
You must perform this procedure using the appliance's local web interface.
Procedure
Step 1 Monitor the major software update’s progress in the Message Center until the appliance completes its necessary
pre-update checks.
At this point, the system logs you and all other users out of the web interface. Unless you are an administrator
or a maintenance user, you cannot log back in until the update is complete.
Step 2 If you are an administrator, log back in to the web interface. The streamlined update page appears.
Step 3 Click show log for current script to see the update log. Click hide log for current script to hide the log
again.
Caution If you encounter any issue with the update (for example, if a manual refresh of the streamlined
update page shows no progress for an extended period of time), do not restart the update. Instead,
contact Support.
What to Do Next
• If the update fails for any reason, the page displays an error message indicating the time and date of the
failure, which script was running when the update failed, and instructions on how to contact Support.
Do not restart the update.
• If the update completes successfully, the page displays a success message, and the appliance reboots.
After the appliance finishes rebooting, refresh the page to log in and complete any required post-update
steps.
Caution Uninstalling from the web interface is not supported for major updates. If you updated your appliance to
a new major version of the Firepower System and you need to revert to an older version, contact Support.
Order of Uninstallation
Uninstall the update in the reverse order that you installed it; that is, first uninstall the update from managed
devices, then from Firepower Management Centers.
Uninstalling the Update from 7000 and 8000 Series Devices in High-Availability Pairs
7000 or 8000 Series devices in high-availability pairs must run the same version of the Firepower System.
Although the uninstallation process triggers an automatic failover, 7000 or 8000 Series devices in mismatched
high-availability pairs do not share configuration information, nor do they install or uninstall updates as part
of their synchronization. If you need to uninstall an update from redundant devices, plan to perform the
uninstallations in immediate succession.
You cannot uninstall an update from 7000 or 8000 Series devices in stacks configured as a high-availability
pair if uninstalling would revert these devices to a version in which configuring stacks into high-availability
is not supported.
To ensure continuity of operations, uninstall the update from devices in a high-availability pair one at a time.
First, uninstall the update from the secondary device. Wait until the uninstallation process completes, then
immediately uninstall the update from the primary device.
Caution If the uninstallation process on a device in a high-availability pair fails, do not restart the uninstall or
change configurations on its peer. Instead, contact Support.
This procedure can be performed on Firepower Management Centers and 7000 & 8000 Series devices.
Procedure
Caution Do not use the web interface to perform tasks other than monitoring the update until the uninstall
has completed and, if necessary, the appliance reboots.
Step 3 Optionally, monitor the task status; see Viewing Task Messages, on page 268.
Step 4 After the uninstall finishes, if necessary, log into the appliance.
Step 5 Clear your browser cache and force a reload of the browser. Otherwise, the user interface may exhibit
unexpected behavior.
Step 6 Choose Help > About and confirm that the software version is listed correctly.
What to Do Next
• Verify that the appliance where you uninstalled the patch is successfully communicating with its managed
devices (for the Firepower Management Center) or its managing Firepower Management Center (for
managed devices).
• Verify that the uninstall succeeded and that all appliances in your deployment are communicating
successfully. For specific information for each update, see the release notes.
Note Download the update directly from the Support Site either manually or by clicking Download Updates.
If you transfer an update file by email, it may become corrupted.
The time it takes to update vulnerability mappings depends on the number of hosts in your network map. You
may want to schedule the update during low system usage times to minimize the impact of any system
downtime. As a rule of thumb, divide the number of hosts on your network by 1000 to determine the
approximate number of minutes to perform the update.
After you update the VDB, you must deploy configurations before updated application detectors and operating
system fingerprints can take effect.
Caution Installing a vulnerability database (VDB) update or deploying an access control policy for the first time
after installing a VDB update immediately restarts the Snort process, temporarily interrupting traffic
inspection. Whether traffic drops during this interruption or passes without further inspection depends on
the model of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page
293 for more information.
You can take advantage of the automated update feature to schedule VDB updates.
Caution Installing a vulnerability database (VDB) update or deploying an access control policy for the first time
after installing a VDB update immediately restarts the Snort process, temporarily interrupting traffic
inspection. Whether traffic drops during this interruption or passes without further inspection depends on
the model of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page
293 for more information.
Procedure
Step 1 Read the VDB Update Advisory Text for the update. The advisory text includes information about the changes
to the VDB made in the update, as well as product compatibility information.
Step 2 Choose System > Updates.
Step 3 In the Product Updates tab, click the install icon next to the VDB update.
Step 4 Check the check box next to the Firepower Management Center entry.
Step 5 Click Install. Depending on the number of hosts in your network map, installing the update may take some
time.
Step 6 Optionally, monitor the task status; see Viewing Task Messages, on page 268.
Caution Do not use the web interface to perform tasks related to mapped vulnerabilities until the update
has completed. If you encounter issues with the update (for example, if the Message Center shows
no progress or indicates that the update has failed) do not restart the update. Instead, contact
Support.
Step 7 After the update finishes, choose Help > About to confirm that the VDB build number matches the update
you installed.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• Optionally, schedule VDB updates; see Vulnerability Database Update Automation, on page 190.
Related Topics
Snort® Restart Scenarios , on page 292
In a multidomain deployment, you can import local intrusion rules in any domain, but you can import intrusion
rule updates from Talos in the Global domain only.
• custom—Because every custom network analysis and intrusion policy uses a system-provided policy
as its base, or as the eventual base in a policy chain, rule updates can affect custom network analysis
and intrusion policies. However, you can prevent rule updates from automatically making those changes.
This allows you to update system-provided base policies manually, on a schedule independent of rule
update imports. Regardless of your choice (implemented on a per-custom-policy basis), updates to
system-provided policies do not override any settings you customized.
Note that importing a rule update discards all cached changes to network analysis and intrusion policies. For
your convenience, the Rule Updates page lists policies with cached changes and the users who made those
changes.
Caution Importing a rule update with new or updated shared object rules, which are binaries, restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether
traffic drops during this interruption or passes without further inspection depends on the model of the
managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more
information. Make sure your process for downloading and installing rule updates complies with your
security policies. In addition, intrusion rule updates may be large, so import rules during periods of low
network use.
Import a new intrusion rule update manually if your Firepower Management Center does not have Internet
access.
Procedure
Step 1 Manually download the update from the Cisco Support Site (http://www.cisco.com/cisco/web/support/
index.html).
Step 2 Choose System > Updates, then click the Rule Updates tab.
Step 3 If you want to move all user-defined rules that you have created or imported to the deleted folder, you must
click Delete All Local Rules in the toolbar, then click OK.
Step 4 Choose Rule Update or text rule file to upload and install and click Browse to navigate to and choose the
rule update file.
Step 5 If you want to automatically re-deploy policies to your managed devices after the update completes, choose
Reapply all policies after the rule update import completes.
Step 6 Click Import. The system installs the rule update and displays the Rule Update Log detailed view.
Note Contact Support if you receive an error message while installing the rule update.
To import a new intrusion rule update automatically, your appliance must have Internet access to connect to
the Support Site.
Procedure
Procedure
Step 6 If you want to automatically re-deploy the changed configuration to your managed devices after the update
completes, check the Deploy updated policies to targeted devices after rule update completes check box.
Step 7 Click Save.
Caution Contact Support if you receive an error message while installing the intrusion rule update.
The status message under the Recurring Rule Update Imports section heading changes to indicate that the
rule update has not yet run.
Note The system automatically increments the revision number when you delete a local rule;
this is a device that allows you to reinstate local rules. All deleted local rules are moved
from the local rule category to the deleted rule category.
• Policy validation fails if you enable an imported local rule that uses the deprecated threshold keyword
in combination with the intrusion event thresholding feature in an intrusion policy.
• All imported local rules are automatically saved in the local rule category.
• The system always sets local rules that you import to the disabled rule state. You must manually set the
state of local rules before you can use them in your intrusion policy.
Intrusion rules imported as described below are saved in the local rule category.
Procedure
What to Do Next
• Make sure you enable the appropriate rules in your intrusion policies.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Field Description
Summary The name of the import file. If the import fails, a brief statement of the reason for the
failure appears under the file name.
Field Description
Time The time and date that the import started.
User ID The user name of the user that triggered the import.
The red status icon indicating an unsuccessful or incomplete import appears on the
Rule Update Log page during the import and is replaced by the green icon only when
the import has successfully completed.
Tip You can view import details as they appear while an intrusion rule update import is in progress.
In a multidomain deployment, you can view data for the current domain and for any descendant domains.
You cannot view data from higher level or sibling domains.
Procedure
Note Deleting the file from the log does not delete any object imported in the import file, but only
deletes the import log records.
Tip You search the entire Rule Update Import Log database even when you initiate a search by clicking Search
on the toolbar from the Rule Update Import Log detailed view with only the records for a single import
file displayed. Make sure you set your time constraints to include all objects you want to include in the
search.
Field Description
Action An indication that one of the following has occurred for the object type:
• new (for a rule, this is the first time the rule has been stored on this appliance)
• changed (for a rule update component or rule, the rule update component has been modified, or the rule
has a higher revision number and the same GID and SID)
• collision (for a rule update component or rule, import was skipped because its revision conflicts with
an existing component or rule on the appliance)
• deleted (for rules, the rule has been deleted from the rule update)
• enabled (for a rule update edit, a preprocessor, rule, or other feature has been enabled in a default policy
provided with the system)
• disabled (for rules, the rule has been disabled in a default policy provided with the system)
• drop (for rules, the rule has been set to Drop and Generate Events in a default policy provided with the
system)
• error (for a rule update or local rule file, the import failed)
• apply (the Reapply all policies after the rule update import completes option was enabled for the
import)
Default Action The default action defined by the rule update. When the imported object type is rule, the default action is Pass,
Alert, or Drop. For all other imported object types, there is no default action.
Details A string unique to the component or rule. For rules, the GID, SID, and previous revision number for a changed
rule, displayed as previously (GID:SID:Rev). This field is blank for a rule that has not changed.
Domain The domain whose intrusion policies can use the updated rule. Intrusion policies in descendant domains can
also use the rule. This field is only present in a multidomain deployment.
Field Description
GID The generator ID for a rule. For example, 1 (standard text rule, Global domain or legacy GID) or 3 (shared
object rule).
Name The name of the imported object, which for rules corresponds to the rule Message field, and for rule update
components is the component name.
Policy For imported rules, this field displays All, which indicates that the imported rule was included in all default
intrusion policies. For other types of imported objects, this field is blank.
Type The type of imported object, which can be one of the following:
• rule update component (an imported component such as a rule pack or policy pack)
• rule (for rules, a new or updated rule; note that in Version 5.0.1 this value replaced the update value,
which is deprecated)
• policy apply (the Reapply all policies after the rule update import completes option was enabled
for the import)
Count The count (1) for each record. The Count field appears in a table view when the table is constrained, and the
Rule Update Log detailed view is constrained by default to rule update records. This field is not searchable.
Related Topics
Viewing Details of the Intrusion Rule Update Import Log, on page 157
In a multidomain deployment, you can view data for the current domain and for any descendant domains.
You cannot view data from higher level or sibling domains.
Procedure
Note Download the update directly from the Support Site, either manually or by clicking Download and install
geolocation update from the Support Site on the Geolocation Updates page. If you transfer an update
file by email, it may become corrupted.
Time needed to update the GeoDB depends on your appliance; the installation usually takes 30 to 40 minutes.
Although a GeoDB update does not interrupt any other system functions (including the ongoing collection of
geolocation information), the update does consume system resources while it completes. Consider this when
planning your updates.
The GeoDB update overrides any previous versions of the GeoDB and is effective immediately. When you
update the GeoDB, the Firepower Management Center automatically updates the related data on its managed
devices. It may take a few minutes for a GeoDB update to take effect throughout your deployment. You do
not need to re-deploy after you update.
You can import a new GeoDB update by automatically connecting to the Support Site only if the appliance
has Internet access.
Procedure
If your Firepower Management Center does not have Internet access, you can download the GeoDB update
from the Cisco Support Site to a local machine on your network, then manually upload it to your Firepower
Management Center.
Procedure
Step 1 Manually download the update from the Cisco Support Site (http://www.cisco.com/cisco/web/support/
index.html).
Step 2 Choose System > Updates.
Step 3 Click the Geolocation Updates tab.
Step 4 Choose Upload and install geolocation update.
Step 5 Browse to the update you downloaded, and click Upload.
Step 6 Click Import.
Step 7 Optionally, monitor the task status; see Viewing Task Messages, on page 268.
Step 8 After the update finishes, return to the Geolocation Updates page or choose Help > About to confirm that
the GeoDB build number matches the update you installed.
You can automate recurring geolocation database (GeoDB) updates. Recurring GeoDB updates run once
every 7 days (weekly); you can configure the time the update recurs each week.
Procedure
Note While the system collects backup data, there may be a temporary pause in data correlation, and the system
may prevent you from changing configurations related to the backup.
• You can restore a backup onto a replacement appliance only if the two appliances are the same model
and are running the same version of the Firepower System software.
• Backups do not include captured file data.
• You cannot create or restore backup files for NGIPSv, Firepower Threat Defense physical or virtual
managed devices or ASA FirePOWER modules. To back up event data, perform a backup of the managing
Firepower Management Center.
• Do not use the backup and restore process to copy configurations between appliances. A backup file
contains information that uniquely identifies an appliance, and cannot be shared.
• After you restore a Firepower Management Center, you must apply the latest intrusion rule update.
• Private keys associated with PKI objects are encrypted with a randomly generated key when stored on
the appliance. If you perform a backup that contains private keys associated with PKI objects, the private
keys are decrypted before being included in the unencrypted backup file. Store the backup file in a secure
location.
• If you restore a backup that contains private keys associated with PKI objects, the system encrypts the
keys with a randomly generated key before storing them on the appliance.
• If you restore a backup that includes a file policy with either a clean list or custom detection list enabled,
the system merges any existing file lists(s) with the file lists(s) being restored.
• If you perform a backup, then delete reviewed intrusion events, then restore using that backup, the system
restores the deleted intrusion events but does not restore their reviewed status. You view those restored
intrusion events under Intrusion Events, not under Reviewed Events.
• If you restore a backup that contains intrusion event data on an appliance that already contains that data,
duplicate events are created. To avoid this, restore intrusion event backups only on appliances without
prior intrusion event data.
• If you configured any interface associations with security zones or interface groups, these associations
are not backed up. You must reconfigure them after you restore.
• On Firepower Management Centers, the backup and restore functions are available only in the Global
domain. You can use the export and import functions as substitutes for backup and restore within the
scope of a subdomain.
Related Topics
Remote Storage Management, on page 891
About Configuration Import/Export, on page 171
Marking Intrusion Events Reviewed, on page 2287
Interface Objects: Interface Groups and Security Zones, on page 357
Backup Files
The system backs up different data depending on the type of backup you perform. Note that the system does
not back up captured file data. Use the following table to determine what kind of backup you want to perform.
7000 & 8000 Series, performed from the device itself Yes No No No
7000 & 8000 Series, performed from the managing Yes No Yes No
Firepower Management Center
Note You cannot create or restore backup files for NGIPSv devices, Firepower Threat Defense physical or
virtual managed devices, or ASA FirePOWER modules. To back up event data, perform a backup of the
managing Firepower Management Center.
You should periodically save a backup file that contains all of the configuration files required to restore the
appliance, in addition to event data. You may also want to back up the system when testing configuration
changes so that you can revert to a saved configuration if needed. You can choose to save the backup file on
the appliance or on your local computer.
As an alternative, or if your backup file is larger than 4GB, copy it via SCP to a remote host. Uploading a
backup from your local computer does not work on backup files larger than 4GB because web browsers do
not support uploading files that large. On Firepower Management Centers, the backup file can be saved to a
remote location.
Related Topics
Remote Storage Management, on page 891
Procedure
Step 5 If you want to be notified when the backup is complete, select the Email check box and type your email
address in the accompanying text box.
Note To receive email notifications, you must configure a relay host as described in Configuring a Mail
Relay Host and Notification Address, on page 909.
Step 6 To use secure copy (SCP) to copy the backup archive to a different machine, select the Copy when complete
check box, then type the following information in the accompanying text boxes:
• in the Host field, the hostname or IP address of the machine where you want to copy the backup
• in the Path field, the path to the directory where you want to copy the backup
• in the User field, the user name you want to use to log into the remote machine
• in the Password field, the password for that user name. If you prefer to access your remote machine
with an SSH public key instead of a password, you must copy the contents of the SSH Public Key field
to the specified user’s authorized_keys file on that machine.
Tip With this option cleared, the system stores temporary files used during the backup on the remote
server; temporary files are not stored on the remote server when this option is selected. Cisco
recommends that you periodically save backups to a remote location so the appliance can be
restored in case of system failure.
• To save this configuration as a backup profile that you can use later, click Save As New.
What to Do Next
• Store the backup file in a secure location if it contains PKI object data, as the private keys are stored
unencrypted within the backup.
You must perform this procedure using the appliance's local web interface.
Procedure
• To save this configuration as a backup profile that you can use later, click Save As New.
What to Do Next
• Store the backup file in a secure location if it contains PKI object data, as the private keys are stored
unencrypted within the backup.
Procedure
What to Do Next
• Store the backup file in a secure location if it contains PKI object data, as the private keys are stored
unencrypted within the backup.
You must perform this procedure using the device's web user interface.
You can create backup profiles that contain the settings that you want to use for different types of backups.
You can later select one of these profiles when you back up the files on your appliance.
Tip When you create a backup file for a Firepower Management Center using a new file name, the system
automatically creates a backup profile with that name.
Procedure
You can upload a backup file from your local host to an appliance. You must perform this procedure using
the device's web interface.
If your backup file contains PKI objects, on upload the system re-encrypts private keys associated with internal
CA and internal certificate objects with a randomly generated key.
• Copy backups larger than 4GB from your local host via SCP to a remote host and retrieve it from there
to your Firepower Management Center, as web browsers do not support uploading files that large. See
Remote Storage Management, on page 891 for more information.
Procedure
What to Do Next
• Refresh the Backup Management Page to reveal detailed file system information after the appliance
verifies the file integrity.
Functionality Description
System Information The originating appliance name, type, and version. Note that you can only restore a
backup to an identical appliance type and version.
Date Created The date and time that the backup file was created
VDB Version The build of the vulnerability database (VDB) running on the appliance at the time of
backup.
Functionality Description
Size (MB) The size of the backup file, in megabytes
View Click the name of the backup file to view a list of the files included in the compressed
backup file.
Restore Click with the backup file selected to restore it on the appliance. If your VDB version
does not match the VDB version in the backup file, this option is disabled.
Download Click with the backup file selected to save it to your local computer.
Move On a Firepower Management Center, when you have a previously created local backup
selected, click to send the backup to the designated remote backup location.
You can restore the appliance from backup files using the Backup Management page. You must perform this
procedure using the device's web interface.
Caution • This action overwrites all configuration files and, on the managed device, all event data.
• Do not restore backups created on virtual Firepower Management Centers to physical Firepower
Management Centers — this may stress system resources.
Note If you add licenses after a backup has completed, these licenses will not be removed or overwritten if this
backup is restored. To prevent a conflict on restore, remove those licenses before restoring the backup,
noting where the licenses were used, and add and reconfigure them after restoring the backup. If a conflict
occurs, contact Support.
• Remove any licenses added to your appliance after a backup has completed before restoring the backup
to avoid a conflict on restore. See About Firepower Feature Licenses, on page 109 for more information.
• Confirm the appliance does not have the same intrusion event data as stored in the backup, because
restoring the backup under such conditions creates duplicate events. See About Intrusion Events, on
page 2275 for more information.
Procedure
What to Do Next
• Import the latest Cisco Rule Update; see Update Intrusion Rules One-Time Manually, on page 151. If
you re-deploy policies as part of the import, you do not need to deploy configuration changes (below).
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• Add and reconfigure any licenses you removed from your appliance before restoring the backup.
• Contact Support if your appliance shows a license conflict on restore.
Note The importing and exporting appliances must be running the same version of the Firepower System. For
access control and its subpolicies (including intrusion policies), the intrusion rule update version must
also match. If the versions do not match, the import fails. You cannot use the Import/Export feature to
update intrusion rules. Instead, download and apply the latest rule update version.
• FlexConfig policies. However, the contents of any secret key variables are cleared when you export the
policy. You must manually edit the values of all secret keys after importing a FlexConfig policy that
uses secret keys.
• Platform settings
• Health policies
• Alert responses
• Application detectors (both user-defined and those provided by Cisco Professional Services)
• Dashboards
• Custom tables
• Custom workflows
• Saved searches
• Custom user roles
• Report templates
• Third-party product and vulnerability mappings
Exporting Configurations
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin
Depending on the number of configurations being exported and the number of objects those configurations
reference, the export process may take several minutes.
Tip
Many list pages in the Firepower System include an export icon ( ) next to list items. Where this icon
is present, you can use it as a quick alternative to the export procedure that follows.
Procedure
Step 2 Check the configurations you want to export and click Export.
Step 3 Follow your web browser’s prompts to save the exported package to your computer.
Importing Configurations
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin
Depending on the number of configurations being imported and the number of objects those configurations
reference, the import process may take several minutes.
Note If you log out of the system, if you change to a different domain, or if your user session times out after
you click Import, the import process continues in the background until it is complete.
Procedure
Step 1 On the importing appliance, choose System > Tools > Import/Export.
Step 2 Click Upload Package.
Step 3 Enter the path to the exported package or browse to its location, then click Upload.
Step 4 If there are no version mismatches or other issues, choose the configurations you want to import, then click
Import.
If you do not need to perform any conflict resolution or interface object mapping, the import completes and
a success message appears. Skip the rest of this procedure.
Step 5 If prompted, on the Import Conflict Resolution page, map interface objects used in the imported configurations
to zones and groups with matching interface types managed by the importing Firepower Management Center.
Interface object type (security zone or interface group) and interface type (passive, inline, routed, and so on)
of source and destination objects must match. For information, see Interface Objects: Interface Groups and
Security Zones, on page 357.
If the configurations you are importing reference security zones or interface groups that do not already exist,
you can map them to existing interface objects, or create new ones.
What to Do Next
• Optionally, view a report summarizing the imported configurations; see Viewing Task Messages, on
page 268.
The resolution options the system offers depends on whether your deployment uses domains, and whether
the imported configuration is a duplicate of a configuration defined in the current domain, or a configuration
defined in an ancestor or descendant of the current domain. The following table lists when the system does
or does not present a resolution option.
When you import an access control policy with a file policy that uses clean or custom detection file lists and
a file list presents a duplicate name conflict, the system offers conflict resolution options as described in the
table above, but the action the system performs on the policies and file lists varies as described in the table
below:
If you modify an imported configuration on an appliance, and later re-import that configuration to the same
appliance, you must choose which version of the configuration to keep.
Note Some tasks (such as those involving automated software updates or that require pushing updates to managed
devices) may place a significant load on networks with low bandwidths. You should schedule tasks like
these to run during periods of low network use.
You set the frequency for a recurring task using the same process for all types of tasks.
Note that the time displayed on most pages on the web interface is the local time, which is determined by
using the time zone you specify in your local configuration. Further, the Firepower Management Center
automatically adjusts its local time display for daylight saving time (DST), where appropriate. However,
recurring tasks that span the transition dates from DST to standard time and back do not adjust for the transition.
That is, if you create a task scheduled for 2:00 AM during standard time, it will run at 3:00 AM during DST.
Similarly, if you create a task scheduled for 2:00 AM during DST, it will run at 1:00 AM during standard
time.
Procedure
Step 7 In the Run At field, specify the time when you want to start your recurring task.
Step 8 For a task to be run on a weekly or monthly basis, select the days when you want to run the task in the Repeat
On field.
Step 9 Select the remaining options for the type of task you are creating:
• Backup - Schedule backup jobs as described in Automating Firepower Management Center Backups,
on page 179.
• Download CRL - Schedule certificate revocation list downloads as described in Configuring Certificate
Revocation List Downloads, on page 181.
• Deploy Policies - Schedule policy deployment as described in Automating Policy Deployment, on page
182.
• Nmap Scan - Schedule Nmap scans as described in Scheduling an Nmap Scan, on page 183.
• Report - Schedule report generation as described in Automating Report Generation, on page 184
• Firepower Recommended Rules - Schedule automatic update of Firepower recommended rules as
described in Automating Firepower Recommendations, on page 185
• Download Latest Update - Schedule software or VDB update downloads as described in Automating
Software Downloads, on page 187 or Automating VDB Update Downloads, on page 190.
• Install Latest Update - Schedule installation of software or VDB updates on a Firepower Management
Center or managed device as described in Automating Software Installs, on page 189 or Automating
VDB Update Installs, on page 191
• Push Latest Update - Schedule push of software updates to managed devices as described in Automating
Software Pushes, on page 188.
• Update URL Filtering Database - Scheduling automatic update of URL filtering data as described in
Automating URL Filtering Updates, on page 192
Related Topics
Backup and Restore Introduction, on page 161
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
You must perform this procedure using the 7000 or 8000 Series device's local web interface.
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
You must perform this procedure using the local web interface for the Firepower Management Center or the
7000 or 8000 Series device. In a multidomain deployment, this task is only supported in the Global domain
for the Firepower Management Center.
The system automatically creates the Download CRL task when you enable downloading a certificate revocation
list (CRL) in the local configuration on an appliance where you enable user certificates or audit log certificates
for the appliance. You can use the scheduler to edit the task to set the frequency of the update.
Procedure
Step 7 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured on the Firepower
Management Center to send status messages.
Step 8 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
After modifying configuration settings in the Management Center, you must deploy those changes to the
affected devices.
In a multidomain deployment, you can schedule policy deployments only for your current domain.
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Out-of-Date Policies, on page 299
If you have not used the Nmap scanning capability before, you configure Nmap scanning before defining a
scheduled scan.
Related Topics
Nmap Scanning, on page 1872
After Nmap replaces a host’s operating system, applications, or servers detected by the system with the results
from an Nmap scan, the system no longer updates the information replaced by Nmap for the host.
Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan
to scan a host using Nmap, you may want to set up regularly scheduled scans to keep Nmap-supplied operating
systems, applications, or servers up to date. If the host is deleted from the network map and re-added, any
Nmap scan results are discarded and the system resumes monitoring of all operating system and service data
for the host.
In a multidomain deployment:
• You can schedule scans only for your current domain
• The remediation and Nmap targets you select must exist at your current domain or an ancestor domain.
• Choosing to perform an Nmap scan on a non-leaf domain scans the same targets in each descendant of
that domain.
Procedure
Step 10 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 11 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Note Configuring this option does not distribute the
reports.
Step 9 If you do not want to receive report email attachments when reports have no data (for example, when no
events of a certain type occurred during the report period), select the If report is empty, still attach to email
check box.
Step 10 Click Save.
You can automatically generate rule state recommendations based on network discovery data for your network
using the most recently saved configuration settings in a custom intrusion policy.
Note If the system automatically generates scheduled recommendations for an intrusion policy with unsaved
changes, you must discard your changes in that policy and commit the policy if you want the policy to
reflect the automatically generated recommendations.
When the task runs, the system automatically generates recommended rule states, and modifies the states of
intrusion rules based on the configuration of your policy. Modified rule states take effect the next time you
deploy your intrusion policy.
In a multidomain deployment, you can automate recommendations for intrusion policies at the current domain
level. The system builds a separate network map for each leaf domain. In a multidomain deployment, if you
enable this feature in an intrusion policy in an ancestor domain, the system generates recommendations using
data from all descendant leaf domains. This can enable intrusion rules tailored to assets that may not exist in
all leaf domains, which can affect performance.
Procedure
Step 8 (Optional) To email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field.
Step 9 Click Save.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
About Firepower Recommended Rules, on page 1533
Configuring a Mail Relay Host and Notification Address, on page 909
Note Cisco strongly recommends that you use your Management Centers to update the devices they manage.
• To update the Management Center, schedule the software installation using the Install Latest Update
task.
• To use a Management Center to automate software updates for its managed devices, you must schedule
two tasks:
◦Push (copy) the update to managed devices using the Push Latest Update task.
◦Install the update on managed devices using the Install Latest Update task.
When scheduling updates to managed devices, schedule the push and install tasks to happen in succession;
you must first push the update to the device before you can install it. To automate software updates on
a device group, you must select all the devices within the group. Allow enough time between tasks for
the process to complete; schedule tasks at least 30 minutes apart. If you schedule a task to install an
update and the update has not finished copying from the Management Center to the device, the installation
task will not succeed. However, if the scheduled installation task repeats daily, it will install the pushed
update when it runs the next day.
Note You must manually upload and install updates in two situations. First, you cannot schedule major updates
to the Firepower System. Second, you cannot schedule updates for or pushes from Management Center
that cannot access the Support Site. If your Management Center is not directly connected to the Internet,
you should use management interfaces configuration to set up a proxy to allow it to download updates
from the Support Site.
Note that a task scheduled to install an update on a device group will install the pushed update to each device
within the device group simultaneously. Allow enough time for the scheduled task to complete for each device
within the device group.
If you want to have more control over this process, you can use the Once option to download and install
updates during off-peak hours after you learn that an update has been released.
Related Topics
Management Interfaces, on page 875
System Software Updates Introduction, on page 131
You can create a scheduled task that automatically downloads the latest software updates from Cisco. You
can use this task to schedule download of updates you plan to install manually.
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
If you want to automate the installation of software updates on managed devices, you must push the updates
to the devices before installing.
When you create the task to push software updates to managed devices, make sure you allow enough time
between the push task and a scheduled install task for the updates to be copied to the device.
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Make sure you allow enough time between the task that pushes the update to a managed device and the task
that installs the update.
Caution Depending on the update being installed, the appliance may reboot after the software is installed.
Procedure
Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 10 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Caution Installing a vulnerability database (VDB) update or deploying an access control policy for the first time
after installing a VDB update immediately restarts the Snort process, temporarily interrupting traffic
inspection. Whether traffic drops during this interruption or passes without further inspection depends on
the model of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page
293 for more information.
Allow enough time between tasks for the process to complete. For example, if you schedule a task to install
an update and the update has not fully downloaded, the installation task will not succeed. However, if the
scheduled installation task repeats daily, it will install the downloaded VDB update when the task runs the
next day.
Note:
• You cannot schedule updates for appliances that cannot access the Support Site. If your Management
Center is not directly connected to the Internet, you should use management interfaces configuration to
set up a proxy to allow it to download updates from the Support Site.
• If you want to have more control over this process, you can use the Once option to download and install
VDB updates during off-peak hours after you learn that an update has been released.
• In multidomain deployments, you can only schedule VDB updates for the Global domain. The changes
take effect when you redeploy policies.
Related Topics
Management Interfaces, on page 875
Procedure
Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Allow enough time between the task that downloads the VDB update and the task that installs the update.
Caution Installing a vulnerability database (VDB) update or deploying an access control policy for the first time
after installing a VDB update immediately restarts the Snort process, temporarily interrupting traffic
inspection. Whether traffic drops during this interruption or passes without further inspection depends on
the model of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page
293 for more information.
Procedure
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
You can use the scheduler to automate updates of URL filtering data from Cisco Collective Security Intelligence
(CSI).
Note that when you enable URL filtering, you can also enable automatic updates. This forces the Management
Center to contact CSI every 30 minutes for URL filtering data updates.
Note If you enabled automatic updates when you enabled URL filtering, do not create a scheduled task to update
URL filtering data. Schedule a task only if you want strict control over URL filtering updates.
Although daily updates tend to be small, if it has been more than five days since your last update, new URL
filtering data may take up to 20 minutes to download, depending on your bandwidth. Then, it may take up to
30 minutes to perform the update itself.
Procedure
Step 7 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 8 Click Save.
Related Topics
Configuring a Mail Relay Host and Notification Address, on page 909
Column Description
Name Displays the name of the scheduled task and the comment associated with it.
Last Run Time Displays the actual start date and time.
For a recurring task, this applies to the most recent execution.
Last Run Status Describes the current status for a scheduled task:
•
A check mark icon ( ) indicates that the task ran successfully.
•
A question mark icon ( ) indicates that the task is in an unknown state.
•
An exclamation mark icon ( ) indicates that the task failed.
Next Run Time Displays the next execution time for a recurring task.
Displays N/A for a one-time task.
Creator Displays the name of the user that created the scheduled task.
In a multidomain deployment, you can view scheduled tasks only for your current domain.
Procedure
In a multidomain deployment, you can edit scheduled tasks only for your current domain.
Procedure
In a multidomain deployment, you can delete scheduled tasks only for your current domain.
Procedure
You can use the database purge page to purge discovery, identity, connection, and Security Intelligence data
files from the Management Center databases. Note that when you purge a database, the appropriate process
is restarted.
Caution Purging a database removes the data you specify from the Firepower Management Center. After the data
is deleted, it cannot be recovered.
Procedure
Note Checking the Connection Events check box does not remove Security Intelligence events.
Connections with Security Intelligence data will still appear in the Security Intelligence event viewer.
Correspondingly, checking the Security Intelligence Events check box does not remove connection
events with associated Security Intelligence data.
Step 4 Click Purge Selected Events.
The items are purged and the appropriate processes are restarted.
About Dashboards
Firepower System dashboards provide you with at-a-glance views of current system status, including data
about the events collected and generated by the system. You can also use dashboards to see information about
the status and overall health of the appliances in your deployment. Keep in mind that the information the
dashboard provides depends on how you license, configure, and deploy the system.
Tip The dashboard is a complex, highly customizable monitoring feature that provides exhaustive data. For
a broad, brief, and colorful picture of your monitored network, use the Context Explorer. Dashboards are
available on the Firepower Management Center and 7000 & 8000 Series devices.
A dashboard uses tabs to display widgets: small, self-contained components that provide insight into different
aspects of the system. For example, the predefined Appliance Information widget tells you the appliance
name, model, and currently running version of the Firepower System software. The system constrains widgets
by the dashboard time range, which you can change to reflect a period as short as the last hour or as long as
the last year.
The system is delivered with several predefined dashboards, which you can use and modify. If your user role
has access to dashboards (Administrator, Maintenance User, Security Analyst, Security Analyst [Read Only],
and custom roles with the Dashboards permission), by default your home page is the predefined Summary
Dashboard. However, you can configure a different default home page, including non-dashboards. You can
also change the default dashboard. Note that if your user role cannot access dashboards, your default home
page is relevant to the role; for example, a Discovery Admin sees the Network Discovery page.
You can also use predefined dashboards as the base for custom dashboards, which you can either share or
restrict as private. Unless you have Administrator access, you cannot view or modify private dashboards
created by other users.
Note Some drill-down pages and table views of events include a Dashboard toolbar link that you can click to
view a relevant predefined dashboard. If you delete a predefined dashboard or tab, the associated toolbar
links do not function.
In a multidomain deployment, you cannot view dashboards from ancestor domains; however, you can create
new dashboards that are copies of the higher-level dashboards.
In addition, each dashboard has a set of preferences that determines its behavior.
You can minimize and maximize widgets, add and remove widgets from tabs, as well as rearrange the widgets
on a tab.
Note For widgets that display event counts over a time range, the total number of events may not reflect the
number of events for which detailed data is available in the event viewer. This occurs because the system
sometimes prunes older event details to manage disk space usage. To minimize the occurrence of event
detail pruning, you can fine-tune event logging to log only those events most important to your deployment.
Widget Availability
The dashboard widgets that you can view depend on the type of appliance you are using, your user role, and
your current domain (in a multidomain deployment).
In a multidomain deployment, if you do not see a widget that you expect to see, switch to the Global domain.
See Switching Domains on the Firepower Management Center, on page 27.
Note that:
• An invalid widget is one that you cannot view because you are using the wrong type of appliance.
• An unauthorized widget is one that you cannot view because your user account does not have the
necessary privileges.
For example, the Appliance Status widget is available only on the Management Center for users with
Administrator, Maintenance User, Security Analyst, or Security Analyst (Read Only) account privileges.
Although you cannot add an unauthorized or invalid widget to a dashboard, an imported dashboard may
contain unauthorized or invalid widgets. For example, such widgets can be present if the imported dashboard:
• Was created by a user with different access privileges, or
• Belongs to an ancestor domain.
Unavailable widgets are disabled and display error messages that indicate why you cannot view them.
Individual widgets also display error messages when those widgets have timed out or are otherwise experiencing
problems.
Note You can delete or minimize unauthorized and invalid widgets, as well as widgets that display no data,
keeping in mind that modifying a widget on a shared dashboard modifies it for all users of the appliance.
Note The dashboard widgets you can view depend on the type of appliance you are using, your user role, and
your current domain in a multidomain deployment.
You can configure the widget to display more or less information by modifying the widget preferences to
display a simple or an advanced view; the preferences also control how often the widget updates.
The color of the ball representing link state indicates the current status, as follows:
• green: link is up and at full speed
• yellow: link is up but not at full speed
• red: link is not up
Note A red-shaded Custom Analysis widget indicates that its use is harming system performance. If the widget
continues to stay red over time, remove the widget. You can also disable all Custom Analysis widgets
from the Dashboard settings in your system configuration (System > Configuration > Dashboard)
The direction icon ( ) indicates and controls the sort order of the display. A downward-pointing icon indicates
descending order; an upward-pointing icon indicates ascending order. To change the sort order, click the icon.
Next to each event, the widget can display one of three icons to indicate any changes from the most recent
results:
• The new event icon ( ) signifies that the event is new to the results.
• The up arrow icon ( ) indicates that the event has moved up in the standings since the last time the
widget updated. A number indicating how many places the event has moved up appears next to the icon.
• The down arrow icon ( ) indicates that the event has moved down in the standings since the last time
the widget updated. A number indicating how many places the event has moved down appears next to
the icon.
Note In a multidomain deployment, the system builds a separate network map for each leaf domain. As a result,
a leaf domain can contain an IP address that is unique within its network, but identical to an IP address
in another leaf domain. When you view Custom Analysis widgets in an ancestor domain, multiple instances
of that repeated IP address can be displayed. At first glance, they might appear to be duplicate entries.
However, if you drill down to the host profile information for each IP address, the system shows that they
belong to different leaf domains.
On the other hand, aggregating by Unique Events tells you how many unique intrusion events of each type
have occurred (for example, how many detections of network trojans, potential violations of corporate policy,
attempted denial-of-service attacks, and so on).
You can further constrain the widget using a saved search, either one of the predefined searches delivered
with your appliance or a custom search that you created. For example, constraining the first example (intrusion
events using the Classification field, aggregated by Count) using the Dropped Events search tells you how
many intrusion events of each type were dropped.
Related Topics
Modifying Dashboard Time Settings, on page 219
Preference Details
Title If you do not specify a title for the widget, the system uses the configured event type as the title.
Preset Custom Analysis presets provide quick access to information about your deployment. The predefined
dashboards make extensive use of these presets. You can use these presets or you can create a custom
configuration.
Table (required) The table of events or assets that contains the data the widget displays.
Field (required) The specific field of the event type you want to display. To show data over time (line graphs), choose
Time. To show relative occurrences of events (bar graphs), choose another option.
Aggregate (required) The aggregation method configures how the widget groups the data it displays. For most event types, the
default option is Count.
Filter You can use application filters to constrain data from the Application Statistics and Intrusion Event
Statistics by Application tables.
Search You can use a saved search to constrain the data that the widget displays. You do not have to specify a
search, although some presets use predefined searches.
Only you can access searches that you have saved as private. If you configure the widget on a shared
dashboard and constrain its events using a private search, the widget resets to not using the search when
another user logs in. This affects your view of the widget as well. If you want to make sure that this does
not happen, save the dashboard as private.
Only fields that constrain connection summaries can constrain Custom Analysis dashboard widgets based
on connection events. Invalid saved searches are dimmed.
If you constrain a Custom Analysis widget using a saved search, then edit the search, the widget does
not reflect your changes until the next time it updates.
Preference Details
Show Choose whether you want to display the most (Top) or the least (Bottom) frequently occurring events.
Show Movers Choose whether you want to display the icons that indicate changes from the most recent results.
Time Zone Choose the time zone you want to use to display results.
Color You can change the color of the bars in the widget's bar graph.
Related Topics
Configuring Widget Preferences, on page 216
From a Custom Analysis widget, you can invoke an event view (workflow) that provides detailed information
about the events displayed in the widget. The events appear in the default workflow for that event type,
constrained by the dashboard time range. This also changes the appropriate time window on the Firepower
Management Center, depending on how many time windows you configured and on the event type.
For example:
• If you configure multiple time windows, then access health events from a Custom Analysis widget, the
events appear in the default health events workflow, and the health monitoring time window changes
to the dashboard time range.
• If you configure a single time window and then access any type of event from the Custom Analysis
widget, the events appear in the default workflow for that event type, and the global time window changes
to the dashboard time range.
Procedure
Updates all files related to updates, such as rule updates and system updates
You can hover your pointer over a disk usage category in the By Category stacked bar to view the percentage
of available disk space used by that category, the actual storage space on the disk, and the total disk space
available for that category. Note that if you have a malware storage pack installed, the total disk space available
for the Files category is the available disk space on the malware storage pack.
You can configure the widget to display only the By Category stacked bar, or you can show the stacked bar
plus the admin (/), /Volume, and /boot partition usage, as well as the /var/storage partition if the malware
storage pack is installed, by modifying the widget preferences.
The widget preferences also control how often the widget updates, as well as whether it displays the current
disk usage or collected disk usage statistics over the dashboard time range.
The widget preferences control how often the widget updates. On 7000 & 8000 Series devices, the preferences
also control whether the widget displays the traffic rate for unused interfaces (by default, the widget only
displays the traffic rate for active interfaces).
The resulting event view is constrained by the dashboard time range; accessing intrusion events via the
dashboard changes the events (or global) time window for the appliance. Note that packets in a passive
deployment are not dropped, regardless of intrusion rule state or the inline drop behavior of the intrusion
policy.
The Network Compliance over Time (%) style displays a stacked area graph showing the relative proportion
of hosts that are compliant, non-compliant, and that have not yet been evaluated, over the dashboard time
range.
The Network Compliance over Time style displays a line graph that shows the number of hosts that are
compliant, non-compliant, and that have not yet been evaluated, over the dashboard time range.
The preferences control how often the widget updates. You can check the Show Not Evaluated box to hide
events which have not been evaluated.
Feeds update every 24 hours (although you can manually update the feed), and the widget displays the last
time the feed was updated based on the local time of the appliance. Keep in mind that the appliance must have
access to the web site (for the two preconfigured feeds) or to any custom feed you configure.
When you configure the widget, you can also choose how many stories from the feed you want to show in
the widget, as well as whether you want to show descriptions of the stories along with the headlines; keep in
mind that not all RSS feeds use descriptions.
On the RSS Feed widget, you can:
• click one of the stories in the feed to view the story
• click the more link to go to the feed’s web site
• click the update icon ( ) to manually update the feed
Managing Dashboards
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Any
Security
Analyst/Maint
Procedure
Step 1 Choose Overview > Dashboards, and then choose the dashboard you want to modify from the menu.
Step 2 Manage your dashboards:
• Create Dashboards — Create a custom dashboard; see Creating Custom Dashboards, on page 217.
• Delete Dashboards — To delete a dashboard, click the delete icon ( ) next to the dashboard you want
to delete. If you delete your default dashboard, you must define a new default or the appliance prompts
you to choose a dashboard every time you attempt to view a dashboard.
• Edit Options — Edit custom dashboard options; see Editing Dashboards Options, on page 219.
• Modify Time Constraints — Modify the time display or pause/unpause the dashboard as described in
Modifying Dashboard Time Settings, on page 219.
Tip Every configuration of the Custom Analysis widget in the Cisco predefined dashboards corresponds
to a system preset for that widget. If you change or delete one of these widgets, you can restore it by
creating a new Custom Analysis widget based on the appropriate preset.
Procedure
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 221.
Step 2 Click the add icon ( ) next to the last existing tab.
Step 3 Enter a name for the tab.
Step 4 Click OK.
Each tab can display one or more widgets in a three-column layout. When adding a widget to a dashboard,
you choose the tab to which you want to add the widget. The system automatically adds it to the column with
the fewest widgets. If all columns have an equal number of widgets, the new widget is added to the leftmost
column. You can add a maximum of 15 widgets to a dashboard tab.
Tip After you add widgets, you can move them to any location on the tab. You cannot, however, move widgets
from tab to tab.
The dashboard widgets you can view depend on the type of appliance you are using, your user role, and your
current domain (in a multidomain deployment). Keep in mind that because not all user roles have access to
all dashboard widgets, users with fewer permissions viewing a dashboard created by a user with more
permissions may not be able to use all of the widgets on the dashboard. Although the unauthorized widgets
still appear on the dashboard, they are disabled.
Procedure
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 221.
Step 2 Click the tab where you want to add the widget.
Step 3 Click Add Widgets. You can view the widgets in each category by clicking on the category name, or you
can view all widgets by clicking All Categories.
Step 4 Click Add next to the widgets you want to add. The Add Widgets page indicates how many widgets of each
type are on the tab, including the widget you want to add.
Tip To add multiple widgets of the same type (for example, you may want to add multiple RSS Feed
widgets, or multiple Custom Analysis widgets), click Add again.
Step 5 When you are finished adding widgets, click Done to return to the dashboard.
What to Do Next
• If you added a Custom Analysis widget, configure the widget preferences; see Configuring Widget
Preferences, on page 216.
Related Topics
Widget Availability, on page 202
Procedure
Step 1 On the title bar of the widget whose preferences you want to change, click the show preferences icon ( ).
Step 2 Make changes as needed.
Step 3 On the widget title bar, click the hide preferences icon ( ) to hide the preferences section.
Tip Instead of creating a new dashboard, you can export a dashboard from another appliance, then import it
onto your appliance. You can then edit the imported dashboard to suit your needs.
Procedure
Option Description
Copy Dashboard When you create a custom dashboard, you can choose to base it on any existing dashboard,
whether user-created or system-defined. This option makes a copy of the preexisting dashboard,
which you can modify to suit your needs. Optionally, you can create a blank new dashboard
by choosing None. This option is available only when you create a new dashboard.
In a multidomain deployment, you can copy any non-private dashboards from ancestor domains.
Change Tabs Every Specifies (in minutes) how often the dashboard should cycle through its tabs. Unless you pause
the dashboard or your dashboard has only one tab, this setting advances your view to the next
tab at the interval you specify. To disable tab cycling, enter 0 in the Change Tabs Every field.
Option Description
Refresh Page Every Specifies (in minutes) how often the current dashboard tab should refresh with new data. This
value must be greater than the Change Tabs Every setting. Unless you pause the dashboard,
this setting will refresh the entire dashboard at the interval you specify. To disable the periodic
page refresh, enter 0 in the Refresh Page Every field. Determines how often the entire
dashboard page automatically refreshes.
Refreshing the entire dashboard allows you to see any preference or layout changes that were
made to a shared dashboard by another user, or that you made to a private dashboard on another
computer, since the last time the dashboard refreshed. A frequent refresh can be useful, for
example, in a networks operations center (NOC) where a dashboard is displayed at all times.
If you make changes to the dashboard at a local computer, the dashboard in the NOC
automatically refreshes at the interval you specify, and no manual refresh is required. Note
that you do not need to refresh the entire dashboard to see data updates; individual widgets
update according to their preferences.
Note This setting is separate from the update interval available on many individual widgets;
although refreshing the dashboard page resets the update interval on individual widgets,
widgets will update according to their individual preferences even if you disable the
Refresh Page Every setting.
Save As Private Determines whether the custom dashboard can be viewed and modified by all users of the
appliance or is associated with your user account and reserved solely for your own use. Keep
in mind that any user with dashboard access, regardless of role, can modify shared dashboards.
If you want to make sure that only you can modify a particular dashboard, save it as private.
You can minimize and maximize widgets, as well as rearrange the widgets on a tab.
Procedure
• To minimize or maximize a widget on the dashboard, click the minimize ( ) or maximize icon ( )
in a widget’s title bar.
• To delete a widget if you no longer want to view it on a tab, click the close icon ( ) in the title bar of
the widget.
Procedure
Step 1 View the dashboard you want to edit; see Viewing Dashboards, on page 221.
Step 2 Click the edit icon ( ) next to the dashboard you want to modify.
Step 3 Change the options as described in Custom Dashboard Options, on page 217.
Step 4 Click Save.
You can change the time range to reflect a period as short as the last hour (the default) or as long as the last
year. When you change the time range, the widgets that can be constrained by time automatically update to
reflect the new time range.
Note that not all widgets can be constrained by time. For example, the dashboard time range has no effect on
the Appliance Information widget, which provides information that includes the appliance name, model, and
current version of the Firepower System software.
Keep in mind that for enterprise deployments of the Firepower System, changing the time range to a long
period may not be useful for widgets like the Custom Analysis widget, depending on how often newer events
replace older events.
You can also pause a dashboard, which allows you to examine the data provided by the widgets without the
display changing and interrupting your analysis. Pausing a dashboard has the following effects:
• Individual widgets stop updating, regardless of any Update Every widget preference.
• Dashboard tabs stop cycling, regardless of the Cycle Tabs Every setting in the dashboard properties.
• Dashboard pages stop refreshing, regardless of the Refresh Page Every setting in the dashboard
properties.
• Changing the time range has no effect.
When you are finished with your analysis, you can unpause the dashboard. Unpausing the dashboard causes
all appropriate widgets on the page to update to reflect the current time range. In addition, dashboard tabs
resume cycling and the dashboard page resumes refreshing according to the settings you specified in the
dashboard properties.
If you experience connectivity problems or other issues that interrupt the flow of system information to the
dashboard, the dashboard automatically pauses and an error notice appears until the problem is resolved.
Note Your session normally logs you out after 1 hour of inactivity (or another configured interval), regardless
of whether the dashboard is paused. If you plan to passively monitor the dashboard for long periods of
time, consider exempting some users from session timeout, or changing the system timeout settings.
Procedure
Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 221.
Step 2 Optionally, to change the dashboard time range, choose a time range from the Show the Last drop-down list.
Step 3 Optionally, pause or unpause the dashboard on the time range control, using the pause ( ) or play icon ( ).
Procedure
Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 221.
Step 2 Click the tab title you want to rename.
Step 3 Type a name for the tab.
Step 4 Click OK.
Viewing Dashboards
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Any
Security
Analyst/Maint
By default, the home page for your appliance displays the default dashboard. If you do not have a default
dashboard defined, the home page shows the Dashboard Management page, where you can choose a dashboard
to view.
Procedure
You can use the health monitor to create a collection of tests, referred to as a health policy, and apply the
health policy to one or more appliances. The tests, referred to as health modules, are scripts that test for criteria
you specify. You can modify a health policy by enabling or disabling tests or by changing test settings, and
you can delete health policies that you no longer need. You can also suppress messages from selected appliances
by blacklisting them.
The tests in a health policy run automatically at the interval you configure. You can also run all tests, or a
specific test, on demand. The health monitor collects health events based on the test conditions configured.
Note All Appliances automatically report their hardware status via the Hardware Alarms health module. The
Firepower Management Center also automatically reports status using the modules configured in the
default health policy. Some health modules, such as the Appliance Heartbeat module, run on the Firepower
Management Center and report the status of the Firepower Management Center's managed devices. Some
health modules do not provide managed device status unless you apply a health policy configured with
those modules to a device.
You can use the health monitor to access health status information for the entire system, for a particular
appliance, or, in a multidomain deployment, a particular domain. Pie charts and status tables on the Health
Monitor page provide a visual summary of the status of all appliances on your network, including the Firepower
Management Center. Individual appliance health monitors let you drill down into health details for a specific
appliance.
Fully customizable event views allow you to quickly and easily analyze the health status events gathered by
the health monitor. These event views allow you to search and view event data and to access other information
that may be related to the events you are investigating. For example, if you want to see all the occurrences of
CPU usage with a certain percentage, you can search for the CPU usage module and enter the percentage
value.
You can also configure email, SNMP, or syslog alerting in response to health events. A health alert is an
association between a standard alert and a health status level. For example, if you need to make sure an
appliance never fails due to hardware overload, you can set up an email alert. You can then create a health
alert that triggers that email alert whenever CPU, disk, or memory usage reaches the Warning level you
configure in the health policy applied to that appliance. You can set alerting thresholds to minimize the number
of repeating alerts you receive.
You can also generate troubleshooting files for an appliance if you are asked to do so by Support.
Because health monitoring is an administrative activity, only users with administrator user role privileges can
access system health data.
Health Modules
Health modules, or health tests, test for the criteria you specify in a health policy.
Appliance Heartbeat Any This module determines if an appliance heartbeat is being heard from the
appliance and alerts based on the appliance heartbeat status.
Automatic Application 7000 & 8000 Series This module determines if an appliance has been bypassed because it did not
Bypass Status respond within the number of seconds set in the bypass threshold, and alerts
when a bypass occurs.
Backlog Status Management Center This module displays an alert if the backlog of event data awaiting transmission
from the device to the Management Center has grown continuously for more
than 30 minutes.
To reduce the backlog, evaluate your bandwidth and consider logging fewer
events.
Classic License Monitor Management Center This module determines if sufficient Classic licenses for Control, Protection,
URL Filtering, Malware, and VPN remain. It also alerts when devices in a
stack have mismatched license sets. It alerts based on a warning level
automatically configured for the module. You cannot change the configuration
of this module.
CPU Usage Any This module checks that the CPU on the appliance is not overloaded and alerts
when CPU usage exceeds the percentages configured for the module.
Card Reset Any This module checks for network cards which have restarted due to hardware
failure and alerts when a reset occurs.
Cluster Status Threat Defense This module monitors the status of device clusters. The module alerts if:
• A new primary unit is elected to a cluster.
• A new secondary unit joins a cluster.
• A primary or secondary unit leaves a cluster.
Disk Usage Any This module compares disk usage on the appliance’s hard drive and malware
storage pack to the limits configured for the module and alerts when usage
exceeds the percentages configured for the module. This module also alerts
when the system excessively deletes files in monitored disk usage categories,
or when disk usage excluding those categories reaches excessive levels, based
on module thresholds. Use the Disk Usage health status module to monitor
disk usage for the / and /volume partitions on the appliance and track draining
frequency. Although the disk usage module lists the /boot partition as a
monitored partition, the size of the partition is static so the module does not
alert on the boot partition.
Host Limit Management Center This module determines if the number of hosts the Firepower Management
Center can monitor is approaching the limit and alerts based on the warning
level configured for the module. For more information, see Firepower System
Host Limit, on page 1848.
Hardware Alarms 7000 & 8000 Series, This module determines if hardware needs to be replaced on a physical managed
Threat Defense device and alerts based on the hardware status. The module also reports on the
(physical) status of hardware-related daemons and on the status of 7000 and 8000 Series
devices in high-availability deployments.
HA Status Management Center This module monitors and alerts on the high availability status of the Firepower
Management Center. If you have not established Firepower Management Center
high availability, the HA Status is Not in HA.
This module does not monitor or alert on the high availability status of managed
devices, regardless of whether they are paired. The HA Status for a managed
device is always Not in HA. Use the device management page Devices >
Device Management to monitor devices in high availability pairs.
Health Monitor Process Any This module monitors the status of the health monitor itself and alerts if the
number of minutes since the last health event received by the Firepower
Management Center exceeds the Warning or Critical limits.
Inline Link Mismatch Any managed device This module monitors the ports associated with inline sets and alerts if the two
Alarms except ASA FirePOWER interfaces of an inline pair negotiate different speeds.
The maximum number of events you can set for either limit is 999, and the
Critical limit must be higher than the Warning limit.
Interface Status Any This module determines if the device currently collects traffic and alerts based
on the traffic status of physical interfaces and aggregate interfaces. For physical
interfaces, the information includes interface name, link state, and bandwidth.
For aggregate interfaces, the information includes interface name, number of
active links, and total aggregate bandwidth.
For ASA FirePOWER, interfaces labeled DataPlaneInterfacex, where x is a
numerical value, are internal interfaces (not user-defined) and involve packet
flow within the system.
Link State Propagation Any except NGIPSv and This module determines when a link in a paired inline set fails and triggers the
ASA FirePOWER link state propagation mode.
If a link state propagates to the pair, the status classification for that module
changes to Critical and the state reads:
Local Malware Analysis Any This module alerts if a device is configured for local malware analysis and
fails to download local malware analysis engine signature updates from the
AMP cloud.
Platform Faults Firepower 2100 On Firepower 2100 devices, a fault is a mutable object that is managed by the
Firepower Management Center. Each fault represents a failure in the Firepower
2100 instance or an alarm threshold that has been raised. During the lifecycle
of a fault, it can change from one state or severity to another.
Each fault includes information about the operational state of the affected
object at the time the fault was raised. If the fault is transitional and the failure
is resolved, then the object transitions to a functional state.
For more information, see the Cisco Firepower 2100 FXOS Faults and Error
Messages Guide.
Power Supply Physical Management This module determines if power supplies on the device require replacement
Centers,7000 & 8000 and alerts based on the power supply status.
Series Note If an 8000 Series managed device experiences a power failure, it may
take up to 20 minutes to generate an alert.
Process Status Any This module determines if processes on the appliance exit or terminate outside
of the process manager. If a process is deliberately exited outside of the process
manager, the module status changes to Warning and the health event message
indicates which process exited, until the module runs again and the process
has restarted. If a process terminates abnormally or crashes outside of the
process manager, the module status changes to Critical and the health event
message indicates the terminated process, until the module runs again and the
process has restarted.
Reconfiguring Detection Any managed device This module alerts if a device reconfiguration has failed.
RRD Server Process Management Center This module determines if the round robin data server that stores time series
data is running properly. The module will alert If the RRD server has restarted
since the last time it updated; it will enter Critical or Warning status if the
number of consecutive updates with an RRD server restart reaches the numbers
specified in the module configuration.
Time Series Data Management Center This module tracks the presence of corrupt files in the directory where time
Monitor series data (such as correlation event counts) are stored and alerts when files
are flagged as corrupt and removed.
Time Synchronization Any This module tracks the synchronization of a device clock that obtains time
Status using NTP with the clock on the NTP server and alerts if the difference in the
clocks is more than ten seconds.
URL Filtering Monitor Management Centers This module tracks communications between the Firepower Management
Center and its managed devices, as well as with Cisco Collective Security
Intelligence (CSI), where the system obtains threat intelligence for commonly
visited URLs. The module alerts if the Firepower Management Center fails to
successfully communicate with or retrieve an update from Cisco CSI.
This module also alerts if the Firepower Management Center cannot push URL
data to your managed devices.
User Agent Status Management Center This module alerts when heartbeats are not detected for any User Agents
Monitor connected to the Firepower Management Center.
Procedure
Step 1 Determine which health modules you want to monitor as discussed in Health Modules, on page 224.
You can set up specific policies for each kind of appliance you have in your Firepower System, enabling only
the appropriate tests for that appliance.
Tip To quickly enable health monitoring without customizing the monitoring behavior, you can apply the
default policy provided for that purpose.
Step 2 Apply a health policy to each appliance where you want to track health status as discussed in Creating Health
Policies, on page 231.
Step 3 (Optional.) Configure health monitor alerts as discussed in Creating Health Monitor Alerts, on page 237.
You can set up email, syslog, or SNMP alerts that trigger when the health status level reaches a particular
severity level for specific health modules.
Health Policies
A health policy contains configured health test criteria for several modules. You can control which health
modules run against each of your appliances and configure the specific limits used in the tests run by each
module.
When you configure a health policy, you decide whether to enable each health module for that policy. You
also select the criteria that control which health status each enabled module reports each time it assesses the
health of a process.
You can create one health policy that can be applied to every appliance in your system, customize each health
policy to the specific appliance where you plan to apply it, or use the default health policy provided for you.
In a multidomain deployment, administrators in ancestor domains can apply health policies to devices in
descendant domains, which descendant domains can use or replace with customized local policies.
If you want to customize a health policy to use with your appliances, you can create a new policy. The settings
in the policy initially populate with the settings from the health policy you choose as a basis for the new policy.
You can enable or disable modules within the policy and change the alerting criteria for each module as
needed.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain. Administrators in ancestor domains can apply health policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies.
Procedure
• To temporarily save your changes to this module and switch to another module’s settings to modify,
choose the other module from the list at the left of the page. If you click Save Policy and Exit when
you are done, all changes you made will be saved; if you click Cancel, you discard all changes.
What to Do Next
• Apply the health policy to each appliance as described in Applying Health Policies, on page 232. This
applies your changes and updates the policy status for all affected policies.
When you apply a health policy to an appliance, the health tests for all the modules you enabled in the policy
automatically monitor the health of the processes and hardware on the appliance. Health tests then continue
to run at the intervals you configured in the policy, collecting health data for the appliance and forwarding
that data to the Firepower Management Center.
If you enable a module in a health policy and then apply the policy to an appliance that does not require that
health test, the health monitor reports the status for that health module as disabled.
If you apply a policy with all modules disabled to an appliance, it removes all applied health policies from
the appliance so no health policy is applied.
When you apply a different policy to an appliance that already has a policy applied, expect some latency in
the display of new data based on the newly applied tests.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain. Administrators in ancestor domains can apply health policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies.
Procedure
What to Do Next
• Optionally, monitor the task status; see Viewing Task Messages, on page 268.
Monitoring of the appliance starts as soon as the policy is successfully applied.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain. Administrators in ancestor domains can apply health policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies.
Procedure
What to Do Next
• Reapply the health policy as described in Applying Health Policies, on page 232. This applies your
changes and updates the policy status for all affected policies.
You can delete health policies that you no longer need. If you delete a policy that is still applied to an appliance,
the policy settings remain in effect until you apply a different policy. In addition, if you delete a health policy
that is applied to a device, any health monitoring alerts in effect for the device remain active until you disable
the underlying associated alert response.
In a multidomain deployment, you can only delete health policies created in the current domain.
Tip To stop health monitoring for an appliance, create a health policy with all modules disabled and apply it
to the appliance.
Procedure
Note On a Firepower Management Center, Health Monitor blacklist settings are local configuration settings.
Therefore, if you blacklist a device, then delete it and later re-register it with the Firepower Management
Center, the blacklist settings remain persistent. The newly re-registered device remains blacklisted.
In a multidomain deployment, administrators in ancestor domains can blacklist an appliance or health module
in descendant domains. However, administrators in the descendant domains can override the ancestor
configuration and clear the blacklist for devices in their domain.
Blacklisting Appliances
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Maint
You can blacklist appliances individually or by group, model, or associated health policy.
After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor Appliance
Module Summary and Device Management page. Health events for the appliance have a status of disabled.
If you need to set the events and health status for an individual appliance to disabled, you can blacklist the
appliance. After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor
Appliance Module Summary, and health events for the appliance have a status of disabled.
In a multidomain deployment, blacklisting an appliance in an ancestor domain blacklists it for all descendant
domains. Descendant domains can override this inherited configuration and clear the blacklisting. You can
only blacklist the Firepower Management Center at the Global level.
Procedure
You can blacklist individual health policy modules on appliances. You may want to do this to prevent events
from the module from changing the status for the appliance to warning or critical.
After the blacklist settings take effect, the appliance shows as Partially Blacklisted or All Modules Blacklisted
on the Blacklist page and in the Appliance Health Monitor Module Status Summary, but only in expanded
views on the main Appliance Status Summary page.
Tip Make sure that you keep track of individually blacklisted modules so you can reactivate them when you
need them. You may miss necessary warning or critical messages if you accidentally leave a module
disabled.
In a multidomain deployment, administrators in ancestor domains can blacklist health modules in descendant
domains. However, administrators in descendant domains can override this ancestor configuration and clear
the blacklisting for policies applied in their domains. You can only blacklist Firepower Management Center
health modules at the Global level.
Procedure
Severity Description
Critical The health test results met the criteria to trigger a Critical alert status.
Warning The health test results met the criteria to trigger a Warning alert status.
Normal The health test results met the criteria to trigger a Normal alert status.
Recovered The health test results met the criteria to return to a normal alert status, following a Critical or Warning alert status.
When you create a health monitor alert, you create an association between a severity level, a health module,
and an alert response. You can use an existing alert or configure a new one specifically to report on system
health. When the severity level occurs for the selected module, the alert triggers.
If you create or update a threshold in a way that duplicates an existing threshold, you are notified of the
conflict. When duplicate thresholds exist, the health monitor uses the threshold that generates the fewest alerts
and ignores the others. The timeout value for the threshold must be between 5 and 4,294,967,295 minutes.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.
Procedure
You can edit existing health monitor alerts to change the severity level, health module, or alert response
associated with the health monitor alert.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.
Procedure
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.
Procedure
What to Do Next
• Disable or delete the underlying alert response to ensure that alerting does not continue; see Firepower
Management Center Alert Responses, on page 2097.
The health monitor provides the compiled health status for all devices managed by the Firepower Management
Center, plus the Firepower Management Center. The health monitor is composed of:
• The status table — Provides a count of the managed appliances for this Firepower Management Center
by overall health status.
• The pie chart — Indicates the percentage of appliances currently in each health status category.
• The appliance list — Provides details on the health of the managed devices.
In a multidomain deployment, the health monitor in an ancestor domain displays data from all descendant
domains. In the descendant domains, it displays data from the current domain only.
Procedure
Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the
lower table. If the arrow points right, the appliance list is hidden.
Step 3 You have the following choices:
• View appliance health monitors; see Viewing Appliance Health Monitors, on page 241.
• Create health policies; see Creating Health Policies, on page 231.
• Create health monitor alerts; see Creating Health Monitor Alerts, on page 237.
Critical Red Indicates that the critical limits have been exceeded for at least one health module
on the appliance and the problem has not been corrected.
Warning Yellow Indicates that warning limits have been exceeded for at least one health module on
the appliance and the problem has not been corrected.
Normal Green Indicates that all health modules on the appliance are running within the limits
configured in the health policy applied to the appliance.
Recovered Green Indicates that all health modules on the appliance are running within the limits
configured in the health policy applied to the appliance, including modules that were
in a Critical or Warning state.
Disabled Blue Indicates that an appliance is disabled or blacklisted, that the appliance does not
have a health policy applied to it, or that the appliance is currently unreachable.
The Appliance Health Monitor provides a detailed view of the health status of an appliance.
In a multidomain deployment, you can view the health status of appliances in descendant domains.
Tip Your session normally logs you out after 1 hour of inactivity (or another configured interval). If you plan
to passively monitor health status for long periods of time, consider exempting some users from session
timeout, or changing the system timeout settings. See User Account Login Options, on page 69 and
Configuring Session Timeouts, on page 918 for more information.
Procedure
What to Do Next
• If you want to run all health modules for the appliance, see Running All Modules for an Appliance, on
page 242
• If you want to run a specific health module for an appliance, see Running a Specific Health Module,
on page 242
• If you want to generate health module alert graphs for the appliance, see Generating Health Module
Alert Graphs, on page 243
• If you want to produce troubleshooting files for the appliance, see Downloading Advanced
Troubleshooting Files, on page 271
• If you want to download advanced troubleshooting files for the appliance, see Downloading Advanced
Troubleshooting Files, on page 271
• If you want to execute Firepower Threat Defense CLI commands from the Firepower Management
Center web interface, see Using the Firepower Threat Defense CLI from the Web Interface, on page
272
Health module tests run automatically at the policy run time interval you configure when you create a health
policy. However, you can also run all health module tests on demand to collect up-to-date health information
for the appliance.
In a multidomain deployment, you can run health module tests for appliances in the current domain and in
any descendant domains.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Step 2 Click Run All Modules. The status bar indicates the progress of the tests, then the Health Monitor Appliance
page refreshes.
Note When you manually run health modules, the first refresh that automatically occurs may not reflect
the data from the manually run tests. If the value has not changed for a module that you just ran
manually, wait a few seconds, then refresh the page by clicking the device name. You can also wait
for the page to refresh again automatically.
Health module tests run automatically at the policy run time interval you configure when you create a health
policy. However, you can also run a health module test on demand to collect up-to-date health information
for that module.
In a multidomain deployment, you can run health module tests for appliances in the current domain and in
any descendant domains.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Step 2 In the Module Status Summary graph, click the color for the health alert status category you want to view.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Run.
The status bar indicates the progress of the test, then the Health Monitor Appliance page refreshes.
Note When you manually run health modules, the first refresh that automatically occurs may not reflect
the data from the manually run tests. If the value has not changed for a module that you just manually
ran, wait a few seconds, then refresh the page by clicking the device name. You can also wait for the
page to refresh automatically again.
You can graph the results over a period of time of a particular health test for a specific appliance.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Step 2 In the Module Status Summary graph of the Health Monitor Appliance page, click the color for the health
alert status category you want to view.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Graph.
Tip If no events appear, you may need to adjust the time
range.
The Table View of Health Events page provides a list of all health events on the specified appliance.
When you access health events from the Health Monitor page on your Firepower Management Center, you
retrieve all health events for all managed appliances.
In a multidomain deployment, you can view data for the current domain and for any descendant domains.
You cannot view data from higher level or sibling domains.
Tip You can bookmark this view to allow you to return to the page in the health events workflow containing
the Health Events table of events. The bookmarked view retrieves events within the time range you are
currently viewing, but you can then modify the time range to update the table with more recent information
if needed.
Procedure
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Step 2 In the Module Status Summary graph, click the color for the event status category you want to view.
The Alert Detail list toggles the display to show or hide events.
Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Events.
The Health Events page appears, containing results for a query with the name of the appliance and the name
of the specified health alert module as constraints. If no events appear, you may need to adjust the time range.
Step 4 If you want to view all health events for the specified appliance, expand Search Constraints, and click the
Module Name constraint to remove it.
In a multidomain deployment, you can view data for the current domain and for any descendant domains.
You cannot view data from higher level or sibling domains.
Procedure
• View Multiple — To view event details for multiple health events, choose the check box next to the
rows that correspond with the events you want to view details for and then click View.
• View Status — To view all events of a particular status, click the status icon in the Status column for
an event with that status.
Note The 8350 hardware platform has six fans, which display as FAN2 through FAN7. This is expected behavior.
If you receive a hardware alert related to FAN1 or fan numbering in general on the 8350 platform, you
can disregard the alert.
ftwo daemon status If the ftwo daemon goes down, health status for the Hardware Alarms
module changes to red and message details include a reference to the
daemon.
NFE cards detected Indicates the number of NFE cards detected on the system. If this value
does not match the appliance’s expected NFE count, the Hardware Alarms
module changes to red.
NFE hardware status If one or more NFE cards are not communicating, the Hardware Alarms
module changes to red and the applicable card appears in the message
details.
NFE heartbeat If the system detects no NFE heartbeat, the Hardware Alarms module
changes to red and message details include a reference to the relevant
card(s).
NFE internal link status If the link between the NMSB and NFE card(s) goes down, the Hardware
Alarms module changes to red and message details include a reference
to the relevant ports.
NFE Message daemon If the NFE Message daemon goes down, health status for the Hardware
Alarms module changes to red and the message details include a reference
to the daemon (and, if applicable, the NFE card number).
NFE temperature status Indicates the current temperature status of the given NFE card. The
Hardware Alarms module indicates green for OK, yellow for Warning,
and red for Critical (and, if applicable, the NFE card number).
NFE TCAM daemon If the NFE TCAM daemon goes down, health status for the Hardware
Alarms module changes to red and message details include a reference
to the daemon (and, if applicable, the NFE card number).
nfm_ipfragd (host frag) daemon If the nfm_ipfragd daemon goes down, health status for the Hardware
Alarms module changes to red and message details include a reference
to the daemon (and, if applicable, the NFE card number).
NFE Platform daemon If the NFE Platform daemon goes down, health status for the Hardware
Alarms module changes to red and message details include a reference
to the daemon (and, if applicable, the NFE card number).
NMSB communications If the Media assembly is not present or not communicating, health status
for the Hardware Alarms module changes to red and message details
include a reference to the NFE temperature (and, if applicable, the NFE
card number).
psls daemon status If the psls daemon goes down, health status for the Hardware Alarms
module changes to red and message details include a reference to the
daemon.
Rulesd (host rules) daemon If the Rulesd daemon goes down, health status for the Hardware Alarms
module changes to yellow and message details include a reference to the
daemon (and, if applicable, the NFE card number).
scmd daemon status If the scmd daemon goes down, health status for the Hardware Alarms
module changes to red and message details include a reference to the
daemon.
The table below describes the fields that can be viewed and searched in the health events table.
Field Description
Module Name Specify the name of the module which generated the health events you want to
view. For example, to view events that measure CPU performance, type CPU. The
search should retrieve applicable CPU Usage and CPU temperature events.
Test Name The name of the health module that generated the event.
(Search only)
Description The description of the health module that generated the event. For example, health
events generated when a process was unable to execute are labeled Unable to
Execute.
Value The value (number of units) of the result obtained by the health test that generated
the event.
For example, if the Firepower Management Center generates a health event whenever
a device it is monitoring is using 80 percent or more of its CPU resources, the value
could be a number from 80 to 100.
Units The units descriptor for the result. You can use the asterisk (*) to create wildcard
searches.
For example, if the Firepower Management Center generates a health event when
a device it is monitoring is using 80 percent or more of its CPU resources, the units
descriptor is a percentage sign (%).
Status The status (Critical, Yellow, Green, or Disabled) reported for the appliance.
Domain For health events reported by managed devices, the domain of the device that
reported the health event. For health events reported by the Firepower Management
Center, Global. This field is only present in a multidomain deployment.
System Statistics
The Statistics page in the Firepower System web interface lists the current status of general appliance statistics,
including disk usage and system processes, Data Correlator statistics, and intrusion event information.
You view system statistics on both the Firepower Management Center and 7000 & 8000 Series devices.
Type of Statistics Statistics Page Section Management Center 7000 & 8000 Series
Devices
host statistics The Host Statistics Section, on yes yes
page 250
system status and disk The Disk Usage Section, on page yes yes
space usage 250
Type of Statistics Statistics Page Section Management Center 7000 & 8000 Series
Devices
system process status The Processes Section, on page yes yes
251
Category Description
Time The current time on the system.
Uptime The number of days (if applicable), hours, and minutes since the system was last started.
Load Average The average number of processes in the CPU queue for the past 1 minute, 5 minutes,
and 15 minutes.
Disk Usage The percentage of the disk that is being used. Click the arrow to view more detailed host
statistics.
Related Topics
Viewing System Statistics, on page 258
Tip On the Firepower Management Center, you can also use the health monitor to monitor disk usage and
alert on low disk space conditions.
Cpu(s)
Lists the following CPU usage information:
• user process usage percentage
• system process usage percentage
• nice usage percentage (CPU usage of processes that have a negative nice value, indicating a higher
priority). Nice values indicate the scheduled priority for system processes and can range between -20
(highest priority) and 19 (lowest priority).
• idle usage percentage
Mem
Lists the following memory usage information:
• total number of kilobytes in memory
• total number of used kilobytes in memory
• total number of free kilobytes in memory
• total number of buffered kilobytes in memory
Swap
Lists the following swap usage information:
• total number of kilobytes in swap
• total number of used kilobytes in swap
• total number of free kilobytes in swap
• total number of cached kilobytes in swap
The following table describes each column that appears in the Processes section.
Column Description
Pid The process ID number
Nice The nice value, which is a value that indicates the scheduling priority of a process. Values
range between -20 (highest priority) and 19 (lowest priority)
Size The memory size used by the process (in kilobytes unless the value is followed by m, which
indicates megabytes)
Res The amount of resident paging files in memory (in kilobytes unless the value is followed by
m, which indicates megabytes)
Time The amount of time (in hours:minutes:seconds) that the process has been running
Related Topics
System Daemons, on page 253
Executables and System Utilities, on page 254
System Daemons
Daemons continually run on an appliance. They ensure that services are available and spawn processes when
required. The following table lists daemons that you may see on the Process Status page and provides a brief
description of their functionality.
Note The table below is not an exhaustive list of all processes that may run on an appliance.
Daemon Description
crond Manages the execution of scheduled commands (cron jobs)
httpsd Manages the HTTPS (Apache web server with SSL) service, and checks for working
SSL and valid certificate authentication; runs in the background to provide secure
web access to the appliance
kupdated Manages the Linux kernel update process, which performs disk synchronization
pm Manages all Firepower System processes, starts required processes, restarts any
process that fails unexpectedly
safe_mysqld Manages safe mode operation of the database; restarts the database daemon if an
error occurs and logs runtime information to a file
Daemon Description
sfestreamer Manages connections to third-party client applications that use the Event Streamer
(Management Center
only)
sfmgr Provides the RPC service for remotely managing and configuring an appliance
using an sftunnel connection to the appliance
sfmbservice Provides access to the sfmb message broker process running on a remote appliance,
using an sftunnel connection to the appliance. Currently used only by health
monitoring to send health events and alerts from a managed device to a Firepower
Management Center.
sftroughd Listens for connections on incoming sockets and then invokes the correct executable
(typically the Cisco message broker, sfmb) to handle the request
sftunnel Provides the secure communication channel for all processes requiring
communication with a remote appliance
sshd Manages the Secure Shell (SSH) process; runs in the background to provide SSH
access to the appliance
Executable Description
awk Utility that executes programs written in the awk programming language
cat Utility that reads files and writes content to standard output
Executable Description
chsh Utility that changes the default login shell
SFDataCorrelator Analyzes binary files created by the system to generate events, connection data,
(Management Center only) and network maps
egrep Utility that searches files and folders for specified input; supports extended set
of regular expressions not supported in standard grep
grep Utility that searches files and directories for specified input
ifconfig Indicates the network configuration executable. Ensures that the MAC address
stays constant
iptables Handles access restriction based on changes made to the Access Configuration
page.
killall Utility that can be used to end all sessions and processes
logger Utility that provides a way to access the syslog daemon from the command line
md5sum Utility that prints checksums and block counts for specified files
Executable Description
openssl Indicates authentication certificate creation
sfheartbeat Identifies a heartbeat broadcast, indicating that the appliance is active; heartbeat
used to maintain contact between a device and Firepower Management Center
smtpclient Mail client that handles email transmission when email event notification
functionality is enabled
snmptrap Forwards SNMP trap data to the SNMP trap server specified when SNMP
notification functionality is enabled
sudo Indicates a sudo process, which allows users other than admin to run executables
top Utility that displays information about the top CPU processes
touch Utility that can be used to change the access and modification times of specified
files
wc Utility that performs line, word, and byte counts on specified files
Related Topics
Configuring the Access List for Your System, on page 898
Category Description
Events/Sec Number of discovery events that the Data Correlator receives and processes
per second
Connections/Sec Number of connections that the Data Correlator receives and processes per
second
CPU Usage — User (%) Average percentage of CPU time spent on user processes for the current day
CPU Usage — System (%) Average percentage of CPU time spent on system processes for the current
day
VmSize (KB) Average size of memory allocated to the Data Correlator for the current day,
in kilobytes
VmRSS (KB) Average amount of memory used by the Data Correlator for the current day,
in kilobytes
Note The information in the Intrusion Event Information section of the Statistics page is based on intrusion
events stored on the managed device rather than those sent to the Firepower Management Center. No
intrusion event information is listed on this page if the managed device cannot (or is configured not to)
store intrusion events locally.
The following table describes the statistics displayed in the Intrusion Event Information section of the Statistics
page.
Statistic Description
Last Alert Was The date and time that the last event occurred
Total Events Last Hour The total number of events that occurred in the past hour
Total Events Last Day The total number of events that occurred in the past twenty-four hours
Total Events in Database The total number of events in the events database
On the Firepower Management Center, the web interface displays statistics for that appliance and any devices
it manages. On 7000 and 8000 Series devices, the system displays statistics for that device only.
Procedure
• Click the down arrow next to By Partion to expand it. If you have a malware storage pack installed, the
/var/storage partition usage is displayed.
Step 5 Optionally, click the arrow next to Processes to view the information described in Process Status Fields, on
page 251.
System Messages
When you need to track down problems occurring in the Firepower System, the Message Center is the place
to start your investigation. This feature allows you to view the messages that the Firepower System continually
generates about system activities and status.
To open the Message Center, click on the System Status icon, located to the immediate right of the Deploy
button in the main menu. This icon can take one of the following forms, depending on the system status:
• — Indicates one or more errors and any number of warnings are present on the system.
• — Indicates one or more warnings and no errors are present on the system.
• — Indicates no warnings or errors are present on the system.
If a number is displayed with the icon, it indicates the total current number of error or warning messages.
To close the Message Center, click anywhere outside of it within the Firepower System web interface.
In addition to the Message Center, the web interface displays pop-up notifications in immediate response to
your activities and ongoing system activities. Some pop-up notifications automatically disappear after five
seconds, while others are "sticky," meaning they display until you explicitly dismiss them by clicking their
dismissal icons ( ). Click the Dismiss link at the top of the notifications list to dismiss all notifications at
once.
Tip Hovering your cursor over a non-sticky pop-up notification causes it to be sticky.
The system determines which messages it displays to users in pop-up notifications and the Message Center
based on their licenses, domains, and access roles.
Message Types
The Message Center displays messages reporting system activities and status organized into three different
tabs:
Deployments
This tab displays current status related to configuration deployment for each appliance in your system,
grouped by domain. The Firepower System reports the following deployment status values on this tab.
You can get additional detail about the deployment jobs by clicking Show History.
• Running (spinning ) — The configuration is in the process of deploying.
• Success ( ) — The configuration has successfully been deployed.
• Warning ( ) — Warning deployment statuses contribute to the message count displayed with
the warning System Status icon ( ).
• Failure ( ) — The configuration has failed to deploy; see Out-of-Date Policies, on page 299.
Failed deployments contribute to the message count displayed with the error System Status icon
( ).
Health
This tab displays current health status information for each appliance in your system, grouped by
domain. Health status is generated by health modules as described in About Health Monitoring, on
page 223. The Firepower System reports the following health status values on this tab:
• Warning ( ) — Indicates that warning limits have been exceeded for a health module on an
appliance and the problem has not been corrected. The Health Monitoring page indicates these
conditions with a yellow triangle icon ( ). Warning statuses contribute to the message count
displayed with the warning System Status icon ( ).
• Critical ( ) — Indicates that critical limits have been exceeded for a health module on an appliance
and the problem has not been corrected. The Health Monitoring page indicates these conditions
with a icon. Critical statuses contribute to the message count displayed with the error System
Status icon ( ).
• Error ( ) — Indicates that a health monitoring module has failed on an appliance and has not
been successfully re-run since the failure occurred. The Health Monitoring page indicates these
conditions with a icon. Error statuses contribute to the message count displayed with the error
System Status icon ( ).
You can click on links in the Health tab to view related detailed information on the Health Monitoring
page. If there are no current health status conditions, the Health tab displays no messages.
Tasks
In the Firepower System, you can perform certain tasks (such as configuration backups or update
installation) that can require some time to complete. This tab displays the status of these long-running
tasks, and can include tasks initiated by you or, if you have appropriate access, other users of the system.
The tab presents messages in reverse chronological order based on the most recent update time for each
message. Some task status messages include links to more detailed information about the task in question.
The Firepower System reports the following task status values on this tab:
• Waiting ( ) — Indicates a task that is waiting to run until another in-progress task is complete.
This message type displays an updating progress bar.
• Running (spinning ) — Indicates a task that is in-progress. This message type displays an
updating progress bar.
• Retrying ( ) — Indicates a task that is automatically retrying. Note that not all tasks are permitted
to try again. This message type displays an updating progress bar.
• Success ( ) — Indicates a task that has completed successfully.
• Failure ( ) — Indicates a task that did not complete successfully. Failed tasks contribute to the
message count displayed with the error System Status icon ( ).
• Stopped ( ) — Indicates a task that was interrupted due to a system update. Stopped tasks cannot
be resumed.
New messages appear in this tab as new tasks are started. As tasks complete (status success, failure, or
stopped), this tab continues to display messages with final status indicated until you remove them.
Cisco recommends you remove messages to reduce clutter in the Tasks tab as well as the message
database.
Message Management
From the Message Center you can:
• Configure pop-up notification behavior (choosing whether to display them).
• Display additional task status messages from the system database (if any are available that have not been
removed).
• Remove individual task status messages. (This affects all users who can view the removed messages.)
• Remove task status messages in bulk. (This affects all users who can view the removed messages.)
Tip Cisco recommends that you periodically remove accumulated task status messages from the Task tab to
reduce clutter in the display as well the database. When the number of messages in the database approaches
100,000, the system automatically deletes task status messages that you have removed.
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 You have the following choices:
• Click on the Deployments tab to view messages related to configuration deployments. See Viewing
Deployment Messages, on page 266.
• Click on the Health tab to view messages related to the health of your Firepower Management Center
and the devices registered to it. See Viewing Health Messages, on page 267.
• Click on the Tasks tab to view or manage messages related to long-running tasks. See Viewing Task
Messages, on page 268 or Managing Task Messages, on page 268.
• Click on the cog icon ( ) in the upper right corner of the Message Center to configure pop-up notification
behavior. See Configuring Notification Behavior, on page 269.
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Deployments tab.
Step 3 You have the following choices:
• Click on total to view all current deployment statuses.
• Click on a status value to view only messages with that deployment status.
• Hover your cursor over the time elapsed indicator for a message (e.g., 1m 5s) to view the elapsed time,
and start and stop times for the deployment.
Step 4 Click Show History to view more detailed information about the deployment jobs.
The Deployment History table lists the deployment jobs in the left column in reverse chronological order.
a) Select a deployment job.
The table in the right column shows each device that was included in the job, and the deployment status
per device.
b) To view responses from the device, and commands sent to the device during deployment, click the download
icon in the Transcript column for the device.
The transcript includes the following sections:
• Snort Apply—If there are any failures or responses from Snort-related policies, messages appear
in this section. Normally, the section is empty.
• CLI Apply—This section covers features that are configured using commands sent to the Lina
process.
• Infrastructure Messages—This section shows the status of different deployment modules.
In the CLI Apply section, the deployment transcript includes commands sent to the device, and any
responses returned from the device. These response can be informative messages or error messages. For
failed deployments, look for messages that indicate errors with the commands. Examining these errors
can be particularly helpful if you are using FlexConfig policies to configure customized features. These
errors can help you correct the script in the FlexConfig object that is trying to configure the commands.
Note There is no distinction made in the transcript between commands sent for managed features and
those generated from FlexConfig policies.
For example, the following sequence shows that Firepower Management Center (FMC) sent commands
to configure GigabitEthernet0/0 with the logical name outside. The device responded that it automatically
set the security level to 0. Firepower Threat Defense does not use the security level for anything.
Related Topics
Deploying Configuration Changes, on page 288
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Health tab.
Step 3 You have the following choices:
• Click on total to view all current health statuses.
• Click on a status value to view only messages with that status.
• Hover your cursor over the relative time indicator for a message (e.g., 3 day(s) ago) to view the time
of the most recent update for that message.
• To view detailed health status information for a particular message, click on the message.
• To view complete health status on the Health Monitoring page, click on Health Monitor at the bottom
of the tab.
Related Topics
About Health Monitoring, on page 223
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Tasks tab.
Step 3 You have the following choices:
• Click on total to view all current task statuses.
• Click on a status value to view only messages for tasks with the that status.
Note Messages for stopped tasks appear only in the total list of task status messages. You cannot
filter on stopped tasks.
• Hover your cursor over the relative time indicator for a message (e.g., 3 day(s) ago) to view the time
of the most recent update for that message.
• Click on any link within a message to view more information about the task.
• If more task status messages are available for display, click on Fetch more messages at the bottom of
the message list to retrieve them.
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Tasks tab.
Step 3 You have the following choices:
• If more task status messages are available for display, click on Fetch more messages at the bottom of
the message list to retrieve them.
• To remove a single message for a completed task (status stopped, success, or failure), click on the remove
icon ( ) next to the message.
• To remove all messages for all tasks that have completed (status stopped, success, or failure), filter the
messages on total and click on Remove all completed tasks.
• To remove all messages for all tasks that have completed successfully, filter the messages on success,
and click on Remove all successful tasks.
• To remove all messages for all tasks that have failed, filter the messages on failure, and click on Remove
all failed tasks.
Note This setting affects all pop-up notifications and persists between login sessions.
Procedure
Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the cog icon ( ) in the upper right corner of the Message Center.
Step 3 To enable or disable pop-up notification display, click the Show notifications slider.
Step 4 Click on the cog icon ( ) again to hide the slider.
Step 5 Click on the System Status icon again to close the Message Center.
Hardware Performance and Logs data and logs related to the performance of the appliance hardware
System Configuration, Policy, and Logs configuration settings, data, and logs related to the current system configuration
of the appliance
Detection Configuration, Policy, and Logs configuration settings, data, and logs related to detection on the appliance
Interface and Network Related Data configuration settings, data, and logs related to inline sets and network
configuration of the appliance
Discovery, Awareness, VDB Data, and Logs configuration settings, data, and logs related to the current discovery and
awareness configuration on the appliance
Upgrade Data and Logs data and logs related to prior upgrades of the appliance
All Database Data all database-related data that is included in a troubleshoot report
You can generate and download customized troubleshooting files that you can send to Support.
In a multidomain deployment, you can generate and download troubleshooting files for devices in descendant
domains.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
In a multidomain deployment, you can generate and download troubleshooting files for devices in descendant
domains. You can download files from the Firepower Management Center only from the Global domain.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Using the Firepower Threat Defense CLI from the Web Interface
Smart License Classic License Supported Devices Supported Domains Access
Any Any Firepower Threat Any Admin/Maint/Any
Defense Security Analyst
You can execute selected Firepower Threat Defense command line interface (CLI) commands from the
Firepower Management Center web interface. These commands are ping, packet-tracer, traceroute, and
show (except for the show subcommands history and banner).
In a multidomain deployment, you can enter Firepower Threat Defense CLI commands through the Firepower
Management Center web interface for managed devices in descendant domains.
Note In deployments using Firepower Management Center high availability, this feature is available only in
the active Firepower Management Center.
For more information on the Firepower Threat DefenseCLI, see the Command Reference for Firepower Threat
Defense.
Procedure
Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 241.
Procedure
Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click the troubleshooting icon.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Click the Packet Tracer tab.
Step 6 Select the Packet type for the trace, and specify the protocol characteristics:
• ICMP—Enter the ICMP type, ICMP code (0-255), and optionally, the ICMP identifier.
• TCP/UDP/SCTP—Enter the source and destination port numbers.
• IP—Enter the protocol number, 0-255.
Packet capture data includes information from Snort and preprocessors about verdicts and actions the system
takes while processing a packet. Multiple packet captures are possible at a time. You can configure the system
to modify, delete, clear, and save captures.
Note Capturing packet data requires packet copy. This operation may cause delays while processing packets
and may also degrade the packet throughput. Cisco recommends that you use packet filters to capture
specific traffic data.
The saved traffic data can be downloaded in pcap or ASCII file formats.
Procedure
Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click the troubleshooting icon.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Select the Capture w/Trace tab.
Step 6 Click Add Capture.
Step 7 Enter the Name for capturing the trace.
Step 8 Select the Interface for the capturing the trace.
Step 9 Specify Match Criteria details:
a) Select the Protocol.
b) Enter the IP address for the Source Host.
c) Enter the IP address for the Destination Host.
d) (Optional) Check SGT number check box, and enter a Security Group Tag (SGT).
Step 10 Specify Buffer details:
a) (Optional) Enter a maximum Packet Size.
b) (Optional) Enter a minimum Buffer Size.
c) Select either Continuous Capture if you want the traffic captured without interruption, or Stop when
full if you want the capture to stop when the maximum buffer size is reached.
d) Select Trace if you want to capture the details for each packet.
e) (Optional) Check Trace Count check box. Default value is 50. You can enter values in the range of 1-1000.
Step 11 Click Save.
Feature-Specific Troubleshooting
See the following table for feature-specific troubleshooting tips and techniques.
User identity sources Troubleshoot the User Agent Identity Source, on page 1916
Troubleshoot the ISE/ISE-PIC Identity Source, on page 1921
Troubleshoot the TS Agent Identity Source, on page 1922
Troubleshoot the Captive Portal Identity Source, on page 1927
Troubleshoot the Remote Access VPN Identity Source, on page 1928
Realms and user data downloads Troubleshooting Realms and User Downloads, on page 1961
Custom Security Group Tag (SGT) rule conditions Troubleshooting Custom SGT Conditions, on page 334
Cisco Threat Intelligence Director (TID) Troubleshooting Common Issues With TID, on page 1459
Intrusion performance statistics Intrusion Performance Statistic Logging Configuration, on page 1690
7000 and 8000 Series, NGIPSv, and ASA with generate-troubleshoot, on page 2526
FirePOWER Services Command Line Interface
(CLI)
Tip Each task topic in this guide has a Supported Domains value that indicates the domain levels where you
can perform the task.
Each leaf domain builds its own network map, based on the discovery data collected by that leaf domain’s
devices. Events reported by a managed device (connection, intrusion, malware, and so on) are also associated
with the device's leaf domain.
Domains Terminology
This documentation uses the following terms when describing domains and multidomain deployments:
Global Domain
In a multidomain deployment, the top-level domain. If you do not configure multitenancy, all devices,
configurations, and events belong to the Global domain. Administrators in the Global domain can
manage the entire Firepower System deployment.
Subdomain
A second or third-level domain.
Second-level domain
A child of the Global domain. Second-level domains can be leaf domains, or they can have subdomains.
Third-level domain
A child of a second-level domain. Third-level domains are always leaf domains.
Leaf domain
A domain with no subdomains. Each device must belong to a leaf domain.
Descendant domain
A domain descending from the current domain in the hierarchy.
Child domain
A domain’s direct descendant.
Ancestor domain
A domain from which the current domain descends.
Parent domain
A domain’s direct ancestor.
Sibling domain
A domain with the same parent.
Current domain
The domain you are logged into now. The system displays the name of the current domain before your
user name at the top right of the web interface. Unless your user role is restricted, you can edit
configurations in the current domain.
Domain Properties
To modify a domain's properties, you must have Administrator access in that domain's parent domain.
Name and Description
Each domain must have a unique name within its hierarchy. A description is optional.
Parent Domain
Second- and third-level domains have a parent domain. You cannot change a domain's parent after you
create the domain.
Devices
Only leaf domains may contain devices. In other words, a domain may contain subdomains or devices,
but not both. You cannot save a deployment where a non-leaf domain directly controls a device.
In the domain editor, the web interface displays available and selected devices according to their current
place in your domain hierarchy.
Host Limit
The number of hosts a Firepower Management Center can monitor, and therefore store in network
maps, depends on its model. In a multidomain deployment, leaf domains share the available pool of
monitored hosts, but have separate network maps.
To ensure that each leaf domain can populate its network map, you can set host limits at each subdomain
level. If you set a domain's host limit to 0, the domain shares in the general pool.
Setting the host limit has a different effect at each domain level:
• Leaf — For a leaf domain, a host limit is a simple limit on the number of hosts the leaf domain
can monitor.
• Second Level — For a second-level domain that manages third-level leaf domains, a host limit
represents the total number of hosts that the leaf domains can monitor. The leaf domains share
the pool of available hosts.
• Global — For the Global domain, the host limit is equal to the total number of hosts a Firepower
Management Center can monitor. You cannot change it
The sum of subdomains' host limits can add up to more than their parent domain's host limit. For
example, if the Global domain host limit is 150,000, you can configure multiple subdomains each with
a host limit of 100,000. Any of those domains, but not all, can monitor 100,000 hosts.
The network discovery policy controls what happens when you detect a new host after you reach the
host limit; you can drop the new host, or replace the host that has been inactive for the longest time.
Because each leaf domain has its own network discovery policy, each leaf domain governs its own
behavior when the system discovers a new host.
If you reduce the host limit for a domain and its network map contains more hosts than the new limit,
the system deletes the hosts that have been inactive the longest.
Managing Domains
Smart License Classic License Supported Device Supported Access
Domains
Any Any Any Any Admin
To modify a domain's properties, you must have Administrator access in that domain's parent domain.
Procedure
• Edit — Click the edit icon ( ) next to the domain you want to modify; see Domain Properties, on page
281.
• Delete — Click the delete icon ( ) next to the empty domain you want to delete, then confirm your
choice. Move devices from domains you want to delete by editing their destination domain.
Step 3 When you are done making changes to the domain structure and all devices are associated with leaf domains,
click Save to implement your changes.
Step 4 If prompted, make additional changes:
• If you changed a leaf domain to a parent domain, move or delete the old network map; see Moving Data
Between Domains, on page 284.
• If you moved devices between domains and must assign new policies and security zones or interface
groups, see Moving Devices Between Domains, on page 285.
What to Do Next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can create up to 50 subdomains under a top-level Global domain, in two or three levels.
You must assign all devices to a leaf domain before you can implement the domain configuration. When you
add a subdomain to a leaf domain, the domain stops being a leaf domain and you must reassign its devices.
Procedure
What to Do Next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Because events and network maps are associated with leaf domains, when you change a leaf domain to a
parent domain, you have two choices:
• Move the network map and associated events to a new leaf domain.
• Delete the network map but retain the events. In this case, the events remain associated with the parent
domain until the system prunes events as needed or as configured. Or, you can delete old events manually.
Procedure
Step 1 For each former leaf domain that is now a parent domain, you have two choices:
• Choose a new Leaf Domain to inherit the Parent Domain's events and network map.
• Choose None to delete the parent domain's network map, but retain old events.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Moving a device between domains can affect the configurations and policies applied to the device. The system
automatically keeps and updates what it can, and deletes what it cannot.
If you assign a Remote Access VPN policy to a device, you cannot move the same device from one domain
to another domain.
Specifically:
• If the health policy applied to a moved device is inaccessible in the new domain, you can choose a new
health policy.
• If the access control policy assigned to a moved device is not valid or accessible in the new domain,
choose a new policy. Every device must have an assigned access control policy.
• If the interfaces on the moved device belong to a security zone that is inaccessible in the new domain,
you can choose a new zone.
• Interfaces are removed from:
◦Security zones that are inaccessible in the new domain and not used in an access control policy.
◦All interface groups.
If devices require a policy update but you do not need to move interfaces between zones, the system displays
a message stating that zone configurations are up to date. For example, if a device's interfaces belong to a
security zone configured in a common ancestor domain, you do not need to update zone configurations when
you move devices from subdomain to subdomain.
Procedure
Step 1 In the Move Devices dialog box, under Select Device(s) to Configure, check the device you want to configure.
Check multiple devices to assign the same health and access control policies.
Step 2 Choose an Access Control Policy to apply to the device, or choose New Policy to create a new policy.
Step 3 Choose a Health Policy to apply to the device, or choose None to leave the device without a health policy.
Step 4 If prompted to assign interfaces to new zones, choose a New Security Zone for each listed interface, or choose
None to assign it later.
Step 5 After you configure all affected devices, click Save to save policy and zone assignments.
Step 6 Click Save to implement the domain configuration.
What to Do Next
• Update other configurations on the moved device that were affected by the move.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Policy Deployment
After you configure your deployment, and any time you change that configuration, you must deploy the
changes to affected devices. You can view deployment status in the Message Center.
Deploying updates the following components:
• Device and interface configurations
• Device-related policies: NAT. VPN, QoS, platform settings
• Access control and related policies: DNS, file, identity, intrusion, network analysis, prefilter, SSL
• Network discovery policy
• Intrusion rule updates
• Configurations and objects associated with any of these elements
You can configure the system to deploy automatically by scheduling a deploy task or by setting the system
to deploy when importing intrusion rule updates. Automating policy deployment is especially useful if you
allow intrusion rule updates to modify system-provided base policies for intrusion and network analysis.
Intrusion rule updates can also modify default values for the advanced preprocessing and performance options
in your access control policies.
In a multidomain deployment, you can deploy changes for any domain where your user account belongs:
• Switch to an ancestor domain to deploy changes to all subdomains at the same time.
After you configure your deployment, and any time you change that configuration, deploy the changes to
affected devices.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293. On
Firepower 7010, 7020, and 7030 managed devices, deploying configuration changes can take up to five
minutes. To minimize inconvenience, deploy during a change window.
Procedure
Step 2 Identify and choose the devices where you want to deploy configuration changes.
• Sort—Sort the device list by clicking a column heading.
• Expand—Click the plus icon ( ) to expand a device listing to view the configuration changes to be
deployed. The system marks out-of-date policies with an index ( ) icon.
• Filter—Filter the device list. Click the arrow in the upper-right corner of any column heading in the
display, enter text in the Filter text box, and press Enter.
What to Do Next
• Optionally, monitor the deployment status; see Viewing Deployment Messages, on page 266.
• If configuration fails to deploy, see Guidelines for Deploying Configuration Changes, on page 290 for
possible solutions.
Related Topics
Snort® Restart Scenarios , on page 292
You can deploy configuration settings to a device even if you do not make changes that would typically mark
the configuration as out-of-date.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293. On
Firepower 7010, 7020, and 7030 managed devices, deploying configuration changes can take up to five
minutes. To minimize inconvenience, deploy during a change window.
Procedure
What to Do Next
• Optionally, monitor the deployment status; see Viewing Deployment Messages, on page 266.
• If configuration fails to deploy, see Guidelines for Deploying Configuration Changes, on page 290 for
possible solutions.
Related Topics
Snort® Restart Scenarios , on page 292
Deployment Consequences
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293. On
Firepower 7010, 7020, and 7030 managed devices, deploying configuration changes can take up to five
minutes.
• Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection
is interrupted on all non-management interfaces, not just the interface you modified. Whether this
interruption drops traffic or passes it without further inspection depends on the model of the managed
device and the interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
• If you are performing application control but disable required detectors, the system automatically enables
the appropriate system-provided detectors upon policy deploy. If none exist, the system enables the most
recently modified user-defined detector for the application.
• When you deploy changes to a network discovery policy, the system deletes and then rediscovers MAC
address, TTL, and hops information from the network map for the hosts in your monitored networks.
Also, the affected managed devices discard any discovery data that has not yet been sent to the Firepower
Management Center.
Troubleshooting
• Do not apply inline configurations to devices deployed passively, and vice versa.
• Do not exceed the capability of your devices.
Complex access control policies and rules can command significant resources and negatively affect
performance. When you deploy an access control policy, the system evaluates all the rules together and
creates an expanded set of criteria that target devices use to evaluate network traffic.
If you exceed the maximum number of access control rules or invoked intrusion policies supported by
a target device, the system displays a warning. The maximum depends on a number of factors, including
policy complexity, physical memory, and the number of processors on the device.
• Verify that the devices are the correct model for the features you configured, and are using the correct
licenses and minimum versions of the Firepower System. For example, you cannot target stacked 7000
or 8000 Series devices running different versions of the Firepower System.
Auto-deploying
You can configure the system to deploy automatically as follows:
• After the completion of an intrusion rule upate
• Using a scheduled task
Related Topics
Snort® Restart Scenarios , on page 292
Related Topics
Access Control Policy Advanced Settings, on page 1226
Configurations that Restart the Snort Process When Deployed or Activated, on page 294
The following graphic illustrates how Snort restarts can occur when you enable or disable Inspect traffic
during policy apply.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293.
Note In addition to traffic handling when the Snort process is down while it restarts, traffic can also pass without
inspection or drop when the Snort process is busy, depending on the configuration of the Failsafe option
(see Inline Sets on the Firepower System, on page 512) or the Snort Fail Open Busy option (see Configure
an Inline Set of IPS-Only Interfaces, on page 601). A device supports either the Failsafe option or the
Snort Fail Open option, but not both.
Security Intelligence
• From the Security Intelligence tab in an access control policy, add multiple objects to a whitelist or
blacklist, or delete multiple objects; whether the Snort process restarts can vary by device, depending
on the memory available for inspection.
File Policy
• Enable or disable Inspect Archives.
• Enable or disable Store files in a Detect Files or Block Files rule.
• Add the first or remove the last active file rule that combines the Malware Cloud Lookup or Block
Malware rule action with an analysis option (Spero Analysis or MSEXE, Dynamic Analysis, or Local
Malware Analysis) or a store files option (Malware, Unknown, Clean, or Custom).
Identity Policy
• When SSL decryption is disabled (that is, when the access control policy does not include an SSL policy),
add the first or remove the last active authentication rule.
An active authentication rule has either an Active Authentication rule action, or a Passive Authentication
rule action with Use active authentication if passive or VPN identity cannot be established selected.
Network Discovery
• Enable or disable non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols,
using the network discovery policy.
Device Management
• Routing—Add a routed interface pair or virtual router to a 7000 or 8000 Series device.
• VPN—Add or remove a VPN on a 7000 or 8000 Series device.
Caution The system does not warn you that the Snort process restarts when you add or remove
a VPN on a 7000 or 8000 Series device.
• MTU—Change the highest MTU value among all non-management interfaces on a device.
• Classic Device High Availability—Change a high-availability state sharing option. The system does not
warn you that the Snort process restarts on the primary and secondary devices.
• Automatic Application Bypass (AAB)—The currently deployed AAB configuration activates when a
malfunction of the Snort process or a device misconfiguration causes a single packet to use an excessive
amount of processing time. The result is a partial restart of the Snort process to alleviate extremely high
latency or prevent a complete traffic stall. This partial restart causes a few packets to pass without
inspection, or drop, depending on how the device handles traffic.
System Updates
• In the rare cases when a system update does not require a reboot but does update the Snort binary, the
Snort process restarts.
• Install a vulnerability database (VDB) update or deploy an access control policy for the first time after
installing a VDB update.
Related Topics
Deploying Configuration Changes, on page 288
Snort® Restart Scenarios , on page 292
The system warns you that continuing restarts the Snort process on all managed devices, and allows you
to cancel.
• Create or break a Firepower Threat Defense high availability pair—The system warns you that continuing
to create a high availability pair restarts the Snort process on the primary and secondary devices and
allows you to cancel.
• Install a vulnerability database (VDB) update or deploy an access control policy for the first time after
installing a VDB update.
• Restart the Snort process in the 7000 or 8000 Series user interface (System > Configuration >
Process)—The system prompts you for confirmation and allows you to cancel.
Policy Comparison
To review policy changes for compliance with your organization's standards or to optimize system performance,
you can examine the differences between two policies or between a saved policy and the running configuration.
You can compare the following policy types:
• DNS
• File
• Health
• Identity
• Intrusion
• Network Analysis
• SSL
The comparison view displays both policies in a side-by-side format. Differences between the two policies
are highlighted:
• Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in
red text.
• Green indicates that the highlighted setting appears in one policy but not the other.
Comparing Policies
Smart License Classic License Supported Devices Supported Domains Access
feature dependent feature dependent Any feature dependent feature dependent
Procedure
Step 1 Access the management page for the policy you want to compare:
• DNS—Policies > Access Control > DNS
• File—Policies > Access Control > Malware & File
• Health—System > Health > Policy
• Identity—Policies > Access Control > Identity
• Intrusion—Policies > Access Control > Intrusion
• Network Analysis—Policies > Access Control, then click Network Analysis Policy or Policies >
Access Control > Intrusion, then click Network Analysis Policy
Note If your custom user role limits access to the first path listed here, use the second path to access
the policy.
• SSL—Policies > Access Control > SSL
Step 4 Depending on the comparison type you choose, you have the following choices:
• If you are comparing two different policies, choose the policies you want to compare from the Policy
A and Policy B drop-down lists.
• If you are comparing the running configuration to another policy, choose the second policy from the
Policy B drop-down list.
• Comparison Report—To generate a PDF report that lists the differences between the two policies, click
Comparison Report.
Policy Reports
For most policies, you can generate two kinds of reports. A report on a single policy provides details on the
policy's current saved configuration, while a comparison report lists only the differences between two policies.
You can generate a single-policy report for all policy types except health.
Note Intrusion policy reports combine the settings in the base policy with the settings of the policy layers, and
make no distinction between which settings originated in the base policy or policy layer.
Procedure
Step 1 Access the management page for the policy for which you want to generate a report:
• Access Control — Policies > Access Control
• DNS — Policies > Access Control > DNS
• File — Policies > Access Control > Malware & File
• Health — System > Health > Policy
• Identity — Policies > Access Control > Identity
• Intrusion — Policies > Access Control > Intrusion
• NAT for 7000 & 8000 Series devices — Devices > NAT
• Network Analysis — Policies > Access Control, then click Network Analysis Policy or Policies >
Access Control > Intrusion, then click Network Analysis Policy
Note If your custom user role limits access to the first path listed here, use the second path to access
the policy.
Step 2 Click the report icon ( ) next to the policy for which you want to generate a report.
Out-of-Date Policies
The Firepower System marks out-of-date policies with red status text that indicates how many of its targeted
devices need a policy update. To clear this status, you must re-deploy the policy to the devices.
Configuration changes that require a policy re-deploy include:
• Modifying an access control policy: any changes to access control rules, the default action, policy targets,
Security Intelligence filtering, advanced options including preprocessing, and so on.
• Modifying any of the policies that the access control policy invokes: the SSL policy, network analysis
policies, intrusion policies, file policies, identity policies, or DNS policies.
• Changing any reusable object or configuration used in an access control policy or policies it invokes:
◦network, port, VLAN tag, URL, and geolocation objects
◦Security Intelligence lists and feeds
◦application filters or detectors
◦intrusion policy variable sets
◦file lists
◦decryption-related objects and security zones
• Updating the system software, intrusion rules, or the vulnerability database (VDB).
Keep in mind that you can change some of these configurations from multiple places in the web interface.
For example, you can modify security zones using the object manager (Objects > Object Management), but
modifying an interface type in a device’s configuration (Devices > Device Management) can also change a
zone and require a policy re-deploy.
Note that the following updates do not require policy re-deploy:
• automatic updates to Security Intelligence feeds and additions to the Security Intelligence global blacklist
or whitelist using the context menu
• automatic updates to URL filtering data
• scheduled geolocation database (GeoDB) updates
Combining discovery and IPS gives context to your network activity and allows you to take advantage of
many features, including:
• impact flags and indications of compromise, which can tell you which of your hosts are vulnerable to a
particular exploit, attack, or piece of malware
• adaptive profile updates and Firepower recommendations, which allow you to examine traffic differently
depending on the destination host
• correlation, which allows you to respond to intrusions (and other events) differently depending on the
affected host
However, if your organization is interested in performing only IPS, or only discovery, there are a few
configurations that can optimize the performance of the system.
Note You must use an access control policy, even if it simply allows all traffic. The network discovery policy
can only examine traffic that the access control policy allows to pass.
First, make sure your access control policy does not require complex processing and uses only simple,
network-based criteria to handle network traffic. You must implement all of the following guidelines;
misconfiguring any one of these options eliminates the performance benefit:
• Do not use the Security Intelligence feature. Remove any populated global whitelist or blacklist from
the policy’s Security Intelligence configuration.
• Do not include access control rules with Monitor or Interactive Block actions. Use only Allow, Trust,
and Block rules. Keep in mind that allowed traffic can be inspected by discovery; trusted and blocked
traffic cannot.
• Do not include access control rules with application, user, URL, ISE attribute, or geolocation-based
network conditions. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.
• Do not include access control rules that perform file, malware, or intrusion inspection. In other words,
do not associate a file policy or intrusion policy with any access control rule.
• Make sure that the default intrusion policy for the access control policy is set to No Rules Active.
• Select Network Discovery Only as the policy’s default action. Do not choose a default action for the
policy that performs intrusion inspection.
In conjunction with the access control policy, you can configure and deploy the network discovery policy,
which specifies the network segments, ports, and zones that the system examines for discovery data, as well
as whether hosts, applications, and users are discovered on the segments, ports, and zones.
Related Topics
The Default Intrusion Policy, on page 1695
Note If you are performing application, user, or URL control, you cannot disable discovery for a performance
benefit. Although you can prevent the system from storing discovery data, the system must collect and
examine it to implement those features.
To disable discovery, implement all of the following guidelines; misconfiguring any eliminates the performance
benefit:
• In your access control policy, do not include rules with application, user, URL, ISE attribute, or
geolocation-based network conditions, even if your devices are appropriately licensed. Use only simple
network-based conditions: zone, IP address, VLAN tag, and port.
• Delete all rules from your network discovery policy.
After you deploy access control and network discovery policies, new discovery halts on target devices. The
system gradually deletes information in the network map according to the timeout periods you specified in
the network discovery policy. Alternatively, you can purge all discovery data immediately.
Introduction to Rules
Rules in various policies exert granular control over network traffic. The system evaluates traffic against rules
in the order that you specify, using a first-match algorithm.
Although these rules may include other configurations that are not consistent across policies, they share many
basic characteristics and configuration mechanics, including:
• Conditions—Rule conditions specify the traffic that each rule handles. You can configure each rule with
multiple conditions. Traffic must match all conditions to match the rule.
• Action—A rule's action determines how the system handles matching traffic. Note that even if a rule
does not have an Action list you can choose from, the rule still has an associated action. For example,
a custom network analysis rule uses a network analysis policy as its "action." As another example, QoS
rules do not have an explicit action because all QoS rules do the same thing: rate limit traffic.
• Position—A rule's position dermines its evaluation order. When using a policy to evaluate traffic, the
system matches traffic to rules in the order you specify. Usually, the system handles traffic according
to the first rule where all the rule’s conditions match the traffic. (Monitor rules, which track and log but
do not affect traffic flow, are an exception.) Proper rule order reduces the resources required to process
network traffic, and prevents rule preemption.
• Category—To organize some rule types, you can create custom rule categories in each parent policy.
• Logging—For many rules, logging settings govern whether and how the system logs connections handled
by the rule. Some rules (such as identity and network analysis rules) do not include logging settings
because the rules neither determine the final disposition of connections, nor are they specifically designed
to log connections. As another example, QoS rules do not include logging settings; you cannot log a
connection simply because it was rate limited.
• Comments—For some rule types, each time you save changes, you can add comments. For example,
you might summarize the overall configuration for the benefit of other users, or note when you change
a rule and the reason for the change.
Tip A right-click menu in many policy editors provides shortcuts to many rule management options, including
editing, deleting, moving, enabling, and disabling.
Prefilter rules
SSL rules
DNS rules
Identity rules
Network analysis rules
QoS rules
Network Conditions, on page 309 Source and destination IP address, Access control rules
and where supported, geographical Prefilter rules
location or originating client
SSL rules
DNS rules
Identity rules
Network analysis rules
QoS rules
Port and ICMP Code Conditions, Source and destination ports, Access control rules
on page 314 protocols, and ICMP codes Prefilter rules
SSL rules
Identity rules
QoS rules
URL Conditions (URL Filtering), URL, and where supported, URL Access control rules
on page 321 characteristic (category and SSL rules
reputation)
QoS rules
User, Realm, and ISE Attribute Logged-in authoritative user of a Access control rules
Conditions (User Control), on host, or that user's realm, group, or SSL rules (no ISE attributes)
page 327 ISE attributes
QoS rules
Custom SGT Conditions, on page Custom Security Group Tag (SGT) Access control rules
332 QoS rules
Interface Conditions
Interface rule conditions control traffic by its source and destination interfaces.
Depedending on the rule type and the devices in your deployment, you can use predefined interface objects
called security zones or interface groups to build interface conditions. Interface objects segment your network
to help you manage and classify traffic flow by grouping interfaces across multiple devices; see Interface
Objects: Interface Groups and Security Zones, on page 357.
Tip Constraining rules by interface is one of the best ways to improve system performance. If a rule excludes
all of a device’s interfaces, that rule does not affect that device's performance.
Just as all interfaces in an interface object must be of the same type (all inline, passive, switched, routed, or
ASA FirePOWER), all interface objects used in an interface condition must be of the same type. Because
devices deployed passively do not transmit traffic, in passive deployments you cannot constrain rules by
destination interface.
Note If a configuration supports tunnel zone constraints, a rezoned connection—a connection with an assigned
tunnel zone—does not match security zone constraints. For more information, see Tunnel Zones and
Prefiltering, on page 1285.
Rule Type Supports Security Zones? Supports Tunnel Zones? Supports Interface
Groups?
Access control yes yes no
SSL yes no no
Identity yes no no
Note You are not required to group all internal (or external) interfaces into a single zone. Choose the grouping
that makes sense for your deployment and security policies.
Then, configure an access control rule with a destination zone condition set to Internal. This simple rule
matches traffic that leaves the device from any interface in the Internal zone. To inspect matching traffic for
intrusions and malware, choose a rule action of Allow, then associate the rule with an intrusion and a file
policy.
Procedure
Step 1 In the rule editor, click the tab for interface conditions:
• Interface groups and security zones (tunnel, prefilter, QoS)—Click the Interface Objects tab.
• Security zones (access control, SSL, DNS, identity, network analysis)—Click the Zones tab.
• Tunnel zones (access control)—Click the Zones tab.
Step 2 Find and choose the interfaces you want to add from the Available Interface Objects or Available Zones
list.
(Access control only) To match connections in rezoned tunnels, choose tunnel zones instead of security zones.
You cannot use tunnel and security zones in the same rule. For more information, see Tunnel Zones and
Prefiltering, on page 1285.
What to Do Next
• (Access control only) If you rezoned tunnels during prefiltering, configure additional rules if necessary
to ensure complete coverage. Connections in rezoned tunnels do not match rules with security zone
constraints. For more information, see Using Tunnel Zones, on page 1286.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Network Conditions
Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel
rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.
You can use predefined objects to build network conditions, or manually specify individual IP addresses or
address blocks.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
Access Control Rule 2: Allows proxied traffic from the same IP address, but only if the proxy server for that
traffic is one you choose (209.165.200.225 or 209.165.200.238)
Access Control Rule 3: Blocks proxied traffic from the same IP address if it uses any other proxy server.
Prefilter no no
SSL yes no
Identity yes no
Network analysis no no
Procedure
Step 3 (Optional) If the rule supports original client constraints, under Source Networks, configure the rule to handle
proxied traffic based on its original client:
• Source/Proxy—Click the Source sub-tab to specify proxy servers.
• Original Client—Click the Original Client sub-tab to add a network as an original client constraint. In
proxied connections, the original client's IP address must match one of these networks to match the rule.
Step 4 Click Add to Source, Add to Original Client, or Add to Destination, or drag and drop.
Step 5 Add networks that you want to specify manually. Enter a source, original client, or destination IP address or
address block, then click Add.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local
environments.
Step 6 Save or continue editing the rule.
In this example, a network object group called Private Networks (that comprises the IPv4 and IPv6 Private
Networks network objects, not shown) represents your internal networks. The example also manually specifies
the example.com IP address, and uses a system-provided North Korea geolocation object to represent North
Korea IP addresses.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
Procedure
Step 4 Add endpoints that you want to specify manually. Enter a source or destination IP address or address block,
then click Add.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local
environments.
Step 5 Save or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
VLAN Conditions
VLAN rule conditions control VLAN-tagged traffic. The system uses the innermost VLAN tag to filter VLAN
traffic, with the exception of the prefilter policy, which uses the outermost VLAN tag in its rules.
You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094.
Use a hyphen to specify a range of VLAN tags.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal VLAN tags to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
• Identity
• Network analysis
Caution Adding the first or removing the last active authentication rule when SSL decryption is
disabled (that is, when the access control policy does not include an SSL policy) restarts
the Snort process when you deploy configuration changes, temporarily interrupting
traffic inspection. Whether traffic drops during this interruption or passes without further
inspection depends on the model of the managed device and how it handles traffic. See
Snort® Restart Traffic Behavior, on page 293 for more information.
Note that an active authentication rule has either an Active Authentication rule action,
or a Passive Authentication rule action with Use active authentication if passive or
VPN identity cannot be establishedselected.
• IMCP echo—A destination ICMP port with the type set to 0 or a destination ICMPv6 port with the type
set to 129 only matches unsolicited echo replies. ICMP echo replies sent in response to ICMP echo
requests are ignored. For a rule to match on any ICMP echo, use ICMP type 8 or ICMPv6 type 128.
Procedure
• Destination (ICMP)—Choose ICMP or IPv6-ICMP from the Protocol drop down list, then choose a
Type and related Code in the pop-up window that appears. For more information on ICMP types and
codes, see the Internet Assigned Numbers Authority (IANA) website.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Encapsulation Conditions
Encapsulation conditions are specific to tunnel rules.
These conditions control certain types of plaintext, passthrough tunnels by their encapsulation protocol. You
must choose at least one protocol to match before you can save the rule. You can choose:
• GRE (47)
• IP-in-IP (4)
• IPv6-in-IP (41)
• Teredo (UDP (17)/3455)
Related Topics
Overview: Application Detection, on page 1893
To build an application condition or filter, choose the applications whose traffic you want to control from a
list of available applications. Optionally (and recommended), constrain the available applications using filters.
You can use filters and individually specified applications in the same condition.
Procedure
Step 2 (Optional) For an access control rule, enable content restriction features by clicking the dimmed icons for
Safe Search ( ) or YouTube EDU ( ) and setting related options.
For additional configuration requirements, see Using Access Control Rules to Enforce Content Restriction,
on page 1300.
In most cases, enabling content restriction populates the condition's Selected Applications and Filters list
with the appropriate values. The system does not automatically populate the list if applications or filters related
to content restriction are already present in the list when you enable content restriction.
Continue with the procedure to refine your application and filter selections, or skip to saving the rule.
Step 3 Find and choose the applications you want to add from the Available Applications list.
To constrain the applications displayed in Available Applications, choose one or more Application Filters
or search for individual applications. After you constrain the available applications, you can add All apps
matching the filter, or choose and add individual applications.
Tip
Click the information icon ( ) next to an application to display summary information and internet
search links. The unlock icon ( ) marks applications that the system can identify only in decrypted
traffic.
When you choose filters, singly or in combination, the Available Applications list updates to display only the
applications that meet your criteria. You can choose system-provided filters in combination, but not user-defined
filters.
• Multiple filters for the same characteristic (risk, business relevance, and so on)—Application traffic
must match only one of the filters. For example, if you choose both the medium and high-risk filters,
the Available Applications list displays all medium and high-risk applications.
• Filters for different application characteristics—Application traffic must match both filter types. For
example, if you choose both the high-risk and low business relevance filters, the Available Applications
list displays only applications that meet both criteria.
Tip Before you add more filters and applications, click Clear Filters to clear your current choices.
The web interface lists filters added to a condition above and separately from individually added applications.
Step 5 Save or continue editing the rule or configuration.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Application Characteristics
The system characterizes each application that it detects using the criteria described in the following table.
Use these characteristics as application filters.
Risk The likelihood that the application is being used for purposes that Peer-to-peer applications tend to have
might be against your organization’s security policy. a very high risk.
Category A general classification for the application that describes its most Facebook is in the social networking
essential function. Each application belongs to at least one category. category.
Tag Additional information about the application. Applications can have Video streaming web applications often
any number of tags, including none. are tagged high bandwidth and
displays ads.
This identification should occur within 3 to 5 packets, or after the server certificate exchange in the SSL
handshake if the traffic is encrypted.
If early traffic matches all other criteria but application identification is incomplete, the system allows the
packet to pass and the connection to be established (or the SSL handshake to complete). After the system
completes its identification, the system applies the appropriate action to the remaining session traffic.
For access control, these passed packets are inspected by the access control policy’s default intrusion policy
(not the default action intrusion policy nor the almost-matched rule’s intrusion policy).
choose only these applications. Applications without this tag can only be detected in unencrypted or
decrypted traffic.
• Decrypted traffic—The system assigns the decrypted traffic tag to applications that the system
can detect in decrypted traffic only, not encrypted or unencrypted.
Related Topics
The Default Intrusion Policy, on page 1695
Special Considerations for Application Detection, on page 1897
When you block web traffic, you can allow the user’s browser its default behavior, or you can display a generic
system-provided or custom HTTP response page. Interactive blocking gives users a chance to bypass a website
block by clicking through a warning page. For more information, see HTTP Response Pages and Interactive
Blocking, on page 1251.
Rule Type Supports Cat. and Rep. Filtering? Supports Manual Filtering?
Access control yes yes
Note To see URL category and reputation information in events and application details, you must create at least
one rule with a URL condition. You must also enable communications with Cisco Collective Security
Intelligence (CSI) to obtain the latest threat intelligence.
• If an access control rule blocks high-risk social networking sites and somebody posts a link on their
profile page that contains links to malicious payloads, the system can change the reputation of that page
from Benign Sites to High Risk and block it.
Related Topics
Collective Security Intelligence Communications Configuration Options, on page 1409
Snort® Restart Scenarios , on page 292
Note To filter a large number of URLs, use a URL list instead of individual or grouped URL objects. For more
information, see Security Intelligence Lists and Feeds, on page 381.
You can perform this type of URL filtering without a special license. Manual URL filtering is not supported
in SSL rules; instead, use distinguished name conditions.
For example, you might use access control to block a category of websites that are not appropriate for your
organization. However, if the category contains a website that is appropriate, and to which you want to provide
access, you can create a manual Allow rule for that site and place it before the Block rule for the category.
When manually filtering specific URLs, carefully consider other traffic that might be affected. To determine
whether network traffic matches a URL condition, the system performs a simple substring match. If the
requested URL matches any part of the string, the URLs are considered to match.
For example, if you allow all traffic to example.com, your users could browse to URLs including:
• http://example.com/
• http://example.com/newexample
• http://www.example.com/
As another example, consider a scenario where you want to explicitly block ign.com (a gaming site). However,
substring matching means that blocking ign.com also blocks verisign.com, which might not be your intent.
Related Topics
Security Intelligence Lists and Feeds, on page 381
When you build a URL condition, you choose the URL categories whose traffic you want to control. Optionally,
you can constrain those URL categories with a reputation.
In access control and QoS rules, you can also filter individual URLs using predefined URL objects, URL lists
and feeds, and manual per-rule URLs. You cannot constrain these URLs with a reputation. Manual URL
filtering is not supported in SSL rules; instead, use distinguished name conditions.
Procedure
Step 1 In the rule editor, click the tab for URL conditions:
• Access control or QoS—Click the URLs tab.
• SSL—Click the Category tab.
social networking sites with a risk Social Network 3 - Benign sites with security risks
greater than benign (levels 1
through 3)
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip In an SSL policy, you can handle and decrypt traffic to specific URLs by defining a distinguished name
SSL rule condition. The common name attribute in a certificate’s subject distinguished name contains the
site’s URL. Decrypting HTTPS traffic allows access control rules to evaluate the decrypted session, which
improves URL filtering.
• http://example.com/
• https://example.com/
To configure a rule that matches only HTTP or HTTPS traffic, add an application condition to the rule. For
example, you could allow HTTPS access to a site while disallowing HTTP access by constructing two access
control rules, each with an application and URL condition.
The first rule allows HTTPS traffic to the website:
Action: Allow
Application: HTTPS
URL: example.com
Action: Block
Application: HTTP
URL: example.com
This identification should occur within 3 to 5 packets, or after the server certificate exchange in the SSL
handshake if the traffic is encrypted.
If early traffic matches all other rule conditions but identification is incomplete, the system allows the packet
to pass and the connection to be established (or the SSL handshake to complete). After the system completes
its identification, the system applies the appropriate rule action to the remaining session traffic.
For access control, these passed packets are inspected by the access control policy’s default intrusion policy—not
the default action intrusion policy nor the almost-matched rule’s intrusion policy.
Related Topics
The Default Intrusion Policy, on page 1695
• ISE attribute conditions—Match traffic based on a user's ISE-assigned Security Group Tag (SGT),
Device Type (also referred to as Endpoint Profile), or Location IP (also referred to as Endpoint Location).
Requires that you configure ISE as an identity source.
Note The ISE-PIC identity source does not provide ISE attribute data.
Note In some rules, custom SGT conditions can match traffic tagged with SGT attributes that were not assigned
by ISE. This is not considered user control, and only works if you are not using ISE as an identity source;
see Custom SGT Conditions, on page 332.
Rule Type Supports User and Realm Conditions? Supports ISE Attribute Conditions?
Access control yes yes
SSL yes no
Related Topics
The User Agent Identity Source, on page 1915
The ISE/ISE-PIC Identity Source, on page 1917
The Terminal Services (TS) Agent Identity Source, on page 1921
The Captive Portal Identity Source, on page 1922
Configure Realms
Configure a realm for each AD or LDAP server you want to monitor, including your ISE/ISE-PIC, User
Agent, and TS Agent servers, and perform a user download. For more information, see Creating a Realm,
on page 1963.
Note If you are configuring an ISE SGT attribute rule condition, configuring a realm is optional. The ISE SGT
attribute rule condition can be configured in policies with or without an associated identity policy (where
realms are invoked).
When you configure a realm, you specify the users and user groups whose activity you want to monitor.
Including a user group automatically includes all of that group’s members, including members of any secondary
groups. However, if you want to use the secondary group as a rule criterion, you must explicitly include the
secondary group in the realm configuration.
For each realm, you can enable automatic download of user data to refresh authoritative data for users and
user groups.
You can constrain a rule by realm, or by users and user groups within that realm.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the rule editor, click the tab for ISE attribute conditions:
• Access control—Click the SGT/ISE Attributes tab.
• QoS—Click the ISE Attributes tab.
You can use ISE-assigned Security Group Tags (SGTs) to constrain ISE attribute conditions. To use custom
SGTs in access control rules, see Custom SGT Conditions, on page 332.
Step 2 Find and choose the ISE attributes you want to use from the Available Attributes list:
• Security Group Tag (SGT)
• Device Type (also referred to as Endpoint Profile)
• Location IP (also referred to as Endpoint Location)
Step 3 Further constrain the rule by choosing attribute metadata from the Available Metadata list. Or, keep the
default: any.
Step 4 Click Add to Rule, or drag and drop.
Step 5 (Optional) Constrain the rule with an IP address in the Add a Location IP Address field, then click Add.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Rules targeting realms, users, or user groups are not matching traffic
If you configure a User Agent, TS Agent, or ISE/ISE-PIC device to monitor a large number of user groups,
or if you have a very large number of users mapped to hosts on your network, the system may drop user
records due to your Firepower Management Center user limit. As a result, rules with user conditions may not
match traffic as expected.
Rules targeting user groups or users within user groups are not matching traffic as expected
If you configure a rule with a user group condition, your LDAP or Active Directory server must have user
groups configured. The system cannot perform user group control if the server organizes the users in basic
object hierarchy.
Rules targeting users in secondary groups are not matching traffic as expected
If you configure a rule with a user group condition that includes or excludes users who are members of a
secondary group on your Active Directory server, your server may be limiting the number of users it reports.
By default, Active Directory servers limit the number of users they report from secondary groups. You must
customize this limit so that all of the users in your secondary groups are reported to the Firepower Management
Center and eligible for use in rules with user conditions.
Rules are not matching users when seen for the first time
After the system detects activity from a previously-unseen user, the system retrieves information about them
from the server. Until the system successfully retrieves this information, activity seen by this user is not
handled by matching rules. Instead, the user session is handled by the next rule it matches (or the policy's
default action, if applicable).
For example, this may explain when:
• Users who are members of user groups are not matching rules with user group conditions.
• Users who were reported by a User Agent, TS Agent, or ISE/ISE-PIC device are not matching rules,
when the server used for user data retrieval is an Active Directory server.
Note that this may also cause the system to delay the display of user data in event views and analysis tools.
Note If you use ISE SGTs to match traffic, even if a packet does not have an assigned SGT attribute, the packet
still matches an ISE SGT rule if the SGT associated with the packet's source IP address is known in ISE.
Related Topics
User, Realm, and ISE Attribute Conditions (User Control), on page 327
If you configure ISE, Cisco recommends that you delete or disable existing rules with custom SGT conditions.
Instead, use ISE attribute conditions to match traffic with SGT attributes.
Related Topics
Configure an ISE/ISE-PIC Connection, on page 1918
The following procedure describes how to filter traffic tagged with SGT attributes that were not assigned by
ISE. This is not considered user control, and only works if you are not using ISE/ISE-PIC as an identity source;
see ISE SGT vs Custom SGT Rule Conditions, on page 332.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In many policies, you can search for and within rules. The system matches your input to rule names and
condition values, including objects and object groups.
You cannot search for values in a Security Intelligence or URL list or feed.
Procedure
What to Do Next
• Before you begin a new search, click the clear icon ( ) to clear the search and any highlighting.
Some policy editors allow you to filter your rule view by affected devices.
The system uses a rule's interface constraints to determine if the rule affects a device. If you constrain a rule
by interface (security zone or interface group condition), the device where that interface is located is affected
by that rule. Rules with no interface constraint apply to any interface, and therefore every device.
QoS rules are always constrained by interface.
Procedure
Step 1 In the policy editor, click the Rules tab, then click Filter by Device.
A list of targeted devices and device groups appears.
Step 2 Check one or more check boxes to display only the rules that apply to those devices or groups. Or, check All
to reset and display all of the rules.
Tip Hover your pointer over a rule criterion to see its value. If the criterion represents an object with
device-specific overrides, the system displays the override value when you filter the rules list by only
that device. If the criterion represents an object with domain-specific overrides, the system displays
the override value when you filter the rules list by devices in that domain.
Step 3 Click OK.
Related Topics
Creating and Editing Access Control Rules, on page 1236
Configuring Prefiltering, on page 1282
Configuring QoS Rules, on page 616
Configure NAT for Threat Defense, on page 1037
Tip Hover your pointer over an icon to read the warning, error, or informational text.
You can deploy a policy that Preempted rules or rules that cannot match traffic due
displays rule or other warnings. to misconfiguration have no effect. This includes
However, misconfigurations conditions using empty object groups, application
marked with warnings have no filters that match no applications, excluded LDAP
warning
effect. users, invalid ports, and so on.
If you disable a rule with a However, if a warning icon marks a licensing error
warning, the warning icon or model mismatch, you cannot deploy until you
disappears. It reappears if you correct the issue.
enable the rule without correcting
the underlying issue.
Information icons convey helpful With application control and URL filtering, the
information about configurations system may skip matching the first few packets of a
that may affect the flow of traffic. connection against some rules, until the system
These issues do not prevent you identifies the application or web traffic in that
information
from deploying. connection. This allows connections to be established
so that applications and HTTP requests can be
identified.
Related Topics
Limitations to Application Control, on page 320
Limitations to URL Filtering, on page 326
Note Always order rules to suit your organization's needs. Place top-priority rules that must apply to all traffic
near the top of the policy. However, rules with application or URL conditions are more likely to match
traffic if you do not prioritize them. This occurs because the system may skip matching the first few
packets of a connection against some rules until the system identifies the application or web traffic in that
connection. This allows connections to be established so that applications and HTTP requests can be
identified.
Related Topics
Limitations to Application Control, on page 320
Limitations to URL Filtering, on page 326
• SSL rules that decrypt traffic—Not only the decryption, but further analaysis of the decrypted traffic,
requires resources. Narrow focus, and where possible, block or choose not to decrypt encrypted traffic.
• Access control rules that invoke deep inspection—Intrusion, file, and malware inspection requires
resources, especially if you use multiple custom intrusion policies and variable sets. Make sure you only
invoke deep inspection where required.
For maximum performance benefit, constrain rules by interface. If a rule excludes all of a device’s interfaces,
that rule does not affect that device's performance.
Rule Preemption
Rule preemption occurs when a rule will never match traffic because a rule earlier in the evaluation order
matches the traffic first. A rule's conditions govern whether it preempts other rules. In the following example,
the second rule cannot block Admin traffic because the first rule allows it:
Any type of rule condition can preempt a subsequent rule. The VLAN range in the first SSL rule includes the
VLAN in the second rule, so the first rule preempts the second:
In the following example, Rule 1 matches any VLAN because no VLANs are configured, so Rule 1 preempts
Rule 2, which attempts to match VLAN 2:
A rule also preempts an identical subsequent rule where all configured conditions are the same:
If you reverse the rules, you first match all traffic trusted by Good CA, including traffic trusted by Bad CA.
Because no traffic ever matches the subsequent Bad CA rule, malicious traffic may be allowed instead of
blocked.
traffic matches to the Safe Search rule unless YouTube EDU is enabled in a rule with a higher evaluation
priority.
A similar rule preemption occurs if you position an SSL rule with the safesearch supported filter higher
in the evaluation order than an SSL rule with specific YouTube application conditions.
Related Topics
About Content Restriction, on page 1299
The Firepower 9300 chassis can offload connections that meet the following criteria:
• They are fastpathed by the prefilter policy.
• IPv4 addresses only.
• TCP, UDP, GRE only.
• Standard or 802.1Q tagged Ethernet frames only.
• Switched or routed interfaces only. Not supported on passive, inline, or inline tap interfaces.
To identify a flow as being eligible for offload, create a prefilter policy rule that applies the Fastpath action.
Use prefilter rules for TCP/UDP, and tunnel rules for GRE. Incidentally, if you configure access control rules
to apply the Trust action based on security zone, source and destination network and port matching only, and
you disable Security Intelligence, flows matching those rules are also eligible for offloading.
Once a connection is established, if it is eligible to be offloaded, further processing happens in the NIC rather
than in the Firepower Threat Defense software. Offloaded flows continue to receive limited stateful inspection,
such as basic TCP flag and option checking. The system can selectively escalate packets to the firewall system
for further processing if necessary.
Reverse flows for offloaded flows are also offloaded.
After you edit an object used in an active policy, you must redeploy the changed configuration for your changes
to take effect. You cannot delete an object that is in use by an active policy.
Object Types
The following table lists the objects you can create in the Firepower System, and indicates whether each object
type can be grouped or configured to allow overrides.
Interface: no no
• Security Zone
• Interface Group
Tunnel Zone no no
Application Filter no no
Geolocation no no
Time Range no no
Variable Set no no
Sinkhole no no
File List no no
SLA Monitor no no
AS Path no yes
Note Because security zones and interface groups are tied to device interfaces, which you configure at the leaf
level, administrators in descendant domains can view and edit zones and groups created in ancestor
domains. Subdomain users can add and delete interfaces from ancestor zones and groups, but cannot delete
or rename the zones/groups.
Object names must be unique within the domain hierarchy. The system may identify a conflict with the name
of an object you cannot view in your current domain.
For objects that support grouping, you can group objects in the current domain with objects inherited from
ancestor domains.
Object overrides allow you to define device-specific or domain-specific values for certain types of object,
including network, port, VLAN tag, and URL. In a multidomain deployment, you can define a default value
for an object in an ancestor domain, but allow administrators in descendant domains to add override values
for that object.
Editing Objects
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Access
Admin/Network
Admin
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
In a multidomain deployment, the system displays objects created in the current and ancestor domains, which
you can filter.
Procedure
Sorting Objects
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Access
Admin/Network
Admin
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Object Groups
Grouping objects allows you to reference multiple objects with a single configuration. The system allows you
to use objects and object groups interchangeably in the web interface. For example, anywhere you would use
a port object, you can also use a port object group.
You can group network, port, VLAN tag, URL, and PKI objects. Network object groups can be nested, that
is, you can add a network object group to another network object group up to 10 levels.
Objects and object groups of the same type cannot have the same name. In a multidomain deployment, the
names of object groups must be unique within the domain hierarchy. Note that the system may identify a
conflict with the name of an object group you cannot view in your current domain.
When you edit an object group used in a policy (for example, a network object group used in an access control
policy), you must re-deploy the changed configuration for your changes to take effect.
Deleting a group does not delete the objects in the group, just their association with each other. Additionally,
you cannot delete a group that is in use in an active policy. For example, you cannot delete a VLAN tag group
that you are using in a VLAN condition in a saved access control policy.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can group objects in the current domain with objects inherited from ancestor domains.
Procedure
Step 7 Optionally for Network, Port, URL, and VLAN Tag groups:
• Enter a Description.
• Check the Allow Overrides check box to allow overrides for this object group; see Allowing Object
Overrides, on page 352.
What to Do Next
• If an active policy references your object group, deploy configuration changes; see Deploying
Configuration Changes, on page 288.
Object Overrides
An object override allows you to define an alternate value for an object, which the system uses for the devices
you specify.
You can create an object whose definition works for most devices, and then use overrides to specify
modifications to the object for the few devices that need different definitions. You can also create an object
that needs to be overridden for all devices, but its use allows you to create a single policy for all devices.
Object overrides allow you to create a smaller set of shared policies for use across devices without giving up
the ability to alter policies when needed for individual devices.
For example, you might want to deny ICMP traffic to the different departments in your company, each of
which is connected to a different network. You can do this by defining an access control policy with a rule
that includes a network object called Departmental Network. By allowing overrides for this object, you can
then create overrides on each relevant device that specifies the actual network where that device is connected.
In a multidomain deployment, you can define a default value for an object in an ancestor domain and allow
administrators in descendant domains to add override values for that object. For example, a managed security
service provider (MSSP) might use a single Firepower Management Center to manage network security for
multiple customers. Administrators at the MSSP can define an object in the Global domain for use in all
customers' deployments. Administrators for each customer can log into descendant domains to override that
object for their organizations. These local administrators cannot view or affect the override values of other
customers of the MSSP.
You can target an object override to a specific domain. In this case, the system uses the object override value
for all devices in the targeted domain unless you override it at the device level.
From the object manager, you can choose an object that can be overridden and define a list of device-level or
domain-level overrides for that object.
You can use object overrides with the following object types only:
• Network
• Port
• VLAN tag
• URL
• SLA Monitor
• Prefix List
• Route Map
• Access List
• AS Path
• Community List
• Policy List
• PKI Enrollment
If you can override an object, the Override column appears for the object type in the object manager. Possible
values for this column include:
• Green checkmark — indicates that you can create overrides for the object and no overrides have been
added yet
• Red X — indicates that you cannot create overrides for the object
• Number — represents a count of the overrides that have been added to that object (for example, "2"
indicates two overrides have been added)
Procedure
Procedure
Step 1 In the object editor, check the Allow Overrides check box.
Step 2 Click Save.
What to Do Next
• Add object override values; see Adding Object Overrides, on page 352.
Procedure
Example:
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can modify the description and the value of an existing override, but you cannot modify the existing
target list. Instead, you must add a new override with new targets, which replaces the existing override.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Network Objects
A network object represents one or more IP addresses. You can use network objects and groups in various
places in the system’s web interface, including access control policies, network variables, intrusion rules,
identity rules, network discovery rules, event searches, reports, and so on.
When you configure an option that requires a network object, the list is automatically filtered to show only
those objects that are valid for the option. For example, some options require host objects, while other options
require subnets.
IPv6 example:
2001:DB8::0DB8:800:200C:417A or 2001:DB8:0:0:0DB8:800:200C:417A
Network
An address block, also known as a subnet.
IPv4 example:
209.165.200.224/27
IPv6 example:
2001:DB8:0:CD30::/60
Address Range
A range of IP addresses.
IPv4 example:
209.165.200.225-209.165.200.250
IPv6 example:
2001:db8:0:cd30::1-2001:db8:0:cd30::1000
Group
A group of network objects or other network object groups.
For example:
209.165.200.225
209.165.201.1
209.165.202.129
You can create nested groups by adding one network object group to another network object group.
You can nest up to 10 levels of groups.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Port Objects
Port objects represent different protocols in slightly different ways:
TCP and UDP
A port object represents the transport layer protocol, with the protocol number in parentheses, plus an
optional associated port or port range. For example: TCP(6)/22.
You can restrict an ICMP or IPV6-ICMP port object by type and, if applicable, code. For more
information on ICMP types and codes, see:
• http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml
• http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml
Other
A port object can represent other protocols that do not use ports.
The Firepower System provides default port objects for well-known ports. You cannot modify or delete these
default objects. You can create custom port objects in addition to the default objects.
You can use port objects and groups in various places in the system’s web interface, including access control
policies, identity rules, network discovery rules, port variables, and event searches. For example, if your
organization uses a custom client that uses a specific range of ports and causes the system to generate excessive
and misleading events, you can configure your network discovery policy to exclude monitoring those ports.
When using port objects, observe the following guidelines:
• You cannot add any protocol other than TCP or UDP for source port conditions in access control rules.
Also, you cannot mix transport protocols when setting both source and destination port conditions in a
rule.
• If you add an unsupported protocol to a port object group used in a source port condition, the rule where
it is used does not take affect on the managed device when the configuration is deployed.
• If you create a port object containing both TCP and UDP ports, then add it as a source port condition in
a rule, you cannot add a destination port, and vice versa.
Procedure
• If you want to add override values to this object, expand the Override section and click Add; see Adding
Object Overrides, on page 352.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Although tunnel zones are not interface objects, you can use them in place of security zones in certain
configurations; see Tunnel Zones and Prefiltering, on page 1285.
All interfaces in an interface object must be of the same type: all inline, passive, switched, routed, or ASA
FirePOWER. After you create an interface object, you cannot change the type of interfaces it contains.
The Interface Objects page of the object manager lists the security zones and interface groups configured on
your managed devices. The page also displays the type of interfaces in each interface object, and you can
expand each interface object to view which interfaces on which devices belong to each object.
Unless restricted by role, subdomain users can view and edit interface objects created in ancestor domains.
Subdomain users can add and delete interfaces from these interface objects. They cannot, however, delete or
rename the interface objects. You can neither view nor edit interface objects created in descendant domains.
Tip You can create empty interface objects and add interfaces to them later. To add an interface, the interface
must have a name. You can also create security zones (but not interface groups) while configuring interfaces
in Devices > Device Management.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Tunnel Zones
A tunnel zone represents certain types of plaintext, passthrough tunnels that you explicitly tag for special
analysis. A tunnel zone is not an interface object, even though you can use it as an interface constraint in some
configurations.
For detailed information, see Tunnel Zones and Prefiltering, on page 1285.
Application Filters
System-provided application filters help you perform application control by organizing applications according
to basic characteristics: type, risk, business relevance, category, and tags. In the object manager, you can
create and manage reuseable user-defined application filters based on combinations of the system-provided
filters, or on custom combinations of applications. For detailed information, see Application Conditions
(Application Control), on page 316.
Procedure
• If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing
Object Overrides, on page 352.
• If you want to add override values to this object, expand the Override section and click Add; see Adding
Object Overrides, on page 352.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Related Topics
Autotransition from Custom SGTs to ISE SGTs, on page 333
Custom SGT Conditions, on page 332
ISE SGT vs Custom SGT Rule Conditions, on page 332
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
URL Objects
Each URL object you configure represents a single URL or IP address. You can use URL objects and groups
in various places in the system’s web interface, including access control policies and event searches. For
example, you could write an access control rule that blocks a specific website.
When creating URL objects, especially if you do not configure SSL inspection to decrypt or block encrypted
traffic, keep the following points in mind:
• If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using
the subject common name in the public key certificate used to encrypt the traffic. Also, the system
disregards subdomains within the subject common name, so do not include subdomain information. For
example, use example.com rather than www.example.com.
• When matching web traffic using access control rules with URL conditions, the system disregards the
encryption protocol (HTTP vs HTTPS). In other words, if you block a website, both HTTP and HTTPS
traffic to that website is blocked, unless you use an application condition to refine the rule. When creating
a URL object, you do not need to specify the protocol when creating an object. For example, use
example.com rather than http://example.com/.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Geolocation Objects
Each geolocation object you configure represents one or more countries or continents that the system has
identified as the source or destination of traffic on your monitored network. You can use geolocation objects
in various places in the system’s web interface, including access control policies, SSL policies, and event
searches. For example, you could write an access control rule that blocks traffic to or from certain countries.
To ensure that you are using up-to-date information to filter your network traffic, Cisco strongly recommends
that you regularly update your Geolocation Database (GeoDB).
Procedure
Step 5 Check the check boxes for the countries and continents you want to include in your geolocation object.
Checking a continent chooses all countries within that continent, as well as any countries that GeoDB updates
may add under that continent in the future. Unchecking any country under a continent unchecks the continent.
You can choose any combination of countries and continents.
Step 6 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Procedure
• To specify a single continuous range, such as typical weekend hours (Fridays at 5pm through Mondays
at 8am, including evenings and nights), choose Range Type Range.
• To specify part of multiple days, such as Monday through Friday from 8am to 5pm (excluding evenings,
nights, and early mornings every day), choose Range Type Daily Interval.
• To specify multiple noncontiguous times of day or different hours for different days, create multiple
recurring intervals. For example, to apply a policy at all times other than standard working hours, create
a single time range object with the following two recurring intervals:
◦A Daily Interval for Monday through Friday from 5pm through 8am, and
◦A Range recurring interval for Friday at 5pm through Monday at 8am.
What to Do Next
Specify the time range object in a VPN group policy object using the Access Hours field.
For details, see Configure Group Policy Objects, on page 434 and Group Policy Advanced Options, on page
438.
Variable Sets
Variables represent values commonly used in intrusion rules to identify source and destination IP addresses
and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions,
adaptive profile updates, and dynamic rule states.
Tip Preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion
rules.
You use variable sets to manage, customize, and group your variables. You can use the default variable set
provided by the system or create your own custom sets. Within any set you can modify predefined default
variables and add and modify user-defined variables.
Most of the shared object rules and standard text rules that the Firepower System provides use predefined
default variables to define networks and port numbers. For example, the majority of the rules use the variable
$HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or
outside) network. In addition, specialized rules often use other predefined variables. For example, rules that
detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.
Rules are more effective when variables more accurately reflect your network environment. At a minimum,
you should modify default variables in the default set. By ensuring that a variable such as $HOME_NET correctly
defines your network and $HTTP_SERVERS includes all web servers on your network, processing is optimized
and all relevant systems are monitored for suspicious activity.
To use your variables, you link variable sets to intrusion policies associated with access control rules or with
the default action of an access control policy. By default, the default variable set is linked to all intrusion
policies used by access control policies.
Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all variables currently
configured on your system. Within any variable set, you can add user-defined variables and customize the
value of any variable.
Initially, the Firepower System provides a single, default variable set comprised of predefined default values.
Each variable in the default set is initially set to its default value, which for a predefined variable is the value
set by the Cisco Talos Security Intelligence and Research Group (Talos) and provided in rule updates.
Although you can leave predefined default variables configured to their default values, Cisco recommends
that you modify a subset of predefined variables.
You could work with variables only in the default set, but in many cases you can benefit most by adding one
or more custom sets, configuring different variable values in different sets, and perhaps even adding new
variables.
When using multiple sets, it is important to remember that the current value of any variable in the default set
determines the default value of the variable in all other sets.
When you select Variable Sets on the Object Manager page, the object manager lists the default variable set
and any custom sets you created.
On a freshly installed system, the default variable set is comprised only of the default variables predefined
by Cisco.
Each variable set includes the default variables provided by the system and all custom variables you have
added from any variable set. Note that you can edit the default set, but you cannot rename or delete the default
set.
In a multidomain deployment, the system generates a default variable set for each subdomain.
Caution Importing an access control or an intrusion policy overwrites existing default variables in the default
variable set with the imported default variables. If your existing default variable set contains a custom
variable not present in the imported default variable set, the unique variable is preserved.
Related Topics
Managing Variables, on page 378
Managing Variable Sets, on page 377
Variables
Variables belong to one of the following categories:
Default Variables
Variables provided by the Firepower System. You cannot rename or delete a default variable, and you
cannot change its default value. However, you can create a customized version of a default variable.
Customized Variables
Variables you create. These variables can include:
• customized default variables
When you edit the value for a default variable, the system moves the variable from the Default
Variables area to the Customized Variables area. Because variable values in the default set
determine the default values of variables in custom sets, customizing a default variable in the
default set modifies the default value of the variable in all other sets.
• user-defined variables
You can add and delete your own variables, customize their values within different variable sets,
and reset customized variables to their default values. When you reset a user-defined variable, it
remains in the Customized Variables area.
User-defined variables can be one of the following types:
◦network variables specify the IP addresses of hosts in your network traffic.
◦port variables specify TCP or UDP ports in network traffic, including the value any for
either type.
For example, if you create custom standard text rules, you might also want to add your own user-defined
variables to more accurately reflect your traffic or as shortcuts to simplify the rule creation process.
Alternatively, if you create a rule that you want to inspect traffic in the “demilitarized zone” (or DMZ)
only, you can create a variable named $DMZ whose value lists the server IP addresses that are exposed.
You can then use the $DMZ variable in any rule written for this zone.
Advanced Variables
Variables provided by the Firepower System under specific conditions. These variables have a very
limited deployment.
Caution Importing an access control or an intrusion policy overwrites existing default variables in the default
variable set with the imported default variables. If your existing default variable set contains a custom
variable not present in the imported default variable set, the unique variable is preserved.
The following table describes the variables provided by the system and indicates which variables you typically
would modify. For assistance determining how to tailor variables to your network, contact Professional
Services or Support.
Defines Domain Name Service (DNS) servers. If you create a rule that Not required in current rule set.
$DNS_SERVERS
affects DNS servers specifically, you can use the $DNS_SERVERS variable
as a destination or source IP address.
Defines the network that the Firepower System views as the unprotected Yes, you should adequately define
$EXTERNAL_NET
network, and is used in many rules to define the external network. $HOME_NET and then exclude
$HOME_NET as the value for
$EXTERNAL_NET.
Defines non-encrypted ports used in intrusion rules that detect files in Not required.
$FILE_DATA_PORTS
a network stream.
Defines the ports of FTP servers on your network, and is used for FTP Yes, if your FTP servers use ports
$FTP_PORTS
server exploit rules. other than the default ports (you
can view the default ports in the
web interface).
Defines the data channel ports where the packet decoder extracts the Not required.
$GTP_PORTS
payload inside a GTP (General Packet Radio Service [GPRS] Tunneling
Protocol) PDU.
Defines the network that the associated intrusion policy monitors, and Yes, to include the IP addresses for
$HOME_NET
is used in many rules to define the internal network. your internal network.
Defines the ports of web servers on your network, and is used for web Yes, if your web servers use ports
$HTTP_PORTS
server exploit rules. other than the default ports (you
can view the default ports in the
web interface).
Defines the web servers on your network. Used in web server exploit Yes, if you run HTTP servers.
$HTTP_SERVERS
rules.
Defines Oracle database server ports on your network, and is used in Yes, if you run Oracle servers.
$ORACLE_PORTS
rules that scan for attacks on Oracle databases.
Defines the ports you want the system to scan for shell code exploits, Not required.
$SHELLCODE_PORTS
and is used in rules that detect exploits that use shell code.
Defines the ports of SIP servers on your network, and is used for SIP Not required.
$SIP_PORTS
exploit rules.
Defines SIP servers on your network, and is used in rules that address
$SIP_SERVERS
SIP-targeted exploits.
Defines SMTP servers on your network, and is used in rules that address Yes, if you run SMTP servers.
$SMTP_SERVERS
exploits that target mail servers.
Defines SNMP servers on your network, and is used in rules that scan Yes, if you run SNMP servers.
$SNMP_SERVERS
for attacks on SNMP servers.
Identifies a legacy advanced variable that appears only when it existed No, you can only view or delete
$SNORT_BPF
on your system in a Firepower System software release before Version this variable. You cannot edit it or
5.3.0 that you subsequently upgraded to Version 5.3.0 or greater. recover it after deleting it.
Defines database servers on your network, and is used in rules that Yes, if you run SQL servers.
$SQL_SERVERS
address database-targeted exploits.
Defines the ports of SSH servers on your network, and is used for SSH Yes, if your SSH servers use ports
$SSH_PORTS
server exploit rules. other than the default port (you can
view the default ports in the web
interface).
Defines SSH servers on your network, and is used in rules that address Yes, if you run SSH servers, you
$SSH_SERVERS
SSH-targeted exploits. should adequately define
$HOME_NET and then include
$HOME_NET as the value for
$SSH_SERVERS.
Defines known Telnet servers on your network, and is used in rules that Yes, if you run Telnet servers.
$TELNET_SERVERS
address Telnet server-targeted exploits.
Provides a general tool that allows you to configure one or more features No, only as instructed in a feature
$USER_CONF
not otherwise available via the web interface. description or with the guidance of
Conflicting or duplicate $USER_CONF configurations will halt the system. Support.
Network Variables
Network variables represent IP addresses you can use in intrusion rules that you enable in an intrusion policy
and in intrusion policy rule suppressions, dynamic rule states, and adaptive profile updates. Network variables
differ from network objects and network object groups in that network variables are specific to intrusion
policies and intrusion rules, whereas you can use network objects and groups to represent IP addresses in
various places in the system’s web interface, including access control policies, network variables, intrusion
rules, network discovery rules, event searches, reports, and so on.
You can use network variables in the following configurations to specify the IP addresses of hosts on your
network:
• intrusion rules—Intrusion rule Source IPs and Destination IPs header fields allow you to restrict packet
inspection to the packets originating from or destined to specific IP addresses.
• suppressions—The Network field in source or destination intrusion rule suppressions allows you to
suppress intrusion event notifications when a specific IP address or range of IP addresses triggers an
intrusion rule or preprocessor.
• dynamic rule states—The Network field in source or destination dynamic rule states allows you to detect
when too many matches for an intrusion rule or preprocessor rule occur in a given time period.
• adaptive profile updates—When you enable adaptive profile updates, the adaptive profiles Networks
field identifies hosts where you want to improve reassembly of packet fragments and TCP streams in
passive deployments.
When you use variables in the fields identified in this section, the variable set you link to an intrusion policy
determines the variable values in the network traffic handled by an access control policy that uses the intrusion
policy.
You can add any combination of the following network configurations to a variable:
• any combination of network variables, network objects, and network object groups that you select from
the list of available networks
• individual network objects that you add from the New Variable or Edit Variable page, and can then add
to your variable and to other existing and future variables
• literal, single IP addresses or address blocks
You can list multiple literal IP addresses and address blocks by adding each individually. You can list
IPv4 and IPv6 addresses and address blocks alone or in any combination. When specifying IPv6 addresses,
you can use any addressing convention defined in RFC 4291.
The default value for included networks in any variable you add is the word any, which indicates any IPv4
or IPv6 address. The default value for excluded networks is none, which indicates no network. You can also
specify the address :: in a literal value to indicate any IPv6 address in the list of included networks, or no
IPv6 addresses in the list of exclusions.
Adding networks to the excluded list negates the specified addresses and address blocks. That is, you can
match any IP address with the exception of the excluded IP address or address blocks.
For example, excluding the literal address 192.168.1.1 specifies any IP address other than 192.168.1.1, and
excluding 2001:db8:ca2e::fa4c specifies any IP address other than 2001:db8:ca2e::fa4c.
You can exclude any combination of networks using literal or available networks. For example, excluding
the literal values 192.168.1.1 and 192.168.1.5 includes any IP address other than 192.168.1.1 or 192.168.1.5.
That is, the system interprets this as “not 192.168.1.1 and not 192.168.1.5,” which matches any IP address
other than those listed between brackets.
Note the following points when adding or editing network variables:
• You cannot logically exclude the value any which, if excluded, would indicate no address. For example,
you cannot add a variable with the value any to the list of excluded networks.
• Network variables identify traffic for the specified intrusion rule and intrusion policy features. Note that
preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion
rules.
• Excluded values must resolve to a subset of included values. For example, you cannot include the address
block 192.168.5.0/24 and exclude 192.168.6.0/24.
Port Variables
Port variables represent TCP and UDP ports you can use in the Source Port and Destination Port header
fields in intrusion rules that you enable in an intrusion policy. Port variables differ from port objects and port
object groups in that port variables are specific to intrusion rules. You can create port objects for protocols
other than TCP and UDP, and you can use port objects in various places in the system’s web interface, including
port variables, access control policies, network discovery rules, and event searches.
You can use port variables in the intrusion rule Source Port and Destination Port header fields to restrict
packet inspection to packets originating from or destined to specific TCP or UDP ports.
When you use variables in these fields, the variable set you link to the intrusion policy associated with an
access control rule or policy determines the values for these variables in the network traffic where you deploy
the access control policy.
You can add any combination of the following port configurations to a variable:
• any combination of port variables and port objects that you select from the list of available ports
Note that the list of available ports does not display port object groups, and you cannot add these to
variables.
• individual port objects that you add from the New Variable or Edit Variable page, and can then add to
your variable and to other existing and future variables
Only TCP and UDP ports, including the value any for either type, are valid variable values. If you use
the new or edit variables page to add a valid port object that is not a valid variable value, the object is
added to the system but is not displayed in the list of available objects. When you use the object manager
to edit a port object that is used in a variable, you can only change its value to a valid variable value.
• single, literal port values and port ranges
You must separate port ranges with a dash (-). Port ranges indicated with a colon (:) are supported for
backward compatibility, but you cannot use a colon in port variables that you create.
You can list multiple literal port values and ranges by adding each individually in any combination.
Tip To create a variable with the value any, name and save the variable without adding a
specific value.
• You cannot logically exclude the value any which, if excluded, would indicate no ports. For example,
you cannot save a variable set when you add a variable with the value any to the list of excluded ports.
• Adding ports to the excluded list negates the specified ports and port ranges. That is, you can match any
port with the exception of the excluded ports or port ranges.
• Excluded values must resolve to a subset of included values. For example, you cannot include the port
range 10-50 and exclude port 60.
Advanced Variables
Advanced variables allow you to configure features that you cannot otherwise configure via the web interface.
The Firepower System currently provides only two advanced variables, and you can only edit the USER_CONF
advanced variable.
USER_CONF
USER_CONF provides a general tool that allows you to configure one or more features not otherwise available
via the web interface.
Caution Do not use the advanced variable USER_CONF to configure an intrusion policy feature unless you are
instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will
halt the system.
When editing USER_CONF, you can type up to 4096 total characters on a single line; the line wraps
automatically. You can include any number of valid instructions or lines until you reach the 8192 maximum
character length for a variable or a physical limit such as disk space. Use the backslash (\) line continuation
character after any complete argument in a command directive.
Resetting USER_CONF empties it.
SNORT_BPF
SNORT_BPF is a legacy advanced variable that appears only when it was configured on your system in a
Firepower System software release before Version 5.3.0 that you subsequently upgraded to Version 5.3.0 or
greater. You can only view or delete this variable. You cannot edit it or recover it after deleting it.
This variable allowed you to apply a Berkeley Packet Filter (BPF) to filter traffic before it reached the system.
You should now use access control rules instead of this variable to enforce the filtering once offered by
SNORT_BPF. This variable appears only with configurations that existed before system upgrade.
Variable Reset
You can reset a variable to its default value on the variable set new or edit variables page. The following table
summarizes the basic principles of resetting variables.
Resetting a variable in a custom set simply resets it to the current value for that variable in the default set.
Conversely, resetting or modifying the value of a variable in the default set always updates the default value
of that variable in all custom sets. When the reset icon is grayed out, indicating that you cannot reset the
variable, this means that the variable has no customized value in that set. Unless you have customized the
value for a variable in a custom set, a change to the variable in the default set updates the value used in any
intrusion policy where you have linked the variable set.
Note It is good practice when you modify a variable in the default set to assess how the change affects any
intrusion policy that uses the variable in a linked custom set, especially when you have not customized
the variable value in the custom set.
You can hover your pointer over the reset icon ( ) in a variable set to see the reset value. When the customized
value and the reset value are the same, this indicates one of the following:
• you are in the custom or default set where you added the variable with the value any
• you are in the custom set where you added the variable with an explicit value and elected to use the
configured value as the default value
You can customize the value of Var1 in any set. In Custom Set 2 where Var1 has not been customized, its
value is 192.168.1.0/24. In Custom Set 1 the customized value 192.168.2.0/24 of Var1 overrides the default
value. Resetting a user-defined variable in the default set resets its default value to any in all sets.
It is important to note in this example that, if you do not update Var1 in Custom Set 2, further customizing or
resetting Var1 in the default set consequently updates the current, default value of Var1 in Custom Set 2,
thereby affecting any intrusion policy linked to the variable set.
Although not shown in the example, note that interactions between sets are the same for user-defined variables
and default variables except that resetting a default variable in the default set resets it to the value configured
by Cisco in the current rule update.
Note that, except for the origin of Var1 from Custom Set 1, this example is identical to the example above
where you added Var1 to the default set. Adding the customized value 192.168.1.0/24 for Var1 to Custom
Set 1 copies the value to the default set as a customized value with a default value of any. Thereafter, Var1
values and interactions are the same as if you had added Var1 to the default set. As with the previous example,
keep in mind that further customizing or resetting Var1 in the default set consequently updates the current,
default value of Var1 in Custom Set 2, thereby affecting any intrusion policy linked to the variable set.
In the next example, you add Var1 with the value 192.168.1.0/24 to Custom Set 1 as in the previous example,
but you elect not to use the configured value of Var1 as the default value in other sets.
This approach adds Var1 to all sets with a default value of any. After adding Var1, you can customize its
value in any set. An advantage of this approach is that, by not initially customizing Var1 in the default set,
you decrease your risk of customizing the value in the default set and thus inadvertently changing the current
value in a set such as Custom Set 2 where you have not customized Var1.
Nesting Variables
You can nest variables so long as the nesting is not circular. Nested, negated variables are not supported.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Managing Variables
Smart License Classic License Supported Devices Supported Domains Access
Threat Protection Any Any Admin/Access
Admin/Network
Admin
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
• Delete — Click the delete icon ( ) next to the variable. If you have saved the variable set since adding
the variable, click Yes to confirm that you want to delete the variable.
You cannot delete the following:
◦default variables
◦user-defined variables that are used by intrusion rules or other variables
◦variables belonging to ancestor domains
• Edit — Click the edit icon ( ) next to the variable you want to edit; see Editing Variables, on page
380.
• Reset — If you want to reset a modified variable to its default value, click the reset icon ( ) next to a
modified variable. If the reset icon is dimmed, one of the following is true:
◦The current value is already the default value.
◦The configuration belongs to an ancestor domain.
Tip Hover your pointer over an active reset icon to display the default
value.
Step 5 Click Save to save the variable set. If the variable set is in use by an access control policy, click Yes to confirm
that you want to save your changes.
Because the current value in the default set determines the default value in all other sets, modifying or resetting
a variable in the default set changes the current value in other sets where you have not customized the default
value.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Adding Variables
Procedure
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.
Step 5 Click Save to save the variable. If you are adding a new variable from a custom set, you have the following
options:
• Click Yes to add the variable using the configured value as the customized value in the default set and,
consequently, the default value in other custom sets.
• Click No to add the variable as the default value of any in the default set and, consequently, in other
custom sets.
Step 6 Click Save to save the variable set. Your changes are saved, and any access control policy the variable set is
linked to displays an out-of-date status.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Editing Variables
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can edit both custom and default variables.
You cannot change the Name or Type values in an existing variable.
Procedure
Step 1 In the variable set editor, click the edit icon ( ) next to the variable you want to modify.
If a view icon ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission
to modify the object.
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.
Step 3 Click Save to save the variable.
Step 4 Click Save to save the variable set. If the variable set is in use by an access control policy, click Yes to confirm
that you want to save your changes. Your changes are saved, and any access control policy the variable set
is linked to displays an out-of-date status.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
• URLs—Use in access control policies to blacklist and whitelist as part of Security Intelligence. You can
also use URL lists in access control and QoS rules, whose analysis and traffic handling phases occur
after Security Intelligence.
Lists
A list is a static collection that you manage manually.
By default, access control and DNS policies use Global blacklists and whitelists as part of Security Intelligence.
Whitelist Now and Blacklist Now actions allow you to build and implement these lists without redeploying;
see Blacklist Now, Whitelist Now, and Global Lists, on page 383.
Custom lists can augment and fine-tune feeds and the Global lists, although implementing custom lists requires
redeploy.
Feeds
A feed is a dynamic collection that updates on an interval over HTTP or HTTPS.
The regularly updated Cisco Intelligence Feed allows you to filter network traffic based on the latest threat
intelligence from Talos. You can also use third-party feeds. Or, with a custom internal feed, you could easily
maintain an enterprise-wide blacklist in a large deployment with multiple Firepower Management Centers.
When the system updates a feed, although it may take a few minutes for your changes to propagate, you do
not have to redeploy. If you want strict control over when the system updates a feed from the Internet, you
can disable automatic updates for that feed. However, automatic updates ensure the most up-to-date, relevant
data.
Note The system does not perform peer SSL certificate verification when downloading custom feeds, nor does
the system support the use of certificate bundles or self-signed certificates to verify the remote peer.
Tip The number of entries you can include is limited by the maximum size of the file. For example, a URL
list with no comments and an average URL length of 100 characters (including Punycode or percent
Unicode representations and newlines) can contain more than 5.24 million entries.
In a DNS list entry, you can specify an asterisk (*) wildcard character for a domain label. All labels match
the wildcard. For example, an entry of www.example.* matches both www.example.com and www.example.co.
If you add comment lines within the source file, they must start with the pound (#) character. If you upload
a source file with comments, the system removes your comments during upload. Source files you download
contain all your entries without your comments.
If the system downloads a corrupt feed or a feed with no recognizable entries, the system continues using the
old feed data (unless it is the first download). However, if the system can recognize even one entry in the
feed, it uses the entries it can recognize.
Custom whitelists and blacklists Upload new and replacement lists Yes
using the object manager.
Note These options apply to Security Intelligence only. Security Intelligence cannot blacklist traffic that has
already been fastpathed. Similarly, Security Intelligence whitelisting does not automatically trust or fastpath
matching traffic. For more information, see About Security Intelligence, on page 1257.
Blacklist HTTP/S Connections to URL Now A URL Global Blacklist for URL
Whitelist HTTP/S Connections to URL Now Global Whitelist for URL
Blacklist DNS Requests to Domain Now DNS requests for an entire Global Blacklist for DNS
domain
Whitelist DNS Requests to Domain Now Global Whitelist for DNS
In a multidomain deployment, you can choose the Firepower System domains where you want to enforce the
blacklisting or whitelisting by adding items to Domain lists as well as the Global lists; see Security Intelligence
Lists and Multitenancy, on page 384.
Because adding an entry to a Security Intelligence list affects access control, you must have one of:
• Administrator access
• A combination of default roles: Network Admin or Access Admin, plus Security Analyst and Security
Approver
• A custom role with both Modify Access Control Policy and Deploy Configuration to Devices permissions
Domain Lists
In addition to being able to access (but not edit) the Global lists, each subdomain has its own named lists, the
contents of which apply only to that subdomain. For example, a subdomain named Company A owns:
• Domain Blacklist - Company A and Domain Whitelist - Company A
• Domain Blacklist for DNS - Company A, Domain Whitelist for DNS - Company A
• Domain Blacklist for URL - Company A, Domain Whitelist for URL - Company A
Any administrator at or above the current domain can populate these lists. You can use the context menu to
whitelist or blacklist an item in the current and all descendant domains. However, only an administrator in
the associated domain can remove an item from a Domain list.
For example, a Global administrator could choose to blacklist the same IP address in the Global domain and
Company A’s domain, but not blacklist it in Company B’s domain. This action would add the same IP address
to:
• Global Blacklist (where it can be removed only by Global administrators)
• Domain Blacklist - Company A (where it can be removed only by Company A administrators)
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
Note Descendant Domain lists do not appear in the object manager because they are symbolic aggregations,
not hand-populated lists. They appear where you can use them: in access control and DNS policies.
Although you cannot delete the system-provided feeds, you can change the frequency of (or disable) their
updates. By default, each feed updates every two hours.
In a multidomain deployment, the system-provided feeds belong to the Global domain and can be modified
only by an administrator in that domain. You can modify the update frequency for custom feeds belonging
to your domain.
Procedure
Note You cannot whitelist or blacklist address blocks using a /0 netmask in a Security Intelligence feed. If you
want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor or
Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.
When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded. By
default, the system downloads the entire feed source on the interval you configure, then automatically updates
its managed devices.
You also can configure the system to use an md5 checksum to determine whether to download an updated
feed. If the checksum has not changed since the last time the system downloaded the feed, the system does
not need to re-download it. You may want to use md5 checksums for internal feeds, especially if they are
large. The md5 checksum must be stored in a simple text file with only the checksum. Comments are not
supported.
Manually updating Security Intelligence feeds updates all feeds, including the Intelligence Feeds.
Procedure
Procedure
After the Firepower Management Center downloads and verifies the feed updates, it communicates any changes
to its managed devices. Your deployment begins filtering traffic using the updated feeds.
Note You cannot whitelist or blacklist address blocks using a /0 netmask in a Security Intelligence list. If you
want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor or
Block rule action, respectively, and a default value of any for the Source Networks and Destination
Networks.
To modify a Security Intelligence list, you must make your changes to the source file and upload a new copy.
You cannot modify the file’s contents using the web interface. If you do not have access to the source file,
download a copy from the system.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Step 4 If you need a copy of the list to edit, click Download, then follow your browser’s prompts to save the list as
a text file.
Step 5 Make changes to the list as necessary.
Step 6 On the Security Intelligence pop-up window, click Browse to browse to the modified list, then click Upload.
Step 7 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Sinkhole Objects
A sinkhole object represents either a DNS server that gives non-routeable addresses for all domain names
within the sinkhole, or an IP address that does not resolve to a server. You can reference the sinkhole object
within a DNS policy rule to redirect matching traffic to the sinkhole. You must assign the object both an IPv4
address and an IPv6 address.
Procedure
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may
identify a conflict with the name of an object you cannot view in your current domain.
Step 5 Enter the IPv4 Address and IPv6 Address of your sinkhole.
Step 6 You have the following options:
• If you want to redirect traffic to a sinkhole server, choose Log Connections to Sinkhole.
• If you want to redirect traffic to a non-resolving IP address, choose Block and Log Connections to
Sinkhole.
Step 7 If you want to assign an Indication of Compromise (IoC) type to your sinkhole, choose one from the Type
drop-down.
Step 8 Click Save.
File Lists
If you use AMP for Firepower, and the AMP cloud incorrectly identifies a file’s disposition, you can add the
file to a file list to better detect the file in the future. These files are specified using SHA-256 hash values.
Each file list can contain up to 10000 unique SHA-256 values.
There are two predefined categories of file lists:
Clean List
If you add a file to this list, the system treats it as if the AMP cloud assigned a clean disposition.
In a multidomain deployment, a clean list and custom detection list is present for each domain. In lower-level
domains, you can view but not modify ancestor's lists.
Because you manually specify the blocking behavior for the files included in these lists, the system does not
query the AMP cloud for these files’ dispositions. You must configure a rule in the file policy with either a
Malware Cloud Lookup or Block Malware action and a matching file type to calculate a file’s SHA value.
Caution Do not include malware on the clean list. The clean list overrides both the AMP cloud and the custom
detection list.
followed by a description and end with either the LF or CR+LF Newline character. The system ignores any
additional information in the entry.
Note the following:
• Deleting a source file from the file list also removes all associated SHA-256 hashes from the file list.
• You cannot upload multiple files to a file list if the successful source file upload results in the file list
containing more than 10000 distinct SHA-256 values.
• The system truncates descriptions exceeding 256 characters to the first 256 characters on upload. If the
description contains commas, you must use an escape character (\,). If no description is included, the
source file name is used instead.
• All non-duplicate SHA-256 values are added to the file list. If a file list contains a SHA-256 value, and
you upload a source file containing that value, the newly uploaded value does not modify the existing
SHA-256 value. When viewing captured files, file events, or malware events related to the SHA-256
value, any threat name or description is derived from the individual SHA-256 value.
• The system does not upload invalid SHA-256 values in a source file.
• If multiple uploaded source files contain an entry for the same SHA-256 value, the system uses the most
recent value.
• If a source file contains multiple entries for the same SHA-256 value, the system uses the last one.
• You cannot directly edit a source file within the object manager. To make changes, you must first modify
your source file directly, delete the copy on the system, then upload the modified source file.
• The number of entries associated with a source file refers to the number of distinct SHA-256 values. If
you delete a source file from a file list, the total number of SHA-256 entries the file list contains decreases
by the number of valid entries in the source file.
You can submit a file’s SHA-256 value to add it to a file list. You cannot add duplicate SHA-256 values.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Step 4 Choose Enter SHA Value from the Add by drop-down list.
Step 5 Enter a description of the source file in the Description field.
Step 6 Enter or paste the file’s entire value in the SHA-256 field. The system does not support matching partial
values.
Step 7 Click Add.
Step 8 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the
list.
If you have a copy of the file you want to add to a file list, you can upload the file to the Firepower Management
Center for analysis; the system calculates the file’s SHA-256 value and adds the file to the list. The system
does not enforce a limit on the size of files for SHA-256 calculation.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Note After you deploy configuration changes, the system no longer queries the AMP cloud for files on the list.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
If a view icon ( ) appears instead, the object belongs to an ancestor domain, or you do not have permission
to modify the object.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Note After you deploy the policies, the system no longer queries the AMP cloud for files on the list.
You can edit or delete individual SHA-256 values on a file list. Note that you cannot directly edit a source
file within the object manager. To make changes, you must first modify your source file directly, delete the
copy on the system, then upload the modified source file.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
• Click the edit icon ( ) next to the SHA-256 value you want to change, and modify the SHA-256 or
Description values as desired.
• Click the delete icon ( ) next to the SHA-256 value you want to delete.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
Note After configuration changes are deployed, the system no longer queries the AMP cloud for files on the
list.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Step 4 Next to the source file you want to download, click the view icon ( ).
Step 5 Click Download SHA List and follow the prompts to save the source file.
Step 6 Click Close.
Note Although you can use cipher suites in the web interface in the same places as cipher suite lists, you cannot
add, modify, or delete cipher suites.
Procedure
Step 5 Choose one or more cipher suites from the Available Ciphers list.
Step 6 Click Add.
Step 7 Optionally, click the delete icon ( ) next to any cipher suites in the Selected Ciphers list that you want to
remove.
Step 8 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can define one or more asterisks (*) as wild cards in an attribute. In a common name attribute, you can
define one or more asterisks per domain name label. Wild cards match only within that label, though you can
define multiple labels with wild cards. See the following table for examples.
Procedure
Step 5 In the DN field, enter a value for the distinguished name or common name. You have the following options:
• If you add a distinguished name, you can include one of each attribute listed in Distinguished Name
Objects, on page 398 separated by commas.
• If you add a common name, you can include multiple labels and wild cards.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
PKI Objects
PKI Objects for SSL Application
PKI objects represent the public key certificates and paired private keys required to support your deployment.
Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also
contain the private key paired with the certificate. Internal and external certificate objects consist of server
certificates; internal certificate objects also contain the private key paired with the certificate.
If you use trusted certificate authority objects and internal certificate objects to configure a connection to
ISE/ISE-PIC, you can use ISE/ISE-PIC as an identity source.
If you use internal certificate objects to configure captive portal, the system can authenticate the identity of
your captive portal device when connecting to users' web browsers.
If you use trusted certificate authority objects to configure realms, you can configure secure connections to
LDAP or AD servers.
If you use PKI objects in SSL rules, you can match traffic encrypted with:
• the certificate in an external certificate object
• a certificate either signed by the CA in a trusted CA object, or within the CA’s chain of trust
You can manually input certificate and key information, upload a file containing that information, or in some
cases, generate a new CA certificate and private key.
When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject
distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject
distinguished name. To view other certificate details, edit the PKI object.
Note The Firepower Management Center and managed devices encrypt all private keys stored in internal CA
objects and internal certificate objects with a randomly generated key before saving them. If you upload
private keys that are password protected, the appliance decrypts the key using the user-supplied password,
then reencrypts it with the randomly generated key before saving it.
Note If you reference an internal CA object in a Decrypt - Resign SSL rule and the rule matches an encrypted
session, the user’s browser may warn that the certificate is not trusted while negotiating the SSL handshake.
To avoid this, add the internal CA object certificate to either the client or domain list of trusted root
certificates.
After you create an internal CA object containing a signed certificate, you can download the CA certificate
and private key. The system encrypts downloaded certificates and private keys with a user-provided password.
Whether system-generated or user-created, you can modify the internal CA object name, but cannot modify
other object properties.
You cannot delete an internal CA object that is in use. Additionally, after you edit an internal CA object used
in an SSL policy, the associated access control policy goes out-of-date. You must re-deploy the access control
policy for your changes to take effect.
If the private key file is password-protected, you can supply the decryption password. If the certificate and
key are encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.
Note If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s encryption algorithm type, in addition to any configured rule conditions. You
must upload an elliptic curve-based CA certificate to decrypt outgoing traffic encrypted with an elliptic
curve-based algorithm, for example.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate
file.
Step 6 Above the Key field, click Browse to upload a DER or PEM-encoded paired private key file.
Step 7 If the uploaded file is password-protected, check the Encrypted, and the password is: check box, and enter
the password.
Step 8 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can configure an internal CA object by providing identification information to generate a self-signed
RSA-based CA certificate and private key.
The generated CA certificate is valid for ten years. The Valid From date is a week before generation.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Procedure
You can only reference an internal CA object in an SSL rule if it contains a signed certificate.
Procedure
In a multidomain deployment, object names must be unique within the domain hierarchy. The system may
identify a conflict with the name of an object you cannot view in your current domain.
What to Do Next
• You must upload a signed certificate issued by a CA as described in Uploading a Signed Certificate
Issued in Response to a CSR, on page 404
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Once uploaded, the signed certificate can be referenced in SSL rules.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
The system encrypts the private key stored in an internal CA object with a randomly generated key before
saving it to disk. If you download a certificate and private key from an internal CA object, the system first
decrypts the information before creating a file containing the certificate and private key information. You
must then provide a password the system uses to encrypt the downloaded file.
Caution Private keys downloaded as part of a system backup are decrypted, then stored in the unencrypted backup
file.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can download CA certificates for both the current domain and ancestor domains.
Procedure
After you create the trusted CA object, you can modify the name and add certificate revocation lists (CRL),
but cannot modify other object properties. There is no limit on the number of CRLs you can add to an object.
If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.
Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration
configuration.
You cannot delete a trusted CA object that is in use. Additionally, after you edit a trusted CA object that is in
use, the associated access control policy goes out-of-date. You must re-deploy the access control policy for
your changes to take effect.
Trusted CA Object
You can configure an external CA object by uploading an X.509 v3 CA certificate. You can upload a file
encoded in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)
If the file is password-protected, you must supply the decryption password. If the certificate is encoded in the
PEM format, you can also copy and paste the information.
You can upload a CA certificate only if the file contains proper certificate information; the system validates
the certificate before saving the object.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
After you add the CRL, you can view the list of revoked certificates. If you want to modify a CRL you have
uploaded to an object, you must delete the object and recreate it.
You can upload only files that contain a proper CRL. There is no limit to the number of CRLs you can add
to a trusted CA object. However, you must save the object each time you upload a CRL, before adding another
CRL.
Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration
configuration.
In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
Note Adding a CRL to an object has no effect when the object is used in your ISE/ISE-PIC integration
configuration.
Procedure
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can upload only files that contains proper server certificate information; the system validates the file
before saving the object. If the certificate is encoded in the PEM format, you can also copy and paste the
information.
Procedure
Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate
file.
Step 6 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can configure an internal certificate object by uploading an X.509 v3 RSA-based or elliptic curve-based
server certificate and paired private key. You can upload a file in one of the following supported formats:
• Distinguished Encoding Rules (DER)
• Privacy-enhanced Electronic Mail (PEM)
If the file is password-protected, you must supply the decryption password. If the certificate and key are
encoded in the PEM format, you can also copy and paste the information.
You can upload only files that contain proper certificate or key information, and that are paired with each
other. The system validates the pair before saving the object.
After you create the internal certificate object, you can modify the name, but cannot modify other object
properties.
You cannot delete an internal certificate object that is in use. Additionally, after you edit an internal certificate
object that is in use, the associated access control policy goes out-of-date. You must re-deploy the access
control policy for your changes to take effect.
Procedure
Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate
file.
Step 6 Above the Key field, or click Browse to upload a DER or PEM-encoded paired private key file.
Step 7 If the uploaded private key file is password-protected, check the Encrypted, and the password is: check
box, and enter the password.
Step 8 Click Save.
The certificate enrollment object may also includes certificate revocation information. For more information
on PKI, digital certificates, and certificate enrollment see PKI Infrastructure and Digital Certificates , on
page 792.
• The Override column indicates whether the object allows overrides (a green check mark) or not (a red
X). If a number is displayed, it is the number of overrides in place.
Use the Override option to customize the object settings for each device that is part of the VPN
configuration. Overriding makes each device's trustpoint details unique. Typically the Common Name
or Subject is overridden for each device in the VPN configuration.
See Object Overrides, on page 350 for details and procedures on overriding objects of any type.
• Edit a previously created certificate enrollment object by clicking on the edit icon (a pencil). Editing
can only be done if the enrollment object is not associated with any managed devices. Refer to the adding
instructions for editing a certificate enrollment object.
• Delete a previously created certificate enrollment object by clicking on the delete icon (a trash can).
You cannot delete a certificate enrollment object if it is associated with any managed device.
Press (+) Add Cert Enrollment to open the Add Cert Enrollment dialog and configure a Certificate
Enrollment Object, see Adding Certificate Enrollment Objects, on page 412. Then install the certificate on
each managed, headend device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 447
Installing a Certificate Using SCEP Enrollment, on page 448
Installing a Certificate Using Manual Enrollment, on page 449
Installing a Certificate by Importing a PKCS12 File, on page 450
Procedure
Step 2 Enter the Name, and optionally, a Description of this enrollment object.
When enrollment is complete, this name is the name of the trustpoint on the managed devices with which it
is associated.
Step 3 Open the CA Information tab and choose the Enrollment Type.
• Self-Signed Certificate—The managed device, acting as a CA, generates its own self-signed root
certificate. No other information is needed in this pane.
Note When enrolling a self-signed certificate you must specify the Common Name (CN) in the
certificate parameters.
• SCEP—(Default) Simple Certificate Enrollment Protocol. Specify the SCEP information. See Certificate
Enrollment Object SCEP Options, on page 413.
• Manual—Paste an obtained CA certificate in the CA Certificate field. You can obtain a CA certificate
by copying it from another device.
• PKCS12 File—Import a PKCS12 file on a Firepower Threat Defense managed device that supports
VPN connectivity. A PKCS#12, or PFX, file holds a server certificate, intermediate certificates, and a
private key in one encrypted file.
Step 4 (Optional) Open the Certificate Parameters tab and specify the certificate contents. See Certificate Enrollment
Object Certificate Parameters, on page 414.
This information is placed in the certificate and is readable by any party who receives the certificate from the
router.
Step 5 (Optional) Open the Key tab and specify the Key information. See Certificate Enrollment Object Key Options,
on page 415.
Step 6 (Optional) Click the Revocation tab, and specify the revocation options: See Certificate Enrollment Object
Revocation Options, on page 415.
Step 7 Allow Overrides of this object if desired. See Object Overrides, on page 350 for a full description of object
overrides.
What to Do Next
Associate and install the enrollment object on a device to create a trustpoint on that device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 447
Installing a Certificate Using SCEP Enrollment, on page 448
Installing a Certificate Using Manual Enrollment, on page 449
Installing a Certificate by Importing a PKCS12 File, on page 450
Fields
Enrollment Type—set to SCEP.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll.
Use an HTTP URL in the form of http://CA_name:port, where CA_name is the host DNS name or IP address
of the CA server. The port number is mandatory.
If the CA cgi-bin script location at the CA is not the default (/cgi-bin/pkiclient.exe), you must also include
the nonstandard script location in the URL, in the form of http://CA_name:port/script_location, where
script_location is the full path to the CA scripts.
Challenge Password / Confirm Password—The password used by the CA server to validate the identity of
the device. You can obtain the password by contacting the CA server directly or by entering the following
address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll. The password is good for 60 minutes
from the time you obtain it from the CA server. Therefore, it is important that you deploy the password as
soon as possible after you create it.
Retry Period—The interval between certificate request attempts, in minutes. Value can be 1 to 60 minutes.
The default is 1 minute.
Retry Count—The number of retries that should be made if no certificate is issued upon the first request.
Value can be 1 to 100. The default is 10.
CA Certificate Source—Specify how the CA certificate will be obtained.
• Retrieve Using SCEP (Default, and only supported option)—Retrieve the certificate from the CA server
using the Simple Certificate Enrollment Process (SCEP). Using SCEP requires a connection between
your device and the CA server. Ensure there is a route from your device to the CA server before beginning
the enrollment process.
Fingerprint—When retrieving the CA certificate using SCEP, you may enter the fingerprint for the CA
server. Using the fingerprint to verify the authenticity of the CA server’s certificate helps prevent an
unauthorized party from substituting a fake certificate in place of the real one. Enter the Fingerprint for the
CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the
certificate is rejected. Obtain the CA’s fingerprint by contacting the server directly, or by entering the following
address in a web browser: http://<URLHostName>/certsrv/mscep/mscep.dll.
Fields
Enter all information using the standard LDAP X.500 format.
• Include FQDN—Whether to include the device’s fully qualified domain name (FQDN) in the certificate
request. Choices are:
◦Use Device Hostname as FQDN
◦Don't use FQDN in certificate
◦Custom FQDN—Select this and then specify it in the Custom FQDN field that displays.
• Include Device's IP Address—The interface whose IP address is included in the certificate request.
• Common Name (CN)—The X.500 common name to include in the certificate.
Note When enrolling a self-signed certificate you must specify the Common Name (CN) in
the certificate parameters.
• Organization Unit (OU)—The name of the organization unit (for example, a department name) to
include in the certificate.
• Organization (O)—The organization or company name to include in the certificate.
Fields
• Key Type—RSA (default, and only supported option) or ECDSA.
• Key Name—If the key pair you want to associate with the certificate already exists, this field specifies
the name of that key pair.If the key pair does not exist, this field specifies the name to assign to the key
pair that will be generated during enrollment. If you do not specify an RSA key pair, the fully qualified
domain name (FQDN) key pair is used instead.
• Key Size—If the key pair does not exist, defines the desired key size (modulus), in bits. The recommended
size is 1024. The larger the modulus size, the more secure the key. However, keys with larger modulus
sizes take longer to generate (a minute or more when larger than 512 bits) and longer to process when
exchanged.
Fields
• Enable Certificate Revocation Lists—Check to enable CRL checking.
◦Use CRL distribution point from the certificate—Check to obtain the revocation lists ditribution
URL from the certificate.
◦Use static URL configured—Check this to add a static, pre-defined distribution URL for revocation
lists. Then add the URLs.
CRL Server URLs—The URL of the LDAP server from which the CRL can be downloaded. This
URL must start with ldap://, and include a port number in the URL.
Procedure
Step 1 Select Objects > Object Management and choose SLA Monitor from the table of contents.
Step 2 Click Add SLA Monitor.
Step 3 Enter a name for the object in the Name field.
Step 4 (Optional) Enter a description for the object in the Descriptionfield.
Step 5 Enter the frequency of ICMP echo request transmissions, in seconds, in the Frequency field. Valid values
range from 1 to 604800 seconds (7 days). The default is 60 seconds.
Note The frequency cannot be less than the timeout value; you must convert frequency to milliseconds to
compare the values.
Step 6 Enter the ID number of the SLA operation in theSLA Monitor ID field. Values range from 1 to2147483647.
You can create a maximum of 2000 SLA operations on a device. Each ID number must be unique to the policy
and the device configuration.
Step 7 Enter the amount of time that must pass after an ICMP echo request before a rising threshold is declared, in
milliseconds, in the Threshold field . Valid values range from 0 to 2147483647 milliseconds. The default is
5000 milliseconds. The threshold value is used only to indicate events that exceed the defined value. You can
use these events to evaluate the proper timeout value. It is not a direct indicator of the reachability of the
monitored address.
Note The threshold value should not exceed the timeout
value.
Step 8 Enter the amount of time that the SLA operation waits for a response to the ICMP echo requests, in milliseconds,
in the Timeout field. Values range from 0 to 604800000 milliseconds (7 days). The default is 5000 milliseconds.
If a response is not received from the monitored address within the amount of time defined in this field, the
static route is removed from the routing table and replaced by the backup route.
Note The timeout value cannot exceed the frequency value (adjust the frequency value to milliseconds to
compare the numbers).
Step 9 Enter the size of the ICMP request packet payload, in bytes, in the Data Size field. Values range from 0 to
16384 bytes. The default is 28 bytes, which creates a total ICMP packet of 64 bytes. Do not set this value
higher than the maximum allowed by the protocol or the Path Maximum Transmission Unit (PMTU). For
purposes of reachability, you might need to increase the default data size to detect PMTU changes between
the source and the target. A low PMTU can affect session performance and, if detected, might indicate that
the secondary path should be used.
Step 10 Enter a value for type of service (ToS) defined in the IP header of the ICMP request packet in the ToS field.
Values range from 0 to 255. The default is 0. This field contains information such as delay, precedence,
reliability, and so on. It can be used by other devices on the network for policy routing and features such as
committed access rate.
Step 11 Enter the number of packets that are sent in the Number of Packets field. Values range from 1 to 100. The
default is 1 packet.
Note Increase the default number of packets if you are concerned that packet loss might falsely cause the
Firepower Threat Defense device to believe that the monitored address cannot be reached.
Step 12 Enter the IP address that is being monitored for availability by the SLA operation, in the Monitored Address
field.
Step 13 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 14 Click Save.
Prefix Lists
You can create prefix list objects for IPv4 and IPv6 to use when you are configuring route maps, policy maps,
OSPF Filtering, or BGP Neighbor Filtering.
Procedure
Step 1 Select Objects > Object Management and choose Prefix Lists > IPv6 Prefix List from the table of contents.
Step 2 Click Add Prefix List.
Step 3 Enter a name for the prefix list object in the Name field on the New Prefix List Object window.
Step 4 Click Add on theNew Prefix List Object window.
Step 5 Select the appropriate action, Allow or Block from the Action drop-down list, to indicate the redistribution
access.
Step 6 Enter a unique number that indicates the position a new prefix list entry will have in the list of prefix list
entries already configured for this object, in the Sequence No. field. If left blank, the sequence number will
default to five more than the largest sequence number currently in use.
Step 7 Specify the IPv6 address in the IP address/mask length format in the IP address field. The mask length must
be a valid value between 1-128.
Step 8 Enter the minimum prefix length in the Minimum Prefix Length field. The value must be greater than the
mask length and less than or equal to the Maximum Prefix Length, if specified.
Step 9 Enter the maximum prefix length in the Maximum Prefix Length field. The value must be greater than or
equal to the Minimum Prefix Length, if present, or greater than the mask length if the Minimum Prefix Length
is not specified.
Step 10 Click Add.
Step 11 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 12 Click Save.
Procedure
Step 1 Select Objects > Object Management and choose Prefix Lists > IPv4 Prefix List from the table of contents.
Step 2 Click Add Prefix List.
Step 3 Enter a name for the prefix list object in the Name field on the New Prefix List Object window.
Step 4 Click Add.
Step 5 Select the appropriate action, Allow or Block from the Action drop-down list, to indicate the redistribution
access.
Step 6 Enter a unique number that indicates the position a new prefix list entry will have in the list of prefix list
entries already configured for this object, in the Sequence No. field. If left blank, the sequence number will
default to five more than the largest sequence number currently in use.
Step 7 Specify the IPv4 address in the IP address/mask length format in the IP address field. The mask length must
be a valid value between 1- 32.
Step 8 Enter the minimum prefix length in the Minimum Prefix Length field. The value must be greater than the
mask length and less than or equal to the Maximum Prefix Length, if specified.
Step 9 Enter the maximum prefix length in the Maximum Prefix Length field. The value must be greater than or
equal to the Minimum Prefix Length, if present, or greater than the mask length if the Minimum Prefix Length
is not specified.
Step 10 Click Add.
Step 11 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 12 Click Save.
Route Maps
Route maps are used when redistributing routes into any routing process. They are also used when generating
a default route into a routing process. A route map defines which of the routes from the specified routing
protocol are allowed to be redistributed into the target routing process. Configure a route map, to create a new
route map entry for a Route Map object or to edit an existing one.
• Add AS Path.
• Add Community Lists.
• Add Policy Lists.
Procedure
Step 1 Select Objects > Object Management and choose Route Map from the table of contents.
Step 2 Click Add Route Map.
Step 3 Click Add on theNew Route Map Object window.
Step 4 In the Sequence No. field, enter a number, between 0 and 65535, that indicates the position a new route map
entry will have in the list of route maps entries already configured for this route map object.
Note We recommend that you number clauses in intervals of at least 10 to reserve numbering space in
case you need to insert clauses in the future.
Step 5 Select the appropriate action, Allow or Block from the Redistribution drop-down list, to indicate the
redistribution access.
Step 6 Click the Match Clauses tab to match (routes/traffic) based on the following criteria, which you select in the
table of contents:
• Security Zones — Match traffic based on the (ingress/egress) interfaces. You can select zones and add
them, or type in interface names and add them.
• IPv4 — Match IPv4 (routes/traffic) based on the following criteria; select the tab to define the criteria.
1 Click the Address tab to match routes based on the route address. For IPv4 addresses, choose whether
to use an Access list or Prefix list for matching from the drop-down list and then enter or select the
ACL objects or Prefix list objects you want to use for matching.
2 Click the Next Hop tab to match routes based on the next hop address of a route. For IPv4 addresses,
choose whether to use an access list or Prefix list for matching from the drop-down list and then
enter or select the ACL objects or Prefix list objects you want to use for matching.
3 Click the Route Source tab to match routes based on the advertising source address of the route.
For IPv4 addresses, choose whether to use an access list or Prefix list for matching from the drop-down
list and then enter or select the ACL objects or Prefix list objects you want to use for matching.
• IPv6 — Match IPv6 (routes/traffic) based on the route address, next-hop address or advertising source
address of route.
• BGP — Match BGP (routes/traffic) based on the following criteria; select the tab to define the criteria.
1 Click the AS Path tab to enable matching the BGP autonomous system path access list with the
specified path access list. If you specify more than one path access list, then the route can match
either path access list.
2 Click the Community List tab to enable matching the BGP community with the specified community.
If you specify more than one community, then the route can match either community. Any route that
does not match at least one Match community will not be advertised for outbound route maps.
3 Click the Policy List tab to configure a route map to evaluate and process a BGP policy. When
multiple policy lists perform matching within a route map entry, all policy lists match on the incoming
attribute only.
Step 7 Click the Set Clauses tab to set routes/traffic based on the following criteria, which you select in the table of
contents:
• Metric Values — Set either Bandwidth, all of the values or none of the values.
1 Enter a metric value or bandwidth in Kbits per second in the Bandwidth field. Valid values are an
integer value in the range from 0 to 4294967295.
2 Select to specify the type of metric for the destination routing protocol, from the Metric Type
drop-down list. Valid values are : internal, type-1, or type-2.
3 Enter the EIGRP route delay in tens of microseconds in the Delay field. Valid values range from
1to 4294967295.
4 Enter the likelihood of successful packet transmission for EIGRP in the Reliability field. Valid
values range from 0 to 255. The value 255 means 100 percent reliability; 0 means no reliability.
5 Enter the effective EIGRP bandwidth of a route in the Effective field. Valid values range from 1 to
255. The value 255 means 100 percent loading.
6 Enter the minimum MTU size of a route for EIGRP, in bytes in the MTU field. Valid values range
from 1 to 4294967295.
• BGP Clauses — Set BGP routes based on the following criteria; select the tab to define the criteria.
1 Click the AS Path tab to modify an autonomous system path for BGP routes.
a Enter an AS path number in the Prepend AS Path field to prepend an arbitrary autonomous
system path string to BGP routes. Usually the local AS number is prepended multiple times,
increasing the autonomous system path length. If you specify more than one AS path number
then the route can prepend either AS number.
b Enter an AS path number in the Prepend Last AS to AS Path field to prepend the AS path with
the last AS number. Enter a value for the AS number from 1 to 10.
c Check the Convert route tag into AS path check box to convert the tag of a route into an
autonomous system path.
b Click the Specific Community radio button, to enter a community number, if applicable. Valid
values are from 1 to 4294967295.
c Check the Add to existing communities check box, to add the community to the already existing
communities.
d Select the Internet, No-Advertise, or No-Export check-boxes to use one of the well-known
communities.
Access List
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
An access list object, also known as an access control list (ACL), selects the traffic to which a service will
apply. You use these objects when configuring particular features, such as route maps. Traffic identified as
allowed by the ACL is provided the service, whereas “blocked” traffic is excluded from the service. Excluding
traffic from a service does not necessarily mean that it is dropped altogether.
You can configure the following types of ACL:
• Extended—Identifies traffic based on source and destination address and ports. Supports IPv4 and IPv6
addresses, which you can mix in a given rule.
• Standard—Identifies traffic based on destination address only. Supports IPv4 only.
An ACL is composed of one or more access control entry (ACE), or rule. The order of ACEs is important.
When the ACL is evaluated to determine if a packet matches an “allowed” ACE, the packet is tested against
each ACE in the order in which the entries are listed. After a match is found, no more ACEs are checked. For
example, if you want to “allow” 10.100.10.1, but “block” the rest of 10.100.10.0/24, the allow entry must come
before the block entry. In general, place more specific rules at the top of an ACL.
Packets that do not match an “allow” entry are considered to be blocked.
The following topics explain how to configure ACL objects.
Procedure
Step 1 Select Objects > Object Management and choose Access Control Lists > Extended from the table of
contents.
Step 2 Do one of the following:
• Click Add Extended ACL to create a new object.
• Click the edit icon ( ) to edit an existing object.
Step 3 In the Extended ACL Object dialog box, enter a name for the object (no spaces allowed), and configure the
access control entries:
a) Do one of the following:
• Click Add to create a new entry.
• Click the edit icon ( ) to edit an existing entry.
The right-click menu also includes options to cut, copy, and paste entries, or to delete them.
b) Select the Action, whether to Allow (match) or Block (not match) the traffic criteria.
Note The Logging, Log Level, and Log Interval options are used for access rules only (ACLs attached
to interfaces or applied globally). Because ACL objects are not used for access rules, leave these
values at their defaults.
c) Configure the source and destination addresses on the Network tab using any of the following techniques:
• Select the desired network objects or groups from the Available list and click Add to Source or Add
to Destination. You can create new objects by clicking the + button above the list. You can mix
IPv4 and IPv6 addresses.
• Type an address in the edit box below the source or destination list and click Add. You can specify
a single host address (such as 10.100.10.5 or 2001:DB8::0DB8:800:200C:417A), or a subnet (in
10.100.10.0/24 or 10.100.10.0 255.255.255.0 format, or for IPv6, 2001:DB8:0:CD30::/60).
d) Click the Port tab and configure the service using any of the following techniques.
• Select the desired port objects or groups from the Available list and click Add to Source or Add to
Destination. You can create new objects by clicking the + button above the list. The object can
specify TCP/UDP ports, ICMP/ICMPv6 message types, or other protocols (including “any”). However,
the source port, which you typically would leave empty, accepts TCP/UDP only.
• Type or select a port or protocol in the edit box below the source or destination list and click Add.
Note To get an entry that applies to all IP traffic, select a destination port object that specifies “all”
protocols.
e) Click Add to add the entry to the object.
f) If necessary, click and drag the entry to move it up or down in the rule order to the desired location.
Repeat the process to create or edit additional entries in the object.
Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 5 Click Save.
Procedure
Step 1 Select Objects > Object Management and choose Access Control Lists > Standard from the table of
contents.
Step 2 Do one of the following:
• Click Add Standard ACL to create a new object.
• Click the edit icon ( ) to edit an existing object.
Step 3 In the Standard ACL Object dialog box, enter a name for the object (no spaces allowed), and configure the
access control entries:
a) Do one of the following:
• Click Add to create a new entry.
The right-click menu also includes options to cut, copy, and paste entries, or to delete them.
b) For each access control entry, configure the following properties:
• Action—Whether to Allow (match) or Block (not match) the traffic criteria.
• Network—Add the IPv4 network objects or groups that identify the destination of the traffic.
Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 5 Click Save.
AS Path Objects
An AS Path is a mandatory attribute to set up BGP. It is a sequence of AS numbers through which a network
can be accessed. An AS-PATH is a sequence of intermediate AS numbers between source and destination
routers that form a directed route for packets to travel. Neighboring autonomous systems (ASes ) use BGP to
exchange and update messages about how to reach different AS prefixes. After each router makes a new local
decision on the best route to a destination, it will send that route, or path information, along with the
accompanying distance metrics and path attributes, to each of its peers. As this information travels through
the network, each router along the path prepends its unique AS number to a list of ASes in the BGP message.
This list is the route's AS-PATH. An AS-PATH along with an AS prefix, provides a specific handle for a
one-way transit route through the network. Use the Configure AS Path page to create, copy and edit autonomous
system (AS) path policy objects. You can create AS path objects to use when you are configuring route maps,
policy maps, or BGP Neighbor Filtering. An AS path filter allows you to filter the routing update message
by using regular expressions.
Procedure
Step 1 Select Objects > Object Management and choose AS Path from the table of contents.
Step 2 Click Add AS Path.
Step 3 Enter a name for the AS Path object in the Name field. Valid values are between 1 and 500.
Step 4 Click Add on the New AS Path Object window.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) Specify the regular expression that defines the AS path filter in the Regular Expression field.
c) Click Add.
Step 5 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 6 Click Save.
Community Lists
A Community is an optional transitive BGP attribute. A community is a group of destinations that share some
common attribute. It is used for route tagging. The BGP community attribute is a numerical value that can be
assigned to a specific prefix and advertised to other neighbors. Communities can be used to mark a set of
prefixes that share a common attribute. Upstream providers can use these markers to apply a common routing
policy such as filtering or assigning a specific local preference or modifying other attributes. Use the Configure
Community Lists page to create, copy and edit community list policy objects. You can create community list
objects to use when you are configuring route maps or policy maps. You can use community lists to create
groups of communities to use in a match clause of a route map. The community list is an ordered list of
matching statements. Destinations are matched against the rules until a match is found.
Procedure
Step 1 Select Objects > Object Management and choose Community List from the table of contents.
Step 2 Click Add Community List.
Step 3 In the Name field, specify a name for the community list object.
Step 4 Click Add on the New Community List Object window.
Step 5 Select the Standard radio button to indicate the community rule type.
Standard community lists are used to specify well-known communities and community numbers.
Note You cannot have entries using Standard and entries using Expanded community rule types in the
same Community List object.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) In the Communities field, specify a community number. Valid values can be from 1 to 4294967295 or
from 0:1 to 65534:65535.
c) Select the appropriate Route Type.
• Internet — Select to specify the Internet well-known community. Routes with this community are
advertised to all peers (internal and external).
• No Advertise — Select to specify the no-advertise well-known community. Routes with this
community are not advertised to any peer (internal or external).
• No Export — Select to specify the no-export well-known community. Routes with this community
are advertised to only peers in the same autonomous system or to only other sub-autonomous systems
within a confederation. These routes are not advertised to external peers.
Step 6 Select the Expanded radio button to indicate the community rule type.
Expanded community lists are used to filter communities using a regular expression. Regular expressions are
used to specify patterns to match COMMUNITIES attributes.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) Specify the regular expression in the Expressions field.
Step 7 Click Add.
Step 8 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 9 Click Save.
Policy Lists
Use the Configure Policy List page to create, copy, and edit policy list policy objects. You can create policy
list objects to use when you are configuring route maps. When a policy list is referenced within a route map,
all of the match statements within the policy list are evaluated and processed. Two or more policy lists can
be configured with a route map. A policy list can also coexist with any other preexisting match and set
statements that are configured within the same route map but outside of the policy list. When multiple policy
lists perform matching within a route map entry, all policy lists match on the incoming attribute only.
Procedure
Step 1 Select Objects > Object Management and choose Policy List from the table of contents.
Step 2 Click Add Policy List.
Step 3 Enter a name for the policy list object in the Name field. Object names are not case-sensitive.
Step 4 Select whether to allow or block access for matching conditions from the Action drop-down list.
Step 5 Click the Interface tab to distribute routes that have their next hop out of one of the interfaces specified.
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 6 Click the Address tab to redistribute any routes that have a destination address that is permitted by a standard
access list or prefix list.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access
List Objects or Prefix list objects you want to use for matching.
Step 7 Click the Next Hop tab to redistribute any routes that have a next hop router address passed by one of the
access lists or prefix lists specified.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access
List Objects or Prefix list objects you want to use for matching.
Step 8 Click the Route Source tab to redistribute routes that have been advertised by routers and access servers at
the address specified by the access lists or prefix list.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access
List Objects or Prefix list objects you want to use for matching.
Step 9 Click the AS Path tab to match a BGP autonomous system path. If you specify more than one AS path, then
the route can match either AS path.
Step 10 Click the Community Rule tab to enable matching the BGP community with the specified community. If
you specify more than one community, then the route can match either community. To enable matching the
BGP community exactly with the specified community, check the Match the specified community exactly
check box.
Step 11 Click the Metric & tag tab to match the metric and security group tag of a route.
a) Enter the metric values to use for matching in the Metric field. You can enter multiple values separated
by commas. This setting allows you to match any routes that have a specified metric. The metric values
can range from 0 to 4294967295.
b) Enter the tag values to use for matching in the Tag field. You can enter multiple values separated by
commas. This setting allows you to match any routes that have a specified security group tag. The tag
values can range from 0 to 4294967295.
Step 12 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 352.
Step 13 Click Save.
VPN Objects
IKEv2 proposal, you can select multiple algorithms and modulus groups in one policy. Since peers choose
during the Phase 1 negotiation, this makes it possible to create a single IKE proposal, but consider multiple,
different proposals to give higher priority to your most desired options. For IKEv2, the policy object does not
specify authentication, other policies must define the authentication requirements.
An IKE policy is required when you configure a site-to-site IPsec VPN. For more information, see Firepower
Threat Defense VPN, on page 783.
Use the IKEv1 Policy page to create, delete, or edit an IKEv1 policy object. These policy objects contain the
parameters required for IKEv1 policies.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IKEv1 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access,
you may Edit ( ), View ( ), or Delete ( ) a proposal.
Step 2 (Optional) Choose Add IKEv1 Policy to create a new policy object.
Step 3 Enter a Name for this policy. A maximum of 128 characters is allowed.
Step 4 (Optional) Enter a Description for this proposal. A maximum of 1,024 characters is allowed.
Step 5 Enter the Priority value of the IKE policy.
The priority value determines the order of the IKE policy compared by the two negotiating peers when
attempting to find a common security association (SA). If the remote IPsec peer does not support the parameters
selected in your first priority policy, it tries to use the parameters defined in the next lowest priority. Valid
values range from 1 to 65,535. The lower the number, the higher the priority. If you leave this field blank,
Management Center assigns the lowest unassigned value starting with 1, then 5, then continuing in increments
of 5.
Step 7 Choose the Hash Algorithm that creates a Message Digest, which is used to ensure message integrity.
When deciding which encryption and Hash Algorithms to use for the IKEv1 proposal, your choice is limited
to algorithms supported by the managed devices. For an extranet device in the VPN topology, you must choose
the algorithm that matches both peers. For a full explanation of the options, see Deciding Which Hash
Algorithms to Use, on page 790.
The Diffie-Hellman group to use for encryption. A larger modulus provides higher security but requires more
processing time. The two peers must have a matching modulus group. Select the group that you want to allow
in the VPN.For a full explanation of the options, see Deciding Which Diffie-Hellman Modulus Group to
Use, on page 790.
Step 9 Set the Lifetimeof the security association (SA), in seconds. You can specify a value from 120 to 2,147,483,647
seconds. The default is 86400.
When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. Generally,
the shorter the lifetime (up to a point), the more secure your IKE negotiations. However, with longer lifetimes,
future IPsec security associations can be set up more quickly than with shorter lifetimes.
Step 10 Set the Authentication Method to use between the two peers.
• Preshared Key—Preshared keys allow for a secret key to be shared between two peers and to be used
by IKE during the authentication phase. If one of the participating peers is not configured with the same
preshared key, the IKE SA cannot be established.
• Certificate—When you use Certificates as the authentication method for VPN connections, peers obtain
digital certificates from a CA server in your PKI infrastructure, and trade them to authenticate each
other.
Note In a VPN topology that supports IKEv1, the Authentication Method specified in the chosen IKEv1
Policy object becomes the default in the IKEv1 Authentication Type setting. These values must
match, otherwise, your configuration will error.
Step 11 Click Save
The new IKEv1 policy is added to the list.
Use the IKEv2 policy dialog box to create, delete, and edit an IKEv2 policy object. These policy objects
contain the parameters required for IKEv2 policies.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IKEv2 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access,
you may Edit ( ), View ( ), or Delete ( ) a policy.
Step 6 Set the Lifetimeof the security association (SA), in seconds. You can specify a value from 120 to 2,147,483,647
seconds. The default is 86400.
When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. Generally,
the shorter the lifetime (up to a point), the more secure your IKE negotiations. However, with longer lifetimes,
future IPsec security associations can be set up more quickly than with shorter lifetimes.
Step 7 Choose the Integrity Algorithms portion of the Hash Algorithm used in the IKE policy. The Hash Algorithm
creates a Message Digest, which is used to ensure message integrity.
When deciding which encryption and Hash Algorithms to use for the IKEv2 proposal, your choice is limited
to algorithms supported by the managed devices. For an extranet device in the VPN topology, you must choose
the algorithm that matches both peers. Select all the algorithms that you want to allow in the VPN.For a full
explanation of the options, see Deciding Which Hash Algorithms to Use, on page 790.
Step 8 Choose the Encryption Algorithm used to establish the Phase 1 SA for protecting Phase 2 negotiations.
When deciding which encryption and Hash Algorithms to use for the IKEv2 proposal, your choice is limited
to algorithms supported by the managed devices. For an extranet device in the VPN topology, you must choose
the algorithm that matches both peers. Select all the algorithms that you want to allow in the VPN. For a full
explanation of the options, see Deciding Which Encryption Algorithm to Use, on page 789.
There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:
• When you create an IKEv1 IPsec Proposal (Transform Set) object, you select the mode in which IPsec
operates, and define the required encryption and authentication types. You can select single options for
the algorithms. If you want to support multiple combinations in a VPN, create multiple IKEv1 IPsec
Proposal objects.
• When you create an IKEv2 IPsec Proposal object, you can select all of the encryption and Hash Algorithms
allowed in a VPN. During IKEv2 negotiations, the peers select the most appropriate options that each
support.
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec Proposals. It provides
authentication, encryption, and antireplay services. ESP is IP protocol type 50.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IPsec IKev1 Proposal from the table of contents.
Previously configured Proposals are listed including system defined defaults. Depending on your level of
access, you may Edit ( ), View ( ), or Delete ( ) a Proposal.
Step 5 Choose the ESP Encryption method. The Encapsulating Security Protocol (ESP) encryption algorithm for
this Proposal.
For IKEv1, select one of the options. When deciding which encryption and Hash Algorithms to use for the
IPsec proposal, your choice is limited to algorithms supported by the devices in the VPN. For a full explanation
of the options, see Deciding Which Encryption Algorithm to Use, on page 789.
Procedure
Step 1 Choose Objects > Object Management and then VPN > IKEv2 IPsec Proposal from the table of contents.
Previously configured Proposals are listed including system defined defaults. Depending on your level of
access, you may Edit ( ), View ( ), or Delete ( ) a Proposal.
Step 5 Choose the ESP Hash method, the hash or integrity algorithm to use in the Proposal for authentication.
For IKEv2, select all the options you want to support for ESP Hash. For a full explanation of the options,
see Deciding Which Hash Algorithms to Use, on page 790.
Step 6 Choose the ESP Encryption method. The Encapsulating Security Protocol (ESP) encryption algorithm for
this Proposal.
For IKEv2, click Select to open a dialog box where you can select all of the options you want to support.
When deciding which encryption and Hash Algorithms to use for the IPsec proposal, your choice is limited
to algorithms supported by the devices in the VPN. For a full explanation of the options, see Deciding Which
Encryption Algorithm to Use, on page 789.
Note There is no group policy attribute inheritance on the Firepower Threat Defense. A group policy object is
used, in its entirety, for a user. The group policy object identified by the AAA server upon login is used,
or, if that is not specified, the default group policy configured for the VPN connection is used. The provided
default group policy can be set to your default values, but will only be used if it is assigned to a connection
profile and no other group policy has been identified for the user.
Related Topics
Configure Group Policy Objects, on page 434
Procedure
Step 1 Choose Objects > Object Management > VPN > Group Policy.
Previously configured policies are listed including the system default. Depending on your level of access, you
may edit, view, or delete a group policy.
Step 4 Specify the General parameters for this Group Policy as described in Group Policy General Options, on page
435.
Step 5 Specify the AnyConnect parameters for this Group Policy as described in Group Policy AnyConnect Options,
on page 436.
Step 6 Specify the Advanced parameters for this Group Policy as described in Group Policy Advanced Options, on
page 438.
Step 7 Click Save.
The new Group Policy is added to the list.
What to Do Next
Add the group policy object to a remote access VPN connection profile.
Related Topics
Adding and Editing Firepower Threat Defense Remote Access VPN Connection Profile, on page 818
Navigation Path
Objects > Object Management > VPN > Group Policy, click Click Add Group Policy or choose a current
policy to edit., then select the General tab.
Banner Fields
Specifies the banner text to present to users at login. The length can be up to 491 characters. There is no default
value. The IPsec VPN client supports full HTML for the banner, however, the AnyConnect client supports
only partial HTML. To ensure that the banner displays properly to remote users, use the /n tag for IPsec clients,
and the <BR> tag for SSL clients.
DNS/WINS Fields
Domain Naming System (DNS) and Windows Internet Naming System (WINS) servers. Used for AnyConnect
client name resolution.
• Primary DNS Server and Secondary DNS Server—Choose or create a Network Object which defines
the IPv4 or IPv6 addresses of the DNS servers you want this group to use.
• Primary WINS Server and Secondary WINS Server—Choose or create a Network Object containing
the IP addresses of the WINS servers you want this group to use.
• DHCP Network Scope—Choose or create a Network Object containing the IPv4 address of the DHCP
Network for this group. This setting does not support IPv6, address ranges, or subnet specifications. If
not set properly, deployment of the VPN policy fails.
• Default Domain—Name of the default domain. Specify a top-level domain, for example, example.com.
Related Topics
Configure Group Policy Objects, on page 434
Navigation
Objects > Object Management > VPN > Group Policy. Click Add Group Policy or choose a current policy
to edit. Then select the AnyConnect tab.
Profile Fields
Profile—Choose or create a file object containing an AnyConnect Client Profile. See Firepower Threat
Defense File Objects, on page 439 for object creation details.
An AnyConnect Client Profile is a group of configuration parameters stored in an XML file. The AnyConnect
software client uses it to configure the connection entries that appear in the client's user interface. These
parameters (XML tags) also configure settings to enable more AnyConnect features.
Use the GUI-based AnyConnect Profile Editor, an independent configuration tool, to create an AnyConnect
Client Profile. See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect
Secure Mobility Client Administrator Guide for details.
◦Interval—Available when SSL rekey is enabled. Set to a default of 4 minutes with a range of
4-10080 minutes (1 week).
• Client Firewall Rules—Use the Client Firewall Rules to configure firewall settings for the VPN client's
platform. Rules are based on criteria such as source address, destination address, and protocol. Extended
Access Control List building block objects are used to define the traffic filter criteria. Choose or create
an Extended ACL for this group policy. Define a Private Network Rule to control data flowing to the
private network, a Public Network Rule to control data flowing "in the clear", outside of the established
VPN tunnel, or both.
Note Ensure that the ACL contains only TCP/UDP/ICMP/IP ports and source network as
any, any-ipv4 or any-ipv6.
Only VPN clients running Microsoft Windows can use these firewall settings.
Related Topics
Configure Group Policy Objects, on page 434
Navigation Path
Objects > Object Management > VPN > Group Policy, click Click Add Group Policy or choose a current
policy to edit., then select the Advanced tab.
• Maximum Connection Time / Alert Interval—Specifies the maximum user connection time in minutes.
At the end of this time, the system stops the connection. The minimum is 1 minute). The Alert interval
specifies the interval of time before maximum connection time is reached to display a message to the
user.
• Idle Timeout / Alert Interval—Specifies this user’s idle timeout period in minutes. If there is no
communication activity on the user connection in this period, the system stops the connection. The
minimum time is 1 minute. The default is 30 minutes. The Alert interval specifies the interval of time
before idle time is reached to display a message to the user.
Related Topics
Configure Group Policy Objects, on page 434
Navigation Path
Objects > Object Management > VPN > AnyConnect File.
Fields
• Name and Description—Enter the name, up to 128 characters, and an optional description to identify
this file object.
• File Name and File Type—The name and full path of the file, and its type. Click Browse to select the
file, and choose the corresponding type.
Only the AnyConnect Client Image and AnyConnect Client Profile types are valid, and they must
be located on the Firepower Management Center platform to include them in a file object.
Related Topics
About Firepower Threat Defense Cisco AnyConnect Secure Mobility Client Image, on page 829
Group Policy AnyConnect Options, on page 436
Navigation
Objects > Object Management > VPN > Certificate Map
Fields
• Name—Identify this object so it can be referred to from other configurations, such as Remote Access
VPN.
• Mapping Criteria—Specify the contents of the certificate to evaluate. If the certificate satisifies these
rules, the user will be mapped to the connection profile containing this object.
◦Component—Select the component of the client certificate to use for the matching rule.
◦Field—Select the field for the matching rule according to the Subject or the Issuer of the client
certificate.
If the Field is set to Alternative Subject or Extended Key Usage the Component will be frozen as
Whole Field
◦Operator—Select the operator for the matching rule as follows:
◦Equals—The certificate component must match the entered value. If they do not match
exactly, the connection is denied.
◦Contains—The certificate component must contain the entered value. If the component does
not contain the value, the connection is denied.
◦Does Not Equal—The certificate component cannot equal the entered value. For example,
for a selected certificate component of Country, and an entered value of US, if the client
county value equals US, then the connection is denied.
◦Does Not Contain—The certificate component cannot contain the entered value. For example,
for a selected certificate component of Country, and an entered value of US, if the client
county value contains US, the connection is denied.
• Value—The value of the matching rule. The value entered is associated with the selected component
and operator.
Related Topics
Configuring Certificate Maps, on page 832
Address Pools
You can configure IP address pools for both IPv4 and IPv6 that can be used for the Diagnostic interface with
clustering, or for VPN remote access profiles.
Procedure
Step 1 Select Objects > Object Management > Address Pools > IPv4 Pools.
Step 2 Click Add IPv4 Pools, and configure the following fields:
• Name—Enter the name of the address pool. It can be up to 64 characters
• Description—Add an optional description for this pool.
• IP Address—Enter a range of addresses available in the pool. Use dotted decimal notation and a dash
between the beginning and the end address, for example: 10.10.147.100-10.10.147.177.
• Mask—Identifies the subnet on which this IP address pool resides.
• Allow Overrides—Check this check box to enable object overrides. Click the expand arrow to show
the Overrides table. You can add a new override by clicking Add. See Object Overrides, on page 350
for more information.
FlexConfig Objects
Use FlexConfig policy objects in FlexConfig policies to provide customized configuration of features on
Firepower Threat Defense devices that you cannot otherwise configure using Firepower Management Center.
For more information on FlexConfig policies, see FlexConfig Policy Overview, on page 621.
You can configure the following types of objects for FlexConfig.
Text Objects
Text objects define free-form text strings that you use as variables in a FlexConfig object. These objects
can have single values or be a list of multiple values.
There are several predefined text objects that are used in the predefined FlexConfig objects. If you use
the associated FlexConfig object, you simply need to edit the contents of the text object to customize
how the FlexConfig object configures a given device. When editing a predefined object, it is in general
a better option to create device overrides for each device you are configuring, rather than directly change
the default values of these objects. This helps avoid unintended consequences if another user wants to
use the same FlexConfig object for a different set of devices.
For information on configuring text objects, see Configure FlexConfig Text Objects, on page 647.
FlexConfig Objects
FlexConfig Objects include device configuration commands, variables, and scripting language
instructions. During configuration deployment, these instructions are processed to create a sequence
of configuration commands with customized parameters to configure specific features on the target
devices.
These instructions are either configured before (prepended) the system configures features defined in
regular Firepower Management Center policies and settings, or after (appended). Any FlexConfig that
depends on Firepower Management Center-configured objects (for example, a network object) must
be appended to the configuration deployment, or the needed objects would not be configured before
the FlexConfig needed to refer to the objects.
For more information on configuring FlexConfig objects, see Configure FlexConfig Objects, on page
642.
Procedure
Step 1 Select Objects > Object Management > RADIUS Server Group.
All currently configured RADIUS Server Group objects will be listed. Use the filter to narrow down the list.
Step 2 Choose and edit a listed RADIUS Server Group object, or add a new one.
See RADIUS Server Options, on page 444 and RADIUS Server Group Options, on page 443 to configure this
object.
Navigation Path
Objects > Object Management > RADIUS Server Group. Choose and edit a configured RADIUS Server
Group object or add a new one.
Fields
• Name and Description—Enter a name and optionally, a description to identify this RADIUS Server
Group object.
• Enable authorize only—If this RADIUS server group is not being used for authentication, but is being
used for authorization or accounting, check this field to enable authorize-only mode for the RADIUS
server group.
Authorize only mode eliminates the need of including the RADIUS server password in the
Access-Request. Thus, the password, configured for the individual RADIUS servers, is ignored.
• Enable interim account update and Interval—Enables the generation of RADIUS
interim-accounting-update messages in order to inform the RADIUS server of newly assigned IP
addresses. Set the length, in hours, of the interval between periodic accounting updates in the Interval
field. The valid range is 1 to 120 and the default value is 24.
• Group Accounting Mode—The method for sending accounting messages to the RADIUS servers in
the group. Choose Single, accounting messages are sent to a single server in the group, this is the default.
Or, Simultaneous, accounting messages are sent to all servers in the group simultaneously.
• Retry Interval—The interval between attempts to contact the RADIUS servers. Values range from 1
to 10 seconds.
• Realms(Optional)—Specify or select the AD or LDAP realm this RADIUS server group is associated
with. This realm is then selected in identity policies to access the associated RADIUS server group when
determining the VPN authentication identity source for a traffic flow. This realm effectively provides a
bridge from the identity policy to this Radius server group. If no realm is associated with this RADIUS
server group, the RADIUS server group cannot be reached to determine the VPN authentication identity
source for a traffic flow in an identity policy.
• RADIUS Servers—See RADIUS Server Options, on page 444
Related Topics
RADIUS Server Groups, on page 442
Navigation Path
Objects > Object Management > RADIUS Server Group. Choose and edit a listed RADIUS Server Group
object or add a new one. Then, in the RADIUS Server Group dialog, choose and edit a listed RADIUS Server
or add a new one.
Fields
• Name and Description—Enter a name, up to 128 characters, and optionally, a description to identify
this RADIUS Server object.
• Hostname/IP Address—The network object that identifies the hostname or IP address of the RADIUS
server to which authentication requests will be sent. You may only select one, to add additional servers,
add additional RADIUS Server to the RADIUS Server Group list.
• Authentication Port—The port on which RADIUS authentication and authorization are performed.
The default is 1812.
• Key and Confirm Key— The shared secret that is used to encrypt data between the managed device
(client) and the RADIUS server.
The key is a case-sensitive, alphanumeric string of up to 127 characters. Special characters are permitted.
The key you define in this field must match the key on the RADIUS server. Enter the key again in the
Confirm field.
• Accounting Port—The port on which RADIUS accounting is performed. The default is 1813.
Related Topics
RADIUS Server Groups, on page 442
RADIUS Server Group Options, on page 443
• When enrollment is done from the parent domain, the certificate enrollment object also needs to be in
that domain. If the trustpoint on the device is overridden in the child domain, the overridden value will
be deployed on the device.
• When certificate enrollment is done on a device in a leaf domain, the enrollment will not be visible to
the parent domain or another child domain.
• When a leaf domain is deleted, certificate enrollments on contained devices have to be removed.
• Once a device has certificates enrolled in one domain, it will not be allowed to be enrolled in any other
domain. However, the certificates can be viewed in the the other domain. .
• When a device is moved from one domain to another domain, or from no domain into a domain, certificate
enrollments on that device have to be removed and reconfigured in the new domain. You will receive
an alert to delete the enrollments on these devices.
See PKI Infrastructure and Digital Certificates , on page 792 for an introduction to Digital Certificates.
See Certificate Enrollment Objects, on page 410 for a description of the objects used to enroll and obtain
certificates on managed devices.
Procedure
Step 2 Choose (+) Add > Add New Certificate to associate and install an enrollment object on a device. Continue
based on the type of enrollment.
Note When a certificate enrollment object is associated with and then installed on a device, the process of
certificate enrollment starts immediately. The process is automatic for self-signed and SCEP enrollment
types, meaning it does not require any additional administrator action. Manual certificate enrollment
and importing a PKCS12 file requires extra administrator action.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 447
Installing a Certificate Using SCEP Enrollment, on page 448
Installing a Certificate Using Manual Enrollment, on page 449
Installing a Certificate by Importing a PKCS12 File, on page 450
Procedure
Step 1 On the Devices > Certificates screen, choose Add > Add New Certificate to open the Add New Certificate
dialog.
Step 2 Choose a device from the Device drop down list.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the appropriate type from the drop-down list.
• Click (+), to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects, on
page 412.
Step 4 Press Install, to start the Self Signed, automatic, enrollment process.
For self signed enrollment type trustpoints, the CA Certificate status will always be NotApplicable since
the managed device is acting as its own CA and does not need a CA certificate to generate its own Identity
Certificate.
The Identity Certificate will go from InProgress to Available as the device creates its own self signed identity
certificate.
Step 5 Click the magnifying glass to view the self-signed Identity Certificate created for this device.
What to Do Next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your VPN Authentication Method.
Note Using SCEP enrollment establishes a direct connection between the managed device and the CA server.
So be sure your device is connected to the CA server before beginning the enrollment process.
Procedure
Step 1 On the Devices > Certificates screen, choose Add > Add New Certificate to open the Add New Certificate
dialog.
Step 2 Choose a device from the Device drop down list.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the appropriate type from the drop-down list.
• Click (+), to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects, on
page 412.
Step 5 Click the magnifying glass to view the Identity Certificate created and installed on this device.
What to Do Next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your VPN Authentication Method.
Procedure
Step 1 On the Devices > Certificates screen, choose Add > Add New Certificate to open the Add New Certificate
dialog.
Step 2 Choose a device from the Device drop down list.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the appropriate type from the drop-down list.
• Click (+), to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects, on
page 412.
Step 7 Click the magnifying glass to view the Identity Certificate for this device.
What to Do Next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your VPN Authentication Method.
Procedure
Step 1 Go to Devices > Certificates, then click + Add > Import PKCS12 File to open the Import PKCS12 File
dialog.
Step 2 Choose a pre-configured managed device from the Device drop down list.
Step 3 Specify a Certificate Enrollment type of PKCS12.
Step 4 Select Browse to find and choose your PKCS#12 Certificate file.
Step 5 Enter the Passphrase for decryption.
Step 6 Press Add
For file import, the CA Certificate and Identity Certificate status will go from InProgress to Available
as it installs the PKCS12 file on the device.
Step 7 Once Available, click the magnifying glass to view the Identity Certificate for this device.
What to Do Next
The certificate (trustpoint) on the managed device is named the same as the PKCS#12 file. Use this certificate
in your VPN authentication configuration.
Device Management
The Firepower Management Center is a key component in the Firepower System. You can use the Firepower
Management Center to manage the full range of devices that comprise the Firepower System, and to aggregate,
analyze, and respond to the threats they detect on your network.
By using the Firepower Management Center to manage devices, you can:
• configure policies for all your devices from a single location, making it easier to change configurations
• install various types of software updates on devices
• push health policies to your managed devices and monitor their health status from the Firepower
Management Center
The Firepower Management Center aggregates and correlates intrusion events, network discovery information,
and device performance data, allowing you to monitor the information that your devices are reporting in
relation to one another, and to assess the overall activity occurring on your network.
You can use a Firepower Management Center to manage nearly every aspect of a device’s behavior.
Note Although a Firepower Management Center can manage devices running certain previous releases as
specified in the compatibility matrix available at http://www.cisco.com/c/en/us/support/security/
defense-center/products-device-support-tables-list.html, new features are not available to these
previous-release devices.
When you manage a device, information is transmitted between the Firepower Management Center and the
device over a secure, SSL-encrypted TCP tunnel.
The following illustration lists what is transmitted between a Firepower Management Center and its managed
devices. Note that the types of events and policies that are sent between the appliances are based on the device
type.
Backing Up a Device
You cannot create or restore backup files for NGIPSv devices or ASA FirePOWER modules.
When you perform a backup of a physical managed device from the device itself, you back up the device
configuration only. To back up configuration data and, optionally, unified files, perform a backup of the
device using the managing Firepower Management Center.
To back up event data, perform a backup of the managing Firepower Management Center.
Updating Devices
From time to time, Cisco releases updates to the Firepower System, including:
• intrusion rule updates, which may contain new and updated intrusion rules
• vulnerability database updates
• geolocation updates
• software patches and updates
You can use the Firepower Management Center to install an update on the devices it manages.
Related Topics
Backup Files, on page 162
NAT Environments
Network address translation (NAT) is a method of transmitting and receiving network traffic through a router
that involves reassigning the source or destination IP address. The most common use for NAT is to allow
private networks to communicate with the internet. Static NAT performs a 1:1 translation, which does not
pose a problem for Firepower Management Center communication with devices, but port address translation
(PAT) is more common. PAT lets you use a single public IP address and unique ports to access the public
network; these ports are dynamically assigned as needed, so you cannot initiate a connection to a device behind
a PAT router.
Normally, you need both IP addresses (along with a registration key) for both routing purposes and for
authentication: the Firepower Management Center specifies the device IP address, and the device specifies
the Firepower Management Center IP address. However, if you only know one of the IP addresses, which is
the minimum requirement for routing purposes, then you must also specify a unique NAT ID on both sides
of the connection to establish trust for the initial communication and to look up the correct registration key.
The Firepower Management Center and device use the registration key and NAT ID (instead of IP addresses)
to authenticate and authorize for initial registration.
For example, you add a device to the Firepower Management Center, and you do not know the device IP
address (for example, the device is behind a PAT router), so you specify only the NAT ID and the registration
key. On the device, you specify the Firepower Management Center IP address, the same NAT ID, and the
same registration key. The device registers to the Firepower Management Center's IP address. At this point,
the Firepower Management Center uses the NAT ID instead of IP address to authenticate the device.
Although the use of a NAT ID is most common for NAT environments, you might choose to use the NAT
ID to simplify adding many devices to the Firepower Management Center. On the Firepower Management
Center, specify a unique NAT ID for each device you want to add, and then on each device, specify both the
Firepower Management Center IP address and the NAT ID. Note: The NAT ID must be unique per device.
Event data streams from managed devices to both Firepower Management Centers in the high availability
pair. If one Firepower Management Center fails, you can monitor your network without interruption using
the other Firepower Management Center.
Note that Firepower Management Centers configured as a high availability pair do not need to be on the same
trusted management network, nor do they have to be in the same geographic location.
Caution Because the system restricts some functionality to the active Firepower Management Center, if that
appliance fails, you must promote the standby Firepower Management Center to active.
Hardware Requirements
The two Firepower Management Centers in a high availability configuration must be the same model.
Software Requirements
The two Firepower Management Centers in a high availability configuration must have the same major (first
number), minor (second number), and maintenance (third number) software version.
License Requirements
A device managed with Firepower Management Centers in a high availability configuration requires the same
number of feature licenses and related subscriptions as a device managed by a single Firepower Management
Center.
For example, if you want to enable advanced malware protection for two devices managed by a Firepower
Management Center pair, buy two Malware licenses and two TAM subscriptions, add those licenses to the
Firepower Management Center, then assign the licenses to the two devices on the active Firepower Management
Center. The system automatically replicates all feature licenses from active to standby Firepower Management
Center, so the licenses are available on failover.
Or, if you want to enable advanced malware protection for two Firepower Threat Defense devices managed
by a Firepower Management Center pair, buy two Malware licenses and two TM subscriptions, register the
active Firepower Management Center with the Cisco Smart Software Manager, then assign the licenses to the
two Firepower Threat Defense devices on the active Firepower Management Center. When failover occurs,
the system communicates with the Smart Software Manager to release the Smart License entitlements from
the active Firepower Management Center and assign them to the standby Firepower Management Center.
Primary/Secondary Roles
When setting up Firepower Management Centers in a high availability pair, you configure one Firepower
Management Center to be primary and the other as secondary. During configuration, the primary unit's policies
are synchronized to the secondary unit. After this synchronization, the primary Firepower Management Center
becomes the active peer, while the secondary Firepower Management Center becomes the standby peer, and
the two units act as a single appliance for managed device and policy configuration.
Active/Standby Status
The main differences between the two Firepower Management Centers in a high availability pair are related
to which peer is active and which peer is standby. The active Firepower Management Center remains fully
functional, where you can manage devices and policies. On the standby Firepower Management Center,
functionality is hidden; you cannot make any configuration changes.
Note Whichever appliance you use as the secondary loses all of its device registrations and policy configurations
when you resolve split-brain. For example, you would lose modifications to any policies that existed on
the secondary but not on the primary. If the Firepower Management Center is in a high availability
split-brain scenario where both appliances are active, and you register managed devices and deploy policies
before you resolve split-brain, you must export any policies and unregister any managed devices from the
intended standby Firepower Management Center before re-establishing high availability. You may then
register the managed devices and import the policies to the intended active Firepower Management Center.
Warning Make sure that there is at least one operational Firepower Management Center during an upgrade.
Procedure
Step 1 Access the web interface of the active Firepower Management Center and pause data synchronization; see
Pausing Communication Between Paired Firepower Management Centers, on page 467.
Step 2 Upgrade the standby Firepower Management Center; see Update Software on a Firepower Management
Center, on page 138.
When the upgrade completes, the standby unit becomes active. When both peers are active, the high availability
pair is in a degraded state (split-brain).
Step 3 Upgrade the other Firepower Management Center.
Step 4 Decide which Firepower Management Center you want to use as the secondary. Unregister its devices and
export any configurations you want to preserve.
When you choose a new active Firepower Management Center, the Firepower Management Center you
designate as secondary will lose all of its device registrations and deployed policy configurations. For example,
you will lose modifications to any policies you made since you paused synchronization.
Step 5 Resolve split-brain by choosing the new active Firepower Management Center.
Establishing high availability can take a significant amount of time, even several hours, depending on the
bandwidth between the peers and the number of policies. It also depends on the number of devices registered
to the active Firepower Management Center, which need to be synced to the standby Firepower Management
Center. You can view the High Availability page to check the status of the high availability peers.
Procedure
Step 1 Log into the Firepower Management Center that you want to designate as the secondary.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Under Role for this Firepower Management Center, choose Secondary.
Step 5 Enter the hostname or IP address of the primary Firepower Management Center in the Primary Firepower
Management Center Host text box.
You can leave this empty if the primary Firepower Management Center does not have a routable address. In
this case, use both the Registration Key and the Unique NAT ID fields. You also need to specify the secondary
IP address on the primary unit; you need to specify the IP address of at least one unit.
Step 6 Enter a one-time-use registration key in the Registration Key text box.
The registration key is a user-defined alphanumeric value up to 37 characters in length.
Step 7 If you did not specify the primary IP address, or if you do not plan to specify the secondary IP address on the
primary Firepower Management Center, then in the Unique NAT ID field, enter a unique alphanumeric ID.
See NAT Environments, on page 455 for more information.
Step 8 Click Register.
Step 9 Using an account with Admin access, log into the Firepower Management Center that you want to designate
as the primary.
Step 10 Choose System > Integration.
Step 11 Choose High Availability.
Step 12 Under Role for this Firepower Management Center, choose Primary.
Step 13 Enter the hostname or IP address of the secondary Firepower Management Center in the Secondary Firepower
Management Center Host text box.
You can leave this empty if the secondary Firepower Management Center does not have a routable address.
In this case, use both the Registration Key and the Unique NAT ID fields. You also need to specify the
primary IP address on the secondary unit; you need to specify the IP address of at least one unit.
Step 14 Enter the same one-time-use registration key in the Registration Key text box you used in step 6.
Step 15 If required, enter the same NAT ID that you used in step 7 in the Unique NAT ID text box.
Step 16 Click Register.
After you identify your active and standby Firepower Management Centers, you can view information about
the local Firepower Management Center and its peer.
Note In this context, Local Peer refers to the appliance where you are viewing the system status. Remote Peer
refers to the other appliance, regardless of active or standby status.
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
You can view:
Summary Information
System Status
If automatic device registration fails on the standby Firepower Management Center, but appears to be registered
to the active Firepower Management Center, complete the following steps:
Procedure
Step 1 Unregister the device from the active Firepower Management Center.
Step 2 Log into the CLI for the affected device.
Step 3 Run the CLI command: configure manager delete.
Step 4 Run the CLI command: configure manager add.
Configure remote management for the active Firepower Management Center.
Step 5 Log into the active Firepower Management Center and register the device.
Because the system restricts some functionality to the active Firepower Management Center, if that appliance
fails, you must promote the standby Firepower Management Center to active:
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Switch Peer Roles to change the local role from Active to Standby, or Standby to Active. With the
Primary or Secondary designation unchanged, the roles are switched between the two peers.
If you want to temporarily disable high availability, you can disable the communications channel between
the Firepower Management Centers. If you pause synchronization on the active peer, you can resume
synchronization on either the standby or active peer. However, if you pause synchronization on the standby
peer, you only can resume synchronization on the standby peer.
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Pause Synchronization.
If you temporarily disable high availability, you can restart high availability by enabling the communications
channel between the Firepower Management Centers. If you paused synchronization on the active unit, you
can resume synchronization on either the standby or active unit. However, if you paused synchronization on
the standby unit, you only can resume synchronization on the standby unit.
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Resume Synchronization.
Note If you landed on this topic while trying to edit remote management on a 7000 and 8000 Series managed
device, see Editing Remote Management on a Managed Device, on page 497.
If the IP address for one of the high availability peers changes, high availability enters a degraded state. To
recover high availability, you must manually change the IP address.
Procedure
Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Peer Manager.
Step 5 Choose the edit icon ( ).
Step 6 Enter the display name of the appliance, which is used only within the context of the Firepower System.
Entering a different display name does not change the host name for the appliance.
Step 7 Enter the fully qualified domain name or the name that resolves through the local DNS to a valid IP address
(that is, the host name), or the host IP address.
Step 8 Choose Save.
Warning Make sure that there is at least one operational Firepower Management Center during an upgrade.
Procedure
Step 1 Access the web interface of the active Firepower Management Center and pause data synchronization; see
Pausing Communication Between Paired Firepower Management Centers, on page 467.
Step 2 Upgrade the standby Firepower Management Center; see Update Software on a Firepower Management
Center, on page 138.
When the upgrade completes, the standby unit becomes active. When both peers are active, the high availability
pair is in a degraded state (split-brain).
Step 3 Upgrade the other Firepower Management Center.
Step 4 Decide which Firepower Management Center you want to use as the secondary. Unregister its devices and
export any configurations you want to preserve.
When you choose a new active Firepower Management Center, the Firepower Management Center you
designate as secondary will lose all of its device registrations and deployed policy configurations. For example,
you will lose modifications to any policies you made since you paused synchronization.
Step 5 Resolve split-brain by choosing the new active Firepower Management Center.
Procedure
Step 1 Log into one of the Firepower Management Centers in the high availability pair.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Break High Availability.
Step 5 Choose one of the following options for handling managed devices:
• To control all managed devices with this Firepower Management Center, choose Manage registered
devices from this console. All devices will be unregistered from the peer.
• To control all managed devices with the other Firepower Management Center, choose Manage registered
devices from peer console. All devices will be unregistered from this Firepower Management Center.
• To stop managing devices altogether, choose Stop managing registered devices from both consoles.
All devices will be unregistered from both Firepower Management Centers.
Field Description
Name The display name used for the device in Firepower Management Center. The
status icon to the left of the name indicates its current health status.
Field Description
Group The group to which you assigned the managed devices.
License Type The licenses that are enabled on the managed device.
Access Control Policy A link to the currently deployed access control policy. If the system identifies
the access control policy as out-of-date, it displays a warning icon ( ) next to
the link.
Related Topics
About Firepower Feature Licenses, on page 109
About Health Monitoring, on page 223
Managing Access Control Policies, on page 1219
When your Firepower Management Center manages a large volume of devices, you can narrow the results
on the Device Management page to easier find a particular device.
Procedure
configuration and event information. High availability peers also use the channel, which is by default on port
8305/tcp.
Note This documentation explains how to configure remote management of a 7000 or 8000 Series device using
its local web interface, before you register the device to the FMC. For information on configuring remote
management for other models, see the appropriate quick start guide.
To enable communications between two appliances, you must provide a way for the appliances to recognize
each other. There are three criteria the Firepower System uses when allowing communications:
• the hostname or IP address of the appliance with which you are trying to establish communication.
In NAT environments, even if the other appliance does not have a routable address, you must provide
a hostname or an IP address either when you are configuring remote management, or when you are
adding the managed appliance.
• a self-generated alphanumeric registration key up to 37 characters in length that identifies the connection.
• an optional unique alphanumeric NAT ID that can help the Firepower System establish communications
in a NAT environment.
The NAT ID must be unique among all NAT IDs used to register managed appliances.
Related Topics
NAT Environments, on page 455
Use this procedure to add a single device to the Firepower Management Center. If you plan to link devices
for redundancy or performance, you must still use this procedure, keeping in mind the following points:
• 8000 Series stacks—Use this procedure to add each device to the Firepower Management Center, then
establish the stack; see Establishing Device Stacks, on page 540.
• 7000 and 8000 Series high availability—Use this procedure to add each device to the Firepower
Management Center, then establish high availability; see Establishing Device High Availability, on
page 525. For high availability stacks, first stack the devices, then establish high availability between the
stacks.
• Firepower Threat Defense high availability—Use this procedure to add each device to the Firepower
Management Center, then establish high availability; see Add a Firepower Threat Defense High
Availability Pair, on page 672.
• Firepower Threat Defense clusters—Make sure cluster units are in a successfully formed cluster on
FXOS, then use this procedure to add each unit to the Firepower Management Center as a separate
managed device. Finally, cluster the units on the Firepower Management Center. For more information,
see Add a Cluster to the Management Center, on page 695.
Note If you have established or will establish Firepower Management Center high availability, add devices only
to the active (or intended active) Firepower Management Center. When you establish high availability,
devices registered to the active Firepower Management Center are automatically registered to the standby.
Procedure
Step 4 In the Display Name field, enter a name for the device as you want it to display in the Firepower Management
Center.
Step 5 In the Registration Key field, enter the same registration key that you used when you configured the device
to be managed by the Firepower Management Center. The registration key is a one-time-use shared secret.
Step 6 In a multidomain deployment, regardless of your current domain, assign the device to a leaf Domain.
If your current domain is a leaf domain, the device is automatically added to the current domain. If your
current domain is not a leaf domain, post-registration, you must switch to the leaf domain to configure the
device.
Step 10 If you used a NAT ID during device setup, expand the Advanced section and enter the same NAT ID in the
Unique NAT ID field.
Step 11 Check the Transfer Packets check box to allow the device to transfer packets to the Firepower Management
Center.
This option is enabled by default. If you disable it, you completely prohibit packet transfer to the Firepower
Management Center.
Related Topics
Creating a Basic Access Control Policy, on page 1220
If you no longer want to manage a device, you can delete it from the Firepower Management Center. Deleting
a device:
• Severs all communication between the Firepower Management Center and the device.
• Removes the device from the Device Management page.
• Returns the device to local time management if the device is configured via the platform settings policy
to receive time from the Firepower Management Center via NTP.
Procedure
Field Description
Name The display name of the device on the Firepower Management Center.
Transfer Whether the managed device sends packet data with the events to the Firepower Management
Packets Center.
Mode The mode of the management interface for the device: routed or transparent.
Force Deploy Forces deployment of all policies and device configuration updates on the device.
Related Topics
About Firepower Feature Licenses, on page 109
Field Description
Model The model name and number for the managed device.
Field Description
Version The version of the software currently installed on the managed device.
Policy A link to the platform settings policy currently deployed to the managed device.
Inventory A link to the inventory details for the associated Firepower 2100 device. The Inventory
Details window displays the following information, harvested from the FXOS platform
REST API:
• Fan
• Memory
• CPU
• Power Supply
• Storage
• Network Module
This field only appears in Firepower Management Centers on Firepower 2100 devices.
Field Description
Status An icon that represents the current health status of the device. Clicking the icon displays
the Health Monitor for the appliance.
Policy A link to a read-only version of the health policy currently deployed at the device.
Blacklist A link to the Health Blacklist page, where you can enable and disable health blacklist
modules.
Related Topics
Viewing Appliance Health Monitors, on page 241
Editing Health Policies, on page 233
Blacklisting Health Policy Modules, on page 236
Field Description
Host The IP address or host name of the device. The host name is fully qualified domain name
or the name that resolves through the local DNS to a valid IP address (that is, the host
name).
Status An icon indicating the status of the communication channel between the Firepower
Management Center and the managed device. You can hover over the status icon to view
the last time the Firepower Management Center contacted the device.
Bypass Threshold The Automatic Application Bypass threshold, in milliseconds. 7000 & 8000 Series,
NGIPSv, ASA
FirePOWER ,
Firepower Threat
Defense
Inspect Local Router Whether the device inspects traffic received on routed 7000 & 8000 Series
Traffic interfaces that is destined for itself, such as ICMP, DHCP, and
OSPF traffic.
Fast-Path Rules The number of 8000 Series fastpath rules that have been 8000 Series
created on the device.
In a multidomain deployment, ancestor domains can view information about all devices in descendant domains.
You must be in a leaf domain to edit a device.
Procedure
Note In some cases, if you edit the host name or IP address of a device by another method (using the device’s
LCD panel or CLI, for example), you may need to use the procedure below to manually update the host
name or IP address on the managing Firepower Management Center.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 7 Click Force Deploy to force deployment of current policies and device configuration to the device.
Step 8 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can enable licenses on your device if you have available licenses on your Firepower Management Center.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
About Firepower Feature Licenses, on page 109
The Automatic Application Bypass (AAB) feature limits the time allowed to process packets through an
interface and allows packets to bypass detection if the time is exceeded. The feature functions with any
deployment; however, it is most valuable in inline deployments.
You balance packet processing delays with your network’s tolerance for packet latency. When a malfunction
within Snort or a device misconfiguration causes traffic processing time to exceed a specified threshold, AAB
causes Snort to restart within ten minutes of the failure, and generates troubleshoot data that can be analyzed
to investigate the cause of the excessive processing time.
Typically, you use Rule Latency Thresholding in the intrusion policy to fast-path packets after the latency
threshold value is exceeded. Rule Latency Thresholding does not shut down the engine or generate troubleshoot
data.
If detection is bypassed, the device generates a health monitoring alert.
Caution AAB activates when an excessive amount of time is spent processing a single packet. AAB activation
partially restarts the Snort process, which temporarily interrupts the inspection of a few packets. Whether
packets drop during this interruption or pass without inspection depends on the model of the managed
device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
section.
Step 4 Check Automatic Application Bypass.
Step 5 Enter a Bypass Threshold from 250 ms to 60,000 ms. The default setting is 3000 milliseconds (ms).
Step 6 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
If locally-bound traffic matches a Monitor rule in a Layer 3 deployment, that traffic may bypass inspection.
To ensure inspection of the traffic, enable Inspect Local Router Traffic.
Procedure
Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
section.
Step 4 Check Inspect Local Router Traffic to inspect exception traffic when a 7000 or 8000 Series device is
deployed as a router.
Step 5 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
As a form of early traffic handling, 8000 Series fastpath rules can send traffic directly through an 8000 Series
device without further inspection or logging. (In a passive deployment, 8000 Series fastpath rules simply stop
analysis.) Each 8000 Series fastpath rule applies to a specific security zone or inline interface set. Because
8000 Series fastpath rules function at the hardware level, you can use only the following simple, outer-header
criteria to fastpath traffic:
• initiator and responder IP address or address block
• protocol, and for TCP and UDP, initiator and responder port
• VLAN ID
By default, 8000 Series fastpath rules affect connections from specified initiators to specified responders. To
fastpath all connections that meets the rule's criteria, regardless of which host is the initiator and which is the
responder, you can make the rule bidirectional.
Note Although they perform a similar function, 8000 Series fastpath rules are not related to the Fastpath tunnel
or prefilter rules that you configure in prefilter policies.
Procedure
Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
section.
Step 4 Click New IPv4 Rule or New IPv6 Rule.
Step 5 From the Domain drop-down list, choose an inline set or passive security zone.
Step 6 Configure the traffic you want to fastpath. Traffic must meet all the conditions to be fastpathed.
• Initiator and Responder (required)—Enter IP addresses or address blocks for initiators and responders.
• Protocol—Choose a protocol, or choose All.
• Initiator Port and Responder Port—For TCP and UDP traffic, enter initiator and responder ports. Leave
the fields blank or enter Any to match all TCP or UDP traffic. You can enter a comma-separated list of
ports, but you cannot enter port ranges.
• VLAN—Enter a VLAN ID. Leave the field blank or enter Any to match all traffic regardless of VLAN
tag.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note You cannot shut down or restart the ASA FirePOWER with the Firepower System user interface. See the
ASA documentation for more information on how to shut down the respective devices.
Procedure
Field Description
Name Each interface type is represented by a unique icon that indicates its type and link state
(if applicable). You can hover your pointer over the name or the icon to view the interface
type, speed, and duplex mode (if applicable) in a tooltip. The interface icons are described
in Interface Icons, on page 499.
The icons use a badging convention to indicate the current link state of the interface, which
may be one of three states:
• error ( )
• fault ( )
• not available ( )
Logical interfaces have the same link state as their parent physical interface. ASA
FirePOWER modules do not display link state. Note that disabled interfaces are represented
by semi-transparent icons.
Interface names, which appear to the right of the icons, are auto-generated with the
exception of hybrid and ASA FirePOWER interfaces, which are user-defined. Note that
for ASA FirePOWER interfaces, the system displays only interfaces that are enabled,
named, and have link.
Physical interfaces display the name of the physical interface. Logical interfaces display
the name of the physical interface and the assigned VLAN tag.
ASA FirePOWER interfaces display the name of the security context and the name of the
interface if there are multiple security contexts. If there is only one security context, the
system displays only the name of the interface.
Security Zone The security zone where the interface is assigned. To add or edit a security zone, click
the edit icon ( ).
Used by The inline set, virtual switch, or virtual router where the interface is assigned. ASA
FirePOWER modules do not display the Used by column.
MAC Address The MAC address displayed for the interface when it is enabled for switched and routed
features.
For NGIPSv devices, the MAC address is displayed so that you can match the network
adapters configured on your device to the interfaces that appear on the Interfaces page.
ASA FirePOWER modules do not display MAC addresses.
IP Addresses IP addresses assigned to the interface. Hover your pointer over an IP address to view
whether it is active or inactive. Inactive IP addresses are grayed out. ASA FirePOWER
modules do not display IP addresses.
Field Description
Interface The interface IDs. For the failover link or cluster control link interface, the interface
settings are view-only.
Logical Name The configured name of the interface.
MAC Address The interface MAC address(es). For High Availability, this column shows both the active
(Active/Standby) MAC address and the standby MAC address.
IP Address The IP addresses assigned to the interface. The type of address assignment shows in
parentheses: Static, DHCP, or PPPoE.
Device groups enable you to easily assign policies and install updates on multiple devices.
If you add the primary device in a stack or a high-availability pair to a group, both devices are added to the
group. If you unstack the devices or break the high-availability pair, both devices remain in that group.
Procedure
You can change the set of devices that reside in any device group. You must remove an appliance from its
current group before you can add it to a new group.
Moving an appliance to a new group does not change its policy to the policy previously assigned to the group.
You must assign the group's policy to the new device.
If you add the primary device in a stack or a device high-availability pair to a group, both devices are added
to the group. If you unstack the devices or break the high-availability pair, both devices remain in that group.
In a multidomain deployment, you can only edit device groups in the domain where they were created.
Procedure
The Firepower 2100 chassis supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c use
a community-based form of security.
Procedure
Port field The port on which the Firepower chassis communicates with the SNMP
host. You cannot change the default port.
Name Description
Community field The default SNMP v1 or v2 community name or SNMP v3 username
the Firepower chassis includes on any trap messages it sends to the
SNMP host.
Enter an alphanumeric string between 1 and 32 characters. Do not use
@ (at sign), \ (backslash), " (double quote), ? (question mark) or an
empty space. The default is public.
Note that if the Community field is already set, the text to the right of
the empty field reads Set: Yes. If the Community field is not yet
populated with a value, the text to the right of the empty field reads Set:
No.
System Admin Name field The contact person responsible for the SNMP implementation.
Enter a string of up to 255 characters, such as an email address or a
name and telephone number.
Location field The location of the host on which the SNMP agent (server) runs.
Enter an alphanumeric string up to 510 characters.
What to Do Next
Create SNMP traps and users.
Procedure
Name Description
Community field The SNMP v1 or v2 community name or the SNMP v3 username the
Firepower chassis includes when it sends the trap to the SNMP host.
This must be the same as the community or username that is configured
for the SNMP service.
Enter an alphanumeric string between 1 and 32 characters. Do not use
@ (at sign), \ (backslash), " (double quote), ? (question mark) or an
empty space.
Port field The port on which the Firepower chassis communicates with the SNMP
host for the trap.
Enter an integer between 1 and 65535.
Version field The SNMP version and model used for the trap. This can be one of the
following:
• V1
• V2
• V3
Type field If you select V2 or V3 for the version, the type of trap to send. This can
be one of the following:
• Traps
• Informs
Privilege field If you select V3 for the version, the privilege associated with the trap.
This can be one of the following:
• Auth—Authentication but no encryption
• Noauth—No authentication or encryption
• Priv—Authentication and encryption
Procedure
Note This documentation explains how to configure remote management of a 7000 or 8000 Series device using
its local web interface, before you register the device to the FMC. For information on configuring remote
management for other models, see the appropriate quick start guide.
To enable communications between two appliances, you must provide a way for the appliances to recognize
each other. There are three criteria the Firepower System uses when allowing communications:
• the hostname or IP address of the appliance with which you are trying to establish communication.
In NAT environments, even if the other appliance does not have a routable address, you must provide
a hostname or an IP address either when you are configuring remote management, or when you are
adding the managed appliance.
• a self-generated alphanumeric registration key up to 37 characters in length that identifies the connection.
• an optional unique alphanumeric NAT ID that can help the Firepower System establish communications
in a NAT environment.
The NAT ID must be unique among all NAT IDs used to register managed appliances.
Procedure
Step 1 On the web interface for the device you want to manage, choose Configuration > ASA FirePOWER
Configuration > Integration > Remote Management.
Step 2 Click the Remote Management tab, if it is not already displaying.
Step 3 Click Add Manager.
Step 4 In the Management Host field, enter one of the following for the Firepower Management Center that you
want to use to manage this appliance:
• The IP address
• The fully qualified domain name or the name that resolves through the local DNS to a valid IP address
(that is, the host name)
Caution Use a host name rather than an IP address if your network uses DHCP to assign IP addresses.
In a NAT environment, you do not need to specify an IP address or host name here if you plan to specify it
when you add the managed appliance. In this case, the Firepower System uses the NAT ID you will provide
later to identify the remote manager on the managed appliance’s web interface.
Step 5 In the Registration Key field, enter the registration key that you want to use to set up communications between
appliances.
Step 6 For NAT environments, in the Unique NAT ID field, enter a unique alphanumeric NAT ID that you want
to use to set up communications between appliances.
Step 7 Click Save.
What to Do Next
• Wait until the appliances confirm that they can communicate with each other and the Pending Registration
status appears.
• Add this device to the Firepower Management Center; see Adding Devices to the Firepower Management
Center, on page 473.
Procedure
Step 1 On the web interface for the device, choose System > Integration.
Step 2 Click the Remote Management tab, if it is not already displaying.
Step 3 You can:
• Disable remote management — Click the slider next to the manager to enable or disable it. Disabling
management blocks the connection between the Firepower Management Center and the device, but does
not delete the device from the Firepower Management Center. If you no longer want to manage a device,
see Deleting Devices from the Firepower Management Center, on page 475.
• Edit manager information — Click the edit icon ( ) next to the manager you want to modify, modify
the Name and Host fields, and click Save.
Caution If you change the management port, you must change it for all appliances in your deployment that need
to communicate with each other.
Procedure
What to Do Next
• Repeat this procedure for every appliance in your deployment that must communicate with this appliance.
Interface Icons
Table 58: Interface Icon Types and Descriptions
Procedure
You can configure the sensing interfaces of a managed device, according to your Firepower System deployment,
from the Interfaces page of the appliance editor. Note that you can only configure a total of 1024 interfaces
on a managed device.
Note The Firepower Management Center does not display ASA interfaces when the ASA FirePOWER is
deployed in SPAN port mode.
Procedure
Step 3 Click the edit icon ( ) next to the interface you want to configure.
Step 4 Use the interface editor to configure the sensing interface:
• HA Link — If you want an interface configured on each member of a high-availability pair of devices
to act as a redundant communications channel between the devices; also called a high availability link
interface, click HA Link and proceed as described in Configuring HA Link Interfaces, on page 501.
• Inline — If you want an interface configured to handle traffic in an inline deployment, click Inline and
proceed as described in Configuring Inline Interfaces, on page 511.
• Passive — If you want an interface configured to analyze traffic in a passive deployment, click Passive
and proceed as described in Configuring Passive Interfaces, on page 508.
• Routed — If you want an interface configured to route traffic in a Layer 3 deployment, click Routed
and proceed as described in Routed Interfaces, on page 1142.
• Switched — If you want an interface configured to switch traffic in a Layer 2 deployment, click Switched
and proceed as described in Switched Interface Configuration, on page 1132.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
After you establish a 7000 or 8000 Series device high-availability pair, you can configure a physical interface
as a high availability (HA) link interface. This link acts as a redundant communications channel for sharing
health information between the paired devices. When you configure an HA link interface on one device, you
automatically configure an interface on the second device. You must configure both HA links on the same
broadcast domain.
Dynamic NAT relies on dynamically allocating IP addresses and ports to map to other IP addresses and ports.
Without an HA link, these mappings are lost in a failover, causing all translated connections to fail as they
are routed through the now-active device in the high-availability pair.
Procedure
Step 3 Next to the interface you want to configure as a HA link interface, click the edit icon ( ).
Step 4 Click HA Link.
Step 5 Check the Enabled check box.
Note If you clear the check box, the system administratively takes down the interface, disabling
it.
Step 6 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to autonegotiate speed and duplex settings.
Step 7 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
Note Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI
and MDIX to attain link.
Step 8 Enter a maximum transmission unit (MTU) in the MTU field.
The range of MTU values can vary depending on the model of the managed device and the interface type.
See MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504 for more information.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 9 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Snort® Restart Scenarios , on page 292
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Disabling Interfaces
Smart License Classic License Supported Devices Supported Domains Access
Any Any 7000 & 8000 Series Leaf only Admin/Network
Admin
NGIPSv
You can disable an interface by setting the interface type to None. Disabled interfaces appear grayed out in
the interface list.
Procedure
Step 3 Next to the interface you want to disable, click the edit icon ( ).
Step 4 Click None.
Step 5 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When editing an ASA FirePOWER interface, you can configure only the interface’s security zone from the
Firepower Management Center.
You fully configure ASA FirePOWER interfaces using the ASA-specific software and CLI. If you edit an
ASA FirePOWER and switch from multiple context mode to single context mode (or visa versa), the ASA
FirePOWER renames all of its interfaces. You must reconfigure all Firepower System security zones, correlation
rules, and related configurations to use the updated ASA FirePOWER interface names. For more information
about ASA FirePOWER interface configuration, see the ASA documentation.
Note You cannot change the type of ASA FirePOWER interface, nor can you disable the interface from the
Firepower Management Center.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv
Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Note The system trims 18 bytes from the configured MTU value. Do not set the IPv4 MTU lower than 594 or
the IPv6 MTU lower than 1298.
Related Topics
About the MTU, on page 590
When you update a security zone object, the system saves a new revision of the object. As a result, if you
have managed devices in the same security zone that have different revisions of the security zone object
configured in the interfaces, you may log what appear to be duplicate connections.
If you notice duplicate connection reporting, you can update all managed devices to use the same revision of
the object.
Procedure
Step 3 For each interface logging duplicate connection events, change the Security Zone to another zone, click Save,
then change it back to the desired zone, and click Save again.
Step 4 Repeat steps 2 through 3 for each device logging duplicate events. You must edit all devices before you
continue.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution Do not deploy configuration changes to any device until you edit the zone setting for interfaces on all
devices you want to sync. You must deploy to all managed devices at the same time.
Note Outbound traffic includes flow control packets. Because of this, passive interfaces on your appliances
may show outbound traffic and, depending on your configuration, generate events; this is expected behavior.
When you disable a passive interface, users can no longer access it for security purposes.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Step 3 Click the edit icon ( ) next to the interface you want to configure as a passive interface.
Step 4 Click Passive.
Step 5 If you want to associate the passive interface with a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 7 7000 & 8000 Series only: From the Mode drop-down list, designate the link mode, or choose Autonegotiation
to specify that the interface is configured to automatically negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.
Step 8 7000 & 8000 Series only: From the MDI/MDIX drop-down list, designate whether the interface is configured
for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note For the system to affect traffic, you must deploy relevant configurations to managed devices using routed,
switched, or transparent interfaces, or inline interface pairs.
You can configure the interfaces on your managed device to route traffic between a host on your network and
external hosts through different inline interface pairs, depending on whether the device traffic is inbound or
outbound. This is an asynchronous routing configuration. If you deploy asynchronous routing but you include
only one interface pair in an inline set, the device may not correctly analyze your network traffic because it
might see only half of the traffic. Adding multiple inline interface pairs to the same inline interface set allows
the system to identify the inbound and outbound traffic as part of the same traffic flow. You can also achieve
this by including the interface pairs in the same security zone.
When the system generates a connection event from traffic passing through an asynchronous routing
configuration, the event may identify an ingress and egress interface from the same inline interface pair. The
configuration in the following diagram, for example, would generate a connection event identifying eth3 as
the ingress interface and eth2 as the egress interface. This is expected behavior in this configuration.
Note If you assign multiple interface pairs to a single inline interface set but you experience issues with duplicate
traffic, reconfigure to help the system uniquely identify packets. For example, you could reassign your
interface pairs to separate inline sets or modify your security zones.
For devices with inline sets, a software bridge is automatically set up to transport packets after the device
restarts. If the device is restarting, there is no software bridge running anywhere. If you enable bypass mode
on the inline set, it goes into hardware bypass while the device is restarting. In that case, you may lose a few
seconds of packets as the system goes down and comes back up, due to renegotiation of link with the device.
However, the system will pass traffic while Snort is restarting.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
• The system warns you if you set the interfaces in an inline pair to different speeds or if the interfaces
negotiate to different speeds.
• If you configure an interface as an inline interface, the adjacent port on its NetMod automatically becomes
an inline interface as well to complete the pair.
• To configure inline interfaces on an NGIPSv device, you must create the inline pair using adjacent
interfaces.
Procedure
Step 3 Click the edit icon ( ) next to the interface you want to configure.
Step 4 Click Inline.
Step 5 If you want to associate the inline interface with a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 6 Choose an existing inline set from the Inline Set drop-down list, or choose New to add a new inline set.
Note If you add a new inline set, you must configure it after you set up the inline interface; see Adding
Inline Sets, on page 514.
Step 7 Check the Enabled check box.
If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.
Step 8 7000 & 8000 Series only: From the Mode drop-down list, designate the link mode, or choose Autonegotiation
to specify that the interface is configured to automatically negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.
Step 9 7000 & 8000 Series only: From the MDI/MDIX drop-down list, designate whether the interface is configured
for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Name
The name of the inline set.
Interfaces
A list of all inline interface pairs assigned to the inline set. A pair is not available when you disable either
interface in the pair from the Interfaces tab.
MTU
The maximum transmission unit for the inline set. The range of MTU values can vary depending on the model
of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Failsafe
Behavior of the interface on a 7000 or 8000 Series or NGIPSv device when the Snort process is busy or down.
• Enabled—New and existing flows pass without inspection when the Snort process is busy or down.
• Disabled—New and existing flows drop when the Snort process is busy and pass without inspection
when the Snort process is down.
The Snort process can be busy when traffic buffers are full, indicating that there is more traffic than the
managed device can handle, or because of other software issues.
The Snort process goes down when you deploy a configuration that requires it to restart. See Configurations
that Restart the Snort Process When Deployed or Activated, on page 294 for more information.
Note When traffic passes without inspection, features that rely on the Snort process do not function. These
include application control and deep inspection. The system performs only basic access control using
simple, easily determined transport and network layer characteristics.
Bypass Mode
Firepower 7000 or 8000 Series only: The configured bypass mode of the inline set. This setting determines
how the relays in the inline interfaces respond when an interface fails. The bypass mode allows traffic to
continue to pass through the interfaces. The non-bypass mode blocks traffic.
Caution In bypass mode, you may lose a few packets when you reboot the appliance. You cannot configure bypass
mode for inline sets on 7000 or 8000 Series devices in a high-availability pair, inline sets on an NGIPSv
device, for non-bypass NetMods on 8000 Series devices, or for SFP modules on Firepower 7115 or 7125
devices.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Procedure
Step 9 7000 and 8000 Series only: Specify the bypass mode:
• Click Bypass to allow traffic to continue to pass through the interfaces.
• Click Non-Bypass to block traffic.
Note You cannot configure bypass mode for inline sets on 7000 or 8000 Series devices in high-availability
pairs, inline sets on an NGIPSv device, for non-bypass NetMods on 8000 Series devices, or for SFP
modules on Firepower 7115 or 7125 devices.
Step 10 Optionally, configure advanced settings; see Advanced Inline Set Options, on page 515.
Step 11 Click OK.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Tap Mode
Tap mode is available on 7000 and 8000 Series devices when you create an inline or inline with fail-open
interface set.
With tap mode, the device is deployed inline, but instead of the packet flow passing through the device, a
copy of each packet is sent to the device and the network traffic flow is undisturbed. Because you are working
with copies of packets rather than the packets themselves, rules that you set to drop and rules that use the
replace keyword do not affect the packet stream. However, rules of these types do generate intrusion events
when they are triggered, and the table view of intrusion events indicates that the triggering packets would
have dropped in an inline deployment.
There are benefits to using tap mode with devices that are deployed inline. For example, you can set up the
cabling between the device and the network as if the device were inline and analyze the kinds of intrusion
events the device generates. Based on the results, you can modify your intrusion policy and add the drop rules
that best protect your network without impacting its efficiency. When you are ready to deploy the device
inline, you can disable tap mode and begin dropping suspicious traffic without having to reconfigure the
cabling between the device and the network.
Note that you cannot enable this option and strict TCP enforcement on the same inline set.
You cannot disable link state propagation for inline sets configured on 7000 and 8000 Series devices in
high-availability pairs.
Note that only 7000 and 8000 Series devices support this option. In addition, you cannot enable this option
and tap mode on the same inline set.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you delete an inline set, any inline interfaces assigned to the set become available for inclusion in
another set. The interfaces are not deleted.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• About 7000 and 8000 Series Device High Availability, page 521
• Establishing Device High Availability, page 525
• Editing Device High Availability, page 526
• Configuring Individual Devices in a High-Availability Pair, page 526
• Configuring Individual Device Stacks in a High-Availability Pair, page 527
• Configuring Interfaces on a Device in a High-Availability Pair, page 528
• Switching the Active Peer in a Device High-Availability Pair, page 528
• Placing a High-Availability Peer into Maintenance Mode, page 529
• Replacing a Device in a Stack in a High-Availability Pair, page 530
• Device High Availability State Sharing, page 530
• Device High Availability State Sharing Statistics for Troubleshooting, page 533
• Separating Device High-Availability Pairs, page 536
Note Static routes, non-SFRP IP addresses, and routing priorities are not synchronized between the peer devices
or peer device stacks. Each peer device or peer device stack maintains its own routing intelligence.
Related Topics
SFRP, on page 1148
Advanced Virtual Switch Settings, on page 1137
Note After you pair the devices, you cannot change the license options for individual paired
devices, but you can change the license for the entire high-availability pair.
Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device.
Installing an unsupported hard drive may damage the device. Malware storage pack kits
are available for purchase only from Cisco, and are for use only with 8000 Series devices.
Contact Support if you require assistance with the malware storage pack. See the
Firepower System Malware Storage Pack Guide for more information.
• If the devices are targeted by NAT policies, both peers must have the same NAT policy.
• In a multidomain deployment, you can only establish 7000 or 8000 Series device high-availability or
device stacks within a leaf domain.
degraded state. The system also does not fail over when one of the devices or device stacks is in maintenance
mode. Note that disconnecting the stacking cable from an active stack sends that stack into maintenance mode.
Shutting down the secondary device in an active stack also sends that stack into maintenance mode.
Note If the active member of the high-availability pair goes into maintenance mode and the active role fails
over to the other pair member, when the original active pair member is restored to normal operation it
does not automatically reclaim the active role.
Caution When you deploy, resource demands may result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293. On
Firepower 7010, 7020, and 7030 managed devices, deploying configuration changes can take up to five
minutes. To minimize inconvenience, deploy during a change window. See Snort® Restart Scenarios ,
on page 292 and Configurations that Restart the Snort Process When Deployed or Activated, on page 294.
Devices in high-availability pairs receive updates as a single entity rather than individual devices or stacks.
When the update is started, the system first deploys it to the standby device or stack, which goes into
maintenance mode until any necessary processes restart and the device begins processing traffic again. The
system then deploys the update to the active device or stack, which follows the same process.
Note You can achieve Layer 3 redundancy without using device high availability by using the Cisco Redundancy
Protocol (SFRP). SFRP allows devices to act as redundant gateways for specified IP addresses. With
network redundancy, you configure two devices or stacks to provide identical network connections,
ensuring connectivity for other hosts on the network.
Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy
in a 7000 or 8000 Series device high-availability pair.
switched interfaces or routed interfaces, the system establishes the high-availability pair, but sets it to a pending
status. After you configure the necessary attributes, the system completes the high-availability pair and sets
it to a normal status.
After you establish a high-availability pair, the system treats the peer devices or stacks as a single device on
the Device Management page. Device high-availability pairs display the High Availability icon ( ) in the
appliance list. Any configuration changes you make are synchronized between the paired devices. The Device
Management page displays which device or stack in the high-availability pair is active, which changes after
manual or automatic failover.
Removing registration of a device high-availability pair from a Firepower Management Center removes
registration from both devices or stacks. You remove a device high-availability pair from the Firepower
Management Center as you would an individual managed device.
You can then register the high-availability pair on another Firepower Management Center. To register single
devices from a high-availability pair, you add remote management to the active device in the pair and then
add that device to the Firepower Management Center, which adds the whole pair. To register stacked devices
in a high-availability pair, you add remote management to the primary device of the either stack and then add
that device to the Firepower Management Center, which adds the whole pair.
After you establish a device high-availability pair, you can configure a high-availability link interface.
Note This procedure describes establishing a 7000 & 8000 Series device high-availability pair. For information
on establishing Firepower Threat Defense high availability, see Add a Firepower Threat Defense High
Availability Pair, on page 672.
When establishing a 7000 & 8000 Series device high-availability pair, you designate one of the devices or
stacks as active and the other as standby. The system applies a merged configuration to the paired devices. If
there is a conflict, the system applies the configuration from the device or stack you designated as active.
In a multidomain deployment, devices in a high-availability pair must belong to the same domain.
Procedure
After you establish a 7000 or 8000 Series device high-availability pair, most changes you make to the device
configuration also change the configuration of the whole high-availability pair.
You can view the status of the high-availability pair by hovering your pointer over the status icon in the
General section. You can also view which device or stack is the active peer and standby peer in the pair.
Procedure
Step 3 Use the sections on the High Availability page to make changes to the high-availability pair configuration as
you would a single device configuration.
After you establish a 7000 or 8000 Series device high-availability pair, you can still configure some attributes
for each device within the pair. You can make changes to a paired device just as you would to a single device.
Procedure
After you configure stacked 8000 Series devices into a high-availability pair, the system limits the stack
attributes that you can edit. You can edit the name of a stack in a paired stack. In addition, you can edit the
network configuration of the stack, as described in Configuring Interfaces on a Device in a High-Availability
Pair, on page 528.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can configure interfaces on individual devices in a 7000 or 8000 Series device high-availability pair.
However, you must also configure an equivalent interface on the peer device in the pair. For paired stacks,
you configure identical interfaces on the primary devices of the stacks. When you configure virtual routers,
you select the stack where you want to configure the routers.
Procedure
Related Topics
Virtual Router Configuration, on page 1150
After you establish a 7000 or 8000 Series device high-availability pair, you can manually switch the active
and standby peer devices or stacks.
Procedure
After you establish a 7000 or 8000 Series device high-availability pair, you can manually trigger failover by
placing one of the peers into maintenance mode to perform maintenance on the devices. In maintenance mode,
the system administratively takes down all interfaces except for the management interface. After maintenance
is completed, you can re-enable the peer to resume normal operation.
Note You should not place both peers in a high-availability pair into maintenance mode at the same time. Doing
so will prevent that pair from inspecting traffic.
Procedure
What to Do Next
• When maintenance is complete, click the toggle maintenance mode icon ( ) again to bring the peer
out of maintenance mode.
After you place a stack that is a member of a high-availability pair into maintenance mode, you can replace
a secondary device in the stack for another device. You can only select devices that are not currently stacked
or paired. The new device must follow the same guidelines for establishing a device stack.
Procedure
Note If paired devices fail over, the system terminates all existing SSL-encrypted sessions on the active device.
Even if you establish high availability state sharing, these sessions must be renegotiated on the standby
device. If the server establishing the SSL session supports session reuse and the standby device does not
have the SSL session ID, it cannot renegotiate the session.
Blocking Persistence
While many connections are blocked on the first packet based on access control rules or other factors, there
are cases where the system allows some number of packets through before determining that the connection
should be blocked. With state sharing, the system immediately blocks the connection on the peer device or
stack as well.
When establishing state sharing for a high-availability pair, you can configure the following options:
Enabled
Click the check box to enable state sharing. Clear the check box to disable state sharing.
Related Topics
Configuring HA Link Interfaces, on page 501
Device high-availability state sharing allows 7000 or 8000 Series devices or stacks in high-availability pairs
to synchronize as much state as necessary, so that if either device or stack fails, the other peer can take over
with no interruption to traffic flow.
Caution Modifying a high-availability state sharing option on a 7000 or 8000 Series device restarts the Snort
process on the primary and secondary devices, temporarily interrupting traffic insepection on both devices.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293 for
more information.
Procedure
Step 1 Configure HA link interfaces for each device in the device high-availability pair; see Configuring HA Link
Interfaces, on page 501.
Step 2 Choose Devices > Device Management.
Step 3 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Configuring HA Link Interfaces, on page 501
Snort® Restart Scenarios , on page 292
Packets Received
The system batches multiple messages into single packets in order to decrease overhead. The Packets Received
counter displays the total number of these data packets, as well as other control packets that have been received
by a device.
The value should be close to the number of packets sent by the peer device. During active use, the values may
not match, but should be close. Because the number of messages received should be close and incrementing
at the same rate as the number of messages sent by the peer, the number of packets received should have the
same behavior.
For troubleshooting, you should view both the packets received and the messages sent, compare the rate of
increase, and make sure the values are increasing at the same rate. If the sent value on the paired peer is
incrementing, the received value on the device should also increase at the same rate.
Contact Support if the received packets stop incrementing or increment slower than the messages sent by the
peer.
Contact Support if the received bytes stop incrementing or increment slower than the messages sent by the
peer.
Messages Sent
Messages sent are the number of high availability synchronization messages sent to the paired peer.
This data is useful in comparison to the number of messages received. During active use, the values may not
match, but should be close.
For troubleshooting, you should view both the messages received and the messages sent, compare the rate of
increase, and make sure the values are close.
Contact Support if the messages sent increment at a similar rate to the total bytes received.
Bytes Sent
Bytes sent are the total number of bytes sent that make up the high availability synchronization messages sent
to the peer.
This data are useful in comparison to the number of messages received. During active use, the values may
not match, but should be close. The number of bytes received on the peer should be close to, but not more
than this value.
Contact Support if the total bytes received is not incrementing at about the same rate as the bytes sent.
Tx Errors
Tx errors are the number of memory allocation failures the system encounters when trying to allocate space
for messages to be sent to the paired peer.
This value should be zero at all times on both peers. Contact Support if this number is not zero or if the number
steadily increases, which indicates the system has encountered an error where it cannot allocate memory.
Tx Overruns
Tx overruns are the number of times the system attempts and fails to place a message into the transit queue.
This value should be zero at all times on both peers. When the value is not zero or is steadily increasing, it
indicates that the system is sharing too much data across the HA link that cannot be sent quickly enough.
You should increase the HA link MTU if it was previously set below the default value (9918 or 9922). You
can change the minimum flow lifetime and minimum synchronization interval settings to reduce the amount
of data shared across the HA link to prevent the number from incrementing.
Recent Logs
The system log displays the most recent high availability synchronization messages. The log should not display
any ERROR or WARN messages. It should remain comparable between the peers, such as the same number
of sockets being connected.
However, the data displayed may be opposite in some instances, for example, one peer reports that it received
a connection from the other peer and references different IP addresses. The log provides a comprehensive
view of the high availability state sharing connection, and any errors within the connection.
Contact Support if the log displays an ERROR or WARN message, or any message that does not appear to
be purely informational.
After you establish state sharing, you can view the following information about the configuration in the State
Sharing section of the High Availability page:
• The HA link interface that is being used and its current link state
• Detailed synchronization statistics for troubleshooting issues
The state sharing statistics are primarily counters for different aspects of the high availability synchronization
traffic sent and received, along with some other error counters. In addition, you can view the latest system
logs for each device in the high-availability pair.
Procedure
Step 3 In the State Sharing section, click the view statistics icon ( ).
Step 4 Choose a Device to view if your high-availability pair is composed of device stacks.
Step 5 You can:
• Click Refresh to update the statistics.
• Click View to view the latest data log for each device in the high-availability pair.
When you separate, or "break," a 7000 or 8000 Series device high-availability pair:
• The active peer (device or stack) retains full deployment functionality
• The standby peer (device or stack) loses its interface configurations and fails over to the active peer,
unless you choose to leave the interface configurations active, in which case the standby peer resumes
normal operation.
• The standby peer always loses the configuration of passive interfaces.
• Any peer in maintenance mode resumes normal operation.
Procedure
For more information about stacked configurations, see the Cisco Firepower 8000 Series Getting Started
Guide. For more information about the malware storage pack, see the Firepower System Malware Storage
Pack Guide. Firepower System Malware Storage Pack Guide.
Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an
unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only
from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with
the malware storage pack. See the Firepower System Malware Storage Pack Guide for more information.
When you establish a stacked configuration, you combine the resources of each stacked device into a single,
shared configuration.
You designate one device as the primary device, where you configure the interfaces for the entire stack. You
designate the other devices as secondary. Secondary devices must not be currently sensing any traffic and
must not have link on any interface.
Connect the primary device to the network segment you want to analyze in the same way you would configure
a single device. Connect the secondary devices to the primary device using the stacked device cabling
instructions found in the Cisco Firepower 8000 Series Getting Started Guide.
All devices in the stacked configuration must have the same hardware, run the same software version, and
have the same licenses. If the devices are targeted by NAT policies, both the primary and secondary device
must have the same NAT policy. You must deploy updates to the entire stack from the Firepower Management
Center. If an update fails on one or more devices in the stack, the stack enters a mixed-version state. You
cannot deploy policies to or update a stack in a mixed-version state. To correct this state, you can break the
stack or remove individual devices with different versions, update the individual devices, then reestablish the
stacked configuration. After you stack the devices, you can change the licenses only for the entire stack at
once.
After you establish the stacked configuration, the devices act like a single, shared configuration. If the primary
device fails, no traffic is passed to the secondary devices. Health alerts are generated indicating that the stacking
heartbeat has failed on the secondary devices.
If the secondary device in a stack fails, inline sets with configurable bypass enabled go into bypass mode on
the primary device. For all other configurations, the system continues to load balance traffic to the failed
secondary device. In either case, a health alert is generated to indicate loss of link.
You can use a device stack as you would a single device in your deployment, with a few exceptions. If you
have 7000 or 8000 Series devices in a high-availability pair, you cannot stack a device high-availability pair
or a device in a high-availability pair. You also cannot configure NAT on a device stack.
Note If you use eStreamer to stream event data from stacked devices to an external client application, collect
the data from each device and ensure that you configure each device identically. The eStreamer settings
are not automatically synchronized between stacked devices.
In a multidomain deployment, you can only stack devices that belong to the same domain.
Related Topics
About Health Monitoring, on page 223
For additional devices, the primary device in the stack must have the necessary stacking NetMods for additional
cabled devices. For example, if you have a Firepower 8260 where the primary only has a single stacking
NetMod, you cannot add another secondary device to this stack. You add secondary devices to an existing
stack in the same manner that you initially establish a stacked device configuration.
All devices in a stack must be of the same hardware model (for example, a Firepower 8140 with another
8140). You can stack a total of four devices (one primary device and up to three secondary devices) in the
8200 family and in the 8300 family.
In a multidomain deployment, all devices in the stack must belong to the same domain.
Procedure
Related Topics
About 7000 and 8000 Series Device High Availability, on page 521
After you establish a device stack, most changes you make to the device configuration also change the
configuration of the entire stack. On the Stack page of the appliance editor, you can make changes to the stack
configuration as on the Device page of a single device.
You can change the display name of the stack, enable and disable licenses, view system and health policies,
and configure advanced settings.
Procedure
Step 3 Use the sections on the Stack page to make changes to the stacked configuration as you would a single device
configuration.
If the Firepower Management Center cannot communciate with the device, you must connect to the device
and use CLI commands to separate the stack and unregister the device. For more information, see stacking
disable and delete CLI commands in the relevant chapter: Configuration Commands, on page 2505.
To replace a device within a stack:
Procedure
Step 1 Select the stack with the device to replace and break that stack. For more information, see Separating Stacked
Devices, on page 544.
Step 2 Unregister the device from the Firepower Management Center. For more information, see Deleting Devices
from the Firepower Management Center, on page 475.
Step 3 Register the replacement device to the Firepower Management Center. For more information, see Adding
Devices to the Firepower Management Center, on page 473.
Step 4 Create a device stack that includes the replacement deivce. for more information, see Establishing Device
Stacks, on page 540.
After you place a stack that is a member of a high-availability pair into maintenance mode, you can replace
a secondary device in the stack for another device. You can only select devices that are not currently stacked
or paired. The new device must follow the same guidelines for establishing a device stack.
Procedure
After you establish a device stack, you can still configure some attributes for an individual device within the
stack. You can make changes to a device configured in a stack as you would for a single device. You can
change the display name of a device, view system settings, shut down or restart a device, view health
information, and edit device management settings.
Procedure
With the exception of the management interface, you configure stacked device interfaces on the Interfaces
page of the primary device in the stack. You can choose any device in the stack to configure the management
interface.
The Interfaces page of a Firepower stacked device includes the hardware and interfaces views that you find
on an individual device.
Procedure
Related Topics
Management Interfaces, on page 875
If you no longer need to use a stacked configuration for your devices, you can break the stack and separate
the devices.
Note If a stacked device fails, or if communication fails between member devices of a stack, you cannot separate
the stacked devices using the Firepower Management Center web interface. In this case, use the auxiliary
CLI command configure stacking disable to remove the stack configuration from each device
individually.
Procedure
If the Firepower Management Center cannot communciate with the device, you must connect to the device
and use CLI commands to separate the stack and unregister the device. For more information, see stacking
disable and delete CLI commands in the relevant chapter: Configuration Commands, on page 2505.
To replace a device within a stack:
Procedure
Step 1 Select the stack with the device to replace and break that stack. For more information, see Separating Stacked
Devices, on page 544.
Step 2 Unregister the device from the Firepower Management Center. For more information, see Deleting Devices
from the Firepower Management Center, on page 475.
Step 3 Register the replacement device to the Firepower Management Center. For more information, see Adding
Devices to the Firepower Management Center, on page 473.
Step 4 Create a device stack that includes the replacement deivce. for more information, see Establishing Device
Stacks, on page 540.
Note The firewall mode only affects regular firewall interfaces, and not IPS-only interfaces such as inline sets
or passive interfaces. IPS-only interfaces can be used in both firewall modes. See Configure an IPS-Only
Interface, on page 597 for more information about IPS-only interfaces. Inline sets might be familiar to
you as "transparent inline sets," but the inline interface type is unrelated to the transparent firewall mode
described in this chapter or the firewall-type interfaces.
using routed mode instead of transparent mode. In routed mode, you can have one or more isolated bridge
groups like in transparent mode, but also have normal routed interfaces as well for a mixed deployment.
Diagnostic Interface
In addition to each Bridge Virtual Interface (BVI) IP address, you can add a separate Diagnostic slot/port
interface that is not part of any bridge group, and that allows only management traffic to the Firepower Threat
Defense device.
If you do not name the BVI in routed mode, then the Firepower Threat Defense device does not route bridge
group traffic. This configuration replicates transparent firewall mode for the bridge group. If you do not need
clustering or EtherChannel or redundant member interfaces, you might consider using routed mode instead.
In routed mode, you can have one or more isolated bridge groups like in transparent mode, but also have
normal routed interfaces as well for a mixed deployment.
purpose of this bridge group is to replace an external switch, you need to configure an access policy so all
bridge group interfaces can freely communicate.
Figure 3: Routed Firewall Network with an Inside Bridge Group and an Outside Routed Interface
BPDU Handling
To prevent loops using the Spanning Tree Protocol, BPDUs are passed by default.
1 When the inside host at 10.1.1.75 sends a packet to a web server, the real source address of the packet,
10.1.1.75, is changed to a mapped address, 209.165.201.15.
2 When the server responds, it sends the response to the mapped address, 209.165.201.15, and the
Firepower Threat Defense device receives the packet because the upstream router includes this
mapped network in a static route directed to the Firepower Threat Defense device management IP
address.
3 The Firepower Threat Defense device then undoes the translation of the mapped address,
209.165.201.15, back to the real address, 10.1.1.1.75. Because the real address is directly-connected,
the Firepower Threat Defense device sends it directly to the host.
4 For host 192.168.1.2, the same process occurs, except for returning traffic, the Firepower Threat
Defense device looks up the route in its routing table and sends the packet to the downstream router
at 10.1.1.3 based on the Firepower Threat Defense device static route for 192.168.1.0/24.
• Voice over IP (VoIP) and DNS traffic, and the endpoint is at least one hop away from the Firepower
Threat Defense device—For example, if you have the CCM on one bridge group member interface, and
a router and then an H.323 gateway on a different bridge group member interface, then you need to add
a static route on the Firepower Threat Defense device for the router that is the H.323 gateway for
successful call completion. If you enable NAT for the inspected traffic, a static route is required to
determine the egress interface for the real host address that is embedded in the packet. Affected
applications include:
◦DNS
◦H.323
◦RTSP
◦SIP
◦Skinny (SCCP)
◦SunRPC
◦TFTP
Feature Description
Dynamic DNS —
DHCP relay The transparent firewall can act as a DHCPv4 server, but it does not
support DHCP relay. DHCP relay is not required because you can allow
DHCP traffic to pass through using two access rules: one that allows
DCHP requests from the inside interface to the outside, and one that allows
the replies from the server in the other direction.
Dynamic routing protocols You can, however, add static routes for traffic originating on the Firepower
Threat Defense device for bridge group member interfaces. You can also
allow dynamic routing protocols through the Firepower Threat Defense
device using an access rule.
Multicast IP routing You can allow multicast traffic through the Firepower Threat Defense
device by allowing it in an access rule.
Feature Description
VPN termination for through The transparent firewall supports site-to-site VPN tunnels for management
traffic connections only on bridge group member interfaces. It does not terminate
VPN connections for traffic through the Firepower Threat Defense device.
You can pass VPN traffic through the ASA using an access rule, but it
does not terminate non-management connections.
Feature Description
EtherChannel, redundant Only physical interfaces and subinterfaces are supported as bridge group
member interfaces member interfaces.
Diagnostic interfaces are also not supported.
Dynamic DNS —
DHCP relay The routed firewall can act as a DHCPv4 server, but it does not support
DHCP relay on BVIs or bridge group member interfaces.
Dynamic routing protocols You can, however, add static routes for BVIs. You can also allow dynamic
routing protocols through the Firepower Threat Defense device using an
access rule. Non-bridge group interfaces support dynamic routing.
Multicast IP routing You can allow multicast traffic through the Firepower Threat Defense
device by allowing it in an access rule. Non-bridge group interfaces support
multicast routing.
VPN termination for through You cannot terminate a VPN connection on the BVI. Non-bridge group
traffic interfaces support VPN.
Bridge group member interfaces support site-to-site VPN tunnels for
management connections only. It does not terminate VPN connections
for traffic through the Firepower Threat Defense device. You can pass
VPN traffic through the bridge group using an access rule, but it does not
terminate non-management connections.
Default Settings
Bridge Group Defaults
By default, all ARP packets are passed within the bridge group.
• In routed mode, EtherChannel, redundant interfaces are not supported as bridge group members.
You can set the firewall mode when you perform the initial system setup at the CLI. We recommend setting
the firewall mode during setup because changing the firewall mode erases your configuration to ensure you
do not have incompatible settings. If you need to change the firewall mode later, you must do so from the
CLI.
Procedure
Step 1 Deregister the Firepower Threat Defense device from the Management Center.
You cannot change the mode until you deregister the device.
a) Choose Devices > Device Management.
b) Select the device from the list of managed devices.
c) Delete the device (click the Trash can icon), confirm, and wait for system to remove the device.
Step 2 Access the Firepower Threat Defense device CLI, preferably from the console port.
If you use SSH to the diagnostic interface, then changing the mode erases your interface configuration and
you will be disconnected. You should instead connect to the management interface.
Example:
> configure firewall transparent
This will destroy the current interface configurations, are you sure that you want to
proceed? [y/N] y
The firewall mode was changed successfully.
Management Interface
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 Firepower Management Center. It uses its own IP address and static routing. You
can configure its settings at the CLI using the configure network command. If you change the IP address at
the CLI after you add it to the Firepower Management Center, you can match the IP address in the Firepower
Management Center in the Devices > Device Management > Devices > Management area.
Diagnostic Interface
The Diagnostic logical interface can be configured along with the rest of the data interfaces on the Devices
> Device Management > Interfaces screen. Using the Diagnostic interface is optional (see the routed and
transparent mode deployments for scenarios). The Diagnostic interface only allows management traffic, and
does not allow through traffic. It does not support SSH; you can SSH to data interfaces or to the Management
interface only. The Diagnostic interface is useful for SNMP or syslog monitoring.
To cable the above scenario on the ASA 5506-X, ASA 5508-X, or ASA 5516-X, see the following:
If you configure the Diagnostic IP address, then you need an inside router:
Or you can deploy with an inside router, in which case you can use the Diagnostic interface with an IP address
for additional management access:
• Bridge group interfaces (routed and transparent firewall mode)—You can group together multiple
interfaces on a network, and the Firepower Threat Defense device uses bridging techniques to pass traffic
between the interfaces. Each bridge group includes a Bridge Virtual Interface (BVI) to which you assign
an IP address on the network. In routed mode, the Firepower Threat Defense device routes between
BVIs and regular routed interfaces. In transparent mode, each bridge group is separate and cannot
communicate with each other.
IPS-Only Mode
IPS-only mode interfaces bypass many firewall checks and only support IPS security policy. You might want
to implement IPS-only interfaces if you have a separate firewall protecting these interfaces and do not want
the overhead of firewall functions.
Note The firewall mode only affects regular firewall interfaces, and not IPS-only interfaces such as inline sets
or passive interfaces. IPS-only interfaces can be used in both firewall modes.
Note Inline sets might be familiar to you as "transparent inline sets," but the inline interface
type is unrelated to the transparent firewall mode or the firewall-type interfaces.
• Passive or ERSPAN Passive—Passive interfaces monitor traffic flowing across a network using a switch
SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the
switch. This function provides the system visibility within the network without being in the flow of
network traffic. When configured in a passive deployment, the system cannot take certain actions such
as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally and no traffic received
on these interfaces is retransmitted. Encapsulated remote switched port analyzer (ERSPAN) interfaces
allow you to monitor traffic from source ports distributed over multiple switches, and uses GRE to
encapsulate the traffic. ERSPAN interfaces are only allowed when the device is in routed firewall mode.
Auto-MDI/MDIX Feature
For RJ-45 interfaces, the default auto-negotiation setting also includes the Auto-MDI/MDIX feature.
Auto-MDI/MDIX eliminates the need for crossover cabling by performing an internal crossover when a
straight cable is detected during the auto-negotiation phase. Either the speed or duplex must be set to
auto-negotiate to enable Auto-MDI/MDIX for the interface. If you explicitly set both the speed and duplex
to a fixed value, thus disabling auto-negotiation for both settings, then Auto-MDI/MDIX is also disabled. For
Gigabit Ethernet, when the speed and duplex are set to 1000 and full, then the interface always auto-negotiates;
therefore Auto-MDI/MDIX is always enabled and you cannot disable it.
Procedure
Step 1 For the Firepower Threat Defense appliance, perform the following tasks. For the Firepower Threat Defense
on the FXOS chassis, you configure basic interface settings on the Firepower 9300 chassis supervisor. See
the Firepower 9300 configuration guide for more information.
a) Enable the Physical Interface and Configure Ethernet Settings, on page 567
b) (Optional) (Optional) Configure a Redundant Interface, on page 572
You can configure a redundant interface to increase the Firepower Threat Defense reliability.
c) (Optional) (Optional) Configure an EtherChannel, on page 574
An EtherChannel lets you combine multiple interfaces so you can increase the bandwidth for a single
network, and also provide interface redundancy.
Step 2 (Optional) Configure VLAN Subinterfaces and 802.1Q Trunking, on page 576.
VLAN subinterfaces let you divide a physical, redundant, or EtherChannel interface into multiple logical
interfaces that are tagged with different VLAN IDs.
Step 3 Configure Routed Mode Interfaces, on page 580 or Configure Bridge Group Interfaces, on page 581
Step 4 (Optional) Configure IPv6 Addressing, on page 585
Step 5 (Optional) Perform Advanced Interface Configuration, on page 589.
You can configure manual MAC addresses, the MTU, and other settings for interfaces.
This procedure only covers a small subset of Interface settings. Refrain from setting other parameters at this
point. For example, you cannot name an interface that you want to use as part of an EtherChannel or redundant
interface.
Note For the Firepower Threat Defense on the FXOS chassis, you configure basic interface settings on the
Firepower 9300 chassis. See the Firepower 9300 configuration guide for more information.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose None.
Regular firewall interfaces have the mode set to None. The other modes are for IPS-only interface types.
Step 6 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example,
you cannot select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you
can select. For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for
GigabitEthernet ports, and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on
Firepower 2100 series devices do not support Auto.
Redundant Interfaces
A logical redundant interface consists of a pair of physical interfaces: an active and a standby interface. When
the active interface fails, the standby interface becomes active and starts passing traffic. You can configure a
redundant interface to increase the Firepower Threat Defense device reliability.
You can configure up to 8 redundant interface pairs.
EtherChannels
An 802.3ad EtherChannel is a logical interface (called a port-channel interface) consisting of a bundle of
individual Ethernet links (a channel group) so that you increase the bandwidth for a single network. A port
channel interface is used in the same way as a physical interface when you configure interface-related features.
You can configure up to 48 EtherChannels.
All interfaces in the channel group must be the same type and speed. The first interface added to the channel
group determines the correct type and speed. Note that for interfaces that you can configure to use either the
RJ-45 or SFP connector, you can include both RJ-45 and SFP interfaces in the same EtherChannel.
The EtherChannel aggregates the traffic across all the available active interfaces in the channel. The interface
is selected using a proprietary hash algorithm, based on source or destination MAC addresses, IP addresses,
TCP and UDP port numbers and VLAN numbers.
If you use the Firepower Threat Defense device in an Active/Standby failover deployment, then you need to
create separate EtherChannels on the switches in the VSS/vPC, one for each Firepower Threat Defense device.
On each Firepower Threat Defense device, a single EtherChannel connects to both switches. Even if you
could group all switch interfaces into a single EtherChannel connecting to both Firepower Threat Defense
device (in this case, the EtherChannel will not be established because of the separate Firepower Threat Defense
device system IDs), a single EtherChannel would not be desirable because you do not want traffic sent to the
standby Firepower Threat Defense device.
LACP coordinates the automatic addition and deletion of links to the EtherChannel without user intervention.
It also handles misconfigurations and checks that both ends of member interfaces are connected to the correct
channel group. “On” mode cannot use standby interfaces in the channel group when an interface goes down,
and the connectivity and configurations are not checked.
Load Balancing
The Firepower Threat Defense device distributes packets to the interfaces in the EtherChannel by hashing the
source and destination IP address of the packet (this criteria is configurable). The resulting hash is divided by
the number of active links in a modulo operation where the resulting remainder determines which interface
owns the flow. All packets with a hash_value mod active_links result of 0 go to the first interface in the
EtherChannel, packets with a result of 1 go to the second interface, packets with a result of 2 go to the third
interface, and so on. For example, if you have 15 active links, then the modulo operation provides values from
0 to 14. For 6 active links, the values are 0 to 5, and so on.
If an active interface goes down and is not replaced by a standby interface, then traffic is rebalanced between
the remaining links. The failure is masked from both Spanning Tree at Layer 2 and the routing table at Layer
3, so the switchover is transparent to other network devices.
All interfaces that are part of the channel group share the same MAC address. This feature makes the
EtherChannel transparent to network applications and users, because they only see the one logical connection;
they have no knowledge of the individual links.
The port-channel interface uses the lowest numbered channel group interface MAC address as the port-channel
MAC address. Alternatively you can manually configure a MAC address for the port-channel interface. We
recommend manually configuring a unique MAC address in case the group channel interface membership
changes. If you remove the interface that was providing the port-channel MAC address, then the port-channel
MAC address changes to the next lowest numbered interface, thus causing traffic disruption.
Bridge Group
In routed mode, EtherChannels and redundant interfaces are not support as bridge group members.
High Availability
• When you use a redundant or EtherChannel interface as a High Availability link, it must be pre-configured
on both units in the High Availability pair; you cannot configure it on the primary unit and expect it to
replicate to the secondary unit because the High Availability link itself is required for replication.
• If you use a redundant or EtherChannel interface for the state link, no special configuration is required;
the configuration can replicate from the primary unit as normal.
• You can monitor redundant or EtherChannel interfaces for High Availability. When an active member
interface fails over to a standby interface, this activity does not cause the redundant or EtherChannel
interface to appear to be failed when being monitored for device-level High Availability. Only when all
physical interfaces fail does the redundant or EtherChannel interface appear to be failed (for an
EtherChannel interface, the number of member interfaces allowed to fail is configurable).
• If you use an EtherChannel interface for a High Availability or state link, then to prevent out-of-order
packets, only one interface in the EtherChannel is used. If that interface fails, then the next interface in
the EtherChannel is used. You cannot alter the EtherChannel configuration while it is in use as a High
Availability link. To alter the configuration, you need to either shut down the EtherChannel while you
make changes, or temporarily disable High Availability; either action prevents High Availability from
occurring for the duration.
Model Support
• EtherChannels are supported on Firepower Threat Defense device appliances only; they are not supported
on the Firepower Threat Defense Virtual.
• For the Firepower 9300 chassis, you configure EtherChannels in FXOS, not in the Firepower Threat
Defense device OS.
• Redundant interfaces are not supported on the Firepower 9300 chassis.
Redundant Interfaces
• You can configure up to 8 redundant interface pairs.
• All Firepower Threat Defense device configuration refers to the logical redundant interface instead of
the member physical interfaces.
• You cannot use a redundant interface as part of an EtherChannel, nor can you use an EtherChannel as
part of a redundant interface. You cannot use the same physical interfaces in a redundant interface and
an EtherChannel interface. You can, however, configure both types on the Firepower Threat Defense
device if they do not use the same physical interfaces.
• If you shut down the active interface, then the standby interface becomes active.
• Redundant interfaces do not support Diagnostic slot/port interfaces as members. You can, however, set
a redundant interface comprised of non-Diagnostic interfaces as management-only.
EtherChannels
• EtherChannels are supported on Firepower Threat Defense device appliances only; they are not supported
on the Firepower Threat Defense Virtual.
• You can configure up to 48 EtherChannels.
• Each channel group can have up to 16 active interfaces. For switches that support only 8 active interfaces,
you can assign up to 16 interfaces to a channel group: while only eight interfaces can be active, the
remaining interfaces can act as standby links in case of interface failure.
• All interfaces in the channel group must be the same type and speed. The first interface added to the
channel group determines the correct type and speed. Note that for interfaces that you can configure to
use either the RJ-45 or SFP connector, you can include both RJ-45 and SFP interfaces in the same
EtherChannel.
• The device to which you connect the Firepower Threat Defense device EtherChannel must also support
802.3ad EtherChannels; for example, you can connect to the Catalyst 6500 switch or Cisco Nexus 7000
switch.
• The Firepower Threat Defense device does not support LACPDUs that are VLAN-tagged. If you enable
native VLAN tagging on the neighboring switch using the Cisco IOS vlan dot1Q tag native command,
then the Firepower Threat Defense device will drop the tagged LACPDUs. Be sure to disable native
VLAN tagging on the neighboring switch.
• In Catalyst 3750-X Cisco IOS software versions earlier than 15.1(1)S2, the Firepower Threat Defense
device did not support connecting an EtherChannel to a switch stack. With default switch settings, if
the Firepower Threat Defense device EtherChannel is connected cross stack, and if the master switch
is powered down, then the EtherChannel connected to the remaining switch will not come up. To improve
compatibility, set the stack-mac persistent timer command to a large enough value to account for
reload time; for example, 8 minutes or 0 for indefinite. Or, you can upgrade to more a more stable switch
software version, such as 15.1(1)S2.
• All Firepower Threat Defense device configuration refers to the logical EtherChannel interface instead
of the member physical interfaces.
• You cannot use a redundant interface as part of an EtherChannel, nor can you use an EtherChannel as
part of a redundant interface. You cannot use the same physical interfaces in a redundant interface and
an EtherChannel interface. You can, however, configure both types on the Firepower Threat Defense
device if they do not use the same physical interfaces.
redundant interface to increase the Firepower Threat Defense reliability. By default, redundant interfaces are
enabled.
Note For the Firepower Threat Defense on the FXOS chassis, redundant interfaces are not supported.
Caution If you are using a physical interface already in your configuration, removing the name will clear any
configuration that refers to the interface.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings,
on page 567.
Step 3 Click Add Interfaces > Redundant Interface.
Step 4 On the General tab, set the following parameters:
a) Redundant ID—Set an integer between 1 and 8.
b) Primary Interface—Choose an interface from the drop-down list. After you add the interface, any
configuration for it (such as an IP address) is removed.
c) Secondary Interface—The second interface must be the same physical type as the first interface.
Step 5 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.
Step 7 (Optional) Add a VLAN subinterface. See Configure VLAN Subinterfaces and 802.1Q Trunking, on page
576.
Step 8 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 580 or Configure Bridge Group Interfaces, on page 581.
Configure an EtherChannel
This section describes how to create an EtherChannel port-channel interface, assign interfaces to the
EtherChannel, and customize the EtherChannel.
Note For the Firepower Threat Defense on the FXOS chassis, you configure EtherChannels on the Firepower
9300 chassis supervisor. See the Firepower 9300 configuration guide for more information.
Note If you are using a physical interface already in your configuration, removing the name will clear any
configuration that refers to the interface.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings,
on page 567.
Step 3 Click Add Interfaces > Ether Channel Interface.
Step 4 On the General tab, set the Ether Channel ID to a number between 1 and 48.
Step 5 In the Available Interfaces area, click an interface and then click Add to move it to the Selected Interfaces
area. Repeat for all interfaces that you want to make members.
Make sure all interfaces are the same type and speed. The first interface you add determines the type and
speed of the EtherChannel. Any non-matching interfaces you add will be put into a suspended state. The
Management Center does not prevent you from adding non-matching interfaces.
Step 6 (Optional) Click the Advanced tab to customize the EtherChannel. Set the following parameters on the
Information sub-tab:
• Load Balancing—Select the criteria used to load balance the packets across the group channel interfaces.
By default, the Firepower Threat Defense device balances the packet load on interfaces according to the
source and destination IP address of the packet. If you want to change the properties on which the packet
is categorized, choose a different set of criteria. For example, if your traffic is biased heavily towards
the same source and destination IP addresses, then the traffic assignment to interfaces in the EtherChannel
will be unbalanced. Changing to a different algorithm can result in more evenly distributed traffic. For
more information about load balancing, see Load Balancing, on page 570.
• LACP Mode—Choose Active, Passive, or On. We recommend using Active mode (the default).
• Active Physical Interface: Range—From the left drop-down list, choose the minimum number of
active interfaces required for the EtherChannel to be active, between 1 and 16. The default is 1. From
the right drop-down list, choose the maximum number of active interfaces allowed in the EtherChannel,
between 1 and 16. The default is 8. If your switch does not support 16 active interfaces, be sure to set
this command to 8 or fewer.
• Active Mac Address—Set a manual MAC address if desired. The mac_address is in H.H.H format,
where H is a 16-bit hexadecimal digit. For example, the MAC address 00-0C-F1-42-4C-DE is entered
as 000C.F142.4CDE.
Step 7 (Optional) Click the Hardware Configuration tab and set the Duplex and Speed to override these settings
for all member interfaces. This method provides a shortcut to set these parameters because these parameters
must match for all interfaces in the channel group.
Step 8 Click OK.
Step 9 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.
Step 10 (Optional) Add a VLAN subinterface. See Configure VLAN Subinterfaces and 802.1Q Trunking, on page
576.
Step 11 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 580 or Configure Bridge Group Interfaces, on page 581.
VLAN subinterfaces let you divide a physical, redundant, or EtherChannel interface into multiple logical
interfaces that are tagged with different VLAN IDs. An interface with one or more VLAN subinterfaces is
automatically configured as an 802.1Q trunk. Because VLANs allow you to keep traffic separate on a given
physical interface, you can increase the number of interfaces available to your network without adding
additional physical interfaces or devices.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click Add Interfaces > Sub Interface.
Step 3 On the General tab, set the following parameters:
a) Interface—Choose the physical, redundant, or port-channel interface to which you want to add the
subinterface.
b) Sub-Interface ID—Enter the subinterface ID as an integer between 1 and 4294967295. The number of
subinterfaces allowed depends on your platform. You cannot change the ID after you set it.
c) VLAN ID—Enter the VLAN ID between 1 and 4094 that will be used to tag the packets on this subinterface.
Step 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.
Step 6 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 580 or Configure Bridge Group Interfaces, on page 581.
Bridge Groups
A bridge group is a group of interfaces that the Firepower Threat Defense device bridges instead of routes.
Bridge groups are supported in both transparent and routed firewall mode. For more information about bridge
groups, see About Bridge Groups, on page 551.
IPv6
This section includes information about how to configure IPv6.
IPv6 Addressing
You can configure two types of unicast addresses for IPv6:
• Global—The global address is a public address that you can use on the public network. For a bridge
group, this address needs to be configured for the BVI, and not per member interface. You can also
configure a global IPv6 address for the management interface in transparent mode.
• Link-local—The link-local address is a private address that you can only use on the directly-connected
network. Routers do not forward packets using link-local addresses; they are only for communication
on a particular physical network segment. They can be used for address configuration or for the Neighbor
Discovery functions such as address resolution. In a bridge group, only member interfaces have link-local
addresses; the BVI does not have a link-local address.
At a minimum, you need to configure a link-local address for IPv6 to operate. If you configure a global address,
a link-local address is automatically configured on the interface, so you do not also need to specifically
configure a link-local address. For bridge group member interfaces, when you configure the global address
on the BVI, the Firepower Threat Defense device automatically generates link-local addresses for member
interfaces. If you do not configure a global address, then you need to configure the link-local address, either
automatically or manually.
When this feature is enabled on an interface, the source addresses of IPv6 packets received on that interface
are verified against the source MAC addresses to ensure that the interface identifiers use the Modified EUI-64
format. If the IPv6 packets do not use the Modified EUI-64 format for the interface identifier, the packets are
dropped and the following system log message is generated:
The address format verification is only performed when a flow is created. Packets from an existing flow are
not checked. Additionally, the address verification can only be performed for hosts on the local link.
If the duplicate address is the link-local address of the interface, the processing of IPv6 packets is disabled
on the interface. If the duplicate address is a global address, the address is not used.
The Firepower Threat Defense device uses neighbor solicitation messages to perform Duplicate Address
Detection. By default, the number of times an interface performs Duplicate Address Detection is 1.
The Firepower Threat Defense device can participate in router advertisements so that neighboring devices
can dynamically learn a default router address. Router advertisement messages (ICMPv6 Type 134) are
periodically sent out each IPv6 configured interface of the Firepower Threat Defense device.
Router advertisements are also sent in response to router solicitation messages (ICMPv6 Type 133). Router
solicitation messages are sent by hosts at system startup so that the host can immediately autoconfigure without
needing to wait for the next scheduled router advertisement message.
High Availability
• Do not configure High Availability link interfaces with the procedures in this chapter. See the High
Availability chapter for more information.
• When you use High Availability, you must set the IP address and standby address for data interfaces
manually; DHCP and PPPoE are not supported.
IPv6
• IPv6 is supported on all interfaces.
• You can only configure IPv6 addresses manually in transparent mode.
• The Firepower Threat Defense device does not support IPv6 anycast addresses.
Model Support
• For the Firepower 2100 series, bridge groups are not supported in routed mode.
• For the Firepower Threat Defense Virtual, bridge groups are not supported in routed mode.
This procedure describes how to set the name, security zone, and IPv4 address.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
The routed interface is a Routed-type interface, and can only belong to Routed-type zones.
Step 5 Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down list.
• Use Static IP—Enter the IP address and subnet mask.
• Use DHCP—Configure the following optional parameters:
◦Obtain default route using DHCP—Obtains the default route from the DHCP server.
◦DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255.
The default administrative distance for the learned routes is 1.
• Use PPPoE—If the interface is connected to a DSL, cable modem, or other connection to your ISP, and
your ISP uses PPPoE to provide your IP address, configure the following parameters:
◦VPDN Group Name—Specify a group name of your choice to represent this connection.
◦PPPoE User Name—Specify the username provided by your ISP.
◦PPPoE Password/Confirm Password—Specify and confirm the password provided by your ISP.
◦PPP Authentication—Choose PAP, CHAP, or MSCHAP.
PAP passes a cleartext username and password during authentication and is not secure. With CHAP,
the client returns the encrypted [challenge plus password], with a cleartext username in response
to the server challenge. CHAP is more secure than PAP, but it does not encrypt data. MSCHAP
is similar to CHAP but is more secure because the server stores and compares only encrypted
passwords rather than cleartext passwords as in CHAP. MSCHAP also generates a key for data
encryption by MPPE.
◦PPPoE route metric—Assign an administrative distance to the learned route. Valid values are
from 1 to 255. By default, the administrative distance for the learned routes is 1.
◦Enable Route Settings—To manually configure the PPPoE IP address, check this box and then
enter the IP Address.
◦Store Username and Password in Flash—Stores the username and password in flash memory.
The Firepower Threat Defense device stores the username and password in a special location of
NVRAM.
Step 6 (Optional) See Configure IPv6 Addressing, on page 585 to configure IPv6 addressing.
Step 7 Click OK.
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.
This procedure describes how to set the name and security zone for each bridge group member interface.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
The bridge group member interface is a Switched-type interface, and can only belong to Switched-type zones.
Do not configure any IP address settings for this interface. You will set the IP address for the Bridge Virtual
Interface (BVI) only. Note that the BVI does not belong to a zone, and you cannot apply access control policies
to the BVI.
management address is recommended for full functionality, including remote management and other
management operations.
For routed mode, if you provide a name for the BVI, then the BVI participates in routing. Without a name,
the bridge group remains isolated as in transparent firewall mode.
Note For a separate Diagnostic interface, a non-configurable bridge group (ID 301) is automatically added to
your configuration. This bridge group is not included in the bridge group limit.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Choose Add Interfaces > Bridge Group Interface.
Step 3 (Routed Mode) In the Name field, enter a name up to 48 characters in length.
You must name the BVI if you want to route traffic outside the bridge group members, for example, to the
outside interface or to members of other bridge groups. The name is not case-sensitive.
Step 4 In the Bridge Group ID field, enter the bridge group ID between 1 and 250.
Step 5 In the Description field, enter a description for this bridge group.
Step 6 On the Interfaces tab, click an interface and then click Add to move it to the Selected Interfaces area. Repeat
for all interfaces that you want to make members of the bridge group.
Step 7 (Transparent Mode) Click the IPv4 tab. In the IP Address field, enter the IPv4 address and subnet mask.
Do not assign a host address (/32 or 255.255.255.255) to the BVI. Also, do not use other subnets that contain
fewer than 3 host addresses (one each for the upstream router, downstream router, and transparent firewall)
such as a /30 subnet (255.255.255.252). The Firepower Threat Defense device drops all ARP packets to or
from the first and last addresses in a subnet. For example, if you use a /30 subnet and assign a reserved address
from that subnet to the upstream router, then the Firepower Threat Defense device drops the ARP request
from the downstream router to the upstream router.
Step 8 (Routed Mode) Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type
drop-down list.
• Use Static IP—Enter the IP address and subnet mask.
• Use DHCP—Configure the following optional parameters:
◦Obtain default route using DHCP—Obtains the default route from the DHCP server.
◦DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255.
The default administrative distance for the learned routes is 1.
Step 9 (Optional) See Configure IPv6 Addressing, on page 585 to configure IPv6 addressing.
Step 10 Click OK.
Step 11 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.
In transparent firewall mode, all interfaces must belong to a bridge group. The only exception is the Diagnostic
slot/port interface. For the Firepower 9300 chassis, the diagnostic interface ID depends on the mgmt-type
interface that you assigned to the Firepower Threat Defense logical device. You cannot use any other interface
types as diagnostic interfaces. You can configure one diagnostic interface in single mode or per context.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the Diagnostic interface.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down list.
• Use Static IP—Enter the IP address and subnet mask.
• Use DHCP—Configure the following optional parameters:
◦Obtain default route using DHCP—Obtains the default route from the DHCP server.
◦DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255.
The default administrative distance for the learned routes is 1.
Step 5 (Optional) See Configure IPv6 Addressing, on page 585 to configure IPv6 addressing.
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.
To configure a global IPv6 address for any routed mode interface and for the transparent or routed mode BVI,
perform the following steps.
Note Configuring the global address automatically configures the link-local address, so you do not need to
configure it separately. For bridge groups, configuring the global address on the BVI automatically
configures link-local addresses on all member interfaces.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the IPv6 tab.
For routed mode, the Basic tab is selected by default. For transparent mode, the Address tab is selected by
default.
Step 4 Configure the global IPv6 address using one of the following methods.
• (Routed interface) Stateless autoconfiguration—Check the Autoconfiguration check box.
Enabling stateless autconfiguration on the interface configures IPv6 addresses based upon prefixes
received in Router Advertisement messages. A link-local address, based on the Modified EUI-64 interface
ID, is automatically generated for the interface when stateless autoconfiguration is enabled.
Although RFC 4862 specifies that hosts configured for stateless autoconfiguration do not send Router
Advertisement messages, the Firepower Threat Defense device does send Router Advertisement messages
in this case. Uncheck the IPv6 > Settings > Enable RA check box to suppress messages.
• Manual configuration—To manually configure a global IPv6 address:
1 Click the Address tab, and click Add Address.
The Add Address dialog box appears.
2 In the Address field, enter either a full global IPv6 address, including the interface ID, or enter the
IPv6 prefix, along with the IPv6 prefix length. (Routed Mode) If you only enter the prefix, then be
sure to check the Enforce EUI 64 check box to generate the interface ID using the Modified EUI-64
format. For example, 2001:0DB8::BA98:0:3210/48 (full address) or 2001:0DB8::/48 (prefix, with
EUI 64 checked).
Step 5 For Routed interfaces, you can optionally set the following values on the Basic tab:
• To automatically configure the link-local address when you do not configure the global address, check
the Enable IPv6 check box.
If you do not want to configure a global address, and only need to configure a link-local address, you
have the option of generating the link-local addresses based on the interface MAC addresses (Modified
EUI-64 format. Because MAC addresses use 48 bits, additional bits must be inserted to fill the 64 bits
required for the interface ID.)
• To enforce the use of Modified EUI-64 format interface identifiers in IPv6 addresses on a local link,
check the Enforce EUI-64 check box.
• To manually set the link-local address, enter an address in the Link-Local address field.
A link-local address should start with FE8, FE9, FEA, or FEB, for example fe80::20d:88ff:feee:6a82.
If you do not want to configure a global address, and only need to configure a link-local address, you
have the option of manually defining the link-local address. Note that we recommend automatically
assigning the link-local address based on the Modified EUI-64 format. For example, if other devices
enforce the use of the Modified EUI-64 format, then a manually-assigned link-local address may cause
packets to be dropped.
• Check the Enable DHCP for address config check box to set the Managed Address Config flag in the
IPv6 router advertisement packet.
This flag in IPv6 router advertisements informs IPv6 autoconfiguration clients that they should use
DHCPv6 to obtain addresses, in addition to the derived stateless autoconfiguration address.
• Check the Enable DHCP for non-address config check box to set the Other Address Config flag in
the IPv6 router advertisement packet.
This flag in IPv6 router advertisements informs IPv6 autoconfiguration clients that they should use
DHCPv6 to obtain additional information from DHCPv6, such as the DNS server address.
Step 6 For Routed interfaces, see Configure IPv6 Neighbor Discovery (Routed Mode Only), on page 587 to configure
settings on the Prefixes and Settings tabs. For BVI interfaces, see the following parameters on the Settings
tab:
• DAD attempts—The maximum number of DAD attempts, between 1 and 600. Set the value to 0 to
disable duplicate address detection (DAD) processing. This setting configures the number of consecutive
neighbor solicitation messages that are sent on an interface while DAD is performed on IPv6 addresses.
1 attempt is the default.
• NS Interval—The interval between IPv6 neighbor solicitation retransmissions on an interface, between
1000 and 3600000 ms. The default value is 1000 ms.
• Reachable Time—The amount of time that a remote IPv6 node is considered reachable after a reachability
confirmation event has occurred, between 0 and 3600000 ms. The default value is 0 ms. When 0 is used
for the value, the reachable time is sent as undetermined. It is up to the receiving devices to set and track
the reachable time value. The neighbor reachable time enables detecting unavailable neighbors. Shorter
configured times enable detecting unavailable neighbors more quickly, however, shorter times consume
more IPv6 network bandwidth and processing resources in all IPv6 network devices. Very short configured
times are not recommended in normal IPv6 operation.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the IPv6 tab, and then the Prefixes tab.
Step 4 (Optional) To configure which IPv6 prefixes are included in IPv6 router advertisements, perform the following
steps:
a) Click Add Prefix.
b) In the Address field, enter the IPv6 address with the prefix length or check the Default check box to use
the default prefix.
c) (Optional) Uncheck the Advertisement check box to indicate that the IPv6 prefix is not advertised.
d) Check the Off Link check box to indicate that the specified prefix is assigned to the link. Nodes sending
traffic to addresses that contain the specified prefix consider the destination to be locally reachable on the
link. This prefix should not be used for on-link determination.
e) To use the specified prefix for autoconfiguration, check the Autoconfiguration check box.
f) For the Prefix Lifetime, click Duration or Expiration Date.
• Duration—Enter a Preferred Lifetime for the prefix in seconds. This setting is the amount of time
that the specified IPv6 prefix is advertised as being valid. The maximum value represents infinity.
Valid values are from 0 to 4294967295. The default is 2592000 (30 days). Enter a Valid Lifetime
for the prefix in seconds. This setting is the amount of time that the specified IPv6 prefix is advertised
as being preferred. The maximum value represents infinity. Valid values are from 0 to 4294967295.
The default setting is 604800 (seven days). Alternatively, check the Infinite checkbox to set an
unlimited duration.
• Expiration Date—Choose a Valid and Preferred date and time.
g) Click OK.
Step 5 Click the Settings tab.
Step 6 (Optional) Set the maximum number of DAD attempts, between 1 and 600. 1 attempt is the default. Set the
value to 0 to disable duplicate address detection (DAD) processing.
This setting configures the number of consecutive neighbor solicitation messages that are sent on an interface
while DAD is performed on IPv6 addresses.
Step 7 (Optional) Configure the interval between IPv6 neighbor solicitation retransmissions in the NS Interval field,
between 1000 and 3600000 ms.
The default value is 1000 ms.
Step 8 (Optional) Configure the amount of time that a remote IPv6 node is considered reachable after a reachability
confirmation event has occurred in the Reachable Time field, between 0 and 3600000 ms.
The default value is 0 ms. When 0 is used for the value, the reachable time is sent as undetermined. It is up
to the receiving devices to set and track the reachable time value.
The neighbor reachable time enables detecting unavailable neighbors. Shorter configured times enable detecting
unavailable neighbors more quickly, however, shorter times consume more IPv6 network bandwidth and
processing resources in all IPv6 network devices. Very short configured times are not recommended in normal
IPv6 operation.
Step 9 (Optional) To suppress the router advertisement transmissions, uncheck the Enable RA check box. If you
enable router advertisement transmissions, you can set the RA lifetime and interval.
Router advertisement messages are automatically sent in response to router solicitation messages. You may
want to disable these messages on any interface for which you do not want the Firepower Threat Defense
device to supply the IPv6 prefix (for example, the outside interface).
• RA Lifetime—Configure the router lifetime value in IPv6 router advertisements, between 0 and 9000
seconds.
The default is 1800 seconds.
• RA Interval—Configure the interval between IPv6 router advertisement transmissions, between 3 and
1800 seconds.
The default is 200 seconds.
You might want to assign unique MAC addresses to subinterfaces. For example, your service provider might
perform access control based on the MAC address.
Default MTU
The default MTU on the Firepower Threat Defense device is 1500 bytes. This value does not include the
18-22 bytes for the Ethernet header, VLAN tagging, or other overhead.
Note The Firepower Threat Defense device can receive frames larger than the configured MTU as long as there
is room in memory.
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 Firepower Threat Defense 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 Firepower
Threat Defense device drops the packet.
• If the ARP packet does not match any entries in the static ARP table, then you can set the Firepower
Threat Defense device to either forward the packet out all interfaces (flood), or to drop the packet.
Note The dedicated Diagnostic interface never floods packets even if this parameter is set to
flood.
Default Settings
• If you enable ARP inspection, the default setting is to flood non-matching packets.
• The default timeout value for dynamic MAC address table entries is 5 minutes.
• By default, each interface automatically learns the MAC addresses of entering traffic, and the Firepower
Threat Defense device adds corresponding entries to the MAC address table.
Customize the MTU on the interface, for example, to allow jumbo frames.
Caution Changing the highest MTU value on the device for a non-management/diagnostic interface restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection
is interrupted on all non-management/diagnostic interfaces, not just the interface you modified. Whether
this interruption drops traffic or passes it without further inspection depends on the model of the managed
device and the interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Note You do not need to reboot Firepower 2100 series devices, where jumbo frame support
is always enabled.
• If you use an interface in an inline set, the MTU setting is not used. However, the jumbo frame setting
is relevant to inline sets; jumbo frames enable the inline interfaces to receive packets up to 9000 bytes.
To enable jumbo frames, you must set the MTU of any interface above 1500 bytes.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 On the General tab, set the MTU between 64 and 9198 bytes; the maximum is 9000 for the Firepower Threat
Defense Virtual and 9184 for the Firepower Threat Defense on the Firepower 9300 chassis.
The default is 1500 bytes.
Step 6 If you set the MTU above 1500 bytes, reload the system to enable jumbo frames.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab.
The Information tab is selected.
Step 4 In the Active MAC Address field, enter a MAC address in H.H.H format, where H is a 16-bit hexadecimal
digit.
For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE.
Note The Standby MAC Address and DNS Lookup are not used at this
time.
Step 5 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.
By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP
packets by enabling ARP inspection (see Configure ARP Inspection, on page 955). ARP inspection compares
ARP packets with static ARP entries in the ARP table.
For routed interfaces, you can enter static ARP entries, but normally dynamic entries are sufficient. For routed
interfaces, the ARP table is used to deliver packets to directly-connected hosts. Although senders identify a
packet destination by an IP address, the actual delivery of the packet on Ethernet relies on the Ethernet MAC
address. When a router or host wants to deliver a packet on a directly connected network, it sends an ARP
request asking for the MAC address associated with the IP address, and then delivers the packet to the MAC
address according to the ARP response. The host or router keeps an ARP table so it does not have to send
ARP requests for every packet it needs to deliver. The ARP table is dynamically updated whenever ARP
responses are sent on the network, and if an entry is not used for a period of time, it times out. If an entry is
incorrect (for example, the MAC address changes for a given IP address), the entry needs to time out before
it can be updated with the new information.
For transparent mode, the Firepower Threat Defense only uses dynamic ARP entries in the ARP table for
traffic to and from the Firepower Threat Defense device, such as management traffic.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP tab (called ARP and MAC for transparent mode).
Step 4 Click Add ARP Config.
The Add ARP Config dialog box appears.
Step 5 In the IP Address field, enter the IP address of the host.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b.
Step 7 To perform proxy ARP for this address, check the Enable Alias check box.
If the Firepower Threat Defense device receives an ARP request for the specified IP address, then it responds
with the specified MAC address.
Step 8 Click OK, and then click OK again to exit the Advanced settings.
Step 9 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.
Add a Static MAC Address and Disable MAC Learning for a Bridge Group
Normally, MAC addresses are added to the MAC address table dynamically as traffic from a particular MAC
address enters an interface. You can disable MAC address learning; however, unless you statically add MAC
addresses to the table, no traffic can pass through the Firepower Threat Defense device. You can also add
static MAC addresses to the MAC address table. One benefit to adding static entries is to guard against MAC
spoofing. If a client with the same MAC address as a static entry attempts to send traffic to an interface that
does not match the static entry, then the Firepower Threat Defense device drops the traffic and generates a
system message. When you add a static ARP entry (see Add a Static ARP Entry, on page 593), a static MAC
address entry is automatically added to the MAC address table.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP and MAC tab.
Step 4 (Optional) Disable MAC learning by unchecking the Enable MAC Learning check box.
Step 5 To add a static MAC address, click Add MAC Config.
The Add MAC Config dialog box appears.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b. Click OK.
Step 7 Click OK to exit the Advanced settings.
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.
This section describes how to prevent IP spoofing, allow full fragment reassembly, and override the default
fragment setting set for at the device level in Platform Settings .
Anti-Spoofing
This section lets you enable Unicast Reverse Path Forwarding on an interface. Unicast RPF guards against
IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets
have a source IP address that matches the correct source interface according to the routing table.
Normally, the Firepower Threat Defense device only looks at the destination address when determining where
to forward the packet. Unicast RPF instructs the device to also look at the source address; this is why it is
called Reverse Path Forwarding. For any traffic that you want to allow through the Firepower Threat Defense
device, the device routing table must include a route back to the source address. See RFC 2267 for more
information.
For outside traffic, for example, the Firepower Threat Defense device can use the default route to satisfy the
Unicast RPF protection. If traffic enters from an outside interface, and the source address is not known to the
routing table, the device uses the default route to correctly identify the outside interface as the source interface.
If traffic enters the outside interface from an address that is known to the routing table, but is associated with
the inside interface, then the Firepower Threat Defense device drops the packet. Similarly, if traffic enters the
inside interface from an unknown source address, the device drops the packet because the matching route (the
default route) indicates the outside interface.
Unicast RPF is implemented as follows:
• ICMP packets have no session, so each packet is checked.
• UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets
arriving during the session are checked using an existing state maintained as part of the session. Non-initial
packets are checked to ensure they arrived on the same interface used by the initial packet.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the Security Configuration tab.
Step 4 To enable Unicast Reverse Path Forwarding, check the Anti-Spoofing check box.
Step 5 To enable full fragment reassembly, check the Full Fragment Reassembly check box.
Step 6 To change the number of fragments allowed per packet, check the Override Default Fragment Setting check
box, and set the following values:
• Size—Set the maximum number of packets that can be in the IP reassembly database waiting for
reassembly. The default is 200. Set this value to 1 to disable fragments.
• Chain—Set the maximum number of packets into which a full IP packet can be fragmented. The default
is 24 packets.
• Timeout—Set the maximum number of seconds to wait for an entire fragmented packet to arrive. The
timer starts after the first fragment of a packet arrives. If all fragments of the packet do not arrive by the
number of seconds specified, all fragments of the packet that were already received will be discarded.
The default is 5 seconds.
for example, copper port auto-negotiation; behavior of the optical link partner such as how it handles link
faults and de-bounce timing; spanning tree protocol convergence; dynamic routing protocol convergence; and
so on. During this time, you may experience dropped connections.
You may also experience dropped connections due to application identification errors when analyzing
connections midstream after the return to normal operations.
The supported Hardware Bypass network modules for these models include:
• Firepower 6-port 1G SX FTW Network Module single-wide (FPR-NM-6X1SX-F)
• Firepower 6-port 10G SR FTW Network Module single-wide (FPR-NM-6X10SR-F)
• Firepower 6-port 10G LR FTW Network Module single-wide (FPR-NM-6X10LR-F)
• Firepower 2-port 40G SR FTW Network Module single-wide (FPR-NM-2X40G-F)
• Firepower 8-port 1G Copper FTW Network Module single-wide (FPR-NM-8X1G-F)
General Guidelines
• IPS-only interfaces support physical interfaces only, and cannot be EtherChannels, redundant interfaces,
VLANs, and so on. The exception is for EtherChannels configured on the Firepower 9300 chassis, which
are supported.
• IPS-only interfaces are supported in intra-chassis and inter-chassis clustering.
Note For the Firepower Threat Defense on the FXOS chassis, you configure basic interface settings on the
Firepower 9300 chassis. See the Firepower 9300 configuration guide for more information.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose Passive or Erspan.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 In the Name field, enter a name up to 48 characters in length.
Step 6 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
Step 7 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.
Step 8 (Optional) On the General tab, set the MTU between 64 and 9198 bytes; for the Firepower Threat Defense
Virtual and Firepower Threat Defense on the FXOS chassis, the maximum is 9000 bytes.
The default is 1500 bytes.
Step 10 For ERSPAN interfaces, set the IPv4 address and mask on the IPv4 tab.
Step 11 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
The exact speed and duplex options depend on your hardware.
• Duplex—Choose Full, Half, or Auto. Auto is the default.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default.
This section enables and names two physical interfaces that you can add to an inline set. You can also optionally
enable Hardware Bypass for supported interface pairs.
Note For the Firepower Threat Defense on the FXOS chassis, you configure basic interface settings on the
Firepower 9300 chassis. See the Firepower 9300 configuration guide for more information.
Procedure
Step 1 Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose None.
After you add this interface to an inline set, this field will show Inline for the mode.
Step 7 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
The exact speed and duplex options depend on your hardware.
• Duplex—Choose Full, Half, or Auto. Auto is the default.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default.
Step 9 Click the edit icon ( ) for the second interface you want to add to the inline set.
Step 10 Configure the settings as for the first interface.
Step 11 Click the Inline Sets tab.
Step 12 Click Add Inline Set.
The Add Inline Set dialog box appears with the General tab selected.
Step 13 In the Name field, enter a name for the set.
Step 14 (Optional) Change the MTU between 64 and 9198 bytes; for the Firepower Threat Defense Virtual and
Firepower Threat Defense on the FXOS chassis, the maximum is 9000 bytes.
The default is 1500 bytes.
Step 15 (Optional) For the Bypass mode, choose one of the following options:
• Disabled—Set Hardware Bypass to disabled for interfaces where Hardware Bypass is supported, or use
interfaces where Hardware Bypass is not supported.
• Standby—Set Hardware Bypass to the standby state on supported interfaces. Only pairs of Hardware
Bypass interfaces are shown. In the standby state, the interfaces remain in normal operation until there
is a trigger event.
• Bypass-Force—Manually forces the interface pair to go into a bypass state. The Inline Sets tab shows
Yes for any interface pairs that are in Bypass-Force mode.
Step 16 In the Available Interfaces Pairs area, click a pair and then click Add to move it to the Selected Interface
Pair area.
All possible pairings between named and enabled interfaces with the mode set to None show in this area.
Step 17 (Optional) Click the Advanced tab to set the following optional parameters:
• Tap Mode—Set to inline tap mode.
Note that you cannot enable this option and strict TCP enforcement on the same inline set.
• Propagate Link State—Configure link state propagation.
Link state propagation automatically brings down the second interface in the inline interface pair when
one of the interfaces in an inline set goes down. When the downed interface comes back up, the second
interface automatically comes back up, also. In other words, if the link state of one interface changes,
the device senses the change and updates the link state of the other interface to match it. Note that devices
require up to 4 seconds to propagate link state changes. Link state propagation is especially useful in
resilient network environments where routers are configured to reroute traffic automatically around
network devices that are in a failure state.
• Strict TCP Enforcement—To maximize TCP security, you can enable strict enforcement, which blocks
connections where the three-way handshake was not completed.
Strict enforcement also blocks:
◦Non-SYN TCP packets for connections where the three-way handshake was not completed
◦Non-SYN/RST packets from the initiator on a TCP connection before the responder sends the
SYN-ACK
◦Non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before
the session is established
◦SYN packets on an established TCP connection from either the initiator or the responder
• Snort Fail Open—Enable or disable either or both of the Busy and Down options if you want new and
existing traffic to pass without inspection (enabled) or drop (disabled) when the Snort process is busy
or down.
By default, traffic passes without inspection when the Snort process is down, and drops when it is busy.
When the Snort process is:
◦Busy—It cannot process traffic fast enough because traffic buffers are full, indicating that there is
more traffic than the device can handle, or because of other software resource issues.
◦Down—It is restarting because you deployed a configuration that requires it to restart. See
Configurations that Restart the Snort Process When Deployed or Activated, on page 294.
When the Snort process is down and comes back up, it inspects new connections. To prevent false
positives and false negatives, it does not inspect existing connections on inline, routed, or transparent
interfaces because initial session information might have been lost while it was down.
Note When Snort fails open, features that rely on the Snort process do not function. These include
application control and deep inspection. The system performs only basic access control using
simple, easily determined transport and network layer characteristics.
Step 20 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
You can only set the zone after you add the interface to the inline set; adding it to an inline set configures the
mode to Inline and lets you choose inline-type security zones.
If you added or changed interfaces on your device, you must manually refresh the interfaces in the Firepower
Management Center. For example, if you add EtherChannels on a Firepower 9300 device, additional interfaces
on the Firepower Threat Defense Virtual, or network interface cards, then you must perform this procedure.
Procedure
What to Do Next
•
DHCP Options
DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. The
configuration parameters are carried in tagged items that are stored in the Options field of the DHCP message
and the data are also called options. Vendor information is also stored in Options, and all of the vendor
information extensions can be used as DHCP options.
For example, Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone
starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request
with option 150 or 66 to the DHCP server to obtain this information.
A single request might include both options 150 and 66. In this case, the ASA DHCP server provides values
for both options in the response if they are already configured on the ASA.
You can use advanced DHCP options to provide DNS, WINS, and domain name parameters to DHCP clients;
DHCP option 15 is used for the DNS domain suffix.You can also use the DHCP automatic configuration
setting to obtain these values or define them manually. When you use more than one method to define this
information, it is passed to DHCP clients in the following sequence:
1 Manually configured settings.
2 Advanced DHCP options settings.
3 DHCP automatic configuration settings.
For example, you can manually define the domain name that you want the DHCP clients to receive and then
enable DHCP automatic configuration. Although DHCP automatic configuration discovers the domain together
with the DNS and WINS servers, the manually defined domain name is passed to DHCP clients with the
discovered DNS and WINS server names, because the domain name discovered by the DHCP automatic
configuration process is superseded by the manually defined domain name.
About DDNS
DDNS update integrates DNS with DHCP. The two protocols are complementary: DHCP centralizes and
automates IP address allocation; DDNS update automatically records the association between assigned
addresses and hostnames at predefined intervals. DDNS allows frequently changing address-hostname
associations to be updated frequently. Mobile hosts, for example, can then move freely on a network without
user or administrator intervention. DDNS provides the necessary dynamic update and synchronization of the
name-to-address mapping and address-to-name mapping on the DNS server.
The DDNS name and address mapping is held on the DHCP server in two resource records (RRs): the A RR
includes the name-to-IP address mapping, while the PTR RR maps addresses to names. Of the two methods
for performing DDNS updates—the IETF standard defined by RFC 2136 and a generic HTTP method—the
Firepower Threat Defense device supports the IETF method.
Note DDNS is not supported on the BVI or bridge group member interfaces.
In general, the DHCP server maintains DNS PTR RRs on behalf of clients. Clients may be configured to
perform all desired DNS updates. The server may be configured to honor these updates or not. The DHCP
server must know the fully qualified domain name (FQDN) of the client to update the PTR RR. The client
provides an FQDN to the server using a DHCP option called Client FQDN.
Firewall Mode
• DHCP Relay is not supported in transparent firewall mode or in routed mode on the BVI or bridge group
member interface.
• DHCP Server is supported in transparent firewall mode on a bridge group member interface. In routed
mode, the DHCP server is supported on the BVI interface, not the bridge group member interface.
• DDNS is not supported in transparent firewall mode or in routed mode on the BVI or bridge group
member interface.
IPv6
Does not support IPv6 for DHCP server; IPv6 for DHCP relay is supported.
DHCPv4 Server
• The maximum available DHCP pool is 256 addresses.
• You can configure only one DHCP server on each interface. Each interface can have its own pool of
addresses to use. However the other DHCP settings, such as DNS servers, domain name, options, ping
timeout, and WINS servers, are configured globally and used by the DHCP server on all interfaces.
• You cannot configure a DHCP client or DHCP relay service on an interface on which the server is
enabled. Additionally, DHCP clients must be directly connected to the interface on which the server is
enabled.
• Firepower Threat Defense device does not support QIP DHCP servers for use with the DHCP proxy
service.
• The relay agent cannot be enabled if the DHCP server is also enabled.
• The DHCP server does not support BOOTP requests.
DHCP Relay
• You can configure a maximum of 10 DHCPv4 relay servers, global and interface-specific servers
combined, with a maximum of 4 servers per interface.
• You can configure a maximum of 10 DHCPv6 relay servers. Interface-specific servers for IPv6 are not
supported.
• The relay agent cannot be enabled if the DHCP server feature is also enabled.
• DHCP relay services are not available in transparent firewall mode. You can, however, allow DHCP
traffic through using an access rule. To allow DHCP requests and replies through the Firepower Threat
Defense device, you need to configure two access rules, one that allows DCHP requests from the inside
interface to the outside (UDP destination port 67), and one that allows the replies from the server in the
other direction (UDP destination port 68).
• For IPv4, clients must be directly-connected to the Firepower Threat Defense device and cannot send
requests through another relay agent or a router. For IPv6, the Firepower Threat Defense device supports
packets from another relay server.
• The DHCP clients must be on different interfaces from the DHCP servers to which the Firepower Threat
Defense device relays requests.
• You cannot enable DHCP Relay on an interface in a traffic zone.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select DHCP > DHCP Server.
Step 3 Configure the following DHCP server options:
• Ping Timeout—The amount of time in milliseconds that Firepower Threat Defense device waits to time
out a DHCP ping attempt. Valid values range from 10 to 10000 milliseconds. The default value is 50
milliseconds.
To avoid address conflicts, the Firepower Threat Defense device sends two ICMP ping packets to an
address before assigning that address to a DHCP client.
• Lease Length—The amount of time in seconds that the client may use its allocated IP address before
the lease expires. Valid values range from 300 to 1048575 seconds. The default value is 3600 seconds
(1 hour).
• (Routed mode) Auto-configuration—Enables DHCP auto configuration on the Firepower Threat
Defense device. Auto-configuration enables the DHCP server to provide the DHCP clients with the
DNS server, domain name, and WINS server information obtained from a DHCP client running on the
specified interface. Otherwise, you can disable auto configuration and add the values yourself in Step
4.
• Interface—The interface on a DHCP client that provides DNS, WINS, an domain name information
for automatic configuration if the Firepower Threat Defense device is acting as a DHCP client on a
specified interface (usually outside). In transparent mode, specify a bridge group member interface. In
routed mode, specify a routed interface or a BVI; do not specify the bridge group member interface.
Step 5 Select the Server tab, click Add, and configure the following options:
• Choose the interface from the drop-down list.
• Address Pool—The range of IP addresses from lowest to highest that is used by the DHCP server. The
range of IP addresses must be on the same subnet as the selected interface and cannot include the IP
address of the interface itself.
• Enable DHCP Server—Enables the DHCP server on the selected interface.
• IP Address 1 and IP Address 2—The IP address(es) to be returned with this option code. To add a new
IP address, see Creating Network Objects, on page 354.
• ASCII—The ASCII value that is returned to the DHCP client. The string cannot include spaces.
• HEX—The HEX value that is returned to the DHCP client. The string must have an even number of
digits and no spaces. You do not need to use a 0x prefix.
You can configure a DHCP relay agent to forward DHCP requests received on an interface to one or more
DHCP servers. DHCP clients use UDP broadcasts to send their initial DHCPDISCOVER messages because
they do not have information about the network to which they are attached. If the client is on a network
segment that does not include a server, UDP broadcasts normally are not forwarded by the Firepower Threat
Defense device because it does not forward broadcast traffic.
You can remedy this situation by configuring the interface of the Firepower Threat Defense device that is
receiving the broadcasts to forward DHCP requests to a DHCP server on another interface.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select DHCP > DHCP Relay.
Step 3 In the Timeout field, enter the amount of time in seconds that the Firepower Threat Defense device waits to
time out the DHCP relay agent. Valid values range from 1 to 3600 seconds. The default value is 60 seconds.
The timeout is for address negotiation through the local DHCP Relay agent.
Step 4 On the DHCP Relay Agent tab, click Add, and configure the following options:
• Interface—The interface connected to the DHCP clients.
• Enable IPv4 Relay—Enables IPv4 DHCP Relay for this interface.
• Set Route—(For IPv4) Changes the default gateway address in the DHCP message from the server to
that of the Firepower Threat Defense device interface that is closest to the DHCP client, which relayed
the original DHCP request. This action allows the client to set its default route to point to the Firepower
Threat Defense device even if the DHCP server specifies a different router. If there is no default router
option in the packet, the Firepower Threat Defense device adds one containing the interface address.
• Enable IPv6 Relay—Enables IPv6 DHCP Relay for this interface.
Configure DDNS
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
Dynamic DNS (DDNS) update integrates DNS with DHCP. DDNS update automatically records the association
between assigned addresses and hostnames, which allows frequently changing address-hostname associations
to be updated efficiently.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select DHCP > DDNS, and configure the following DDNS options:
• DHCP Client Requests DHCP Server to update Records—Configures the DHCP client to request
that it update the specified records. Available options are Not Selected, No Update, Only PTR, and
Both A and PTR Records. See About DDNS, on page 606 for a description of A and PTR records.
• Enable DHCP Client Broadcast—Enables the DHCP client to use a broadcast address to reach the
DHCP server.
• Dynamic DNS Update—Which records to update for the DDNS updates for the DHCP server. Available
options are Not Selected, Only PTR, and Both A and PTR Records .
• Override DHCP Client Requests—Specifies that the DHCP server actions should override any update
actions requested by the DHCP client.
Step 3 On the DHCP Client ID Interface tab, choose the interface from the Available Interfaces list, and then click
Add to move it to the Selected Interfaces list.
Step 4 On the DDNS Interface Settings tab, click Add, and configure the following options:
• Interface—Choose the interface from the drop-down list to add DDNS settings for each configured
interface .
• Method Name—The DDNS update method assigned to the interface.
• Host Name—The host name of the DDNS client.
• DHCP Client requests DHCP server to update requests—Configures the DHCP client to request
that it update the specified records. Available options are Not Selected, No Update, Only PTR, and
Both A and PTR Records. See About DDNS, on page 606 for a description of A and PTR records.
• Dynamic DNS Update—Which records to update for the DDNS updates for the DHCP server. Available
options are Not Selected, Only PTR, and Both A and PTR Records .
• Override DHCP Client Requests—Specifies that the DHCP server actions should override any update
actions requested by the DHCP client.
Introduction to QoS
Quality of Service, or QoS, rate limits (polices) network traffic that is allowed or trusted by access control.
The system does not rate limit traffic that was fastpathed.
QoS is supported for routed interfaces on Firepower Threat Defense devices only.
In a QoS policy, a maximum of 32 QoS rules handle network traffic. The system matches traffic to QoS rules
in the order you specify. The system rate limits traffic according to the first rule where all rule conditions
match the traffic. Traffic that does not match any of the rules is not rate limited.
You must constrain QoS rules by source or destination (routed) interfaces. The system enforces rate limiting
independently on each of those interfaces; you cannot specify an aggregate rate limit for a set of interfaces.
QoS rules can also rate limit traffic by other network characteristics, as well as contextual information such
as application, URL, user identity, and custom Security Group Tags (SGTs).
You can rate limit download and upload traffic independently. The system determines download and upload
directions based on the connection initiator.
Note QoS is not subordinate to a master access control configuration; you configure QoS independently.
However, the access control and QoS policies deployed to the same device share identity configurations;
see Associating Other Policies with Access Control, on page 1228.
To perform policy-based rate limiting, configure and deploy QoS policies to managed devices. Each QoS
policy can target mutiple devices; each device can have one deployed QoS policy at a time.
Only one person should edit a policy at a time, using a single browser window. If multiple users save the same
policy, the last saved changes are retained. For your convenience, the system displays information on who (if
anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30
minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.
Procedure
Step 3 Configure QoS rules; see Configuring QoS Rules, on page 616 and Rule Management: Common Characteristics,
on page 303.
The Rules tab in the QoS policy editor lists each rule in evaluation order, and displays a summary of the rule
conditions and rate limiting configurations. A right-click menu provides rule management options, including
moving, enabling, and disabling.
Helpful in larger deployments, you can Filter by Device to display only the rules that affect a specfic device
or group of devices. You can also search for and within rules; the system matches text you enter in the Search
Rules field to rule names and condition values, including objects and object groups.
Note Properly creating and ordering rules is a complex task, but one that is essential to building an effective
deployment. If you do not plan carefully, rules can preempt other rules, require additional licenses,
or contain invalid configurations. Icons represent comments, warnings, and errors. If issues exist,
click Show Warnings to display a list. For more information, see Rule Performance Guidelines, on
page 337.
Step 4 Click Policy Assignments to identify the managed devices targeted by the policy; see Setting Target Devices
for a QoS Policy, on page 616.
If you identified target devices during policy creation, verify your choices.
Procedure
What to Do Next
• Configure and deploy the QoS policy; see Rate Limiting with QoS Policies, on page 614.
Each QoS policy can target mutiple devices; each device can have one deployed QoS policy at a time.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you create or edit a rule, use the upper portion of the rule editor to configure general rule properties.
Use the tabs on the lower portion to configure rule conditions and comments.
Procedure
For detailed information on rule components, see QoS Rule Components, on page 618.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Rule Performance Guidelines, on page 337
State (Enabled/Disabled)
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.
Conditions
Conditions specify the specific traffic the rule handles. You can configure each rule with multiple conditions.
Traffic must match all conditions to match the rule. Each condition type has its own tab in the rule editor.
You can rate limit traffic using:
• Interface Conditions, on page 307 (routed only; required)
• Network Conditions, on page 309
• Port and ICMP Code Conditions, on page 314
• Application Conditions (Application Control), on page 316
• URL Conditions (URL Filtering), on page 321
• User, Realm, and ISE Attribute Conditions (User Control), on page 327
• Custom SGT Conditions, on page 332
Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall
configuration for the benefit of other users, or note when you change a rule and the reason for the change.
In the policy editor, the system displays how many comments a rule has. In the rule editor, use the Comments
tab to view existing comments and add new ones.
Caution Cisco strongly recommends using FlexConfig policies only if you are an advanced user with a strong
ASA background and at your own risk. You may configure any commands that are not blacklisted. Enabling
features through FlexConfig policies may cause unintended results with other configured features.
You may contact the Cisco Technical Assistance Center for support concerning FlexConfig policies that
you have configured. The Cisco Technical Assistance Center does not design or write custom configurations
on any customer's behalf. Cisco expresses no guarantees for correct operation or interoperability with
other Firepower System features. FlexConfig features may become deprecated at any time. For fully
guaranteed feature support, you must wait for Firepower Management Center support. When in doubt, do
not use FlexConfig policies.
The system includes a set of predefined FlexConfig objects that represent tested configurations. If the feature
you need is not represented by these objects, first determine if you can configure an equivalent feature in
standard policies. For example, the access control policy includes intrusion detection and prevention, HTTP
and other types of protocol inspection, URL filtering, application filtering, and access control, which the ASA
implements using separate features. Because many features are not configured using CLI commands, you will
not see every policy represented within the output of show running-config.
Note At all times, keep in mind that there is not a one-to-one overlap between ASA and Firepower Threat
Defense. Do not attempt to completely recreate an ASA configuration on a Firepower Threat Defense
device. You must carefully test any feature that you configure using FlexConfig.
Because the system uses ASA software commands to configure some features, you need to determine the
current ASA version used in software running on the Firepower Threat Defense device. This version number
indicates which ASA CLI configuration guides to use for instructions on configuring a feature. You also
should examine the current CLI-based configuration and compare it to the ASA configuration you want to
implement.
Keep in mind that any ASA configuration will be very different from a Firepower Threat Defense configuration.
Many Firepower Threat Defense policies are configured outside of the CLI, so you cannot see the configuration
by looking at the commands. Do not try to create a one-to-one correspondence between an ASA and Firepower
Threat Defense configuration.
To view this information, make an SSH connection to the device's management interface and issue the following
commands:
• show version system and look for the Cisco Adaptive Security Appliance Software Version number.
(If you issue the command through the Firepower Management Center CLI tool, omit the system
keyword.)
• show running-config to view the current CLI configuration.
• show running-config all to include all the default commands in the current CLI configuration.
You can also issue these commands from within Firepower Management Center using the following procedure.
Procedure
Access-list Advanced ACL, Extended ACL, and Standard ACL are blocked.
Ethertype ACL is allowed.
You can use standard and extended ACL objects defined in the object
manager inside the template as variables.
Network Object/Object-group Network object creation in the FlexConfig object is blocked, but you
can use network objects and groups defined in the object manager inside
the template as variables.
Route-Map Object Route-map object creation in the FlexConfig object is blocked, but you
can use route map objects defined in the object manager inside the
template as variables.
Service Object/Object-group Service object creation in the FlexConfig object is blocked, but you can
use port objects defined in the object manager inside the template as
variables.
Template Scripts
You can use scripting language to control processing within a FlexConfig object. Scripting language instructions
are a subset of commands supported in the Apache Velocity 1.3.1 template engine, a Java-based scripting
language that supports looping, if/else statements, and variables.
To learn how to use the scripting language, see the Velocity Developer Guide at http://velocity.apache.org/
engine/devel/developer-guide.html.
FlexConfig Variables
You can use variables in a FlexConfig object in cases where part of a command or processing instruction
depends on runtime information rather than static information. During deployment, the variables are replaced
with strings obtained from other configurations for the device based on the type of variable:
• Policy object variables are replaced with strings obtained from objects defined in Firepower Management
Center.
• System variables are replaced with information obtained from the device itself or from policies configured
for it.
• Processing variables are loaded with the contents of policy object or system variables as scripting
commands are processed. For example, in a loop, you iteratively load one value from a policy object or
system variable into a processing variable, then use the processing variable to form a command string
or perform some other action. These processing variables do not show up in the Variables list within a
FlexConfig object. Also, you do not add them using the Insert menu in the FlexConfig object editor.
• Secret key variables are replaced with the single string defined for the variable within the FlexConfig
object.
Variables start with the $ character, except for secret keys, which start with the @ character. For example,
$ifname is a policy object variable in the following command, whereas @keyname is a secret key.
interface $ifname
key @keyname
Note The first time you insert a policy object or system variable, you must do so through the Insert menu in
the FlexConfig object editor. This action adds the variable to the Variables list at the bottom of the
FlexConfig object editor. But you must type in the variable string on subsequent uses, even when using
system variables. If you are adding a processing variable, which does not have an object or system variable
assignment, do not use the Insert menu. If you are adding a secret key, always use the Insert menu. Secret
key variables do not show up in the Variables list.
Whether a variable is resolved as a single string, a list of strings, or a table of values depends on the type of
policy object or system variable you assign to the variable. (Secret keys always resolve to a single string.)
You must understand what will be returned in order to process the variables correctly.
The following topics explain the various types of variable and how to process them.
#if($tcpMssMinimum == "true")
sysopt connection tcpmss minimum $tcpMssBytes
#else
sysopt connection tcpmss $tcpMssBytes
#end
In this example, you would use the Insert menu in the FlexConfig object editor to add the first use of
$tcpMssBytes, but you would type in the variable directly on the #else line.
Secret key variables are a special type of single value variable. For secret keys, you always use the Insert
menu to add the variable, even for second and subsequent uses. These variables do not show up in the Variables
list within the FlexConfig object. For example, if you wanted to hide the keys for EIGRP configuration, you
could copy the Eigrp_Interface_Configure FlexConfig, and replace the $eigrpAuthKey and $eigrpAuthKeyId
variables with secret keys, @SecretEigrpAuthKey and @SecretEigrpAuthKeyId.
Note Policy object variables for network objects also equate to a single IP address specification, either a host
address, network address, or address range. However, in this case, you must know what type of address
to expect, because the ASA commands require specific address types. For example, if a command requires
a host address, using a network object variable that points to an object that contains a network address
will result in an error during deployment.
Thus, you would typically use a loop to process multiple value variables of the same type. For example, the
predefined FlexConfig Default_Inspection_Protocol_Enable uses a #foreach loop to go through the
enableInspectProtocolList object and process each value.
policy-map global_policy
class inspection_default
#foreach ( $protocol in $enableInspectProtocolList)
inspect $protocol
#end
In this example, the script assigns each value in turn to the $protocol variable, which is then used in an ASA
inspect command to enable the inspection engine for that protocol. In this case, you simply type in $protocol
as a variable name. You do not use the Insert menu to add it, because you are not assigning an object or
system value to the variable. However, you must use the Insert menu to add $enableInspectProtocolList.
The system loops through the code between #foreach and #end until there are no values remaining in
$enableInspectProtocolList.
In this example, you would use the Insert menu in the FlexConfig object editor to add the first use of
$netflow_Destination, and then add .get(0). But you would type in the variable directly for the
$netflow_Destination.get(1) and $netflow_Destination.get(2) specifications.
[{intf_hardwarare_id=GigabitEthernet0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.10.1, intf_ipv6_link_local_address=,
intf_logical_name=outside},
{intf_hardwarare_id=GigabitEthernet0/1, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},
{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},
{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]
In the above example, information is returned for 4 interfaces. Each interface includes a table of named values.
For example, intf_hardwarare_id is the name of the interface hardware name property, and returns strings
such as GigabitEthernet0/0.
This type of variable is typically of indeterminate length, so you need to use looping to process the values.
But you also need to add the property name to the variable name to indicate which value to retrieve.
For example, IS-IS configuration requires that you add the ASA isis command to an interface that has a logical
name in interface configuration mode. However, you enter that mode using the interface’s hardware name.
Thus, you need to identify which interfaces have logical names, then configure just those interfaces using
their hardware names. The ISIS_Interface_Configuration predefined FlexConfig does this using an if/then
structure nested in a loop. In the following code, you can see that the #foreach scripting command loads each
interface map into the $intf variable, then the #if statement keys off the intf_logical_name value in the map
($intf.intf_logical_name), and if the value is in the list defined in the isisIntfList predefined text variable,
enters the interface command using the intf_hardwarare_id value ($intf.intf_hardwarare_id). You would need
to edit the isisIntfList variable to add the names of the interfaces on which to configure IS-IS.
Note Do not deploy this FlexConfig to the device, however, because it will not contain any valid configuration
commands. You would get deployment errors. After obtaining the preview, delete the FlexConfig object
from the FlexConfig policy and save the policy.
$IPv4_Private_addresses
$SYS_FW_MANAGEMENT_IP
$SYS_FW_ENABLED_INSPECT_PROTOCOL_LIST
$SYS_FTD_ROUTED_INTF_MAP_LIST
$SYS_FW_INTERFACE_NAME_LIST
The preview of this object might look like the following (line returns added for clarity):
192.168.0.171
[dns, ftp, h323 h225, h323 ras, rsh, rtsp, sqlnet, skinny, sunrpc,
xdmcp, sip, netbios, tftp, icmp, icmp error, ip-options]
[{intf_hardwarare_id=GigabitEthernet0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.10.1, intf_ipv6_link_local_address=,
intf_logical_name=outside},
{intf_hardwarare_id=GigabitEthernet0/1, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},
{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},
{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]
• Text Objects—For text strings, which can include IP addresses, numbers, and other free-form text such
as interface or zone names. Select FlexConfig > Text Object from the table of contents, then click Add
Text Object. You can configure these objects to contain a single value or multiple values. These objects
are highly flexible and built specifically for use within FlexConfig objects. For detailed information,
see Configure FlexConfig Text Objects, on page 647.
• Network—For IP addresses. You can use network objects or groups. Select Network from the table of
contents, then select Add Network > Add Object or Add Group. If you use a group object, the variable
returns a list of each IP address specification within the group. Addresses can be host, network, or address
ranges, depending on the object contents. See Network Objects, on page 353.
• Security Zones—For interfaces within a security zone or interface group. Select Interface from the
table of contents, then select Add > Security Zone or Interface Group. A security zone variable returns
a list of the interfaces within that zone or group for the device being configured. See Interface Objects:
Interface Groups and Security Zones, on page 357.
• Standard ACL Object—For standard access control lists. A standard ACL variable returns the name
of the standard ACL object. Select Access List > Standard from the table of contents, then click Add
Standard Access List Object. See Access List, on page 422.
• Extended ACL Object—For extended access control lists. An extended ACL variable returns the name
of the extended ACL object. Select Access List > Extended from the table of contents, then click Add
Extended Access List Object. See Access List, on page 422.
• Route Map—For route map objects. A route map variable returns the name of the route map object.
Select Route Map from the table of contents, then click Add Route Map. See Route Maps, on page
419.
Name Description
SYS_FW_OS_MODE The operating system mode of the device. Possible values are
ROUTED or TRANSPARENT.
Name Description
SYS_FTD_INTF_POLICY_MAP A map with interface name as key and policy-map as value. This
variable returns nothing if there are no interface-based service
policies defined on the device.
SYS_FTD_ROUTED_INTF_MAP_LIST A list of routed interface maps on the device. Each map includes
a set of named values related to routed interface configuration.
SYS_FTD_SWITCHED_INTF_MAP_LIST A list of switched interface maps on the device. Each map includes
a set of named values related to switched interface configuration.
SYS_FTD_INLINE_INTF_MAP_LIST A list of inline interface maps on the device. Each map includes
a set of named values related to inline set interface configuration.
SYS_FTD_PASSIVE_INTF_MAP_LIST A list of passive interface maps on the device. Each map includes
a set of named values related to passive interface configuration.
SYS_FTD_INTF_BVI_MAP_LIST A list of Bridge Virtual Interface maps on the device. Each map
includes a set of named values related to BVI configuration.
SYS_FW_INTERFACE_HARDWARE_ID_LIST A list of the hardware names for interfaces on the device, such
as GigabitEthernet0/0.
SYS_FW_INTERFACE_NAME_LIST A list of logical names for interfaces on the device, such as inside.
SYS_FW_NON_INLINE_INTERFACE_NAME_LIST A list of logical names for interfaces that are not part of inline
sets, such as all routed interfaces.
For example, Snort inspection includes the HTTP protocol, so do not enable ASA-style HTTP inspection. (In
fact, you cannot add http to the enableInspectProtocolList object. In this case, you are prevented from
misconfiguring your device.) Instead, configure the access control policy to perform application or URL
filtering, as needed, to implement your HTTP inspection requirements.
PrefixDelegationInside Configures the inside interface for DHCPv6 None, but could be used with a copy of
prefix delegation. The object includes DHCPv6_Prefix_Delegation_Configure.
multiple entries, in order, interface name,
IPv6 suffix with prefix length, and prefix
pool name.
PrefixDelegationOutside Configure the outside DHCPv6 prefix None, but could be used with a copy of
delegation client. The object includes DHCPv6_Prefix_Delegation_Configure.
multiple entries, in order, interface name
and IPv6 prefix length
Use FlexConfig policies to customize the configuration of a Firepower Threat Defense device.
Before using FlexConfig, try to configure all the policies and settings you need using the other features in
Firepower Management Center. FlexConfig is a method of last resort to configure ASA-based features that
are compatible with Firepower Threat Defense but which are not otherwise configurable in Firepower
Management Center.
Following is the end-to-end procedure for configuring and deploying a FlexConfig policy.
Procedure
Step 1 Determine the CLI command sequence that you want to configure.
If you have a functioning configuration on an ASA device, use show running-config to get the sequence of
commands that you need. Make adjustments to items such as interface names and IP addresses as needed.
If this is for a new feature, it is best to try to implement it on an ASA device in a lab setting to verify that you
have the correct command sequence.
For more information, see the following topics:
• Recommended Usage for FlexConfig Policies, on page 622
• CLI Commands in FlexConfig Objects, on page 622
Step 2 Select Objects > Object Management, then select FlexConfig > FlexConfig Objects from the table of
contents.
Examine the predefined FlexConfig objects to determine if any will be able to generate the commands you
need. Click the view icon ( ) to see the object contents. If an existing object is close to what you want, start
by making a copy of the object, and then edit the copy. See Predefined FlexConfig Objects, on page 632.
Examining the objects will also give you an idea of the structure, command syntax, and expected sequencing
for a FlexConfig object.
Note If you find any objects that you will use, either directly or as copies, examine the Variables list at
the bottom of the object. Make note of the variable names, except those in all capitals that start with
SYS, which are system variables. These variables are text objects that you will probably need to edit
and define overrides for, especially if the default value column shows the object has no value.
Step 3 If you need to create your own FlexConfig objects, determine what variables you will need and create the
associated objects.
The CLI you need to deploy might contain IP addresses, interface names, port numbers, and other parameters
that you might want to adjust over time. These are best isolated into variables, which point to objects that
contain the necessary values. You might also need variables for strings that are part of the configuration but
which might change over time.
Also, determine if you need different values for each device to which you will assign the policy. For example,
you might want to configure the feature on three devices, but you might need to specify a different interface
name or IP address on a given command for each of these devices. If you need to customize the object for
each device, ensure that you enable overrides when creating the object, and then define the override values
per device.
See the following topics for an explanation of the various types of variables and how to configure the related
objects when necessary.
• FlexConfig Variables, on page 626
• FlexConfig Policy Object Variables, on page 630
• FlexConfig System Variables, on page 631
• Configure FlexConfig Text Objects, on page 647
Step 4 If you are using the predefined FlexConfig objects, edit the text objects used as variables.
See Configure FlexConfig Text Objects, on page 647.
Step 9 Click Deploy in the menu bar, select the devices assigned to the policy, and click the Deploy button.
Wait for deployment to complete.
Use FlexConfig objects to define a configuration to be deployed to a device. Each FlexConfig policy is
composed of a list of FlexConfig objects, so the objects are essentially code modules composed of Apache
Velocity scripting commands, ASA software configuration commands, and variables.
There are several predefined FlexConfig objects that you can use directly, or you can make copies if you need
to edit them. You can also create your own objects from scratch. A FlexConfig object’s content can range
from a single simple command string to elaborate CLI command structures that use variables and scripting
commands to deploy commands whose content can differ from device to device or deployment to deployment.
You can also create FlexConfig policy objects when defining FlexConfig policies.
Procedure
You can use variables to supply information that can be known only at runtime, or which can differ from
device to device. You simply type in processing variables, but you must use the Insert menu to add variables
that are associated with policy objects or system variables, or which are secret keys. For a complete discussion
of variables, see FlexConfig Variables, on page 626.
• To insert system variables, choose Insert > Insert System Variable > Variable Name. For a detailed
explanation of these variables, see FlexConfig System Variables, on page 631.
• To insert policy object variables, choose Insert > Insert Policy Object > Object Type, selecting the
appropriate type of object. Then, give the variable a name (which can be the same name as the associated
policy object), select the object to associate with the variable, and click Save. For a detailed explanation
of these types, see FlexConfig Policy Object Variables, on page 630. For more detail on the procedure,
see Add a Policy Object Variable to a FlexConfig Object, on page 645.
• To insert secret key variables, choose Insert > Secret Key and define the variable name and value. For
more detail on the procedure, see Configure Secret Keys, on page 646.
Note You must use the Insert menu to create a new policy object or system variable. However, for
subsequent uses of that variable, you must type it in, $ included. This is also true for system variables:
the first time you use it, add it from the Insert menu. Then, type it out for subsequent uses. If you
use the Insert menu more than once for a system variable, the system variable is added to the Variables
list multiple times, and the FlexConfig will not validate, meaning you cannot save your changes. For
processing variables (those not associated with a policy object or system variable), simply type in
the variable. If you are adding a secret key, always use the Insert menu. Secret key variables do not
show up in the Variables list.
Step 6 Choose the deployment frequency and type.
• Deployment—Select one of the following:
◦Once—Commands in the object are deployed once. Use this option when you know (from testing)
that the configuration commands will not be negated by commands generated for managed features
upon each deployment. Also, this option is appropriate when you are clearing the configuration
for a feature without intending to reconfigure it.
◦Everytime—Commands in the object are deployed each time you deploy the device configuration.
Test to determine if you need to first clear commands for a feature configuration before re-issuing
commands on subsequent deployments. Use an Everytime deployment when it is likely, or a tested
reality, that the configuration commands in the object will be removed by the deployment of
managed features.
Step 7 (Optional.) Click the Validate icon above the object body to check the integrity of the script.
The object is always validated when you click Save. You cannot save an invalid object.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
You can insert variables into a FlexConfig policy object that are associated with other types of policy object.
When the FlexConfig is deployed to a device, these variables resolve to the names or content of the associated
object.
Use the following procedure for the first use of a policy object variable in a FlexConfig object. If you need
to refer to the object again, type in the variable (including the $ sign). To understand how to use these variables,
see How to Process Variables, on page 627.
Procedure
Step 1 Choose Insert > Insert Policy Object > Object Type, selecting the appropriate type of object.
Step 2 Enter a name for the variable, and optionally, a description.
The name must be unique within the context of the FlexConfig object. It cannot include spaces. You are
allowed to use the exact same name as the object associated with the variable.
Step 3 Select the object to associate with the variable and click Add to move it to the Selected Object list.
You can associate a variable with a single object only.
Note For text objects, you can select any of the predefined objects as needed. However, many of these
objects have no default values. You must update the objects to add the required values either directly
or as overrides for the device to which you will deploy the FlexConfig object. Trying to deploy a
FlexConfig without updating these objects typically results in deployment errors.
Step 4 Click Save.
The variable appears in the Variables list at the bottom of the FlexConfig object editor.
A secret key is any single-string variable whose content you want to mask, such as passwords. The system
provides special treatment for these variables to help you prevent the dissemination of sensitive information.
Secret key variables do not show up in the Variables list in the FlexConfig object.
Use the following procedure to create, insert, and otherwise manage secret key variables in a FlexConfig
object. Unlike other types of variables, you can use the Insert command every time you need to insert a given
secret key variable. With respect to processing, these variables behave like single-value text object variables;
see Single Value Variables, on page 627.
Note Any data defined in a secret key variable is masked from users except when previewing a FlexConfig
policy. In addition, if you export a FlexConfig policy, the content of any secret key variable is erased.
When you import the policy, you will need to manually edit each secret key variable to enter the data.
Procedure
Step 1 While editing a FlexConfig Policy Object, choose Insert > Secret Key.
Step 2 In the Insert Secret Key dialog box, do any of the following:
• To create a new key, click Add Secret Key, then fill in the following information and click Add.
◦Secret Key Name—The name of the variable. This name appears in the FlexConfig object prefixed
with @.
◦Password, Confirm Password—The secret string, which is masked with asterisks as you type.
• To insert a secret key variable in the FlexConfig object, select the check box for the variable.
• To edit the value of a secret key variable, click the edit icon ( ) for the variable. Make your changes
and click Add.
• To delete a secret key variable, click the delete icon ( ) for the variable.
Use text objects in FlexConfig objects as the target of policy object variables. You can use variables to supply
information that can be known only at runtime, or which can differ from device to device. During deployment,
variables that point to text objects are replaced by the content of the text object.
Text objects contain free-form strings, which can be keywords, interface names, numbers, IP addresses, and
so forth. The content depends on how you will use the information within a FlexConfig script.
Before creating or editing a text object, determine exactly what content you will need. This includes how you
intend to process the object, which will help you decide between creating a single string or multiple string
object. Read the following topics:
• FlexConfig Variables, on page 626
• How to Process Variables, on page 627
Procedure
You cannot change the variable type after you save the object.
Step 6 If the variable type is Multiple, use the up and down arrows to specify a Count.
Rows are added or removed from the object as you change the number.
both, in which case the values configured in the base object act as default values in cases where an override
does not exist for a given device.
When editing predefined objects, it is a good practice to use device overrides, so that the system defaults
remain in place for other users who might need to use the object in different FlexConfig policies. The approach
you take depends on the requirements of your organization.
Tip Some predefined objects require multiple values where each value serves a specific purpose. Read the
description text carefully to determine the expected values in the object. In some cases, the instructions
specify that you must use overrides instead of changing the base values. In the case of
enableInspectProtocolList, you are prevented from entering protocols whose inspection is incompatible
with Snort inspection.
If you decide to use device overrides, do the following.
a) Select Allow Overrides.
b) Expand the Overrides area (if necessary) and click Add.
If an override already exists for the device, click the edit icon for the override to change it.
c) On the Targets tab in the Add Object Override dialog box, select the device for which you are defining
values and click Add to move it to the Selected Devices list.
d) Click the Override tab, adjust the Count as needed, then click in the variable fields and type in the values
for the device.
e) Click Add.
Step 8 Click Save.
What to Do Next
• If an active policy references your object, deploy configuration changes; see Deploying Configuration
Changes, on page 288.
A FlexConfig policy contains two ordered lists of FlexConfig objects, one prepended list and one appended
list. For an explanation of prepend/append, see Configure FlexConfig Objects, on page 642.
FlexConfig policies are shared policies that you can assign to multiple devices.
Procedure
• Click New Policy to create a new FlexConfig Policy. You are prompted to enter a name. Optionally,
select devices in the Available Devices list and click Add to Policy to assign devices. Click Save.
• Click the edit icon ( ) to edit an existing Policy. You can change the name or description by clicking
them in edit mode.
• Click the copy icon ( ) to create a new policy with the same contents. You are prompted for a name.
Device assignments are not retained for the copy.
• Click the delete icon to remove a policy you no longer need.
Step 3 Select the FlexConfig objects required for the policy from the Available FlexConfig list and click > to add
them to the policy.
Objects are automatically added to the prepended or appended list based on the deployment type specified in
the FlexConfig object.
Step 4 For each selected object, click the view icon ( ) next to the object to identify the variables used in the object.
Except for system variables, which start with SYS, you need to ensure that the objects associated with the
variables are not empty. A blank or brackets with nothing between them, [ ], indicate an empty object. You
will need to edit these objects before deploying the policy.
Note If you use object overrides, those values will not show up in this view. Thus, an empty default value
does not necessarily mean that you have not updated the object with the required values. Previewing
the configuration will show whether the variables resolve correctly for a given device. See Preview
the FlexConfig Policy, on page 650.
Step 5 Click Save.
What to Do Next
• Set target devices for the policy; see Set Target Devices for a FlexConfig Policy, on page 649.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you create a FlexConfig policy, you can select the devices that use the policy. You can subsequently
change device assignments for the policy as described below.
Note Normally, when you unassign a policy from a device, the system automatically removes the associated
configuration upon the next deployment. However, because FlexConfig objects are scripts for deploying
customized commands, simply unassigning a FlexConfig policy from a device does not remove the
commands that were configuring by the FlexConfig objects. If your intention is to remove
FlexConfig-generated commands from a device's configuration, see Remove Features Configured Using
FlexConfig, on page 653.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Preview a FlexConfig policy to see how the FlexConfig objects get translated into CLI commands. The preview
shows the commands that will be generated for a selected device from the scripts and variables used in the
FlexConfig objects. The variables are resolved based on the configuration for the device, so you get a clear
idea of what will be deployed.
Use the preview to look for potential problems in the FlexConfig objects. Correct the objects until the preview
shows the expected results.
You must preview the configuration separately for each device, because the variables can resolve differently
based on the device configuration.
Procedure
After you deploy a FlexConfig policy to a device, verify that the deployment was successful and that the
resulting configuration is what you expected. Also, verify that the device is performing as expected.
Procedure
a) Click the System Status icon in the menu bar, which is the unnamed icon between Deploy and System.
The icon looks like one of the following, and it might include a number if there are errors:
• — Indicates no warnings or errors are present on the system.
• — Indicates one or more warnings and no errors are present on the system.
• — Indicates one or more errors and any number of warnings are present on the system.
Step 2 Verify that the deployed configuration includes the expected commands.
You can do this by making an SSH connection to the device's management IP address. Use the show
running-config command to view the configuration.
Alternatively, use the CLI tool within Firepower Management Center.
a) Choose System > Health > Monitor and click the name of the device.
You might need to click the open/close arrow in the Count column in the Status table to see any devices.
b) Click Advanced Troubleshooting.
c) Click the Threat Defense CLI tab.
d) Select show as the command, and type running-config as the parameter.
e) Click Execute.
The running configuration appears in the text box. You can select the configuration and press Ctrl+C, then
paste it into a text file for later analysis.
exact commands to use are feature-dependent and should be mentioned in the ASA configuration guide and
command reference you used to learn how to configure the feature.
If commands that show statistics indicate that numbers are not changing (for example, hit counts, connection
counts, and so forth), the configuration might be valid but not meaningful. If you know that traffic is going
through the device that should show up in statistics, look for what is missing in your configuration. For
example, NAT or access rules might be dropping or changing traffic before a feature can act on it.
You can use the show commands from an SSH session or through the Firepower Management Center CLI
tool.
However, if the show command that you need to use is not available directly within the Firepower Threat
Defense CLI, you will need make an SSH connection to the device to use the commands. From the CLI, enter
the following command sequence to enter Privileged EXEC mode within the diagnostic CLI. From there, you
should be able to enter these otherwise unsupported show commands.
If you decide you need to remove a set of configuration commands you configured using FlexConfig, you
must manually remove that configuration. Unassigning the FlexConfig policy from a device does not remove
the configuration.
To manually remove the configuration, you create new FlexConfig objects to clear or negate the configuration
commands.
Procedure
Step 1 Choose Objects > Object Management and create the FlexConfig Objects to clear or negate the configuration
commands.
If a feature has a clear command that can remove all configuration settings, then use that command. For
example, the predefined Eigrp_Unconfigure_All object contains a single command that removes all
EIGRP-related configuration commands:
If there is not a clear command for the feature, you need to use the no form of each command you want to
remove. For example, the predefined Sysopt_basic_negate object removes the commands configured through
the predefined Sysopt_basic object.
You would typically configure a FlexConfig object that removes configurations as a prepended, deploy once
object.
Step 2 Choose Devices > FlexConfig and create a new FlexConfig policy or edit the existing policy.
If you want to preserve the FlexConfig policy that deploys the configuration commands, create a new policy
specifically for negating the commands, and assign the devices to the policy. Then, add the new FlexConfig
objects to the policy.
If you want to completely remove the FlexConfig configuration objects from all devices, you can simply
delete those commands from the existing FlexConfig policy and replace them with the objects that negate the
configuration.
Step 7 While editing the FlexConfig policy, click Policy Assignments and remove the device. Optionally, remove
the FlexConfig Objects from the policy.
Assuming that the FlexConfig policy simply removes the unwanted configuration commands, there is no need
to keep the policy assigned to the device after the removal is complete.
However, if the FlexConfig policy retains options that you still want configured on the device, remove the
negation objects from the policy. They are no longer needed.
Note High availability is not supported on Firepower Threat Defense Virtual running on Amazon Web Services.
Hardware Requirements
The two units in a High Availability configuration must:
• Be the same model.
• For the Firepower 9300 chassis, both units in the High Availability pair must have the same interfaces
assigned to the High Availability logical devices.
• Have the same number and types of interfaces. For the Firepower 9300 chassis, all interfaces must be
preconfigured in FXOS identically before you enable High Availability.
If you are using units with different flash memory sizes in your High Availability configuration, make sure
the unit with the smaller flash memory has enough space to accommodate the software image files and the
configuration files. If it does not, configuration synchronization from the unit with the larger flash memory
to the unit with the smaller flash memory will fail.
Software Requirements
The two units in a High Availability configuration must:
• Be in the same firewall mode (routed or transparent).
• Have the same major (first number), minor (second number), and maintenance (third number) software
version.
• Be in the same domain or group on the Firepower Management Center.
• Have the same NTP configuration. See Configure NTP Time Synchronization for Threat Defense, on
page 986.
• Be fully deployed on the Firepower Management Center with no uncommitted changes.
• Not have DHCP or PPPoE configured in any of their interfaces.
License Requirements
Firepower Threat Defense devices in a high availability configuration must have the same licenses. Before
high availability is established, it does not matter which licenses are assigned to the secondary/standby device.
During high availability configuration, the Firepower Management Center releases any unnecessary licenses
assigned to the standby device and replaces them with identical licenses assigned to the primary/active device.
For example, if the active device has a Base license and a Threat license, and the standby device has only a
Base license, the Firepower Management Center communicates with the Cisco Smart Software Manager to
obtain an available Threat license from your account for the standby device. If your Smart Licenses account
does not include enough purchased entitlements, your account becomes Out-of-Compliance until you purchase
the correct number of licenses. High availability configurations require two Smart License entitlements; one
for each device in the pair.
Failover Link
The two units in a failover pair constantly communicate over a failover link to determine the operating status
of each unit.
Note When using an EtherChannel or Redundant Interface as the failover or stateful link, you must confirm
that the same port channel with the same member interfaces exists on both devices before establishing
high availability.
For a redundant interface used as the failover link, see the following benefits for added redundancy:
• When a failover unit boots up, it alternates between the member interfaces to detect an active unit.
• If a failover unit stops receiving keepalive messages from its peer on one of the member interfaces, it
switches to the other member interface.
For an EtherChannel used as the failover link, to prevent out-of-order packets, only one interface in the
EtherChannel is used. If that interface fails, then the next interface in the EtherChannel is used. You cannot
alter the EtherChannel configuration while it is in use as a failover link.
If you do not use a switch between the units, if the interface fails, the link is brought down on both peers. This
condition may hamper troubleshooting efforts because you cannot easily determine which unit has the failed
interface and caused the link to come down.
The Firepower Threat Defense device supports Auto-MDI/MDIX on its copper Ethernet ports, so you can
either use a crossover cable or a straight-through cable. If you use a straight-through cable, the interface
automatically detects the cable and swaps one of the transmit/receive pairs to MDIX.
For optimum performance when using long distance failover, the latency for the state link should be less than
10 milliseconds and no more than 250 milliseconds. If latency is more than 10 milliseconds, some performance
degradation occurs due to retransmission of failover messages.
Defense devices become active. Therefore, the following two connection methods shown in the following
figures are NOT recommended.
Scenario 2—Recommended
We recommend that failover links NOT use the same switch as the data interfaces. Instead, use a different
switch or use a direct cable to connect the failover link, as shown in the following figures.
Scenario 3—Recommended
If the Firepower Threat Defense data interfaces are connected to more than one set of switches, then a failover
link can be connected to one of the switches, preferably the switch on the secure (inside) side of network, as
shown in the following figure.
Scenario 4—Recommended
The most reliable failover configurations use a redundant interface on the failover link, as shown in the
following figures.
the active unit cannot perform network tests to check the standby interface health; it can only track the link
state. You also cannot connect to the standby unit on that interface for management purposes.
1 When the primary unit fails over, the secondary unit assumes the IP addresses and MAC addresses of the
primary unit and begins passing traffic.
2 The unit that is now in standby state takes over the standby IP addresses and MAC addresses.
Because network devices see no change in the MAC to IP address pairing, no ARP entries change or time out
anywhere on the network.
If the secondary unit boots without detecting the primary unit, the secondary unit becomes the active unit and
uses its own MAC addresses, because it does not know the primary unit MAC addresses. However, when the
primary unit becomes available, the secondary (active) unit changes the MAC addresses to those of the primary
unit, which can cause an interruption in your network traffic. Similarly, if you swap out the primary unit with
new hardware, a new MAC address is used.
Virtual MAC addresses guard against this disruption because the active MAC addresses are known to the
secondary unit at startup, and remain the same in the case of new primary unit hardware. You can manually
configure virtual MAC addresses.
If you do not configure virtual MAC addresses, you might need to clear the ARP tables on connected routers
to restore traffic flow. The Firepower Threat Defense device does not send gratuitous ARPs for static NAT
addresses when the MAC address changes, so connected routers do not learn of the MAC address change for
these addresses.
The IP address and MAC address for the state link do not change at failover; the only exception is if the state
link is configured on a regular data interface.
Stateful Failover
During Stateful Failover, the active unit continually passes per-connection state information to the standby
unit. After a failover occurs, the same connection information is available at the new active unit. Supported
end-user applications are not required to reconnect to keep the same communication session.
Supported Features
The following state information is passed to the standby Firepower Threat Defense device when Stateful
Failover is enabled:
• NAT translation table
• TCP connection states
• UDP connection states
• Snort connection states
• Strict TCP enforcement
• The ARP table
• The Layer 2 bridge table (for bridge groups)
• The HTTP connection table
• The ISAKMP and IPsec SA table
Note Routes are synchronized only for link-up or link-down events on an active unit. If the
link goes up or down on the standby unit, dynamic routes sent from the active unit may
be lost. This is normal, expected behavior.
• DHCP Server
• ARP Inspection
• AVC—App-id verdicts are replicated, but not detection states. So, proper synchronization occurs as
long as App-id verdicts are complete and synchronized before failover occurs.
• URL
• Geolocation
• URL Filtering
• IPS Detection state—Upon failover, once mid-flow pickup occurs, new inspections are completed, but
old states are lost.
• File malware blocking—File disposition must become available before failover.
• File type detection and blocking—File type must be identified before failover. If failover occurs while
the original active device is identifying the file, the file type is not synced. Even if your file policy blocks
that file type, the new active device downloads the file.
• TLS sessions not decrypted
• TLS URL
• User Agent
• ISE Session Directory
• Identity/Captive Portal—Existing user sessions work correctly after failover. For authentications in
progress when failover occurs, depending on the race condition between captive portal flows and the
failover switch, there are two possible outcomes:
◦The user has not authenticated before failover occurs. In this case, the browser session fails. Upon
refreshing, the session goes to the new active unit and you are returned to the captive portal
configuration page.
◦The user already authenticated with the original active unit, but failover occurs and the browser
session fails. Upon refreshing, you are returned to the captive portal configuration page so you can
authenticate a second time with the new active unit.
• Signature Lookup—If failover occurs in the middle of a file transmit, no file event is generated and no
detection occurs.
• File Storage—If failover occurs when the file is being stored, it is stored on the original active device.
If the original active device went down while the file was being stored, the file does not get stored.
• File Pre-class (Local Analysis)—If failover occurs in the middle of pre-classification, detection fails.
• File Dynamic Analysis - Connectivity to the cloud—If failover occurs, the system may submit the file
to the cloud.
• Archive File Support—If failover occurs in the middle of an analysis, the system loses visibility into
the file/archive.
• Custom Blacklisting—If failover occurs, no events are generated.
• IP Reputation
• URL Reputation
• DNS Sinkhole
• Fragment settings
• VPN—VPN end users do not have to reauthenticate or reconnect the VPN session after a failover.
However, applications operating over the VPN connection could lose packets during the failover process
and not recover from the packet loss.
Unsupported Features
The following state information is not passed to the standby Firepower Threat Defense device when Stateful
Failover is enabled:
• Sessions inside plaintext tunnels
• Inspection after decryption
• TLS Decryption State
• DHCP client
• DHCP server address leases
• Multicast routing
for 30 to 50 seconds when it senses the topology change. To avoid traffic loss while the port is in a blocking
state, you can configure one of the following workarounds:
• Enable the STP PortFast feature on the switch:
interface interface_id
spanning-tree portfast
The PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port
still participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
• Disable interface monitoring.
• Increase interface holdtime to a high value that will allow STP to converge before the Firepower Threat
Defense devices fail over.
• Decrease STP timers to allow STP to converge faster than the interface holdtime.
Interface Monitoring
When a unit does not receive hello messages on a monitored interface for 2 polling periods, it runs interface
tests. If all interface tests fail for an interface, but this same interface on the other unit continues to successfully
pass traffic, then the interface is considered to be failed. If the threshold for failed interfaces is met, then a
failover occurs. If the other unit interface also fails all the network tests, then both interfaces go into the
“Unknown” state and do not count towards the failover limit.
An interface becomes operational again if it receives any traffic. A failed device returns to standby mode if
the interface failure threshold is no longer met.
If an interface has IPv4 and IPv6 addresses configured on it, the device uses the IPv4 addresses to perform
the health monitoring.
If an interface has only IPv6 addresses configured on it, then the device uses IPv6 neighbor discovery instead
of ARP to perform the health monitoring tests. For the broadcast ping test, the device uses the IPv6 all nodes
address (FE02::1).
Interface Tests
The Firepower Threat Defense device uses the following interface tests:
1 Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the interface
is down, then the device considers it failed. If the status is Up, then the device performs the Network
Activity test.
2 Network Activity test—A received network activity test. The purpose of this test is to generate network
traffic using LANTEST messages to determine which (if either) unit has failed. At the start of the test,
each unit clears its received packet count for its interfaces. As soon as a unit receives any packets during
the test (up to 5 seconds), then the interface is considered operational. If one unit receives traffic and the
other unit does not, then the unit that received no traffic is considered failed. If neither unit received traffic,
then the device starts the ARP test.
3 ARP test—A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time, the
unit sends ARP requests to these machines, attempting to stimulate network traffic. After each request,
the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered
operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list
no traffic has been received, the device starts the ping test.
4 Broadcast Ping test—A ping test that consists of sending out a broadcast ping request. The unit then counts
all received packets for up to 5 seconds. If any packets are received at any time during this interval, the
interface is considered operational and testing stops. If no traffic is received, the testing starts over again
with the ARP test.
Interface Status
Monitored interfaces can have the following status:
• Unknown—Initial status. This status can also mean the status cannot be determined.
• Normal—The interface is receiving traffic.
• Normal (Waiting)—The interface is up, but has not yet received a hello packet from the corresponding
interface on the peer unit.
• Normal (Not-Monitored)—The interface is up, but is not monitored by the failover process.
• Testing—Hello messages are not heard on the interface for five poll times.
• Link Down—The interface or VLAN is administratively down.
• Link Down (Waiting)—The interface or VLAN is administratively down and has not yet received a
hello packet from the corresponding interface on the peer unit.
• Link Down (Not-Monitored)—The interface or VLAN is administratively down, but is not monitored
by the failover process.
• No Link—The physical link for the interface is down.
• No Link (Waiting)—The physical link for the interface is down and has not yet received a hello packet
from the corresponding interface on the peer unit.
• No Link (Not-Monitored)—The physical link for the interface is down, but is not monitored by the
failover process.
• Failed—No traffic is received on the interface, yet traffic is heard on the peer interface.
Active unit interface physical link down. 500 milliseconds 5 seconds 15 seconds
Active unit interface up, but connection problem causes 5 seconds 25 seconds 75 seconds
interface testing.
Failover Events
In Active/Standby failover, failover occurs on a unit basis.
The following table shows the failover action for each failure event. For each failure event, the table shows
the failover policy (failover or no failover), the action taken by the active unit, the action taken by the standby
unit, and any special notes about the failover condition and actions.
Standby Group
Failure Event Policy Active Group Action Action Notes
Active unit failed (power or Failover n/a Become active No hello messages are received on
hardware) Mark active as failed any monitored interface or the
failover link.
Standby unit failed (power or No failover Mark standby as n/a When the standby unit is marked as
hardware) failed failed, then the active unit does not
attempt to fail over, even if the
interface failure threshold is
surpassed.
Failover link failed during No failover Mark failover link as Mark failover link as You should restore the failover link
operation failed failed as soon as possible because the unit
cannot fail over to the standby unit
while the failover link is down.
Failover link failed at startup No failover Mark failover link as Become active If the failover link is down at startup,
failed both units become active.
State link failed No failover No action No action State information becomes out of
date, and sessions are terminated if a
failover occurs.
Interface failure on active unit Failover Mark active as failed Become active None.
above threshold
Standby Group
Failure Event Policy Active Group Action Action Notes
Interface failure on standby unit No failover No action Mark standby as When the standby unit is marked as
above threshold failed failed, then the active unit does not
attempt to fail over even if the
interface failure threshold is
surpassed.
Additional Guidelines
• When the active unit fails over to the standby unit, the connected switch port running Spanning Tree
Protocol (STP) can go into a blocking state for 30 to 50 seconds when it senses the topology change.
To avoid traffic loss while the port is in a blocking state, you can enable the STP PortFast feature on the
switch:
interface interface_id spanning-tree portfast
This workaround applies to switches connected to both routed mode and bridge group interfaces. The
PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port still
participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
• You cannot enable failover if a local CA server is configured. Remove the CA configuration using the
no crypto ca server command.
• Configuring port security on the switch(es) connected to the Firepower Threat Defense failover pair can
cause communication problems when a failover event occurs. This problem occurs when a secure MAC
address configured or learned on one secure port moves to another secure port, a violation is flagged by
the switch port security feature.
• For Active/Standby High Availability and a VPN IPsec tunnel, you cannot monitor both the active and
standby units using SNMP over the VPN tunnel. The standby unit does not have an active VPN tunnel,
and will drop traffic destined for the NMS. You can instead use SNMPv3 with encryption so the IPsec
tunnel is not required.
• Make sure each unit in the High Availability pair uses a unique hostname; the Firepower Management
Center cannot add the secondary unit if it has the same name as the primary unit.
When establishing an Active/Standby High Availability pair, you designate one of the devices as primary and
the other as secondary. The system applies a merged configuration to the paired devices. If there is a conflict,
the system applies the configuration from the device you designated as primary.
In a multidomain deployment, devices in a high availability pair must belong to the same domain.
Note The system uses the failover link to sync configuration, while the stateful failover link is used to sync
application content between peers. After high availability is established, selected interface links and
encryption settings cannot be modified without breaking the high availability pair and reconfiguring it.
Caution Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort
process on the primary and secondary devices, temporarily interrupting traffic inspection on both devices.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See Snort® Restart Traffic Behavior, on page 293 for
more information. The system warns you that continuing to create a high availability pair restarts the Snort
process on the primary and secondary devices and allows you to cancel.
Note While you are setting up the High Availability feature for Remote Access VPN, if the primary device has
RAVPN configuration with an identity certificate enrolled using a CertEnrollment object, then the secondary
device must also have an identity certificate enrolled using the same CertEnrollment object. The
CertEnrollment object can have different values for the primary and secondary device due to the
device-specific overrides. The limitation is only to have the same CertEnrollment object enrolled on the
2 devices before the HA formation.
Procedure
Step 1 Add both devices to the Firepower Management Center according to Adding Devices to the Firepower
Management Center, on page 473.
Step 2 Choose Devices > Device Management.
Step 3 From the Add drop-down menu, choose Add High Availability.
Step 4 Enter a display Name for the high availability pair.
Step 5 Under Device Type, choose Firepower Threat Defense.
Step 6 Choose the Primary Peer device for the high availability pair.
Step 7 Choose the Secondary Peer device for the high availability pair.
Step 8 Click Continue.
Step 9 Under LAN Failover Link, choose an Interface with enough bandwidth to reserve for failover communications.
Step 10 Type any identifying Logical Name.
Step 11 Type a Primary IP address for the failover link on the active unit. This address should be on an unused subnet.
Note 169.254.0.0/16 and fd00:0:0:*::/64 are internally used subnets and cannot be used for the failover or
state links.
Step 12 Optionally, choose Use IPv6 Address.
Step 13 Type a Secondary IP address for the failover link on the standby unit. This IP address must be in the same
subnet as the primary IP address.
Step 14 If IPv4 addresses are used, type a Subnet Mask that applies to both the primary and secondary IP addresses.
Step 15 Optionally, under Stateful Failover Link, choose the same Interface, or choose a different interface and enter
the high availability configuration information.
Note 169.254.0.0/16 and fd00:0:0:*::/64 are internally used subnets and cannot be used for the failover or
state links.
Step 16 Optionally, choose Enabled and choose the Key Generation method for IPsec Encryption between the
failover links.
Step 17 Click OK. This process takes a few minutes as the process synchronizes system data.
You can edit the Failover Trigger Criteria to improve failover results. Interface Monitoring allows you to
determine which interfaces are better suited for failover.
By default, monitoring is enabled on all physical interfaces with logical names configured. You might want
to exclude interfaces attached to less critical networks from affecting your failover policy.
Procedure
Procedure
You can configure active and standby MAC addresses for failover in two places on the Firepower Management
Center:
• The Advanced tab of the Edit Interface page during interface configuration; see Configure the MAC
Address, on page 593.
• The Add Interface MAC Address page accessed from the High Availability page; see
If active and standby MAC addresses are configured in both locations, the addresses defined during interface
configuration takes preference for failover.
You can minimize loss of traffic during failover by designating active and standby mac addresses to the
physical interface. This feature offers redundancy against IP address mapping for failover.
Procedure
Switch the Active Peer in a Firepower Threat Defense High Availability Pair
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Admin/Network
Defense Admin
Firepower Threat
Defense Virtual
After you establish a Firepower Threat Defense high availability pair, you can manually switch the active and
standby units, effectively forcing failover for reasons such as persistent fault or health events on the current
active unit. Both units should be fully deployed before you complete this procedure.
Procedure
• Both units are in an active-active situation and you want to suspend one of them.
• You want to troubleshoot an active or standby unit and do not want the units to fail over during that
time.
Use the following CLI command on a particular unit of the high availability pair to suspend failover:
configure high-availability suspend
This command checks the high availability configuration and then suspends it. If the device is in an active
state, failover occurs if it is connected to a standby unit. If the unit is an active node without a peer node, it
goes into a suspended state, where it no longer processes traffic. If the unit is a standby unit, it goes into a
suspended state.
To resume failover, use the following command:
configure high-availability resume
Note Failover suspension is not a permanent state. If you reload the unit, it resumes automatically and returns
to a standalone unit.
Replace a Unit
If you need to replace a failed unit in a Firepower Threat Defense high availability pair, you must choose the
Force Break option to separate the pair. After you replace or repair the unit, you must then register the device
on the Firepower Management Center and re-establish high availability. The process varies depending on
whether the device is primary or secondary.
Follow the steps below to replace a failed primary unit in a Firepower Threat Defense high availability pair.
Failing to follow these steps can overwrite the existing high availability configuration.
Procedure
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on
page 679.
Step 2 Unregister the failed primary Firepower Threat Defense device from the Firepower Management Center; see
Deleting Devices from the Firepower Management Center, on page 475.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Adding Devices
to the Firepower Management Center, on page 473.
Step 4 Configure high availability, using the existing secondary/active unit as the primary device and the replacement
device as the secondary/standby device during registration; see Add a Firepower Threat Defense High
Availability Pair, on page 672.
What to Do Next
Follow the steps below to replace a failed secondary unit in a Firepower Threat Defense high availability pair.
Procedure
Step 1 Choose Force Break to separate the high availability pair; see Separate Units in a High Availability Pair, on
page 679.
Step 2 Unregister the secondary Firepower Threat Defense device from the Firepower Management Center; see
Deleting Devices from the Firepower Management Center, on page 475.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Adding Devices
to the Firepower Management Center, on page 473.
Step 4 Configure high availability, using the existing primary/active unit as the primary device and the replacement
device as the secondary/standby device during registration; see Add a Firepower Threat Defense High
Availability Pair, on page 672.
When you break a high availability pair, the active device retains full deployment functionality. The standby
device loses its failover and interface configurations, and becomes a standalone device.
Note If you cannot reach the high availability pair using the Firepower Management Center, use the CLI
command configure failover disable to remove the failover configuration from both devices.
Procedure
You can delete the pair from the Firepower Management Center and disable High Availability on each unit
using the CLI.
Procedure
You can view the failover history of both high availability devices in a single view. The history displays in
chronological order and includes the reason for any failover.
Procedure
You can view the stateful failover link statistics of both the primary and secondary devices in the high
availability pair.
Procedure
Note Some features are not supported when using clustering. See Unsupported Features with Clustering, on
page 690.
Note Individual interfaces are not supported, with the exception of a management interface.
The following sections provide more detail about clustering concepts and implementation.
Bootstrap Configuration
When you deploy the cluster, the Firepower 9300 chassis supervisor pushes a minimal bootstrap configuration
to each unit that includes the cluster name, cluster control link interface, and other cluster settings.
Cluster Members
Cluster members work together to accomplish the sharing of the security policy and traffic flows. This section
describes the nature of each member role.
2 Any other units with a higher priority respond to the election request; the priority is set when you deploy
the cluster and is not configurable.
3 If after 45 seconds, a unit does not receive a response from another unit with a higher priority, then it
becomes primary.
4 If a unit later joins the cluster with a higher priority, it does not automatically become the primary unit;
the existing primary unit always remains as the primary unless it stops responding, at which point a new
primary unit is elected.
Note You can manually force a unit to become the primary. For centralized features, if you force a primary unit
change, then all connections are dropped, and you have to re-establish the connections on the new primary
unit.
Cluster Interfaces
For intra-chassis clustering, you can assign both physical interfaces or EtherChannels (also known as port
channels) to the cluster. Interfaces assigned to the cluster are Spanned interfaces that load-balance traffic
across all members of the cluster.
For inter-chassis clustering, you can only assign data EtherChannels to the cluster. These Spanned
EtherChannels include the same member interfaces on each chassis; on the upstream switch, all of these
interfaces are included in a single EtherChannel, so the switch does not know that it is connected to multiple
devices.
Individual interfaces are not supported, with the exception of a management interface.
Chassis-Application Monitoring
Chassis-application health monitoring is always enabled. The Firepower 9300 chassis supervisor checks the
Firepower Threat Defense application periodically (every second). If the Firepower Threat Defense device is
up and cannot communicate with the Firepower 9300 chassis supervisor for 3 seconds, the Firepower Threat
Defense device generates a syslog message and leaves the cluster.
If the Firepower 9300 chassis supervisor cannot communicate with the application after 45 seconds, it reloads
the Firepower Threat Defense device. If the Firepower Threat Defense device cannot communicate with the
supervisor, it removes itself from the cluster.
Interface Monitoring
Each unit monitors the link status of all hardware interfaces in use, and reports status changes to the primary
unit. For inter-chassis clustering, Spanned EtherChannels use the cluster Link Aggregation Control Protocol
(cLACP). Each chassis monitors the link status and the cLACP protocol messages to determine if the port is
still active in the EtherChannel, and informs the Firepower Threat Defense application if the interface is down.
When you enable health monitoring, all physical interfaces are monitored by default (including the main
EtherChannel for EtherChannel interfaces). Only named interfaces that are in an Up state can be monitored.
For example, all member ports of an EtherChannel must fail before a named EtherChannel is removed from
the cluster.
If a monitored interface fails on a particular unit, but it is active on other units, then the unit is removed from
the cluster. The amount of time before the Firepower Threat Defense device removes a member from the
cluster depends on whether the unit is an established member or is joining the cluster. The Firepower Threat
Defense device does not monitor interfaces for the first 90 seconds that a unit joins the cluster. Interface status
changes during this time will not cause the Firepower Threat Defense device to be removed from the cluster.
For an established member, the unit is removed after 500 ms.
For inter-chassis clustering, if you add or delete an EtherChannel from the cluster, interface health-monitoring
is suspended for 95 seconds to ensure that you have time to make the changes on each chassis.
Note When the Firepower Threat Defense device becomes inactive and fails to automatically rejoin the cluster,
all data interfaces are shut down; only the Management/Diagnostic interface can send and receive traffic.
SNMP Engine ID No —
Configuration Replication
All units in the cluster share a single configuration. You can only make configuration changes on the primary
unit, and changes are automatically synced to all other units in the cluster.
Management Interface
You must assign a Management type interface to the cluster. This interface is a special individual interface
as opposed to a Spanned interface. The management interface lets you connect directly to each unit. This
Management logical interface is separate from the other interfaces on the device. It is used to set up and
register the device to the Firepower Management Center. It uses its own local authentication, IP address, and
static routing. Each cluster member uses a separate IP address on the management network that you set as
part of the bootstrap configuration.
The management interface is shared between the Management logical interface and the Diagnostic logical
interface. The Diagnostic logical interface is optional and is not configured as part of the bootstrap configuration.
The Diagnostic interface can be configured along with the rest of the data interfaces. If you choose to configure
the Diagnostic interface, configure a Main cluster IP address as a fixed address for the cluster that always
belongs to the current primary unit. You also configure a range of addresses so that each unit, including the
current primary, can use a Local address from the range. The Main cluster IP address provides consistent
diagnostic access to an address; when a primary unit changes, the Main cluster IP address moves to the new
primary unit, so access to the cluster continues seamlessly. For outbound management traffic such as TFTP
or syslog, each unit, including the primary unit, uses the Local IP address to connect to the server.
Connection Roles
There are 3 different roles defined for each connection:
• Owner—The unit that initially receives the connection. The owner maintains the TCP state and processes
packets. A connection has only one owner. If the original owner fails, then when new units receive
packets from the connection, the director chooses a new owner from those units.
• Director—The unit that handles owner lookup requests from forwarders and also maintains the connection
state to serve as a backup if the owner fails. When the owner receives a new connection, it chooses a
director based on a hash of the source/destination IP address and TCP ports, and sends a message to the
director to register the new connection. If packets arrive at any unit other than the owner, the unit queries
the director about which unit is the owner so it can forward the packets. A connection has only one
director. If a director fails, the owner chooses a new director.
• Forwarder—A unit that forwards packets to the owner. If a forwarder receives a packet for a connection
it does not own, it queries the director for the owner, and then establishes a flow to the owner for any
other packets it receives for this connection. The director can also be a forwarder. Note that if a forwarder
receives the SYN-ACK packet, it can derive the owner directly from a SYN cookie in the packet, so it
does not need to query the director. (If you disable TCP sequence randomization, the SYN cookie is not
used; a query to the director is required.) For short-lived flows such as DNS and ICMP, instead of
querying, the forwarder immediately sends the packet to the director, which then sends them to the
owner. A connection can have multiple forwarders; the most efficient throughput is achieved by a good
load-balancing method where there are no forwarders and all packets of a connection are received by
the owner.
For inter-chassis clustering, if the director for a flow is in the same chassis as the owner, then an additional
director is chosen on a different chassis to act as the director's backup in case the owner's chassis fails. If the
director is already on a different chassis, then no additional directors are required.
1 The SYN packet originates from the client and is delivered to one Firepower Threat Defense device (based
on the load balancing method), which becomes the owner. The owner creates a flow, encodes owner
information into a SYN cookie, and forwards the packet to the server.
2 The SYN-ACK packet originates from the server and is delivered to a different Firepower Threat Defense
device (based on the load balancing method). This Firepower Threat Defense device is the forwarder.
3 Because the forwarder does not own the connection, it decodes owner information from the SYN cookie,
creates a forwarding flow to the owner, and forwards the SYN-ACK to the owner.
4 The owner sends a state update to the director, and forwards the SYN-ACK to the client.
5 The director receives the state update from the owner, creates a flow to the owner, and records the TCP
state information as well as the owner. The director acts as the backup owner for the connection.
6 Any subsequent packets delivered to the forwarder will be forwarded to the owner.
7 If packets are delivered to any additional units, it will query the director for the owner and establish a flow.
8 Any state change for the flow results in a state update from the owner to the director.
• Site-to-site VPN
• Remote access VPN (SSL VPN and IPsec VPN)
• DHCP client, server, and proxy. DHCP relay is supported.
• High Availability
• Integrated Routing and Bridging
Note Traffic for centralized features is forwarded from member units to the primary unit over the cluster control
link.
If you use the rebalancing feature, traffic for centralized features may be rebalanced to non-master units
before the traffic is classified as a centralized feature; if this occurs, the traffic is then sent back to the
primary unit.
For centralized features, if the primary unit fails, all connections are dropped, and you have to re-establish
the connections on the new primary unit.
• Dynamic routing
• Static route monitoring
After the secondary members learn the routes from the primary unit, each unit makes forwarding decisions
independently.
The OSPF LSA database is not synchronized from the primary unit to secondary units. If there is a primary
unit switchover, the neighboring router will detect a restart; the switchover is not transparent. The OSPF
process picks an IP address as its router ID. Although not required, you can assign a static router ID to ensure
a consistent router ID is used across the cluster. See the OSPF Non-Stop Forwarding feature to address the
interruption.
• Dynamic NAT xlates managed by the primary unit—The primary unit maintains and replicates the xlate
table to secondary units. When a secondary unit receives a connection that requires dynamic NAT, and
the xlate is not in the table, it requests the xlate from the primary unit. The secondary unit owns the
connection.
• No static PAT for the following inspections—
◦FTP
◦RSH
◦SQLNET
◦TFTP
◦XDMCP
◦SIP
Switch Prerequisites
• Be sure to complete the switch configuration and successfully connect all the EtherChannels from the
chassis to the switch(es) before you configure clustering on the Firepower 9300 chassis.
• For a list of supported switches, see Cisco FXOS Compatibility.
Additional Guidelines
• You can include up to 6 modules in the cluster in up to 6 chassis.
• When adding a unit to an existing cluster, or when reloading a unit, there will be a temporary, limited
packet/connection drop; this is expected behavior. In some cases, the dropped packets can hang your
connection; for example, dropping a FIN/ACK packet for an FTP connection will make the FTP client
hang. In this case, you need to reestablish the FTP connection.
• If you use a Windows 2003 server connected to a Spanned interface, when the syslog server port is down
and the server does not throttle ICMP error messages, then large numbers of ICMP messages are sent
back to the cluster. These messages can result in some units of the cluster experiencing high CPU, which
can affect performance. We recommend that you throttle ICMP error messages.
Add the logical devices to the Management Center, and then group them into a cluster.
Procedure
Step 1 In the Management Center, choose Devices > Device Management, and choose Add > Add Device to add
each unit as a separate managed device using the management IP addresses you assigned when you deployed
the cluster.
Note If you use Management Center High Availability, make sure the standby Management Center also
successfully registers each unit before you continue and form the cluster on the active Management
Center: Log into the standby Management Center to check the registration status of each unit.
Step 2 Choose Add > Add Cluster to group the units into a cluster.
a) Choose the Primary device from the drop-down list.
All other eligible members are added to the Secondary Devices box.
b) Specify a Name for the cluster.
c) Click OK.
The cluster object is added to the Devices screen, with the member units underneath. The current primary
unit is indicated by "(primary)" after the unit name.
Note If you add more units to the cluster later on the FXOS chassis, then you must add each unit to the
Management Center, and then add them as secondary nodes of the cluster as soon as possible.
Step 3 To configure device-specific settings, click the edit icon ( ) for the cluster; you can only configure the cluster
as a whole, and not member units in the cluster.
Step 4 On the Devices > Device Management > Cluster tab, you can see General, License, System, and Health
settings. This tab is most useful for setting license entitlements. On the Devices tab, you can change the
management IP address for the primary unit only.
Step 5 (Optional) If you want to configure the Diagnostic interface, perform the following steps:
The Diagnostic interface is the only interface that can run in Individual interface mode. You can use this
interface for syslog messages or SNMP, for example.
a) Add an IPv4 and/or IPv6 address pool.
b) Click the Interfaces tab to edit the Diagnostic interface.
c) On the IPv4 tab, enter the Virtual IP Address and mask. This IP address is a fixed address for the cluster,
and always belongs to the current primary unit.
d) From the IPv4 Address Pool drop-down list, choose the address pool you created.
Include at least as many addresses as there are units in the cluster. The Virtual IP address is not a part of
this pool, but needs to be on the same network. You cannot determine the exact Local address assigned
to each unit in advance.
e) For the Mask, enter the subnet mask for the cluster IP pool.
f) On the IPv6 > Basic tab, from the IPv6 Address Pool drop-down list, choose the address pool you created.
g) Configure other interface settings as normal.
Step 6 Configure other device-level settings as desired.
Step 7 Click Save, and then Deploy.
You can add a new cluster member to an existing cluster, for example, when you add an additional module
to the Firepower 9300 device, or an additional chassis.
Procedure
Step 1 In the Management Center, choose Devices > Device Management, and choose Add > Add Device to add
the new logical device.
Step 2 Choose Add > Add Cluster.
Step 3 Choose the current Primary device from the drop-down list.
When you choose a primary device that is already in a cluster, then the existing cluster name is auto-filled,
and all eligible secondary devices are added to the Secondary Devices box, including the new unit you just
added to the Management Center.
If you need to remove a cluster member (for example, if you remove a module on the Firepower 9300, or
remove a chassis), then you should delete it from the Management Center. Do not delete the member if it is
still a healthy part of the cluster according to the Firepower Chassis Manager; even though you removed it
from the Management Center, it will still be an operational part of the cluster, which can cause problems if it
became the primary unit and the Management Center can no longer manage it.
Procedure
Step 1 In the Management Center, choose Devices > Device Management, and click the trash can next to the
secondary unit.
Step 2 Confirm that you want to delete the unit.
The unit is removed from the cluster and from the Management Center devices list.
If a unit was removed from the cluster, for example for a failed interface, you must manually rejoin the cluster
by accessing the unit CLI. Make sure the failure is resolved before you try to rejoin the cluster. See Rejoining
the Cluster, on page 687 for more information about why a unit can be removed from a cluster.
Procedure
Step 1 Access the CLI of the unit that needs to rejoin the cluster, either from the console port or using SSH to the
Management interface. Log in with the username admin and the password you set during initial setup.
Step 2 Enable clustering:
cluster enable
Path Determination
Routing protocols use metrics to evaluate what path will be the best for a packet to travel. A metric is a standard
of measurement, such as path bandwidth, that is used by routing algorithms to determine the optimal path to
a destination. To aid the process of path determination, routing algorithms initialize and maintain routing
tables, which include route information. Route information varies depending on the routing algorithm used.
Routing algorithms fill routing tables with a variety of information. Destination or next hop associations tell
a router that a particular destination can be reached optimally by sending the packet to a particular router
representing the next hop on the way to the final destination. When a router receives an incoming packet, it
checks the destination address and attempts to associate this address with a next hop.
Routing tables also can include other information, such as data about the desirability of a path. Routers compare
metrics to determine optimal routes, and these metrics differ depending on the design of the routing algorithm
used.
Routers communicate with one another and maintain their routing tables through the transmission of a variety
of messages. The routing update message is one such message that generally consists of all or a portion of a
routing table. By analyzing routing updates from all other routers, a router can build a detailed picture of
network topology. A link-state advertisement, another example of a message sent between routers, informs
other routers of the state of the sender links. Link information also can be used to build a complete picture of
network topology to enable routers to determine optimal routes to network destinations.
The primary advantage of hierarchical routing is that it mimics the organization of most companies and
therefore supports their traffic patterns well. Most network communication occurs within small company
groups (domains). Because intradomain routers need to know only about other routers within their domain,
their routing algorithms can be simplified, and, depending on the routing algorithm being used, routing update
traffic can be reduced accordingly.
The following figure shows the egress interface selection method in routed mode. In almost all cases, a route
lookup is equivalent to the NAT rule interface, but in some configurations, the two methods might differ.
ECMP Routing
The Firepower Threat Defense device supports Equal-Cost Multi-Path (ECMP) routing.
You can have up to 3 equal cost static or dynamic routes per interface. For example, you can configure multiple
default routes on the outside interface that specify different gateways.
In this case, traffic is load-balanced on the outside interface between 10.1.1.2, 10.1.1.3, and 10.1.1.4. Traffic
is distributed among the specified gateways based on an algorithm that hashes the source and destination IP
addresses.
ECMP is not supported across multiple interfaces, so you cannot define a route to the same destination on a
different interface. The following route is disallowed when configured with any of the routes above:
Routing Table
This section describes the routing table.
Even though OSPF routes have the better administrative distance, both routes are installed in the routing
table because each of these routes has a different prefix length (subnet mask). They are considered
different destinations and the packet forwarding logic determines which route to use.
• If the Firepower Threat Defense device learns about multiple paths to the same destination from a single
routing protocol, such as RIP, the route with the better metric (as determined by the routing protocol)
is entered into the routing table.
Metrics are values associated with specific routes, ranking them from most preferred to least preferred.
The parameters used to determine the metrics differ for different routing protocols. The path with the
lowest metric is selected as the optimal path and installed in the routing table. If there are multiple paths
to the same destination with equal metrics, load balancing is done on these equal cost paths.
• If the Firepower Threat Defense device learns about a destination from more than one routing protocol,
the administrative distances of the routes are compared, and the routes with lower administrative distance
are entered into the routing table.
Each routing protocol is prioritized using an administrative distance value. The following table shows the
default administrative distance values for the routing protocols supported by the ASA.
Static route 1
External BGP 20
Internal EIGRP 90
OSPF 110
RIP 120
Unknown 255
The smaller the administrative distance value, the more preference is given to the protocol. For example, if
the ASA receives a route to a certain network from both an OSPF routing process (default administrative
distance - 110) and a RIP routing process (default administrative distance - 120), the ASA chooses the OSPF
route because OSPF has a higher preference. In this case, the router adds the OSPF version of the route to the
routing table.
In this example, if the source of the OSPF-derived route was lost (for example, due to a power shutdown),
the ASA would then use the RIP-derived route until the OSPF-derived route reappears.
The administrative distance is a local setting. For example, if you use the distance-ospf command to change
the administrative distance of routes obtained through OSPF, that change would only affect the routing table
for the ASA on which the command was entered. The administrative distance is not advertised in routing
updates.
Administrative distance does not affect the routing process. The EIGRP, OSPF, RIP and BGP routing processes
only advertise the routes that have been discovered by the routing process or redistributed into the routing
process. For example, the RIP routing process advertises RIP routes, even if routes discovered by the OSPF
routing process are used in the ASA routing table.
Backup Routes
A backup route is registered when the initial attempt to install the route in the routing table fails because
another route was installed instead. If the route that was installed in the routing table fails, the routing table
maintenance process calls each routing protocol process that has registered a backup route and requests them
to reinstall the route in the routing table. If there are multiple protocols with registered backup routes for the
failed route, the preferred route is chosen based on administrative distance.
Because of this process, you can create floating static routes that are installed in the routing table when the
route discovered by a dynamic routing protocol fails. A floating static route is simply a static route configured
with a greater administrative distance than the dynamic routing protocols running on the Firepower Threat
Defense device. When the corresponding route discovered by a dynamic routing process fails, the static route
is installed in the routing table.
For example, a packet destined for 192.168.32.1 arrives on an interface with the following routes in the routing
table:
• 192.168.32.0/24 gateway 10.1.1.2
• 192.168.32.0/19 gateway 10.1.1.3
In this case, a packet destined to 192.168.32.1 is directed toward 10.1.1.2, because 192.168.32.1 falls within
the 192.168.32.0/24 network. It also falls within the other route in the routing table, but 192.168.32.0/24 has
the longest prefix within the routing table (24 bits verses 19 bits). Longer prefixes are always preferred over
shorter ones when forwarding a packet.
Note Existing connections continue to use their established interfaces even if a new similar connection would
result in different behavior due to a change in routes.
After the secondary members learn the routes from the primary unit, each unit makes forwarding decisions
independently.
The OSPF LSA database is not synchronized from the primary unit to secondary units. If there is a primary
unit switchover, the neighboring router will detect a restart; the switchover is not transparent. The OSPF
process picks an IP address as its router ID. Although not required, you can assign a static router ID to ensure
a consistent router ID is used across the cluster. See the OSPF Non-Stop Forwarding feature to address the
interruption.
These are some of the differences between route maps and ACLs:
• Route maps are more flexible than ACLs and can verify routes based on criteria which ACLs can not
verify. For example, a route map can verify if the type of route is internal.
• Each ACL ends with an implicit deny statement, by design convention. If the end of a route map is
reached during matching attempts, the result depends on the specific application of the route map. Route
maps that are applied to redistribution behave the same way as ACLs: if the route does not match any
clause in a route map then the route redistribution is denied, as if the route map contained a deny statement
at the end.
For each route that is being redistributed, the router first evaluates the match criteria of a clause in the route
map. If the match criteria succeeds, then the route is redistributed or rejected as dictated by the permit or deny
clause, and some of its attributes might be modified by the values set from the set commands. If the match
criteria fail, then this clause is not applicable to the route, and the software proceeds to evaluate the route
against the next clause in the route map. Scanning of the route map continues until a clause is found that
matches the route or until the end of the route map is reached.
A match or set value in each clause can be missed or repeated several times, if one of these conditions exists:
• If several match entries are present in a clause, all must succeed for a given route in order for that route
to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).
• If a match entry refers to several objects in one entry, either of them should match (the logical OR
algorithm is applied).
• If a match entry is not present, all routes match the clause.
• If a set entry is not present in a route map permit clause, then the route is redistributed without
modification of its current attributes.
Note Do not configure a set entry in a route map deny clause because the deny clause prohibits route
redistribution—there is no information to modify.
A route map clause without a match or set entry does perform an action. An empty permit clause allows a
redistribution of the remaining routes without modification. An empty deny clause does not allow a
redistribution of other routes (this is the default action if a route map is completely scanned, but no explicit
match is found).
Default Route
The simplest option is to configure a default route to send all traffic to an upstream router, relying on the
router to route the traffic for you. A default route identifies the gateway IP address to which the ASA sends
all IP packets for which it does not have a learned or static route. A default static route is simply a static route
with 0.0.0.0/0 as the destination IP address.
Static Routes
You might want to use static routes in the following cases:
• Your networks use an unsupported router discovery protocol.
• Your network is small and you can easily manage static routes.
• You do not want the traffic or CPU overhead associated with routing protocols.
• In some cases, a default route is not enough. The default gateway might not be able to reach the destination
network, so you must also configure more specific static routes. For example, if the default gateway is
outside, then the default route cannot direct traffic to any inside networks that are not directly connected
to the Firepower Threat Defense device.
• You are using a feature that does not support dynamic routing protocols.
Route Priorities
• Routes that identify a specific destination take precedence over the default route.
• When multiple routes exist to the same destination (either static or dynamic), then the administrative
distance for the route determines priority. Static routes are set to 1, so they typically are the highest
priority routes.
• When you have multiple static routes to the same destination with the same administrative distance, see
ECMP Routing, on page 705.
• For traffic emerging from a tunnel with the Tunneled option, this route overrides any other configured
or learned default routes.
The Firepower Threat Defense device implements static route tracking by associating a static route with a
monitoring target host on the destination network that the Firepower Threat Defense device monitors using
ICMP echo requests. If an echo reply is not received within a specified time period, the host is considered
down, and the associated route is removed from the routing table. An untracked backup route with a higher
metric is used in place of the removed route.
When selecting a monitoring target, you need to make sure that it can respond to ICMP echo requests. The
target can be any network object that you choose, but you should consider using the following:
• The ISP gateway (for dual ISP support) address
• The next hop gateway address (if you are concerned about the availability of the gateway)
• A server on the target network, such as a syslog server, that the Firepower Threat Defense device needs
to communicate with
• A persistent network object on the destination network
You can configure static route tracking for statically defined routes or default routes obtained through DHCP
or PPPoE. You can only enable PPPoE clients on multiple interfaces with route tracking configured.
IPv6
• Static route tracking is not supported for IPv6.
Clustering
In clustering, static route monitoring is only supported on the primary unit.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Click the Routing tab.
Step 3 Select Static Route from the table of contents.
Step 4 Click Add Routes.
Step 5 Click the IPv4 or IPv6 radio button depending on the type of static route that you are adding.
Step 6 Choose the Interface to which this static route applies.
For transparent mode, choose a bridge group member interface name. For routed mode with bridge groups,
you can choose either the bridge group member interface for the BVI name. To “black hole” unwanted traffic,
choose the Null0 interface.
Step 8 In the Gateway or IPv6 Gateway field, enter or choose the gateway router which is the next hop for this
route. You can provide an IP address or a Networks/Hosts object.
Step 9 In the Metric field, enter the number of hops to the destination network. Valid values range from 1 to 255;
the default value is 1. The metric is a measurement of the “expense” of a route, based on the number of hops
(hop count) to the network on which a specific host resides. Hop count is the number of networks that a
network packet must traverse, including the destination network, before it reaches its final destination. The
metric is used to compare routes among different routing protocols. The default administrative distance for
static routes is 1, giving it precedence over routes discovered by dynamic routing protocols but not directly
connected routes. The default administrative distance for routes discovered by OSPF is 110. If a static route
has the same administrative distance as a dynamic route, the static route takes precedence. Connected routes
always take precedence over static or dynamically discovered routes.
Step 10 (Optional) For a default route, click the Tunneled checkbox to define a separate default route for VPN traffic.
You can define a separate default route for VPN traffic if you want your VPN traffic to use a different default
route than your non VPN traffic. For example, traffic incoming from VPN connections can be easily directed
towards internal networks, while traffic from internal networks can be directed towards the outside. When
you create a default route with the tunneled option, all traffic from a tunnel terminating on the device that
cannot be routed using learned or static routes, is sent to this route. You can configure only one default tunneled
gateway per device. ECMP for tunneled traffic is not supported.
Step 11 (IPv4 static route only) To monitor route availability, enter or choose the name of an SLA (service level
agreement) Monitor object that defines the monitoring policy, in the Route Tracking field.
See SLA Monitor Objects, on page 416.
About OSPF
OSPF is an interior gateway routing protocol that uses link states rather than distance vectors for path selection.
OSPF propagates link-state advertisements rather than routing table updates. Because only LSAs are exchanged
instead of the entire routing tables, OSPF networks converge more quickly than RIP networks.
OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations. Each router
in an OSPF area contains an identical link-state database, which is a list of each of the router usable interfaces
and reachable neighbors.
The advantages of OSPF over RIP include the following:
• OSPF link-state database updates are sent less frequently than RIP updates, and the link-state database
is updated instantly, rather than gradually, as stale information is timed out.
• Routing decisions are based on cost, which is an indication of the overhead required to send packets
across a certain interface. The Firepower Threat Defense device calculates the cost of an interface based
on link bandwidth rather than the number of hops to the destination. The cost can be configured to
specify preferred paths.
The disadvantage of shortest path first algorithms is that they require a lot of CPU cycles and memory.
The Firepower Threat Defense device can run two processes of OSPF protocol simultaneously on different
sets of interfaces. You might want to run two processes if you have interfaces that use the same IP addresses
(NAT allows these interfaces to coexist, but OSPF does not allow overlapping addresses). Or you might want
to run one process on the inside and another on the outside, and redistribute a subset of routes between the
two processes. Similarly, you might need to segregate private addresses from public addresses.
You can redistribute routes into an OSPF routing process from another OSPF routing process, a RIP routing
process, or from static and connected routes configured on OSPF-enabled interfaces.
The Firepower Threat Defense device supports the following OSPF features:
• Intra-area, inter-area, and external (Type I and Type II) routes.
• Virtual links.
• LSA flooding.
• Authentication to OSPF packets (both password and MD5 authentication).
• Configuring the Firepower Threat Defense device as a designated router or a designated backup router.
The Firepower Threat Defense device also can be set up as an ABR.
• Stub areas and not-so-stubby areas.
• Area boundary router Type 3 LSA filtering.
OSPF supports MD5 and clear text neighbor authentication. Authentication should be used with all routing
protocols when possible because route redistribution between OSPF and other protocols (such as RIP) can
potentially be used by attackers to subvert routing information.
If NAT is used, if OSPF is operating on public and private areas, and if address filtering is required, then you
need to run two OSPF processes—one process for the public areas and one for the private areas.
A router that has interfaces in multiple areas is called an Area Border Router (ABR). A router that acts as a
gateway to redistribute traffic between routers using OSPF and routers using other routing protocols is called
an Autonomous System Boundary Router (ASBR).
An ABR uses LSAs to send information about available routes to other OSPF routers. Using ABR Type 3
LSA filtering, you can have separate private and public areas with the ASA acting as an ABR. Type 3 LSAs
(inter-area routes) can be filtered from one area to other, which allows you to use NAT and OSPF together
without advertising private networks.
Note Only Type 3 LSAs can be filtered. If you configure the Firepower Threat Defense device as an ASBR in
a private network, it will send Type 5 LSAs describing private networks, which will get flooded to the
entire AS, including public areas.
If NAT is employed but OSPF is only running in public areas, then routes to public networks can be redistributed
inside the private network, either as default or Type 5 AS external LSAs. However, you need to configure
static routes for the private networks protected by the Firepower Threat Defense device. Also, you should not
mix public and private networks on the same Firepower Threat Defense device interface.
You can have two OSPF routing processes, one RIP routing process, and one EIGRP routing process running
on the Firepower Threat Defense device at the same time.
Failover Guidelines
OSPFv2 and OSPFv3 support Stateful Failover.
IPv6 Guidelines
• OSPFv2 does not support IPv6.
• OSPFv3 supports IPv6.
• OSPFv3 uses IPv6 for authentication.
• The Firepower Threat Defense device installs OSPFv3 routes into the IPv6 RIB, provided it is the best
route.
Clustering Guidelines
• OSPFv3 encryption is not supported. An error message appears if you try to configure OSPFv3 encryption
in a clustering environment.
• In Spanned interface mode, dynamic routing is not supported on management-only interfaces.
• When a master role change occurs in the cluster, the following behavior occurs:
◦In spanned interface mode, the router process is active only on the master unit and is in a suspended
state on the slave units. Each cluster unit has the same router ID because the configuration has
been synchronized from the master unit. As a result, a neighboring router does not notice any
change in the router ID of the cluster during a role change.
Additional Guidelines
• OSPFv2 and OSPFv3 support multiple instances on an interface.
• OSPFv3 supports encryption through ESP headers in a non-clustered environment.
• OSPFv3 supports Non-Payload Encryption.
• OSPFv2 supports Cisco NSF Graceful Restart and IETF NSF Graceful Restart mechanisms as defined
in RFCs 4811, 4812 & 3623 respectively.
• OSPFv3 supports Graceful Restart mechanism as defined in RFC 5187.
• There is a limit to the number of intra area (type 1) routes that can be distributed. For these routes, a
single type-1 LSA contains all prefixes. Because the system has a limit of 35 KB for packet size, 3000
routes result in a packet that exceeds the limit. Consider 2900 type 1 routes to be the maximum number
supported.
Configure OSPFv2
This section describes the tasks involved in configuring an OSPFv2 routing process.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select Process 1. You can enable up to two OSPF process instances for each context. You must chose an
OSPF process to be able to configure the Area parameters.
Step 4 Chose the OSPF role from the drop-down list, and enter a description for it in the next field. The options are
Internal, ABR, ASBR, and ABR and ASBR. See About OSPF, on page 717 for a description of the OSPF
roles.
Step 5 Select the Area tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 6 Configure the following area options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Area ID—Designation of the area for which routes are to be summarized.
• Area Type—Choose one of the following:
◦Normal— (Default) Standard OSPF area.
◦Stub—A stub area does not have any routers or areas beyond it. Stub areas prevent Autonomous
System (AS) External LSAs (Type 5 LSAs) from being flooded into the stub area. When you create
a stub area, you can prevent summary LSAs (Types 3 and 4) from being flooded into the area by
NOT checking the Summary Stub check box.
◦NSSA—Makes the area a not-so-stubby area (NSSA). NSSAs accept Type 7 LSAs. You can
disable route redistribution by NOT checking the Redistribute check box and checking the Default
Information Originate check box. You can prevent summary LSAs from being flooded into the
area by NOT checking the Summary NSSA check box.
• Metric Value—The metric used for generating the default route. The default value is 10. Valid metric
values range from 0 to 16777214.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2
for a Type 2 external route.
• Available Network—Choose one of the available networks and click Add, or click the add icon ( )
to add a new network object. See Network Objects, on page 353 for the procedure for adding networks.
• Authentication—Choose the OSPF authentication:
◦None—(Default) Disables OSPF area authentication.
◦Password—Provides a clear text password for area authentication, which is not recommended
where security is a concern.
◦MD5—Allows MD5 authentication.
• Default Cost—The default cost for the OSPF area, which is used to determine the shortest paths to the
destination. Valid values range from 0 to 65535. The default value is 1.
What to Do Next
Continue with Configure OSPF Redistribution.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the Redistribution tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following redistribution options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Route Type—Choose one of the following types:
◦Static—Redistributes static routes to the OSPF routing process.
◦Connected—Redistributes connected routes (routes established automatically by virtue of having
the IP address enabled on the interface) to the OSPF routing process. Connected routes are
redistributed as external to the device. You can select whether to use subnets under the Optional
list .
◦OSPF—Redistributes routes from another OSPF routing process, for example, internal, external
1 and 2, NSSA external 1 and 2, or whether to use subnets. You can select these options under the
Optional list.
◦BGP—Redistribute routes from the BGP routing process. Add the AS number and whether to use
subnets.
◦RIP—Redistributes routes from the RIP routing process. You can select whether to use subnets
under the Optional list.
• Metric Value—Metric value for the routes being distributed. The default value is 10. Valid values range
from 0 to 16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric
will be carried through from one process to the other if no metric value is specified. When redistributing
other processes to an OSPF process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2
for a Type 2 external route.
• Tag Value—Tag specifies the 32-bit decimal value attached to each external route that is not used by
OSPF itself, but which may be used to communicate information between ASBRs. If none is specified,
then the remote autonomous system number is used for routes from BGP and EGP. For other protocols,
zero is used. Valid values are from 0 to 4294967295.
• RouteMap—Checks for filtering the importing of routes from the source routing protocol to the current
routing protocol. If this parameter is not specified, all routes are redistributed. If this parameter is
specified, but no route map tags are listed, no routes are imported. Or you can add a new route map by
clicking the add icon ( ). See Route Maps to add a new route map.
What to Do Next
Continue with Configure OSPF Inter-Area Filtering, on page 725.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the InterArea tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete inter-areas.
Step 4 Configure the following inter-area filtering options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Area ID—The area for which routes are to be summarized.
• PrefixList—The name of the prefix. To add a new prefix list object, see Step 5.
• Traffic Direction—Inbound or outbound. Choose Inbound to filter LSAs coming into an OSPF area,
or Outbound to filter LSAs coming out of an OSPF area. If you are editing an existing filter entry, you
cannot modify this setting.
Step 5 Click the add icon ( ), and enter a name for the new prefix list, and whether to allow overrides.
You must configure a prefix list before you can configure a prefix rule.
Step 6 Click Add to configure prefix rules, and configure the following parameters:
• Action—Select Block or Allow for the redistribution access.
• Sequence No—The routing sequence number. By default, sequence numbers are automatically generated
in increments of 5, beginning with 5.
• IP Address—Specify the prefix number in the format of IP address/mask length.
• Min Prefix Length—(Optional) The minimum prefix length.
• Max Prefix Length—(Optional)The maximum prefix length.
What to Do Next
Continue with Configure OSPF Filter Rules, on page 726.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the Filter Rule tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete filter rules.
Step 4 Configure the following filter rule options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Access List—The access list for this OSPF process. To add a new standard access list object, click the
add icon ( ) and see Configure Standard ACL Objects, on page 424.
• Traffic Direction—Choose In or Out for the traffic direction being filtered. Choose In to filter LSAs
coming into an OSPF area, or Out to filter LSAs coming out of an OSPF area. If you are editing an
existing filter entry, you cannot modify this setting.
• Interface—The interface for this filter rule.
What to Do Next
Continue with Configure OSPF Summary Addresses, on page 727.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the Summary Address tab, and click Add.
You can click the edit icon ( ) to edit, or use the right-click menu to cut, copy, past, insert, and delete
summary addresses.
Step 4 Configure the following summary address options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Available Network—The IP address of the summary address. Select one from the Available networks
list and click Add, or to add a new network, click the add icon ( ). See Network Objects, on page 353
for the procedure for adding networks.
• Tag—A 32-bit decimal value that is attached to each external route. This value is not used by OSPF
itself, but may be used to communicate information between ASBRs .
• Advertise— Advertises the summary route. Uncheck this check box to suppress routes that fall under
the summary address. By default, this check box is checked.
What to Do Next
Continue with Configure OSPF Interfaces and Neighbors, on page 728.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the Interface tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following Interface options for each OSPF process:
• Interface—The interface you are configuring.
• Default Cost—The cost of sending a packet through the interface. The default value is 10.
• Priority— Determines the designated router for a network. Valid values range from 0 to 255. The default
value is 1. Entering 0 for this setting makes the router ineligible to become the designated router or
backup designated router.
When two routers connect to a network, both attempt to become the designated router. The device with
the higher router priority becomes the designated router. If there is a tie, the router with the higher router
ID becomes the designated router. This setting does not apply to interfaces that are configured as
point-to-point interfaces.
• MTU Ignore— OSPF checks whether neighbors are using the same MTU on a common interface. This
check is performed when neighbors exchange DBD packets. If the receiving MTU in the DBD packet
is higher than the IP MTU configured on the incoming interface, OSPF adjacency is not established.
• Database Filter—Use this setting to filter the outgoing LSA interface during synchronization and
flooding. By default, OSPF floods new LSAs over all interfaces in the same area, except the interface
on which the LSA arrives. In a fully meshed topology, this flooding can waste bandwidth and lead to
excessive link and CPU usage. Checking this check box prevents OSPF flooding of the LSA on the
selected interface.
• Hello Interval—Specifies the interval, in seconds, between hello packets sent on an interface. Valid
values range from 1 to 8192 seconds. The default value is 10 seconds.
The smaller the hello interval, the faster topological changes are detected, but more traffic is sent on the
interface. This value must be the same for all routers and access servers on a specific interface.
• Transmit Delay—Estimated time in seconds to send an LSA packet on the interface. Valid values range
from 1 to 65535 seconds. The default is 1 second.
LSAs in the update packet have their ages increased by the amount specified by this field before
transmission. If the delay is not added before transmission over a link, the time in which the LSA
propagates over the link is not considered. The value assigned should take into account the transmission
and propagation delays for the interface. This setting has more significance on very low-speed links.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to
the interface. The time must be greater than the expected round-trip delay between any two routers on
the attached network. Valid values range from 1 to 65535 seconds. The default is 5 seconds.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message. If the router receives no acknowledgment, it resends the LSA. Be conservative when setting
this value, or needless retransmission can result. The value should be larger for serial lines and virtual
links.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors
indicate that the router is down. The value must be the same for all nodes on the network and can range
from 1 to 65535.
• Hello Multiplier—Specifies the number of Hello packets to be sent per second. Valid values are between
3 and 20.
• Point-to-Point—Lets you transmit OSPF routes over VPN tunnels.
• Authentication—Type of authentication algorithm. Supported values are SHA-1 and MD5. Click Add
and enter the Key ID, Key, and confirm the key.
• Enter Password—The password you configure if you choose Password as the type of authentication.
• Confirm Password—Confirm the password you chose.
Configuring the NSF graceful-restart feature involves two steps; configuring capabilities and configuring
a device as NSF-capable or NSF-aware. A NSF-capable device can indicate its own restart activities
to neighbors and a NSF-aware device can help a restarting neighbor.
A device can be configured as NSF-capable or NSF-aware, depending on some conditions:
• A device can be configured as NSF-aware irrespective of the mode in which it is.
• A device has to be in either Failover or Spanned Etherchannel (L2) cluster mode to be configured
as NSF-capable.
• For a device to be either NSF-aware or NSF-capable, it should be configured with the capability
of handling opaque Link State Advertisements (LSAs)/ Link Local Signaling (LLS) block as
required.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF, and click Advanced.
Step 3 Select the General tab, and configure the following:
• Router ID—Choose Automatic or IP address for the router ID. If you choose IP address, enter the IP
address in the IP Address field.
• Ignore LSA MOSPF—Suppresses syslog messages when the route receives unsupported LSA Type 6
multicast OSPF (MOSPF) packets.
• RFC 1583 Compatible—Configures RFC 1583 compatibility as the method used to calculate summary
route costs. Routing loops can occur with RFC 1583 compatibility enabled. Disable it to prevent routing
loops. All OSPF routers in an OSPF routing domain should have RFC compatibility set identically.
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure
the router to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
◦Log Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message
whenever an OSPF neighbor goes up or down. This setting is checked by default.
◦Log Adjacency Change Details—Causes the Firepower Threat Defense device to send a syslog
message whenever any state change occurs, not just when a neighbor goes up or down. This setting
is unchecked by default.
• Administrative Route Distances—Allows you to modify the settings that were used to configure
administrative route distances for inter-area, intra-area, and external IPv6 routes. The administrative
route distance is an integer from 1 to 254. The default is 110.
• LSA Group Pacing—Specifies the interval in seconds at which LSAs are collected into a group and
refreshed, check summed, or aged. Valid values range from 10 to 1800. The default value is 240.
• Enable Default Information Originate—Check the Enable check box to generate a default external
route into an OSPF routing domain and configure the following options:
◦Always advertise the default route—Ensures that the default route is always advertised.
◦Metric—Metric used for generating the default route. Valid metric values range from 0 to 16777214.
The default value is 10.
◦Metric Type—The external link type that is associated with the default route that is advertised
into the OSPFv3 routing domain. Valid values are 1 (Type 1 external route) and 2 (Type 2 external
route). The default is Type 2 external route.
◦Route Map—Choose the routing process that generates the default route if the route map is satisfied
or click the add icon ( ) to add a new one. See Route Maps to add a new route map.
e) Enable IETF Non Stop Forwarding—Enables non stop forwarding, which allows for the forwarding of
data packets to continue along known routes while the routing protocol information is being restored
following a switchover. OSPF uses extensions to the OSPF protocol to recover its state from neighboring
OSPF devices. For the recovery to work, the neighbors must support the NSF protocol extensions and be
willing to act as "helpers" to the device that is restarting. The neighbors must also continue forwarding
data traffic to the device that is restarting while protocol state recovery takes place.
Configure OSPFv3
This section describes the tasks involved in configuring an OSPFv3 routing process.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPFv3.
Step 3 By default Enable Process 1 is selected. You can enable up to two OSPF process instances.
Step 4 Chose the OSPFv3 role from the drop-down list, and enter a description for it. The options are Internal, ABR,
ASBR, and ABR and ASBR. See About OSPF, on page 717 for descriptions of the OSPFv3 roles.
Step 5 Select the Area tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 6 Select the General tab, and configure the following options for each OSPF process:
• Area ID—The area for which routes are to be summarized.
• Cost—The metric or cost for the summary route, which is used during OSPF SPF calculations to
determine the shortest paths to the destination. Valid values range from 0 to 16777215.
• Type—Specifies Normal, NSSA, or Stub. If you select Normal, there are no other parameters to configure.
If you select Stub, you can choose to send summary LSAs in the area. If you select NSSA, you can
configure the next three options:
◦Allow Sending summary LSA into this area—Allows the sending of summary LSAs into the
area.
◦Redistribute imports routes to normal and NSSA area—Allows redistribution to import routes
to normal and not to stubby areas.
◦Defaults information originate—Generates a default external route into an OSPFv3 routing
domain.
• Metric—Metric used for generating the default route. The default value is 10. Valid metric values range
from 0 to 16777214.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPFv3 routing domain. The available options are 1 for a Type 1 external route or
2 for a Type 2 external route.
Step 9 Configure the following route summary options for each OSPF process:
• IPv6 Prefix/Length—The IPv6 prefix. To add a new network object, click the add icon ( ). See
Network Objects, on page 353 for the procedure for adding networks.
• Cost—The metric or cost for the summary route, which is used during OSPF SPF calculations to
determine the shortest paths to the destination. Valid values range from 0 to 16777215.
• Advertise—Advertises the summary route. Uncheck this check box to suppress routes that fall under
the summary address. By default, this check box is checked.
attached network. The value must be greater than the expected round-trip delay, and can range from 1
to 65535. The default is 5.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message. If the router receives no acknowledgment, it resends the LSA. Be conservative when setting
this value, or needless retransmission can result. The value should be larger for serial lines and virtual
links.
• Transmit Delay—The estimated time in seconds that is required to send an LSA packet on the interface.
The integer value must be greater than zero. Valid values range from 1 to 8192. The default is 1.
LSAs in the update packet have their own ages incremented by this amount before transmission. If the
delay is not added before transmission over a link, the time in which the LSA propagates over the link
is not considered. The value assigned should take into account the transmission and propagation delays
for the interface. This setting has more significance on very low-speed links.
What to Do Next
Continue with Configure OSPFv3 Redistribution.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPF.
Step 3 Select the Redistribution tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following redistribution options for each OSPF process:
• Source Protocol—The source protocol from which routes are being redistributed. The supported protocols
are connected, OSPF, static, and BGP. If you choose OSPF, you must enter the Process ID in the Process
ID field. If you choose BCP, you must add the AS number in the AS Number field.
• Metric —Metric value for the routes being distributed. The default value is 10. Valid values range from
0 to 16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric
will be carried through from one process to the other if no metric value is specified. When redistributing
other processes to an OSPF process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2
for a Type 2 external route.
• Tag —Tag specifies the 32-bit decimal value attached to each external route that is not used by OSPF
itself, but which may be used to communicate information between ASBRs. If none is specified, then
the remote autonomous system number is used for routes from BGP and EGP. For other protocols, zero
is used. Valid values are from 0 to 4294967295.
• Route Map—Checks for filtering the importing of routes from the source routing protocol to the current
routing protocol. If this parameter is not specified, all routes are redistributed. If this parameter is
specified, but no route map tags are listed, no routes are imported. Or you can add a new route map by
clicking the add icon ( ). See Route Maps, on page 419 for the procedure to add a new route map.
• Process ID—The OSPF process ID, either 1 or 2.
Note The Process ID is enabled the OSPFv3 process is redistributing a route learned by another
OSPFv3 process.
• Match—Enables OSPF routes to be redistributed into other routing domains:
◦Internal for routes that are internal to a specific autonomous system.
◦External 1 for routes that are external to the autonomous system, but are imported into OSPFv3
as Type 1 external routes.
◦External 2 for routes that are external to the autonomous system, but are imported into OSPFv3
as Type 2 external routes.
◦NSSA External 1 for routes that are external to the autonomous system, but are imported into
OSPFv3 in an NSSA for IPv6 as Type 1 external routes.
◦NSSA External 2 for routes that are external to the autonomous system, but are imported into
OSPFv3 in an NSSA for IPv6 as Type 2 external routes.
What to Do Next
Continue with Configure OSPFv3 Summary Prefixes, on page 735.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPFv3.
Step 3 Select the Summary Prefix tab, and click Add.
You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete summary
prefixes.
Step 4 Configure the following summary prefix options for each OSPF process:
• IPv6 Prefix/Length—The IPv6 prefix and prefix length label. Select one from the list or click the add
icon ( ) to add a new network object. See Network Objects, on page 353 for the procedure for adding
networks.
• Advertise— Advertises routes that match the specified prefix and mask pair. Uncheck this check box
to suppress routes that match the specified prefix and mask pair.
• (Optional) Tag—A value that you can use as a match value for controlling redistribution through route
maps.
What to Do Next
Continue with Configure OSPFv3 Interfaces, Authentication, and Neighbors, on page 736.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPFv3.
Step 3 Select the Interface tab, and click Add.
You can click the Pencil icon to edit, or use the right-click menu to cut, copy, past, insert, and delete areas.
Step 4 Configure the following interface options for each OSPFv3 process:
• Interface—The interface you are configuring.
• Enable OSPFv3—Enables OSPFv3.
• OSPF Process—Choose 1 or 2.
Step 5 Select the Properties tab, and configuring the following options for each OSPFv3 process:
• Filter Outgoing Link Status Advertisements—Filters outgoing LSAs to an OSPFv3 interface. All
outgoing LSAs are flooded to the interface by default.
• Disable MTU mismatch detection—Disables the OSPF MTU mismatch detection when DBD packets
are received. OSPF MTU mismatch detection is enabled by default.
• Flood Reduction—Changes normal LSAs into Do Not Age LSAs, so that they don't get flooded every
3600 seconds across areas.
OSPF LSAs are refreshed every 3600 seconds. In large OSPF networks, this can lead to large amounts
of unnecessary LSA flooding from area to area.
• Point-to-Point Network—Lets you transmit OSPF routes over VPN tunnels. When an interface is
configured as point-to-point, non-broadcast, the following restrictions apply:
◦You can define only one neighbor for the interface.
◦You need to manually configure the neighbor.
◦You need to define a static route pointing to the crypto endpoint.
◦If OSPF over a tunnel is running on the interface, regular OSPF with an upstream router cannot
be run on the same interface.
◦You should bind the crypto map to the interface before specifying the OSPF neighbor to ensure
that the OSPF updates are passed through the VPN tunnel. If you bind the crypto map to the
interface after specifying the OSPF neighbor, use the clear local-host all command to clear OSPF
connections so that the OSPF adjacencies can be established over the VPN tunnel.
• Broadcast— Specifies that the interface is a broadcast interface. By default, this check box is checked
for Ethernet interfaces. Uncheck this check box to designate the interface as a point-to-point, nonbroadcast
interface. Specifying an interface as point-to-point, nonbroadcast lets you transmit OSPF routes over
VPN tunnels.
• Cost—Specifies the cost of sending a packet on the interface. Valid values for this setting range from
0 to 255. The default value is 1. Entering 0 for this setting makes the router ineligible to become the
designated router or backup designated router. This setting does not apply to interfaces that are configured
as point-to-point, nonbroadcast interfaces.
When two routers connect to a network, both attempt to become the designated router. The device with
the higher router priority becomes the designated router. If there is a tie, the router with the higher router
ID becomes the designated router.
• Priority—Determines the designated router for a network. Valid values range from 0 to 255.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors
indicate that the router is down. The value must be the same for all nodes on the network and can range
from 1 to 65535.
• Poll Interval— Time period in seconds between OSPF packets that the router will send before adjacency
is established with a neighbor. Once the routing device detects an active neighbor, the hello packet
interval changes from the time specified in the poll interval to the time specified in the hello interval.
Valid values range from 1 to 65535 seconds.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to
the interface. The time must be greater than the expected round-trip delay between any two routers on
the attached network. Valid values range from 1 to 65535 seconds. The default is 5 seconds.
• Transmit Delay—Estimated time in seconds to send a link-state update packet on the interface. Valid
values range from 1 to 65535 seconds. The default is 1 second.
Configuring the NSF graceful-restart feature involves two steps; configuring capabilities and configuring
a device as NSF-capable or NSF-aware. A NSF-capable device can indicate its own restart activities
to neighbors and a NSF-aware device can help a restarting neighbor.
A device can be configured as NSF-capable or NSF-aware, depending on some conditions:
• A device can be configured as NSF-aware irrespective of the mode in which it is.
• A device has to be in either Failover or Spanned Etherchannel (L2) cluster mode to be configured
as NSF-capable.
• For a device to be either NSF-aware or NSF-capable, it should be configured with the capability
of handling opaque Link State Advertisements (LSAs)/ Link Local Signaling (LLS) block as
required.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select Routing > OSPFv3, and click Advanced.
Step 3 For Router ID, choose Automatic or IP address. If you choose IP address, enter the IP address in the IP
Address field.
Step 4 Check the Ignore LSA MOSPF check box if you want to suppress syslog messages when the route receives
unsupported LSA Type 6 multicast OSPF (MOSPF) packets.
Step 5 Select the General tab, and configure the following:
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure
the router to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
◦Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message
whenever an OSPF neighbor goes up or down. This setting is checked by default.
◦Include Details—Causes the Firepower Threat Defense device to send a syslog message whenever
any state change occurs, not just when a neighbor goes up or down. This setting is unchecked by
default.
• Administrative Route Distances—Allows you to modify the settings that were used to configure
administrative route distances for inter-area, intra-area, and external IPv6 routes. The administrative
route distance is an integer from 1 to 254. The default is 110.
• Default Information Originate—Check the Enable check box to generate a default external route into
an OSPFv3 routing domain and configure the following options:
◦Always Advertise—Will always advertise the default route whether or not one exists.
◦Metric—Metric used for generating the default route. Valid metric values range from 0 to 16777214.
The default value is 10.
◦Metric Type—The external link type that is associated with the default route that is advertised
into the OSPFv3 routing domain. Valid values are 1 (Type 1 external route) and 2 (Type 2 external
route). The default is Type 2 external route.
◦Route Map—Choose the routing process that generates the default route if the route map is satisfied
or click the add icon ( ) to add a new one. See Route Maps, on page 419 to add a new route map.
• SPF Throttle—Specifies the delay in milliseconds to receive a change to the SPF calculation. The
default value is 5000 milliseconds. The minimum specifies the delay in milliseconds between the first
and second SPF calculations. The default value is 10000 milliseconds. The maximum specifies the
maximum wait time in milliseconds for SPF calculations. The default value is 10000 milliseconds.
Note For SPF throttling, if the minimum or maximum time is less than the first occurrence value,
then OSPFv3 automatically corrects to the first occurrence value. Similarly, if the maximum
delay specified is less than the minimum delay, then OSPFv3 automatically corrects to the
minimum delay value.
Step 13 Check the Enable graceful-restart (Use when Spanned Cluster or Failover Configured) and enter the
graceful-restart interval in seconds. The range is 1-1800. The default value is 120 seconds. For a restart interval
below 30 seconds, graceful restart will be terminated.
Step 14 Click OK to save the graceful restart configuration.
Step 15 Click Save on the Routing page to save your changes.
About BGP
BGP is an inter and intra autonomous system routing protocol. An autonomous system is a network or group
of networks under a common administration and with common routing policies. BGP is used to exchange
routing information for the Internet and is the protocol used between Internet service providers (ISP).
to as a suggestion because the external AS that is receiving the MEDs may also be using other BGP
attributes for route selection. The route with the lower MED metric is preferred.
• Origin—The origin attribute indicates how BGP learned about a particular route. The origin attribute
can have one of three possible values and is used in route selection.
◦IGP—The route is interior to the originating AS. This value is set when the network router
configuration command is used to inject the route into BGP.
◦EGP—The route is learned via the Exterior Border Gateway Protocol (EBGP).
◦Incomplete—The origin of the route is unknown or learned in some other way. An origin of
incomplete occurs when a route is redistributed into BGP.
• AS_path—When a route advertisement passes through an autonomous system, the AS number is added
to an ordered list of AS numbers that the route advertisement has traversed. Only the route with the
shortest AS_path list is installed in the IP routing table.
• Next hop—The EBGP next-hop attribute is the IP address that is used to reach the advertising router.
For EBGP peers, the next-hop address is the IP address of the connection between the peers. For IBGP,
the EBGP next-hop address is carried into the local AS.
• Community—The community attribute provides a way of grouping destinations, called communities,
to which routing decisions (such as acceptance, preference, and redistribution) can be applied. Route
maps are used to set the community attribute. The predefined community attributes are as follows:
◦no-export—Do not advertise this route to EBGP peers.
◦no-advertise—Do not advertise this route to any peer.
◦internet—Advertise this route to the Internet community; all routers in the network belong to it.
• If the local preferences are the same, prefer the path that was originated by BGP running on this router.
• If no route was originated, prefer the route that has the shortest AS_path.
• If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is
lower than EGP, and EGP is lower than incomplete).
• If the origin codes are the same, prefer the path with the lowest MED attribute.
• If the paths have the same MED, prefer the external path over the internal path.
• If the paths are still the same, prefer the path through the closest IGP neighbor.
• Determine if multiple paths require installation in the routing table for BGP Multipath, on page 745.
• If both paths are external, prefer the path that was received first (the oldest one).
• Prefer the path with the lowest IP address, as specified by the BGP router ID.
• If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster
list length.
• Prefer the path that comes from the lowest neighbor address.
BGP Multipath
BGP Multipath allows installation into the IP routing table of multiple equal-cost BGP paths to the same
destination prefix. Traffic to the destination prefix is then shared across all installed paths.
These paths are installed in the table together with the best path for load-sharing. BGP Multipath does not
affect best-path selection. For example, a router still designates one of the paths as the best path, according
to the algorithm, and advertises this best path to its BGP peers.
In order to be candidates for multipath, paths to the same destination need to have these characteristics equal
to the best-path characteristics:
• Weight
• Local preference
• AS-PATH length
• Origin code
• Multi Exit Discriminator (MED)
• One of these:
◦Neighboring AS or sub-AS (before the addition of the BGP Multipaths)
◦AS-PATH (after the addition of the BGP Multipaths)
These are the additional requirements for internal BGP (iBGP) multipath candidates:
• The path should be learned from an internal neighbor (iBGP).
• The IGP metric to the BGP next hop should be equal to the best-path IGP metric, unless the router is
configured for unequal-cost iBGP multipath.
BGP inserts up to n most recently received paths from multipath candidates into the IP routing table, where
n is the number of routes to install to the routing table, as specified when you configure BGP Multipath. The
default value, when multipath is disabled, is 1.
For unequal-cost load balancing, you can also use BGP Link Bandwidth.
Note The equivalent next-hop-self is performed on the best path that is selected among eBGP multipaths before
it is forwarded to internal peers.
IPv6 Guidelines
Supports IPv6. Graceful restart is not supported for IPv6 address family.
Configure BGP
To configure BGP, see the following topics:
Procedure
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select the Routing tab.
Step 3 Select BGP.
Step 4 Select the Enable BGP checkbox to enable the BGP routing process.
Step 5 In the AS Number field, enter the autonomous system (AS) number for the BGP process. The AS number
internally includes multiple autonomous numbers. The AS number can be from 1 to4294967295 or from 1.0
to 65535.65535. The AS number is a uniquely assigned value, that identifies each network on the Internet.
Step 6 (Optional) Edit the various BGP settings, starting with General. The defaults for these settings are appropriate
in most cases, but you can adjust them to fit the needs of your network. Click the Edit (pencil) button to edit
the settings in the group :
a) In the Router ID drop-down list, select Automatic or Manual from the drop-down list. If you choose
Automatic, the highest-level IP address on the Firepower Threat Defense device is used as the router ID.
To use a fixed router ID, choose Manual and enter an IPv4 address in theIP Address field. The default
value is Automatic.
b) Enter the number of AS numbers in AS_PATH attribute. An AS _PATH attribute is a sequence of
intermediate AS numbers between source and destination routers that form a directed route for packets to
travel. Valid values are between 1 and 254. The default value is None.
c) Check the Log Neighbor Changes check box to enable logging of BGP neighbor changes (up or down)
and resets. This helps in troubleshooting network connectivity problems and measuring network stability.
This is enabled by default.
d) Check the Use TCP Path MTU Discovery check box to use the Path MTU determining technique to
determine the maximum transmission unit (MTU) size on the network path between two IP hosts. This
avoids IP fragmentation. This is enabled by default.
e) Check the Reset session upon Failover check box to reset the external BGP session immediately upon
link failure. This is enabled by default.
f) Check the Enforce that the first AS is peer’s AS for EBGP routes check box to discard incoming updates
received from external BGP peers that do not list their AS number as the first segment in the AS_PATH
attribute. This prevents a mis-configured or unauthorized peer from misdirecting traffic by advertising a
route as if it was sourced from another autonomous system. This is enabled by default.
g) Check the Use dot notation for AS number check box to split the full binary 4-byte AS number into two
words of 16 bits each, separated by a dot. AS numbers from 0-65553 are represented as decimal numbers
and AS numbers larger than 65535 are represented using the dot notation. This is disabled by default.
h) Click OK.
Step 7 (Optional) Edit the Best Path Selection section:
a) Enter a value for Default Local Preference between 0 and 4294967295.The default value is 100. Higher
values indicate higher preference. This preference is sent to all routers and access servers in the local
autonomous system.
b) Check the Allow comparing MED from different neighbors check box to allow the comparison of Multi
Exit Discriminator (MED) for paths from neighbors in different autonomous systems. This is disabled by
default.
c) Check the Compare Router ID for identical EBGP paths check box to compare similar paths received
from external BGP peers during the best path selection process and switch the best path to the route with
the lowest router ID. This is disabled by default.
d) Check the Pick the best MED path among paths advertised from the neighboring AS check box to
enable MED comparison among paths learned from confederation peers. The comparison between MEDs
is made only if no external autonomous systems are there in the path. This is disabled by default.
e) Check the Treat missing MED as the least preferred one check box to consider the missing MED
attribute as having a value of infinity, making the path the least desirable; therefore, a path with a missing
MED is least preferred. This is disabled by default.
f) Click OK.
Step 8 (Optional) Edit the Neighbor Timers section:
a) Enter the time interval for which the BGP neighbor remains active after not sending a keepalive message
in the Keepalive interval field. At the end of this keepalive interval, the BGP peer is declared dead, if no
messages are sent. The default value is 60 seconds.
b) Enter the time interval for which the BGP neighbor remains active while a BGP connection is being
initiated and configured in the Hold time field. The default value is 180 seconds.
c) (Optional) Enter the minimum time interval for which the BGP neighbor remains active while a BGP
connection is being initiated and configured in the Min Hold time field. Specify a value from 0 to 65535.
d) Click OK.
Step 9 (Optional) Edit the Graceful Restart section:
Note This section is available only when the Firepower Threat Defensedevice is in failover or spanned
cluster mode. This is done so that there is no drop in packets in the traffic flow, when one of the
devices in the failover setup fails.
a) Check the Enable Graceful Restartcheckbox to enable Firepower Threat Defense peers to avoid a routing
flap following a switchover.
b) Specify the time duration that Firepower Threat Defense peers will wait to delete stale routes before a
BGP open message is received in the Restart Time field. The default value is 120 seconds. Valid values
are between 1 and 3600 seconds.
c) Enter the time duration that the Firepower Threat Defense will wait before deleting stale routes after an
end of record (EOR) message is received from the restarting Firepower Threat Defense in theStalepath
Time field. The default value is 360 seconds. Valid values are between 1 and 3600 seconds.
d) Click OK.
Step 10 Click Save.
Configure Route maps, Administrative Route Distances, Synchronisation, Next-hop, and packet forwarding.
The defaults for these settings are appropriate in most cases, but you can adjust them to fit the needs of your
network.
Procedure
Step 1 Choose Routing > BGP > IPv4or IPv6 and select the General tab.
Step 2 In the General tab, update the following sections:
a) In the Settings section, enter or select a Route Map object and enter a Scanning Interval for BGP routers
for next-hop validation. Valid values are from 5 to 60 seconds. The default value is 60. Click OK.
Note The Route Map field is applicable only to IPv4
settings
b) In the Routes and Synchronization section, update the following as required, and clickOK :
• (Optional) Generate Default Routes— Select this to configure, a BGP routing process to distribute
a default route (network 0.0.0.0).
• (Optional) Summarize subnet routes into network-level routes— Select this to configure automatic
summarization of subnet routes into network-level routes. This checkbox is applicable only to IPv4
settings.
• (Optional) Advertise inactive routes— Select this to advertise routes that are not installed in the
routing information base (RIB).
• (Optional) Synchronise between BGP and IGP system— Select this to enable synchronization
between BGP and your Interior Gateway Protocol (IGP) system. Usually, a BGP speaker does not
advertise a route to an external neighbor unless that route is local or exists in the IGP. This feature
allows routers and access servers within an autonomous system to have the route before BGP makes
it available to other autonomous systems.
• (Optional) Redistribute IBGP into IGP— Select this to configure iBGP redistribution into an
interior gateway protocol (IGP), such as OSPF.
c) In the Administrative Route Distances section, update the following as required, and clickOK :
• External — Enter the administrative distance for external BGP routes. Routes are external when
learned from an external autonomous system. The range of values for this argument are from 1 to
255. The default value is 20.
• Internal — Enter administrative distance for internal BGP routes. Routes are internal when learned
from peer in the local autonomous system. The range of values for this argument are from 1 to 255.
The default value is 200.
• Local — Enter administrative distance for local BGP routes. Local routes are those networks listed
with a network router show command, often as back doors, for the router or for the networks that is
being redistributed from another process. The range of values for this argument are from 1 to 255.
The default value is 200.
d) In the Next Hop section, optionally select the Enable address tracking checkbox to enable BGP next
hop address tracking and enter the Delay Interval between checks on updated next-hop routes installed
in the routing table. Click OK.
Note The Next Hop section is applicable only to IPv4
settings.
e) In the Forward Packets over Multiple Paths section, update the following as required and click OK:
• (Optional) Number of Paths — Specify the maximum number of Border Gateway Protocol routes
that can be installed in a routing table. The range of values are from 1 to 8. The default value is 1.
• (Optional) IBGP Number of Paths — Specify the maximum number of parallel internal Border
Gateway Protocol (iBGP) routes that can be installed in a routing table. The range of values are from
1 to 8. The default value is 1.
A BGP router needs to establish a connection with each of its peers before exchanging updates. These peers
are called BGP neighbors. Use the Neighbor tab to define BGP IPv4 or IPv6 neighbors and neighbor settings.
Procedure
Step 1 Choose Routing > BGP > IPv4or IPv6 and click the Neighbor tab.
Step 2 Click Add to define BGP neighbors and neighbor settings.
Step 3 Enter the BGP neighbor IP address. This IP address is added to the BGP neighbor table.
Step 4 Enter the BGP neighbor Interface.
Note The Interface field is only applicable to IPv6
settings.
Step 5 Enter the autonomous system to which the BGP neighbor belongs, in the Remote AS field.
Step 6 Select the Enabled address checkbox to enable communication with this BGP neighbor. Further neighbor
settings will be configured only if the Enabled address check box is selected.
Step 7 (Optional) Select the Shutdown administratively checkbox to disable a neighbor or peer group.
Step 8 (Optional) Select the Configure graceful restart checkbox to enable configuration of the BGP graceful restart
capability for this neighbor. After selecting this option, you must use the Graceful Restart (failover / spanned
mode) option to specify whether graceful restart should be enabled or disabled for this neighbor.
Note The graceful restart fields are only applicable to IPv4
settings.
Step 9 (Optional) Enter a Description for the BGP neighbor.
Step 10 (Optional) In the Filtering Routes tab, use access lists, route maps, prefix lists and AS path filters as required,
to distribute BGP Neighbor information. Update the following sections:
a) Enter or Select the appropriate incoming or outgoing Access List to distribute BGP neighbor information.
Note Access Lists are only applicable to IPv4
settings.
b) Enter or Select the appropriate incoming or outgoing Route Maps to apply a route map to incoming or
outgoing routes.
c) Enter or Select the appropriate incoming or outgoing Prefix List to distribute BGP neighbor information.
d) Enter or Select the appropriate incoming or outgoing AS path filter to distribute BGP neighbor information.
e) Select the Limit the number of prefixes allowed from the neighborto control the number of prefixes
that can be received from a neighbor.
• Enter the maximum number of prefixes allowed from a specific neighbor in the Maximum Prefixes
field.
• Enter the percentage (of maximum) at which the router starts to generate a warning message in the
Threshold Level field. Valid values are integers between 1 and 100. The default value is 75.
f) Select theControl prefixes received from the peer check box to specify additional controls for the prefixes
received from a peer. Do one of the following
• Select the Terminate peering when prefix limit is exceeded radio button to stop the BGP neighbor
when the prefix limit is reached. Specify the interval after which the BGP neighbor will restart in
the Restart interval field.
• Select Give only warning message when prefix limit is exceeded radio button to generate a log
message when the maximum prefix limit is exceeded. Here, the BGP neighbor will not be terminated.
g) Click OK.
Step 11 (Optional) In the Routes tab, specify miscellaneous Neighbor route parameter. Proceed to update the following:
a) Enter the minimum interval (in seconds) between the sending of BGP routing updates in the Advertisment
Interval field. Valid values are between 1 and 600.
b) Select the Remove private AS numbers from outbound routing updates to exclude the private AS
numbers from being advertised on outbound routes.
c) Select the Generate default routes checkbox to allow the local router to send the default route 0.0.0.0 to
a neighbor to use as a default route. Enter or Select the route map that allows the route 0.0.0.0 to be injected
conditionally in the Route map field.
d) To add conditionally advertised routes, click the Add Row + button. In the Add Advertised Route dialog
box, do the following:
1 Add or select a route map in the Advertise Map field, that will be advertised if the conditions of the
exist map or the non-exist map are met.
2 Select the Exist Map radio button and choose a route map from the Route Map Object Selector. This
route map will be compared with the routes in the BGP table, to determine whether or not the advertise
map route is advertised.
3 Select the Non-Exist Map radio button and choose a route map from the Route Map Object Selector.
This route map will be compared with the routes in the BGP table, to determine whether or not the
advertise map route is advertised.
4 Click OK.
Step 12 In the Timers tab, select the Set Timers for the BGP Peer check box to set the keepalive frequency, hold
time and minimum hold time
• Keepalive Interval — Enter the frequency (in seconds) with which the Firepower Threat Defense device
sends keepalive messages to the neighbor. Valid values are between 0 and 65535. The default value is
60 seconds.
• Hold time — Enter the interval (in seconds) after not receiving a keepalive message that theFirepower
Threat Defense device declares a peer dead. Valid values are between 0 and 65535. The default value
is 180 seconds.
• Min hold time — (Optional) Enter the minimum interval (in seconds) after not receiving a keepalive
message that the Firepower Threat Defense device declares a peer dead. Valid values are between 0 and
65535. The default value is 0 seconds.
b) (Optional) Select the Send Communty attribute to this neighbor check box to specify that communities
attributes should be sent to the BGP neighbor
c) (Optional) Select the Use FTD as next hop for this neighbor check box to configure the router as the
next-hop for a BGP speaking neighbor or peer group.
d) Select the Disable Connection Verification checkbox to disable the connection verification process for
eBGP peering sessions that are reachable by a single hop but are configured on a loopback interface or
otherwise configured with a non-directly connected IP address. When deselected (default), a BGP routing
process will verify the connection of single-hop eBGP peering session (TTL=254) to determine if the
eBGP peer is directly connected to the same network segment by default. If the peer is not directly connected
to same network segment, connection verification will prevent the peering session from being established.
e) Select the Allow connections with neighbor that is not directly connected radio button to accept and
attempt BGP connections to external peers residing on networks that are not directly connected. (Optional)
Enter the time-to-live in the TTL hops field. Valid values are between 1 and 255. Alternately, select the
Limited number of TTL hops to neighbor radio button, to secure a BGP peering session. Enter the
maximum number of hops that separate eBGP peers in the TTL hops field. Valid values are between 1
and 254.
f) (Optional) Select the Use TCP MTU path discovery check box to enable a TCP transport session for a
BGP session.
g) Choose the TCP connection mode from the TCP Transport Modedrop-down list. Options are Default,
Active, or Passive.
h) (Optional) Enter a Weight for the BGP neighbor connection.
i) Select the BGP Version that the Firepower Threat Defense device will accept from the drop-down list.
The version can be set to 4-Only to force the software to use only Version 4 with the specified neighbor.
The default is to use Version 4 and dynamically negotiate down to Version 2 if requested.
Step 14 Update the Migration tab, only if AS migration is considered.
Note The AS migration customization should be removed after transition has been completed.
a) (Optional) Select the Customize the AS number for routes received from the neighbor check box to
customize the AS_PATH attribute for routes received from an eBGP neighbor.
b) Enter the local autonomous system number in the Local AS number field. Valid values are any valid
autonomous system number from 1 to 4294967295 or 1.0 to65535.65535.
c) (Optional) Select the Do not prepend local AS number to routes received from neighbor check box
to prevent the local AS number from being prepended to any routes received from eBGP peer.
d) (Optional) Select the Replace real AS number with local AS number in routes received from neighbor
check box to replace the real autonomous system number with the local autonomous system number in
the eBGP updates. The autonomous system number from the local BGP routing process is not prepended.
e) (Optional) Select the Accept either real AS number or local AS number in routesreceived from
neighbor check box to configure the eBGP neighbor to establish a peering session using the real autonomous
system number (from the local BGP routing process) or by using the local autonomous system number.
Step 15 Click OK.
Step 16 Click Save.
BGP neighbors store and exchange routing information and the amount of routing information increases as
more BGP speakers are configured. Route aggregation is the process of combining the attributes of several
different routes so that only a single route is advertised. Aggregate prefixes use the classless interdomain
routing (CIDR) principle to combine contiguous networks into one classless set of IP addresses that can be
summarized in routing tables. As a result fewer routes need to be advertised. Use the Add/Edit Aggregate
Address dialog box to define the aggregation of specific routes into one route.
Procedure
Step 1 When editing a Firepower Threat Defense device, select Routing > BGP > IPv4or IPv6 and select the
Aggregate Address tab.
Step 2 Click the Aggregate Addresses tab.
Step 3 Enter a value for the aggregate timer (in seconds) in the Aggregate Timer field. Valid values are 0 or any
value between 6 and 60. The default value is 30.
Step 4 Click Add and update the Add Aggregate Address dialog:
a) Network — Enter an IPv4 address or select the desired network/hosts objects.
b) Attribute Map — (Optional) Enter or select the route map used to set the attribute of the aggregate route.
c) Advertise Map — (Optional) Enter or select the route map used to select the routes to create AS_SET
origin communities.
d) Suppress Map — (Optional) Enter or select the route map used to select the routes to be suppressed.
e) Generate AS set path Information— (Optional) Select the check box to enable generation of autonomous
system set path information.
f) Filter all routes from updates— (Optional) Select the check box to filter all more-specific routes from
updates.
g) Click OK.
What to Do Next
• For BGPv4 settings, proceed to Configure BGPv4 Filtering Settings, on page 754
• For BGPv6 settings, proceed to Configure BGP Network Settings, on page 755
Filtering settings are used to filter routes or networks received in incoming BGP updates. Filtering is used to
restrict routing information that the router learns or advertises.
Procedure
Step 1 Choose Routing > BGP > IPv4 and select the Filtering tab.
Step 2 Click Add and update the Add Filter dialog:
a) Access List— Select an access control list that defines which networks are to be received and which are
to be suppressed in routing updates.
b) Direction— (Optional) Select a direction that specifies if the filter should be applied to inbound updates
or outbound updates.
c) Protocol— (Optional) Select the routing process for which you want to filter: None, BGP, Connected,
OSPF, RIP, or Static.
d) Process ID— (Optional) Enter the process ID for the OSPF routing protocol.
e) Click OK.
Step 3 Click Save.
Network settings are used to add networks that will be advertised by the BGP routing process and route maps
that will be examined to filter the networks to be advertised.
Procedure
Step 1 Choose Routing > BGP > IPv4or IPv6 and select the Networks tab.
Step 2 Click Add and update the Add Networks dialog:
a) Network— Enter the network to be advertised by the BGP routing processes.
b) (Optional) Route Map— Enter or select a route map that should be examined to filter the networks to be
advertised. If not specified, all networks are redistributed.
c) Click OK.
Step 3 Click Save.
Redistribution settings allow you to define the conditions for redistributing routes from another routing domain
into BGP.
Procedure
Step 1 Choose Routing > BGP > IPv4or IPv6 and select the Redistribution tab.
Step 2 Click Add and update the Add Redistribution dialog:
a) Source Protocol— Select the protocol from which you want to redistribute routes into the BGP domain
from the Source Protocol drop-down list.
b) Process ID— Enter the identifier for the selected source protocol. Applies to the OSPF protocol.
c) Metric— (Optional) Enter a metric for the redistributed route.
d) Route Map— Enter or select a route map that should be examined to filter the networks to be redistributed.
If not specified, all networks are redistributed.
e) Match— The conditions used for redistributing routes from one routing protocol to another. The routes
must match the selected condition to be redistributed. You can choose one or more of the following match
conditions. These options are enabled only when OSPF is chosen as the Source Protocol.
• Internal
• External 1
• External 2
• NSSA External 1
• NSSA External 2
f) Click OK.
Route Injection settings allow you to define the routes to be conditionally injected into the BGP routing table.
Procedure
Step 1 Choose Routing > BGP > IPv4or IPv6 and select the Route Injection tab.
Step 2 Click Add and update the Add Route Injection dialog:
a) Inject Map— Enter or select the route map that specifies the prefixes to inject into the local BGP routing
table.
b) Exist Map— Enter or select the route map containing the prefixes that the BGP speaker will track.
c) Injected routes will inherit the attributes of the aggregate route— Select this to configure the injected
route to inherit attributes of the aggregate route.
d) Click OK.
Step 3 Click Save.
About RIP
The Routing Information Protocol, or RIP, as it is more commonly called, is one of the most enduring of all
routing protocols. RIP has four basic components: routing update process, RIP routing metrics, routing stability,
and routing timers. Devices that support RIP send routing-update messages at regular intervals and when the
network topology changes. These RIP packets include information about the networks that the devices can
reach, as well as the number of routers or gateways that a packet must travel through to reach the destination
address. RIP generates more traffic than OSPF, but is easier to configure.
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection. When RIP is
enabled on an interface, the interface exchanges RIP broadcasts with neighboring devices to dynamically
learn about and advertise routes.
The Firepower Threat Defense device supports both RIP Version 1 and RIP Version 2. RIP Version 1 does
not send the subnet mask with the routing update. RIP Version 2 sends the subnet mask with the routing update
and supports variable-length subnet masks. Additionally, RIP Version 2 supports neighbor authentication
when routing updates are exchanged. This authentication ensures that the Firepower Threat Defense device
receives reliable routing information from a trusted source.
RIP has advantages over static routes because the initial configuration is simple, and you do not need to update
the configuration when the topology changes. The disadvantage to RIP is that there is more network and
processing overhead than in static routing.
routers maintain only the best route (the route with the lowest metric value) to a destination. After updating
its routing table, the router immediately begins transmitting routing updates to inform other network routers
of the change. These updates are sent independently of the regularly scheduled updates that RIP routers send.
RIP Timers
RIP uses numerous timers to regulate its performance. These include a routing-update timer, a route-timeout
timer, and a route-flush timer. The routing-update timer clocks the interval between periodic routing updates.
Generally, it is set to 30 seconds, with a small random amount of time added whenever the timer is reset. This
is done to help prevent congestion, which could result from all routers simultaneously attempting to update
their neighbors. Each routing table entry has a route-timeout timer associated with it. When the route-timeout
timer expires, the route is marked invalid but is retained in the table until the route-flush timer expires.
Additional Guidelines
The following information applies to RIP Version 2 only:
• If using neighbor authentication, the authentication key and key ID must be the same on all neighbor
devices that provide RIP Version 2 updates to the interface.
• With RIP Version 2, the Firepower Threat Defense device transmits and receives default route updates
using the multicast address 224.0.0.9. In passive mode, it receives route updates at that address.
• When RIP Version 2 is configured on an interface, the multicast address 224.0.0.9 is registered on that
interface. When a RIP Version 2 configuration is removed from an interface, that multicast address is
unregistered.
Limitations
• The Firepower Threat Defense device cannot pass RIP updates between interfaces.
• RIP Version 1 does not support variable-length subnet masks.
• RIP has a maximum hop count of 15. A route with a hop count greater than 15 is considered unreachable.
• RIP convergence is relatively slow compared to other routing protocols.
• You can only enable a single RIP process on the Firepower Threat Defense device.
Configure RIP
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Select the Routing tab.
Step 3 Select RIP from the table of contents.
Step 4 Select the Enable RIP checkbox to configure the RIP settings.
Step 5 Select the RIP versions for sending and receiving RIP updates from the RIP Version drop-down list.
Step 6 (Optional) Select the Generate Default Route checkbox to generate a default route for distribution, based
on the route map that you specify.
a) Specify a route map name to use for generating default routes, in the Route Map field.
The default route 0.0.0.0/0 is generated for distribution over a certain interface , when the route map,
specified in the Route Map field, is present.
Step 7 When Send and Receive Version 2 is the chosen RIP Version, the Enable Auto Summary option is available.
When the Enable Auto Summary checkbox is checked, automatic route summarization is enabled. Disable
automatic summarization if you must perform routing between disconnected subnets. When automatic
summarization is disabled, subnets are advertised.
Note RIP Version 1 always uses automatic summarization—you cannot disable
it.
Step 8 Click the Networks tab. Define one or more networks for RIP routing. Enter IP address(es), or enter or select
the desired Network/Hosts objects. There is no limit to the number of networks you can add to the security
appliance configuration. Any interface that belongs to a network defined by this command, will participate
in the RIP routing process. The RIP routing updates will be sent and received only through interfaces on the
specified networks. Also, if the network of an interface is not specified, the interface will not be advertised
in any RIP updates.
Note RIP only supports IPv4
objects.
Step 9 (Optional) Click the Passive Interface tab. Use this option to specify passive interfaces on the appliance, and
by extension the active interfaces. The device listens for RIP routing broadcasts on passive interfaces, using
that information to populate its routing tables, but does not broadcast routing updates on passive interfaces.
Interfaces that are not designated as passive, receive and send updates.
Step 10 Click the Redistribution tab to manage redistribution routes. These are the routes that are being redistributed
from other routing processes into the RIP routing process.
a) Click Add to specify redistribution routes.
b) Select the routing protocol to redistribute into the RIP routing process, in the Protocol drop-down list.
Note For the OSPF protocol, specify a process ID. Similarly, specify an AS path for BGP. When you
choose the Connected option in the Protocol drop-down list, you can redistribute, directly
connected networks into the RIP routing process.
c) (Optional) If you are redistributing OSPF routes into the RIP routing process, you can select specific types
of OSPF routes to redistribute in the Match drop-down list . Ctrl-click to select multiple types:
• Internal – Routes internal to the autonomous system (AS) are redistributed.
• External 1 – Type 1 routes external to the AS are redistributed.
• External 2 – Type 2 routes external to the AS are redistributed.
• NSSA External 1 – Type 1 routes external to a not-so-stubby area (NSSA) are redistributed.
• NSSA External 2 – Type 2 routes external to an NSSA are redistributed
e) (Optional) Enter the name of a route map that must be satisfied, in the Route Map field before the route
can be redistributed into the RIP routing process. Routes are redistributed only if IP address matches an
allow statement in the route map address list.
f) Click OK.
Step 11 (Optional) Click the Filtering tab to manage filters for the RIP policy. In this section, filters are used to prevent
routing updates through an interface, control the advertising of routes in routing updates, control the processing
of routing updates and filtering sources of routing updates.
a) Click Add to add RIP filters.
b) Select the type of traffic to be filtered - Inbound or Outbound in the Traffic Direction field.
Note If traffic direction is inbound, you can only define an Interface
filter.
c) Specify whether the filter is based on an Interface or a Route, by selecting the appropriate radio button in
the Filter On field. If you select Interface, enter or Select the name of the interface on which routing
updates are to be filtered. If you select Route, choose the route type:
• Static – Only static routes are filtered.
• Connected – Only connected routes are filtered.
• OSPF – Only OSPFv2 routes discovered by the specified OSPF process are filtered. Enter the Process
ID of the OSPF process to be filtered.
• BGP – Only BGPv4 routes discovered by the specified BGP process are filtered. Enter the AS path
of the BGP process to be filtered.
d) In the Access List field, enter or select the name of one or more access control lists (ACLs) that define
the networks to be allowed or removed from RIP route advertisements.
e) Click OK.
Step 12 (Optional) Click the Broadcast tab to add or edit interface configurations. Using the Broadcast tab, you can
override the global RIP versions to send or receive per interface. You can also define the authentication
parameters per interface if you want to implement authentication to ensure valid RIP updates.
a) Click Add to add interface configurations.
b) Enter or Select an interface defined on this appliance in the Interface field.
c) In the Send option, select the appropriate boxes to specify sending updates using the RIP Version 1,
Version 2, or both. These options let you override, for the specified interface, the global Send versions
specified .
d) In the Receive option, select the appropriate boxes to specify accepting updates using the RIP Version
1, Version 2, or both. These options let you override, for the specified interface, the global Receive
versions specified .
e) Select the Authentication used on this interface for RIP broadcasts.
• None – No authentication
• MD5 – Employ MD5
• Clear Text – Employ clear-text authentication
If you choose MD5 or Clear Text, you must also provide the following authentication parameters.
• Key ID – The ID of the authentication key. Valid values are from 0 to 255.
• Key – The key used by the chosen authentication method. Can contain up to 16 characters
• Confirm – Enter the authentication key again, to confirm
f) Click OK.
Note The UDP and non-UDP transports are both supported for multicast routing. However, the non-UDP
transport has no FastPath optimization.
IGMP Protocol
IP hosts use the Internet Group Management Protocol (IGMP) to report their group memberships to
directly-connected multicast routers. IGMP is used to dynamically register individual hosts in a multicast
group on a particular LAN. Hosts identify group memberships by sending IGMP messages to their local
multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover
which groups are active or inactive on a particular subnet.
IGMP uses group addresses (Class D IP address) as group identifiers. Host group address can be in the range
of 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is never assigned to any group. The address 224.0.0.1
is assigned to all systems on a subnet. The address 224.0.0.2 is assigned to all routers on a subnet.
Note When you enable multicast routing on the Firepower Threat Defense device, IGMP Version 2 is
automatically enabled on all interfaces.
Note If the Firepower Threat Defense device is the PIM RP, use the untranslated outside address of the Firepower
Threat Defense device as the RP address.
send multicast traffic to the RP. If there is only one router per segment that forwards multicast traffic, there
will be no loops. The DF is chosen using the following mechanism:
• The router with the lowest metric to the RP is the DF.
• If the metric is equal, then the router with the highest IP address becomes the DF.
Note The Firepower Threat Defense device does not act as a C-RP, even though the C-RP is
a mandatory requirement for BSR traffic. Only routers can act as a C-RP. So, for BSR
testing functionality, you must add routers to the topology.
• BSR Election Mechanism — Each C-BSR originates Bootstrap messages (BSMs) that contain a BSR
Priority field. Routers within the domain flood the BSMs throughout the domain. A C-BSR that hears
about a higher-priority C-BSR than itself suppresses its sending of further BSMs for some period of
time. The single remaining C-BSR becomes the elected BSR, and its BSMs inform all the other routers
in the domain that it is the elected BSR.
Multicast Addresses
Multicast addresses specify an arbitrary group of IP hosts that have joined the group and want to receive traffic
sent to this group.
Clustering
Multicast routing supports clustering. In Layer 2 clustering, the primary unit sends all multicast routing packets
and data packets until fast-path forwarding is established. After fast-path forwarding is established, subordinate
units may forward multicast data packets. All data flows are full flows. Stub forwarding flows are also
supported. Because only one unit receives multicast packets in Layer 2 clustering, redirection to the primary
unit is common. In Layer 3 clustering, units do not act independently. All data and routing packets are processed
and forwarded by the primary unit. Subordinate units drop all packets that have been sent.
Firewall Mode
Supported only in routed firewall mode. Transparent firewall mode is not supported.
IPv6
Does not support IPv6.
Clustering
In clustering, for IGMP and PIM, this feature is only supported on the primary unit.
Additional Guidelines
You must configure an access control or prefilter rule on the inbound security zone to allow traffic to the
multicast host, such as 224.1.2.3. However, you cannot specify a destination security zone for the rule, or it
cannot be applied to multicast connections during initial connection validation.
Procedure
Note Only the UDP transport layer is supported for multicast routing.
The following table lists the maximum number of entries for specific multicast tables based on the amount
of RAM on the Firepower Threat Defense device. Once these limits are reached, any new entries are discarded.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 Check the Enable Multicast Routing check box.
Checking this check box enables IP multicast routing on the Firepower Threat Defense device. Unchecking
this check box disables IP multicast routing. By default, multicast is disabled. Enabling multicast routing
enables multicast on all interfaces.
You can disable multicast on a per-interface basis. This is useful if you know that there are no multicast hosts
on a specific interface and you want to prevent the Firepower Threat Defense device from sending host query
messages on that interface.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Protocol tab, click Add or Edit.
Use the Add IGMP parameters dialog box to add new IGMP parameters to the Firepower Threat Defense
device. Use the Edit IGMP parameters dialog box to change existing parameters.
Note All multicast routers on a subnet must support the same version of IGMP. The Firepower Threat
Defense device does not automatically detect Version 1 routers and switch to Version 1.
However, you can have a mix of IGMP Version 1 and 2 hosts on the subnet; the Firepower
Threat Defense device running IGMP Version 2 works correctly when IGMP Version 1 hosts
are present.
• Query Interval—The interval in seconds at which the designated router sends IGMP host-query
messages. The range is 1 to 3600. The default is 125.
Note If the Firepower Threat Defense device does not hear a query message on an interface for the
specified timeout value, then the Firepower Threat Defense device becomes the designated
router and starts sending the query messages.
• Response Time—The interval in seconds before the Firepower Threat Defense device deletes the group.
The range is 1 to 25. The default is 10.
If the Firepower Threat Defense device does not receive a response to a host query within this amount
of time, it deletes the group.
• Group Limit—The maximum number of hosts that can join on an interface. The range is 1 to 500. The
default is 500.
You can limit the number of IGMP states resulting from IGMP membership reports on a per-interface
basis. Membership reports exceeding the configured limits are not entered in the IGMP cache, and traffic
for the excess membership reports is not forwarded
• Query Timeout—The period of time in seconds before which the Firepower Threat Defense device
takes over as the requester for the interface after the previous requester has stopped. The range is 60 to
300. The default is 255.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > Access Group.
Step 3 On the Access Group tab, click Add or Edit.
Use the Add IGMP Access Group parameters dialog box to add new IGMP access groups to the Access
Group table. Use the Edit IGMP Access Group parameters dialog box to change existing parameters.
• Standard Access List— From the Standard Access List drop-down list, select the standard ACL
or click the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on
page 424 for the procedure.
• Extended Access List—From the Extended Access List drop-down list, select the extended ACL
or click the add icon ( ) to create a new extended ACL. See Configure Extended ACL Objects,
on page 423 for the procedure.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Static Group tab, click Add or Edit.
Use the Add IGMP Static Group parameters dialog box to statically assign a multicast group to an interface.
Use the Edit IGMP Static Group parameters dialog box to change existing static group assignments.
Note See Configure IGMP Static Groups, on page 773 if you want to forward multicast packets for a specific
group to an interface without the Firepower Threat Defense device accepting those packets as part of the
group.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Join Group tab, click Add or Edit.
Use the Add IGMP Join Group parameters dialog box to configure the Firepower Threat Defense device
to be a member of a multicast group. Use the Edit IGMP Join Group parameters dialog box to change
existing parameters.
Note PIM is not supported with PAT. The PIM protocol does not use ports, and PAT only works with protocols
that use ports.
Procedure
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Protocol tab, click Add or Edit.
Use the Add PIM parameters dialog box to add new PIM parameters to the interface. Use the Edit PIM
parameters dialog box to change existing parameters.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Neighbor Filter tab, click Add or Edit.
Use the Add PIM Neighbor Filter dialog box to add new PIM neighbor filters to the interface. Use the Edit
PIM Neighbor Filter dialog box to change existing parameters.
• If a permitted neighbor does not support bidirectional mode, then the DF election does not occur.
• If a denied neighbor supports bidirectional mode, then the DF election does not occur.
• If a denied neighbor does not support bidirectional mode, the DF election can occur.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Multicast Routing > PIM.
Step 3 On the Bidirectional Neighbor Filter tab, click Add or Edit.
Use the Add PIM Bidirectional Neighbor Filter dialog box to create ACL entries for the PIM bidirectional
neighbor filter ACL. Use the Edit PIM Bidirectional Neighbor Filter dialog box to change existing
parameters.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Rendezvous Points tab, click Add or Edit.
Use the Add Rendezvous Point dialog box to create a new entry to the Rendezvous Point table. Use the Edit
Rendezvous Point dialog box to change existing parameters.
Note This behavior is known as Shortest Path Switchover (SPT). We recommend that you always use the Shared
Tree option.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Route Tree tab, select the path for the route tree:
• Click the Shortest Path radio button to use the shortest-path tree for all multicast groups.
• Click the Shared Tree radio button to use the shared tree for all multicast groups.
• Click the Shared tree for below mentioned group radio button to designate the groups specified in
the Multicast Groups table, and then from the Standard Access List drop-down list, select a standard
ACL or click the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects,
on page 424 for the procedure.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Request Filter tab, define the multicast sources that are allowed to register with the Firepower Threat
Defense device when it acts as an RP:
• From the Filter PIM register messages using: drop-down list select None, Access List, or Route Map.
• If you choose Access List from the drop-down list, select an extended ACL or click the add icon (
)
to create a new extended ACL. See Configure Extended ACL Objects, on page 423 for the procedure.
Note In the Add Extended Access List Entry dialog box, select Allow from the drop-down list o
create a rule that allows the specified source of the specified multicast traffic to register with
the Firepower Threat Defense device, or select Block to create a rule that prevents the specified
source of the specified multicast traffic from registering with the Firepower Threat Defense
device.
• If you choose Route Map, select a route map from the Route Map drop-down list, or click the add icon
( ) to create a new route map. See Creating Network Objects for the procedure.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Bootstrap Router tab, check the Configure this FTD as a Candidate Bootstrap Router (C-BSR)
check box to perform the C-BSR setup.
a) From the Interface drop-down list, select the interface on the Firepower Threat Defense device from
which the BSR address is derived to make it a candidate.
This interface must be enabled with PIM.
b) In the Hash mask length field, enter the length of a mask (32 bits maximum) that is to be ANDed with
the group address before the hash function is called. All groups with the same seed hash (correspond) to
the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This fact
allows you to get one RP for multiple groups. The range is 0 to 32.
c) In the Priority field, enter the priority of the candidate BSR. The BSR with the larger priority is preferred.
If the priority values are the same, the router with the larger IP address is the BSR. The range is 0 to 255.
The default value is 0.
Step 4 (Optional) Click the add icon ( ) to select an interface on which no PIM BSR messages will be sent or
received in the Configure this FTD as a Border Bootstrap Router (BSR) section.
• From the Interface drop-down list, select the interface on which no PIM BSR messages will be sent or
received.
RP or BSR advertisements are filtered effectively isolating two domains of RP information exchange.
• Check the Enable Border BSR check box to enable BSR.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > Multicast Routes, and then click Add or Edit.
Use the Add Multicast Route Configuration dialog box to add a new multicast route to the Firepower Threat
Defense device. Use the Edit Multicast Route Configuration dialog box to change an existing multicast
route.
Step 3 From the Source Network drop-down box, select an existing network or click the add icon ( ) to add a new
one. See Creating Network Objects for the procedure.
Step 4 To configure an interface to forward the route, click the Interface radio button and configure the following
options:
• From the Source Interface drop-down list, select the incoming interface for the multicast route.
• From the Output Interface/Dense drop-down list, select the destination interface that the route is
forwarded through.
• In the Distance field, enter the distance of the multicast route. The range is 0 to 255.
Step 5 To configure an RPF address to forward the route, click the Address radio button and configure the following
options:
• In the RPF Address field, enter the IP address for the multicast route.
• In the Distance field, enter the distance of the multicast route The range is 0 to 255.
Procedure
Step 1 Choose Devices > Device Management, and edit the Firepower Threat Defense device.
Step 2 Choose Routing > Multicast Routing > Multicast Boundary Filter, and then click Add or Edit.
Use the Add Multicast Boundary Filter dialog box to add new multicast boundary filters to the Firepower
Threat Defense device. Use the Edit Multicast Boundary Filter dialog box to change existing parameters.
You can configure a multicast boundary for administratively scoped multicast addresses. A multicast boundary
restricts multicast data packet flows and enables reuse of the same multicast group address in different
administrative domains. When a multicast boundary is defined on an interface, only the multicast traffic
permitted by the filter ACL passes through the interface.
Step 3 From the Interface drop-down list, choose the interface for which you are configuring the multicast boundary
filter ACL.
Step 4 From the Standard Access List drop-down list, choose the standard ACL you want to use, or click the add
icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page 424 for the procedure.
Step 5 Check the Remove any Auto-RP group range announcement from the Auto-RP packets that are denied
by the boundary check box to filter Auto-RP messages from sources denied by the boundary ACL. If this
check box is not checked, all Auto-RP messages are passed.
Step 6 Click OK to save the multicast boundary filter configuration.
VPN Types
The Firepower Management Center supports the following types of VPN connections:
• Remote Access VPNs on Firepower Threat Defense devices.
Remote access VPNs are secure, encrypted connections, or tunnels, between remote users and your
company’s private network. The connection consists of a VPN endpoint device, which is a workstation
or mobile device with VPN client capabilities, and a VPN headend device, or secure gateway, at the
edge of the corporate private network.
Firepower Threat Defense devices can be configured to support Remote Access VPNs over SSL or IPsec
IKEv2 by the Firepower Management Center. Functioning as secure gateways in this capacity, they
authenticate remote users, authorize access, and encrypt data to provide secure connections to your
network. No other types of appliances, managed by the Firepower Management Center, support Remote
Access VPN connections.
Firepower Threat Defense secure gateways support the AnyConnect Secure Mobility Client full tunnel
client. This client is required to provide secure SSL IPsec IKEv2 connections for remote users. This
client gives remote users the benefits of a client without the need for network administrators to install
and configure clients on remote computers since it can be deployed to the client platform upon
connectivity. It is the only client supported on endpoint devices.
• Site-to-site VPNs on Firepower Threat Defense devices.
A site-to-site VPN connects networks in different geographic locations. You can create site-to-site IPsec
connections between managed devices, and between managed devices and other Cisco or third-party
peers that comply with all relevant standards. These peers can have any mix of inside and outside IPv4
and IPv6 addresses. Site-to-site tunnels are built using the Internet Protocol Security (IPsec) protocol
suite and IKEv1 or IKEv2. After the VPN connection is established, the hosts behind the local gateway
can connect to the hosts behind the remote gateway through the secure VPN tunnel.
• Site-to-site VPNs on 7000 and 8000 Series devices.
These site-to-site VPNs are referred to as Gateway VPNs or Firepower VPNs in the Firepower
Management Center. See Gateway VPNs, on page 1193, for information on this type of VPN connection.
VPN Basics
Tunneling makes it possible to use a public TCP/IP network, such as the Internet, to create secure connections
between remote users and private corporate networks. Each secure connection is called a tunnel.
IPsec-based VPN technologies use the Internet Security Association and Key Management Protocol (ISAKMP,
or IKE) and IPsec tunneling standards to build and manage tunnels. ISAKMP and IPsec accomplish the
following:
• Negotiate tunnel parameters.
• Establish tunnels.
• Authenticate users and data.
• Manage security keys.
• Encrypt and decrypt data.
• Manage data transfer across the tunnel.
• Manage data transfer inbound and outbound as a tunnel endpoint or router.
A device in a VPN functions as a bidirectional tunnel endpoint. It can receive plain packets from the private
network, encapsulate them, create a tunnel, and send them to the other end of the tunnel where they are
unencapsulated and sent to their final destination. It can also receive encapsulated packets from the public
network, unencapsulate them, and send them to their final destination on the private network.
After the site-to-site VPN connection is established, the hosts behind the local gateway can connect to the
hosts behind the remote gateway through the secure VPN tunnel. A connection consists of the IP addresses
and hostnames of the two gateways, the subnets behind them, and the method the two gateways use to
authenticate to each other.
• A limit to the time the device uses an encryption key before replacing it.
When IKE negotiation begins, the peer that starts the negotiation sends all of its policies to the remote peer,
and the remote peer searches for a match with its own policies, in priority order. A match between IKE policies
exists if they have the same encryption, hash (integrity and PRF for IKEv2), authentication, and Diffie-Hellman
values, and an SA lifetime less than or equal to the lifetime in the policy sent. If the lifetimes are not identical,
the shorter lifetime—From the remote peer policy—Applies. By default, the Firepower Management Center
deploys an IKEv1 policy at the lowest priority for all VPN endpoints to ensure a successful negotiation.
IPsec
IPsec is one of the most secure methods for setting up a VPN. IPsec provides data encryption at the IP packet
level, offering a robust security solution that is standards-based. With IPsec, data is transmitted over a public
network through tunnels. A tunnel is a secure, logical communication path between two peers. Traffic that
enters an IPsec tunnel is secured by a combination of security protocols and algorithms.
An IPsec Proposal policy defines the settings required for IPsec tunnels. An IPsec proposal is a collection of
one or more crypto-maps that are applied to the VPN interfaces on the devices. A crypto map combines all
the components required to set up IPsec security associations, including:
• A proposal (or transform set) is a combination of security protocols and algorithms that secure traffic
in an IPsec tunnel. During the IPsec security association (SA) negotiation, peers search for a proposal
that is the same at both peers. When it is found, it is applied to create an SA that protects data flows in
the access list for that crypto map, protecting the traffic in the VPN. There are separate IPsec proposals
for IKEv1 and IKEv2. In IKEv1 proposals (or transform sets), for each parameter, you set one value.
For IKEv2 proposals, you can configure multiple encryption and integration algorithms for a single
proposal.
• A crypto map, combines all components required to set up IPsec security associations (SA), including
IPsec rules, proposals, remote peers, and other parameters that are necessary to define an IPsec SA.
When two peers try to establish an SA, they must each have at least one compatible crypto map entry.
Dynamic crypto map policies are used in site-to-site VPNs when an unknown remote peer tries to start
an IPsec security association with the local hub. The hub cannot be the initiator of the security association
negotiation. Dynamic crypto-policies allow remote peers to exchange IPsec traffic with a local hub even
if the hub does not know the remote peer’s identity. A dynamic crypto map policy essentially creates a
crypto map entry without all the parameters configured. The missing parameters are later dynamically
configured (as the result of an IPsec negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies apply only in a hub-and-spoke and full-mesh VPN topologies. In a
point-to-point or full mesh VPN topology, you can apply only static crypto map policies. Emulate the
use of dynamic crypto-maps in a point-to-point topology by creating a hub-and-spoke topology with
two devices. Specify a dynamic IP address for the spoke and enable dynamic crypto-maps on this
topology.
VPN Licensing
There is no specific licensing for enabling Firepower Threat Defense VPN, it is available by default.
The Firepower Management Center determines whether to allow or block the usage of strong crypto on a
Firepower Threat Defense device based on attributes provided by the smart licensing server.
This is controlled by whether you selected the option to allow export-controlled functionality on the device
when you registered with Cisco Smart License Manager. If you are using the evaluation license, or you did
not enable export-controlled functionality, you cannot use strong encryption.
• 3DES—Triple DES, which encrypts three times using 56-bit keys, is more secure than DES because it
processes each block of data three times with a different key. However, it uses more system resources
and is slower than DES.
• DES—Data Encryption Standard, which encrypts using 56-bit keys, is a symmetric secret-key block
algorithm. It is faster than 3DES and uses less system resources, but it is also less secure. If you do not
need strong data confidentiality, and if system resources or speed is a concern, choose DES.
• Null—A null encryption algorithm provides authentication without encryption. This is typically used
for testing purposes only.
• MD5 (Message Digest 5)—Produces a 128-bit digest. MD5 uses less processing time for an overall
faster performance than SHA, but it is considered to be weaker than SHA.
• Null or None (NULL, ESP-NONE)—(IPsec Proposals only.) A null Hash Algorithm; this is typically
used for testing purposes only. However, you should choose the null integrity algorithm if you select
one of the AES-GCM/GMAC options as the encryption algorithm. Even if you choose a non-null option,
the integrity hash is ignored for these encryption standards.
If you select AES encryption, to support the large key sizes required by AES, you should use Diffie-Hellman
(DH) Group 5 or higher. IKEv1 policies allow groups 1, 2, and 5 only.
To implement the NSA Suite B cryptography specification, use IKEv2 and select one of the elliptic curve
Diffie-Hellman (ECDH) options: 19, 20, or 21. Elliptic curve options and groups that use 2048-bit modulus
are less exposed to attacks such as Logjam.
For IKEv2, you can configure multiple groups. The system orders the settings from the most secure to the
least secure and negotiates with the peer using that order. For IKEv1, you can select a single option only.
• 1—Diffie-Hellman Group 1: 768-bit modulus.
• 2—Diffie-Hellman Group 2: 1024-bit modulus.
• 5—Diffie-Hellman Group 5: 1536-bit modulus. Considered good protection for 128-bit keys.
• 14—Diffie-Hellman Group 14: 2048 bit modulus. Considered good protection for 192-bit keys.
• 19—Diffie-Hellman Group 19: 256 bit elliptic curve.
• 20—Diffie-Hellman Group 20: 384 bit elliptic curve.
• 21—Diffie-Hellman Group 21: 521 bit elliptic curve.
• 24—Diffie-Hellman Group 24: 2048-bit modulus and 256-bit prime order subgroup.
Pre-shared Keys
Preshared keys allow for a secret key to be shared between two peers. The key is used by IKE in the
authentication phase. The same shared key must be configured on each peer, or the IKE SA cannot be
established.
To configure the pre-shared keys, choose whether you will use a manual or automatically generated key, and
then speicify the key in the IKEv1/IKEv2 options. Then, when your configuration is deployed, the key is
configured on all devices in the topology.
Digital Certificates
When you use Digital Certificates as the authentication method for VPN connections, peers are configured
to obtain digital certificates from a Certificate Authority (CA). CAs are trusted authorities that “sign” certificates
to verify their authenticity, thereby guaranteeing the identity of the device or user.
CA servers manage public CA certificate requests and issue certificates to participating network devices as
part of a Public Key Infrastructure (PKI), this activity is called Certificate Enrollment. These digital certificates,
also called identity certificates contain:
• The digital identification of the owner for authentication, such as name, serial number, company,
department, or IP address.
• A public key needed to send and receive encrypted data to the certificate owner.
• The secure digital signature of a CA.
Certificates also provide non-repudiation of communication between two peers, meaning that it they prove
that the communication actually took place.
Certificate Enrollment
Using a PKI improves the manageability and scalability of your VPN since you do not have to configure
pre-shared keys between all the encrypting devices. Instead, you individually enroll each participating device
with a CA server, which is explicitly trusted to validate identities and create an identity certificate for the
device. When this has been accomplished, each participating peer sends their identity certificate to the other
peer to validate their identities and establish encrypted sessions with the public keys contained in the certificates.
See Certificate Enrollment Objects, on page 410for details on enrolling Firepower Threat Defense devices.
• Using the Simple Certificate Enrollment Protocol (SCEP) to retrieve the CA’s certificate from the CA
server
• Manually copying the CA's certificate from another participating device
Trustpoints
Once enrollment is complete, a trustpoint is created on the managed device. It is the object representation of
a CA and associated certificates. A trustpoint includes the identity of the CA, CA-specific parameters, and
an association with a single enrolled identity certificate.
PKCS#12 File
A PKCS#12, or PFX, file holds the server certificate, any intermediate certificates, and the private key in one
encrypted file. This type of file may be imported directly into a device to create a trustpoint.
Revocation Checking
A CA may also revoke certificates for peers that no longer participate in you network. Revoked certificates
are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation
list (CRL) stored on an LDAP server. A peer may check these before accepting a certificate from another
peer.
Define a pre-shared key for VPN authentication manually or automatically, there is no default key. When
choosing automatic, the Firepower Management Center generates a pre-shared key and assigns it to all the
nodes in the topology.
Implicit Topologies
In addition to the three main VPN topologies, other more complex topologies can be created as combinations
of these topologies. They include:
• Partial mesh—A network in which some devices are organized in a full mesh topology, and other devices
form either a hub-and-spoke or a point-to-point connection to some of the fully meshed devices. A partial
mesh does not provide the level of redundancy of a full mesh topology, but it is less expensive to
implement. Partial mesh topologies are used in peripheral networks that connect to a fully meshed
backbone.
• Tiered hub-and-spoke—A network of hub-and-spoke topologies in which a device can behave as a hub
in one or more topologies and a spoke in other topologies. Traffic is permitted from spoke groups to
their most immediate hub.
VPN Topology
To create a new site-to-site VPN topology you must, at minimum, give it a unique name, specify a topology
type, choose the IKE version that is used for IPsec IKEv1 or IKEv2, or both. Also, determine your authentication
method. Once configured, you deploy the topology to Firepower Threat Defense devices. The Firepower
Management Center configures site-to-site VPNs on Firepower Threat Defense devices only.
You can select from three types of topologies, containing one or more VPN tunnels:
• Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.
• Hub and Spoke deployments establish a group of VPN tunnels connecting a hub endpoint to a group of
spoke nodes.
• Full Mesh deployments establish a group of VPN tunnels among a set of endpoints.
Authentication
For authentication of VPN connections, configure a preshared key in the topology, or a trustpoint on each
device. Preshared keys allow for a secret key, used during the IKE authentication phase, to be shared between
two peers. A trustpoint includes the identity of the CA, CA-specific parameters, and an association with a
single enrolled identity certificate.
Extranet Devices
Each topology type can include Extranet devices, devices that you do not manage in Firepower Management
Center. These include:
• Cisco devices that Firepower Management Center supports, but for which your organization is not
responsible. Such as spokes in networks managed by other organizations within your company, or a
connection to a service provider or partner's network.
• Non-Cisco devices. You cannot use Firepower Management Center to create and deploy configurations
to non-Cisco devices.
Add non-Cisco devices, or Cisco devices not managed by the Firepower Management Center, to a VPN
topology as "Other" devices. Also specify the IP address of each remote device.
implemented between two firewalls (or other security gateways) that are connected over an untrusted
network, such as the Internet.
Procedure
Step 1 For certificate authentication for your VPNs, you must prepare the devices by allocating trustpoints as described
in Firepower Threat Defense Certificate Based Authentication, on page 445.
Step 2 Select Devices > VPN > Site To Site to manage your Firepower Threat Defense Site-to-site VPN configurations
and deployments. Choose from the following:
• Add—To create a new VPN topology, click Add VPN > Firepower Threat Defense Device, and
continue as instructed in Configuring Firepower Threat Defense Site-to-site VPNs, on page 800:
Note VPNs topologies can be created only on leaf domains.
• Edit—To modify the settings of an existing VPN topology, click the edit icon ( ). Modifying is similar
to configuring, continue as instructed above.
Note You cannot edit the topology type after you initially save it. To change the topology type, delete
the topology and create a new one.
Two users should not edit the same topology simultaneously; however, the web interface does
not prevent simultaneous editing.
• Delete—To delete a VPN deployment, click the delete icon ( ).
• View VPN status—This status applies to Firepower VPNs ONLY. Currently, no status is displayed for
Firepower Threat Defense VPNs. To determine the status of the Firepower Threat Defense VPNs, see
Firepower Threat Defense VPN Monitoring , on page 843.
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment
was successful.
Procedure
Step 1 Choose Devices > VPN > Site To Site.Then Add VPN > Firepower Threat Defense Device, or edit a listed
VPN Topology. .
Step 2 Enter a unique Topology Name. We recommend naming your topology to indicate that it is a Firepower
Threat Defense VPN, and its topology type.
Step 3 Choose the Network Topology for this VPN.
Step 4 Choose the IKE versions to use during IKE negotiations. IKEv1 or IKEv2.
Default is IKEv2. Select either or both options as appropriate; select IKEv1 if any device in the topology does
not support IKEv2.
Step 5 Add Endpoints for this VPN deployment by clicking the add icon ( ) for each node in the topology.
Configure each endpoint field as described in Firepower Threat Defense VPN Endpoint Options, on page
801.
• For Point to point, configure Node A and Node B.
• For Hub and Spoke, configure a Hub Node and Spoke Nodes
• For Full Mesh, configure multiple Nodes
Step 6 (Optional) Specify non-default IKE options for this deployment as described in Firepower Threat Defense
VPN IKE Options, on page 802
Step 7 (Optional) Specify non-default IPsec options for this deployment as described in Firepower Threat Defense
VPN IPsec Options, on page 803
Step 8 (Optional) Specify non-default Advanced options for this deployment as described in Firepower Threat
Defense Advanced Site-to-site VPN Deployment Options, on page 806.
Step 9 Click Save.
The endpoints are added to your configuration.
What to Do Next
Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment was
successful.
Navigation Path
Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN
Topology. Open the Endpoint tab.
Fields
Device
Choose an endpoint node for your deployment:
• A Firepower Threat Defense device managed by this Firepower Management Center.
• A Firepower Threat Defense high availability container managed by this Firepower Management
Center.
• An Extranet device, any device (Cisco or third-party) not managed by this Firepower Management
Center.
Device Name
For Extranet devices only, provide a name for this device. We recommend naming it such that it is
identifiable as an un-manaaged device.
Interface
If you chose a managed device as your endpoint, choose an interface on that managed device.
IP Address
• If you choose a device not managed by the Firepower Management Center, specify an IP address
for the endpoint.
• If you chose a managed device as an endpoint, choose a single IPv4 address or multiple IPv6
addresses from the drop-down list (these are the addresess already assigned to this interface on
this managed device).
• All endpoints in a topology must have the same IP addressing scheme. IPv4 tunnels can carry
IPv6 taffic and vice-versa. The Protected Networks define which addressing scheme the tunneled
traffic will use.
• If the managed device is a high-availability container, choose from a list of interfaces.
This IP is Private
Check the check box if the endpoint resides behind a firewall with network address translation (NAT).
Public IP address
If you checked the This IP is Private check box, specify a public IP address for the firewall. If the
endpoint is a responder, specify this value.
Connection Type
Specify the allowed negotiation as bidirectional, answer-only, or originate-only. Supported combinations
for the connection type are:
Bi-Directional Answer-Only
Bi-Directional Bi-Directional
Certificate Map
Choose a pre-configured certificate map object, or add a certificate map object that defines what
information is necessary in the received client certificate for it to be valid for VPN connectivity. See
Firepower Threat Defense Certificate Map Objects, on page 440 for details.
Protected Networks
Defines a list of networks protected by this VPN endpoint. Click the add icon ( ) to select from
available Network Objects or add Network Objects inline. See Creating Network Objects, on page 354.
Access Control Lists will be generated from the choices made here.
VPN endpoints cannot have the same IP address and protected networks in a VPN endpoint pair cannot
overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6 entries, the
other endpoint's protected network must have at least one entry of the same type (that is, IPv4 or IPv6).
If it does not, then the other endpoint's IP address must be of the same type and must not overlap with
the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128 CIDR address
blocks for IPv6.) If both of these checks fail, the endpoint pair is invalid.
Note Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.
Navigation Path
Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN
Topology. Open the IKE tab.
Fields
Policy
Choose a predefined IKEv1 or IKEv2 policy object or create a new one to use. For details, see Firepower
Threat Defense IKE Policies, on page 428
Authentication Type
Note In a VPN topology that supports IKEv1, the Authentication Method specified
in the chosen IKEv1 Policy object becomes the default in the IKEv1
Authentication Type setting. These values must match, otherwise, your
configuration will error.
• Pre-shared Automatic Key—The Management Center automatically defines the preshared key
that is used for this VPN. Specify the Pre-shared Key Length, the number of characters in the
key, 1-27.
• Pre-shared Manual Key—Manually assign the preshared key that is used for this VPN. Specify
the Key and then re-enter it in Confirm Key to confirm.
When this option is chosen for IKEv2, the Enforce hex-based pre-shared key only check box
appears, check if desired. If enforced, you must enter a valid hex value for the key, an even number
of 2-256 characters, using numerals 0-9, or A-F.
• Certificate—When you use Certificates as the authentication method for VPN connections, peers
obtain digital certificates from a CA server in your PKI infrastructure, and trade them to authenticate
each other.
In the Certificate field, select a pre-configured PKI Enrollment Object. This enrollment object
is used to generate a trustpoint with the same name on the managed device. The trustpoint is
created when the PKI enrollment object is associated with that device.
For a full explanation of the options, see Deciding Which Authentication Method to Use, on page 791.
Note Settings in this dialog apply to the entire topology, all tunnels, and all managed devices.
Crypto-Map Type
A crypto map combines all the components required to set up IPsec security associations (SA). When
two peers try to establish an SA, they must each have at least one compatible crypto map entry. The
proposals defined in the crypto map entry are used in the IPsec security negotiation to protect the data
flows specified by that crypto map’s IPsec rules. Choose static or dynamic for this deployment's
crypto-map:
• Static—Use a static crypto map in a point-to-point or full mesh VPN topology.
• Dynamic—Dynamic crypto-maps essentially create a crypto map entry without all the parameters
configured. The missing parameters are later dynamically configured (as the result of an IPsec
negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies apply only in a hub-and-spoke VPN configuration. In a point-to-point
or full mesh VPN topology, you can apply only static crypto map policies. Emulate the use of
dynamic crypto-maps in a point-to-point topology by creating a hub-and-spoke topology with
two devices. Specify a dynamic IP address for the spoke, and enable dynamic crypto map on this
topology.
IKEv2 Mode
For IPsec IKEv2 only, specify the encapsulation mode for applying ESP encryption and authentication
to the tunnel. This determines what part of the original IP packet has ESP applied.
• Tunnel mode—(default) Encapsulation mode is set to tunnel mode. Tunnel mode applies ESP
encryption and authentication to the entire original IP packet (IP header and data), hiding the
ultimate source and destination addresses and becoming the payload in a new IP packet.
The major advantage of tunnel mode is that the end systems do not need to be modified to receive
the benefits of IPsec. This mode allows a network device, such as a router, to act as an IPsec
proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts
packets and forwards them along the IPsec tunnel. The destination router decrypts the original IP
datagram and forwards it onto the destination system. Tunnel mode also protects against traffic
analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true
source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.
• Transport preferred— Encapsulation mode is set to transport mode with an option to fallback
to tunnel mode if the peer does not support it. In Transport mode only the IP payload is encrypted,
and the original IP headers are left intact. Therefore, the admin must select a protected network
that matches the VPN interface IP address.
This mode has the advantages of adding only a few bytes to each packet and allowing devices on
the public network to see the final source and destination of the packet. With transport mode, you
can enable special processing (for example, QoS) on the intermediate network based on the
information in the IP header. However, the Layer 4 header is encrypted, which limits examination
of the packet.
• Transport required— Encapsulation mode is set to transport mode only, falling back to tunnel
mode is not allowed. If the endpoints cannot successfully negotiate transport mode, due to one
endpoint not supporting it, the VPN connection is not made.
Proposals
Click ( ) to specify the proposals for your chosen IKEv1 or IKEv2 method. Select from the available
IKEv1 IPsec Proposals or IKEv2 IPsec Proposals objects, or create and then select a new one. See
Configure IKEv1 IPsec Proposal Objects, on page 432 and Configure IKEv2 IPsec Proposal Objects,
on page 433 for details.
Enable Security Association (SA) Strength Enforcement
Enabling this option ensures that the encryption algorithm used by the child IPsec SA is not stronger
(in terms of the number of bits in the key) than the parent IKE SA.
Lifetime (seconds)
The number of seconds a security association exists before expiring. The default is 28,800 seconds.
Lifetime (kbytes)
The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association
before it expires. The default is 4,608,000 kilobytes. No specification allows infinite data.
ESPv3 Settings
Navigation Path
Devices > VPN > Site To Site, then select Add VPN > Firepower Threat Defense Device, or edit a listed
VPN Topology. Open the Advanced tab, and select Tunnel in the navigation pane.
Tunnel Options
Only available for Hub and Spoke, and Full Mesh topologies. This section will not display for Point to Point
configurations.
• Enable Spoke to Spoke Connectivity through Hub—Disabled by default. Choosing this field enables
the devices on each end of the spokes to extend their connection through the hub node to the other device.
NAT Settings
• Keepalive Messages Traversal —Elect whether to enable NAT keepalive message traversal. NAT
traversal keepalive is used for the transmission of keepalive messages when there is a device (middle
device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPsec
flow.
If you select this option, configure the Interval, in seconds, between the keepalive signals sent between
the spoke and the middle device to indicate that the session is active. The value can be from 5 to 3600
seconds. The default is 20 seconds.
• Use the certificate OU field to determine the tunnel—Indicates that if a node is not determined based
on the configured mapping (the above option) if selected, then use the value of the organizational unit
(OU) in the subject distinguished name (DN) of the received certificate to determine the tunnel.
• Use the IKE identity to determine the tunnel—Indicates that if a node is not determined based on a
rule matching or taken from the OU (the above options) if selected, then the certificate-based IKE
sessions are mapped to a tunnel based on the content of the phase1 IKE ID.
• Use the peer IP address to determine the tunnel—Indicates that if a tunnel is not determined based
on a rule matching or taken from the OU or IKE ID methods (the above options) if selected, then use
the established peer IP address.
Note If you are using client certificates in your deployment, they must be added to your client's platform
independent of the Firepower Threat Defense or Firepower Management Center. No facilities, such as
SCEP or CA Services, are provided to populate your clients with certificates.
The login information provided by a remote user is validated by an LDAP/AD realm or a RADIUS server
group. These entities are integrated with the Firepower Threat Defense secure gateway.
Once authenticated via a VPN connection, the remote user takes on a VPN Identity.This VPN Identity is used
by Identity Policies on the Firepower Threat Defense secure gateway to recognize and filter network traffic
belonging to that remote user.
Identity policies are associated with access control policies, which determine who has access to network
resources. It is in this way, that the remote user is blocked from, or allowed access to, your network resources.
See the Realms and Identity Policies, on page 1957 and Getting Started with Access Control Policies, on page
1213 chapters for more information.
AAA
• Server authentication using self-signed or CA-signed identity certificates.
• AAA username and password-based remote authentication using RADIUS or LDAP/AD.
• RADIUS group and user authorization attributes, and RADIUS accounting.
• NGFW Access Control integration using VPN Identity.
VPN Tunneling
• Address assignment
• Split tunneling
• Split DNS
• Client Firewall ACLs
• Session Timeouts for maximum connect and idle time
Monitoring
• New VPN Dashboard Widget showing VPN Users by various characteristics such as Duration, Client
Application.
• RA VPN events including authentication information such as username and OS platform.
• Tunnel statistics available using the Firepower Threat Defense Unified CLI.
Configuration
• You can only add a new RA VPN Policy by walking through the wizard. You must proceed through the
entire wizard to create a new policy, no policy will be saved if you cancel before completing the wizard.
• Two users should not edit an RA VPN Policy at the same time; however, the web interface does not
prevent simultaneous editing. If this occurs, the last saved configuration persists.
• Moving a Firepower Threat Defense device from one domain to another domain is not possible if a
Remote Access VPN policy is assigned to that device.
• If you are using client certificates in your deployment, they must be added to your client's platform
independent of the Firepower Threat Defense or Firepower Management Center. No facilities, such as
SCEP or CA Services, are provided to populate your clients with certificates.
Procedure
Note You must ensure that the AAA Server is reachable from the Firepower Threat Defense device
for the remote access VPN solution to work. For more information on configuration and
troubleshooting, see AAA Server Connectivity, on page 825
When the wizard has been completed, you return to this Policy listing page. Set up access control for
VPN users and enable NAT exemption (if necessary) to complete a basic RA VPN Policy configuration.
Then, deploy the configuration, and establish VPN connections.
•( ) Edit—Modify an existing Remote Access VPN policy. Click the edit icon or the VPN policy row
to open the policy for editing. See Editing Firepower Threat Defense Remote Access VPN Policy, on
page 817 for details.
Note Two users should not edit an RA VPN Policy at the same time; however, the web interface
does not prevent simultaneous editing. If this occurs, the last saved configuration persists.
•( ) Delete—Delete a Remote Access VPN configuration.
What to Do Next
Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment was
successful.
Procedure
Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
The major components of a Remote Access policy are shown.
Step 3 To add or edit a Connection Profile, see Adding and Editing Firepower Threat Defense Remote Access VPN
Connection Profile, on page 818.
Step 4 To add or edit Access Interfaces, see Firepower Threat Defense Remote Access VPN Access Interface
Options, on page 827.
Step 5 Choose the Advanced tab to complete the Remote Access VPN configuration:
a) To set up AnyConnect Client Images, see About Firepower Threat Defense Cisco AnyConnect Secure
Mobility Client Image, on page 829.
b) To set up the Address Assignment Policy, see About Firepower Threat Defense Remote Access VPN
Address Assignment Policy, on page 831.
c) To configure Certificate Maps for this connection profile, see Configuring Certificate Maps, on page
832.
d) Choose Group Policies from the navigation pane to add more Group Policies that can be assigned to
remote users using this connection profile. These are in addition to the default group policy specified when
the profile was created. See Configuring Group Policies, on page 832.
e) To edit IPsec options, see Editing Firepower Threat Defense IPsec Settings, on page 834.
Adding and Editing Firepower Threat Defense Remote Access VPN Connection Profile
Remote Access VPN policy contains the Connection Profiles targeted for specific devices. These policies
pertain to creating the tunnel itself, such as, how AAA is accomplished, and how addresses are assigned
(DHCP or Address Pools) to VPN clients. They also include user attributes, which are identified in group
policies configured on the Firepower Threat Defense device or obtained from a AAA server. A device also
provides a default connection profile named DefaultWEBVPNGroup. The connection profile that is configured
using the wizard appears in the list.
Procedure
Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
The major components of a Remote Access policy are shown.
Step 3 Select a Connection Profile and click the corresponding Edit icon.
The edit connection profile page is displayed. For more information, see Firepower Threat Defense Remote
Access VPN Connection Profile Options, on page 819
Related Topics
Firepower Threat Defense Remote Access VPN Connection Profile Options, on page 819
Firepower Threat DefenseRemote Access VPN Connection Profile
Firepower Threat Defense Remote Access VPN Access Interface Options, on page 827
Firepower Threat Defense Remote Access VPN IPsec/IKEv2 Parameters Page, on page 839
About Aliases, on page 827
About Client Address Assignment, on page 819
Fields
The Connection Profile page lists the profiles created under the Remote Access VPN policy. The table lists
information about client address assignment, group policy, and AAA options.
To add a connection profile, choose the Add icon and specify the following in the Add Connection Profile
window:
• Connection Profile—Provide a name that the remote users will use for VPN connections. Specifies a
set of parameters that define how the remote users connect to the VPN device. For more information
about Connection Profile, see Adding and Editing Firepower Threat Defense Remote Access VPN
Connection Profile, on page 818
• Group Policy— A collection of user-oriented attributes which are applied to the client when the VPN
connectivity is established. Group policies configure common attributes for groups of users. For more
information about Group Policy, see Configuring Group Policies, on page 832.
Choose the Add icon to add a new group policy for the connection profile.
Related Topics
Firepower Threat DefenseRemote Access VPN Connection Profile
Adding and Editing Firepower Threat Defense Remote Access VPN Connection Profile, on page 818
Editing Firepower Threat Defense Remote Access VPN Policy, on page 817
Configuring Group Policies, on page 832
Remote Access VPN AAA Settings, on page 820
About Client Address Assignment, on page 819
About Aliases, on page 827
Note You can use the IP address from the already created pools in Firepower Management Center or create a
new pool using the Add option. Also, you can create a IP pool to Firepower Management Center using
the Objects > Object Management > Address Pools path. For more information, see Address Pools,
on page 441.
• Address Pools—Specifies the name and IP address range from the selected pool. Select the Add icon
and choose the pool from the list. Select the Edit icon to edit the selected address pool. To delete a
address pool, select the Delete icon in that row.
Note If you share your Remote Access VPN configuration among multiple Firepower Threat
Defense devices, bear in mind that all devices share the same address pool unless you
use device-level object overrides to replace the global definition with a unique address
pool for each device. Unique address pools are required to avoid overlapping addresses
in cases where the devices are not using NAT.
Select the Add icon in the Address Pools window to add a new IPv4 address or IPv6 address pool.
When you choose the IPv4 pool, provide a starting and ending IP address. When you choose to include
a new IPv6 address pool, enter Number of Addresses in the range 1-16384. Select the Allow Overrides
option to avoid conflicts with IP address when objects are shared across many devices. For more
information, see Address Pools, on page 441.
• DHCP Servers—Specifies the name and DHCP ( Dynamic Host Configuration Protocol) server address
as network objects. Select the Add icon and choose the server from the object list. To delete a DHCP
server, select the Delete icon in that row.
Select the Add icon in the New Network Objects window to add a new network object. Enter the new
object name, description, network, and select the Allow Overrides option as applicable. For more
information, see Creating Network Objects, on page 354 and Allowing Object Overrides, on page 352.
Note The DHCP server address can be configured only with IPv4 address.
Related Topics
About Aliases, on page 827
Remote Access VPN AAA Settings, on page 820
Firepower Threat Defense Remote Access VPN Connection Profile Options, on page 819
Editing Firepower Threat Defense IPsec Settings, on page 834
About Firepower Threat Defense Remote Access VPN Address Assignment Policy, on page 831
section Understanding Policy Enforcement of Permissions and Attributes to understand more about remote
access VPN authorization.
Note Before you add or edit the Remote Access VPN policy, you must configure the Realm and RADIUS server
groups you want to specify. For more information, see Creating a Realm, on page 1963 and RADIUS Server
Groups, on page 442.
Without DNS configured, the device cannot resolve AAA server names, named URLs, and CA Servers
with FQDN or Hostnames, it can only resolve IP addresses. Configure DNS by creating a FlexConfig
policy using a FlexConfig objects with the DNS configuration CLI commands. For more information, see
Configure the FlexConfig Policy, on page 648 and Configure FlexConfig Objects, on page 642.
• Authentication Method—It is the way a user is identified before being allowed access to the network
and network services. It controls access by requiring valid user credentials, which are typically a username
and password. It may also include the certificate from the client. Supported authentication methods are
AAA only, Client Certificate only, and AAA + Client Certificate.
When you select the Authentication Method as:
◦AAA Only—If you select the Authentication Server as RADIUS, by default, the Authorization
Server has the same value. Select the Accounting Server from the drop-down list. Whenever you
select AD and LDAP from the Authentication Server drop-down list, you must manually select
the Authorization Server and Accounting Server respectively.
◦Client Certificate Only—User is authenticated using client certificate. Client certificate must be
configured on VPN client endpoints. By default, user name is derived from client certificate fields
CN & OU respectively. In case, user name is specified in other fields in the client certificate, use
'Primary' and 'Secondary' field to map appropriate fields.
If you select Map specific field option, which includes the username from the client certificate.
The Primary and Secondary fields display default values: CN (Common Name) and OU
(Organisational Unit) respectively. If you select the Use entire DN as username option, the
system automtically retrieves the user identity. A distinguished name (DN) is a unique identification,
made up of individual fields, that can be used as the identifier when matching users to a connection
profile. DN rules are used for enhanced certificate authentication.
Primary and Secondary fields pertaining to the Map specific field option contains these common
values:
◦C (Country)
◦CN (Common Name)
◦DNQ (DN Qualifier
◦EA (Email Address)
◦GENQ (Generational Qualifier)
◦GN (Given Name)
◦I (Initial)
◦L (Locality)
◦N (Name)
◦O (Organisation)
◦OU (Organisational Unit)
◦SER (Serial Number)
◦SN (Surname)
◦SP (State Province)
◦T (Title)
◦UID (User ID)
◦UPN (User Principal Name)
◦Client Certificate & AAA—Both types of authentication are done, see AAA Only and Client
Certificate Only descriptions.
Whichever authentication method you choose, select or deselect Allow connection only if user
exists in authorization database.
• Authentication Server—Authentication is the way a user is identified before being allowed access to
the network and network services. Authentication requires valid user credentials, certificate, or both.
You can use authentication alone or with authorization and accounting.
Enter or select a LDAP or AD realm or a RADIUS server group that have been previously configured
to authenticate Remote Access VPN users.
• Authorization Server—Enter or select a RADIUS server group object that has been pre-configured to
authorize Remote Access VPN users.
After authentication is complete, authorization controls the services and commands available to each
authenticated user. Authorization works by assembling a set of attributes that describe what the user is
authorized to perform, their actual capabilities, and restrictions. Were you not to use authorization,
authentication alone would provide the same access to all authenticated users. Authorization requires
authentication. Only RADIUS servers are supported for Authorization services. To know more about
how remote access VPN authorization works, please refer to the section Understanding Policy
Enforcement of Permissions and Attributes later in this page.
Check Allow connection only if user exists in authorization database if desired.
When enabled, the username of the client must exist in the authorization database to allow a successful
connection. If the username does not exist in the authorization database, then the connection is denied.
When a RADIUS Server is configured for user authorization in the Connection Profile, the Remote
Access VPN system administrator can configure multiple authorization attributes for users or user-groups.
The authorization attributes that are configured on the RADIUS server can be specific for a user or a
user-group. Once users are authenticated, these specific authorization attributes are pushed to the
Firepower Threat Defense device.
Note The obtained AAA server attributes override the attribute values that may have been
previously configured on the Group Policy or the Connection Profile.
• Accounting Server—Enter or select the RADIUS Server Group object that will be used to account for
the Remote Access VPN session.
Accounting is used to track the services users are accessing, as well as the amount of network resources
they are consuming. When AAA accounting is activated, the network access server reports user activity
to the RADIUS server. Accounting information includes when sessions start and stop, usernames, the
number of bytes that pass through the device for each session, the service used, and the duration of each
session. This data can then be analyzed for network management, client billing, or auditing. You can
use accounting alone or together with authentication and authorization.
• Strip Realm from username—Whether to remove the realm from the username before passing the
username on to the AAA server. For example, if you select this option and provide domain\username,
the domain is stripped off from the username and sent to AAA server for authentication. By default this
option is unchecked.
• Strip Group from username—Whether to remove the group name from the username before passing
the username on to the AAA server. By default this option is unchecked.
Note A realm is an administrative domain. Enabling these options allows the authentication
to be based on the username alone. You can enable any combination of these options.
However, you must select both check boxes if your server cannot parse delimiters.
• Password Management—Enable managing the password for the Remote Access VPN users. Select to
notify ahead of the password expiry or on the day the password expires.
Note Unlike ASA, the Firepower Threat Defense device does not support inheriting system default attributes
from the default group policy DfltGrpPolicy. The attributes on the group policy assigned to the connection
profile are finally used for the user session, if they are not overridden by user attributes or the group policy
from the AAA server as indicated above.
RADIUS Authorization
As indicated above, the Firepower Threat Defense device supports applying user authorization attributes (also
called user entitlements or permissions) to VPN connections from the external RADIUS server that are
configured for authentication and/or authorization in the remote access VPN policy.
The following link lists all the supported RADIUS authorization attributes for ASA, which should also be
applicable forFirepower Threat Defense devices for Remote Access VPN authorization. http://www.cisco.com/
c/en/us/td/docs/security/asa/asa97/configuration/general/asa-97-general-config/
aaa-radius.html#ID-2113-0000003a
Note Firepower Threat Defense devices support attributes with vendor ID 3076. Please refer to this link to
configure RADIUS authorization on the commonly used RADIUS servers.
https://www.cisco.com/c/en/us/td/docs/security/asa/asa90/configuration/guide/asa_90_cli_config/ref_
extserver.html#24640
RADIUS attributes 146 and 150 are sent from Firepower Threat Defense devices to the RADIUS server for
authentication and authorization requests. All three (146, 150, and 151) previously listed attributes are sent
from Firepower Threat Defense devices to the RADIUS server for accounting start, interim-update, and stop
requests.
Only the following are the downstream RADIUS attribute numbers that are officially supported for the
Firepower Threat Defense device:
• Group-Policy (Attribute Number = 25) - Sets the group policy for the remote access VPN session. You
can use one of the following formats:
group policy name
OU=group policy name
OU=group policy name;
• Access-hours (Attribute Number = 1)
• Banner (Attribute Number = 15, 36)
• IP Address Pools (Attribute Number = 217)
The IP Address pool name is configured on the RADIUS Server and it requires the IP Address pool
with the same name to be configured and deployed on the device to be used during RADIUS authorization.
In order to use an IP address pool, create a connection profile in the remote access VPN policy and
configure the IP address pools in it, so that the IP address pools can be deployed on the Firepower Threat
Defense devices. There is no way to deploy an IP address pool to the device without associating it in a
connection profile.
Note Unlike ASA, IP address pools cannot be configured on Group Policy and can only be
configured in the Connection Profile for the Firepower Threat Defense device.
Note Filter ACLs are referred to by ACL name in the RADIUS server. It requires the ACL
configuration to be already present on the Firepower Threat Defense device, so that it
can be used during RADIUS authorization. In order to use a filter ACL, configure a
group policy in the remote access VPN configuration and use the filter ACL in 'VPN
Filter' field so that the filter ACL can be deployed to the device. You must note that you
may not really use the group policy but it needs to be configured to deploy the filter
ACL. You cannot directly deploy a filter ACL to the device without associating it to a
group policy.
Note If you place a AAA server on a data interface, be sure the management-only routing
policies do not match traffic destined for a data interface. For example, if you have a
default route through the diagnostic interface, then traffic will never fall back to the data
routing table. Use the show route management-only and show route commands to
verify routing determination.
• For both activities on the same AAA servers, in addition to making the servers reachable over the
Management interface for user-identity handling, do one of the following to provide VPN authentication
access to the same AAA servers:
◦Enable and configure the Diagnostic interface with an IP address on the same subnet as the
Management interface, and then configure a route to the AAA server through this interface. The
Diagnostic interface access will be used for VPN activity, the Management interface access for
identity handling.
Note When configured this way, you cannot also have a data interface on the same subnet as
the Diagnostic and Management interfaces. Also, if for any reason, you want the
Management interface and a data interface on the same network, for example when
using the device itself as a gateway); You will not be able to use this solution, since the
Diagnostic interface must remain disabled.
◦Configure a route through a data interface to the AAA server. The data interface access will be
used for VPN activity, the Management interface access for user-identity handling.
Note If you place a AAA server on a data interface, be sure the management-only routing
policies do not match traffic destined for a data interface. For example, if you have a
default route through the diagnostic interface, then traffic will never fall back to the data
routing table. Use the show route management-only and show route commands to
verify routing determination.
Note You must configure DNS on each device in order to use AAA server names, named
URLs, and CA Servers using FQDN or Hostnames. Without DNS the system can only
configure and use IP addresses. You can configure DNS by creating a FlexConfig policy
using FlexConfig objects with the DNS configuration CLI commands. For more
information, see Configure the FlexConfig Policy, on page 648 and Configure FlexConfig
Objects, on page 642. For more information about the DNS commands to use in the
FlexConfig objects, see http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/
configuration/guide/config/basic.html#wp1080248
After deployment, use the following CLI commands to monitor and troubleshoot AAA server connectivity
from the Firepower Threat Defense device:
• show aaa-server to displays AAA server statistics.
About Aliases
Aliases
Aliases contain alternate names or URLs for a specific connection profile. Remote Access VPN administrators
can enable or disable the Alias names and Alias URLs. VPN users can choose an Alias name when they
connect to the Firepower Threat Defense device. Aliases names for all connections configured on this device
can be turned on or off for display. You can also configure the list of Alias URLs, which your endpoints can
select while initiating the Remote Access VPN connection. If users connect using the Alias URL, system will
automatically log them using the connection profile that matches the Alias URL.
Note Alias URLs and Alias names must be unique across all connection profiles in the Remote Access VPN
policy.
To add a Alias Name and Alias URL, select the Add icon in the separate panes, specify the Alias Name and
Alias URL respectively. Select the Enabled check box in each window to enable the aliases. To add a Alias
URL, create a new URL object. For more information see Creating URL Objects, on page 361.
Click the Edit icon to edit the Alias name or the Alias URL. To delete a Alias name or the Alias URL, click
the Delete icon in that row. Select Allow Overrides to avoid conflicts with IP address when objects are shared
across many devices. Click Save to save the changes.
Access Interfaces
The Access Interface table lists the interface groups and security zones that contain the device interfaces.
These are configured for remote access SSL or IPsec IKEv2 VPN connections. The table displays the name
of the interface group or security-zone, the interface trustpoints used by the interface, and whether Datagram
Transport Layer Security (DTLS) is enabled. For more information about adding access interface, see
Adding Access Interface, on page 828
To edit an access interface, select the Edit icon in that row. To delete an access interface, select the Delete
icon in that row.
Access Settings
• Allow Users to select connection profile will logging in—If you have multiple connection profiles,
selecting this option allows the user to select the correct connection profile during login. You must select
this option for IPsec-IKEv2 VPNs.
For SSL Settings, use the following information:
• Web Access Port Number—The port to use for VPN sessions. The default port is 443.
• DTLS Port Number—The UDP port to use for DTLS connections. The default port is 443.
• SSL Global Identity Certificate—Specifies the SSL Global Identity certificate. Select the option from
the drop-down list. The SSL Global Identity Certificate will be used for all the associated interfaces
if the Interface Specific Identity Certificate is not provided.
For IPsec-IKEv2 Settings, use the following information:
• IKEv2 Identity Certificate—Specifies the IKEv2 identity certificate.
Related Topics
Firepower Threat Defense Remote Access VPN IPsec/IKEv2 Parameters Page, on page 839
About SSL Settings, on page 962
Adding Access Interface, on page 828
About Aliases, on page 827
Procedure
Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
The major components of a Remote Access policy are shown.
Step 3 Select a Connection Profile and click the corresponding Edit icon.
The edit connection profile page is displayed.
Step 4 To add an access interface, select the Add icon and specify values for the following in the Add Access
Interface window:
a) Access Interface—The interface group or security zone to which the interface belongs. Select the value
from the drop-down list.
The interface group or security zone must be a Routed type. Other interface types are not supported for
Remote Access VPN connectivity.
Associate the Protocol object with the access interface.
b) Enable IKEv2—Select this option to enable IKEv2 settings.
c) Enable SSL—Select this option to enable SSL settings.
Step 5 Select Enable Datagram Transport Layer Security.
When selected it enables Datagram Transport Layer Security on the interface and allows an AnyConnect VPN
client to establish a SSL VPN connection using two simultaneous tunnels—an SSL tunnel and a DTLS tunnel.
Enabling DTLS avoids latency and bandwidth problems associated with certain SSL connections and improves
the performance of real-time applications that are sensitive to packet delays.
About Firepower Threat Defense Cisco AnyConnect Secure Mobility Client Image
when the user authenticates, the Firepower Threat Defense device, examines the revision of the client, and
upgrades the client as necessary.
The Remote Access VPN administrator associates the new or additional AnyConnect client images to the
VPN policy. The administrator unassociates the unsupported or end of life client packages that are no longer
required.
The Firepower Management Center determines the type of operating system by using the file package name.
In case the user renamed the file without indicating the operating system information, the valid operating
system type must be selected from the list box.
You can download the AnyConnect client image file by visiting https://software.cisco.com/download/
navigator.html?mdfid=283000185.
Related Topics
Adding Cisco AnyConnect Mobility Client Image to the Firepower Management Center , on page 830
Firepower Threat DefenseRemote Access VPN Connection Profile
Adding Cisco AnyConnect Mobility Client Image to the Firepower Management Center
Smart License Classic Supported Devices Supported Domains Access
License
One of these AnyConnect N/A Firepower Threat Any Administrator
licenses associated with Defense
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex
Procedure
Step 1 Devices > VPN > Remote Access, choose and edit a listed RA VPN policy, then choose the Advanced tab.
Step 2 Click the Add icon in the Available AnyConnect Images portion of the AnyConnect Images dialog.
Step 3 Enter the Name, File Name, and Description for the available AnyConnect Image.
Step 4 Click Browse to navigate to the location for selecting the client image to be uploaded.
Step 5 Click Save to upload the image in the Firepower Management Center.
Once you upload the client image to the Firepower Management Center, the operating system displays platform
information for the image that got uploaded to the Firepower Management Center.
Alternatively, you can upload the Cisco AnyConnect Mobility client image to the Firepower Management
Center by using the AnyConnect File object. For more information, see Firepower Threat Defense File
Objects, on page 439. For more information about the client image, see About Firepower Threat Defense
Cisco AnyConnect Secure Mobility Client Image, on page 829.
Click the Show re-order buttons link to view a specific client image, when additional client images are
available for a particular operating system.
Note To delete an already installed Cisco AnyConnect client image, click the Delete icon in that row.
Related Topics
About Firepower Threat Defense Cisco AnyConnect Secure Mobility Client Image, on page 829
Firepower Threat DefenseRemote Access VPN Connection Profile
About Firepower Threat Defense Remote Access VPN Address Assignment Policy
The Firepower Threat Defense device can use IPv4 or IPv6 policy for assigning IP addresses to Remote Access
VPN clients. If you configure more than one address assignment method, the Firepower Threat Defense device
tries each of the options until it finds an IP address.
IPv4 or IPv6 Policy
You can use the IPv4 or IPv6 policy to find an IP address to the Remote Access VPN clients. Firstly, you
must try with the IPv4 policy and later followed by IPv6 policy.
• Use Authorization Server—Retrieves address from an external authorization server on a per-user basis.
If you are using an authorization server that has IP address configured, we recommend using this method.
Address assignment is supported by RADIUS-based authorization server only. It is not supported for
AD/LDAP. This method is available for both IPv4 and IPv6 assignment policies.
• Use DHCP—Obtains IP addresses from a DHCP server configured in a connection profile. You can
also define the range of IP addresses that the DHCP server can use by configuring DHCP network scope
in the group policy. If you use DHCP, configure the server in the Objects > Object Management >
Network pane. This method is available for IPv4 assignment policies.
• Use an internal address pool—Internally configured address pools are the easiest method of address
pool assignment to configure. If you use this method, create the IP address pools in Objects > Object
Management >Address Pools pane and select the same in the connection profile. This method is
available for both IPv4 and IPv6 assignment policies.
• Reuse an IP address so many minutes after it is released—Delays the reuse of an IP address after its
return to the address pool. Adding a delay helps to prevent problems firewalls can experience when an
IP address is reassigned quickly. By default, the delay is set to zero, meaning the Firepower Threat
Defense device does not impose a delay in reusing the IP address. If you want to extend the delay, enter
the number of minutes in the range 0 - 480 to delay the IP address reassignment. This configurable
element is available for IPv4 assignment policies.
Related Topics
About Client Address Assignment, on page 819
Remote Access VPN AAA Settings, on page 820
Firepower Threat DefenseRemote Access VPN Connection Profile
Procedure
Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
The major components of a Remote Access policy are shown.
Step 3 Click Advanced > Certificate Maps.
Step 4 Set the General Settings for Certificate Group Matching
Select any, or all, of the following options to establish authentication and to determine to which connection
profile (tunnel group) to map the client. Selections are priority-based, if a match is not found for the first
selection matching continues down the list of options. When the rules are satisfied, the mapping is done. If
the rules are not satisfied, the default connection profile (listed at the bottom) is used for this connection.
• Use Group URL if Group URL and Certificate Map match different Connection profiles
• Use the configured rules to match a certificate to a Connection Profile—Enable this to use the rules
defined here in the Connection Profile Maps.
Note Configuring a certificate mapping implies certificate based authentication. The remote user will be
prompted for a client certificate regardless of the configured Authentication Method.
Step 5 Add Certificate to Connection Profile Mapping for this policy.
a) Click Add.
b) Choose or create a Certificate Map Object.
c) Specify the Connection Profile that is used if the rules in the certificate map object are satisfied.
d) Click Save.
Step 6 Click Save.
A Group Policy is a set of attribute and value pairs, stored in a group policy object, that define the remote
access VPN experience. For example, in the group policy object, you configure general attributes such as
addresses, protocols, and connection settings.
The group policy applied to a user is determined when the VPN tunnel is being established. The RADIUS
authorization server assigns the group policy or it is obtained from the current connection profile.
Note There is no group policy attribute inheritance on the Firepower Threat Defense. A group policy object is
used, in its entirety, for a user. The group policy object identified by the AAA server upon login is used,
or, if that is not specified, the default group policy configured for the VPN connection is used. The provided
default group policy can be set to your default values, but will only be used if it is assigned to a connection
profile and no other group policy has been identified for the user.
Procedure
Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
The major components of a Remote Access policy are shown.
Step 3 Click Advanced > Group Policies.
Step 4 Select more group policies to associate with this Remote Access VPN policy. These are above and beyond
the default group policy assigned at RA VPN policy creation time. Click Add.
Use the Refresh and Search utilities to locate the group policy. Add a new Group Policy object if necessary.
Step 5 Click OK when you have the Selected Group Policy window set as desired.
Related Topics
Configure Group Policy Objects, on page 434
Procedure
Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
Step 3 Click the Advanced tab.
The list of IPsec settings appears in a navigation pane on the left of the screen.
Note The IPsec settings are applicable only if you selected IPsec as the VPN protocol while configuring
your remote access VPN policy. If not, you can enable IKEv2 using the Edit Access Interface dialog
box. See Firepower Threat Defense Remote Access VPN Access Interface Options, on page 827 for
more information.
Step 4 Use the navigation pane to edit the following IPsec options:
a) Crypto Maps—The Crypto Maps page lists the interface groups on which IKEv2 protocol is enabled.
Crypto Maps are auto generated for the interfaces on which IKEv2 protocol is enabled. To edit a Crypto
Map, see Crypto Maps Options, on page 835. You can add or remove interface groups to the selected VPN
policy in the Access Interface tab. See Firepower Threat Defense Remote Access VPN Access Interface
Options, on page 827 for more information.
b) IKE Policy—The IKE Policy page lists all the IKE policy objects applicable for the selected VPN policy
when AnyConnect endpoints connect using the IPsec protocol. See Firepower Threat Defense Remote
Access VPN IKE Policies Page, on page 839 for more information. To add a new IKE policy, see Configure
IKEv2 Policy Objects , on page 430. Firepower Threat Defense supports only AnyConnect IKEv2 clients.
Third party standard IKEv2 clients are not supported.
c) IPsec/IKEv2 Parameters—The IPsec/IKEv2 Parameters page enables you to modify the IKEv2 session
settings, IKEv2 Security Association settings, IPsec settings, and NAT Transparency settings. See Firepower
Threat Defense Remote Access VPN IPsec/IKEv2 Parameters Page, on page 839 for more information.
Step 5 Click Save.
Step 6 Click Deploy to deploy the configuration changes on the Firepower Threat Defense device(s).
Related Topics
Editing Firepower Threat Defense Remote Access VPN Policy, on page 817
Firepower Threat Defense Remote Access VPN Access Interface Options, on page 827
Related Topics
Crypto Maps Options, on page 835
Editing Firepower Threat Defense IPsec Settings, on page 834
Navigation Path
Devices > VPN > Remote Access, choose and edit a listed RA VPN policy, then choose the Advanced tab.
In the navigation pane, open IPsec > Crypto Maps.
Interface Group
The interface group on which IKEv2 protocol is enabled.
Note You can add or remove an interface group associated with the selected VPN
configuration using the Firepower Threat Defense Remote Access VPN Access
Interface Options, on page 827 tab.
Note You can use the same port that you use for SSL VPN running on the same
device. Even if you have an SSL VPN configured, you must select this option
to enable file downloads over SSL for IKEv2 IPsec clients.
The Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without
transmitting it to each other. A larger modulus provides higher security but requires more processing
time. The two peers must have a matching modulus group. Select the Modulus group that you want to
allow in the remote access VPN configuration:
• 1—Diffie-Hellman Group 1 (768-bit modulus).
• 2—Diffie-Hellman Group 2 (1024-bit modulus).
• 5—Diffie-Hellman Group 5 (1536-bit modulus, considered good protection for 128-bit keys, but
group 14 is better). If you are using AES encryption, use this group (or higher).
• 14—Diffie-Hellman Group 14 (2048-bit modulus, considered good protection for 128-bit keys).
• 19—Diffie-Hellman Group 19 (256-bit elliptical curve field size).
• 20—Diffie-Hellman Group 20 (384-bit elliptical curve field size).
• 21—Diffie-Hellman Group 21 (521-bit elliptical curve field size).
• 24—Diffie-Hellman Group 24 ( 2048-bit modulus and 256-bit prime order subgroup).
ESPv3 Settings
Validate incoming ICMP error messages
Choose whether to validate ICMP error messages received through an IPsec tunnel and destined for an
interior host on the private network.
Related Topics
Editing Firepower Threat Defense IPsec Settings, on page 834
Note Firepower Threat Defense supports only IKEv2 for remote access VPNs.
Unlike IKEv1, in an IKEv2 proposal, you can select multiple algorithms and modulus groups in one policy.
Since peers choose during the Phase 1 negotiation, this makes it possible to create a single IKE proposal, but
consider multiple, different proposals to give higher priority to your most desired options. For IKEv2, the
policy object does not specify authentication, other policies must define the authentication requirements.
An IKE policy is required when you configure a remote access IPsec VPN.
IKE Policy
The IKE Policy table specifies all the IKE policy objects applicable for the selected VPN configuration when
AnyConnect endpoints connect using the IPsec protocol. See About Firepower Threat Defense IKE Policies
in Remote Access VPNs, on page 838 for more information.
Note Firepower Threat Defense supports only IKEv2 for remote access VPNs.
Click the Add button to select from the available IKEv2 policies or add a new IKEv2 policy. To add a new
IKEv2 policy, see Configure IKEv2 Policy Objects , on page 430.
Name
Name of the IKEv2 policy.
Integrity
The Integrity Algorithms portion of the Hash Algorithm used in the IKEv2 policy.
Encryption
The Encryption Algorithm used to establish the Phase 1 SA for protecting Phase 2 negotiations.
PRF Hash
The pseudorandom function (PRF) portion of the Hash Algorithm used in the IKE policy. In IKEv1,
the Integrity and PRF algorithms are not separated, but in IKEv2, you can specify different algorithms
for these elements.
DH Group
The Diffie-Hellman group used for encryption.
Related Topics
Editing Firepower Threat Defense IPsec Settings, on page 834
IPsec Settings
Enable Fragmentation Before Encryption
This option lets traffic travel across NAT devices that do not support IP fragmentation. It does not
impede the operation of NAT devices that do support IP fragmentation.
Path Maximum Transmission Unit Aging
Check to enable PMTU (Path Maximum Transmission Unit) Aging, the interval to Reset PMTU of an
SA (Security Association).
Value Reset Interval
Enter the number of minutes at which the PMTU value of an SA (Security Association) is reset to its
original value. Valid range is 10 to 30 minutes, default is unlimited.
NAT Settings
Keepalive Messages Traversal
Select whether to enable NAT keepalive message traversal. NAT traversal keepalive is used for the
transmission of keepalive messages when there is a device (middle device) located between a
VPN-connected hub and spoke, and that device performs NAT on the IPsec flow. If you select this
option, configure the interval, in seconds, between the keepalive signals sent between the spoke and
the middle device to indicate that the session is active. The value can be from 10 to 3600 seconds. The
default is 20 seconds.
Interval
Sets the NAT keepalive interval, from 10 to 3600 seconds. The default is 20 seconds.
Related Topics
Editing Firepower Threat Defense IPsec Settings, on page 834
Remote access VPNs provide secure connections for remote users, such as mobile users or telecommuters.
Monitoring these connections provides important indicators of connction and user session performance at a
glance.
Procedure
Step 1 Choose Overview > Dashboards > Access Controlled User Statistics, and then choose the VPN dashboard.
Step 2 View the Remote Access VPN information widgets:
• Current VPN Users by Duration.
What to Do Next
The VPN dashboard is a complex, highly customizable monitoring feature that provides exhaustive data.
• For complete information on how to use dashboards in the Firepower System, see Dashboards, on page
201.
• For information on how to modify the VPN dashboard widgets, see Configuring Widget Preferences,
on page 216.
• To learn more about user activity; see Viewing User Activity Data, on page 2440.
• To learn more about the contents of the columns in the user activity table; see Active Sessions, Users,
and User Activity Data, on page 2427.
See Health Monitoring, on page 223 for more details on how you can use the health monitor to check the
status of critical functionality across your Firepower System deployment.
When you access health events from the Health Events page on your Firepower Management Center, you
retrieve all health events for all managed appliances. You can narrow the events by specifying the module
which generated the health events you want to view.
Procedure
System Messages
The Message Center is the place to start your troubleshooting. This feature allows you to view messages that
are continually generated about system activities and status. To open the Message Center, click in the System
Status icon, located to the immediate right of the Deploy button in the main menu. See System Messages,
on page 261 for details on using the Message Center.
Note VPN syslogs are automatically enabled to be sent to the Firepower Management Center by default whenever
a device is configured with site-to-site or remote access VPNs.
The Firepower System captures event information to help you to gather additional information about the
source of your VPN problems. Any VPN syslogs that are displayed have a default severity level ‘ERROR’ or
higher (unless changed). By default the rows are sorted by the Time column.
Procedure
Debug Commands
This section explains how you use debug commands to help you diagnose and resolve VPN-related problems.
Not all available debug commands are described in this section. Commands are included here based on the
their usefulness in assisting you to diagnose VPN-related problems.
Usage Guidelines Because debugging output is assigned high priority in the CPU process, it can render the system unusable.
For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions
with the Cisco Technical Assistance Center (TAC). Moreover, it is best to use debug commands during
periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood
that increased debug command processing overhead will affect system use.
You can view debug output in a CLI session only. Output is directly available when connected to the Console
port, or when in the diagnostic CLI (enter system support diagnostic-cli). You can also view output from
the regular Firepower Threat Defense CLI using the show console-output command.
To show debugging messages for a given feature, use the debug command. To disable the display of debug
messages, use the no form of this command. Use no debug all to turn off all debugging commands.
Syntax Description feature Specifies the feature for which you want to enable debugging. To see available
features, use the debug ? command for CLI help.
subfeature (Optional) Depending on the feature, you can enable debug messages for one or
more subfeatures. Use ? to see the available subfeatures.
level (Optional) Specifies the debugging level. The level might not be available for all
features. Use ? to see the available levels.
Example
With multiple sessions running on a remote access VPN, troubleshooting can be difficult given the size of
the logs. You can use the debug webvpn condition command to set up filters to target your debug process
more precisely.
debug webvpn condition {group name | p-ipaddress ip_address [{subnet subnet_mask | prefix length}] |
reset | user name}
Where:
• group name filters on a group policy (not a tunnel group or connection profile).
• p-ipaddress ip_address [{subnet subnet_mask | prefix length}] filters on the public IP address of the
client. The subnet mask (for IPv4) or prefix (for IPv6) is optional.
• reset resets all filters. You can use the no debug webvpn condition command to turn off a specific
filter.
• user name filters by username.
If you configure more than one condition, the conditions are conjoined (ANDed), so that debugs are shown
only if all conditions are met.
After setting up the condition filter, use the base debug webvpn command to turn on the debug. Simply setting
the conditions does not enable the debug. Use the show debug and show webvpn debug-condition commands
to view the current state of debugging.
The following shows an example of enabling a conditional debug on the user jdoe.
undebug Disables debugging for a feature. This command is a synonym for no debug.
debug aaa
See the following commands for debugging configurations or settings associated with authentication,
authorization, and accounting (AAA, pronounced “triple A”).
Syntax Description aaa Enables debugging for AAA. Use ? to see the available subfeatures.
common (Optional) Specifies the AAA common debug level. Use ? to see the available
levels.
shim (Optional) Specifies the AAA shim debug level. Use ? to see the available levels.
undebug aaa Disables debugging for AAA. This command is a synonym for no debug aaa.
debug crypto
See the following commands for debugging configurations or settings associated with crypto.
debug crypto [ca | condition | engine | ike-common | ikev1 | ikev2 | ipsec | ss-apic]
Syntax Description crypto Enables debugging for crypto. Use ? to see the available subfeatures.
ca (Optional) Specifies the PKI debug levels. Use ? to see the available subfeatures.
condition (Optional) Specifies the IPsec/ISAKMP debug filters. Use ? to see the available
filters.
engine (Optional) Specifies the crypto engine debug levels. Use ? to see the available
levels.
ike-common (Optional) Specifies the IKE common debug levels. Use ? to see the available
levels.
ikev1 (Optional) Specifies the IKE version 1 debug levels. Use ? to see the available
levels.
ikev2 (Optional) Specifies the IKE version 2 debug levels. Use ? to see the available
levels.
ipsec (Optional) Specifies the IPsec debug levels. Use ? to see the available levels.
condition (Optional) Specifies the Crypto Secure Socket API debug levels. Use ? to see
the available levels.
vpnclient (Optional) Specifies the EasyVPN client debug levels. Use ? to see the available
levels.
undebug crypto Disables debugging for crypto. This command is a synonym for no debug crypto.
debug crypto ca
See the following commands for debugging configurations or settings associated with crypto ca.
Syntax Description crypto ca Enables debugging for crypto ca. Use ? to see the available subfeatures.
cluster (Optional) Specifies the PKI cluster debug level. Use ? to see the available levels.
cmp (Optional) Specifies the CMP transactions debug level. Use ? to see the available
levels.
messages (Optional) Specifies the PKI Input/Output message debug level. Use ? to see the
available levels.
periodic-authentication (Optional) Specifies the PKI periodic-authentication debug level. Use ? to see
the available levels.
scep-proxy (Optional) Specifies the SCEP proxy debug level. Use ? to see the available
levels.
server (Optional) Specifies the local CA server debug level. Use ? to see the available
levels.
transactions (Optional) Specifies the PKI transaction debug level. Use ? to see the available
levels.
trustpool (Optional) Specifies the trustpool debug level. Use ? to see the available levels.
Command Description
undebug Disables debugging for crypto ca. This command is a synonym for no debug
crypto ca.
Syntax Description ikev1 Enables debugging for ikev1. Use ? to see the available subfeatures.
undebug crypto ikev1 Disables debugging for IKEv1. This command is a synonym for no debug crypto
ikev1.
Syntax Description ikev2 Enables debugging ikev2. Use ? to see the available subfeatures.
ha (Optional) Specifies the IKEv2 HA debug level. Use ? to see the available levels.
platform (Optional) Specifies the IKEv2 platform debug level. Use ? to see the available
levels.
protocol (Optional) Specifies the IKEv2 protocol debug level. Use ? to see the available
levels.
undebugcrypto ikev2 Disables debugging for IKEv2. This command is a synonym for no debug crypto
ikev2.
Syntax Description ipsec Enables debugging for ipsec. Use ? to see the available subfeatures.
undebugcrypto ipsec Disables debugging for IPsec. This command is a synonym for no debug crypto
ipsec.
debug ldap
See the following commands for debugging configurations or settings associated with LDAP (Lightweight
Directory Access Protocol).
Syntax Description ldap Enables debugging for LDAP. Use ? to see the available subfeatures.
undebugldap Disables debugging for LDAP. This command is a synonym for no debug ldap.
debug ssl
See the following commands for debugging configurations or settings associated with SSL sessions.
Syntax Description ssl Enables debugging for SSL. Use ? to see the available subfeatures.
cipher (Optional) Specifies the SSL cipher debug level. Use ? to see the available levels.
device (Optional) Specifies the SSL device debug level. Use ? to see the available levels.
undebug ssl Disables debugging for SSL. This command is a synonym for no debug ssl.
debug webvpn
See the following commands for debugging configurations or settings associated with WebVPN.
debug webvpn [anyconnect | chunk | cifs | citrix | compression | condition | cstp-auth | customization | failover
| html | javascript | kcd | listener | mus | nfs | request | response | saml | session | task | transformation | url |
util | xml]
Syntax Description webvpn Enables debugging for WebVPN. Use ? to see the available subfeatures.
anyconnect (Optional) Specifies the WebVPN AnyConnect debug level. Use ? to see the
available levels.
chunk (Optional) Specifies the WebVPN chunk debug level. Use ? to see the available
levels.
cifs (Optional) Specifies the WebVPN CIFS debug level. Use ? to see the available
levels.
citrix (Optional) Specifies the WebVPN Citrix debug level. Use ? to see the available
levels.
compression (Optional) Specifies the WebVPN compression debug level. Use ? to see the
available levels.
condition (Optional) Specifies the WebVPN filter conditions debug level. Use ? to see the
available levels.
cstp-auth (Optional) Specifies the WebVPN CSTP authentication debug level. Use ? to see
the available levels.
customization (Optional) Specifies the WebVPN customization debug level. Use ? to see the
available levels.
failover (Optional) Specifies the WebVPN failover debug level. Use ? to see the available
levels.
html (Optional) Specifies the WebVPN HTML debug level. Use ? to see the available
levels.
javascript (Optional) Specifies the WebVPN Javascript debug level. Use ? to see the
available levels.
kcd (Optional) Specifies the WebVPN KCD debug level. Use ? to see the available
levels.
listener (Optional) Specifies the WebVPN listener debug level. Use ? to see the available
levels.
mus (Optional) Specifies the WebVPN MUS debug level. Use ? to see the available
levels.
nfs (Optional) Specifies the WebVPN NFS debug level. Use ? to see the available
levels.
request (Optional) Specifies the WebVPN request debug level. Use ? to see the available
levels.
response (Optional) Specifies the WebVPN response debug level. Use ? to see the available
levels.
saml (Optional) Specifies the WebVPN SAML debug level. Use ? to see the available
levels.
session (Optional) Specifies the WebVPN session debug level. Use ? to see the available
levels.
task (Optional) Specifies the WebVPN task debug level. Use ? to see the available
levels.
transformation (Optional) Specifies the WebVPN transformation debug level. Use ? to see the
available levels.
url (Optional) Specifies the WebVPN URL debug level. Use ? to see the available
levels.
util (Optional) Specifies the WebVPN utility debug level. Use ? to see the available
levels.
xml (Optional) Specifies the WebVPN XML debug level. Use ? to see the available
levels.
undebug webvpn Disables debugging for WebVPN. This command is a synonym for no debug
webvpn.
Tip For 7000 and 8000 Series devices, you can perform limited system configuration tasks
from the local web interface, such as console configuration and remote management.
These are not the same configurations that you apply to a 7000 or 8000 Series device
using a platform settings policy.
The system configuration identifies basic settings for a Firepower Management Center.
Procedure
HTTPS Certificate Request an HTTPS server certificate, if needed, from a trusted authority and no yes
upload certificates to the system; see Custom HTTPS Certificates, on page 866.
External Database Enable external read-only access to the database, and provide a client driver to no no
Access download; see External Database Access Settings, on page 871.
Database Specify the maximum number of each type of event that the Firepower no no
Management Center can store; see Database Event Limits, on page 872.
Management Change options such as the IP address, hostname, and proxy settings of the no yes
Interfaces appliance; see Management Interfaces, on page 875.
Process Shut down, reboot, or restart Firepower System-related processes; see System no yes
Shut Down and Restart, on page 889.
Remote Storage Configure remote storage for backups and reports; see Remote Storage no no
Device Management, on page 891.
Change Configure the system to send a detailed report of changes to the system over the no yes
Reconciliation last 24 hours; see Change Reconciliation, on page 895.
Access Control Configure the system to prompt users for a comment when they add or modify no no
Preferences an access control policy; see Policy Change Comments, on page 896.
Access List Control which computers can access the system on specific ports; see The Access yes no
List, on page 897.
Audit Log Configure the system to send an audit log to an external host; see Audit Logs, yes no
on page 899.
Custom Audit Log Configure the system to secure the channel when streaming the audit log to an yes no
Client Certificates external host; see Custom Audit Log Client Certificates, on page 902
Dashboard Enable Custom Analysis widgets on the dashboard; see Dashboard Settings, on no no
page 907.
DNS Cache Configure the system to resolve IP addresses automatically on event view pages; no no
see DNS Cache, on page 907.
External Set the default user role for any user whose account is externally authenticated; yes no
Authentication see External Authentication Settings, on page 944
Intrusion Policy Configure the system to prompt users for a comment when they modify an no no
Preferences intrusion policy; see Policy Change Comments, on page 896.
Language Specify a different language for the web interface; see Language Selection, on yes no
page 909.
Login Banner Create a custom login banner that appears when users log in; see Login Banners, yes no
on page 910.
Network Analysis Configure the system to prompt users for a comment when they modify a network no no
Policy Preferences analysis policy; see Policy Change Comments, on page 896.
SNMP Enable Simple Network Management Protocol (SNMP) polling; see SNMP yes no
Polling, on page 911.
Security Enable compliance with specific requirements set out by the United States yes no
Certifications Department of Defense; see Enabling Security Certifications Compliance, on
Compliance page 994.
Time View the current time setting and, if the time synchronization setting in the no yes
current system configuration is set to Manually in Local Configuration, change
the time; see Time and Time Synchronization, on page 913.
Time Manage time synchronization on the system; see Time and Time Synchronization, yes no
Synchronization on page 913.
Shell Timeout Configure the amount of idle time, in minutes, before a user’s login session times yes no
out due to inactivity; see Session Timeouts, on page 917.
Vulnerability Map vulnerabilities to a host IP address for any application protocol traffic no no
Mapping received or sent from that address; see Vulnerability Mapping, on page 919.
Console Configure console access via VGA or serial port, or via Lights-Out Management no limited
Configuration (LOM); see Remote Console Access Management, on page 920.
REST API Enable or disable access to the Firepower Management Center via the Firepower no no
Preferences REST API; see REST API Preferences, on page 926.
Related Topics
Introduction to Firepower Platform Settings, on page 933
Appliance Information
The Information page of the web interface includes the information listed in the table below. Unless otherwise
noted, all fields are read-only.
Field Description
Name A name you assign to the appliance. Note that this name is only used within the
context of the Firepower System. Although you can use the host name as the
name of the appliance, entering a different name in this field does not change
the host name.
Software Version The version of the software currently installed on the appliance.
Prohibit Packet Transfer Specifies whether the managed device sends packet data with events, allowing
to the Firepower the data to be stored on the Firepower Management Center. This setting is
Management Center available on the local web interface on 7000 and 8000 Series devices.
Operating System The version of the operating system currently running on the appliance.
Version
IPv4 Address The IPv4 address of the default (eth0) management interface. If IPv4 management
is disabled, this field indicates that.
IPv6 Address The IPv6 address of the default (eth0) management interface. If IPv6 management
is disabled, this field indicates that.
Current Policies The system-level policies currently deployed . If a policy has been updated since
it was last deployed, the name of the policy appears in italics.
Field Description
Model Number The appliance-specific model number stored on the internal flash drive. This
number may be important for troubleshooting.
The Information page on the Firepower Management Center’s web interface or on the 7000 and 8000 Series
local web interface provides information about your system, including read-only information such as the
product name and model number. The page also provides you with an option to change the display name of
the system and, for 7000 and 8000 Series devices, prohibit packet transfer.
Note Prohibiting packet transfer can be a good idea in a low-bandwidth deployment where you are not concerned
about the specific content of the packet that triggered the intrusion policy violation.
Procedure
You can generate a certificate request based on your system information and the identification information
you supply. You can use it to self-sign a certificate if you have an internal certificate authority (CA) installed
that is trusted by your browser. You can also send the resulting request to a certificate authority to request a
server certificate. After you have a signed certificate from a certificate authority (CA), you can import it.
You can restrict access to the Firepower System web server using client browser certificate checking. When
you enable user certificates, the web server checks that a user’s browser client has a valid user certificate
selected. That user certificate must be generated by the same trusted certificate authority used for the server
certificate. The browser cannot load the web interface under any of the following circumstances:
• The user selects a certificate in the browser that is not valid.
• The user selects a certificate in the browser that is not generated by the certificate authority that signed
the server certificate.
• The user selects a certificate in the browser that is not generated by a certificate authority in the certificate
chain on the device.
To verify client browser certificates, configure the system to use the online certificate status protocol (OSCP)
or load one or more certificate revocation lists (CRLs). Using the OSCP, when the web server receives a
connection request it communicates with the certificate authority to confirm the client certificate's validity
before establishing the connection. If you configure the server to load one or more CRLs, the web server
compares the client certificate against those listed in the CRLs. If a user selects a certificate that is listed in a
CRL as a revoked certificate, the browser cannot load the web interface.
Note If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both client
browser certificates and audit log server certificates.
Caution The Firepower Management Center supports 2048-bit HTTPS certificates. If the certificate used by the
Firepower Management Center was generated using a public server key larger than 2048 bits, you will
not be able to log in to the Management Center web interface. For more information about updating HTTPS
Certificates to Version 6.0.0, see "Update Management Center HTTPS Certificates to Version 6.0" in
Firepower System Release Notes, Version 6.0. If you generate or import an HTTPS Certificate and cannot
log in to the Management Center web interface, contact Support.
You can only view server certificates for the appliance you are logged in to.
Procedure
When you generate a certificate request through the local configuration HTTPS Certificate page using this
procedure, you can only generate a certificate for a single system. If you install a certificate that is not signed
by a globally known or internally trusted CA, you receive a security warning when you connect to the system.
The key generated for the certificate request is in Base-64 encoded PEM format.
Procedure
What to Do Next
• Submit the certificate request to the certificate authority.
• When you receive the signed certificate, import it to the Firepower Management Center; see Importing
HTTPS Server Certificates, on page 869.
If the signing authority that generated the certificate requires you to trust an intermediate CA, you must also
supply a certificate chain (or certificate path).
If you require client certificates, accessing an appliance via the web interface will fail when the server certificate
does not meet either of the following criteria:
• The certificate is signed by the same CA that signed the client certificate.
• The certificate is signed by a CA that has signed an intermediate certificate in the certificate chain.
Caution The Firepower Management Center supports 2048-bit HTTPS certificates. If the certificate used by the
Firepower Management Center was generated using a public server key larger than 2048 bits, you will
not be able to log in to the Management Center web interface. For more information about updating HTTPS
Certificates to Version 6.0.0, see "Update Management Center HTTPS Certificates to Version 6.0" in
Firepower System Release Notes, Version 6.0. If you generate or import an HTTPS Certificate and cannot
log in to the Management Center web interface, contact Support.
Procedure
The system supports validating HTTPS client certificates using either OSCP or imported CRLs in
Privacy-enhanced Electronic Mail (PEM) format.
If you choose to use CRLs, to ensure that the list of revoked certificates stays current, you can create a scheduled
task to update the CRLs. The system displays the most recent refresh of the CRLs.
Note To access the web interface after enabling client certificates, you must have a valid client certificate
present in your browser (or a CAC inserted in your reader).
Procedure
Step 5 Enter a valid URL to an existing CRL file and click Add CRL. Repeat to add up to 25 CRLs.
Step 6 Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs.
Note Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs. Edit
the task to set the frequency of the update.
Step 7 Verify that the client certificate is signed by the certificate authority loaded onto the appliance and the server
certificate is signed by a certificate authority loaded in the browser certificate store. (These should be the same
certificate authority.)
Caution Saving a configuration with enabled client certificates, with no valid client certificate in your
browser certificate store, disables all web server access to the appliance. Make sure that you have
a valid client certificate installed before saving settings.
Step 8 Click Save.
Related Topics
Configuring Certificate Revocation List Downloads, on page 181
Use the Firepower Management Center's system configuration to enable database access and create an access
list that allows selected hosts to query the database. Note that this access list does not also control appliance
access.
You can also download a package that contains the following:
• RunQuery, the Cisco-provided database query tool
• InstallCert, a tool you can use to retrieve and accept the SSL certificate from the Firepower Management
Center you want to access
• the JDBC driver you must use to connect to the database
See the Firepower System Database Access Guide for information on using the tools in the package you
downloaded to configure database access.
Procedure
Related Topics
Firepower System IP Address Conventions, on page 12
user databases to remove selected discovery data; and you can purge discovery and connection data from the
Firepower Management Center database.
Procedure
Step 4 Optionally, in the Data Pruning Notification Address field, enter the email address where you want to
receive pruning notifications.
Step 5 Click Save.
Connection summaries (aggregated 50 million (Management Center Virtual) Zero (disables storage)
connection events)
50 million (MC750)
100 million (MC1000 and MC1500)
300 million (MC2000 and MC2500)
500 million (MC3500)
1 billion (MC4000 and MC4500)
White list violation history a 30-day history of violations One day’s history
Management Interfaces
After setup, you can change the management network settings, including adding more management interfaces,
hostname, search domains, DNS servers, and HTTP proxy on both the Management Center and the managed
devices.
Note For the Firepower 9300 chassis (the Firepower 4100 and 9300), the MGMT interface is for chassis
management, not for Firepower Threat Defense logical device management. You must configure a separate
NIC interface to be of type mgmt (and/or firepower-eventing), and then assign it to the Firepower Threat
Defense logical device.
Note For Firepower Threat Defense on any chassis, the physical management interface is shared between the
Diagnostic logical interface, which is useful for SNMP or syslog, and is configured along with data
interfaces in the Management Center, and the Management logical interface for Management Center
communication. See Management/Diagnostic Interface and Network Deployment, on page 561 for more
information.
See the following tables for supported management interfaces on each Firepower Management Center and
managed device model.
The following example shows the Firepower Management Center using separate management interfaces for
devices; and each managed device using 1 management interface.
The following example shows the Firepower Management Center and managed devices using a separate event
interface.
Figure 19: Separate Event Interface on the Firepower Management Center and Managed Devices
The following example shows a mix of multiple management interfaces and a separate event interface on the
Firepower Management Center and a mix of managed devices using a separate event interface, or using a
single management interface.
For the 7000 & 8000 Series devices, you can configure management interface settings using a web interface
similar to the Management Center interface. For the Firepower Threat Defense device, vNGIPS, and ASA
FirePOWER module, you must use the CLI to configure these settings. The CLI is also optionally available
on the 7000 & 8000 Series; you cannot use the CLI on the Management Center. (The Management Center
supports Linux shell access, and only under Cisco TAC supervision. See Firepower System User Interfaces.)
Related Topics
Communication Ports Requirements, on page 2469
Modify the management interface settings on the Firepower Management Center. You can optionally enable
additional management interfaces or confugure an event-only interface.
Caution Be careful when making changes to the management interface to which you are connected; if you cannot
re-connect because of a configuration error, you need to access the Management Center console port to
re-configure the network settings in the Linux shell. You must contact Cisco TAC to guide you in this
operation.
Procedure
Step 1 Choose System > Configuration, and then choose Management Interfaces.
Step 2 In the Interfaces area, click Edit next to the interface that you want to configure.
All available interfaces are listed in this section. You cannot add more interfaces.
You can configure the following options on each management interface:
• Enabled—Enable the management interface. Do not disable the default eth0 management interface.
Some processes require the eth0 interface.
• Channels—Configure an event-only interface; you can configure only one event interface on the
Management Center. To do so, uncheck the Management Traffic check box, and leave the Event
Traffic check box checked. Other management interfaces should have both check boxes checked.
• Mode—Specify a link mode. Note that any changes you make to auto-negotiation are ignored for
GigabitEthernet interfaces.
• MTU—Set the maximum transmission unit (MTU). The default is 1500. The range within which you
can set the MTU can vary depending on the model and interface type.
Because the system automatically trims 18 bytes from the configured MTU value, any value below 1298
does not comply with the minimum IPv6 MTU setting of 1280, and any value below 594 does not comply
with the minimum IPv4 MTU setting of 576. For example, the system automatically trims a configured
value of 576 to 558.
• MDI/MDIX—Set the Auto-MDIX setting.
Step 3 In the Routes area, edit a static route by clicking the edit icon ( ), or add a route by clicking the add icon
( ). View the route statistics by clicking the view icon ( ).
Note For the default route, you can change only the gateway IP
address.
You can configure the following settings for a static route:
• Destination—Set the destination address of the network to which you want to create a route.
• Netmask or Prefix Length—Set the netmask (IPv4) or prefix length (IPv6) for the network.
• Interface—Set the egress management interface.
• Gateway—Set the gateway IP address.
Step 4 In the Shared Settings area, set network parameters shared by all interfaces.
Note If you selected DHCP for the eth0 interface, you cannot manually specify some shared settings
derived from the DHCP server.
You can configure the following shared settings:
• Hostname—Set the Management Center hostname. If you change the hostname, reboot the Management
Center if you want the new hostname reflected in syslog messages. Syslog messages do not reflect a
new hostname until after a reboot.
• Domains—Set the search domain(s) for the Management Center, separated by commas. These domains
are added to hostnames when you do not specify a fully-qualified domain name in a command, for
example, ping system. The domains are used only on the management interface, or for commands that
go through the management interface.
• Primary DNS Server, Secondary DNS Server, Tertiary DNS Server—Set the DNS servers to be
used in order of preference.
• Remote Management Port—Set the remote management port for communication with managed devices.
The Management Center and managed devices communicate using a two-way, SSL-encrypted
communication channel, which by default is on port 8305.
Note Cisco strongly recommends that you keep the default settings for the remote management port,
but if the management port conflicts with other communications on your network, you can
choose a different port. If you change the management port, you must change it for all devices
in your deployment that need to communicate with each other.
Modify the management interface settings on the managed device using the web interface. You can optionally
enable an event interface if your model supports it.
Caution Be careful when making changes to the management interface; if you cannot re-connect because of a
configuration error, you will need to access the device console port and reconfigure the settings at the
CLI.
Procedure
Step 1 Choose System > Configuration, and then choose Management Interfaces.
Step 2 In the Interfaces area, click Edit next to the interface that you want to configure.
All available interfaces are listed in this section. You cannot add more interfaces.
You can configure the following options on each management interface:
• Enabled—Enable the management interface. Do not disable the default eth0 management interface.
Some processes require the eth0 interface.
• Channels—(8000 series only) Configure an event-only interface. You can enable the eth1 management
interface on your 8000 series device to act as an event interface. To do so, uncheck the Management
Traffic check box, and leave the Event Traffic check box checked. For the eth0 management interface,
leave both check boxes checked.
We recommend that you use the default management interface for both management and eventing
channels; and then enable a separate event-only interface. The Firepower Management Center event-only
interface cannot accept management channel traffic, so you should simply disable the management
channel on the device event interface.
• Mode—Specify a link mode. Note that any changes you make to auto-negotiation are ignored for
GigabitEthernet interfaces.
• MTU—Set the maximum transmission unit (MTU). The default is 1500. The range within which you
can set the MTU can vary depending on the model and interface type.
Because the system automatically trims 18 bytes from the configured MTU value, any value below 1298
does not comply with the minimum IPv6 MTU setting of 1280, and any value below 594 does not comply
with the minimum IPv4 MTU setting of 576. For example, the system automatically trims a configured
value of 576 to 558.
• MDI/MDIX—Set the Auto-MDIX setting.
• IPv4 Configuration—Set the IPv4 IP address. Choose:
◦Static—Manually enter the IPv4 management IP address and netmask.
◦DHCP—Set the interface to use DHCP (eth0 only).
◦Disabled—Disable IPv4. Do not disable both IPv4 and IPv6.
Step 3 In the Routes area, edit a static route by clicking the edit icon ( ), or add a route by clicking the add icon
( ). View the route statistics by clicking the view icon ( ).
Note For the default route, you can change only the gateway IP
address.
You can configure the following settings for a static route:
• Destination—Set the destination address of the network to which you want to create a route.
• Netmask or Prefix Length—Set the netmask (IPv4) or prefix length (IPv6) for the network.
• Interface—Set the egress management interface.
• Gateway—Set the gateway IP address.
Step 4 In the Shared Settings area, set network parameters shared by all interfaces.
Note If you selected DHCP for the eth0 interface, you cannot manually specify some shared settings
derived from the DHCP server.
Step 5 In the LCD Panel area, check the Allow reconfiguration of network settings check box to enable changing
network settings using the device’s LCD panel.
You can use the LCD panel to edit the IP address for the device. Confirm that any changes you make are
reflected on the managing Firepower Management Center. In some cases, you may need to update the data
manually on the Firepower Management Center as well.
Caution Allowing reconfiguration using the LCD panel can present a security risk. You need only physical
access, not authentication, to configure network settings using the LCD panel. The web interface
warns you that enabling this option is a potential security issue.
Step 6 In the Proxy area, configure HTTP proxy settings.
The device is configured to directly-connect to the internet on ports TCP/443 (HTTPS) and TCP/80 (HTTP).
You can use a proxy server, to which you can authenticate via HTTP Digest.
Note Proxies that use NT LAN Manager (NTLM) authentication are not
supported.
a) Check the Enabled check box.
b) In the HTTP Proxy field, enter the IP address or fully-qualified domain name of your proxy server.
c) In the Port field, enter a port number.
d) Supply authentication credentials by choosing Use Proxy Authentication, and then provide a User Name
and Password.
Step 7 Click Save.
Modify the management interface settings on the managed device using the CLI. Many of these settings are
ones that you set when you performed the initial setup; this procedure lets you change those settings, and set
additional settings such as enabling an event interface if your model supports it, or adding static routes. For
information about the Firepower Threat Defense CLI, see Command Reference for Firepower Threat Defense.
For information about the classic device CLI, see Classic Device Command Line Reference, on page 2473in
this guide. The Firepower Threat Defense and classic devices use the same commands for management
interface configuration. Other commands may differ between the platforms.
Caution When using SSH, be careful when making changes to the management interface; if you cannot re-connect
because of a configuration error, you will need to access the device console port.
Procedure
Step 1 Connect to the device CLI, either from the console port or using SSH.
See Logging Into the Command Line Interface on Firepower Threat Defense Devices, on page 25 or Logging
Into the Command Line Interface on Classic Devices, on page 24.
Step 2 Log in with the Admin username and password.
Step 3 Enable an event-only interface (for supported models; see Management Interface Support, on page 876):
configure network management-interface enable management_interface
configure network management-interface disable-management-channel management_interface
Example:
This example is for a Firepower 4100 or 9300 device; valid interface names differ by device type.
>
We recommend that you use the default management interface for both management and eventing channels;
and then enable a separate event-only interface. The Firepower Management Center event-only interface
cannot accept management channel traffic, so you should simply disable the management channel on the
device event interface.
Step 4 Configure the network settings of the management interface and/or event interface:
If you do not specify the management_interface argument, then you change the network settings for the default
management interface. When configuring an event interface, be sure to specify the management_interface
argument. The event interface can be on a separate network from the management interface, or on the same
network. If you are connected to the interface you are configuring, you will be disconnected. You can re-connect
to the new IP address.
a) Configure the IPv4 address:
• Manual configuration:
configure network ipv4 manual ip_address netmask gateway_ip [management_interface]
Example:
>
>
• Manual configuration:
configure network ipv6 manual ip6_address ip6_prefix_length [ip6_gateway_ip]
[management_interface]
Example:
>
Step 5 (Firepower Threat Defense only) Enable a DHCP server on the default management interface to provide IP
addresses to connected hosts:
configure network ipv4 dhcp-server-enable start_ip_address end_ip_address
Example:
> configure network ipv4 dhcp-server-enable 10.10.10.200 10.10.10.254
DHCP Server Enabled
>
You can only configure a DHCP server when you set the management interface IP address manually. This
command is not supported on the Firepower Threat Defense Virtual. To display the status of the DHCP server,
enter show network-dhcp-server:
Example:
> configure network static-routes ipv4 add management0 10.89.89.0 255.255.255.0 10.10.1.1
Configuration updated successfully
>
To display static routes, enter show network-static-routes (the default route is not shown):
[…]
Example:
> configure network hostname farscape1
Example:
> configure network dns searchdomains example.com,cisco.com
Set the search domain(s) for the device, separated by commas. These domains are added to hostnames when
you do not specify a fully-qualified domain name in a command, for example, ping system. The domains are
used only on the management interface, or for commands that go through the management interface.
Example:
> configure network dns servers 10.10.6.5,10.20.89.2,10.80.54.3
Step 10 Set the remote management port for communication with the Management Center:
configure network management-interface tcpport number
Example:
> configure network management-interface tcpport 8555
The Management Center and managed devices communicate using a two-way, SSL-encrypted communication
channel, which by default is on port 8305.
Note Cisco strongly recommends that you keep the default settings for the remote management port, but
if the management port conflicts with other communications on your network, you can choose a
different port. If you change the management port, you must change it for all devices in your
deployment that need to communicate with each other.
Step 11 Configure an HTTP proxy. The device is configured to directly-connect to the internet on ports TCP/443
(HTTPS) and TCP/80 (HTTP). You can use a proxy server, to which you can authenticate via HTTP Digest.
After issuing the command, you are prompted for the HTTP proxy address and port, whether proxy
authentication is required, and if it is required, the proxy username, proxy password, and confirmation of the
proxy password.
configure network http-proxy
Example:
> configure network http-proxy
Manual proxy configuration
Enter HTTP Proxy address: 10.100.10.10
Enter HTTP Proxy Port: 80
Use Proxy Authentication? (y/n) [n]: Y
Enter Proxy Username: proxyuser
Enter Proxy Password: proxypassword
Confirm Proxy Password: proxypassword
These same options are available for 7000 and 8000 Series managed devices. You can also restart the Snort
process on these devices.
Caution Do not shut off appliances using the power button; it may cause a loss of data. Shut down appliances
completely via the web interface.
Caution Restarting the Snort process temporarily interrupts traffic inspection. Whether traffic drops during this
interruption or passes without inspection depends on the model of the managed device and how it handles
traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
For Firepower virtual managed devices, the virtual infrastructure, such as VMware, typically provides
configurable power options to define the way a virtual machine is shut down, restarted, or suspended. Consult
the documentation for your virtual platform to determine how to set these options.
Note For Firepower virtual managed devices running on VMware, custom power options are part of VMware
Tools, so you must have VMware Tools installed on your virtual machines to configure graceful shut
down.
Procedure
Note When you reboot your Firepower Management Center or managed device, this logs you out of your
appliance, and the system runs a database check that can take up to an hour to complete.
Step 5 To restart the appliance:
• Management Center—Click Run Command next to Restart Management Center.
• Managed device—Click Run Command next to Restart Appliance Console.
Note Restarting the Firepower Management Center may cause deleted hosts to reappear in the network
map.
Step 6 To restart the Snort process on a managed device, click Run Command next to Restart Snort.
Note This command is only available from the 7000 and 8000 Series device’s local web interface.
Caution Restarting the Snort process temporarily interrupts traffic inspection. Whether traffic drops during
this interruption or passes without inspection depends on how the device is configured. See Snort®
Restart Traffic Behavior, on page 293 for more information.
Related Topics
Snort® Restart Scenarios , on page 292
Note The system supports only Version 1 of the Server Message Block protocol for backup and remote storage.
You cannot send backups to one remote system and reports to another, but you can choose to send either to
a remote system and store the other on the Firepower Management Center.
Tip After configuring and selecting remote storage, you can switch back to local storage only if you have not
increased the connection database limit.
Procedure
Procedure
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see
Remote Storage Management Advanced Options, on page 894.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.
• Enter Disk Space Threshold for backup to remote storage. Default is 90%.
Procedure
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see
Remote Storage Management Advanced Options, on page 894.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.
Procedure
Step 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see
Remote Storage Management Advanced Options, on page 894.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.
Step 7 If you want to test the settings, you must click Test.
Step 8 Click Save.
sec=mode
where mode is the security mode you want to use for remote storage.
Mode Description
[none] Attempt to connect as null user (no name).
Mode Description
krb5i Use Kerberos authentication and packet signing.
Change Reconciliation
To monitor the changes that users make and ensure that they follow your organization’s preferred standard,
you can configure the system to send, via email, a detailed report of changes made over the past 24 hours.
Whenever a user saves changes to the system configuration, a snapshot is taken of the changes. The change
reconciliation report combines information from these snapshots to present a clear summary of recent system
changes.
The following sample graphic displays a User section of an example change reconciliation report and lists
both the previous value for each configuration and the value after changes. When users make multiple changes
to the same configuration, the report lists summaries of each distinct change in chronological order, beginning
with the most recent.
You can view changes made during the previous 24 hours.
Procedure
Related Topics
Using the Audit Log to Examine Changes, on page 2458
You can configure the Firepower System to prompt users for comments when they modify an access control
policy, intrusion policy, or network analysis policy. You can use comments to track users’ reasons for policy
changes. If you enable comments on policy changes, you can make the comment optional or mandatory. The
system prompts the user for a comment when each new change to a policy is saved.
Procedure
Step 2 Configure the policy comment preferences for any of the following:
• Click Access Control Preferences for comment preferences for access control policies.
• Click Intrusion Policy Preferences for comment preferences for intrusion policies.
• Click Network Analysis Policy Preferences for comment preferences for network analysis policies.
Step 3 You have the following choices for each policy type:
• Disabled—Disables change comments.
• Optional—Gives users the option to describe their changes in a comment.
• Required—Requires users to describe their changes in a comment before saving.
You can also add access to poll for SNMP information over port 161.
Caution By default, access is not restricted. To operate in a more secure environment, consider adding access for
specific IP addresses and then deleting the default any option.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Note that this access list does not control external database access.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Firepower System IP Address Conventions, on page 12
Audit Logs
Firepower Management Center and Classic managed devices log read-only auditing information for user
activity. On the Management Center and 7000 and 8000 Series web interfaces, audit logs are presented in a
standard event view. From this event view, you can view, sort, and filter audit log messages based on any
item in the audit view. You can easily delete and report on audit information and you can view detailed reports
of the changes that users make.
You can configure Firepower Management Center and Classic managed devices to send audit log messages
to the syslog. To do so, you specify the syslog server, and the severity, facility, and optional tag associated
with the messages. The tag appears with the audit log messages in the syslog. The facility indicates the
subsystem that creates the message and the severity defines the severity of the message. Syslog messages do
not include facilities and severities; these values tell the system that receives the syslog messages how to
categorize them.
You can also configure Firepower Management Center and Classic managed devices to stream audit log
messages to an HTTP server.
Audit log streaming settings are part of different configurations depending on the type of appliance:
• For the Firepower Management Center, streaming the audit log is part of the system configuration.
• For a Classic managed device, audit log streaming settings are part of the Firepower Management Center
platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
You can secure the channel for audit log streaming by enabling TLS and mutual authentication using TLS
certificates; for more information, see Custom Audit Log Client Certificates, on page 902.
Caution Sending audit information to an external URL may affect system performance.
When this feature is enabled, audit log records appear in the syslog in the following format :
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
device name precedes the audit log message.
For example, if you specify a tag of FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: admin@10.1.1.2, Operations > Monitoring,
Page View
You can secure the channel for audit log streaming by enabling TLS and mutual authentication using TLS
certificates; for more information, see Custom Audit Log Client Certificates, on page 902.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When this feature is enabled, the appliance sends audit log records to an HTTP server in the following format:
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
device name precedes the audit log message.
For example, if you specify a tag of FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: admin@10.1.1.2, Operations > Monitoring,
Page View
You can secure the channel for this stream by enabling TLS and mutual authentication using SSL certificates;
for more information, see Custom Audit Log Client Certificates, on page 902.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Caution To allow encrypted posts, use an HTTPS URL. Sending audit information to an external URL
may affect system performance.
Step 6 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can require the server to provide a signed certificate. To verify that certificate, configure the appliance
to load one of more certificate revocation lists (CRLs). The appliance compares the server certificate against
those listed in the CRLs. If a server offers a certificate that is listed in a CRL as a revoked certificate, the audit
log cannot be streamed to that server.
Note If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both client
browser certificates and audit log server certificates.
Audit log streaming fails if you import a client certificate that does not meet one of the following criteria:
• The certificate is not signed by the same CA that signed the server certificate.
• The certificate is not signed by a CA that has signed an intermediate certificate in the certificate chain.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
You can view the audit log client certificate only for the appliance you are logged in to.
Note To view the audit log client certificate for an ASA FirePOWER device, use the CLI command show
audit_cert.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
When you generate a certificate request using this procedure, you can generate a certificate for only a single
system. To ensure security, use certificates signed by a globally known and trusted CA.
The system generates certificate request keys in Base-64 encoded PEM format.
Note For an ASA FirePOWER device, generate the key pair and certificate manually.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Submit the certificate request to the certificate authority.
• When you receive the signed certificate, import it to the appliance for which it was requested; see
Importing Audit Log Client Certificates, on page 904.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
If the signing authority that generated the certificate requires you to trust an intermediate CA, provide a
certificate chain (or certificate path).
Audit log streaming will fail if you import a client certificate that does not meet one of the following criteria:
• The certificate is not signed by the same CA that signed the server certificate.
• The certificate is not signed by a CA that has signed an intermediate certificate in the certificate chain.
Note To import an audit log client certificate to an ASA FirePOWER, use the CLI command configure
audit_cert import.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
The system supports validating audit log server certificates using imported CRLs in Distinguished Encoding
Rules (DER) format.
If you choose to use CRLs, to ensure that the list of revoked certificates stays current, you can create a scheduled
task to update the CRLs. The system displays the most recent refresh of the CRLs.
Note If you choose CRLs, the system uses the same CRLs to validate both audit log certificates and certificates
to secure the HTTP connection between an appliance and a web browser.
Caution If you enable mutual authentication without importing a valid client certificate, audit log streaming will
fail.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 6 Enter a valid URL to an existing CRL file and click Add CRL. Repeat to add up to 25 CRLs.
Step 7 Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs.
Note Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs. Edit
the task to set the frequency of the update.
Step 8 Verify that you have a valid server certificate generated by the same certificate authority that created the client
certificate.
Step 9 Click Save.
Dashboard Settings
Dashboards provide you with at-a-glance views of current system status through the use of widgets: small,
self-contained components that provide insight into different aspects of the Firepower System. The Firepower
System is delivered with several predefined dashboard widgets.
You can configure the Firepower Management Center so that Custom Analysis widgets are enabled on the
dashboard.
Related Topics
About Dashboards, on page 201
Use Custom Analysis dashboard widgets to create a visual representation of events based on a flexible,
user-configurable query.
Procedure
DNS Cache
You can configure the system to resolve IP addresses automatically on the event view pages. You can also
configure basic properties for DNS caching performed by the appliance. Configuring DNS caching allows
you to identify IP addresses you previously resolved without performing additional lookups. This can reduce
the amount of traffic on your network and speed the display of event pages when IP address resolution is
enabled.
DNS resolution caching is a system-wide setting that allows the caching of previously resolved DNS lookups.
Procedure
Step 4 In the DNS Cache Timeout (in minutes) field, enter the number of minutes a DNS entry remains cached in
memory before it is removed for inactivity.
The default setting is 300 minutes (five hours).
Related Topics
Configuring Event View Settings, on page 33
Management Interfaces, on page 875
Email Notifications
Configure a mail host if you plan to:
• Email event-based reports
• Email status reports for scheduled tasks
• Email change reconciliation reports
• Email data-pruning notifications
• Use email for discovery event, impact flag, correlation event alerting, intrusion event alerting, and health
event alerting
When you configure email notification, you can select an encryption method for the communication between
the system and mail relay host, and can supply authentication credentials for the mail server if needed. After
configuring, you can test the connection.
Procedure
Note Certificate validation is not required for encrypted communication between the appliance and mail
server.
Step 6 In the From Address field, enter the valid email address you want to use as the source email address for
messages sent by the appliance.
Step 7 Optionally, to supply a user name and password when connecting to the mail server, choose Use
Authentication. Enter a user name in the Username field. Enter a password in the Password field.
Step 8 To send a test email using the configured mail server, click Test Mail Server Settings.
A message appears next to the button indicating the success or failure of the test.
Step 9 Click Save.
Language Selection
You can use the Language page to specify a different language for the web interface.
This configuration applies to either a Firepower Management Center or a 7000 and 8000 Series managed
device.
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a 7000 and 8000 Series managed device, you apply this configuration from the Firepower Management
Center as part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Caution The language you specify here is used for the web interface for every user who logs into the appliance.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Login Banners
You can use the Login Banner page to specify session, login, or custom message banners for a security
appliance or shared policy.
You can use spaces but not tabs in banner text. You can specify multiple lines of text for the banner. If your
text includes empty lines, the system displays this as a carriage return (CR) in the banner. You can only use
ASCII characters, including new-line (press the Enter key), which counts as two characters.
When you access the security appliance through Telnet or SSH, the session closes if there is not enough system
memory available to process the banner messages, or if a TCP write error occurs when attempting to display
the banner messages.
You can create a custom login banner that appears to users logging in via either SSH or the web interface.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
SNMP Polling
You can enable Simple Network Management Protocol (SNMP) polling for Firepower Management Centers
and Classic managed devices. This feature supports use of versions 1, 2, and 3 of the SNMP protocol.
This feature allows access to:
• The standard management information base (MIB), which includes system details such as contact,
administrative, location, service information, IP addressing and routing information, and transmission
protocol usage statistics
• Additional MIBs for 7000 and 8000 Series managed devices that include statistics on traffic passing
through physical interfaces, logical interfaces, virtual interfaces, ARP, NDP, virtual bridges, and virtual
routers
Note When selecting SNMP versions for the SNMP protocol, note that SNMPv2 only supports read-only
communities and SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.
Note that enabling the SNMP feature does not cause the system to send SNMP traps; it only makes the
information in the MIBs available for polling by your network management system.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Note You must add SNMP access for any computer you plan to use to poll the system. Note that the SNMP
MIB contains information that could be used to attack your deployment. Cisco recommends that you
restrict your access list for SNMP access to the specific hosts that will be used to poll for the MIB. Cisco
also recommends you use SNMPv3 and use strong passwords for network management access.
SNMPv3 only supports read-only users and encryption with AES128.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• manually
• using one or more NTP servers (Recommended)
You can use a hardware Firepower Management Center as an NTP server, but do not use a virtual Firepower
Management Center as an NTP server.
If you specify a remote NTP server, your appliance must have network access to it. Do not specify an untrusted
NTP server. Connections to NTP servers do not use configured proxy settings.
Note Ensure that the time on your Firepower Management Center and managed devices matches after time
synchronization. Otherwise, unintended consequences may occur when the managed devices communicate
with the Firepower Management Center.
When the system is synchronizing its time based on NTP, you can view the NTP Status from the Firepower
Management Center's web interface and from 7000 and 8000 Series device's local web interface, which
provides the following information:
Column Description
NTP Server The IP address and name of the configured NTP server.
Column Description
Offset The number of milliseconds of difference between the time on the appliance and the
configured NTP server. Negative values indicate that the appliance is behind the NTP
server, and positive values indicate that it is ahead.
Last Update The number of seconds that have elapsed since the time was last synchronized with the
NTP server. The NTP daemon automatically adjusts the synchronization times based on
a number of conditions. For example, if you see larger update times such as 300 seconds,
that indicates that the time is relatively stable and the NTP daemon has determined that
it does not need to use a lower update increment.
You can view the current time and time source from the Firepower Management Center or the 7000 and 8000
Series device’s local web interface using the Time page.
Note To have the Firepower Management Center serve time using NTP, manually change the time before
configuring the Management Center to serve time using NTP.
Procedure
What to Do Next
• To have the Firepower Management Center serve time using NTP, continue as described in Serving
Time from the Firepower Management Center, on page 916
Note If you configure the Management Center to serve time using NTP, and then later disable it, the NTP service
on managed devices still attempts to synchronize time with the Management Center. You must update
and redeploy any applicable platform settings policies to establish a new time source.
Procedure
Caution If the appliance is rebooted and your DHCP server sets an NTP server record different than the
one you specify here, the DHCP-provided NTP server will be used instead. To avoid this situation,
configure your DHCP server to set the same NTP server.
Step 5 Click Save.
Note It may take a few minutes for the Management Center to synchronize with its managed devices.
Synchronizing Time
Smart License Classic License Supported Devices Supported Domains Access
Any Any Management Center Any Admin
Classic
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• Confirm that the time on your Management Center and managed devices matches.
Session Timeouts
Unattended login sessions of the Firepower System web interface or auxiliary command line interface may
be security risks. You can configure, in minutes, the amount of idle time before a user’s login session times
out due to inactivity. You can also set a similar timeout for shell (command line) sessions.
Your deployment may have users who plan to passively, securely monitor the web interface for long periods
of time. You can exempt users from the web interface session timeout with a user configuration option. Users
with the Administrator role, whose complete access to menu options poses an extra risk if compromised,
cannot be made exempt from session timeouts.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
If you must restrict shell access to the system, an additional option allows you to permanently disable the
expert command in the auxiliary command line interface. Disabling expert mode on an appliance prevents
any user, even users with Configuration shell access, from going into expert mode in the shell. When a user
goes into expert mode on the auxiliary command line interface, the user can run any Linux command appropriate
to the shell. When not in expert mode, command line users can only run the commands provided by the
auxiliary command line interface.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Caution After you deploy a policy with expert mode disabled to an appliance, you cannot restore the ability
to access expert mode through the web interface or the auxiliary command line interface. You
must contact Support to restore the expert mode capability.
Step 4 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Vulnerability Mapping
The Firepower System automatically maps vulnerabilities to a host IP address for any application protocol
traffic received or sent from that address, when the server has an application ID in the discovery event database
and the packet header for the traffic includes a vendor and version.
For any servers which do not include vendor or version information in their packets, you can configure whether
the system associates vulnerabilities with server traffic for these vendor and versionless servers.
For example, a host serves SMTP traffic that does not have a vendor or version in the header. If you enable
the SMTP server on the Vulnerability Mapping page of a system configuration, then save that configuration
to the Firepower Management Center managing the device that detects the traffic, all vulnerabilities associated
with SMTP servers are added to the host profile for the host.
Although detectors collect server information and add it to host profiles, the application protocol detectors
will not be used for vulnerability mapping, because you cannot specify a vendor or version for a custom
application protocol detector and cannot select the server for vulnerability mapping.
Procedure
Tip You can check or clear all check boxes at once using the check box next to Enabled.
Procedure
Note When you change your remote console from Physical Serial Port to Lights-Out Management or
from Lights-Out Management to Physical Serial Port on the 70xx Family of devices (except the
Firepower 7050), you may have to reboot the appliance twice to see the expected boot prompt.
Step 4 To configure LOM via SOL, enter the necessary IPv4 settings:
• Choose the address Configuration for the system (DHCP or Manual)
• Enter the IP Address to be used for LOM.
Note The LOM IP address must be different from the management interface IP address of the system.
What to Do Next
• If you configured Lights-Out Management, enable a Lights-Out Management user; see Lights-Out
Management User Access Configuration, on page 921.
Note that if you deactivate, then reactivate, a role with LOM while a user with that role is logged in, or restore
a user or user role from a backup during that user’s login session, that user must log back into the web interface
to regain access to IPMItool commands.
You configure LOM and LOM users on a per-system basis using each system’s local web interface. You
cannot use the Firepower Management Center to configure LOM on a managed device. Similarly, because
users are managed independently per appliance, enabling or creating a LOM-enabled user on the Firepower
Management Center does not transfer that capability to users on managed devices.
Procedure
Linux
IPMItool is standard with many distributions and is ready to use.
Mac
You must install IPMItool on a Mac. First, confirm that your Mac has Apple's XCode Developer tools installed,
making sure that the optional components for command line development are installed (UNIX Development
and System Tools in newer versions, or Command Line Support in older versions). Then you can install
macports and the IPMItool. Use your favorite search engine for more information or try these sites:
https://developer.apple.com/technologies/tools/
http://www.macports.org/
Windows
You must compile IPMIutil on Windows. If you do not have access to a compiler, you can use IPMIutil itself
to compile. Use your favorite search engine for more information or try this site:
http://ipmiutil.sourceforge.net/
Procedure
Procedure
Note The baseboard management controller (BMC) for a Firepower 71xx, Firepower 82xx, or a Firepower 83xx
device is only accessible via 1Gbps link speeds when the host is powered on. When the device is powered
down, the BMC can only establish Ethernet link at 10 and 100Mbps. Therefore if LOM is being used to
remotely power the device, connect the device to the network using 10 and 100Mbps link speeds only.
Caution In rare cases, if your computer is on a different subnet than the system's management interface and the
system is configured for DHCP, attempting to access LOM features can fail. If this occurs, you can either
disable and then re-enable LOM on the system, or use a computer on the same subnet as the system to
ping its management interface. You should then be able to use LOM.
Caution Cisco is aware of a vulnerability inherent in the Intelligent Platform Management Interface (IPMI) standard
(CVE-2013-4786). Enabling Lights-Out Management (LOM) on an system exposes this vulnerability. To
mitigate this vulnerability, deploy your systems on a secure management network accessible only to trusted
users and use a complex, non-dictionary-based password of the maximum supported length for your system
and change it every three months. To prevent exposure to this vulnerability, do not enable LOM.
If all attempts to access your system have failed, you can use LOM to restart your system remotely. Note that
if a system is restarted while the SOL connection is active, the LOM session may disconnect or time out.
Caution Do not restart your system unless it does not respond to any other attempts to restart. Remotely restarting
does not gracefully reboot the system and you may lose data.
chassis power cycle power -c Restarts the appliance (not valid on 70xx Family
devices)
chassis power off power -d Powers down the appliance (not valid on 70xx
Family devices)
For example, to display a list of appliance information, the IPMItool command is:
Procedure
Procedure
Note In deployments using Firepower Management Center high availability, this feature is available only in
the active Firepower Management Center.
Procedure
You can also enable VMware Tools on all supported versions of ESXi. For a list of supported versions, see
the Cisco Firepower NGIPSv for VMware Quick Start Guide. For information on the full functionality of
VMware Tools, see the VMware website (http://www.vmware.com/).
Because the NGIPSv does not have a web interface, you must use the command line interface to enable
VMware Tools on a NGIPSv; see the Cisco Firepower NGIPSv for VMware Quick Start Guide.
Procedure
Related Topics
Configuring Firepower Platform Settings, on page 934
System Configuration Settings, on page 862
Use the Platform Settings page (Devices > Platform Settings) to manage platform settings policies. This
page indicates the type of device for each policy. The Status column shows the device targets for the policy.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you create a new platform settings policy you must, at minimum, choose the device type: Classic
managed devices or Firepower Threat Defense.
Note Platform settings for Firepower Threat Defense devices differ from platform settings for Classic managed
devices.
Procedure
Step 4 Enter a Name for the new policy and optionally, a Description.
Step 5 Optionally, choose the Available Devices where you want to apply the policy and click Add to Policy (or
drag and drop) to add the selected devices. You can enter a search string in the Search field to narrow the list
of devices.
Step 6 Click Save.
The system creates the policy and opens it for editing.
Step 7 Configure the platform settings based on the device platform type:
• For Firepower Settings, see Introduction to Firepower Platform Settings, on page 933.
• For Threat Defense Settings, see Platform Settings for Firepower Threat Defense, on page 955.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add targeted devices at the same time you create a new policy, or you can change them later.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Platform Settings Policies for Managed Devices, on page 929
System Configuration Settings, on page 862
To configure platform settings, you can edit an existing platform settings policy or create a new policy. If you
edit a platform settings policy that is currently deployed to a device, redeploy the policy after you have saved
your changes.
Procedure
The Edit Policy page appears. You can change the policy name and policy description. For information about
configuring each aspect of the platform settings policy, see one of the following sections:
• Configuring the Access List for Your System, on page 898
• Sending Audit Log Messages to the Syslog, on page 899
• Sending Audit Log Messages to an HTTP Server, on page 900
• Enabling External Authentication, on page 945
• Specifying a Different Language, on page 910
• Adding a Custom Login Banner, on page 911
• Configuring Session Timeouts, on page 918
• Configuring SNMP Polling, on page 912
• Sending Audit Log Messages to the Syslog, on page 899
• Serving Time from the Firepower Management Center, on page 916
Step 3 (Optional) Click Policy Assignment to choose the Available Devices where you want to deploy the policy.
Click Add to Policy (or drag and drop) to add the selected devices.
You can enter a search string in the Search field to narrow the list of devices.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can also add access to poll for SNMP information over port 161.
Caution By default, access is not restricted. To operate in a more secure environment, consider adding access for
specific IP addresses and then deleting the default any option.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Note that this access list does not control external database access.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Audit Logs
Firepower Management Center and Classic managed devices log read-only auditing information for user
activity. On the Management Center and 7000 and 8000 Series web interfaces, audit logs are presented in a
standard event view. From this event view, you can view, sort, and filter audit log messages based on any
item in the audit view. You can easily delete and report on audit information and you can view detailed reports
of the changes that users make.
You can configure Firepower Management Center and Classic managed devices to send audit log messages
to the syslog. To do so, you specify the syslog server, and the severity, facility, and optional tag associated
with the messages. The tag appears with the audit log messages in the syslog. The facility indicates the
subsystem that creates the message and the severity defines the severity of the message. Syslog messages do
not include facilities and severities; these values tell the system that receives the syslog messages how to
categorize them.
You can also configure Firepower Management Center and Classic managed devices to stream audit log
messages to an HTTP server.
Audit log streaming settings are part of different configurations depending on the type of appliance:
• For the Firepower Management Center, streaming the audit log is part of the system configuration.
• For a Classic managed device, audit log streaming settings are part of the Firepower Management Center
platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
You can secure the channel for audit log streaming by enabling TLS and mutual authentication using TLS
certificates; for more information, see Custom Audit Log Client Certificates, on page 902.
Caution Sending audit information to an external URL may affect system performance.
When this feature is enabled, audit log records appear in the syslog in the following format :
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
device name precedes the audit log message.
For example, if you specify a tag of FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: admin@10.1.1.2, Operations > Monitoring,
Page View
You can secure the channel for audit log streaming by enabling TLS and mutual authentication using TLS
certificates; for more information, see Custom Audit Log Client Certificates, on page 902.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 5 From the Facility list, choose a facility described in Syslog Alert Facilities, on page 2100.
Step 6 From the Severity list, choose a severity described in Syslog Severity Levels, on page 2101.
Step 7 Optionally, in the Tag field, enter the tag name that you want to appear with the syslog message. For example,
if you want all audit log records sent to the syslog to be preceded with FROMMC, enter FROMMC in the field.
Step 8 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When this feature is enabled, the appliance sends audit log records to an HTTP server in the following format:
Date Time Host [Tag] Sender: User_Name@User_IP, Subsystem, Action
Where the local date, time, and originating hostname precede the bracketed optional tag, and the sending
device name precedes the audit log message.
For example, if you specify a tag of FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: admin@10.1.1.2, Operations > Monitoring,
Page View
You can secure the channel for this stream by enabling TLS and mutual authentication using SSL certificates;
for more information, see Custom Audit Log Client Certificates, on page 902.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Caution To allow encrypted posts, use an HTTPS URL. Sending audit information to an external URL
may affect system performance.
Step 6 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can require the server to provide a signed certificate. To verify that certificate, configure the appliance
to load one of more certificate revocation lists (CRLs). The appliance compares the server certificate against
those listed in the CRLs. If a server offers a certificate that is listed in a CRL as a revoked certificate, the audit
log cannot be streamed to that server.
Note If you choose to verify certificates using CRLs, the system uses the same CRLs to validate both client
browser certificates and audit log server certificates.
Audit log streaming fails if you import a client certificate that does not meet one of the following criteria:
• The certificate is not signed by the same CA that signed the server certificate.
• The certificate is not signed by a CA that has signed an intermediate certificate in the certificate chain.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
You can view the audit log client certificate only for the appliance you are logged in to.
Note To view the audit log client certificate for an ASA FirePOWER device, use the CLI command show
audit_cert.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
When you generate a certificate request using this procedure, you can generate a certificate for only a single
system. To ensure security, use certificates signed by a globally known and trusted CA.
The system generates certificate request keys in Base-64 encoded PEM format.
Note For an ASA FirePOWER device, generate the key pair and certificate manually.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Submit the certificate request to the certificate authority.
• When you receive the signed certificate, import it to the appliance for which it was requested; see
Importing Audit Log Client Certificates, on page 904.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
If the signing authority that generated the certificate requires you to trust an intermediate CA, provide a
certificate chain (or certificate path).
Audit log streaming will fail if you import a client certificate that does not meet one of the following criteria:
• The certificate is not signed by the same CA that signed the server certificate.
• The certificate is not signed by a CA that has signed an intermediate certificate in the certificate chain.
Note To import an audit log client certificate to an ASA FirePOWER, use the CLI command configure
audit_cert import.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Important The Audit Log Certificate page is not available on a standby Firepower Management Center in a high
availability setup. You cannot perform this task from a standby Firepower Management Center.
The system supports validating audit log server certificates using imported CRLs in Distinguished Encoding
Rules (DER) format.
If you choose to use CRLs, to ensure that the list of revoked certificates stays current, you can create a scheduled
task to update the CRLs. The system displays the most recent refresh of the CRLs.
Note If you choose CRLs, the system uses the same CRLs to validate both audit log certificates and certificates
to secure the HTTP connection between an appliance and a web browser.
Caution If you enable mutual authentication without importing a valid client certificate, audit log streaming will
fail.
Procedure
Step 1 Depending on whether you are configuring audit log streaming for a Firepower Management Center or a
Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 6 Enter a valid URL to an existing CRL file and click Add CRL. Repeat to add up to 25 CRLs.
Step 7 Click Refresh CRL to load the current CRL or CRLs from the specified URL or URLs.
Note Enabling fetching of the CRL creates a scheduled task to regularly update the CRL or CRLs. Edit
the task to set the frequency of the update.
Step 8 Verify that you have a valid server certificate generated by the same certificate authority that created the client
certificate.
Step 9 Click Save.
When you enable external authentication, you can set the default user role for any user whose account is
externally authenticated. You can select multiple roles, as long as those roles can be combined. For example,
if you enable external authentication that retrieves only users in the Network Security group in your company,
you may set the default user role to include the Security Analyst role so users can access collected event data
without any additional user configuration on your part. However, if your external authentication retrieves
records for other personnel in addition to the security group, you would probably want to leave the default
role unselected.
If no access role is selected, users can log in but cannot access any functionality. After a user attempts to log
in, their account is listed on the user management page (System > Users), where you can edit the account
settings to grant additional permissions.
Tip If you configure the system to use one user role and apply the policy, then later modify the configuration
to use different default user roles, any user accounts created before the modification retain the first user
role until you modify the accounts, or delete and recreate them.
If you want to specify the set of users who can authenticate against the LDAP server for shell access or for
CAC authentication and authorization, you must create separate authentication objects for each and enable
the objects separately.
If a user with internal authentication attempts to log in, the system first checks if that user is in the local user
database. If the user exists, the system then checks the username and password against the local database. If
a match is found, the user logs in successfully. If the login fails, however, and external authentication is
enabled, the system checks the user against each external authentication server in the authentication order
shown in the configuration. If the username and password match results from an external server, the system
changes the user to an external user with the default privileges for that authentication object.
If an external user attempts to log in, the system checks the username and password against the external
authentication server. If a match is found, the user logs in successfully. If the login fails, the user login attempt
is rejected. External users cannot authenticate against the user list in the local database. If the user is a new
external user, an external user account is created in the local database with the default privileges from the
external authentication object.
Related Topics
User Accounts, on page 65
Procedure
Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click External Authentication.
Step 3 From the Status drop-down list, choose Enabled.
Step 4 From the Default User Role drop-down list, choose user roles to define the default permissions you want to
grant to externally authenticated users.
Step 5 If you want to use the external server to authenticate CLI or shell access accounts, choose Enabled from the
Shell Authentication drop-down list.
Step 6 If you want to enable CAC authentication and authorization, choose an available CAC authentication object
from the CAC Authentication drop-down list. For information about configuring CAC authentication and
authorization, see CAC Authentication, on page 78.
Step 7 To enable use of a preconfigured authentication object, check the check box next to the object. You must
specify at least one authentication object to enable external authentication.
If you enabled shell authentication, you must specify an authentication object configured to allow CLI or
shell access.
Use different authentication objects to manage CLI or shell access and CAC authentication in the same system
configuration; see CAC Authentication, on page 78 and LDAP Shell Access Fields, on page 94.
Step 8 Optionally, use the up and down arrows to change the order in which authentication servers are accessed when
an authentication request occurs.
CLI or shell access users can only authenticate against the server whose authentication object is highest in
the profile order.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Language Selection
You can use the Language page to specify a different language for the web interface.
This configuration applies to either a Firepower Management Center or a 7000 and 8000 Series managed
device.
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a 7000 and 8000 Series managed device, you apply this configuration from the Firepower Management
Center as part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Caution The language you specify here is used for the web interface for every user who logs into the appliance.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Login Banners
You can use the Login Banner page to specify session, login, or custom message banners for a security
appliance or shared policy.
You can use spaces but not tabs in banner text. You can specify multiple lines of text for the banner. If your
text includes empty lines, the system displays this as a carriage return (CR) in the banner. You can only use
ASCII characters, including new-line (press the Enter key), which counts as two characters.
When you access the security appliance through Telnet or SSH, the session closes if there is not enough system
memory available to process the banner messages, or if a TCP write error occurs when attempting to display
the banner messages.
You can create a custom login banner that appears to users logging in via either SSH or the web interface.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Session Timeouts
Unattended login sessions of the Firepower System web interface or auxiliary command line interface may
be security risks. You can configure, in minutes, the amount of idle time before a user’s login session times
out due to inactivity. You can also set a similar timeout for shell (command line) sessions.
Your deployment may have users who plan to passively, securely monitor the web interface for long periods
of time. You can exempt users from the web interface session timeout with a user configuration option. Users
with the Administrator role, whose complete access to menu options poses an extra risk if compromised,
cannot be made exempt from session timeouts.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
If you must restrict shell access to the system, an additional option allows you to permanently disable the
expert command in the auxiliary command line interface. Disabling expert mode on an appliance prevents
any user, even users with Configuration shell access, from going into expert mode in the shell. When a user
goes into expert mode on the auxiliary command line interface, the user can run any Linux command appropriate
to the shell. When not in expert mode, command line users can only run the commands provided by the
auxiliary command line interface.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
Caution After you deploy a policy with expert mode disabled to an appliance, you cannot restore the ability
to access expert mode through the web interface or the auxiliary command line interface. You
must contact Support to restore the expert mode capability.
Step 4 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
SNMP Polling
You can enable Simple Network Management Protocol (SNMP) polling for Firepower Management Centers
and Classic managed devices. This feature supports use of versions 1, 2, and 3 of the SNMP protocol.
This feature allows access to:
• The standard management information base (MIB), which includes system details such as contact,
administrative, location, service information, IP addressing and routing information, and transmission
protocol usage statistics
• Additional MIBs for 7000 and 8000 Series managed devices that include statistics on traffic passing
through physical interfaces, logical interfaces, virtual interfaces, ARP, NDP, virtual bridges, and virtual
routers
Note When selecting SNMP versions for the SNMP protocol, note that SNMPv2 only supports read-only
communities and SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.
Note that enabling the SNMP feature does not cause the system to send SNMP traps; it only makes the
information in the MIBs available for polling by your network management system.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Note You must add SNMP access for any computer you plan to use to poll the system. Note that the SNMP
MIB contains information that could be used to attack your deployment. Cisco recommends that you
restrict your access list for SNMP access to the specific hosts that will be used to poll for the MIB. Cisco
also recommends you use SNMPv3 and use strong passwords for network management access.
SNMPv3 only supports read-only users and encryption with AES128.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Time settings are displayed on most pages on the appliance in local time using the time zone you set on the
Time Zone page (America/New York by default), but are stored on the appliance itself using UTC time. In
addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed
in the Manual clock setting option, if enabled).
You can manage time synchronization using the Time Synchronization page. You can choose to synchronize
the time:
• manually
• using one or more NTP servers (Recommended)
You can use a hardware Firepower Management Center as an NTP server, but do not use a virtual Firepower
Management Center as an NTP server.
If you specify a remote NTP server, your appliance must have network access to it. Do not specify an untrusted
NTP server. Connections to NTP servers do not use configured proxy settings.
Note Ensure that the time on your Firepower Management Center and managed devices matches after time
synchronization. Otherwise, unintended consequences may occur when the managed devices communicate
with the Firepower Management Center.
Synchronizing Time
Smart License Classic License Supported Devices Supported Domains Access
Any Any Management Center Any Admin
Classic
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center as
part of a platform settings policy.
In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.
Procedure
Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• Management Center—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• Confirm that the time on your Management Center and managed devices matches.
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 Firepower Threat Defense 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 Firepower
Threat Defense device drops the packet.
• If the ARP packet does not match any entries in the static ARP table, then you can set the Firepower
Threat Defense device to either forward the packet out all interfaces (flood), or to drop the packet.
Note The dedicated Diagnostic interface never floods packets even if this parameter is set to
flood.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select ARP Inspection.
Step 3 Add entries to the ARP inspection table.
a) Click Add to create a new entry, or click the Edit icon if the entry already exists.
b) 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.
c) Click OK.
Step 4 Add static ARP entries according to Add a Static ARP Entry, on page 593.
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
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
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 a 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:
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 the Advanced > Security
Configuration tab. Select Devices > Device Management, edit a Firepower Threat Defense device, and
select the Interfaces tab to edit interface properties..
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select Fragment.
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.
Configure HTTP
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
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.
Note You cannot use the system-provided any network object. Instead, use any-ipv4 or
any-ipv6.
• 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. 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 Firepower Management Center. It has a separate IP address and static routing.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a 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.
a) Click Add to add a new rule, or click the Edit icon to edit an existing rule.
b) 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 the + button.
• 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.
c) 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.
By default, you can send ICMP packets to any interface using either IPv4 or IPv6, with these exceptions:
• The Firepower Threat Defense device does not respond to ICMP echo requests directed to a broadcast
address.
• The Firepower Threat Defense device 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.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select ICMP.
Step 3 Configure ICMP rules.
a) Click Add to add a new rule, or click the Edit icon to edit an existing rule.
b) 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 or group 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.
c) 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. This value is not currently used by the system.
Account must have the strong-crypto features enabled. For more information, see Smart License Types and
Restrictions, on page 120.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select SSL.
Step 3 Add entries to the Add SSL Configuration table.
a) Click Add to create a new entry, or click the Edit icon if the entry already exists.
b) Select the required security configurations from the drop-down list .
• Protocol Version—Specifies the TLS protocols to be used while establishing remote access VPN
sessions.
• Security Level—Indicates the kind of security positioning you would like to set up for the SSL.
Step 4 Select the Available Algorithms based on the protocol version that you select and click Add to include them
for the selected protocol. For more information, seeAbout SSL Settings, on page 962
The algorithms are listed based on the protocol version that you select. Each security protocol identifies unique
algorithm for setting up the security level.
What to Do Next
You can click Deploy to deploy the policy to the assigned devices.
Fields
Minimum SSL Version as Server—Specify the minimum SSL/TLS protocol version that the Firepower
Threat Defense device uses when acting as a server. For example, when it functions as a Remote Access VPN
Gateway. Select the protocol version from drop-down list.
TLS V1 Accepts SSLv2 client hellos and negotiates TLSv1 (or greater).
TLSV1.1 Accepts SSLv2 client hellos and negotiates TLSv1.1 (or greater).
TLSV1.2 Accepts SSLv2 client hellos and negotiates TLSv1.2 (or greater).
Diffie-Hellmann Group—Choose a group from the drop-down list. Available options are Group1 - 768-bit
modulus, Group2 - 1024-bit modulus, Group5 - 1536-bit modulus, Group14 - 2048-bit modulus, 224-bit prime
order, and Group24 - 2048-bit modulus, 256-bit prime order. The default is Group1.
Elliptical Curve Diffie-Hellman Group—Choose a group from the drop-down list. Available options are
Group19 - 256-bit EC, Group20 - 384-bit EC, and Group21 - 521-bit EC. The default value is Group19.
TLSv1.2 adds support for the following ciphers:
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-GCM-SHA256
• RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
The SSL configuration table can be used to specify the protocol version, security level, and Cipher algorithms
that you want to support on the Firepower Threat Defense devices.
Protocol Version—Lists the protocol version that the Firepower Threat Defense device supports and uses
for SSL connections. Available protocol versions are:
• Default
• TLSV1
• TLSV1.1
• TLSV1.2
• DTLSv1
Security Level—Lists the cipher security levels that Firepower Threat Defense device supports and uses for
SSL connections. Choose one of the following options:
All includes all ciphers, including NULL-SHA.
Low includes all ciphers, except NULL-SHA.
Medium includes all ciphers, except NULL-SHA, DES-CBC-SHA, RC4-SHA, and RC4-MD5 (this is the
default).
Fips includes all FIPS-compliant ciphers, except NULL-SHA, DES-CBC-SHA, RC4-MD5, RC4-SHA, and
DES-CBC3-SHA.
High includes only AES-256 with SHA-2 ciphers and applies to TLS version 1.2 and the default version.
Custom includes one or more ciphers that you specify in the Cipher algorithms/custom string box. This option
provides you with full control of the cipher suite using OpenSSL cipher definition strings.
Cipher Algorithms/Custom String—Lists the cipher algorithms that Firepower Threat Defense device
supports and uses for SSL connections. For more information about ciphers using OpenSSL, see https://
www.openssl.org/docs/apps/ciphers.html
The Firepower Threat Defense device specifies the order of priority for supported ciphers as:
Ciphers supported by TLSv1.2 only
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA256
AES256-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
AES128-SHA256
RC4-SHA
RC4-MD5
DES-CBC-SHA
NULL-SHA
If you want to allow SSH connections to one or more interfaces on the Firepower Threat Defense device,
configure Secure Shell settings.
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 a Firepower Threat Defense policy.
Step 2 Select Secure Shell.
Step 3 (Optional.) Change SSH access limitations.
• SSH Version—By default, users can connect using SSH version 1 and 2. You can limit access to just
one of those versions. For example, select 2 if you want to support SSH version 2 only.
• Timeout—How long an SSH session can be idle before the system disconnects the session. Set the
timeout from 1 to 60 minutes. The default is 5 minutes.
• Enable Secure Copy—Whether to enable the secure copy (SCP) server on the device. This allows the
device to function as an SCP server for transferring files from or to the device. Only clients that are
allowed to access the security appliance using SSH can establish a secure copy connection. SCP requires
SSH version 2.
Step 4 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.
a) Click Add to add a new rule, or click the Edit icon to edit an existing rule.
b) 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 the + button.
• 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.
c) 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.
Configure SMTP
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
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.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a 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.
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 only supports read-only users and encryption with 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 a 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 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.
Note You create users for SNMPv3 only. These steps are not applicable for SNMPv1 or SNMPv2c.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click SNMP from the table of contents and then click the Users tab.
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 Select the type of authentication you want to use: MD5 or SHA, in the Auth Algorithm Type drop-down
list.
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, 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 theEncryption 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
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click SNMP from the table of contents and then click the Hosts tab.
Step 3 Click Add.
Step 4 In the IP Address field, 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 ClickOK.
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.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 ClickSNMP from the table of contents and click the SNMP Traps tab 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.
a) Check Enable All SNMP Traps to quickly select all traps in the subsequent four sections.
b) Check Enable All Syslog Traps to enable transmission of trap-related syslog messages.
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
Configure 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.
With Firepower Threat Defense, you can configure syslog in two places:
• Platform Settings—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
ASA Series Syslog Messages. This configuration is explained in the following topics.
• Alert Responses—This syslog configuration generates alerts for access control rules, intrusion rules,
and other advanced services as described in Configurations Supporting Alert Responses, on page 2098.
These messages are not numbered. For information on configuring this type of syslog, see Creating a
Syslog Alert Response, on page 2099.
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.
Note Firepower Threat Defense does not generate syslog messages with a severity level of zero (emergencies).
You customize these criteria by creating a message list that you can specify when you set the output destination.
Alternatively, you can configure the Firepower Threat Defense device to send a particular message class to
each type of output destination independently of the message list.
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.
ha Failover (High 101, 102, 103, 104, 105, 210, 311, 709
Availability)
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
sys System 199, 211, 214, 216, 306, 307, 315, 414, 604, 605, 606, 610, 612,
614, 615,701, 711
vpn IKE and IPsec 316, 320, 402, 404, 501, 602, 702, 713, 714, 715
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 Firepower Threat Defense device, you must specify a logging output
destination. If you enable logging without specifying a logging output destination, the Firepower Threat
Defense 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 Firepower Threat Defense 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. For example,
for each syslog server:
◦A Firepower 4110 can have up to 22 UDP syslog connections.
◦A Firepower 4120 can have up to 46 UDP syslog connections.
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 Firepower Threat Defense device sends syslogs via TCP, the connection takes about one
minute to initiate after the syslogd service restarts.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click Syslog from the table of contents.
Step 3 Click the Logging Setup tab to enable logging, specify FTP Server settings, and specify Flash usage. For
more information, see Enable Logging and Configure Basic Settings, on page 977
Step 4 Click the Logging Destinations tab 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, on page 979
You must enable a logging destination to see messages at that destination.
Step 5 Click the E-mail Setup tab 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, on
page 980
Step 6 Click the Events List tab 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, on page 980
Step 7 Click the Rate Limit tab 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, on page 981
Step 8 Click the Syslog Settings tab 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,
on page 982
Step 9 Click the Syslog Servers tab 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, on
page 983
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 a 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.
• 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 711011. 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) Enable VPN logging by checking the Enable Logging to FMC check box. Choose the syslog
severity level for VPN messages from the Logging Level drop-down list.
For information on the levels, see Severity Levels, on page 973.
Step 5 (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 6 (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 bytes.
• 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 bytes.
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 a 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:
a) 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.
b) 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
tab.
• Disable Logging —Prevents messages from being sent to this destination.
c) 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, on page 974.
d) 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.
You can set up a list of recipients for syslog messages to be sent as e-mails.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a 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, on page 973.
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 tab, and then
use the event list to define the logging filter for the various types of destination, in the Logging Destinations
tab.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select Syslog > Events List.
Step 3 Configure an event list.
a) Click Add to add a new list, or edit an existing list.
b) Enter a name for the event list in the Name field. Spaces are not allowed.
c) 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, on page 974.
For information on the levels, see Severity Levels, on page 973.
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.
d) To identify messages specifically by message ID, select the Message ID tab 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, on page 974.
For specific message numbers, see Cisco ASA Series Syslog Messages.
e) Click OK to save the event list.
Step 4 Click the Logging Destinations tab and add or edit the destination that should use the filter.
See Enable Logging Destinations, on page 979.
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 a Firepower Threat Defense policy.
Step 2 Select Syslog > Rate Limit.
Step 3 To limit message generation by severity level, click Add on the Logging Level tab and configure the following
options:
• Logging Level—The severity level you are rate limiting. For information on the levels, see Severity
Levels, on page 973.
• 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.
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 a 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 Check the Enable timestamp on each syslog message check box to include the date and time a message was
generated in the syslog message.
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.
a) 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.
b) To add a rule, click the Add button.
c) 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.
d) 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.
To configure a syslog server to handle messages generated from the data plane, perform the following steps.
To configure a syslog server for connection and other events, for example, for access control rules, see Creating
a Syslog Alert Response, on page 2099.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a 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.
a) In the IP Address drop-down list, select a network host object that contains the IP address of the syslog
server.
b) Choose the protocol (either TCP or UDP) and enter the port number for communications between the
Firepower Threat Defense device and the syslog server.
The default ports are 514 for UDP, 1470 for TCP. Valid non-default port values for either protocol are
1025 through 65535.
c) 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).
d) Check the Enable Secure Syslog check box to encrypt the connection between the device and server using
SSL/TLS over TCP.
You must select TCP as the protocol to use this option. You must also upload the certificate required to
communicate with the syslog server on the Devices > Certificates page. Finally, upload the certificate
from the Firepower Threat Defense device to the syslog server to complete the secure relationship and
allow it to decrypt the traffic.
e) 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, on page 561.
f) 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.
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 a 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 or 5 to 1440
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. 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 ASA 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).
Use Network Time Protocol (NTP) servers to synchronize the clock settings on your devices. By default, the
device uses the Firepower Management Center server as the NTP server, but you can configure a different
NTP server.
Procedure
Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Select Time Synchronization.
Step 3 Configure one of the following clock options:
• Via NTP from Defense Center—Use the Firepower Management Center server as the NTP server.
This is the default.
• Via NTP from—Enter the fully-qualified DNS name (such as ntp.example.com), or IP address, of
another NTP server. You can enter multiple addresses by separating them with commas, for example:
ntp1.example.com, ntp2.example.com.
Note The U.S. Government has changed the name of the Unified Capabilities Approved
Products List (UCAPL) to the Department of Defense Information Network Approved
Products List (DODIN APL). References to UCAPL in this documentation and the
Firepower Management Center web interface can be interpreted as references to DODIN
APL.
• Federal Information Processing Standards (FIPS) 140: a requirements specification for encryption
modules
You can enable security certifications compliance in CC mode or UCAPL mode. Enabling security certifications
compliance does not guarantee strict compliance with all requirements of the security mode selected. For
more information on hardening procedures, refer to the guidelines for this product provided by the certifying
entity.
Caution After you enable this setting, you cannot disable it. If you need to do so, contact Support for assistance.
The system does not allow remote storage for Yes Yes — — — —
backups or reports.
The system does not support exporting event data Yes Yes Yes Yes — —
using eStreamer
By default, the system enforces auto-logout for login Yes Yes Yes Yes Yes Yes
account sessions.
The minimum required password length for the local — — No No Yes Yes
admin user can be configured using the local device
CLI.
The admin user can be locked out after a maximum Yes Yes Yes Yes — —
number of failed login attempts configurable through
the web interface.
The admin user can be locked out after a maximum — — Yes, Yes, Yes Yes
number of failed login attempts configurable through regardless regardless
the local appliance CLI. of security of security
certifications certifications
compliance compliance
enablement. enablement.
The system automtically rekeys an SSH session with Yes Yes Yes Yes Yes Yes
an appliance:
• After a key has been in use for one hour of
session activity
• After a key has been used to transmit 1 GB of
data over the connection
The system performs a file system integrity check Yes Yes Yes Yes Yes Yes
(FSIC) at boot-time. If the FSIC fails, Firepower
software does not start, remote SSH access is
disabled, and you can access the appliance only via
local console. If this happens, contact Cisco TAC.
Caution The Firepower Management Center will not receive event data from a managed device
unless both are operating in the same security certifications compliance mode.
Note The Firepower System does not support CC or UCAPL mode for:
• Firepower Management Centers in high availability pairs
• Classic devices in stacks or high availability pairs
• Firepower Threat Defense devices in clusters
Appliance Hardening
See the following topics for information about features you can use to further harden Firepower:
• Licensing the Firepower System, on page 109
• Firepower System User Authentication, on page 74
• Logging into the Firepower System, on page 15
• Audit Logs, on page 899
• Custom Audit Log Client Certificates, on page 902
This configuration applies to a Firepower Management Center, a Classic managed device (7000 and 8000
Series, ASA FirePOWER, and NGIPSv), or Firepower Threat Defense:
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic or Firepower Threat Defense managed device, you apply this configuration from the
Firepower Management Center as part of a platform settings policy.
In any case, the configuration does not take effect until you save your system configuration changes or deploy
the shared platform settings policy.
Caution After you enable this setting, you cannot disable it. If you need to do so, contact Cisco TAC for assistance.
Procedure
What to Do Next
• If you have not already, apply the Control and Protection licenses to all classic appliances in your
deployment.
• Establish additional configuration changes as described in the guidelines for this product provided by
the certifying entity.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Administrators in ancestor domains can target NAT policies to devices in descendant domains, which descendant
domains can use or replace with customized local policies. If a NAT policy targets devices in different
descendant domains, administrators in the descendant domains can view information about target devices
belonging to their domain only.
Procedure
• Copy — Click the copy icon ( ) next to the policy you want to copy; see Copying NAT Policies, on
page 1003.
• Create — Click New Policy; see Creating NAT Policies, on page 1000.
• Delete — Click the delete icon ( ) next to the policy you want to delete, then click OK. When prompted
whether to continue, you are also informed if another user has unsaved changes in the policy.
Caution After you have deployed a NAT policy to a managed device, you cannot delete the policy
from the device. Instead, you must deploy a NAT policy with no rules to remove the NAT
rules already present on the managed device. You also cannot delete a policy that is the last
deployed policy on any of its target devices, even if it is out of date. Before you can delete
the policy completely, you must deploy a different policy to those targets.
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
• Edit — Click the edit icon ( ); see Configuring NAT Policies, on page 1001.
• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 298.
When you create a new NAT policy you must, at minimum, give it a unique name. Although you are not
required to identify policy targets at policy creation time, you must perform this step before you can deploy
the policy. If you apply a NAT policy with no rules to a device, the system removes all NAT rules from that
device.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Administrators in ancestor domains can target NAT policies to devices in descendant domains, which descendant
domains can use or replace with customized local policies. If a NAT policy targets devices in different
descendant domains, administrators in the descendant domains can view information about target devices
belonging to their domain only.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Administrators in ancestor domains can target NAT policies to devices in descendant domains, which descendant
domains can use or replace with customized local policies. If a NAT policy targets devices in different
descendant domains, administrators in the descendant domains can view information about target devices
belonging to their domain only.
If you change the type of an interface to a type that is not valid for use with a NAT policy that targets a device
with that interface, the policy labels the interface as deleted. Click Save in the NAT policy to automatically
remove the interface from the policy.
Note Rule attributes differ by NAT policy type. When adding or editing rules, click ? in the dialog box for more
information, or see the relevant chapter: Network Address Translation (NAT) for Firepower Threat
Defense, on page 1023 or NAT for 7000 and 8000 Series Devices, on page 1005.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can identify the managed devices you want to target with your policy while creating or editing a policy.
You can search a list of available devices, 7000 or 8000 Series stacks, and high-availability pairs, and add
them to a list of selected devices.
You cannot target stacked devices running different versions of the Firepower System (for example, if an
upgrade on one of the devices fails).
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Administrators in ancestor domains can target NAT policies to devices in descendant domains, which descendant
domains can use or replace with customized local policies. If a NAT policy targets devices in different
descendant domains, administrators in the descendant domains can view information about target devices
belonging to their domain only.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can make a copy of a NAT policy. The copy includes all policy rules and configurations.
In a multidomain deployment, you can copy policies from current and ancestor domains.
Procedure
Caution In 7000 or 8000 Series device high-availability pairs, only select an individual peer interface for a static
NAT rule on a paired device if all networks affected by the NAT translations are private. Do not use
configurations for static NAT rules affecting traffic between public and private networks.
Caution In 7000 or 8000 Series device high-availability pairs, only select an individual peer interface for a static
NAT rule on a paired device if all networks affected by the NAT translations are private. Do not use this
configuration for static NAT rules affecting traffic between public and private networks.
If you configure dynamic NAT on a device high-availability pair without HA link interfaces established, both
paired devices independently allocate dynamic NAT entries, and the system cannot synchronize the entries
between devices.
You can deploy NAT policies to a device stack as you would a standalone device. If you establish a device
stack from devices that were included in a NAT policy and had rules associated with interfaces from the
secondary device that was a member of the stack, the interfaces from the secondary device remain in the NAT
policy. You can save and deploy policies with the interfaces, but the rules do not provide any translation.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain. Administrators in ancestor domains can target NAT policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies
You can specify a dynamic rule’s numeric position when you add or edit a dynamic rule. You can also highlight
a dynamic rule before adding a new dynamic rule to insert the new rule below the rule you highlighted.
You can select one or more dynamic rules by clicking a blank space in the row for the rule. You can drag and
drop selected dynamic rules into a new location, thereby changing the position of the rules you moved and
all subsequent rules.
You can cut or copy selected rules and paste them above or below an existing rule. You can only paste static
rules in the Static Translations list and only dynamic rules in the Dynamic Translations list. You can also
delete selected rules and insert new rules into any location in the list of existing rules.
You can display explanatory warnings to identify rules that will never match because they are preempted by
preceding rules.
If you have access control policies in your deployment, the system does not translate traffic until it has passed
through access control.
Procedure
If you create a rule that causes the NAT policy to fail upon deploy, an error icon ( ) appears next to the rule.
An error occurs if there is a conflict in the static rules, or if you edit a network object used in the policy that
now makes the policy invalid. For example, an error occurs if you change a network object to use only IPv6
addresses and the rule that uses that object no longer has any valid networks where at least one network is
required. Error icons appear automatically; you do not have to click Show Warnings.
Procedure
You create and edit NAT rules from within an existing NAT policy. Each rule belongs to only one policy.
The web interface for adding or editing a rule is similar. You specify the rule name, state, type, and position
(if dynamic) at the top of the page. You build conditions using the tabs on the left side of the page; each
condition type has its own tab.
The following list summarizes the configurable components of a NAT rule.
Name
Give each rule a unique name. For static NAT rules, use a maximum of 22 characters. For dynamic NAT
rules, use a maximum of 30 characters. You can use printable characters, including spaces and special characters,
with the exception of the colon (:).
Rule State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic for
translation. When viewing the list of rules in a NAT policy, disabled rules are grayed out, although you can
still modify them.
Type
A rule’s type determines how the system handles traffic that matches the rule’s conditions. When you create
and edit NAT rules, the configurable components vary according to rule type.
Conditions
Rule conditions identify the specific traffic you want to translate. Conditions can match traffic by any
combination of multiple attributes, including security zone, network, and transport protocol port.
Related Topics
Creating and Editing NAT Rules, on page 1009
In a multidomain deployment, the system displays policies and rules created in the current domain, which
you can edit. It also displays policies and rules created in ancestor domains, which you cannot edit. To view
and edit rules created in a lower domain, switch to that domain.
Procedure
Note Static rules must include an original destination network. Dynamic rules must include a translated
source network.
Step 6 Click Add.
Step 7 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Static
Static rules provide one-to-one translations on destination networks and optionally port and protocol. When
configuring static translations, you can configure source zones, destination networks, and destination ports.
You cannot configure destination zones or source networks.
You must specify an original destination network. For destination networks, you can only select network
objects and groups containing a single IP address or enter literal IP addresses that represent a single IP address.
You can only specify a single original destination network and a single translated destination network.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
You can specify a single original destination port and a single translated destination port. You must specify
an original destination network before you can specify an original destination port. In addition, you cannot
specify a translated destination port unless you also specify an original destination port, and the translated
value must match the protocol of the original value.
Caution For static NAT rules on a 7000 or 8000 Series device in a high-availability pair, only select an individual
peer interface if all networks affected by the NAT translations are private. Do not use this configuration
for static NAT rules affecting traffic between public and private networks.
Dynamic IP Only
Dynamic IP Only rules translate many-to-many source networks, but maintain port and protocol. When
configuring dynamic IP only translations, you can configure zones, source networks, original destination
networks, and original destination ports. You cannot configure translated destination networks or translated
destination ports.
You must specify at least one translated source network. If the number of translated source network values
is less than the number of original source networks, the system displays a warning on the rule that it is possible
to run out of translated addresses before all original addresses are matched.
If there are multiple rules with conditions that match the same packet, the low priority rules become dead,
meaning they can never be triggered. The system also displays warnings for dead rules. You can view tooltips
to determine which rule supersedes the dead rule.
Note You can save and deploy policies with dead rules, but the rules cannot provide any translation.
In some instances, you may want to create rules with limited scope preceding rules with a broader scope. For
example:
Dynamic IP + Port
Dynamic IP and port rules translate many-to-one or many-to-many source networks and port and protocol.
When configuring dynamic IP and port translations, you can configure zones, source networks, original
destination networks, and original destination ports. You cannot configure translated destination networks or
translated destination ports.
You must specify at least one translated source network. If there are multiple rules with conditions that match
the same packet, the low priority rules become dead, meaning they can never be triggered. The system also
displays warnings for dead rules. You can view tool tips to determine which rule supersedes the dead rule.
Note You can save and deploy policies with dead rules, but the rules cannot provide any translation.
If you specify only original destination ports, you cannot specify translated destination ports.
Note If you create a dynamic IP and port rule, and the system passes traffic that does not use a port, no translation
occurs for the traffic. For example, a ping (ICMP) from an IP address that matches the source network
does not map, because ICMP does not use a port.
Table 76: Available NAT Rule Condition Types per NAT Rule Type
Original Destination Ports Optional; single port only, and only Optional
allowed if you define the original
destination network
Translated Destination Ports Optional; single port only, and only Not allowed
allowed if you define the original
destination port
Condition Description
Zones A configuration of one or more routed interfaces where you can deploy
NAT policies. Zones provide a mechanism for classifying traffic on source
and destination interfaces, and you can add source and destination zone
conditions to rules.
Destination Ports Transport protocol ports, including individual and group port objects you
create based on transport protocols.
Adding conditions to NAT rules is essentially the same for each type of condition. You choose from a list of
available conditions on the left, and add the conditions you chose to one or two lists of selected conditions
on the right.
For all condition types, you choose one or more individual available conditions by clicking on them to highlight
them. You can either click a button between the two types of lists to add available conditions that you choose
to your lists of selected conditions, or drag and drop available conditions that you choose into the list of
selected conditions.
You can add up to 50 conditions of each type to a list of selected conditions. For example, you can add up to
50 source zone conditions, up to 50 destination zone conditions, up to 50 source network conditions, and so
on, until you reach the upper limit for the appliance.
Procedure
• To delete a single condition from a list of selected conditions, click the delete icon ( ) next to the
condition.
• To delete a condition from a list of selected conditions, right-click to highlight the row for a selected
condition, then click Delete.
For network conditions, you type the literal value in a configuration field below the list of original or translated
conditions.
In the case of port conditions, you choose a protocol from a drop-down list. When the protocol is All, or TCP
or UDP, you enter a port number in a configuration field.
Each relevant conditions page provides the controls needed to add literal values. Values you enter in a
configuration field appear as red text if the value is invalid, or until it is recognized as valid. Values change
to blue text as you type when they are recognized as valid. A grayed Add button activates when a valid value
is recognized. Literal values you add appear immediately in the list of selected conditions.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
Note You can save and deploy policies with disabled interfaces, but the rules cannot provide any translation
until the interfaces are enabled.
The two lists on the right are the source and destination zones used for matching purposes by the NAT rules.
If the rule already has values configured, these lists display the existing values when you edit the rule. If the
source zones list is empty, the rule matches traffic from any zone or interface. If the destination zones list is
empty, the rule matches traffic to any zone or interface.
The system displays warnings for rules with zone combinations that never trigger on a targeted device.
Note You can save and deploy policies with these zone combinations, but the rules will not provide any
translation.
You can add individual interfaces by selecting an item in a zone or by selecting a standalone interface. You
can only add interfaces in a zone if the zone it is assigned to has not already been added to a source zones or
destination zones list. These individually selected interfaces are not affected by changes to zones, even if you
remove them and add them to a different zone. If an interface is the primary member of a high-availability
pair and you are configuring a dynamic rule, you can add only the primary interface to the source zones or
destination zones list. For static rules, you can add individual high-availability pair member interfaces to the
source zones list. You can only add a primary high-availability pair interface to a list if none of its children
have been added, and you can only add individual high-availability pair interfaces if the primary has not been
added.
If you add a zone, the rule uses all interfaces associated with the zone. If you add or remove an interface from
the zone, the rule will not use the updated version of the zone until the device configuration has been re-deployed
to the devices where the interfaces reside.
Note In a static NAT rule, you can add only source zones. In a dynamic NAT rule, you can add both source
and destination zones.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or
group, it can cause the rule to become invalid.
You can add any of the following kinds of source network conditions to a dynamic NAT rule:
• individual and group network objects that you have created using the object manager
• individual network objects that you add from the Source Network conditions page, and can then add to
your rule and to other existing and future rules
• literal, single IP addresses, ranges, or address blocks
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
When you update the network conditions in a dynamic rule in use in a deployed policy, the system drops any
network sessions using the existing translated address pool.
Procedure
You can add multiple IP addresses, CIDR blocks, and prefix lengths to each network object.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment,
using literal IP addresses to constrain this configuration can have unexpected results. Using
override-enabled objects allows descendant domain administrators to tailor Global configurations
to their local environments.
c) Click Add next to the value you entered.
Step 11 Click Add to save the rule.
Step 12 Click Save to save the changed policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or
group, it can cause the rule to become invalid.
You can add any of the following kinds of destination network conditions to a NAT rule:
• individual and group network objects that you have created using the object manager
• individual network objects that you add from the Destination Network conditions page, and can then
add to your rule and to other existing and future rules
• literal, single IP addresses, range, or address blocks
For static NAT rules, you can add only a CIDR with subnet mask /32, and only if there is not already
a value in the list.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
When you update the network conditions in a dynamic rule in use in a deployed policy, the system drops any
network sessions using the existing translated address pool.
Procedure
• To specify the translation value for traffic that matches the translated destination network, click Add to
Translated.
Step 10 Optionally, click the Enter an IP address prompt below the Original Destination Network or Translated
Destination Network list, enter an IP address or address block, and click Add.
Step 11 Click Add.
Step 12 Click Save to save the changes to the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution If a port object or object group is being used by a NAT rule, and you change or delete the object or group,
it can cause the rule to become invalid.
You can add any of the following kinds of port conditions to a NAT rule:
• individual and group port objects that you have created using the object manager
• individual port objects that you add from the Destination Ports conditions page, and can then add to
your rule and to other existing and future rules
• literal port values, consisting of a TCP, UDP, or All (TCP and UDP) transport protocol and a port
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
One of the main functions of NAT is to enable private IP networks to connect to the Internet. NAT replaces
a private IP address with a public IP address, translating the private addresses in the internal private network
into legal, routable addresses that can be used on the public Internet. In this way, NAT conserves public
addresses because it can be configured to advertise at a minimum only one public address for the entire network
to the outside world.
Other functions of NAT include:
Note NAT is not required. If you do not configure NAT for a given set of traffic, that traffic will not be translated,
but will have all of the security policies applied as normal.
NAT Basics
The following topics explain some of the basics of NAT.
NAT Terminology
This document uses the following terminology:
• Real address/host/network/interface—The real address is the address that is defined on the host, before
it is translated. In a typical NAT scenario where you want to translate the inside network when it accesses
the outside, the inside network would be the “real” network. Note that you can translate any network
connected to the device, not just an inside network. Therefore if you configure NAT to translate outside
addresses, “real” can refer to the outside network when it accesses the inside network.
• Mapped address/host/network/interface—The mapped address is the address that the real address is
translated to. In a typical NAT scenario where you want to translate the inside network when it accesses
the outside, the outside network would be the “mapped” network.
Note During address translation, IP addresses configured for the device interfaces are not
translated.
NAT Types
You can implement NAT using the following methods:
• Dynamic NAT—A group of real IP addresses are mapped to a (usually smaller) group of mapped IP
addresses, on a first come, first served basis. Only the real host can initiate traffic. See Dynamic NAT,
on page 1041.
• Dynamic Port Address Translation (PAT)—A group of real IP addresses are mapped to a single IP
address using a unique source port of that IP address. See Dynamic PAT, on page 1047.
• Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic
initiation. See Static NAT, on page 1054.
• Identity NAT—A real address is statically translated to itself, essentially bypassing NAT. You might
want to configure NAT this way when you want to translate a large group of addresses, but then want
to exempt a smaller subset of addresses. See Identity NAT, on page 1064.
1 When the inside host at 10.1.2.27 sends a packet to a web server, the real source address of the packet,
10.1.2.27, is translated to a mapped address, 209.165.201.10.
2 When the server responds, it sends the response to the mapped address, 209.165.201.10, and the Firepower
Threat Defense device receives the packet because the Firepower Threat Defense device performs proxy
ARP to claim the packet.
3 The Firepower Threat Defense device then changes the translation of the mapped address, 209.165.201.10,
back to the real address, 10.1.2.27, before sending it to the host.
The following figure shows a typical NAT scenario in transparent mode, with the same network on the inside
and outside interfaces. The transparent firewall in this scenario is performing the NAT service so that the
upstream router does not have to perform NAT.
1 When the inside host at 10.1.1.75 sends a packet to a web server, the real source address of the packet,
10.1.1.75, is changed to a mapped address, 209.165.201.15.
2 When the server responds, it sends the response to the mapped address, 209.165.201.15, and the Firepower
Threat Defense device receives the packet because the upstream router includes this mapped network in
a static route directed to the Firepower Threat Defense device management IP address.
3 The Firepower Threat Defense device then undoes the translation of the mapped address, 209.165.201.15,
back to the real address, 10.1.1.1.75. Because the real address is directly-connected, the Firepower Threat
Defense device sends it directly to the host.
4 For host 192.168.1.2, the same process occurs, except for returning traffic, the Firepower Threat Defense
device looks up the route in its routing table and sends the packet to the downstream router at 10.1.1.3
based on the Firepower Threat Defense device static route for 192.168.1.0/24.
We recommend using auto NAT unless you need the extra features that manual NAT provides. It is easier to
configure auto NAT, and it might be more reliable for applications such as Voice over IP (VoIP). (For VoIP,
you might see a failure in the translation of indirect addresses that do not belong to either of the objects used
in the rule.)
Auto NAT
All NAT rules that are configured as a parameter of a network object are considered to be auto NAT rules.
This is a quick and easy way to configure NAT for a network object. You cannot create these rules for a group
object, however.
Although these rules are configured as part of the object itself, you cannot see the NAT configuration in the
object definition through the object manager.
When a packet enters an interface, both the source and destination IP addresses are checked against the auto
NAT rules. The source and destination address in the packet can be translated by separate rules if separate
matches are made. These rules are not tied to each other; different combinations of rules can be used depending
on the traffic.
Because the rules are never paired, you cannot specify that sourceA/destinationA should have a different
translation than sourceA/destinationB. Use manual NAT for that kind of functionality, where you can identify
the source and destination address in a single rule.
Manual NAT
Manual NAT lets you identify both the source and destination address in a single rule. Specifying both the
source and destination addresses lets you specify that sourceA/destinationA can have a different translation
than sourceA/destinationB.
Note For static NAT, the rule is bidirectional, so be aware that “source” and “destination” are used in commands
and descriptions throughout this guide even though a given connection might originate at the “destination”
address. For example, if you configure static NAT with port address translation, and specify the source
address as a Telnet server, and you want all traffic going to that Telnet server to have the port translated
from 2323 to 23, then you must specify the source ports to be translated (real: 23, mapped: 2323). You
specify the source ports because you specified the Telnet server address as the source address.
The destination address is optional. If you specify the destination address, you can either map it to itself
(identity NAT), or you can map it to a different address. The destination mapping is always a static mapping.
Section 3 Manual NAT If a match is still not found, section 3 rules are applied on a first
match basis, in the order they appear in the configuration. This
section should contain your most general rules. You must also
ensure that any specific rules in this section come before general
rules that would otherwise apply.
For section 2 rules, for example, you have the following IP addresses defined within network objects:
• 192.168.1.0/24 (static)
• 192.168.1.0/24 (dynamic)
• 10.1.1.0/24 (static)
• 192.168.1.1/32 (static)
• 172.16.1.0/24 (dynamic) (object def)
• 172.16.1.0/24 (dynamic) (object abc)
NAT Interfaces
Except for bridge group member interfaces, you can configure a NAT rule to apply to any interface (in other
words, all interfaces), or you can identify specific real and mapped interfaces. You can also specify any
interface for the real address, and a specific interface for the mapped address, or vice versa.
For example, you might want to specify any interface for the real address and specify the outside interface
for the mapped address if you use the same private addresses on multiple interfaces, and you want to translate
them all to the same global pool when accessing the outside.
However, the concept of “any” interface does not apply to bridge group member interfaces. When you specify
“any” interface, all bridge group member interfaces are excluded. Thus, to apply NAT to bridge group members,
you must specify the member interface. This could result in many similar rules where only one interface is
different. You cannot configure NAT for the Bridge Virtual Interface (BVI) itself, you can configure NAT
for member interfaces only.
Note You cannot configure NAT for interfaces operating in inline, inline tap, or passive modes. When specifying
interfaces, you do so indirectly by selecting the interface object that contains the interface.
Note If you configure the mapped interface to be any interface, and you specify a mapped address on the same
network as one of the mapped interfaces, then if an ARP request for that mapped address comes in on a
different interface, then you need to manually configure an ARP entry for that network on the ingress
interface, specifying its MAC address. Typically, if you specify any interface for the mapped interface,
then you use a unique network for the mapped addresses, so this situation would not occur. Configure the
ARP table in the ingress interface's Advanced settings.
“source” address). If the Firepower Threat Defense device ARP response is received before the actual host
ARP response, then traffic will be mistakenly sent to the Firepower Threat Defense device.
Note You cannot configure NAT for interfaces operating in inline, inline tap, or passive modes.
The following table lists the inspected protocols that apply NAT rewrite and their NAT limitations. Keep
these limitations in mind when writing NAT rules that include these protocols. Inspected protocols not listed
here do not apply NAT rewrite. These inspections include GTP, HTTP, IMAP, POP, SMTP, SSH, and SSL.
Note NAT rewrite is supported on the listed ports only. For some of these protocols, you can extend inspection
to other ports using Network Analysis Policies, but NAT rewrite is not extended to those ports. This
includes DCERPC, DNS, FTP, and Sun RPC inspection. If you use these protocols on non-standard ports,
do not use NAT on the connections.
DNS over UDP UDP/53 No NAT support is available for name resolution No
through WINS.
Note If you remove a dynamic NAT or PAT rule, and then add a new rule with mapped
addresses that overlap the addresses in the removed rule, then the new rule will not be
used until all connections associated with the removed rule time out or are cleared using
the clear xlate command. This safeguard ensures that the same address is not assigned
to multiple hosts.
• You cannot use an object group with both IPv4 and IPv6 addresses; the object group must include only
one type of address.
• (Manual NAT only.) When using any as the source address in a NAT rule, the definition of “any” traffic
(IPv4 vs. IPv6) depends on the rule. Before the Firepower Threat Defense device performs NAT on a
packet, the packet must be IPv6-to-IPv6 or IPv4-to-IPv4; with this prerequisite, the Firepower Threat
Defense device can determine the value of any in a NAT rule. For example, if you configure a rule from
“any” to an IPv6 server, and that server was mapped from an IPv4 address, then any means “any IPv6
traffic.” If you configure a rule from “any” to “any,” and you map the source to the interface IPv4 address,
then any means “any IPv4 traffic” because the mapped interface address implies that the destination is
also IPv4.
• You can use the same mapped object or group in multiple NAT rules.
• The mapped IP address pool cannot include:
◦The mapped interface IP address. If you specify “any” interface for the rule, then all interface IP
addresses are disallowed. For interface PAT (routed mode only), specify the interface name instead
of the interface address.
◦The failover interface IP address.
◦(Transparent mode.) The management IP address.
◦(Dynamic NAT.) The standby interface IP address when VPN is enabled.
• Avoid using overlapping addresses in static and dynamic NAT policies. For example, with overlapping
addresses, a PPTP connection can fail to get established if the secondary connection for PPTP hits the
static instead of dynamic xlate.
• If you specify a destination interface in a rule, then that interface is used as the egress interface rather
than looking up the route in the routing table. However, for identity NAT, you have the option to use a
route lookup instead.
Network address translation can be very complex. We recommend that you keep your rules as simple as
possible to avoid translation problems and difficult troubleshooting situations. Careful planning before you
implement NAT is critical. The following procedure provides the basic approach.
The NAT policy is a shared policy. You assign the policy to devices that should have similar NAT rules.
Whether a given rule in the policy applies to an assigned device is determined by the interface objects (security
zones or interface groups) used in the rule. If the interface objects include one or more interface for the device,
the rule is deployed to the device. Thus, you can configure rules that apply to subsets of devices within a
single shared policy by carefully designing your interface objects. Rules that apply to “any” interface object
are deployed to all devices.
You can configure multiple NAT policies if groups of your devices require significantly different rules.
Procedure
To accomplish the above, you would do the following. Although this example rule is for dynamic auto NAT,
you can generalize the technique for any type of NAT rule.
Procedure
Step 1 Create the security zones for the inside and outside interfaces.
a) Choose Objects > Object Management.
b) Select Interface Objects from the table of contents and click Add > Security Zone. (You can use interface
groups instead of zones.)
c) Configure the inside zone properties.
• Name—Enter a name, for example, inside-zone.
• Type—Select Routed for routed-mode devices, Switched for transparent mode.
• Selected Interfaces—Add the FTD-A/inside and FTD-B/inside interfaces to the selected list.
d) Click Save.
e) Click Add > Security Zone and define the outside zone properties.
• Name—Enter a name, for example, outside-zone.
• Type—Select Routed for routed-mode devices, Switched for transparent mode.
• Selected Interfaces—Add the FTD-A/outside and FTD-B/outside interfaces to the selected list.
f) Click Save.
Step 2 Create the network object for the original inside network on the Object Management page.
a) Select Network from the table of contents and click Add Network > Add Object.
b) Configure the inside network properties.
• Name—Enter a name, for example, inside-network.
• Network—Enter the network address, for example, 192.168.1.0/24.
c) Click Save.
Step 3 Create the network object for the translated NAT pool and define overrides.
a) Click Add Network > Add Object.
b) Configure the NAT pool properties for FTD-A.
• Name—Enter a name, for example, NAT-pool.
• Network—Enter the range of addresses to include in the pool for FTD-A, for example,
10.100.10.10-10.100.10.200.
Note The interface objects control on which devices the rule is configured. Because in this example
the zones contain interfaces for FTD-A and FTD-B only, even if the NAT policy were assigned
to additional devices, the rule would be deployed to those 2 devices only.
e) On the Translation tab, configure the following:
• Original Source = inside-network object.
• Translated Source > Address= NAT-pool object.
f) Click Save.
You now have a single rule that will be interpreted differently for FTD-A and FTD-B, providing unique
translations for the inside networks protected by each firewall.
Dynamic NAT
The following topics explain dynamic NAT and how to configure it.
Note For the duration of the translation, a remote host can initiate a connection to the translated host if an access
rule allows it. Because the address is unpredictable, a connection to the host is unlikely. Nevertheless, in
this case you can rely on the security of the access rule.
The following figure shows a typical dynamic NAT scenario. Only real hosts can create a NAT session, and
responding traffic is allowed back.
The following figure shows a remote host attempting to initiate a connection to a mapped address. This address
is not currently in the translation table; therefore, the packet is dropped.
The advantage of dynamic NAT is that some protocols cannot use PAT. PAT does not work with the following:
• IP protocols that do not have a port to overload, such as GRE version 0.
• Some multimedia applications that have a data stream on one port, the control path on another port, and
are not open standard.
Use dynamic auto NAT rules to translate addresses to different IP addresses that are routable on the destination
network.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
traffic exits the device. By default, the rule applies to all interfaces (Any) except for bridge group member
interfaces.
Use dynamic manual NAT rules when auto NAT does not meet your needs. For example, if you want to do
different translations based on the destination. Dynamic NAT translates addresses to different IP addresses
that are routable on the destination network.
• Translated Source—This can be a network object or group, but it cannot include a subnet.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule.
For dynamic NAT, you can also perform port translation on the destination. In the Object Manager, ensure
that there are port objects you can use for the Original Destination Port and Translated Destination Port.
If you specify the source port, it will be ignored.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 (On the Translation tab.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet
addresses as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—The network object or group that contains the mapped addresses.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.
Step 7 (Optional.) Identify the destination service ports for service translation: Original Destination Port, Translated
Destination Port.
Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source
Port fields empty. However, because the destination translation is always static, you can perform port translation
for the destination port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
fallback). This option is available only if you select a destination interface that is not a member of a
bridge group. To use the IPv6 address of the interface, also check the IPv6 option.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
Dynamic PAT
The following topics describe dynamic PAT.
For the duration of the translation, a remote host on the destination network can initiate a connection to the
translated host if an access rule allows it. Because the port address (both real and mapped) is unpredictable,
a connection to the host is unlikely. Nevertheless, in this case you can rely on the security of the access rule.
After the connection expires, the port translation also expires.
You cannot use dynamic PAT for IPv6 (NAT66) when translating between interfaces in the same bridge
group. This restriction does not apply when the interfaces are members of different bridge groups, or between
a bridge group member and a standard routed interface.
Dynamic PAT does not work with some multimedia applications that have a data stream that is different from
the control path. For more information, see NAT Support for Inspected Protocols, on page 1034.
Dynamic PAT might also create a large number of connections appearing to come from a single IP address,
and servers might interpret the traffic as a DoS attack. You can configure a PAT pool of addresses and use a
round-robin assignment of PAT addresses to mitigate this situation.
Use dynamic auto PAT rules to translate addresses to unique IP address/port combinations, rather than to
multiple IP addresses only. You can translate to a single address (either the destination interface's address or
another address), or use a PAT pool of addresses to provide a larger number of possible translations.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
this NAT rule applies. Source is the object containing the real interface, the one through which the traffic
enters the device. Destination is the object containing the mapped interface, the one through which
traffic exits the device. By default, the rule applies to all interfaces (Any) except for bridge group member
interfaces.
Step 6 If you are using a PAT pool, select the PAT Pool tab and do the following:
a) Select Enable PAT pool.
b) Select the network object group that contains the addresses for the pool in the PAT > Address field.
You can alternatively select Destination Interface IP, which is another way to implement interface PAT.
c) (Optional) Select the following options as needed:
• Use Round Robin Allocation—To assign addresses/ports in a round-robin fashion. By default
without round robin, all ports for a PAT address will be allocated before the next PAT address is
used. The round-robin method assigns one address/port from each PAT address in the pool before
returning to use the first address again, and then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as
opposed to per IP address, by including the destination address and port in the translation information.
Normally, the destination port and address are not considered when creating PAT translations, so
you are limited to 65535 ports per PAT address. For example, with extended PAT, you can create a
translation of 10.1.1.1:1027 when going to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027
when going to 192.168.1.7:80. You cannot use this option with interface PAT or interface PAT
fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat
range when allocating TCP/UDP ports. When choosing the mapped port number for a translation,
PAT uses the real source port number if it is available. However, without this option, if the real port
is not available, by default the mapped ports are chosen from the same range of ports as the real port
number: 1 to 511, 512 to 1023, and 1024 to 65535. To avoid running out of ports at the low ranges,
configure this setting. To use the entire range of 1 to 65535, also check the Include Reserved Ports
option.
fallback). This option is available only if you select a destination interface that is not a member of a
bridge group. To use the IPv6 address of the interface, also check the IPv6 option. You cannot select
this option if you already configured interface PAT as the translated address or PAT pool.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
Use dynamic manual PAT rules when auto PAT does not meet your needs. For example, if you want to do
different translations based on the destination. Dynamic PAT translates addresses to unique IP address/port
combinations, rather than to multiple IP addresses only. You can translate to a single address (either the
destination interface's address or another address), or use a PAT pool of addresses to provide a larger number
of possible translations.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule.
For dynamic NAT, you can also perform port translation on the destination. In the Object Manager, ensure
that there are port objects you can use for the Original Destination Port and Translated Destination Port.
If you specify the source port, it will be ignored.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 (On the Translation tab.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet
addresses as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
◦(Interface PAT.) To use the address of the destination interface, select Destination Interface IP.
You must also select a specific destination interface object. To use the IPv6 address of the interface,
you must also select the IPv6 option on the Advanced tab. Skip the step for configuring a PAT
pool.
◦To use a single address other than the destination interface address, select the host network object
you created for this purpose. Skip the step for configuring a PAT pool.
◦To use a PAT pool, leave Translated Source empty.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.
Step 7 (Optional.) Identify the destination service ports for service translation: Original Destination Port, Translated
Destination Port.
Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source
Port fields empty. However, because the destination translation is always static, you can perform port translation
for the destination port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
Step 8 If you are using a PAT pool, select the PAT Pool tab and do the following:
a) Select Enable PAT pool.
b) Select the network object group that contains the addresses for the pool in the PAT > Address field.
You can alternatively select Destination Interface IP, which is another way to implement interface PAT.
c) (Optional) Select the following options as needed:
• Use Round Robin Allocation—To assign addresses/ports in a round-robin fashion. By default
without round robin, all ports for a PAT address will be allocated before the next PAT address is
used. The round-robin method assigns one address/port from each PAT address in the pool before
returning to use the first address again, and then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as
opposed to per IP address, by including the destination address and port in the translation information.
Normally, the destination port and address are not considered when creating PAT translations, so
you are limited to 65535 ports per PAT address. For example, with extended PAT, you can create a
translation of 10.1.1.1:1027 when going to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027
when going to 192.168.1.7:80. You cannot use this option with interface PAT or interface PAT
fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat
range when allocating TCP/UDP ports. When choosing the mapped port number for a translation,
PAT uses the real source port number if it is available. However, without this option, if the real port
is not available, by default the mapped ports are chosen from the same range of ports as the real port
number: 1 to 511, 512 to 1023, and 1024 to 65535. To avoid running out of ports at the low ranges,
configure this setting. To use the entire range of 1 to 65535, also check the Include Reserved Ports
option.
Static NAT
The following topics explain static NAT and how to implement it.
Note For applications that require application inspection for secondary channels (for example, FTP and VoIP),
NAT automatically translates the secondary ports.
Following are some other uses of static NAT with port translation.
Static NAT with Identity Port Translation
You can simplify external access to internal resources. For example, if you have three separate servers
that provide services on different ports (such as FTP, HTTP, and SMTP), you can give external users
a single IP address to access those services. You can then configure static NAT with identity port
translation to map the single external IP address to the correct IP addresses of the real servers based on
the port they are trying to access. You do not need to change the port, because the servers are using the
standard ones (21, 80, and 25 respectively).
For example, you have a load balancer at 10.1.2.27. Depending on the URL requested, it redirects traffic to
the correct web server.
For a many-to-few or many-to-one configuration, where you have more real addresses than mapped addresses,
you run out of mapped addresses before you run out of real addresses. Only the mappings between the lowest
real IP addresses and the mapped pool result in bidirectional initiation. The remaining higher real addresses
can initiate traffic, but traffic cannot be initiated to them (returning traffic for a connection is directed to the
correct real address because of the unique 5-tuple (source IP, destination IP, source port, destination port,
protocol) for the connection).
Note Many-to-few or many-to-one NAT is not PAT. If two real hosts use the same source port number and go
to the same outside server and the same TCP destination port, and both hosts are translated to the same
IP address, then both connections will be reset because of an address conflict (the 5-tuple is not unique).
Instead of using a static rule this way, we suggest that you create a one-to-one rule for the traffic that needs
bidirectional initiation, and then create a dynamic rule for the rest of your addresses.
Use static auto NAT rules to translate addresses to different IP addresses that are routable on the destination
network. You can also do port translation with the static NAT rule.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
• (Optional.) Original Port, Translated Port—If you need to translate a TCP or UDP port, select the
protocol in Original Port, and type the original and translated port numbers. For example, you can
translate TCP/80 to 8080 if necessary.
Use static manual NAT rules when auto NAT does not meet your needs. For example, if you want to do
different translations based on the destination. Static NAT translates addresses to different IP addresses that
are routable on the destination network. You can also do port translation with the static NAT rule.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 (On the Translation tab.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet
addresses as they appear in the original packet.
See the following figure for an example of the original packet vs. the translated packet.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
◦To use a set group of addresses, select Address and the network object or group that contains the
mapped addresses. Typically, you configure the same number of mapped addresses as real addresses
for a one-to-one mapping. You can, however, have a mismatched number of addresses.
◦(Static interface NAT with port translation.) To use the address of the destination interface, select
Destination Interface IP. You must also select a specific destination interface object. To use the
IPv6 address of the interface, you must also select the IPv6 option on the Advanced tab. This
configures static interface NAT with port translation: the source address/port is translated to the
interface's address and the same port number.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.
Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or
both. For example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination
address.
• Unidirectional—Select this option to prevent the destination addresses from initiating traffic to the
source addresses.
Identity NAT
You might have a NAT configuration in which you need to translate an IP address to itself. For example, if
you create a broad rule that applies NAT to every network, but want to exclude one network from NAT, you
can create a static NAT rule to translate an address to itself.
The following figure shows a typical identity NAT scenario.
Use static identity auto NAT rules to prevent the translation of an address. That is, to translate the address to
itself.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Do not configure the Original Port and Translated Port options for identity NAT.
have the system determine the destination interface based on the routing table rather than using the
destination interface configured in the NAT rule.
Use static identity manual NAT rules when auto NAT does not meet your needs. For example, if you want
to do different translations based on the destination. Use static identity NAT rules to prevent the translation
of an address. That is, to translate the address to itself.
You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports. You can use the same object for identity
NAT.
Procedure
Step 1 Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.
Step 5 Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear in the
original packet.
See the following figure for an example of the original packet vs. the translated packet where you perform
identity NAT on the inside host but translate the outside host.
• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Interface Object to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.
Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or
both. For example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination
address.
NAT rules include the following basic properties. The properties are the same for auto NAT and manual NAT
rules except where indicated.
NAT Type
Whether you want to configure a Manual NAT Rule or an Auto NAT Rule. Auto NAT translates the
source address only, and you cannot make different translations based on the destination address.
Because auto NAT is more simple to configure, use it unless you need the added features of manual
NAT. For more information on the differences, see Auto NAT and Manual NAT, on page 1027.
Type
Whether the translation rule is Dynamic or Static. Dynamic translation automatically chooses the
mapped address from a pool of addresses, or an address/port combination when implementing PAT.
Use static translation if you want to precisely define the mapped address/port.
The following topics describe the tabs for the NAT rules properties.
Note The concept of “any” interface does not apply to bridge group member interfaces. When you specify “any”
interface, all bridge group member interfaces are excluded. Thus, to apply NAT to bridge group members,
you must specify the member interface. You cannot configure NAT for the Bridge Virtual Interface (BVI)
itself, you can configure NAT for member interfaces only.
If you select interface objects, a NAT rule will be configured on an assigned device only if the device has
interfaces included in all selected objects. For example, if you select both source and destination security
zones, both zones must contain one or more interface for a given device.
• Identity NAT—The same object as the original source. Optionally, you can select a different
object that has the exact same contents.
• Identity NAT—The same object as the original source. Optionally, you can select a different
object that has the exact same contents.
Original Destination
The network object that contains the addresses of the destinations. If you leave this blank, the source
address translation applies regardless of destination. If you do specify the destination address, you can
configure a static translation for that address or just use identity NAT for it.
You can select Source Interface IP to base the original destination on the source interface (which
cannot be Any). If you select this option, you must also select a translated destination object. To
implement a static interface NAT with port translation for the destination addresses, select this option
and also select the appropriate port objects for the destination ports.
Translated Destination
The network object or group that contains the destination addresses used in the translated packet. If
you selected an object for Original Destination, you can set up identity NAT (that is, no translation)
by selecting the same object.
Original Source Port, Translated Source Port, Original Destination Port, Translated Destination Port
The port objects that define the source and destination services for the original and translated packets.
You can translate the ports, or select the same object to make the rule sensitive to the service without
translating the ports. Keep the following rules in mind when configuring services:
• (Dynamic NAT or PAT.) You cannot do translation on the Original Source Port and Translated
Source Port. You can do translation on the destination port only.
• NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and
mapped service objects are identical (both TCP or both UDP). For identity NAT, you can use the
same service object for both the real and mapped ports.
PAT
The addresses to use for the PAT pool, one of the following:
• Address—The object that defines the PAT pool addresses, either a network object that includes
a range, or a network object group that contains hosts, ranges, or both. You cannot include subnets.
The group cannot contain both IPv4 and IPv6 addresses; it must contain one type only.
• Destination Interface IP—Indicates that you want to use the destination interface as the PAT
address. For this option, you must select a specific Destination Interface Object; you cannot
use Any as the destination interface. This is another way to implement interface PAT.
Round Robin
To assign addresses/ports in a round-robin fashion. By default without round robin, all ports for a PAT
address will be allocated before the next PAT address is used. The round-robin method assigns one
address/port from each PAT address in the pool before returning to use the first address again, and then
the second address, and so on.
IPv6
Whether to use the IPv6 address of the destination interface for interface PAT.
Perform Route Lookup for Destination Interface (Static Identity NAT only. Routed mode only.)
If you select source and destination interfaces when selecting the same object for original and translated
source address, you can select this option to have the system determine the destination interface based
on the routing table rather than using the destination interface configured in the NAT rule.
• NAT66—Translates IPv6 packets to a different IPv6 address. We recommend using static NAT. Although
you can use dynamic NAT or PAT, IPv6 addresses are in such large supply, you do not have to use
dynamic NAT.
Note NAT64 and NAT 46 are possible on standard routed interfaces only. NAT66 is possible on both routed
and bridge group member interfaces.
You need to define two policies, one for the source IPv6 network, and one for the destination IPv4 network.
Although you can accomplish this with a single manual NAT rule, if the DNS server is on the external network,
you probably need to rewrite the DNS response. Because you cannot enable DNS rewrite on a manual NAT
rule when you specify a destination, creating two auto NAT rules is the better solution.
Following is a typical example where you have an inside IPv6-only network, but there are some IPv4-only
services on the outside Internet that internal users need.
In this example, you translate the inside IPv6 network to IPv4 using dynamic interface PAT with the IP address
of the outside interface. Outside IPv4 traffic is statically translated to addresses on the 2001:db8::/96 network,
allowing transmission on the inside network. You enable DNS rewrite on the NAT46 rule, so that replies from
the external DNS server can be converted from A (IPv4) to AAAA (IPv6) records, and the addresses converted
from IPv4 to IPv6.
Following is a typical sequence for a web request where a client at 2001:DB8::100 on the internal IPv6 network
tries to open www.example.com.
1 The client’s computer sends a DNS request to the DNS server at 2001:DB8::D1A5:CA81. The NAT rules
make the following translations to the source and destination in the DNS request:
• 2001:DB8::100 to a unique port on 209.165.201.1 (The NAT64 interface PAT rule.)
• 2001:DB8::D1A5:CA81 to 209.165.202.129 (The NAT46 rule. D1A5:CA81 is the IPv6 equivalent
of 209.165.202.129.)
2 The DNS server responds with an A record indicating that www.example.com is at 209.165.200.225. The
NAT46 rule, with DNS rewrite enabled, converts the A record to the IPv6-equivalent AAAA record, and
translates 209.165.200.225 to 2001:db8:D1A5:C8E1in the AAAA record. In addition, the source and
destination addresses in the DNS response are untranslated:
• 209.165.202.129 to 2001:DB8::D1A5:CA81
• 209.165.201.1 to 2001:db8::100
3 The IPv6 client now has the IP address of the web server, and makes an HTTP request to www.example.com
at 2001:db8:D1A5:C8E1. (D1A5:C8E1 is the IPv6 equivalent of 209.165.200.225.) The source and
destination of the HTTP request are translated:
• 2001:DB8::100 to a unique port on 209.156.101.54 (The NAT64 interface PAT rule.)
Procedure
Step 1 Create the network objects that define the inside IPv6 and outside IPv4 networks.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8::/96.
d) Click Save.
e) Click Add Network > Add Object and define the outside IPv4 network.
Name the network object (for example, outside_v4_any) and enter the network address 0.0.0.0/0.
f) Click Save.
Step 2 Configure the NAT64 dynamic PAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
f) Click OK.
With this rule, any traffic from the 2001:db8::/96 subnet on the inside interface going to the outside interface
gets a NAT64 PAT translation using the IPv4 address of the outside interface.
Step 3 Configure the static NAT46 rule for the outside IPv4 network.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) On the Advanced tab, select Translate DNS replies that match this rule.
f) Click OK.
With this rule, any IPv4 address on the outside network coming to the inside interface is translated to an
address on the 2001:db8::/96 network using the embedded IPv4 address method. In addition, DNS responses
are converted from A (IPv4) to AAAA (IPv6) records, and the addresses converted from IPv4 to IPv6.
You can configure a static translation between IPv6 address pools using auto NAT. The following example
explains how to convert inside addresses on the 2001:db8:122:2091::/96 network to outside addresses on the
2001:db8:122:2999::/96 network.
Procedure
Step 1 Create the network objects that define the inside IPv6 and outside IPv6 NAT networks.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.
d) Click Save.
e) Click Add Network > Add Object and define the outside IPv6 NAT network.
Name the network object (for example, outside_nat_v6) and enter the network address
2001:db8:122:2999::/96.
f) Click Save.
Step 2 Configure the static NAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click OK.
With this rule, any traffic from the 2001:db8:122:2091::/96 subnet on the inside interface going to the
outside interface gets a static NAT66 translation to an address on the 2001:db8:122:2999::/96 network.
A simple approach for implementing NAT66 is to dynamically assign internal addresses to different ports on
the outside interface IPv6 address.
When you configure an interface PAT rule for NAT66, all the global addresses that are configured on that
interface are used for PAT mapping. Link-local or site-local addresses for the interface are not used for PAT.
Procedure
Step 1 Create the network object that defines the inside IPv6 network.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.
d) Click Save.
Step 2 Configure the dynamic PAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) On the Advanced tab, select IPv6, which indicates that the IPv6 address of the destination interface should
be used.
g) Click OK.
With this rule, any traffic from the 2001:db8:122:2091::/96 subnet on the inside interface going to the
outside interface gets a NAT66 PAT translation to one of the IPv6 global addresses configured for the
outside interface.
Monitoring NAT
To monitor and troubleshoot NAT connections, log into the device CLI and use the following commands.
• show nat displays the NAT rules and per-rule hit counts. There are additional keywords to show other
aspects of NAT.
• show xlate displays the actual NAT translations that are currently active.
• clear xlate lets you remove an active NAT translation. You might need to remove active translations if
you alter NAT rules, because existing connections continue to use the old translation slot until the
connection ends. Clearing a translation allows the system to build a new translation for a client on the
client's next connection attempt based on your new rules.
The following example performs static NAT for an inside web server. The real address is on a private network,
so a public address is required. Static NAT is necessary so hosts can initiate traffic to the web server at a fixed
address.
Procedure
Step 1 Create the network objects that define the server’s private and public host addresses.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the web server’s private address.
Name the network object (for example, WebServerPrivate) and enter the real host IP address, 10.1.2.27.
d) Click Save.
e) Click Add Network > Add Object and define the public address.
Name the network object (for example, WebServerPublic) and enter the host address 209.165.201.10.
f) Click Save.
Step 2 Configure static NAT for the object.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 3 Click Save on the NAT rule page.
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
The following example configures dynamic NAT for inside users on a private network when they access the
outside. Also, when inside users connect to an outside web server, that web server address is translated to an
address that appears to be on the inside network.
Figure 35: Dynamic NAT for Inside, Static NAT for Outside Web Server
Procedure
Step 1 Create a network object for the dynamic NAT pool to which you want to translate the inside addresses.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the dynamic NAT pool.
Name the network object (for example, myNATpool) and enter the network range
209.165.201.20-209.165.201.30.
d) Click Save.
Step 2 Create a network object for the inside network.
a) Click Add Network > Add Object.
b) Name the network object (for example, MyInsNet) and enter the network address 10.1.2.0/24.
c) Click Save.
Step 3 Create a network object for the outside web server.
a) Click Add Network > Add Object.
b) Name the network object (for example, MyWebServer) and enter the host address 209.165.201.12.
c) Click Save.
Step 4 Create a network object for the translated web server address.
a) Click Add Network > Add Object.
b) Name the network object (for example, TransWebServer) and enter the host address 10.1.2.20.
c) Click Save.
Step 5 Configure dynamic NAT for the inside network using the dynamic NAT pool object.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 6 Configure static NAT for the web server.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 7 Click Save on the NAT rule page.
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
The following example shows an inside load balancer that is translated to multiple IP addresses. When an
outside host accesses one of the mapped IP addresses, it is untranslated to the single load balancer address.
Depending on the URL requested, it redirects traffic to the correct web server.
Figure 36: Static NAT with One-to-Many for an Inside Load Balancer
Procedure
Step 1 Create a network object for the addresses to which you want to map the load balancer.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the addresses.
Name the network object (for example, myPublicIPs) and enter the network range
209.165.201.3-209.165.201.5.
d) Click Save.
Step 2 Create a network object for the load balancer.
a) Click Add Network > Add Object.
b) Name the network object (for example, myLBHost), enter the host address 10.1.2.27.
c) Click Save.
Step 3 Configure static NAT for the load balancer.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 4 Click Save on the NAT rule page.
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
The following static NAT-with-port-translation example provides a single address for remote users to access
FTP, HTTP, and SMTP. These servers are actually different devices on the real network, but for each server,
you can specify static NAT-with-port-translation rules that use the same mapped IP address, but different
ports.
Procedure
d) Click Save.
Step 2 Create a network object for the HTTP server.
a) Click Add Network > Add Object.
b) Name the network object (for example, HTTPserver), enter the host address 10.1.2.28.
c) Click Save.
Step 3 Create a network object for the SMTP server.
a) Click Add Network > Add Object.
b) Name the network object (for example, SMTPserver), enter the host address 10.1.2.29.
c) Click Save.
Step 4 Create a network object for the public IP address used for the three servers.
a) Click Add Network > Add Object.
b) Name the network object (for example, ServerPublicIP) and enter the host address 209.165.201.3.
c) Click Save.
Step 5 Configure static NAT with port translation for the FTP server, mapping the FTP port to itself.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) Click Save.
Step 6 Configure static NAT with port translation for the HTTP server, mapping the HTTP port to itself.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 7 Configure static NAT with port translation for the SMTP server, mapping the SMTP port to itself.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) Click Save.
Step 8 Click Save on the NAT rule page.
The following figure shows a host on the 10.1.2.0/24 network accessing two different servers. When the host
accesses the server at 209.165.201.11, the real address is translated to 209.165.202.129:port. When the host
accesses the server at 209.165.200.225, the real address is translated to 209.165.202.130:port.
Procedure
d) Click Save.
Step 2 Create a network object for the DMZ network 1.
a) Click Add Network > Add Object.
b) Name the network object (for example, DMZnetwork1) and enter the network address 209.165.201.0/27
(subnet mask of 255.255.255.224).
c) Click Save.
Step 3 Create a network object for the PAT address for DMZ network 1.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.
c) Click Save.
Step 4 Create a network object for the DMZ network 2.
c) Click Save.
Step 5 Create a network object for the PAT address for DMZ network 2.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.
c) Click Save.
Step 6 Configure dynamic manual PAT for DMZ network 1.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 7 Configure dynamic manual PAT for DMZ network 2.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
e) Click Save.
Step 8 Click Save on the NAT rule page.
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Access Admin
Defense Administrator
Network Admin
The following figure shows the use of source and destination ports. The host on the 10.1.2.0/24 network
accesses a single host for both web services and Telnet services. When the host accesses the server for Telnet
services, the real address is translated to 209.165.202.129:port. When the host accesses the same server for
web services, the real address is translated to 209.165.202.130:port.
Procedure
d) Click Save.
Step 2 Create a network object for the Telnet/Web server.
a) Click Add Network > Add Object.
b) Name the network object (for example, TelnetWebServer) and enter the host address 209.165.201.11.
c) Click Save.
Step 3 Create a network object for the PAT address when using Telnet.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.
c) Click Save.
Step 4 Create a network object for the PAT address when using HTTP.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.
c) Click Save.
Step 5 Configure dynamic manual PAT for Telnet access.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
f) Click Save.
Step 6 Configure dynamic manual PAT for web access.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
e) Click Save.
Step 7 Click Save on the NAT rule page.
The following figure shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that
you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public
IP address provided by NAT to access the Internet. The below example uses interface PAT rules. However,
for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San
Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule.
Identity NAT simply translates an address to the same address.
Figure 40: Interface PAT and Identity NAT for Site-to-Site VPN
Procedure
d) Click Save.
e) Click Add Network > Add Object and define the inside San Jose network.
Name the network object (for example, sanjose-network) and enter the network address 10.2.2.0/24.
f) Click Save.
Step 2 Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1
(Boulder).
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Static.
Note Because you do not want to translate the destination address, you need to configure identity
NAT for it by specifying the same address for the original and translated destination
addresses. Leave all of the port fields blank. This rule configures identity NAT for both
source and destination.
g) Click Save.
Step 3 Configure manual dynamic interface PAT when going to the Internet for the inside Boulder network on
Firewall1 (Boulder).
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
• Insert Rule = any position after the first rule. Because this rule will apply to any destination address,
the rule that uses sanjose-network as the destination must come before this rule, or the sanjose-network
rule will never be matched. The default is to place new manual NAT rules at the end of the "NAT
Rules Before Auto NAT" section.
e) Click Save.
Step 4 If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.
• The manual identity NAT rule would be for sanjose-network when the destination is boulder-network.
Create new interface objects for the Firewall2 inside and outside networks.
• The manual dynamic interface PAT rule would be for sanjose-network when the destination is "any."
• If you configure a manual NAT rule, you cannot configure DNS modification if you specify the destination
address as well as the source address. These kinds of rules can potentially have a different translation
for a single address when going to A vs. B. Therefore, the Firepower Threat Defense device cannot
accurately match the IP address inside the DNS reply to the correct twice NAT rule; the DNS reply does
not contain information about which source/destination address combination was in the packet that
prompted the DNS request.
• You must enable DNS application inspection with DNS NAT rewrite enabled for NAT rules to rewrite
DNS queries and responses. By default, DNS inspection with DNS NAT rewrite enabled is globally
applied, so you probably do not need to change the inspection configuration.
• DNS rewrite is actually done on the xlate entry, not the NAT rule. Thus, if there is no xlate for a dynamic
rule, rewrite cannot be done correctly. The same problem does not occur for static NAT.
• DNS rewrite does not rewrite DNS Dynamic Update messages (opcode 5).
The following figure shows an FTP server and DNS server on the outside IPv4 network. The system has a
static translation for the outside server. In this case, when an inside IPv6 user requests the address for
ftp.cisco.com from the DNS server, the DNS server responds with the real address, 209.165.200.225.
Because you want inside users to use the mapped address for ftp.cisco.com (2001:DB8::D1A5:C8E1, where
D1A5:C8E1 is the IPv6 equivalent of 209.165.200.225) you need to configure DNS reply modification for
the static translation. This example also includes a static NAT translation for the DNS server, and a PAT rule
for the inside IPv6 hosts.
Procedure
Step 1 Create the network objects for the FTP server, DNS server, inside network, and PAT pool.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the real FTP server address.
Name the network object (for example, ftp_server) and enter the host address, 209.165.200.225.
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated IPv6 address.
Name the network object (for example, ftp_server_v6) and enter the host address, 2001:DB8::D1A5:C8E1.
f) Click Save.
g) Click Add Network > Add Object and define the DNS server's real address.
Name the network object (for example, dns_server) and enter the host address, 209.165.201.15.
h) Click Save.
i) Click Add Network > Add Object and define the DNS server's translated IPv6 address.
Name the network object (for example, dns_server_v6) and enter the host address, 2001:DB8::D1A5:C90F
(where D1A5:C90F is the IPv6 equivalent of 209.165.201.15).
j) Click Save.
k) Click Add Network > Add Object and define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:DB8::/96.
l) Click Save.
m) Click Add Network > Add Object and define the IPv4 PAT pool for the inside IPv6 network.
Name the network object (for example, ipv4_pool) and enter the range 209.165.200.230-209.165.200.235.
n) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
g) Click OK.
Step 3 Configure the static NAT rule for the DNS server.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
e) On the Advanced tab, select Net to Net Mapping, because this is a one-to-one NAT46 translation.
f) Click OK.
Step 4 Configure the dynamic NAT with a PAT pool rule for the inside IPv6 network.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.
f) Click OK.
The following figure shows a DNS server that is accessible from the outside interface. A server, ftp.cisco.com,
is on the inside interface. You configure NAT to statically translate the ftp.cisco.com real address (10.1.3.14)
to a mapped address (209.165.201.10) that is visible on the outside network.
In this case, you want to enable DNS reply modification on this static rule so that inside users who have access
to ftp.cisco.com using the real address receive the real address from the DNS server, and not the mapped
address.
When an inside host sends a DNS request for the address of ftp.cisco.com, the DNS server replies with the
mapped address (209.165.201.10). The system refers to the static rule for the inside server and translates the
address inside the DNS reply to 10.1.3.14. If you do not enable DNS reply modification, then the inside host
attempts to send traffic to 209.165.201.10 instead of accessing ftp.cisco.com directly.
Procedure
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_outside) and enter the host address, 209.165.201.10.
f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) On the Advanced tab, select Translate DNS replies that match this rule.
g) Click OK.
The following figure shows an FTP server and DNS server on the outside. The system has a static translation
for the outside server. In this case, when an inside user requests the address for ftp.cisco.com from the DNS
server, the DNS server responds with the real address, 209.165.20.10. Because you want inside users to use
the mapped address for ftp.cisco.com (10.1.2.56) you need to configure DNS reply modification for the static
translation.
Procedure
d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_translated) and enter the host address, 10.1.2.56.
f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a Firepower Threat Defense NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.
f) On the Advanced tab, select Translate DNS replies that match this rule.
g) Click OK.
Virtual Switches
You can configure a 7000 or 8000 Series device in a Layer 2 deployment so that it provides packet switching
between two or more networks. In a Layer 2 deployment, you can configure virtual switches to operate as
standalone broadcast domains, dividing your network into logical segments. A virtual switch uses the media
access control (MAC) address from a host to determine where to send packets.
When you configure a virtual switch, the switch initially broadcasts packets through every available port on
the switch. Over time, the switch uses tagged return traffic to learn which hosts reside on the networks
connected to each port.
A virtual switch must contain two or more switched interfaces to handle traffic. For each virtual switch, traffic
becomes limited to the set of ports configured as switched interfaces. For example, if you configure a virtual
switch with four switched interfaces, packets sent in through one port for broadcast can only be sent out of
the remaining three ports on the switch.
When you configure a physical switched interface, you must assign it to a virtual switch. You can also define
additional logical switched interfaces on a physical port as needed. You can group multiple physical interfaces
into a single logical switched interface called a link aggregation group (LAG). This single aggregate logical
link provides higher bandwidth, redundancy, and load-balancing between two endpoints.
Caution If a Layer 2 deployment fails for any reason, the device no longer passes traffic.
For each physical switched interface, you can add multiple logical switched interfaces. You must associate
each logical interface with a VLAN tag to handle traffic received by the physical interface with that specific
tag. You must assign a logical switched interface to a virtual switch to handle traffic.
When configuring a switched interface, the range within which you can set the MTU can vary depending on
the Firepower System device model and interface type.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
To edit an existing logical switched interface, click the edit icon ( ) next to the interface.
When you delete a logical switched interface, you remove it from the physical interface where it resides, as
well as the virtual switch and security zone it is associated with.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Step 3 Next to the interface you want to configure as a switched interface, click the edit icon ( ).
Step 4 Click the Switched tab.
Step 5 If you want to associate the switched interface with a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 6 If you want to associate the switched interface with a virtual switch, do one of the following:
• Choose an existing virtual switch from the Virtual Switch drop-down list.
• Choose New to add a new virtual switch; see Adding Virtual Switches, on page 1137.
Step 7 Check the Enabled check box to allow the switched interface to handle traffic.
Note If you clear the check box, the interface becomes disabled so that users cannot access it for security
purposes.
Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.
Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.
Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 11 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Step 7 If you want to associate the switched interface with a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 8 If you want to associate the switched interface with a virtual switch, do one of the following:
• Choose an existing virtual switch from the Virtual Switch drop-down list.
• Choose New to add a new virtual switch; see Adding Virtual Switches, on page 1137.
Step 9 Check the Enabled check box to allow the switched interface to handle traffic.
If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a
physical interface, you also disable all of the logical interfaces associated with it.
Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 11 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Step 3 Next to the logical switched interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Field Description
Name The name of the virtual switch.
Interfaces All switched interfaces that are assigned to the virtual switch. Interfaces that you have
disabled from the Interfaces tab are not available.
Hybrid Interface The optionally configured hybrid interface that ties the virtual switch to a virtual
router.
Unicast Packets Unicast packet statistics for the virtual switch, including:
• Unicast packets received
• Unicast packets forwarded (excludes drops by host)
• Unicast packets unintentionally dropped
Broadcast Packets Broadcast packet statistics for the virtual switch, including:
• Broadcast packets received
• Broadcast packets forwarded
• Broadcast packets unintentionally dropped
You can also add switches as you configure switched interfaces. You can assign only switched interfaces to
a virtual switch. If you want to create a virtual switch before you configure the switched interfaces on your
managed devices, you can create an empty virtual switch and add interfaces to it later.
Tip
To edit an existing virtual switch, click the edit icon ( ) next to the switch.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Logical Hybrid Interfaces, on page 1189
Enabling Spanning Tree Protocol (STP) and Dropping Bridge Protocol Data Units (BPDU)
STP is a network protocol used to prevent network loops. BPDUs are exchanged through the network, carrying
information about network bridges. The protocol uses BPDUs to identify and select the fastest network links,
if there are redundant links in the network. If a network link fails, Spanning Tree fails over to an existing
alternate link.
Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy
in a 7000 or 8000 Series device high-availability pair. Only enable STP if your virtual switch switches
traffic between multiple network interfaces.
If your virtual switch routes traffic between VLANs, similar to a router on a stick, BPDUs enter and exit the
device through different logical switched interfaces, but the same physical switched interface. As a result,
STP identifies the device as a redundant network loop, which can cause issues in certain Layer 2 deployments.
To prevent this, you can configure the virtual switch at the domain level to have the device drop BPDUs when
monitoring traffic. You can only drop BPDUs if you disable STP.
Note Drop BPDUs only if your virtual swtich routes traffic between VLANs on a single physical interface.
Note that if you associate the virtual switch with a logical hybrid interface, the switch uses the same strict
TCP enforcement setting as the virtual router associated with the logical hybrid interface. You cannot specify
strict TCP enforcement on the switch in this case.
Procedure
Step 12 If you want to drop BPDUs at the domain level, check the Drop BPDUs check box.
Step 13 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you delete a virtual switch, any switched interfaces assigned to the switch become available for inclusion
in another switch.
Procedure
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Virtual Routers
You can configure a managed device in a Layer 3 deployment so that it routes traffic between two or more
interfaces. To route traffic, you must assign an IP address to each interface and assign the interfaces to the
virtual router. The interfaces assigned to virtual routers can be physical, logical, or link aggregation group
(LAG) interfaces.
You can configure the system to route packets by making packet forwarding decisions according to the
destination address. Interfaces configured as routed interfaces receive and forward the Layer 3 traffic. Routers
obtain the destination from the outgoing interface based on the forwarding criteria, and access control rules
designate the security policies to be applied.
In Layer 3 deployments, you can define static routes. In addition, you can configure Routing Information
Protocol (RIP) and Open Shortest Path First (OSPF) dynamic routing protocols. You can also configure a
combination of static routes and RIP or static routes and OSPF.
Note that you can only configure virtual routers, physical routed interfaces, or logical routed interfaces on a
7000 or 8000 Series device.
Caution If a Layer 3 deployment fails for any reason, the device no longer passes traffic.
Related Topics
LAG Configuration, on page 1176
Routed Interfaces
You can set up routed interfaces with either physical or logical configurations. You can configure physical
routed interfaces for handling untagged VLAN traffic. You can also create logical routed interfaces for handling
traffic with designated VLAN tags.
In a Layer 3 deployment, the system drops any traffic received on an external physical interface that does not
have a routed interface waiting for it. The system drops a packet if:
• It receives a packet with no VLAN tag, and you have not configured a physical routed interface for that
port.
• It receives a VLAN-tagged packet, and you have not configured a logical routed interface for that port.
The system handles traffic that has been received with VLAN tags on switched interfaces by stripping the
outermost VLAN tag on ingress prior to any rules evaluation or forwarding decisions. Packets leaving the
device through a VLAN-tagged logical routed interface are encapsulated with the associated VLAN tag on
egress. The system drops any traffic received with a VLAN tag after the stripping process completes.
You can add static Address Resolution Protocol (ARP) entries to a routed interface. If an external host needs
to know the MAC address of the destination IP address it needs to send traffic to on your local network, it
sends an ARP request. When you configure static ARP entries, the virtual router responds with an IP address
and associated MAC address.
Note that disabling the ICMP Enable Responses option for logical routed interfaces does not prevent ICMP
responses in all scenarios. You can add network-based rules to an access control policy to drop packets where
the destination IP is the routed interface’s IP and the protocol is ICMP.
If you have enabled the Inspect Local Router Traffic option on the managed device, the system drops the
packets before they reach the host, thereby preventing any response.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
If you change the parent physical interface to inline or passive, the system deletes all the associated logical
interfaces.
Related Topics
Advanced Device Settings, on page 478
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
You can configure one or more physical ports on a managed device as routed interfaces. You must assign a
physical routed interface to a virtual router before it can route traffic.
Caution Adding a routed interface pair on a 7000 or 8000 Series device restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 3 Next to the interface you want to modify, click the edit icon ( ).
Step 4 Click Routed to display the routed interface options.
Step 5 If you want to apply a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 7 Check the Enabled check box to allow the routed interface to handle traffic. If you clear the check box, the
interface becomes disabled so that users cannot access it for security purposes.
Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.
Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX
to attain link.
MDI/MDIX settings are available only for copper interfaces.
Step 10 In the MTU field, choose a maximum transmission unit (MTU), which designates the largest size packet
allowed.
The MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 11 Next to ICMP, check the Enable Responses check box to allow the interface to respond to ICMP traffic such
as pings and traceroute.
Step 12 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements.
Step 13 To add an IP address, click Add.
Step 14 In the Address field, enter the routed interface’s IP address and subnet mask using CIDR notation.
Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.
Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the interface automatically,
check the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
For SFRP options, see Configuring SFRP, on page 1148 for more information.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
For each physical routed interface, you can add multiple logical routed interfaces. You must associate each
logical interface with a VLAN tag to handle traffic received by the physical interface with that specific tag.
You must assign a logical routed interface to a virtual router to route traffic.
Caution Adding a routed interface pair on 7000 or 8000 Series devices restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 9 Check the Enabled check box to allow the routed interface to handle traffic.
If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a
physical interface, you also disable all of the logical interfaces associated with it.
Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 11 Next to ICMP, check the Enable Responses check box to communicate updates or error information to other
routers, intermediary devices, or hosts.
Step 12 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements.
Step 13 To add an IP address, click Add.
Step 14 In the Address field, enter the IP address in CIDR notation.
Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.
Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the interface automatically,
choose the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
For SFRP options, see Configuring SFRP, on page 1148 for more information.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
When you delete a logical routed interface, you remove it from the physical interface where it resides, as well
as its assigned virtual router and security zone.
Procedure
Step 3 Next to the logical routed interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
SFRP
You can configure Cisco Redundancy Protocol (SFRP) to achieve network redundancy for high availability
on either a 7000 or 8000 Series device high-availability pair or individual devices. SFRP provides gateway
redundancy for both IPv4 and IPv6 addresses. You can configure SFRP on routed and hybrid interfaces.
If the interfaces are configured on individual devices, they must be in the same broadcast domain. You must
designate at least one of the interfaces as master and an equal number as backup. The system supports only
one master and one backup per IP address. If network connectivity is lost, the system automatically promotes
the backup to master to maintain connectivity.
The options you set for SFRP must be the same on all interfaces in a group of SFRP interfaces. Multiple IP
addresses in a group must be in the same master/backup state. Therefore, when you add or edit an IP address,
the state you set for that address propagates to all the addresses in the group. For security purposes, you must
enter values for Group ID and Shared Secret that are shared among the interfaces in the group.
To enable SFRP IP addresses on a virtual router, you must also configure at least one non-SFRP IP address.
For 7000 or 8000 Series devices in a high-availability pair, you designate the shared secret and the system
copies it to the high-availability pair peer along with the SFRP IP configuration. The shared secret authenticates
peer data.
Related Topics
About 7000 and 8000 Series Device High Availability, on page 521
Configuring SFRP
Smart License Classic License Supported Devices Supported Domains Access
Any Control 7000 & 8000 Series Leaf only Admin/Network
Admin
You can configure Cisco Redundancy Protocol (SFRP) to achieve network redundancy for high availability
on either a 7000 or 8000 Series device high-availability pair or individual devices. SFRP provides gateway
redundancy for both IPv4 and IPv6 addresses. You can configure SFRP on routed and hybrid interfaces.
Note Cisco does not recommend enabling more than one non-SFRP IP address on a 7000 or 8000 Series device
high-availability pair's routed or hybrid interface where one SFRP IP address is already configured. The
system does not perform NAT if a 7000 or 8000 Series device high-availability pair fails over while in
standby mode.
Procedure
Step 3 Next to the interface where you want to configure SFRP, click the edit icon ( ).
Step 4 Choose the type of interface where you want to configure SFRP, either Routed or Hybrid.
Step 5 You can configure SFRP while adding or editing an IP address. Click Add to add an IP address. To edit an
IP address, click the edit icon ( ).
Step 6 For Type, choose SFRP to display the SFRP options.
Step 7 In the Group ID field, enter a value that designates a group of master or backup interfaces configured for
SFRP.
Step 8 For Priority, choose either Master or Backup to designate the preferred interface:
• For individual devices, you must set one interface to master on one device and the other to backup on
a second device.
• For 7000 or 8000 Seriesdevice high-availability pairs, when you set one interface as master, the other
automatically becomes the backup.
Step 10 In the Adv. Interval (seconds) field, enter an interval for route advertisements for Layer 3 traffic.
Step 11 Click OK.
Step 12 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
About 7000 and 8000 Series Device High Availability, on page 521
Caution Adding a virtual router on a 7000 or 8000 Series device restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Before you can use routed interfaces in a Layer 3 deployment, you must configure virtual routers and assign
routed interfaces to them. A virtual router is a group of routed interfaces that route Layer 3 traffic.
You can assign only routed and hybrid interfaces to a virtual router.
To maximize TCP security, you can enable strict enforcement, which blocks connections where the three-way
handshake was not completed. Strict enforcement also blocks:
• non-SYN TCP packets for connections where the three-way handshake was not completed
• non-SYN/RST packets from the initiator on a TCP connection before the responder sends the SYN-ACK
• non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before the
session is established
• SYN packets on an established TCP connection from either the initiator or the responder
Note that if you change the configuration of a Layer 3 interface to a non-Layer 3 interface or remove a Layer
3 interface from the virtual router, the router may fall into an invalid state. For example, if it is used in DHCPv6,
it may cause an upstream and downstream mismatch.
You can add virtual routers from the Virtual Routers tab of the device management page. You can also add
routers as you configure routed interfaces.
If you want to create a virtual router before you configure the interfaces on your managed devices, you can
create an empty virtual router and add interfaces to it later.
Caution Adding a virtual router on a 7000 or 8000 Series device restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
DHCP Relay
DHCP provides configuration parameters to Internet hosts. A DHCP client that has not yet acquired an IP
address cannot communicate directly with a DHCP server outside its broadcast domain. To allow DHCP
clients to communicate with DHCP servers, you can configure DHCP relay instances to handle cases where
the client is not on the same broadcast domain as the server.
You can set up DHCP relay for each virtual router you configure. By default, this feature is disabled. You
can enable either DHCPv4 relay or DHCPv6 relay.
Note You cannot run a DHCPv6 Relay chain through two or more virtual routers running on the same device.
The following procedure explains how to set up DHCPv4 relay on a virtual router.
Procedure
Step 8 In the Max Hops field, enter the maximum number of hops from 1 to 255.
Step 9 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You cannot run a DHCPv6 Relay chain through two or more virtual routers running on the same device.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Static Routes
Static routing allows you to write rules about the IP addresses of traffic passing through a router. It is the
simplest way of configuring path selection of a virtual router because there is no communication with other
routers regarding the current topology of the network.
The Static Routes table includes summary information about each route, as described in the following table.
Field Description
Enabled Specifies whether this route is currently enabled or disabled.
Field Description
Type Specifies the action that is taken for this route, which will is one of the following:
• IP — designates that the route forwards packets to the address of a neighboring router.
• Interface — designates that the route forwards packets to an interface through which
traffic is routed to hosts on a directly connected network.
• Discard — designates that the static route drops packets.
Gateway The target IP address if you selected IP as the static route type or the interface if you selected
Interface as the static route type.
Preference Determines the route selection. If you have multiple routes to the same destination, the
system selects the route with the higher preference.
Procedure
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Dynamic Routing
Dynamic, or adaptive, routing uses a routing protocol to alter the path that a route takes in response to a change
in network conditions. The adaptation is intended to allow as many routes as possible to remain valid, that is,
have destinations that can be reached in response to the change. This allows the network to “route around”
damage, such as loss of a node or a connection between nodes, so long as other path choices are available.
You can configure a router with no dynamic routing, or you can configure the Routing Information Protocol
(RIP) or the Open Shortest Path First (OSPF) routing protocol.
RIP Configuration
Routing Information Protocol (RIP) is a dynamic routing protocol, designed for small IP networks, that relies
on hop count to determine routes. The best routes use the fewest number of hops. The maximum number of
hops allowed for RIP is 15. This hop limit also limits the size of the network that RIP can support.
While configuring RIP, you must choose interfaces from those already included in the virtual router, where
you want to configure RIP. Disabled interfaces are not available.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
RIP authentication uses one of the authentication profiles you configured on the virtual router.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can configure several advanced RIP settings pertaining to various timeout values and other features that
affect the behavior of the protocol.
Caution Changing any of the advanced RIP settings to incorrect values can prevent the router from communicating
successfully with other RIP routers.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add an import filter to designate which routes are accepted or rejected from RIP into the route table.
Import filters are applied in the order they appear in the table.
When adding an import filter, you use one of the filters you configured on the virtual router.
Tip
To edit a RIP import filter, click the edit icon ( ). To delete a RIP import filter, click the delete icon
( ).
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add an export filter to define which routes will be accepted or rejected from the route table to RIP.
Export filters are applied in the order they appear in the table.
When adding an export filter, you use one of the filters you configured on the virtual router.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
OSPF Configuration
Open Shortest Path First (OSPF) is an adaptive routing protocol that defines routes dynamically by obtaining
information from other routers and advertising routes to other routers using link state advertisements. The
router keeps information about the links between it and the destination to make routing decisions. OSPF
assigns a cost to each routed interface, and considers the best routes to have the lowest costs.
Procedure
Step 14 Choose the Summary check box to designate that default stubnets that are subnetworks of this stubnet are
suppressed.
Step 15 In the Stub cost field, enter a value that defines the cost associated with routing to this stub network.
Step 16 Click OK.
Step 17 If you want to add a network, click the add icon ( ) under Networks.
Step 18 In the IP Address field, enter an IP address in CIDR notation for the network.
Step 19 Check the Hidden check box to indicate that the network is hidden. Hidden networks are not propagated into
other areas.
Step 20 Click OK.
Step 21 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Interfaces
Select the interface where you want to configure OSPF. Interfaces you have disabled from the Interfaces tab
are not available.
Type
Select the type of OSPF interface from the following choices:
• Broadcast — On broadcast networks, flooding and hello messages are sent using multicasts, a single
packet for all the neighbors. The option designates a router to be responsible for synchronizing the link
state databases and originating network link state advertisements. This network type cannot be used on
physically non-broadcast multiple-access (NBMP) networks and on unnumbered networks without
proper IP prefixes.
• Point-to-Point (PtP) — Point-to-point networks connect just two routers together. No election is performed
and no network link state advertisement is originated, which makes it simpler and faster to establish.
This network type is useful not only for physically PtP interfaces, but also for broadcast networks used
as PtP links. This network type cannot be used on physically NBMP networks.
• Non-Broadcast — On NBMP networks, the packets are sent to each neighbor separately because of the
lack of multicast capabilities. Similar to broadcast networks, the option designates a router, which plays
a central role in the propagation of link state advertisements. This network type cannot be used on
unnumbered networks.
• Autodetect — The system determines the correct type based on the specified interface.
Cost
Specify the output cost of the interface.
Stub
Specify whether the interface should listen for OSPF traffic and transmit its own traffic.
Priority
Enter a numerical value that specifies the priority value used in designated router election. On every multiple
access network, the system designates a router and backup router. These routers have some special functions
in the flooding process. Higher priority increases preferences in this election. You cannot configure a router
with a priority of 0.
Nonbroadcast
Specify whether hello packets are sent to any undefined neighbors. This switch is ignored on any NBMA
network.
Authentication
Select the OSPF authentication profile that this interface uses from one of the authentication profiles you
configured on the virtual router or select None. For more information about configuring authentication profiles,
see Adding Virtual Router Authentication Profiles, on page 1171.
Hello Interval
Type the interval, in seconds, between the sending of hello messages.
Poll
Type the interval, in seconds, between the sending of hello messages for some neighbors on NBMA networks.
Retrans Interval
Type the interval, in seconds, between retransmissions of unacknowledged updates.
Retrans Delay
Type the estimated number of seconds it takes to transmit a link state update packet over the interface.
Wait Time
Type the number of seconds that the router waits between starting election and building adjacency.
Dead Interval
Type the number of seconds that the router waits before declaring a neighbor down when not receiving
messages from it. If this value is defined, it overrides the value calculated from dead count.
Dead Count
Type a numerical value that when multiplied by the hello interval specifies the number of seconds that the
router waits before declaring a neighbor down when not receiving messages from it.
To edit an OSPF area interface, click the edit icon ( ). To delete an OSPF area interface, click the delete
icon ( ). Disabling a configured interface from the Interfaces tab also deletes it.
You can configure a subset of the interfaces assigned to the virtual router for OSPF.
You can choose only one interface for use in an OSPF area.
Procedure
Step 12 In the IP address field, enter an IP address for the neighbor receiving hello messages on non-broadcast
networks from this interface.
Step 13 Check the Eligible check box to indicate that the neighbor is eligible to receive messages.
Step 14 Click OK.
Tip
To edit a neighbor, click the edit icon ( ). To delete a neighbor, click the delete icon
( ).
Step 15 Click OK.
Step 16 Click Save.
Step 17 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
All areas in an OSPF autonomous system must be physically connected to the backbone area. In some cases
where this physical connection is not possible, you can use a vlink to connect to the backbone through a
non-backbone area. Vlinks can also be used to connect two parts of a partitioned backbone through a
non-backbone area.
You must add a minimum of two OSPF areas before you can add a vlink.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add an import filter to define which routes are accepted or rejected from OSPF into the route table.
Import filters are applied in the order they appear in the table.
When adding an import filter, you use one of the filters you configured on the virtual router.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add an export filter to define which routes will be accepted or rejected from the route table to OSPF.
Export filters are applied in the order they appear in the table.
When adding an export filter, you use one of the filters you configured on the virtual router.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Field Description
Name The name of the filter.
From Router The router IP addresses that this filter attempts to match in a router. You must enter
this value for static and RIP filters.
Next Hop The next hop where packets using this route are forwarded. You must enter this value
for static and RIP filters.
Field Description
Destination Type The type of destination where packets are sent:
• Router
• Device
• Discard
OSPF Path Type Applies only to OSPF protocol. The path type can be one of the following:
• Ext-1
• Ext-2
• Inter Area
• Intra Area
OSPF Router ID Applies only to OSPF protocol. The router ID of the router advertising that
route/network.
The Filter tab of the virtual router editor displays a table listing of all the filters you have configured on a
virtual router. The table includes summary information about each filter.
Procedure
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can set up Authentication Profiles for use in RIP and OSPF configurations. You can configure a simple
password or specify a shared cryptographic key. Simple passwords allow for every packet to carry eight bytes
of the password. The system ignores received packets lacking this password. Cryptographic keys allow for
validation, a 16-byte long digest generated from a password to be appended to every packet.
Note that for OSPF, each area can have a different authentication method. Therefore, you create authentication
profiles that can be shared among many areas. You cannot add authentication for OSPFv3.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can view runtime statistics for each virtual router. The statistics display unicast packets, packets dropped,
and separate routing tables for IPv4 and IPv6 addresses.
Procedure
When you delete a virtual router, any routed interfaces assigned to the router become available for inclusion
in another router.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
The endpoints in a LAG can be two 7000 or 8000 Series devices, as shown in the illustration above, or a 7000
or 8000 Series device connected to a third-party access switch or router. The two devices do not have to match,
but they must have the same physical configuration and they must support the IEEE 802.ad link aggregation
standard. A typical deployment for a LAG might be to aggregate access links between two managed devices,
or to create a point-to-point connection between a managed device and an access switch or a router.
Note that you cannot configure aggregate interfaces on NGIPSv devices or ASA FirePOWER modules.
LAG Configuration
There are two types of aggregate interfaces:
• switched — Layer 2 aggregate interfaces
• routed — Layer 3 aggregate interfaces
You implement link aggregation through the use of link aggregation groups (LAGs). You configure a LAG
by creating an aggregate switched or routed interface and then associating a set of physical interfaces with
the link. All of the physical interfaces must be of the same speed and medium.
You create aggregate links either dynamically or statically. Dynamic link aggregation uses Link Aggregation
Control Protocol (LACP), a component of the IEEE 802.ad link aggregation standard, while static link
aggregation does not. LACP enables each device on either end of the LAG to exchange link and system
information to determine which links will be actively used in the aggregation. A static LAG configuration
requires you to manually maintain link aggregations and deploy load-balancing and link selection policies.
When you create a switched or routed aggregate interface, a link aggregation group of the same type is created
and numbered automatically. For example, when you create your first LAG (switched or routed), the aggregate
interface can be identified by the lag0 label in the Interfaces tab for your managed device. When you associate
physical and logical interfaces with this LAG, they appear nested below the primary LAG in a hierarchical
tree menu. Note that a switched LAG can only contain switched physical interfaces, and a routed LAG can
only contain routed physical interfaces.
Consider the following requirements when you configure a LAG:
• The Firepower System supports a maximum of 14 LAGs, and assigns a unique ID to each LAG interface
in the range of 0 to 13. The LAG ID is not configurable.
• You must configure the LAG on both sides of the link, and you must set the interfaces on either side of
the link to the same speed.
• You must associate at least two physical interfaces per LAG, up to a maximum of eight. A physical
interface cannot belong to more than one LAG.
• Physical interfaces in a LAG cannot be used in any other mode of operation, either as inline or passive,
or be used as part of another logical interface for tagged traffic.
• Physical interfaces in a LAG can span multiple NetMods, but cannot span multiple sensors (i.e. all
physical interfaces must reside on the same device).
• A LAG cannot contain a stacking NetMod.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Note When you create a LAG interface you also create an “untagged” logical interface by default, which is
identified by the lagn.0 label, where n is an integer from 0 to 13. To be operational, each LAG requires
this one logical interface at a minimum. You can associate additional logical interfaces with any LAG to
handle VLAN-tagged traffic. Each additional logical interface requires a unique VLAN tag. The Firepower
System supports VLAN tags in the range of 1 through 4094.
You can also configure the Cisco Redundancy Protocol (SFRP) on a logical routed interface. SFRP allows
devices to act as redundant gateways for specified IP addresses.
Note that disabling the ICMP Enable Responses option for logical routed interfaces does not prevent ICMP
responses in all scenarios. You can add network-based rules to an access control policy to drop packets where
the destination IP is the routed interface’s IP and the protocol is ICMP.
If you have enabled the Inspect Local Router Traffic option, which is an advanced setting on the managed
device, it drops the packets before they reach the host, thereby preventing any response.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Related Topics
SFRP, on page 1148
Advanced Device Settings, on page 478
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Load-Balancing Algorithms
You assign an egress load-balancing algorithm to the LAG that determines how to distribute traffic to the
LAG bundle’s member links. The load-balancing algorithm makes hashing decisions based on values in various
packet fields, such as Layer 2 MAC addresses, Layer 3 IP addresses, and Layer 4 port numbers (TCP/UDP
traffic). The load-balancing algorithm you select applies to all of the LAG bundle’s member links.
Choose the load-balancing algorithm that supports your deployment scenario from the following options when
you configure a LAG:
• Destination IP
• Destination MAC
• Destination Port
• Source IP
• Source MAC
• Source Port
Note You should configure both ends of the LAG to have the same load-balancing algorithm.
Higher layer algorithms will back off to lower layer algorithms as necessary (such as a
Layer 4 algorithm backing off to Layer 3 for ICMP traffic).
Note You should configure both ends of the LAG to have the same link selection policy.
Choose the link selection policy that supports your deployment scenario from the following options:
• Highest Port Count — Choose this option for the highest total active port count to provide added
redundancy.
• Highest Total Bandwidth — Choose this option to provide the highest total bandwidth for the aggregated
link.
• Stable — Choose this option if your primary concern is link stability and reliability. Once you configure
a LAG, the active links change only when absolutely necessary (such as link failure) rather than doing
so for added port count or bandwidth.
• LACP Priority — Choose this option to use the LACP algorithm to determine which links are active in
the LAG. This setting is appropriate if you have undefined deployment goals, or if the device at the other
end of the LAG is not managed by the Firepower Management Center.
LACP is a key aspect of automating the link selection method that supports dynamic link aggregation. When
LACP is enabled, a link selection policy based on LACP priority uses the following properties of LACP:
LACP system priority
You configure this value on each partnered device running LACP to determine which one is superior
in link aggregation. The system with the lower value has the higher system priority. In dynamic link
aggregation, the system with the higher LACP system priority sets the selected state of member links
on its side first, then the system with the lower priority sets its member links accordingly. You can
specify 0 to 65535. If you do not specify a value, the default priority is 32768.
LACP
When you enable LACP, you need to specify a transmission mode for each end of the LAG that determines
how LACP packets are exchanged between partnered devices. There are two options for LACP mode:
• Active — Choose this mode to place a device into an active negotiating state, in which the device initiates
negotiations with remote links by sending LACP packets.
• Passive — Choose this mode to place a device into a passive negotiating state, in which the device
responds to LACP packets it receives but does not initiate LACP negotiation.
Note Both modes allow LACP to negotiate between links to determine if they can form a link
bundle based on criteria such as port speed. However, you should avoid a passive-passive
configuration, which essentially places both ends of the LAG in listening mode.
LACP has a timer which defines how often LACP packets are sent between devices. LACP exchanges packets
at these rates:
• Slow — 30 seconds
• Fast — 1 second
The device where this option is applied expects to receive LACP packets with this frequency from the partner
device on the other side of the LAG.
Note When a LAG is configured on a managed device that is part of a device stack, only the primary device
participates in LACP communication with the partner system. All secondary devices forward LACP
messages to the primary device. The primary device relays any dynamic LAG modifications to the secondary
devices.
You can combine between two and eight physical ports on a managed device to create a switched LAG
interface. You must assign a switched LAG interface to a virtual switch before it can handle traffic. A managed
device can support up to 14 LAG interfaces.
Procedure
Step 3 Choose Add Aggregate Interface from the Add drop-down menu.
Step 4 Click Switched to display the switched LAG interface options.
Step 5 If you want to apply a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 7 Check the Enabled check box to allow the switched LAG interface to handle traffic.
If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.
Step 8 From the Mode, choose an option to designate the link mode, or choose Autonegotiation to specify that the
interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options. When links auto negotiate speed, all
active links are selected for the LAG based on the same speed setting.
Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.
Step 11 Under Link Aggregation, choose one or more physical interfaces from Available Interfaces to add to the
LAG bundle.
Tip To remove physical interfaces from the LAG bundle, choose one or more physical interfaces and click
the remove selected icon ( ). To remove all physical interfaces from the LAG bundle, click the
remove all icon ( ). Deleting the LAG interface from the Interfaces tab also removes the interfaces.
Step 12 Choose an option from the Load-Balancing Algorithm drop-down list.
Step 13 Choose a Link Selection Policy from the drop-down list.
Tip Choose LACP Priority if you are configuring an aggregate interface between a Firepower System
device and a third-party network device.
Step 14 If you chose LACP Priority as the Link Selection Policy, assign a value for System Priority and click the
Configure Interface Priority link to assign a priority value for each interface in the LAG.
Step 15 Choose either Inner or Outer from the Tunnel Level drop-down list.
Note The tunnel level only applies to IPv4 traffic when Layer 3 load balancing is configured. The outer
tunnel is always used for Layer 2 and IPv6 traffic. If the Tunnel Level is not explicitly set, the default
is Outer.
Step 16 Under LACP, check the Enabled check box to allow the switched LAG interface to handle traffic using the
Link Aggregation Control Protocol.
If you clear the check box, the LAG interface becomes a static configuration and the Firepower System will
use all of the physical interfaces selected for the aggregation.
Step 17 Click a Rate radio button to set the frequency that determines how often LACP control messages are received
from the partner device:
• Click Slow to receive packets every 30 seconds.
• Click Fast to receive packets every 1 second.
Step 18 Click a Mode radio button to establish the listening mode of the device:
• Click Active to initiate negotiations with remote links by sending LACP packets to the partner device.
• Click Passive to respond to LACP packets received.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
You can combine between two and eight physical ports on a managed device to create a routed LAG interface.
You must assign a routed LAG interface to a virtual router before it can route traffic. A managed device can
support up to 14 LAG interfaces.
Caution Adding a routed interface pair on 7000 or 8000 Series devices restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 3 Choose Add Aggregate Interface from the Add drop-down menu.
Step 4 Click Routed to display the routed LAG interface options.
Step 5 If you want to apply a security zone, do one of the following:
• Choose an existing security zone from the Security Zone drop-down list.
• Choose New to add a new security zone; see Creating Security Zone and Interface Group Objects, on
page 358.
Step 7 Check the Enabled check box to allow the routed LAG interface to handle traffic.
If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.
Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the LAG interface is configured to auto negotiate speed and duplex settings.
Step 9 Choose an option from the MDI/MDIX drop-down list to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.
Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the LAG interface automatically,
check the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
Step 17 If you chose SFRP for Type, set options as described in SFRP, on page 1148.
Step 18 Click OK.
Note When adding an IP address to a routed interface of a 7000 or 8000 Series device in a high-availability
pair, you must add a corresponding IP address to the routed interface on the high-availability peer.
Step 19 Click Add to add a static ARP entry.
Step 20 Enter an IP address the IP Address field.
Step 21 Enter a MAC address to associate with the IP address in the MAC Address field. Use the standard format
(for example, 01:23:45:67:89:AB).
Step 22 Click OK.
Step 23 Under Link Aggregation, choose one or more physical interfaces from Available Interfaces to add to the
LAG bundle.
Tip To remove physical interfaces from the LAG bundle, choose one or more physical interfaces and click
the remove selected icon ( ). To remove all physical interfaces from the LAG bundle, click the
remove all icon ( ). Deleting the LAG interface from the Interfaces tab also removes the interfaces.
Step 29 Click a Rate radio button to set the frequency that determines how often LACP control messages are received
from the partner device.
• Click Slow to receive packets every 30 seconds.
• Click Fast to receive packets every 1 second.
Step 30 Click a Mode radio button to establish the listening mode of the device.
• Click Active to initiate negotiations with remote links by sending LACP packets to the partner device.
• Click Passive to respond to LACP packets received.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Advanced Device Settings, on page 478
For each switched or routed aggregate interface, you can add multiple logical interfaces. You must associate
each logical LAG interface with a VLAN tag to handle traffic received by the LAG interface with that specific
tag. You add logical interfaces to switched or routed aggregate interfaces in the same way you would add
them to physical switched or routed interfaces.
Note When you create a LAG interface you also create an “untagged” logical interface by default, which is
identified by the lagn.0 label, where n is an integer from 0 to 13. To be operational, each LAG requires
this one logical interface at a minimum. You can associate additional logical interfaces with any LAG to
handle VLAN-tagged traffic. Each additional logical interface requires a unique VLAN tag. The Firepower
System supports VLAN tags in the range of 1 through 4094.
Caution Adding a routed interface pair on 7000 or 8000 Series devices restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 3 From the Add drop-down menu, choose Add Logical Interface.
Step 4 Click Switched to display the switched interface options, or click Routed to display the routed interface
options.
Step 5 Choose an available LAG from the Interface drop-down list. The aggregate interface is identified by the lagn
label, where n is an integer from 0 to 13.
Step 6 Configure the remaining settings appropriate to the interface type you chose:
• Switched — See Adding Logical Switched Interfaces, on page 1134 for more information on adding a
logical interface to a switched interface.
• Routed — See Adding Logical Routed Interfaces, on page 1145 for more information on adding a logical
interface to a routed interface.
Related Topics
SFRP, on page 1148
Advanced Device Settings, on page 478
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
You can view protocol and traffic statistics for each aggregate interface. The statistics show LACP protocol
information such as LACP key and partner information, packets received, packets transmitter, and packets
dropped. Statistics are further refined per member interface to show traffic and link information on a per-port
basis.
Aggregate interface information is also presented to the dashboard via predefined dashboard widgets. The
Current Interface Status widget shows the status of all interfaces on the appliance, enabled or unused. The
Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s interfaces
over the dashboard time range. See Predefined Dashboard Widgets, on page 204.
Procedure
Step 3 Next to the interface where you want to view the interface statistics, click the view icon ( ).
The aggregate interface can be identified by the lagn label, where n can be an integer from 0 to 13.
Procedure
Step 3 Next to the aggregate interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the aggregate interface.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 293 for more information.
Related Topics
Configuring SFRP, on page 1148
Advanced Device Settings, on page 478
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Caution Adding a routed interface pair on 7000 or 8000 Series devices restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 3 From the Add drop-down menu, choose Add Logical Interface.
Step 4 Click Hybrid to display the hybrid interface options.
Step 5 In the Name field, enter a name for the interface.
Step 6 From the Virtual Router drop-down list, choose an existing virtual router, choose None, or choose New to
add a new virtual router.
Note If you add a new virtual router, you must configure it on the Device Management page after you
finish setting up the hybrid interface. See Adding Virtual Routers, on page 1150.
Step 7 From the Virtual Switch drop-down list, choose an existing virtual switch, choose None, or choose New to
add a new virtual switch.
Note If you add a new virtual switch, you must configure it on the Device Management page after you
finish setting up the hybrid interface. See Adding Virtual Switches, on page 1137.
Step 8 Check the Enabled check box to allow the hybrid interface to handle traffic.
Note If you clear the check box, the interface becomes disabled and administratively taken
down.
Step 9 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 293
for more information.
Step 10 Next to ICMP, check the Enable Responses check box to allow the interface to respond to ICMP traffic such
as pings and traceroute.
Step 11 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements. You can only enable this option if you added IPv6 addresses.
Step 12 To add an IP address, click Add.
Step 13 In the Address field, enter the IP address and subnet mask. Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.
Step 14 Optionally if you have IPv6 addresses, next to the IPv6 field, check the Address Autoconfiguration check
box to set the IP address of the interface automatically.
Step 15 For Type, choose either Normal or SFRP.
Step 16 If you chose SFRP for Type, set options as described in SFRP, on page 1148.
Step 17 Click OK.
Step 18 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 504
Snort® Restart Scenarios , on page 292
Procedure
Step 3 Next to the logical hybrid interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
IPsec
The IPsec protocol suite defines how IP packets across a VPN tunnel are hashed, encrypted, and encapsulated
in the ESP or AH security protocol. The Firepower System uses the hash algorithm and encryption key of the
Security Association (SA), which becomes established between the two gateways by the Internet Key Exchange
(IKE) protocol.
Security associations (SA) establish shared security attributes between two devices and allow VPN endpoints
to support secure communication. An SA allows two VPN endpoints to handle the parameters for how the
VPN tunnel is secured between them.
The system uses the Internet Security Association and Key Management Protocol (ISAKMP) during the initial
phase of negotiating the IPsec connection to establish the VPN between endpoints and the authenticated key
exchange. The IKE protocol resides within ISAKMP.
The AH security protocol provides protection for packet headers and data, but it cannot encrypt them. ESP
provides encryption and protection for packets, but it cannot secure the outermost IP header. In many cases,
this protection is not required, and most VPN deployments use ESP more frequently than AH because of its
encryption capabilities. Since VPN only operates in tunnel mode, the system encrypts and authenticates the
entire packet from Layer 3 and up in the ESP protocol. ESP in tunnel mode encrypts the data as well as
providing the latter’s encryption capabilities.
IKE
The Firepower System uses the IKE protocol to mutually authenticate the two gateways against each other
as well as to negotiate the SA for the tunnel. The process consists of two phases.
IKE phase 1 establishes a secure authenticated communication channel by using the Diffie-Hellman key
exchange to generate a pre-shared key to encrypt further IKE communications. This negotiation results in a
bidirectional ISAKMP security association. The system allows you to perform the authentication using a
pre-shared key. Phase 1 operates in main mode, which seeks to protect all data during the negotiation, while
also protecting the identity of the peers.
During IKE phase 2, the IKE peers use the secure channel established in phase 1 to negotiate security
associations on behalf of IPsec. The negotiation results in a minimum of two unidirectional security associations,
one inbound and one outbound.
VPN Deployments
A VPN deployment specifies the endpoints and networks that are included in a VPN and how they connect
to each other. After you configure a VPN deployment on the Firepower Management Center, you can then
deploy it to your managed devices or devices managed by another Firepower Management Center.
The system supports three types of VPN deployments: point-to-point, star, and mesh.
Related Topics
Managing VPN Deployments, on page 1203
Only Cisco managed devices can be used as endpoints in VPN deployments. Third-party endpoints are not
supported.
You must define a pre-shared key for VPN authentication. You can specify a default key to use in all of the
VPN connections you generate in a deployment. For point-to-point deployments, you can specify a preshared
key for each endpoint pair.
In a multidomain deployment, you can configure a VPN deployment across domains; that is, you can assign
endpoints to devices that belong to different domains. In such cases, you can view but not modify the ancestor
deployment in the related descendant domains. When you drill down for deployment details, the system
displays information for devices that belong to the current domain only.
Type
Click PTP to specify that you are configuring a point-to-point deployment.
Pre-shared Key
Define a unique pre-shared key for authentication. The system uses this key for all the VPNs in your
deployment, unless you specify a pre-shared key for each endpoint pair.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an
endpoint for your deployment. For Cisco-managed devices not managed by the Firepower Management
Center you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
selected device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the virtual
router you specified.
IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the specified
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you choose a managed device not managed by the Firepower Management Center, specify an
IP address for the endpoint.
Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network. IKE version 1 only supports a single protected network.
Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint
pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4
or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not
overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128
CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.
Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint
is a responder, you must specify this value.
Pre-shared Key
If you cleared the Use Deployment Key check box, specify a pre-shared key in this field.
Related Topics
Configuring Point-to-Point VPN Deployments, on page 1204
Type
Click Star to specify that you are configuring a star deployment.
Pre-shared Key
Define a unique pre-shared key for authentication.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an
endpoint for your deployment. For Cisco-managed devices not managed by the Firepower Management
Center you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
selected device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the selected
virtual router.
IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the specified
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you chose a managed device not managed by the Firepower Management Center, specify an
IP address for the endpoint.
Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network.
Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint
pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4
or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not
overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128
CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.
Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint
is a responder, you must specify this value.
Related Topics
Configuring Star VPN Deployments, on page 1204
Type
Click Mesh to specify that you are configuring a mesh deployment.
Pre-shared Key
Define a unique pre-shared key for authentication.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an
endpoint for your deployment. For Cisco-managed devices not managed by the Firepower Management
Center you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
specified device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the
specified virtual router.
IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the selected
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you chose a managed device not managed by the Firepower Management Center, specify an
IP address for the endpoint.
Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network. IKE version 1 only supports a single protected network.
Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint
pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4
or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not
overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128
CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.
Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint
is a responder, you must specify this value.
Related Topics
Configuring Mesh VPN Deployments, on page 1205
Algorithm
Specify the phase one and phase two algorithm proposals to secure data in your deployment. Choose
Cipher, Hash, and Diffie-Hellman (DH) group authentication messages for both phases.
IKE v2
Check the check box to specify that the system uses IKE version 2. This version supports the star
deployment and multiple protected networks.
Life Time
Specify a numerical value and select a time unit for the maximum SA renegotiation interval. You can
specify a minimum of 5 minutes and a maximum of 24 hours.
Life Packets
Specify the number of packets that can be transmitted over an IPsec SA before it expires. You can use
any integer between 0 and 18446744073709551615.
Life Bytes
Specify the number of bytes that can be transmitted over an IPsec SA before it expires. You can use
any integer between 0 and 18446744073709551615.
AH
Check the check box to specify that the system uses the authentication header security protocol for the
data to be protected. Clear the check box to use encryption service payload (ESP) protocol.
Related Topics
Configuring Advanced VPN Deployment Settings, on page 1206
Caution Adding or removing a VPN on a 7000 or 8000 Series device restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this
interruption or passes without further inspection depends on the model of the managed device and how it
handles traffic. See Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
• Edit — To modify the settings in an existing VPN deployment, click the edit icon ( ); see Editing
VPN Deployments, on page 1207.
• Delete — To delete a VPN deployment, click the delete icon ( ).
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
• View VPN status — To view the status of an existing VPN deployment, click the status icon; see Viewing
VPN Status, on page 1208.
Related Topics
Snort® Restart Scenarios , on page 292
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 13 Repeat step 7 through step 10 to complete the leaf node, which has the same options as the hub node.
Step 14 Click Save.
The leaf node is added to your deployment.
Step 15 Click Save to finish configuring your deployment.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In a multidomain deployment, the system displays VPN deployments created in the current domain, which
you can edit. It also displays VPN deployments created in ancestor domains if one of the endpoint devices
belongs to your domain. You cannot edit VPN deployments created in ancestor domains. To view and edit
VPN deployments created in a lower domain, switch to that domain.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution Two users should not edit the same deployment simultaneously; however, note that the web interface
does not prevent simultaneous editing.
In a multidomain deployment, the system displays VPN deployments created in the current domain, which
you can edit. It also displays VPN deployments created in ancestor domains if one of the endpoint devices
belongs to your domain. You cannot edit VPN deployments created in ancestor domains. To view and edit
VPN deployments created in a lower domain, switch to that domain.
Procedure
Tip You cannot edit the deployment type after you initially save the deployment. To change the deployment
type, you must delete the deployment and create a new one.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can click a status icon to view the deployment status along with basic information about the endpoints
in the deployment, such as endpoint name and IP address. The VPN status updates every minute or when a
status change occurs, such as an endpoint going down or coming up.
Related Topics
Viewing VPN Status, on page 1208
In a multidomain deployment, the system displays VPN deployments created in the current domain. It also
displays VPN deployments created in ancestor domains if one of the endpoint devices belongs to your domain.
To view VPN deployments created in a lower domain, switch to that domain.
Procedure
Endpoint
The device path to the routed interface and IP address designated as the VPN endpoint.
Status
Whether the VPN connection is up or down.
Protocol
The protocol used for encryption, either ESP or AH.
Packets Received
The number of packets per interface the VPN tunnel receives during an IPsec SA negotiation.
Packets Forwarded
The number of packets per interface the VPN tunnel transmits during an IPsec SA negotiation.
Bytes Received
The number of bytes per interface the VPN tunnel receives during an IPsec SA negotiation.
Bytes Forwarded
The number of bytes per interface the VPN tunnel transmits during an IPsec SA negotiation.
Time Created
The date and time the VPN connection was created.
NAT Traversal
If "Yes" is displayed, at least one of the VPN endpoints resides behind a device with network address
translation.
IKE State
The state of the IKE SA: connecting, established, deleting, or destroying.
IKE Event
The IKE SA event: reauthentication or rekeying.
IKE Algorithm
The IKE algorithm being used by the VPN deployment.
IPsec State
The state of the IPsec SA: installing, installed, updating, rekeying, deleting, and destroying.
IPsec Event
Notification of when the IPsec SA event is rekeying.
IPsec Algorithm
IPsec algorithm being used by the VPN deployment.
Related Topics
Viewing VPN Statistics and Logs, on page 1210
In a multidomain deployment, the system displays VPN deployments created in the current domain. It also
displays VPN deployments created in ancestor domains if one of the endpoint devices belongs to your domain.
To view VPN deployments created in a lower domain, switch to that domain.
Procedure
Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility and
performance. For example, reputation-based blacklisting uses simple source and destination data, so it can
block prohibited traffic early in the process. In contrast, detecting and blocking intrusions and exploits is a
last-line defense.
Although you can configure the system without licensing your deployment, many features require that you
enable the appropriate licenses before you deploy. Also, some features are only available on certain device
models. Warning icons and confirmation dialog boxes designate unsupported features.
Note For the system to affect traffic, you must deploy relevant configurations to managed devices using routed,
switched, or transparent interfaces, or inline interface pairs. Sometimes, the system prevents you from
deploying inline configurations to passively deployed devices, including inline devices in tap mode. In
other cases, the policy may deploy successfully, but attempting to block or alter traffic using passively
deployed devices can have unexpected results. For example, the system may report multiple
beginning-of-connection events for each blocked connection, because blocked connections are not blocked
in passive deployments.
The following list describes the configurations you can change after you create a simple policy.
Note You can only edit access control policies that were created in the current domain. Also, you cannot edit
settings that are locked by an ancestor access control policy.
Inheritance Settings
Policy inheritance allows you to create a hierarchy of access control policies. A parent (or base) policy
defines and enforces default settings for its descendants, which is especially useful in multidomain
deployments.
A policy's inheritance settings allow you to select its base policy. You can also lock settings in the
current policy to force any descendants to inherit them. Descendant policies can override unlocked
settings.
Policy Assignment
Each access control policy identifies the devices that use it. Each device can be targeted by only one
access control policy. In a multidomain deployment, you can require that all the devices in a domain
use the same base policy.
Rules
Access control rules provide a granular method of handling network traffic. Rules in an access control
policy are numbered, starting at 1, including rules inherited from ancestor policies. The system matches
traffic to access control rules in top-down order by ascending rule number.
Usually, the system handles network traffic according to the first access control rule where all the rule’s
conditions match the traffic. Conditions can be simple or complex, and their use often depends on
certain licenses.
Default Action
The default action determines how the system handles and logs traffic that is not handled by any other
access control configuration. The default action can block or trust all traffic without further inspection,
or inspect traffic for intrusions and discovery data.
Although an access control policy can inherit its default action from an ancestor policy, you cannot
enforce this inheritance.
Security Intelligence
Security Intelligence is a first line of defense against malicious internet content. This feature allows
you to blacklist (block) connections based on the latest IP address, URL, and domain name reputation
intelligence. To ensure continual access to vital resources, you can override blacklists with custom
whitelists.
HTTP Responses
When the system blocks a user’s website request, you can either display a generic system-provided
response page, or a custom page. You can also display a page that warns users, but also allows them
to continue to the originally requested site.
The access control policy default action can block or trust traffic without further inspection, or inspect traffic
for intrusions and discovery data.
Note You cannot perform file or malware inspection on traffic handled by the default action. Logging for
connections handled by the default action is initially disabled, though you can enable it.
If you are using policy inheritance, the default action for the lowest-level descendant determines final traffic
handling. Although an access control policy can inherit its default action from its base policy, you cannot
enforce this inheritance.
The following table describes the types of inspection you can perform on traffic handled by each default
action.
Access Control: Trust All Traffic trust (allow to its final destination none
without further inspection)
The following diagrams illustrate the Block All Traffic and Trust All Traffic default actions.
The following diagrams illustrate the Intrusion Prevention and Network Discovery Only default actions.
Tip The purpose of Network Discovery Only is to improve performance in a discovery-only deployment.
Different configurations can disable discovery if you are only interested in intrusion detection and
prevention.
Although an access control policy can inherit its default action from an ancestor policy, you cannot enforce
this inheritance.
Note Although the most useful implementation of access control inheritance and enforcement complements
multitenancy, you can create a hierarchy of access control policies within a single domain. You can also
assign and deploy access control policies at any level.
The Firepower System allows you to edit system-provided access control policies and create custom access
control policies. Depending on your devices' initial configurations, system-provided policies can include:
• Default Access Control—Blocks all traffic without further inspection.
• Default Intrusion Prevention—Allows all traffic, but also inspects with the Balanced Security and
Connectivity intrusion policy and default intrusion variable set.
• Default Network Discovery—Allows all traffic while inspecting it for discovery data but not intrusions
or exploits.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
When you create a new access control policy, you must, at minimum, choose a default action.
In most cases, logging of connections handled by a default action is initially disabled. An exception occurs
if you create a subpolicy in a multidomain deployment. In that case, the system enables connection logging
according to the logging configuration of the inherited default action.
Procedure
Tip If you want to trust all traffic by default, or if you chose a base policy and do not want to inherit the
default action, you can change the default action later.
Step 6 Optionally, choose the Available Devices where you want to deploy the policy, then click Add to Policy (or
drag and drop) to add the selected devices. To narrow the devices that appear, type a search string in the
Search field.
If you want to deploy this policy immediately, you must perform this step.
What to Do Next
• Optionally, further configure the new policy as described in Editing an Access Control Policy, on page
1221.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Only one person should edit a policy at a time, using a single browser window. If multiple users save the same
policy, the last saved changes are retained. For your convenience, the system displays information on who (if
anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30
minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.
Procedure
• Default Action Variable Set—To change the variable set associated with an Intrusion Prevention
default action, click the variables icon ( ). In the popup window that appears, select a new variable
set and click OK. You can also click the edit icon ( ) to edit the selected variable set in a new window.
For more information, see Managing Variables, on page 378.
• Default Action Logging—To configure logging for connections handled by the default action, click the
logging icon ( ); see Logging Connections with a Policy Default Action, on page 2242.
• HTTP Responses—To specify what the user sees in a browser when the system blocks a website request,
click the HTTP Responses tab; see Choosing HTTP Response Pages, on page 1252.
• Inheritance: Change Base Policy—To change the base access control policy for this policy, click
Inheritance Settings; see Choosing a Base Access Control Policy, on page 1223.
• Inheritance: Lock Settings in Descendants—To enforce this policy's settings in its descendant policies,
click Inheritance Settings; see Locking Settings in Descendant Access Control Policies, on page 1224.
• Policy Assignment: Targets—To identify the managed devices targeted by this policy, click Policy
Assignment; see Setting Target Devices for an Access Control Policy, on page 1226.
• Policy Assignment: Required in Domains—To enforce this policy in a subdomain, click Policy
Assignment; see Requiring an Access Control Policy in a Domain, on page 1225.
• Rules—To manage access control rules, and to inspect and block malicious traffic using intrusion and
file policies, click the Rules tab; see Creating and Editing Access Control Rules, on page 1236.
• Rule Conflicts—To show rule conflict warnings, enable Show rule conflicts. Rule conflicts occur when
a rule will never match traffic because an earlier rule always matches the traffic first. Because determining
rule conflicts is resource intensive, displaying them may take some time. For more information, see
Guidelines for Ordering Rules, on page 338.
• Security Intelligence—To immediately blacklist (block) connections based on the latest reputation
intelligence, click the Security Intelligence tab; see Configuring Security Intelligence, on page 1259.
• Advanced Options—To set preprocessing, SSL inspection, identity, performance, and other advanced
options, click the Advanced tab; see Access Control Policy Advanced Settings, on page 1226.
• Warnings—To view a list of warnings or errors in your access control policy (and its descendant and
associated policies), click Show Warnings. Warnings and errors mark configurations that could adversely
affect traffic analysis and flow or prevent the policy from deploying. If there are no warnings, the button
does not appear. To view rule conflict warnings, first enable Show rule conflicts.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 Edit the access control policy whose inheritance settings you want to change; see Editing an Access Control
Policy, on page 1221.
Step 2 Manage policy inheritance:
• Change Base Policy — To change the base access control policy for this policy, click Inheritance
Settings and proceed as described in Choosing a Base Access Control Policy, on page 1223.
• Lock Settings in Descendants — To enforce this policy's settings in its descendant policies, click
Inheritance Settings and proceed as described in Locking Settings in Descendant Access Control
Policies, on page 1224 .
• Required in Domains — To enforce this policy in a subdomain, click Policy Assignment and proceed
as described in Requiring an Access Control Policy in a Domain, on page 1225.
• Inherit Settings from Base Policy — To inherit settings from a base access control policy, click the
Security Intelligence, HTTP Responses, or Advanced tab and proceed as directed in Inheriting Access
Control Policy Settings from the Base Policy, on page 1223.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can use one access control policy as the base (parent) for another. By default, a child policy inherits its
settings from its base policy, though you can change unlocked settings.
When you change the base policy for the current access control policy, the system updates the current policy
with any locked settings from the new base policy.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
A new child policy inherits many settings from its base policy. If these settings are unlocked in the base policy,
you can override them.
If you later reinherit the settings from the base policy, the system displays the base policy's settings and dims
the controls. However, the system saves the overrides you made, and restores them if you disable inheritance
again.
Procedure
Step 1 In the access control policy editor, click the Security Intelligence, HTTP Responses, or Advanced tab.
Step 2 Check the Inherit from base policy check box for each setting you want to inherit.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Lock a setting in an access control policy to enforce the setting in all descendant policies. Descendant policies
can override unlocked settings.
When you lock settings, the system saves overrides already made in descendant polices so that the overrides
can be restored if you unlock settings again.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can require that every device in a domain use the same base access control policy or one of its descendant
policies.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
An access control policy specifies the devices that use it. Each device can be targeted by only one access
control policy. In multidomain deployments, you can require that all the devices in a domain use the same
base policy.
Procedure
Under Impacted Devices, the system lists the devices whose assigned access control policies are children of
the current policy. Any change to the current policy affects these devices.
Step 3 Optionally, click the Required on Domains tab to require that all the devices in the subdomains you choose
use the same base policy. See Requiring an Access Control Policy in a Domain, on page 1225.
Step 4 Click OK to save your targeted device settings.
Step 5 Click Save to save the access control policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Caution See Configurations that Restart the Snort Process When Deployed or Activated, on page 294 for a list of
advanced setting modifications that restart the Snort process, temporarily interrupting traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on the model
of the managed device and how it handles traffic. See also Snort® Restart Traffic Behavior, on page 293.
General Settings
To customize the number of characters you store for each URL requested by your users, see Limiting Logging
of Long URLs, on page 2243.
To customize the length of time before you re-block a website after a user bypasses an initial block, see Setting
the User Bypass Timeout for a Blocked Website, on page 1254.
Disable Retry URL cache miss lookup to allow the system to immediately pass traffic to a URL without a
cloud lookup when the category is not cached. The system treats URLs that require a cloud lookup as
Uncategorized until the cloud lookup completes with a different category.
Disable Enable Threat Intelligence Director to stop publishing TID data to your configured devices. For
more information about TID, see Cisco Threat Intelligence Director (TID), on page 1417.
To inspect traffic when you deploy configuration changes unless specific configurations require restarting
the Snort process, ensure that Inspect traffic during policy apply is set to its default value (enabled). When
this option is enabled, resource demands could result in a small number of packets dropping without inspection.
See Snort® Restart Scenarios , on page 292 for more information.
Associated Policies
Use advanced settings to associate subpolicies (SSL, identity, prefilter) with access control; see Associating
Other Policies with Access Control, on page 1228.
For more information, see Advanced Access Control Settings for Network Analysis and Intrusion Policies,
on page 1695.
Use an access control policy's advanced settings to associate one of each of the following subpolicies with
the access control policy:
• SSL policy—Monitors, decrypts, blocks, or allows application layer protocol traffic encrypted with
Secure Socket Layer (SSL) or Transport Layer Security (TLS).
Caution Adding or removing an SSL policy restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic drops
during this interruption or passes without further inspection depends on the model of
the managed device and how it handles traffic. See Snort® Restart Traffic Behavior,
on page 293 for more information.
• Identity policy—Performs user authentication based on the realm and authentication method associated
with the traffic.
• Prefilter policy—Performs early traffic handling using limited network (layer 4) outer-header criteria.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) in the appropriate Policy Settings area.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note 8000 Series fastpathing, prefilter evaluation, Security Intelligence filtering, SSL inspection, user
identification, and some decoding and preprocessing occur before access control rules evaluate network
traffic.
The system matches traffic to access control rules in the order you specify. In most cases, the system handles
network traffic according to the first access control rule where all the rule’s conditions match the traffic.
Each rule also has an action, which determines whether you monitor, trust, block, or allow matching traffic.
When you allow traffic, you can specify that the system first inspect it with intrusion or file policies to block
any exploits, malware, or prohibited files before they reach your assets or exit your network.
The following scenario summarizes the ways that traffic can be evaluated by access control rules in an inline,
intrusion prevention deployment.
Traffic you allow, whether with an access control rule or the default action, is automatically eligible for
inspection for host, application, and user data by the network discovery policy. You do not explicitly enable
discovery, although you can enhance or disable it. However, allowing traffic does not automatically guarantee
discovery data collection. The system performs discovery only for connections involving IP addresses that
are explicitly monitored by your network discovery policy; additionally, application discovery is limited for
encrypted sessions.
Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to
pass, or if you do not configure SSL inspection. However, some access control rule conditions require
unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion
and file inspection of encrypted payloads. This helps reduce false positives and improve performance when
an encrypted connection matches an access control rule that has intrusion and file inspection configured.
Disabled rules are dimmed and marked (disabled) beneath the rule name.
To create or edit a rule, use the access control rule editor. You can:
• Configure basic properties such as the rule’s name, state, position, and action in the upper portion of the
editor.
• Add conditions using the tabs on the left side of the lower portion of the editor.
• Use the tabs on the right side of the lower portion to configure inspection and logging options, and also
to add comments to the rule. For your convenience, the editor lists the rule’s inspection and logging
options regardless of which tab you are viewing.
Note Properly creating and ordering access control rules is a complex task, but one that is essential to building
an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require
additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as
you expect, the access control policy interface has a robust warning and error feedback system for rules.
State
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.
Position
Rules in an access control policy are numbered, starting at 1. If you are using policy inheritance, rule 1 is the
first rule in the outermost policy. The system matches traffic to rules in top-down order by ascending rule
number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that
traffic.
Rules can also belong to a section and a category, which are organizational only and do not affect rule position.
Rule position goes across sections and categories.
Conditions
Conditions specify the specific traffic the rule handles. Conditions can be simple or complex; their use often
depends on license.
Action
A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow
(with or without further inspection) matching traffic. The system does not perform deep inspection on trusted,
blocked, or encrypted traffic.
Inspection
Deep inspection options govern how the system inspects and blocks malicious traffic you would otherwise
allow. When you allow traffic with a rule, you can specify that the system first inspect it with intrusion or file
policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network.
Logging
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record
of traffic that matches a rule. In general, you can log sessions at the beginning or end of a connection, or both.
You can log connections to the database, as well as to the system log (syslog) or to an SNMP trap server.
Comments
Each time you save changes to an access control rule, you can add comments.
In most cases, the system handles network traffic according to the first access control rule where all the rule’s
conditions match the traffic. Except Monitor rules (which log traffic but do not affect traffic flow), the system
does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule.
To help you organize access control rules, every access control policy has two system-provided rule sections,
Mandatory and Default. To further organize, you can create custom rule categories inside the Mandatory or
Default sections. After you create a category, you cannot move it, although you can delete it, rename it, and
move rules into, out of, within, and around it. The system assigns rule numbers across sections and categories.
If you use policy inheritance, the current policy's rules are nested between its parent policy's Mandatory and
Default rule sections. Rule 1 is the first rule in the outermost policy, not the current policy, and the system
assigns rule numbers across policies, sections, and categories.
Any predefined user role that allows you to modify access control policies also allows you to move and modify
access control rules within and among rules categories. You can, however, create custom roles that restrict
users from moving and modifying rules. Any user who is allowed to modify access control policies can add
rules to custom categories and modify rules in them without restriction.
Tip Proper access control rule order reduces the resources required to process network traffic, and prevents
rule preemption. Although the rules you create are unique to every organization and deployment, there
are a few general guidelines to follow when ordering rules that can optimize performance while still
addressing your needs.
You can divide an access control policy's Mandatory and Default rule sections into custom categories. After
you create a category, you cannot move it, although you can delete it, rename it, and move rules into, out of,
within, and around it. The system assigns rule numbers across sections and categories.
Procedure
• To insert a category above or below an access control rule, choose above rule or below rule, then enter
an existing rule number.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the access control policy editor, you have the following options:
• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ).
If a view icon ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have
permission to modify the rule.
the file and malware inspection icon ( ) to configure the rule’s Inspection options. If the icon is
dimmed, no policy of that type is selected for the rule. See Access Control Using Intrusion and File
Policies, on page 1243 for more information.
• Content Restriction—Click the Safe Search icon ( ) or YouTube EDU icon ( ) to configure content
restriction settings on the Applications tab of the rule editor. If the icons are dimmed, content restriction
is disabled for the rule. See About Content Restriction, on page 1299 for more information.
• Logging—Click an active (blue) logging icon ( ) to specify Logging options. If the icon is dimmed,
connection logging is disabled for the rule. See Connection Logging Strategies, on page 2232 for more
information.
• Comments—Click the number in the comment column to add Comments. The number indicates how
many comments the rule already contains. See Access Control Rule Comments, on page 1241 for more
information.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you create an access control rule, it is enabled by default. If you disable a rule, the system does not use
it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of
rules in an access control policy, disabled rules are grayed out, although you can still modify them.
Tip You can also enable or disable an access control rule using the rule editor.
Procedure
Step 1 In the access control policy editor, right-click the rule and choose a rule state.
If a view icon ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have
permission to modify the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can move an existing rule within, but not between, access control policies. When you add or move a rule
to a category, the system places it last in the category.
Tip You can move multiple rules at once by selecting the rules then cutting and pasting using the right-click
menu.
Procedure
Step 1 In the access control rule editor, you have the following options:
• If you are adding a new rule, use the Insert drop-down list.
• If you are editing an existing rule, click Move.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note If locally-bound traffic matches a Monitor rule in a Layer 3 deployment, that traffic may bypass inspection.
To ensure inspection of the traffic, enable Inspect Local Router Traffic in the advanced device settings
for the managed device routing the traffic.
When you block web requests, you can display a HTTP response page; see HTTP Response Pages and
Interactive Blocking, on page 1251.
If a user bypasses the block, the rule mimics an Allow rule. Therefore, you can associate either type of
Interactive Block rule with a file and intrusion policy to inspect this user-allowed traffic. The system can also
inspet with network discovery.
If a user does not (or cannot) bypass the block, the rule mimics a Block rule. Matching traffic is denied without
further inspection.
• You can perform network-based advanced malware protection (AMP), also using a file policy. AMP
for Firepower can inspect files for malware, and block detected malware depending on the configuration.
The following diagram illustrates the types of inspection performed on traffic that meets the conditions of an
Allow rule (or a user-bypassed Interactive Block rule. Notice that file inspection occurs before intrusion
inspection; blocked files are not inspected for intrusion-related exploits.
For simplicity, the diagram displays traffic flow for situations where both (or neither) an intrusion and a file
policy are associated with an access control rule. You can, however, configure one without the other. Without
a file policy, traffic flow is determined by the intrusion policy; without an intrusion policy, traffic flow is
determined by the file policy.
Regardless of whether the traffic is inspected or dropped by an intrusion or file policy, the system can inspect
it using network discovery. However, allowing traffic does not automatically guarantee discovery inspection.
The system performs discovery only for connections involving IP addresses that are explicitly monitored by
your network discovery policy; additionally, application discovery is limited for encrypted sessions.
Procedure
Step 1 In the access control rule editor, click the Comments tab.
Step 2 Click New Comment.
Step 3 Enter your comment and click OK. You can edit or delete this comment until you save the rule.
Step 4 Click Save.
Step 5 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Access control occurs before deep inspection; access control rules and the access control default action
determine which traffic is inspected by intrusion and file policies.
By associating an intrusion or file policy with an access control rule, you are telling the system that before it
passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an
intrusion policy, a file policy, or both.
Note By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false
positives and improve performance when an encrypted connection matches an access control rule that has
intrusion and file inspection configured.
The system can also receive AMP for Endpoints data from the AMP cloud, then present this data alongside
any AMP for Firepower data.
In the scenario above, the first three access control rules in the policy—Monitor, Trust, and Block—cannot
inspect matching traffic. Monitor rules track and log but do not inspect network traffic, so the system continues
to match traffic against additional rules to determine whether to permit or deny it. Trust and Block rules handle
matching traffic without further inspection of any kind, while traffic that does not match continues to the next
access control rule.
The fourth and final rule in the policy, an Allow rule, invokes various other policies to inspect and handle
matching traffic, in the following order:
• Discovery: Network Discovery Policy—First, the network discovery policy inspects traffic for discovery
data. Discovery is passive analysis and does not affect the flow of traffic. Although you do not explicitly
enable discovery, you can enhance or disable it. However, allowing traffic does not automatically
guarantee discovery data collection. The system performs discovery only for connections involving IP
addresses that are explicitly monitored by your network discovery policy.
• AMP for Firepower and File Control: File Policy—After traffic is inspected by discovery, the system
can inspect it for prohibited files and malware. AMP for Firepower detects and optionally blocks malware
in many types of files, including PDFs, Microsoft Office documents, and others. If your organization
wants to block not only the transmission of malware files, but all files of a specific type (regardless of
whether the files contain malware), file control allows you to monitor network traffic for transmissions
of specific file types, then either block or allow the file.
• Intrusion Prevention: Intrusion Policy—After file inspection, the system can inspect traffic for
intrusions and exploits. An intrusion policy examines decoded packets for attacks based on patterns,
and can block or alter malicious traffic. Intrusion policies are paired with variable sets, which allow you
to use named values to accurately reflect your network environment.
• Destination—Traffic that passes all the checks described above passes to its destination.
An Interactive Block rule (not shown in the diagram) has the same inspection options as an Allow rule. This
is so you can inspect traffic for malicious content when a user bypasses a blocked website by clicking through
a warning page.
Traffic that does not match any of the non-Monitor access control rules in the policy is handled by the default
action. In this scenario, the default action is an Intrusion Prevention action, which allows traffic to its final
destination as long as it is passed by the intrusion policy you specify. In a different deployment, you might
have a default action that trusts or blocks all traffic without further inspection. Note that the system can inspect
traffic allowed by the default action for discovery data and intrusions, but not prohibited files or malware.
You cannot associate a file policy with the access control default action.
Note Sometimes, when a connection is analyzed by an access control policy, the system must process the first
few packets in that connection, allowing them to pass, before it can decide which access control rule (if
any) will handle the traffic. However, so these packets do not reach their destination uninspected, you can
use an intrusion policy—called the default intrusion policy—to inspect them and generate intrusion events.
Note Traffic allowed by an Intrusion Prevention or Network Discovery Only default action can be inspected
for discovery data and intrusions, but cannot be inspected for prohibited files or malware. You cannot
associate a file policy with the access control default action.
You do not have to perform both file and intrusion inspection in the same rule. For a connection matching an
Allow or Interactive Block rule:
• without a file policy, traffic flow is determined by the intrusion policy
• without an intrusion policy, traffic flow is determined by the file policy
• without either, allowed traffic is inspected by network discovery only
Tip The system does not perform any kind of inspection on trusted traffic. Although configuring an Allow
rule with neither an intrusion nor file policy passes traffic like a Trust rule, Allow rules let you perform
discovery on matching traffic.
The diagram below illustrates the types of inspection you can perform on traffic that meets the conditions of
either an Allow or user-bypassed Interactive Block access control rule. For simplicity, the diagram displays
traffic flow for situations where both (or neither) an intrusion and a file policy are associated with a single
access control rule.
For any single connection handled by an access control rule, file inspection occurs before intrusion inspection.
That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple
blocking by type takes precedence over malware inspection and blocking.
For example, consider a scenario where you normally want to allow certain network traffic as defined in an
access control rule. However, as a precaution, you want to block the download of executable files, examine
downloaded PDFs for malware and block any instances you find, and perform intrusion inspection on the
traffic.
You create an access control policy with a rule that matches the characteristics of the traffic you want to
provisionally allow, and associate it with both an intrusion policy and a file policy. The file policy blocks the
download of all executables, and also inspects and blocks PDFs containing malware:
• First, the system blocks the download of all executables, based on simple type matching specified in the
file policy. Because they are immediately blocked, these files are subject to neither malware nor intrusion
inspection.
• Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network.
Any PDFs with a malware disposition are blocked, and are not subject to intrusion inspection.
• Finally, the system uses the intrusion policy associated with the access control rule to inspect any
remaining traffic, including files not blocked by the file policy.
Note Until a file is detected and blocked in a session, packets from the session may be subject to intrusion
inspection.
The system also logs the end of the associated connection to the Firepower Management Center database,
regardless of the logging configuration of the invoking access control rule.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the
last file rule that combines the Malware Cloud Lookup or Block Maware file rule action with an analyis
option (Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files
option (Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration
changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes
without further inspection depends on the model of the managed device and how it handles traffic. See
Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
Step 1 In the access control rue editor, choose an Action of Allow, Interactive Block, or Interactive Block with
reset.
Step 2 Click the Inspection tab.
Step 3 Choose a Malware Policy (file policy) to inspect traffic that matches the access control rule, or choose None
to disable file inspection for matching traffic.
Step 4 (Optional) Disable logging of file or malware events for matching connections by clicking the Logging tab
and unchecking Log Files.
Note Cisco recommends you leave file and malware event logging enabled.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip Even if you use system-provided intrusion policies, Cisco strongly recommends you configure the system’s
intrusion variables to accurately reflect your network environment. At a minimum, modify default variables
in the default set.
Procedure
Step 1 In the access control policy editor, create a new rule or edit an existing rule; see Access Control Rule
Components, on page 1233.
Step 2 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.
Step 3 Click the Inspection tab.
Step 4 Choose a system-provided or custom Intrusion Policy, or choose None to disable intrusion inspection for
traffic that matches the access control rule.
Step 5 If you want to change the variable set associated with the intrusion policy, choose a value from the Variable
Set drop-down list.
Step 6 Click Save to save the rule.
Step 7 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
HTTP response pages do not always appear when the system blocks web traffic; see Limitations to HTTP
Response Pages, on page 1251.
Encrypted Traffic
The system displays a response page for connections decrypted by the SSL policy, then blocked (or interactively
blocked) either by access control rules or by the access control policy default action. In these cases, the system
encrypts the response page and sends it at the end of the reencrypted SSL stream.
However, the system does not display a response page for encrypted connections blocked by access control
rules (or any other configuration). Access control rules evaluate encrypted connections if you did not configure
an SSL policy, or your SSL policy passes encrypted traffic.
For example, the system cannot decrypt HTTP/2 or SPDY sessions. If web traffic encrypted using one of
these protocols reaches access control rule evaluation, the system does not display a response page if the
session is blocked.
Reliable display of HTTP response pages depends on your network configuration, traffic loads, and size of
the page. Smaller pages are more likely to display successfully.
Procedure
Step 1 In the access control policy editor, click the HTTP Responses tab.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 2 Choose the Block Response Page and Interactive Block Response Page:
• System-provided—Displays a generic response. Click the view icon ( ) to view the code for this page.
• Custom—Create a custom response page. A pop-up window appears, prepopulated with system-provided
code that you can replace or modify by clicking the edit icon ( ). A counter shows how many characters
you have used.
• None—Disables the response page and blocks sessions without interaction or explanation. To quickly
disable interactive blocking for the whole access control policy, choose this option.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip To quickly disable interactive blocking for the whole access control policy, display neither the
system-provided page nor a custom page. The system then blocks all connections without interaction.
If a user does not bypass an interactive block, matching traffic is denied without further inspection. If a user
bypasses an interactive block, the access control rule allows the traffic, although the traffic may still be subject
to deep inspection and blocking.
By default, a user bypass is in effect for 10 minutes (600 seconds) without displaying the warning page on
subsequent visits. You can set the duration to as long as a year, or you can force the user to bypass the block
every time. This limit applies to every Interactive Block rule in the policy. You cannot set the limit per rule.
Logging options for interactively blocked traffic are identical to those in allowed traffic, but if a user does
not bypass the interactive block, the system can log only beginning-of-connection events. When the system
initially warns the user, it marks any logged beginning-of-connection event with the Interactive Block
or Interactive Block with reset action. If the user bypasses the block, additional connection
events logged for the session have an action of Allow.
Procedure
Step 1 As part of access control, configure an access control rule that matches web traffic; see Creating and Editing
Access Control Rules, on page 1236:
• Action—Set the rule action to Interactive Block or Interactive Block with reset; see Access Control
Rule Interactive Blocking Actions, on page 1240.
• Conditions—Use URL conditions to specify the web traffic to interactively block; see URL Conditions
(URL Filtering), on page 321.
• Logging—Assume users will bypass the block and choose logging options accordingly; see Logging
for Allowed Connections, on page 2238.
• Inspection—Assume users will bypass the block and choose deep inspection options accordingly; see
Access Control Using Intrusion and File Policies, on page 1243.
Step 2 (Optional) On the access control policy HTTP Responses tab, choose a custom interactive-block HTTP
response page; see Choosing HTTP Response Pages, on page 1252.
Step 3 (Optional) On the access control policy Advanced tab, change the user bypass timeout; see Setting the User
Bypass Timeout for a Blocked Website, on page 1254.
After a user bypasses a block, the system allows the user to browse to that page without warning until the
timeout period elapses.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to General Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 In the Allow an Interactive Block to bypass blocking for (seconds) field, type the number of seconds that
must elapse before the user bypass expires. Specifying zero forces your users to bypass the block every time.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note You cannot blacklist fastpathed traffic. 8000 Series fastpathing and prefilter evaluation occur before
Security Intelligence filtering. Fastpathed traffic bypasses all further evaluation, including Security
Intelligence.
Although you can configure custom blacklists, Cisco provides access to regularly updated intelligence feeds.
Sites representing security threats such as malware, spam, botnets, and phishing appear and disappear faster
than you can update and deploy custom configurations.
You can refine Security Intelligence blacklisting with whitelists and monitor-only blacklists. These mechanisms
exempt traffic from being blacklisted, but do not automatically trust or fastpath matching traffic. Traffic
whitelisted or monitored at the Security Intelligence stage is intentionally subject to further analysis with the
rest of access control.
Blacklisting, whitelisting, or monitoring traffic based on a DNS list or feed also requires that you:
• Create a DNS policy. See Creating Basic DNS Policies, on page 1265 for more information.
• Configure DNS rules that reference your DNS lists or feeds. See Creating and Editing DNS Rules, on
page 1268 for more information.
Because you deploy the DNS policy as part of your access control policy, you must associate both policies.
See DNS Policy Deploy, on page 1275 for more information.
Note In passive deployments, to optimize performance, Cisco recommends that you always use monitor-only
settings. Managed devices that are deployed passively cannot affect traffic flow; there is no advantage to
configuring the system to block traffic. Additionally, because blocked connections are not actually blocked
in passive deployments, the system may report multiple beginning-of-connection events for each blocked
connection.
Example: Whitelisting
If a reputable feed improperly blocks your access to vital resources but is overall useful to your organization,
you can whitelist only the improperly classified IP addresses, rather than removing the whole feed from the
blacklist.
Each access control policy has Security Intelligence options. You can whitelist or blacklist network objects,
URL objects and lists, and Security Intelligence feeds and lists, all of which you can constrain by security
zone. You can also associate a DNS policy with your access control policy, and whitelist or blacklist domain
names.
Caution From the Security Intelligence tab in an access control policy, adding multiple objects to a whitelist or
blacklist, or deleting multiple objects, sometimes restarts the Snort process when you deploy configuration
changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes
without further inspection depends on the model of the managed device and how it handles traffic. See
Snort® Restart Traffic Behavior, on page 293 for more information. Note that whether the Snort process
restarts can vary by device, depending on the memory available for inspection.
You can add up to a total of 255 network objects and 32767 URL objects and lists to the whitelists and
blacklists. That is, the number of objects in the whitelists plus the number in the blacklists cannot exceed 255
network objects, or 32767 URL objects and lists.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
Procedure
Step 1 In the access control policy editor, click the Security Intelligence tab.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Find the Available Objects you want to add to the whitelist or blacklist. You have the following options:
• Search the available objects by typing in the Search by name or value field. Clear the search string by
clicking reload ( ) or clear ( ).
• If no existing list or feed meets your needs, click the add icon (), select New Network List or New
URL List, and proceed as described in Creating Security Intelligence Feeds, on page 386 or Uploading
New Security Intelligence Lists to the Firepower Management Center, on page 388.
• If no existing object meets your needs, click the add icon (
), select New Network Object or New
URL Object, and proceed as described in Creating Network Objects, on page 354.
Step 6 Click Add to Whitelist or Add to Blacklist, or click and drag the selected objects to either list.
To remove an object from a whitelist or blacklist, click its delete icon ( ) To remove multiple objects, choose
the objects and right-click to Delete Selected.
Step 7 Optionally, set blacklisted objects to monitor-only by right-clicking the object under Blacklist, then choosing
Monitor-only (do not block).
You cannot set system-provided Security Intelligence lists to monitor only.
Step 8 Choose a DNS policy from the DNS Policy drop-down list; see DNS Policy Overview, on page 1263.
Step 9 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In the blacklist, objects set to block are marked with the block icon ( ) while monitor-only objects are marked
with the monitor icon ( ). Monitor-only allows the system to handle connections involving blacklisted IP
addresses and URLs using access control, but also logs the connection’s match to the blacklist.
Because the whitelist overrides the blacklist, if you add the same object to both lists, the system displays the
blacklisted object with a strikethrough.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1456.
Zone Constraints
Except for the system-provded Global lists, you can constrain Security Intelligence filtering by zone. To
enforce Security Intelligence filtering for an object on multiple zones, you must add the object to the whitelist
or blacklist separately for each zone.
Logging
Security Intelligence logging, enabled by default, logs all blocked and monitored connections handled by an
access control policy’s target devices. However, the system does not log whitelist matches; logging of whitelisted
connections depends on their eventual disposition. You must enable logging for blacklisted connections before
you can set blacklisted objects to monitor-only.
Dga Malware algorithms used to generate a large number of domain names acting as
rendezvous points with their command-and-control servers
OpenRelay Open mail relays that are known to be used for spam
Response IP addresses and URLs that are actively participating in malicious or suspicious
activity
Suspicious Files that appear to be suspicious and have characteristics that resemble known
malware
Note DNS-based Security Intelligence may not work as intended for a domain name unless the DNS server
deletes a domain cache entry due to expiration, or a client’s DNS cache or the local DNS server’s cache
is cleared or expires.
You configure DNS-based Security Intelligence using a DNS policy and associated DNS rules. To deploy it
to your devices, you must associate your DNS policy with an access control policy, then deploy your
configuration to managed devices.
Rules
Rules provide a granular method of handling network traffic based on the domain name. Rules in a
DNS policy are numbered, starting at 1. The system matches traffic to DNS rules in top-down order
by ascending rule number.
When you create a DNS policy, the system populates it with a default Global DNS Whitelist rule and
a default Global DNS Blacklist rule. Both rules are fixed to the first position in their respective categories.
You cannot modify these rules, but you can disable them.
In a multidomain deployment, the system also adds Descendant DNS Whitelists and Descendant DNS
Blacklists rules to DNS policies in ancestor domains. These rules are fixed to the second position in
their respective categories.
Note If multitenancy is enabled for your Firepower Management Center, the system
is organized into a hierarchy of domains, including ancestor and descendant
domains. These domains are distinct and separate from the domain names used
in DNS management.
A descendant list contains the domains whitelisted or blacklisted by Firepower System subdomain
users. From an ancestor domain, you cannot view the contents of descendant lists. If you do not want
subdomain users to whitelist or blacklist domains:
• disable the descendant list rules, and
• enforce Security Intelligence using the access control policy inheritance settings
Usually, the system handles DN-based network traffic according to the first DNS rule where all the
rule’s conditions match the traffic. If no DNS rules match the traffic, the system continues evaluating
the traffic based on the associated access control policy's rules. DNS rule conditions can be simple or
complex.
Procedure
What to Do Next
• Optionally, further configure the new policy as described in Logging Connections with Security
Intelligence, on page 2240.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Only one person should edit a DNS policy at a time, using a single browser window. If multiple users attempt
to save the same policy, only the first set of saved changes are retained.
To protect the privacy of your session, after thirty minutes of inactivity on the policy editor, a warning appears.
After sixty minutes, the system discards your changes.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Use the DNS Policy page (Policies > Access Control > DNS) to manage custom DNS policies. In addition
to custom policies that you create, the system provides the Default DNS Policy, which uses the default blacklist
and whitelist. You can edit and use this system-provided custom policy. In a multidomain deployment, this
default policy uses the default Global DNS Blacklist, Global DNS Whitelist, Descendant DNS Blacklists,
and Descendant DNS Whitelists, and can only be edited in the Global domain.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
DNS Rules
DNS rules handle traffic based on the domain name requested by a host. As part of Security Intelligence, this
evaluation happens after any traffic decryption, and before access control evaluation.
The system matches traffic to DNS rules in the order you specify. In most cases, the system handles network
traffic according to the first DNS rule where all the rule’s conditions match the traffic. When you create DNS
rules, the system places whitelist rules before monitor and blacklist rules, and evaluates traffic against whitelist
rules first.
In addition to its unique name, each DNS rule has the following basic components:
State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and
stops generating warnings and errors for that rule.
Position
Rules in a DNS policy are numbered, starting at 1. The system matches traffic to rules in top-down order by
ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that
handles that traffic.
Conditions
Conditions specify the specific traffic the rule handles. A DNS rule must contain a DNS feed or list condition,
and can also match traffic by security zone, network, or VLAN.
Action
A rule’s action determines how the system handles matching traffic:
• Whitelisted traffic is allowed, subject to further access control inspection.
• Monitored traffic is subject to further evaluation by remaining DNS blacklist rules. If the traffic does
not match a DNS blacklist rule, it is inspected with access control rules. The system logs a Security
Intelligence event for the traffic.
• Blacklisted traffic is dropped without further inspection. You can also return a Domain Not Found
response, or redirect the DNS query to a sinkhole server.
Related Topics
About Security Intelligence, on page 1257
In a DNS policy, you can add up to a total of 32767 DNS lists to the whitelist and blacklist rules; that is, the
number of lists in the DNS policy cannot exceed 32767.
Procedure
Step 1 In the DNS policy editor, you have the following options:
• To add a new rule, click Add DNS Rule.
• To edit an existing rule, click the edit icon ( ).
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
When you create a DNS rule, it is enabled by default. If you disable a rule, the system does not use it to
evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules
in a DNS policy, disabled rules are dimmed, although you can still modify them. Note that you can also enable
or disable a DNS rule using the DNS rule editor.
Procedure
Step 1 In the DNS policy editor, right-click the rule and choose a rule state.
Step 2 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• logging—the rule action determines when and how you can log details about matching traffic
Keep in mind that only devices deployed inline can blacklist traffic. Devices deployed passively or in tap
mode can whitelist and log, but not affect, traffic.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1456.
Whitelist Action
The Whitelist action allows matching traffic to pass. When you whitelist traffic, it is subject to further
inspection either by a matching access control rule, or the access control policy's default action.
The system does not log whitelist matches. However, logging of whitelisted connections depends on their
eventual disposition.
Monitor Action
The Monitor action does not affect traffic flow; matching traffic is neither immediately whitelisted nor
blacklisted. Rather, traffic is matched against additional rules to determine whether to permit or deny it. The
first non-Monitor DNS rule matched determines whether the system blacklists the traffic. If there are no
additional matching rules, the traffic is subject to access control evaluation.
For connections monitored by a DNS policy, the system logs end-of-connection Security Intelligence and
connection events to the Firepower Management Center database.
Blacklist Actions
The blacklist actions blacklist traffic without further inspection of any kind:
• The Drop action drops the traffic.
• The Domain Not Found action returns a non-existent internet domain response to the DNS query, which
prevents the client from resolving the DNS request.
• The Sinkhole action returns a sinkhole object's IPv4 or IPv6 address in response to the DNS query. The
sinkhole server can log, or log and block, follow-on connections to the IP address. If you configure a
Sinkhole action, you must also configure a sinkhole object.
For a connection blacklisted based on the Drop or Domain Not Found actions, the system logs
beginning-of-connection Security Intelligence and connection events. Because blacklisted traffic is immediately
denied without further inspection, there is no unique end of connection to log.
For a connection blacklisted based on the Sinkhole action, logging depends on the sinkhole object configuration.
If you configure your sinkhole object to only log sinkhole connections, the system logs end-of-connection
connection events for the follow-on connection. If you configure your sinkhole object to log and block sinkhole
connections, the system logs beginning-of-connection connection events for the follow-on connection, then
blocks that connection.
Note On an ASA FirePOWER device, if you configure a DNS rule with a sinkhole action, and traffic matches
the rule, the ASA blocks the follow-on sinkhole connection by default. As a workaround, run the following
commands from the ASA command line:
asa(config)# policy-map global_policy
asa(config-pmap)# class inspection_default
asa(config-pmap-c)# no inspect dns preset_dns_map
If the ASA continues to block the connection, contact Support.
Related Topics
Actions and Connection Logging, on page 2235
Zone conditions in DNS rules allow you to control traffic by its source and destination security zones. A
security zone is a grouping of one or more interfaces, which may be located across multiple devices. An option
you choose during a device’s initial setup, called its detection mode, determines how the system initially
configures the device’s interfaces, and whether those interfaces belong to a security zone.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Network conditions in DNS rules allow you to control traffic by its source IP address. You can explicitly
specify the source IP addresses for the traffic you want to control.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
VLAN conditions in DNS rules allow you to control VLAN-tagged traffic. The system uses the innermost
VLAN tag to identify a packet by VLAN.
When you build a VLAN-based DNS rule condition, you can manually specify VLAN tags. Alternately, you
can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one
or more VLAN tags.
Procedure
Step 1 In the DNS rule editor, select the VLAN Tags tab.
Step 2 Find and select the VLANs you want to add from the Available VLAN Tags, as follows:
• To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon (
)
above the Available VLAN Tags list and proceed as described in Creating VLAN Tag Objects, on page
359.
• To search for VLAN tag objects and groups to add, click the Search by name or value prompt above
the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in
the object. The list updates as you type to display matching objects.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
DNS conditions in DNS rules allow you to control traffic if a DNS list, feed, or category contains the domain
name requested by the client. You must define a DNS condition in a DNS rule.
Regardless of whether you add a global or custom whitelist or blacklist to a DNS condition, the system applies
the configured rule action to the traffic. For example, if you add the Global Whitelist to a rule, and configure
a Drop action, the system blacklists all traffic that should have been whitelisted.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
After you finish updating your DNS policy configuration, you must deploy it as part of access control
configuration.
• Associate your DNS policy with an access control policy, as described in Configuring Security
Intelligence, on page 1259.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Introduction to Prefiltering
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation.
Prefilter policies deployed to managed devices use limited outer-header criteria to quickly handle traffic.
Contrasted with the rest of access control, which uses inner headers and has more robust inspection capabilities,
prefiltering is simple, fast, and early.
Configure prefiltering if you want to:
• Improve performance— The sooner you exclude traffic that does not require inspection, the better. You
can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation
headers, without inspecting their encapsulated connections. You can also fastpath or block any other
connections that benefit from early handling.
• Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels, so that you can
later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary
because after prefiltering, access control uses inner headers.
Prefilter policies deployed to Classic devices (7000 and 8000 Series, NGIPSv, ASA FirePOWER) have no
effect. Instead, use early-placed Trust and Block access control rules to approximate prefilter functionality,
keeping in mind the differences between the two features.
Also:
• 8000 Series devices—Device-specific fastpath rules can bypass access control (but cannot block traffic);
see Configuring Fastpath Rules (8000 Series), on page 483.
• Classic devices—All Classic devices can match entire GRE-encapsulated tunnels using access control
rules, with some limitations; see Port and ICMP Code Conditions, on page 314.
Implementation Prefilter policy. Access control policy. About Prefilter Policies, on page
1281
The prefilter policy is invoked by The access control policy is a
the access control policy. master configuration. In addition Associating Other Policies with
to invoking subpolicies, access Access Control, on page 1228
control policies have their own
rules.
Bypass capability Fastpath rule action. Trust rule action. Introduction to Access Control
Rules, on page 1231
Fastpathing traffic in the prefilter Traffic trusted by access control
stage bypasses all further inspection rules is only exempt from deep
and handling, including: inspection and discovery.
• Security Intelligence
• authentication requirements
imposed by an identity policy
• SSL decryption
• access control rules
• deep inspection of packet
payloads
• discovery
• rate limiting
Connection logging Fastpathed and blocked traffic only. Any connection. Configurable Connection Logging,
Allowed connections may still be on page 2232
logged by other configurations.
Supported devices Firepower Threat Defense only. All. Prefiltering Model Restrictions, on
page 1277
Access control has no insight into encrypted passthrough tunnels. For example, access control rules see a
passthrough VPN tunnel as one connection. The system handles the entire tunnel using only the information
in its outer, encapsulation header.
Connection Logging
You can log connections fastpathed and blocked by the prefilter policy; see Configurable Connection Logging,
on page 2232.
Connection events contain information on whether and how logged connections—including entire tunnels—were
prefiltered. You can view this information in event views (workflows), dashboards, and reports, and use it as
correlation criteria. Keep in mind that because fastpathed and blocked connections are not subject to deep
inspection, associated connection events contain limited information.
Configuring Prefiltering
Smart License Classic License Supported Devices Supported Domains Access
Any N/A Firepower Threat Any Admin/Access
Defense Admin/Network
Admin
To perform custom prefiltering, configure and deploy prefilter policies to managed devices, as a part of access
control.
Only one person should edit a policy at a time, using a single browser window. If multiple users save the same
policy, the last saved changes are retained. For your convenience, the system displays information on who (if
anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30
minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.
Procedure
Step 3 Configure the prefilter policy's default action and its logging options.
• Default action—Choose a default action for supported plaintext, passthrough tunnels: Analyze all tunnel
traffic (with access control) or Block all tunnel traffic.
• Default action logging—Click the logging icon ( ) next to the default action; see Logging Connections
with a Policy Default Action, on page 2242. You can configure default action logging for blocked tunnels
only.
Step 5 Evaluate rule order. To move a rule, click and drag or use the right-click menu to cut and paste.
Properly creating and ordering rules is a complex task, but one that is essential to building an effective
deployment. If you do not plan carefully, rules can preempt other rules or contain invalid configurations. For
more information, see Rule Performance Guidelines, on page 337.
Step 9 Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Encapsulation and Encapsulation conditions match only Port conditions can use a wider range of
port/protocol criteria plaintext tunnels over selected protocols, port and protocol constraints than tunnel
listed in Encapsulation Conditions, on rules; see Port and ICMP Code
page 316. Conditions, on page 314.
Network criteria Tunnel endpoint conditions constrain the Network conditions constrain the source
endpoints of the tunnels you want to and destination hosts in each connection;
handle; see Tunnel Endpoint Conditions, see Network Conditions, on page 309.
on page 312.
Rezone sessions for Supported, using tunnel zones; see Tunnel Not supported.
further analysis Zones and Prefiltering, on page 1285.
State (Enabled/Disabled)
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.
Position
Rules are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule
number. The first rule that traffic matches is the rule that handles that traffic, regardless of rule type (tunnel
vs prefilter).
Action
A rule's action determines how the system handles and logs matching traffic:
• Fastpath—Exempts matching traffic from all futher inspection and control, including access control,
identity requirements, and rate limiting. Fastpathing a tunnel fastpaths all encapsulated connections.
• Block—Blocks matching traffic without further inspection of any kind. Blocking a tunnel blocks all
encapsulated connections.
• Analyze—Allows traffic to continue to be analyzed by the rest of access control, using inner headers.
If passed by access control and any related deep inspection, this traffic may also be rate limited. For
tunnel rules, enables rezoning with the Assign Tunnel Zone option.
Caution Exercise caution when assigning tunnel zones. Connections in rezoned tunnels may not match security
zone constraints in later evaluation. See Using Tunnel Zones, on page 1286 for a brief walkthrough of a
tunnel zone implementation, and a discussion of the implications of rezoning without explicitly handling
rezoned traffic.
Conditions
Conditions specify the specific traffic the rule handles. Traffic must match all a rule's conditions to match the
rule. Each condition type has its own tab in the rule editor.
Logging
A rule's logging settings govern the records the system keeps of the traffic it handles.
In tunnel and prefilter rules, you can log fastpathed and blocked traffic (the Fastpath and Block actions). For
traffic subject to further analysis (the Analyze action), logging in the prefilter policy is disabled, although
matching connections may still be logged by other configurations. For more information, see Logging
Connections with Tunnel and Prefilter Rules, on page 2239.
Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall
configuration for the benefit of other users, or note when you change a rule and the reason for the change.
You cannot edit or delete these comments after you save the rule.
Related Topics
Rule Performance Guidelines, on page 337
Caution For configurations that support tunnel zone constraints, connections in rezoned tunnels do not match
security zone constraints. For example, after you rezone a tunnel, access control rules can match its
encapsulated connections with their newly assigned tunnel zone, but not with any original security zone.
See Using Tunnel Zones, on page 1286 for a brief walkthough of a tunnel zone implementation, and a discussion
of the implications of rezoning without explicitly handling rezoned traffic.
This example procedure summarizes how you might rezone GRE tunnels for further analysis, using tunnel
zones. You can adapt the concepts described in this example to other scenarios where you need to tailor traffic
inspection to connections encapsulated in plaintext, passthrough tunnels.
Consider a Firepower System deployment where your organization's internal traffic flows through the Trusted
security zone. The Trusted security zone represents a set of sensing interfaces across multiple managed devices
deployed in various locations. Your organization's security policy requires that you allow internal traffic after
deep inspection for exploits and malware.
Internal traffic sometimes includes plaintext, passthrough, GRE tunnels between particular endpoints. Because
the traffic profile of this encapsulated traffic is different from your "normal" interoffice activity—perhaps it
is known and benign—you can limit inspection of certain encapsulated connections while still complying
with your security policy.
In this example, after you deploy configuration changes:
• Plaintext, passthrough, GRE-encapsulated tunnels detected in the Trusted zone have their individual
encapsulated connections evaluated by one set of intrusion and file policies.
• All other traffic in the Trusted zone is evaluated with a different set of intrusion and file policies.
You accomplish this task by rezoning GRE tunnels. Rezoning ensures that access control associates
GRE-encapsulated connections with a custom tunnel zone, rather than their original Trusted security zone.
Rezoning is required due to the way the Firepower System and access control handle encapsulated traffic; see
Passthrough Tunnels and Access Control, on page 1280 and Tunnel Zones and Prefiltering, on page 1285.
Procedure
Step 1 Configure custom intrusion and file policies that tailor deep inspection to encapsulated traffic, and another
set of intrusion and file policies tailored to nonencapsulated traffic.
Step 2 Configure custom prefiltering to rezone GRE tunnels flowing through the Trusted security zone.
Create a custom prefilter policy and associate it with access control. In that custom prefilter policy, create a
tunnel rule (in this example, GRE_tunnel_rezone) and a corresponding tunnel zone (GRE_tunnel). For more
information, see Configuring Prefiltering, on page 1282.
Tunnel endpoint Specify the source and destination endpoints for the GRE tunnels used in your
condition organization.
Tunnel rules are bidirectional by default. If you do not change the Match tunnels
from... option, it does not matter which endpoints you specify as source and
which as destination.
Assign Tunnel Zone Create the GRE_tunnel tunnel zone, and assign it to tunnels that match the rule.
Caution If you skip this step, the rezoned connections may match any access control rule not constrained
by security zone. If the rezoned connections do not match any access control rules, they are handled
by the access control policy default action. Make sure this is your intent.
Step 4 Configure access control to handle nonencapsulated connections flowing through the Trusted security zone.
In the same access control policy, configure a rule (in this example, internal_default_inspection) that handles
non-rezoned traffic in the Trusted security zone.
Step 5 Evaluate the position of the new access control rules relative to preexisting rules. Change rule order if necessary.
If you place the two new access control rules next to each other, it does not matter which you place first.
Because you rezoned GRE tunnels, the two rules cannot preempt each other.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
What to Do Next
• Assign tunnel zones to plaintext, passthrough tunnels as part of custom prefiltering; see Configuring
Prefiltering, on page 1282.
Introduction to IAB
IAB identifies applications that you trust to traverse your network without further inspection if performance
and flow thresholds are exceeded. For example, if a nightly backup significantly impacts system performance,
you can configure thresholds that, if exceeded, trust traffic generated by your backup application. Optionally,
you can configure IAB so that, when an inspection performance threshold is exceeded, IAB trusts all traffic
that exceeds any flow bypass threshold, regardless of the application type.
The system implements IAB on traffic allowed by access control rules or the access control policy's default
action, before the traffic is subject to deep inspection. A test mode allows you to determine whether thresholds
are exceeded and, if so, to identify the application flows that would have been bypassed if you had actually
enabled IAB (called bypass mode).
The following graphic illustrates the IAB decision-making process:
IAB Options
State
Enables or disables IAB.
Applications/Filters
Provides an editor where you can specify bypassable applications and sets of applications (filters). See
Application Conditions (Application Control), on page 316.
All applications including unidentified applications
When an inspection performance threshold is exceeded, trusts all traffic that exceeds any flow bypass
threshold, regardless of the application type.
Note Inspection performance and flow bypass thresholds are disabled by default. You must enable at least one
of each, and one of each must be exceeded for IAB to trust traffic. If you enable more than one inspection
performance or flow bypass threshold, only one of each must be exceeded for IAB to trust traffic.
Drop Percentage
Average packets dropped as a percentage of total packets, when packets are dropped because of
performance overloads caused by expensive intrusion rules, file policies, decompression, and so on.
This does not refer to packets dropped by normal configurations such as intrusion rules. Note that
specifying an integer greater than 1 activates IAB when the specified percentage of packets is dropped.
When you specify 1, any percentage from 0 through 1 activates IAB. This allows a small number of
packets to activate IAB.
Package Latency
Average packet latency in microseconds.
Flow Rate
The rate at which the system processes flows, measured as the number of flows per second. Note that
this option configures IAB to measure flow rate, not flow count.
Note Inspection performance and flow bypass thresholds are disabled by default. You must enable at least one
of each, and one of each must be exceeded for IAB to trust traffic. If you enable more than one inspection
performance or flow bypass threshold, only one of each must be exceeded for IAB to trust traffic.
Flow Duration
The maximum number of seconds a flow can remain open.
Flow Velocity
The maximum transfer rate in kilobytes per second.
Configuring IAB
Smart License Classic License Supported Devices Supported Domains Access
Any Control Any Any Admin Access
Admin Network
Admin
Caution Not all deployments require IAB, and those that do might use it in a limited fashion. Do not enable IAB
unless you have expert knowledge of your network traffic, especially application traffic, and system
performance, including the causes of predictable performance issues. Before you run IAB in bypass mode,
make sure that trusting the specified traffic does not expose you to risk.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to Intelligent
Application Bypass Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
◦Click All applications including unidentified applications so that, when an inspection performance
threshold is exceeded, IAB trusts all traffic that exceeds any flow bypass threshold, regardless of
the application type.
• Inspection Performance Thresholds—Click Configure and enter at least one threshold value.
• Flow Bypass Thresholds—Click Configure and enter at least one threshold value.
You must specify at least one inspection performance threshold and one flow bypass threshold; both must be
exceeded for IAB to trust traffic. If you enter more than one threshold of each type, only one of each type
must be exceeded. For detailed information, see IAB Options, on page 1292.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Allow -
indicates that the applied IAB configuration was in test mode and traffic for the application
specified by Application Protocol remains available for inspection.
Trust -
indicates that the applied IAB configuration was in bypass mode and traffic for the application
specified by Application Protocol has been trusted to traverse the network without further
inspection.
Reason
Intelligent App Bypass indicates that IAB triggered the event in bypass or test mode.
Application Protocol
This field displays the application protocol that triggered the event.
Example
In the following truncated graphic, some fields are omitted. The graphic shows the Action, Reason, and
Application Protocol fields for two connection events resulting from different IAB settings in two separate
access control policies.
For the first event, the Trust action indicates that IAB was enabled in bypass mode and Bonjour protocol
traffic was trusted to pass without further inspection.
For the second event, the Allow action indicates that IAB was enabled in test mode, so Ubuntu Update Manager
traffic was subject to further inspection but would have been bypassed if IAB had been in bypass mode.
Example
In the following truncated graphic, some fields are omitted. The flow in the second event was both bypassed
(Action: Trust; Reason: Intelligent App Bypass) and inspected by an intrusion rule (Reason: Intrusion
Monitor). The Intrusion Monitor reason indicates that an intrusion rule set to Generate Events detected
but did not block an exploit during the connection. In the example, this happened before the application was
detected. After the application was detected, IAB recognized the application as bypassable and trusted the
flow.
• Field: any
• Aggregate: either of:
◦IAB Bypassed Connections
• Filter: any
Examples
In the following Custom Analysis dashboard widget examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications were
specified as bypassable and IAB was enabled in bypass mode in the deployed access control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been bypassed
because the applications were specified as bypassable and IAB was enabled in test mode in the deployed
access control policy. .
• Preset: None
• Filter: any
• X-Axis: any
• Y-Axis: either of:
◦IAB Bypassed Connections
Examples
The following graphic shows two abbreviated report examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications were
specified as bypassable and IAB was enabled in bypass mode in the deployed access control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been bypassed
because the applications were specified as bypassable and IAB was enabled in test mode in the deployed
access control policy.
You can use two methods to configure the system to enforce these features:
Method: Access Control Rules
Content restriction features communicate the restricted status of a search or content query via an element
in the request URI, an associated cookie, or a custom HTTP header element. You can configure access
control rules to modify these elements as the system processes traffic.
The table below describes the differences between these enforcement methods.
The system logs different values for the Reason field in connection events, depending on the method:
• Access Control Rules—Content Restriction
• DNS Sinkhole—DNS Block
Caution To avoid rule preemption, position rules governing YouTube EDU above rules governing Safe Search in
both SSL and access control policies; see Content Restriction Rule Order, on page 339.
Procedure
Step 1 Create an SSL policy; see Creating Basic SSL Policies, on page 1331.
Step 2 Add SSL rules for handling Safe Search and YouTube EDU traffic:
• Choose Decrypt - Resign as the Action for the rules. The system does not support any other action for
content restriction handling.
• In the Applications tab, add selections to the Selected Applications and Filters list:
◦YouTube EDU—Add the YouTube and YouTube Upload applications.
◦Safe Search—Add the Category: search engine filter.
For more information, see Adding an Application Condition to an SSL Rule, on page 1365.
Step 3 Set rule positions for the SSL rules you added. Click and drag, or use the right-click menu to cut and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.
Step 4 Create or edit an access control policy, and associate the SSL policy with the access control policy.
For more information, see Associating Other Policies with Access Control, on page 1228.
Step 5 In the access control policy, add rules for handling Safe Search and YouTube EDU traffic:
• Choose Allow as the Action for the rules. The system does not allow any other action for content
restriction handling.
• In the Applications tab, click the dimmed icon for either Safe Search ( ) or YouTube EDU ( ), and
set related options; see Safe Search Options for Access Control Rules, on page 1302 and YouTube EDU
Options for Access Control Rules, on page 1302.
These icons are disabled, rather than dimmed, if you choose any Action other than Allow for the rule.
You cannot enable Safe Search and YouTube EDU restrictions for the same access control rule.
• In the Applications tab, refine application selections in the Selected Applications and Filters list.
In most cases, enabling Safe Search or YouTube EDU populates the Selected Applications and Filters
list with the appropriate values. The system does not automatically populate the list if a Safe Search or
YouTube application is already present in the list when you enable the feature. If applications do not
populate as expected, manually add them as follows:
◦YouTube EDU—Add the YouTube and YouTube Upload applications.
◦Safe Search—Add the Category: search engine filter.
For more information, see Configuring Application Conditions and Filters, on page 317.
Step 6 Set rule positions for the access control rules you added. Click and drag, or use the right-click menu to cut
and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.
Step 7 Configure the HTTP response page that the system displays when it blocks restricted content; see Choosing
HTTP Response Pages, on page 1252.
Step 8 Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note If you check Enable YouTube EDU, you must enter a Custom ID. This ID
is defined externally by YouTube. The system does not validate what you enter
against the YouTube system. If you enter an invalid ID, YouTube EDU
restrictions may not perform as expected.
Typically, a DNS sinkhole directs traffic away from a particular target. This procedure describes how to
configure a DNS sinkhole to redirect traffic to the Google SafeSearch Virtual IP Address (VIP), which imposes
content filters on Google and YouTube search results.
Because Google SafeSearch uses a single IPv4 address for the VIP, hosts must use IPv4 addressing.
Caution If your network includes proxy servers, this content restriction method is not effective unless you position
your Firepower Threat Defense devices between the proxy servers and the Internet.
This procedure describes enforcing content restriction for Google searches only. To enforce content restriction
for other search engines, see Using Access Control Rules to Enforce Content Restriction, on page 1300.
Procedure
Step 1 Obtain a list of supported Google domains via the following URL: https://www.google.com/supported_
domains.
Step 2 Create a custom DNS list on your local computer, and add the following entries:
• To enforce Google SafeSearch, add an entry for each supported Google domain.
• To enforce YouTube Restricted Mode, add a "youtube.com" entry.
The custom DNS list must be in text file (.txt) format. Each line of the text file must specify an individual
domain name, stripped of any leading periods. For example, the supported domain ".google.com" must appear
as "google.com".
Step 3 Upload the custom DNS list to the Firepower Management Center; see Uploading New Security Intelligence
Lists to the Firepower Management Center, on page 388.
Step 4 Determine the IPv4 address for the Google SafeSearch VIP. For example, run nslookup on
forcesafesearch.google.com.
Step 5 Create a sinkhole object for the SafeSearch VIP; see Creating Sinkhole Objects, on page 390.
Use the following values for this object:
• IPv4 Address—Enter the SafeSearch VIP address.
• IPv6 Address—Enter the IPv6 loopback address (::1).
• Log Connections to Sinkhole—Click this radio button.
• Type—Choose None.
Step 6 Create a basic DNS policy; see Creating Basic DNS Policies, on page 1265.
Step 7 Add a DNS rule for the sinkhole; see Creating and Editing DNS Rules, on page 1268.
For this rule:
• Check the Enabled check box.
• Choose Sinkhole from the Action drop-down list.
• Choose the sinkhole object you created from the Sinkhole drop-down list.
• Add the custom DNS list you created to the Selected Items list on the DNS tab.
• (Optional) Choose a network in the Networks tab to limit content restriction to specific users. For
example, if you want to limit content restriction to student users, assign students to a different subnet
than faculty, and specify that subnet in this rule.
Step 8 Associate the DNS policy with an access control policy; see Associating Other Policies with Access Control,
on page 1228.
Step 9 Deploy configuration changes; see Deploying Configuration Changes, on page 288.
If the system can decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted
traffic with access control, or decrypts it using one of the following methods:
• Decrypt with a known private key. When an external host initiates an SSL handshake with a server on
your network, the system matches the exchanged server certificate with a server certificate previously
uploaded to the appliance. It then uses the uploaded private key to decrypt the traffic.
• Decrypt by re-signing the server certificate. When a host on your network initiates an SSL handshake
with an external server, the system re-signs the exchanged server certificate with a previously uploaded
certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.
Decrypted traffic is subject to the same traffic handling and analysis as originally unencrypted traffic: network,
reputation, and user-based access control; intrusion detection and prevention; Cisco Advanced Malware
Protection (Cisco AMP); and discovery. If the system does not block the decrypted traffic post-analysis, it
re-encrypts the traffic before passing it to the destination host.
Although the data transmitted in the session is encrypted, the handshake messages are not.
After an SSL handshake completes, the managed device caches encrypted session data, which allows session
resumption without requiring the full handshake. The managed device also caches server certificate data,
which allows faster handshake processing in subsequent sessions.
Networks ClientHello
Ports ClientHello
Users ClientHello
Versions ServerHello
If the ClientHello message does not match a Decrypt - Resign rule, the system does not modify the message.
It then determines whether the message passes access control evaluation (which can include deep inspection).
If the message passes, the system transmits it to the destination server.
If the message matches a Decrypt - Resign rule, the system modifies the ClientHello message as follows:
• Compression methods—Strips the compression_methods element, which specifies the compression
methods the client supports. The Firepower System cannot decrypt compressed sessions. This modification
reduces the Compressed Session type of undecryptable traffic.
• Cipher suites—Strips cipher suites from the cipher_suites element if the Firepower System does not
support them. If the Firepower System does not support any of the specified cipher suites, the system
transmits the original, unmodified element. This modification reduces the Unknown Cipher Suite and
Unsupported Cipher Suite types of undecryptable traffic.
• Session identifiers—Strips any value from the Session Identifier element and the SessionTicket
extension that does not match cached session data. If a ClientHello value matches cached data, an
interrupted session can resume without the client and server performing the full SSL handshake. This
modification increases the chances of session resumption and reduces the Session Not Cached type of
undecryptable traffic.
• Elliptic curves—Strips elliptic curves from the Supported Elliptic Curves extension if the Firepower
System does not support them. If the Firepower System does not support any of the specified elliptic
curves, the managed device removes the extension and strips any related cipher suites from the
cipher_suites element.
• ALPN extensions—Strips any value from the Application-Layer Protocol Negotiation (ALPN) extension
that is unsupported in the Firepower System (for example, the SPDY and HTTP/2 protocols). This
modification only occurs if the message matches an SSL rule associated with content restriction features.
For more information, see About Content Restriction, on page 1299.
• Other Extensions—Strips the Extended Master Secret, Next Protocol Negotiation (NPN), and TLS
Channel IDs extensions.
Note The system performs these ClientHello modifications by default. If your SSL policy is configured correctly,
this default behavior results in more frequent decryption of traffic. To tune the default behavior for your
individual network, contact Support.
After the system modifies the ClientHello message, it determines whether the message passes access control
evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination
server.
Direct communication between the client and server is no longer possible during the SSL handshake, because
after message modification the Message Authentication Codes (MACs) computed by the client and server no
longer match. For all subsequent handshake messages (and for the encrypted session once established), the
managed device acts as a man-in-the-middle (MITM). It creates two SSL sessions, one between client and
managed device, one between managed device and server. As a result, each session contains different
cryptographic session details.
Note The cipher suites that the Firepower System can decrypt are frequently updated and do not correspond
directly to the cipher suites you can use in SSL rule conditions. For the current list of decryptable cipher
suites, contact Support.
Related Topics
Default Handling Options for Undecryptable Traffic, on page 1328
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment, on page 1324
If the messages do not match any SSL rules, the managed device performs the default action for the SSL
policy. For more information, see SSL Policy Default Actions, on page 1328.
If the messages match an SSL rule, the managed device continues as appropriate:
Action: Monitor
The SSL handshake continues to completion. The managed device tracks and logs but does not decrypt
encrypted traffic.
Action: Block or Block with Reset
The managed device blocks the SSL session. If appropriate, it also resets the TCP connection.
While processing the ServerHello and Certificate messages, the managed device caches distinguished names
and certificate data to allow faster handshake processing in both reestablished and subsequent SSL sessions.
Devices configured and deployed with inline, routed, switched, or hybrid interfaces can modify the flow of
traffic. These devices can monitor, block, allow, and decrypt incoming and outgoing traffic.
Devices configured and deployed with passive or inline (tap mode) interfaces cannot affect the flow of traffic.
They can only monitor, allow, and decrypt incoming traffic. Note that passive deployments do not support
decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve Diffie-Hellman
(ECDHE) cipher suites.
SSL inspection requires public key certificates and paired private keys for certain features. You must upload
certificates and paired private keys to the Firepower Management Center to decrypt and control traffic based
on encryption session characteristics.
Decide whether you want to not decrypt, block, monitor, or decrypt the encrypted traffic you match your rules
against. Map these decisions to SSL rule actions, undecryptable traffic actions, and the SSL policy default
action.
To decrypt... Collect...
incoming traffic to a server you control the server’s certificate file and paired private key file
outgoing traffic to an external server a CA certificate file and paired private key file
You can also generate a CA certificate and private key.
After you have collected this information, upload it to the system and configure reusable objects.
Related Topics
Distinguished Name Objects, on page 398
PKI Objects, on page 400
Traffic from an external network goes to LifeIns’s router. The router routes traffic to the Customer Service
department, and mirrors a copy of the traffic to the managed device for inspection.
On the managing Firepower Management Center, a user in the Access Control and SSL Editor custom role
configures SSL inspection to:
• log all encrypted traffic sent to the Customer Service department
• decrypt encrypted traffic sent using the online application form to Customer Service
• not decrypt all other encrypted traffic sent to Customer service, including traffic sent using the online
request form
The user also configures access control to inspect the decrypted application form traffic for fake application
data and log when fake data is detected.
In the following scenarios, the user submits an online form to Customer Service. The user’s browser establishes
a TCP connection with the server, then initiates an SSL handshake. The managed device receives a copy of
this traffic. The client and server complete the SSL handshake, establishing the encrypted session. Based on
handshake and connection details, the system logs the connection and acts upon the copy of the encrypted
traffic.
Note In a passive deployment, if traffic is encrypted with either the DHE or ECDHE cipher suite, you cannot
decrypt it with a known private key.
For traffic with legitimate application form information, the system logs the connection.
In contrast, if the decrypted traffic contains fake application data, the system logs the connection and the fake
data.
LifeIns plans to deploy a device in an inline deployment for the Underwriting department.
Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The managed
device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the managing Firepower
Management Center. LifeIns’s router routes traffic to the destination host.
On the managing Firepower Management Center, a user in the Access Control and SSL Editor custom role
configures an SSL access control rule to:
• log all encrypted traffic sent to the Underwriting department
• block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer
service department
• decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s
junior underwriters to MedRepo’s requests department
• not decrypt encrypted traffic sent from the senior underwriters
The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:
• block decrypted traffic if it contains a spoof attempt, and log the spoof attempt
• block decrypted traffic that contains information not compliant with regulations, and log the improper
information
• allow all other encrypted and decrypted traffic
The system reencrypts allowed decrypted traffic before sending it to the destination host.
You can also cause the system to decrypt and resign the traffic using an SSL access control rule with the
action Decrypt - Resign. If traffic matches the SSL rule, after the system modifies the ClientHello message,
it determines whether the message passes access control evaluation (which can include deep inspection). If
the message passes, the system transmits it to the destination server. For more information, see ClientHello
Message Handling, on page 1308
In the following scenarios, the user submits information online to a remote server. The user’s browser establishes
a TCP connection with the server, then initiates an SSL handshake. The managed device receives this traffic;
based on handshake and connection details, the system logs the connection and acts on the traffic. If the system
blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL
handshake, establishing the encrypted session.
In contrast, any decrypted traffic that is a spoof attempt is dropped. The system logs the connection and the
spoof attempt.
Note When decrypting traffic in an inline deployment by re-signing the server certificate, the device acts as a
man-in-the-middle. It creates two SSL sessions, one between client and managed device, one between
managed device and server. As a result, each session contains different cryptographic session details.
Note Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is
not trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store
or the client trusted certificates store.
In contrast, any decrypted traffic that contains information that does not meet regulatory requirements is
dropped. The system logs the connection and the non-conforming information.
Caution Adding or removing an SSL policy restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on the model of the managed device and how it handles traffic. See Snort®
Restart Traffic Behavior, on page 293 for more information.
The simplest SSL policy, as shown in the following diagram, directs the device where it is deployed to handle
encrypted traffic with a single default action. You can set the default action to block decryptable traffic without
further inspection, or to inspect undecrypted decryptable traffic with access control. The system can then
either allow or block the encrypted traffic. If the device detects undecryptable traffic, it either blocks the traffic
without further inspection or does not decrypt it, inspecting it with access control.
A more complex SSL policy can handle different types of undecryptable traffic with different actions, control
traffic based on whether a certificate authority (CA) issued or trusts the encryption certificate, and use SSL
rules to exert granular control over encrypted traffic logging and handling. These rules can be simple or
complex, matching and inspecting encrypted traffic using multiple criteria.
Related Topics
SSL Rule Conditions, on page 1341
Block with reset block the SSL session without further inspection and reset the TCP connection
Unknown Cipher Suite The system does not recognize the cipher suite. Inherit default Do not decrypt
action Block
Block with reset
Inherit default action
Unsupported Cipher The system does not support decryption based on the detected Inherit default Do not decrypt
Suite cipher suite. action Block
Block with reset
Inherit default action
Session not cached The SSL session has session reuse enabled, the client and server Inherit default Do not decrypt
reestablished the session with the session identifier, and the action Block
system did not cache that session identifier.
Block with reset
Inherit default action
Handshake Errors An error occurred during SSL handshake negotiation. Inherit default Do not decrypt
action Block
Block with reset
Inherit default action
When you first create an SSL policy, logging connections that are handled by the default action is disabled
by default. Because the logging settings for the default action also apply to undecryptable traffic handling,
logging connections handled by the undecryptable traffic actions is disabled by default.
Note that if your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic
by re-signing the server certificate. Because you can still inspect this traffic with access control, it is not
handled by the undecryptable traffic actions. If you want to allow this traffic, configure an SSL rule with the
Do not decrypt action to match the server certificate common name or distinguished name.
Note The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed
device, and the client and server establish a tunneled SSL connection using the CONNECT HTTP method.
The Handshake Errors undecryptable action determines how the system handles this traffic.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
• Edit—Click the edit icon ( ); see Editing an SSL Policy, on page 1332. If a view icon ( ) appears
instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the
configuration.
• Import/Export—See About Configuration Import/Export, on page 171.
• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 298.
To configure an SSL policy, you must give the policy a unique name and specify a default action.
Procedure
What To Do Next
• Configure rules to add to your SSL policy; see Creating and Modifying SSL Rules, on page 1339.
• Set the default handling for undecryptable traffic; see Setting Default Handling for Undecryptable
Traffic, on page 1332.
• Configure logging options for default handling of undecryptable traffic; see Logging Connections with
a Policy Default Action, on page 2242.
• Associate the SSL policy with an access control policy as described in Associating Other Policies with
Access Control, on page 1228.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can set undecryptable traffic actions at the SSL policy level to handle certain types of encrypted traffic
the system cannot decrypt or inspect. When you deploy an SSL policy that does not contain any SSL rules,
the undecryptable traffic actions determine how all undecryptable encrypted traffic on your network is handled.
Depending on the type of undecryptable traffic, you can choose to:
• block the connection
• block the connection, then reset it
• inspect the encrypted traffic with access control
• inherit the default action from the SSL policy
Procedure
Step 1 In the SSL policy editor, click the Undecryptable Actions tab.
Step 2 For each field, choose either the SSL policy's default action or another action you want to take on the type of
undecryptable traffic. See Default Handling Options for Undecryptable Traffic, on page 1328 and SSL Policy
Default Actions, on page 1328 for more information.
Step 3 Click Save to save the policy.
What to Do Next
• Configure default logging for connections handled by the undecryptable traffic actions; see Logging
Connections with a Policy Default Action, on page 2242.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Only one person should edit a policy at a time, using a single browser window. If multiple users save the same
policy, the last saved changes are retained. For your convenience, the system displays information on who (if
anyone) is currently editing each policy. To protect the privacy of your session, a warning appears after 30
minutes of inactivity on the policy editor. After 60 minutes, the system discards your changes.
Procedure
• Paste—If you want to paste a cut or copied rule, right-click a selected rule and choose Paste Above or
Paste Below.
What to Do Next
• If the SSL policy is not already associated with an access control policy, associate it as described in
Associating Other Policies with Access Control, on page 1228.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Creating and Modifying SSL Rules, on page 1339
system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted
before being allowed to the destination. Traffic that does not match the SSL rule continues to the next
rule.
• SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the server
certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic. The
decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted and
unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All
remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the
SSL rule continues to the next rule.
• SSL Policy Default Action handles all traffic that does not match any of the SSL rules. The default
action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for
access control inspection.
a trusted CA object by uploading a CA certificate the trusted CA trusts the server certificate used to encrypt the session, whether:
your organization trusts
• the CA issued the certificate directly
• the CA issued a certificate to an intermediate CA that issued the server
certificate
a distinguished name object containing a certificate the subject or issuer common name, country, organization, or organizational
subject or issuer distinguished name unit on the certificate used to encrypt the session matches the configured
distinguished name
Related Topics
Cipher Suite Lists, on page 397
Distinguished Name Objects, on page 398
PKI Objects, on page 400
State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and
stops generating warnings and errors for that rule.
Position
Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by
ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that
handles that traffic.
Conditions
Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network
or geographical location, VLAN, port, application, requested URL, user, certificate, certificate subject or
issuer, certificate status, cipher suite, or encryption protocol version. The use of conditions can depend on
target device licenses.
Action
A rule’s action determines how the system handles matching traffic. You can monitor, allow, block, or decrypt
encrypted matching traffic. Decrypted and allowed encrypted traffic is subject to further inspection. Note that
the system does not perform inspection on blocked encrypted traffic.
Logging
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record
of traffic that matches a rule. You can log a connection when the system blocks an encrypted session or allows
it to pass without decryption, according to the settings in an SSL policy. You can also force the system to log
connections that it decrypts for further evaluation by access control rules, regardless of how the system later
handles or inspects the traffic. You can log connections to the Firepower Management Center database, as
well as to the system log (syslog) or to an SNMP trap server.
Tip Properly creating and ordering SSL rules is a complex task. If you do not plan your policy carefully, rules
can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that
the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback
system for rules.
Related Topics
Interface Conditions, on page 307
Network Conditions, on page 309
VLAN Conditions, on page 313
Port and ICMP Code Conditions, on page 314
Application Conditions (Application Control), on page 316
URL Conditions (URL Filtering), on page 321
User, Realm, and ISE Attribute Conditions (User Control), on page 327
Rule Performance Guidelines, on page 337
SSL Rules Troubleshooting, on page 1351
Procedure
• Choose a rule Action; see Configuring SSL Rule Actions, on page 1347.
• Configure the rule’s conditions; see SSL Rule Condition Types, on page 1342.
• Specify Logging options; see Logging Decryptable Connections with SSL Rules, on page 2239.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip Proper SSL rule order reduces the resources required to process network traffic, and prevents rule
preemption. Although the rules you create are unique to every organization and deployment, there are a
few general guidelines to follow when ordering rules that can optimize performance while still addressing
your needs.
In addition to ordering rules by number, you can group rules by category. By default the system provides
three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete
the system-provided categories or change their order.
Related Topics
Rule Performance Guidelines, on page 337
Procedure
Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you
want to use.
Step 2 Click Save.
Tip When you save the rule, it is placed last in that
category.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the SSL rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate
rule number.
Step 2 Click Save.
Tip When you save the rule, it is placed where you
specified.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• handling — foremost, the rule action governs whether the system will monitor, trust, block, or decrypt
encrypted traffic that matches the rule’s conditions
• logging — the rule action determines when and how you can log details about matching encrypted traffic.
Your SSL inspection configuration handles, inspects, and logs decrypted traffic:
• The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.
• The policy’s default action handles traffic that does not meet the condition of any non-Monitor SSL rule.
You can log a connection event when the system blocks or trusts an encrypted session. You can also force
the system to log connections that it decrypts for further evaluation by access control rules, regardless of how
the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about
the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events,
however:
• for blocked connections (Block, Block with reset), the system immediately ends the sessions and generates
an event
• for trusted connections (Do not decrypt), the system generates an event when the session ends
Networks by its source or destination IP address, You can explicitly specify IP addresses. The geolocation feature
country, or continent also allows you to control traffic based on its source or destination
country or continent.
VLAN Tags tagged by VLAN The system uses the innermost VLAN tag to identify a packet by
VLAN.
Ports by its source or destination port You can control encrypted traffic based on the TCP port.
Users by the user involved in the session You can control encrypted traffic based on the LDAP user logged
into a host involved in an encrypted, monitored session. You can
control traffic based on individual users or groups retrieved from
a Microsoft Active Directory server.
Applications by the application detected in a session You can control access to individual applications in encrypted
sessions, or filter access according to basic characteristics: type,
risk, business relevance, and categories.
Distinguished by the subject or issuer distinguished name You can control encrypted traffic based on the CA that issued a
Names of the server certificate used to negotiate server certificate, or the server certificate holder.
the encrypted session
Certificates by the server certificate used to negotiate You can control encrypted traffic based on the server certificate
the encrypted session passed to the user’s browser in order to negotiate the encrypted
session.
Certificate Status by properties of the server certificate used You can control encrypted traffic based on a server certificate’s
to negotiate the encrypted session status.
Cipher Suites by the cipher suite used to negotiate the You can control encrypted traffic based on the cipher suite selected
encrypted session by the server to negotiate the encrypted session.
Versions by the version of SSL or TLS used to You can control encrypted traffic based on the version of SSL or
encrypt the session TLS used to encrypt the session.
Related Topics
Network-Based SSL Rule Conditions, on page 1354
User-Based SSL Rule Conditions, on page 1360
Reputation-Based URL Blocking in Encrypted Traffic, on page 1366
Server Certificate-Based SSL Rule Conditions, on page 1368
ClientHello Message Handling, on page 1308
For more information, see Default Handling Options for Undecryptable Traffic, on page 1328
Tip Note that you cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment,
as the device does not directly inspect the traffic. If you create a rule with the Block or Block with reset
action that contains passive or inline (tap mode) interfaces within a security zone condition, the policy
editor displays a warning icon ( ) next to the rule.
Related Topics
About HTTP Response Pages, on page 1251
Similarly, you can associate one Certificate Authority certificate and private key with the Decrypt - Resign
action. If traffic matches this rule, the system re-signs the server certificate with the CA certificate, then acts
as a man-in-the-middle. It creates two SSL sessions, one between client and managed device, one between
managed device and server. Each session contains different cryptographic session details, and allows the
system to decrypt and reencrypt traffic. This action is more suited for outgoing traffic, as you replace the
certificate’s private key with one you control to obtain the session keys.
Re-signing a server certificate involves either replacing the certificate’s public key with a CA certificate public
key, or replacing the entire certificate. Normally, if you replace an entire server certificate, the client browser
warns the certificate is not signed by a trusted authority when establishing the SSL connection. However, if
your client’s browser trusts the CA in the policy, the browser does not warn that the certificate is not trusted.
If the original server certificate is self-signed, the system replaces the entire certificate, and trusts the re-signing
CA, but the user’s browser does not warn that the certificate is self-signed. In this case, replacing only the
server certificate public key causes the client browser does warn that the certficate is self-signed.
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you
associate one CA certificate with a Decrypt - Resign action, you cannot create an SSL rule that decrypts
multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external
certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption
algorithm type. You can optionally replace the self-signed certificate key only and not the entire certificate,
in which case users see a self-signed certificate key notice in the browser.
For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign
rule only if the action references an EC-based CA certificate; you must add EC-based external certificates
and cipher suites to the rule if you want to create certificate and cipher suite rule conditions. Similarly, a
Decrypt - Resign rule that references an RSA-based CA certificate matches only outgoing traffic encrypted
with an RSA algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all
other configured rule conditions match.
Note the following:
• You cannot use the Decrypt - Known Key action in a passive deployment if the cipher suite used to
establish the SSL connection applies either the Diffie-Hellman ephemeral (DHE) or the elliptic curve
Diffie-Hellman ephemeral (ECDHE) key exchange algorithm. If your SSL policy targets a device with
passive or inline (tap mode) interfaces, and contains a Decrypt - Known Key rule with a cipher suite
condition containing either a DHE or an ECDHE cipher suite, the system displays an information icon
( ) next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline
(tap mode) interfaces, the system displays a warning icon ( ).
• You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment because the
device does not directly inspect traffic. If you create a rule with the Decrypt - Resign action that contains
passive or inline (tap mode) interfaces within a security zone, the policy editor displays a warning icon
( ) next to the rule. If your SSL policy targets a device with passive or inline (tap mode) interfaces,
and contains a Decrypt - Resign rule, the system displays an information icon ( ) next to the rule. If
you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the
system displays a warning icon ( ). If you deploy an SSL policy that contains a Decrypt - Resign rule
to a device with passive or inline (tap mode) interfaces, any SSL sessions that match the rule fail.
• If the client does not trust the CA used to re-sign the server certificate, it warns the user that the certificate
should not be trusted. To prevent this, import the CA certificate into the client trusted CA store.
Alternatively, if your organization has a private PKI, you can issue an intermediate CA certificate signed
by the root CA which is automatically trusted by all clients in the organization, then upload that CA
certificate to the device.
• You can add an anonymous cipher suite to the Cipher Suite condition in an SSL rule, but keep in mind:
◦The system automatically strips anonymous cipher suites during ClientHello processing. For the
system to use the rule, you must also configure your SSL rules in an order that prevents ClientHello
processing. For more information, see SSL Rule Order, on page 340.
◦You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule, because the
system cannot decrypt traffic encrypted with an anonymous cipher suite.
• The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed
device, and the client and server establish a tunneled SSL connection using the CONNECT HTTP
method. The Handshake Errors undecryptable action determines how the system handles this traffic.
• The system cannot decrypt traffic in the captive portal authentication connection between a captive
portal user's web browser and the captive portal daemon on the managed device.
• You cannot match on Distinguished Name or Certificate conditions when creating an SSL rule with
a Decrypt - Known Key action. The assumption is that if this rule matches traffic, the certificate, subject
DN, and issuer DN already match the certificate associated with the rule.
• If you create an internal CA object and choose to generate a certificate signing request (CSR), you cannot
use this CA for a Decrypt - Resign action until you upload the signed certificate to the object.
• If you configure a rule with the Decrypt - Resign action, and mismatch signature algorithm type for
one or more external certificate objects or cipher suites, the policy editor displays an information icon
( ) next to the rule. If you mismatch signature algorithm type for all external certificate objects, or all
cipher suites, the policy displays a warning icon ( ) next to the rule, and you cannot deploy the access
control policy associated with the SSL policy.
• If the customer's browser uses certificate pinning to verify a server certificate, you cannot decrypt this
traffic by re-signing the server certificate. To allow this traffic, configure an SSL rule with the Do not
decrypt action to match the server certificate common name or distinguished name.
• If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive
Block with reset, the system blocks the matching connection without interaction and the system does
not display a response page.
• If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the
preprocessor normalizes decrypted traffic, it might drop a packet and replace it with a trimmed packet.
This does not end the SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of
the SSL session.
Related Topics
PKI Objects, on page 400
Procedure
Step 1 In the SSL policy editor, you have the following options:
• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ).
What to Do Next
• Configure rule conditions, as described in Network-Based SSL Rule Conditions, on page 1354, User-Based
SSL Rule Conditions, on page 1360, Reputation-Based SSL Rule Conditions, on page 1361, and Server
Certificate-Based SSL Rule Conditions, on page 1368.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the SSL rule editor, select Decrypt - Resign from the Action list.
Step 2 Select an internal CA certificate object from the list.
Step 3 To replace only the certificate public key instead of the entire certificate, you must check Replace Key Replace
Key Only . Because you're replacing the public key only, users get a self-signed certificate notice in the
browser.
Step 4 Click Add.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the SSL rule editor, select Decrypt - Known Key from the Action drop-down list.
Step 2 Click the Click to select decryption certs field.
Step 3 Select one or more internal certificate objects in the Available Certificates list, then click Add to Rule.
Step 4 Click OK.
Step 5 Click Add.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the SSL policy editor, click the Search Rules prompt, type a search string, then press Enter.
Tip Columns for rules with matching values are highlighted, with differentiated highlighting for the indicated
(first) match.
Step 2 Find the rules you are interested in:
• To navigate between matching rules, click the next-match ( ) or previous-match ( ) icon.
• To refresh the page and clear the search string and any highlighting, click the clear icon ( ).
When you create an SSL rule, it is enabled by default. If you disable a rule, the system does not use it to
evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules
in an SSL policy, disabled rules are grayed out, although you can still modify them. Note that you can also
enable or disable an SSL rule using the rule editor.
Procedure
Step 1 In the SSL policy editor, right-click a rule and choose a rule state.
Step 2 Click Save.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the SSL policy editor, select the rules by clicking in a blank area for each rule.
Step 2 Right-click the rule and select Cut.
Step 3 Right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or
Paste below.
Tip You cannot copy and paste SSL rules between two different SSL policies.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can create custom categories between the Standard Rules and Root Rules categories to further organize
your rules without having to create additional policies. You can rename and delete categories that you add.
You cannot move these categories, but you can move rules into, within, and out of them.
Procedure
Creating overly complex rules and misordering rules can affect performance. For detailed information, see
Rule Performance Guidelines, on page 337.
Related Topics
Rule and Other Policy Warnings, on page 336
Rule Performance Guidelines, on page 337
Note When traffic matches a rule, the device applies the configured rule action to the traffic. When the connection
ends, the device logs the traffic if configured to do so.
Each rule condition allows you to specify one or more properties of traffic you want to match against; these
properties include details of:
• the flow of traffic, including the security zone through which it travels, IP address and port, country of
origin or destination, and origin or destination VLAN
• the user associated with a detected IP address
• the traffic payload, including the application detected in the traffic
• the connection encryption, including the SSL/TLS protocol version and cipher suite and server certificate
used to encrypt the connection
• the category and reputation of the URL specified in the server certificate’s distinguished name
You can combine network-based conditions with each other and with other types of conditions to create an
SSL rule. These SSL rules can be simple or complex, matching and inspecting traffic using multiple conditions.
Related Topics
Firepower System IP Address Conventions, on page 12
• To match encrypted traffic entering the device from an interface in the zone, add that zone to the Source
Zones.
If you add both source and destination zone conditions to a rule, matching traffic must originate from one of
the specified source zones and egress through one of the destination zones.
Note that just as all interfaces in a zone must be of the same type (all inline, all passive, all switched, or all
routed), all zones used in a zone condition for an SSL rule must be of the same type. That is, you cannot write
a single rule that matches encrypted traffic to or from zones of different types.
Warning icons indicate invalid configurations, such as zones that contain no interfaces. For details, hover
your pointer over the icon.
Procedure
Example
As a simple example, when you register a device with an Inline detection mode, the Firepower Management
Center creates two zones: Internal and External, and assigns the first pair of interfaces on the device to those
zones. Hosts connected to the network on the Internal side represent your protected assets.
To extend this scenario, you could deploy additional identically configured devices—managed by the same
Firepower Management Center—to protect similar resources in several different locations. Like the first
device, each of these devices protects the assets in its Internal security zone.
Note You are not required to group all internal (or external) interfaces into a single zone. Choose the grouping
that makes sense for your deployment and security policies.
In this deployment, you may decide that although you want these hosts to have unrestricted access to the
Internet, you nevertheless want to protect them by decrypting and inspecting incoming encrypted traffic.
To accomplish this, configure an SSL rule with a zone condition where the Destination Zone is set to Internal.
This simple SSL rule matches traffic that leaves the device from any interface in the Internal zone.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Interface Objects: Interface Groups and Security Zones, on page 357
Note If you want to write rules to control traffic by geographical location, to ensure you are using up-to-date
geolocation data to filter your traffic, Cisco strongly recommends you regularly update the geolocation
database (GeoDB) on your Firepower Management Center.
You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single
network condition, and you can mix network and geolocation-based configurations:
• To match encrypted traffic from an IP address or geographical location, configure the Source Networks.
• To match encrypted traffic to an IP address or geographical location, configure the Destination Networks.
If you add both source and destination network conditions to a rule, matching encrypted traffic must originate
from one of the specified IP addresses and be destined for one of the destination IP addresses.
When building a network condition, warning icons indicate invalid configurations. For details, hover your
pointer over the icon.
Related Topics
Firepower System IP Address Conventions, on page 12
Procedure
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Source or Add to Destination.
Tip You can also drag and drop selected
objects.
Step 5 Add any source or destination IP addresses or address blocks that you want to specify manually. Click the
Enter an IP address prompt below the Source Networks or Destination Networks list; then type an IP
address or address block and click Add.
Step 6 Save or continue editing the rule.
Example
The following graphic shows the network condition for an SSL rule that blocks encrypted connections
originating from your internal network and attempting to access resources either in the Cayman Islands or an
offshore holding corporation server at 182.16.0.3.
The example manually specifies the offshore holding corporation’s server IP address, and uses a system-provided
Cayman Islands geolocation object to represent Cayman Island IP addresses.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Network Objects, on page 353
Firepower System IP Address Conventions, on page 12
Tip After you create a VLAN tag object, you can use it not only to build SSL rules, but also to represent VLAN
tags in various other places in the system’s web interface. You can create VLAN tag objects either using
the object manager or on-the-fly while you are configuring access control rules.
You can add a maximum of 50 items to the Selected VLAN Tags in a single VLAN tag condition. When
building a VLAN tag condition, warning icons indicate invalid configurations. For details, hover your pointer
over the icon.
Procedure
Step 1 In the SSL rule editor, select the VLAN Tags tab.
Step 2 Find the VLANs you want to add from the Available VLAN Tags, as follows:
• To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon ( )
above the Available VLAN Tags list.
• To search for VLAN tag objects and groups to add, click the Search by name or value prompt above
the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in
the object. The list updates as you type to display matching objects.
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected
objects.
Step 5 Add any VLAN tags that you want to specify manually. Click the Enter a VLAN Tag prompt below the
Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag
from 1 to 4094; use a hyphen to specify a range of VLAN tags.
Step 6 Save or continue editing the rule.
Example
The following graphic shows a VLAN tag condition for an SSL rule that matches encrypted traffic on
public-facing VLANs (represented by a VLAN tag object group), as well as the manually added VLAN 42.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
VLAN Tag Objects, on page 359
You can only configure the Selected Source Ports and Selected Destination Ports lists with TCP ports. Port
objects containing non-TCP ports are greyed out in the Available Ports list.
When building a port condition, warning icons indicate invalid configurations. For example, you can use the
object manager to edit in-use port objects so that the rules that use those object groups become invalid. For
details, hover your pointer over the icon.
Procedure
Step 3 To select a TCP-based port object, click it. To select all TCP-based port objects, right-click and then select
Select All. If the object includes non-TCP-based ports, you cannot add it to your port condition.
Step 4 Click Add to Source or Add to Destination.
Tip You can also drag and drop selected
objects.
Step 5 Enter a Port under the Selected Source Ports or Selected Destination Ports list to manually specify source
or destination ports. You can specify a single port with a value from 0 to 65535.
Step 6 Click Add.
Note The Firepower Management Center will not add a port to a rule condition that results in an invalid
configuration.
Step 7 Save or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Port Objects, on page 355
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note When you filter application traffic using access control rules, you can use application tags as a criterion.
to filter. However, you cannot use application tags to filter encrypted traffic because there is no benefit.
All applications that the system can detect in encrypted traffic are tagged SSL Protocol; applications
without this tag can only be detected in unencrypted or decrypted traffic.
In a single application condition, you can add a maximum of 50 items to the Selected Applications and
Filters list. Each of the following counts as an item:
• One or more filters from the Application Filters list, individually or in custom combination. This item
represents set of applications, grouped by characteristic.
• A filter created by saving search of the applications in the Available Applications list. This item
represents a set of applications, grouped by substring match.
• An individual application from the Available Applications list.
In the web interface, filters added to a condition are listed above and separately from individually added
applications.
Note that when you deploy an SSL policy, for each rule with an application condition, the system generates
a list of unique applications to match. In other words, you may use overlapping filters and individually specified
applications to ensure complete coverage.
The system links multiple filters of the same filter type with an OR operation. For example, if you select the
Medium and High filters under the Risks type, the resulting filter is:
Related Topics
Application Filters, on page 359
• To constrain the applications by applying a filter, use the Application Filters list. The Available
Applications list updates as you apply filters.
Once constrained, an All apps matching the filter option appears at the top of the Available Applications
list.
Note If you select one or more filters in the Application Filters list and also search the Available Applications
list, your selections and the search-filtered Available Applications list are combined using an AND
operation. That is, the All apps matching the filter condition includes all the individual conditions
currently displayed in the Available Applications list as well as the search string entered above the
Available Applications list.
You can add a maximum of 50 items per condition, and filters added to a condition are listed above and
separately from individually added applications. When building an application condition, warning icons
indicate invalid configurations. For details, hover your pointer over the icon.
Procedure
Example
The following graphic shows the application condition for an SSL rule that decrypts a custom group of
applications for MyCompany, all applications with high risk and low business relevance, gaming applications,
and some individually selected applications.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
This identification occurs after the server certificate exchange. If traffic exchanged during the SSL handshake
matches all other conditions in an SSL rule containing an application condition but the identification is not
complete, the SSL policy allows the packet to pass. This behavior allows the handshake to complete so that
applications can be identified. For your convenience, affected rules are marked with an information icon ( ).
After the system completes its identification, the system applies the SSL rule action to the remaining session
traffic that matches its application condition.
Related Topics
Activating and Deactivating Detectors, on page 1909
Tip URL conditions in SSL rules do not support manual URL filtering. Instead, use a distinguished name
condition matching on the subject common name.
Procedure
Step 5 Click Add to Rule to add the selected items to the Selected Categories list.
Tip You can also drag and drop selected
items.
Step 6 Save or continue editing the rule.
Example
The following graphic shows the URL condition for an example access control rule that blocks: all malware
sites, all high-risk sites, and all non-benign social networking sites.
The following table summarizes how you build the condition shown in the graphic above.
social networking sites with Social Network 3 - Benign sites with security risks
a risk greater than benign
(levels 1 through 3)
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
To detect multiple cipher suites in a rule, the certificate issuer, or the certificate holder, you can create reusable
cipher suite list and distinguished name objects and add them to your rule. To detect the server certificate and
certain certificate statuses, you must create external certificate and external CA objects for the rule.
Note You cannot configure a distinguished name condition if you also choose the Decrypt - Known Key action.
Because that action requires you to choose a server certificate to decrypt traffic, the certificate already
matches the traffic.
You can match against multiple subject and issuer distinguished names in a single certificate status rule
condition; only one common or distinguished name needs to match to match the rule.
If you add a distinguished name manually, it can contain the common name attribute (CN). If you add a
common name without CN=, the system prepends CN= before saving the object.
You can also add a distinguished name with one each of the following attributes, separated by commas: C,
CN, O, OU.
In a single DN condition, you can add a maximum of 50 literal values and distinguished name objects to the
Subject DNs, and 50 literal values and distinguished name objects to the Issuer DNs.
The system-provided DN object group, Cisco-Undecryptable-Sites, contains websites whose traffic the system
cannot decrypt. You can add this group to a DN condition to block or not decrypt traffic to or from these
websites, without wasting system resources attempting to decrypt that traffic. You can modify individual
entries in the group. You cannot delete the group. System updates can modify the entries on this list, but the
system preserves user changes.
The first time the system detects an encrypted session to a new server, DN data is not available for ClientHello
processing, which can result in an undecrypted first session. After the initial session, the managed device
caches data from the server Certificate message. For subsequent connections from the same client, the system
can match the ClientHello message conclusively to rules with DN conditions and process the message to
maximize decryption potential.
Procedure
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Subject or Add to Issuer.
Tip You can also drag and drop selected
objects.
Step 5 Add any literal common names or distinguished names that you want to specify manually. Click the Enter
DN or CN prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished
name and click Add.
Step 6 Add or continue editing the rule.
Example
The following graphic illustrates a distinguished name rule condition searching for certificates issued to
goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these certificates is
allowed, subject to access control.
Example
The following graphic illustrates a distinguished name rule condition searching for certificates issued to
badbakery.example.com and associated domains, or certificates issued by badca.example.com. Traffic encrypted
with these certificates is decrypted using a re-signed certificate.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Distinguished Name Objects, on page 398
You can choose to match against multiple certificates in a single certificate rule condition; if the certificate
used to encrypt the traffic matches any of the uploaded certificates, the encrypted traffic matches the rule.
You can add a maximum of 50 external certificate objects and external certificate object groups to the Selected
Certificates in a single certificate condition.
Note the following:
• You cannot configure a certificate condition if you also select the Decrypt - Known Key action. Because
that action requires you to select a server certificate to decrypt traffic, the implication is that the certificate
already matches the traffic.
• If you configure a certificate condition with an external certificate object, any cipher suites you add to
a cipher suite condition, or internal CA objects you associate with the Decrypt - Resign action, must
match the external certificate’s signature algorithm type. For example, if your rule’s certificate condition
references an EC-based server certificate, any cipher suites you add, or CA certificates you associate
with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types
in this case, the policy editor displays a warning icon next to the rule.
• The first time the system detects an encrypted session to a new server, certificate data is not available
for ClientHello processing, which can result in an undecrypted first session. After the initial session, the
managed device caches data from the server Certificate message. For subsequent connections from the
same client, the system can match the ClientHello message conclusively to rules with certificate conditions
and process the message to maximize decryption potential.
Procedure
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected
objects.
Step 5 Add or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
External Certificate Objects, on page 408
Self-signed The detected server certificate contains the The detected server certificate contains
same subject and issuer distinguished name. different subject and issuer distinguished
names.
Valid All of the following are true: At least one of the following is true:
• The policy trusts the CA that issued • The policy does not trust the CA that
the certificate issued the certificate
• The signature is valid • The signature is invalid
• The issuer is valid • The issuer is invalid
• None of the policy’s trusted CAs • A trusted CA in the policy revoked
revoked the certificate. the certificate
• The current date is between the • The current date is before the
certificate Valid From and Valid To certificate Valid From date
date
• The current date is after the certificate
Valid To date
Invalid signature The certificate’s signature cannot be The certificate’s signature is properly
properly validated against the certificate’s validated against the certificate’s content.
content.
Invalid issuer The issuer CA certificate is not stored in The issuer CA certificate is stored in the
the policy’s list of trusted CA certificates. policy’s list of trusted CA certificates.
Expired The current date is after the certificate Valid The current date is before or on the
To date. certificate Valid To date.
Not yet valid The current date is before the certificate The current date is after or on the certificate
Valid From date. Valid From date.
Server mismatch The server name does not match the server's The server name matches the SNI name of
Server Name Indication (SNI) name, which the server to which the client is requesting
could indicate an attempt to spoof the server access.
name.
Note that even though a certificate might match more than one status, the rule causes an action to be taken on
the traffic only once.
Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates
and associated CRLs as objects. You then add these trusted CA objects to an SSL policy’s list of trusted CA
certificates.
The first time the system detects an encrypted session to a new server, certificate status is not available for
ClientHello processing, which can result in an undecrypted first session. After the initial session, the managed
device caches data from the server Certificate message. For subsequent connections from the same client, the
system can match the ClientHello message conclusively to rules with certificate status conditions and process
the message to maximize decryption potential.
You can trust CAs by adding root and intermediate CA certificates to your SSL policy, then use these trusted
CAs to verify server certificates used to encrypt traffic.
If a trusted CA certificate contains an uploaded certificate revocation list (CRL), you can also verify whether
a trusted CA revoked the encryption certificate.
Procedure
Step 1 In the SSL rule editor, select the Trusted CA Certificates tab.
Step 2 Find the trusted CAs you want to add from the Available Trusted CAs, as follows:
• To add a trusted CA object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Trusted CAs list.
• To search for trusted CA objects and groups to add, click the Search by name or value prompt above
the Available Trusted CAs list, then type either the name of the object, or a value in the object. The
list updates as you type to display matching objects.
Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected
objects.
Step 5 Add or continue editing the rule.
What to Do Next
• Add a certificate status SSL rule condition to your SSL rule. See Matching Traffic on Certificate Status,
on page 1375 for more information.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Trusted Certificate Authority Objects, on page 406
Tip Upload all certificates within a root CA’s chain of trust to the list of trusted CA certificates, including the
root CA certificate and all intermediate CA certificates. Otherwise, it is more difficult to detect trusted
certificates issued by intermediate CAs. Also, if you configure certificate status conditions to trust traffic
based on the root issuer CA, all traffic within a trusted CA’s chain of trust can be allowed without
decryption, rather than unnecessarily decrypting it.
When you create an SSL policy, the system populates the Trusted CA Certificates tab with a default Trusted
CA object group, Cisco Trusted Authorities.
You can modify individual entries in the group, and choose whether to include this group in your SSL policy.
You cannot delete the group. System updates can modify the entries on this list, but user changes are preserved.
Procedure
Step 1 In the Firepower Management Center, choose Policies > Access Control > SSL.
Step 2 Add a new policy or edit an existing policy.
Step 3 Add a new SSL rule or edit an existing rule.
Step 4 In the Add Rule or Editing Rule dialog box, choose the Cert Status tab.
Step 5 For each certificate status, you have the following options:
• Choose Yes to match against the presence of that certificate status.
• Choose No to match against the absence of that certificate status.
• Choose Any to skip the condition when matching the rule. In other words, choosing Any means the rule
matches whether the certificate status is present or absent.
Example
The organization trusts the Verified Authority certificate authority. The organization does not trust the Spammer
Authority certificate authority. The system administrator uploads the Verified Authority certificate and an
intermediate CA certificate issued by Verified Authority to the system. Because Verified Authority revoked
a certificate it previously issued, the system administrator uploads the CRL that Verified Authority provided.
The following graphic illustrates a certificate status rule condition checking for valid certificates, those issued
by a Verified Authority, are not on the CRL, and still within the Valid From and Valid To date. Because of
the configuration, traffic encrypted with these certificates is not decrypted and inspected with access control.
The following graphic illustrates a certificate status rule condition checking for the absence of a status. In this
case, because of the configuration, it matches against traffic encrypted with a certificate that has not expired
and monitors that traffic.
The following graphic illustrates a certificate status rule condition that matches on the presence or absence
of several statuses. Because of the configuration, if the rule matches incoming traffic encrypted with a certificate
issued by an invalid user, self-signed, invalid, or expired, it decrypts the traffic with a known key.
The following graphic illustrates a certificate status rule condition that matches if the SNI of the request
matches the server name or if the CRL is not valid. Because of the configuration, if the rule matches either
condition, traffic is blocked.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note You cannot add new cipher suites. You can neither modify nor delete predefined cipher suites.
You can add a maximum of 50 cipher suites and cipher suite lists to the Selected Cipher Suites in a single
cipher suite condition. The system supports adding the following cipher suites to a cipher suite condition:
• SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_FIPS_WITH_DES_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_DES_CBC_SHA
• TLS_DH_Anon_WITH_AES_128_GCM_SHA256
• TLS_DH_Anon_WITH_AES_256_GCM_SHA384
• TLS_DH_Anon_WITH_CAMELLIA_128_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DH_Anon_WITH_CAMELLIA_256_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_NULL_SHA
• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_NULL_SHA
• TLS_ECDHE_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
match the cipher suite’s signature algorithm type. For example, if your rule’s cipher suite condition
references an EC-based cipher suite, any server certificates you add, or CA certificates you associate
with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types
in this case, the policy editor displays a warning icon next to the rule.
• You can add an anonymous cipher suite to the Cipher Suite condition in an SSL rule, but keep in mind:
◦The system automatically strips anonymous cipher suites during ClientHello processing. For the
system to use the rule, you must also configure your SSL rules in an order that prevents ClientHello
processing. For more information, see SSL Rule Order, on page 340.
◦You cannot use either the Decrypt - Resign or Decrypt - Known Key action in the rule, because
the system cannot decrypt traffic encrypted with an anonymous cipher suite.
• When specifying a cipher suite as a rule condition, consider that the rule matches on the negotiated
cipher suite in the ServerHello message, rather than on the full list of cipher suites specified in the
ClientHello message. During ClientHello processing, the managed device strips unsupported cipher
suites from the ClientHello message. However, if this results in all specified cipher suites being stripped,
the system retains the original list. If the system retains unsupported cipher suites, subsequent evaluation
results in an undecrypted session.
Procedure
Step 1 In the SSL rule editor, select the Cipher Suite tab.
Step 2 Find the cipher suites you want to add from the Available Cipher Suites, as follows;
• To add a cipher suite list on the fly, which you can then add to the condition, click the add icon ( )
above the Available Cipher Suites list.
• To search for cipher suites and lists to add, click the Search by name or value prompt above the
Available Cipher Suites list, then type either the name of the cipher suite, or a value in the cipher suite.
The list updates as you type to display matching cipher suites.
Step 3 To select a cipher suite, click it. To select all cipher suites, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected cipher
suites.
Step 5 Add or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Cipher Suite Lists, on page 397
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note File events generated by inspecting NetBIOS-ssn (SMB) traffic do not immediately generate connection
events because the client and server establish a persistent connection. The system generates connection
events after the client or server ends the session.
To further target your analysis, you can use a malware file’s network file trajectory page to track the spread
of an individual threat across hosts over time, allowing you to concentrate outbreak control and prevention
efforts where most useful.
Tip If your organization uses AMP for Endpoints, the system can import and display endpoint-based data
alongside any data gathered by AMP for Firepower. Importing this data does not require a license.
If your organization requires additional security or wants to limit outside connections, you can use a Cisco
AMP Private Cloud Virtual Appliance (AMPv). AMPv privately collects AMP for Endpoints events and
forwards them to the Firepower Management Center.
File Analysis
The system applies several methods of file inspection and analysis to determine whether a file contains
malware.
Note Based on your configuration, you can either inspect a file the first time the system detects it, and wait for
a cloud lookup result, or pass the file on this first detection without waiting for the cloud lookup result.
Based on whether you enable the option in a file rule, the system inspects files in the following order:
Spero Analysis
If the file is an eligible executable file, the device can analyze the file's structure and submit the resulting
Spero signature to the AMP Threat Grid cloud. The cloud uses this signature to determine if the file
contains malware.
Dynamic Analysis
If the device preclassifies files as possible malware, it submits these files to the AMP Threat Grid cloud
or an AMP Threat Grid on-premises appliance for dynamic analysis, regardless of whether the device
stores the file.
The AMP Threat Grid cloud or on-premises AMP Threat Grid appliance runs the file in a sandbox
environment to determine whether the file is malicious, and returns a threat score that describes the
likelihood a file contains malware. From the threat score, you can view a dynamic analysis summary
report that details why the cloud assigned the threat score.
Archive Files
The system can inspect up to three levels of nested files beneath the outermost archive file (level 0) if the file
is an archive (such as .zip or .rar archive files). If any individual file matches a file rule with a block action,
the system blocks the entire archive, not just the individual file. The system can also block archives that exceed
a specified level of nesting, or whose contents are encrypted or otherwise cannot be inspected.
File Tracking
If a file has a disposition in the AMP cloud that you know to be incorrect, you can add the file’s SHA-256
value to a file list:
• To treat a file as if the AMP cloud assigned a clean disposition, add the file to the clean list.
• To treat a file as if the AMP cloud assigned a malware disposition, add the file to the custom detection
list.
On subsequent detection, the device either allows or blocks the file without reevaluating the file's disposition.
You can use the clean list or custom detection list per file policy.
Note You must configure a rule in the file policy to either perform a malware cloud lookup or block malware
on matching files to calculate a file's SHA-256 value.
Related Topics
File Lists, on page 391
Malware Dispositions
The system determines file dispositions based on the disposition returned by the AMP cloud. To improve
performance, if the system already knows the disposition for a file based on its SHA-256 value, the Firepower
Management Center uses the cached disposition rather than querying the AMP cloud. Based on its disposition,
the system can block the file. If any nested file inside an archive file is blocked, the system blocks the entire
archive file.
A file can have one of the following file dispositions as a result of addition to a file list, or due to threat score:
• Malware indicates that the AMP cloud categorized the file as malware, local malware analysis identified
malware, or the file’s threat score exceeded the malware threshold defined in the file policy.
• Clean indicates that the AMP cloud categorized the file as clean, or that a user added the file to the clean
list.
• Unknown indicates that the system queried the AMP cloud, but the file has not been assigned a disposition;
in other words, the AMP cloud has not categorized the file.
• Custom Detection indicates that a user added the file to the custom detection list.
• Unavailable indicates that the system could not query the AMP cloud. You may see a small percentage
of events with this disposition; this is expected behavior.
Archive files have dispositions based on the dispositions assigned to the files inside the archive. All archives
that contain identified malware files receive a disposition of Malware. Archives without identified malware
files receive a disposition of Unknown if they contain any unknown files, and a disposition of Clean if they
contain only clean files.
Archive File Disposition Number of Unknown Files Number of Clean Files Number of Malware Files
Unknown 1 or more Any 0
Clean 0 1 or more 0
Archive files, like other files, may have dispositions of Custom Detection or Unavailable if the conditions
for those dispositions apply.
Tip If you see several Unavailable malware events in quick succession, make sure the Firepower Management
Center can contact the AMP cloud.
Note that file dispositions can change. For example, the AMP cloud can determine that a file that was previously
thought to be clean is now identified as malware, or the reverse—that a malware-identified file is actually
clean. When the disposition changes for a file you queried in the last week, the AMP cloud notifies the system
so it can automatically take action the next time it detects that file being transmitted. A changed disposition
is called a retrospective disposition.
Dispositions returned from an AMP cloud query, associated threat scores, and dispositions assigned by local
malware analysis, have a time-to-live (TTL) value. After a disposition has been held for the duration specified
in the TTL value without update, the system purges the cached information. Dispositions and associated threat
scores have the following TTL values:
• Clean — 4 hours
• Unknown — 1 hour
• Malware — 1 hour
If a query against the cache identifies a cached disposition that timed out, the system re-queries the AMP
cloud for a new disposition.
If your organization uses AMP for Endpoints, individual users install lightweight connectors on endpoints:
computers and mobile devices. Connectors can inspect files upon upload, download, execution, open, copy,
move, and so on. These connectors communicate with the AMP cloud to determine if inspected files contain
malware.
When a file is positively identified as malware, the AMP cloud sends the threat identification to the Firepower
Management Center. The AMP cloud can also send other kinds of information to the Firepower Management
Center, including data on scans, quarantines, blocked executions, and cloud recalls. The Firepower Management
Center logs this information as malware events.
AMP for Endpoints can generate indications of compromise (IOC) when a host’s security may be compromised.
The Firepower System can display this IOC information for its monitored hosts. Cisco occasionally develops
new IOC types for endpoint-based malware events, which the system automatically downloads.
With AMP for Endpoints, you can not only configure Management Center-initiated remediations and alerts
based on malware events, but you can also use the AMP for Endpoints management console help you mitigate
the effect of malware. The management console provides a robust, flexible web interface where you control
all aspects of your AMP for Endpoints deployment and manage all phases of an outbreak. You can:
• configure custom malware detection policies and profiles for your entire organization, as well as perform
flash and full scans on all your users’ files
• perform malware analysis, including view heat maps, detailed file information, network file trajectory,
and threat root causes
• configure multiple aspects of outbreak control, including automatic quarantines, application blocking
to stop non-quarantined executables from running, and exclusion lists
• create custom protections, block execution of certain applications based on group policy, and create
custom whitelists
Tip For detailed information on AMP for Endpoints, see the AMP for Endpoints management
console.
Note Depending on your deployment, endpoints monitored by AMP for Endpoints may not be the same hosts
as those monitored by AMP for Firepower. For this reason, endpoint-based malware events do not add
hosts to the network map. However, the system uses IP and MAC address data to tag monitored hosts
with indications of compromise obtained from your AMP for Endpoints deployment. If two different hosts
monitored by different AMP solutions have the same IP and MAC address, the system can incorrectly tag
monitored hosts with AMP for Endpoints IOCs.
The following table summarizes the differences between the two strategies.
malware detection and in network traffic, using access control and file on individual endpoints, using a connector that
blocking method policies communicates with the AMP cloud
network traffic inspected traffic passing through a managed device none; connectors installed on endpoints directly
inspect files
malware analysis choices Management Center-based, plus analysis in the Management Center-based, plus additional options
AMP cloud on the AMP for Endpoints management console
malware mitigation malware blocking in network traffic, Management AMP for Endpoints-based quarantine and outbreak
Center-initiated remediations control options, Management Center-initiated
remediations
events generated file events, captured files, malware events, and malware events
retrospective malware events
information in malware basic malware event information, plus connection in-depth malware event information; no
events data (IP address, port, and application protocol) connection data
network file trajectory Management Center-based Management Center-based, plus additional options
on the AMP for Endpoints management console
required licenses or licenses required to perform file control and AMP AMP for Endpoints subscription (not
subscriptions for Firepower license-based)
File Policies
A file policy is a set of configurations that the system uses to perform AMP for Firepower and file control,
as part of your overall access control configuration. This association ensures that before the system passes a
file in traffic that matches an access control rule’s conditions, it first inspects the file. Consider the following
diagram of a simple access control policy in an inline deployment.
The policy has two access control rules, both of which use the Allow action and are associated with file
policies. The policy’s default action is also to allow traffic, but without file policy inspection. In this scenario,
traffic is handled as follows:
• Traffic that matches Rule 1 is inspected by File Policy A.
• Traffic that does not match Rule 1 is evaluated against Rule 2. Traffic that matches Rule 2 is inspected
by File Policy B.
• Traffic that does not match either rule is allowed; you cannot associate a file policy with the default
action.
You can associate a single file policy with an access control rule whose action is Allow, Interactive Block,
or Interactive Block with reset. The system then uses that file policy to inspect network traffic that meets
the conditions of the access control rule.
By associating different file policies with different access control rules, you have granular control over how
you identify and block files transmitted on your network. Note, however, that you cannot use a file policy to
inspect traffic handled by the access control default action.
Although the system can only inspect up to 3 levels of nested archive files, you can configure your file policy
to block archive files that exceed that depth (or a lower maximum depth that you specify). If you want to
restrict nested archives further, you have the option to configure a lower maximum file depth of 2 or 1.
If you choose not to block files that exceed the maximum archive file depth of 3, when archive files that
contain some extractable contents and some contents nested at a depth of 3 or greater appear in monitored
traffic, the system examines and reports data only for the files it was able to inspect.
Note If traffic that contains an archive file is blacklisted or whitelisted by Security Intelligence, or if the top-level
archive file’s SHA-256 value is on the custom detection list, the system does not inspect the contents of
the archive file. If a nested file is blacklisted, the entire archive is blocked; however, if a nested file is
whitelisted, the archive is not automatically passed (depending on any other nested files and characteristics).
If your file policy is configured to inspect archive file contents, you can use the event viewer context menu
and the network file trajectory viewer to view information about the files inside an archive when the archive
file appears in a file event, malware event, or as a captured file.
All file contents of the archive are listed in table form, with a short summary of their relevant information:
name, SHA-256 hash value, type, category, and archive depth. A network file trajectory icon appears by each
file, which you can click to view further information about that specific file.
The File Policies page displays a list of existing file policies along with their last-modified dates. You can
use this page to manage your file policies.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Note The system checks the AMP cloud for updates to the list of file types eligible for dynamic analysis (no
more than once a day). If the list of eligible file types changes, this constitutes a change in the file policy;
any access control policy using the file policy is marked out-of-date if deployed to any devices. You must
deploy policies before the updated file policy can take effect on the device.
Procedure
Step 1 Select Policies > Access Control > Malware & File .
Step 2 Manage your file policies:
• Compare—Click Compare Policies; see Comparing Policies, on page 297.
• Create — To create a file policy, click New File Policy and proceed as described in Creating a File
Policy, on page 1392.
• Copy — To copy a file policy, click the copy icon ( ).
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
• Delete — If you want to delete a file policy, click the delete icon ( ), then click Yes and OK as
prompted.
If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission
to modify the configuration.
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
• Edit — If you want to modify an existing file policy, click the edit icon ( ).
• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 298.
Procedure
Step 1 Select Policies > Access Control > Malware & File .
Tip
To make a copy of an existing file policy, click the copy icon ( ), then type a unique name for the
new policy in the dialog box that appears. You can then modify the copy.
Step 2 Click New File Policy.
Step 3 Enter a Name and optional Description for your new policy.
Step 4 Click Save.
Step 5 Add one or more rules to the file policy as described in Creating File Rules, on page 1398.
Step 6 Optionally, select the Advanced tab and configure advanced options as described in Advanced and Archive
File Inspection Options, on page 1393.
Step 7 Save the file policy.
What to Do Next
• Add the file policy to an access control rule as described in Access Control Rule Configuration to Perform
File Control and Malware Protection, on page 1246.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
The Advanced tab in the file policy editor has the following archive file inspection options:
• Inspect Archives - allows you to inspect the contents of archive files
• Block Encrypted Archives - allows you to block archive files that have encrypted contents
• Block Uninspectable Archives - allows you to block archive files with contents that the system is unable
to inspect for reasons other than encryption; this usually applies to corrupted files, or those that exceed
your specified maximum archive depth
• Max Archive Depth - allows you to block nested archive files that exceed the specified depth; the
top-level archive file is not considered in this count; depth begins at 1 with the first nested file
Related Topics
Snort® Restart Scenarios , on page 292
Procedure
Step 1 Select Policies > Access Control > Malware & File .
Step 2 Click the edit icon ( ) next to the file policy you want to edit. If a view icon ( ) appears instead, the
configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
Step 3 You have the following options:
• Add a file rule by selecting Add File Rule. For more information, see File Rules, on page 1394.
• Edit an existing file rule by clicking the edit icon ( ) next to the rule you want to edit.
• Configure advanced options as described in Advanced and Archive File Inspection Options, on page
1393.
Note The file policy editor displays how many access control policies use the file policy you are currently
editing. You can click the notification to display a list of the parent policies and, optionally, continue
to the Access Control Policies page.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
File Rules
A file policy, like its parent access control policy, contains rules that determine how the system handles files
that match the conditions of each rule. You can configure separate file rules to take different actions for
different file types, application protocols, or directions of transfer.
Once a file matches a rule, the rule can:
• allow or block files based on simple file type matching
• block files based on disposition
direction of transfer You can inspect incoming FTP, HTTP, IMAP, POP3, and NetBIOS-ssn (SMB) traffic for
downloaded files; you can inspect outgoing FTP, HTTP, SMTP, and NetBIOS-ssn (SMB) traffic
for uploaded files.
Tip Use Any to detect files over multiple application protocols, regardless of whether users
are sending or receiving.
file categories and types The system can detect various types of files. These file types are grouped into basic categories,
including multimedia (swf, mp3), executables (exe, torrent), and PDFs. You can configure file
rules that detect individual file types, or on entire categories of file types.
For example, you could block all multimedia files, or just ShockWave Flash (swf) files. Or, you
could configure the system to alert you when a user downloads a BitTorrent (torrent) file.
Note Frequently triggered file rules can affect system performance. For example, detecting
multimedia files in HTTP traffic (YouTube, for example, transmits significant Flash
content) could generate an overwhelming number of events.
file rule action A file rule’s action determines how the system handles traffic that matches the conditions of the
rule.
Depending on the selected action, you can configure whether the system stores the file or performs
Spero, local malware, or dynamic analysis on a file. If you select a Block action, you can also
configure whether the system also resets the blocked connection.
Note File rules are evaluated in rule-action, not numerical,
order.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the
last file rule that combines the Malware Cloud Lookup or Block Malware file rule action with an analysis
option (Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files
option (Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration
changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes
without further inspection depends on the model of the managed device and how it handles traffic. See
Snort® Restart Traffic Behavior, on page 293 for more information.
Depending on the file rule action, you can configure options to reset the connection when a file transfer is
blocked, store captured files to the managed device, locally analyze files for malware, submit captured files
to the AMP cloud for dynamic and Spero analysis, and store files that cannot be currently submitted to the
cloud for later submission.
File Rule Action Block Files Block Malware Detect Files Malware Cloud
Option capable? capable? capable? Lookup capable?
Spero Analysis for no yes, you can submit no yes, you can submit
MSEXE executable files executable files
Dynamic Analysis no yes, you can submit no yes, you can submit
executable files with executable files with
Unknown file Unknown file
dispositions dispositions
File Rule Action Block Files Block Malware Detect Files Malware Cloud
Option capable? capable? capable? Lookup capable?
Capacity Handling no yes no yes
Store files yes, you can store yes, you can store yes, you can store yes, you can store
all matching file file types matching all matching file file types matching
types the file dispositions types the file dispositions
you select you select
• If the total number of bytes for all file names for files in a POP3, POP, SMTP, or IMAP session exceeds
1024, file events from the session may not reflect the correct file names for files that were detected after
the file name buffer filled.
• When transmitting text-based files over SMTP, some mail clients convert newlines to the CRLF newline
character standard. Since Mac-based hosts use the carriage return (CR) character and Unix/Linux-based
hosts use the line feed (LF) character, newline conversion by the mail client can modify the size of the
file. Note that some mail clients default to newline conversion when processing an unrecognizable file
type.
Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the
last file rule that combines the Malware Cloud Lookup or Block Maware file rule action with an analyis
option (Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files
option (Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration
changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes
without further inspection depends on the model of the managed device and how it handles traffic. See
Snort® Restart Traffic Behavior, on page 293 for more information.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Snort® Restart Scenarios , on page 292
Cloud Connections
The Firepower System provides connections to the following public cloud-based servers to help you perform
Cisco Advanced Malware Protection (AMP):
• AMP cloud—allows you to retrieve AMP for Firepower malware dispositions and updates, and AMP
for Endpoints scan records, malware detections, quarantines, and indications of compromise (IOC)
• AMP Threat Grid cloud—allows you to submit eligible files for AMP for Firepower dynamic analysis,
and retrieve threat scores and dynamic analysis reports
Depending on your organization's privacy or security needs, you can also deploy private cloud servers:
• An AMP Private Cloud Virtual Appliance (AMPv) acts as a compressed, on-premises AMP cloud, as
well as an anonymized proxy to connect to the public AMP cloud.
• An AMP Threat Grid appliance acts as an on-premises AMP Threat Grid cloud that does not contact
the public AMP Threat Grid cloud.
Depending on your deployment, endpoints monitored by AMP for Endpoints may not be the same hosts as
those monitored by AMP for Firepower. For this reason, endpoint-based malware events do not add hosts to
the network map. However, the system uses IP and MAC address data to tag monitored hosts with indications
of compromise obtained from your AMP for Endpoints deployment. If two different hosts monitored by
different AMP solutions have the same IP and MAC address, the system can incorrectly tag monitored hosts
with AMP for Endpoints IOCs.
Use the AMP Management page (AMP > AMP Management) to manage connections to the AMP cloud.
By default, a connection to the United States (US) AMP public cloud is configured and enabled for AMP for
Firepower. You cannot delete or disable an AMP for Firepower cloud connection, but you can switch between
the European Union (EU) and United States (US) AMP clouds, or configure a private cloud (AMPv) connection.
To add a separate FireAMP connection for endpoints, you must have an account in the FireAMP portal. An
AMP for Endpoints connection that has not registered successfully to the portal does not disable AMP for
Firepower.
To use the legacy port for AMP communications, see Collective Security Intelligence Communications
Configuration Options, on page 1409.
Caution Cisco strongly recommends you configure AMP for Endpoints connections at the leaf level only, especially
if your leaf domains have overlapping IP space. If multiple subdomains have hosts with the same IP-MAC
address pair, the system could save endpoint-based malware events to the wrong leaf domain, or associate
IOCs with the wrong hosts.
If your organization has deployed AMP for Endpoints, you can import threat identifications, indications of
compromise (IOC), and other malware-related information from the AMP cloud to the system. You must
configure an AMP for Endpoints connection even if you already have a AMP for Firepower connection
configured.
Caution In a multidomain deployment, Cisco strongly recommends you configure AMP for Endpoints connections
at the leaf level only, especially if your leaf domains have overlapping IP space. If multiple subdomains
have hosts with the same IP-MAC address pair, the system could save endpoint-based malware events to
the wrong leaf domain, or associate IOCs with the wrong hosts.
Procedure
Step 4 Check the Use for AMP for Firepower check box if you want to use this cloud for AMP for Firepower and
AMP for Endpoints.
In a multidomain deployment, this check box appears only in the Global domain. Each Firepower Management
Center can have only one AMP for Firepower connection.
Step 6 Confirm that you want to continue to the AMP for Endpoints management console, then log into the
management console.
Step 7 Using the management console, authorize the AMP cloud to send AMP for Endpoints data to the Firepower
Management Center.
Step 8 If you want to restrict the data you receive, select specific groups within your organization for which you
want to receive information.
By default, the AMP cloud sends data for all groups. To manage groups, choose Management > Groups on
the AMP for Endpoints management console. For detailed information, see the management console online
help.
Step 9 Click Allow to enable the connection and start the transfer of data.
Clicking Deny returns you to the Firepower Management Center, where the connection is marked as denied.
If you navigate away from the Applications page on the AMP for Endpoints management console, and neither
deny nor allow the connection, the connection is marked as pending on the Firepower Management Center’s
web interface. The health monitor does not alert you of a failed connection in either of these situations. If you
want to connect to the AMP cloud later, delete the failed or pending connection, then recreate it.
Incomplete registration of an AMP for Endpoints connection does not disable the AMP for Firepower
connection.
What to Do Next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
Note Dynamic analysis, a component of AMP for Firepower, requires that managed devices have direct or
proxied access to the AMP Threat Grid cloud or an on-premises AMP Threat Grid appliance on port 443.
AMPv does not support dynamic analysis, nor does AMPv support anonymized retrieval of threat
intelligence for other features that rely on Cisco Collective Security Intelligence (CSI), such as URL and
Security Intelligence filtering.
Connecting to AMPv
Smart License Classic License Supported Devices Supported Domains Access
Malware (AMP for Malware (AMP for Any Any Admin
Firepower) Firepower)
Any (AMP for Any (AMP for
Endpoints) Endpoints)
Procedure
Step 5 In the Host field, enter the private cloud host name that you configured when you set up AMPv.
Step 6 Click Browse next to the Certificate Upload Path field to browse to the location of a valid TLS or SSL
encryption certificate for AMPv. For more information, see the AMPv documentation.
Step 7 Check the Use for AMP for Firepower check box if you want to use this private cloud for AMP for Firepower
and AMP for Endpoints.
If you configured a different private cloud to handle AMP for Firepower communications, you can clear this
check box; if this is your only AMPv connection, you cannot.
In a multidomain deployment, this check box appears only in the Global domain. Each Firepower Management
Center can have only one AMP for Firepower connection.
Step 8 To communicate with AMPv using a proxy, check the Use Proxy for Connection check box.
Step 9 Click Register, confirm that you want to disable existing direct connections to the AMP cloud, and finally
confirm that you want to continue to the AMPv management console to complete registration.
Step 10 Log into the management console and complete the registration process. For further instructions, see the
AMPv documentation.
What to Do Next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
Use the Firepower Management Center to delete an AMP cloud or AMPv connection if you no longer want
to receive malware-related information from the cloud. Note that deregistering a connection using the AMP
for Endpoints or AMPv management console does not remove the connection from the system. Deregistered
connections display a failed state on the Firepower Management Center web interface.
You can also temporarily disable a connection. When you reenable a cloud connection, the cloud resumes
sending data to the system, including queued data from the disabled period.
Caution For disabled connections, the AMP cloud and AMPv can store malware events, indications of compromise,
and so on until you re-enable the connection. In rare cases—for example, with a very high event rate or
a long-term disabled connection—the cloud may not be able to store all information generated while the
connection is disabled.
In a multidomain deployment, the system displays connections created in the current domain, which you can
manage. It also displays connections created in ancestor domains, which you cannot manage. To manage
connections in a lower domain, switch to that domain. Each Firepower Management Center can have only
one AMP for Firepower connection, which belongs to the Global domain.
Procedure
What to Do Next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
Note
For information about the button on the AMP > Dynamic Analysis Connections page, see Enabling
Access to Dynamic Analysis Results in the Public Cloud, on page 1406.
By default, the Firepower Management Center can connect to the public AMP Threat Grid cloud for file
submission and report retrieval. You can neither configure nor delete this connection.
Procedure
Cisco AMP Threat Grid offers more detailed reporting on analyzed files than is available in the Firepower
Management Center. If your organization has an account in the Cisco AMP Threat Grid public cloud, you
can access the Cisco AMP Threat Grid portal directly to view additional details about files sent for analysis
from your managed devices. However, for privacy reasons, file analysis details are available only to the
organization that submitted the files. Therefore, before you can view this information, you must associate
your Firepower Management Center with the files submitted by its managed devices.
Procedure
What to Do Next
After the association is activated, see Viewing Dynamic Analysis Results in the Cisco AMP Threat Grid
Public Cloud, on page 2339.
If you install an on-premises AMP Threat Grid appliance on your network, you can configure a dynamic
analysis connection to submit files and retrieve reports from the appliance. When configuring the on-premises
appliance dynamic analysis connection, you register the Firepower Management Center to the on-premises
appliance.
Procedure
Note Cisco recommends that you either enable automatic updates or use the scheduler to schedule updates.
Although you can manually perform on-demand updates by clicking Update Now, automating the process
ensures the most up-to-date, relevant data. You cannot start an on-demand update if an update is already
in progress.
Connections to uncategorized URLs do not match rules with category or reputation-based URL conditions.
You cannot assign categories or reputations to URLs manually.
Related Topics
Communication Ports Requirements, on page 2469
Procedure
• About File and Malware Inspection Performance and Storage Tuning, page 1411
• File and Malware Inspection Performance and Storage Options, page 1411
• Tuning File and Malware Inspection Performance and Storage, page 1414
Table 100: Advanced Access Control File and AMP for Firepower Options
Allow file if cloud lookup for Specifies how long the system 0 - 30 seconds Cisco recommends that you use
Block Malware takes longer will hold the last byte of a file the default value to avoid
than (seconds) that matches a Block Malware blocking traffic because of
rule and that does not have a connection failures. Do not set
cached disposition, while this option to 0 without
malware cloud lookup occurs. contacting Support.
If the time elapses without the
system obtaining a disposition,
the file passes. Dispositions of
Unavailable are not cached.
Do not calculate SHA-256 Prevents the system from 0 - 4294967295 (4GB) Enter 0 to remove the
hash values for files larger storing files larger than a certain restriction.
than (in bytes) size, performing a malware
This value must be greater than
cloud lookup on the files, or
or equal to Maximum file size
blocking the files if added to the
to store (bytes) and Maximum
custom detection list.
file size for dynamic analysis
testing (bytes).
Minimum file size to store Specifies the minimum file size 0 - 10485760 (10MB) Enter 0 to disable file storage.
(bytes) the system can store using a file
This field must be less than or
rule.
equal to Maximum file size to
store (bytes) and Do not
calculate SHA-256 hash
values for files larger than (in
bytes).
Maximum file size to store Specifies the maximum file size 0 - 10485760 (10MB) Enter 0 to disable file storage.
(bytes) the system can store using a file
This field must be greater than
rule.
or equal to Minimum file size
to store (bytes), and less than
or equal to Do not calculate
SHA-256 hash values for files
larger than (in bytes).
Maximum file size for Specifies the maximum file size 0 -104857600 (100MB) This field must be greater than
dynamic analysis testing the system can submit to the or equal to Minimum file size
(bytes) AMP cloud for dynamic for dynamic analysis testing
analysis. (bytes), and less than or equal
to Do not calculate SHA-256
hash values for files larger
than (in bytes).
If you deploy your access
control policy to a device
running Version 5.x of the
Firepower System, the system
modifies all values greater than
2097152, to 2097152.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Files and Malware Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Set any of the options described in File and Malware Inspection Performance and Storage Options, on page
1411.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Observables and the AND/OR operators between them form an indicator's pattern, as illustrated in the following
examples.
After publishing to elements, TID generates observations when the system identifies observables in traffic.
TID also updates the incidents associated with the observable's parent indicator(s).
An incident is fully realized when an indicator's pattern is fulfilled. For more information, see Observation
and Incident Generation, on page 1442.
those flat files. In addition, TID can retrieve and ingest intelligence provided in Structured Threat
Information eXpression (STIX™) format.
• TID provides granular control of filtering actions—With Security Intelligence, you can specify
filtering criteria by network, URL, or DNS object. A given object can contain multiple IP addresses,
URLs, or DNS domain names, but you can only blacklist or whitelist by object, not by individual
components of an object. With TID, you can configure filtering actions for individual criteria (that is,
simple indicators or individual observables).
• TID configuration changes do not require redeployment—After you modify Security Intelligence
settings in the access control policy, you must redeploy the changed configuration to managed devices.
With TID, after initial deployment of the access control policy to the managed devices, you can configure
sources, indicators, and observables without redeploying, and the system automatically publishes new
TID data to the elements.
Note If you have enabled both Security Intelligence and TID in an access control policy, the system filters
traffic first by Security Intelligence criteria and then by TID criteria. For more information, see
TID-Firepower Management Center Action Prioritization, on page 1456.
Note If you encounter an issue during TID configuration or operation, see Troubleshooting Common Issues
With TID, on page 1459.
Procedure
Step 1 Configure which sources of intelligence you want TID to ingest. For more information, see Using TID Sources
to Ingest Feed Data, on page 1422 and Source Requirements, on page 1421.
Step 2 TID ingests the intelligence data and allows you to aggregate and analyze that data in a consolidated view.
In this view, you can refine the actions the system takes when it detects indicators and observables in traffic
passing through your elements.
Step 3 Configure access control policies to publish TID data to your elements. For more information, see Using
Access Control to Publish TID Data and Generate Events, on page 1441 and Platform and Element Requirements,
on page 1420.
Step 4 TID operationalizes the data by publishing it to the elements.
Step 5 The elements monitor traffic and report observations to the Firepower Management Center.
Step 6 The Firepower Management Center collects observations from all elements, evaluates the observations against
TID indicators, and generates or updates incidents as appropriate.
Step 7 Perform incident analysis. For more information, see Using TID to Analyze Incident and Observation Data,
on page 1442
Hosting Platforms
You can host TID on physical and virtual Firepower Management Centers:
• running Version 6.2.2 or later of the Firepower System.
• configured with a minimum of 15 GB of memory.
• configured with REST API access enabled.
Note If you host TID on the active Firepower Management Center in a high availability configuration, the
system does not synchronize TID configurations and TID data to the standby Firepower Management
Center. We recommend performing regular backups of TID data on your active Firepower Management
Center so that you can restore the data after failover.
For more information, see Firepower Management Center Access and License Requirements, on page 1421
and Firepower Management Center and Managed Device Performance Impact, on page 1421.
Elements
You can use any Firepower Management Center-managed device as a TID element if the device is running
Version 6.2.2 or later of the Firepower System.
The following diagram shows data flow in a sample Firepower System configuration.
Access
You can use Firepower Management Center user accounts to access the TID menus and pages:
• Accounts with the Admin or Threat Intelligence Director User user role.
• Accounts with a custom user role containing the Intelligence permission.
In addition, you can use Firepower Management Center user accounts with the Admin, Access Admin, or
Network Admin user role to enable or disable TID in your access control policies.
For more information about user accounts, see Firepower System User Management, on page 43.
Licensing
The Firepower System requires a Malware license (Classic or Smart) if you want to configure file policies
for SHA-256 observable publishing.
For more information, see Using Access Control to Publish TID Data and Generate Events, on page 1441 and
About Firepower Feature Licenses, on page 109.
Managed Device
There is no exceptional performance impact. TID impacts performance identically to the Firepower Management
Center Security Intelligence feature.
Source Requirements
Feeds must meet the following type and delivery requirements to be used as sources in TID:
Note For information about the flat file Content types TID supports, see
Source Configuration Fields, on page 1422.
Type The data format of the source (STIX or Flat File). URL, Upload
During STIX ingestion, TID creates a simple or complex indicator from the
contents of the STIX file.
During Flat File ingestion, TID creates a simple indicator for each observable
value in the flat file.
http://abc@google.com:8080/index.htm
as
abc@google.com/index.htm/
• IPv4—source contains one or more valid IPv4 addresses, as defined in
RFC 791.
Note TID does not accept CIDR
blocks.
• IPv6—source contains one or more valid IPv6 addresses, as defined in
RFC 4291.
Note TID does not accept prefix
lengths.
The system uses this value to identify the data types of the observables and
observations related to the source.
• When the Delivery of the source is TAXII, this is the discovery URL for
the TAXII discovery service.
• When the Delivery of the source is URL, this is the URL specifying where
the text file is located on a server.
You must specify the protocol, domain name or IP address, and file name.
Specifying a port for communications with the server is optional.
SSL Settings > Self-Signed When enabled, TID uses a self-signed server certificate for communicating with URL
Certificate your URL or TAXII server.
SSL Settings > Server Displays if you enable Self-Signed Certificate. The server's PEM-encoded URL
Certificate certificate for communicating with your URL or TAXII server, if required by
the self-signed server certificate.
• If you have access to the self-signed server certificate, open the certificate
in a text editor and copy the entire block of text, including the BEGIN
CERTIFICATE and END CERTIFICATE lines. Enter this entire string
into the field.
• If you do not have access to the self-signed server certificate, leave the
field blank. After you save the source, TID retrieves the certificate from
the server.
Take note of the certificate's expiration date. After the certificate expires, enter
a new Server Certificate or delete the existing Server Certificate.
SSL Settings > User The user's PEM-encoded certificate for communicating with your URL or TAXII URL
Certificate server, if required by the server.
Open the certificate in a text editor and copy the entire block of text, including
the BEGIN CERTIFICATE and END CERTIFICATE lines. Enter this entire
string into the field.
Username / Password The credentials, if required, to access the TAXII server's directory service where TAXII
the files are stored.
Note If you specified an http:// value in the URL field, TID sends the user
name and password over an insecure connection.
Feeds One or more feeds from the TAXII delivery service that you want to import as TAXII
sources in TID. Click to fetch feeds from the specified TAXII delivery service
URL.
TID creates one source for each selected feed.
File The local file that you want to import as a source in TID. Upload
Action The action (Block or Monitor) you want to perform on traffic matching the data any
contained within this source.
Note You can block flat files at the source, indicator, and observable level.
You cannot block STIX feeds at the source level. However, you can
block a simple indicator from a STIX feed at the indicator or observable
level. For more information, see Editing TID Actions at the Source,
Indicator, or Observable Level, on page 1452.
Indicators can inherit Action settings from a parent source, and
observables can inherit Action settings from a parent indicator. For
more information, see Inheritance in TID Configurations, on page 1428.
Update Every (minutes) or The frequency that TID should update the source, in minutes; for example, 1440. TAXII, URL
Never Update
• When TID updates a URL source, it overwrites the old file with the new file.
• When TID updates a TAXII source, it updates the old data with new or
changed information from the new file.
If you check the Never Update checkbox, TID never updates the source.
After the TTL elapses, TID deletes all of the source's indicators that have not
been seen or updated since the time the indicator was ingested. TID also deletes
all observables associated with the indicators if there are no surviving indicators
referencing the observables.
Publish Specifies whether TID publishes data from the source to registered elements. any
When this option is enabled, the system automatically publishes the initial source
data and any subsequent changes including:
• changes from periodic source refreshes
• changes resulting from system action (for example, TTL expiration)
• any user-initiated changes (for example, a change in the Action setting for
an indicator or observable)
For more information, see Publishing TID Data at the Source, Indicator, or
Observable Level, on page 1449.
Indicators can inherit Publish settings from a parent source, and observables can
inherit Publish settings from a parent indicator. For more information, see
Inheritance in TID Configurations, on page 1428.
If SourceB later contributes IndicatorB, which also includes ObservableA, the system modifies ObservableA
as follows:
In this example, ObservableA has two parents: one parent for its Action setting and one parent for its Publish
setting. If you manually edit the settings for the observable and then revert the settings, the system sets the
Action setting to the IndicatorA value and the Publish setting to the IndicatorB value.
Note If you whitelist an observable, whitelisting always takes precedence over the Action setting, whether the
setting in the observable is an inherited or override value.
To override an inherited setting, change the setting at the child level; see Editing TID Actions at the Source,
Indicator, or Observable Level, on page 1452 and Publishing TID Data at the Source, Indicator, or Observable
Level, on page 1449. After you override an inherited setting, the child object retains that setting despite changes
to the parent object(s).
For example, you might start with the following original settings, with no overrides set:
If you override the setting for IndicatorA, the settings would be the following:
In this case, any changes to the Publish setting for SourceA no longer cascade automatically to IndicatorA.
However, inheritance from IndicatorA to ObservableA1 and ObservableA2 continues, because the observable
settings are not currently set to override values.
If you later override the setting for ObservableA1:
Any changes to the Publish setting for IndicatorA no longer cascade automatically to ObservableA1. However,
those changes continue to cascade to ObservableA2, because it is not set to an override value.
At the observable level, you can revert from an override setting to the inherited setting, and the system resumes
cascading setting changes automatically from the parent indicator to that observable.
Procedure
Configure a URL source if you want TID to fetch a single feed from a file on a host. For more information
about source configuration fields, see Source Configuration Fields, on page 1422.
Procedure
Configure an Upload source if you want TID to receive a local file containing a single feed. For more
information about source configuration fields, see Source Configuration Fields, on page 1422.
Procedure
Configure SSL Settings if the host server requires an encrypted connection. For more information about
source configuration fields, see Source Configuration Fields, on page 1422.
Procedure
Step 1 In the Edit Source dialog, expand the SSL Settings section.
Step 2 (Optional) If your server certificate is self-signed, enable Self-Signed Certificate. If not, skip to Step 5.
Step 3 (Optional) Choose a SSL Hostname Verification method.
Step 4 (Optional) If you have access to the self-signed server certificate, enter a Server Certificate. If you do not
have access to the self-signed server certificate, leave the Server Certificate blank. After you save the source,
TID retrieves the certificate from the server.
Step 5 (Optional) If your server requires a user certificate, enter a User Certificate and a User Private Key.
What to Do Next
• Continue configuring the source.
The Sources page displays summary information about all configured sources; see Source Summary
Information, on page 1434. For detailed information about configurable source fields, see Source Configuration
Fields, on page 1422.
Procedure
Field Description
Name The source name.
Action The action (Block or Monitor) that the system is configured to perform on traffic matching the data contained
within this source.
Indicators can inherit Action settings from a parent source, and observables can inherit Action settings from a
parent indicator. For more information, see Inheritance in TID Configurations, on page 1428.
Publish On or Off toggle specifying whether TID publishes data from the source to registered elements.
Indicators can inherit Publish settings from a parent source, and observables can inherit Publish settings from
a parent indicator. For more information, see Inheritance in TID Configurations, on page 1428.
Last Updated The date and time TID last updated the source.
Field Description
Status The current status of the source:
• New—The source is newly created.
• Scheduled—The initial download or subsequent update is scheduled, but not yet in progress.
• Downloading—TID is performing the initial download or update refresh.
• Parsing or Processing ( )—TID is ingesting the source.
• Completed with Errors ( )—TID finished ingesting the source, but some observables are unsupported
or invalid.
• Error ( )—TID experienced a problem. If the source is a TAXII or URL source with an Update
Frequency specified, and updates are not paused, TID retries on the next scheduled update.
Clicking this icon allows you to edit settings for the source.
Data Description
Status Message Briefly describes the current status of the source.
Last Updated Specifies the date and time TID last updated the source.
Next Update Specifies when TID will update the source next.
Data Description
Observables Specifies observable counts:
• Consumed—The number of observables TID TID processed during the most recent source update.
This number represents all observables contained in the update, regardless of whether they were
ingested or discarded.
• Unsupported—The number of unsupported observables that the system did not add to TID during
the most recent update.
For more information about supported observable types, see the Content description in Source
Configuration Fields, on page 1422.
• Invalid—The number of invalid observables that the system did not add to TID during the most
recent update.
An observable is invalid if it is improperly constructed. For example, 10.10.10.10.123 is not a
valid IPv4 address.
Note For TAXII sources, TID provides separate Last Update and Total observable counts,
because TAXII updates add incremental data, rather than replacing existing data. For
observables from other source types, TID provides only the Last Update count, because
updates from those sources replace the existing data set entirely.
The Indicators page displays summary information about all indicators for configured sources. For more
information, see Indicator Summary Information, on page 1437.
Procedure
• To filter the indicators displayed on the page, click the Filter icon ( ). For more information, see
Filtering TID Data in Table Views, on page 1453.
• To sort the order of the indicators displayed on the page, click on any column's Sort icon ( ). For more
information, see Sorting TID Data in Table Views, on page 1453.
• To view additional details about an indicator (including associated observables), click the indicator
name. For more information, see Indicator Details, on page 1438.
• In the Incidents column, click the number to view information about incidents associated with an
indicator, or hover the cursor over the icon to view whether the incidents are fully- or partially-realized.
• To determine whether TID finished ingesting an indicator from the source, view the Status column.
Field Description
Type The indicator type:
• Simple—Contains a single observable.
• Complex—Contains two or more observables.
Source The source that contained the indicator (the parent source).
Field Description
Action The action associated with the indicator. For more information, see Editing TID Actions at
the Source, Indicator, or Observable Level, on page 1452.
Indicators can inherit Action settings from a parent source, and observables can inherit
Action settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1428.
Publish The publish setting for the indicator. For more information, see Publishing TID Data at the
Source, Indicator, or Observable Level, on page 1449.
Indicators can inherit Publish settings from a parent source, and observables can inherit
Publish settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1428.
Last Updated The date and time TID last updated the indicator.
• Completed With Errors ( )—TID finished ingesting the indicator, but some
observables are unsupported or invalid.
Indicator Details
The Indicator Details page displays indicator and observable data for an incident.
Field Description
Name The indicator name.
Expires The date and time the incident will expire, based on the source's TTL value.
Action The action associated with the indicator. For more information, see Editing TID Actions at the Source,
Indicator, or Observable Level, on page 1452.
Indicators can inherit the Action setting from a parent source, and observables can inherit the Action
setting from a parent indicator. For more information, see Inheritance in TID Configurations, on page
1428.
Field Description
Publish The publish setting for the indicator. For more information, see Publishing TID Data at the Source,
Indicator, or Observable Level, on page 1449.
Indicators can inherit the Publish setting from a parent source, and observables can inherit the Publish
setting from a parent indicator. For more information, see Inheritance in TID Configurations, on page
1428.
Indicator Pattern The observables and operators that form the indicator's pattern. Operators link the observables within
the indicator. AND relationships are indicated with the AND operator. OR relationships are indicated
with the OR operator or by a close grouping of several observables.
Optionally, use the Whitelist icon ( ) to whitelist an observable. For more information, see Whitelisting
TID Observables, on page 1452.
The Observables page displays all successfully ingested observables; see Observable Summary Information,
on page 1440.
Procedure
• To view indicators that contain the observable, click the number in the Indicators column. The Incidents
page opens with the observable value as the filter. For more information, see Viewing and Managing
Indicators, on page 1436.
Field Description
Type The type of observable data: SHA-256, Domain, URL, IPv4, or IPv6.
Action The action configured for the observable. For more information, see Editing TID Actions
at the Source, Indicator, or Observable Level, on page 1452.
Indicators can inherit Action settings from a parent source, and observables can inherit
Action settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1428.
Publish The publish setting for the observable; see Publishing TID Data at the Source, Indicator, or
Observable Level, on page 1449.
Indicators can inherit Publish settings from a parent source, and observables can inherit
Publish settings from a parent indicator. For more information, see Inheritance in TID
Configurations, on page 1428.
Updated At The date and time TID last updated the observable.
Expires The date that the observable will be automatically purged from TID based on TTL for the
parent indicator.
Field Description
Clicking this icon whitelists the observable; see Whitelisting TID Observables, on page
1452.
You must configure access control policies to publish TID data from the Firepower Management Center to
your managed devices (elements). In addition, we recommend that you configure your access control policies
to maximize observation and Firepower Management Center event generation.
Perform the steps below for each access control policy deployed to a TID element.
Procedure
Step 1 Verify that the Enable Threat Intelligence Director check box is checked in the Advanced Settings tab of
the access control policy. This option is enabled by default. For more information, see Access Control Policy
Advanced Settings, on page 1226.
Step 2 Add rules to the access control policy if they are not already present. TID requires that the access control
policy specify at least one rule. For more information, see Creating a Basic Access Control Policy, on page
1220.
Step 3 If you choose Intrusion Prevention as the default action for the access control policy, associate an SSL policy
with the access control policy; see Associating Other Policies with Access Control, on page 1228.
Step 4 If you want SHA-256 observables to generate observations and Firepower Management Center events, create
one or more Malware Cloud Lookup or Block Malware file rules and associate the file policy with one or
more rules in the access control policy. For more information, see Configuring an Access Control Rule to
Perform File Control and AMP, on page 1247.
Step 5 If you want IPv4, IPv6, URL, or Domain Name observations to generate connection and security intelligence
events, enable connection and security intelligence logging in the access control policy:
• In access control rules where you invoked a file policy, enable Log at End of Connection and File
Events: Log Files, if not already enabled. For more information, see Logging Connections with Access
Control Rules, on page 2241.
• Verify that default logging (DNS Policy, Networks, and URLs) is enabled in your Security Intelligence
settings. For more information, see Logging Connections with Security Intelligence, on page 2240.
Step 6 Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Note TID ignores unsupported, invalid, and whitelisted observables when evaluating an indicator's pattern.
If TID ingested the observables from the example above and the observables were seen in order, incident
generation would proceed as follows:
1 When the system identifies Observable A in traffic, TID:
• Generates a fully-realized incident for Indicator 1.
• Generates partially-realized incidents for Indicator 2 and Indicator 3.
The Incidents page displays summary information about all TID incidents; see Incident Summary Information,
on page 1444.
Procedure
• To view the date and time an incident was last updated by TID, hover the cursor over the value in the
Last Updated column.
• To view more information about the indicator associated with the incident, click the text in the Indicator
Name column; see Viewing and Managing Indicators, on page 1436.
• To view incident details, click the name in the Incident ID column; see Incident Details, on page 1445.
Step 3 Manage custom incident fields by clicking the Incident ID value for an incident:
• To assign an optional, custom name to the incident, add or edit text in the Name field.
• To assign an optional, custom description for the incident, add or edit text in the Description field.
• To indicate the relative importance of the incident, assign a rating in the Confidence field.
• To assign an optional custom tag or keyword to the incident, add or edit text in the Category field.
• To indicate the status of your investigation into the incident, choose a value from the drop-down list in
the Status field.
• To view all indicator details, click the indicator link immediately under the Indicator heading in the
lower section of the window.
• To expand the indicator summary fields, click the arrow next to the indicator link immediately under
the Indicator heading.
Step 4 Manage TID configurations within an incident; see Manage TID Configurations within an Incident, on page
1448.
Field Description
Last Updated The number of days since either the system or a user last updated the incident. To view the date and time of the
update, hover the cursor over the value in this column.
Field Description
Incident ID The unique identifier for the incident. This ID has the following format:
<type>-<date>-<number>
• <type>—The type of indicator or observable involved in the incident. For simple indicators, this value
indicates the observable type: IP (IPv4 or IPv6), URL (URL), DOM (domain), or SHA (SHA-256). For complex
indicators, this value is COM.
• <date>—The date (yyyymmdd) on which the incident was created.
• <number>—The daily incident number, that is, a number specifying where the incident occurs in the daily
sequence of incidents. Note that this sequence starts at 0. For example, DOM-20170828-10 is the 11th
incident created on that day.
Next to the identifier, the system displays an icon that indicates whether the incident is partially realized ( )
or fully realized ( ). For more information, see Observation and Incident Generation, on page 1442.
Indicator Name The name of the indicator involved in the incident. To view additional information about the indicator, click
the value in this column; see Viewing and Managing Indicators, on page 1436.
Type The type of indicator involved in the incident. For more information, see Observable Summary Information,
on page 1440.
Action Taken The action taken by the system in relation to the incident. For more information, see Incident Details, on page
1445.
Status The status of your investigation into the incident. For more information, see Incident Details, on page 1445.
Incident Details
The Incident Details window displays information about a single TID incident. This window is divided into
two sections:
• Incident Details: Basic Information, on page 1445
• Incident Details: Indicator and Observations, on page 1446
Field Description
IncidentID or An icon indicating the incident's status (partially-realized or fully-realized), as well as the unique identifier
IncidentID for the incident.
Note TID ignores unsupported, invalid, or whitelisted observables when determining an incident's
status.
Opened The date and time the incident was last updated.
Confidence A custom, optional value that indicates the relative importance of the incident.
Action Taken The action taken by the system: Monitored, Blocked, or Partially Blocked.
Partially Blocked indicates that the incident contained both Monitored and Blocked observations.
Note The Action Taken indicates the action taken by the system, not necessarily the action selected
in TID. For more information, see TID-Firepower Management Center Action Prioritization,
on page 1456.
Category A custom, optional tag or keyword that you add to the incident.
Status A value indicating the current stage of your analysis of the incident. All incidents are New until you change
the Status for the first time.
This field is optional. Depending on the needs of your organization, consider using the status values as
follows:
• New—The incident requires investigation, but you have not started investigating.
• Open—You are currently investigating the incident.
• Closed—You investigated the incident and took action.
• Rejected—You investigated the incident and determined there was no action to take.
Indicator Section
When you first view indicator details, this section displays only the indicator name.
Click the indicator name to view the indicator on the Indicators page.
Click the down arrow next to the indicator name to view more indicator details without leaving the incident.
Detail fields include:
Field Description
Description The indicator description provided by the source.
Source The source that contained the indicator. Click this link to access full source details.
Expires The date and time the incident will expire, based on the source's TTL value.
Action The action associated with the indicator. For more information, see Editing TID Actions
at the Source, Indicator, or Observable Level, on page 1452.
Publish The publish setting for the indicator. For more information, see Publishing TID Data
at the Source, Indicator, or Observable Level, on page 1449.
Download STIX If the source type is STIX, click this button to download the STIX file.
Indicator Pattern
The indicator pattern is a graphical representation of the observables and operators that comprise the indicator.
Operators link the observables within the indicator. AND relationships are indicated with the AND operator.
OR relationships are indicated with the OR operator or by a close grouping of several observables.
If an observable in the pattern has already been seen, the observable box is white. If an observable has not
already been seen, the observable box is grey.
In the indicator pattern:
• Click the Whitelist icon ( ) to whitelist the observable. This icon is present in both white and grey
observable boxes. For more information, see Whitelisting TID Observables, on page 1452.
• If you hover the cursor over a white observable box, the system highlights the related observation in the
Observations section.
• If you click on a white observable box, the system highlights the related observation in the Observations
section, scrolls that observation into view (if multiple observations are present), and expands that
observation's detailed display.
• If you hover the cursor over or click grey observable box in the indicator pattern, there is no change in
the Observations section. Because the observable is unseen, there are no observation details to display
yet.
Observations Section
By default, the Observations section displays summary information, which includes:
• The type of observable that triggered the observation (for example, Domain)
Note If a single observable has been seen three or more times, TID displays the first and last
observation details. The details for intermediary observations are not available.
If you hover the cursor over an observation in the Observations section, the system highlights the related
observable in the indicator pattern.
If you click an observation in the Observations section, the system highlights the related observable(s) in the
indicator pattern and scrolls the first related observable into view (if multiple observables are present). Clicking
an observation also expands the details of the observation in the Observations section.
Observation details include the following fields:
Field Description
SOURCE The source IP address and port for the traffic that
triggered the observation.
DESTINATION The destination IP address and port for the traffic that
triggered the observation.
The Incident Details window displays information about a TID incident; see Incident Details, on page 1445.
Procedure
Use any of the following pages to toggle TID data publishing for sources, indicators, or observables. If you
pause publishing from these pages, the system no longer sends related TID observables to your elements.
Note:
• Pausing publication for a parent pauses all children. If you pause publishing at the source level, you
pause publishing for all its indicators. If you pause publishing at the indicator level, you pause publishing
for all of its observables.
• Pausing publication for a child interrupts inheritance. If you pause publishing at the indicator level, and
subsequently publish at the source level, publishing for the indicator remains paused until you change
the individual setting for the indicator. If you pause publishing at the observable level, and subsequently
publish at the indicator level, publishing for the observable remains paused until you change the individual
setting for the observable. At the observable level, you can revert automatically to the parent indicator's
publishing status. For more information about inheritance, see Inheritance in TID Configurations, on
page 1428.
• Publishing for flat file Upload sources can be only be paused at the indicator level.
Note To purge all TID observables stored on your elements, see Publishing or Purging TID Data at the Feature
Level, on page 1451.
Procedure
Step 2 Locate the Publish slider ( ) and use it to toggle publishing to elements.
Step 3 (Observables only) If you want to resume inheriting the publication setting from the parent indicator, click
the revert icon ( ) next to the Publish setting for the observable.
What to Do Next
• Set the publication frequency for TID data at the observable level; see Setting the Observable Publication
Frequency, on page 1450.
By default, the system publishes observables to TID elements every 5 minutes. Use this procedure to set this
interval to a different value.
Procedure
Use the Settings page to toggle TID data publishing for the entire feature.
If you pause publishing at the feature level, the system purges all TID observables stored on your elements.
You must manually Resume publishing if you want to resume sending TID data to your elements and generating
observations.
To toggle TID data publishing without purging TID data, see Publishing TID Data at the Source, Indicator,
or Observable Level, on page 1449.
Procedure
Note:
• Editing the action for a parent sets the action for all children. If you edit the action at the source level,
you set the action for all its indicators. If you edit the action at the indicator level, you set the action for
all of its observables.
• Editing the action for a child interrupts inheritance. If you edit the action at the indicator level, and
subsequently edit it at the source level, the indicator's action is retained until you edit the action for the
individual indicator. If you edit the action at the observable level, and subsequently edit it at the indicator
level, the observable's action is retained until you edit the action for the individual observable. At the
observable level, you can revert automatically to the parent indicator's action. For more information
about inheritance, see Inheritance in TID Configurations, on page 1428.
For information about action prioritization in the Firepower System, see TID-Firepower Management Center
Action Prioritization, on page 1456.
Procedure
The Whitelist icon ( ) appears on the indicator details page and the observables page. If you want to whitelist
an observable, click the icon.
If you whitelist an observable, TID ignores the observable when evaluating for partially or fully realized
incidents. For example, if Observable 1 and Observable 2 are linked by the AND operator and you whitelist
Observable 1, TID generates a fully realized incident when Observable 2 is seen.
Procedure
Procedure
Step 2 To sort the table by the data in a column, click the Sort icon ( ). To reverse the sort order, click the icon again.
Viewing Elements
Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Global Admin/Threat
Intelligence Director
(TID) User
Procedure
TID configurations and TID data Back Up Threat Intelligence Restore Threat Intelligense
Director Director Data
For more information, see Backing up a Firepower Management Center, on page 163 and Restoring the
Appliance from a Backup File, on page 169.
Note If you host TID on the active Firepower Management Center in a high availability configuration, the
system does not synchronize TID configurations and TID data to the standby Firepower Management
Center. We recommend performing regular backups of TID data on your active Firepower Management
Center so that you can restore the data after failover.
For more information about the Firepower Management Center events that TID observations generate, see
TID Observations in Firepower Management Center Events, on page 1456.
The system action logged for TID-related events can vary, depending on the interaction of TID and other
Firepower Management Center features. For more information about action prioritization, see TID-Firepower
Management Center Action Prioritization, on page 1456.
• Confirm that you enabled event logging required for TID in your access control policy, as described in
Using Access Control to Publish TID Data and Generate Events, on page 1441.
Procedure
Observation Connection Events Table Security Intelligence Events File Events Table Malware Events Table
Content Table
SHA-256 Yes No Yes Yes, if disposition is
Malware or Custom
Detection.
Table 113: TID URL or IPv4/IPv6 Observable Action vs. Security Intelligence Action
Setting: Security Intelligence Setting: TID URL or IPv4/IPv6 TID Incidents Security Intelligence Events Fields:
Action Observable Action Field: Action
Taken Action Security Intelligence Reason
Category
Whitelist Monitor or Block (no incident Allow (none) (none)
generated)
Block Monitor or Block Blocked Block as determined by IP Block
system analysis; see or URL
Security Intelligence Block
Options, on page 1261
Table 114: TID Domain Name Observable Action vs. DNS Policy Action
Setting: DNS Policy Action Setting: TID TIDIncidents Security Intelligence Events Fields:
Domain Name Field: Action
Observable Taken Action Security Intelligence Reason
Action Category
Setting: DNS Policy Action Setting: TID TIDIncidents Security Intelligence Events Fields:
Domain Name Field: Action
Observable Taken Action Security Intelligence Reason
Action Category
Drop, Domain Not Found, Monitor Blocked Block as determined by system DNS Block
Sinkhole—Log, or analysis; see Security
Sinkhole—Block and Log Intelligence Options, on
page 1261
Table 115: TID SHA-256 Observable Action vs. Malware Cloud Lookup File Policy
File Disposition TID SHA-256 Observable Action Taken in TID Action in File Events Action in Malware
Action Incidents Events
Clean Monitor or Block Monitored Malware Cloud n/a
Lookup
Table 116: TID SHA-256 Observable Action vs. Block Malware File Policy
File Disposition TID SHA-256 Observable Action Taken in TID Action in File Events Action in Malware
Action Incidents Events
Clean or Unknown Monitor Monitored Malware Cloud n/a
Lookup
System is performing a Security Intelligence or DNS Policy action instead of a TID action
This is by design. For more information, see TID-Firepower Management Center Action Prioritization, on
page 1456.
TID is disabled
Add memory to your appliance. Threat Intelligence Director can only be used on appliances with at least
15GB of memory.
Both network analysis and intrusion policies are invoked by a parent access control policy, but at different
times. As the system analyzes traffic, the network analysis (decoding and preprocessing) phase occurs before
and separately from the intrusion prevention (additional preprocessing and intrusion rules) phase. Together,
network analysis and intrusion policies provide broad and deep packet inspection. They can help you detect,
alert on, and protect against network traffic that could threaten the availability, integrity, and confidentiality
of hosts and their data.
The Firepower System is delivered with several similarly named network analysis and intrusion policies (for
example, Balanced Security and Connectivity) that complement and work with each other. By using
system-provided policies, you can take advantage of the experience of the Cisco Talos Security Intelligence
and Research Group (Talos). For these policies, Talos sets intrusion and preprocessor rule states, as well as
provides the initial configurations for preprocessors and other advanced settings.
You can also create custom network analysis and intrusion policies. You can tune settings in custom policies
to inspect traffic in the way that matters most to you so that you can improve both the performance of your
managed devices and your ability to respond effectively to the events they generate.
You create, edit, save, and manage network analysis and intrusion policies using similar policy editors in the
web interface. When you are editing either type of policy, a navigation panel appears on the left side of the
web interface; the right side displays various configuration pages.
In an inline deployment (that is, where relevant configurations are deployed to devices using routed, switched,
or transparent interfaces, or inline interface pairs), the system can block traffic without further inspection at
almost any step in the illustrated process. Security Intelligence, the SSL policy, network analysis policies, file
policies, and intrusion policies can all either drop or modify traffic. Only the network discovery policy, which
passively inspects packets, cannot affect the flow of traffic.
Similarly, at each step of the process, a packet could cause the system to generate an event. Intrusion and
preprocessor events (sometimes referred to collectively as intrusion events) are indications that a packet or
its contents may represent a security risk.
Tip The diagram does not reflect that access control rules handle encrypted traffic when your SSL inspection
configuration allows it to pass, or if you do not configure SSL inspection. By default, the system disables
intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve
performance when an encrypted connection matches an access control rule that has intrusion and file
inspection configured.
Note that for a single connection, although the system selects a network analysis policy before an access
control rule as shown in the diagram, some preprocessing (notably application layer preprocessing) occurs
after access control rule selection. This does not affect how you configure preprocessing in custom network
analysis policies.
A network analysis policy governs packet processing in phases. First the system decodes packets through the
first three TCP/IP layers, then continues with normalizing, preprocessing, and detecting protocol anomalies:
• The packet decoder converts packet headers and payloads into a format that can be easily used by the
preprocessors and later, intrusion rules. Each layer of the TCP/IP stack is decoded in turn, beginning
with the data link layer and continuing through the network and transport layers. The packet decoder
also detects various anomalous behaviors in packet headers.
• In inline deployments, the inline normalization preprocessor reformats (normalizes) traffic to minimize
the chances of attackers evading detection. It prepares packets for examination by other preprocessors
and intrusion rules, and helps ensure that the packets the system processes are the same as the packets
received by the hosts on your network.
Note In a passive deployment, Cisco recommends that you enable adaptive profile updates
at the access control policy level, instead of inline normalization at the network analysis
level.
• Various network and transport layers preprocessors detect attacks that exploit IP fragmentation, perform
checksum validation, and perform TCP and UDP session preprocessing.
Note that some advanced transport and network preprocessor settings apply globally to all traffic handled
by the target devices of an access control policy. You configure these in the access control policy rather
than in a network analysis policy.
• Various application-layer protocol decoders normalize specific types of packet data into formats that
the intrusion rules engine can analyze. Normalizing application-layer protocol encodings allows the
system to effectively apply the same content-related intrusion rules to packets whose data is represented
differently, and to obtain meaningful results.
• The Modbus and DNP3 SCADA preprocessors detect traffic anomalies and provide data to intrusion
rules. Supervisory Control and Data Acquisition (SCADA) protocols monitor, control, and acquire data
from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment,
electric power distribution, airport and shipping systems, and so on.
• Several preprocessors allow you to detect specific threats, such as Back Orifice, portscans, SYN floods
and other rate-based attacks.
Note that you configure the sensitive data preprocessor, which detects sensitive data such as credit card
numbers and Social Security numbers in ASCII text, in intrusion policies.
In a newly created access control policy, one default network analysis policy governs preprocessing for all
traffic for all intrusion policies invoked by the same parent access control policy. Initially, the system uses
the Balanced Security and Connectivity network analysis policy as the default, but you can change it to another
system-provided or custom network analysis policy. In a more complex deployment, advanced users can tailor
traffic preprocessing options to specific security zones, networks, and VLANs by assigning different custom
network analysis policies to preprocess matching traffic.
Note All packets, regardless of which network analysis policy preprocesses them, are matched to configured
access control rules—and thus are potentially subject to inspection by intrusion policies—in top-down
order.
The diagram in How Policies Examine Traffic For Intrusions, on page 1466 shows the flow of traffic through
a device in an inline, intrusion prevention and AMP for Firepower deployment, as follows:
• Access Control Rule A allows matching traffic to proceed. The traffic is then inspected for discovery
data by the network discovery policy, for prohibited files and malware by File Policy A, and then for
intrusions by Intrusion Policy A.
• Access Control Rule B also allows matching traffic. However, in this scenario, the traffic is not inspected
for intrusions (or files or malware), so there are no intrusion or file policies associated with the rule.
Note that by default, traffic that you allow to proceed is inspected by the network discovery policy; you
do not need to configure this.
• In this scenario, the access control policy’s default action allows matching traffic. The traffic is then
inspected by the network discovery policy, and then by an intrusion policy. You can (but do not have
to) use a different intrusion policy when you associate intrusion policies with access control rules or the
default action.
The example in the diagram does not include any blocking or trusting rules because the system does not
inspect blocked or trusted traffic.
When the system processes packets according to an intrusion policy, first a rule optimizer classifies all activated
rules in subsets based on criteria such as: transport layer, application protocol, direction to or from the protected
network, and so on. Then, the intrusion rules engine selects the appropriate rule subsets to apply to each packet.
Finally, a multi-rule search engine performs three different types of searches to determine if the traffic matches
the rule:
• The protocol field search looks for matches in particular fields in an application protocol.
• The generic content search looks for ASCII or binary byte matches in the packet payload.
• The packet anomaly search looks for packet headers and payloads that, rather than containing specific
content, violate well-established protocols.
In a custom intrusion policy, you can tune detection by enabling and disabling rules, as well as by writing
and adding your own standard text rules. You can also use Firepower recommendations to associate the
operating systems, servers, and client application protocols detected on your network with rules specifically
written to protect those assets.
Variable Sets
Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Most
variables in a set represent values commonly used in intrusion rules to identify source and destination IP
addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule
suppressions and dynamic rule states.
The system provides a single default variable set, which is comprised of predefined default variables. Most
system-provided shared object rules and standard text rules use these predefined default variables to define
networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the
protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network. In addition,
specialized rules often use other predefined variables. For example, rules that detect exploits against web
servers use the $HTTP_SERVERS and $HTTP_PORTS variables.
Tip Even if you use system-provided intrusion policies, Cisco strongly recommends that you modify key
default variables in the default set. When you use variables that accurately reflect your network environment,
processing is optimized and the system can monitor relevant systems for suspicious activity. Advanced
users can create and use custom variable sets for pairing with one or more custom intrusion policies.
Related Topics
Predefined Default Variables, on page 366
As the database accumulates intrusion events, you can begin your analysis of potential attacks. The system
provides you with the tools you need to review intrusion events and evaluate whether they are important in
the context of your network environment and your security policies.
Note how:
• A default network analysis policy governs the preprocessing of all traffic handled by the access control
policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is the
default.
• The default action of the access control policy allows all non-malicious traffic, as determined by the
system-provided Balanced Security and Connectivity intrusion policy. Because the default action allows
traffic to pass, the discovery feature can examine it for host, application, and user data before the intrusion
policy can examine and potentially block malicious traffic.
• The policy uses default Security Intelligence options (global whitelist and blacklist only), does not
decrypt encrypted traffic with an SSL policy, and does not perform special handling and inspection of
network traffic using access control rules.
A simple step you can take to tune your intrusion prevention deployment is to use a different set of
system-provided network analysis and intrusion policies as your defaults. Cisco delivers several pairs of these
policies with the Firepower System.
Or, you can tailor your intrusion prevention deployment by creating and using custom policies. You may find
that the preprocessor options, intrusion rule, and other advanced settings configured in those policies do not
address the security needs of your network. By tuning your network analysis and intrusion policies you can
configure, at a very granular level, how the system processes and inspects the traffic on your network for
intrusions.
Tip Even if you use system-provided network analysis and intrusion policies, you should configure the system’s
intrusion variables to accurately reflect your network environment. At a minimum, modify key default
variables in the default set.
As new vulnerabilities become known, Talos releases intrusion rule updates. These rule updates can modify
any system-provided network analysis or intrusion policy, and can provide new and updated intrusion rules
and preprocessor rules, modified states for existing rules, and modified default policy settings. Rule updates
may also delete rules from system-provided policies and provide new rule categories, as well as modify the
default variable set.
If a rule update affects your deployment, the web interface marks affected intrusion and network analysis
policies as out of date, as well as their parent access control policies. You must re-deploy an updated policy
for its changes to take effect.
For your convenience, you can configure rule updates to automatically re-deploy affected intrusion policies,
either alone or in combination with affected access control policies. This allows you to easily and automatically
keep your deployment up-to-date to protect against recently discovered exploits and intrusions.
To ensure up-to-date preprocessing settings, you must re-deploy access control policies, which also deploys
any associated SSL, network analysis, and file policies that are different from those currently running, and
can also can update default values for advanced preprocessing and performance options.
Cisco delivers the following network analysis and intrusion policies with the Firepower System:
Balanced Security and Connectivity network analysis and intrusion policies
These policies are built for both speed and detection. Used together, they serve as a good starting point
for most organizations and deployment types. The system uses the Balanced Security and Connectivity
policies and settings as defaults in most cases.
Note If you disable a preprocessor in a custom network analysis policy, but the system needs to use that
preprocessor to later evaluate packets against an enabled intrusion or preprocessor rule, the system
automatically enables and uses the preprocessor although the preprocessor remains disabled in the network
analysis policy web interface.
• Specify ports, where appropriate, to focus the activity of certain preprocessors. For example, you can
identify additional ports to monitor for DNS server responses or encrypted SSL sessions, or ports on
which you decode telnet, HTTP, and RPC traffic.
For advanced users with complex deployments, you can create multiple network analysis policies, each tailored
to preprocess traffic differently. Then, you can configure the system to use those policies to govern the
preprocessing of traffic using different security zones, networks, or VLANs. (Note that ASA FirePOWER
modules cannot restrict preprocessing by VLAN.)
Note Tailoring preprocessing using custom network analysis policies—especially multiple network analysis
policies—is an advanced task. Because preprocessing and intrusion inspection are so closely related, you
must be careful to allow the network analysis and intrusion policies examining a single packet to
complement each other.
responses to intrusion events. Note that in addition to these per-policy alerting configurations, you can
globally enable or disable email alerting on intrusion events for each rule or rule group. Your email alert
settings are used regardless of which intrusion policy processes a packet.
Notice how a default network analysis policy governs the preprocessing of all traffic handled by the access
control policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is
the default.
A simple way to tune preprocessing is to create and use a custom network analysis policy as the default.
However, if you disable a preprocessor in a custom network analysis policy but the system needs to evaluate
preprocessed packets against an enabled intrusion or preprocessor rule, the system automatically enables and
uses the preprocessor although it remains disabled in the network analysis policy web interface.
Note In order to get the performance benefits of disabling a preprocessor, you must make sure that none of
your intrusion policies have enabled rules that require that preprocessor.
An additional challenge arises if you use multiple custom network analysis policies. For advanced users with
complex deployments, you can tailor preprocessing to specific security zones, networks, and VLANs by
assigning custom network analysis policies to preprocess matching traffic. (Note that ASA FirePOWER cannot
restrict preprocessing by VLAN.) To accomplish this, you add custom network analysis rules to your access
control policy. Each rule has an associated network analysis policy that governs the preprocessing of traffic
that matches the rule.
Tip You configure network analysis rules as an advanced setting in an access control policy. Unlike other
types of rules in the Firepower System, network analysis rules invoke—rather than being contained
by—network analysis policies.
The system matches packets to any configured network analysis rules in top-down order by rule number.
Traffic that does not match any network analysis rule is preprocessed by the default network analysis policy.
While this allows you a great deal of flexibility in preprocessing traffic, keep in mind that all packets, regardless
of which network analysis policy preprocessed them, are subsequently matched to access control rules—and
thus to potential inspection by intrusion policies—in their own process. In other words, preprocessing a packet
with a particular network analysis policy does not guarantee that the packet will be examined with any
particular intrusion policy. You must carefully configure your access control policy so it invokes the correct
network analysis and intrusion policies to evaluate a particular packet.
The following diagram shows in focused detail how the network analysis policy (preprocessing) selection
phase occurs before and separately from the intrusion prevention (rules) phase. For simplicity, the diagram
eliminates the discovery and file/malware inspection phases. It also highlights the default network analysis
and default-action intrusion policies.
In this scenario, an access control policy is configured with two network analysis rules and a default network
analysis policy:
• Network Analysis Rule A preprocesses matching traffic with Network Analysis Policy A. Later, you
want this traffic to be inspected by Intrusion Policy A.
• Network Analysis Rule B preprocesses matching traffic with Network Analysis Policy B. Later, you
want this traffic to be inspected by Intrusion Policy B.
• All remaining traffic is preprocessed with the default network analysis policy. Later, you want this traffic
to be inspected by the intrusion policy associated with the access control policy’s default action.
After the system preprocesses traffic, it can examine the traffic for intrusions. The diagram shows an access
control policy with two access control rules and a default action:
• Access Control Rule A allows matching traffic. The traffic is then inspected by Intrusion Policy A.
• Access Control Rule B allows matching traffic. The traffic is then inspected by Intrusion Policy B.
• The access control policy’s default action allows matching traffic. The traffic is then inspected by the
default action’s intrusion policy.
Each packet’s handling is governed by a network analysis policy and intrusion policy pair, but the system
does not coordinate the pair for you. Consider a scenario where you misconfigure your access control policy
so that Network Analysis Rule A and Access Control Rule A do not process the same traffic. For example,
you could intend the paired policies to govern the handling of traffic on a particular security zone, but you
mistakenly use different zones in the two rules’ conditions. This could cause traffic to be incorrectly
preprocessed. For this reason, tailoring preprocessing using network analysis rules and custom policies is an
advanced task.
Note that for a single connection, although the system selects a network analysis policy before an access
control rule, some preprocessing (notably application layer preprocessing) occurs after access control rule
selection. This does not affect how you configure preprocessing in custom network analysis policies.
A dividing line separates the navigation panel into links to policy settings you can configure with (below) or
without (above) direct interaction with policy layers. To navigate to any settings page, click its name in the
navigation panel. Dark shading of an item in the navigation panel highlights your current settings page. For
example, in the illustration above the Policy Information page would be displayed to the right of the navigation
panel.
Policy Information
The Policy Information page provides configuration options for commonly used settings. As shown in the
illustration for the network analysis policy panel above, a policy change icon ( ) appears next to Policy
Information in the navigation panel when the policy contains unsaved changes. The icon disappears when
you save your changes.
protect those assets. This allows you to tailor your intrusion policy to the specific needs of your monitored
network.
Policy Layers
The Policy Layers page displays a summary of the layers that comprise your network analysis or intrusion
policy. Expanding the Policy Layers link displays sublinks to summary pages for the layers in your policy.
Expanding each layer sublink displays further sublinks to the configuration pages for all rules, preprocessors,
or advanced settings that are enabled in the layer.
Note After you save, you must deploy the network analysis or intrusion policy for your changes to take effect.
If you deploy a policy without saving, the system uses the most recently saved configuration.
policy, the system either automatically enables required settings, or warns you that disabled settings will have
no effect on traffic, as follows:
• You cannot save an intrusion policy if you added an SNMP rule alert but did not configure SNMP
alerting. You must either configure SNMP alerting or disable the rule alert, then save again.
• You cannot save an intrusion policy if it includes enabled sensitive data rules but you have not enabled
the sensitive data preprocessor. You must either allow the system to enable the preprocessor and save
the policy, or disable the rules and save again.
• If you disable a required preprocessor in a network analysis policy, you can still save the policy. However,
the system automatically uses the disabled preprocessor with its current settings, even though the
preprocessor remains disabled in the web interface.
• If you disable inline mode in a network analysis policy but enable the Inline Normalization preprocessor,
you can still save the policy. However, the system warns you that normalization settings will be ignored.
Disabling inline mode also causes the system to ignore other settings that allow preprocessors to modify
or block traffic, including checksum verification and rate-based attack prevention.
Related Topics
Configuring Network Analysis Policy Preferences
Configuring Intrusion Policy Preferences
Procedure
If you want to exit the network analysis or intrusion policy advanced editor, you have the following choices:
• Cache — To exit the policy and cache changes, choose any menu or other path to another page. On
exiting, click Leave page when prompted, or click Stay on page to remain in the advanced editor.
• Discard — To discard unsaved changes, click Discard Changes on the Policy Information page, then
click OK.
• Save — To save changes to the policy, click Commit Changes on the Policy Information page. If
prompted, enter a comment, and then click OK.
Layer Basics
Larger organizations with many managed devices may have many intrusion policies and network analysis
policies to support the unique needs of different departments, business units or, in some instances, different
companies. Configurations in both policy types are contained in building blocks called layers, which you can
use to efficiently manage multiple policies.
Layers in intrusion and network analysis policies work in essentially the same way. You can create and edit
either policy type without consciously using layers. You can modify your policy configurations and, if you
have not added user layers to your policy, the system automatically includes your changes in a single
configurable layer that is initially named My Changes. You can also add up to 200 layers where you can
configure any combination of settings. You can copy, merge, move, and delete user layers and, most important,
share individual user layers with other policies of the same type.
Built-in Layers
The read-only base policy layer. The policy in this layer can be either a system-provided policy or a
custom policy you created.
By default, a network analysis or intrusion policy includes a base policy layer and a My Changes layer. You
can add user layers as necessary.
Each policy layer contains complete configurations for either all preprocessors in a network analysis policy
or all intrusion rules and advanced settings in an intrusion policy. The lowest, base policy layer includes all
the settings from the base policy you selected when you created the policy. A setting in a higher layer takes
precedence over the same setting in a lower layer. Features not explicitly set in a layer inherit their settings
from the next highest layer where they are explicitly set. The system flattens the layers, that is, it applies only
the cumulative effect of all settings, when it handles network traffic.
Tip You can create an intrusion or network analysis policy based solely on the default settings in the base
policy. In the case of an intrusion policy, you can also use Firepower rule state recommendations if you
want to tailor your intrusion policy to the specific needs of your monitored network.
The following figure shows an example layer stack that, in addition to the base policy layer and the initial My
Changes layer, also includes two additional user-configurable layers, User Layer 1 and User Layer 2. Note
in the figure that each user-configurable layer that you add is initially positioned as the highest layer in the
stack; thus, User Layer 2 in the figure was added last and is highest in the stack.
Regardless of whether you allow rule updates to modify your policy, changes in a rule update never override
changes you make in a layer. This is because changes in a rule update are made in the base policy, which
determines the default settings in your base policy layer; your changes are always made in a higher layer, so
they override any changes that a rule update makes to your base policy.
If you use a system-provided policy as your base, importing rule updates may modify settings in your base
policy. However, you can configure a custom policy so that the system does not automatically make these
changes to its system-provided base policy. This allows you to update system-provided base policies manually,
on a schedule independent of rule updates. In either case, changes that a rule update makes to your base policy
do not change or override settings in your My Changes or any other layer.
System-provided intrusion and network analysis policies are similarly named but contain different
configurations. For example, the Balanced Security and Connectivity network analysis policy and the Balanced
Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates.
Rule updates can also delete existing rules from system-provided policies.
Changes to default variables and rule categories are handled at the system level.
When you use a system-provided policy as your intrusion or network analysis base policy, you can allow rule
updates to modify your base policy which, in this case, is a copy of the system-provided policy. If you allow
rule updates to update your base policy, a new rule update makes the same changes in your base policy that
it makes to the system-provided policy that you use as your base policy. If you have not modified the
corresponding setting, a setting in your base policy determines the setting in your policy. However, rule
updates do not override changes you make in your policy.
If you do not allow rule updates to modify your base policy, you can manually update your base policy after
importing one or more rule updates.
Rule updates always delete intrusion rules that Talos deletes, regardless of the rule state in your intrusion
policy or whether you allow rule updates to modify your base intrusion policy.
Until you re-deploy your changes to network traffic, rules in your currently deployed intrusion policies behave
as follows:
• Disabled intrusion rules remain disabled.
• Rules set to Generate Events continue to generate events when triggered.
• Rules set to Drop and Generate Events continue to generate events and drop offending packets when
triggered.
Rule updates do not modify a custom base policy unless both of the following conditions are met:
• You allow rule updates to modify the system-provided base policy of the parent policy, that is, the policy
that originated the custom base policy.
• You have not made changes in the parent policy that override the corresponding settings in the parent’s
base policy.
When both conditions are met, changes in the rule update are passed to the child policy, that is, the policy
using the custom base policy, when you save the parent policy.
For example, if a rule update enables a previously disabled intrusion rule, and you have not modified the rule’s
state in the parent intrusion policy, the modified rule state is passed to the base policy when you save the
parent policy.
Likewise, if a rule update modifies a default preprocessor setting and you have not modified the setting in the
parent network analysis policy, the modified setting is passed to the base policy when you save the parent
policy.
You can choose a different system-provided or custom policy as your base policy.
You can chain up to five custom policies, with four of the five using one of the other four previously created
policies as its base policy; the fifth must use a system-provided policy as its base.
Procedure
Step 1 While editing your policy, click Policy Information in the navigation panel.
Step 2 You can configure the following choices:
• Choose a base policy — Choose from the Base Policy drop-down list.
• Allow rule updates to modify the base policy — Click Manage Base Policy, then check the Update
when a new Rule Update is installed check box.
Tip When you save your policy with the check box cleared and then import a rule update, an Update
Now button appears on the Base Policy summary page and the status message on the page updates
to inform you that the policy is out of date. If you want to update your base policy with the
changes in the most recently imported rule update, click Update Now.
Step 3 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Related Topics
Tailoring Intrusion Protection to Your Network Assets, on page 1533
Layer Management
The Policy Layers page provides a single-page summary of the complete layer stack for your network analysis
or intrusion policy. On this page you can add shared and unshared layers, copy, merge, move, and delete
layers, access the summary page for each layer, and access configuration pages for enabled, disabled, and
overridden configurations within each layer.
For each layer, you can view the following information:
• whether the layer is a built-in, shared user, or unshared user layer
• which layers contain the highest, that is the effective, preprocessor or advanced setting configurations,
by feature name
• in an intrusion policy, the number of intrusion rules whose states are set in the layer, and the number of
rules set to each rule state.
The Policy Layers page also provides a summary of the net effect of all enabled preprocessors (network
analysis) or advanced settings (intrusion) and, for intrusion policies, intrusion rules.
The feature name in the summary for each layer indicates which configurations are enabled, disabled,
overridden, or inherited in the layer, as follows:
You can add up to 200 layers to a network analysis or intrusion policy. When you add a layer, it appears as
the highest layer in your policy. The initial state is Inherit for all features and, in an intrusion policy, no event
filtering, dynamic state, or alerting rule actions are set.
You give a user-configurable layer a unique name when you add the layer to your policy. Later, you can
change the name and, optionally, add or modify a description that is visible when you edit the layer.
You can copy a layer, move a layer up or down within the User Layers page area, or delete a user layer,
including the initial My Changes layer. Note the following considerations:
• When you copy a layer, the copy appears as the highest layer.
• Copying a shared layer creates a layer that is initially unshared and which you can then share if you
choose.
• You cannot delete a shared layer; a layer with sharing enabled that you have not shared with another
policy is not a shared layer.
You can merge a user-configurable layer with another user-configurable layer immediately beneath it. A
merged layer retains all settings that were unique to either layer, and accepts the settings from the higher layer
if both layers included settings for the same preprocessor, intrusion rule, or advanced setting. The merged
layer retains the name of the lower layer. In the policy where you create a sharable layer that you can add to
other policies, you can merge an unshared layer immediately above the sharable layer with the sharable layer,
but you cannot merge the sharable layer with an unshared layer beneath it. In a policy where you add a shared
layer that you created in another policy, you can merge the shared layer into an unshared layer immediately
beneath it and the resulting layer is no longer shared; you cannot merge an unshared layer into a shared layer
beneath it.
Shared Layers
A shared layer is a layer you add to your policy after creating the layer in another policy where you allow it
to be shared. A sharable layer is a layer you allow to be shared.
The following figure shows an example master policy where you create the company-wide layer and site-specific
layers for sites A and B, and allow these to be shared. You then add these as shared layers to the policies for
sites A and B.
The company-wide layer in the master policy includes settings applicable to sites A and B. The site-specific
layers include settings specific to each site. For example, in the case of a network analysis policy Site A might
not have web servers on the monitored network and would not require the protection or processing overhead
of the HTTP Inspect preprocessor, but both sites would likely require TCP stream preprocessing. You could
enable TCP stream processing in the company-wide layer that you share with both sites, disable the HTTP
Inspect preprocessor in the site-specific layer that you share with Site A, and enable the HTTP Inspect
preprocessor in the site-specific layer that you share with Site B. By editing configurations in a higher layer
in the site-specific policies, you could also further tune the policy for each site if necessary with any
configuration adjustments.
It is unlikely that the flattened net settings in the example master policy would be useful for monitoring traffic,
but the time saved in configuring and updating the site-specific policies makes this a useful application of
policy layers.
Many other layer configurations are possible. For example, you could define policy layers by company, by
department, by network, or even by user. In the case of an intrusion policy, you could also include advanced
settings in one layer and rule settings in another.
You can allow a user-configurable layer to be shared with other policies of the same type (intrusion or network
analysis). When you modify a configuration within a sharable layer and then commit your changes, the system
updates all policies that share the layer and provides you with a list of all affected policies. You can only
change feature configurations in the policy where you created the layer.
You cannot disable sharing for a layer that you have added to another policy; you must first delete the layer
from the other policy or delete the other policy.
You cannot add a shared layer to a policy when your base policy is a custom policy where the layer you want
to share was created. To do so would give the policy a circular dependency.
In a multidomain deployment, you can add shared layers from ancestor policies to policies in descendant
domains.
Managing Layers
Smart License Classic License Supported Devices Supported Domains Access
Threat Protection Any Any Admin/Intrusion
Admin
Procedure
Step 1 While editing your policy, click Policy Layers in the navigation panel.
Step 2 You can take any of the following management actions on the Policy Layers page:
• Add a shared layer from another policy — Click the add shared layer icon ( ) next to User Layers,
choose the layer from the Add Shared Layer drop-down list, then click OK.
• Add an unshared layer — Click the add layer icon ( ) next to User Layers, enter a Name, and click
OK.
• Add or change the layer description — Click the edit icon ( ) next to the layer, then add or change the
Description.
• Allow a layer to be shared with another policy — Click the edit icon ( ) next to the layer, then clear
the Sharing check box.
• Change the layer name — Click the edit icon ( ) next to the layer, then change the Name.
• Copy a layer — Click the copy icon ( ) for the layer.
• Delete a layer — Click the delete icon ( ) for the layer, then click OK.
• Merge two layers — Click the merge icon ( ) for the upper of the two layers, then click OK.
• Move a layer — Click any open area in the layer summary and drag until the position arrow ( ) points
to a line above or below a layer where you want to move the layer.
Step 3 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Navigating Layers
Smart License Classic License Supported Devices Supported Domains Access
Threat Protection Any Any Admin/Intrusion
Admin
Procedure
Step 1 While editing your policy, click Policy Layers in the navigation panel.
Step 2 You can take any of the following actions to navigate through your layers:
• Access a preprocessor or advanced settings page — If you want to access a layer-level preprocessor or
advanced setting configuration page, click the feature name in the row for the layer. Configuration pages
are read-only in the base policy and in shared layers.
• Access a rule page — If you want to access a layer-level rule configuration page filtered by rule state
type, click the icon for drop and generate events ( ), generate events ( ), or disabled ( ) in the
summary for the layer. No rules are displayed if the layer contains no rules set to the selected rule state.
• Display the Policy Information page — If you want to display the Policy Information page, click Policy
Summary in the navigation panel.
• Display a layer summary page — If you want to display the summary page for a layer, click the layer
name in the row for the layer or, alternately, click the edit icon ( ) next to a user layer. You can also
click the view icon ( ) to access the read-only summary page for a shared layer.
Step 3 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
one threshold SNMP alert override a setting of the same type for the rule in a lower layer. Note that setting a threshold
overwrites any existing threshold for the rule in the layer.
one or more suppression rate-based cumulatively combine settings of the same type for each selected rule down to the first
rule state layer where a rule state is set for the rule. Settings below the layer where a rule state is set
are ignored.
one or more comment add a comment to a rule. Comments are rule-specific, not policy- or layer-specific. You
can add one or more comments to a rule in any layer.
For example, if you set a rule state to Drop and Generate Events in one layer and to Disabled in a higher layer,
the intrusion policy Rules page shows that the rule is disabled.
In another example, if you set a source-based suppression for a rule to 192.168.1.1 in one layer, and you also
set a destination-based suppression for the rule to 192.168.1.2 in another layer, the Rules page shows that the
cumulative effect is to suppress events for the source address 192.168.1.1 and the destination address
192.168.1.2. Note that suppression and rate-based rule state settings cumulatively combine settings of the
same type for each selected rule down to the first layer where a rule state is set for the rule. Settings below
the layer where a rule state is set are ignored.
Color-coding on each Rules page for a specific layer indicates whether the effective state is in a higher, lower,
or the current layer, as follows:
• red—the effective state is in a higher layer
• yellow—the effective state is in a lower layer
• unshaded—the effective state is in the current layer
Because the intrusion policy Rules page is a composite view of the net effect of all rule settings, rule states
are not color-coded on this page.
In an intrusion policy, you can set the rule state, event filtering, dynamic state, alerting, and rule comments
for a rule in any user-configurable layer. After accessing the layer where you want to make your changes,
you add settings on the Rules page for the layer the same as you would on the intrusion policy Rules page.
Procedure
Step 1 While editing your intrusion policy, expand Policy Layers in the navigation panel.
Step 2 Expand the policy layer you want to modify.
Step 3 Click Rules immediately beneath the policy layer you want to modify.
Step 4 Modify any of the settings described in Tuning Intrusion Policies Using Rules, on page 1505.
Tip To delete an individual setting from an editable layer, double-click the rule message on the Rules page
for the layer to display rule details. Click Delete next to the setting you want to delete, then click OK
twice.
Step 5 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
You can simultaneously remove a specific type of event filter, dynamic state, or alerting from multiple layers
in your intrusion policy. The system removes the selected setting and copies the remaining settings for the
rule to the highest editable layer in the policy.
The system removes the setting type downward through each layer where it is set until it removes all the
settings or encounters a layer where a rule state is set for the rule. In the latter case, it removes the setting
from that layer and stops removing the setting type.
When the system encounters the setting type in a shared layer or in the base policy, and if the highest layer
in the policy is editable, the system copies the remaining settings and rule state for the rule to that editable
layer. Otherwise, if the highest layer in the policy is a shared layer, the system creates a new editable layer
above the shared layer and copies the remaining settings and rule state for the rule to that editable layer.
Note Removing rule settings derived from a shared layer or the base policy causes any changes to this rule from
lower layers or the base policy to be ignored. To stop ignoring changes from lower layers or the base
policy, set the rule state to Inherit on the summary page for the topmost layer.
Procedure
Step 1 While editing your intrusion policy, click Rules immediately beneath Policy Information in the navigation
panel.
Tip You can also choose Policy from the layer drop-down list on the Rules page for any layer, or click
Manage Rules on the Policy Information page.
Step 2 Choose the rule or rules from which you want to remove multiple settings:
• Choose specific — If you want to choose specific rules, check the check box next to each rule.
• Choose all — If you want to choose all the rules in the current list, check the check box at the top of the
column.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
When a custom network analysis or intrusion policy where you have not added layers uses another custom
policy as its base policy, you must set a rule to inherit its rule state if:
• you delete an event filter, dynamic state, or SNMP alert that is set for the rule in the base policy, and
• you want the rule to accept subsequent changes that you make to it in the other custom policy that you
use as your base policy
Procedure
Step 1 While editing your intrusion policy, expand Policy Layers in the navigation panel.
Step 2 Expand My Changes.
Step 3 Click the Rules link immediately beneath My Changes.
Step 4 Choose the rule or rules whose settings you want to accept. You have the following choices:
• Choose specific rules — If you want to choose specific rules, check the check box next to each rule.
• Choose all rules — If you want to choose all the rules in the current list, check the check box at the top
of the column.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Because the Settings and Advanced Settings pages are composite views of all relevant settings, these page do
not use color coding to indicate the positions of effective configurations.
Procedure
Step 1 While editing your policy, expand Policy Layers in the navigation panel, then click the name of the layer you
want to modify.
Step 2 You have the following choices:
• Change the layer Name.
• Add or change the Description.
• Check or clear the Sharing check box to specify whether a layer can be shared with another policy.
• To access the configuration page for an enabled preprocessor/advanced setting, click the edit icon ( )
or the feature sublink.
• To disable a preprocessor/advanced setting in the current layer, click Disabled next to the feature.
• To enable a preprocessor/advanced setting in the current layer, click Enabled next to the feature.
• To inherit the preprocessor/advanced setting state and configuration from the settings in the highest
layer below the current layer, click Inherit.
Step 3 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Tip System-provided intrusion and network analysis policies are similarly named but contain different
configurations. For example, the Balanced Security and Connectivity network analysis policy and the
Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion
rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the
intrusion policy governs mostly intrusion rules.
For intrusion rules to affect traffic, you must correctly configure drop rules and rules that replace content, as
well as well as correctly deploy managed devices inline, that is, with inline interface sets. Finally, you must
enable the intrusion policy’s drop behavior, or Drop when Inline setting.
When tailoring your intrusion policy, especially when enabling and adding rules, keep in mind that some
intrusion rules require that traffic first be decoded or preprocessed in a certain way. Before an intrusion policy
examines a packet, the packet is preprocessed according to configurations in a network analysis policy. If you
disable a required preprocessor, the system automatically uses it with its current settings, although the
preprocessor remains disabled in the network analysis policy web interface.
Caution Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion
policies examining a single packet must complement each other. Tailoring preprocessing, especially using
multiple custom network analysis policies, is an advanced task.
After you configure a custom intrusion policy, you can use it as part of your access control configuration by
associating the intrusion policy with one or more access control rules or an access control policy’s default
action. This forces the system to use the intrusion policy to examine certain allowed traffic before the traffic
passes to its final destination. A variable set that you pair with the intrusion policy allows you to accurately
reflect your home and external networks and, as appropriate, the servers on your network.
Note that by default, the system disables intrusion inspection of encrypted payloads. This helps reduce false
positives and improve performance when an encrypted connection matches an access control rule that has
intrusion inspection configured.
On the Intrusion Policy page (Policies > Access Control > Intrusion) you can view your current custom
intrusion policies, along with the following information:
• the time and date the policy was last modified (in local time) and the user who modified it
• whether the Drop when Inline setting is enabled, which allows you to drop and modify traffic in an
inline deployment
• which access control policies and devices are using the intrusion policy to inspect traffic
• whether a policy has unsaved changes, as well as information about who (if anyone) is currently editing
the policy
• in a multidomain deployment, the domain where the policy was created
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
• Export — If you want to export an intrusion policy to import on another Firepower Management Center,
click the export icon ( ); see Exporting Configurations, on page 173.
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 298.
The base policy defines the intrusion policy’s default settings. Modifying a setting in the new policy
overrides—but does not change—the settings in the base policy. You can use either a system-provided or
custom policy as your base policy.
The intrusion policy’s drop behavior, or Drop when Inline setting, determines how the system handles drop
rules (intrusion or preprocessor rules whose rule state is set to Drop and Generate Events) and other intrusion
policy configurations that affect traffic. You should enable drop behavior in inline deployments when you
want to drop or replace malicious packets. Note that in passive deployments, the system cannot affect traffic
flow regardless of the drop behavior.
Procedure
Step 5 Set the system’s drop behavior in an inline deployment as described in Setting Drop Behavior in an Inline
Deployment, on page 1502.
Step 6 Create the policy:
• Click Create Policy to create the new policy and return to the Intrusion Policy page. The new policy
has the same settings as its base policy.
• Click Create and Edit Policy to create the policy and open it for editing in the advanced intrusion policy
editor; see Intrusion Policy Changes, on page 1502.
Related Topics
Intrusion Rules in Layers, on page 1490
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Procedure
Step 4 To save changes you made in this policy since the last policy commit, choose Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Generating and Applying Firepower Recommendations, on page 1536
Configuring Intrusion Rules in Layers, on page 1491
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Note To block the transfer of malware over FTP, you must not only correctly configure AMP for Firepower,
but also enable Drop when Inline in your access control policy’s default intrusion policy.
When you view intrusion events, workflows can include the inline result, which indicates whether traffic was
actually dropped, or whether it only would have dropped.
Procedure
Step 4 Click Commit Changes to save changes you made in this policy since the last policy commit.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
External Responses
In addition to the various views of intrusion events with in the web interface, you can enable logging to system
log (syslog) facilities or send event data to an SNMP trap server. Per policy, you can specify intrusion event
notification limits, set up intrusion event notification to external logging facilities, and configure external
responses to intrusion events.
Note that in addition to these per-policy alerting configurations, you can globally enable or disable email
alerting on intrusion events for each rule or rule group. Your email alert settings are used regardless of which
intrusion policy processes a packet.
Related Topics
Sensitive Data Detection Basics, on page 1539
Global Rule Thresholding Basics, on page 1553
If you want the Firepower System to perform intrusion detection and prevention but do not need to take
advantage of discovery data, you can optimize performance by disabling new discovery as described below.
Procedure
Step 1 Modify or delete rules associated with the access control policy deployed at the target device. None of the
access control rules associated with that device can have user, application, or URL conditions; see Creating
and Editing Access Control Rules, on page 1236.
Step 2 Delete all rules from the network discovery policy for the target device; see Configuring Network Discovery
Rules, on page 1934.
Step 3 Deploy the changed configuration to the target device; see Deploying Configuration Changes, on page 288.
conditions specified in each rule, and triggers the rule if the data packet meets all the conditions specified in
the rule.
An intrusion policy contains:
• intrusion rules, which are subdivided into shared object rules and standard text rules
• preprocessor rules, which are associated with a detection option of the packet decoder or with one of
the preprocessors included with the Firepower System
You cannot save changes to any rule created by Talos, but you can save a copy of a modified rule as a custom
rule. You can modify either variables used in the rule or rule header information (such as source and destination
ports and IP addresses). In a multidomain deployment, rules created by Talos belong to the Global domain.
Administrators in descendant domains can save local copies of the rules, which they can then edit.
For the rules it creates, Talos assigns default rule states in each default intrusion policy. Most preprocessor
rules are disabled by default and must be enabled if you want the system to generate events for preprocessor
rules and, in an inline deployment, drop offending packets.
You can adjust how rules are displayed in the intrusion policy, and can sort rules by several criteria. You can
also display the details for a specific rule to see rule settings, rule documentation, and other rule specifics.
Procedure
Heading Description
GID Integer that indicates the Generator ID (GID) for the rule.
SID Integer that indicates the Snort ID (SID), which acts a unique identifier for the rule.
For custom rules, the SID is 1000000 or higher.
Message Message included in events generated by this rule, which also acts as the name of the rule.
Heading Description
The rule state for the rule:
• Drop and generate events ( )
• Generate events ( )
• Disabled ( )
Note the icon for a disabled rule is a dimmed version of the icon for a rule that is set to generate events
without dropping traffic. Also, clicking the rule state icon for a rule allows you to change the rule state.
Event filter, including event thresholds and event suppression, applied to the rule.
Dynamic rule state for the rule, which goes into effect if specified rate anomalies occur.
You can also use the layer drop-down list to switch to the Rules page for other layers in your policy. Note
that, unless you add layers to your policy, the only editable views listed in the drop-down list are the policy
Rules page and the Rules page for a policy layer that is originally named My Changes; note also that making
changes in one of these views is the same as making the changes in the other. The drop-down list also lists
the Rules page for the read-only base policy.
Item Description
Summary The rule summary. For rule-based events, this row appears when the rule documentation contains
summary information.
Rule State The current rule state for the rule. Also indicates the layer where the rule state is set.
Firepower Recommendation If Firepower recommendations have been generated, an icon that represents the recommended
rule state; see Intrusion Rules Page Columns, on page 1507. If the recommendation is to enable
the rule, the system also indicates the network assets or configurations that triggered the
recommendation.
Item Description
Rule Overhead The rule’s potential impact on system performance and the likelihood that the rule might generate
false positives. Local rules do not have an assigned overhead, unless they are mapped to a
vulnerability.
Thresholds Thresholds currently set for this rule, as well as the facility to add a threshold for the rule.
Suppressions Suppression settings currently set for this rule, as well as the facility to add suppressions for
the rule.
Dynamic State Rate-based rule states currently set for this rule, as well as the facility to add dynamic rule states
for the rule.
Alerts SNMP alerts set for this rule, as well as the facility to add an alert for the rule.
Comments Comments added to this rule, as well as the facility to add comments for the rule.
Documentation The rule documentation for the current rule, supplied by the Cisco Talos Security Intelligence
and Research Group (Talos).
Procedure
You can set a single threshold for a rule from the Rule Detail page. Adding a threshold overwrites any existing
threshold for the rule.
Note that a revert icon ( ) appears in a field when you enter an invalid value; click it to revert to the last
valid value for that field or to clear the field if there was no previous value.
Procedure
Step 3 From the Track By drop-down list, choose Source or Destination to indicate whether you want the event
instances tracked by source or destination IP address.
Step 4 In the Count field, enter the number of event instances you want to use as your threshold.
Step 5 In the Seconds field, enter a number that specifies the time period, in seconds, for which event instances are
tracked.
Step 6 Click OK.
Tip
The system displays an event filter icon ( ) next to the rule in the Event Filtering column. If you add
multiple event filters to a rule, the system includes an indication over the icon of the number of event
filters.
You can set one or more suppressions for a rule in your intrusion policy.
Note that a revert icon ( ) appears in a field when you type an invalid value; click it to revert to the last valid
value for that field or to clear the field if there was no previous value.
Procedure
Step 3 If you chose Source or Destination for the suppression type, in the Network field enter the IP address, an
address block, or a comma-separated list comprised of any combination of these.
If the intrusion policy is associated with the default action of an access control policy, you can also specify
or list a network variable in the default action variable set.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
You can set one or more dynamic rule states for a rule. The first dynamic rule state listed has the highest
priority. When two dynamic rule states conflict, the action of the first is carried out.
Dynamic rule states are policy-specific.
Note that a revert icon ( ) appears in a field when you enter an invalid value; click it to revert to the last
valid value for that field or to clear the field if there was no previous value.
Procedure
Step 1 From an intrusion rule’s details, click Add next to Dynamic State.
Step 2 From the Track By drop-down list, choose an option to indicate how you want the rule matches tracked:
• Choose Source to track the number of hits for that rule from a specific source or set of sources.
• Choose Destination to track the number of hits for that rule to a specific destination or set of destinations.
• Choose Rule to track all matches for that rule.
Step 3 If you set Track By to Source or Destination, enter the IP address of each host you want to track in the
Network field.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
Step 4 Next to Rate, specify the number of rule matches per time period to set the attack rate:
• In the Count field, specify the number of rule matches you want to use as your threshold.
• In the Seconds field, specify the number of seconds that make up the time period for which attacks are
tracked.
Step 5 From the New State drop-down list, choose the new action to be taken when the conditions are met.
Step 6 Enter a value in the Timeout field.
After the timeout occurs, the rule reverts to its original state. Enter 0 to prevent the new action from timing
out.
You can set an SNMP alert for a rule from the Rule Detail page.
Procedure
From an intrusion rule’s details, click Add SNMP Alert next to Alerts.
Tip
The system displays an alert icon ( ) next to the rule in the Alerting column. If you add multiple
alerts to a rule, the system includes an indication over the icon of the number of alerts.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Category:"os-windows,os-linux", which retrieves any rules in the os-linux category or in the os-windows
category.
• When you choose a filter type group heading that is a keyword (Category, Classifications, Microsoft
Vulnerabilities, Microsoft Worms, Priority, and Rule Update), it lists the available arguments.
When you choose an item from this type of group, the argument and the keyword it applies to are
immediately added to the filter. If the keyword is already in the filter, it replaces the existing argument
for the keyword that corresponds to that group.
For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added
to the filter text box. If you then click os-windows under Category, the filter changes to
Category:"os-windows".
• Reference under Rule Content is a keyword, and so are the specific reference ID types listed below it.
When you choose any of the reference keywords, a pop-up window appears, where you supply an
argument and the keyword is added to the existing filter. If the keyword is already in use in the filter,
the new argument you supply replaces the existing argument.
For example, if you click Rule Content > Reference > CVE ID in the filter panel, a pop-up window
prompts you to supply the CVE ID. If you enter 2007, then CVE:”2007” is added to the filter text box. In
another example, if you click Rule Content > Referencein the filter panel, a pop-up window prompts
you to supply the reference. If you enter 2007, then Reference:”2007” is added to the filter text box.
• When you choose rule filter keywords from different groups, each filter keyword is added to the filter
and any existing keywords are maintained (unless overridden by a new value for the same keyword).
For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added
to the filter text box. If you then click MS00-006 under Microsoft Vulnerabilities, the filter changes
to Category:"os-linux" MicrosoftVulnerabilities:"MS00-006".
• When you choose multiple keywords, the system combines them using AND logic to create a compound
search filter. For example, if you choose preprocessor under Category and then choose Rule Content
> GID and enter 116, you get a filter of Category: “preprocessor” GID:”116”, which retrieves all rules
that are preprocessor rules and have a GID of 116.
• The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, and Priority filter groups
allow you to submit more than one argument for a keyword, separated by commas. For example, you
can choose os-linux and os-windows from Category to produce the filter
Category:"os-windows,app-detect", which retrieves any rules in the os-linux category or in the
os-windows category.
The same rule may be retrieved by more than one filter keyword/argument pair. For example, the DOS Cisco
attempt rule (SID 1545) appears if rules are filtered by the dos category, and also if you filter by the High
priority.
Note The Cisco Talos Security Intelligence and Research Group (Talos) may use the rule update mechanism
to add and remove rule filters.
Note that the rules on the Rules page may be either shared object rules (generator ID 3) or standard text rules
(generator ID 1, Global domain or legacy GID; 1000 - 2000, descendant domains). The following table
describes the different rule filters.
Rule Content Finds rules according to the content of the rule. No A grouping keywords
Category Finds rules according to the rule categories used by the rule Yes A keyword arguments
editor. Note that local rules appear in the local sub-group.
Classifications Finds rules according to the attack classification that appears No A keyword arguments
in the packet display of an event generated by the rule.
Microsoft Finds rules according to Microsoft bulletin number. Yes A keyword arguments
Vulnerabilities
Microsoft Finds rules based on specific worms that affect Microsoft Yes A keyword arguments
Worms Windows hosts.
Priority Finds rules according to high, medium, and low priorities. Yes A keyword arguments
The classification assigned to a rule determines its priority. Note that if you pick
These groups are further grouped into rule categories. Note one of the items from
that local rules (that is, rules that you import or create) do not the sub-list, it adds a
appear in the priority groups. modifier to the
argument.
Rule Update Finds rules added or modified through a specific rule update. No A keyword arguments
For each rule update, view all rules in the update, only new
rules imported in the update, or only existing rules changed
by the update.
When you select a keyword by clicking on a node in the criteria list, you can supply the argument you want
to filter by. If that keyword is already used in the filter, the argument you supply replaces the existing argument
for that keyword.
For example, if you click SID under Rule Content in the filter panel, a pop-up window appears, prompting
you to supply a SID. If you type 1045, then SID:”1045”is added to the filter text box. If you then click SID
again and change the SID filter to 1044, the filter changes to SID:”1044”.
Reference contain the supplied string in the reference field. You can also filter by a specific type of reference and
supplied string.
Direction are based on whether the rule includes the indicated directional setting.
Source IP use the specified addresses or variables for the source IP address designation in the rule. You can filter
by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or
$EXTERNAL_NET.
Destination IP use the specified addresses or variables for the source IP address designation in the rule. You can filter
by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or
$EXTERNAL_NET.
Source port include the specified source port. The port value must be an integer between 1 and 65535 or a port
variable.
Destination port include the specified destination port. The port value must be an integer between 1 and 65535 or a port
variable.
Metadata have metadata containing the matching key value pair. For example, type metadata:”service http” to
locate rules with metadata relating to the HTTP application protocol.
Note The Cisco Talos Security Intelligence and Research Group (Talos) may use the rule update mechanism
to add and remove rule categories.
Each rule filter can include one or more keywords in the format:
keyword:”argument”
where keyword is one of the keywords in the intrusion rule filter groups and argument is enclosed in double
quotes and is a single, case-insensitive, alphanumeric string to search for in the specific field or fields relevant
to the keyword. Note that keywords should be typed with initial capitalization.
Arguments for all keywords except gid and sid are treated as partial strings. For example, the argument 123
returns "12345", "41235", "45123", and so on. The arguments for gid and sid return only exact matches;
for example, sid:3080 returns only SID 3080.
Each rule filter can also include one or more alphanumeric character strings. Character strings search the rule
Message field, Snort ID (SID), and Generator ID (GID). For example, the string 123 returns the strings
"Lotus123", "123mania", and so on in the rule message, and also returns SID 6123, SID 12375, and so on.
You can search for a partial SID by filtering with one or more character strings.
All character strings are case-insensitive and are treated as partial strings. For example, any of the strings
ADMIN, admin, or Admin return "admin", "CFADMIN", "Administrator" and so on.
You can enclose character strings in quotes to return exact matches. For example, the literal string "overflow
attempt" in quotes returns only that exact string, whereas a filter comprised of the two strings overflow and
attempt without quotes returns "overflow attempt", "overflow multipacket attempt", "overflow with
evasion attempt", and so on.
You can narrow filter results by entering any combination of keywords, character strings, or both, separated
by spaces. The result includes any rule that matches all the filter conditions.
You can enter multiple filter conditions in any order. For example, each of the following filters returns the
same rules:
• url:at login attempt cve:200
You can filter the rules on the Rules page to display a subset of rules. You can then use any of the page
features, including choosing any of the features available in the context menu. This can be useful, for example,
when you want to set a threshold for all the rules in a specific category. You can use the same features with
rules in a filtered or unfiltered list. For example, you can apply new rule states to rules in a filtered or unfiltered
list.
All filter keywords, keyword arguments, and character strings are case-insensitive. If you click an argument
for a keyword already in the filter, it replaces the existing argument.
Procedure
• Expand a keyword, and click an argument value. For example, expand Rule State and click Generate
Events.
Generate Events
You want the system to detect a specific intrusion attempt and generate an intrusion event when it finds
matching traffic. When a malicious packet crosses your network and triggers the rule, the packet is sent
to its destination and the system generates an intrusion event. The malicious packet reaches its target,
but you are notified via the event logging.
Disable
You do not want the system to evaluate matching traffic.
Note Choosing either the Generate Events or Drop and Generate Events options enables the rule. Choosing
Disable disables the rule.
Cisco strongly recommends that you do not enable all the intrusion rules in an intrusion policy. The
performance of your managed device is likely to degrade if all rules are enabled. Instead, tune your rule
set to match your network environment as closely as possible.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation panel.
Step 4 Choose the rule or rules where you want to set the rule state.
Step 5 Choose one of the following:
• Rule State > Generate Events
• Rule State > Drop and Generate Events
• Rule State > Disable
Step 6 To save changes you made in this policy since the last policy commit, click Policy Information in the
navigation panel, then click Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Option Description
Limit Logs and displays events for the specified number of packets (specified by the Count argument) that trigger
the rule during the specified time period. For example, if you set the type to Limit, the Count to 10, and
the Seconds to 60, and 14 packets trigger the rule, the system stops logging events for the rule after displaying
the first 10 that occur within the same minute.
Option Description
Threshold Logs and displays a single event when the specified number of packets (specified by the Count argument)
trigger the rule during the specified time period. Note that the counter for the time restarts after you hit the
threshold count of events and the system logs that event. For example, you set the type to Threshold,
Count to 10, and Seconds to 60, and the rule triggers 10 times by second 33. The system generates one
event, then resets the Seconds and Count counters to 0. The rule then triggers another 10 times in the next
25 seconds. Because the counters reset to 0 at second 33, the system logs another event.
Both Logs and displays an event once per specified time period, after the specified number (count) of packets
trigger the rule. For example, if you set the type to Both, Count to two, and Seconds to 10, the following
event counts result:
• If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is
not met)
• If the rule is triggered twice in 10 seconds, the system generates one event (the threshold is met when
the rule triggers the second time)
• If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met
when the rule triggers the second time, and following events are ignored)
Next, specify tracking, which determines whether the event threshold is calculated per source or destination
IP address.
Option Description
Source Calculates event instance count per source IP address.
Finally, specify the number of instances and time period that define the threshold.
Option Description
Count The number of event instances per specified time period per tracking IP address required to meet the
threshold.
Seconds The number of seconds that elapse before the count resets. If you set the threshold type to limit, the tracking
to Source IP, the count to 10, and the seconds to 10, the system logs and displays the first 10 events that
occur in 10 seconds from a given source port. If only 7 events occur in the first 10 seconds, the system logs
and displays those; if 40 events occur in the first 10 seconds, the system logs and displays 10, then begins
counting again when the 10-second time period elapses.
Note that you can use intrusion event thresholding alone or in any combination with rate-based attack
prevention, the detection_filter keyword, and intrusion event suppression.
Tip You can also add thresholds from within the packet view of an intrusion event.
Related Topics
The detection_filter Keyword, on page 1662
Setting Threshold Options within the Packet View, on page 2301
You can set a threshold for one or more specific rules in an intrusion policy. You can also separately or
simultaneously modify existing threshold settings. You can set a single threshold for each. Adding a threshold
overwrites any existing threshold for the rule.
You can also modify the global threshold that applies by default to all rules and preprocessor-generated events
associated with the intrusion policy.
A revert icon ( ) appears in a field when you enter an invalid value; click it to revert to the last valid value
for that field or to clear the field if there was no previous value.
Tip A global or individual threshold on a managed device with multiple CPUs may result in a higher number
of events than expected.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation pane.
Step 4 Choose the rule or rules where you want to set a threshold.
Step 5 Choose Event Filtering > Threshold.
Step 6 Choose a threshold type from the Type drop-down list.
Step 7 From the Track By drop-down list, choose whether you want the event instances tracked by Source or
Destination IP address.
Step 8 Enter a value in the Count field.
Step 9 Enter a value in the Seconds field.
Step 10 Click OK.
Tip
The system displays an event filter icon ( ) next to the rule in the Event Filtering column. If you add
multiple event filters to a rule, a number over the icon indicates the number of event filters.
Step 11 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Global Rule Thresholding Basics, on page 1553
You may want to view or delete an existing threshold setting for a rule. You can use the Rules Details view
to display the configured settings for a threshold to see if they are appropriate for your system. If they are not,
you can add a new threshold to overwrite the existing values.
Note that you can also modify the global threshold that applies by default to all rules and preprocessor-generated
events logged by the intrusion policy.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation pane.
Step 4 Choose the rule or rules with a configured threshold you want to view or delete.
Step 5 To remove the threshold for each selected rule, choose Event Filtering > Remove Thresholds.
Step 6 Click OK.
Step 7 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Global Rule Thresholding Basics, on page 1553
Tip You can add suppressions from within the packet view of an intrusion event. You can also access
suppression settings by using the right-click context menu on the intrusion rules editor page (Objects >
Intrusion Rules) and on any intrusion event page (if the event was triggered by an intrusion rule).
Related Topics
The detection_filter Keyword, on page 1662
Setting Threshold Options within the Packet View, on page 2301
You can suppress intrusion event notification for a rule or rules in your intrusion policy. When notification
is suppressed for a rule, the rule triggers but events are not generated. You can set one or more suppressions
for a rule. The first suppression listed has the highest priority. When two suppressions conflict, the action of
the first is carried out.
Note that a revert icon ( ) appears in a field when you enter an invalid value; click it to revert to the last
valid value for that field or to clear the field if there was no previous value.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation panel.
Step 4 Choose the rule or rules for which you want to configure suppression conditions.
Step 5 Choose Event Filtering > Suppression.
Step 6 Choose a Suppression Type.
Step 7 If you chose Source or Destination for the suppression type, in the Network field enter the IP address, address
block, or variable you want to specify as the source or destination IP address, or a comma-separated list
comprised of any combination of these.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You may want to view or delete an existing suppression condition. For example, you can suppress event
notification for packets originating from a mail server IP address because the mail server normally transmits
packets that look like exploits. If you then decommission that mail server and reassign the IP address to another
host, you should delete the suppression conditions for that source IP address.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation panel.
Step 4 Choose the rule or rules for which you want to view or delete suppressions.
Step 5 You have the following choices:
• To remove all suppression for a rule, choose Event Filtering > Remove Suppressions.
• To remove a specific suppression setting, click the rule, then click Show details. Expand the suppression
settings and click Delete next to the suppression settings you want to remove.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
In some cases, you may not want to set a rule to the Drop and Generate Events state because you do not want
to drop every packet that matches the rule, but you do want to drop packets matching the rule if a particular
rate of matches occurs in a specified time. Dynamic rule states let you configure the rate that should trigger
a change in the action for a rule, what the action should change to when the rate is met, and how long the new
action should persist.
The following diagram shows an example where an attacker is attempting to access a host. Repeated attempts
to find a password trigger a rule which has rate-based attack prevention configured. The rate-based settings
change the rule attribute to Drop and Generate Events after rule matches occur five times in a 10-second span.
The new rule attribute times out after 15 seconds.
After the timeout, note that packets are still dropped in the rate-based sampling period that follows. If the
sampled rate is above the threshold in the current or previous sampling period, the new action continues. The
new action reverts to Generate Events only after a sampling period completes where the sampled rate was
below the threshold rate.
Note that when started, the new action occurs until the timeout is reached, even if the rate falls below the
configured rate during that time period. When the timeout is reached, if the rate has fallen below the threshold,
the action for the rule reverts to the action initially configured for the rule.
You can configure rate-based attack prevention in an inline deployment to block attacks, either temporarily
or permanently. Without rate-based configuration, rules set to Generate Events do generate events, but the
system does not drop packets for those rules. However, if the attack traffic matches rules that have rate-based
criteria configured, the rate action may cause packet dropping to occur for the period of time that the rate
action is active, even if those rules are not initially set to Drop and Generate Events.
Note Rate-based actions cannot enable disabled rules or drop traffic that matches disabled rules.
You can define multiple rate-based filters on the same rule. The first filter listed in the intrusion policy has
the highest priority. Note that when two rate-based filter actions conflict, the action of the first rate-based
filter is carried out.
You can set one or more dynamic rule states for a rule. The first dynamic rule state listed has the highest
priority. When two dynamic rule states conflict, the action of the first is carried out.
Dynamic rule states are policy-specific.
A revert icon ( ) appears in a field when you enter an invalid value; click it to revert to the last valid value
for that field or to clear the field if there was no previous value.
Note Dynamic rule states cannot enable disabled rules or drop traffic that matches disabled rules.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation pane.
Step 4 Choose the rule or rules where you want to add a dynamic rule state.
Step 5 Choose Dynamic State > Add Rate-Based Rule State.
Step 6 Choose a value from the Track By drop-down list.
Step 7 If you set Track By to Source or Destination, enter the address of each host you want to track in the Network
field. You can specify a single IP address, address block, variable, or a comma-separated list comprised of
any combination of these.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.
Step 8 Next to Rate, specify the number of rule matches per time period to set the attack rate:
• Enter a value in the Count field.
• Enter a value in the Seconds field.
Step 9 From the New State drop-down list, specify the new action to be taken when the conditions are met.
Step 10 Enter a value in the Timeout field.
After the timeout occurs, the rule reverts to its original state. Specify 0 or leave the Timeout field blank to
prevent the new action from timing out.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add comments to rules in your intrusion policy. Comments added this way are policy-specific; that
is, comments you add to a rule in one intrusion policy are not visible in other intrusion policies. Any comments
you add can be seen in the Rule Details view on the Rules page for the intrusion policy.
After you commit the intrusion policy changes containing the comment, you can also view the comment by
clicking Rule Comment on the rule Edit page.
Procedure
Step 3 Click Rules immediately under Policy Information in the navigation panel.
Step 4 Choose the rule or rules where you want to add a comment.
Step 5 Choose Comments > Add Rule Comment.
Step 6 In the Comment field, enter the rule comment.
Step 7 Click OK.
Tip
The system displays a comment icon ( ) next to the rule in the Comments column. If you add multiple
comments to a rule, a number over the icon indicates the number of comments.
Step 8 Optionally, delete a rule comment by clicking Delete next to the comment.
You can only delete a comment if the comment is cached with uncommitted intrusion policy changes. After
intrusion policy changes are committed, the rule comment is permanent.
Step 9 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can also choose either to use the recommendations immediately or to review the recommendations (and
affected rules) before accepting them.
Choosing to use recommended rule states adds a read-only Firepower Recommendations layer to your intrusion
policy, and subsequently choosing not to use recommended rule states removes the layer.
You can schedule a task to generate recommendations automatically based on the most recently saved
configuration settings in your intrusion policy.
The system does not change rule states that you set manually:
• Manually setting the states of specified rules before you generate recommendations prevents the system
from modifying the states of those rules in the future.
• Manually setting the states of specified rules after you generate recommendations overrides the
recommended states of those rules.
Tip The intrusion policy report can include a list of rules with rule states that differ from
the recommended state.
While displaying the recommendation-filtered Rules page, or after accessing the Rules page directly from the
navigation panel or the Policy Information page, you can manually set rule states, sort rules, and take any of
the other actions available on the Rules page, such as suppressing rules, setting rule thresholds, and so on.
Note TheCisco Talos Security Intelligence and Research Group (Talos) determines the appropriate state of each
rule in the system-provided policies. If you use a system-provided policy as your base policy, and you
allow the system to set your rules to the Firepower recommended rule state, the rules in your intrusion
policy match the settings recommended by Cisco for your network assets.
Base Policy Rule State Rule Protects Your Discovered Assets? Recommend Rule State
Generate Events or Disable yes Generate Events
any no Disable
When you generate recommendations without changing the advanced settings for Firepower recommended
rules, the system recommends rule state changes for all hosts in your entire discovered network.
By default, the system generates recommendations only for rules with low or medium overhead, and generates
recommendations to disable rules.
The system does not recommend a rule state for an intrusion rule that is based on a vulnerability that you
disable using the Impact Qualification feature.
The system always recommends that you enable a local rule associated with a third-party vulnerability mapped
to a host.
The system does not make state recommendations for unmapped local rules.
Related Topics
Deactivating Individual Vulnerabilities, on page 2379
Third-Party Product Mappings, on page 1862
Networks to Examine
Specifies the monitored networks or individual hosts to examine for recommendations. You can specify
a single IP address or address block, or a comma-separated list comprised of either or both.
Lists of addresses within the hosts that you specify are linked with an OR operation except for negations,
which are linked with an AND operation after all OR operations are calculated.
If you want to dynamically adapt active rule processing for specific packets based on host information,
you can also enable adaptive profile updates.
Related Topics
Firepower System IP Address Conventions, on page 12
Adaptive Profile Updates and Firepower Recommended Rules, on page 1832
Starting or stopping use of Firepower recommendations may take several minutes, depending on the size of
your network and intrusion rule set.
The system builds a separate network map for each leaf domain. In a multidomain deployment, if you enable
this feature in an intrusion policy in an ancestor domain, the system generates recommendations using data
from all descendant leaf domains. This can enable intrusion rules tailored to assets that may not exist in all
leaf domains, which can affect performance.
Procedure
Step 1 In the intrusion policy editor's navigation pane, click Firepower Recommendations.
Step 2 (Optional) Configure advanced settings; see Advanced Settings for Firepower Recommendations, on page
1535.
Step 3 Generate and apply recommendations.
• Generate and Use Recommendations—Generates recommendations and changes rule states to match.
Only available if you have never generated recommendations.
• Generate Recommendations—Regardless of whether you are using recommendations, generates new
recommendations but does not change rule states to match.
• Update Recommendations—If you are using recommendations, generates recommendations and changes
rule states to match. Otherwise, generates new recommendations without changing rule states.
• Use Recommendations—Changes rule states to match any unimplemented recommendations.
• Do Not Use Recommendations—Stops use of recommendations. If you manually changed a rule's state
before you applied recommendations, the rule state returns to the value you gave it. Otherwise, the rule
state returns to its default value.
When you generate recommendations, the system displays a summary of the recommended changes. To view
a list of rules where the system recommends a state change, click View next to the newly proposed rule state.
Step 5 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Automating Firepower Recommendations, on page 185
Individual data types identify the sensitive data you can detect and generate events on in your specified
destination network traffic. You can modify default settings for data type options that specify the following:
• a threshold that must be met for a detected data type to generate a single per-session event
You can create and modify custom data types to detect data patterns that you specify. For example, a hospital
might create a data type to protect patient numbers, or a university might create a data type to detect student
numbers that have a unique numbering pattern.
The system detects sensitive data per TCP session by matching individual data types against traffic. You can
modify the default settings for each data type and for global options that apply to all data types in your intrusion
policy. The Firepower System provides predefined, commonly used data types. You can also create custom
data types.
A sensitive data preprocessor rule is associated with each data type. You enable sensitive data detection and
event generation for each data type by enabling the corresponding preprocessor rule for the data type. A link
on the configuration page takes you to a filtered view of sensitive data rules on the Rules page, where you
can enable and disable rules and configure other rule attributes.
When you save changes to your intrusion policy, you are given the option to automatically enable the sensitive
data preprocessor if the rule associated with a data type is enabled and sensitive data detection is disabled.
Tip The sensitive data preprocessor can detect sensitive data in unencrypted Microsoft Word files that are
uploaded and downloaded using FTP or HTTP; this is possible because of the way Word files group ASCII
text and formatting commands separately.
The system does not detect encrypted or obfuscated sensitive data, or sensitive data in a compressed or encoded
format such as a Base64-encoded email attachment. For example, the system would detect the phone number
(555)123-4567, but not an obfuscated version where each number is separated by spaces, as in (5 5 5) 1 2 3
- 4 5 6 7, or by intervening HTML code, such as <b>(555)</b>-<i>123-4567</i>. However, the system would
detect, for example, the HTML coded number <b>(555)-123-4567</b> where no intervening codes interrupt
the numbering pattern.
Mask
Replaces with Xs all but the last four digits of credit card numbers and Social Security numbers in the triggering
packet. The masked numbers appear in the intrusion event packet view in the web interface and in downloaded
packets.
Networks
Specifies the destination host or hosts to monitor for sensitive data. You can specify a single IP address,
address block, or a comma-separated list of either or both. The system interprets a blank field as any, meaning
any destination IP address.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
Global Threshold
Specifies the total number of all occurrences of all data types during a single session that the preprocessor
must detect in any combination before generating a global threshold event. You can specify 1 through 65535.
Cisco recommends that you set the value for this option higher than the highest threshold value for any
individual data type that you enable in your policy.
Note the following points regarding global thresholds:
• You must enable preprocessor rule 139:1 to detect and generate events and, in an inline deployment,
drop offending packets on combined data type occurrences.
• The preprocessor generates up to one global threshold event per session.
• Global threshold events are independent of individual data type events; that is, the preprocessor generates
an event when the global threshold is reached, regardless of whether the event threshold for any individual
data type has been reached, and vice versa.
Related Topics
Firepower System IP Address Conventions, on page 12
Option Description
Data Type Specifies the unique name for the data type.
Threshold Specifies the number of occurrences of the data type when the system generates an event. You can specify
1 through 255.
Note that the preprocessor generates one event for a detected data type per session. Note also that global
threshold events are independent of individual data type events; that is, the preprocessor generates an
event when the data type event threshold is reached, regardless of whether the global event threshold has
been reached, and vice versa.
Option Description
Destination Ports Specifies destination ports to monitor for the data type. You can specify a single port, a comma-separated
list of ports, or any, meaning any destination port.
Application Protocols Specifies up to eight application protocols to monitor for the data type. You must activate application
detectors to identify application protocols to monitor.
Note that, for Classic devices, this feature requires a Control license.
Pattern Specifies the pattern to detect. This field is only present for custom data types.
Related Topics
Activating and Deactivating Detectors, on page 1909
U.S. Phone Numbers Matches U.S. phone numbers adhering to the pattern (\d{3}) 138:6
?\d{3}-\d{4}.
U.S. Social Security Matches 9-digit U.S. Social Security numbers that have valid 138:4
Numbers Without 3-digit area numbers, valid 2-digit group numbers, and do not
Dashes have dashes.
U.S. Social Security Matches 9-digit U.S. Social Security numbers that have valid 138:3
Numbers With Dashes 3-digit area numbers, valid 2-digit group numbers, and dashes.
To reduce false positives from 9-digit numbers other than Social Security numbers, the preprocessor uses an
algorithm to validate the 3-digit area number and 2-digit group number that precede the 4-digit serial number
in each Social Security number. The preprocessor validates Social Security group numbers through November
2009.
Because sensitive data detection can have a high impact on the performance of your Firepower System, Cisco
recommends that you adhere to the following guidelines:
• Choose the No Rules Active default policy as your base intrusion policy.
• Ensure that the following settings are enabled in the corresponding network analysis policy:
◦FTP and Telnet Configuration under Application Layer Preprocessors
◦IP Defragmentation and TCP Stream Configuration under Transport/Network Layer
Preprocessors.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
• If you want to inspect custom sensitive data, create a custom data type; see Custom Sensitive Data
Types, on page 1546.
Step 7 Add or remove application protocols to monitor for a data type; see Monitored Application Protocols and
Sensitive Data, on page 1544.
Note To detect sensitive data in FTP traffic, you must add the Ftp data application protocol.
Step 8 Optionally, to display sensitive data preprocessor rules, click Configure Rules for Sensitive Data Detection.
You can enable or disable any of the listed rules. You can also configure sensitive data rules for any of the
other actions available on the Rules page, such as rule suppression, rate-based attack prevention, and so on;
see Intrusion Rule Types, on page 1505 for more information.
Step 9 To save changes you made in this policy since the last policy commit, click Policy Information in the
navigation panel, then click Commit Changes.
If you enable sensitive data preprocessor rules in your policy without enabling sensitive data detection, you
are prompted to enable sensitive data detection when you save changes to your policy.
If you leave the policy without committing changes, changes since the last commit are discarded if you edit
a different policy.
What to Do Next
• If you want to generate intrusion events, enable Sensitive Data Detection rules 138:2, 138:3, 138:4,
138:5, 138:6, 138:>999999, or 139:1. For more information, see Intrusion Rule States, on page 1520,
Global Sensitive Data Detection Options, on page 1540, System-Provided Sensitive Data Types, on page
1542, and Custom Sensitive Data Types, on page 1546.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Special Case: Sensitive Data Detection in FTP Traffic, on page 1546
Related Topics
Activating and Deactivating Detectors, on page 1909
Special Case: Sensitive Data Detection in FTP Traffic, on page 1546
You can specify application protocols to monitor in both system-provided and custom sensitive data types.
The application protocols you select are policy-specific.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Special Case: Sensitive Data Detection in FTP Traffic, on page 1546
• Ensure that the FTP Data detector, which is enabled by default, is enabled.
• Ensure that your configuration includes at least one port to monitor for sensitive data.
Note that it is not necessary to specify an FTP port except in the unlikely case where you only want to detect
sensitive data in FTP traffic. Most sensitive data configurations will include other ports such as HTTP or
email ports. In the case where you do want to specify only one FTP port and no other ports to monitor, Cisco
recommends that you specify the FTP command port 23.
Related Topics
The FTP/Telnet Decoder, on page 1724
Activating and Deactivating Detectors, on page 1909
Configuring Sensitive Data Detection, on page 1543
Metacharacters are literal characters that have special meaning within regular expressions.
{n} Matches the preceding character or escape sequence n times. For example, \d{2} matches 55, 12, and so on;
\l{3} matches AbC, www, and so on; \w{3}
matches a1B, 25C, and so on; x{5} matches
xxxxx
\ Allows you to use metacharacters as actual characters and is \? matches a question mark, \\ matches a
also used to specify a predefined character class. backslash, \d matches numeric characters, and
so on
You must use a backslash to escape certain characters for the sensitive data preprocessor to interpret them
correctly as literal characters.
\{ {
\} }
\\ \
When defining a custom sensitive data pattern, you can use character classes.
\D Matches any byte that is not a numeric ASCII character not 0-9
\W Matches any byte that is not an ASCII alphanumeric character not a-zA-Z0-9
The preprocessor treats characters entered directly, instead of as part of a regular expression, as literal characters.
For example, the data pattern 1234 matches 1234.
The following data pattern example, which is used in system-provided sensitive data rule 138:4, uses the
escaped digits character class, the multiplier and option-specifier metacharacters, and the literal dash (-) and
left and right parentheses () characters to detect U.S. phone numbers:
(\d{3}) ?\d{3}-\d{4}
Exercise caution when creating custom data patterns. Consider the following alternative data pattern for
detecting phone numbers which, although using valid syntax, could cause many false positives:
(?\d{3})? ?\d{3}-?\d{4}
Because the second example combines optional parentheses, optional spaces, and optional dashes, it would
detect, among others, phone numbers in the following desirable patterns:
• (555)123-4567
• 555123-4567
• 5551234567
However, the second example pattern would also detect, among others, the following potentially invalid
patterns, resulting in false positives:
• (555 1234567
• 555)123-4567
• 555) 123-4567
Consider finally, for illustration purposes only, an extreme example in which you create a data pattern that
detects the lowercase letter a using a low event threshold in all destination traffic on a small company network.
Such a data pattern could overwhelm your system with literally millions of events in only a few minutes.
In a multidomain deployment, the system displays sensitive data types created in the current domain, which
you can edit. It also displays data types created in ancestor domains, which you can edit in a limited way. For
ancestor data types, the name and pattern fields display as read-only, but you can set the other options to
policy-specific values.
You cannot delete a data type if the sensitive data rule for that data type is enabled in any intrusion policy.
Procedure
What to Do Next
• Enable the associated custom sensitive data preprocessing rule in each policy where you want to use
that data type; see Setting Intrusion Rule States, on page 1521.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Editing Custom Sensitive Data Types, on page 1550
You can edit all fields in custom sensitive data types. Note, however, that when you modify the name or
pattern field, these settings change in all intrusion policies on the system. You can set the other options to
policy-specific values.
In a multidomain deployment, the system displays sensitive data types created in the current domain, which
you can edit. It also displays data types created in ancestor domains, which you can edit in a limited way. For
ancestor data types, the name and pattern fields display as read-only, but you can set the other options to
policy-specific values.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip A global or individual threshold on a managed device with multiple CPUs may result in a higher number
of events than expected.
The following diagram demonstrates how the global rule thresholding works. In this example, an attack is in
progress for a specific rule. The global limit threshold is set to limit event generation for each rule to two
events every 20 seconds. Note that the period starts at one second and ends at 21 seconds. After the period
ends, the cycle starts again and the next two rule matches generate events, then the system does not generate
any more events during that period.
Option Description
Limit Logs and displays events for the specified number of packets (specified by the count argument) that trigger the rule
during the specified time period.
For example, if you set the type to Limit, the Count to 10, and the Seconds to 60, and 14 packets trigger the rule, the
system stops logging events for the rule after displaying the first 10 that occur within the same minute.
Option Description
Threshold Logs and displays a single event when the specified number of packets (specified by the count argument) trigger the
rule during the specified time period. Note that the counter for the time restarts after you hit the threshold count of
events and the system logs that event.
For example, you set the type to Threshold, Count to 10, and Seconds to 60, and the rule triggers 10 times by second
33. The system generates one event, then resets the Seconds and Count counters to 0. The rule then triggers another
10 times in the next 25 seconds. Because the counters reset to 0 at second 33, the system logs another event.
Both Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the
rule.
For example, if you set the type to Both, Count to 2, and Seconds to 10, the following event counts result:
• If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is not met)
• If the rule is triggered twice in 10 seconds, the system generates one event (the threshold is met when the rule
triggers the second time)
• If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met when the
rule triggered the second time and following events are ignored)
The Track By option determines whether the event instance count is calculated per source or destination IP
address.
You can also specify the number of instances and time period that define the threshold, as follows:
Option Description
Count For a Limit threshold, the number of event instances per specified time period per tracking IP
address or address range required to meet the threshold.
For a Threshold threshold, the number of rule matches you want to use as your threshold.
Seconds For a Limit threshold, the number of seconds that make up the time period when attacks are tracked.
For a Threshold threshold, the number of seconds that elapse before the count resets. If you set
the threshold type to Limit, the tracking to Source, Count to 10, and Seconds to 10, the system
logs and displays the first 10 events that occur in 10 seconds from a given source port. If only
seven events occur in the first 10 seconds, the system logs and displays those, if 40 events occur
in the first 10 seconds, the system logs and displays 10, then begins counting again when the
10-second time period elapses.
Related Topics
Configuring Global Thresholds, on page 1556
Intrusion Event Thresholds, on page 1522
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Global Rule Thresholding Options, on page 1554
Configuring Intrusion Rules in Layers, on page 1491
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
You can disable global thresholding in the highest policy layer if you want to threshold events for specific
rules rather than applying thresholding to every rule by default.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Configuring Intrusion Rules in Layers, on page 1491
Caution Make sure you use a controlled network environment to test any intrusion rules that you write before you
use the rules in a production environment. Poorly written intrusion rules may seriously affect the
performance of the system.
In a multidomain deployment, the system displays rules created in the current domain, which you can edit. It
also displays rules created in ancestor domains, which you cannot edit. To view and edit rules created in a
lower domain, switch to that domain. The system-provided intrusion rules belong to the Global domain.
Administrators in descendant domains can make local editable copies of these system rules.
Rule Anatomy
All standard text rules contain two logical sections: the rule header and the rule options. The rule header
contains:
• the rule's action or type
• the protocol
• the source and destination IP addresses and netmasks
• direction indicators showing the flow of traffic from source to destination
• the source and destination ports
Note that the options section of a rule is the section enclosed in parentheses. The intrusion rules editor provides
an easy-to-use interface to help you build standard text rules.
The following table describes each part of the rule header shown above.
Source IP Address $EXTERNAL_NET Tests traffic coming from any host that is not on your
internal network.
Source Ports any Tests traffic coming from any port on the originating
host.
Operator -> Tests external traffic (destined for the web servers on
your network).
Note The previous example uses default variables, as do most intrusion rules.
Related Topics
Variable Sets, on page 364
Note In an inline deployment, rules with the rule state set to Drop and Generate Events generate an intrusion
event against the packet that triggered the rule. Also, if you apply a drop rule in a passive deployment,
the rule acts as an alert rule.
By default, pass rules override alert rules. You can create pass rules to prevent packets that meet criteria
defined in the pass rule from triggering the alert rule in specific situations, rather than disabling the alert rule.
For example, you might want a rule that looks for attempts to log into an FTP server as the user “anonymous”
to remain active. However, if your network has one or more legitimate anonymous FTP servers, you could
write and activate a pass rule that specifies that, for those specific servers, anonymous users do not trigger
the original rule.
Within the intrusion rules editor, you select the rule type from the Action list.
Note The system ignores port definitions in an intrusion rule header when the protocol is set
to ip.
Use IP as the protocol type to examine all protocols assigned by IANA, including TCP, UDP, ICMP, IGMP,
and many more.
Note You cannot currently write rules that match patterns in the next header (for example, the TCP header) in
an IP payload. Instead, content matches begin with the last decoded protocol. As a workaround, you can
match patterns in TCP headers by using rule options.
Within the Intrusion Rules editor, you select the protocol type from the Protocol list.
Related Topics
Intrusion Rule Header Protocol, on page 1562
Use... To Test...
Directional only traffic from the specified source IP address to the specified destination IP address
Bidirectional all traffic traveling between the specified source and destination IP addresses
Tip The system recognizes only IP addresses and does not accept host names for source or destination IP
addresses.
Within the intrusion rules editor, you specify source and destination IP addresses in the Source IPs and
Destination IPs fields.
When writing standard text rules, you can specify IPv4 and IPv6 addresses in a variety of ways, depending
on your needs. You can specify a single IP address, any, IP address lists, CIDR notation, prefix lengths, a
network variable, or a network object or network object group. Additionally, you can indicate that you want
to exclude a specific IP address or set of IP addresses. When specifying IPv6 addresses, you can use any
addressing convention defined in RFC 4291.
In a multidomain deployment, using literal IP addresses in this configuration can have unexpected results.
For example, you might create an intrusion rule in the Global domain with a literal source IP address (192.0.2.2)
and enable it in an intrusion policy used by descendant domains. In this case, you could potentially see events
in descendant domain A (where 192.0.2.2 represents DeviceA) and in descendant domain B (where 192.0.2.2
represents DeviceB), but only one set of events is a reliable indicator of intrusion vulnerability. Using
override-enabled objects allows descendant domain administrators to tailor Global configurations to their
local environments.
Note that you would not mix IPv4 and IPv6 source and destination 2001:db8::abcd
addresses in the same rule.
a list of IP addresses brackets ([]) to enclose the IP addresses and commas to separate [192.168.1.1,192.168.1.15]
them [2001:db8::b3ff, 2001:db8::0202]
a block of IP addresses IPv4 CIDR block or IPv6 address prefix notation 192.168.1.0/24
2001:db8::/32
anything except a the ! character before the IP address or addresses you want to !192.168.1.15
specific IP address or set negate
!2001:db8::0202:b3ff:fe1e
of addresses
all IP addresses except the variable name, in uppercase letters, preceded by !$ !$HOME_NET
addresses defined by an
IP address variable
IP addresses defined by the object or group name using the format !{object_name}. ${192.168sub16}
a network object or
network object group
all IP addresses except the object or group name, in curly braces ({}), preceded by !$. !${192.168sub16}
addresses defined by a
network object or
network object group
The following descritpions provide additional information on some of the IP address entry methods.
Any IP Address
You can specify the word any as a rule source or destination IP address to indicate any IPv4 or IPv6 address.
For example, the following rule uses the argument any in the Source IPs and Destination IPs fields and
evaluates packets with any IPv4 or IPv6 source or destination address:
Multiple IP Addresses
You can list individual IP addresses by separating the IP addresses with commas and, optionally, by surrounding
non-negated lists with brackets, as shown in the following example:
[192.168.1.100,192.168.1.103,192.168.1.105]
You can list IPv4 and IPv6 addresses alone or in any combination, as shown in the following example:
[192.168.1.100,2001:db8::1234,192.168.1.105]
Note that surrounding an IP address list with brackets, which was required in earlier software releases, is not
required. Note also that, optionally, you can enter lists with a space before or after each comma.
You can also use IPv4 Classless Inter-Domain Routing (CIDR) notation or IPv6 prefix lengths to specify
address blocks. For example:
• 192.168.1.0/24 specifies the IPv4 addresses in the 192.168.1.0 network with a subnet mask of
255.255.255.0, that is, 192.168.1.0 through 192.168.1.255.
• 2001:db8::/32 specifies the IPv6 addresses in the 2001:db8:: network with a prefix length of 32 bits,
that is, 2001:db8:: through 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff.
Tip If you need to specify a block of IP addresses but cannot express it using CIDR or prefix length notation
alone, you can use CIDR blocks and prefix lengths in an IP address list.
Network Objects
You can specify a network object or network object group using the syntax:
${object_name | group_name}
where:
• object_name is the name of a network object
• group_name is the name of a network object group
Consider the case where you have created a network object named 192.168sub16 and a network object group
named all_subnets. You could specify the following to identify IP addresses using the network object:
${192.168sub16}
and you could specify the following to use the network object group:
${all_subnets}
You can also use negation with network objects and network object groups. For example:
!${192.168sub16}
IP Addresses Negation
You can use an exclamation point (!) to negate a specified IP address. That is, you can match any IP address
with the exception of the specified IP address or addresses. For example, !192.168.1.1 specifies any IP
address other than 192.168.1.1, and !2001:db8:ca2e::fa4c specifies any IP address other than
2001:db8:ca2e::fa4c.
To negate a list of IP addresses, place ! before a bracketed list of IP addresses. For example,
![192.168.1.1,192.168.1.5] would define any IP address other than 192.168.1.1 or 192.168.1.5.
Be careful when using the negation character with IP address lists. For example, if you use
[!192.168.1.1,!192.168.1.5] to match any address that is not 192.168.1.1 or 192.168.1.5, the system
interprets this syntax as “anything that is not 192.168.1.1, or anything that is not 192.168.1.5.”
Because 192.168.1.5 is not 192.168.1.1, and 192.168.1.1 is not 192.168.1.5, both IP addresses match the IP
address value of [!192.168.1.1,!192.168.1.5], and it is essentially the same as using “any.”
Instead, use ![192.168.1.1,192.168.1.5]. The system interprets this as “not 192.168.1.1 and not
192.168.1.5,” which matches any IP address other than those listed between brackets.
Note that you cannot logically use negation with any which, if negated, would indicate no address.
Related Topics
Variable Sets, on page 364
Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip.
You can list ports by separating the ports with commas, as shown in the following example:
a range of ports a dash between the first and last port number in the range 80-443
all ports less than or equal to a specific a dash before the port number
-21
port
all ports greater than or equal to a a dash after the port number
80-
specific port
all ports except a specific port or range the ! character before the port, port list, or range of ports you
!20
of ports want to negate
Note that you can logically use negation with all port designations
except any, which if negated would indicate no port.
all ports defined by a port variable the variable name, in uppercase letter, preceded by $ $HTTP_PORTS
all ports except ports defined by a port the variable name, in uppercase letter, preceded by !$ !$HTTP_PORTS
variable
Message
You can specify meaningful text that appears as a message when the rule triggers. The message gives immediate
insight into the nature of the vulnerability that the rule detects attempts to exploit. You can use any printable
standard ASCII characters except curly braces ({}). The system strips quotes that completely surround the
message.
Tip You must specify a rule message. Also, the message cannot consist of white space only, one or more
quotation marks only, one or more apostrophes only, or any combination of just white space, quotation
marks, or apostrophes.
To define the event message in the intrusion rules editor, you enter the event message in the Message field.
Classification
For each rule, you can specify an attack classification that appears in the packet display of the event. The
following table lists the name and number for each classification.
Custom Classification
If you want more customized content for the packet display description of the events generated by a rule you
define, you can create a custom classification.
Argument Description
Classification Name The name of the classification. The page is difficult to read if
you use more than 40 characters. The following characters are
not supported: <>()\'"&$; and the space character.
Argument Description
Classification Description A description of the classification. You can use alphanumeric
characters and spaces. The following characters are not
supported: <>()\'"&$;
Custom Priority
By default, the priority of a rule derives from the event classification for the rule. However, you can override
the classification priority for a rule by adding the priority keyword to the rule and selecting a high, medium,
or low priority. For example, to assign a high priority for a rule that detects web application attacks, add the
priority keyword to the rule and select high as the priority.
Custom Reference
You can use the reference keyword to add references to external web sites and additional information about
the event. Adding a reference provides analysts with an immediately available resource to help them identify
why the packet triggered a rule. The following table lists some of the external systems that can provide data
on known exploits and attacks.
McAfee page
mcafee 98574
Website reference
url www.example.com?exploit=14
Nessus page
nessus 10039
id_system,id
where id_system is the system being used as a prefix, and id is the Bugtraq ID, CVE number, Arachnids ID,
or URL (without http://).
For example, to specify the authentication bypass vulnerability on Microsoft Commerce Server 2002 servers
documented in Bugtraq ID 17134, enter the value:
bugtraq,17134
Note the following when adding references to a rule:
• Do not use a space after the comma.
• Do not use uppercase letters in the system ID.
Related Topics
Adding a Custom Classification, on page 1571
Defining an Event Priority, on page 1572
Defining an Event Reference, on page 1572
In a multidomain deployment, the system displays custom classifications created in the current domain, and
you can set the priorities for these classifications. It also displays custom classifications created in ancestor
domains, but you cannot set the priorities for these classifications. To view and edit custom classifications
created in a lower domain, switch to that domain.
Procedure
Step 1 While creating or editing a rule, choose Edit Classifications from the Classification drop-down list.
If View Classifications displays instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
Step 2 Enter a Classification Name and Classification Description as described in Intrusion Event Details, on page
1567.
Step 3 Choose a priority for the classification from the Priority drop-down list.
Step 4 Click Add.
Step 5 Click Done.
What to Do Next
• Continue with creating or editing the rule. See Writing New Rules, on page 1574 or Modifying Existing
Rules, on page 1575 for more information.
Related Topics
Custom Rule Creation, on page 1573
Procedure
Step 1 While creating or editing a rule, choose priority from the Detection Options drop-down list.
Step 2 Click Add Option.
Step 3 Choose a value from the priority drop-down list.
Step 4 Click Save.
What to Do Next
• Continue with creating or editing the rule. See Writing New Rules, on page 1574 or Modifying Existing
Rules, on page 1575 for more information.
Related Topics
Custom Rule Creation, on page 1573
Procedure
Step 1 While creating or editing a rule, choose reference from the Detection Options drop-down list.
Step 2 Click Add Option.
Step 3 Enter a value in the reference field as described in Intrusion Event Details, on page 1567.
Step 4 Click Save.
What to Do Next
• Continue with creating or editing the rule. See Writing New Rules, on page 1574 or Modifying Existing
Rules, on page 1575 for more information.
Related Topics
Custom Rule Creation, on page 1573
The system saves the custom rule in the local rule category, regardless of the method you used to create it.
When you create a custom intrusion rule, the system assigns it a unique rule number, which has the format
GID:SID:Rev. The elements of this number are:
GID
Generator ID. For all standard text rules, this value is 1 (Global domain or legacy GID) or 1000 - 2000
(descendant domains). For all shared object rules you save as new, this value is 1.
SID
Snort ID. Indicates whether the rule is a local rule of a system rule. When you create a new rule, the
system assigns the next available SID for a local rule.
SID numbers for local rules start at 1000000, and the SID for each new local rule is incremented by
one.
Rev
The revision number. For a new rule, the revision number is one. Each time you modify a custom rule
the revision number increments by one.
In a custom standard text rule, you set the rule header settings and the rule keywords and arguments. You can
use the rule header settings to focus the rule to only match traffic using a specific protocol and traveling to or
from specific IP addresses or ports.
In a custom system-provided standard text rule or shared object rule, you are limited to modifying rule header
information such as the source and destination ports and IP addresses. You cannot modify the rule keywords
or arguments.
Modifying header information for a shared object rule and saving your changes creates a new instance of the
rule with a generator ID (GID) of 1 (Global domain) or 1000 - 2000 (descendant domains) and the next
available SID for a custom rule. The system links the new instance of the shared object rule to the reserved
soid keyword, which maps the rule you create to the rule created by the Cisco Talos Security Intelligence
and Research Group (Talos). You can delete instances of a shared object rule that you create, but you cannot
delete shared object rules created by Talos.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
• Choose Objects > Intrusion Rules.
The system uses the value any if you do not specify a value for these fields.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results.
Step 6 Choose a value from the Detection Options drop-down list.
Step 7 Click Add Option.
Step 8 Enter any arguments for the keyword you added.
Step 9 Optionally, repeat steps 6 to 8.
Step 10 If you added multiple keywords, you can:
• Reorder keywords — Click the up or down arrow next to the keyword you want to move.
What to Do Next
• Enable your new or changed rules within the appropriate intrusion policy; see Viewing Intrusion Rules
in an Intrusion Policy, on page 1506.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can modify custom intrusion rules. In a multidomain deployment, you can modify custom intrusion rules
that belong to the current domain only.
You can save system-provided rules and rules belonging to ancestor domains as new custom rules in the local
rule category, which you can then modify.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
• Choose Objects > Intrusion Rules.
Step 2 Locate the rule you want to modify. You have the following choices:
• Navigate through the folders to the rule.
• Search for the rule; see Searching for Rules, on page 1578.
• Filter for the group to which the rule belongs; see Filtering Rules, on page 1582.
• Click Save if you are editing a custom rule and want to overwrite the current version of that rule.
• Click Save As New if you are editing a system-provided rule or any rule belonging to an ancestor domain,
or if you are editing a custom rule and want to save the changes as a new rule.
What to Do Next
• If you want to use the local modification of the rule instead of the system-provided rule, deactivate the
system-provided rule by using the procedures at Intrusion Rule States, on page 1520 and activate the local
rule.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Searching for Rules, on page 1578
Rule Filtering on the Intrusion Rules Editor Page, on page 1580
You can add comments to any intrusion rule. Such comments can be helpful to provide context and additional
information about the rule and the exploit or policy violation it identifies.
In a multidomain deployment, the system displays comments created in the current domain, which you can
delete. It also displays comments created in ancestor domains, which you cannot delete. To view comments
created in a lower domain, switch to that domain.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
• Choose Objects > Intrusion Rules.
Step 2 Locate the rule you want to annotate. You have the following choices:
• Navigate through the folders to the rule.
• Search for the rule; see Searching for Rules, on page 1578.
• Filter for the group where the rule belongs; see Filtering Rules, on page 1582.
If a view icon ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have
permission to modify the rule.
What to Do Next
• Continue with creating or editing the rule. See Writing New Rules, on page 1574 or Modifying Existing
Rules, on page 1575 for more information.
Related Topics
Searching for Rules, on page 1578
Event Information Fields, on page 2297
You can delete custom rules if the rules are not currently enabled in an intrusion policy. You cannot delete
either standard text rules or shared object rules provided by the system. In a multidomain deployment, you
can delete local rules created in the current domain only.
The system stores deleted rules in the deleted category, and you can use a deleted rule as the basis for a new
rule. The Rules page in an intrusion policy does not display the deleted category, so you cannot enable deleted
custom rules.
Tip Custom rules include shared object rules that you save with modified header information. The system also
saves these in the local rule category and lists them with a GID of 1 (Global domain or legacy GID) or
1000 - 2000 (descendant domains). You can delete your modified version of a shared object rule, but you
cannot delete the original shared object rule.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
( ) next to a rule you want to delete, and click OK to confirm the deletion.
Related Topics
Intrusion Rule States, on page 1520
The Firepower System provides thousands of standard text rules, and the Cisco Talos Security Intelligence
and Research Group (Talos) continues to add rules as new vulnerabilities and exploits are discovered. You
can easily search for specific rules so that you can activate, deactivate, or edit them.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
• Choose Objects > Intrusion Rules.
What to Do Next
• If you want to view or edit a located rule (or a copy of the rule, if it is a system rule), click the hyperlinked
rule message. See Writing New Rules, on page 1574 or Modifying Existing Rules, on page 1575 for more
information.
Option Description
Signature ID To search for a single rule based on Snort ID (SID), enter an SID number. To search for multiple rules,
enter a comma-separated list of SID numbers. This field has an 80-character limit.
Generator ID To search for standard text rules, select 1. To search for shared object rules, select 3.
Message To search for a rule with a specific message, enter a single word from the rule message in the Message
field. For example, to search for DNS exploits, you would enter DNS, or to search for buffer overflow
exploits, enter overflow.
Protocol To search rules that evaluate traffic of a specific protocol, select the protocol. If you do not select a
protocol, search results contain rules for all protocols.
Source Port To search for rules that inspect packets originating from a specified port, enter a source port number or
a port-related variable.
Destination Port To search for rules that inspect packets destined for a specific port, enter a destination port number or a
port-related variable.
Source IP To search for rules that inspect packets originating from a specified IP address, enter a source IP address
or an IP address-related variable.
Destination IP To search for rules that inspect packets destined for a specified IP address, enter a destination IP address
or an IP address-related variable.
Keyword To search for specific keywords, you can use the keyword search options. You select a keyword and
enter a keyword value for which to search. You can also precede the keyword value with an exclamation
point (!) to match any value other than the specified value.
Category To search for rules in a specific category, select the category from the Category list.
Classification To search for rules that have a specific classification, select the classification name from the Classification
list.
Rule State To search for rules within a specific policy and a specific rule state, select the policy from the first Rule
State list, and choose a state from the second list to search for rules set to Generate Events, Drop and
Generate Events, or Disabled.
Filtering Guidelines
Your filter can include special keywords and their arguments, character strings, and literal character strings
in quotes, with spaces separating multiple filter conditions. A filter cannot include regular expressions, wild
card characters, or any special operator such as a negation character (!), a greater than symbol (>), less than
symbol (<), and so on.
All keywords, keyword arguments, and character strings are case-insensitive. Except for the gid and sid
keywords, all arguments and strings are treated as partial strings. Arguments for gid and sid return only exact
matches.
You can expand a folder on the original, unfiltered page and the folder remains expanded when the subsequent
filter returns matches in that folder. This can be useful when the rule you want to find is in a folder that contains
a large number of rules.
You cannot constrain a filter with a subsequent filter. Any filter you enter searches the entire rules database
and returns all matching rules. When you enter a filter while the page still displays the result of a previous
filter, the page clears and returns the result of the new filter instead.
You can use the same features with rules in a filtered or unfiltered list. For example, you can edit rules in a
filtered or unfiltered list on the intrusion rules editor page. You can also use any of the options in the context
menu for the page.
Tip Filtering may take significantly longer when the combined total of rules in all sub-groups is large because
rules appear in multiple categories, even when the total number of unique rules is much smaller.
Keyword Filtering
Each rule filter can include one or more keywords in the format:
keyword:argument
where keyword is one of the keywords in the following table and argument is a single, case-insensitive,
alphanumeric string to search for in the specific field or fields relevant to the keyword.
Arguments for all keywords except gid and sid are treated as partial strings. For example, the argument 123
returns "12345", "41235", "45123", and so on. The arguments for gid and sid return only exact matches;
for example, sid:3080 returns only SID 3080.
Tip You can search for a partial SID by filtering with one or more character strings.
The following table describes the specific filtering keywords and arguments you can use to filter rules.
Returns one or more rules based on all or part of the Bugtraq ID in a rule
bugtraq bugtraq:2120
reference.
Returns one or more rules based on all or part of the CVE number in a rule
cve cve:2003-0109
reference.
The argument 1 returns standard text rules. The argument 3 returns shared
gid gid:3
object rules.
Returns one or more rules based on all or part of the McAfee ID in a rule
mcafee mcafee:10566
reference.
Returns one or more rules based on all or part of the rule Message field,
msg msg:chat
also known as the event message.
Returns one or more rules based on all or part of the Nessus ID in a rule
nessus nessus:10737
reference.
Returns one or more rules based on all or part of the URL in a rule reference.
url url:faqs.org
Related Topics
Defining an Event Reference, on page 1572
Intrusion Event Details, on page 1567
Preprocessor Generator IDs, on page 2289
All character strings are case-insensitive and are treated as partial strings. For example, any of the strings
ADMIN, admin, or Admin return "admin", "CFADMIN", "Administrator" and so on.
You can enclose character strings in quotes to return exact matches. For example, the literal string "overflow
attempt" in quotes returns only that exact string, whereas a filter comprised of the two strings overflow and
attempt without quotes returns "overflow attempt", "overflow multipacket attempt", "overflow with
evasion attempt", and so on.
Related Topics
Intrusion Event Details, on page 1567
Preprocessor Generator IDs, on page 2289
Filtering Rules
Smart License Classic License Supported Devices Supported Domains Access
Threat Protection Any Any Admin/Intrusion
Admin
On the Intrusion Rules page, you can filter rules into subsets so you can more easily find specific rules. You
can then use any of the page features, including choosing any of the features available in the context menu.
Rule filtering can be particularly useful to locate a specific rule to edit.
Procedure
Step 1 Access the intrusion rules using either of the following methods:
• Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
• Choose Objects > Intrusion Rules.
• Choose a different grouping method from the Group Rules By drop-down list.
Step 3 Enter filter constraints in the text box next to the filter icon ( ) under the Group Rules By list.
Step 4 Press Enter.
Note Clear the current filtered list by clicking the filter clearing icon
( ).
Related Topics
About Adaptive Profiles, on page 1831
content
When you use the content keyword, the rules engine searches the packet payload or stream for that string.
For example, if you enter /bin/sh as the value for one of the content keywords, the rules engine searches
the packet payload for the string /bin/sh.
Match content using either an ASCII string, hexadecimal content (binary byte code), or a combination of both.
Surround hexadecimal content with pipe characters (|) in the keyword value. For example, you can mix
hexadecimal content and ASCII content using something that looks like |90C8 C0FF FFFF|/bin/sh.
You can specify multiple content matches in a single rule. To do this, use additional instances of the content
keyword. For each content match, you can indicate that content matches must be found in the packet payload
or stream for the rule to trigger.
Caution You may invalidate your intrusion policy if you create a rule that includes only one content keyword and
that keyword has the Not option selected.
protected_content
The protected_content keyword allows you to encode your search content string before configuring the
rule argument. The original rule author uses a hash function (SHA-512, SHA-256, or MD5) to encode the
string before configuring the keyword.
When you use the protected_content keyword instead of the content keyword, there is no change to how
the rules engine searches the packet payload or stream for that string and most of the keyword options function
as expected. The following table summarizes the exceptions, where the protected_content keyword options
differ from the content keyword options.
Option Description
Hash Type New option for the protected_content rule keyword.
Cisco recommends that you include at least one content keyword in rules that include a protected_content
keyword to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and
improves performance. Position the content keyword before the protected_content keyword in the rule.
Note that the rules engine uses the fast pattern matcher when a rule includes at least one content keyword,
regardless of whether you enable the content keyword Use Fast Pattern Matcher argument.
Caution You may invalidate your intrusion policy if you create a rule that includes only one protected_content
keyword and that keyword has the Not option selected.
Related Topics
Custom Rule Creation, on page 1573
Basic content and protected_content Keyword Arguments, on page 1585
The replace Keyword, on page 1594
Case Insensitive
Note This option is not supported when configuring the protected_content keyword.
You can instruct the rules engine to ignore case when searching for content matches in ASCII strings. To
make your search case-insensitive, check Case Insensitive when specifying a content search.
Hash Type
Use the Hash Type drop-down to identify the hash function you used to encode your search string. The system
supports SHA-512, SHA-256, and MD5 hashing for protected_content search strings. If the length of your
hashed content does not match the selected hash type, the system does not save the rule.
The system automatically selects the Cisco-set default value. When Default is selected, no specific hash
function is written into the rule and the system assumes SHA-512 for the hash function.
Raw Data
The Raw Data option instructs the rules engine to analyze the original packet payload before analyzing the
normalized payload data (decoded by a network analysis policy) and does not use an argument value. You
can use this keyword when analyzing telnet traffic to check the telnet negotiation options in the payload before
normalization.
You cannot use the Raw Data option together in the same content or protected_content keyword with
any HTTP content option.
Tip You can configure the HTTP Inspect preprocessor Client Flow Depth and Server Flow Depth options
to determine whether raw data is inspected in HTTP traffic, and how much raw data is inspected.
Not
Select the Not option to search for content that does not match the specified content. If you create a rule that
includes a content or protected_content keyword with the Not option selected, you must also include in
the rule at least one other content or protected_content keyword without the Not option selected.
Caution Do not create a rule that includes only one content or protected_content keyword if that keyword has
the Not option selected. You may invalidate your intrusion policy.
For example, SMTP rule 1:2541:9 includes three content keywords, one of which has the Not option selected.
A custom rule based on this rule would be invalid if you removed all of the content keywords except the one
with the Not option selected. Adding such a rule to your intrusion policy could invalidate the policy.
Tip You cannot select the Not check box and the Use Fast Pattern Matcher check box with the same content
keyword.
When you specify only one of a pair, the default for the other option in the pair is assumed.
You cannot mix the Offset and Depth options with the Distance and Within options. For example, you cannot
pair Offset and Within. You can use any number of location options in a rule.
When no location is specified, the defaults for Offset and Depth are assumed; that is, the content search starts
at the beginning of the packet payload and continues to the end of the packet.
You can also use an existing byte_extract variable to specify the value for a location option.
Related Topics
The byte_extract Keyword, on page 1600
• Use Length and Offset together to search for the protected string relative to the beginning of the packet
payload.
• Use Length and Distance together to search for the protected string relative to the current search location.
Tip You cannot mix the Offset and Distance options within a single keyword configuration, but you can use
any number of location options in a rule.
When no location is specified, the defaults are assumed; that is, the content search starts at the beginning of
the packet payload and continues to the end of the packet.
You can also use an existing byte_extract variable to specify the value for a location option.
Related Topics
The byte_extract Keyword, on page 1600
Depth
Note This option is only supported when configuring the content keyword.
Specifies the maximum content search depth, in bytes, from the beginning of the offset value, or if no offset
is configured, from the beginning of the packet payload.
For example, in a rule with a content value of cgi-bin/phf, and offset value of 3, and a depth value of 22,
the rule starts searching for a match to the cgi-bin/phf string at byte 3, and stops after processing 22 bytes
(byte 25) in packets that meet the parameters specified by the rule header.
You must specify a value that is greater than or equal to the length of the specified content, up to a maximum
of 65535 bytes. You cannot specify a value of 0.
The default depth is to search to the end of the packet.
Distance
Instructs the rules engine to identify subsequent content matches that occur a specified number of bytes after
the previous successful content match.
Because the distance counter starts at byte 0, specify one less than the number of bytes you want to move
forward from the last successful content match. For example, if you specify 4, the search begins at the fifth
byte.
You can specify a value of -65535 to 65535 bytes. If you specify a negative Distance value, the byte you
start searching on may fall outside the beginning of a packet. Any calculations will take into account the bytes
outside the packet, even though the search actually starts on the first byte in the packet. For example, if the
current location in the packet is the fifth byte, and the next content rule option specifies a Distance value of
-10 and a Within value of 20, the search starts at the beginning of the payload and the Within option is adjusted
to 15.
The default distance is 0, meaning the current location in the packet subsequent to the last content match.
Length
Note This option is only supported when configuring the protected_content keyword.
The Length protected_content keyword option indicates the length, in bytes, of the unhashed search string.
For example, if you used the content Sample1 to generate a secure hash, use 7 for the Length value. You must
enter a value in this field.
Offset
Specifies in bytes where in the packet payload to start searching for content relative to the beginning of the
packet payload. You can specify a value of 65535 to 65535 bytes.
Because the offset counter starts at byte 0, specify one less than the number of bytes you want to move forward
from the beginning of the packet payload. For example, if you specify 7, the search begins at the eighth byte.
The default offset is 0, meaning the beginning of the packet.
Within
Note This option is only supported when configuring the content keyword.
The Within option indicates that, to trigger the rule, the next content match must occur within the specified
number of bytes after the end of the last successful content match. For example, if you specify a Within value
of 8, the next content match must occur within the next eight bytes of the packet payload or it does not meet
the criteria that triggers the rule.
You can specify a value that is greater than or equal to the length of the specified content, up to a maximum
of 65535 bytes.
The default for Within is to search to the end of the packet.
Note that although the rules engine searches the raw, unnormalized status fields, these options are listed here
separately to simplify explanation below of the restrictions to consider when combining other raw HTTP
fields and normalized HTTP fields.
Five options search normalized fields in HTTP requests, responses, or both, as appropriate :
• HTTP URI
• HTTP Method
• HTTP Header
• HTTP Cookie
• HTTP Client Body
Three options search raw (unnormalized) non-status fields in HTTP requests, responses, or both, as appropriate:
• HTTP Raw URI
• HTTP Raw Header
• HTTP Raw Cookie
• To take advantage of HTTP Inspect preprocessor normalization, and to improve performance, any
HTTP-related rule you create should at a minimum include at least one content or protected_content
keyword with an HTTP URI, HTTP Method, HTTP Header, or HTTP Client Body option selected.
• You cannot use the replace keyword in conjunction with HTTP content or protected_content keyword
options.
You can specify a single normalized HTTP option or status field, or use normalized HTTP options and status
fields in any combination to target a content area to match. However, note the following restrictions when
using HTTP field options:
• You cannot use the Raw Data option together in the same content or protected_content keyword
with any HTTP option.
• You cannot use a raw HTTP field option (HTTP Raw URI, HTTP Raw Header, or HTTP Raw
Cookie) together in the same content or protected_content keyword with its normalized counterpart
(HTTP URI, HTTP Header, or HTTP Cookie, respectively).
• You cannot select Use Fast Pattern Matcher in combination with one or more of the following HTTP
field options:
HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP
Status Message, or HTTP Status Code
However, you can include the options above in a content or protected_content keyword that also
uses the fast pattern matcher to search one of the following normalized fields:
HTTP URI, HTTP Header, or HTTP Client Body
For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules
engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher
is applied only to the HTTP header, not to the HTTP cookie.
• When you combine restricted and unrestricted options, the fast pattern matcher searches only the
unrestricted fields you specify to test whether to pass the rule to the intrusion rules editor for complete
evaluation, including evaluation of the restricted fields.
Related Topics
content Keyword Fast Pattern Matcher Arguments, on page 1592
HTTP URI
Select this option to search for content matches in the normalized request URI field.
Note that you cannot use this option in combination with the pcre keyword HTTP URI (U) option to search
the same content.
Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules
engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a
content match.
Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules
engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a
content match.
HTTP Method
Select this option to search for content matches in the request method field, which identifies the action such
as GET and POST to take on the resource identified in the URI.
HTTP Header
Select this option to search for content matches in the normalized header field, except for cookies, in HTTP
requests; also in responses when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled.
Note that you cannot use this option in combination with the pcre keyword HTTP header (H) option to search
the same content.
Note that you cannot use this option in combination with the pcre keyword HTTP raw header (D) option to
search the same content.
HTTP Cookie
Select this option to search for content matches in any cookie identified in a normalized HTTP client request
header; also in response set-cookie data when the HTTP Inspect preprocessor Inspect HTTP Responses
option is enabled. Note that the system treats cookies included in the message body as body content.
You must enable the HTTP Inspect preprocessor Inspect HTTP Cookies option to search only the cookie
for a match; otherwise, the rules engine searches the entire header, including the cookie.
Note the following:
• You cannot use this option in combination with the pcre keyword HTTP cookie (C) option to search
the same content.
• The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that
terminates the header line are inspected as part of the header and not as part of the cookie.
Related Topics
pcre Modifier Options, on page 1608
Server-Level HTTP Normalization Options, on page 1733
Note These options are not supported when configuring the protected_content keyword.
The fast pattern matcher quickly determines which rules to evaluate before passing a packet to the rules engine.
This initial determination improves performance by significantly reducing the number of rules used in packet
evaluation.
By default, the fast pattern matcher searches packets for the longest content specified in a rule; this is to
eliminate as much as possible needless evaluation of a rule. Consider the following example rule fragment:
alert tcp any any -> any 80 (msg:"Exploit"; content:"GET";
http_method; nocase; content:"/exploit.cgi"; http_uri;
nocase;)
Almost all HTTP client requests contain the content GET, but few will contain the content /exploit.cgi.
Using GET as the fast pattern content would cause the rules engine to evaluate this rule in most cases and would
rarely result in a match. However, most client GET requests would not be evaluated using /exploit.cgi, thus
increasing performance.
The rules engine evaluates the packet against the rule only when the fast pattern matcher detects the specified
content. For example, if one content keyword in a rule specifies the content short, another specifies longer,
and a third specifies longest, the fast pattern matcher will use the content longest and the rule will be
evaluated only if the rules engine finds longest in the payload.
• You can specify Use Fast Pattern Matcher only one time per rule.
• You cannot use Distance, Within, Offset, or Depth when you select Use Fast Pattern Matcher in
combination with Not.
• You cannot select Use Fast Pattern Matcher in combination with any of the following HTTP field options:
HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP
Status Message, or HTTP Status Code
However, you can include the options above in a content keyword that also uses the fast pattern matcher
to search one of the following normalized fields:
HTTP URI, HTTP Header, or HTTP Client Body
For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules
engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher
is applied only to the HTTP header, not to the HTTP cookie.
Note that you cannot use a raw HTTP field option (HTTP Raw URI, HTTP Raw Header, or HTTP
Raw Cookie) together in the same content keyword with its normalized counterpart (HTTP URI,
HTTP Header, or HTTP Cookie, respectively).
When you combine restricted and unrestricted options, the fast pattern matcher searches only the
unrestricted fields you specify to test whether to pass the packet to the rules engine for complete
evaluation, including evaluation of the restricted fields.
• Optionally, when you select Use Fast Pattern Matcher you can also select Fast Pattern Matcher
Only or Fast Pattern Matcher Offset and Length, but not both.
• You cannot use the fast pattern matcher when inspecting Base64 data.
◦byte_jump
◦byte_test
◦byte_math
◦byte_extract
◦base64_decode
offset,length
For example, for the content:
1234567
if you specify the number of offset and length bytes as:
1,5
the fast pattern matcher searches only for the content 23456.
Note that you cannot use this option together with Fast Pattern Matcher Only.
Related Topics
Overview: HTTP content and protected_content Keyword Arguments, on page 1588
The base64_decode and base64_data Keywords, on page 1676
Note You cannot use the replace keyword to replace hashed content in a protected_content keyword.
Optionally, you can enclose the replacement string in quotation marks for backward compatibility with previous
Firepower System software versions. If you do not include quotation marks, they are added to the rule
automatically so the rule is syntactically correct. To include a leading or trailing quotation mark as part of the
replacement text, you must use a backslash to escape it, as shown in the following example:
A rule can contain multiple replace keywords, but only one per content keyword. Only the first instance of
the content found by the rule is replaced.
The following are example uses of the replace keyword:
• If the system detects an incoming packet that contains an exploit, you can replace the malicious string
with a harmless one. Sometimes this technique is more successful than simply dropping the offending
packet. In some attack scenarios, the attacker simply resends the dropped packet until it bypasses your
network defenses or floods your network. By substituting one string for another rather than dropping
the packet, you may trick the attacker into believing that the attack was launched against a target that
was not vulnerable.
• If you are concerned about reconnaissance attacks that try to learn whether you are running a vulnerable
version of, for example, a web server, then you can detect the outgoing packet and replace the banner
with your own text.
Note Make sure that you set the rule state to Generate Events in the inline intrusion policy where you want to
use the replace rule; setting the rule to Drop and Generate events would cause the packet to drop, which
would prevent replacing the content.
As part of the string replacement process, the system automatically updates the packet checksums so that the
destination host can receive the packet without error.
Note that you cannot use the replace keyword in combination with HTTP request message content keyword
options.
Related Topics
The content and protected_content Keywords, on page 1583
Overview: HTTP content and protected_content Keyword Arguments, on page 1588
Argument Description
Bytes The number of bytes to pick up from the packet.
If used without DCE/RPC, the allowed values are 0 to 10, with the following
restrictions:
• If used with the From End argument, bytes can be 0. If Bytes is 0, the extracted
value is 0.
• If you specify a number of bytes other than 1, 2, or 4, you must specify a Number
Type (hexadecimal, octal, or decimal.)
Offset The number of bytes into the payload to start processing. The offset counter starts
at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you
want to jump forward from the beginning of the packet payload or the last successful
content match.
You can specify -65535 to 65535 bytes.
You can also use an existing byte_extract variable or byte_math result to specify
the value for this argument.
The following table describes options you can use to define how the system interprets the values you specified
for the required arguments.
Argument Description
Relative Makes the offset relative to the last pattern found in the last successful content match.
Align Rounds the number of converted bytes up to the next 32-bit boundary.
Multiplier Indicates the value by which the rules engine should multiply the byte_jump value
obtained from the packet to get the final byte_jump value.
That is, instead of skipping the number of bytes defined in a specified byte segment,
the rules engine skips that number of bytes multiplied by an integer you specify with
the Multiplier argument.
Post Jump Offset The number of bytes -65535 through 65535 to skip forward or backward after applying
other byte_jump arguments. A positive value skips forward and a negative value skips
backward. Leave the field blank or enter 0 to disable.
Note that some byte_jump arguments do not apply when you select the DCE/RPC
argument.
Argument Description
From Beginning Indicates that the rules engine should skip the specified number of bytes in the payload
starting from the beginning of the packet payload, instead of from the current position
in the packet.
From End The jump will originate from the byte that follows the last byte of the buffer.
Bitmask Applies the specified hexadecimal bitmask using the AND operator to the bytes
extracted from the Bytes argument.
A bitmask can be 1 to 4 bytes.
The result will be right-shifted by the number of bits equal to the number of trailing
zeros in the mask.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
DCE/RPC Specifies a byte_jump keyword for traffic processed by the DCE/RPC preprocessor.
The DCE/RPC preprocessor determines big endian or little endian byte order, and the
Number Type and Endian arguments do not apply.
When you enable this argument, you can also use byte_jump in conjunction with other
specific DCE/RPC keywords.
Define how the system views string data in a packet by using one of the arguments in the following table.
Argument Description
Hexadecimal String Represents converted string data in hexadecimal format.
For example, if the values you set for byte_jump are as follows:
• Bytes = 4
• Offset = 12
• Relative enabled
• Align enabled
the rules engine calculates the number described in the four bytes that appear 13 bytes after the last successful
content match, and skips ahead that number of bytes in the packet. For instance, if the four calculated bytes
in a specific packet were 00 00 00 1F, the rules engine would convert this to 31. Because align is specified
(which instructs the engine to move to the next 32-bit boundary), the rules engine skips ahead 32 bytes in the
packet.
Alternately, if the values you set for byte_jump are as follows:
• Bytes = 4
• Offset = 12
• From Beginning enabled
• Multiplier = 2
the rules engine calculates the number described in the four bytes that appear 13 bytes after the beginning of
the packet. Then, the engine multiplies that number by two to obtain the total number of bytes to skip. For
instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert
this to 31, then multiply it by two to get 62. Because From Beginning is enabled, the rules engine skips the
first 63 bytes in the packet.
Related Topics
The byte_extract Keyword, on page 1600
DCE/RPC Keywords, on page 1634
Argument Description
Bytes The number of bytes to calculate from the packet.
If used without DCE/RPC, the allowed values are 1 to 10. However, if you specify a
number of bytes other than 1, 2, or 4, you must specify a Number Type (hexadecimal,
octal, or decimal.).
If used with DCE/RPC, allowed values are 1, 2, and 4.
Argument Description
Value Value to test, including its operator.
Supported operators: <, >, =, !, &, ^, !>, !<, !=, !&, or !^.
For example, if you specify !1024, byte_test would convert the specified number,
and if it did not equal 1024, it would generate an event (if all other keyword parameters
matched).
Note that ! and != are equivalent.
You can also use an existing byte_extract variable or byte_math result to specify
the value for this argument.
Offset The number of bytes into the payload to start processing. The offset counter starts
at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you
want to count forward from the beginning of the packet payload or the last successful
content match.
You can use an existing byte_extract variable or byte_math result to specify the
value for this argument.
You can further define how the system uses byte_test arguments with the arguments described in the following
table.
Argument Description
Bitmask Applies the specified hexadecimal bitmask using the AND operator to the bytes extracted from the Bytes
argument.
A bitmask can be 1 to 4 bytes.
The result will be right-shifted by the number of bits equal to the number of trailing zeros in the mask.
Relative Makes the offset relative to the last successful pattern match.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
Argument Description
DCE/RPC Specifies a byte_test keyword for traffic processed by the DCE/RPC preprocessor.
The DCE/RPC preprocessor determines big endian or little endian byte order, and the
Number Type and Endian arguments do not apply.
When you enable this argument, you can also use byte_test in conjunction with other
specific DCE/RPC keywords.
You can define how the system views string data in a packet by using one of the arguments in the following
table.
Argument Description
Hexadecimal String Represents converted string data in hexadecimal format.
• Bytes = 4
• Operator and Value > 128
• Offset = 8
• Relative enabled
The rules engine calculates the number described in the four bytes that appear 9 bytes away from (relative to)
the last successful content match, and, if the calculated number is larger than 128 bytes, the rule is triggered.
Related Topics
The byte_extract Keyword, on page 1600
DCE/RPC Keywords, on page 1634
You can use byte_extract to create up to two separate variables in a rule concurrently. You can redefine a
byte_extract variable any number of times; entering a new byte_extract keyword with the same variable
name and a different variable definition overwrites the previous definition of that variable.
The following table describes the arguments required by the byte_extract keyword.
Argument Description
Bytes to Extract The number of bytes to pick up from the packet.
If you specify a number of bytes other than 1, 2, or 4, you must specify a Number
Type (hexadecimal, octal, or decimal.)
Offset The number of bytes into the payload to begin extracting data. You can specify -65535
to 65535 bytes. The offset counter starts at byte 0, so calculate the offset value by
subtracting 1 from the number of bytes you want to count forward. For example,
specify 7 to count forward 8 bytes. The rules engine counts forward from the beginning
of the packet payload or, if you also specify Relative, after the last successful content
match. Note that you can specify negative numbers only when you also specify
Relative.
You can use an existing byte_math result to specify the value for this argument.
Variable Name The variable name to use in arguments for other detection keywords. You can specify
an alphanumeric string that must begin with a letter.
To further define how the system locates the data to extract, you can use the arguments described in the
following table.
Argument Description
Multiplier A multiplier for the value extracted from the packet. You can specify 0 to 65535. If
you do not specify a multiplier, the default value is 1.
Align Rounds the extracted value to the nearest 2-byte or 4-byte boundary. When you also
select Multiplier, the system applies the multiplier before the alignment.
Relative Makes Offset relative to the end of the last successful content match instead of the
beginning of the payload.
Bitmask Applies the specified hexadecimal bitmask using the AND operator to the bytes
extracted from the Bytes to Extract argument.
A bitmask can be 1 to 4 bytes.
The result will be right-shifted by the number of bits equal to the number of trailing
zeros in the mask.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
DCE/RPC Specifies a byte_extract keyword for traffic processed by the DCE/RPC preprocessor.
The DCE/RPC preprocessor determines big endian or little endian byte order, and the
Number Type and Endian arguments do not apply.
When you enable this argument, you can also use byte_extract in conjunction with
other specific DCE/RPC keywords.
You can specify a number type to read data as an ASCII string. To define how the system views string data
in a packet, you can select one of the arguments in the following table.
Argument Description
Hexadecimal String Reads extracted string data in hexadecimal format.
• Bytes to Extract = 4
• Variable Name = var
• Offset = 8
• Relative = enabled
the rules engine reads the number described in the four bytes that appear 9 bytes away from (relative to) the
last successful content match into a variable named var, which you can specify later in the rule as the value
for certain keyword arguments.
The following table lists the keyword arguments where you can specify a variable defined in the byte_extract
keyword.
Keyword Argument
content Depth, Offset, Distance, Within
byte_jump Offset
isdataat Offset
Related Topics
The DCE/RPC Preprocessor, on page 1710
DCE/RPC Keywords, on page 1634
Basic content and protected_content Keyword Arguments, on page 1585
The byte_jump Keyword, on page 1595
The byte_test Keyword, on page 1598
Packet Characteristics, on page 1657
Argument Description
Bytes The number of bytes to calculate from the packet.
If used without DCE/RPC, the allowed values are 1 to 10:
• Bytes can be 1 to 10 when the operator is +, -. *, or /.
• Bytes can be 1 to 4 when the operator is << or >>.
• If you specify a number of bytes other than 1, 2, or 4, you must specify a Number
Type (hexadecimal, octal, or decimal.)
Argument Description
Offset The number of bytes into the payload to start processing. The offset counter starts
at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you
want to jump forward from the beginning of the packet payload or (if you specified
Relative) from the last successful content match.
You can specify -65535 to 65535 bytes.
You can also specify the byte_extract variable here.
RValue The value following the operator. This can be an unsigned integer or a variable passed
from byte_extract.
Result Variable The name of the variable into which the result of the byte_math calculation will be
stored. You can use this variable as an argument in other keywords.
This value is stored as an unsigned integer.
This variable name:
• Must use alphanumeric characters
• Must not begin with a number
• May include special characters supported by the Microsoft filename/variable
name convention
• Cannot consist entirely of special characters
The following table describes options you can use to define how the system interprets the values you specified
for the required arguments.
Argument Description
Relative Makes the offset relative to the last pattern found in the last successful content match
instead of the beginning of the payload.
Bitmask Applies the specified hexadecimal bitmask using the AND operator to the bytes
extracted from the Bytes argument.
A bitmask can be 1 to 4 bytes.
The result will be right-shifted by the number of bits equal to the number of trailing
zeros in the mask.
If you want to define how the byte_math keyword calculates the bytes, you can choose from the arguments
described in the following table. If you do not select a byte-ordering argument, the rules engine uses big endian
byte order.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
DCE/RPC Specifies a byte_math keyword for traffic processed by the DCE/RPC preprocessor.
The DCE/RPC preprocessor determines big endian or little endian byte order, and the
Number Type and Endian arguments do not apply.
When you enable this argument, you can also use byte_math in conjunction with other
specific DCE/RPC keywords.
Define how the system views string data in a packet by using one of the arguments in the following table.
Argument Description
Hexadecimal String Represents string data in hexadecimal format.
For example, if the values you set for byte_math are as follows:
• Bytes = 2
• Offset = 0
• Operator = *
• RValue = height
• Result Variable = area
the rules engine extracts the number described in the first two bytes in the packet and multiplies it by the
RValue (which uses the existing variable, height) to create the new variable, area.
Keyword Argument
byte_jump Offset
Keyword Argument
byte_test Offset, Value
byte_extract Offset
isdataat Offset
!/pcre/ ismxAEGRBUIPHDMCKSY
where:
• ! is an optional negation (use this if you want to match patterns that do not match the regular expression).
• /pcre/ is a Perl-compatible regular expression.
• ismxAEGRBUIPHDMCKSY is any combination of modifier options.
Also note that you must escape the characters listed in the following table for the rules engine to interpret
them correctly when you use them in a PCRE to search for specific content in a packet payload.
; (semicolon) \; \x3B
: (colon) \: \x3A
You can also use m?regex?, where ? is a delimiter other than /. You may want to use this in situations where
you need to match a forward slash within a regular expression and do not want to escape it with a backslash.
For example, you might use m?regex? ismxAEGRBUIPHDMCKSY where regex is your Perl-compatible regular
expression and ismxAEGRBUIPHDMCKSY is any combination of modifier options.
Tip Optionally, you can surround your Perl-compatible regular expression with quote characters, for example,
pcre_expression or “pcre_expression“.The option of using quotes accommodates experienced users
accustomed to previous versions when quotes were required instead of optional. The intrusion rules editor
does not display quotation marks when you display a rule after saving it.
pcre Syntax
The pcre keyword accepts standard Perl-compatible regular expression (PCRE) syntax. The following sections
describe that syntax.
Tip While this section describes the basic syntax you may use for PCRE, you may want to consult an online
reference or book dedicated to Perl and PCRE for more advanced information.
Metacharacters
Metacharacters are literal characters that have special meaning within regular expressions. When you use
them within a regular expression, you must “escape” them by preceding them with a backslash.
The following table describes the metacharacters you can use with PCRE and gives examples of each.
* Matches zero or more occurrences of a character or abc* matches abc, abcc, abccc, abccccc, and so on.
expression.
+ Matches one or more occurrences of a character or abc+ matches abc, abcc, abccc, abccccc, and so on.
expression.
{} Specifies a limit for the number of matches for a character a{4,6} matches aaaa, aaaaa, or aaaaaa.
or expression. If you want to set a lower and upper limit,
(ab){2} matches abab.
separate the lower limit and upper limit with a comma.
[] Allows you to define character classes, and matches any [abc123] matches a or b or c, and so on.
character or combination of characters described in the set.
^ Matches content at the beginning of a string. Also used for ^in matches the “in” in info, but not in bin. [^a] matches
negation, if used within a character class. anything that does not contain a.
\ Allows you to use metacharacters as actual characters and \. matches a period, \* matches an asterisk, \\ matches a
is also used to specify a predefined character class. backslash and so on. \d matches the numeric characters,
\w matches alphanumeric characters, and so on.
Character Classes
Character classes include alphabetic characters, numeric characters, alphanumeric characters, and white space
characters. While you can create your own character classes within brackets, you can use the predefined
classes as shortcuts for different types of character types. When used without additional qualifiers, a character
class matches a single digit or character.
The following table describes and provides examples of the predefined character classes accepted by PCRE.
\s Matches white space characters, including spaces, carriage returns, tabs, newlines, [ \r\t\n\f]
and form feeds.
/pcre/ismxAEGRBUIPHDMCKSY
where ismxAEGRBUPHMC can include any of the modifying options that appear in the following tables.
Tip Optionally, you can surround the regular expression and any modifying options with quotes, for example,
“/pcre/ismxAEGRBUIPHDMCKSY”. The option of using quotes accommodates experienced users accustomed
to previous versions when quotes were required instead of optional. The intrusion rules editor does not
display quotation marks when you display a rule after saving it.
The following table describes options you can use to perform Perl processing functions.
Option Description
i Makes the regular expression case-insensitive.
s The dot character (.) describes all characters except the newline or \n character. You can use "s" as an
option to override this and have the dot character match all characters, including the newline character.
m By default, a string is treated as a single line of characters, and ^ and $ match the beginning and ending
of a specific string. When you use "m" as an option, ^ and $ match content immediately before or after
any newline character in the buffer, as well as at the beginning or end of the buffer.
x Ignores white space data characters that may appear within the pattern, except when escaped (preceded
by a backslash) or included inside a character class.
The following table describes the PCRE modifiers you can use after the regular expression.
Option Description
A The pattern must match at the beginning of the string (same as using ^ in a regular
expression).
E Sets $ to match only at the end of the subject string. (Without E, $ also matches
immediately before the final character if it is a newline, but not before any other
newline characters).
G By default, * + and ? are “greedy,” which means that if two or more matches are found,
they will choose the longest match. Use the G character to change this so that these
characters always choose the first match unless followed by a question mark character
(?). For example, *? +? and ?? would be greedy in a construct using the G modifier,
and any incidences of *, +, or ? without the additional question mark will not be greedy.
The following table describes the Snort-specific modifiers that you can use after the regular expression.
.
Option Description
R Searches for matching content relative to the end of the last match found by the rules
engine.
B Searches for the content within data before it is decoded by a preprocessor (this option
is similar to using the Raw Data argument with the content or protected_content
keyword).
U Searches for the content within the URI of a normalized HTTP request message decoded
by the HTTP Inspect preprocessor. Note that you cannot use this option in combination
with the content or protected_content keyword HTTP URI option to search the
same content.
Note that a pipelined HTTP request packet contains multiple URIs. A PCRE expression
that includes the U option causes the rules engine to search for a content match only
in the first URI in a pipelined HTTP request packet. To search all URIs in the packet,
use the content or protected_content keyword with HTTP URI selected, either
with or without an accompanying PCRE expression that uses the U option.
I Searches for the content within the URI of a raw HTTP request message decoded by
the HTTP Inspect preprocessor. Note that you cannot use this option in combination
with the content or protected_content keyword HTTP Raw URI option to search
the same content
P Searches for the content within the body of a normalized HTTP request message
decoded by the HTTP Inspect preprocessor.
H Searches for the content within the header, excluding cookies, of an HTTP request or
response message decoded by the HTTP Inspect preprocessor. Note that you cannot
use this option in combination with the content or protected_content keyword
HTTP Header option to search the same content.
D Searches for the content within the header, excluding cookies, of a raw HTTP request
or response message decoded by the HTTP Inspect preprocessor. Note that you cannot
use this option in combination with the content or protected_content keyword
HTTP Raw Header option to search the same content.
M Searches for the content within the method field of a normalized HTTP request message
decoded by the HTTP Inspect preprocessor; the method field identifies the action such
as GET, PUT, CONNECT, and so on to take on the resource identified in the URI.
Option Description
C When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled,
searches for the normalized content within any cookie in an HTTP request header,
and also within any set-cookie in an HTTP response header when the preprocessor
Inspect HTTP Responses option is enabled. When Inspect HTTP Cookies is not
enabled, searches the entire header, including the cookie or set-cookie data.
Note the following:
• Cookies included in the message body are treated as body content.
• You cannot use this option in combination with the content or
protected_content keyword HTTP Cookie option to search the same content.
• The Cookie: and Set-Cookie: header names, leading spaces on the header line,
and the CRLF that terminates the header line are inspected as part of the header
and not as part of the cookie.
K When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled,
searches for the raw content within any cookie in an HTTP request header, and also
within any set-cookie in an HTTP response header when the preprocessor Inspect
HTTP Responses option is enabled. When Inspect HTTP Cookies is not enabled,
searches the entire header, including the cookie or set-cookie data.
Note the following:
• Cookies included in the message body are treated as body content.
• You cannot use this option in combination with the content or
protected_content keyword HTTP Raw Cookie option to search the same
content.
• The Cookie: and Set-Cookie: header names, leading spaces on the header line,
and the CRLF that terminates the header line are inspected as part of the header
and not as part of the cookie.
Y Searches the textual description that accompanies the status code in an HTTP response.
Note Do not use the U option in combination with the R option. This could cause performance problems. Also,
do not use the U option in combination with any other HTTP content option (I, P, H, D, M, C, K, S, or
Y).
Related Topics
Overview: HTTP content and protected_content Keyword Arguments, on page 1588
This example searches packet payload for feedback, followed by zero or one numeric character, followed by
.cgi, and located only in URI data.
• /^ez(\w{3,5})\.cgi/iU
This example searches packet payload for ez at the beginning of a string, followed by a word of 3 to 5 letters,
followed by .cgi. The search is case-insensitive and only searches URI data.
This example would match:
• EZBoard.cgi
• ezman.cgi
• ezadmin.cgi
• EZAdmin.cgi
• /mail(file|seek)\.cgi/U
This example searches packet payload for mail, followed by either file or seek, in URI data.
• m?http\\x3a\x2f\x2f.*(\n|\t)+?U
This example searches packet payload for URI content for a tab or newline character in an HTTP request,
after any number of characters. This example uses m?regex? to avoid using http\:\/\/ in the expression.
Note that the colon is preceded by a backslash.
This example would match:
• http://www.example.com?scriptvar=x&othervar=\n\..\..
• http://www.example.com?scriptvar=\t
• m?http\\x3a\x2f\x2f.*=\|.*\|+?sU
This example searches packet payload for a URL with any number of characters, including newlines, followed
by an equal sign, and pipe characters that contain any number of characters or white space. This example uses
m?regex? to avoid using http\:\/\/ in the expression.
• http://www.example.com?input=|cat /etc/passwd|
• http://www.example.com?value=x&input?|cat /etc/passwd|
• /[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}/i
This example searches packet payload for any MAC address. Note that it escapes the colon characters with
backslashes.
author SnortGuru_20050406
You can use multiple metadata keywords in a rule. You can also use commas to separate multiple key value
arguments in a single metadata keyword, as seen in the following example:
author SnortGuru_20050406, revised_by SnortUser1_20050707,
revised_by SnortUser2_20061003,
revised_by SnortUser1_20070123
You are not limited to using a key value or key=value format; however, you should be aware of limitations
resulting from validation based on these formats.
application
engine
impact_flag
os
policy
rule-type
rule-flushing
soid
Note Contact Support for assistance in adding restricted metadata to local rules that might not otherwise function
as expected.
Impact Level 1
You can use the following reserved key value argument in a metadata keyword:
impact_flag red
This key value argument sets the impact flag to red (level 1) for a local rule you import or a custom rule you
create using the intrusion rules editor.
Note that when Talos includes the impact_flag red argument in a rule provided by Cisco, Talos has determined
that a packet triggering the rule indicates that the source or destination host is potentially compromised by a
virus, trojan, or other piece of malicious software.
Related Topics
Local Intrusion Rule File Import, on page 153
The Intrusion Events Clipboard, on page 2310
Service Metadata
The system detects applications running on the hosts in your network and inserts application protocol
information into your network traffic; it does this regardless of the configuration of your discovery policy.
You can use metadata keyword service arguments in a TCP or UDP rule to match application protocols and
ports in your network traffic. You can combine one or more service application arguments in a rule with a
single port argument.
Service Applications
You can use the metadata keyword with service as the key and an application as the value to match packets
with the identified application protocol. For example, the following key value argument in a metadata keyword
associates the rule with HTTP traffic:
service http
You can identify multiple applications separated by commas. For example:
service http, service smtp, service ftp
Caution Adaptive profiling must be enabled (its default state) as described in Configuring Adaptive Profiles, on
page 1833 for intrusion rules to use service metadata.
The following table describes the most common application values used with the service keyword.
Note Contact Support for assistance if you have difficulty identifying applications not in the table.
Value Description
cvs Concurrent Versions System
shell OS Shell
Value Description
tftp Trivial File Transfer Protocol
Service Ports
You can use the metadata keyword with service as the key and a specified port argument as the value to
define how the rule matches ports in combination with applications.
You can specify any of the port values in the table below, one value per rule.
Value Description
else-ports or The system applies the rule if either of the following conditions is met:
unknown
• The packet application is known and matches the rule application.
• The packet application is unknown and packet ports match the rule ports.
The else-ports and unknown values produce the default behavior that the system uses
when service specifies an application protocol with no port modifier.
and-ports The system applies the rule if the packet application is known and matches the rule
application, and the packet port matches the ports in the rule header. You cannot use
and-ports in a rule that does not specify an application.
or-ports The system applies the rule if any of the following conditions are met:
• The packet application is known and matches the rule application.
• The packet application is unknown and packet port matches the rule ports.
• The packet application does not match the rule application and packet ports
match the rule ports.
• The rule does not specify an application and packet ports match the rule ports.
Except for the and-ports value, you can include a service port argument with or without one or more service
application arguments. For example:
service or-ports, service http, service smtp
Example Matches
The following sample rules using the metadata keyword with service arguments are shown with examples
of data they match and do not match:
• alert tcp any any -> any [80,8080] (metadata:service and-ports, service http, service
smtp;)
• alert tcp any any -> any [80,8080] (metadata:service or-ports, service http;)
◦alert tcp any any -> any [80,8080] metadata:service unknown, service http;)
• author snortguru to display all rules where you have used author for key and SnortGuru for value.
• author s to display all rules where you have used author for key and any terms such as SnortGuru or
SnortUser1 or SnortUser2 for value.
Tip When you search for both key and value , use the same connecting operator (equal to
[=] or a space character) in searches that is used in the key value argument in the rule;
searches return different results depending on whether you follow key with equal to (=)
or a space character.
Note that regardless of the format you use to add metadata, the system interprets your metadata search term
as all or part of a key value or key=value argument. For example, the following would be valid metadata that
does not follow a key value or key=value format:
ab cd ef gh
However, the system would interpret each space in the example as a separator between a key and value . Thus,
you could successfully locate a rule containing the example metadata using any of the following searches for
juxtaposed and single terms:
cd ef
ef gh
ef
but you would not locate the rule using the following search, which the system would interpret as a single key
value argument:
ab ef
Related Topics
Searching for Rules, on page 1578
IP Header Values
You can use keywords to identify possible attacks or security policy violations in the IP headers of packets.
fragbits
The fragbits keyword inspects the fragment and reserved bits in the IP header. You can check each packet
for the Reserved Bit, the More Fragments bit, and the Don't Fragment bit in any combination.
Argument Description
R Reserved bit
To further refine a rule using the fragbits keyword, you can specify any operator described in the following
table after the argument value in the rule.
Operator Description
plus sign (+) The packet must match against all specified bits.
asterisk (*) The packet can match against any of the specified bits.
exclamation point (!) The packet meets the criteria if none of the specified bits are set.
For example, to generate an event against packets that have the Reserved Bit set (and possibly any other bits),
use R+ as the fragbits value.
id
The id keyword tests the IP header fragment identification field against the value you specify in the keyword’s
argument. Some denial-of-service tools and scanners set this field to a specific number that is easy to detect.
For example, in SID 630, which detects a Synscan portscan, the id value is set to 39426, the static value used
as the ID number in packets transmitted by the scanner.
ipopts
The IPopts keyword allows you to search packets for specified IP header options. The following table lists
the available argument values.
Argument Description
rr record route
nop no operation
ts time stamp
Argument Description
satid stream identifier
Analysts most frequently watch for strict and loose source routing because these options may be an indication
of a spoofed source IP address.
ip_proto
The ip_proto keyword allows you to identify packets with the IP protocol specified as the keyword’s value.
You can specify the IP protocols as a number, 0 through 255. You can combine these numbers with the
following operators: <, >, or !. For example, to inspect traffic with any protocol that is not ICMP, use !1 as
a value to the ip_proto keyword. You can also use the ip_proto keyword multiple times in a single rule;
note, however, that the rules engine interprets multiple instances of the keyword as having a Boolean AND
relationship. For example, if you create a rule containing ip_proto:!3; ip_proto:!6, the rule ignores traffic
using the GGP protocol AND the TCP protocol.
tos
Some networks use the type of service (ToS) value to set precedence for packets traveling on that network.
The tos keyword allows you to test the packet’s IP header ToS value against the value you specify as the
keyword’s argument. Rules using the tos keyword will trigger on packets whose ToS is set to the specified
value and that meet the rest of the criteria set forth in the rule.
The ToS field has been deprecated in the IP header protocol and replaced with the Differentiated Services
Code Point (DSCP) field.
ttl
A packet’s time-to-live (ttl) value indicates how many hops it can make before it is dropped. You can use the
ttl keyword to test the packet’s IP header ttl value against the value, or range of values, you specify as the
keyword’s argument. It may be helpful to set the ttl keyword parameter to a low value such as 0 or 1, as low
time-to-live values are sometimes indicative of a traceroute or intrusion evasion attempt. (Note, though, that
the appropriate value for this keyword depends on your managed device placement and network topology.)
Use syntax as follows:
• Use an integer from 0 to 255 to set a specific value for the TTL value. You can also precede the value
with an equal (=) sign (for example, you can specify 5 or =5).
• Use a hyphen (-) to specify a range of TTL values (for example, 0-2 specifies all values 0 through 2,
-5 specifies all values 0 through 5, and 5- specifies all values 5 through 255).
• Use the greater than (>) sign to specify TTL values greater than a specific value (for example, >3 specifies
all values greater than 3).
• Use the greater than and equal to signs (>=) to specify TTL values greater than or equal to a specific
value (for example, >=3 specifies all values greater than or equal to 3).
• Use the less than (<) sign to specify TTL values less than a specific value (for example, <3 specifies all
values less than 3).
• Use the less than and equal to signs (<=) to specify TTL values less than or equal to a specific value (for
example, <=3 specifies all values less than or equal to 3).
Keyword Definition
icmp_id Inspects an ICMP echo request or reply packet's ICMP ID number. Use a numeric
value that corresponds with the ICMP ID number as the argument for the icmp_id
keyword.
icmp_seq The icmp_seq keyword inspects an ICMP echo request or reply packet's ICMP
sequence. Use a numeric value that corresponds with the ICMP sequence number as
the argument for the icmp_seq keyword.
itype
Use the itype keyword to look for packets with specific ICMP message type values. You can specify either
a valid ICMP type value or an invalid ICMP type value to test for different types of traffic. For example,
attackers may set ICMP type values out of range to cause denial of service and flooding attacks.
You can specify a range for the itype argument value using less than (<) and greater than (>).
For example:
• <35
• >36
• 3<>55
icode
ICMP messages sometimes include a code value that provides details when a destination is unreachable.
You can use the icode keyword to identify packets with specific ICMP code values. You can choose to specify
either a valid ICMP code value or an invalid ICMP code value to test for different types of traffic.
You can specify a range for the icode argument value using less than (<) and greater than (>).
For example:
• to find values less than 35, specify <35.
• to find values greater than 36, specify >36.
• to find values between 3 and 55, specify 3<>55.
Tip You can use the icode and itype keywords together to identify traffic that matches both. For example,
to identify ICMP traffic that contains an ICMP Destination Unreachable code type with an ICMP Port
Unreachable code type, specify an itype keyword with a value of 3 (for Destination Unreachable) and
an icode keyword with a value of 3 (for Port Unreachable).
ack
You can use the ack keyword to compare a value against a packet’s TCP acknowledgment number. The rule
triggers if a packet’s TCP acknowledgment number matches the value specified for the ack keyword.
Argument values for ack must be numeric.
flags
You can use the flags keyword to specify any combination of TCP flags that, when set in an inspected packet,
cause the rule to trigger.
Note In situations where you would traditionally use A+ as the value for flags, you should instead use the flow
keyword with a value of established. Generally, you should use the flow keyword with a value of
stateless when using flags to ensure that all combinations of flags are detected.
You can either check for or ignore the values described in the following table for the flag keyword.
CWR An ECN congestion window has been reduced. This was formerly the R1 argument,
which is still supported for backward compatibility.
ECE ECN echo. This was formerly the R2 argument, which is still supported for backward
compatibility.
When using the flags keyword, you can use an operator to indicate how the system performs matches against
multiple flags. The following table describes these operators.
any The packet can contain any of the Select Ack, Psh, and any to specify that either or both the Ack and
specified flags. Psh flags must be set to trigger the rule, and that other flags may
also be set on a packet.
not The packet must not contain the Select Urg and not to specify that the Urgent flag is not set on
specified flag set. packets that trigger this rule.
flow
You can use the flow keyword to select packets for inspection by a rule based on session characteristics. The
flow keyword allows you to specify the direction of the traffic flow to which a rule applies, applying rules to
either the client flow or server flow. To specify how the flow keyword inspects your packets, you can set the
direction of traffic you want analyzed, the state of packets inspected, and whether the packets are part of a
rebuilt stream.
Stateful inspection of packets occurs when rules are processed. If you want a TCP rule to ignore stateless
traffic (traffic without an established session context), you must add the flow keyword to the rule and select
the Established argument for the keyword. If you want a UDP rule to ignore stateless traffic, you must add
the flow keyword to the rule and select either the Established argument or a directional argument, or both.
This causes the TCP or UDP rule to perform stateful inspection of a packet.
When you add a directional argument, the rules engine inspects only those packets that have an established
state with a flow that matches the direction specified. For example, if you add the flow keyword with the
established argument and the From Client argument to a rule that triggers when a TCP or UDP connection
is detected, the rules engine only inspects packets that are sent from the client.
Tip For maximum performance, always include a flow keyword in a TCP rule or a UDP session rule.
The following table describes the stream-related arguments you can specify for the flow keyword:
Argument Description
Established Triggers on established connections.
The following table describes the directional options you can specify for the flow keyword:
Argument Description
To Client Triggers on server responses.
Notice that From Server and To Client perform the same function, as do To Server and From Client. These
options exist to add context and readability to the rule. For example, if you create a rule designed to detect an
attack from a server to a client, use From Server. But, if you create a rule designed to detect an attack from
the client to the server, use From Client.
The following table describes the stream-related arguments you can specify for the flow keyword:
Argument Description
Ignore Stream Traffic Does not trigger on rebuilt stream packets.
For example, you can use To Server, Established, Only Stream Traffic as the value for the flow
keyword to detect traffic, traveling from a client to the server in an established session, that has been
reassembled by the stream preprocessor.
seq
The seq keyword allows you to specify a static sequence number value. Packets whose sequence number
matches the specified argument trigger the rule containing the keyword. While this keyword is used rarely,
it is helpful in identifying attacks and network scans that use generated packets with static sequence numbers.
window
You can use the window keyword to specify the TCP window size you are interested in. A rule containing this
keyword triggers whenever it encounters a packet with the specified TCP window size. While this keyword
is used rarely, it is helpful in identifying attacks and network scans that use generated packets with static TCP
window sizes.
stream_size
You can use the stream_size keyword in conjunction with the stream preprocessor to determine the size in
bytes of a TCP stream, using the format:
direction,operator,bytes
where bytes is number of bytes. You must separate each option in the argument with a comma (,).
The following table describes the case-insensitive directional options you can specify for the stream_size
keyword:
Argument Description
client triggers on a stream from the client matching the specified stream size.
server triggers on a stream from the server matching the specified stream size.
both triggers on traffic from the client and traffic from the server both matching the specified
stream size.
For example, the argument both, >, 200 would trigger when traffic from the client
is greater than 200 bytes AND traffic from the server is greater than 200 bytes.
either triggers on traffic from either the client or the server matching the specified stream
size, whichever occurs first.
For example, the argument either, >, 200 would trigger when traffic from the client
is greater than 200 bytes OR traffic from the server is greater than 200 bytes.
The following table describes the operators you can use with the stream_size keyword:
Operator Description
= equal to
!= not equal to
Operator Description
> greater than
For example, you could use client, >=, 5001216 as the argument for the stream_size keyword to detect
a TCP stream traveling from a client to a server and greater than or equal to 5001216 bytes.
Argument Description
noalert Generate no events regardless of any other detection options specified in the rule.
fastpath Ignore the rest of the connection traffic when there is a match.
For example, the following rule disables TCP client-side stream reassembly without generating an event on
the connection where a 200 OK status code is detected in an HTTP response:
alert tcp any 80 -> any any (flow:to_client, established; content: “200 OK”;
stream_reassemble:disable, client, noalert
SSL Keywords
You can use SSL rule keywords to invoke the Secure Sockets Layer (SSL) preprocessor and extract information
about SSL version and session state from packets in an encrypted session.
When a client and server communicate to establish an encrypted session using SSL or Transport Layer Security
(TLS), they exchange handshake messages. Although the data transmitted in the session is encrypted, the
handshake messages are not.
The SSL preprocessor extracts state and version information from specific handshake fields. Two fields within
the handshake indicate the version of SSL or TLS used to encrypt the session and the stage of the handshake.
ssl_state
The ssl_state keyword can be used to match against state information for an encrypted session. To check
for two or more SSL versions used simultaneously, use multiple ssl_version keywords in a rule.
When a rule uses the ssl_state keyword, the rules engine invokes the SSL preprocessor to check traffic for
SSL state information.
For example, to detect an attacker’s attempt to cause a buffer overflow on a server by sending a ClientHello
message with an overly long challenge length and too much data, you could use the ssl_state keyword with
client_hello as an argument then check for abnormally large packets.
Use a comma-separated list to specify multiple arguments for the SSL state. When you list multiple arguments,
the system evaluates them using the OR operator. For example, if you specify client_hello and server_hello
as arguments, the system evaluates the rule against traffic that has a client_hello OR a server_hello.
You can also negate any argument; for example:
!client_hello, !unknown
To ensure the connection has reached each of a set of states, multiple rules using the ssl_state rule option
should be used. The ssl_state keyword takes the following identifiers as arguments:
Argument Purpose
client_hello Matches against a handshake message with ClientHello as the message type, where
the client requests an encrypted session.
server_hello Matches against a handshake message with ServerHello as the message type, where
the server responds to the client’s request for an encrypted session.
client_keyx Matches against a handshake message with ClientKeyExchange as the message type,
where the client transmits a key to the server to confirm receipt of a key from the
server.
server_keyx Matches against a handshake message with ServerKeyExchange as the message type,
where the client transmits a key to the server to confirm receipt of a key from the
server.
ssl_version
The ssl_version keyword can be used to match against version information for an encrypted session. When
a rule uses the ssl_version keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL
version information.
For example, if you know there is a buffer overflow vulnerability in SSL version 2, you could use the
ssl_version keyword with the sslv2 argument to identify traffic using that version of SSL.
Use a comma-separated list to specify multiple arguments for the SSL version. When you list multiple
arguments, the system evaluates them using the OR operator. For example, if you wanted to identify any
encrypted traffic that was not using SSLv2, you could add ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 to
a rule. The rule would evaluate any traffic using SSL Version 3, TLS Version 1.0, TLS Version 1.1, or TLS
Version 1.2.
The ssl_version keyword takes the following SSL/TLS version identifiers as arguments:
Argument Purpose
sslv2 Matches against traffic encoded using Secure Sockets Layer (SSL) Version 2.
sslv3 Matches against traffic encoded using Secure Sockets Layer (SSL) Version 3.
tls1.0 Matches against traffic encoded using Transport Layer Security (TLS) Version 1.0.
tls1.1 Matches against traffic encoded using Transport Layer Security (TLS) Version 1.1.
tls1.2 Matches against traffic encoded using Transport Layer Security (TLS) Version 1.2.
Note If you select one or more filters in the Application Filters list and also search the Available Applications
list, your selections and the search-filtered Available Applications list are combined using an AND
operation.
Selecting Applications
To select a single application, select it and click Add to Rule. To select all applications in the current
constrained view, right-click and select Select All.
Argument Description
application The RPC application number
To specify the arguments for the rpc keyword, use the following syntax:
application,procedure,version
where application is the RPC application number, procedure is the RPC procedure number, and version is the
RPC version number. You must specify all arguments for the rpc keyword — if you are not able to specify
one of the arguments, replace it with an asterisk (*).
For example, to search for RPC portmapper (which is the RPC application indicated by the number 100000),
with any procedure or version, use 100000,*,* as the arguments.
The following table describes the arguments for the asn1 keyword.
Argument Description
Bitstring Overflow Detects invalid, remotely exploitable bitstring encodings.
Double Overflow Detects a double ASCII encoding that is larger than a standard buffer. This is known to be an exploitable
function in Microsoft Windows, but it is unknown at this time which services may be exploitable.
Oversize Length Detects ASN.1 type lengths greater than the supplied argument. For example, if you set the Oversize
Length to 500, any ASN.1 type greater than 500 triggers the rule.
Absolute Offset Sets an absolute offset from the beginning of the packet payload. (Remember that the offset counter starts
at byte 0.) For example, if you want to decode SNMP packets, set Absolute Offset to 0 and do not set a
Relative Offset. Absolute Offset may be positive or negative.
Relative Offset This is the relative offset from the last successful content match, pcre, or byte_jump. To decode an ASN.1
sequence right after the content "foo", set Relative Offset to 0, and do not set an Absolute Offset. Relative
Offset may be positive or negative. (Remember that the offset counter starts at 0.)
For example, there is a known vulnerability in the Microsoft ASN.1 Library that creates a buffer overflow,
allowing an attacker to exploit the condition with a specially crafted authentication packet. When the system
decodes the asn.1 data, exploit code in the packet could execute on the host with system-level privileges or
could cause a DoS condition. The following rule uses the asn1 keyword to detect attempts to exploit this
vulnerability:
alert tcp $EXTERNAL_NET any -> $HOME_NET 445
(flow:to_server, established; content:”|FF|SMB|73|”;
nocase; offset:4; depth:5;
asn1:bitstring_overflow,double_overflow,oversize_length 100,
relative_offset 54;)
The above rule generates an event against TCP traffic traveling from any IP address defined in the
$EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using
port 445. In addition, it only executes the rule on established TCP connections to servers. The rule then tests
for specific content in specific locations. Finally, the rule uses the asn1 keyword to detect bitstring encodings
and double ASCII encodings and to identify asn.1 type lengths over 100 bytes in length starting 55 bytes from
the end of the last successful content match. (Remember that the offset counter starts at byte 0.)
• In practice, you always use the urilen keyword in combination with the flow:established keyword
and one or more other keywords.
• The rule protocol is always TCP.
• Target ports are always HTTP ports.
You specify the URI length using a decimal number of bytes, less than (<) and greater than (>).
For example:
• specify 5 to detect a URI 5 bytes long.
• specify < 5 (separated by one space character) to detect a URI less than 5 bytes long.
• specify > 5 (separated by one space character) to detect a URI greater than 5 bytes long.
• specify 3 <> 5 (with one space character before and after <>) to detect a URI between 3 and 5 bytes
long inclusive.
For example, there is a known vulnerability in Novell’s server monitoring and diagnostics utility iMonitor
version 2.4, which comes with eDirectory version 8.8. A packet containing an excessively long URI creates
a buffer overflow, allowing an attacker to exploit the condition with a specially crafted packet that could
execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the
urilen keyword to detect attempts to exploit this vulnerability:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS
(msg:"EXPLOIT eDirectory 8.8 Long URI iMonitor buffer
overflow attempt"; flow:to_server,established;
urilen:> 8192; uricontent:"/nds/"; nocase;
classtype:attempted-admin; sid:x; rev:1;)
The above rule generates an event against TCP traffic traveling from any IP address defined in the
$EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using
the ports defined in the $HTTP_PORTS variable. In addition, packets are evaluated against the rule only on
established TCP connections to servers. The rule uses the urilen keyword to detect any URI over 8192 bytes
in length. Finally, the rule searches the URI for the specific case-insensitive content /nds/.
Related Topics
Intrusion Rule Header Protocol, on page 1562
Intrusion Rule Header Source and Destination Ports, on page 1566
Predefined Default Variables, on page 366
DCE/RPC Keywords
The three DCE/RPC keywords described in the following table allow you to monitor DCE/RPC session traffic
for exploits. When the system processes rules with these keywords, it invokes the DCE/RPC preprocessor.
Note in the table that you should always precede dce_opnum with dce_iface, and you should always precede
dce_stub_data with dce_iface + dce_opnum.
You can also use these DCE/RPC keywords in combination with other rule keywords. Note that for DCE/RPC
rules, you use the byte_jump, byte_test, and byte_extract keywords with their DCE/RPC arguments
selected.
Cisco recommends that you include at least one content keyword in rules that include DCE/RPC keywords
to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves
performance. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content
keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument.
You can use the DCE/RPC version and adjoining header information as the matching content in the following
cases:
• the rule does not include another content keyword
• the rule contains another content keyword, but the DCE/RPC version and adjoining information represent
a more unique pattern than the other content
For example, the DCE/RPC version and adjoining information are more likely to be unique than a single
byte of content.
You should end qualifying rules with one of the following version and adjoining information content matches:
• For connection-oriented DCE/RPC rules, use the content |05 00 00| (for major version 05, minor
version 00, and the request PDU (protocol data unit) type 00).
• For connectionless DCE/RPC rules, use the content |04 00| (for version 04, and the request PDU type
00).
In either case, position the content keyword for version and adjoining information as the last keyword in the
rule to invoke the fast pattern matcher without repeating processing already completed by the DCE/RPC
preprocessor. Note that placing the content keyword at the end of the rule applies to version content used as
a device to invoke the fast pattern matcher, and not necessarily to other content matches in the rule.
Related Topics
The DCE/RPC Preprocessor, on page 1710
The content and protected_content Keywords, on page 1583
content Keyword Fast Pattern Matcher Arguments, on page 1592
Overview: The byte_jump and byte_test Keywords
The byte_extract Keyword, on page 1600
dce_iface
You can use the dce_iface keyword to identify a specific DCE/RPC service.
Optionally, you can also use dce_iface in combination with the dce_opnum and dce_stub_data keywords
to further limit the DCE/RPC traffic to inspect.
A fixed, sixteen-byte Universally Unique Identifier (UUID) identifies the application interface assigned to
each DCE/RPC service. For example, the UUID 4b324fc8-670-01d3-1278-5a47bf6ee188 identifies the
DCE/RPC lanmanserver service, also known as the srvsvc service, which provides numerous management
functions for sharing peer-to-peer printers, files, and SMB named pipes. The DCE/RPC preprocessor uses
the UUID and associated header values to track DCE/RPC sessions.
The interface UUID is comprised of five hexadecimal strings separated by hyphens:
<4hexbytes>-<2hexbytes>-<2hexbytes>-<2hexbytes>-<6hexbytes>
You specify the interface by entering the entire UUID including hyphens, as seen in the following UUID for
the netlogon interface:
12345678-1234-abcd-ef00-01234567cffb
Note that you must specify the first three strings in the UUID in big endian byte order. Although published
interface listings and protocol analyzers typically display UUIDs in the correct byte order, you might encounter
a need to rearrange the UUID byte order before entering it. Consider the following messenger service UUID
shown as it might sometimes be displayed in raw ASCII text with the first three strings in little endian byte
order:
f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc
You would specify the same UUID for the dce_iface keyword by inserting hyphens and putting the first
three strings in big endian byte order as follows:
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
Although a DCE/RPC session can include requests to multiple interfaces, you should include only one
dce_iface keyword in a rule. Create additional rules to detect additional interfaces.
DCE/RPC application interfaces also have interface version numbers. You can optionally specify an interface
version with an operator indicating that the version equals, does not equal, is less than, or greater than the
specified value.
Both connection-oriented and connectionless DCE/RPC can be fragmented in addition to any TCP segmentation
or IP fragmentation. Typically, it is not useful to associate any DCE/RPC fragment other than the first with
the specified interface, and doing so may result in a large number of false positives. However, for flexibility
you can optionally evaluate all fragments against the specified interface.
The following table summarizes the dce_iface keyword arguments.
Argument Description
Interface UUID The UUID, including hyphens, that identifies the application interface of the specific
service that you want to detect in DCE/RPC traffic. Any request associated with the
specified interface would match the interface UUID.
Version Optionally, the application interface version number 0 to 65535 and an operator
indicating whether to detect a version greater than (>), less than (<), equal to (=), or
not equal to (!) the specified value.
Argument Description
All Fragments Optionally, enable to match against the interface in all associated DCE/RPC fragments
and, if specified, on the interface version. This argument is disabled by default,
indicating that the keyword matches only if the first fragment or the entire unfragmented
packet is associated with the specified interface. Note that enabling this argument may
result in false positives.
15
15-18
15, 18-20
15, 20-22, 17
15, 18-20, 22, 24-26
SIP Keywords
Four SIP keywords allow you to monitor SIP session traffic for exploits.
Note that the SIP protocol is vulnerable to denial of service (DoS) attacks. Rules addressing these attacks can
benefit from rate-based attack prevention.
Related Topics
Dynamic Intrusion Rule States, on page 1528
Rate-Based Attack Prevention, on page 1821
alert udp any any -> any 5060 ( sip_body; content:"c=IN 192.168.12.14"; )
Note that rules are not limited to searching for SDP content. The SIP preprocessor extracts the entire message
body and makes it available to the rules engine.
ack, benotify, bye, cancel, do, info, invite, join, message, notify, options, prack,
publish, quath, refer, register, service, sprack, subscribe, unsubscribe, update
Methods are case-insensitive. You can separate multiple methods with commas.
Because new SIP methods might be defined in the future, you can also specify a custom method, that is, a
method that is not a currently defined SIP method. Accepted field values are defined in RFC 2616, which
allows all characters except control characters and separators such as =, (, and }. See RFC 2616 for the
complete list of excluded separators. When the system encounters a specified custom method in traffic, it will
inspect the packet header but not the message.
The system supports up to 32 methods, including the 21 currently defined methods and an additional 11
methods. The system ignores any undefined methods that you might configure. Note that the 32 total methods
includes methods specified using the Methods to Check SIP preprocessor option.
You can specify only one method when you use negation. For example:
!invite
Note, however, that multiple sip_method keywords in a rule are linked with an AND operation. For example,
to test for all extracted methods except invite and cancel, you would use two negated sip_method keywords:
sip_method: !invite
sip_method: !cancel
Cisco recommends that you include at least one content keyword in rules that include the sip_method keyword
to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves
performance. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content
keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument.
Related Topics
SIP Preprocessor Options, on page 1748
The content and protected_content Keywords, on page 1583
content Keyword Fast Pattern Matcher Arguments, on page 1592
You can specify a one-digit response-type number 1-9, a specific three-digit number 100-999, or a
comma-separated list of any combination of either. A list matches if any single number in the list matches the
code in the SIP response.
The following table describes the SIP status code values you can specify.
any three-digit code that begins the single digit 1 1xx; that is, 100,
with a specified single digit 101, 102, and so on
Note also that the rules engine does not use the fast pattern matcher to search for the value specify using the
sip_stat_code keyword, regardless of whether your rule includes a content keyword.
GTP Keywords
Three GSRP Tunneling Protocol (GTP) keywords allow you to inspect the GTP command channel for GTP
version, message type, and information elements. You cannot use GTP keywords in combination with other
intrusion rule keywords such as content or byte_jump. You must use the gtp_version keyword in each rule
that uses the gtp_info or gtp_type keyword.
versions define different message types and information elements, you must also use gtp_version when you
use the gtp_type or gtp_info keyword.
You can specify a defined decimal value for a message type, a defined string, or a comma-separated list of
either or both in any combination, as seen in the following example:
When a message includes multiple information elements of the same type, all are inspected for a match. When
information elements occur in an invalid order, only the last instance is inspected.
Note that different GTP versions sometimes use different values for the same information element. For
example, the cause information element has a value of 1 in GTPv0 and GTPv1, but a value of 2 in GTPv2.
The gtp_info keyword matches different values depending on the version number in the packet. In the example
above, the keyword matches the information element value 1 in a GTPv0 or GTPv1 packet and the value 2
in a GTPv2 packet. The keyword does not match a packet when the information element value in the packet
is not a known value for the version specified in the packet.
If you specify an integer for the information element, the keyword matches if the message type in the keyword
matches the value in the GTP packet, regardless of the version specified in the packet.
The following table lists the values and strings recognized by the system for each GTP information element.
SCADA Keywords
The rules engine uses Modbus and DNP3 rules to access certain protocol fields.
Modbus Keywords
You can use Modbus keywords alone or in combination with other keywords such as content and byte_jump.
modbus_data
You can use the modbus_data keyword to point to the beginning of the Data field in a Modbus request or
response.
modbus_func
You can use the modbus_func keyword to match against the Function Code field in a Modbus application
layer request or response header. You can specify either a single defined decimal value or a single defined
string for a Modbus function code.
The following table lists the defined values and strings recognized by the system for Modbus function codes.
Value String
1 read_coils
2 read_discrete_inputs
3 read_holding_registers
4 read_input_registers
5 write_single_coil
6 write_single_register
7 read_exception_status
8 diagnostics
11 get_comm_event_counter
12 get_comm_event_log
15 write_multiple_coils
16 write_multiple_registers
17 report_slave_id
Value String
20 read_file_record
21 write_file_record
22 mask_write_register
23 read_write_multiple_registers
24 read_fifo_queue
43 encapsulated_interface_transport
modbus_unit
You can use the modbus_unit keyword to match a single decimal value against the Unit ID field in a Modbus
request or response header.
DNP3 Keywords
You can use DNP3 keywords alone or in combination with other keywords such as content and byte_jump.
dnp3_data
You can use the dnp3_data keyword to point to the beginning of reassembled DNP3 application layer fragments.
The DNP3 preprocessor reassembles link layer frames into application layer fragments. The dnp3_data
keyword points to the beginning of each application layer fragment; other rule options can match against the
reassembled data within fragments without separating the data and adding checksums every 16 bytes.
dnp3_func
You can use the dnp3_func keyword to match against the Function Code field in a DNP3 application layer
request or response header. You can specify either a single defined decimal value or a single defined string
for a DNP3 function code.
The following table lists the defined values and strings recognized by the system for DNP3 function codes.
Value String
0 confirm
1 read
2 write
3 select
Value String
4 operate
5 direct_operate
6 direct_operate_nr
7 immed_freeze
8 immed_freeze_nr
9 freeze_clear
10 freeze_clear_nr
11 freeze_at_time
12 freeze_at_time_nr
13 cold_restart
14 warm_restart
15 initialize_data
16 initialize_appl
17 start_appl
18 stop_appl
19 save_config
20 enable_unsolicited
21 disable_unsolicited
22 assign_class
23 delay_measure
24 record_current_time
25 open_file
26 close_file
27 delete_file
Value String
28 get_file_info
29 authenticate_file
30 abort_file
31 activate_config
32 authenticate_req
33 authenticate_err
129 response
130 unsolicited_response
131 authenticate_resp
dnp3_ind
You can use the dnp3_ind keyword to match against flags in the Internal Indications field in a DNP3 application
layer response header.
You can specify the string for a single known flag or a comma-separated list of flags, as seen in the following
example:
class_1_events, class_2_events
When you specify multiple flags, the keyword matches against any flag in the list. To detect a combination
of flags, use the dnp3_ind keyword multiple times in a rule.
The following list provides the string syntax recognized by the system for defined DNP3 internal indications
flags.
class_1_events
class_2_events
class_3_events
need_time
local_control
device_trouble
device_restart
no_func_code_support
object_unknown
parameter_error
event_buffer_overflow
already_executing
config_corrupt
reserved_2
reserved_1
dnp3_obj
You can use the dnp3_obj keyword to match against DNP3 object headers in a request or response.
DNP3 data is comprised of a series of DNP3 objects of different types such as analog input, binary input, and
so on. Each type is identified with a group such as analog input group, binary input group, and so on, each of
which can be identified by a decimal value. The objects in each group are further identified by an object
variation such as 16-bit integers, 32-bit integers, short floating point, and so on, each of which specifies the
data format of the object. Each type of object variation can also be identified by a decimal value.
You identify object headers by specifying the decimal number for the type of object header group and the
decimal number for the type of object variation. The combination of the two defines a specific type of DNP3
object.
Packet Characteristics
You can write rules that only generate events against packets with specific packet characteristics.
dsize
The dsize keyword tests the packet payload size. With it, you can use the greater than and less than operators
(< and >) to specify a range of values. You can use the following syntax to specify ranges:
>number_of_bytes
<number_of_bytes
number_of_bytes<>number_of_bytes
For example, to indicate a packet size greater than 400 bytes, use >400 as the dtype value. To indicate a packet
size of less than 500 bytes, use <500. To specify that the rule trigger against any packet between 400 and 500
bytes inclusive, use 400<>500.
Caution The dsize keyword tests packets before they are decoded by any preprocessors.
isdataat
The isdataat keyword instructs the rules engine to verify that data resides at a specific location in the payload.
The following table lists the arguments you can use with the isdataat keyword.
Relative Optional Makes the location relative to the last successful content match. If you specify a relative
location, note that the counter starts at byte 0, so calculate the location by subtracting 1 from
the number of bytes you want to move forward from the last successful content match. For
example, to specify that the data must appear at the ninth byte after the last successful content
match, you would specify a relative offset of 8.
For example, in a rule searching for the content foo, if the value for isdataat is specified as the following:
• Offset = !10
• Relative = enabled
The system alerts if the rules engine does not detect 10 bytes after foo before the payload ends.
sameip
The sameip keyword tests that a packet’s source and destination IP addresses are the same. It does not take
an argument.
fragoffset
The fragoffset keyword tests the offset of a fragmented packet. This is useful because some exploits (such
as WinNuke denial-of-service attacks) use hand-generated packet fragments that have specific offsets.
For example, to test whether the offset of a fragmented packet is 31337 bytes, specify 31337 as the fragoffset
value.
You can use the following operators when specifying arguments for the fragoffset keyword.
Operator Description
! not
Note that you cannot use the not (!) operator in combination with < or >.
cvs
The cvs keyword tests Concurrent Versions System (CVS) traffic for malformed CVS entries. An attacker
can use a malformed entry to force a heap overflow and execute malicious code on the CVS server. This
keyword can be used to identify attacks against two known CVS vulnerabilities: CVE-2004-0396 (CVS 1.11.x
up to 1.11.15, and 1.12.x up to 1.12.7) and CVS-2004-0414 (CVS 1.12.x through 1.12.8, and 1.11.x through
1.11.16). The cvs keyword checks for a well-formed entry, and generates alerts when a malformed entry is
detected.
Your rule should include the ports where CVS runs. In addition, any ports where traffic may occur should be
added to the list of ports for stream reassembly in your TCP policies so state can be maintained for CVS
sessions. The TCP ports 2401 (pserver) and 514 (rsh) are included in the list of client ports where stream
reassembly occurs. However, note that if your server runs as an xinetd server (i.e., pserver), it can run on
any TCP port. Add any non-standard ports to the stream reassembly Client Ports list.
Related Topics
The byte_extract Keyword, on page 1600
TCP Stream Preprocessing Options, on page 1802
Related Topics
Active Responses with Intrusion Drop Rules, on page 1780
Argument Description
reset_source Directs a TCP reset packet to the endpoint that sent the packet that triggered the rule. Alternatively, you
can specify rst_snd, which is supported for backward compatibility.
reset_dest Directs a TCP reset packet to the intended destination endpoint of the packet that triggered the rule.
Alternatively, you can specify rst_rcv, which is supported for backward compatibility.
reset_both Directs a TCP reset packet to both the sending and receiving endpoints. Alternatively, you can specify
rst_all, which is supported for backward compatibility.
icmp_port Directs an ICMP port unreachable message to the sender. This argument is used to terminate UDP traffic.
For example, to configure a rule to reset both sides of a connection when a rule is triggered, use reset_both
as the value for the resp keyword.
You can use a comma-separated list to specify multiple arguments as follows:
argument,argument,argument
You can use the config response command to configure the active response interface to use and the number
of TCP resets to attempt in a passive deployment.
Related Topics
The config response Command, on page 1661
msg
When a packet triggers a react rule that uses the msg argument, the HTML page includes the rule event
message.
If you do not specify the msg argument, the HTML page includes the following message:
Note Because active responses can be routed back, ensure that the HTML response page does not trigger a
react rule; this could result in an unending sequence of active responses. Cisco recommends that you test
react rules extensively before activating them in a production environment.
You can use the config response command to configure the active response interface to use and the number
of TCP resets to attempt in a passive deployment.
Related Topics
Rule Anatomy, on page 1560
The config response Command, on page 1661
• To specify both the number of active response attempts and the active response interface, insert the
command:
config response: attempts att, device dev
where:
◦att is the number 1 to 20 of attempts to land each TCP reset packet within the current connection
window so the receiving host accepts the packet. This sequence strafing is useful only in passive
deployments; in inline deployments, the system inserts reset packets directly into the stream in
place of triggering packets. the system sends only 1 ICMP reachable active response.
◦dev is an alternate interface where you want the system to send active responses in a passive
deployment or insert active responses in an inline deployment.
For example: config response: attempts 10, device eth0
Caution Do not use the USER_CONF advanced variable to configure an intrusion policy feature unless you are
instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will
halt the system.
Related Topics
Active Responses with Intrusion Drop Rules, on page 1780
Advanced Variables, on page 372
Argument Description
by_src Detection criteria count by source IP address.
The count argument specifies the number of packets that must trigger the rule for the specified IP address
within the specified time before the rule generates an event.
The seconds argument specifies the number of seconds within which the specified number of packets must
trigger the rule before the rule generates an event.
Consider the case of a rule that searches packets for the content foo and uses the detection_filter keyword
with the following arguments:
Related Topics
Intrusion Event Thresholds, on page 1522
Intrusion Policy Suppression Configuration, on page 1526
Setting a Dynamic Rule State from the Rules Page, on page 1530
Local Intrusion Rule File Import, on page 153
Argument Description
session Logs packets in the session that triggered the rule.
host Logs packets from the host that sent the packet that triggered the rule. You can add a
directional modifier to log only the traffic coming from the host (src) or going to the
host (dst).
To indicate how much traffic you want to log, use the following argument:
Argument Description
count The number of packets or seconds you want to log after the rule triggers.
This unit of measure is specified with the metric argument, which follows the count
argument.
Select the metric you want to use to log by time or volume of traffic from those described in the following
table.
Caution High-bandwidth networks can see thousands of packets per second, and tagging a large number of packets
may seriously affect performance, so make sure you tune this setting for your network environment.
Argument Description
packets Logs the number of packets specified by the count after the rule triggers.
seconds Logs traffic for the number of seconds specified by the count after the rule triggers.
For example, when a rule with the following tag keyword value triggers:
optional Sets the specified states for a packet. Sets the states in the
set state_name&state_name
specified group if a group is defined.
mandatory Sets the specified state in the specified group for a packet, and
setx state_name
unsets all other states in the group.
mandatory Sets the specified states in the specified group for a packet, and
setx state_name&state_name
unsets all other states in the group.
no group Unsets the specified state if it is set, and sets the specified state
toggle state_name
if it is unset.
no group Unsets the specified states if they are set, and sets the specified
toggle state_name&state_name
states if they are unset.
mandatory Unsets all states set in the specified group, and sets all states unset
toggle all
in the specified group.
no group Determines if any of the specified states are set in the packet.
isset state_name|state_name
no group Determines if the specified states are not set in the packet.
isnotset state_name&state_name
no group Determines if any of the specified states is not set in the packet.
isnotset state_name|state_name
(no state) no group Use this in conjunction with any other operator to suppress event
noalert
generation.
• When using the setx operator, the specified state can only belong to the specified group, and not to any
other group.
• You can define the setx operator multiple times, specifying different states and the same group with
each instance.
• When you use the setx operator and specify a group, you cannot use the set, toggle, or unset operators
on that specified group.
• The isset and isnotset operators evaluate for the specified state regardless of whether the state is in
a group.
• During intrusion policy saves, intrusion policy reapplies, and access control policy applies (regardless
of whether the access control policy references one intrusion policy or multiple intrusion policies), if
you enable a rule that contains the isset or isnotset operator without a specified group, and you do
not enable at least one rule that affects flowbits assignment (set, setx, unset, toggle) for the
corresponding state name and protocol, all rules that affect flowbits assignment for the corresponding
state name are enabled.
• During intrusion policy saves, intrusion policy reapplies, and access control policy applies (regardless
of whether the access control policy references one intrusion policy or multiple intrusion policies), if
you enable a rule that contains the isset or isnotset operator with a specified group, all rules that
affect flowbits assignment (set, setx, unset, toggle) and define a corresponding group name are also
enabled.
an event if one of the attacks is detected. If the user is not logged in, the attack cannot exploit the vulnerability
and no event is generated.
The two rule fragments that follow illustrate this example. The first rule fragment looks for an IMAP login
confirmation from the IMAP server:
alert tcp any 143 -> any any (msg:"IMAP login"; content:"OK
Note that flowbits:set sets a state of logged_in, while flowbits:noalert suppresses the alert because you
are likely to see many innocuous login sessions on an IMAP server.
The next rule fragment looks for a LIST string, but does not generate an event unless the logged_in state has
been set as a result of some previous packet in the session:
content:"LIST"; flowbits:isset,logged_in;)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
In this case, if a previous packet has caused a rule containing the first fragment to trigger, then a rule containing
the second fragment triggers and generates an event.
(msg:"JPEG transfer";
content:"image/";pcre:"/^Content-?Type\x3a(\s*|\s*\r?\n\s+)image\x2fp?jpe?g/smi";
?flowbits:set,http.jpeg; flowbits:noalert;)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
The content and pcre keywords in the first rule fragment match a JPEG file download,
flowbits:set,http.jpeg sets the http.jpeg flowbits state, and flowbits:noalert stops the rule from
generating events. No event is generated because the rule’s purpose is to detect the file download and set the
flowbits state so one or more companion rules can test for the state name in combination with malicious
content and generate events when malicious content is detected.
The next rule fragment detects a GIF file download subsequent to the JPEG file download above:
The content and pcre keywords in the second rule match the GIF file download, flowbits:set,http.jpg
sets the http.jpg flowbit state, and flowbits:noalert stops the rule from generating an event. Note that the
http.jpeg state set by the first rule fragment is still set even though it is no longer needed; this is because the
JPEG download must have ended if a subsequent GIF download has been detected.
The third rule fragment is a companion to the first rule fragment:
(msg:"JPEG exploit";?flowbits:isset,http.jpeg;content:"|FF|";
pcre:"?/\xFF[\xE1\xE2\xED\xFE]\x00[\x00\x01]/";)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
In the third rule fragment, flowbits:isset,http.jpeg determines that the now-irrelevant http.jpeg state
is set, and content and pcre match content that would be malicious in a JPEG file but not in a GIF file. The
third rule fragment results in a false positive event for a nonexistent exploit in a JPEG file.
(msg:"JPEG transfer";
content:"image/";pcre:"/^Content-?Type\x3a(\s*|\s*\r?\n\s+)image\x2fp?jpe?g/smi";
?flowbits:setx,http.jpeg,image_downloads; flowbits:noalert;)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
When the first rule fragment detects a JPEG file download, the flowbits:setx,http.jpeg,image_downloads
keyword sets the flowbits state to http.jpeg and includes the state in the image_downloads group.
The next rule then detects a subsequent GIF file download:
When the second rule fragment matches the GIF download, the flowbits:setx,http.jpg,image_downloads
keyword sets the http.jpg flowbits state and unsets http.jpeg, the other state in the group.
The third rule fragment does not result in a false positive:
Because flowbits:isset,http.jpeg is false, the rules engine stops processing the rule and no event is
generated, thus avoiding a false positive even in a case where content in the GIF file matches exploit content
for a JPEG file.
You must configure the HTTP Inspect preprocessor to inspect HTTP responses and HTTP cookies to return
matches for rules using the http_encode keyword.
Also, you must enable both the decoding and alerting option for each specific encoding type in your HTTP
Inspect preprocessor configuration so the http_encode keyword in an intrusion rule can trigger events on that
encoding type.
The following table describes the encoding types this option can generate events for in HTTP URIs, headers,
cookies, and set-cookies:
double_encode Detects double encoding in the specified location when this encoding type is enabled
for decoding by the HTTP Inspect preprocessor.
non_ascii Detects non-ASCII characters in the specified location when non-ASCII characters
are detected but the detected encoding type is not enabled.
uencode Detects Microsoft %u encoding in the specified location when this encoding type is
enabled for decoding by the HTTP Inspect preprocessor.
bare_byte Detects bare byte encoding in the specified location when this encoding type is enabled
for decoding by the HTTP Inspect preprocessor.
Related Topics
The HTTP Inspect Preprocessor, on page 1732
Server-Level HTTP Normalization Options, on page 1733
Encoding Location
Specifies whether to search for the specified encoding type in an HTTP URI, header, or cookie, including a
set-cookie.
Encoding Type
Specifies one or more encoding types using one of the following formats:
encode_type
encode_type|encode_type|encode_type...
where encode_type is one of the following:
utf8
double_encode
non_ascii
uencode
bare_byte.
Note that you cannot use the negation (!) and OR (|) operators together.
http_encode Keyword example: Using Two http_endcode Keywords to Search for Two Encodings
The following example uses two http_encode keywords in the same rule to search the HTTP URI for UTF-8
AND Microsoft IIS %u encoding:
First, the http_encode keyword:
Tip Updating your vulnerability database (VDB) populates the intrusion rules editor with the most up-to-date
file types, versions, and groups.
Note The system does not automatically enable preprocessors to accomodate the file_type and file_group
keywords.
You must enable specific preprocessors if you want to generate events and, in an inline deployment, drop
offending packets for traffic matching your file_type or file_group keywords.
Netbios-ssn (SMB) The DCE/RPC preprocessor and the SMB File Inspection DCE/RPC preprocessor
option
Related Topics
Vulnerability Database Updates, on page 147
The FTP/Telnet Decoder, on page 1724
The Inline Normalization Preprocessor, on page 1784
The HTTP Inspect Preprocessor, on page 1732
The SMTP Preprocessor, on page 1759
The IMAP Preprocessor, on page 1754
The POP Preprocessor, on page 1757
The DCE/RPC Preprocessor, on page 1710
file_type
The file_type keyword allows you to specify the file type and version of a file detected in traffic. File type
arguments (for example, JPEG and PDF) identify the format of the file you want to find in traffic.
Note Do not use the file_type keyword with another file_type or file_group keyword in the same intrusion
rule.
The system selects Any Version by default, but some file types allow you to select version options (for
example, PDF version 1.7) to identify specific file type versions you want to find in traffic.
file_group
The file_group keyword allows you to select a Cisco-defined group of similar file types to find in traffic
(for example, multimedia or audio). File groups also include Cisco-defined versions for each file type in the
group.
Note Do not use the file_group keyword with another file_group or file_type keyword in the same intrusion
rule.
type of data the file_data keyword points to. You can use the file_data keyword to point to the beginning
of the following payload types:
• HTTP response body
To inspect HTTP response packets, the HTTP Inspect preprocessor must be enabled and you must
configure the preprocessor to inspect HTTP responses. The file_data keyword matches if the HTTP
Inspect preprocessor detects HTTP response body data.
• Normalized JavaScript
To inspect normalized JavaScript data, the HTTP Inspect preprocessor must be enabled and you must
configure the preprocessor to inspect HTTP responses. The file_data keyword matches if the HTTP
Inspect preprocessor detects JavaScript in response body data.
• SMTP payload
To inspect the SMTP payload, the SMTP preprocessor must be enabled. The file_data keyword matches
if the SMTP preprocessor detects SMTP data.
Related Topics
The HTTP Inspect Preprocessor, on page 1732
Server-Level HTTP Normalization Options, on page 1733
The SMTP Preprocessor, on page 1759
The IMAP Preprocessor, on page 1754
When normalized FTP, telnet, or SMTP traffic is detected, the pkt_data keyword points to the beginning of
the normalized packet payload. When other traffic is detected, the pkt_data keyword points to the beginning
of the raw TCP or UDP payload.
The following normalization options must be enabled for the system to normalizae teh corresponding traffic
for inspection by intrusion rules:
• Enable the FTP & Telnet preprocessor Detect Telnet Escape codes within FTP commands option to
normalize FTP traffic for inspection.
• Enable the FTP & Telnet preprocessor Normalize telnet option to normalize telnet traffic for inspection.
• Enable the SMTP preprocessor Normalize option to normalize SMTP traffic for inspection.
Related Topics
Client-Level FTP Options, on page 1729
Telnet Options, on page 1725
SMTP Preprocessor Options, on page 1760
base64_decode
The base64_decode keyword instructs the rules engine to decode packet data as Base64 data. Optional
arguments let you specify the number of bytes to decode and where in the data to begin decoding.
You can use the base64_decode keyword once in a rule; it must precede at least one instance of the base64_data
keyword.
Before decoding Base64 data, the rules engine unfolds lengthy headers that are folded across multiple lines.
Decoding ends when the rules engine encounters any the following:
• the end of a header line
• the specified number of bytes to decode
• the end of the packet
The following table describes the arguments you can use with the base64_decode keyword.
Argument Description
Bytes Specifies the number of bytes to decode. When not specified, decoding continues to
the end of a header line or the end of the packet payload, whichever comes first. You
can specify a positive, non-zero value.
Offset Determines the offset relative to the start of the packet payload or, when you also
specify Relative, relative to the current inspection location. You can specify a positive,
non-zero value.
base64_data
The base64_data keyword provides a reference for inspecting Base64 data decoded using the base64_decode
keyword. The base64_data keyword sets inspection to begin at the start of the decoded Base64 data. Optionally,
you can then use the positional arguments available for other keywords such as content or byte_test to
further specify the location to inspect.
You must use the base64_data keyword at least once after using the base64_decode keyword; optionally,
you can use base64_data multiple times to return to the beginning of the decoded Base64 data.
Note the following when inspecting Base64 data:
• You cannot use the fast pattern matcher.
• If you interrupt Base64 inspection in a rule with an intervening HTTP content argument, you must insert
another base64_data keyword in the rule before further inspecting Base64 data.
Related Topics
Overview: HTTP content and protected_content Keyword Arguments, on page 1588
content Keyword Fast Pattern Matcher Arguments, on page 1592
You configure these performance settings on a per-access-control-policy basis, and they apply to all intrusion
policies invoked by that parent access control policy.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Performance Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Click the Pattern Matching Limits tab in the Performance Settings pop-up window.
Step 4 Enter a value for the maximum number of events to queue in the Maximum Pattern States to Analyze Per
Packet field.
Step 5 To disable the inspection of packets that will be rebuilt into larger streams of data before and after stream
reassembly, check the Disable Content Checks on Traffic Subject to Future Reassembly check box.
Inspection before and after reassembly requires more processing overhead and may decrease performance.
Step 6 Click OK.
Step 7 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Caution Do not override default PCRE limits unless you are an experienced intrusion rule writer with knowledge
of the impact of degenerative patterns.
Option Description
Match Limit State Specifies whether to override Match Limit. You have the following options:
• select Default to use the value configured for Match Limit
• select Unlimited to permit an unlimited number of attempts
• select Custom to specify either a limit of 1 or greater for Match Limit, or
to specify 0 to completely disable PCRE match evaluations
Match Limit Specifies the number of times to attempt to match a pattern defined in a PCRE
regular expression.
Match Recursion Limit Specifies whether to override Match Recursion Limit. You have the following
State options:
• select Default to use the value configured for Match Recursion Limit
• select Unlimited to permit an unlimited number of recursions
• select Custom to specify either a limit of 1 or greater for Match Recursion
Limit, or to specify 0 to completely disable PCRE recursions
Note that for Match Recursion Limit to be meaningful, it must be smaller than
Match Limit.
Match Recursion Limit Specifies the number of recursions when evaluating a PCRE regular expression
against the packet payload.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Performance Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Click the Regular Expression Limits tab in the Performance Settings pop-up window.
Step 4 You can modify any of the options in Regular Expression Limits Overrides for Intrusion Rules, on page 1680.
Step 5 Click OK.
Step 6 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Option Description
Maximum Events The maximum number of events that can be stored for a given packet or packet stream.
Stored Per Packet
Maximum Events The number of events logged for a given packet or packet stream. This cannot exceed
Logged Per Packet the Maximum Events Stored Per Packet value.
Prioritize Event The value used to determine event ordering within the event queue. The highest
Logging By ordered event is reported through the user interface. You can select from:
• priority, which orders events in the queue by the event priority.
• content_length, which orders events by the longest identified content match.
When events are ordered by content length, rule events always take precedence
over decoder and preprocessor events.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Performance Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Click the Intrusion Event Logging Limits tab in the Performance Settings pop-up window.
Step 4 You can modify any of the options in Per Packet Intrusion Event Generation Limits, on page 1682.
Step 5 Click OK.
Step 6 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
As illustrated in the above figure, packet latency timing is tested at the following test points:
• after the completion of all decoder and preprocessor processing and before rule processing begins
• after processing by each rule
If the processing time exceeds the threshold at any test point, packet inspection ceases.
Tip Total packet processing time does not include routine TCP stream or IP fragment reassembly times.
Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing
the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed,
or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop
rule detects an intrusion in an inline deployment, the drop rule triggers an event and the packet is dropped.
Note No packets are evaluated against rules after processing for that packet ceases because of a packet latency
threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules,
cannot drop the packet.
Packet latency thresholding can improve system performance in both passive and inline deployments, and
can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing
time. These performance benefits might occur when, for example:
• for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an
excessive amount of time
• for inline deployments, a period of poor network performance, such as when someone downloads an
extremely large file, slows packet processing
In a passive deployment, stopping the processing of packets might not contribute to restoring network
performance because processing simply moves to the next packet.
Option Description
Threshold (microseconds) Specifies the time, in microseconds, when inspection of a packet ceases.
You can enable rule 134:3 to generate an event and, in an inline deployment, drop offending packets when
the system stops inspecting a packet because the packet latency threshold is exceeded. For more information,
see Intrusion Rule State Options, on page 1520.
Many factors affect measurements of system performance and packet latency, such as CPU speed, data rate,
packet size, and protocol type. For this reason, Cisco recommends that you use the threshold settings in the
following table until your own calculations provide you with settings tailored to your network environment.
5 Mbps 1000
Multiply the average microseconds per packet for your network by a significant safety factor to ensure that
you do not unnecessarily discontinue packet inspections.
For example, Cisco recommends a minimum packet latency threshold of 100 microseconds in a one gigabit
environment. This minimum recommendation is based on test data showing an average of 250,000 packets
per second, which is 0.25 packets per microsecond, or 4 microseconds per packet. Multiplying by a factor of
25 results in a recommended minimum threshold of 100 microseconds.
Note By default, latency-based performance settings for both packet and rule handling are automatically populated
by the latest deployed intrusion rule update, and Cisco recommends that you do not change the default.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Latency-Based Performance Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Click the Packet Handling tab in the Latency-Based Performance Settings pop-up window.
By default, Installed Rule Update is selected. Cisco recommends using this default.
The values displayed do not reflect the automated settings.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
A timer measures the processing time each time a packet is processed against a group of rules. Any time the
rule processing time exceeds a specified rule latency threshold, the system increments a counter. If the number
of consecutive threshold violations reaches a specified number, the system takes the following actions:
• suspends the rules for the specified period
• triggers an event indicating the rules have been suspended
• re-enables the rules when the suspension expires
• triggers an event indicating the rules have been re-enabled
The system zeroes the counter when the group of rules has been suspended, or when rule violations are not
consecutive. Permitting some consecutive violations before suspending rules lets you ignore occasional rule
violations that might have negligible impact on performance and focus instead on the more significant impact
of rules that repeatedly exceed the rule latency threshold.
The following example shows five consecutive rule processing times that do not result in rule suspension.
In the above example, the time required to process each of the first three packets violates the rule latency
threshold of 1000 microseconds, and the violations counter increments with each violation. Processing of the
fourth packet does not violate the threshold, and the violations counter resets to zero. The fifth packet violates
the threshold and the violations counter restarts at one.
The following example shows five consecutive rule processing times that do result in rule suspension.
In the second example, the time required to process each of the five packets violates the rule latency threshold
of 1000 microseconds. The group of rules is suspended because the rule processing time of 1100 microseconds
for each packet violates the threshold of 1000 microseconds for the specified five consecutive violations. Any
subsequent packets, represented in the figure as packets 6 through n, are not examined against suspended
rules until the suspension expires. If more packets occur after the rules are re-enabled, the violations counter
begins again at zero.
Rule latency thresholding has no effect on intrusion events triggered by the rules processing the packet. A
rule triggers an event for any intrusion detected in the packet, regardless of whether the rule processing time
exceeds the threshold. If the rule detecting the intrusion is a drop rule in an inline deployment, the packet is
dropped. When a drop rule detects an intrusion in a packet that results in the rule being suspended, the drop
rule triggers an intrusion event, the packet is dropped, and that rule and all related rules are suspended.
Note Packets are not evaluated against suspended rules. A suspended rule that would have triggered an event
cannot trigger that event and, for drop rules, cannot drop the packet.
Rule latency thresholding can improve system performance in both passive and inline deployments, and can
reduce latency in inline deployments, by suspending rules that take the most time to process packets. Packets
are not evaluated again against suspended rules until a configurable time expires, giving the overloaded device
time to recover. These performance benefits might occur when, for example:
• hastily written, largely untested rules require an excessive amount of processing time
• a period of poor network performance, such as when someone downloads an extremely large file, causes
slow packet inspection
Option Description
Threshold Specifies the time in microseconds that rules should not exceed when examining
a packet.
Consecutive Threshold Specifies the consecutive number of times rules can take longer than the time set
Violations Before for Threshold to inspect packets before rules are suspended.
Suspending Rule
Many factors affect measurements of system performance, such as CPU speed, data rate, packet size, and
protocol type. For this reason, Cisco recommends that you use the threshold settings in the following table
until your own calculations provide you with settings tailored to your network environment.
5 Mbps 5000
Multiply the average microseconds per packet for your network by a significant safety factor to ensure that
you do not unnecessarily suspend rules.
Note By default, latency-based performance settings for both packet and rule handling are automatically populated
by the latest deployed intrusion rule update, and Cisco recommends that you do not change the default.
Procedure
Step 1 In the access control policy editor, click the Advanced tab.
Step 2 Click the edit icon ( ) next to Latency-Based Performance Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 3 Click the Rule Handling tab in the Latency-Based Performance Settings pop-up window.
By default, Installed Rule Update is selected. Cisco recommends using this default.
The values displayed do not reflect the automated settings.
What to Do Next
• If you want to generate events, enable latency rules 134:1 and 134:2. For more information, see Intrusion
Rule State Options, on page 1520.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to Performance
Settings.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 2 Click the Performance Statistics tab in the pop-up window that appears.
Step 3 Modify the Sample time or Minimum number of packets as described above.
Step 4 Optionally, expand the Troubleshoot Options section and modify those options only if asked to do so by
Support.
Step 5 Click OK.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
• About Advanced Access Control Settings for Network Analysis and Intrusion Policies, page 1695
• The Default Intrusion Policy, page 1695
• Advanced Settings for Network Analysis Policies, page 1697
About Advanced Access Control Settings for Network Analysis and Intrusion
Policies
Many of the advanced settings in an access control policy govern intrusion detection and prevention
configurations that require specific expertise to configure. Advanced settings typically require little or no
modification and are not common to every deployment.
that should handle the connection, the remaining packets in the connection are handled and inspected
accordingly.
When you create an access control policy, its default intrusion policy depends on the default action you first
chose. Initial default intrusion policies for access control are as follows:
• Balanced Security and Connectivity (a system-provided policy) is the default intrusion policy for an
access control policy where you first chose the Intrusion Prevention default action.
• No Rules Active is the default intrusion policy for an access control policy where you first chose the
Block all traffic or Network Discovery default action. Although choosing this option disables intrusion
inspection on the allowed packets described above, it can improve performance if you are not interested
in intrusion data.
Note If you are not performing intrusion inspection (for example, in a discovery-only
deployment), keep the No Rules Active policy as your default intrusion policy.
If you change your default action after you create the access control policy, the default intrusion policy does
not automatically change. To change it manually, use the access control policy’s advanced options.
You can choose a system- or user-created policy.
Note The network analysis policy associated with the first matching network analysis rule preprocesses traffic
for the default intrusion policy. If there are no network analysis rules, or none match, the default network
analysis policy is used.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to the Network
Analysis and Intrusion Policies section.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 2 Select an intrusion policy from the Intrusion Policy used before Access Control rule is determined
drop-down list.
If you choose a user-created policy, you can click an edit icon ( ) to edit the policy in a new window. You
cannot edit system-provided policies.
Step 3 Optionally, select a different variable set from the Intrusion Policy Variable Set drop-down list. You can
also select the edit icon ( ) next to the variable set to create and edit variable sets. If you do not change the
variable set, the system uses a default set.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip The system-provided Balanced Security and Connectivity network analysis policy and the Balanced
Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates.
However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy
governs mostly intrusion rules.
A simple way to tune preprocessing is to create and use a custom network analysis policy as the default. For
advanced users with complex deployments, you can create multiple network analysis policies, each tailored
to preprocess traffic differently. Then, you can configure the system to use those policies to govern the
preprocessing of traffic using different security zones, networks, or VLANs.
To accomplish this, you add custom network analysis rules to your access control policy. A network analysis
rule is simply a set of configurations and conditions that specifies how you preprocess traffic that matches
those qualifications. You create and edit network analysis rules in the advanced options in an existing access
control policy. Each rule belongs to only one policy.
Each rule has:
• a set of rule conditions that identifies the specific traffic you want to preprocess
• an associated network analysis policy that you want to use to preprocess traffic that meets all the rules’
conditions
When it is time for the system to preprocess traffic, it matches packets to network analysis rules in top-down
order by rule number. Traffic that does not match any network analysis rules is preprocessed by the default
network analysis policy.
Note If you disable a preprocessor but the system needs to evaluate preprocessed packets against an enabled
intrusion or preprocessor rule, the system automatically enables and uses the preprocessor although it
remains disabled in the network analysis policy web interface. Tailoring preprocessing, especially using
multiple custom network analysis policies, is an advanced task. Because preprocessing and intrusion
inspection are so closely related, you must be careful that you allow the network analysis and intrusion
policies examining a single packet to complement each other.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to the Network
Analysis and Intrusion Policies section.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 2 From the Default Network Analysis Policy drop-down list, select a default network analysis policy.
If you choose a user-created policy, you can click an edit icon ( ) to edit the policy in a new window. You
cannot edit system-provided policies.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
You can add zone, network, and VLAN tag conditions to a rule. If you do not configure a particular condition
for a rule, the system does not match traffic based on that criterion. For example, a rule with a network condition
but no zone condition evaluates traffic based on its source or destination IP address, regardless of its ingress
or egress interface. Traffic that does not match any network analysis rules is preprocessed by the default
network analysis policy.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to the Network
Analysis and Intrusion Policies section.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Tip Click Network Analysis Policy List to view and edit existing custom network analysis policies.
Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.
Step 3 Click Add Rule.
Step 4 Configure the rule's conditions by clicking the tabs corresponding to the conditions you want to add; see Rule
Condition Types, on page 305.
Step 5 Click the Network Analysis tab and choose the Network Analysis Policy you want to use to preprocess the
traffic matching this rule.
Click the edit icon ( ) to edit a custom policy in a new window. You cannot edit system-provided policies.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
A network analysis rule is simply a set of configurations and conditions that specifies how you preprocess
traffic that matches those qualifications. You create and edit network analysis rules in the advanced options
in an existing access control policy. Each rule belongs to only one policy.
Procedure
Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to the Intrusion
and Network Analysis Policies section.
If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.
Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.
Step 3 Edit your custom rules. You have the following options:
• To edit a rule’s conditions, or change the network analysis policy invoked by the rule, click the edit icon
( ) next to the rule.
• To change a rule’s order of evaluation, click and drag the rule to the correct location. To select multiple
rules, use the Shift and Ctrl keys.
• To delete a rule, click the delete icon ( ) next to the rule.
Tip Right-clicking a rule displays a context menu that allows you to cut, copy, paste, edit, delete, and add
new network analysis rules.
Step 4 Click OK.
Step 5 Click Save to save the policy.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Tip System-provided intrusion and network analysis policies are similarly named but contain different
configurations. For example, the Balanced Security and Connectivity network analysis policy and the
Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion
rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the
intrusion policy governs mostly intrusion rules. Network analysis and intrusion policies work together to
examine your traffic.
You can also tailor traffic preprocessing options to specific security zones, networks, and VLANs by creating
multiple custom network analysis policies, then assigning them to preprocess different traffic. (Note that ASA
FirePOWER cannot restrict preprocessing by VLAN.)
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
Step 1 Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy.
Note If your custom user role limits access to the first path listed here, use the second path to access the
policy.
Step 2 Manage your network analysis policy:
• Compare—Click Compare Policies; see Comparing Policies, on page 297.
• Create — If you want to create a new network analysis policy, click Create Policy and proceed as
described in Custom Network Analysis Policy Creation, on page 1702.
• Delete — If you want to delete a network analysis policy, click the delete icon ( ), then confirm that
you want to delete the policy. You cannot delete a network analysis policy if an access control policy
references it.
If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission
to modify the configuration.
• Deploy—Click Deploy; see Deploying Configuration Changes, on page 288.
• Edit — If you want edit an existing network analysis policy, click the edit icon (
) and proceed as
described in Network Analysis Policy Settings and Cached Changes, on page 1704.
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 298.
The base policy defines the network analysis policy’s default settings. Modifying a setting in the new policy
overrides—but does not change—the settings in the base policy. You can use either a system-provided or
custom policy as your base policy.
The network analysis policy’s inline mode allows preprocessors to modify (normalize) and drop traffic to
minimize the chances of attackers evading detection. Note that in passive deployments, the system cannot
affect traffic flow regardless of the inline mode.
Related Topics
The Base Layer, on page 1482
Preprocessor Traffic Modification in Inline Deployments, on page 1707
Creating a Custom Network Analysis Policy, on page 1703
Editing Network Analysis Policies, on page 1705
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
Step 1 Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy.
Note If your custom user role limits access to the first path listed here, use the second path to access the
policy.
Step 2 Click Create Policy. If you have unsaved changes in another policy, click Cancel when prompted to return
to the Network Analysis Policy page.
Step 3 Enter a unique Name.
In a multidomain deployment, policy names must be unique within the domain hierarchy. The system may
identify a conflict with the name of a policy you cannot view in your current domain.
• Click Create and Edit Policy to create the policy and open it for editing in the advanced network
analysis policy editor.
Related Topics
Creating Custom User Roles, on page 61
In addition to custom policies that you create, the system provides two custom policies: Initial Inline Policy
and Initial Passive Policy. These two network analysis policies use the Balanced Security and Connectivity
network analysis policy as their base. The only difference between them is their inline mode, which allows
preprocessors to affect traffic in the inline policy and disables it in the passive policy. You can edit and use
these system-provided custom policies.
Note that you can create and edit network analysis as well as intrusion policies if your Firepower System user
account’s role is restricted to Intrusion Policy or Modify Intrusion Policy.
Related Topics
Creating a Custom Network Analysis Policy, on page 1703
Editing Network Analysis Policies, on page 1705
Note Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion
policies examining a single packet must complement each other. Tailoring preprocessing, especially using
multiple custom network analysis policies, is an advanced task.
The system caches one network analysis policy per user. While editing a network analysis policy, if you select
any menu or other path to another page, your changes stay in the system cache even if you leave the page.
Related Topics
How Policies Examine Traffic For Intrusions, on page 1466
Limitations of Custom Policies, on page 1475
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
Step 1 Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy.
Note If your custom user role limits access to the first path listed here, use the second path to access the
policy.
Step 2 Click the edit icon ( ) next to the network analysis policy you want to configure.
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
Step 4 To save changes you made in this policy since the last policy commit, choose Policy Information, then click
Commit Changes. If you leave the policy without committing changes, changes since the last commit are
discarded if you edit a different policy.
What to Do Next
• If you want a preprocessor to generate events and, in an inline deployment, drop offending packets,
enable rules for the preprocessor. For more information, see Setting Intrusion Rule States, on page 1521.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
The Base Layer, on page 1482
Changing the Base Policy, on page 1484
Preprocessor Configuration in a Network Analysis Policy, on page 1706
Preprocessor Traffic Modification in Inline Deployments, on page 1707
Managing Layers, on page 1488
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Note In most cases, preprocessors require specific expertise to configure and typically require little or no
modification. Tailoring preprocessing, especially using multiple custom network analysis policies, is an
advanced task. Because preprocessing and intrusion inspection are so closely related, the network analysis
and intrusion policies examining a single packet must complement each other.
Modifying a preprocessor configuration requires an understanding of the configuration and its potential impact
on your network.
Note that some advanced transport and network preprocessor settings apply globally to all networks, zones,
and VLANs where you deploy your access control policy. You configure these advanced settings in an access
control policy rather than in a network analysis policy.
Note also that you configure the sensitive data preprocessor, which detects sensitive data such as credit card
numbers and Social Security numbers in ASCII text, in intrusion policies.
Related Topics
The DCE/RPC Preprocessor, on page 1710
The DNP3 Preprocessor, on page 1775
The DNS Preprocessor, on page 1720
The FTP/Telnet Decoder, on page 1724
The GTP Preprocessor, on page 1752
The HTTP Inspect Preprocessor, on page 1732
The IMAP Preprocessor, on page 1754
The Inline Normalization Preprocessor, on page 1784
For a preprocessor configured in the network analysis policy to affect traffic, you must enable and correctly
configure the preprocessor, as well as correctly deploy managed devices inline. Finally, you must enable the
network analysis policy’s Inline Mode setting.
Tip To revert a preprocessor’s configuration to the settings in the base policy, click Revert to Defaults on a
preprocessor configuration page. When prompted, confirm that you want to revert.
When you disable a preprocessor, the sublink and Edit link no longer appear, but your configurations are
retained. Note that to perform their particular analysis, many preprocessors and intrusion rules require that
traffic first be decoded or preprocessed in a certain way. If you disable a required preprocessor, the system
automatically uses it with its current settings, although the preprocessor remains disabled in the network
analysis policy web interface.
If you want to assess how your configuration would function in an inline deployment without actually modifying
traffic, you can disable inline mode. In passive deployments or inline deployments in tap mode, the system
cannot affect traffic regardless of the inline mode setting.
Note Disabling inline mode can affect intrusion event performance statistics graphs. With inline mode enabled
in an inline deployment, the Intrusion Event Performance page (Overview > Summary > Intrusion Event
Performance) displays graphs that represent normalized and blocked packets. If you disable inline mode,
or in a passive deployment, many of the graphs display data about the traffic the system would have
normalized or dropped.
Note In an inline deployment, Cisco recommends that you enable inline mode and configure the inline
normalization preprocessor with the Normalize TCP Payload option enabled. In a passive deployment,
Cisco recommends that you use adaptive profile updates.
Related Topics
Advanced Transport/Network Preprocessor Settings, on page 1779
Checksum Verification, on page 1782
The Inline Normalization Preprocessor, on page 1784
Checksum Verification, on page 1782
Intrusion Event Performance Statistics Graph Types, on page 2315
The two DCE/RPC PDU protocols have their own unique headers and data characteristics. For example, the
connection-oriented DCE/RPC header length is typically 24 bytes and the connectionless DCE/RPC header
length is fixed at 80 bytes. Also, correct fragment order of fragmented connectionless DCE/RPC cannot be
handled by a connectionless transport and, instead, must be ensured by connectionless DCE/RPC header
values; in contrast, the transport protocol ensures correct fragment order for connection-oriented DCE/RPC.
The DCE/RPC preprocessor uses these and other protocol-specific characteristics to monitor both protocols
for anomalies and other evasion techniques, and to decode and defragment traffic before passing it to the rules
engine.
The following diagram illustrates the point at which the DCE/RPC preprocessor begins processing DCE/RPC
traffic for the different transports.
• set the preprocessor to detect when there is an attempt to connect to one or more shared SMB resources
that you identify
• configure the preprocessor to detect files in SMB traffic and to inspect a specified number of bytes in a
detected file
• modify an advanced option that should be modified only by a user with SMB protocol expertise; this
option lets you set the preprocessor to detect when a number of chained SMB AndX commands exceed
a specified maximum number
In addition to enabling SMB traffic file detection in the DCE/RPC preprocessor, you can configure a file
policy to optionally capture and block these files, or submit them to the Cisco AMP cloud for dynamic analysis.
Within that policy, you must create a file rule with an Action of Detect Files or Block Files and a selected
Application Protocol of Any or NetBIOS-ssn (SMB).
Related Topics
Creating a File Policy, on page 1392
The Microsoft IIS proxy server and the DCE/RPC server can be on the same host or on different hosts. Separate
proxy and server options provide for both cases. Note the following in the figure:
• The DCE/RPC server monitors port 593 for DCE/RPC client traffic, but the firewall blocks port 593.
Firewalls typically block port 593 by default.
• RPC over HTTP transports DCE/RPC over HTTP using well-known HTTP port 80, which firewalls are
likely to permit.
• Example 1 shows that you would choose the RPC over HTTP proxy option to monitor traffic between
the DCE/RPC client and the Microsoft IIS RPC proxy server.
• Example 2 shows that you would choose the RPC over HTTP server option when the Microsoft IIS
RPC proxy server and the DCE/RPC server are located on different hosts and the device monitors traffic
between the two servers.
• Traffic is comprised solely of connection-oriented DCE/RPC over TCP after RPC over HTTP completes
the proxied setup between the DCE/RPC client and server.
Reassembly Threshold
When Enable Defragmentation is selected, 0 disables this option, or specifies a minimum number of
fragmented DCE/RPC bytes and, if applicable, segmented SMB bytes to queue before sending a reassembled
packet to the rules engine. A low value increases the likelihood of early detection but could have a negative
impact on performance. You should test for performance impact if you enable this option.
Make sure that the Reassembly Threshold option is greater than or equal to the depth to which the rules need
to detect.
Enable Defragmentation
Specifies whether to defragment fragmented DCE/RPC traffic. When disabled, the preprocessor still detects
anomalies and sends DCE/RPC data to the rules engine, but at the risk of missing exploits in fragmented
DCE/RPC data.
Although this option provides the flexibility of not defragmenting DCE/RPC traffic, most DCE/RPC exploits
attempt to take advantage of fragmentation to hide the exploit. Disabling this option would bypass most known
exploits, resulting in a large number of false negatives.
Related Topics
Basic content and protected_content Keyword Arguments, on page 1585
Overview: The byte_jump and byte_test Keywords
Note You must enable at least one DCE/RPC transport in the default target-based policy except when you have
added a DCE/RPC target-based policy that has at least one transport enabled. For example, you might
want to specify the hosts for all DCE/RPC implementations and not have the default target-based policy
deploy to unspecified hosts, in which case you would not enable a transport for the default target-based
policy.
Optionally, you can also enable and specify auto-detection ports, that is, ports that the preprocessor tests first
to determine if they carry DCE/RPC traffic and continues processing only when it detects DCE/RPC traffic.
When you enable auto-detection ports, ensure that they are set to the port range from 1025 to 65535 to cover
the entire ephemeral port range.
Note that auto-detection occurs only for ports not already identified by transport detection ports.
It is unlikely that you would enable or specify auto-detection ports for the RPC over HTTP Proxy Auto-Detect
Ports option or the SMB Auto-Detect Ports option because there is little likelihood that traffic for either would
occur or even be possible except on the specified default detection ports.
Each target-based policy allows you to specify the various options below. If no preprocessor rule is mentioned
in the following descriptions, the option is not associated with a preprocessor rule.
Networks
The host IP addresses where you want to deploy the DCE/RPC target-based server policy. Also named the
Server Address field in the Add Target pop-up window when you add a target-based policy.
You can specify a single IP address or address block, or a comma-separated list of either or both. You can
configure up to 255 total profiles including the default policy.
Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using
literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled
objects allows descendant domain administrators to tailor Global configurations to their local environments.
Note that the default setting in the default policy specifies all IP addresses on your monitored network
segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify
an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in
another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).
Policy
The Windows or Samba DCE/RPC implementation used by the targeted host or hosts on your monitored
network segment.
Note that you can enable the Auto-Detect Policy on SMB Session global option to automatically override
the setting for this option on a per session basis when SMB is the DCE/RPC transport.
Caution Only someone who is expert in the SMB protocol should modify the setting for the SMB Maximum
AndX Chains option.
You can enable rule 133:20 to generate events and, in an inline deployment, drop offending packets for this
option. See Setting Intrusion Rule States, on page 1521.
TCP Ports
Enables detection of DCE/RPC traffic in TCP on each specified port.
Legitimate DCE/RPC traffic and exploits might use a wide variety of ports, and other ports above port 1024
are common. Typically, when this option is enabled you should also enable TCP Auto-Detect Ports with a
port range from 1025 to 65535 for that option.
UDP Ports
Enables detection of DCE/RPC traffic in UDP on each specified port.
Legitimate DCE/RPC traffic and exploits might use a wide variety of ports, and other ports above port 1024
are common. Typically, when this option is enabled you should also enable UDP Auto-Detect Ports with a
port range from 1025 to 65535 for that option.
SMB Ports
Enables detection of DCE/RPC traffic in SMB on each specified port.
You could encounter SMB traffic using the default detection ports. Other ports are rare. Typically, use the
default settings.
Note that you can enable the Auto-Detect Policy on SMB Session global option to automatically override
the policy type configured for a targeted policy on a per session basis when SMB is the DCE/RPC transport.
Enter a value in this field equal to or smaller than the one defined in the File and Malware Settings section of
the Advanced tab in your access control policy. If you set a value for this option larger than the one defined
for Limit the number of bytes inspected when doing file type detection, the system uses the access control
policy setting as the functional maximum.
If SMB File Inspection is set to Off, this field is disabled.
Related Topics
Firepower System IP Address Conventions, on page 12
You configure the DCE/RPC preprocessor by modifying any of the global options that control how the
preprocessor functions, and by specifying one or more target-based server policies that identify the DCE/RPC
servers on your network by IP address and by either the Windows or Samba version running on them.
Target-based policy configuration also includes enabling transport protocols, specifying the ports carrying
DCE/RPC traffic to those hosts, and setting other server-specific options.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
IP addresses to constrain this configuration can have unexpected results. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.
Procedure
Step 1 Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy.
Note If your custom user role limits access to the first path listed here, use the second path to access the
policy.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
Step 3 Click Settings in the navigation panel on the left.
Step 4 If DCE/RPC Configuration under Application Layer Preprocessors is disabled, click Enabled.
Step 5 Click the edit icon ( ) next to DCE/RPC Configuration.
Step 6 Modify the options in the Global Settings section; see DCE/RPC Global Options, on page 1713.
Step 7 You have the following choices:
• Add a server profile — Click the add icon ( ) next to Servers. Specify one or more IP addresses in
the Server Address field, then click OK.
• Delete a server profile — Click the delete icon ( ) next to the policy.
• Edit a server profile — Click the configured address for the profile under Servers, or click default. You
can modify any of the settings in the Configuration section; see DCE/RPC Target-Based Policy Options,
on page 1714.
Step 8 To save changes you made in this policy since the last policy commit, click Policy Information, then click
Commit Changes.
If you leave the policy without committing changes, cached changes since the last commit are discarded if
you edit a different policy.
What to Do Next
• If you want to generate intrusion events, enable DCE/RPC preprocessor rules (GID 132 or 133). For
more information, see Setting Intrusion Rule States, on page 1521, DCE/RPC Global Options, on page
1713, DCE/RPC Target-Based Policy Options, on page 1714, and Traffic-Associated DCE/RPC Rules, on
page 1718.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Firepower System IP Address Conventions, on page 12
File and Malware Inspection Performance and Storage Options, on page 1411
DCE/RPC Keywords, on page 1634
Managing Layers, on page 1488
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
The most common type of DNS name server response provides one or more IP addresses that correspond to
domain names in the query that prompted the response. Other types of server responses provide, for example,
the destination of an email message or the location of a name server that can provide information not available
from the server originally queried.
A DNS response is comprised of:
• a message header
• a Question section that contains one or more requests
• three sections that respond to requests in the Question section
◦Answer
◦Authority
◦Additional Information.
Responses in these three sections reflect the information in resource records (RR) maintained on the name
server. The following table describes these three sections.
Authority Optionally, one or more resource records that point The name of an authoritative name server for
to an authoritative name server the response
Additional Information Optionally, one or more resource records that The IP address of another server to query
provided additional information related to the
Answer sections
There are many types of resource records, all adhering to the following structure:
Theoretically, any type of resource record can be used in the Answer, Authority, or Additional Information
section of a name server response message. The DNS preprocessor inspects any resource record in each of
the three response sections for the exploits it detects.
The Type and RData resource record fields are of particular importance to the DNS preprocessor. The Type
field identifies the type of resource record. The RData (resource data) field provides the response content.
The size and content of the RData field differ depending on the type of resource record.
DNS messages typically use the UDP transport protocol but also use TCP when the message type requires
reliable delivery or the message size exceeds UDP capabilities. The DNS preprocessor inspects DNS server
responses in both UDP and TCP traffic.
The DNS preprocessor does not inspect TCP sessions picked up in midstream, and ceases inspection if a
session loses state because of dropped packets.
Ports
This field specifies the source port or ports the DNS preprocessor should monitor for DNS server responses.
Separate multiple ports with commas.
The typical port to configure for the DNS preprocessor is well-known port 53, which DNS name servers use
for DNS messages in both UDP and TCP.
4 MF a mail forwarder
You can enable rule 131:1 to generate events and, in an inline deployment, drop offending packets for this
option. See Setting Intrusion Rule States, on page 1521.
You can enable rule 131:2 to generate events and, in an inline deployment, drop offending packets for this
option. See Setting Intrusion Rule States, on page 1521.
In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
Procedure
Step 1 Choose Policies > Access Control, then click Network Analysis Policy or Policies > Access Control >
Intrusion, then click Network Analysis Policy.
Note If your custom user role limits access to the first path listed here, use the second path to access the
policy.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If a view icon ( ) appears instead, the configuration belongs to an ancestor domain, or you do not have
permission to modify the configuration.
What to Do Next
• If you want to generate intrusion events, enable DNS preprocessor. rules (GID 131). For more information,
see Setting Intrusion Rule States, on page 1521 and DNS Preprocessor Options, on page 1722.
• Deploy configuration changes; see Deploying Configuration Changes, on page 288.
Related Topics
Layers in Intrusion and Network Analysis Policies, on page 1481
Conflicts and Changes: Network Analysis and Intrusion Policies, on page 1478
Stateful Inspection
When selected, causes the FTP/Telnet decoder to save state and provide session context for individual packets
and only inspect reassembled sessions. When cleared, analyzes each individual packet without session context.
To check for FTP data transfers, this option must be selected.
Telnet Options
You can enable or disable normalization of telnet commands by the FTP/Telnet decoder, enable or disable a
specific anomaly case, and set the threshold number of Are You There (AYT) attacks to permit.
If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a
preprocessor rule.
Ports
Indicates the ports whose telnet traffic you want to normalize. Telnet typically connects to TCP port 23. In
the interface, list multiple ports separated by commas.
Caution Because encrypted traffic (SSL) cannot be decoded, adding port 22 (SSH) could yield unexpected results.
Normalize
Normalizes telnet traffic to the specified ports.
Detect Anomalies
Enables detection of Telnet SB (subnegotiation begin) without the corresponding SE (subnegotiation end).
Telnet supports subnegotiation, which begins with SB (subnegotiation begin) and must end with an SE
(subnegotiation end). However, certain implementations of Telnet servers will ignore the SB without a
corresponding SE. This is anomalous behavior that could be an evasion case. Because FTP uses the Telnet
protocol on the control connection, it is also susceptible to this behavior.
You can enable rule 126:3 to generate an event and, in an inline deployment, drop offending packets when
this anomaly is detected in Telnet traffic, and rule 125:9 when it is detected on the FTP command channel.
See Setting Intrusion Rule States, on page 1521.