Professional Documents
Culture Documents
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.
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: 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)
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.
Realm, User, User Group, and ISE Attribute Access Control Rule Conditions 9-1
Adding a Realm, User, or User Group Condition to an Access Control Rule 9-3
35-6
Time 41-8
42-5
The Cisco ASA FirePOWER module® is a module that can be deployed on Cisco ASA5506-X,
ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5512-X, ASA5515-X, ASA5516-X, ASA5525-X,
ASA5545-X, ASA5555-X, ASA5585-X-SSP-10, ASA5585-X-SSP-20, ASA5585-X-SSP-40,
ASA5585-X-SSP-60, and ISA3000 devices. The module is designed to help you handle network traffic
in a way that complies with your organization’s security policy—your guidelines for protecting your
network. A security policy may also include an acceptable use policy (AUP), which provides employees
with guidelines of how they may use your organization’s systems.
This guide provides information about onbox configuration of the features and functionality of the ASA
FirePOWER module, accessible via ASDM. The explanatory text, diagrams, and procedures in each
chapter provide detailed information to help you navigate the user interface, maximize the performance
of your system, and troubleshoot complications.
Note If you enable command authorization on the ASA that hosts the ASA FirePOWER module, you must log
in with a user name that has privilege level 15 to see the ASA FirePOWER home, configuration, and
monitoring pages. Read-only or monitor-only access to ASA FirePOWER pages other than the status
page is not supported.
The topics that follow introduce you to the ASA FirePOWER module, describe its key components, and
help you understand how to use this guide:
• Introduction to the ASA FirePOWER Module, page 1-1
• ASA FirePOWER Module Components, page 1-2
• License Conventions, page 1-3
• IP Address Conventions, page 1-4
• simple, easily-determined transport and network layer characteristics: source and destination, port,
protocol, and so on
• the latest contextual information on the traffic, including characteristics such as reputation, risk,
business relevance, application used, or URL visited
• Microsoft Active Directory LDAP users in your organization
Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility
and performance. For example, reputation-based blacklisting, because it uses simple source and
destination data, can block prohibited traffic early in the process, while detecting and blocking intrusions
and exploits is a last-line defense.
Access Control
Access control is a policy-based feature that allows you to specify, inspect, and log the traffic that can
traverse your network. An access control policy determines how the system handles traffic on your
network.
The simplest access control policy handles all traffic using its default action. You can set this default
action to block or trust all traffic without further inspection, or to inspect traffic for intrusions.
A more complex access control policy can blacklist traffic based on Security Intelligence data, as well
as use access control rules to exert granular control over network traffic logging and handling. These
rules can be simple or complex, matching and inspecting traffic using multiple criteria; you can control
traffic by security zone, network or geographical location, port, application, requested URL, and user.
Advanced access control options include preprocessing and performance.
Each access control 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.
If the system-provided policies do not fully address the security needs of your organization, custom
policies can improve the performance of the system in your environment and can provide a focused view
of the malicious traffic and policy violations occurring on your network. By creating and tuning custom
policies you can configure, at a very granular level, how the system processes and inspects the traffic on
your network for intrusions.
File Control
File control allows devices to detect and block your users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. You configure file control as part
of your overall access control configuration; file policies associated with access control rules inspect
network traffic that meets rule conditions.
License Conventions
The License statement at the beginning of a section indicates the license required to use the feature
described in the section, as follows:
Protection
A Protection license allows devices to perform intrusion detection and prevention, file control, and
Security Intelligence filtering.
Control
A Control license allows devices to perform user and application control. A Control license requires
a Protection license.
URL Filtering
A URL Filtering license allows devices to use regularly updated cloud-based category and
reputation data to determine which traffic can traverse your network, based on the URLs requested
by monitored hosts. A URL Filtering license requires a Protection license.
Malware
A Malware license allows devices to perform network-based advanced malware protection (AMP),
that is, to detect, capture, and block malware in files transmitted over your network. It also allows
you to view trajectories, which track files transmitted over your network. A Malware license
requires a Protection license.
Because licensed capabilities are often additive, this documentation only provides the highest required
license for each feature. For example, if a feature requires Protection and Control licenses, only Control
is listed. However, if functionality requires licenses that are not additive, the documentation lists them
with a plus (+) character.
An “or” statement in a License statement indicates that a particular license is required to use the feature
described in the section, but an additional license can add functionality. For example, within a file policy,
some file rule actions require a Protection license while others require a Malware license. So, the License
statement for the documentation on file rules lists “Protection or Malware.”
IP Address Conventions
You can use IPv4 Classless Inter-Domain Routing (CIDR) notation and the similar IPv6 prefix length
notation to define address blocks in many places in the ASA FirePOWER module.
CIDR notation uses a network IP address combined with a bit mask to define the IP addresses in the
specified block of addresses. For example, the following table lists the private IPv4 address spaces in
CIDR notation.
Similarly, IPv6 uses a network IP address combined with a prefix length to define the IP addresses in a
specified block. For example, 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.
When you use CIDR or prefix length notation to specify a block of IP addresses, the ASA FirePOWER
module uses only the portion of the network IP address specified by the mask or prefix length. For
example, if you type 10.1.2.3/8, the ASA FirePOWER module uses 10.0.0.0/8.
In other words, although Cisco recommends the standard method of using a network IP address on the
bit boundary when using CIDR or prefix length notation, the ASA FirePOWER module does not require
it.
For increased flexibility and ease-of-use, the ASA FirePOWER module allows you to create named
objects, which are reusable configurations that associate a name with a value so that when you want to
use that value, you can use the named object instead.
You can create the following types of objects:
• network-based objects that represent IP addresses and networks, port/protocol pairs, security zones,
and origin/destination country (geolocation)
• objects that help you handle traffic, including Security Intelligence feeds and lists, application
filters, URLs, file lists, and intrusion policy variable sets
You can use these objects in various places in the ASA FirePOWER module, including access control
policies, network analysis policies, intrusion policies and rules, reports, dashboards, and so on.
Grouping objects allows you to reference multiple objects with a single configuration. You can group
network, port, and URL objects.
Note In most cases, editing an object used in a policy requires a policy reapply for your changes to take effect.
Editing a security zone also requires that you reapply the appropriate device configurations.
Grouping Objects
License: Any
You can group network, port, and URL objects. The system allows you to use objects and object groups
interchangeably. For example, anywhere you would use a port object, you can also use a port object
group. Objects and object groups of the same type cannot have the same name.
When you edit an object group used in a policy (for example, a network object group used in an access
control policy), you must reapply the policy 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. For example, you cannot delete a URL group that
you are using in a URL condition in a saved access control policy.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under the type of Network, Port, or URL object you want to group, select Object Groups.
The page for the type of object you are grouping appears.
Step 3 Click the Add button that corresponds with the object you want to group.
A pop-up window appears where you can create the group.
Step 4 Type a Name for the group. You can use any printable standard ASCII characters except curly braces ({}).
Step 5 Select one or more objects and click Add.
• Use Shift and Ctrl to select multiple objects, or right-click and Select All.
• Use the filter field ( ) to search for existing objects to include, which updates as you type to
display matching items. Click the reload icon ( ) above the search field or click the clear icon ( )
in the search field to clear the search string.
• Click the add icon ( ) to create objects on the fly if no existing objects meet your needs.
Step 6 Click Store ASA FirePOWER Changes.
Step 1 Click a column heading. To sort in the opposite direction, click the heading again.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under Network, select Individual Objects.
Step 3 Click Add Network.
The Network Objects pop-up window appears.
Step 4 Type a Name for the network object. You can use any printable standard ASCII characters except curly
braces ({}).
Step 5 For each IP address or address block you want to add to the network object, type its value and click Add.
Step 6 Click Store ASA FirePOWER Changes.
The network object is added.
Note If you want strict control over when the system downloads a feed from the Internet, you can disable
automatic updates for that feed. However, Cisco recommends that you allow automatic updates.
Although you can manually perform on-demand updates, allowing the system to download feeds on a
regular basis provides you with the most up-to-date, relevant data.
A Security Intelligence list, contrasted with a feed, is a simple static list of IP addresses that you
manually upload to the system. Use custom lists to augment and fine-tune feeds and the global whitelist
and blacklist. Note that editing custom lists (as well as editing network objects and removing IP
addresses from the global whitelist or blacklist) require an access control policy apply for your changes
to take effect.
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.
Intelligence
Capability Global Whitelist or Blacklist Feed Custom Feed Custom List Network Object
method of use in access control policies by in any access control policy as either a whitelist or blacklist object
default
can be constrained no yes yes yes yes
by security zone?
can be deleted? no no yes, unless currently being used in a saved or applied
access control policy
object manager edit delete IP addresses only disable or fully modify upload a fully modify
capabilities change update modified list
frequency only
requires access yes when deleting (adding IP no no yes yes
policy control addresses does not require
reapply when reapply)
modified?
For more information on creating, managing, and using Security Intelligence lists and feeds, see:
• Working with the Global Whitelist and Blacklist, page 2-6
• Working with the Intelligence Feed, page 2-6
• Working with Custom Security Intelligence Feeds, page 2-7
• Manually Updating Security Intelligence Feeds, page 2-8
• Working with Custom Security Intelligence Lists, page 2-8
• Blacklisting Using Security Intelligence IP Address Reputation, page 5-1
Step 1 On the object manager’s Security Intelligence page, next to the global whitelist or blacklist, click the
edit icon ( ).
The Global Whitelist or Global Blacklist pop-up window appears.
Step 2 Next to the IP addresses you want to remove from the list, click the delete icon ( ).
To delete multiple IP addresses at once, use the Shift and Ctrl keys to select them, then right-click and
select Delete.
Step 3 Click Store ASA FirePOWER Changes.
Your changes are saved, but you must apply your access control policies for them to take effect
Because the intelligence feed is regularly updated, the system can use up-to-date information to filter
your network traffic. Malicious IP addresses that represent security threats such as malware, spam,
botnets, and phishing may appear and disappear faster than you can update and apply new policies.
Although you cannot delete the Intelligence Feed, editing it allows you to change the frequency of its
updates. By default, the feed updates every two hours.
Step 1 On the object manager’s Security Intelligence page, next to the Intelligence Feed, click the edit icon
( ).
The Security Intelligence pop-up window appears.
Step 2 Edit the Update Frequency.
You can select from various intervals from two hours to one week. You can also disable feed updates.
Step 3 Click Store ASA FirePOWER Changes.
Your changes are saved.
Step 1 On the object manager’s Security Intelligence page, click Add Security Intelligence.
The Security Intelligence pop-up window appears.
Step 2 Type a Name for the feed. You can use any printable standard ASCII characters except curly braces ({}).
Step 3 From the Type drop-down list, specify that you want to configure a Feed.
The pop-up window updates with new options.
Step 4 Specify a Feed URL and optionally, an MD5 URL.
Step 5 Select an Update Frequency.
You can select from various intervals from two hours to one week. You can also disable feed updates.
Step 6 Click Store ASA FirePOWER Changes.
The Security Intelligence feed object is created. Unless you disabled feed updates, the system attempts
to download and verify the feed. You can now use the feed object in access control policies.
Step 1 On the object manager’s Security Intelligence page, click Update Feeds.
Step 2 Confirm that you want to update all feeds.
A confirmation dialog appears, warning you that it can take several minutes for the update to take effect.
Step 3 Click OK.
After the system downloads and verifies the feed updates, it begins filtering traffic using the updated
feeds.
Step 1 On the object manager’s Security Intelligence page, click Add Security Intelligence.
The Security Intelligence pop-up window appears.
Step 2 Type a Name for the list. You can use any printable standard ASCII characters except curly braces ({}).
Step 3 From the Type drop-down list, specify that you want to upload a List.
The pop-up window updates with new options.
Step 4 Click Browse to browse to the list .txt file, then click Upload.
The list is uploaded. The pop-up window displays the total number of IP addresses and address blocks
that the system found in the list.
If the number is not what you expected, check the formatting of the file and try again.
Step 5 Click Store ASA FirePOWER Changes.
The Security Intelligence list object is saved. You can now use it in access control policies.
Step 1 On the object manager’s Security Intelligence page, next to the list you want to update, click the edit
icon ( ).
The Security Intelligence pop-up window appears.
Step 2 If you need a copy of the list to edit, click Download, then follow the prompts to save the list as a text file.
Step 3 Make changes to the list as necessary.
Step 4 On the Security Intelligence pop-up window, click Browse to browse to the modified list, then click
Upload.
The list is uploaded.
Step 5 Click Store ASA FirePOWER Changes.
Your changes are saved. If the list is being used by an active access control policy, you must apply the
policy for your changes to take effect.
You cannot delete a port object that is in use. Additionally, after you edit a port object used in an access
control, you must reapply the policy for your changes to take effect.
Note that 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 apply on policy apply. Additionally, 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under Port, select Individual Objects.
Step 3 Click Add Port.
The Port Objects pop-up window appears.
Step 4 Type a Name for the port object. You can use any printable standard ASCII characters except curly braces
({}).
Step 5 Select a Protocol.
You can quickly select TCP, UDP, IP, ICMP, or IPv6-ICMP, or you can use the Other drop-down list to select
either a different protocol or All protocols.
Step 6 Optionally, restrict a TCP or UDP port object using a Port or port range.
You can specify any port from 1 to 65535 or any to match all ports. Use a hyphen to specify a range of
ports.
Step 7 Optionally, restrict an ICMP or IPV6-ICMP port object using a Type and, if appropriate, a related Code.
When you create an ICMP or IPv6-ICMP object, you can specify the type and, if applicable, the code.
For more information on ICMP types and codes, see
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml and
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml. You can set the type to
any to match any type or set the code to any to match any code for the specified type.
Step 8 Optionally, select Other and a protocol from the drop-down list. If you select All protocols, type a port
number in the Port field.
Step 9 Click Store ASA FirePOWER Changes.
The port object is added.
Note that to block HTTPS traffic, you can enter the URL from the Secure Sockets Layer (SSL) certificate
for the traffic. When entering a URL from a certificate, enter the domain name and omit subdomain
information. (For example, type example.com rather than www.example.com.) If you block traffic based
on the certificate URL, both HTTP and HTTPS traffic to that website are blocked.
You cannot delete a URL object that is in use. Additionally, after you edit a URL object used in an access
control policy, you must reapply the policy for your changes to take effect.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under URL, select Individual Objects.
Step 3 Click Add URL.
The URL Objects pop-up window appears.
Step 4 Type a Name for the URL object. You can use any printable standard ASCII characters except curly
braces ({}).
Step 5 Type the URL or IP address for the URL object.
Step 6 Click Store ASA FirePOWER Changes.
The URL object is added.
As with ASA FirePOWER module-provided application filters, you can use user-defined application
filters in access control rules.
You use the object manager (Configuration > ASA FirePOWER Configuration > Object Management) to create and
manage application filters. Note that you can also create an application filter on the fly while adding an
application condition to an access control rule.
The Application Filters list contains the ASA FirePOWER module-provided application filters that you
can select to build your own filter. You can constrain the filters that appear by using a search string; this
is especially useful for categories and tags.
The Available Applications list contains the individual applications in the filters you select. You can also
constrain the applications that appear by using a search string.
The system links multiple filters of the same filter type with an OR operation. Consider a scenario where
the medium risk filter contains 100 applications and the high risk filter contains 50 applications. If you
select both filters, the system would display 150 available applications.
The system links different types of filters with an AND operation. For example, if you select the medium
and high risk filters and the medium and high business relevance filters, the system displays the
applications that have medium or high risk, and also have medium or high business relevance.
Tip Click an information icon ( ) for more information about the associated application. To display
additional information, click any of the Internet search links in the pop-up that appears.
After you determine the applications you want to add to the filter, you can add them either individually,
or, if you selected an application filter, All apps matching the filter. You can add multiple filters and multiple
applications, in any combination, as long as the total number of items in the Selected Applications and
Filters list does not exceed 50.
After you create the application filter, it is listed on the Application Filters page of the object manager.
The page displays the total number of conditions that comprise each filter.
For information on sorting and filtering the application filters that appear, see Using the Object Manager,
page 2-2. Note that you cannot delete an application filter that is in use. Additionally, after you edit an
application filter used in an access control policy, you must reapply the policy for your changes to take
effect.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Click Application Filters.
The Application Filters section appears.
Step 3 Click Add Application Filter.
The Application Filter pop-up window appears.
Step 4 Give the filter a Name. You can use any printable standard ASCII characters except curly braces ({}).
Step 5 Optionally, use ASA FirePOWER module-provided filters in the Application Filters list to narrow the list
of applications you want to add to the filter:
• Click the arrow next to each filter type to expand and collapse the list.
• Right-click a filter type and click Check All or Uncheck All. Note that the list indicates how many
filters you have selected of each type.
• To narrow the filters that appear, type a search string in the Search by name field; this is especially
useful for categories and tags. To clear the search, click the clear icon ( ).
• To refresh the filters list and clear any selected filters, click the reload icon ( ).
• To clear all filters and search fields, click Clear All Filters.
The applications that match the filters you select appear in the Available Applications list. The list
displays 100 applications at a time.
Step 6 Select the applications that you want to add to the filter from the Available Applications list:
• Select All apps matching the filter to add all the applications that meet the constraints you specified in
the previous step.
• To narrow the individual applications that appear, type a search string in the Search by name field. To
clear the search, click the clear icon ( ).
• Use the paging icons at the bottom of the list to browse the list of individual available applications.
• Use Shift and Ctrl keys to select multiple individual applications. Right-click to Select All currently
displayed individual applications.
• To refresh the applications list and clear any selected applications, click the reload icon ( ).
You cannot select individual applications and All apps matching the filter at the same time.
Step 7 Add the selected applications to the filter. You can click and drag, or you can click Add to Rule.
The result is the combination of:
• the selected Application Filters
• either the selected individual Available Applications, or All apps matching the filter
You can add up to 50 applications and filters to the filter. To delete an application or filter from the
selected applications, click the appropriate delete icon ( ). You can also select one or more
applications and filters, or right click to Select All, then right-click to Delete Selected.
Step 8 Click Store ASA FirePOWER Changes.
The application filter is saved.
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 ASA FirePOWER module 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 ASA FirePOWER module 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 as described in Optimizing Predefined
Default Variables, page 2-14. 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.
See the following sections for more information:
• Optimizing Predefined Default Variables, page 2-14
• Understanding Variable Sets, page 2-16
• Managing Variable Sets, page 2-18
• Managing Variables, page 2-19
• Adding and Editing Variables, page 2-20
• Resetting Variables, page 2-26
• Linking Variable Sets to Intrusion Policies, page 2-27
• Understanding Advanced Variables, page 2-27
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. For more
information, see Importing Configurations, page B-3.
The following table describes the variables provided by the ASA FirePOWER module and indicates
which variables you typically would modify. For assistance determining how to tailor variables to your
network, contact Professional Services or Support.
Optionally, 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 the system 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.
After you configure variable sets, you can link them to intrusion policies.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Variable Set.
Step 3 Add a variable set or edit an existing set:
• To add a variable set, click Add Variable Set.
• To edit a variable set, click the edit icon ( ) next to the variable set.
The new or edit variable set page appears. See Adding and Editing Variables, page 2-20 for information
on adding and editing variables within a variable set.
Managing Variables
License: Protection
You manage variables on the new or edit variables page within a variable set. The variables page for all
variable sets separates variables into Customized Variables and Default Variables page areas.
A default variable is a variable provided by the ASA FirePOWER module. You can customize the value
of a default variable. You cannot rename or delete a default variable, and you cannot change its default
value.
A customized variable is one of the following:
• 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.
The following table summarizes the actions you can take to create or edit variables.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Variable Set.
Step 3 Add a variable set or edit an existing set:
• To add a variable set, click Add Variable Set.
• To edit a variable set, click the edit icon ( ) next to the variable set.
The new or edit variable set page appears.
Step 4 Add a variable or edit an existing variable:
• To add a variable, click Add.
• To edit a variable, click the edit icon ( ) next to the variable.
The new or edit variable page appears.
See Adding and Editing Variables, page 2-20 for information on adding and editing variables within a
variable set.
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. For example, 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.
Adding a variable to a variable set adds it to all other sets. With one exception as explained below, the
variable is added to other sets as the default value, which you can then customize.
When you add a variable from a custom set, you must choose whether to use the configured value as the
customized value in the default set.
• If you do use the configured value (for example, 192.168.0.0/16), the variable is added to the default
set using the configured value as a customized value with a default value of any. Because the current
value in the default set determines the default value in other sets, the initial, default value in other
custom sets is the configured value (which in the example is 192.168.0.0/16).
• If you do not use the configured value, the variable is added to the default set using only the default
value any and, consequently, the initial, default value in other custom sets is any.
See Understanding Variable Sets, page 2-16 for more information.
You add variables within a variable set on the New Variable page and edit existing variables on the Edit
Variable page. You use the two pages identically except that when you edit an existing variable you
cannot change the variable name or variable type.
Each page consists mainly of three windows:
• available items, including existing network or port variables, objects, and network object groups
• networks or ports to include in the variable definition
• networks or ports to exclude from the variable definition
You can create or edit two types of variables:
• network variables specify the IP addresses of hosts in your network traffic. See Working with
Network Variables, page 2-24.
• port variables specify TCP or UDP ports in network traffic, including the value any for either type.
See Working with Port Variables, page 2-25.
When you specify whether you want to add a network or port variable type, the page refreshes to list
available items. A search field above the list allows you to constrain the list, which updates as you type.
You can select and drag available items the list of items to include or exclude. You can also select items
and click the Include or Exclude button. Use the Ctrl and Shift keys to select multiple items. You can use
the configuration field below the list of included or excluded items to specify literal IP addresses and
address blocks for network variables, and ports and port ranges for port variables.
A 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.
The following table summarizes the actions you can take to create or edit your variables.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Variable Set.
Step 3 Add a variable set or edit an existing set:
• To add a variable set, click Add Variable Set.
• To edit an existing variable set, click the edit icon ( ) next to the variable set.
The new or edit variable set page appears.
Step 4 Add a new variable or edit an existing variable:
• To add a new variable, click Add.
• To edit an existing variable, click the edit icon ( ) next to the variable.
The new or edit variable page appears.
Step 5 If you are adding a new variable:
• Enter a unique variable Name.
You can use alphanumeric characters and the underscore (_) character.
• Select the Network or Port variable Type from the drop-down list.
Step 6 Optionally, move items from the list of available networks or ports to the list of included or excluded
items.
You can select one or more items and then drag and drop, or click Include or Exclude. Use the Ctrl and
Shift keys to select multiple items.
Tip If addresses or ports in the included and excluded lists for a network or port variable overlap, excluded
addresses or ports take precedence.
Your changes are saved and any access control policy the variable set is linked to displays an out-of-date
status. For your changes to take effect, you must apply the access control policy where the variable set
is linked to an intrusion policy; see Deploying Configuration Changes, page 4-12.
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. An error message warns you and
identifies the offending variable, and you cannot save your variable set when you exclude a value
outside the range of included values.
For information on adding and editing network variables, see Adding and Editing Variables, page 2-20.
• 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.
Note the following points when adding or editing port variables:
• The default value for included ports in any variable you add is the word any, which indicates any
port or port range. The default value for excluded ports is none, which indicates no ports.
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. An error message warns you and identifies the offending
variable, and you cannot save your variable set when you exclude a value outside the range of
included values.
For information on adding and editing port variables, see Adding and Editing Variables, page 2-20.
Resetting Variables
License: Protection
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.
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
USER_CONF
USER_CONF provides a general tool that allows you to configure one or more features not
otherwise available via the module 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Choose Sinkhole from the list of object types.
Step 3 Click Add Sinkhole.
Step 4 Enter a Name.
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, select Log Connections to Sinkhole.
• If you want to redirect traffic to a non-resolving IP address, select 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 Store ASA FirePOWER Changes.
Step 9 Reapply all access control policies with DNS policies that use the sinkhole object.
If you use network-based advanced malware protection (AMP), and the Collective Security Intelligence
Cloud incorrectly identifies a file’s disposition, you can add the file to a file list using a SHA-256 hash
value to better detect the file in the future. Depending on the type of file list, you can do the following:
• To treat a file as if the cloud assigned a clean disposition, add the file to the clean list.
• To treat a file as if the cloud assigned a malware disposition, add the file to the custom detection list.
Because you manually specify the blocking behavior for these files, the system does not perform
malware cloud lookups, even if the files are otherwise identified as malware by the cloud. Note that 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. For more information, see Working with File Rules,
page 32-9.
The system’s clean list and custom detection list are included by default in every file policy. You can opt
not to use either or both lists on a per-policy basis.
Caution Do not include files on this list that are actually malware. The system does not block them, even if the
cloud assigned the file’s a Malware disposition, or if you added the file to the custom detection list.
Each file list can contain up to 10000 unique SHA-256 values. To add files to the file list, you can:
• upload a file so the system calculates and adds the file’s SHA-256 value.
• enter a file’s SHA-256 value directly.
• create and upload a comma-separated value (CSV) source file containing multiple SHA-256 values.
All non-duplicate SHA-256 values are added to the file list.
When you add a file to a file list, edit a SHA-256 value in the file list, or delete SHA-256 values from
the file list, you must reapply any access control policies with file policies that use the list for the changes
to take effect.
For more information on using file lists, see the following topics:
• Uploading Multiple SHA-256 Values to a File List, page 2-29
• Uploading an Individual File to a File List, page 2-30
• Adding a SHA-256 Value to the File List, page 2-31
• Modifying Files on a File List, page 2-32
• Downloading a Source File from a File List, page 2-32
• 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.
• 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.
See Downloading a Source File from a File List, page 2-32 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Click File List.
The File List section appears.
Step 3 Click the edit icon ( ) next to the file list where you want to add values from a source file.
The File List pop-up window appears.
Step 4 Select List of SHAs from the Add by field.
The pop-up window updates to include new fields.
Step 5 Optionally, enter a description of the source file in the Description field.
If you do not enter a description, the system uses the file name.
Step 6 Click Browse to browse to the source file, then click Upload and Add List to add the list.
The source file is added to the file list. The SHA-256 column lists how many SHA-256 values the file
contains.
Step 7 Click Store ASA FirePOWER Changes.
Step 8 Reapply all access control policies with file policies that use the file list.
After the policies apply, the system no longer performs malware cloud lookups on files in the file list.
If you have a copy of the file you want to add to a file list, you can upload the file to the system 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.
Step 1 On the object manager’s File List page, click the edit icon ( ) next to the clean list or custom detection
list where you want to add a file.
The File List pop-up window appears.
Step 2 Select Calculate SHA from the Add by field.
The pop-up window updates to include new fields.
Step 3 Optionally, enter a description of the file in the Description field.
If you do not enter a description, the file name is used for the description on upload.
Step 4 Click Browse to browse to the source file, then click Calculate and Add SHA to add the list.
The file is added to the file list.
Step 5 Click Store ASA FirePOWER Changes.
Step 6 Reapply all access control policies with file policies that use the file list.
After the policies apply, the system no longer performs malware cloud lookups on files in the file list.
Step 1 On the object manager’s File List page, click the edit icon ( ) next to the clean list or custom detection
list where you want to add a file.
The File List pop-up window appears.
Step 2 Select Enter SHA Value from the Add by field.
The pop-up window updates to include new fields.
Step 3 Enter a description of the source file in the Description field.
Step 4 Type or paste the file’s entire SHA-256 value. The system does not support matching partial values.
Step 5 Click Add to add the file.
The file is added to the file list.
Step 6 Click Store ASA FirePOWER Changes.
Step 7 Reapply all access control policies with file policies that use the file list.
After the policies apply, the system no longer performs malware cloud lookups on files in the file list.
Step 1 On the object manager’s File List page, click the edit icon ( ) next to the clean list or custom detection
list where you want to modify a file.
The File List pop-up window appears.
Step 2 Next to the SHA-256 value you want to edit, click the edit icon ( ).
The Edit SHA-256 pop-up window appears.
Tip You can also delete files from the list. Next to the file you want to remove, click the delete icon ( ).
Step 1 On the object manager’s File List page, click the edit icon ( ) next to the clean list or custom detection
list where you want to download a source file.
The File List pop-up window appears.
Step 2 Next to the source file you want to download, click the view icon ( ).
The View SHA-256’s in list pop-up window appears.
Step 3 Click Download SHA List and follow the prompts to save the source file.
Step 4 Click Close.
The File List pop-up window appears.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Security Zones.
Step 3 Click Add Security Zone.
The Security Zones pop-up window appears.
Step 4 Type a Name for the zone. You can use any printable standard ASCII characters except curly braces ({})
and pound signs (#).
Step 5 Select an interface Type for the zone.
After you create a security zone, you cannot change its type.
Step 6 Select one or more interfaces.
Use the Shift and Ctrl keys to select multiple objects. If you have not yet configured interfaces, you can
create an empty zone and add interfaces to it later; skip to step 9.
Step 7 Click Add.
The interfaces you selected are added to the zone, grouped by device.
Step 8 Repeat steps 6 through 8 to add interfaces on other devices to the zone.
Step 9 Click Store ASA FirePOWER Changes.
Note Although you can use cipher suites in the ASDM interface in the same places as cipher suite lists, you
cannot add, modify, or delete cipher suites.
You cannot delete a cipher suite list that is in use. Additionally, after you edit a cipher suite list used in
an SSL policy, you must reapply the associated access control policy for your changes to take effect.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Cipher Suite List.
Step 3 Click Add Cipher Suites.
The Cipher Suite List pop-up window appears.
Step 4 Type a Name for the cipher suite list. You can use any printable standard ASCII characters except a pipe
(|) or curly braces ({}).
Step 5 Select one or more cipher suites and click Add.
• Use Shift and Ctrl to select multiple cipher suites, or right-click and Select All.
• Use the filter field ( ) to search for existing cipher suites to include, which updates as you type to
display matching items. Click the reload icon ( ) above the search field or click the clear icon ( )
in the search field to clear the search string.
Step 6 Click Store ASA FirePOWER Changes.
The cipher suite list is created.
Each distinguished name object represents the distinguished name listed for a public key certificate’s
subject or issuer. You can use distinguished name objects and groups (see Grouping Objects, page 2-2)
in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL
session using a server certificate with the distinguished name as subject or issuer.
Your distinguished name object can contain the common name attribute (CN). If you add a common name
without “CN=” then the system prepends “CN=” before saving the object.
You can also add a distinguished name with one of each attribute listed in the following table, separated
by commas.
OU Organizational Unit
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.
You cannot delete a distinguished name object that is in use. Additionally, after you edit a distinguished
name object used in an SSL policy, you must reapply the associated access control policy for your
changes to take effect.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under Distinguished Name, select Individual Objects.
Step 3 Click Add Distinguished Name.
The Distinguished Name pop-up window appears.
Step 4 Type a Name for the distinguished name object. You can use any printable standard ASCII characters
except a pipe (|) or curly braces ({}).
Step 5 In the DN field, type 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 Table 2-7 on
page 2-35 separated by commas.
• If you add a common name, you can include multiple labels and wild cards.
Step 6 Click Store ASA FirePOWER Changes.
The distinguished name object is added.
Note The ASA FirePOWER module encrypts 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.
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. For more information, see Decrypt Actions: Decrypting Traffic for
Further Inspection, page 13-9.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Internal CAs.
Step 3 Click Import CA.
The Import Internal Certificate Authority pop-up window appears.
Step 4 Type a Name for the internal CA object. You can use any printable standard ASCII characters except a
pipe (|) or curly braces ({}).
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, select the Encrypted, and the password is: check box and enter
the password.
Step 8 Click Store ASA FirePOWER Changes.
The internal CA object is added.
The generated CA certificate is valid for ten years. The Valid From date is a week before generation.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Internal CAs.
Step 3 Click Generate CA.
The Generate Internal Certificate Authority pop-up window appears.
Step 4 Type a Name for the internal CA object. You can use any printable standard ASCII characters except a
pipe (|) or curly braces ({}).
Step 5 Type the identification attributes, as described in Table 2-9 on page 2-39.
Step 6 Click Generate self-signed CA.
The internal CA object is added.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Internal CAs.
Step 3 Click the edit icon ( ) next to the CA object containing the unsigned certificate awaiting the CSR.
The Edit Internal Certificate Authority pop-up window appears.
Step 4 Click Install Certificate.
The Install Internal Certificate Authority pop-up window appears.
Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate
file.
Step 6 If the uploaded file is password protected, select the Encrypted, and the password is: check box and enter
the password.
Step 7 Click Store ASA FirePOWER Changes.
The CA object contains a signed certificate, and can be referenced in SSL rules.
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. For more information, see Creating Backup Files, page 45-1.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Internal CAs.
Step 3 Click the edit icon ( ) next to the internal CA object whose certificate and private key you want to
download.
The Edit Internal Certificate Authority pop-up window appears.
Step 4 Click Download.
The Encrypt Download File pop-up window appears.
Step 5 Type an encryption password in the Password and Confirm Password fields.
Step 6 Click Store ASA FirePOWER Changes.
You are prompted to save the file.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Trusted CAs.
Step 3 Click Add Trusted CAs.
The Import Trusted Certificate Authority pop-up window appears.
Step 4 Type a Name for the trusted CA object. You can use any printable standard ASCII characters except a
pipe (|) or curly braces ({}).
Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate
file.
Step 6 If the file is password-protected, select the Encrypted, and the password is: check box and enter the
password.
Step 7 Click Store ASA FirePOWER Changes.
The trusted CA object is added.
To upload a CRL:
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Trusted CAs.
Step 3 Click the edit icon ( ) next to a trusted CA object.
The Edit Trusted Certificate Authority pop-up window appears.
Step 4 Click Add CRL to upload a DER or PEM-encoded CRL file.
Step 5 Click Store ASA FirePOWER Changes.
Your changes are saved.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select External Certs.
Step 3 Click Add External Cert.
The Add Known External Certificate pop-up window appears.
Step 4 Type a Name for the external certificate object. You can use any printable standard ASCII characters
except a pipe (|) or curly braces ({}).
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 Store ASA FirePOWER Changes.
The internal CA object is added.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Under PKI, select Internal Certs.
Step 3 Click Add Internal Cert.
The Add Known Internal Certificate pop-up window appears.
Step 4 Type a Name for the internal certificate object. You can use any printable standard ASCII characters
except a pipe (|) or curly braces ({}).
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, select the Encrypted, and the password is: check box
and enter the password.
Step 8 Click Store ASA FirePOWER Changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Object Management.
The Object Management page appears.
Step 2 Select Geolocation.
The Geolocation Objects page appears.
Step 3 Click Add Geolocation.
The Geolocation Object pop-up window appears.
Step 4 Type a Name for the geolocation object. You can use any printable standard ASCII characters except
curly braces ({}).
Step 5 Select the check boxes for the countries and continents you want to include in your geolocation object.
Selecting a continent selects all countries within that continent, as well as any countries that GeoDB
updates may add under that continent in the future. Deselecting any country under a continent deselects
the continent. You can select any combination of countries and continents.
Step 6 Click Store ASA FirePOWER Changes.
The geolocation object is added.
The Device Management page allows you to manage the device and interface configurations for the
ASA FirePOWER module.
Caution If you configure the ASA in a failover pair, the ASA FirePOWER configuration does not automatically
synchronize with the ASA FirePOWER module on the secondary device. You must manually export the
ASA FirePOWER configuration from the primary and import it into the secondary every time you make
a change. Upon failover, the module also loses all configuration on the device that failed over.
Step 1 Select Configuration > ASA FirePOWER Configuration > Device Management > Device.
The Device page appears.
Step 2 Next to the General section, click the edit icon ( ).
The General pop-up window appears.
Step 3 In the Name field, type a new assigned name for the module. You may enter alphanumeric characters and
special characters, with the exception of the following characters, which are invalid: +, (, ), {, }, #, &, \,
<, >, ?, ‘, and “.
Step 4 Select the Transfer Packets check box to allow packet data to be stored in the ASA FirePOWER module
with events. Clear the check box to prevent the device from sending packet data with the events.
Step 5 Click Save.
The changes are saved. Note that your changes do not take effect until you apply the device
configuration; see Applying Changes to Device Configuration, page 3-4 for more information.
Field Description
Model The model name and number for the device.
Serial The serial number of the chassis of the device.
Time The current system time of the device.
Version The version of the software currently installed on the ASA FirePOWER
module.
Policy A link to the system policy currently applied to the ASA FirePOWER
module.
Field Description
Application Bypass The state of Automatic Application Bypass on the module.
Bypass Threshold The Automatic Application Bypass threshold, in
milliseconds.
You can use the Advanced section to edit any of these settings. See the following sections for more
information:
• Automatic Application Bypass, page 3-3
• Editing Advanced Device Settings, page 3-3
Note AAB is activated only when an excessive amount of time is spent processing a single packet. If AAB
engages, the system kills all Snort processes.
For more information about enabling Automatic Application Bypass and setting the bypass threshold,
see Editing Advanced Device Settings, page 3-3.
Step 1 Select Configuration > ASA FirePOWER Configuration > Device Management > Device.
The Device page appears.
Step 2 Next to the Advanced section, click the edit icon ( ).
The Advanced pop-up window appears.
Step 3 Optionally, select Automatic Application Bypass if your network is sensitive to latency. Automatic
Application Bypass is most useful in inline deployments. For more information, see Automatic
Application Bypass, page 3-3.
Step 4 When you select the Automatic Application Bypass option, you can type a Bypass Threshold in
milliseconds (ms). The default setting is 3000 ms and the valid range is from 250 ms to 60,000 ms.
Step 5 Click Save.
Your changes are saved. Note that your changes do not take effect until you apply the device
configuration; see Applying Changes to Device Configuration, page 3-4 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Device Management > Interfaces.
The Interfaces page appears.
Step 2 Next to the interface you want to edit, click the edit icon ( ).
The Edit Interface pop-up window appears.
Step 3 From the Security Zone drop-down list, select an existing security zone or select New to add a new security
zone.
Step 4 Click Store ASA FirePOWER Changes.
The security zone is configured. Note that your changes do not take effect until you apply the device
configuration; see Applying Changes to Device Configuration, page 3-4 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Device Management > Device or Configuration > ASA
FirePOWER Configuration > Device Management > Interfaces.
The Device Management page appears.
Tip Optionally, from the Apply Device Changes dialog box, click View Changes. The Device Management
Revision Comparison Report page appears in a new window. For more information, see Using the Device
Management Revision Comparison Report, page 3-5.
Step 1 Select Configuration > ASA FirePOWER Configuration > Device Management > Device or Configuration > ASA
FirePOWER Configuration > Device Management > Interfaces.
The Device Management page appears.
Step 2 Click Apply Changes.
The Apply Device Changes pop-up window appears. Note that the appliance must have unapplied
changes or the Apply Changes button remains disabled.
Step 3 Click View Changes.
The Device Management Revision Comparison Report page appears in a new window.
Step 4 Click Previous and Next to scroll through the differences between the current appliance configuration and
the proposed appliance configuration.
Step 5 Optionally, click Comparison Report to produce a PDF version of the report.
You must configure remote management on the appliance that will be managed, that is, on the device
that you want to manage with a Defense Center. After you configure remote management, you can use
the managing appliance’s web interface to add the managed appliance to your deployment.
Note After you establish remote management and register the Cisco ASA with FirePOWER Services to a
Defense Center, you must manage the ASA FirePOWER module from the Defense Center instead of
ASDM.
To enable communications between two appliances, you must provide a way for the appliances to
recognize each other. There are three criteria the FireSIGHT 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 FireSIGHT System establish
communications in a NAT environment
The NAT ID must be unique among all NAT IDs used to register managed appliances.
When you register a managed device to a Defense Center, the access control policy you select applies to
the device. However, if you do not enable licenses for the device required by features used in the access
control policy you select, the access control policy apply fails.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration > Registration.
The Remote Management page appears.
Step 2 Click Add Manager.
The Add Remote Management page appears.
Step 3 In the Management Host field, type the IP address or the hostname of the appliance that you want to use
to manage this appliance.
The hostname is the fully qualified domain name or the name that resolves through the local DNS to a
valid IP address.
In a NAT environment, you do not need to specify an IP address or hostname here if you plan to specify
it when you add the managed appliance. In this case, the FireSIGHT System uses the NAT ID you will
provide later to identify the remote manager on the managed ASA FirePOWER module interface.
Caution Use a hostname rather than an IP address if your network uses DHCP to assign IP addresses.
Step 4 In the Registration Key field, type the registration key that you want to use to set up communications
between appliances.
Step 5 For NAT environments, in the Unique NAT ID field, type a unique alphanumeric NAT ID that you want to
use to set up communications between appliances.
Note When enabling remote management of a device, in some high availability deployments that use
NAT, you may also need to add the secondary Defense Center as a manager. For more
information, contact Support.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration > Registration.
The Remote Management page appears.
Step 2 Click the edit icon ( ) next to the manager for which you want to edit remote management settings.
The Edit Remote Management page appears.
Step 3 In the Name field, change the display name of the managing appliance.
Step 4 In the Host field, change the IP address or the hostname of the managing appliance.
The hostname is the fully qualified domain name or the name that resolves through the local DNS to a
valid IP address.
Step 5 Click Save.
Your changes are saved.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration > Registration.
The Registration page appears.
Step 2 Select the eStreamer tab.
The eStreamer page appears.
Step 3 Under eStreamer Event Configuration, select the check boxes next to the types of events you want
eStreamer to forward to requesting clients.
You can select any or all of the following on a managed device or Defense Center:
• Intrusion Events to transmit intrusion events.
• Intrusion Event Packet Data to transmit packets associated with intrusion events.
• Intrusion Event Extra Data to transmit additional data associated with an intrusion event such as the
originating IP addresses of a client connecting to a web server through an HTTP proxy or load
balancer.
Note Note that this controls which events the eStreamer server can transmit. Your client must still
specifically request the types of events you want it to receive in the request message it sends to
the eStreamer server. For more information, see the FireSIGHT System eStreamer Integration
Guide.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration > Registration.
The Registration page appears.
Step 2 Select the eStreamer tab.
Note If you use a host name, the eStreamer server must be able to resolve the host to an IP address.
If you have not configured DNS resolution, you should configure it first or use an IP address.
Step 5 If you want to encrypt the certificate file, enter a password in the Password field.
Step 6 Click Save.
The eStreamer server now allows the host to access port 8302 on the eStreamer server and creates an
authentication certificate to use during client-server authentication. The eStreamer page reappears, with
the new client listed under Hostname.
Step 7 Click the download icon ( ) next to the client hostname to download the certificate file.
Step 8 Save the certificate file to the appropriate directory used by your client for SSL authentication.
The client can now connect to the eStreamer server. You do not need to restart the eStreamer service.
Tip To revoke access for a client, click the delete icon ( ) next to the host you want to remove. Note that
you do not need to restart the eStreamer service; access is revoked immediately.
An access control policy determines how the system handles traffic on your network. Each ASA
FirePOWER module can have one currently applied policy.
The simplest access control policy handles all traffic using its default action. You can set this default
action to block or trust all traffic without further inspection, or to inspect traffic for intrusions.
Note that only ASA FirePOWER modules deployed inline can affect the flow of traffic. Applying an
access control policy configured to block or alter traffic to passively deployed devices can have
unexpected results. In some cases, the system prevents you from applying inline configurations to
passively deployed ASA FirePOWER modules.
This chapter explains how to create and apply a simple access control policy. It also contains basic
information on managing access control policies: editing, updating, comparing, and so on. For more
information, see:
• Access Control License and Role Requirements, page 4-2
• Creating a Basic Access Control Policy, page 4-3
• Managing Access Control Policies, page 4-6
• Editing Access Control Policies, page 4-7
• Understanding Out-of-Date Policy Warnings, page 4-9
• Deploying Configuration Changes, page 4-10
• ASA FirePOWER module Applying includesASA FirePOWER module a orYou might be able to
select as few as three intrusion policies across an entire access control policy. Configuration > ASA
FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring >
Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11
• Generating a Report of Current Access Control Settings, page 4-15
Tip When you first create an access control policy, you cannot choose to trust traffic as the default action. If
you want to trust all traffic by default, change the default action after you create the policy.
Use the Access Control Policy page (Policies > Access Control) to create new and manage existing access
control policies.
Optionally, you can use and modify the initial system-provided policy named Default Trust All Traffic.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Tip You can also copy an existing policy from this ASA FirePOWER module or import a policy from another
ASA FirePOWER module. To copy a policy, click the copy icon ( ). To import a policy, see Importing
and Exporting Configurations, page B-1.
The following table describes how the different default actions handle traffic, and lists the types of
inspection you can perform on traffic handled by each default action. Note that you cannot perform file
or malware inspection on traffic handled by the default action. For more information, see Controlling
Traffic Using Intrusion and File Policies, page 10-1.
:
Table 4-2 Access Control Policy Default Actions
The diagram below illustrates the Block All Traffic and Trust All Traffic default actions.
When you first create an access control policy, logging connections that are handled by the default action
is disabled by default. If you select a default action that performs intrusion inspection, the system
automatically associates the default intrusion variable set with the intrusion policy you select. You can
change either of these options, as well as the default action itself, after you create the policy.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
Step 4 If you selected an Intrusion Prevention default action, click the variables icon ( ) to change the variable
set associated with the intrusion policy you selected.
In the pop-up window that appears, select a new variable set and click OK. You can also edit the selected
variable set in a new window by clicking the edit icon ( ). If you do not change the variable set, the
system uses a default set. For more information, see Working with Variable Sets, page 2-13.
Step 5 Click the logging icon ( ) to change logging options for connections handled by the default action.
You can log a matching connection at its beginning and end. Note that the system cannot log the end of
blocked traffic. You can log connections to the ASA FirePOWER module event viewer, external system
log (syslog) or SNMP trap server. For more information, see Logging Connections Handled by the
Access Control Default Action, page 33-11.
Use the access control policy editor to add and organize rules, and so on. The following list provides
information on the policy configurations you can change.
Security Intelligence
Security Intelligence is a first line of defense against malicious Internet content. This feature allows
you to immediately blacklist (block) connections based on the latest reputation intelligence. To
ensure continual access to vital resources, you can override blacklists with custom whitelists. This
traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling,
including rules and the default action. For more information, see Blacklisting Using Security
Intelligence IP Address Reputation, page 5-1.
Rules
Rules provide a granular method of handling network traffic. Rules in an access control policy are
numbered, starting at 1. The system matches traffic to access control rules in top-down order by
ascending rule number.
In most cases, the system handles network traffic according to the first access control rule where all
the rule’s conditions match the traffic. These conditions include security zone, network or
geographical location, port, application, requested URL, or user. Conditions can be simple or
complex; their use often depends on certain licenses.
Use the Rules tab to add, categorize, enable, disable, filter, and otherwise manage rules. For more
information, see Tuning Traffic Flow Using Access Control Rules, page 6-1.
Default Action
The default action determines how the system handles traffic that is not blacklisted by Security
Intelligence and does not match any access control rules. Using the default action, you can block or
trust all traffic without further inspection, or inspect traffic for intrusions. You can also enable or
disable logging of connections handled by the default action.
For more information, see Setting Default Handling and Inspection for Network Traffic, page 4-4
and Logging Connections Based on Access Control Handling, page 33-9.
HTTP Responses
You can specify what the user sees in a browser when the system blocks that user’s website
request—either display a generic system-provided response page, or enter custom HTML. You can
also display a page that warns users, but also allows them to click a button to continue or refresh the
page to load the originally requested site. For more information, see Displaying a Custom Web Page
for Blocked URLs, page 8-14.
– adaptive profiles to improve reassembly of packet fragments and TCP streams in passive
deployments, based on your network’s host operating systems; see Tuning Preprocessing in
Passive Deployments, page 22-1
– performance options for intrusion inspection, file control, file storage, and advanced malware
protection; see Tuning Intrusion Prevention Performance, page 10-6 and Tuning File and
Malware Inspection Performance and Storage, page 10-16
When you edit an access control policy, a message indicates that you have unsaved changes. To retain
your changes, you must save the policy before exiting the policy editor. If you attempt to exit the policy
editor without saving your changes, you are cautioned that you have unsaved changes; you can then
discard your changes and exit the policy, or return to the policy editor.
To protect the privacy of your session, after sixty minutes of inactivity on the policy editor, changes to
your policy are discarded and you are returned to the Access Control Policy page. After the first thirty
minutes of inactivity, a message appears and updates periodically to provide the number of minutes
remaining before changes are discarded. Any activity on the page cancels the timer.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Edit your policy. Take any of the actions summarized above.
Step 4 Save or discard your configuration:
• To save your changes and continue editing, click Store ASA FirePOWER Changes.
• To save your changes and apply your policy, click Apply ASA FirePOWER Changes. See Deploying
Configuration Changes, page 4-10.
• To discard your changes, click Cancel and, if prompted, click OK.
• Changing any reusable object or configuration used in the access control policy or the policies it
invokes: network, port, URL, and geolocation objects; Security Intelligence lists and feeds;
application filters or detectors; intrusion policy variable sets; file lists; security zones, and so on.
• 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 ASA
FirePOWER module interface. For example, you can modify security zones using the object manager
(Configuration > ASA FirePOWER Configuration > Object Management).
Note that the following updates do not require policy reapply:
• automatic updates to URL filtering data
• scheduled geolocation database (GeoDB) updates
To determine why an access control or intrusion policy is out of date, use the comparison viewer.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears. Policies that are out of date are marked with red status text that
indicates that the ASA FirePOWER module needs a policy update.
Step 2 Click the policy status for an out-of-date policy.
The detailed Apply Access Control Policy pop-up window appears.
Step 3 Click Out-of-date next to the changed component you are interested in.
A policy comparison report appears in a new window. For more information, see Comparing Access
Control Policies, page 4-16 and Comparing Two Intrusion Policies or Revisions, page 23-9.
Step 4 Optionally, reapply the policy.
See Deploying Configuration Changes.
Caution In special cases, deploying configuration changes may cause a short pause in traffic flow and processing,
and may also cause a few packets to pass uninspected. To minimize inconvenience, deploy during a
change window.
ASA FirePOWER module Applying includesASA FirePOWER module a orYou might be able to select as few as three
intrusion policies across an entire access control policy. Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
Changes (Monitoring > ASA FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA
FirePOWER ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Tip In the access control policy editor, click Show Warnings to display a pop-up window that lists all the
warnings for the policy.
Additionally, the system warns you at apply-time of any issues that could affect traffic analysis and flow.
Properly configuring access control policies and rules can also reduce the resources required to process
network traffic. Creating complex rules, invoking many different intrusion policies, and mis-ordering
rules can all affect performance.
For more information, see:
• Simplifying Rules to Improve Performance, page 4-12
• Understanding Rule Preemption and Invalid Configuration Warnings, page 4-13
• Ordering Rules to Improve Performance and Avoid Preemption, page 4-14
Note that combining elements into objects that you then use in access control rule conditions does
not improve performance. For example, using a network object that contains 50 individual IP
addresses gives you only an organizational—not a performance—benefit over including those IP
addresses in the condition individually.
• Restrict rules by security zones whenever possible. If a device’s interfaces are not in one of the zones
in a zone-restricted rule, the rule does not affect performance on that device.
• Do not overconfigure rules. If one condition is enough to match the traffic you want to handle, do
not use two.
• If you add a port group to the source ports in a rule, then change the port group to include an ICMP
port, the rule becomes invalid and a warning icon appears next to it. You can still apply the policy,
but the rule will have no effect on network traffic.
• If you add a user to a rule, then change your LDAP user awareness settings to exclude that user, the
rule will have no effect because the user is no longer an access controlled user.
• Allow and Interactive Block rules that optionally inspect traffic for malware, intrusions, or both
Section Description
Policy Information Provides the name and description of the policy, the name of the user who
last modified the policy, and the date and time the policy was last modified.
HTTP Block Response Provides details on the pages you display to users when you block a website
HTTP Interactive Block using the policy.
Response
Security Intelligence Provides details on the policy’s Security Intelligence whitelist and blacklist.
Default Action Lists the default action and associated variable set, if any.
Rules Lists each access control rule in the policy, and provides details about its
configuration.
Advanced Settings Detailed information on the policy’s advanced settings, including:
• network analysis policies used to preprocess traffic for the access
control policy, as well as global preprocessing options
• adaptive profile settings for passive deployments
• performance settings for detecting files, malware, and intrusions
• other policy-wide settings
Referenced Objects Provides details on the reusable objects referenced by the access control
policy, including intrusion policy variable sets.
You can also generate an access control comparison report that compares a policy with the currently
applied policy or with another policy. For more information, see Comparing Access Control Policies,
page 4-16.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the report icon ( ) next to the policy for which you want to generate a report. Remember to save
any changes before you generate an access control policy report; only saved changes appear in the report.
The system generates the report. You are prompted to save the report to your computer.
Tip You can use a similar procedure to compare network analysis, intrusion, file, or system policies.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click Compare Policies.
The Select Comparison window appears.
Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:
• To compare two different policies, select Other Policy.
The page refreshes and the Policy A and Policy B drop-down lists appear.
• To compare another policy to the currently active policy, select Running Configuration.
The page refreshes and the Target/Running Configuration A and Policy B drop-down lists appear.
Step 4 Depending on the comparison type you selected, you have the following choices:
• If you are comparing two different policies, select 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, select the second policy from the
Policy B drop-down list.
Step 5 Click OK to display the policy comparison view.
The comparison view appears.
Step 6 Optionally, click Comparison Report to generate the access control policy comparison report.
The access control policy comparison report appears. You are prompted to save the report to your
computer.
As a first line of defense against malicious Internet content, the ASA FirePOWER module includes the
Security Intelligence feature, which allows you to immediately blacklist (block) connections based on
the latest reputation intelligence, removing the need for a more resource-intensive, in-depth analysis.
Security Intelligence filtering requires a Protection license.
Security Intelligence works by blocking traffic to or from IP addresses that have a known bad reputation.
This traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling.
Note that you could create access control rules that perform a similar function to Security Intelligence
filtering by manually restricting traffic by IP address. However, access control rules are wider in scope,
more complex to configure, and cannot automatically update using dynamic feeds.
Traffic blacklisted by Security Intelligence is immediately blocked and therefore is not subject to any
further inspection—not for intrusions, exploits, malware, and so on. Optionally, and recommended in
passive deployments, you can use a “monitor-only” setting for Security Intelligence filtering. This
allows the system to analyze connections that would have been blacklisted, but also logs the match to
the blacklist and generates an end-of-connection security intelligence event.
For your convenience, Cisco provides the Intelligence Feed (sometimes called the Sourcefire
Intelligence Feed), which is comprised of several regularly updated collections of IP addresses
determined by the VRT to have a poor reputation. The Intelligence Feed tracks open relays, known
attackers, bogus IP addresses (bogon), and so on. You can also customize the feature to suit the unique
needs of your organization, for example:
• third-party feeds—you can supplement the Intelligence Feed with third-party reputation feeds,
which the system can automatically update just as it does the Cisco feed
• custom blacklists—the system allows you to manually blacklist specific IP addresses in many ways
depending on your needs
• enforcing blacklisting by security zone—to improve performance, you may want to target
enforcement, for example, restricting spam blacklisting to a zone that handles email traffic
• monitoring instead of blacklisting—especially useful in passive deployments and for testing feeds
before you implement them; you can merely monitor the violating sessions instead of blocking
them, generating end-of-connection events
• whitelisting to eliminate false positives—when a blacklist is too broad in scope, or incorrectly
blocks traffic that you want to allow (for example, to vital resources), you can override a blacklist
with a custom whitelist
For detailed information on configuring your access control policy to perform Security Intelligence to
perform Security Intelligence filtering and viewing the event data that this filtering produces, see the
following sections:
• Choosing a Security Intelligence Strategy, page 5-2
• Building the Security Intelligence Whitelist and Blacklist, page 5-3
• Logging Security Intelligence (Blacklisting) Decisions, page 33-8
Note Although feed updates and additions to the global blacklist (or global whitelist; see below) automatically
implement changes throughout your deployment, any other change to a Security Intelligence object
requires you to reapply the access control policy. For more information, see Table 2-1 on page 2-5.
For example, 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.
Note You cannot apply an access control policy that uses a populated global whitelist or blacklist to a device
not licensed for Protection. If you added IP addresses to either global list, you must remove the
non-empty list from the policy’s Security Intelligence configuration before you can apply the policy. For
more information, see Working with the Global Whitelist and Blacklist, page 2-6.
After you build your whitelist and blacklist, you can log blacklisted connections. You can also set
individual blacklisted objects, including feeds and lists, to monitor-only. This allows the system to
handle connections involving blacklisted IP addresses using access control, but also logs the
connection’s match to the blacklist.
Use the Security Intelligence tab in the access control policy to configure the whitelist, blacklist, and
logging options. The page lists the Available Objects you can use in either the whitelist or blacklist, as
well as the Available Zones you can use to constrain whitelisted and blacklisted objects. Each type of
object or zone is distinguished with an different icon. The objects marked with the Cisco icon ( )
represent the different categories in the Intelligence Feed.
In the blacklist, objects set to block are marked with the block icon ( ) while monitor-only objects are
marked with the monitor icon ( ). Because the whitelist overrides the blacklist, if you add the same
object to both lists, the system displays the blacklisted object with a strikethrough.
You can add up to a total of 255 objects to the whitelist and the blacklist. That is, the number of objects
in the whitelist plus the number in the blacklist cannot exceed 255.
Note that although you can add network objects with a netmask of /0 to the whitelist or blacklist, address
blocks using a /0 netmask in those objects will be ignored and whitelist and blacklist filtering will not
occur based on those addresses. Address blocks with a /0 netmask from Security Intelligence feeds are
also ignored. 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, instead of Security Intelligence filtering.
To build the Security Intelligence whitelist and blacklist for an access control policy:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Security Intelligence tab.
Security Intelligence settings for the access control policy appear.
Step 4 Optionally, click the logging icon ( ) to log blacklisted connections.
You must enable logging before you can set blacklisted objects to monitor-only. For details, see Logging
Security Intelligence (Blacklisting) Decisions, page 33-8.
Step 5 Begin building your whitelist and blacklist by selecting one or more Available Objects.
Use Shift and Ctrl to select multiple objects, or right-click and Select All.
Tip You can search for existing objects to include, or create objects on the fly if no existing objects meet the
needs of your organization. For more information, see Searching for Objects to Whitelist or Blacklist,
page 5-5.
Step 6 Optionally, constrain the selected objects by zone by selecting an Available Zone.
By default, objects are not constrained, that is, they have a zone of Any. Note that other than using Any,
you can constrain by only one 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. Also, the global
whitelist or blacklist cannot be constrained by zone.
Step 7 Click Add to Whitelist or Add to Blacklist.
You can also click and drag the selected objects to either list.
The objects you selected are added to the whitelist or blacklist.
Tip To remove an object from a list, click its delete icon ( ). Use Shift and Ctrl to select multiple objects,
or right-click and Select All, then right-click and select Delete Selected. If you are deleting a global list,
you must confirm your choice. Note that removing an object from a whitelist or blacklist does not delete
that object from the ASA FirePOWER module.
Step 8 Repeat steps 5 through 7 until you are finished adding objects to your whitelist and blacklist.
Step 9 Optionally, set blacklisted objects to monitor-only by right-clicking the object under Blacklist, then
selecting Monitor-only (do not block).
In passive deployments, Cisco recommends you set all blacklisted objects to monitor-only. Note,
however, that you cannot set the global blacklist to monitor-only.
Step 10 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Within an access control policy, access control rules provide a granular method of handling network
traffic.
Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network
traffic is evaluated by access control rules.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. Conditions can be simple or complex; you can control
traffic by security zone, network or geographical location, port, application, requested URL, and user.
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. However, after the system trusts or blocks traffic, it does not perform further inspection.
The following scenario summarizes the ways that traffic can be evaluated by access control rules in an
inline, intrusion prevention deployment.
• Rule 2: Trust evaluates traffic next. Matching traffic is allowed to pass to its destination without
further inspection. Traffic that does not match continues to the next rule.
• Rule 3: Block evaluates traffic third. Matching traffic is blocked without further inspection. Traffic
that does not match continues to the final rule.
• Rule 4: Allow is the final rule. For this rule, matching traffic is allowed; however, prohibited files,
malware, intrusions, and exploits within that traffic are detected and blocked. Remaining
non-prohibited, non-malicious traffic is allowed to its destination. Note that you might have
additional Allow rules that perform only file inspection, or only intrusion inspection, or neither.
• Default Action handles all traffic that does not match any of the rules. In this scenario, the default
action performs intrusion prevention before allowing non-malicious traffic to pass. In a different
deployment, you might have a default action that trusts or blocks all traffic, without further
inspection. (You cannot perform file or malware inspection on traffic handled by the default action.)
For more information on access control rules, see:
• Creating and Editing Access Control Rules, page 6-2
• Managing Access Control Rules in a Policy, page 6-11
• ASA FirePOWER module Applying includesASA FirePOWER module a orYou might be able to
select as few as three intrusion policies across an entire access control policy. Configuration > ASA
FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring >
Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11
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 access control 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, port, application, requested URL, or user. 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. Note that the system does not perform
inspection on trusted or blocked traffic.
Inspection
Inspection options for an access control rule 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 and end of
a connection. You can log connections to the ASA FirePOWER module, 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 a comment.
Use the access control rule editor to add and edit access control rules; access the rule editor from the
Rules tab of the access control policy editor. In the rule editor, you:
• 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.
For more information, see ASA FirePOWER module Applying includesASA FirePOWER module a
orYou might be able to select as few as three intrusion policies across an entire access control policy.
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA
FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy where you want to add a rule.
The policy page appears, focused on the Rules tab.
Step 3 You have the following options:
• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ) next to the rule you want to edit.
The access control rule editor appears.
Step 4 Type a Name for the rule.
Each rule must have a unique name. You can use up to thirty printable characters, including spaces and
special characters, with the exception of the colon (:).
Step 5 Configure the rule components, as summarized above. You can configure the following, or accept the
defaults:
• Specify whether the rule is Enabled.
• Specify the rule position; see Specifying a Rule's Order of Evaluation, page 6-4.
• Select a rule Action; see Using Rule Actions to Determine Traffic Handling and Inspection, page 6-6.
• Configure the rule’s conditions; see Using Conditions to Specify the Traffic a Rule Handles,
page 6-5.
• For Allow and Interactive Block rules, configure the rule’s Inspection options; see Controlling Traffic
Using Intrusion and File Policies, page 10-1.
• Specify Logging options; see Logging Connections in Network Traffic, page 33-1.
• Add Comments; see Adding Comments to a Rule, page 6-10.
Step 6 Click Store FirePOWER Changes to save the rule.
Your rule is saved. You can click the delete icon ( ) to delete the rule. You must apply the access
control policy for your changes to take effect; see Deploying Configuration Changes, page 4-10.
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. For more information, see Ordering Rules to Improve Performance and Avoid
Preemption, page 4-14.
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 Cisco-provided categories or change their order. For information on changing the position or
category of an existing rule, see Changing a Rule's Position or Category, page 6-13.
Step 1 In the access control rule editor, from the Insert drop-down list, select Into Category, then select the
category you want to use.
When you save the rule, it is placed last in that category.
Step 1 In the access control rule editor, from the Insert drop-down list, select above rule or below rule, then type
the appropriate rule number.
When you save the rule, it is placed where you specified.
Note When you apply an access control policy, the system evaluates all its rules and creates an expanded set
of criteria that the ASA FirePOWER module uses to evaluate network traffic. Complex access control
policies and rules can command significant resources. For tips on simplifying access control rules and
other ways to improve performance, see ASA FirePOWER module Applying includesASA FirePOWER
module a orYou might be able to select as few as three intrusion policies across an entire access control
policy. Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA
FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11.
When you add or edit an access control rule, use the tabs on the left side of the lower portion of the rule
editor to add and edit rule conditions. The following table summarizes the types of conditions you can
add.
Table 6-1 Access Control Rule Condition Types
Note that although you can create access control rules with any license, certain rule conditions require
that you enable specific licensed capabilities before you can apply the policy. For more information, see
License Requirements for Access Control, page 4-2.
You can log trusted network traffic at both the beginning and end of connections. For more information,
see Understanding Logging for Trusted Connections, page 33-5.
For HTTP traffic, when the system blocks a web request, you can override the default browser or server
page with a custom page that explains that the connection was denied. The system calls this custom page
an HTTP response page; see Displaying a Custom Web Page for Blocked URLs, page 8-14.
You can log blocked network traffic only at the beginning of connections. Note that only devices
deployed inline can block traffic. Because blocked connections are not actually blocked in passive
deployments, the system may report multiple beginning-of-connection events for each blocked
connection. For more information, see Understanding Logging for Blocked and Interactively Blocked
Connections, page 33-5.
Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system
performance with multiple similar events. Before you enable logging for an Block rule, consider whether
the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.
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.
You can log allowed network traffic at both the beginning and end of connections.
Step 1 In the access control rule editor, select the Comments tab.
The Comments page appears.
Step 2 Click New Comment.
The New Comment pop-up window appears.
Step 3 Type your comment and click OK.
Your comment is saved. You can edit or delete this comment until you save the rule.
Step 4 Save or continue editing the rule.
For each rule, the policy editor displays its name, a summary of its conditions, the rule action, plus icons
that communicate the rule’s inspection and logging options. Other icons represent comments, warnings,
errors, and other important information, as described in the following table. Disabled rules are grayed
and marked (disabled) beneath the rule name.
Step 1 In the access control policy editor for the policy you want to search, click the Search Rules prompt, type
a search string, then press Enter. You can also use the Tab key or click a blank page area to initiate the
search.
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 ( ).
modify them. Note that you can also enable or disable an access control rule using the rule editor; see
Creating and Editing Access Control Rules, page 6-2.
Step 1 In the access control policy editor for the policy that contains the rule you want to enable or disable,
right-click the rule and choose a rule state:
• To enable an inactive rule, select State > Enable.
• To disable an active rule, select State > Disable.
Step 2 Click Store FirePOWER Changes to save the policy.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Moving a Rule
License: Any
Proper access control rule order reduces the resources required to process network traffic, and prevents
rule preemption.
The following procedure explains how to move one or more rules at a time using the access control
policy editor. You can also move individual access control rules using the rule editor; see Creating and
Editing Access Control Rules, page 6-2.
To move a rule:
Step 1 In the access control policy editor for the policy that contains the rules you want to move, select the rules
by clicking in a blank area for each rule. Use the Ctrl and Shift keys to select multiple rules.
The rules you selected are highlighted.
Step 2 Move the rules. You can cut and paste or drag and drop.
To cut and paste rules into a new location, right-click a selected rule and select Cut. Then, 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.
Note that you cannot copy and paste access control rules between two different access control policies.
Step 3 Click Store FirePOWER Changes to save the policy.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Step 1 In the access control policy editor for the policy where you want to add a rule category, click Add
Category.
Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to set the
position of the new category before you add it. You can also right-click an existing rule and select Insert
new category.
Access control rules within access control policies exert granular control over network traffic logging
and handling. Network-based conditions allow you to manage which traffic can traverse your network,
using one or more of the following criteria:
• source and destination security zones
• source and destination IP addresses or geographical locations
• source and destination port, which also includes transport layer protocol and ICMP code options
You can combine network-based conditions with each other and with other types of conditions to create
an access control rule. These access control rules can be simple or complex, matching and inspecting
traffic using multiple conditions. For detailed information on access control rules, see Tuning Traffic
Flow Using Access Control Rules, page 6-1.
Note Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network
traffic is evaluated by access control rules.
As a simple example, you could create two zones: Internal and External, and assign 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 to protect similar
resources in several different locations. Each of these devices protects the assets in its Internal security
zone.
Tip 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. For more information on creating zones, see
Working with Security Zones, page 2-33.
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 inspecting incoming traffic for intrusions and
malware.
To accomplish this using access control, configure an access control rule with a zone condition where
the Destination Zone is set to Internal. This simple access control rule matches traffic that leaves the device
from any interface in the Internal zone.
To ensure that the system inspects matching traffic for intrusions and malware, choose a rule action of
Allow, then associate this rule with an intrusion and a file policy. For more information, see Using Rule
Actions to Determine Traffic Handling and Inspection, page 6-7 and Controlling Traffic Using Intrusion
and File Policies, page 10-1.
If you want to build a more complex rule, you can add a maximum of 50 zones to each of the Source Zones
and Destination Zones in a single zone condition:
• To match traffic leaving the device from an interface in the zone, add that zone to the Destination
Zones.
Because devices deployed passively do not transmit traffic, you cannot use a zone comprised of
passive interfaces in a Destination Zone condition.
• To match 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.
When building a zone condition, warning icons indicate invalid configurations. For details, ASA
FirePOWER module Applying includesASA FirePOWER module a orYou might be able to select as few
as three intrusion policies across an entire access control policy. Configuration > ASA FirePOWER
Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring > Task Status)
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to control traffic by zone, create a new access control rule
or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the Zones tab.
The Zones tab appears.
Step 3 Find and select the zones you want to add from the Available Zones.
To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone
name. The list updates as you type to display matching zones.
Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select
Select All.
Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.
You can also drag and drop selected zones.
Step 5 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Tip After you create a network or geolocation object, you can use it not only to build access control rules,
but also to represent IP addresses in various other places in the system’s module interface. You can create
these objects using the object manager; you can also create network objects on-the-fly while you are
configuring access control rules. For more information, see Managing Reusable Objects, page 2-1.
Note that 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 ASA FirePOWER module; see Updating the Geolocation
Database, page 43-21.
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 traffic from an IP address or geographical location, configure the Source Networks.
• To match 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 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, see ASA
FirePOWER module Applying includesASA FirePOWER module a orYou might be able to select as few
as three intrusion policies across an entire access control policy. Configuration > ASA FirePOWER
Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring > Task Status)
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to control traffic by network, create a new access control
rule or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the Networks tab.
The Networks tab appears.
Step 3 Find and select the networks you want to add from the Available Networks, as follows:
• Click the Networks tab to display network objects and groups to add; click the Geolocation tab to
display geolocation objects.
• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list; see Working with Network Objects, page 2-3.
• To search for network or geolocation objects to add, select the appropriate tab, click the Search by
name or value prompt above the Available Networks list, then type an object name or the value of one
of the object’s components. The list updates as you type to display matching objects.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.
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.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
• For TCP and UDP, you can control traffic based on the transport layer protocol. The system
represents this configuration using the protocol number in parentheses, plus an optional associated
port or port range. For example: TCP(6)/22.
• For ICMP and ICMPv6 (IPv6-ICMP), you can control traffic based on its Internet layer protocol
plus an optional type and code. For example: ICMP(1):3:3.
• You can control traffic using other protocols that do not use ports.
When you build a port-based access control rule condition, you can manually specify ports. Alternately,
you can configure port conditions with port objects, which are reusable and associate a name with one
or more ports.
Tip After you create a port object, you can use it not only to build access control rules, but also to represent
ports in various other places in the system’s module interface. You can create port objects either using
the object manager or on-the-fly while you are configuring access control rules. For more information,
see Working with Port Objects, page 2-9.
You can add a maximum of 50 items to each of the Selected Source Ports and Selected Destination Ports lists
in a single network condition:
• To match traffic from a port, configure the Selected Source Ports.
If you add only source ports to a condition, you can add ports that use different transport protocols.
For example, you can add both DNS over TCP and DNS over UDP as source port conditions in a
single access control rule.
• To match traffic to a port, configure the Selected Destination Ports.
If you add only destination ports to a condition, you can add ports that use different transport
protocols.
• To match traffic both originating from specific Selected Source Ports and destined for specific Selected
Destination Ports, configure both.
If you add both source and destination ports to a condition, you can only add ports that share a single
transport protocol (TCP or UDP). For example, if you add DNS over TCP as a source port, you can
add Yahoo Messenger Voice Chat (TCP) as a destination port but not Yahoo Messenger Voice Chat
(UDP).
Keep the following points in mind when building a port condition:
• When you add a destination ICMP port with the type set to 0 or a destination ICMPv6 port with the
type set to 129, the access control rule 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.
• When you use the GRE (47) protocol as a destination port condition, you can only add other
network-based conditions to the access control rule, that is, zone, and network conditions. You
cannot save the rule if you add reputation or user-based conditions.
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, see ASA FirePOWER module Applying includesASA FirePOWER module a orYou
might be able to select as few as three intrusion policies across an entire access control policy.
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA
FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to control traffic by port, create a new access control rule
or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the Ports tab.
The Ports tab appears.
Step 3 Find and select the ports you want to add from the Available Ports, as follows:
• To add a port object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Ports list; see Working with Port Objects, page 2-9.
• To search for port objects and groups to add, click the Search by name or value prompt above the
Available Ports list, then type either the name of the object, or the value of a port in the object. The
list updates as you type to display matching objects. For example, if you type 80, the ASA
FirePOWER module displays the Cisco-provided HTTP port object.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and
then select Select All.
Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.
You can also drag and drop selected objects.
Step 5 Add any source or destination ports that you want to specify manually.
• For source ports, select either TCP or UDP from the Protocol drop-down list under the Selected Source
Ports list. Then, enter a Port. You can specify a single port with a value from 0 to 65535.
• For destination ports, select a protocol (including All for all protocols) from the Protocol drop down
list under the Selected Destination Ports list. You can also type the number of an unassigned protocol
that does not appear in the list.
If you select ICMP or IPv6-ICMP, a pop-up window appears where you can select a type and a related
code. For more information on ICMP types and codes, see
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml and
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml.
If you do not want to specify a protocol, or optionally if you specified TCP or UDP, enter a Port. You
can specify a single port with a value from 0 to 65535.
Click Add. Note that the ASA FirePOWER module will not add a port to a rule condition that results in
an invalid configuration.
Step 6 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Access control rules within access control policies exert granular control over network traffic logging
and handling. Reputation-based conditions in access control rules allow you to manage which traffic can
traverse your network, by contextualizing your network traffic and limiting it where appropriate. Access
control rules govern the following types of reputation-based control:
• Application conditions allow you to perform application control, which controls application traffic
based on not only individual applications, but also applications’ basic characteristics: type, risk,
business relevance, categories, and tags.
• URL conditions allow you to perform URL filtering, which controls web traffic based on individual
websites, as well as websites’ system-assigned category and reputation.
You can combine reputation-based conditions with each other and with other types of conditions to
create an access control rule. These access control rules can be simple or complex, matching and
inspecting traffic using multiple conditions. For detailed information on access control rules, see Tuning
Traffic Flow Using Access Control Rules, page 6-1.
Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network
traffic is evaluated by access control rules. Reputation-based access control requires the following
licenses.
Requirement Application Control URL Filtering (cat. & rep.) URL Filtering (manual)
license Control URL Filtering Any
Note For encrypted traffic, the system can identify and filter traffic using only the applications tagged SSL
Protocol. Applications without this tag can only be detected in unencrypted traffic.
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.
When you build an application condition this way, the name of the filter you add to the Selected
Applications and Filters list is a concatenation of the filter types represented in the filter plus the names of
up to three filters for each type. More than three filters of the same type are followed by an ellipsis (...).
For example, the following filter name includes two filters under the Risks type and four under Business
Relevance:
Risks: Medium, High Business Relevance: Low, Medium, High,...
Filter types that are not represented in a filter you add with All apps matching the filter are not included in
the name of the filter you add. These filter types are set to any; that is, these filter types do not constrain
the filter, so any value is allowed for these.
You can add multiple instances of All apps matching the filter to an application condition, with each
instance counting as a separate item in the Selected Applications and Filters list. For example, you could
add all high risk applications as one item, clear your selections, then add all low business relevance
applications as another item. This application condition matches applications that are high risk OR have
low business relevance.
Step 1 In the access control policy where you want to control traffic by application, create a new access control
rule or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the Applications tab.
The Applications tab appears.
Step 3 Optionally, use filters to constrain the list of applications displayed in the Available Applications list.
Select one or more filters in the Application Filters list. For more information, see Matching Traffic with
Application Filters, page 8-3.
Step 4 Find and select the applications you want to add from the Available Applications list.
You can search for and select individual applications, or, when the list is constrained, All apps matching
the filter. For more information, see Matching Traffic from Individual Applications, page 8-4.
Step 5 Click Add to Rule to add the selected applications to the Selected Applications and Filters list.
You can also drag and drop selected applications and filters. Filters appear under the heading Filters, and
applications appear under the heading Applications.
Tip Before you add another filter to this application condition, click Clear All Filters to clear your existing
selections.
Step 6 Optionally, click the add icon ( ) above the Selected Applications and Filters list to save a custom filter
comprised of all the individual applications and filters currently in the list.
Use the object manager to manage this on-the-fly-created filter; see Working with Application Filters,
page 2-11. Note that you cannot save a filter that includes another user-created filter; you cannot nest
user-created filters.
Step 7 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Blocking URLs
License: feature dependent
URL conditions in access control rules allow you to limit the websites that users on your network can
access. This feature is called URL filtering. There are two ways you can use access control to specify
URLs you want to block (or, conversely, allow):
• With any license, you can manually specify individual URLs or groups of URLs to achieve granular,
custom control over web traffic.
• With a URL Filtering license, you can also control access to websites based on the URL’s general
classification, or category, and risk level, or reputation. The system displays this category and
reputation data in connection logs, intrusion events, and application details.
Note To see URL category and reputation information in events, you must create at least one access control
rule with a URL condition.
When you block a website, you can either allow the user’s browser its default behavior, or you can
display a generic system-provided or custom page. You can also give users a chance to bypass a website
block by clicking through a warning page.
Note Before access control rules with category and reputation-based URL conditions can take effect, you
must enable communications with the Cisco cloud. This allows the ASA FirePOWER module to retrieve
URL data. For more information, see Enabling Cloud Communications, page 41-6.
When building a URL condition, warning icons indicate invalid configurations. For details, see ASA
FirePOWER module Applying includesASA FirePOWER module a orYou might be able to select as few
as three intrusion policies across an entire access control policy. Configuration > ASA FirePOWER
Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring > Task Status)
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to control traffic by URL, create a new access control rule
or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the URLs tab.
The URLs tab appears.
Step 3 Find and select the categories of URL you want to add from the Categories and URLs list. To match web
traffic regardless of category, select Any category.
To search for categories to add, click the Search by name or value prompt above the Categories and URLs list,
then type the category name. The list updates as you type to display matching categories.
To select a category, click it. To select multiple categories, use the Shift and Ctrl keys.
Tip Although you can right-click and Select All categories, adding all categories this way exceeds the 50-item
maximum for an access control rule. Instead, use Any.
Step 4 Optionally, qualify your category selections by clicking a reputation level from the Reputations list. If you
do not specify a reputation level, the system defaults to Any, meaning all levels.
You can only select one reputation level. When you choose a reputation level, the access control rule
behaves differently depending on its purpose:
• If the rule blocks or monitors web access (the rule action is Block, Block with reset, Interactive Block,
Interactive Block with reset, or Monitor) selecting a reputation level also selects all reputations more
severe than that level. For example, if you configure a rule to block or monitor Suspicious sites (level
2), it also automatically blocks or monitors High risk (level 1) sites.
• If the rule allows web access, whether to trust or further inspect it (the rule action is Allow or Trust),
selecting a reputation level also selects all reputations less severe than that level. For example, if you
configure a rule to allow Benign sites (level 4), it also automatically allows Well known (level 5) sites.
If you change the rule action for a rule, the system automatically changes the reputation levels in URL
conditions according to the above points.
Step 5 Click Add to Rule or drag and drop the selected items to add them to the Selected URLs list.
Step 6 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Tip After you create a URL object, you can use it not only to build access control rules, but also to represent
URLs in various other places in the system’s module interface. You can create these objects using the
object manager; you can also create URL objects on-the-fly while you are configuring access control
rules. For more information, see Working with URL Objects, page 2-10.
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to control traffic by URL, create a new access control rule
or edit an existing rule.
For detailed instructions, see Creating and Editing Access Control Rules, page 6-2.
Step 2 In the rule editor, select the URLs tab.
The URLs tab appears.
Step 3 Find and select the URL objects and groups you want to add from the Categories and URLs list:
• To add a URL object on the fly, which you can then add to the condition, click the add icon ( )
above the Categories and URLs list; see Working with URL Objects, page 2-10.
• To search for URL objects and groups to add, click the Search by name or value prompt above the
Categories and URLs list, then type either the name of the object, or the value of a URL or IP address
in the object. The list updates as you type to display matching objects.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys. Although you can
right-click and Select All URL objects and categories, adding URLs this way exceeds the 50-item
maximum for an access control rule.
Step 4 Click Add to Rule or to add the selected items to the Selected URLs list.
You can also drag and drop selected items.
Step 5 Add any literal URLs that you want to specify manually. You cannot use wildcards (*) in this field.
Click the Enter URL prompt below the Selected URLs list; then type a URL or IP address and click Add.
Step 6 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
This identification should occur within 3 to 5 packets. If one of these first packets matches all other
conditions in an access control rule containing a URL condition but the identification is not complete,
the access control policy allows the packet to pass. This behavior allows the connection to be established
so that URLs can be identified. For your convenience, affected rules are marked with an information icon
( ).
The allowed 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). For more information, see
Setting the Default Intrusion Policy for Access Control, page 17-1.
After the system completes its identification, the system applies the access control rule action, as well
as any associated intrusion and file policy, to the remaining session traffic that matches its URL
condition.
Note that you configure the interactive HTTP response page separately from the response page you
configure for Block rules. For example, you could display the system-provided page to users whose
sessions are blocked without interaction, but a custom page to users who can click to continue. For more
information, see Displaying a Custom Web Page for Blocked URLs, page 8-14.
Tip To quickly disable interactive blocking for all rules in an access control policy, display neither the
system-provided page nor a custom page. This causes the system to block all connections that match an
Interactive Block rule without interaction.
Step 1 Create an access control rule that matches web traffic with a URL condition.
See Performing Reputation-Based URL Blocking, page 8-8 and Performing Manual URL Blocking,
page 8-10.
Step 2 Make sure the access control rule action is Interactive Block or Interactive Block with reset.
See Using Rule Actions to Determine Traffic Handling and Inspection, page 6-7.
Step 3 Assume users will bypass the block and choose inspection and logging options for the rule accordingly.
As with Allow rules:
• You can associate either type of Interactive Block rule with a file and intrusion policy. For more
information, see Controlling Traffic Using Intrusion and File Policies, page 10-1.
• Logging options for interactively blocked traffic are identical to those in allowed traffic, but keep in
mind that if a user does not bypass the interactive block, the system can log only
beginning-of-connection events.
Note that 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. For more information,
see Logging Connections Based on Access Control Handling, page 33-9.
Step 4 Optionally, set the amount of time that elapses after a user bypasses a block before the system displays
the warning page again.
See Setting the User Bypass Timeout for a Blocked Website, page 8-13.
Step 5 Optionally, create and use a custom page to display to allow users to bypass a block.
See Displaying a Custom Web Page for Blocked URLs, page 8-14.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Advanced tab.
Advanced settings for the access control policy appear.
Step 4 Click the edit icon ( ) next to General Settings.
The General Settings pop-up window appears.
Step 5 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.
You can specify any number of seconds from zero to 31536000 (one year). Specifying zero forces your
users to bypass the block every time.
Step 6 Click OK.
Advanced settings for the access control policy appear.
Step 7 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect. For more information, see
Deploying Configuration Changes, page 4-10.
Step 1 Edit the access control policy monitoring your web traffic.
For more information, see Editing Access Control Policies, page 4-7.
Step 2 Select the HTTP Responses tab.
HTTP response page settings for the access control policy appear.
Step 3 For the Block Response Page and the Interactive Block Response Page, select responses from the drop-down
lists. For each page, you have the following choices:
• To use a generic response, select System-provided. You can click the view icon ( ) to view the
HTML code for this page.
• To create a custom response, select Custom.
A pop-up window appears, prepopulated with system-provided code that you can replace or modify.
When you are done, save your changes. Note that you can edit a custom page by clicking the edit
icon ( ).
• To prevent the system from displaying an HTTP response page, select None. Note that selecting this
option for interactively blocked sessions prevents users from clicking to continue; the session is
blocked without interaction.
Step 4 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect. For more information, see
Deploying Configuration Changes, page 4-10.
The following topics describe how to control user traffic on your network:
• Realm, User, User Group, and ISE Attribute Access Control Rule Conditions, page 9-1
• Troubleshooting Issues with User Access Control Rules, page 9-2
• Adding a Realm, User, or User Group Condition to an Access Control Rule, page 9-3
• Adding an ISE Attribute Condition to an Access Control Rule, page 9-3
Realm, User, User Group, and ISE Attribute Access Control Rule
Conditions
License: Control
Before you can perform user control (create access control rule conditions based on entire realms,
individual users, user groups, or ISE attributes), you must:
• Configure a realm for each Microsoft Active Directory or LDAP server you want to monitor. If you
enable user download for the realm, the Firepower Management Center regularly and automatically
queries the server to download metadata for newly or already-reported authoritative users and user
groups.
• Create an identity policy to associate the realm with an authentication method.
• Configure one or more User Agents or ISE devices, or captive portal. If you want to use an ISE
attribute condition, you must configure ISE.
User Agents, ISE, and captive portal collect authoritative user data that can be used for user control
in access control rule conditions. The identity sources monitor specified users as they log in or out
of hosts or authenticate using LDAP or AD credentials.
Note If you configure a User Agent or ISE 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
mappings based on groups, due to your Firepower Management Center user limit. As a result,
access control rules with realm, user, or user group conditions may not fire as expected.
You can add a maximum of 50 realms, users, and groups to the Selected Users in a single user condition.
Conditions with user groups match traffic to or from any of the group’s members, including members of
any sub-groups, with the exception of individually excluded users and members of excluded sub-groups.
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 in access control rules, you must
explicitly include the secondary group.
Note Hardware-based fast-path rules, Security Intelligence-based traffic filtering, SSL inspection, user
identification, and some decoding and preprocessing occur before access control rules evaluate network
traffic.
Access control rules targeting realms, users, or user groups are not firing
If you configure a User Agent or ISE 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, access control rules with realm or user
conditions may not fire as expected.
Access control rules targeting user groups or users within user groups are not firing as expected
If you configure an access control rule with a user group condition, your LDAP or Active Directory
server must have user groups configured. The Firepower Management Center cannot perform user group
control if the server organizes the users in basic object hierarchy.
Access control rules targeting users in secondary groups are not firing as expected
If you configure an access control 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 access control rules with user conditions.
Access control 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 from
the server. Until the system successfully retrieves this information, activity seen by this user is not
handled by matching access control rules. Instead, the user session is handled by the next access control
rule it matches (or the access control policy default action).
For example, this may explain when:
• Users who are members of user groups are not matching access control rules with user group
conditions.
• Users who were reported by ISE or the User Agent are not matching access control 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.
Step 1 In the access control rule editor, select the Users tab.
Step 2 Search by name or value above the Available Realms list and select a realm.
Step 3 Search by name or value above the Available Users list and select a user or group.
Step 4 Click Add to Rule, or drag and drop.
Step 5 Save or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Step 1 In the access control rule editor, select the ISE Attributes tab.
Step 2 Search by name or value above the Available ISE Session Attributes list and select an attribute.
Step 3 Search by name or value above the Available ISE Metadata list and select metadata.
Step 4 Click Add to Rule, or drag and drop.
Tip You can also use the Add a Location IP Address field to add a Location IP attribute to the condition. 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, page 4-10.
Intrusion and file policies work together, as the last line of defense before traffic is allowed to its
destination:
• Intrusion policies govern the system’s intrusion prevention capabilities; see Understanding
Network Analysis and Intrusion Policies, page 15-1.
• File policies govern the system’s network-based file control and advanced malware protection
(AMP) capabilities; see Understanding and Creating File Policies, page 32-4.
Security Intelligence-based traffic filtering (blacklisting) and traffic decoding and preprocessing occur
before network traffic is examined for intrusions, prohibited files, and malware. 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.
Intrusion prevention and AMP require that you enable specific licensed capabilities as described in the
following table.
For more information on inspecting traffic for intrusions, prohibited files, and malware, see:
• Inspecting Allowed Traffic For Intrusions and Malware, page 10-2
• Tuning Intrusion Prevention Performance, page 10-6
• Tuning File and Malware Inspection Performance and Storage, page 10-16
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. For more information, see Setting the Default Intrusion Policy for Access Control, page 17-1.
For more information on the above scenario and instructions on associating file and intrusion policies
with access control rules and the access control default action, see:
• Understanding File and Intrusion Inspection Order, page 10-2
• Configuring an Access Control Rule to Perform AMP or File Control, page 10-3
• Configuring an Access Control Rule to Perform Intrusion Prevention, page 10-4
• Setting Default Handling and Inspection for Network Traffic, page 4-4
Note Traffic allowed by an Intrusion Prevention default action can be inspected for 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
Tip The system does not perform any kind of inspection on trusted traffic.
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.
Note Until a file is detected and blocked in a session, packets from the session may be subject to intrusion
inspection.
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
cloud lookup nor intrusion inspection.
• Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network.
Any PDFs with a malware file 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy where you want to configure AMP or file
control using access control rules.
Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules, page 6-2.
The access control rule editor appears.
Step 4 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.
Step 5 Select the Inspection tab.
The Inspection tab appears.
Step 6 Select a File Policy to inspect traffic that matches the access control rule, or select None to disable file
inspection for matching traffic.
You can click the edit icon ( ) that appears to edit the policy; see Creating a File Policy, page 32-9.
Step 7 Click Add to save the rule.
Your rule is saved. You must save and apply the access control policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
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; see Optimizing Predefined Default Variables, page 2-14.
Although you can associate a different intrusion policy-variable set pair with each Allow and Interactive
Block rule (as well as with the default action), you cannot apply an access control policy if the target
devices have insufficient resources to perform inspection as configured. For more information, see
Simplifying Rules to Improve Performance, page 4-12.
initial configurations for advanced settings. You can use system-provided policies as-is, or you can use
them as the base for custom policies. Building custom policies can improve the performance of the
system in your environment and provide a focused view of the malicious traffic and policy violations
occurring on your network.
In addition to custom policies that you create, the system provides two custom policies: Initial Inline
Policy and Initial Passive Policy. These two intrusion policies use the Balanced Security and
Connectivity intrusion policy as their base. The only difference between them is their Drop When Inline
setting, which enables drop behavior in the inline policy and disables it in the passive policy. For more
information, see Comparing System-Provided with Custom Policies, page 15-7.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy where you want to configure intrusion
inspection using access control rules.
Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules, page 6-2.
The access control rule editor appears.
Step 4 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.
Step 5 Select the Inspection tab.
The Inspection tab appears.
Step 6 Select a system-provided or custom Intrusion Policy, or select None to disable intrusion inspection for
traffic that matches the access control rule.
If you select a custom intrusion policy, you can click the edit icon ( ) that appears to edit the policy;
see Editing Intrusion Policies, page 23-4.
Caution Do not select Experimental Policy 1 unless instructed to by a Cisco representative. Cisco uses this
policy for testing.
Step 7 Optionally, change the Variable Set associated with the intrusion policy.
You can click the edit icon ( ) that appears to edit the variable set; see Working with Variable Sets,
page 2-13.
Step 8 Click Save to save the rule.
Your rule is saved. You must save and apply the access control policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Performance Settings, then select the Pattern Matching Limits tab in the
pop-up window that appears.
Caution Do not override default PCRE limits unless you are an experienced intrusion rule writer with knowledge
of the impact of degenerative patterns.
The following table describes the options you can configure to override the default limits.
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.
Option Description
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Performance Settings, then select the Regular Expression Limits tab in the
pop-up window that appears.
Step 5 You can modify any of the options in the Regular Expression Constraint Options table.
Step 6 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
The following table describes the options you can configure to determine how many events are logged
per packet or stream.
Option Description
Maximum Events The maximum number of events that can be stored for a given packet or packet
Stored Per Packet stream.
Maximum Events The number of events logged for a given packet or packet stream. This cannot
Logged Per Packet exceed 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Performance Settings, then select the Intrusion Event Logging Limits tab in the
pop-up window that appears.
Step 5 You can modify any of the options in the Intrusion Event Logging Limits Options table.
Step 6 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
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.
For more information on drop rules, see Setting Rule States, page 24-19.
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.
See the Minimum Packet Latency Threshold Settings table for
recommended minimum threshold settings.
You can enable rule 134:3 to generate an event when the system stops inspecting a packet because the
packet latency threshold is exceeded. See Setting Rule States, page 24-19 for more information.
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Latency-Based Performance Settings, then select the Packet Handling tab in
the pop-up window that appears.
Step 5 See the Minimum Packet Latency Threshold Settings table for recommended minimum Threshold
settings.
Step 6 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
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. For more information on drop rules, see Setting Rule States, page 24-19.
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. See the Minimum Rule Latency Threshold Settings table
for recommended minimum threshold settings.
Consecutive Threshold Specifies the consecutive number of times rules can take longer than the time
Violations Before set for Threshold to inspect packets before rules are suspended.
Suspending Rule
Suspension Time Specifies the number of seconds to suspend a group of rules.
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Latency-Based Performance Settings, then select the Rule Handling tab in
the pop-up window that appears.
Step 5 You can configure any of the options in the Rule Latency Thresholding Options table.
See the Minimum Rule Latency Threshold Settings table for recommended minimum Threshold settings.
Step 6 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only
with Support guidance.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only
with Support guidance.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Performance Settings, then select the Performance Statistics tab in the
pop-up window that appears.
Step 5 Modify the Sample time or Minimum number of packets as described above.
Step 6 Optionally, expand the Troubleshoot Options section and modify those options only if asked to do so by
Support.
Step 7 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
If you use file policies to perform file control or malware detection or blocking, you can set the options
listed in the following table. Keep in mind that increasing the file sizes can affect the performance of the
system.
Table 10-8 Advanced Access Control File and Malware Detection Options
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Files and Malware Settings.
The Files and Malware Settings pop-up window appears.
Step 5 You can set any of the options in the Advanced Access Control File and Malware Detection Options
table.
Step 6 Click OK.
You must save and apply the access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
By default, the ASA FirePOWER module cannot inspect traffic encrypted with the Secure Socket Layer
(SSL) or Transport Layer Security (TLS) protocols. As part of access control, the SSL inspection feature
allows you to either block encrypted traffic without inspecting it, or inspect encrypted or decrypted
traffic with access control. As the module handles encrypted sessions, it logs details about the traffic.
The combination of inspecting encrypted traffic and analyzing encrypted session data allows greater
awareness and control of the encrypted applications and traffic in your network.
If the module detects an SSL or TLS handshake over a TCP connection, it determines whether it can
decrypt the detected traffic. If it cannot, it applies a configured action:
• block the encrypted traffic, and optionally reset the TCP connection
• not decrypt the encrypted traffic
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. For more information, see Creating and Editing Access Control Rules,
page 6-2 and Using the SSL Preprocessor, page 19-71.
If the module 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; and advanced
malware protection. If the system does not block the decrypted traffic post-analysis, it reencrypts the
traffic before passing it to the destination host.
Note Certain SSL inspection actions, such as blocking traffic and decrypting outgoing traffic, modify the flow
of traffic. ASA FirePOWER modules deployed inline can perform these actions. ASA FirePOWER
modules deployed passively cannot affect the flow of traffic. However, these devices can still decrypt
incoming traffic; see Example: Decrypting Traffic in a Passive Deployment, page 11-4 for more
information.
For more information, see Tuning Traffic Decryption Using SSL Rules, page 14-1.
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. If you want to decrypt traffic, see the following table:
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.
For more information, see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection,
page 13-8.
After you have collected this information, upload it to the system and configure reusable objects. See
Managing Reusable Objects, page 2-1 for more information.
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.
3. The Customer Service department server receives the encrypted information request (CcDd) and
decrypts it to plain text (fake).
4. The ASA FirePOWER module uses the session key obtained with the uploaded known private key
to decrypt the encrypted traffic to plain text (fake).
The access control policy continues to process the decrypted traffic and finds fake application
information. The module generates an intrusion event. After the session ends, it generates a
connection event.
5. The ASA FirePOWER module receives a connection event with information about the encrypted and
decrypted traffic, and an intrusion event for the fake application data.
2. The ASA FirePOWER module uses the session key obtained with the uploaded known private key
to decrypt this traffic to plain text (spoof).
The access control policy continues to process the decrypted traffic with the custom intrusion policy
and finds a spoof attempt. The ASA FirePOWER module blocks the traffic, then generates an
intrusion event. It generates a connection event after the session ends.
3. The internal router does not receive the blocked traffic.
4. The Underwriting department server does not receive the blocked traffic.
5. The ASA FirePOWER module receives a connection event with information about the encrypted and
decrypted traffic, and an intrusion event for the spoofing attempt.
Inspecting Specific Users’ Encrypted Traffic with a Re-signed Certificate in an Inline Deployment
License: Control
For all SSL-encrypted traffic sent from the new and junior underwriters to MedRepo’s requests
department, the system uses a re-signed server certificate to obtain session keys, then decrypts the traffic
and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to MedRepo.
Note When decrypting traffic in an inline deployment by re-signing the server certificate, the ASA
FirePOWER module acts as a man-in-the-middle. It creates two SSL sessions, one between client and
ASA FirePOWER module, one between ASA FirePOWER module 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.
An SSL policy determines how the system handles encrypted traffic on your network. You can configure
one or more SSL policies. You associate an SSL policy with an access control policy, then apply the
access control policy. When the ASA FirePOWER module detects a TCP handshake, the access control
policy first handles and inspects the traffic. If it subsequently identifies an SSL-encrypted session over
the TCP connection, the SSL policy takes over, handling and decrypting the encrypted traffic. You can
have one currently applied SSL policy.
The simplest SSL policy, as shown in the following diagram, directs the device where it is applied to
handle encrypted traffic with a single default action. You can set the default action to block decryptable
traffic without further inspection, or inspect undecrypted decryptable traffic with access control. The
system can then either allow or block the encrypted traffic. If the ASA FirePOWER module detects
undecryptable traffic, it either blocks the traffic without further inspection or does not decrypt it,
inspecting it with access control.
This chapter explains how to create and apply a simple SSL policy. It also contains basic information on
managing SSL policies: editing, updating, comparing, and so on. For more information, see:
• Creating a Basic SSL Policy, page 12-2
• Editing an SSL Policy, page 12-6
• Applying Decryption Settings Using Access Control, page 12-8
• Generating a Report of Current Traffic Decryption Settings, page 12-9
• Comparing SSL Policies, page 12-10
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. After you create
a basic SSL policy, see the following chapters for more information on tailoring it to your deployment:
• Managing Reusable Objects, page 2-1 describes how to configure reusable public key infrastructure
(PKI) objects and other SSL inspection-related objects to enhance encrypted traffic control and
decrypt traffic.
• Logging Connections in Network Traffic, page 33-1 describes how to configure logging for
encrypted traffic, whether decryptable or undecryptable.
• Applying Decryption Settings Using Access Control, page 12-8 describes how to associate an SSL
policy with an access control policy.
• Getting Started with Access Control Policies, page 4-1 describes how to apply an access control
policy to a device.
• Tuning Traffic Flow Using Access Control Rules, page 6-1 describes how to configure access
control rules to inspect decrypted traffic.
• Getting Started with SSL Rules, page 13-1 describes how to configure SSL rules to handle and log
encrypted traffic.
• Tuning Traffic Decryption Using SSL Rules, page 14-1 describes how to configure SSL rule
conditions to better match specific encrypted traffic.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Give the policy a unique Name and, optionally, a Description.
You can use all printable characters, including spaces and special characters.
Step 3 Specify the Default Action.
Note that you can modify your selected default action after you create your SSL policy. See Setting
Default Handling and Inspection for Encrypted Traffic, page 12-3 for more information.
Step 4 Click Store ASA FirePOWER Changes.
The SSL Policy Editor page appears. See Editing an SSL Policy, page 12-6 for more information.
When you first create an SSL policy, logging connections that are handled by the default action is
disabled by default. You can change this, as well as the default action itself, after you create the policy.
The following procedure explains how to set the default action for an SSL policy while editing the policy.
See Editing an SSL Policy, page 12-6 for the complete procedure for editing an SSL policy.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL policy page appears.
Step 2 Click the edit icon ( ) next to the SSL policy you want to configure.
The SSL policy editor appears.
Step 3 Select a Default Action. See the SSL Policy Default Actions table for more information.
Step 4 Configure logging options for the default action as described in Logging Decryptable Connections with
SSL Rules, page 33-14.
Step 5 Click Store ASA FirePOWER Changes.
The SSL Policy Editor page appears. See Editing an SSL Policy, page 12-6 for more information.
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. For
more information on configuring default logging, see Logging Decryptable Connections with SSL
Rules, page 33-14.
Note The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your 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. See Decrypt
Actions: Decrypting Traffic for Further Inspection, page 13-9 for more information.
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the edit icon ( ) next to the SSL policy you want to configure.
The SSL policy editor appears.
Step 3 Select the Undecryptable Actions tab.
The Undecryptable Actions tab appears.
Step 4 For each field, select the action you want to take on the type of undecryptable traffic, or if you want to
apply the SSL policy’s default action. See the SSL Policy Default Actions table for more information.
Step 5 Click Store ASA FirePOWER Changes.
You must apply the associated access control policy for your changes to take effect; see Deploying
Configuration Changes, page 4-10.
When you change your configuration, a message indicates that you have unsaved changes. To retain your
changes, you must save the policy before exiting the policy editor. If you attempt to exit the policy editor
without saving your changes, you are cautioned that you have unsaved changes; you can then discard
your changes and exit the policy, or return to the policy editor.
To protect the privacy of your session, after sixty minutes of inactivity on the policy editor, changes to
your policy are discarded and you are returned to the SSL Policy page. After the first thirty minutes of
inactivity, a message appears and updates periodically to provide the number of minutes remaining
before changes are discarded. Any activity on the page cancels the timer.
When multiple users edit the same policy concurrently, a message on the policy editor identifies other
users who have unsaved changes. Any user who attempts to save changes is cautioned that his changes
will overwrite changes by other users. When the same policy is saved by multiple users, the last saved
changes are retained.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 You have the following choices:
• To configure your policy, you can take any of the actions summarized in the SSL Policy
Configuration Actions table.
• To organize rules in your policy, you can take any of the actions described in Managing SSL Rules
in a Policy, page 13-11.
Step 3 Save or discard your configuration. You have the following choices:
• To save your changes and continue editing, click Store ASA FirePOWER Changes.
• To discard your changes, click Cancel and, if prompted, click OK.
Your changes are discarded and the SSL Policy page appears.
Note In a passive deployment, the system cannot influence the flow of traffic. If you attempt to apply an access
control policy that references an SSL policy that blocks encrypted traffic, or that is configured to decrypt
traffic by re-signing the server certificate, the system displays a warning. Also, passive deployments do
not support decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve
Diffie-Hellman (ECDHE) cipher suites.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Advanced tab.
Advanced settings for the access control policy appear.
Step 4 Click the edit icon ( ) next to General Settings.
The General Settings pop-up window appears.
Step 5 Select an SSL policy from the SSL Policy to use for inspecting encrypted connections drop-down.
Step 6 Click OK.
Advanced settings for the access control policy appear.
Step 7 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Tip You can also generate an SSL comparison report that compares a policy with the currently applied policy
or with another policy. For more information, see Comparing SSL Policies, page 12-10.
An SSL policy report contains the sections described in the following table.
Section Description
Title Page Identifies the name of the policy report, the date and time the policy was last
modified, and the name of the user who made that modification.
Table of Contents Describes the contents of the report.
Policy Information Provides the name and description of the policy, the name of the user who last
modified the policy, and the date and time the policy was last modified.
Default Action Provides the default action.
Default Logging Provides the default connection logging settings.
Rules Provides the rule action and conditions for each rule in the policy, by rule
category.
Trusted CA Provides the CA certificates that are automatically trusted if detected traffic is
Certificates encrypted using these certificates or other certificates within the chain of trust.
Undecryptable Provides the action taken on detected types of traffic that cannot be decrypted.
Actions
Referenced Objects Provides the name and configuration of all individual objects and group objects
used in the policy, by type of condition (networks, ports, and so on) where the
object is configured.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the report icon ( ) next to the policy for which you want to generate a report. Remember to save
any changes before you generate an SSL policy report; only saved changes appear in the report.
The system generates the report. Depending on your browser settings, the report may appear in a pop-up
window, or you may be prompted to save the report to your computer.
Tip You can use a similar procedure to compare access control, network analysis, intrusion, file, system, or
health policies.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy appears.
Step 2 Click Compare Policies.
The Select Comparison window appears.
Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:
• To compare two different policies, select Other Policy.
The page refreshes and the Policy A and Policy B drop-down lists appear.
• To compare another policy to the currently active policy, select Running Configuration.
The page refreshes and the Target/Running Configuration A and Policy B drop-down lists appear.
Step 4 Depending on the comparison type you selected, you have the following choices:
• If you are comparing two different policies, select 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, select the second policy from the
Policy B drop-down list.
Step 5 Click OK to display the policy comparison view.
The comparison view appears.
Step 6 Optionally, click Comparison Report to generate the SSL policy comparison report.
The SSL policy comparison report appears. Depending on your browser settings, the report may appear
in a pop-up window, or you may be prompted to save the report to your computer.
Within an SSL policy, SSL rules provide a granular method of handling encrypted traffic, whether
blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access
control, or decrypting the traffic for access control analysis.
The ASA FirePOWER module matches traffic to SSL rules in the order you specify. In most cases, the
module handles encrypted traffic according to the first SSL rule where all the rule’s conditions match
the traffic. Conditions can be simple or complex; you can control traffic by security zone, network or
geographical location, port, application, requested URL, user, certificate, certificate distinguished name,
certificate status, cipher suite, or encryption protocol version.
Each rule also has an action, which determines whether you monitor, block, or inspect matching traffic
with access control, optionally after decrypting matching traffic. Note that the module does not further
inspect encrypted traffic it blocks. It does inspect encrypted and undecryptable traffic with access
control. However, some access control rule conditions require unencrypted traffic, so encrypted traffic
may match fewer rules. Also, by default, the module disables intrusion and file inspection of encrypted
payloads.
The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.
identically. The module 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 module 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 module 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.
For more information, see the following sections:
• Configuring Supporting Inspection Information, page 13-3
• Understanding and Creating SSL Rules, page 13-4
• Managing SSL Rules in a Policy, page 13-11
State
By default, rules are enabled. If you disable a rule, the module 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 module 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, port, application, requested URL, user, certificate,
certificate subject or issuer, certificate status, cipher suite, or encryption protocol version.
Conditions can be simple or complex; their use can depends on device licenses.
Action
A rule’s action determines how the module handles matching traffic. You can monitor, trust, block,
or decrypt matching traffic. Decrypted traffic is subject to further inspection. Note that the module
does not perform inspection on blocked or trusted encrypted traffic.
Logging
A rule’s logging settings govern the records the module keeps of the traffic it handles. You can keep
a record of traffic that matches a rule. You can log a connection when the module blocks an
encrypted session or allows it to pass uninspected, according to the settings in an SSL policy. You
can also force the module to log connections that it decrypts for further evaluation by access control
rules, regardless of how the module later handles or inspects the traffic. You can log connections to
the module log (syslog) or to an SNMP trap server.
Tip Properly creating and ordering SSL 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 module handles traffic as
you expect, the SSL policy interface has a robust warning and error feedback system for rules. For more
information, see Troubleshooting SSL Rules, page 13-15.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the edit icon ( ) next to the SSL policy where you want to add a rule.
The SSL policy editor appears, focused on the Rules tab.
Step 3 You have the following options:
• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ) next to the rule you want to edit.
The SSL rule editor appears.
Step 4 Type a Name for the rule.
Each rule must have a unique name. You can use up to thirty printable characters, including spaces and
special characters, with the exception of the colon (:).
Step 5 Configure the rule components, as summarized above. You can configure the following, or accept the
defaults:
• Specify whether the rule is Enabled.
• Specify the rule position; see Specifying an SSL Rule’s Order of Evaluation, page 13-6.
• Select a rule Action; see Using Rule Actions to Determine Encrypted Traffic Handling and
Inspection, page 13-8.
• Configure the rule’s conditions; see Using Conditions to Specify the Encrypted Traffic a Rule
Handles, page 13-6.
• Specify Logging options; see Logging Decryptable Connections with SSL Rules, page 33-14.
Step 6 Click Save to save the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
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. For more information, see Ordering SSL Rules to Improve Performance and
Avoid Preemption, page 13-16.
In addition to ordering rules by number, you can group rules by category. By default the module provides
three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot
delete the ASA FirePOWER module-provided categories or change their order. For information on
changing the position or category of an existing rule, see Changing an SSL Rule’s Position or Category,
page 13-13.
Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you
want to use.
When you save the rule, it is placed last in that category.
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.
When you save the rule, it is placed where you specified.
An SSL rule’s conditions identify the type of encrypted traffic that rule handles. Conditions can be
simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all
the conditions in a rule does the rule apply to the traffic.
If you do not configure a particular condition for a rule, the module does not match traffic based on that
criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based
on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.
When you add or edit an SSL rule, use the tabs on the left side of the lower portion of the rule editor to
add and edit rule conditions. The conditions you can add to an SSL rule are described in the following
table.
Note that while you can control and inspect encrypted traffic, controlling traffic using detected
application, URL category, or user requires additional licenses. Also, overly complex rules can consume
excessive resources and in some cases prevent you from applying the policy. For more information, see
Troubleshooting SSL Rules, page 13-15.
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.
The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The ASA FirePOWER
module inspects decrypted traffic with access control. Access control rules handle decrypted and
unencrypted traffic identically — you can detect and block intrusions, prohibited files, and malware. The
module reencrypts allowed traffic before passing it to its destination.
When you configure the Decrypt - Known Key action, you can associate one or more server certificates and
paired private keys with the action. If traffic matches the rule, and the certificate used to encrypt the
traffic matches the certificate associated with the action, the module uses the appropriate private key to
obtain the session encryption and decryption keys. Because you must have access to the private key, this
action is best suited to decrypt traffic incoming to servers your organization controls.
Similarly, you can associate one Certificate Authority certificate and private key with the Decrypt - Resign
action. If traffic matches this rule, the module 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 device, one between
device and server. Each session contains different cryptographic session details, and allows the module
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 ASA FirePOWER module
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.
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
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 ASA FirePOWER module
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 module displays a warning icon ( ).
• You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment, as 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 targetspassive or inline (tap mode) interfaces, and
contains a Decrypt - Resign rule, the module 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
module displays a warning icon ( ). If you apply 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.
• The ASA FirePOWER module cannot decrypt traffic encrypted with an anonymous cipher suite.
You cannot use either the Decrypt - Resign or Decrypt - Known Key action in an SSL rule if you add an
anonymous cipher suite to the Cipher Suite condition.
• The ASA FirePOWER module cannot decrypt traffic if an HTTP proxy is positioned between a
client and yourdevice, and the client and server establish a tunneled SSL connection using the
CONNECT HTTP method. The Handshake Errors undecryptable action determines how the module
handles this traffic. See Setting Default Handling for Undecryptable Traffic, page 12-4 for more
information.
• 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. For more information, see
Using Rule Actions to Determine Encrypted Traffic Handling and Inspection, page 13-8.
• 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.
For more information, see Obtaining and Uploading a New Signed Certificate, page 2-39.
• 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
apply the access control policy associated with the SSL policy. For more information, see
Controlling Encrypted Traffic by Certificate, page 14-19 and Controlling Encrypted Traffic by
Cipher Suite, page 14-24.
• If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive
Block with reset, the ASA FirePOWER module blocks the matching connection without interaction
and the module 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 may 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. For more information on this option, see Normalizing Inline Traffic, page 21-6.
• If your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic
by re-signing the server certificate. 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.
For each rule, the policy editor displays its name, a summary of its conditions, and the rule action. Icons
represent warnings, errors, and other important information. Disabled rules are grayed out and marked
(disabled) beneath the rule name. See Troubleshooting SSL Rules, page 13-15 for more information
about the icons.
For information on managing SSL rules, see:
• Searching SSL Rules, page 13-12
• Enabling and Disabling SSL Rules, page 13-13
• Changing an SSL Rule’s Position or Category, page 13-13
Step 1 In the SSL policy editor for the policy you want to search, click the Search Rules prompt, type a search
string, then press Enter. You can also use the Tab key or click a blank page area to initiate the search.
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 ( ).
Step 1 In the SSL policy editor for the policy that contains the rule you want to enable or disable, right-click
the rule and choose a rule state:
• To enable an inactive rule, select State > Enable.
• To disable an active rule, State > Disable.
Step 2 Click Store ASA FirePOWER Changes.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
To move a rule:
Step 1 In the SSL policy editor for the policy that contains the rules you want to move, select the rules by
clicking in a blank area for each rule. Use the Ctrl and Shift keys to select multiple rules.
The rules you selected are highlighted.
Step 2 Move the rules. You can cut and paste or drag and drop.
To cut and paste rules into a new location, right-click a selected rule and select Cut. Then, 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.
Note that you cannot copy and paste SSL rules between two different SSL policies.
Step 3 Click Store ASA FirePOWER Changes..
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Step 1 In the SSL policy editor for the policy where you want to add a rule category, click Add Category.
Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to set the
position of the new category before you add it. You can also right-click an existing rule and select Insert
new category.
Properly configuring SSL rules can also reduce the resources required to process network traffic.
Creating complex rules and mis-ordering rules can affect performance.
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. In the SSL policy, order this rule before all Decrypt -
Resign rules that also match the traffic. You can retrieve the pinned certificate from the client's browser
after a successful connection to the website. You can also view the certificate from the logged connection
event, whether the connection succeeded or failed.
Simplifying Rules
The following guidelines can help you simplify your SSL rules and improve performance:
• When constructing a rule, use as few individual elements in your conditions as possible. For
example, in network conditions, use IP address blocks rather than individual IP addresses. In port
conditions, use port ranges. Use application filters and URL categories and reputations to perform
application control and URL filtering, and LDAP user groups to perform user control.
Note that combining elements into objects that you then use in SSL rule conditions does not improve
performance. For example, using a network object that contains 50 individual IP addresses gives you
only an organizational—not a performance—benefit over including those IP addresses in the
condition individually.
• Restrict rules by security zones whenever possible. If a device’s interfaces are not in one of the zones
in a zone-restricted rule, the rule does not affect performance on that device.
• Do not overconfigure rules. If one condition is enough to match the traffic you want to handle, do
not use two.
A basic SSL rule applies its rule action to all encrypted traffic inspected by the ASA FirePOWER
module. To better control and decrypt encrypted traffic, you can configure rule conditions to handle and
log specific types of traffic. Each SSL rule can contain 0, 1, or more rule conditions; a rule only matches
traffic if the traffic matches every condition in that SSL rule.
Note When traffic matches a rule, the ASA FirePOWER module applies the configure rule action to the traffic.
When the connection ends, the module logs the traffic if configured to do so. For more information, see
Using Rule Actions to Determine Encrypted Traffic Handling and Inspection, page 13-8 and Logging
Connections Based on Access Control Handling, page 33-9.
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, and
country of origin or destination
• 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
For more information, see the following sections:
• Logging Decryptable Connections with SSL Rules, page 33-14
• Controlling Encrypted Traffic with Network-Based Conditions, page 14-1
• Controlling Encrypted Traffic by Reputation, page 14-7
• Controlling Traffic Based on Encryption Properties, page 14-16
Tip 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. For more information on creating zones, see
Working with Security Zones, page 2-33.
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 with SSL inspection, 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.
If you want to build a more complex rule, you can add a maximum of 50 zones to each of the Sources
Zones and Destination Zones in a single zone condition:
• To match encrypted traffic leaving the device from an interface in the zone, add that zone to the
Destination Zones.
Because devices deployed passively do not transmit traffic, you cannot use a zone comprised of
passive interfaces in a Destination Zone condition.
• 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.
Step 1 In the SSL policy where you want to control encrypted traffic by zone, create a new SSL rule or edit an
existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Zones tab.
The Zones tab appears.
Step 3 Find and select the zones you want to add from the Available Zones.
To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone
name. The list updates as you type to display matching zones.
Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select
Select All.
Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.
You can also drag and drop selected zones.
Step 5 Save or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Tip After you create a network or geolocation object, you can use it not only to build SSL rules, but also to
represent IP addresses in various other places in the module interface. You can create these objects using
the object manager; you can also create network objects on-the-fly while you are configuring SSL rules.
For more information, see Managing Reusable Objects, page 2-1.
Note that 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 ASA FirePOWER module; see Updating the Geolocation
Database, page 43-21.
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 ASA
FirePOWER module-provided Cayman Islands geolocation object to represent Cayman Island IP
addresses.
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.
Step 1 In the SSL policy where you want to control encrypted traffic by network, create a new SSL rule or edit
an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Networks tab.
The Networks tab appears.
Step 3 Find and select the networks you want to add from the Available Networks, as follows:
• Click the Networks tab to display network objects and groups to add; click the Geolocation tab to
display geolocation objects.
• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list; see Working with Network Objects, page 2-3.
• To search for network or geolocation objects to add, select the appropriate tab, click the Search by
name or value prompt above the Available Networks list, then type an object name or the value of one
of the object’s components. The list updates as you type to display matching objects.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.
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.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Tip After you create a port object, you can use it not only to build SSL rules, but also to represent ports in
various other places in the module interface. You can create port objects either using the object manager
or on-the-fly while you are configuring SSL rules. For more information, see Working with Port Objects,
page 2-9.
You can add a maximum of 50 items to each of the Selected Source Ports and Selected Destination Ports lists
in a single network condition:
• To match encrypted traffic from a TCP port, configure the Selected Source Ports.
• To match encrypted traffic to a TCP port, configure the Selected Destination Ports.
• To match encrypted traffic both originating from TCP Selected Source Ports and destined for TCP
Selected Destination Ports, configure both.
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.
Step 1 In the SSL policy where you want to control encrypted traffic by TCP port, create a new SSL rule or edit
an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Ports tab.
The Ports tab appears.
Step 3 Find and select the TCP ports you want to add from the Available Ports, as follows:
• To add a TCP port object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Ports list; see Working with Port Objects, page 2-9.
• To search for TCP-based port objects and groups to add, click the Search by name or value prompt
above the Available Ports list, then type either the name of the object, or the value of a port in the
object. The list updates as you type to display matching objects. For example, if you type 443, the
ASA FirePOWER module displays the ASA FirePOWER module-provided HTTPS port object.
To select a TCP-based port object, click it. To select multiple TCP-based port objects, use the Shift and
Ctrl keys, or 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 to add the selected objects to the appropriate list.
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 that the ASA FirePOWER module will not add a port to a rule condition that results in an invalid
configuration.
Step 7 Save or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
For traffic to match an SSL rule with a user condition, the IP address of either the source or destination
host in the monitored session must be associated with a logged in access controlled user. You can control
traffic based on individual users or the groups those users belong to.
You can combine user 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. For detailed information on SSL rules, see Understanding and Creating SSL Rules,
page 13-4.
User control requires a Control license and is supported only for LDAP users and groups (access
controlled users), using login and logoff records reported by a User Agent monitoring Microsoft Active
Directory servers.
Before you can write SSL rules with user conditions, you must configure a connection between the ASA
FirePOWER module and at least one of your organization’s Microsoft Active Directory servers. This
configuration, called an authentication object, contains connection settings and authentication filter
settings for the server. It also specifies the users you can use in user conditions.
In addition, you must install User Agents. The agents monitor users when they authenticate against
Active Directory credentials, and send records of those logins to the ASA FirePOWER module. These
records associate users with IP addresses, which is what allows SSL rules with user conditions to trigger.
Step 1 In the SSL policy where you want to control encrypted traffic by user, create a new SSL rule or edit an
existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Users tab.
The Users tab appears.
Step 3 To search for users to add, click the Search by name or value prompt above the Available Users list, then type
the username. The list updates as you type to display matching users.
To select a user, click it. To select multiple users, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 Click Add to Rule or to add the selected users to the Selected Users list.
You can also drag and drop selected users.
Step 5 Save or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
• Application conditions allow you to perform application control, which controls application traffic
based on not only individual applications, but also applications’ basic characteristics: type, risk,
business relevance, and categories.
• URL conditions allow you to control web traffic based on a websites’ assigned category and
reputation.
You can combine reputation-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.
For more information, see the following sections:
• Controlling Encrypted Traffic Based on Application, page 14-8
• Controlling Encrypted Traffic by URL Category and Reputation, page 14-13
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 ASA FirePOWER module can detect in encrypted traffic are tagged SSL Protocol;
applications without this tag can only be detected in unencrypted or decrypted traffic.
Application filters allow you to quickly create application conditions for SSL rules. They simplify policy
creation and administration, and grant you assurance that the module will control web traffic as
expected. For example, you could create an SSL rule that identifies and decrypts all high risk, low
business relevance applications in encrypted traffic. If a user attempts to use one of those applications,
the session is decrypted and inspected with access control.
In addition, Cisco frequently updates and adds additional detectors via system and vulnerability database
(VDB) updates. You can also create your own detectors and assign characteristics (risk, relevance, and
so on) to the applications they detect. By using filters based on application characteristics, you can
ensure that the module uses the most up-to-date detectors to monitor application traffic.
For traffic to match an SSL rule with an application condition, the traffic must match one of the filters
or applications that you add to a Selected Applications and Filters list.
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.
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 module interface, filters added to a condition are listed above and separately from individually
added applications.
Note that when you apply an SSL policy, for each rule with an application condition, the ASA
FirePOWER module generates a list of unique applications to match. In other words, you may use
overlapping filters and individually specified applications to ensure complete coverage.
For more information, see the following sections:
• Matching Encrypted Traffic with Application Filters, page 14-9
• Matching Traffic from Individual Applications, page 14-10
• Adding an Application Condition to an SSL Rule, page 14-12
• Limitations to Encrypted Application Control, page 14-12
Note that the mechanism for filtering applications within an SSL rule is the same as that for creating
reusable, custom application filters using the object manager; see Working with Application Filters,
page 2-11. You can also save many filters you create on-the-fly in access control rules as new, reusable
filters. You cannot save a filter that includes another user-created filter because you cannot nest
user-created filters.
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.
Step 1 In the SSL policy where you want to control traffic by application, create a new SSL rule or edit an
existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Applications tab.
The Applications tab appears.
Step 3 Optionally, use filters to constrain the list of applications displayed in the Available Applications list.
Select one or more filters in the Application Filters list. For more information, see Matching Encrypted
Traffic with Application Filters, page 14-9.
Step 4 Find and select the applications you want to add from the Available Applications list.
You can search for and select individual applications, or, when the list is constrained, All apps matching
the filter. For more information, see Matching Traffic from Individual Applications, page 14-10.
Step 5 Click Add to Rule to add the selected applications to the Selected Applications and Filters list.
You can also drag and drop selected applications and filters. Filters appear under the heading Filters, and
applications appear under the heading Applications.
Tip Before you add another filter to this application condition, click Clear All Filters to clear your existing
selections.
Note 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. For more information, see Controlling Encrypted Traffic by Certificate Distinguished Name,
page 14-17.
Note Before SSL rules with category and reputation-based URL conditions can take effect, you must enable
communications with the Cisco cloud. This allows the ASA FirePOWER module to retrieve URL data.
For more information, see Enabling Cloud Communications, page 41-6.
Using category and reputation data from the Cisco cloud simplifies policy creation and administration.
It grants you assurance that the module controls encrypted web traffic as expected. Finally, because the
cloud is continually updated with new URLs, as well as new categories and risks for existing URLs, you
can ensure that the module uses up-to-date information to filter requested URLs. Malicious sites that
represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster
than you can update and apply new policies.
For example:
• If a rule blocks all gaming sites, as new domains get registered and classified as Gaming, the module
can block those sites automatically.
• If a rule blocks all malware, and a blog page gets infected with malware, the cloud can recategorize
the URL from Blog to Malware and the module can block that site.
• If a rule blocks high-risk social networking sites, and somebody posts a link on their profile page
that contains links to malicious payloads, the cloud can change the reputation of that page from
Benign sites to High risk so the module can block it.
Note that if the cloud does not know the category or reputation of a URL, or if the ASA FirePOWER
module cannot contact the cloud, that URL does not trigger SSL rules with category or reputation-based
URL conditions. You cannot assign categories or reputations to URLs manually.
The following graphic shows the URL condition for an access control rule that blocks: all malware sites,
all high-risk sites, and all non-benign social networking sites.
Tip If you decrypt traffic, then block it with access control, you can give users a chance to bypass the block
by clicking through a warning page. See Interactive Blocking Actions: Allowing Users to Bypass
Website Blocks, page 6-9 for more information.
You can add a maximum of 50 Selected Categories to match in a single URL condition. Each URL
category, optionally qualified by reputation, counts as a single item.
The following table summarizes how you build the condition shown above. Note that you cannot qualify
a literal URL or URL object with a reputation.
When building a URL condition, warning icons indicate invalid configurations. For details, hover your
pointer over the icon and see ASA FirePOWER module Applying includesASA FirePOWER module a
orYou might be able to select as few as three intrusion policies across an entire access control policy.
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA
FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11.
Step 1 In the SSL policy where you want to control encrypted traffic by URL, create a new SSL rule or edit an
existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Categories tab.
The Categories tab appears.
Step 3 Find and select the categories of URL you want to add from the Categories list. To match encrypted web
traffic regardless of category, select Any category.
To search for categories to add, click the Search by name or value prompt above the Categories list, then type
the category name. The list updates as you type to display matching categories.
To select a category, click it. To select multiple categories, use the Shift and Ctrl keys.
Tip Although you can right-click and Select All categories, adding all categories this way exceeds the 50-item
maximum for an SSL rule. Instead, use Any.
Step 4 Optionally, qualify your category selections by clicking a reputation level from the Reputations list. If you
do not specify a reputation level, the module defaults to Any, meaning all levels.
You can only select one reputation level. When you choose a reputation level, the SSL rule behaves
differently depending on its purpose:
• If the rule blocks web access or decrypts traffic (the rule action is Block, Block with reset, Decrypt -
Known Key, Decrypt - Resign, or Monitor) selecting a reputation level also selects all reputations more
severe than that level. For example, if you configure a rule to block Suspicious sites (level 2), it also
automatically blocks High Risk (level 1) sites.
• If the rule allows web access, subject to access control (the rule action is Do not decrypt), selecting a
reputation level also selects all reputations less severe than that level. For example, if you configure
a rule to allow Benign sites (level 4), it also automatically allows Well known (level 5) sites.
If you change the rule action for a rule, the module automatically changes the reputation levels in URL
conditions according to the above points.
Step 5 Click Add to Rule or to add the selected items to the Selected Categories list.
You can also drag and drop selected items.
Step 6 Save or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Note You cannot configure a distinguished name condition if you also select the Decrypt - Known Key action.
Because that action requires you to select a server certificate to decrypt traffic, the certificate already
matches the traffic. See Decrypt Actions: Decrypting Traffic for Further Inspection, page 13-9 for more
information.
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= then the module prepends CN= before saving the object.
You can also add a distinguished name with one of each attribute listed in the following table, separated
by commas.
OU Organizational
Unit
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.
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.
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, in a single DN condition.
The ASA FirePOWER module-provided DN object group, Sourcefire Undecryptable Sites, contains
websites whose traffic the module 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 module preserves user changes.
Step 1 In the SSL policy where you want to control encrypted traffic by certificate subject or issuer
distinguished name, create a new SSL rule or edit an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the DN tab.
The DN tab appears.
Step 3 Find and select the distinguished names you want to add from the Available DNs, as follows:
• To add a distinguished name object on the fly, which you can then add to the condition, click the add
icon ( ) above the Available DNs list; see Working with Distinguished Name Objects, page 2-34.
• To search for distinguished name objects and groups to add, click the Search by name or value prompt
above the Available DNs 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.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 You have the following options:
• Click Add to Subject to add the selected objects to the Subject DNs list.
• Click Add to Issuer to add the selected objects to the Issuer DNs list.
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.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Step 1 In the SSL policy where you want to control encrypted traffic based on server certificate, create a new
SSL rule or edit an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Certificate tab.
The Certificate tab appears.
Step 3 Find and select the server certificates you want to add from the Available Certificates, as follows;
• To add an external certificate object on the fly, which you can then add to the condition, click the
add icon ( ) above the Available Certificates list; see Working with External Certificate Objects,
page 2-43.
• To search for certificate objects and groups to add, click the Search by name or value prompt above the
Available Certificates 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.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 Click Add to Rule to add the selected objects to the Subject Certificates list.
You can also drag and drop selected objects.
Step 5 Add or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
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. Verified server certificates include
certificates signed by trusted CAs.
If a trusted CA certificate contains an uploaded certificate revocation list (CRL), you can also verify
whether a trusted CA revoked the encryption certificate. See Adding a Certificate Revocation List to a
Trusted CA Object, page 2-42 for more information.
After you add trusted CA certificates to the SSL policy, you can configure an SSL rule with various
Certificate Status conditions to match against this traffic. See Working with Trusted Certificate
Authority Objects, page 2-41 and Controlling Encrypted Traffic by Certificate Status, page 14-20 for
more information.
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.
When you create an SSL policy, the ASA FirePOWER module 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. See Creating a Basic
SSL Policy, page 12-2 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the edit icon ( ) next to the SSL policy you want to configure.
The SSL policy editor appears.
Step 3 Select the Trusted CA Certificates tab.
The Trusted CA Certificates page appears.
Step 4 Find and select 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; see Working with Trusted Certificate Authority Objects,
page 2-41.
• 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.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 5 Click Add to Rule to add the selected objects to the Selected Trusted CAs list.
You can also drag and drop selected objects.
Step 6 Add or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Consider the following 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 module. Because Verified Authority revoked a certificate it previously issued, the
system administrator uploads the CRL that Verified Authority distributed.
The following graphic illustrates a certificate status rule condition checking for valid certificates, those
issued by Verified Authority, 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.
Note that even though a certificate may match more than one status, the rule only takes an action on the
traffic once.
Step 1 In the SSL policy where you want to control encrypted traffic based on server certificate status, create a
new SSL rule or edit an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Cert Status tab.
The Cert Status tab appears.
Step 3 For each certificate status, you have the following options:
• Select Yes to match against the presence of that certificate status.
• Select No to match against the absence of that certificate status.
• Select Do Not Match to not match that certificate status.
Step 4 Add or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
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.
Step 1 In the SSL policy where you want to control encrypted traffic by cipher suite, create a new SSL rule or
edit an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Cipher Suite tab.
The Cipher Suite tab appears.
Step 3 Find and select 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; see Working with Geolocation Objects, page 2-45.
• 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.
To select a cipher suite, click it. To select multiple cipher suites, use the Shift and Ctrl keys, or right-click
and then select Select All.
Step 4 Click Add to Rule to add the selected cipher suites to the Selected Cipher Suites list.
You can also drag and drop selected cipher suites.
Step 5 Add or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Session conditions in SSL rules allow you to inspect encrypted traffic based on the SSL or TLS version
used to encrypt the traffic. You can choose to match against traffic encrypted with SSL version 3.0, or
TLS version 1.0, 1.1, or 1.2. By default, all protocol versions are selected when you create a rule; if you
select multiple versions, encrypted traffic that matches any of the selected versions matches the rule. You
must select at least one protocol version when saving the rule condition.
Note You cannot select SSL v2.0 in a version rule condition; the ASA FirePOWER module does not support
decrypting traffic encrypted with SSL version 2.0. You can configure an undecryptable action to allow
or block this traffic without further inspection. For more information, see Logging Decryptable
Connections with SSL Rules, page 33-14.
Step 1 In the SSL policy where you want to control encrypted traffic by encryption protocol version, create a
new SSL rule or edit an existing rule.
For detailed instructions, see Understanding and Creating SSL Rules, page 13-4.
Step 2 In the SSL rule editor, select the Version tab.
The Version tab appears.
Step 3 Select the protocol versions you want to match against: SSL v3.0, TLS v1.0, TLS v1.1, or TLS v1.2.
Step 4 Add or continue editing the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect;
see Deploying Configuration Changes, page 4-10.
Network analysis and intrusion policies work together as part of the ASA FirePOWER module intrusion
detection and prevention feature. The term intrusion detection generally refers to the process of
passively analyzing network traffic for potential intrusions and storing attack data for security analysis.
The term intrusion prevention includes the concept of intrusion detection, but adds the ability to block
or alter malicious traffic as it travels across your network.
In an intrusion prevention deployment, when the system examines packets:
• A network analysis policy governs how traffic is decoded and preprocessed so that it can be further
evaluated, especially for anomalous traffic that might signal an intrusion attempt.
• An intrusion policy uses intrusion and preprocessor rules (sometimes referred to collectively as
intrusion rules) to examine the decoded packets for attacks based on patterns. Intrusion policies are
paired with variable sets, which allow you to use named values to accurately reflect your network
environment.
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 ASA FirePOWER module 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 Vulnerability
Research Team (VRT). For these policies, the VRT 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. You create, edit, save, and manage network
analysis and intrusion policies using similar policy editors. When you are editing either type of policy,
a navigation panel appears on the left side of the user interface; the right side displays various
configuration pages.
This chapter contains a brief overview of the types of configurations the network analysis and intrusion
policies govern, explains how the policies work together to examine traffic and generate records of
policy violations, and provides basic information on navigating the policy editors. This chapter also
explains the benefits and limitations of using custom versus system-provided policies. For more
information, see the following sections:
• Understanding How Policies Examine Traffic For Intrusions, page 15-2
The following diagram shows, in a simplified fashion, the order of traffic analysis in an inline, intrusion
prevention and advanced malware protection (AMP) deployment. It illustrates how the access control
policy invokes other policies to examine traffic, and in which order those policies are invoked. The
network analysis and intrusion policy selection phases are highlighted.
In an inline deployment, the system can block traffic without further inspection at almost any step in the
illustrated process. Security Intelligence, network analysis policies, file policies, and intrusion policies
can all either drop or modify 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.
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.
For more information, see:
• Decoding, Normalizing, and Preprocessing: Network Analysis Policies, page 15-3
• Access Control Rules: Intrusion Policy Selection, page 15-4
• Intrusion Inspection: Intrusion Policies, Rules, and Variable Sets, page 15-5
• Intrusion Event Generation, page 15-6
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. For more information,
see Understanding Packet Decoding, page 21-16.
• 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. For more information, see Normalizing
Inline Traffic, page 21-6.
• Various network and transport layers preprocessors detect attacks that exploit IP fragmentation,
perform checksum validation, and perform TCP and UDP session preprocessing; see Configuring
Transport & Network Layer Preprocessing, page 21-1.
Note that some advanced transport and network preprocessor settings apply globally to all traffic
handled by an access control policy. You configure these in the access control policy rather than in
a network analysis policy; see Configuring Advanced Transport/Network Settings, page 21-1.
• 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. For more information, see Using
Application Layer Preprocessors, page 19-1.
• 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. For more
information, see Configuring SCADA Preprocessing, page 20-1.
• Several preprocessors allow you to detect specific threats, such as Back Orifice, portscans, SYN
floods and other rate-based attacks; see Detecting Specific Threats, page 25-1.
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; see Detecting
Sensitive Data, page 25-19.
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 and networks by
assigning different custom network analysis policies to preprocess matching traffic. For more
information, see Comparing System-Provided with Custom Policies, page 15-7.
When you allow traffic with an access control rule, the system can inspect the traffic for malware,
prohibited files, and intrusions, in that order. Traffic not matching any access control rule is handled by
the access control policy’s default action, which can also inspect for intrusions.
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. For more information, see Limitations of Custom Policies, page 15-11.
The diagram in Understanding How Policies Examine Traffic For Intrusions, page 15-2 shows the flow
of traffic through a device in an inline, intrusion prevention and AMP deployment, as follows:
• The access control rule allows matching traffic to proceed. The traffic is then inspected for
prohibited files and malware by a file policy, and then for intrusions by an intrusion policy.
• In this scenario, the access control policy’s default action allows matching traffic. The traffic is then
inspected 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. For more information, see Using Rule Actions to Determine Traffic
Handling and Inspection, page 6-7 and Setting Default Handling and Inspection for Network Traffic,
page 4-4.
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.
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 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. For
more information, see Optimizing Predefined Default Variables, page 2-14.
• If the packet decoder (configured in the network analysis policy) receives an IP packet that is less
than 20 bytes, which is the size of an IP datagram without any options or payload, the decoder
interprets this as anomalous traffic. If, later, the accompanying decoder rule in the intrusion policy
that examines the packet is enabled, the system generates a preprocessor event.
• If the IP defragmentation preprocessor encounters a series of overlapping IP fragments, the
preprocessor interprets this as a possible attack and, when the accompanying preprocessor rule is
enabled, the system generates a preprocessor event.
• Within the intrusion rules engine, most standard text rules and shared object rules are written so that
they generate intrusion events when triggered by packets.
As the device 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.
• The policy uses default Security Intelligence options (global whitelist and blacklist only), 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 ASA FirePOWER module.
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.
For more information, see:
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; see Optimizing Predefined Default Variables, page 2-14.
As new vulnerabilities become known, the VRT 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 system marks affected intrusion and network analysis
policies as out of date, as well as their parent access control policies. You must reapply an updated policy
for its changes to take effect.
For your convenience, you can configure rule updates to automatically reapply 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 reapply access control policies, which also
reapplies any associated 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.
For more information, see Importing Rule Updates and Local Rule Files, page 43-10.
Cisco delivers the following network analysis and intrusion policies with the ASA FirePOWER module:
Caution Cisco uses another policy, Experimental Policy 1, for testing purposes. Do not use it unless instructed to
do so by a Cisco representative.
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;
see Setting the Default Network Analysis Policy for Access Control, page 17-3.
Tuning options available vary by preprocessor, but some of the ways you can tune preprocessors and
decoders include:
• You can disable preprocessors that do not apply to the traffic you are monitoring. For example, the
HTTP Inspect preprocessor normalizes HTTP traffic. If you are confident that your network does
not include any web servers using Microsoft Internet Information Services (IIS), you can disable the
preprocessor option that looks for IIS-specific traffic and thereby reduce system processing
overhead.
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 user 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
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 or networks.
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. For more information, see Limitations of Custom Policies, page 15-11.
• Within each intrusion policy, you should verify that all rules applicable to your environment are
enabled, and improve performance by disabling rules that are not applicable to your environment.
In an inline deployment, you can specify which rules should drop or modify malicious packets. For
more information, see Setting Rule States, page 24-19.
• You can modify existing rules and write new standard text rules as needed to catch new exploits or
to enforce your security policies; see Understanding and Writing Intrusion Rules, page 27-1.
Other customizations you might make to an intrusion policy include:
• The sensitive data preprocessor detects sensitive data such as credit card numbers and Social
Security numbers in ASCII text. Note that other preprocessors that detect specific threats (back
orifice attacks, several portscan types, and rate-based attacks that attempt to overwhelm your
network with excessive traffic) are configured in network analysis policies. For more information,
see Detecting Specific Threats, page 25-1.
• Global thresholds cause the system to generate events based on how many times traffic matching an
intrusion rule originates from or is targeted to a specific address or address range within a specified
time period. This helps prevent the system from being overwhelmed with a large number of events.
For more information, see Globally Limiting Intrusion Event Logging, page 26-1.
• Suppressing intrusion event notifications and setting thresholds for individual rules or entire
intrusion policies can also can prevent the system from being overwhelmed with a large number of
events. For more information, see Filtering Intrusion Event Notification Per Policy, page 24-20.
• In addition to intrusion events, you can enable logging to 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.
For more information, see Configuring External Alerting for Intrusion Rules, page 36-1.
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,
as summarized in Benefits of a Custom Network Analysis Policy, page 15-9. 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 user 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 and networks by
assigning custom network analysis policies to preprocess matching traffic. 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 ASA FirePOWER module, 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 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 navigation panel appears on the left side of the user interface when you are editing either type of
policy. The following graphic shows the navigation panel for the network analysis policy (left) and the
intrusion policy (right).
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.
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. For more information, see Using
Layers in a Network Analysis or Intrusion Policy, page 16-1.
Note After you save, you must apply a network analysis or intrusion policy for your changes to take effect. If
you apply a policy without saving, the system uses the most recently saved configuration. Although you
can reapply an intrusion policy independently, network analysis policies are applied with their parent
access control policy.
Larger organizations with many ASA FirePOWER modules 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. Optionally, 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.
See the following sections for more information:
• Understanding the Layer Stack, page 16-1 describes the user-configurable and built-in layers that
comprise a basic policy.
• Managing Layers, page 16-5 explains how to use layers in your policies.
Tip You can create an intrusion or network analysis policy based solely on the default settings in the base
policy.
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.
Step 1 While editing your policy, click Policy Information in the navigation panel.
The Policy Information page appears.
Step 2 Select a base policy from the Base Policy drop-down list.
Step 3 Optionally, if you choose a system-provided base policy, click Manage Base Policy to specify whether
intrusion rule updates can automatically modify your base policy.
For more information, see Allowing Rule Updates to Modify a System-Provided Base Policy, page 16-4.
Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
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.
See Changing the Base Policy, page 16-3 for more information.
Step 1 While editing a policy that uses a system-provided policy as its base policy, click Policy Information in the
navigation panel.
The Policy Information page appears.
Step 2 Click Manage Base Policy.
The Base Policy summary page appears.
Step 3 Select or clear the Update when a new Rule Update is installed check box.
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. Optionally, you can click Update Now to update your base policy with
the changes in the most recently imported rule update.
Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
Managing Layers
License: Protection
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 feature name in the summary for each layer indicates which configurations are enabled, disabled,
overridden, or inherited in the layer, as follows:
This 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 following table lists the actions available on the Policy Layers page.
Table 16-1 Network Analysis and Intrusion Policy Layer Configuration Actions
Step 1 While editing your policy, click Policy Layers in the navigation panel.
Adding a Layer
License: Protection
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.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 Click the add layer icon ( ) next to User Layers.
The Add Layer pop-up window appears.
Step 3 Type a unique layer Name and click OK.
The new layer appears as the topmost layer under User Layers.
Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 Click the edit icon ( ) next to the user layer you want to edit.
The summary page for the layer appears.
Step 3 You can take the following actions:
• Modify the layer Name.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 You can take the following actions:
• To copy a layer, click the copy icon ( ) for the layer you want to copy.
The page refreshes and a copy of the layer appears as the highest layer.
• To move a layer up or down within the User Layers page area, 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.
The screen refreshes and the layer appears in the new location.
• To delete a layer, click the delete icon ( ) for the layer you want to delete, then click OK
The page refreshes and the layer is deleted.
Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
Merging Layers
License: Protection
You can merge a user-configurable layer in your network analysis or intrusion policy with the next user
layer 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 shared layer that you add to other policies, you can merge an unshared
layer immediately above the shared layer with the shared layer, but you cannot merge the shared 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.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 Click the merge icon ( ) in the upper of the two layers, then click OK.
The page refreshes and the layer is merged with the layer beneath it.
Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
The master policy in the figure includes a company-wide layer with settings applicable to the policies at
Site A and Site B. It also includes site-specific layers for each policy. 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, or by network. In the case of an intrusion policy, you could also include advanced settings
in one layer and rule settings in another.
Tip 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. When you attempt to save your changes, an error message indicates that the
policy includes a circular dependency. See Understanding Custom Base Policies, page 16-3 for more
information.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 Click the edit icon ( ) next to the layer you want to share with other policies.
The summary page for the layer appears.
Step 3 Select (enable) or clear (disable) the Sharing check box.
Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
Step 1 While editing your policy, click Policy Layers in the navigation panel.
The Policy Layers page appears.
Step 2 Click the add shared layer icon ( ) next to User Layers.
The Add Shared Layer pop-up window appears.
Step 3 Select the shared layer you want to add from the Add Shared Layer drop-down list, then click OK.
The Policy Layers summary page appears and the shared layer you selected appears as the highest layer
in your policy.
If there are no shared layers in any other policies, no drop-down list appears; click OK or Cancel on the
pop-up window to return to the Policy Layers summary page.
Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
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.
Step 1 While editing your intrusion policy, expand Policy Layers in the navigation panel and expand the policy
layer you want to modify.
Step 2 Click Rules immediately beneath the policy layer you want to modify.
The Rules page for the layer appears.
You can modify any of the settings in the Layer Rule Settings table. See Tuning Intrusion Policies Using
Rules, page 24-1 for more information on configuring intrusion rules.
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 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
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. See Setting Rule
States, page 24-19 for more information.
Step 1 While editing your intrusion policy, click Rules immediately beneath Policy Information in the
navigation panel.
Tip You can also select Policy from the layer drop-down list on the Rules page for any layer, or select Manage
Rules on the Policy Information page.
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
See Understanding Rule Filtering in an Intrusion Policy, page 24-9 and Setting a Rule Filter in an
Intrusion Policy, page 24-17 for information on locating rules.
Step 3 You have the following options:
• To remove all thresholds for a rule, select Event Filtering > Remove Thresholds.
• To remove all suppression for a rule, select Event Filtering > Remove Suppressions.
• To remove all rate-based rule states for a rule, select Dynamic State > Remove Rate-Based Rule States.
• To remove all SNMP alert settings for a rule, select Alerting > Remove SNMP Alerts.
A confirmation pop-up window appears.
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. See Setting Rule
States, page 24-19 for more information.
To accept rule changes in a policy where you have not added layers:
Step 1 While editing your intrusion policy, expand the Policy Layers link in the navigation panel, then expand
the My Changes link.
Step 2 Click the Rules link immediately beneath My Changes.
The Rules page for the My Changes layer appears.
Step 3 Select the rule or rules whose settings you want to accept. You have the following options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
See Understanding Rule Filtering in an Intrusion Policy, page 24-9 and Setting a Rule Filter in an
Intrusion Policy, page 24-17 for information on locating rules.
Step 4 Select Inherit from the Rule State drop-down list.
Step 5 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
Step 1 While editing your policy, expand Policy Layers in the navigation panel, then click the name of the layer
you want to modify.
The summary page for the layer appears.
Step 2 You can take any of the actions in the Layer Summary Page Actions table.
Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. For more information, see
Resolving Conflicts and Committing Policy Changes, page 15-15.
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.
This chapter explains how to set the following preferences:
• Setting the Default Intrusion Policy for Access Control, page 17-1 explains how to change the
access control policy’s default intrusion policy, which is used to initially inspect traffic before the
system can determine exactly how to inspect that traffic
• Customizing Preprocessing with Network Analysis Policies, page 17-2 explains how to tailor
certain traffic preprocessing options to specific security zones, and networks by assigning custom
network analysis policies to preprocess matching traffic.
Other chapters describe policy-wide preprocessing and performance options for access control policies.
For more information, see:
• Configuring Advanced Transport/Network Settings, page 21-1
• Tuning Preprocessing in Passive Deployments, page 22-1
• Tuning Intrusion Prevention Performance, page 10-6
• Tuning File and Malware Inspection Performance and Storage, page 10-16
The system inspects these allowed packets with the default intrusion policy, which can generate events
and, if placed inline, block malicious traffic. After the system identifies the access control rule or default
action 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 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, keep the No Rules Active policy as your default intrusion
policy. For more information, see ASA FirePOWER module Applying includesASA FirePOWER
module a orYou might be able to select as few as three intrusion policies across an entire access control
policy. Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA
FirePOWER Monitoring > Task Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER
ChangesConfiguration > ASA FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task
Status)Troubleshooting Access Control Policies and Rules, page 4-11.
Note that 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.
Step 1 In the access control policy where you want to change the default intrusion policy, select the Advanced
tab, then click the edit icon ( ) next to the Network Analysis and Intrusion Policies section.
The Network and Analysis Policies dialog box appears.
Step 2 From the Intrusion Policy used before Access Control rule is determined drop-down list, select a default
intrusion policy. You can choose a system- or user-created policy.
Note that 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.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
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;
see Creating a Custom Network Analysis Policy, page 18-2. Tuning options available vary by
preprocessor.
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 or networks.
To accomplish this, you add custom network analysis rules to your access control 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 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. For more information, see Limitations of
Custom Policies, page 15-11.
By default, the system-provided Balanced Security and Connectivity network analysis policy applies to
all traffic handled by an access control policy. If you add network analysis rules to tailor traffic
preprocessing options, the default network analysis policy preprocesses all traffic not handled by those
rules.
An access control policy’s advanced settings allow you to change this default policy.
Step 1 In the access control policy where you want to change the default network analysis policy, select the
Advanced tab, then click the edit icon ( ) next to the Network Analysis and Intrusion Policies section.
The Network and Analysis Policies dialog box appears.
Step 2 From the Default Network Analysis Policy drop-down list, select a default network analysis policy. You can
choose a system- or user-created policy.
Note that 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.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
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.
Step 1 In the access control policy where you want to create custom preprocessing configurations, select the
Advanced tab, then click the edit icon ( ) next to the Intrusion and Network Analysis Policies section.
The Network and Analysis Policies dialog box appears. If you have not added any custom network
analysis rules, the module interface indicates that you have No Custom Rules, otherwise it displays how
many you have configured.
Tip Click Network Analysis Policy List to display the Network Analysis Policy page in a new window. Use this
page to view and edit your custom network analysis policies; see Managing Network Analysis Policies,
page 18-3
Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.
The dialog box expands to show the custom rules, if any.
Step 3 Click Add Rule.
The network analysis rule editor appears.
Step 4 Build your rule’s conditions. You can restrict NAP preprocessing using the following criteria:
• Preprocessing Traffic Per Zone, page 17-5
• Preprocessing Traffic Per Network, page 17-6
Step 5 Associate a network analysis policy with the rule by clicking the Network Analysis tab and choosing a
policy from the Network Analysis Policy drop-down list.
The system uses the network analysis policy you choose to preprocess traffic that meets all the rule’s
conditions. Note that 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.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
You can add a maximum of 50 zones to each of the Source Zones and Destination Zones in a single zone
condition:
• To match traffic leaving the device from an interface in the zone, add that zone to Destination Zones.
Note that because devices deployed passively do not transmit traffic, you cannot use a zone
comprised of passive interfaces in a Destination Zone condition.
• To match traffic entering the device from an interface in the zone, add that zone to 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.
Warning icons ( ) indicate invalid configurations, such as zones that contain no interfaces. For details,
see ASA FirePOWER module Applying includesASA FirePOWER module a orYou might be able to
select as few as three intrusion policies across an entire access control policy. Configuration > ASA
FirePOWER Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring > Task
Status) Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to preprocess traffic by zone, create a new network analysis
rule or edit an existing rule.
For detailed instructions, see Specifying Traffic to Preprocess Using Network Analysis Rules,
page 17-4.
Step 2 In the network analysis rule editor, select the Zones tab.
The Zones tab appears.
Step 3 Find and select the zones you want to add from the Available Zones.
To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone
name. The list updates as you type to display matching zones.
Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select
Select All.
Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.
You can also drag and drop selected zones.
Step 5 Save or continue editing the rule.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Tip After you create a network object, you can use it not only to build network analysis rules, but also to
represent IP addresses in various other places in the system’s module interface. You can create these
objects using the object manager; you can also create network objects on-the-fly while you are
configuring network analysis rules. For more information, see Working with Network Objects, page 2-3.
You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single
network condition:
• To match traffic from an IP address, configure Source Networks.
• To match traffic to an IP address, configure Destination Networks.
If you add both source and destination network conditions to a rule, matching 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, see
ASA FirePOWER module Applying includesASA FirePOWER module a orYou might be able to select
as few as three intrusion policies across an entire access control policy. Configuration > ASA FirePOWER
Configuration > Policy Apply ASA FirePOWER Changes (Monitoring > ASA FirePOWER Monitoring > Task Status)
Configuration > ASA FirePOWER Configuration > Policy Apply ASA FirePOWER ChangesConfiguration > ASA
FirePOWER Configuration > Policy (Monitoring > ASA FirePOWER Monitoring > Task Status)Troubleshooting
Access Control Policies and Rules, page 4-11.
Step 1 In the access control policy where you want to preprocess traffic by network, create a new network
analysis rule or edit an existing rule.
For detailed instructions, see Specifying Traffic to Preprocess Using Network Analysis Rules,
page 17-4.
Step 2 In the network analysis rule editor, select the Networks tab.
The Networks tab appears.
Step 3 Find and select the networks you want to add from the Available Networks, as follows:
• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list; see Working with Network Objects, page 2-3.
• To search for networks to add, click the Search by name or value prompt above the Available Networks
list, then type an object name or the value of one of the object’s components. The list updates as you
type to display matching objects.
To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then
select Select All.
Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.
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.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Step 1 In the access control policy where you want to change your custom preprocessing configurations, select
the Advanced tab, then click the edit icon ( ) next to the Intrusion and Network Analysis Policies
section.
The Network and Analysis Policies dialog box appears. If you have not added any custom network
analysis rules, the module interface indicates that you have No Custom Rules; otherwise, it displays how
many you have configured.
Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.
The dialog box expands to show the custom rules, if any.
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.
Step 4 Click OK to save your changes.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Network analysis policies govern many traffic preprocessing options, and are invoked by advanced
settings in your access control policy. Network analysis-related preprocessing occurs after Security
Intelligence blacklisting, but before access control rules inspect packets in detail, and before any
intrusion or file inspection begins.
By default, the system uses the Balanced Security and Connectivity network analysis policy to
preprocess all traffic handled by an access control policy. However, you can choose a different default
network analysis policy to perform this preprocessing. For your convenience, the system provides a
choice of several non-modifiable network analysis policies, which are tuned for a specific balance of
security and connectivity by the Vulnerability Research Team (VRT). You can also replace this default
policy with a custom network analysis policy with custom preprocessing settings.
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. Understanding Network Analysis and Intrusion Policies,
page 15-1 provides an overview of how network analysis and intrusion policies work together to examine
your traffic, as well as some basics on using the navigation panel, resolving conflicts, and committing
changes.
You can also tailor traffic preprocessing options to specific security zones, and networks by creating
multiple custom network analysis policies, then assigning them to preprocess different traffic.
Note 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. The system does not
coordinate the policies for you, and uses default options in cases of misconfiguration. For more
information, see Limitations of Custom Policies, page 15-11.
This chapter explains how to create a simple custom network analysis policy. This chapter also contains
basic information on managing network analysis policies: editing, comparing, and so on. For more
information, see:
• Creating a Custom Network Analysis Policy, page 18-2
• Managing Network Analysis Policies, page 18-3
• Allowing Preprocessors to Affect Traffic in Inline Deployments, page 18-5
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click Create Policy.
If you have unsaved changes in another policy, click Cancel when prompted to return to the Network
Analysis Policy page. See Resolving Conflicts and Committing Policy Changes, page 15-15 for
information on saving unsaved changes in another policy.
The Create Network Analysis Policy pop-up window appears.
Step 7 Give the policy a unique Name and, optionally, a Description.
Step 8 Specify the initial Base Policy.
You can either use either a system-provided or custom policy as your base policy.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
Step 9 Specify whether you want to allow preprocessors to affect traffic in an inline deployment:
When you create a new network analysis policy, it has the same settings as its base policy. The following
table lists the most common actions you can take to tailor the new policy to your needs:
When tailoring a network analysis policy, especially when disabling preprocessors, keep in mind that
some 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 module interface.
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. For more information, see
Limitations of Custom Policies, page 15-11.
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. In addition to the actions you can perform in the table above, Understanding Network Analysis
and Intrusion Policies, page 15-1 provides information on using the navigation panel, resolving
conflicts, and committing changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
Tip 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 you configure adaptive profiles.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Preprocessors prepare traffic to be further inspected by normalizing traffic and identifying protocol
anomalies. Preprocessors generate preprocessor event when packets trigger preprocessor options that
you configure. The base policy for your network analysis policy determines which preprocessors are
enabled by default and the default configuration for each.
When you select Settings in the navigation panel of a network analysis policy, the policy lists its
preprocessors by type. On the Settings page, you can enable or disable preprocessors in your network
analysis policy, as well as access preprocessor configuration pages.
A preprocessor must be enabled for you to configure it. When you enable a preprocessor, a sublink to
the configuration page for the preprocessor appears beneath the Settings link in the navigation panel, and
an Edit link to the configuration page appears next to the preprocessor on the Settings page.
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 module interface.
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. For more
information, see Limitations of Custom Policies, page 15-11.
Modifying a preprocessor configuration requires an understanding of the configuration and its potential
impact on your network. The following sections provide links to specific configuration details for each
preprocessor.
SCADA Preprocessors
The Modbus and DNP3 preprocessors detect traffic anomalies and provide data to the intrusion rules
engine for inspection.
Note that some advanced transport and network preprocessor settings apply globally to all networks and
zones where you apply your access control policy. You configure these advanced settings in an access
control policy rather than in a network analysis policy; see Configuring Advanced Transport/Network
Settings, page 21-1.
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. For more information, see
Detecting Sensitive Data, page 25-19.
Section Description
Policy Information Provides the name and description of the policy, the name of the user who last
modified the policy, and the date and time the policy was last modified. Also
indicates whether inline normalization can be enabled, the current rule update
version, and whether the base policy is locked to the current rule update.
Settings Lists all enabled preprocessor settings and their configurations.
You can also generate a comparison report that compares two network analysis policies, or two revisions
of the same policy. For more information, see Comparing Two Network Analysis Policies or Revisions,
page 18-9.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the report icon ( ) next to the policy for which you want to generate a report. Remember to
commit any changes before you generate a network analysis policy report; only committed changes
appear in the report.
The system generates the report. You are prompted to save the report to your computer.
Tip You can use a similar procedure to compare access control, intrusion, or file policies.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click Compare Policies.
The Select Comparison window appears.
Step 7 From the Compare Against drop-down list, select the type of comparison you want to make:
• To compare two different policies, select Other Policy.
The page refreshes and the Policy A and Policy B drop-down lists appear.
• To compare two revisions of the same policy, select Other Revision.
The page refreshes and the Policy, Revision A, and Revision B drop-down lists appear.
Step 8 Depending on the comparison type you selected, you have the following choices:
• If you are comparing two different policies, select the policies you want to compare from the Policy
A and Policy B drop-down lists.
• If you are comparing two revision of the same policy, select the Policy, then select the timestamped
revisions you want to compare from the Revision A and Revision B drop-down lists.
Step 9 Click OK to display the policy comparison view.
The comparison view appears.
Step 10 Optionally, click Comparison Report to generate the network analysis policy comparison report.
The network analysis policy comparison report appears. You are prompted to save the report to your
computer.
You configure application layer preprocessors in a network analysis policy, which prepares traffic for
inspection using the rules enabled in an intrusion policy. See Understanding Network Analysis and
Intrusion Policies, page 15-1 for more information.
Application-layer protocols can represent the same data in a variety of ways. Cisco provides application
layer protocol decoders that normalize specific types of packet data into formats that the intrusion rules
engine can analyze. Normalizing application-layer protocol encodings allows the rules engine to
effectively apply the same content-related rules to packets whose data is represented differently and
obtain meaningful results.
Note that preprocessors do not generate events in most cases unless you enable the accompanying
preprocessor rules in an intrusion policy. See Setting Rule States, page 24-19 for more information.
See the following sections for more information:
• Decoding DCE/RPC Traffic, page 19-2 describes the DCE/RPC preprocessor and explains how to
configure it to prevent evasion attempts and detect anomalies in DCE/RPC traffic.
• Detecting Exploits in DNS Name Server Responses, page 19-14 describes the DNS preprocessor
and explains how to configure it to detect any of three specific exploits in DNS name server
responses.
• Decoding FTP and Telnet Traffic, page 19-18 describes the FTP/Telnet decoder and explains how to
configure it to normalize and decode FTP and Telnet traffic.
• Decoding HTTP Traffic, page 19-31 describes the HTTP decoder and explains how to configure it
to normalize HTTP traffic.
• Using the Sun RPC Preprocessor, page 19-46 describes the RPC decoder and explains how to
configure it to normalize RPC traffic.
• Decoding the Session Initiation Protocol, page 19-48 explains how you can use the SIP preprocessor
to decode and detect anomalies in SIP traffic.
• Configuring the GTP Command Channel, page 19-52 explains how you can use the GTP
preprocessor to provide the rules engine with GTP command channel messages extracted by the
packet decoder.
• Decoding IMAP Traffic, page 19-54 explains how you can use the IMAP preprocessor to decode and
detect anomalies in IMAP traffic.
• Decoding POP Traffic, page 19-57 explains how you can use the POP preprocessor to decode and
detect anomalies in POP traffic.
• Decoding SMTP Traffic, page 19-60 describes the SMTP decoder and explains how to configure it
to decode and normalize SMTP traffic.
• Detecting Exploits Using the SSH Preprocessor, page 19-67 explains how to identify and process
exploits in SSH-encrypted traffic.
• Using the SSL Preprocessor, page 19-71 explains how you can use the SSL preprocessor to identify
encrypted traffic and eliminate false positives by stopping inspection of that traffic.
• Configuring SCADA Preprocessing, page 20-1 explains how you can use the Modbus and DNP3
preprocessors to detect anomalies in corresponding traffic and provide data to the intrusion rules
engine for inspection of certain protocol fields.
Reassembly Threshold
When Enable Defragmentation is selected, 0 disables this option, or 1 to 65535 bytes 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.
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.
session only. See Understanding Target-Based DCE/RPC Server Policies, page 19-4 for more
information.
For example, if you set Policy to Windows XP and the preprocessor detects Windows Vista, the
preprocessor uses a Windows Vista policy for that session. Other settings remain in effect.
When the DCE/RPC transport is not SMB (that is, when the transport is TCP or UDP), the version
cannot be detected and the policy cannot be automatically configured.
To enable this option, select one of the following from the drop-down list:
– Select Client to inspect server-to-client traffic for the policy type.
– Select Server to inspect client-to-server traffic for the policy type.
– Select Both to inspect server-to-client and client-to-server traffic for the policy type.
• 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.
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.
See Auto-Detect Policy on SMB Session, page 19-4.
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. See Creating a File Policy, page 32-9 and Working
with File Rules, page 32-9 for more information.
Because SMB has many functions other than transporting DCE/RPC, the preprocessor first tests
whether the SMB traffic is carrying DCE/RPC traffic, stops processing if it is not, and continues
processing if it is.
• IP encapsulates all DCE/RPC transports.
• TCP transports all connection-oriented DCE/RPC.
• UDP transports connectionless DCE/RPC.
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 select 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 select 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.
Networks
The host IP addresses where you want to apply the DCE/RPC target-based server policy.
You can specify a single IP address or address block, or a comma-separated list of either or both.
You can specify up to 255 total profiles including the default policy. For information on specifying
IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions,
page 1-4.
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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
Policy
The Windows or Samba DCE/RPC implementation used by the targeted host or hosts on your
monitored network segment. See Understanding Target-Based DCE/RPC Server Policies, page 19-4
for detailed information on these policies.
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. See
Auto-Detect Policy on SMB Session, page 19-4.
Note Only someone who is expert in the SMB protocol should modify the default setting for this
option.
You can enable rule 133:20 to generate events for this option. See Setting Rule States, page 24-19
for more information.
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.
– files transferred in an established TCP or SMB session before this option is enabled and the
policy applied
– files transferred concurrently in a single TCP or SMB session
– files transferred across multiple TCP or SMB sessions
– files transferred with non-contiguous data, such as when message signing is negotiated
– files transferred with different data at the same offset, overlapping the data
– files opened on a remote client for editing that the client saves to the file server
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether DCE/RPC Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The DCE/RPC Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 You can modify any of the options described in Selecting Global DCE/RPC Options, page 19-3.
Step 10 You have two options:
• Add a new target-based policy. Click the add icon ( ) next to Servers on the left side of the page.
The Add Target pop-up window appears. Specify a one or more IP addresses in the Server Address
field and click OK.
You can specify a single IP address or address block, or a comma-separated list of either or both.
For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP
Address Conventions, page 1-4.
You can configure up to 255 policies, including the default policy.
Note that for a target-based policy to process traffic, the networks you identify must match or be a
subset of the networks, and zones handled by the network analysis policy where you configure the
target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3 for
more information.
A new entry appears in the list of servers on the left side of the page, highlighted to indicate that it
is selected, and the Configuration section updates to reflect the current configuration for the profile
you added.
• Modify the settings for an existing target-based policy. Click the configured address for a policy you
have added under Servers on the left side of the page, or click default.
Your selection is highlighted and the Configuration section updates to display the current
configuration for the policy you selected. To delete an existing policy, click the delete icon ( )
next to the policy you want to remove.
Step 11 You can modify any of the following target-based policy options:
• To specify the host or hosts where you want to apply the DCE/RPC target-based server policy, enter
a single IP address or address block, or a comma-separated list of either or both in the Networks field.
You can specify up to 255 total profiles including the default policy. Note that you cannot modify
the setting for Networks in the default policy. The default policy applies to all servers on your
network that are not identified in another policy.
• To specify the type of policy you want to apply to the specified host or hosts on your network
segment, select one of the Windows or Samba policy types from the Policy drop-down list.
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. See
Auto-Detect Policy on SMB Session, page 19-4.
• To set the preprocessor to detect when there is an attempt to connect to specified shared SMB
resources, enter a single or comma-separated list of the case-insensitive strings that identify the
shared resources in the SMB Invalid Shares field. Optionally, enclose individual strings in quotes,
which was required in previous software versions but is no longer required.
For example, to detect shared resources named C$, D$, admin, and private, you could enter:
"C$", D$, "admin", private
Note that to detect SMB invalid shares, you must also enable SMB Ports or SMB Auto-Detect Ports, and
enable the global SMB Traffics option.
Note also that in most cases you should append a dollar sign to a drive named by Windows that you
identify as an invalid share. For example, you would enter C$ or "C$" to identify drive C.
• To inspect files detected in DCE/RPC traffic in SMB without analyzing the DCE/RPC traffic, from
the SMB File Inspection drop-down list, select Only. To inspect files detected in DCE/RPC traffic in
SMB as well as the DCE/RPC traffic, from the SMB File Inspection drop-down list, select On. Enter a
number of bytes to inspect in a detected file in the SMB File Inspection Depth field. Enter 0 to inspect
detected files in their entirety.
• To specify a maximum number of chained SMB AndX commands to permit, enter 0 to 255 in the
SMB Maximum AndX Chains field. Specify 1 to permit no chained commands. Specify 0 or leave this
option blank to disable this feature.
Note Only someone who is expert in the SMB protocol should modify the setting for the SMB
Maximum AndX Chains option.
• To enable the processing of DCE/RPC traffic over ports known to carry DCE/RPC traffic for a
Windows policy transport, select or clear the check box next to a detection transport and, optionally,
add or delete ports for the transport.
Select one or any combination of RPC over HTTP Proxy Ports, RPC over HTTP Server Ports, TCP Ports, and
UDP Ports for a Windows policy. Select RPC Proxy Traffic Only when RPC over HTTP proxy is enabled and
detected client-side RPC over HTTP traffic is proxy traffic only; that is, when it does not include
other web server traffic.
Select SMB Ports for a Samba policy.
In most cases, use the default settings. See Understanding DCE/RPC Transports, page 19-5,
Understanding the RPC over HTTP Transport, page 19-7, and Selecting DCE/RPC Target-Based
Policy Options, page 19-8 for more information.
You can type a single port, a range of port numbers separated by a dash (-), or a comma-separated
list of port numbers and ranges.
• To test whether specified ports carry DCE/RPC traffic and continue processing when they do, select
or clear the check box next to an auto-detection transport and, optionally, add or delete ports for the
transport.
Select one or any combination of RPC over HTTP Server Auto-Detect Ports, TCP Auto-Detect Ports, and UDP
Auto-Detect Ports for a Windows policy.
Note that you would rarely, if ever, select RPC over HTTP Proxy Auto-Detect Ports or SMB Auto-Detect
Ports.
Typically, specify a port range from 1025 to 65535 for auto-detection ports that you enable to cover
the entire range of ephemeral ports. See Understanding DCE/RPC Transports, page 19-5,
Understanding the RPC over HTTP Transport, page 19-7, and Selecting DCE/RPC Target-Based
Policy Options, page 19-8 for more information.
See Selecting DCE/RPC Target-Based Policy Options, page 19-8 for more information.
Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
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 differs 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.
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.
this vulnerability and take complete control of a host by sending or otherwise causing the host to receive
a maliciously crafted name server response that causes a miscalculation in the length of an RData text
field, resulting in a buffer overflow.
You should enable this feature when your network might include hosts running operating systems that
have not been upgraded to correct this vulnerability.
You can enable rule 131:3 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
You can enable rule 131:1 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
You can enable rule 131:2 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether DNS Configuration under Application Layer Preprocessors
is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The DNS Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 Optionally, you can modify any of the following in the Settings area:
• Specify the source port or ports the DNS preprocessor should monitor for DNS server responses in
the Ports field. Separate multiple ports with commas.
• Select the Detect Overflow Attempts on RData Text fields check box to enable detection of buffer overflow
attempts in RData text fields.
• Select the Detect Obsolete DNS RR Types check box to enable detection of obsolete resource record
types.
• Select the Detect Experimental DNS RR Types check box to detect experimental resource record types.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Stateful Inspection
When selected, causes the FTP/Telnet decoder to save state and provide session context for
individual packets and only inspects reassembled sessions. When cleared, analyzes each individual
packet without session context.
To check for FTP data transfers, this option must be selected.
You can enable rules 125:7 and 126:2 to generate events for this option. See Setting Rule States,
page 24-19 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
The Advanced Settings page appears.
Step 8 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The FTP and Telnet Configuration page appears.
A message at the bottom of the page identifies the network analysis policy layer that contains the
configuration. See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more
information.
Tip For more information on configuring the other options on this page, see Configuring Telnet Options,
page 19-21, Configuring Server-Level FTP Options, page 19-25, and Configuring Client-Level FTP
Options, page 19-29.
Step 9 Optionally, you can modify any of the following in the Global Settings page area:
• Select Stateful Inspection to examine reassembled TCP streams containing FTP packets. Clear Stateful
Inspection to inspect only unreassembled packets.
• Select Detect Encrypted Traffic to detect encrypted traffic. Clear Detect Encrypted Traffic to ignore
encrypted traffic.
• If needed, select Continue to Inspect Encrypted Data to continue checking a stream after it becomes
encrypted, in case it becomes decrypted again and can be processed.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Ports
Indicates the ports whose telnet traffic you want to normalize. In the interface, list multiple ports
separated by commas.
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 when this anomaly is detected in Telnet traffic, and
rule 125:9 when it is detected on the FTP command channel. See Setting Rule States, page 24-19
for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The FTP and Telnet Configuration page appears.
A message at the bottom of the page identifies the network analysis policy layer that contains the
configuration. See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more
information.
Tip For more information on configuring the other options on this page, see Configuring Global FTP/Telnet
Options, page 19-19, Configuring Server-Level FTP Options, page 19-25, and Configuring Client-Level
FTP Options, page 19-29.
Step 9 Optionally, you can modify any of the following in the Telnet Settings page area:
• Specify the port or ports where telnet traffic should be decoded in the Ports field. Telnet typically
connects to TCP port 23. Separate multiple ports with commas.
Caution Because encrypted traffic (SSL) cannot be decoded, adding port 22 (SSH) could yield unexpected
results.
• Select or clear the Normalize Telnet Protocol Options check box to enable or disable telnet
normalization.
• Select or clear the Detect Anomalies Telnet Protocol Options check box to enable or disable anomaly
detection.
• Specify an Are You There Attack Threshold Number of consecutive AYT commands to permit.
Tip Cisco recommends that you set the AYT threshold to a value no higher than the default value.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Networks
Use this option to specify one or more IP addresses of FTP servers.
You can specify a single IP address or address block, or a comma-separated list comprised of either
or both. You can configure up to 1024 characters, and you can specify up to 255 profiles including
the default profile. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER
module, see IP Address Conventions, page 1-4.
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 address block 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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
Ports
Use this option to specify the ports on the FTP server where the device should monitor traffic. In the
interface, list multiple ports separated by commas.
Command Validity
Use this option to enter a valid format for a specific command. See Creating FTP Command
Parameter Validation Statements, page 19-24 for information on creating FTP command parameter
validation statements to validate the syntax of a parameter received as part of an FTP
communication. Click Add to add a command validation line.
You can enable rules 125:2 and 125:4 to generate events for this option. See Setting Rule States,
page 24-19 for more information.
Caution Changing the setting for this troubleshooting option affects performance and should be done only with
Support guidance.
You can combine the syntax in the table above as needed to create parameter validation statements that
correctly validate each FTP command where you need to validate traffic.
Note When you include a complex expression in a TYPE command, surround it by spaces. Also, surround
each operand within the expression by spaces. For example, type char A | B , not char A|B.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The FTP and Telnet Configuration page appears.
A message at the bottom of the page identifies the network analysis policy layer that contains the
configuration. See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more
information.
Tip For more information on configuring the other options on this page, see Configuring Global FTP/Telnet
Options, page 19-19, Configuring Telnet Options, page 19-21, and Configuring Client-Level FTP
Options, page 19-29.
• Specify any Ports that should be monitored for FTP traffic. Port 21 is the well-known port for FTP
traffic.
• Update the FTP commands used to transfer files from server to client in the File Get Commands field.
• Update the FTP commands used to transfer files from client to server in the File Put Commands field.
Note Do not change the values in the File Get Commands and File Put Commands field unless directed to
do so by Support.
• To detect additional FTP commands outside of those checked by default by the FTP/Telnet
preprocessor, type the commands, separated by spaces in the Additional FTP Commands field.
You can add as many additional FTP commands as needed.
Note Additional commands you may want to add include XPWD, XCWD, XCUP, XMKD, and XRMD. For more
information on these commands, see RFC 775, the Directory oriented FTP commands
specification by the Network Working Group.
• Specify the default maximum number of bytes for a command parameter in the Default Max Parameter
Length field.
• To detect a different maximum parameter length for particular commands, click Add next to Alternate
Max Parameter Length. In the first text box of the row that appears, specify the maximum parameter
length. In the second text box, specify the commands, separated by spaces, where this alternate
maximum parameter length should apply.
You can add as many alternative maximum parameter lengths as needed.
• To check for string format attacks on particular commands, specify the commands, separated by
spaces, in the Check Commands for String Format Attacks text box.
• To specify the valid format for a command, click Add next to Command Validity. Specify the command
you want to validate, then type a validation statement for the command parameter. For more
information on the validation statement syntax, see Understanding Server-Level FTP Options,
page 19-22.
• To improve performance on FTP data transfers by disabling all inspection other than state inspection
on the data transfer channel, enable Ignore FTP Transfers.
Note To inspect data transfers, the global FTP/Telnet Stateful Inspection option must be selected. For
more information on setting global options, see Understanding Global FTP and Telnet Options,
page 19-18.
• To detect when telnet commands are used over the FTP command channel, select Detect Telnet Escape
Codes within FTP Commands.
• To ignore telnet character and line erase commands when normalizing FTP traffic, enable Ignore
Erase Commands during Normalization.
Step 11 Optionally, modify the related troubleshooting option only if asked to do so by Support; click the + sign
next to Troubleshooting Options to expand the troubleshooting options section.
Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Networks
Use this option to specify one or more IP addresses of FTP clients.
You can specify a single IP address or address block, or a comma-separated list comprised of either
or both. You can specify up to 1024 characters, and you can specify up to 255 profiles including the
default profile. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER
module, see IP Address Conventions, page 1-4.
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 address block 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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
You can enable rule 125:1 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The FTP and Telnet Configuration page appears.
Step 9 You have two options:
• Add a new client profile. Click the add icon ( ) next to FTP Client on the left side of the page. The
Add Target pop-up window appears. Specify one or more IP addresses for the client in the Client
Address field and click OK.
You can specify a single IP address or address block, or a comma-separated list of either or both.
You can specify up to 1024 characters, and you can configure up to 255 policies, including the
default policy. For information on using IPv4 and IPv6 address blocks in the ASA FirePOWER
module, see IP Address Conventions, page 1-4.
Note that for a target-based policy to process traffic, the networks you identify must match or be a
subset of the networks, and zones handled by the network analysis policy where you configure the
target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3 for
more information.
A new entry appears in the list of FTP clients on the left side of the page, highlighted to indicate that
it is selected, and the Configuration section updates to reflect the current configuration for the
profile you added.
• Modify the settings for an existing client profile. Click the configured address for a profile you have
added under FTP Client on the left side of the page, or click default.
Your selection is highlighted and the Configuration section updates to display the current
configuration for the profile you selected. To delete an existing profile, click the delete icon ( )
next to the profile you want to remove.
Step 10 Optionally, you can modify any of the following in the Configuration page area:
• Optionally, modify the address or addresses listed in the Networks field and click any other area of
the page.
The highlighted address updates on the left side of the page.
Note that you cannot modify the setting for Network in the default profile. The default profile applies
to all client hosts on your network that are not identified in another profile.
• Specify, in bytes, the maximum length of responses from the FTP client in the Max Response Length
field.
• To detect FTP bounce attacks, select Detect FTP Bounce attempts.
The FTP/Telnet decoder detects when an FTP PORT command is issued and the specified host does
not match the specified host of the client.
• To configure a list of additional hosts and ports where FTP PORT commands should not be treated
as FTP bounce attacks, specify each host (or network in CIDR format) followed by a colon (:) and
the port or port range in the Allow FTP Bounce to field. To enter a range of ports for a host, separate
the beginning port in the range and the final port in the range with a dash (-). You can enter multiple
hosts by separating the entries for the hosts with a comma.
For example, to permit FTP PORT commands directed to the host 192.168.1.1 at port 21 and
commands directed to the host 192.168.1.2 at any of the ports from 22 to 1024, type:
192.168.1.1:21, 192.168.1.2:22-1024
For information on using CIDR notation and prefix lengths in the ASA FirePOWER module, see IP
Address Conventions, page 1-4.
Note To specify multiple individual ports for a host, you must repeat the host IP address for each port
definition. For example, to specify the ports 22 and 25 on 192.168.1.1, type 192.168.1.1:22,
192.168.1.1:25.
• To detect when telnet commands are used over the FTP command channel, select Detect Telnet Escape
Codes within FTP Commands.
• To ignore telnet character and line erase commands when normalizing FTP traffic, select Ignore Erase
Commands During Normalization.
Step 11 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Note If you turn this option on, be make to list all ports that do receive HTTP traffic in a server
profile on the HTTP Configuration page. If you do not, and you enable this option and the
accompanying preprocessor rule, normal traffic to and from the server will generate events.
The default server profile contains all ports normally used for HTTP traffic, but if you
modified that profile, you may need to add those ports to another profile to prevent events
from being generated.
You can enable rule 120:1 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
You can configure detection of HTTP traffic to non-standard ports and on HTTP traffic using proxy
servers. For more information on global HTTP configuration options, see Selecting Global HTTP
Normalization Options, page 19-32.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether HTTP Configuration under Application Layer Preprocessors
is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The HTTP Configuration page appears.
Step 9 You can modify any of the global options described in Selecting Global HTTP Normalization Options,
page 19-32.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
You can set server-level options for each server you monitor, globally for all servers, or for a list of
servers. Additionally, you can use a predefined server profile to set these options, or you can set them
individually to meet the needs of your environment. Use these options, or one of the default profiles that
set these options, to specify the HTTP server ports whose traffic you want to normalize, the amount of
server response payload you want to normalize, and the types of encoding you want to normalize.
If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a
preprocessor rule.
Networks
Use this option to specify the IP address of one or more servers. You can specify a single IP address
or address block, or a comma-separated list comprised of either or both.
In addition to a limit of up to 255 total profiles, including the default profile, you can include up to
496 characters, or approximately 26 entries, in an HTTP server list, and specify a total of 256
address entries for all server profiles. For information on using IPv4 CIDR notation and IPv6 prefix
lengths in the ASA FirePOWER module, see IP Address Conventions, page 1-4.
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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
Ports
The ports whose HTTP traffic the preprocessor engine normalizes. Separate multiple port numbers
with commas.
You can enable rule 119:20 to generate events for this option. See Setting Rule States, page 24-19
for more information.
HTTP Methods
Specifies HTTP request methods in addition to GET and POST that you expect the system to
encounter in traffic. Use a comma to separate multiple values.
Intrusion rules use the content or protected_content keyword with the HTTP Method argument to
search for content in HTTP methods. See HTTP Content Options, page 27-23. You can enable rule
119:31 to generate events when a method other than GET, POST, or a method configured for this
option is encountered in traffic.
No Alerts
Disables intrusion events when accompanying preprocessor rules are enabled.
Note This option does not disable HTTP standard text rules and shared object rules.
is reached. Inspection of decompressed data ends when Server Flow Depth is reached unless you also
select Unlimited Decompression. You can use the file_data rule keyword to inspect decompressed
data; see Pointing to a Specific Payload Type, page 27-96 for more information.
Unlimited Decompression
When Inspect Compressed Data (and, optionally, Decompress SWF File (LZMA), Decompress SWF File
(Deflate), or Decompress PDF File (Deflate)) is enabled, overrides Maximum Decompressed Data Depth
across multiple packets; that is, this option enables unlimited decompression across multiple
packets. Note that enabling this option does not affect Maximum Compressed Data Depth or Maximum
Decompressed Data Depth within a single packet. Note also that enabling this option sets Maximum
Compressed Data Depth and Maximum Decompressed Data Depth to 65535 when you commit your
changes. See Selecting Global HTTP Normalization Options, page 19-32.
Normalize Javascript
When Inspect HTTP Responses is enabled, enables detection and normalization of Javascript within the
HTTP response body. The preprocessor normalizes obfuscated Javascript data such as the unescape
and decodeURI functions and the String.fromCharCode method. The preprocessor normalizes the
following encodings within the unescape, decodeURI, and decodeURIComponent functions:
– %XX
– %uXXXX
– 0xXX
– \xXX
– \uXXXX
The preprocessor detects consecutive white spaces and normalizes them into a single space. When
this option is enabled, a configuration field allows you to specify the maximum number of
consecutive white spaces to permit in obfuscated Javascript data. You can enter a value from 1 to
65535. The value 0 disables event generation, regardless of whether the preprocessor rule (120:10)
associated with this field is enabled.
The preprocessor also normalizes the Javascript plus (+) operator and concatenates strings using the
operator.
You can use the file_data keyword to point intrusion rules to the normalized Javascript data. See
Pointing to a Specific Payload Type, page 27-96 for more information.
You can enable rules 120:9, 120:10, and 120:11 to generate events for this option, as follows:
Note You can only decompress the compressed portions of files found in HTTP GET responses.
– Decompress SWF File (LZMA) decompresses the LZMA-compatible compressed portions of Adobe
ShockWave Flash (.swf) files
– Decompress SWF File (Deflate) decompresses the deflate-compatible compressed portions of
Adobe ShockWave Flash (.swf) files
Decompression ends when Maximum Compressed Data Depth, Maximum Decompressed Data Depth, or the
end of the compressed data is reached. Inspection of decompressed data ends when Server Flow Depth
is reached unless you also select Unlimited Decompression. You can use the file_data rule keyword
to inspect decompressed data; see Pointing to a Specific Payload Type, page 27-96 for more
information.
You can enable rules 120:12 and 120:13 to generate events for this option, as follows:
Note You can only decompress the compressed portions of files found in HTTP GET responses.
Decompression ends when Maximum Compressed Data Depth, Maximum Decompressed Data Depth, or the
end of the compressed data is reached. Inspection of decompressed data ends when Server Flow Depth
is reached unless you also select Unlimited Decompression. You can use the file_data rule keyword
to inspect decompressed data; see Pointing to a Specific Payload Type, page 27-96 for more
information.
You can enable rules 120:14, 120:15, 120:16, and 120:17 to generate events for this option, as
follows:
Log URI
Enables extraction of the raw URI, if present, from HTTP request packets and associates the URI
with all intrusion events generated for the session.
When this option is enabled, you can display the first fifty characters of the extracted URI in the
HTTP URI column of the intrusion events table view. You can display the complete URI, up to 2048
bytes, in the packet view. See Viewing Events, page 34-1 for more information.
Log Hostname
Enables extraction of the host name, if present, from the HTTP request Host header and associates
the host name with all intrusion events generated for the session. When multiple Host headers are
present, extracts the host name from the first header.
When this option is enabled, you can display the first fifty characters of the extracted host name in
the HTTP Hostname column of the intrusion events table view. You can display the complete host
name, up to 256 bytes, in the packet view. See Viewing Events, page 34-1 for more information.
You can enable rule 119:25 to generate events for this option. See Setting Rule States, page 24-19
for more information.
Note that when the preprocessor and rule 119:24 are enabled, the preprocessor generates an
intrusion event if it detects multiple Host headers in an HTTP request, regardless of the setting for
this option. See Enabling Additional HTTP Inspect Preprocessor Rules, page 19-45 for more
information.
Profile
Specifies the types of encoding that are normalized for HTTP traffic. The system provides a default
profile appropriate for most servers, default profiles for Apache servers and IIS servers, and custom
default settings that you can tailor to meet the needs of your monitored traffic. See Selecting
Server-Level HTTP Normalization Encoding Options, page 19-41 for more information.
ASCII Encoding
Decodes encoded ASCII characters and specifies whether the rules engine generates an event on
ASCII-encoded URIs.
You can enable rule 119:1 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
UTF-8 Encoding
Decodes standard UTF-8 Unicode sequences in the URI.
You can enable rule 119:6 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Microsoft %U Encoding
Decodes the IIS %u encoding scheme that uses %u followed by four characters where the 4
characters are a hex encoded value that correlates to an IIS Unicode codepoint.
Tip Legitimate clients rarely use %u encodings, so Cisco recommends decoding HTTP traffic encoded with
%u encodings.
You can enable rule 119:3 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Tip Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings
correctly. Cisco recommends enabling this option because no legitimate clients encode UTF-8 this way.
You can enable rule 119:4 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Tip Cisco recommends enabling this option, because it is seen mainly in attacks and evasion attempts.
You can enable rule 119:7 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Double Encoding
Decodes IIS double encoded traffic by making two passes through the request URI performing
decodes in each one. Cisco recommends enabling this option because it is usually found only in
attack scenarios.
You can enable rule 119:2 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Multi-Slash Obfuscation
Normalizes multiple slashes in a row into a single slash.
You can enable rule 119:8 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Directory Traversal
Normalizes directory traversals and self-referential directories. If you enable the accompanying
preprocessor rules to generate events against this type of traffic, it may generate false positives
because some web sites refer to files using directory traversals.
You can enable rules 119:10 and 119:11 to generate events for this option. See Setting Rule States,
page 24-19 for more information.
Tab Obfuscation
Normalizes the non-RFC standard of using a tab for a space delimiter. Apache and other non-IIS
web servers use the tab character (0x09) as a delimiter in URLs.
Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab
as white space if a space character (0x20) precedes it.
You can enable rule 119:12 to generate events for this option. See Setting Rule States, page 24-19
for more information.
Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab
as white space if a space character (0x20) precedes it.
Non-RFC characters
Detects the non-RFC character list you add in the corresponding field when it appears within
incoming or outgoing URI data. When modifying this field, use the hexadecimal format that
represents the byte character. If and when you configure this option, set the value with care. Using
a character that is very common may overwhelm you with events.
You can enable rule 119:14 to generate events for this option. See Setting Rule States, page 24-19
for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether HTTP Configuration under Application Layer Preprocessors
is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The HTTP Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 You have two options:
• Add a new server profile. Click the add icon ( ) next to Servers on the left side of the page. The
Add Target pop-up window appears. Specify one or more IP addresses for the client in the Server
Address field and click OK.
You can specify a single IP address or address block, or a comma-separated list of either or both.
You can include up to 496 characters in a list, specify a total of 256 address entries for all server
profiles, and create a total of 255 profiles including the default profile. For information on using
IPv4 and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions,
page 1-4.
Note that for a target-based policy to process traffic, the networks you identify must match or be a
subset of the networks, and zones handled by the network analysis policy where you configure the
target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3 for
more information.
A new entry appears in the list of servers on the left side of the page, highlighted to indicate that it
is selected, and the Configuration section updates to reflect the current configuration for the profile
you added.
• Modify the settings for an existing profile. Click the configured address for a profile you have added
under Servers on the left side of the page, or click default.
Your selection is highlighted and the Configuration section updates to display the current
configuration for the profile you selected. To delete an existing profile, click the delete icon ( )
next to the profile you want to remove.
Step 10 Optionally, modify the address or addresses listed in the Networks field and click any other area of the
page.
The highlighted address updates on the left side of the page.
Note that you cannot modify the setting for Networks in the default profile. The default profile applies to
all servers on your network that are not identified in another profile.
Step 11 In the Ports field, list the ports whose traffic you want to inspect with HTTP Inspect. Separate multiple
ports with commas.
Step 12 You can modify any of the other options described in Selecting Server-Level HTTP Normalization
Options, page 19-33.
Step 13 Select a server profile as follows:
• Select Custom to create your own server profile (see Selecting Server-Level HTTP Normalization
Encoding Options, page 19-41 for more information).
• Select All to use the standard default profile, appropriate for all servers.
• Select IIS to use the default IIS profile.
• Select Apache to use the default Apache profile.
Step 14 If you selected Custom, the custom options appear.
Step 15 Configure the HTTP decoding options you want in your profile.
See Selecting Server-Level HTTP Normalization Options, page 19-33 for details on available
normalization options.
Step 16 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Preprocessor Rule
GID:SID Description
120:5 Generates an event when UTF-7 encoding is encountered in HTTP response
traffic; UTF-7 should only appear where 7-bit parity is required, such as in SMTP
traffic.
119:21 Generates an event when an HTTP request header has more than one
content-length field.
119:24 Generates an event when an HTTP request has more than one Host header.
119:28 When enabled, these rules do not generate events.
120:8
Preprocessor Rule
GID:SID Description
119:32 Generates an event when HTTP version 0.9 is encountered in traffic. Note that the
TCP stream configuration must also be enabled. See Using TCP Stream
Preprocessing, page 21-20.
119:33 Generates an event when an HTTP URI includes an unescaped space.
119:34 Generates an event when a TCP connection contains 24 or more pipelined HTTP
requests.
Ports
Specify the ports whose traffic you want to normalize. In the interface, list multiple ports separated
by commas. Typical RPC ports are 111 and 32771. If your network sends RPC traffic to other ports,
consider adding them.
Detect single fragment records which exceed the size of one packet
Detects partial records
You can enable rule 106:4 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether Sun RPC Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Sun RPC Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 In the Ports field, type the port numbers where you want to decode RPC traffic. Separate multiple ports
with commas.
Step 10 You can select or clear any of the following detection options on the Sun RPC Configuration page:
• Detect fragmented RPC records
• Detect multiple records in one packet
• Detect fragmented record sums which exceed one packet
• Detect single fragment records which exceed the size of one packet
Step 11 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Ports
Specifies the ports to inspect for SIP traffic. You can specify an integer from 0 to 65535. Separate
multiple port numbers with commas.
Methods to Check
Specifies SIP methods to detect. You can specify any of the following currently defined SIP
methods:
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. The method name can include alphabetic characters, numbers, and the
underscore character. No other special characters are permitted. Separate multiple methods with
commas.
Because new SIP methods might be defined in the future, your configuration can include an
alphabetic string that is not currently defined. 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, in addition to any methods you specify for this option, the 32 total methods includes
methods specified using the sip_method keyword in intrusion rules. See sip_method, page 27-61 for
more information.
Maximum To Length
Specifies the maximum number of bytes to allow in the request or response To header field. A longer
To triggers an event when rule 140:11 is enabled. The To field identifies the message recipient.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
Preprocessor Rule
GID:SID Description
140:1 Generates an event when the preprocessor is monitoring the maximum number of
SIP sessions allowed by the system.
140:2 Generates an event when the required Request_URI field is empty in a SIP
request.
140:4 Generates an event when the Call-ID header field is empty in a SIP request or
response.
140:6 Generates an event when the value for the sequence number in the SIP request or
response CSeq field is not a 32-bit unsigned integer less than 231.
Preprocessor Rule
GID:SID Description
140:8 Generates an event an event when the From header field is empty in a SIP request
or response.
140:10 Generates an event when the To header field is empty in a SIP request or response.
140:12 Generates an event when the Via header field is empty in a SIP request or response
140:14 Generates an event when the required Contact header field is empty in a SIP
request or response.
140:17 Generates an event when a single SIP request or response packet in UDP traffic
contains multiple messages. Note that older SIP versions supported multiple
messages, but SIP 2.0 supports only one message per packet.
140:18 Generates an event when the actual length of the message body in a SIP request
or response in UDP traffic does not match the value specified in the
Content-Length header field in a SIP request or response.
140:19 Generates an event when the preprocessor does not recognize a method name in
the CSeq field of a SIP response.
140:20 Generates an event when the SIP server does not challenge an authenticated invite
message. Note that this occurs in the case of the InviteReplay billing attack.
140:21 Generates an event when session information changes before the call is set up.
Note that this occurs in the case of the FakeBusy billing attack.
140:22 Generates an event when the response status code is not a three-digit number.
140:23 Generates an event when the Content-Type header field does not specify a content
type and the message body contains data.
140:24 Generates an event when the SIP version is not 1, 1.1, or 2.0.
140:25 Generates an event when the method specified in the CSeq header and the method
field do not match in a SIP request.
140:26 Generates an event when the preprocessor does not recognize the method named
in the SIP request method field.
Preprocessor Rule
GID:SID Description
143:1 Generates an event when the preprocessor detects an invalid message length.
143:2 Generates an event when the preprocessor detects an invalid information element
length.
143:3 Generates an event when the preprocessor detects information elements that are
out of order.
You can use the following procedure to modify the ports the GTP preprocessor monitors for GTP
command messages.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue.See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether GTP Command Channel Configuration under Application Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The GTP Command Channel Configuration page appears.
Step 9 Optionally, modify the ports that the preprocessor inspects for GTP command messages. You can specify
an integer from 0 to 65535. Use commas to separate multiple ports.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Ports
Specifies the ports to inspect for IMAP traffic. You can specify an integer from 0 to 65535. Separate
multiple port numbers with commas.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Preprocessor Rule
GID:SID Description
141:1 Generates an event when the preprocessor detects a client command that is not
defined in RFC 3501.
141:2 Generates an event when the preprocessor detects a server response that is not
defined in RFC 3501.
141:3 Generates an event when the preprocessor is using the maximum amount of
memory allowed by the system. At this point, the preprocessor stops decoding
until memory becomes available.
Ports
Specifies the ports to inspect for POP traffic. You can specify an integer from 0 to 65535. Separate
multiple port numbers with commas.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The POP preprocessor rules in the following table are not associated with specific configuration options.
As with other POP preprocessor rules, you must enable these rules if you want them to generate events.
See Setting Rule States, page 24-19 for information on enabling rules.
Preprocessor Rule
GID:SID Description
142:1 Generates an event when the preprocessor detects a client command that is not
defined in RFC 1939.
142:2 Generates an event when the preprocessor detects a server response that is not
defined in RFC 1939.
142:3 Generates an event when the preprocessor is using the maximum amount of
memory allowed by the system. At this point, the preprocessor stops decoding
until memory becomes available.
Ports
Specifies the ports whose SMTP traffic you want to normalize. You can specify an integer from 0 to
65535. Separate multiple ports with commas.
Stateful Inspection
When selected, causes SMTP decoder to save state and provide session context for individual
packets and only inspects reassembled sessions. When cleared, analyzes each individual packet
without session context.
Normalize
When set to All, normalizes all commands. Checks for more than one space character after a
command.
When set to None, normalizes no commands.
When set to Cmds, normalizes the commands listed in Custom Commands.
Custom Commands
When Normalize is set to Cmds, normalizes the listed commands.
Specify commands which should be normalized in the text box. Checks for more than one space
character after a command.
The space (ASCII 0x20) and tab (ASCII 0x09) characters count as space characters for
normalization purposes.
Ignore Data
Does not process mail data; processes only MIME mail header data.
No Alerts
Disables intrusion events when accompanying preprocessor rules are enabled.
You can enable rules 124:2 and 124:7 to generate events for this option. See Setting Rule States,
page 24-19 for more information.
Invalid Commands
Detects if these commands are sent from the client side.
You can enable rule 124:5 and 124:6 to generate events for this option. See Setting Rule States,
page 24-19 for more information.
Valid Commands
Permits commands in this list.
Even if this list is empty, the preprocessor permits the following valid commands: ATRN AUTH
BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP
IDENT MAIL NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SIZE SOML STARTTLS
TICK TIME TURN TURNME VERB VRFY XADR XAUTH XCIR XEXCH50 X-EXPS XGEN
XLICENSE X-LINK2STATE XQUE XSTA XTRN XUSR
Note RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses
command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps
RCPT and MAIL to the correct command name.
You can enable rule 124:4 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Data Commands
Lists commands that initiate sending data in the same way the SMTP DATA command sends data
per RFC 5321. Separate multiple commands with spaces.
Authentication Commands
Lists commands that initiate an authentication exchange between client and server. Separate
multiple commands with spaces.
Detect xlink2state
Detects packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks. In
inline deployments, the system can also drop those packets.
You can enable rule 124:8 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Log To Addresses
Enables extraction of recipient email addresses from the SMTP RCPT TO command and associates
the recipient addresses with all intrusion events generated for the session. Multiple recipients are
supported.
When this option is enabled, you can view recipients associated with events in the Email Recipient
column of the intrusion events table view. See Viewing Events, page 34-1 for more information.
Log Headers
Enables extraction of email headers. The number of bytes to extract is determined by the value
specified for Header Log Depth.
You can use the content or protected_content keyword to write intrusion rules that use email
header data as a pattern. You can also view the extracted email header in the intrusion event packet
view. See Viewing Events, page 34-1 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Note RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses
command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps
RCPT and MAIL to the correct command name.
Step 15 If needed, click Add next to Alt Max Command Line Len to add commands where you want to specify an
alternate maximum command line length, then specify the line length and the command or commands,
separated by spaces, where you want that length to be enforced.
Step 16 Specify any commands that you want to treat as invalid and detect in the Invalid Commands field. Separate
commands with spaces.
Step 17 Specify any commands that you want to treat as valid in the Valid Commands field. Separate commands
with spaces.
Note Even if the Valid Commands list is empty, the preprocessor treats the following commands as valid:
ATRN, AUTH, BDAT, DATA, DEBUG, EHLO, EMAL, ESAM, ESND, ESOM, ETRN, EVFY,
EXPN, HELO, HELP, IDENT, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SOML, SEND,
ONEX, QUEU, STARTTLS, TICK, TIME, TURN, TURNME, VERB, VRFY, X-EXPS,
X-LINK2STATE, XADR, XAUTH, XCIR, XEXCH50, XGEN, XLICENSE, XQUE, XSTA,
XTRN, or XUSR.
Step 18 Specify any commands that you want to initiate sending data in the same way the SMTP DATA command
sends data per RFC 5321 in the Data Commands field. Separate commands with spaces.
Step 19 Specify any commands that initiate sending data in a way that is similar to how the BDAT command
sends data per RFC 3030 in the Binary Data Commands field. Separate commands with spaces.
Step 20 Specify any commands that initiate an authentication exchange between client and server in the
Authentication Commands field. Separate commands with spaces.
Step 21 To detect packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks, select
Detect xlink2state.
Step 22 To specify the maximum bytes of data to extract and decode for different types of email attachment,
specify a value for any of the following attachment types:
• Base64 Decoding Depth
• 7-Bit/8-Bit/Binary Decoding Depth (includes various multipart content types such as plain text, jpeg
images, mp3 files, and so on)
• Quoted-Printable Decoding Depth
• Unix-to-Unix Decoding Depth
You can specify from 1 to 65535 bytes, or specify 0 to extract and, when necessary, decode all data in
the packet for that type. Specify -1 to ignore data for an attachment type.
You can use the file_data rule keyword in intrusion rules to inspect extracted data. See Pointing to a
Specific Payload Type, page 27-96 for more information.
You must also select the SMTP Stateful Inspection option to extract and decode cross-packet data or data
crossing multiple TCP segments.
Step 23 Configure options for associating contextual information with intrusion events triggered by SMTP
traffic:
• To enable extraction of MIME attachment file names to associate with intrusion events, select Log
MIME Attachment Names.
• To enable extraction of recipient email addresses, select Log To Addresses.
• To enable extraction of sender email addresses to associate with intrusion events, select Log From
Addresses.
• To enable extraction of email headers to associate with intrusion events and for writing rules that
inspect email headers, select Log Headers.
Note that header information is displayed in the intrusion event packet view. Note also that you can
also write intrusion rules that use the content or protected_content keyword with email header
data as a pattern. See Viewing Events, page 34-1 for more information.
Optionally, you can specify a Header Log Depth of 0 to 20480 bytes of the email header to extract. A
value of 0 disables Log Headers.
Step 24 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
number of bytes is exceeded within the specified number of packets. If the maximum number of bytes
is exceeded, it is assumed that a CRC-32 (SSH Version 1) or a Challenge-Response Buffer Overflow
(SSH Version 2) attack has occurred. Additionally, you can detect the SecureCRT exploit, protocol
mismatches, and bad message direction. Note that the preprocessor detects without configuration any
version string value other than version 1 or 2.
Note the following when using the SSH preprocessor:
• You must enable SSH preprocessor rules, which have a generator ID (GID) of 128, if you want these
rules to generate events. See Setting Rule States, page 24-19 for more information.
• The SSH preprocessor does not handle brute force attacks. For information on brute force attempts,
see Adding Dynamic Rule States, page 24-28.
See the following sections for more information:
• Selecting SSH Preprocessor Options, page 19-68
• Configuring the SSH Preprocessor, page 19-70
The preprocessor in the example will also detect any of the following that occur while it is processing
traffic:
• a server overflow, triggered by a version string greater than 80 bytes and indicating a SecureCRT
exploit
• a protocol mismatch
• a packet flowing in the wrong direction
Finally, the preprocessor will automatically detect any version string other than version 1 or version 2.
If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a
preprocessor rule.
Server Ports
Specifies on which ports the SSH preprocessor should inspect traffic.
You can configure a single port or a comma-separated list of ports.
Autodetect Ports
Sets the preprocessor to automatically detect SSH traffic.
When this option is selected, the preprocessor inspects all traffic for an SSH version number. It stops
processing when neither the client nor the server packet contains a version number. When disabled,
the preprocessor inspects only the traffic identified by the Server Ports option.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
The SSL preprocessor stops inspection of encrypted data, which can help to eliminate false positives.
The SSL preprocessor maintains state information as it inspects the SSL handshake, tracking both the
state and SSL version for that session. When the preprocessor detects that a session state is encrypted,
the system marks the traffic in that session as encrypted. You can configure the system to stop processing
on all packets in an encrypted session when encryption is established.
For each packet, the SSL preprocessor verifies that the traffic contains an IP header, a TCP header, and
a TCP payload, and that it occurs on the ports specified for SSL preprocessing. For qualifying traffic,
the following scenarios determine whether the traffic is encrypted:
• the system observes all packets in a session, Server side data is trusted is not enabled, and the session
includes a Finished message from both the server and the client and at least one packet from each
side with an Application record and without an Alert record
• the system misses some of the traffic, Server side data is trusted is not enabled, and the session includes
at least one packet from each side with an Application record that is not answered with an Alert
record
• the system observes all packets in a session, Server side data is trusted is enabled, and the session
includes a Finished message from the client and at least one packet from the client with an
Application record and without an Alert record
• the system misses some of the traffic, Server side data is trusted is enabled, and the session includes
at least one packet from the client with an Application record that is not answered with an Alert
record
If you choose to stop processing on encrypted traffic, the system ignores future packets in a session after
it marks the session as encrypted.
Note You can add the ssl_state and ssl_version keywords to a rule to use SSL state or version information
within the rule. For more information, see Extracting SSL Information from a Session, page 27-53.
Preprocessor Rule
GID:SID Description
137:1 Detects a client hello after a server hello, which is invalid and considered to be
anomalous behavior.
137:2 Detects a server hello without a client hello when Server side data is trusted is
disabled, which is invalid and considered to be anomalous behavior. See
Configuring the SSL Preprocessor, page 19-73 for more information.
Note If the SSL preprocessor detects non-SSL traffic over the ports specified for SSL monitoring, it tries to
decode the traffic as SSL traffic, and then flags it as corrupt.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether SSL Configuration under Application Layer Preprocessors is
enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The SSL Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 Type the ports, separated by commas, where the SSL preprocessor should monitor traffic for encrypted
sessions. Only ports included in the Ports field will be checked for encrypted traffic.
Step 10 Click the Stop inspecting encrypted traffic check box to enable or disable inspection of traffic in a session
after the session is marked as encrypted.
Step 11 Click the Server side data is trusted check box to enable or disable identification of encrypted traffic based
only on the client-side traffic.
Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
You configure Supervisory Control and Data Acquisition (SCADA) preprocessors in a network analysis
policy, which prepares traffic for inspection using the rules enabled in an intrusion policy. See
Understanding Network Analysis and Intrusion Policies, page 15-1 for more information.
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. The ASA FirePOWER module provides preprocessors for the Modbus and
DNP3 SCADA protocols that you can configure as part of your network analysis policy.
If you enable a rule containing Modbus or DNP3 keywords in the corresponding intrusion policy, the
system automatically uses the Modbus or DNP3 processor, respectively, with its current settings,
although the preprocessor remains disabled in the network analysis policy module interface. For more
information, see Modbus Keywords, page 27-73 and DNP3 Keywords, page 27-74.
See the following sections for more information:
• Configuring the Modbus Preprocessor, page 20-1
• Configuring the DNP3 Preprocessor, page 20-3
Preprocessor Rule
GID:SID Description
144:1 Generates an event when the length in the Modbus header does not match the
length required by the Modbus function code.
Each Modbus function has an expected format for requests and responses. If the
length of the message does not match the expected format, this event is generated.
144:2 Generates an event when the Modbus protocol ID is non-zero. The protocol ID
field is used for multiplexing other protocols with Modbus. Because the
preprocessor does not process these other protocols, this event is generated
instead.
144:3 Generates an event when the preprocessor detects a reserved Modbus function
code.
Note regarding the use of the Modbus preprocessor that if your network does not contain any
Modbus-enabled devices, you should not enable this preprocessor in a network analysis policy that you
apply to traffic.
You can use the following procedure to modify the ports the Modbus preprocessor monitors.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether Modbus Configuration under SCADA Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Modbus Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 Optionally, modify the Ports that the preprocessor inspects for Modbus traffic. You can specify an integer
from 0 to 65535. Use commas to separate multiple ports.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Preprocessor Rule
GID:SID Description
145:1 When Log bad CRC is enabled, generates an event when the preprocessor detects a
link layer frame with an invalid checksum.
145:2 Generates an event and blocks the packet when the preprocessor detects a DNP3
link layer frame with an invalid length.
145:3 Generates an event and blocks the packet during reassembly when the
preprocessor detects a transport layer segment with an invalid sequence number.
145:4 Generates an event when the DNP3 reassembly buffer is cleared before a complete
fragment can be reassembled. This happens when a segment carrying the FIR flag
appears after other segments have been queued.
145:5 Generates an event when the preprocessor detects a DNP3 link layer frame that
uses a reserved address.
145:6 Generates an event when the preprocessor detects a DNP3 request or response that
uses a reserved function code.
Note regarding the use of the DNP3 preprocessor that, if your network does not contain any
DNP3-enabled devices, you should not enable this preprocessor in a network analysis policy that you
apply to traffic. See Configuring TCP Stream Preprocessing, page 21-28 for more information.
The following list describes the DNP3 preprocessor options you can configure.
Ports
Enables inspection of DNP3 traffic on each specified port. You can specify a single port or a
comma-separated list of ports. You can specify a value from 0 to 65535 for each port.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether DNP3 Configuration under SCADA Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The DNP3 Configuration page appears. A message at the bottom of the page identifies the network
analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 Optionally, modify the Ports that the preprocessor inspects for DNP3 traffic. You can specify an integer
from 0 to 65535. Use commas to separate multiple ports.
Step 10 Optionally, select or clear the Log bad CRCs check box to specify whether to validate the checksums
contained in DNP3 link layer frames and ignore frames with invalid checksums.
Step 11 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See the Network Analysis Policy
Editing Actions table for more information.
You configure most transport at network layer preprocessors in a network analysis policy, which
prepares traffic for inspection using the rules enabled in an intrusion policy. See Understanding Network
Analysis and Intrusion Policies, page 15-1 for more information.
Transport and network layer preprocessors detect attacks that exploit IP fragmentation, checksum
validation, and TCP and UDP session preprocessing. Before packets are sent to preprocessors, the packet
decoder converts packet headers and payloads into a format that can be easily used by the preprocessors
and the intrusion rules engine and detects various anomalous behaviors in packet headers. After packet
decoding and before sending packets to other preprocessors, the inline normalization preprocessor
normalizes traffic for inline deployments.
You can tailor transport and network layer preprocessor settings that you configure in network analysis
policies by zone, or network. Some transport and network layer settings apply globally to all traffic, and
you configure these in an access control policy.
• Configuring Advanced Transport/Network Settings, page 21-1
• Verifying Checksums, page 21-4
• Normalizing Inline Traffic, page 21-6
• Defragmenting IP Packets, page 21-11
• Understanding Packet Decoding, page 21-16
• Using TCP Stream Preprocessing, page 21-20
• Using UDP Stream Preprocessing, page 21-31
Tip Because UDP data streams are not typically thought of in terms of sessions, see Using UDP Stream
Preprocessing, page 21-31 for further explanation of how the stream preprocessor uses the source and
destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP
header to determine the direction of flow and identify a UDP session.
You can configure the Maximum Active Responses option to initiate one or more active responses to more
precisely and specifically close a TCP connection or UDP session when an offending packet triggers a
TCP or UDP drop rule.
When active responses are enabled in an inline deployment, the system responds to TCP drop rules by
dropping the triggering packet and inserting a TCP Reset (RST) packet in both the client and server
traffic. The system cannot drop the packet in a passive deployment; when active responses are enabled
in a passive deployment, the system responds to TCP drop rules by sending a TCP reset to both the client
and server ends of a TCP connection. When active responses are enabled in inline or passive
deployments, the system closes a UDP session by sending an ICMP unreachable packet to each end of
the session. Active responses are most effective in inline deployments because resets are more likely to
arrive in time to affect the connection or session.
Depending on how you configure the Maximum Active Responses option, the system can also initiate
additional active responses if it sees additional traffic from either end of the connection or session. The
system initiates each additional active response, up to a specified maximum, after a specified number of
seconds have elapsed since the previous response.
See Selecting The TCP Global Option, page 21-21 for information on setting the maximum number of
active responses.
Note that a triggered resp or react rule also initiates an active response regardless of the configuration of
Maximum Active Responses; however, Maximum Active Responses control whether the system initiates
additional active responses for resp and react rules in the same way it controls the maximum number of
active responses for drop rules. See Initiating Active Responses with Rule Keywords, page 27-83 for
more information.
You can also 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. See Setting the Active Response Reset
Attempts and Interface, page 27-85 for more information.
No preprocessor rules are associated with the following options.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 7 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 8 Click the edit icon ( ) next to Transport/Network Layer Preprocessor Settings.
The Transport/Network Layer Preprocessor Settings pop-up window appears.
Step 9 You have the following options:
• Specify a value 1 to 25 of Maximum Active Responses per TCP connection. A setting of 0 disables
active responses triggered by drop rules and disables additional active responses triggered by resp
or react rules.
• Specify a value 1 to 300 of Minimum Response Seconds to wait until either Maximum Active Responses
occur or any additional traffic on a connection where the system has initiated an active response
results in a subsequent active response.
Step 10 Click OK.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 7 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 8 Click the edit icon ( ) next to Transport/Network Layer Preprocessor Settings.
The Transport/Network Layer Preprocessor Settings pop-up window appears.
Step 9 Expand Troubleshooting Options.
Step 10 Specify for Session Termination Logging Threshold the number of bytes that result in a logged message when
the session terminates and the specified number was exceeded.
The upper limit of 1GB is also restricted by the amount of memory on the device allocated for stream
processing.
Step 11 Click OK.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Verifying Checksums
License: Protection
The system can verify all protocol-level checksums to ensure that complete IP, TCP, UDP, and ICMP
transmissions are received and that, at a basic level, packets have not been tampered with or accidentally
altered in transit. A checksum uses an algorithm to verify the integrity of a protocol in the packet. The
packet is considered to be unchanged if the system computes the same value that is written in the packet
by the end host.
Disabling checksum verification may leave your network susceptible to insertion attacks. Note that the
system does not generate checksum verification events. In an inline deployment, you can configure the
system to drop packets with invalid checksums.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Edit Policy page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether Checksum Verification under Transport/Network Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Checksum Verification page appears. A message at the bottom of the page identifies the policy layer
that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy, page 16-1
for more information.
Step 9 You can set any of the options in the Checksum Verification section to Enabled or Disabled in a passive or
inline deployment, or to Drop in an inline deployment:
• ICMP Checksums
• IP Checksums
• TCP Checksums
• UDP Checksums
Note that to drop offending packets, in addition to setting an option to Drop you must also enable Inline
Mode in the associated network analysis policy. See Allowing Preprocessors to Affect Traffic in Inline
Deployments, page 18-5 for more information. Note also that setting these options to Drop in a passive
deployment is the same as setting them to Enabled.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Tip In an inline deployment, Cisco recommends that you configure the inline normalization preprocessor
with the Normalize TCP Payload option enabled. In a passive deployment, Cisco recommends that you
configure adaptive profiles. For more information, see Tuning Preprocessing in Passive Deployments,
page 22-1.
Minimum TTL
When Reset TTL is greater than or equal to the value 1 to 255 set for this option, specifies the
following:
• the minimum value the system will permit in the IPv4 Time to Live (TTL) field when Normalize IPv4
is enabled; a lower value results in normalizing the packet value for TTL to the value set for Reset TTL
• the minimum value the system will permit in the IPv6 Hop Limit field when Normalize IPv6 is
enabled; a lower value results in normalizing the packet value for Hop Limit to the value set for Reset
TTL
The system assumes a value of 1 when the field is empty.
Note that you can enable the following rules in the decoder rule category to generate events for this
option:
• You can enable rule 116:428 to generate an event when the system detects an IPv4 packet with a
TTL less than the specified minimum.
• You can enable rule 116:270 to generate an event when the system detects an IPv6 packet with a hop
limit that is less than the specified minimum.
See the packet decoder Detect Protocol Header Anomalies option in Configuring Packet Decoding,
page 21-19 for more information.
Reset TTL
When set to a value 1 to 255 that is greater than or equal to Minimum TTL, normalizes the following:
• the IPv4 TTL field when Normalize IPv4 is enabled
• the IPv6 Hop Limit field when Normalize IPv6 is enabled
The system normalizes the packet by changing its TTL or Hop Limit value to the value set for this
option when the packet value is less than Minimum TTL. Setting this option to a value of 0, or any value
less than Minimum TTL, disables the option. The system assumes a value of 0 when the field is empty.
Normalize IPv4
Enables normalization of IPv4 traffic. The system also normalizes the TTL field as needed when this
option is enabled and the value set for Reset TTL enables TTL normalization. You can also enable
Normalize Don’t Fragment Bits and Normalize Reserved Bits when this option is enabled.
When you enable this option, the system performs the following base IPv4 normalizations:
• truncates packets with excess payload to the datagram length specified in the IP header
• clears the Differentiated Services (DS) field, formerly known as the Type of Service (TOS) field
• sets all option octets to 1 (No Operation)
Normalize IPv6
Sets all Option Type fields in the Hop-by-Hop Options and Destination Options extension headers
to 00 (Skip and continue processing). The system also normalizes the Hop Limit field as needed
when this option is enabled and the value set for Reset TTL enables hop limit normalization.
Normalize ICMPv4
Clears the 8-bit Code field in Echo (Request) and Echo Reply messages in ICMPv4 traffic.
Normalize ICMPv6
Clears the 8-bit Code field in Echo (Request) and Echo Reply messages in ICMPv6 traffic.
– 129:8
– 129:11
– 129:14 through 129:19
The Total Blocked Packets performance graph tracks the number of packets blocked in inline
deployments and, in passive deployments, the number that would have been blocked in an inline
deployment.
Specify... To allow...
sack TCP options 4 (Selective Acknowledgment Permitted) and
5 (Selective Acknowledgment)
echo TCP options 6 (Echo Request) and 7 (Echo Reply)
partial_order TCP options 9 (Partial Order Connection Permitted) and 10
(Partial Order Service Profile)
conn_count TCP Connection Count options 11 (CC), 12 (CC.New), and
13 (CC.Echo)
Specify... To allow...
alt_checksum TCP options 14 (Alternate Checksum Request) and 15
(Alternate Checksum)
md5 TCP option 19 (MD5 Signature)
the option number, a specific option, including options for which there is no
2 to 255 keyword
any all TCP options; this setting effectively disables TCP
option normalization
When you do not specify any for this option, normalizations include the following:
• except MSS, Window Scale, Time Stamp, and any explicitly allowed options, sets all option bytes
to No Operation (TCP Option 1)
• sets the Time Stamp octets to No Operation if Time Stamp is present but invalid, or valid but not
negotiated
• blocks the packet if Time Stamp is negotiated but not present
• clears the Time Stamp Echo Reply (TSecr) option field if the Acknowledgment (ACK) control bit
is not set
• sets the MSS and Window Scale options to No Operation (TCP Option 1) if the SYN control bit is
not set
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Edit Policy page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices depending on whether Inline Normalization is enabled under Transport/Network
Layer Preprocessors:
Defragmenting IP Packets
License: Protection
When an IP datagram is broken into two or more smaller IP datagrams because it is larger than the
maximum transmission unit (MTU), it is fragmented. A single IP datagram fragment may not contain
enough information to identify a hidden attack. Attackers may attempt to evade detection by transmitting
attack data in fragmented packets. The IP defragmentation preprocessor reassembles fragmented IP
datagrams before the rules engine executes rules against them so the rules can more appropriately
identify attacks in those packets. If fragmented datagrams cannot be reassembled, rules do not execute
against them.
Note that you must enable IP defragmentation preprocessor rules, which have a generator ID (GID) of
123, if you want these rules to generate events. See Setting Rule States, page 24-19 for more
information.
See the following sections for more information:
• Understanding IP Fragmentation Exploits, page 21-11
• Target-Based Defragmentation Policies, page 21-12
• Selecting Defragmentation Options, page 21-13
• Configuring IP Defragmentation, page 21-14
The Jolt2 attack sends a large number of copies of the same fragmented IP packet in an attempt to
overuse IP defragmentors and cause a denial of service attack. A memory usage cap disrupts this and
similar attacks in the IP defragmentation preprocessor, and places the system self-preservation above
exhaustive inspection. The system is not overwhelmed by the attack, remains operational, and continues
to inspect network traffic.
Different operating systems reassemble fragmented packets in different ways. Attackers who can
determine which operating systems your hosts are running can also fragment malicious packets so that
a target host reassembles them in a specific manner. Because the system does not know which operating
systems the hosts on your monitored network are running, the preprocessor may reassemble and inspect
the packets incorrectly, thus allowing an exploit to pass through undetected. To mitigate this kind of
attack, you can configure the defragmentation preprocessor to use the appropriate method of
defragmenting packets for each host on your network. See Target-Based Defragmentation Policies,
page 21-12 for more information.
Note that you can also use adaptive profiles to dynamically select target-based policies for the IP
defragmentation preprocessor using host operating system information for the target host in a packet.
For more information, see Tuning Preprocessing in Passive Deployments, page 22-1.
Preallocated Fragments
The maximum number of individual fragments that the preprocessor can process at once. Specifying
the number of fragment nodes to preallocate enables static memory allocation.
Caution Processing an individual fragment uses approximately 1550 bytes of memory. If the preprocessor
requires more memory to process the individual fragments than the predetermined allowable memory
limit for the device, the memory limit for the device takes precedence.
You can configure the following options for each IP defragmentation policy:
Networks
The IP address of the host or hosts to which you want to apply the defragmentation policy.
You can specify a single IP address or address block, or a comma-separated list of either or both.
You can specify up to 255 total profiles, including the default policy. For information on using IPv4
and IPv6 address blocks in the ASA FirePOWER module, see IP Address Conventions, page 1-4.
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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
Policy
The defragmentation policy you want to use for a set of hosts on your monitored network segment.
You can choose among seven policies: BSD, BSD-Right, First, Linux, Last, Solaris, and Windows.
See Target-Based Defragmentation Policies, page 21-12 for detailed information on these policies.
Timeout
Specifies the maximum amount of time, in seconds, that the preprocessor engine can use when
reassembling a fragmented packet. If the packet cannot be reassembled within the specified time
period, the preprocessor engine stops attempting to reassemble the packet and discards received
fragments.
Minimum TTL
Specifies the minimum acceptable TTL value a packet may have. This option detects TTL-based
insertion attacks.
You can enable rule 123:1 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Detect Anomalies
Identifies fragmentation problems such as overlapping fragments.
You can enable the following rules to generate events for this option:
• 123:1 through 123:4
• 123:5 (BSD policy)
• 123:6 through 123:8
Overlap Limit
Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments
in a session has been detected, defragmentation stops for that session. You must enable Detect
Anomalies to configure this option. A blank value disables this option.
You can enable rule 123:12 to generate events for this option. See Setting Rule States, page 24-19
for more information.
Configuring IP Defragmentation
License: Protection
You can use the following procedure to configure the IP defragmentation preprocessor. For more
information on the IP defragmentation preprocessor configuration options, see Selecting
Defragmentation Options, page 21-13.
To configure IP defragmentation:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Edit Policy page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether IP Defragmentation under Transport/Network Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The IP Defragmentation page appears. A message at the bottom of the page identifies the policy layer
that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy, page 16-1
for more information.
Step 9 Optionally, you can modify the setting for Preallocated Fragments in the Global Settings page area.
Step 10 You have two options:
• Add a new target-based policy. Click the add icon ( ) next to Servers on the left side of the page.
The Add Target pop-up window appears. Specify one or more IP addresses in the Host Address field
and click OK.
You can specify a single IP address or address block, or a comma-separated list of either or both.
You can create a total of 255 target-based policies including the default policy. For information on
using IP address blocks in the ASA FirePOWER module, see IP Address Conventions, page 1-4.
Note that for a target-based policy to process traffic, the networks you identify must match or be a
subset of the networks, and zones handled by the network analysis policy where you configure the
target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3 for
more information.
A new entry appears in the list of targets on the left side of the page, highlighted to indicate that it
is selected, and the Configuration section updates to reflect the current configuration for the policy
you added.
• Modify the settings for an existing target-based policy. Click the configured address for a policy you
have added under Hosts on the left side of the page, or click default.
Your selection is highlighted and the Configuration section updates to display the current
configuration for the policy you selected. To delete an existing target-based policy, click the delete
icon ( ) next to the policy you want to remove.
Step 11 Optionally, you can modify any of the options in the Configuration page area.
Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Note that intrusion rules 12065, 12066, 12067, and 12068 in the policy-other rule category detect, but
do not decode, Teredo traffic. Optionally, you can use these rules to drop Teredo traffic in an inline
deployment; however, you should ensure that these rules are disabled or set to generate events
without dropping traffic when you enable Detect Teredo on Non-Standard Ports. See Filtering Rules in
an Intrusion Policy, page 24-9 and Setting Rule States, page 24-19 for more information.
Because these are experimental options, some systems do not account for them and may be open to
exploits.
Note In addition to the experimental options listed in the above table, the system considers any TCP
option with an option number greater than 26 to be experimental.
You can enable rule 116:58 to generate events for this option. See Setting Rule States, page 24-19
for more information.
You can enable rule 116:57 to generate events for this option. See Setting Rule States, page 24-19
for more information.
Detect T/TCP
Detects TCP headers with the CC.ECHO option. The CC.ECHO option confirms that TCP for
Transactions (T/TCP) is being used. Because T/TCP header options are not in widespread use, some
systems do not account for them and may be open to exploits.
You can enable rule 116:56 to generate events for this option. See Setting Rule States, page 24-19
for more information.
See the inline normalization Minimum TTL option in Normalizing Inline Traffic, page 21-6 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Edit Policy page appears.
Step 7 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 8 You have two choices, depending on whether Packet Decoding under Transport/Network Layer
Preprocessors is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Packet Decoding page appears. A message at the bottom of the page identifies the policy layer that
contains the configuration. See Resolving Conflicts and Committing Policy Changes, page 15-15 for
more information
Step 9 You can enable or disable any of the detection options on the Packet Decoding page. See Understanding
Packet Decoding, page 21-16 for more information.
Step 10 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
You can configure the system so that the preprocessor detects any TCP traffic that cannot be identified
as part of an established TCP session, although this is not recommended for typical use because the
events would quickly overload the system and not provide meaningful data.
Attacks like stick and snot use the system’s extensive rule sets and packet inspection against itself. These
tools generate packets based on the patterns in Snort-based intrusion rules, and send them across the
network. If your rules do not include the flow or flowbits keyword to configure them for stateful
inspection, each packet will trigger the rule, overwhelming the system. Stateful inspection allows you to
ignore these packets because they are not part of an established TCP session and do not provide
meaningful information. When performing stateful inspection, the rules engine detects only those
attacks that are part of an established TCP session, allowing analysts to focus on these rather than the
volume of events caused by stick or snot.
Note that you can also use adaptive profiles to dynamically select target-based policies for the TCP
stream preprocessor using host operating system information for the target host in a packet. For more
information, see Tuning Preprocessing in Passive Deployments, page 22-1.
The following table identifies the operating system policies and the host operating systems that use each.
Tip The First operating system policy could offer some protection when you do not know the host operating
system. However, it may result in missed attacks. You should edit the policy to specify the correct
operating system if you know it.
Network
Specifies the host IP addresses to which you want to apply the TCP stream reassembly policy.
You can specify a single IP address or address block. You can specify up to 255 total profiles
including the default policy. For information on using IPv4 and IPv6 address blocks in the ASA
FirePOWER module, see IP Address Conventions, page 1-4.
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).
Note also that for a target-based policy to process traffic, the networks you identify must match or
be a subset of the networks, and zones handled by the network analysis policy where you configure
the target-based policy. See Customizing Preprocessing with Network Analysis Policies, page 17-3
for more information.
Policy
Identifies the TCP policy operating system of the target host or hosts. If you select a policy other
than Mac OS, the system removes the data from the synchronization (SYN) packets and disables
event generation for rule 129:2.
For more information, see Understanding Target-Based TCP Policies, page 21-21.
Timeout
The number of seconds between 1 and 86400 the intrusion rules engine keeps an inactive stream in
the state table. If the stream is not reassembled in the specified time, the intrusion rules engine
deletes it from the state table.
Note If your device is deployed on a segment where the network traffic is likely to reach the device’s
bandwidth limits, you should consider setting this value higher (for example, to 600 seconds) to
lower the amount of processing overhead.
Caution The upper limit is the maximum window size permitted by RFC, and is intended to prevent an attacker
from evading detection, but setting a significantly large maximum window size could result in a
self-imposed denial of service.
You can enable rule 129:6 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Overlap Limit
Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments
in a session has been detected, segment reassembly stops for that session and, if Stateful Inspection
Anomalies is enabled and the accompanying preprocessor rule is enabled, an event is generated.
You can enable rule 129:7 to generate events for this option. See Setting Rule States, page 24-19 for
more information.
Flush Factor
In an inline deployment, specifies that when a segment of decreased size has been detected
subsequent to the configured number between 1 and 2048 of segments of non-decreasing size, the
system flushes segment data accumulated for detection. Setting the value to 0 disables detection of
this segment pattern, which can indicate the end of a request or response. Note that the Inline
Normalization Normalize TCP Payload option must be enabled for this option the be effective. See
Normalizing Inline Traffic, page 21-6 for more information.
Legacy Reassembly
Sets the stream preprocessor to emulate the deprecated Stream 4 preprocessor when reassembling
packets, which lets you compare events reassembled by the stream preprocessor to events based on
the same data stream reassembled by the Stream 4 preprocessor.
Asynchronous Network
Specifies whether the monitored network is an asynchronous network, that is, a network where the
system sees only half the traffic. When this option is enabled, the system does not reassemble TCP
streams to increase performance.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only
with Support guidance.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only
with Support guidance.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
For example, the following graphic shows the Perform Stream Reassembly on Both Services pop-up
window.
Note that you can enable adaptive profiles to monitor traffic for the stream preprocessor to reassemble
based on services discovered on your network. See Tuning Preprocessing in Passive Deployments,
page 22-1 for more information.
Step 13 You have two choices:
• To add services to monitor, select one or more services from the Available list on the left, then click
the right arrow (>) button.
• To remove a service, select it from the Enabled list on the right, then click the left arrow (<) button.
Use Ctrl or Shift while clicking to select multiple service detectors. You can also click and drag to select
multiple adjacent service detectors.
Step 14 Click OK to add the selections.
The TCP Stream Configuration page is displayed and the services are updated.
Step 15 Optionally, expand the Troubleshooting Options and modify either of the TCP stream preprocessing policy
settings only if asked to do so by Support. For more information, see Selecting TCP Policy Options,
page 21-22.
Step 16 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
Typically, the system uses the static settings in your network analysis policy to preprocess and analyze
traffic. With the adaptive profiles feature, however, the system can adapt to network traffic by associating
traffic with host information and processing the traffic accordingly.
When a host receives traffic, the operating system running on the host reassembles IP fragments. The
order used for that reassembly depends on the operating system. Similarly, each operating system may
implement TCP in different ways, and therefore reassemble TCP streams differently. If preprocessors
reassemble data using a format other than that used for the operating system of the destination host, the
system may miss content that could be malicious when reassembled on the receiving host.
Tip In a passive deployment, Cisco recommends that you configure adaptive profiles. In an inline
deployment, Cisco recommends that you configure the inline normalization preprocessor with the
Normalize TCP Payload option enabled. For more information, see Normalizing Inline Traffic, page 21-6.
For more information on using adaptive profiles to improve reassembly of packet fragments and TCP
streams, see the following topics:
• Understanding Adaptive Profiles, page 22-1
• Configuring Adaptive Profiles, page 22-2
Adaptive profiles switch to the appropriate operating system profile based on the operating system in the
host profile for the target host, as illustrated in the following diagram.
For example, you configure adaptive profiles for the 10.6.0.0/16 subnet and set the default IP
Defragmentation target-based policy to Linux. The ASA FirePOWER module where you configure the
settings includes the 10.6.0.0/16 subnet.
When a device detects traffic from Host A, which is not in the 10.6.0.0/16 subnet, it uses the Linux
target-based policy to reassemble IP fragments. However, when it detects traffic from Host B, which is
in the 10.6.0.0/16 subnet, it retrieves Host B’s operating system data, where Host B is running Microsoft
Windows XP Professional. The system uses the Windows target-based profile to do the IP
defragmentation for the traffic destined for Host B.
See Defragmenting IP Packets, page 21-11 for information on the IP Defragmentation preprocessor. See
Using TCP Stream Preprocessing, page 21-20 for information on the stream preprocessor.
You can use any of these addressing methods alone or in any combination as a list of IP addresses,
address blocks, or variables separated by commas, as shown in the following example:
192.168.1.101, 192.168.4.0/24, $HOME_NET
For information on specifying address blocks, see IP Address Conventions, page 1-4.
Tip You can apply adaptive profiles to all hosts in the network by using a variable with a value of any or by
specifying 0.0.0.0/0 as the network value.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Detection Enhancement Settings.
The Detection Enhancement Settings pop-up window appears.
Step 5 Select Adaptive Profiles - Enabled to enable adaptive profiles.
Step 6 Optionally, in the Adaptive Profiles - Attribute Update Interval field, type the number of minutes that should
elapse between synchronization of data.
Note Increasing the value for this option could improve performance in a large network.
Step 7 In the Adaptive Profiles - Networks field, type the specific IP address, address block, or variable, or a list
that includes any of these addressing methods separated by commas, to identify any host in the network
for which you want to use adaptive profiles.
See Working with Variable Sets, page 2-13 for information on configuring variables.
Step 8 Click OK to retain your settings.
Intrusion policies are defined sets of intrusion detection and prevention configurations that inspect
traffic for security violations and, in inline deployments, can block or alter malicious traffic. Intrusion
policies are invoked by your access control policy and are the system’s last line of defense before traffic
is allowed to its destination.
Cisco delivers several intrusion policies with the ASA FirePOWER module. By using system-provided
policies you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For
these policies, the VRT sets intrusion and preprocessor rule states (enabled or disabled), as well as
provides the initial configurations for other advanced settings. An enabled rule causes the system to
generate intrusion events for (and optionally block) traffic matching the rule. Disabling a rule stops
processing of the rule.
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. Understanding Network Analysis and Intrusion Policies,
page 15-1 provides an overview of how network analysis and intrusion policies work together to examine
your traffic, as well as some basics on using the navigation panel, resolving conflicts, and committing
changes.
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. For more information, see
Limitations of Custom Policies, page 15-11.
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.
For more information, see Controlling Traffic Using Intrusion and File Policies, page 10-1.
This chapter explains how to create a simple custom intrusion policy. The chapter also contains basic
information on managing intrusion policies: editing, comparing, and so on. For more information, see:
• Creating a Custom Intrusion Policy, page 23-2
• Managing Intrusion Policies, page 23-3
• Editing Intrusion Policies, page 23-4
• Applying an Intrusion Policy, page 23-8
• Generating a Report of Current Intrusion Settings, page 23-8
• Comparing Two Intrusion Policies or Revisions, page 23-9
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Tip You can also import a policy from another ASA FirePOWER module; see Importing and Exporting
Configurations, page B-1.
Caution Do not use Experimental Policy 1 unless instructed to do so by a Cisco representative. Cisco uses this
policy for testing.
When tailoring an 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 user interface.
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. For more information, see
Limitations of Custom Policies, page 15-11.
The system caches one intrusion policy. While editing an intrusion 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. In addition
to the actions you can perform in the table above, Understanding Network Analysis and Intrusion
Policies, page 15-1 provides information on resolving conflicts and committing changes
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the intrusion policy you want to configure.
The intrusion policy editor appears, focused on the Policy Information page and with a navigation panel
on the left.
Step 3 Edit your policy. Take any of the actions summarized above.
Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. For more information, see Resolving Conflicts and Committing Policy Changes,
page 15-15.
Note To block the transfer of malware files over FTP, you must not only correctly configure network-based
advanced malware protection (AMP), but also enable Drop when Inline in your access control policy’s
default intrusion policy. To determine or change the default intrusion policy, see Setting the Default
If you want to assess how your configuration would function in an inline deployment without actually
affecting traffic, you can disable drop behavior. In this case, the system generates intrusion events but
does not drop packets that trigger drop rules. When you are satisfied with the results, you can enable
drop behavior.
Note that in passive deployments the system cannot affect traffic regardless of the drop behavior. In other
words, in a passive deployment, rules set to Drop and Generate Events behave identically to rules set to
Generate Events—the system generates intrusion events but cannot drop packets.
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. When a packet matches a drop rule, the
inline result is:
• Dropped, for packets dropped by a correctly configured inline deployment with drop behavior
enabled
• Would have dropped, for packets that were not dropped either because your device is deployed
passively or because drop behavior is disabled. Note that the inline result is always Would have
dropped for packets seen while the system is pruning, regardless of deployment.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
The Policy Information page appears.
Step 3 Set the policy’s drop behavior:
• To allow intrusion rules to affect traffic and generate events, enable Drop when Inline.
• To prevent intrusion rules from affecting traffic while still generating events, disable Drop when
Inline.
Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. For more information, see Resolving Conflicts and Committing Policy Changes,
page 15-15.
An advanced setting must be enabled for you to configure it. When you enable an advanced setting, a
sublink to the configuration page for the advanced setting appears beneath the Advanced Settings link in
the navigation panel, and an Edit link to the configuration page appears next to the advanced setting on
the Advanced Settings page.
Tip To revert an advanced setting’s configuration to the settings in the base policy, click Revert to Defaults on
the configuration page for the advanced setting. When prompted, confirm that you want to revert.
When you disable an advanced setting, the sublink and Edit link no longer appear, but your configurations
are retained. Note that some intrusion policy configurations (sensitive data rules, SNMP alerts for
intrusion rules) require enabled and correctly configured advanced settings. You cannot save an intrusion
policy misconfigured in this way; see Resolving Conflicts and Committing Policy Changes, page 15-15.
Modifying the configuration of an advanced setting requires an understanding of the configuration you
are modifying and its potential impact on your network. The following sections provide links to specific
configuration details for each advanced setting.
External Responses
In addition to the various views of intrusion events within the user 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. For more information, see:
• Configuring SNMP Responses, page 36-3
• Configuring Syslog Responses, page 36-6
• You can schedule intrusion policy reapply tasks to recur on a regular basis; see Automating
Applying an Intrusion Policy, page 39-4.
• When you import a rule update, you can automatically apply intrusion policies after the import
completes. If you do not enable this option, you must manually reapply the policies changed by the
rule update. See Importing Rule Updates and Local Rule Files, page 43-10 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the apply icon ( ) next to the policy you want to reapply.
The Reapply Intrusion Policy window appears.
Section Description
Policy Information Provides the name and description of the intrusion policy, the name of the user
who last modified the policy, and the date and time the policy was last modified.
Also indicates whether dropping packets in an inline deployment is enabled or
disabled, the current rule update version, and whether the base policy is locked
to the current rule update.
Advanced Settings Lists all enabled intrusion policy advanced settings and their configurations.
Rules Provides a list of all enabled rules and their actions.
You can also generate a comparison report that compares two intrusion policies, or two revisions of the
same policy. For more information, see Comparing Two Intrusion Policies or Revisions, page 23-9.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the report icon ( ) next to the intrusion policy for which you want to generate a report.
Remember to commit any potential changes before you generate an intrusion policy report; only
committed changes appear in the report.
The system generates the intrusion policy report. You are prompted to save the report to your computer.
You can perform any of the actions described in the following table.
Tip You can use a similar procedure to compare access control, network analysis, file, or system policies.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click Compare Policies.
The Select Comparison window appears.
Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:
• To compare two different policies, select Other Policy.
• To compare two revisions of the same policy, select Other Revision.
Remember to commit any changes before you generate an intrusion policy report; only committed
changes appear in the report.
Step 4 Depending on the comparison type you selected, you have the following choices:
• If you are comparing two different policies, select the policies you want to compare from the Policy
A and Policy B drop-down lists.
• If you are comparing two revisions of the same policy, select the policy from the Policy drop-down
list, then select the revisions you want to compare from the Revision A and Revision B drop-down lists.
Step 5 Click OK to display the intrusion policy comparison view.
The comparison view appears.
Step 6 Click Comparison Report to generate the intrusion policy comparison report.
Step 7 The intrusion policy report appears. You are prompted to save the report to your computer.
You can use the Rules page in an intrusion policy to configure rule states and other settings for shared
object rules, standard text rules, and preprocessor rules.
You enable a rule by setting its rule state to Generate Events or to Drop and Generate Events. Enabling
a rule causes the system to generate events on traffic matching the rule. Disabling a rule stops processing
of the rule. Optionally, you can set your intrusion policy so that a rule set to Drop and Generate Events
in an inline deployment generates events on, and drops, matching traffic. See Setting Drop Behavior in
an Inline Deployment, page 23-5 for more information. In a passive deployment, a rule set to Drop and
Generate Events just generates events on matching traffic.
You can filter rules to display a subset of rules, enabling you to select the exact set of rules where you
want to change rule states or rule settings.
When an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses
it with its current configuration even though it remains disabled in the network analysis policy’s user
interface. For more information, see Limitations of Custom Policies, page 15-11.
See the following sections for more information:
• Understanding Intrusion Prevention Rule Types, page 24-1 describes the intrusion rules and
preprocessor rules you can view and configure in an intrusion policy.
• Viewing Rules in an Intrusion Policy, page 24-2 describes how you can change the order of rules on
the Rules page, interpret the icons on the page, and focus in on rule details.
• Filtering Rules in an Intrusion Policy, page 24-9 describes how you can use rule filters to find the
rules for which you want to apply rule settings.
• Setting Rule States, page 24-19 describes how to enable and disable rules from the Rules page.
• Filtering Intrusion Event Notification Per Policy, page 24-20 explains how to set event filtering
thresholds for specific rules and set suppression on specific rules.
• Adding Dynamic Rule States, page 24-28 explains how to set rule states that trigger dynamically
when rate anomalies are detected in matching traffic.
• Adding SNMP Alerts, page 24-31 describes how to associate SNMP alerts with specific rules.
• Adding Rule Comments, page 24-32 describes how to add comments to rules in an intrusion policy.
An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit
vulnerabilities on your network; an intrusion rule analyzes network traffic to check if it matches the
criteria in the rule. The system compares packets against the conditions specified in each rule and, if the
packet data matches all the conditions specified in a rule, the rule triggers. The system includes two types
of intrusion rules created by the Cisco Vulnerability Research Team (VRT): shared object rules, which
are compiled and cannot be modified (except for rule header information such as source and destination
ports and IP addresses), and standard text rules, which can be saved and modified as new custom
instances of the rule.
The system also includes preprocessor rules, which are rules associated with preprocessor and packet
decoder detection options. You cannot copy or edit preprocessor rules. Most preprocessor rules are
disabled by default and must be enabled (that is, set to Generate Events or to Drop and Generate Events)
if you want the system to generate events for preprocessor rules and, in an inline deployment, drop
offending packets.
The VRT determines the default rule states of Cisco’s shared object rules, standard text rules, and
preprocessor rules for each default intrusion policy included with the system.
The following table describes each type of rule included with the ASA FirePOWER module.
Type Description
shared object rule An intrusion rule created by the Cisco Vulnerability Research Team (VRT) that is delivered as a binary
module compiled from C source code. You can use shared object rules to detect attacks in ways that
standard text rules cannot. You cannot modify the rule keywords and arguments in a shared object rule;
you are limited to either modifying variables used in the rule, or modifying aspects such as the source
and destination ports and IP addresses and saving a new instance of the rule as a custom shared object
rule. A shared object rule has a GID (generator ID) of 3. See Modifying Existing Rules, page 27-102 for
more information.
standard text rule An intrusion rule either created by the VRT, copied and saved as a new custom rule, created using the
rule editor, or imported as a local rule that you create on a local machine and import. You cannot modify
the rule keywords and arguments in a standard rule created by the VRT; you are limited to either
modifying variables used in the rule, or modifying aspects such as the source and destination ports and
IP addresses and saving a new instance of the rule as a custom standard text rule. See Modifying Existing
Rules, page 27-102, Understanding and Writing Intrusion Rules, page 27-1 and Importing Local Rule
Files, page 43-16 for more information. A standard text rule created by the VRT has a GID (generator
ID) of 1. Custom standard text rules that you create using the rule editor or import as local rules have a
SID (Signature ID) of 1000000 or greater.
preprocessor rule A rule associated with a detection option of the packet decoder or with one of the preprocessors included
with the ASA FirePOWER module. You must enable preprocessor rules if you want them to generate
events. These rules have a decoder- or preprocessor-specific GID (generator ID).
• the rule attribute menus—for more information, see Setting Rule States, page 24-19, Filtering
Intrusion Event Notification Per Policy, page 24-20, Adding Dynamic Rule States, page 24-28,
Adding SNMP Alerts, page 24-31, and Adding Rule Comments, page 24-32
• the rules listing—for more information, see the Rules Page Columns table.
• the rule details—for more information, see Viewing Rule Details, page 24-4
You can also sort rules by different criteria; for more information, see Sorting the Rule Display,
page 24-4.
Note that the icons used as column headers correspond to the menus in the menu bar, where you access
those configuration items. For example, the Rule State menu is marked with the same icon ( ) as the
Rule State column.
The following table describes the columns on the Rules page.
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. See Using
Layers in a Network Analysis or Intrusion Policy, page 16-1 for more information. The drop-down list
also lists the Rules page for the read-only base policy. See Understanding the Base Layer, page 16-2 for
information on the base policy.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules on the Policy Information page.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Note that selecting Rules above the dividing line in the navigation panel takes you to the same rules
listing. You can view and set all rule attributes in your policy in this view.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Click the title or icon in the top of the column you want to sort by.
The rules are sorted by the column, in the direction indicated by the arrow that appears on the column
heading. To sort in the opposite direction, click the heading again. The sort order and the arrow reverse.
You can view rule documentation and rule overhead from the Rule Detail view. You can also view and
add rule-specific features.
Note that local rules do not have any overhead, unless they are mapped to a vulnerability.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Highlight the rule whose rule details you want to view.
Tip You can also open Rule Detail by double-clicking a rule in the Rules view.
Step 4 Next to Rate, indicate the number of rule matches per time period to set the attack rate:
• In the Count field, using an integer between 0 and 2147483647, specify the number of rule matches
you want to use as your threshold.
• In the Seconds field, using an integer between 0 and 2147483647, 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, select the new action to be taken when the conditions are met:
• Select Generate Events to generate an event.
• Select Drop and Generate Events to generate an event and drop the packet that triggered the event in
inline deployments or to generate an event in passive deployments.
• Select Disabled to take no action.
Step 6 In the Timeout field, using an integer between 1 and 2147483647 (approximately 68 years), type the
number of seconds you want the new action to remain in effect. After the timeout occurs, the rule reverts
to its original state. Specify 0 to prevent the new action from timing out.
Step 7 Click OK.
The system adds the dynamic rule state and displays a dynamic state icon ( ) next to the rule in the
Dynamic State column. If you add multiple dynamic rule state filters to a rule, a number over the icon
indicates the number of filters.
If any required fields are blank, you receive an error message indicating which fields you must fill.
Tip To delete a rule comment, click Delete in the rule comments section. Note that 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.
The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, Preprocessor, and
Priority filter groups allow you to submit more than one argument for a keyword, separated by commas.
For example, you can press Shift and then select os-linux and os-windows from Category to produce the
filter Category:"os-windows,os-linux", which retrieves any rules in the os-linux category or in the
os-windows category.
• Reference under Rule Content is a keyword, and so are the specific reference ID types listed below
it. When you select 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 > Reference in 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 select 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 select multiple keywords, the system combines them using AND logic to create a
compound search filter. For example, if you select preprocessor under Category and then select 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 press Shift and then select 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 VRT 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). The following table describes the different rule filters.
Multiple
Argument
Filter Group Description Support? Heading is... Items in List are...
Rule Finds rules according to the configuration of the rule. See No A grouping keywords
Configuration Understanding Rule Configuration Filters, page 24-12.
Rule Content Finds rules according to the content of the rule. See No A grouping keywords
Understanding Rule Content Filters, page 24-14.
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.
See Understanding Rule Categories, page 24-16.
Classifications Finds rules according to the attack classification that No A keyword arguments
appears in the packet display of an event generated by the
rule. See Defining the Intrusion Event Classification,
page 27-12.
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.
Platform Finds rules according to their relevance to specific versions Yes A keyword arguments
Specific of operating systems. Note that if you pick
Note that a rule may affect more than one operating system one of the items
or more than one version of an operating system. For from the sub-list, it
example, enabling SID 2260 affects multiple versions of adds a modifier to
Mac OS X, IBM AIX, and other operating systems. the argument.
Preprocessors Finds rules for individual preprocessors. Yes A grouping sub-groupings
Note that you must enable preprocessor rules associated
with a preprocessor option to generate events for the option
when the preprocessor is enabled; see Setting Rule States,
page 24-19.
Multiple
Argument
Filter Group Description Support? Heading is... Items in List are...
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
that local rules (that is, rules that you create) do not appear from the sub-list, it
in the priority groups. adds a modifier to
the argument.
Rule Update Finds rules added or modified through a specific rule No A keyword arguments
update. 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.
• To find rules with a threshold type of both, select Both, then click OK.
• To find rules with thresholds tracked by source, select Source, then click OK.
• To find rules with thresholds tracked by destination, select Destination, then click OK.
• To find any rule with a threshold set, select All, then click OK.
The Rules page updates to display rules where the type of threshold indicated in the filter has been
applied to the rule.
Destination IP Type the destination IP address to filter Finds rules that use the specified addresses or
by, then click OK. variables for the source IP address designation in the
rule.
Note that 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 Type the source port to filter by, then Finds rules that include the specified source port.
click OK.
The port value must be an integer
between 1 and 65535 or a port variable.
Destination port Type the destination port to filter by, Finds rules that include the specified destination port.
then click OK.
The port value must be an integer
between 1 and 65535 or a port variable.
Note The Cisco VRT may use the rule update mechanism to add and remove rule categories.
Keyword:”argument”
where keyword is one of the keywords in the filter groups described in the Rule types table 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, Signature ID, and Generator ID. 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. For information on the rule Message field, see Defining the Event Message, page 27-11. 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
• login attempt cve:200 url:at
• login cve:200 attempt url:at
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Construct a filter by clicking on keywords or arguments in the filter panel on the left. Note that if you
click an argument for a keyword already in the filter, it replaces the existing argument. See the following
for more information:
• Guidelines for Constructing Intrusion Policy Rule Filters, page 24-10
• Understanding Rule Configuration Filters, page 24-12
• Understanding Rule Content Filters, page 24-14
• Understanding Rule Categories, page 24-16
• Editing a Rule Filter Directly, page 24-16
The page refreshes to display all matching rules, and the number of rules matching the filter is displayed
above the filter text box.
Step 5 Select the rule or rules where you want to apply a new setting. You have the following options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 Optionally, make any changes to the rule that you would normally make on the page. See the following
sections for more information:
• See Setting Rule States, page 24-19 for information on enabling and disabling rules on the Rules
page.
• See Filtering Intrusion Event Notification Per Policy, page 24-20 for information on adding
thresholding and suppression to rules.
• See Adding Dynamic Rule States, page 24-28 for information on setting dynamic rule states that
trigger when rate anomalies occur in matching traffic.
• See Adding SNMP Alerts, page 24-31 for information on adding SNMP alerts to specific rules.
• See Adding Rule Comments, page 24-32 for information on adding rule comments to rules.
Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache.
See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Note that this page indicates the total number of enabled rules, the total number of enabled rules set to
Generate Events, and the total number set to Drop and Generate Events. Note also that in a passive
deployment, rules set to Drop and Generate Events only generate events.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Locate the rule or rules where you want to set the rule state. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules where you want to set the rule state. You have the following options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 You have the following options:
• To generate events when traffic matches the selected rules, select Rule State > Generate Events.
• To generate events and drop the traffic in inline deployments when traffic matches the selected rules,
select Rule State > Drop and Generate Events.
• To not inspect traffic matching the selected rules, select Rule State > Disable.
Note Cisco strongly recommends that you do not enable all the intrusion rules in an intrusion policy. The
performance of your device is likely to degrade if all rules are enabled. Instead, tune your rule set to
match your network environment as closely as possible.
Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for
more information.
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.
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, you must specify tracking, which determines whether the event threshold is calculated per source
or destination IP address. Select one of the options from the following table to specify how the system
tracks event instances.
Option Description
Source Calculates event instance count per source IP address.
Destination Calculates event instance count per destination IP address.
Finally, you must 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. See Adding Dynamic Rule
States, page 24-28, Filtering Events, page 27-86, and Configuring Suppression Per Intrusion Policy,
page 24-25 for more information.
See the following sections for more information:
• Adding and Modifying Intrusion Event Thresholds, page 24-23
• Setting a Threshold for a Rule, page 24-6
• Viewing and Deleting Intrusion Event Thresholds, page 24-24
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Locate the rule or rules where you want to set a threshold. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules where you want to set a threshold. You have the following options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 Select Event Filtering > Threshold.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Locate the rule or rules that have a configured threshold you want to view or delete. You have the
following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules with a configured threshold you want to view or delete. You have the following
options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 To remove the threshold for each selected rule, select Event Filtering > Remove Thresholds. Click OK in the
confirmation pop-up window that appears.
Tip To remove a specific threshold, you can also highlight the rule and click Show details. Expand the
threshold settings, then click Delete next to the threshold settings you want to remove. Click OK to
confirm that you want to delete the configuration.
You can suppress intrusion event notification for a rule or rules. 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. Note that when two suppressions conflict, the action of
the first is carried out.
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists the rules alphabetically by message.
Step 4 Locate the rule or rules where you want to set suppression. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules for which you want to configure suppression conditions. You have the following
options:
• To select a specific rule, select the check box next to the rule.
• To select all rules in the current list, select the check box at the top of the column.
Step 6 Select Event Filtering > Suppression.
The suppression pop-up window appears.
Step 7 Select one of the following Suppression Type options:
• Select Rule to completely suppress events for a selected rule.
• Select Source to suppress events generated by packets originating from a specified source IP address.
• Select Destination to suppress events generated by packets going to a specified destination IP address.
Step 8 If you selected 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.
For information on using IPv4 CIDR and IPv6 prefix length address blocks, see IP Address Conventions,
page 1-4.
Step 9 Click OK.
The system adds your suppression conditions and displays an event filter icon ( ) next to the rule in
the Event Filtering column next the suppressed rule. If you add multiple event filters to a rule, a number
over the icon indicates the number of event filters.
Step 10 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache.
See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears. By default, the page lists rules alphabetically by message.
Step 4 Locate the rule or rules where you want to view or delete suppressions. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules for which you want to view or delete suppressions. You have the following
options:
• To select a specific rule, select the check box next to the rule.
• To select all rules in the current list, select the check box at the top of the column.
Step 6 You have two options:
• To remove all suppression for a rule, select Event Filtering > Remove Suppressions. Click OK in the
confirmation pop-up window that appears.
• To remove a specific suppression setting, highlight the rule and click Show details. Expand the
suppression settings and click Delete next to the suppression settings you want to remove. Click OK
to confirm that you want to delete your selected settings.
The page refreshes and the suppression settings are deleted.
Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for
more information.
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.
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 Dynamic rule states cannot enable disabled rules or drop traffic that matches disabled rules.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears.
Step 4 Locate the rule or rules where you want to add a dynamic rule state. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules where you want to add a dynamic rule state. You have the following options:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 Select Dynamic State > Add Rate-Based Rule State.
The Add Rate-Based Rule State dialog box appears.
Step 7 From the Track By drop-down list, select how you want the rule matches tracked:
• Select Source to track the number of hits for that rule from a specific source or set of sources.
• Select Destination to track the number of hits for that rule to a specific destination or set of
destinations.
• Select Rule to track all matches for that rule.
Step 8 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. For information on using IPv4 CIDR and IPv6 prefix length address blocks, see
IP Address Conventions, page 1-4.
Step 9 Next to Rate, indicate the number of rule matches per time period to set the attack rate:
• In the Count field, using an integer between 1 and 2147483647, specify the number of rule matches
you want to use as your threshold.
• In the Seconds field, using an integer between 1 and 2147483647, specify the number of seconds that
make up the time period for which attacks are tracked.
Step 10 From the New State drop-down list, specify the new action to be taken when the conditions are met:
Tip To delete all dynamic rule settings for a set of rules, select the rules on the Rules page, then select
Dynamic State > Remove Rate-Based States. You can also delete individual rate-based rule state filters from
the rule details for the rule by selecting the rule, clicking Show details, then clicking Delete by the
rate-based filter you want to remove.
Step 13 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache.
See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears.
Step 4 Locate the rule or rules where you want to set SNMP alerts. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules where you want to set SNMP alerts:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 Select Alerting > Add SNMP Alert.
The system adds the alert and displays an alert icon ( ) next to the rule in the Alerting column. If you
add multiple alert types to a rule, a number over the icon indicates the number of alert types.
Tip To remove an SNMP alert from a rule, click the check box next to the rule and select Alerting > Remove
SNMP Alerts, then click OK to confirm the deletion.
Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for
more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Rules.
The Rules page appears.
Step 4 Locate the rule or rules where you want to add a comment to a rule. You have the following options:
• To sort the current display, click on a column heading or icon. To reverse the sort, click again.
• Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more
information, see the following topics: Understanding Rule Filtering in an Intrusion Policy,
page 24-9 and Setting a Rule Filter in an Intrusion Policy, page 24-17.
The page refreshes to display all matching rules.
Step 5 Select the rule or rules where you want to add a comment:
• To select a specific rule, select the check box next to the rule.
• To select all the rules in the current list, select the check box at the top of the column.
Step 6 Select Comments > Add Rule Comment.
The Add Comment dialog box appears.
Step 7 In the Comment field, type the rule comment.
Step 8 Click OK.
The system adds the comment and 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.
Tip To delete a rule comment, highlight the rule and click Show Details, then click Delete in the Comments
section. Note that 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 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache.
See Managing Intrusion Policies, page 23-3 and Editing Intrusion Policies, page 23-4 for more
information.
You can use several preprocessors in a network analysis policy to detect specific threats to your
monitored network, such as Back Orifice attacks, several portscan types, and rate-based attacks that
attempt to overwhelm your network with excessive traffic. Note that when an intrusion rule or rule
argument requires a disabled preprocessor, the system automatically uses it with its current configuration
even though it remains disabled in the network analysis policy’s user interface. For more information,
see Limitations of Custom Policies, page 15-11.
You can also use sensitive data detection, which you configure in an intrusion policy, to detect unsecured
transmission of sensitive numerical data.
See the following sections for more information on detecting specific threats:
• Detecting Back Orifice, page 25-1 explains detection of Back Orifice attacks.
• Detecting Portscans, page 25-3 describes the different types of portscans and explains how you can
use portscan detection to identify threats to your networks before they develop into attacks.
• Preventing Rate-Based Attacks, page 25-9 explains how to limit denial of service (DoS) and SYN
flood attacks.
• Detecting Sensitive Data, page 25-19 explains how to detect and generate events on sensitive data
such as credit card numbers and Social Security numbers in ASCII text.
Preprocessor rule
GID:SID Description
105:1 Back Orifice traffic detected
105:2 Back Orifice client traffic detected
105:3 Back Orifice server traffic detected
105:4 Back Orifice snort buffer attack detected
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 In the navigation panel on the left, click Settings.
The Settings page appears.
Step 8 You have two choices, depending on whether Back Orifice Detection under Specific Threat Detection is
enabled:
• If the preprocessor is enabled, click Edit.
• If the preprocessor is disabled, click Enabled, then click Edit.
The Back Orifice Detection page appears. A message at the bottom of the page identifies the intrusion
policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy,
page 16-1 for more information.
Step 9 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
Detecting Portscans
License: Protection
A portscan is a form of network reconnaissance that is often used by attackers as a prelude to an attack.
In a portscan, an attacker sends specially crafted packets to a targeted host. By examining the packets
that the host responds with, the attacker can often determine which ports are open on the host and, either
directly or by inference, which application protocols are running on these ports.
Note that when portscan detection is enabled, you must enable rules on the intrusion policy Rules page
with generator ID (GID) 122 for enabled portscan types for the portscan detector to generate portscan
events. See Setting Rule States, page 24-19 and Table 25-5 on page 25-7 for more information.
By itself, a portscan is not evidence of an attack. In fact, some of the portscanning techniques used by
attackers can also be employed by legitimate users on your network. Cisco’s portscan detector is
designed to help you determine which portscans might be malicious by detecting patterns of activity.
Attackers are likely to use several methods to probe your network. Often they use different protocols to
draw out different responses from a target host, hoping that if one type of protocol is blocked, another
may be available. The following table describes the protocols you can activate in the portscan detector.
Protocol Description
TCP Detects TCP probes such as SYN scans, ACK scans, TCP connect() scans, and scans with
unusual flag combinations such as Xmas tree, FIN, and NULL
UDP Detects UDP probes such as zero-byte UDP packets
ICMP Detects ICMP echo requests (pings)
IP Detects IP protocol scans. These scans differ from TCP and UDP scans because the attacker,
instead of looking for open ports, is trying to discover which IP protocols are supported on
a target host.
Note For events generated by the portscan connection detector, the protocol number is set to 255. Because
portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers
Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved
number, so that number is used in portscan events to indicate that there is not an associated protocol for
the event.
Portscans are generally divided into four types based on the number of targeted hosts, the number of
scanning hosts, and the number of ports that are scanned. The following table describes the kinds of
portscan activity you can detect.
Type Description
Portscan Detection A one-to-one portscan in which an attacker uses one or a few hosts to scan
multiple ports on a single target host.
One-to-one portscans are characterized by:
• a low number of scanning hosts
• a single host that is scanned
• a high number of ports scanned
This option detects TCP, UDP, and IP portscans.
Port Sweep A one-to-many portsweep in which an attacker uses one or a few hosts to scan a
single port on multiple target hosts.
Portsweeps are characterized by:
• a low number of scanning hosts
• a high number of scanned hosts
• a low number of unique ports scanned
This option detects TCP, UDP, ICMP, and IP portsweeps.
Decoy Portscan A one-to-one portscan in which the attacker mixes spoofed source IP addresses
with the actual scanning IP address.
Decoy portscans are characterized by:
• a high number of scanning hosts
• a low number of ports that are scanned only once
• a single (or a low number of) scanned hosts
The decoy portscan option detects TCP, UDP, and IP protocol portscans.
Distributed Portscan A many-to-one portscan in which multiple hosts query a single host for open
ports.
Distributed portscans are characterized by:
• a high number of scanning hosts
• a high number of ports that are scanned only once
• a single (or a low number of) scanned hosts
The distributed portscan option detects TCP, UDP, and IP protocol portscans.
The information that the portscan detector learns about a probe is largely based on seeing negative
responses from the probed hosts. For example, when a web client tries to connect to a web server, the
client uses port 80/tcp and the server can be counted on to have that port open. However, when an
attacker probes a server, the attacker does not know in advance if it offers web services. When the
portscan detector sees a negative response (that is, an ICMP unreachable or TCP RST packet), it records
the response as a potential portscan. The process is more difficult when the targeted host is on the other
side of a device such as a firewall or router that filters negative responses. In this case, the portscan
detector can generate filtered portscan events based on the sensitivity level that you select.
The following table describes the three different sensitivity levels you can choose from.
Level Description
Low Detects only negative responses from targeted hosts. Select this sensitivity level to suppress
false positives, but keep in mind that some types of portscans (slow scans, filtered scans)
might be missed.
This level uses the shortest time window for portscan detection.
Medium Detects portscans based on the number of connections to a host, which means that you can
detect filtered portscans. However, very active hosts such as network address translators and
proxies may generate false positives.
Note that you can add the IP addresses of these active hosts to the Ignore Scanned field to
mitigate this type of false positive.
This level uses a longer time window for portscan detection.
High Detects portscans based on a time window, which means that you can detect time-based
portscans. However, if you use this option, you should be careful to tune the detector over
time by specifying IP addresses in the Ignore Scanned and Ignore Scanner fields.
This level uses a much longer time window for portscan detection.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
You can specify a single IP address or address block, or a comma-separated lists of either or both. For
information on using IPv4 and IPv6 address blocks, see IP Address Conventions, page 1-4.
Step 14 Optionally, in the Ignore Scanned field, specify which hosts you want to ignore as the target of a scan. Use
this field to indicate hosts on your network that are especially active. You may need to modify this list
of hosts over time.
You can specify a single IP address or address block, or a comma-separated lists of either or both. For
information on using IPv4 and IPv6 address blocks, see IP Address Conventions, page 1-4.
Step 15 Optionally, clear the Detect Ack Scans check box to discontinue monitoring of sessions picked up in
mid-stream.
Note Detection of mid-stream sessions helps to identify ACK scans, but may cause false events, particularly
on networks with heavy traffic and dropped packets.
Step 16 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
When you enable the accompanying preprocessor rules, the portscan detector generates intrusion events
that you can view just as you would any other intrusion event. However, the information presented on
the packet view is different from the other types of intrusion events. This section describes the fields that
appear on the packet view for a portscan event and how you can use that information to understand the
types of probes that occur on your network.
Begin by using the intrusion event views to drill down to the packet view for a portscan event.
Note that you cannot download a portscan packet because single portscan events are based on multiple
packets; however, the portscan packet view provides all usable packet information.
Note For events generated by the portscan connection detector, the protocol number is set to 255. Because
portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers
Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved
number, so that number is used in portscan events to indicate that there is not an associated protocol for
the event.
The following table describes the information provided in the packet view for portscan events.
Information Description
Device The device that detected the event.
Time The time when the event occurred.
Message The event message generated by the preprocessor.
Source IP The IP address of the scanning host.
Destination IP The IP address of the scanned host.
Information Description
Priority Count The number of negative responses (for example, TCP RSTs and ICMP
unreachables) from the scanned host. The higher the number of negative
responses, the higher the priority count.
Connection Count The number of active connections on the hosts. This value is more accurate for
connection-based scans such as TCP and IP.
IP Count The number of times that the IP addresses that contact the scanned host changes.
For example, if the first IP address is 10.1.1.1, the second IP is 10.1.1.2, and the
third IP is 10.1.1.1, then the IP count is 3.
This number is less accurate for active hosts such as proxies and DNS servers.
Scanner/Scanned The range of IP addresses for the scanned hosts or the scanning hosts, depending
IP Range on the type of scan. For portsweeps, this field shows the IP range of scanned
hosts. For portscans, this shows the IP range of the scanning hosts.
Port/Proto Count For TCP and UDP portscans, the number of times that the port being scanned
changes. For example, if the first port scanned is 80, the second port scanned is
8080, and the third port scanned is again 80, then the port count is 3.
For IP protocol portscans, the number of times that the protocol being used to
connect to the scanned host changes.
Port/Proto Range For TCP and UDP portscans, the range of the ports that were scanned.
For IP protocol portscans, the range of IP protocol numbers that were used to
attempt to connect to the scanned host.
Open Ports The TCP ports that were open on the scanned host. This field appears only when
the portscan detects one or more open ports.
You can configure your network analysis policy to include rate-based filters that detect excessive activity
directed at hosts on your network. You can use this feature on a device deployed in inline mode to block
rate-based attacks for a specified time, then revert to only generating events and not drop traffic.
Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize the impact of
that traffic on legitimate requests. Rate-based attacks usually have one of the following characteristics:
• any traffic containing excessive incomplete connections to hosts on the network, indicating a SYN
flood attack
To configure SYN attack detection, see Preventing SYN Attacks, page 25-11.
• any traffic containing excessive complete connections to hosts on the network, indicating a TCP/IP
connection flood attack
To configure simultaneous connection detection, see Controlling Simultaneous Connections,
page 25-12.
• excessive rule matches in traffic going to a particular destination IP address or addresses or coming
from a particular source IP address or addresses.
To configure source or destination-based dynamic rule states, see Setting a Dynamic Rule State,
page 24-29.
• excessive matches for a particular rule across all traffic.
To configure rule-based dynamic rule states, see Setting a Dynamic Rule State, page 24-29.
In a network analysis policy, you can either configure SYN flood or TCP/IP connection flood detection
for the entire policy; in an intrusion policy, you can set rate-based filters for individual intrusion or
preprocessor rules. Note that manually adding a rate-based filter to rules 135:1 and 135:2 has no effect.
Rules with GID:135 use the client as the source value and the server as the destination value. See
Preventing SYN Attacks, page 25-11 and Controlling Simultaneous Connections, page 25-12 for more
information.
Each rate-based filter contains several components:
• for policy-wide or rule-based source or destination settings, the network address designation
• the rule matching rate, which you configure as a count of rule matches within a specific number of
seconds
• a new action to be taken when the rate is exceeded
When you set a rate-based setting for the entire policy, the system generates events when it detects
a rate-based attack, and optionally can drop the traffic in an inline deployment. When setting
rate-based actions for individual rules, you have three available actions: Generate Events, Drop and
Generate Events, and Disable.
• the duration of the action, which you configure as a timeout value
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 period expires, if the rate has fallen below
the threshold, the action for the rule reverts to the action initially configured for the rule. For policy-wide
settings, the action reverts to the action of each rule the traffic matches or stops if it does not match any
rules.
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 create
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. However, if
you set a rate-based filter at the policy level, you can generate events on or generate events on and drop
traffic that contains an excessive number of SYN packets or SYN/ACK interactions within a designated
time period.
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 system implements the
action of the first rate-based filter. Similarly, policy-wide rate-based filters override rate-based filters set
on individual rules if the filters conflict.
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 generating events only after a sampling period completes where the
sampled rate is below the threshold rate.
Enabling this option also activates rule 135:1. Manually activating this rule has no effect. The rule state
is always displayed as Disabled, and never changes. The rule generates events when this option is
enabled and a defined rate condition is exceeded.
As shown in the diagram, the first five packets matching the rule do not generate events because the rule
does not trigger until the rate exceeds the rate indicated by the detection_filter keyword. After the
rule triggers, event notification begins, but the rate-based criteria do not trigger the new action of Drop
and Generate Events until five more packets pass.
After the rate-based criteria are met, events are generated and the packets are dropped until the
rate-based timeout period expires and the rate falls below the threshold. After twenty seconds elapse, the
rate-based action times out. After the timeout, note that packets are still dropped in the rate-based
sampling period that follows. Because the sampled rate is above the threshold rate in the previous
sampling period when the timeout happens, the rate-based action continues.
Note that although the example does not depict this, you can use the Drop and Generate Events rule state
in combination with the detection_filter keyword to start dropping traffic when hits for the rule reach
the specified rate. When deciding whether to configure rate-based settings for a rule, consider whether
setting the rule to Drop and Generate Events and including the detection_filter keyword would
achieve the same result, or whether you want to manage the rate and timeout settings in the intrusion
policy. For more information, see Setting Rule States, page 24-19.
You can use thresholding and suppression to reduce excessive events by limiting the number of event
notifications for a rule or by suppressing notifications altogether for that rule. For more information on
the available options for thresholding and suppression, see Configuring Event Thresholding, page 24-21
and Configuring Suppression Per Intrusion Policy, page 24-25.
If you apply suppression to a rule, the system suppresses event notifications for that rule for all
applicable IP addresses even if a rate-based action change occurs. However, the interaction between
thresholding and rate-based criteria is more complex.
The following example shows an attacker attempting a brute-force login. Repeated attempts to find a
password trigger a rule that has rate-based attack prevention configured. The rate-based settings change
the rule attribute to Drop and Generate Events for 15 seconds when there are five hits on the rule in 10
seconds. In addition, a limit threshold limits the number of events the rule can generate to 10 events in
23 seconds.
As shown in the diagram, the rule generates events for the first five matching packets. After five packets,
the rate-based criteria trigger the new action of Drop and Generate Events, and for the next five packets
the rule generates events and the system drops the packet. After the tenth packet, the limit threshold has
been reached, so for the remaining packets the system does not generate events but does drop the packets.
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 rate 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 is below the threshold rate.
Note that although it is not shown in this example, if a new action triggers because of rate-based criteria
after a threshold has been reached, the system generates a single event to indicate the change in action.
So, for example, when the limit threshold of 10 is reached and the system stops generating events and
the action changes from Generate Events to Drop and Generate Events on the 14th packet, the system
generates an eleventh event to indicate the change in action.
Note that although it is not shown in this example, if a new action triggers because of rate-based criteria
after a threshold has been reached, the system generates a single event to indicate the change in action.
So, for example, if the limit threshold of 10 has been reached and the system stops generating events and
the action changes to Drop and Generate events on the 14th packet, the system generates an eleventh
event to indicate the change in action.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon ( ) next to Network Analysis and Intrusion Policies.
The Network Analysis and Intrusion Policies pop-up window appears.
Step 5 Click Network Analysis Policy List.
The Network Analysis Policy List pop-up window appears.
Step 6 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 7 In the navigation panel on the left, click Settings.
The Settings page appears.
Step 8 You have two choices, depending on whether Rate-Based Attack Prevention under Specific Threat Detection
is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Rate-Based Attack Prevention page appears. A message at the bottom of the page identifies the
intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or
Intrusion Policy, page 16-1 for more information.
Step 9 You have two options:
• To prevent incomplete connections intended to flood a host, click Add under SYN Attack Prevention.
The SYN Attack Prevention dialog box appears.
• To prevent excessive numbers of connections, click Add under Control Simultaneous Connections.
The Control Simultaneous Connections dialog box appears.
Step 10 Select how you want to track traffic:
• To track all traffic from a specific source or range of sources, select Source from the Track By
drop-down list and type a single IP address or address block in the Network field.
• To track all traffic to a specific destination or range of destinations, select Destination from the Track
By drop-down list and type an IP address or address block in the Network field.
Note that the system tracks traffic separately for each IP address included in the Network field. Traffic
from an IP address that exceeds the configured rate results in generated events only for that IP address.
As an example, you might set a source CIDR block of 10.1.0.0/16 for the network setting and configure
the system to generate events when there are ten simultaneous connections open. If eight connections
are open from 10.1.4.21 and six from 10.1.5.10, the system does not generate events, because neither
source has the triggering number of connections open. However, if eleven simultaneous connections are
open from 10.1.4.21, the system generates events only for the connections from 10.1.4.21.
For information on using CIDR notation and prefix lengths, see IP Address Conventions, page 1-4.
Step 11 Indicate the triggering rate for the rate tracking setting:
• For SYN attack configuration, indicate the number of SYN packets per number of seconds in the
Rate fields.
• For simultaneous connection configuration, indicate the number of connections in the Count field.
Step 12 To drop packets matching the rate-based attack prevention settings, select Drop.
Step 13 In the Timeout field, indicate the time period after which to stop generating events, and if applicable,
dropping, for traffic with the matching pattern of SYNs or simultaneous connections.
Caution Timeout values can be integers from 1 to 1,000,000. However, setting a high timeout value may entirely
block connection to a host in an inline deployment.
Step 14 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
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 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. Cisco 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.
See the following sections for more information:
• Deploying Sensitive Data Detection, page 25-20
• Selecting Global Sensitive Data Detection Options, page 25-20
• Selecting Individual Data Type Options, page 25-21
• Using Predefined Data Types, page 25-22
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 user
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. For information on using IPv4 and IPv6 address
blocks, see IP Address Conventions, page 1-4.
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. See Selecting Individual Data Type Options,
page 25-21 for more information.
Note the following points regarding global thresholds:
– You must enable preprocessor rule 139:1 to detect and generate events on combined data type
occurrences. See Setting Rule States, page 24-19 for information on enabling rules in your
intrusion policy.
– 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.
Option Description
Data Type Displays the unique name for the data type.
Threshold Specifies the number of occurrences of the data type when the system generates
an event. You receive an error message when you save the policy if you do not set
a threshold for an enabled data type. 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.
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. You
receive an error message when you save the policy if you enable the rule for a data
type without setting at least one port or application protocol for the data type.
Application Specifies up to eight application protocols to monitor for the data type. You
Protocols receive an error message when you save the policy if you enable the rule for a data
type without setting at least one port or application protocol for the data type.
Note that this
feature requires a See Selecting Application Protocols to Monitor, page 25-25 for detailed
Control license. instructions for selecting application protocols for data types.
Pattern For a custom data type, the specified pattern to detect (data patterns for data types
provided by Cisco are predefined). See Using Custom Data Types, page 25-27 for
more information. The user interface does not display built-in patterns for
predefined data types.
Note that custom and predefined data patterns are system-wide.
Preprocessor Rule
Data Type Description GID:SID
Credit Card Numbers Matches Visa®, MasterCard®, Discover® and American Express® 138:2
fifteen- and sixteen-digit credit card numbers, with or without their
normal separating dashes or spaces; also uses the Luhn algorithm to
verify credit card check digits.
Email Addresses Matches email addresses. 138:5
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 3-digit 138:4
Numbers Without Dashes area numbers, valid 2-digit group numbers, and do not have dashes.
U.S. Social Security Matches 9-digit U.S. Social Security numbers that have valid 3-digit 138:3
Numbers With Dashes area numbers, valid 2-digit group numbers, and dashes.
Custom Matches a user-defined data pattern in the specified traffic. See Using 138:>999999
Custom Data Types, page 25-27 for more information.
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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is
enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Sensitive Data Detection page appears. A message at the bottom of the page identifies the intrusion
policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy,
page 16-1 for more information.
Step 5 You can take any of the actions described in the Sensitive Data Configuration Actions table.
Step 6 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is
enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Sensitive Data Detection page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration.
See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more information.
Step 5 Click the data type name under Data Types to select the data type you want to modify.
The Configuration area updates to display the current settings for the selected data type.
Step 6 Click inside the Application Protocols field, or click Edit next to the field.
The Application Protocols pop-up window appears.
Step 7 You have two choices:
• To add up to eight application protocols to monitor, select one or more application protocols from
the Available list on the left, then click the right arrow (>) button.
• To remove an application protocol, select it from the Enabled list on the right, then click the left arrow
(<) button.
Use Ctrl or Shift while clicking to select multiple application protocols. You can also click and drag to
select multiple adjacent application protocols.
Note To detect sensitive data in FTP traffic, you must add the FTP data application protocol. See Special
Case: Detecting Sensitive Data in FTP Traffic, page 25-26 for more information.
You must use a backslash to escape the characters in the following table for the sensitive data
preprocessor to interpret them correctly as literal characters.
The following table describes the character classes you can use when defining a custom sensitive data
pattern.
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 predefined 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is
enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Sensitive Data Detection page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration.
See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more information.
Step 5 In the Targets page area, click the name of the custom data type you want to modify.
The page updates to show the current settings for the data type, and the Edit Data Type Name and Pattern
link appears in the upper right of the Configuration page area.
Step 6 Click the Edit Data Type Name and Pattern link.
The Edit Data Type pop-up window appears.
Step 7 Modify the data type name, pattern, or both and click OK, or click Cancel to abandon your edits. See
Defining Data Patterns in Custom Data Types, page 25-27 for information on specifying the data pattern.
The Sensitive Data Detection page appears. If you clicked OK, the page displays your changes.
You can use thresholds to limit the number of times the system logs and displays intrusion events.
Thresholds, which you configure as part of your intrusion policy, cause the system to generate events
based on how many times traffic matching a rule originates from or is targeted to a specific address or
address range within a specified time period. This can prevent you from being overwhelmed with a large
number of events. This feature requires a Protection license.
You can set event notification thresholds in two ways:
• You can set a global threshold across all traffic to limit how often events from a specific source or
destination are logged and displayed per specified time period. For more information, see
Understanding Thresholding, page 26-1 and Configuring Global Thresholds, page 26-3.
• You can set thresholds per shared object rule, standard text rule, or preprocessor rule in your
intrusion policy configuration, as described in Configuring Event Thresholding, page 24-21.
Understanding Thresholding
License: Protection
By default, every intrusion policy contains a global rule threshold. The default threshold limits event
generation for each rule to one event every 60 seconds on traffic going to the same destination. This
global threshold applies by default to all intrusion rules and preprocessor rules. Note that you can disable
the threshold in the Advanced Settings page in an intrusion policy.
You can also override this threshold by setting individual thresholds on specific rules. For example, you
might set a global limit threshold of five events every 60 seconds, but then set a specific threshold of ten
events for every 60 seconds for SID 1315. All other rules generate no more than five events in each
60-second period, but the system generates up to ten events for each 60-second period for SID 1315.
For more information on setting rule-based thresholds, see Configuring Event Thresholding, page 24-21.
The following diagram shows an example where an attack is in progress for a specific rule. A global limit
threshold limits 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, note that 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.
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)
Next, specify the tracking, which determines whether the event instance count is calculated per source
or destination 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 or address range 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, 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Global Rule Thresholding under Intrusion Rule Thresholds is
enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Global Rule Thresholding page appears. A message at the bottom of the page identifies the intrusion
policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy,
page 16-1 for more information.
Step 5 From the Type radio buttons, select the type of threshold that will apply over the time specified by the
seconds argument. See the Thresholding Options table for more information:
• Select Limit to log and display an event for each packet that triggers the rule until the limit specified
by the count argument is exceeded.
• Select Threshold to log and display a single event for each packet that triggers the rule and represents
either the instance that matches the threshold set by the count argument or is a multiple of the
threshold.
• Select Both to log and display a single event after the number of packets specified by the count
argument trigger the rule.
Step 6 Select the tracking method from the Track By radio buttons:
• Select Source to identify rule matches in traffic coming from a particular source IP address or
addresses.
• Select Destination to identify rule matches in traffic going to a particular destination IP address.
Step 7 In the Count field:
• For a Limit threshold, specify the number of event instances per specified time period per tracking IP
address required to meet the threshold.
• For a Threshold threshold, specify the number of rule matches you want to use as your threshold.
Step 8 In the Seconds field:
• For a Limit threshold, specify the number of seconds that make up the time period when attacks are
tracked.
• For a Threshold threshold, specify the number of seconds that elapse before the count resets. Note
that the count resets if the number of rule matches indicated by the Count field occur before the
number of seconds indicated elapse.
Step 9 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Settings in the navigation panel on the left.
The Settings page appears.
Step 4 Under Intrusion Rule Thresholds, disable Global Rule Thresholding.
Step 5 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the
system cache. See Resolving Conflicts and Committing Policy Changes, page 15-15 for more
information.
An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit
vulnerabilities on your network by analyzing network traffic to check if it matches the criteria in the rule.
The system compares packets against the conditions specified in each rule and, if the packet data matches
all the conditions specified in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion
event. If it is a pass rule, it ignores the traffic. You can view and evaluate intrusion events from the ASA
FirePOWER module interface.
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.
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. For more information, see
Limitations of Custom Policies, page 15-11.
Note that the options section of a rule is the section enclosed in parentheses. The rule 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.
Note The previous example uses default variables, as do most intrusion rules. See Working with Variable Sets,
page 2-13 for more information about variables, what they mean, and how to configure them.
See the following sections for more information about rule header parameters:
• Specifying Rule Actions, page 27-4 describes rule types and explains how to specify the action that
occurs when the rule triggers.
• Specifying Protocols, page 27-4 explains how to define the traffic protocol for traffic that the rule
should test.
• Specifying IP Addresses In Intrusion Rules, page 27-5 explains how to define the individual IP
addresses and IP address blocks in the rule header.
• Defining Ports in Intrusion Rules, page 27-8 explains how to define the individual ports and port
ranges in the rule header.
• Specifying Direction, page 27-9 describes the available operators and explains how to specify the
direction traffic must be traveling to be tested by the rule.
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. For more information on drop rules, see Setting Rule States, page 24-19.
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 rule editor, you select the rule type from the Action list. For more information about the
procedures you use to build a rule header using the rule editor, see Constructing a Rule, page 27-100.
Specifying Protocols
License: Protection
In each rule header, you must specify the protocol of the traffic the rule inspects. You can specify the
following network protocols for analysis:
• ICMP (Internet Control Message Protocol)
• IP (Internet Protocol)
Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more
information, see Defining Ports in Intrusion Rules, page 27-8.
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 rule editor, you select the protocol type from the Protocol list. See Constructing a Rule,
page 27-100 for more information about the procedures you use to build a rule header using the rule
editor.
Tip The system recognizes only IP addresses and does not accept host names for source or destination IP
addresses.
Within the rule editor, you specify source and destination IP addresses in the Source IPs and Destination
IPs fields. See Constructing a Rule, page 27-100 for more information about the procedures you use to
build a rule header using the rule editor.
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.
The following table summarizes the various ways you can specify source and destination IP addresses.
See the following sections for more in-depth information about the syntax you can use to specify source
and destination IP addresses, and for information about using variables to specify IP addresses:
• IP Address Conventions, page 1-4.
• Working with Variable Sets, page 2-13
• Specifying Any IP Address, page 27-6
• Specifying Multiple IP Addresses, page 27-6
• Specifying Network Objects, page 27-7
• Excluding IP Addresses in Intrusion Rules, page 27-7
[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.
Note You must surround negated lists with brackets. See Excluding IP Addresses in Intrusion Rules, page 27-7
for more information.
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. For more information, see IP Address
Conventions, page 1-4.
• 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.
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.
Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more
information, see Specifying Protocols, page 27-4.
You can list ports by separating the ports with commas, as shown in the following example:
80, 8080, 8138, 8600-9000, !8650-8675
Optionally, the following example shows how you can surround a port list with brackets, which was
required in previous software versions but is no longer required:
[80, 8080, 8138, 8600-9000, !8650-8675]
Note that you must surround negated port lists in brackets, as shown in the following example:
![20, 22, 23]
Note also that a list of source or destination ports in an intrusion rule can include a maximum of 64
characters.
The following table summarizes the syntax you can use:
a range of ports a dash between the first and last port number in the range 80-443
all ports less than or equal a dash before the port number -21
to a specific port
all ports greater than or a dash after the port number 80-
equal to a specific port
all ports except a specific the ! character before the port, port list, or range of ports you want to negate !20
port or range of ports 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 the variable name, in uppercase letter, preceded by $ $HTTP_PORTS
variable See Working with Port Variables, page 2-25 for more information.
all ports except ports the variable name, in uppercase letter, preceded by !$ !$HTTP_PORTS
defined by a port variable
Specifying Direction
License: Protection
Within the rule header, you can specify the direction that the packet must travel for the rule to inspect it.
The following table describes these options.
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
See Constructing a Rule, page 27-100 for more information about the procedures you use to build a rule
header using the rule editor.
Note that you can also use adaptive profiles to dynamically adapt active rule processing for specific
packets based on rule metadata and host information. For more information, see Tuning Preprocessing
in Passive Deployments, page 22-1.
See the following sections for more information:
• Defining Intrusion Event Details, page 27-11 describes the syntax and use of keywords that allow
you to define the event’s message, priority information, and references to external information about
the exploit the rule detects.
• Searching for Content Matches, page 27-15 describes how to use the content or
protected_content keywords to test the content of the packet payload.
• Constraining Content Matches, page 27-17 describes how to use modifying keywords for the
content or protected_content keywords.
• Replacing Content in Inline Deployments, page 27-29 describes how to use the replace keyword in
inline deployments to replace specified content of equal length.
• Using Byte_Jump and Byte_Test, page 27-30 describes how to use the byte_jump and byte_test
keywords to calculate where in a packet the rules engine should begin testing for a content match,
and which bytes it should evaluate.
• Searching for Content Using PCRE, page 27-34 describes how to use the pcre keyword to use
Perl-compatible regular expressions in rules.
• Adding Metadata to a Rule, page 27-41 describes how to use the metadata keyword to add
information to a rule.
• Inspecting IP Header Values, page 27-44 describes the syntax and use of keywords that test values
in the packet’s IP header.
• Inspecting ICMP Header Values, page 27-47 describes the syntax and use of keywords that test
values in the packet’s ICMP header.
• Inspecting TCP Header Values and Stream Size, page 27-49 describes the syntax and use of
keywords that test values in the packet’s TCP header.
• Enabling and Disabling TCP Stream Reassembly, page 27-53 describes how to enable and disable
stream reassembly for a single connection when inspected traffic on the connection matches the
conditions of the rule.
• Extracting SSL Information from a Session, page 27-53 describes the use and syntax of keywords
that extract version and state information from encrypted traffic.
• Reading Packet Data into Keyword Arguments, page 27-80 describes how to read a value from a
packet into a variable that you can use later in the same rule to specify the value for arguments in
certain other keywords.
• Inspecting Application Layer Protocol Values, page 27-55 describes the use and syntax of keywords
that test application layer protocol properties.
• Inspecting Packet Characteristics, page 27-78 describes the use and syntax of the dsize, sameIP,
isdataat, fragoffset, and cvs keywords.
• Initiating Active Responses with Rule Keywords, page 27-83 explains how to use the resp keyword
to actively close TCP connections or UDP sessions, the react keyword to send an HTML page and
then actively close TCP connections, and the config response command to specify the active
response interface and the number of TCP resets to attempt in a passive deployment.
• Filtering Events, page 27-86 describes how to prevent a rule from triggering an event unless a
specified number packets meet the rule’s detection criteria within a specified time.
• Evaluating Post-Attack Traffic, page 27-87 describes how to log additional traffic for the host or
session.
• Detecting Attacks That Span Multiple Packets, page 27-88 describes how to assign state names to
packets from attacks that span multiple packets in a single session, then analyze and alert on packets
according to their state.
• Generating Events on the HTTP Encoding Type and Location, page 27-93 describes how to generate
events on the type of encoding in an HTTP request or response URI, header, or cookie, including
set-cookies, before normalization.
• Detecting File Types and Versions, page 27-95 describes how to point to a specific file type or file
version using the file_type or file_group keyword.
• Pointing to a Specific Payload Type, page 27-96 describes how to point to the beginning of the
HTTP response entity body, SMTP payload, or encoded email attachment.
• Pointing to the Beginning of the Packet Payload, page 27-98 describes how to point to the beginning
of the packet payload.
• Decoding and Inspecting Base64 Data, page 27-98 describes how you can use the base64_decode
and base64_data keywords to decode and inspect Base64 data, especially in HTTP requests.
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 rule editor, enter the event message in the Message field. See
Constructing a Rule, page 27-100 for more information about using the rule editor to build rules.
To specify a classification in the rule editor, select a classification from the Classification list. See Writing
New Rules, page 27-100 for more information on the rule editor.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Step 2 Click Create Rule.
The Create Rule page appears.
Step 3 Under the Classification drop-down list, click Edit Classifications.
A pop-up window appears.
Step 4 Type the name of the classification in the Classification Name field.
You can use up to 255 alphanumeric characters, but the page is difficult to read if you use more than 40
characters. The following characters are not supported: <>()\'"&$; and the space character.
Step 5 Type a description of the classification in the Classification Description field.
You can use up to 255 alphanumeric characters and spaces. The following characters are not supported:
<>()\'"&$;
To specify a reference using the rule editor, select reference from the Detection Options list, and enter a
value in the corresponding field as follows:
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 following in the reference field:
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.
See Constructing a Rule, page 27-100 for more information about using the rule editor to build rules.
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.
Option Description
Hash Type New option for the protected_content rule keyword. For
more information, see Hash Type, page 27-18.
Case Insensitive Not supported
Within Not supported
Depth Not supported
Length New option for the protected_content rule keyword. For
more information, see Length, page 27-21.
Use Fast Pattern Matcher Not supported
Fast Pattern Matcher Only Not supported
Fast Pattern Matcher Offset and Length Not supported
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.
Note that all content matches must be true for the rule to trigger an event, that is, each content match has
an AND relationship with the others.
Note also that, in an inline deployment, you can set up rules that match malicious content and then
replace it with your own text string of equal length. See Replacing Content in Inline Deployments,
page 27-29 for more information.
Step 1 In the content field, type the content you want to find (for example, |90C8 C0FF FFFF|/bin/sh).
If you want to search for any content that is not the specified content, select the Not check box.
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. For more information, see Not, page 27-19.
Step 2 Optionally, add additional keywords that modify the content keyword or add constraints for the
keyword.
For more information on other keywords, see Understanding Keywords and Arguments in Rules,
page 27-9. For more information on constraining the content keyword, see Constraining Content
Matches, page 27-17.
Step 3 Continue with creating or editing the rule.
See Writing New Rules, page 27-100 or Modifying Existing Rules, page 27-102 for more information.
Step 1 Using a SHA-512, SHA-256, or MD5 hash generator, encode the content you want to find (for example,
run the string Sample1 through a SHA-512 hash generator).
The generator outputs a hash for your string.
Step 2 In the protected_content field, type the hash you generated in step 1 (for example,
B20AABAF59605118593404BD42FE69BD8D6506EE7F1A71CE6BB470B1DF848C814BC5DBEC2081999F15691A7
1FAECA5FBA4A3F8B8AB56B7F04585DA6D73E5DD15).
If you want to search for any content that is not the specified content, select the Not check box.
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. For more information, see Not, page 27-19.
Step 3 From the Hash Type drop-down list, select the hash function you used in step 1 (for example, SHA-512).
Note that the number of bits in the hash entered in step 2 must match the hash type or the system does
not save the rule. For more information, see Hash Type, page 27-18.
Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function.
Step 4 Type a value in the required Length field. The value must correspond with the length of the original,
unhashed string you want to find (for example, the string Sample1 from step 2 has the length 7).
For more information, see Length, page 27-21.
Step 5 Type a value in either the Offset or Distance field. You cannot mix the Offset and Distance options within a
single keyword configuration.
For more information, see Using Search Location Options in the protected_content Keyword,
page 27-22.
Step 6 Optionally, add additional constraining options that modify the protected_content keyword.
For more information, see Constraining Content Matches, page 27-17.
Step 7 Optionally, add additional keywords that modify the protected_content keyword.
For more information, see Understanding Keywords and Arguments in Rules, page 27-9.
Step 8 Continue with creating or editing the rule.
See Writing New Rules, page 27-100 or Modifying Existing Rules, page 27-102 for more information.
Case Insensitive
License: Protection
Note This option is not supported when configuring the protected_content keyword. For more information,
see Using the protected_content Keyword, page 27-15.
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.
Step 1 Select Case Insensitive for the content keyword you are adding.
Step 2 Continue with creating or editing the rule.
See Constraining Content Matches, Searching for Content Matches, page 27-15, Writing New Rules,
page 27-100 or Modifying Existing Rules, page 27-102 for more information.
Hash Type
License: Protection
Note This option is only configurable with the protected_content keyword. For more information, see Using
the protected_content Keyword, page 27-15.
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.
Step 1 From the Hash Type drop-down list, select Default, SHA-512, SHA-256, or MD5 as the hash for the
protected_content keyword you are adding.
Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function. For more
information, see Hash Type, page 27-18.
Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content
Matches, page 27-15, Writing New Rules, page 27-100, or Modifying Existing Rules, page 27-102 for
more information.
Raw Data
License: Protection
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. See HTTP Content Options, page 27-23 for more information.
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. For more
information, see Selecting Server-Level HTTP Normalization Options, page 19-33.
Step 1 Select the Raw Data check box for the content or protected_content keyword you are adding.
Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content
Matches, page 27-15, Writing New Rules, page 27-100, or Modifying Existing Rules, page 27-102 for
more information.
Not
License: Protection
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.
To search for content that does not match the specified content:
Step 1 Select the Not check box for the content or protected_content keyword you are adding.
Tip You cannot select the Not check box and the Use Fast Pattern Matcher check box with the same content
keyword.
Step 2 Include in the rule at least one other content or protected_content keyword that does not have the Not
option selected.
Step 3 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content
Matches, page 27-15, Writing New Rules, page 27-100, or Modifying Existing Rules, page 27-102 for
more information.
Depth
Note This option is only supported when configuring the content keyword. For more information, see Using
the content Keyword, page 27-15.
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. For more information,
see Using the protected_content Keyword, page 27-15.
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. For more information, see Using
the content Keyword, page 27-15.
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.
You can use either of two content location pairs to specify where to begin searching for the specified
content and how far to continue searching, as follows:
• Use Offset and Depth together to search relative to the beginning of the packet payload.
• Use Distance and Within together to search relative to the current search location.
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. See
Reading Packet Data into Keyword Arguments, page 27-80 for more information.
Step 1 Type the value in the field for the content keyword you are adding. You have the following choices:
• Offset
• Depth
• Distance
• Within
You can use any number of location options in a rule.
Step 2 Continue with creating or editing the rule. See Constraining Content Matches, page 27-17, Searching for
Content Matches, page 27-15, Writing New Rules, page 27-100 or Modifying Existing Rules,
page 27-102 for more information.
Use the required Length protected_content location option in combination with either the Offset or
Distance location option to specify where to begin searching for the specified content and how far to
continue searching, as follows:
• 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. For more
information, see Reading Packet Data into Keyword Arguments, page 27-80.
Step 1 Type the value in the field for the protected_content keyword you are adding. You have the following
choices:
• Length (required)
• Offset
• Distance
You cannot mix the Offset and Distance options within a single protected_content keyword, but you can
use any number of location options in a rule.
Step 2 Continue with creating or editing the rule. See Constraining Content Matches, page 27-17, Searching for
Content Matches, page 27-15, Writing New Rules, page 27-100 or Modifying Existing Rules,
page 27-102 for more information.
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 rule editor for complete
evaluation, including evaluation of the restricted fields. See Use Fast Pattern Matcher, page 27-26
for more information.
The above restrictions are reflected in the description of each option in the following list describing the
HTTP content and protected_content keyword options.
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. See the Snort-Specific Post Regular Expression Modifiers table for more
information.
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. See the Snort-Specific Post Regular Expression Modifiers table for more
information.
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. See
Selecting Server-Level HTTP Normalization Options, page 19-33 for more information.
Note the following:
– You cannot use this option in combination with the pcre keyword HTTP cookie (C) option to
search the same content. See the Snort-Specific Post Regular Expression Modifiers table for
more information.
– 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.
– 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.
To specify an HTTP content option when doing a content search of TCP traffic:
Step 1 Optionally, to take advantage of HTTP Inspect preprocessor normalization, and to improve performance,
select:
• at least one from among the HTTP URI, HTTP Raw URI, HTTP Method, HTTP Header, HTTP Raw Header, or
HTTP Client Body options for the content or protected_content keyword you are adding
• the HTTP Cookie or HTTP Raw Cookie option
Step 2 Continue with creating or editing the rule. See Constraining Content Matches, page 27-17, Searching for
Content Matches, page 27-15, Writing New Rules, page 27-100, or Modifying Existing Rules,
page 27-102 for more information.
Note These options are not supported when configuring the protected_content keyword. For more
information, see Using the protected_content Keyword, page 27-15.
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 use the Use Fast Pattern Matcher option to specify a shorter search pattern for the fast pattern
matcher to use. Ideally, the pattern you specify is less likely to be found in the packet than the longest
pattern and, therefore, more specifically identifies the targeted exploit.
Note the following restrictions when selecting Use Fast Pattern Matcher and other options in the same
content keyword:
• 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). See HTTP Content Options, page 27-23 for more information.
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; see Decoding and Inspecting
Base64 Data, page 27-98 for more information.
only that the content 12345 be anywhere in the payload. When the fast pattern matcher detects the
pattern, the packet can be evaluated against additional keywords in the rule. There is no need for the rules
engine to reevaluate the packet to determine if it includes the pattern 12345.
You would not use this option when the rule contains other conditions relative to the specified content.
For example, you would not use this option to search for the content 1234 if another rule condition sought
to determine if abcd occurs before 1234. In this case, the rules engine could not determine the relative
location because specifying Fast Pattern Matcher Only instructs the rules engine not to search for the
specified content.
Note the following conditions when using this option:
• The specified content is location-independent; that is, it may occur anywhere in the payload; thus,
you cannot use positional options (Distance, Within, Offset, Depth, or Fast Pattern Matcher Offset and
Length).
• You cannot use this option in combination with Not.
• You cannot use this option in combination with Fast Pattern Matcher Offset and Length.
• The specified content will be treated as case-insensitive, because all patterns are inserted into the
fast pattern matcher in a case-insensitive manner; this is handled automatically, so it is not necessary
to select Case Insensitive when you select this option.
• You should not immediately follow a content keyword that uses the Fast Pattern Matcher Only option
with the following keywords, which set the search location relative to the current search location:
• isdataat
• pcre
• content when Distance or Within is selected
• content when HTTP URI is selected
• asn1
• byte_jump
• byte_test
• byte_extract
• base64_decode
Step 1 Select Use Fast Pattern Matcher for the content keyword you are adding.
Step 2 Optionally, select Fast Pattern Matcher Only to determine without rules engine evaluation if the specified
pattern exists in the packet.
Evaluation proceeds only if the fast pattern matcher detects the specified content.
Step 3 Optionally, specify in Fast Pattern Matcher Offset and Length a portion of the pattern to search for the content
using the syntax:
offset,length
where offset specifies how many bytes from the beginning of the content to begin the search, and
length specifies the number of bytes to continue.
Step 4 Continue with creating or editing the rule. See Constraining Content Matches, page 27-17, Searching for
Content Using PCRE, page 27-34, Writing New Rules, page 27-100, or Modifying Existing Rules,
page 27-102 for more information.
Note You cannot use the replace keyword to replace hashed content in a protected_content keyword. For
more information, see Using the protected_content Keyword, page 27-15.
Optionally, you can enclose the replacement string in quotation marks for backward compatibility with
previous ASA FirePOWER module 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:
"replacement text plus \"quotation\" marks""
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 explain 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. See Searching for Content Matches, page 27-15 and HTTP Content Options,
page 27-23 for more information.
Step 1 On the Create Rule page, select content in the drop-down list and click Add Option.
The content keyword appears.
Step 2 Specify the content you want to detect in the content field and, optionally, select any applicable
arguments. Note that you cannot use the HTTP request message content keyword options with the
replace keyword.
Step 3 Select replace in the drop-down list and click Add Option.
The replace keyword appears beneath the content keyword.
Step 4 Specify the replacement string for the specified content in the replace: field.
byte_jump
License: Protection
The byte_jump keyword calculates the number of bytes defined in a specified byte segment, and then
skips that number of bytes within the packet, either forward from the end of the specified byte segment,
or from the beginning of the packet payload, depending on the options you specify. This is useful in
packets where a specific segment of bytes describe the number of bytes included in variable data within
the packet.
The following table describes the arguments required by the byte_jump keyword.
Argument Description
Bytes The number of bytes to calculate from the packet.
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 also use an existing byte_extract variable to specify the value for this
argument. See Reading Packet Data into Keyword Arguments, page 27-80 for
more information.
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 -63535 through 63535 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.
See the DCE/RPC argument in the Endianness Arguments table for byte_jump
arguments that do not apply when you select the DCE/RPC argument.
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, rather than from the
end of the byte segment that specifies the number of bytes to skip.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
Argument Description
Little Endian Processes data in little endian byte order.
DCE/RPC Specifies a byte_jump keyword for traffic processed by the DCE/RPC
preprocessor. See Decoding DCE/RPC Traffic, page 19-2 for more information.
The DCE/RPC preprocessor determines big endian or little endian byte order,
and the Number Type, Endian, and From Beginning arguments do not apply.
When you enable this argument, you can also use byte_jump in conjunction with
other specific DCE/RPC keywords. See DCE/RPC Keywords, page 27-58 for
more information.
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.
Decimal String Represents converted string data in decimal format.
Octal String Represents converted string data in octal 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.
To use byte_jump:
Step 1 Select byte_jump in the drop-down list and click Add Option.
The byte_jump section appears beneath the last keyword you selected.
byte_test
License: Protection
The byte_test keyword calculates the number of bytes in a specified byte segment and compares them,
according to the operator and value you specify.
The following table describes the required arguments for the byte_test keyword.
Argument Description
Bytes The number of bytes to calculate from the packet. You can specify 1 to 10 bytes.
Operator and Value Compares the specified value to <, >, =, !, &, ^, !>, !<, !=, !&, 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 to specify the value for this
argument. See Reading Packet Data into Keyword Arguments, page 27-80 for
more information.
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 also use an existing byte_extract variable to specify the value for this
argument. See Reading Packet Data into Keyword Arguments, page 27-80 for
more information.
You can further define how the system uses byte_test arguments with the arguments described in the
following table.
Argument Description
Relative Makes the offset relative to the last successful pattern match.
Align Rounds the number of converted bytes up to the next 32-bit boundary.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
Little Endian Processes data in little endian byte order.
DCE/RPC Specifies a byte_test keyword for traffic processed by the DCE/RPC
preprocessor. See Decoding DCE/RPC Traffic, page 19-2 for more information.
The DCE/RPC preprocessor determines big endian or little endian byte order,
and the Number Type and Endian argument do not apply.
When you enable this argument, you can also use byte_test in conjunction with
other specific DCE/RPC keywords. See DCE/RPC Keywords, page 27-58 for
more information.
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.
Decimal String Represents converted string data in decimal format.
Octal String Represents converted string data in octal format.
To use byte_test:
Step 1 On the Create Rule page, select byte_test in the drop-down list and click Add Option.
The byte_test section appears beneath the last keyword you selected.
The pcre keyword allows you to use Perl-compatible regular expressions (PCRE) to inspect packet
payloads for specified content. You can use PCRE to avoid writing multiple rules to match slight
variations of the same content.
Regular expressions are useful when searching for content that could be displayed in a variety of ways.
The content may have different attributes that you want to account for in your attempt to locate it within
a packet’s payload.
Note that the regular expression syntax used in intrusion rules is a subset of the full regular expression
library and varies in some ways from the syntax used in commands in the full library. When adding a
pcre keyword using the rule editor, enter the full value in the following format:
!/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.
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
rule editor does not display quotation marks when you display a rule after saving it.
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.
See Perl-Compatible Regular Expression Basics, page 27-36 for more information about regular
expression syntax.
The following sections provide more information about building valid values for the pcre keyword:
• Perl-Compatible Regular Expression Basics, page 27-36 describes the common syntax used in
Perl-compatible regular expressions.
• PCRE Modifier Options, page 27-37 describes the options you can use to modify your regular
expression.
• Example PCRE Keyword Values, page 27-40 gives example usage of the pcre keyword in rules.
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
License: Protection
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.
Character Classes
License: Protection
Character classes include alphabetic characters, numeric characters, alphanumeric characters, and white
space characters. While you can create your own character classes within brackets (see Metacharacters,
page 27-36), 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.
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 rule 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.
Option Description
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.
.
Table 27-21 Snort-Specific Post Regular Expression Modifiers
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. See HTTP Content Options,
page 27-23 for more information.
Note 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. See HTTP Content
Options, page 27-23 for more information.
P Searches for the content within the body of a normalized HTTP request message decoded by the HTTP
Inspect preprocessor. See the content and protected_content keyword HTTP Client Body option in
HTTP Content Options, page 27-23 for more information.
Option Description
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. See HTTP
Content Options, page 27-23 for more information.
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. See HTTP Content Options, page 27-23 for more information.
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. See the content and protected_content
keyword HTTP Method option in HTTP Content Options, page 27-23 for more information.
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. See HTTP Content Options, page 27-23 for more
information.
• 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. See HTTP Content Options, page 27-23 for more
information.
• 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.
S Searches the 3-digit status code in an HTTP response. See the content and protected_content
keyword HTTP Status Code option in HTTP Content Options, page 27-23 for more information.
Y Searches the textual description that accompanies the status code in an HTTP response. See the
content and protected_content keyword HTTP Status Message option in HTTP Content Options,
page 27-23 for more information.
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).
• http://www.example.com?scriptvar=x&othervar=\n\..\..
• http://www.example.com?scriptvar=\t
This example would not match:
• ftp://ftp.example.com?scriptvar=&othervar=\n\..\..
• http://www.example.com?scriptvar=|/bin/sh -i|
• 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.
This example would match:
• http://www.example.com?value=|/bin/sh/ -i|
• http://www.example.com?input=|cat /etc/passwd|
This example would not match:
• ftp://ftp.example.com?value=|/bin/sh/ -i|
• 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.
• Be aware when using commas that the system interprets a comma as a separator for multiple
key value or key=value statements. For example:
key value, key value, key value
• Be aware when using the equal to (=) character or space character that the system interprets these
characters as separators between key and value. For example:
key value
key=value
All other characters are permitted.
To match a rule with an identified application protocol, you must define the metadata keyword and a
key value statement, with service as the key and an application for the value. For example, the
following key value statement in a metadata keyword associates the rule with HTTP traffic:
service http
The following table describes the most common application values.
Note Contact Support for assistance in defining applications not in the table.
Value Description
dcerpc Distributed Computing Environment/Remote Procedure Calls System
dns Domain Name System
Value Description
finger Finger user information protocol
ftp File Transfer Protocol
ftp-data File Transfer Protocol (Data Channel)
http Hypertext Transfer Protocol
imap Internet Message Access Protocol
isakmp Internet Security Association and Key Management Protocol
netbios-dgm NETBIOS Datagram Service
netbios-ns NETBIOS Name Service
netbios-ssn NETBIOS Session Service
nntp Network News Transfer Protocol
oracle Oracle Net Services
pop2 Post Office Protocol, version 2
pop3 Post Office Protocol, version 3
smtp Simple Mail Transfer Protocol
ssh Secure Shell network protocol
telnet Telnet network protocol
tftp Trivial File Transfer Protocol
x11 X Window System
Note Contact Support for assistance in adding restricted metadata to local rules that might not otherwise
function as expected. See Importing Local Rule Files, page 43-16 for more information.
Argument Description
R Reserved bit
M More Fragments bit
D Don’t Fragment 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.
Argument Description
rr record route
eol end of list
nop no operation
ts time stamp
sec IP security option
lsrr loose source routing
ssrr strict source routing
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.
The ToS field has been deprecated in the IP header protocol and replaced with the Differentiated Services
Code Point (DSCP) field.
icmp_id
The icmp_id keyword 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.
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).
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. See Applying Rules to
a TCP or UDP Client or Server Flow, page 27-50 for more information about the flow keyword.
You can either check for or ignore the values described in the following table for the flag keyword.
Tip For more information on Explicit Congestion Notification (ECN), see the information provided at:
http://www.faqs.org/rfcs/rfc3168.html.
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.
Tip For maximum performance, always include a flow keyword in a TCP rule or a UDP session rule.
To specify flow, select the flow keyword from the Detection Options list on the Create Rule page and click
Add Option. Next, select the arguments from the list provided for each field.
The following table describes the stream-related arguments you can specify for the flow keyword:
Argument Description
Established Triggers on established connections.
Stateless Triggers regardless of the state of the stream processor.
The following table describes the directional options you can specify for the flow keyword:
Argument Description
To Client Triggers on server responses.
To Server Triggers on client responses.
From Client Triggers on client responses.
From Server 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.
Only Stream Traffic Triggers only 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.
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
> greater than
< less than
>= greater than or equal to
<= less than or equal to
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
To use stream_reassemble:
Step 1 On the Create Rule page, select stream_reassemble in the drop-down list and click Add Option.
The stream_reassemble section appears.
ssl_state
License: Protection
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.
unknown Matches against any handshake message type.
ssl_version
License: Protection
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.
RPC
License: Protection
The rpc keyword identifies Open Network Computing Remote Procedure Call (ONC RPC) services in
TCP or UDP packets. This allows you to detect attempts to identify the RPC programs on a host.
Intruders can use an RPC portmapper to determine if any of the RPC services running on your network
can be exploited. They can also attempt to access other ports running RPC without using portmapper.
The following table lists the arguments that the rpc keyword accepts.
Argument Description
application The RPC application number
procedure The RPC procedure invoked
version The RPC version
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.
ASN.1
License: Protection
The asn1 keyword allows you to decode a packet or a portion of a packet, looking for various malicious
encodings.
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.)
urilen
License: Protection
You can use the urilen keyword in conjunction with the HTTP Inspect preprocessor to inspect HTTP
traffic for URIs of a specific length, less than a maximum length, greater than a minimum length, or
within a specified range.
After the HTTP Inspect preprocessor normalizes and inspects the packet, the rules engine evaluates the
packet against the rule and determines whether the URI matches the length condition specified by the
urilen keyword. You can use this keyword to detect exploits that attempt to take advantage of URI
length vulnerabilities, for example, by creating a buffer overflow that allows the attacker to cause a DoS
condition or execute code on the host with system-level privileges.
Note the following when using the urilen keyword in a rule:
• 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. See Specifying Protocols, page 27-4 for more information.
• Target ports are always HTTP ports. See Defining Ports in Intrusion Rules, page 27-8 and
Optimizing Predefined Default Variables, page 2-14 for more information.
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/.
DCE/RPC Keywords
License: Protection
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. See Decoding DCE/RPC Traffic, page 19-2 for more information.
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. For more information, see Using Byte_Jump and Byte_Test, page 27-30 and
Reading Packet Data into Keyword Arguments, page 27-80.
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. See Searching for Content Matches, page 27-15 and Use Fast Pattern Matcher,
page 27-26 for more information.
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.
See the following sections for more information:
dce_iface
License: Protection
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. See dce_opnum, page 27-60 and
dce_stub_data, page 27-60 for more information.
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.
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.
dce_opnum
License: Protection
You can use the dce_opnum keyword in conjunction with the DCE/RPC preprocessor to detect packets
that identify one or more specific operations that a DCE/RPC service provides.
Client function calls request specific service functions, which are referred to in DCE/RPC specifications
as operations. An operation number (opnum) identifies a specific operation in the DCE/RPC header. It
is likely that an exploit would target a specific operation.
For example, the UUID 12345678-1234-abcd-ef00-01234567cffb identifies the interface for the
netlogon service, which provides several dozen different operations. One of these is operation 6, the
NetrServerPasswordSet operation.
You should precede a dce_opnum keyword with a dce_iface keyword to identify the service for the
operation. See dce_iface, page 27-59 for more information.
You can specify a single decimal value 0 to 65535 for a specific operation, a range of operations
separated by a hyphen, or a comma-separated list of operations and ranges in any order.
Any of the following examples would specify valid netlogon operation numbers:
15
15-18
15, 18-20
15, 20-22, 17
15, 18-20, 22, 24-26
dce_stub_data
License: Protection
You can use the dce_stub_data keyword in conjunction with the DCE/RPC preprocessor to specify that
the rules engine should start inspection at the beginning of the stub data, regardless of any other rule
options. Packet payload rule options that follow the dce_stub_data keyword are applied relative to the
stub data buffer.
DCE/RPC stub data provides the interface between a client procedure call and the DCE/RPC run-time
system, the mechanism that provides the routines and services central to DCE/RPC. DCE/RPC exploits
are identified in the stub data portion of the DCE/RPC packet. Because stub data is associated with a
specific operation or function call, you should always precede dce_stub_data with dce_iface and
dce_opnum to identify the related service and operation.
The dce_stub_data keyword has no arguments. See dce_iface, page 27-59 and dce_opnum, page 27-60
for more information.
SIP Keywords
License: Protection
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. See Adding Dynamic Rule States, page 24-28 and
Preventing Rate-Based Attacks, page 25-9 for more information.
See the following sections for more information:
• sip_header, page 27-61
• sip_body, page 27-61
• sip_method, page 27-61
• sip_stat_code, page 27-62
sip_header
License: Protection
You can use the sip_header keyword to start inspection at the beginning of the extracted SIP request or
response header and restrict inspection to header fields.
The sip_header keyword has no arguments. See sip_method, page 27-61 and sip_stat_code, page 27-62
for more information.
The following example rule fragment points to the SIP header and matches the CSeq header field:
alert udp any any -> any 5060 ( sip_header; content:"CSeq"; )
sip_body
License: Protection
You can use the sip_body keyword to start inspection at the beginning of the extracted SIP request or
response message body and restrict inspection to the message body.
The sip_body keyword has no arguments.
The following example rule fragment points to the SIP message body and matches a specific IP address
in the c (connection information) field in extracted SDP data:
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.
sip_method
License: Protection
A method field in each SIP request identifies the purpose of the request. You can use the sip_method
keyword to test SIP requests for specific methods. Separate multiple methods with commas.
You can specify any of the following currently defined SIP methods:
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. See Selecting
SIP Preprocessor Options, page 19-49 for more information.
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. See Searching for Content Matches, page 27-15 and Use Fast Pattern Matcher,
page 27-26 for more information.
sip_stat_code
License: Protection
A three-digit status code in each SIP response indicates the outcome of the requested action. You can
use the sip_stat_code keyword to test SIP responses for specific status codes.
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.
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
License: Protection
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.
See the following sections for more information:
• gtp_version, page 27-63
• gtp_type, page 27-63
• gtp_info, page 27-67
gtp_version
You can use the gtp_version keyword to inspect GTP control messages for GTP version 0, 1, or 2.
Because different GTP versions define different message types and information elements, you must use
this keyword when you use the gtp_type or gtp_info keyword. You can specify the value 0, 1, or 2.
Step 1 On the Create Rule page, select gtp_version in the drop-down list and click Add Option.
The gtp_version keyword appears.
Step 2 Specify 0, 1, or 2 to identify the GTP version.
gtp_type
Each GTP message is identified by a message type, which is comprised of both a numeric value and a
string. You can use the gtp_type keyword in combination with the gtp_version keyword to inspect
traffic for specific GTP message types.
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:
10, 11, echo_request
The system uses an OR operation to match each value or string that you list. The order in which you list
values and strings does not matter. Any single value or string in the list matches the keyword. You receive
an error if you attempt to save a rule that includes an unrecognized string or an out-of-range value.
Note in the table that different GTP versions sometimes use different values for the same message type.
For example, the sgsn_context_request message type has a value of 50 in GTPv0 and GTPv1, but a
value of 130 in GTPv2.
The gtp_type keyword matches different values depending on the version number in the packet. In the
example above, the keyword matches the message type value 50 in a GTPv0 or GTPv1 packet and the
value 130 in a GTPv2 packet. The keyword does not match a packet when the message type value in the
packet is not a known value for the version specified in the packet.
If you specify an integer for the message type, 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 defined values and strings recognized by the system for each GTP message
type.
Step 1 On the Create Rule page, select gtp_type in the drop-down list and click Add Option.
The gtp_type keyword appears.
Step 2 Specify a defined decimal value 0 to 255 for the message type, a defined string, or a comma-separated
list of either or both in any combination. See the GTP Message Types table for values and strings
recognized by the system.
gtp_info
A GTP message can include multiple information elements, each of which is identified by both a defined
numeric value and a defined string. You can use the gtp_info keyword in combination with the
gtp_version keyword to start inspection at the beginning of a specified information element and restrict
inspection to the specified information element.
You can specify either the defined decimal value or the defined string for an information element. You
can specify a single value or string, and you can use multiple gtp_info keywords in a rule to inspect
multiple information elements.
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.
You can use the following procedure to specify a GTP information element.
Step 1 On the Create Rule page, select gtp_info in the drop-down list and click Add Option.
The gtp_info keyword appears.
Step 2 Specify a single defined decimal value 0 to 255 for the information element, or a single defined string.
See the GTP Information Elements table for values and strings recognized by the system.
Modbus Keywords
License: Protection
You can use Modbus keywords to point to the beginning of the Data field in a Modbus request or
response, to match against the Modbus Function Code, and to match against a Modbus Unit ID. You can
use Modbus keywords alone or in combination with other keywords such as content and byte_jump.
See the following sections for more information:
• modbus_data, page 27-73
• modbus_func, page 27-73
• modbus_unit, page 27-74
modbus_data
You can use the modbus_data keyword to point to the beginning of the Data field in a Modbus request
or response.
Step 1 On the Create Rule page, select modbus_data from the drop-down list and click Add Option.
The modbus_data keyword appears.
The modbus_data keyword has no arguments.
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
Value String
8 diagnostics
11 get_comm_event_counter
12 get_comm_event_log
15 write_multiple_coils
16 write_multiple_registers
17 report_slave_id
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
Step 1 On the Create Rule page, select modbus_func in the drop-down list and click Add Option.
The modbus_func keyword appears.
Step 2 Specify a single defined decimal value 0 to 255 for the function code, or a single defined string. See the
Modbus Function Codes table for values and strings recognized by the system.
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.
Step 1 On the Create Rule page, select modbus_unit in the drop-down list and click Add Option.
The modbus_unit keyword appears.
Step 2 Specify a decimal value 0 through 255.
DNP3 Keywords
License: Protection
You can use DNP3 keywords to point to the beginning of application layer fragments, to match against
DNP3 function codes and objects in DNP3 responses and requests, and to match against internal
indication flags in DNP3 responses. 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.
Step 1 On the Create Rule page, select modbus_data from the drop-down list and click Add Option.
The dnp3_data keyword appears.
The dnp3_data keyword has no arguments.
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
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
Value String
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
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
Step 1 On the Create Rule page, select dnp3_func in the drop-down list and click Add Option.
The dnp3_func keyword appears.
Step 2 Specify a single defined decimal value 0 to 255 for the function code, or a single defined string. See the
DNP3 Function Codes table for values and strings recognized by the system.
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
Step 1 On the Create Rule page, select dnp3_ind in the drop-down list and click Add Option.
The dnp3_ind keyword appears.
Step 2 You can specify the string for a single known flag or a comma-separated list of flags.
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.
Step 1 On the Create Rule page, select dnp3_obj in the drop-down list and click Add Option.
The dnp3_obj keyword appears.
Step 2 Specify a decimal value 0 through 255 to identify a known object group, and another decimal value 0
through 255 to identify a known object variation type.
dsize
License: Protection
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
License: Protection
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.
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.
To use isdataat:
Step 1 On the Create Rule page, select isdataat in the drop-down list and click Add Option.
The isdataat section appears.
sameip
License: Protection
The sameip keyword tests that a packet’s source and destination IP addresses are the same. It does not
take an argument.
fragoffset
License: Protection
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
> greater than
< less than
Note that you cannot use the not (!) operator in combination with < or >.
cvs
License: Protection
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. For more
information, see Selecting Stream Reassembly Options, page 21-26.
Step 1 Add the cvs option to a rule and type invalid-entry as the keyword argument.
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 extract from the packet. You can specify 1, 2, 3, or 4
bytes.
Offset The number of bytes into the payload to begin extracting data. You can specify
-65534 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; see the Additional Optional byte_extract
Arguments table for more information.
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. See the Required byte_extract Arguments table for
more information.
Argument Description
Big Endian Processes data in big endian byte order, which is the default network byte order.
Argument Description
Little Endian Processes data in little endian byte order.
DCE/RPC Specifies a byte_extract keyword for traffic processed by the DCE/RPC
preprocessor. See Decoding DCE/RPC Traffic, page 19-2 for more information.
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. See DCE/RPC Keywords, page 27-58
for more information.
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.
Decimal String Reads extracted string data in decimal format.
Octal String Reads extracted string data in octal format.
To use byte_extract:
Step 1 On the Create Rule page, select t byte_extract in the drop-down list and click Add Option.
The byte_extract section appears beneath the last keyword you selected.
The following table lists the arguments you can use with the resp keyword to specify exactly what you
want the ASA FirePOWER module to do when the rule triggers.
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_net Directs an ICMP network unreachable message to the sender.
icmp_host Directs an ICMP host unreachable message to the sender.
icmp_port Directs an ICMP port unreachable message to the sender. This argument is used to
terminate UDP traffic.
icmp_all Directs the following ICMP messages to the sender:
• network unreachable
• host unreachable
• port unreachable
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
See Setting the Active Response Reset Attempts and Interface, page 27-85 for information on using the
config response command to configure the active response interface to use and the number of TCP
resets to attempt in a passive deployment.
Step 1 On the Create Rule page, select resp in the drop-down list and click Add Option.
The resp keyword appears.
Step 2 Specify any of the arguments in the resp Arguments table in the resp field; use a comma-separated list
to specify multiple arguments.
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.
See Setting the Active Response Reset Attempts and Interface, page 27-85 for information on using the
config response command to configure the active response interface to use and the number of TCP
resets to attempt in a passive deployment.
Step 1 On the Create Rule page, select react in the drop-down list and click Add Option.
The react keyword appears.
Step 2 You have two choices:
• To send an HTML page that includes the event message configured for the rule to the client before
closing a connection, type msg in the react field.
• To send an HTML page that includes the following default message to the client before closing a
connection, leave the react field blank:
You are attempting to access a forbidden site.
Consult your system administrator for details
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.
To specify active response reset attempts, the active response interface, or both:
Step 1 Depending on whether you want to specify only the number of active responses, only the active response
interface, or both, insert a form of the config response command on a separate line in the USER_CONF
advanced variable. You have the following choices:
• To specify only the number of active response attempts, insert the command:
config response: attempts att
• 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.
Filtering Events
License: Protection
You can use the detection_filter keyword to prevent a rule from generating events unless a specified
number of packets trigger the rule within a specified time. This can stop the rule from prematurely
generating events. For example, two or three failed login attempts within a few seconds could be
expected behavior, but a large number of attempts within the same time could indicate a brute force
attack.
The detection_filter keyword requires arguments that define whether the system tracks the source or
destination IP address, the number of times the detection criteria must be met before triggering an event,
and how long to continue the count.
Use the following syntax to delay the triggering of events:
track by_src/by_dst, count count, seconds number_of_seconds
The track argument specifies whether to use the packet’s source or destination IP address when counting
the number of packets that meet the rule’s detection criteria. Select from the argument values described
in the following table to specify how the system tracks event instances.
Argument Description
by_src Detection criteria count by source IP address.
by_dst Detection criteria count by destination 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:
track by_src, count 10, seconds 20
In the example, the rule will not generate an event until it has detected foo in 10 packets within 20
seconds from a given source IP address. If the system detects only 7 packets containing foo within the
first 20 seconds, no event is generated. However, if foo occurs 40 times in the first 20 seconds, the rule
generates 30 events and the count begins again when 20 seconds have elapsed.
You can choose from two types of tagging. The following table describes the two types of tagging. Note
that the session tag argument type causes the system to log packets from the same session as if they came
from different sessions if you configure only rule header options in the intrusion rule. To group packets
from the same session together, configure one or more rule options (such as a flag keyword or content
keyword) within the same intrusion rule.
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:
host, 30, seconds, dst
all packets that are transmitted from the client to the host for the next 30 seconds are logged.
The flowbits state name is a user-defined label assigned to packets in a specific part of a session. You
can label packets with state names based on packet content to help distinguish malicious packets from
those you do not want to alert on. You can define up to 1024 state names. For example, if you want to
alert on malicious packets that you know only occur after a successful login, you can use the flowbits
keyword to filter out the packets that constitute an initial login attempt so you can focus only on the
malicious packets. You can do this by first creating a rule that labels all packets in the session that have
an established login with a logged_in state, then creating a second rule where flowbits checks for
packets with the state you set in the first rule and acts only on those packets. See flowbits Example Using
state_name, page 27-90 for an example that uses flowbits to determine if a user is logged in.
An optional group name allows you to include a state name in a group of states. A state name can belong
to several groups. States not associated with a group are not mutually exclusive, so a rule that triggers
and sets a state that is not associated with a group does not affect other currently set states. See flowbits
Example Resulting in a False Positive, page 27-91 for an example that illustrates how including a state
name in a group can prevent false positives by unsetting another state in the same group.
The following table describes the various combinations of operators, states, and groups available to the
flowbits keyword. Note that state names can contain alphanumeric characters, periods (.), underscores
(_), and dashes (-).
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
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:
alert tcp any any -> any 143 (msg:"IMAP LIST";
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.
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:
(msg:"GIF transfer"; content:"image/"; pcre:"/^Content-
Type\x3a(\s*|\s*\r?\n\s+)image\x2fgif/smi";
flowbits:set,http.tif,image_downloads; flowbits:noalert;)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
The content and pcre keywords in the second rule match the GIF file download,
flowbits:set,http.tif sets the http.tif 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.
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:
(msg:"GIF transfer"; content:"image/"; pcre:"/^Content-
Type\x3a(\s*|\s*\r?\n\s+)image\x2fgif/smi";
flowbits:setx,http.tif,image_downloads; flowbits:noalert;)
The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:
When the second rule fragment matches the GIF download, the
flowbits:setx,http.tif,image_downloads keyword sets the http.tif flowbits state and unsets
http.jpeg, the other state in the group.
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 can use the http_encode keyword to generate events on the type of encoding in an HTTP request
or response before normalization, either in the HTTP URI, in non-cookie data in an HTTP header, in
cookies in HTTP requests headers, or set-cookie data in HTTP responses.
You must configure the HTTP Inspect preprocessor to inspect HTTP responses and HTTP cookies to
return matches for rules using the http_encode keyword. See Decoding HTTP Traffic, page 19-31 and
Selecting Server-Level HTTP Normalization Options, page 19-33 for more information.
Also, you must enable both the decoding and alerting option for each specific encoding type in your
HTTP Inspect preprocessor configuration for the http_encode keyword in an intrusion rule to trigger
events on that encoding type. See Selecting Server-Level HTTP Normalization Encoding Options,
page 19-41 for more information.
Note that the base36 encoding type has been deprecated. For backward compatibility, the base36
argument is allowed in existing rules, but it does not cause the rules engine to inspect base36 traffic.
The following table describes the encoding types this option can generate events for in HTTP URIs,
headers, cookies, and set-cookies:
Tip Updating your vulnerability database (VDB) populates the rule editor with the most up-to-date file types,
versions, and groups. For more information, see Updating the Vulnerability Database, page 43-9.
You must enable specific preprocessors in order to generate intrusion events for traffic matching your
file_type or file_group keywords.
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.
To view and configure the most up-to-date file types and versions, update your VDB. For more
information, see Updating the Vulnerability Database, page 43-9.
Step 1 On the Create Rule page, select file_type from the drop-down list and click Add Option.
The file_type keyword appears.
Step 2 Select one or more file types from the drop-down list. Selecting a file type automatically adds the
argument to the rule.
To remove a file type argument from the rule, click the delete icon ( ) next to the file type you want
to remove.
Step 3 Optionally, customize the target versions for each file type. The system selects Any Version by default,
but some file types allow you to select individual target versions.
Note Updating your VDB populates the rule editor with the most up-to-date file types and versions. If you
select Any Version, the system configures your rule to include new versions when they are added in later
VDB updates.
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.
To view and configure the most up-to-date file groups, update your VDB. For more information, see
Updating the Vulnerability Database, page 43-9.
Step 1 On the Create Rule page, select file_group from the drop-down list and click Add Option.
The file_group keyword appears.
Step 2 Select a file group to add to the rule.
The file_data keyword provides a pointer that serves as a reference for the positional arguments
available for other keywords such as content, byte_jump, byte_test, and pcre. The detected traffic
determines the 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. See Decoding HTTP Traffic, page 19-31 and
Inspect HTTP Responses in Selecting Server-Level HTTP Normalization Options, page 19-33 for more
information. The file_data keyword matches if the HTTP Inspect preprocessor detects HTTP
response body data.
• Uncompressed gzip file data
To inspect uncompressed gzip files in the HTTP response body, the HTTP Inspect preprocessor must
be enabled and you must configure the preprocessor to inspect HTTP responses and to decompress
gzip-compressed files in the HTTP response body. For more information, see Decoding HTTP
Traffic, page 19-31, and the Inspect HTTP Responses and Inspect Compressed Data options in Selecting
Server-Level HTTP Normalization Options, page 19-33. The file_data keyword matches if the
HTTP Inspect preprocessor detects uncompressed gzip data in the HTTP response body.
• Normalized JavaScript
To inspect normalized JavaScript data, the HTTP Inspect preprocessor must be enabled and you
must configure the preprocessor to inspect HTTP responses. See Decoding HTTP Traffic,
page 19-31 and Inspect HTTP Responses in Selecting Server-Level HTTP Normalization Options,
page 19-33 for more information. 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. See Configuring SMTP
Decoding, page 19-64 for more information. The file_data keyword matches if the SMTP
preprocessor detects SMTP data.
• Encoded email attachments in SMTP, POP, or IMAP traffic
To inspect email attachments in SMTP, POP, or IMAP traffic, the SMTP, POP, or IMAP
preprocessor, respectively, must be enabled, alone or in any combination. Then, for each enabled
preprocessor, you must ensure that the preprocessor is configured to decode each attachment
encoding type that you want decoded. The attachment decoding options that you can configure for
each preprocessor are: Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable
Decoding Depth, and Unix-to-Unix Decoding Depth. See Decoding IMAP Traffic, page 19-54, Decoding
POP Traffic, page 19-57, and Decoding SMTP Traffic, page 19-60 for more information.
You can use multiple file_data keywords in a rule.
Step 1 On the Create Rule page, select file_data from the drop-down list and click Add Option.
The file_data keyword appears.
The file_data keyword has no arguments.
Step 1 On the Create Rule page, select pkt_data from the drop-down list and click Add Option.
The pkt_data keyword appears.
The pkt_data keyword has no arguments.
base64_decode
License: Protection
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. See base64_data, page 27-99 for more information.
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.
Relative Specifies inspection relative to the current inspection location.
Step 1 On the Create Rule page, select base64_decode from the drop-down list and click Add Option.
The base64_decode keyword appears.
Step 2 Optionally, select any of the arguments described in the Optional base64_decode Arguments table.
base64_data
License: Protection
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; see Use Fast Pattern Matcher, page 27-26 for more
information.
• 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; see HTTP
Content Options, page 27-23 for more information.
Step 1 On the Create Rule page, select base64_data from the drop-down list and click Add Option.
The base64_data keyword appears.
Constructing a Rule
License: Protection
Just as you can create your own custom standard text rules, you can also modify existing standard text
rules and shared object rule provided by Cisco and save your changes as a new rule. Note that for shared
object rules provided by Cisco, you are limited to modifying rule header information such as the source
and destination ports and IP addresses. You cannot modify the rule keywords and arguments in a shared
object rule.
See the following sections for more information:
• Writing New Rules, page 27-100
• Modifying Existing Rules, page 27-102
• Adding Comments to Rules, page 27-103
• Deleting Custom Rules, page 27-104
Note The system assigns a new SID to any custom rule in an intrusion policy that you import. For more
information, see Importing and Exporting Configurations, page B-1.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Step 2 Click Create Rule.
The Create Rule page appears.
Step 3 In the Message field, enter the message you want displayed with the event.
For details on event messages, see Defining the Event Message, page 27-11.
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.
Step 4 From the Classification list, select a classification to describe the type of event.
For details on available classifications, see Defining the Intrusion Event Classification, page 27-12.
Step 5 From the Action list, select the type of rule you would like to create. You can use one of the following:
• Select alert to create a rule that generates an event when traffic triggers the rule.
• Select pass to create a rule that ignores traffic that triggers the rule.
Step 6 From the Protocol list, select the traffic protocol (tcp, udp, icmp, or ip) of packets you want the rule to
inspect.
For more information about selecting a protocol type, see Specifying Protocols, page 27-4.
Step 7 In the Source IPs field, enter the originating IP address or address block for traffic that should trigger the
rule. In the Destination IPs field, enter the destination IP address or address block for traffic that should
trigger the rule.
For more detailed information about the IP address syntax that the rule editor accepts, see Specifying IP
Addresses In Intrusion Rules, page 27-5.
Step 8 In the Source Port field, enter the originating port numbers for traffic that should trigger the rule. In the
Destination Port field, enter the receiving port numbers for traffic that should trigger the rule.
Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip.
For more detailed information about the port syntax that the rule editor accepts, see Defining Ports in
Intrusion Rules, page 27-8.
Step 9 From the Direction list, select the operator that indicates which direction of traffic you want to trigger the
rule. You can use one of the following:
• Directional to match traffic that moves from the source IP address to the destination IP address
• Bidirectional to match traffic that moves in either direction
Step 10 From the Detection Options list, select the keyword that you want to use.
Note Do not modify the protocol for a shared object rule; doing so would render the rule ineffective.
To modify a rule:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Step 2 Locate the rule or rules you want to modify. You have the following options:
• To locate rules by browsing rule categories, navigate through the folders to the rule you want and
click the edit icon ( ) next to the rule.
• To locate a rule or rules by filtering the rules displayed on the page, enter a rule filter in the text box
indicated by the filter icon ( ) at the upper left of the rule list. Navigate to the rule you want and
click the edit icon ( ) next to the rule. See Filtering Rules on the Rule Editor Page, page 27-104
for more information.
The rule editor opens, displaying the rule you selected.
Note that if you select a shared object rule, the rule editor displays only the rule header information. A
shared object rule can be identified on the Rule Editor page by a listing that begins with the number 3
(the GID), for example, 3:1000004.
Step 3 Make any modifications to the rule (see Writing New Rules, page 27-100 for more information about
rule options) and click Save As New.
The rule is saved to the local rule category.
Tip If you want to use the local modification of the rule instead of the system rule, deactivate the system rule
by using the procedures at Setting Rule States, page 24-19 and activate the local rule.
Step 4 Activate the intrusion policy by applying it as part of an access control policy as described in Deploying
Configuration Changes, page 4-10 to apply your changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Step 2 Locate the rule you want to annotate. You have the following options:
• To locate a rule by browsing rule categories, navigate through the folders to the rule you want and
click the edit icon ( ) next to the rule.
• To locate a rule by filtering the rules displayed on the page, enter a rule filter in the text box, which
is indicated by the filter icon ( ), at the upper left of the rule list. Navigate to the rule you want
and click the edit icon ( ) next to the rule. See Filtering Rules on the Rule Editor Page,
page 27-104 for more information.
The rule editor appears.
Step 3 Click Rule Comment.
The Rule Comment page appears.
Step 4 Enter your comment in the text box and click Add Comment.
The comment is saved in the comment text box.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Step 2 You have two choices:
• Click Delete Local Rules, then click OK.
All rules not currently enabled in an intrusion policy whose changes you have saved are deleted from
the local rule category and moved to the deleted category.
• Navigate through the folders to the local rule category; click on the local rule category to expand it,
then click the delete icon ( ) next to a rule you want to delete.
The rule is deleted from the local rule category and moved to the deleted category.
Note that custom standard text rules have a generator ID (GID) of 1 (for example, 1:1000012) and
custom shared object rules have a GID of 3 (for example, 3:1000005).
Tip The system also stores shared object rules that you save with modified header information in the local
rule category and lists them with a GID of 3. You can delete your modified version of a shared object
rule, but you cannot delete the original shared object rule.
You can filter the rules on the Rule Editor page to display a subset of rules. This can be useful, for
example, when you want to modify a rule or change its state but have difficulty finding it among the
thousands of rules available.
When you enter a filter, the page displays any folder that includes at least one matching rule, or a
message when no rule matches. 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.
Optionally, 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 Rule Editor page.
See the following sections for more information:
• Using Keywords in a Rule Filter, page 27-105
• Using Character Strings in a Rule Filter, page 27-106
• Combining Keywords and Character Strings in a Rule Filter, page 27-107
• Filtering Rules, page 27-107
Tip You can search for a partial SID by filtering with one or more character strings. See Using Character
Strings in a Rule Filter, page 27-106 for more information.
The following table describes the specific filtering keywords and arguments you can use to filter rules.
url Returns one or more rules based on all or part of the URL in a rule url:faqs.org
reference. See Defining the Event Reference, page 27-14 for more
information.
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.
Filtering Rules
License: Protection
You can filter the rules on the Rule Editor page to display a subset of rules so you can more easily find
specific rules. You can then use any of the page features.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.
The Rule Editor page appears.
Rule filtering can be particularly useful on the Rule Editor page when you want to locate a rule to edit
it. See Modifying Existing Rules, page 27-102 for more information.
Step 2 Optionally, select a different grouping method from the Group Rules By list.
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.
Step 3 Optionally, click the folder next to any group that you want to expand.
The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you
can also expand.
Note also that expanding a group on the original, unfiltered page can be useful when you expect that a
rule might be in that group. The group remains expanded when the subsequent filter results in a match
in that folder, and when you return to the original, unfiltered page by clicking on the filter clearing icon
( ).
Step 4 To activate the filter text box, click to the right of the filter icon ( ) that is inside the text box at the
upper left of the rule list.
Step 5 Type your filter constraints and press Enter.
Your filter can include keywords and arguments, character strings with or without quotes, and spaces
separating multiple conditions. See Filtering Rules on the Rule Editor Page, page 27-104 for more
information.
The page refreshes to display any group that contains at least one matching rule.
Step 6 Optionally, open any folder not already opened to display matching rules. You have the following
filtering choices:
• To enter a new filter, position your cursor inside the filter text box and click to activate it; type your
filter and press Enter.
• To clear the current filtered list and return to the original, unfiltered page, click the filter clearing
icon ( ).
Step 7 Optionally, make any changes to the rule that you would normally make on the page. See Modifying
Existing Rules, page 27-102.
To put any changes you make into effect, apply the intrusion policy part of an access control policy as
described in Deploying Configuration Changes, page 4-10.
You can configure identity policies to use User Agents, ISE devices, or captive portal to obtain data about
the users on your network.
User awareness
The ability to view and analyze user data
User control
The ability to configure user access control rule conditions to block users or user activity in traffic
on your network, based on conclusions you drew from user awareness.
You can obtain user data from authoritative identity sources (referenced by your identity policy).
An identity source is authoritative if a trusted server validated the user login. You can use the data
obtained from authoritative logins to perform user awareness and user control. Authoritative user logins
are obtained from passive and active authentications:
• Passive authentications occur when a user authenticates through an external server. The User Agent
and ISE are the only passive authentication methods supported by the ASA FirePOWER module.
• Active authentications occur when a user authenticates through a Firepower device. Captive portal
is the only active authentication method supported by the ASA FirePOWER module.
The following table provides a brief overview of the user identity sources supported by the ASA
FirePOWER module.
Table 28-1
The user activity database on the device contains records of user activity on your network reported by
all of your configured identity sources. The system logs events in the following circumstances:
• when it detects individual logins or logoffs
• when it detects a new user
• when you manually delete a user
• when the system detects a user that is not in the database, but cannot add the user because you have
reached your user limit
The users database contains a record for each user reported by your configured identity sources.
• The total number of users the device can store depends on the model. When the limit has been
reached, you must delete users (manually or with a database purge) to allow new users to be added.
If an identity source is configured to exclude specific user names, user activity data for those user names
are not reported to the ASA FirePOWER module. These excluded user names remain in the database,
but are not associated with IP addresses.
When the system detects multiple logins to the same host by different users, the system assumes that
only one user is logged into any given host at a time, and that the current user of a host is the last
authoritative user login. If multiple users are logged in through remote sessions, the last user reported
by the server is the user reported to the ASA FirePOWER module.
When the system detects multiple logins to the same host by the same user, the system records the first
time that a user logs into a specific host and disregards subsequent logins. If an individual user is the
only person who logs into a specific host, the only login that the system records is the original login.
If another user logs into that host, however, the system records the new login. Then, if the original user
logs in again, his or her new login is recorded.
Note If your deployment includes an ASA5506-X, ASA5508-X, or ASA5516-X device, you can store a
maximum of 2,000 authoritative users.
Your device model determines how many individual users you can monitor. When the system detects
activity from a new user, that user is added to the Users database. You can detect users using User
Agents, ISE, and captive portal.
A realm consists of one or more LDAP or Microsoft Active Directory servers that share the same
credentials. You must configure a realm if you want to perform user and user group queries, user access
control, or to configure a User Agent, ISE, or captive portal. After configuring one or more realms, you
can configure an identity policy.
An identity policy associates traffic on your network with an authoritative identity source and a realm.
After configuring your identity policy, you can associate it with an access control policy and deploy the
access control policy to your device.
Realm Fundamentals
License: Any
Realms establish connections between the ASA FirePOWER module and the servers targeted for
monitoring. They specify the connection settings and authentication filter settings for the server. Realms
can:
• specify the users and user groups whose activity you want to monitor.
• allow you to query the server for user metadata on authoritative users.
You can add multiple servers as directories within a realm, but they must share the same basic realm
information. The directories within a realm must be exclusively LDAP or exclusively AD servers. After
you enable a realm, your saved changes take effect next time the ASA FirePOWER module queries the
server.
To perform user awareness, you must configure a realm for any of the supported server types. The
module uses these connections to query the servers for data associated with POP3 and IMAP users. The
module uses the email addresses in POP3 and IMAP logins to correlate with LDAP users on an Active
Directory, OpenLDAP, or Oracle Directory Server Enterprise Edition server. For example, if a device
detects a POP3 login for a user with the same email address as an LDAP user, the module associates the
LDAP user’s metadata with that user.
To perform user access control, you can configure the following:
• a realm for an AD server configured for either a User Agent or ISE device.
• a realm for an Oracle or OpenLDAP server configured for captive portal.
If you configure a realm to download users (for user awareness or user control), the ASA FirePOWER
module regularly queries the server to obtain metadata for new and updated users whose activity was
detected since the last query.
User activity data is stored in the user activity database and user identity data is stored in the users
database. The maximum number of users you can store and use in access control depends on your device
model. When choosing which users and groups to include, make sure the total number of users is less
than your model limit. If your access control parameters are too broad, the ASA FirePOWER module
obtains information on as many users as it can and reports the number of users it failed to retrieve in the
task queue.
Note If you remove a user that has been detected by the module from your LDAP servers, the ASA
FirePOWER module does not remove that user from its users database; you must manually delete it.
However, your LDAP changes are reflected in access control rules when the ASA FirePOWER module
next updates its list of authoritative users.
Cisco recommends that you limit the size of your LDAP or AD server groups to contain a maximum
of 1500 users. Configuring realms to include or exclude oversized groups, or creating access control
rules that target oversized user groups may result in performance issues.
• By default, AD 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 ASA
FirePOWER module.
Creating a Realm
License: Control
To create a realm:
What to Do Next
• Enable the realm as described in Enabling or Disabling a Realm, page 29-17.
• Optionally, monitor the task status; see the Task Status page (Monitoring > ASA FirePOWER Monitoring
> Task Status).
Realm Fields
License: Any
The following fields are used to configure a realm.
AD Primary Domain
For AD realms only, the domain for the Active Directory server where users should be authenticated.
Description
An optional description for the realm.
Base DN
The directory tree on the server where the ASA FirePOWER module should begin searching for user
data.
Typically, the base DN has a basic structure indicating the company domain and operational unit.
For example, the Security organization of the Example company might have a base DN of
ou=security,dc=example,dc=com.
Group DN
The directory tree on the server where the ASA FirePOWER module should search for users with
the group attribute.
Group Attribute
The group attribute for the server: Member, Unique Member, or Custom.
Name
A unique name for the realm.
Type
The type of realm, AD or LDAP.
Encryption
The encryption method you want to use for the server connection. If you specify an Encryption
method, you must specify a host name in this field.
Hostname / IP Address
The hostname or IP address for the server.
Port
The port you want to use for the server connection.
SSL Certificate
The SSL certificate you want to use for authentication to the server. You must configure the
Encryption type in order to use an SSL certificate.
If you are using a certificate to authenticate, the name of the server in the certificate must match the
server Hostname / IP Address. For example, if you use 10.10.10.250 as the IP address but
computer1.example.com in the certificate, the connection fails.
Step 1 On the Add New Realm page, type a Name and, optionally, a Description.
Step 2 Select a Type from the drop-down list.
Step 3 If you are configuring an AD realm, enter an AD Primary Domain.
Step 4 Enter a distinguished Directory Username and Directory Password for a user with appropriate rights to the
user information you want to retrieve.
Step 5 Enter a Base DN for the directory.
Step 6 Enter a Group DN for the directory.
Step 7 Optionally, select a Group Attribute from the drop-down list.
Step 8 Click OK.
What to Do Next
• Configure the realm directory as described in Configuring a Realm Directory, page 29-7.
What to Do Next
• Optionally, configure automatic user download as described in Configuring Automatic User
Download, page 29-7.
If you do not specify any groups to include, the ASA FirePOWER module retrieves user data for all the
groups that match the parameters you provided. For performance reasons, Cisco recommends that you
explicitly include only the groups that represent the users you want to use in access control.
Step 1 On the User Download tab, select the Download users and groups (required for user access control) check box.
Step 2 Select a time to Begin automatic download at from the drop-down lists.
Step 3 Select a download interval from the Repeat Every drop-down list.
Step 4 To include or exclude user groups from the download, select user groups from the Available Groups
column and click Add to Include or Add to Exclude.
Step 5 To include or exclude individual users, type the user into the field below Groups to Include or Groups to
Exclude and click Add.
Note Excluding users from download prevents you from writing an access control rule with that user
as a condition. Separate multiple users with commas. You can also use an asterisk (*) as a
wildcard character in this field.
Note If the module is performing user timeouts at unexpected intervals, confirm that the time on your User
Agent or ISE device is synchronized with the time on the ASA FirePOWER module.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Identity Policy.
Step 2 Type a Name and, optionally, a Description.
Step 3 If you want to add a rule to the policy, click Add Rule as described in Creating an Identity Rule,
page 29-11
Step 4 If you want to add a rule category, click Add Category as described in Adding an Identity Rule Category,
page 29-18
Step 5 If you want to configure active authentication using captive portal, click Active Authentication as
described in Configuring Captive Portal (Active Authentication), page 29-9.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Server Certificate
The server certificate presented by the captive portal daemon.
Port
The port number you want to use for the captive portal connection. The port number in this field
must match the port number you configured on the ASA FirePOWER device using the
captive-portal CLI command.
• If you want to perform active authentication via captive portal on HTTPS traffic, you must create
SSL rules to decrypt the traffic originating from the users you want to authenticate using captive
portal.
• If you want to decrypt traffic in the captive portal connection, create an SSL rule to decrypt the
traffic destined for the port you plan to use for captive portal.
• Use the captive-portal ASA CLI command to enable captive portal for active authentication and
define the port as described in the ASA Firewall Configuration Guide (Version 9.5(2) or later):
http://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products
-installation-and-configuration-guides-list.html.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Identity Policy and edit an identity policy.
Step 2 Click Active Authentication.
Step 3 Select the appropriate Server Certificate from the drop-down list. Optionally, click the add icon ( ) to
create an object on the fly.
Step 4 Type a Port and specify the Maximum login attempts.
Step 5 Optionally, to authenticate users through a HTTP response page, select an Active Authentication Response
Page.
Step 6 Click Save.
Step 7 Configure an identity rule with Active Authentication as the Action as described in Creating an Identity
Rule, page 29-11. If you selected a response page in step 5, you must also select HTTP Response Page
as the Authentication Type.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Step 1 On the Realm & Settings tab of the identity rule editor page, use Cisco-provided filters in the Application
Filters list to narrow the list of applications you want to add to the filter.
• Click the arrow next to each filter type to expand and collapse the list.
• Right-click a filter type and click Check All or Uncheck All. Note that the list indicates how many
filters you have selected of each type.
• To narrow the filters that appear, type a search string in the Search by name field; this is especially
useful for categories and tags. To clear the search, click the clear icon ( ).
• To refresh the filters list and clear any selected filters, click the reload icon ( ).
• To clear all filters and search fields, click Clear All Filters.
Step 2 Select the applications that you want to add to the filter from the Available Applications list:
• Select All apps matching the filter to add all the applications that meet the constraints you specified in
the previous step.
• To narrow the individual applications that appear, type a search string in the Search by name field. To
clear the search, click the clear icon ( ).
• Use the paging icons at the bottom of the list to browse the list of individual available applications.
• To refresh the applications list and clear any selected applications, click the reload icon ( ).
Step 3 Add the selected applications to exclude from external authentication. You can click and drag, or you
can click Add to Rule. The result is the combination of:
• the selected Application Filters
• either the selected individual Available Applications, or All apps matching the filter
What to Do Next
• Continue configuring the identity rule as described in Creating an Identity Rule, page 29-11.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
Step 2 Select the Advanced tab.
Step 3 Click the edit icon ( ) next to Identity Policy Settings.
Step 4 Select an identity policy from the drop-down.
Step 5 Click OK.
Step 6 Click Store ASA FirePOWER Changes to save your changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Identity Policy.
Step 2 Click Add Rule.
Step 3 Configure basic identity rule information as described in Configuring Basic Identity Rule Information,
page 29-13.
Step 4 Optionally, add a zone condition as described in Adding a Zone Condition to an Identity Rule,
page 29-14.
Step 5 Optionally, add a network or geolocation condition as described in Adding a Network or Geolocation
Condition to an Identity Rule, page 29-13.
Step 6 Optionally, add a port condition as described in Adding a Port Condition to an Identity Rule, page 29-14.
Step 7 Associate the rule with a realm as described in Associating a Realm and Configuring Active
Authentication Settings in an Identity Rule, page 29-15.
Step 8 Click Add.
Step 9 Click Store ASA FirePOWER Changes.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Enabled
Selecting this option enables the identity rule in the identity policy. Deselecting this option disables
the identity rule.
Action
The type of authentication you want to perform on the users in the specified Realm. You can select
Passive Authentication (User Agent or ISE), Active Authentication (captive portal), or No
Authentication. You must fully configure the authentication method, or identity source, before
selecting it as the action in an identity rule.
Realm
The realm containing the users you want to perform the specified Action on. You must fully configure
a realm before selecting it as the realm in an identity rule.
Authentication Type
The method you want to use to perform active authentication. The selections vary depending on the
type of realm, LDAP or AD:
– Select HTTP Basic if you want to authenticate users using an unencrypted HTTP Basic
Authentication (BA) connection. Users log in to the network using their browser's default
authentication popup window.
– Select NTLM if you want to authenticate users using a NT LAN Manager (NTLM) connection.
This selection is only available when you select an AD realm. Users log in to the network using
their browser's default authentication popup window. If you select NTLM as your identity rule
Authentication Type, you cannot use a 2003 Windows Server as your identity rule realm.
– Select HTTP Negotiate to allow the captive portal server to choose between HTTP Basic or
NTLM for the authentication connection. This selection is only available when you select an
AD realm. Users log in to the network using their browser's default authentication popup
window.
– Select HTTP Response Page if you want to authenticate users using a ASA FirePOWER
module-provided or custom HTTP response page. Users log in to the network using the response
page you configure.
Step 1 On the identity rule editor page, select the Networks tab.
Step 2 Find the networks you want to add from the Available Networks, as follows:
• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list.
• To search for network or geolocation objects to add, select the appropriate tab, click the Search by
name or value prompt above the Available Networks list, then type an object name or the value of one
of the object’s components. 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 Source or Add to Destination.
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 Click Add or continue editing the rule.
Step 1 On the identity rule editor page, select the Ports tab.
Step 2 Find the TCP ports you want to add from the Available Ports, as follows:
• To add a TCP port object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Ports list.
• To search for TCP-based port objects and groups to add, click the Search by name or value prompt
above the Available Ports list, then type either the name of the object, or the value of a port in the
object. The list updates as you type to display matching objects. For example, if you type 443, the
ASA FirePOWER module displays the provided HTTPS port object.
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.
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 ASA FirePOWER module will not add a port to a rule condition that results in an invalid
configuration.
Step 1 On the identity rule editor page, select the Zones tab.
Step 2 Find the zones you want to add from the Available Zones. To search for zones to add, click the Search by
name prompt above the Available Zones list, then type a zone name. The list updates as you type to display
matching zones.
Step 3 Click to select a zone. To select all zones, right-click and then select Select All.
Step 4 Click Add to Source or Add to Destination.
Step 5 Click Add or continue editing the rule.
Step 1 On the identity rule editor page, select the Realm & Settings tab.
Step 2 Select a Realm from the drop-down list.
Step 3 Optionally, select the Use active authentication if passive authentication cannot identify user check box. Note
that this check box appears only when configuring a Passive Authentication rule.
Step 4 If you selected the check box in step 3, or if this is an Active Authentication rule, continue with step 4.
Otherwise, skip to step 8.
Step 5 Optionally, select the Identify as Special Identities/Guest if authentication cannot identify user check box.
Step 6 Select an Authentication Type from the drop-down list.
Step 7 Optionally, Exclude HTTP User-Agents to exempt specific application traffic from active authentication as
described in Excluding Applications From Active Authentication, page 29-10.
Step 8 Click Add or continue editing the rule.
Managing Realms
License: Control
To manage a Realm:
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Realms.
Step 2 If you want to delete a realm, click the delete icon ( ).
Step 3 If you want to edit a realm, click the edit icon ( ) next to the realm and make changes as described in
Creating a Realm, page 29-4.
Step 4 If you want to enable or disable a realm, click the State slider next to the realm you want to enable or
disable as described in Enabling or Disabling a Realm, page 29-17.
Step 5 If you want to download users and user groups on demand, click the download icon ( ) as described
in Downloading Users and User Groups On-Demand, page 29-16.
Step 6 If you want to copy a realm, click the copy icon ( ).
Step 7 If you want to compare realms, see Comparing Realms, page 29-16.
Comparing Realms
License: Control
To Compare Realms:
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Realms.
Step 2 Click Compare Realms.
Step 3 Select Compare Realm from the Compare Against drop-down list.
Step 4 Select the realms you want to compare from the Realm A and Realm B drop-down lists.
Step 5 Click OK.
Step 6 If you want to navigate individually through changes, click Previous or Next above the title bar.
Step 7 Optionally, click Comparison Report to generate the realm comparison report.
Step 8 Optionally, click New Comparison to generate a new realm comparison view.
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Realms.
Step 2 Click the download icon ( ) next to the realm where you want to download users and user groups.
What to Do Next
• Optionally, monitor the task status; see the Task Status page (Monitoring > ASA FirePOWER Monitoring
> Task Status).
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Realms.
Step 2 Click the State slider next to the realm you want to enable or disable.
What to Do Next
• Optionally, monitor the task status; see the Task Status page (Monitoring > ASA FirePOWER Monitoring
> Task Status).
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Identity Policy.
Step 2 If you want to copy a policy, click the copy icon ( ).
Step 3 If you want to generate a report for the policy, click the report icon ( ).
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Identity Policy.
Step 2 If you want to edit an identity rule, click the edit icon ( ) and make changes as described in Creating
an Identity Rule, page 29-11.
Step 3 If you want to delete an identity rule, click the delete icon ( ).
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Step 1 On the identity rule editor page, you have the following choices:
• Select above Category from the first Insert drop-down list, then select the category above which you
want to position the rule from the second drop-down list.
• Select below rule from the drop-down list, then enter an existing rule number. This option is valid
only when at least one rule exists in the policy.
• Select above rule from the drop-down list, then, enter an existing rule number. This option is valid
only when at least one rule exists in the policy.
Step 2 Click OK.
Note Rules in a category you delete are added to the category above.
User Agent
If you experience issues with the User Agent connection, see the Firepower User Agent Configuration
Guide.
If you experience issues with user data reported by the User Agent, note the following:
• After the system detects activity from a User Agent user whose data is not yet in the database, the
system retrieves information about them from the server. In some cases, the system requires up to
60 minutes to successfully retrieve this information from Active Directory servers. Until the data
retrieval succeeds, activity seen by the User Agent user is handled by access control rules, and is not
displayed in the web interface.
ISE
If you experience issues with the ISE connection, check the following:
• The pxGrid Identity Mapping feature within ISE must be enabled before you can successfully
integrate ISE with the Firepower System.
• All ISE system certificates and Firepower Management Center certificates must include the
serverAuth and clientAuth extended key usage values.
• The time on your ISE device must be synchronized with the time on the Firepower Management
Center. If the appliances are not synchronized, the system may perform user timeouts at unexpected
intervals.
• If your deployment includes a primary and a secondary pxGrid node, the certificates for both nodes
must be signed by the same certificate authority.
• If your deployment includes a primary and a secondary MNT node, the certificates for both nodes
must be signed by the same certificate authority.
If you experience issues with user data reported by ISE, note the following:
• After the system detects activity from an ISE user whose data is not yet in the database, the system
retrieves information about them from the server. In some cases, the system requires up to 60
minutes to successfully retrieve this information from Active Directory servers. Until the data
retrieval succeeds, activity seen by the ISE user is handled by access control rules, and is not
displayed in the web interface.
Captive Portal
If you experience issues with captive portal authentication, note the following:
• After a captive portal user enters their login credentials, the system checks their credentials against
the data in the server. In some cases, if the user’s data was not yet in the database, the system requires
up to 60 minutes to successfully retrieve this information from Active Directory servers. Until the
data retrieval succeeds, the captive portal user is not authenticated.
If the captive portal user is not authenticated after 25 seconds, the system displays an error message
and the captive portal user’s session times out. The user must retry their captive portal login.
• Connections between the ASA FirePOWER module and the monitored LDAP servers, configured as
directories within identity realms.
You can install an agent on any computer or server running:
• Microsoft Windows Vista
• Microsoft Windows 7
• Microsoft Windows 8
• Microsoft Windows Server 2003
• Microsoft Windows Server 2008
• Microsoft Windows Server 2012
The computer must also have TCP/IP access to the device and the Microsoft Active Directory servers
you want to monitor. You can also install an agent on any Active Directory server running one of the
supported operating systems. If you want to perform real-time data retrieval, the server must be running
Windows Server 2008 or Windows Server 2012.
For detailed information about the multi-step User Agent configuration and a complete discussion of the
server requirements, see the User Agent Configuration Guide.
The ASA FirePOWER module connection not only allows you to retrieve metadata for the users whose
logins and logoffs were detected by User Agents, but also is used to specify the users and groups you
want to use in access control rules. If the agent is configured to exclude specific user names, login data
for those user names are not reported to the ASA FirePOWER module. User agent data is stored in the
user database and user activity database on the device.
Note User Agents cannot transmit Active Directory user names ending with the $ character to the ASA
FirePOWER module. You must remove the final $ character if you want to monitor these users.
If multiple users are logged into a host using remote sessions, the agent may not detect logins from that
host properly. For information about how to prevent this, see the User Agent Configuration Guide.
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Identity Sources.
Step 2 Select User Agent for the Service Type to enable the User Agent connection.
Step 3 Click the Add New Agent button to add a new agent.
Step 4 Type the Hostname or Address of the computer where you plan to install the agent. You must use an IPv4
address; you cannot configure the ASA FirePOWER module to connect to a User Agent using an IPv6
address.
Step 5 Click Add.
Step 6 To delete a connection, click the delete icon ( ) and confirm that you want to delete it.
What to Do Next
• Continue User Agent setup as described in the Firepower User Agent Configuration Guide.
Caution If you configure ISE to monitor a large number of user groups, the system may drop user mappings based
on groups, due to memory limitations. As a result, access control rules with realm or user conditions may
not fire as expected.
Note Make sure the time on your ISE device is synchronized with the time on the ASA FirePOWER module.
If the appliances are not synchronized, the system may perform user timeouts at unexpected intervals.
Configuring an ISE connection also populates the ASA FirePOWER module database with ISE attribute
data: Security Group Tag (SGT), Endpoint Profile, and Endpoint Location. ISE attributes can be
used for user awareness and in access control rule conditions.
Endpoint Location
The Endpoint Location attribute is applied by Cisco ISE and identifies the IP address of the endpoint
device.
Endpoint Profile
The Endpoint Profile attribute is applied by Cisco ISE and identifies the endpoint device type for
each packet.
For more information about the Cisco ISE product, see the Cisco Identity Services Engine Administrator
Guide.
ISE Fields
The following fields are used to configure a connection to ISE.
pxGrid Server CA
The certificate authority for the pxGrid framework. If your deployment includes a primary and a
secondary pxGrid node, the certificates for both nodes must be signed by the same certificate
authority.
MNT Server CA
The certificate authority for the ISE certificate when performing bulk downloads. If your
deployment includes a primary and a secondary MNT node, the certificates for both nodes must be
signed by the same certificate authority.
MC Server Certificate
The certificate and key that the ASA FirePOWER module should provide to ISE when connecting
to ISE or performing bulk downloads.
Step 1 Select Configuration > ASA FirePOWER Configuration > Integration > Identity Sources.
Step 2 Select Identity Services Engine for the Service Type to enable the ISE connection.
Step 3 Type a Primary Host Name/IP Address and, optionally, a Secondary Host Name/IP Address.
Step 4 Select the appropriate certificates from the pxGrid Server CA, MNT Server CA, and MC Server Certificate
drop-down lists. Optionally, click the add icon ( ) to create an object on the fly.
Step 5 Optionally, type an ISE Network Filter using CIDR block notation.
• POP3 and IMAP user logins detected by traffic-based detection, if those users have the same email
address as an LDAP or AD user. This metadata can be used for user awareness.
You configure an ASA FirePOWER module user database-server connection as a directory within a
realm. You must select the Download users and user groups for access control check box to download a
realm's user and user group data for user awareness and user control.
The ASA FirePOWER module obtains the following information and metadata about each user:
• LDAP user name
• first and last names
• email address
• department
• telephone number
The following topics explain DNS policies, DNS rules, and how to deploy DNS policies.
• DNS Policy Overview, page 31-1
• DNS Policy Components, page 31-1
• DNS Rules, page 31-2
• DNS Policy Deploy, page 31-8
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 ASA FirePOWER module matches traffic to DNS rules
in top-down order by ascending rule number.
When you create a DNS policy, the ASA FirePOWER module populates it with a default Global
DNS Whitelist rule, and a default Global DNS Blacklist rule. Each rule is fixed to the first position
in their respective categories. You cannot modify these rules, but you can disable them. The module
evaluates rules in the following order:
– Global DNS Whitelist rule (if enabled)
– whitelist rules
– Global DNS Blacklist rule (if enabled)
– blacklist and monitor rules
Usually, the module handles domain name-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 module continues
evaluating the traffic based on the associated access control policy's rules. DNS rule conditions can be
simple or complex.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > DNS Policy.
Step 2 Edit your DNS policy:
• Name and Description - To change the name or description, click the field and type the new
information.
• Rules - To add, categorize, enable, disable, or otherwise manage DNS rules, click the Rules tab and
proceed as described in Creating and Editing DNS Rules, page 31-3.
Step 3 Click Store ASA FirePOWER Changes.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
DNS Rules
License: Any
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 ASA FirePOWER module matches traffic to DNS rules in the order you specify. In most cases, the
module handles network traffic according to the first DNS rule where all the rule’s conditions match the
traffic. When you create DNS rules, the module 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 ASA FirePOWER module 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 ASA FirePOWER module 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 or network.
Action
A rule’s action determines how the ASA FirePOWER module 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 module 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > DNS Policy.
Step 2 You have the following options:
• To add a new rule, click Add DNS Rule.
• To edit an existing rule, click the edit icon ( ).
Step 3 Enter a Name.
Step 4 Configure the rule components, or accept the defaults:
• Action - Select a rule Action; see DNS Rule Actions, page 31-5.
• Conditions - Configure the rule’s conditions; see DNS Rule Conditions, page 31-6.
• Enabled - Specify whether the rule is Enabled.
Step 5 Click Add or OK.
Step 6 Click Store ASA FirePOWER Changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > DNS Policy.
Step 2 In the DNS policy editor that contains the rule you want to enable or disable, right-click the rule and
choose a rule state.
Step 3 Click OK.
Step 4 Click Store ASA FirePOWER Changes.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
• For non-Monitor rules, the module does not continue to evaluate traffic against additional,
lower-priority DNS rules after that traffic matches a rule.
Note the following regarding rule order:
• The Global Whitelist is always first, and takes precedence over all other rules.
• The Whitelist section precedes the Blacklist section; whitelist rules always take precedence over
other rules.
• The Global Blacklist is always first in the Blacklist section, and takes precedence over all other
Monitor and blacklist rules.
• The Blacklist section contains Monitor and blacklist rules.
• When you first create a DNS rule, the module positions it last in the Whitelist section if you assign
a Whitelist action, or last in the Blacklist section if you assign any other action.
You can drag and drop rules to reorder them, and change the evaluation order.
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 module 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 module 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 ASA FirePOWER module logs end-of-connection
Security Intelligence and connection events.
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 module 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 module logs
end-of-connection connection events for the follow-on connection. If you configure your sinkhole object
to log and block sinkhole connections, the module logs beginning-of-connection connection events for
the follow-on connection, then blocks that connection.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Step 4 Add any source IP addresses or address blocks that you want to specify manually. Click the Enter an IP
address prompt below the Source Networks list; then type an IP address or address block and click Add.
Step 5 Save or continue editing the rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
• To add a DNS list or feed on the fly, which you can then add to the condition, click the add icon
( ) above the DNS Lists and Feeds list and proceed as described in Working with the Intelligence
Feed, page 2-6
• To search for DNS lists, feeds, or categories to add, click the Search by name or value prompt above
the DNS Lists and Feeds list, then type an object name or the value of one of the object’s components.
The list updates as you type to display matching objects.
Step 3 Click Add to Rule.
What to Do Next
• Deploy configuration changes; see Deploying Configuration Changes, page 4-10.
Malicious software, or malware, can enter your organization’s network via multiple routes. To help you
identify and mitigate the effects of malware, the ASA FirePOWER module’s file control and advanced
malware protection components can detect, track, store, analyze, and optionally block the transmission
of malware and other types of files in network traffic.
You configure the system to perform malware protection and file control as part of your overall access
control configuration. File policies that you create and associate with access control rules handle
network traffic that matches the rules.
Although you can create file policies with any license, certain aspects of malware protection and file
control require that you enable specific licensed capabilities on the ASA FirePOWER module, as
described in the following table.
Table 32-1 License and Appliance Requirements for Intrusion and File Inspection
eligible file, the ASA FirePOWER module then performs a malware cloud lookup using the file’s
SHA-256 hash value. Based on these results, the Cisco cloud returns a file disposition to the ASA
FirePOWER module.
If a file has a disposition in the 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 cloud assigned a clean disposition, add the file to the clean list.
• To treat a file as if the cloud assigned a malware disposition, add the file to the custom detection list.
If the system detects a file’s SHA-256 value on a file list, it takes the appropriate action without
performing a malware lookup or checking the file disposition. Note that 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. You can enable use of the clean list or custom detection list on a per-file-policy basis.
To inspect or block files, you must enable a Protection license on the ASA FirePOWER module. To add
files to a file list, you must also enable a Malware license.
Tip If you see several Unavailable malware events in quick succession, check your cloud connection and
port configuration. For more information, see Security, Internet Access, and Communication Ports,
page D-1.
Based on the file disposition, the ASA FirePOWER module either blocks the file or blocks its upload or
download. To improve performance, if the system already knows the disposition for a file based on its
SHA-256 value, your appliance uses the cached disposition rather than querying the Cisco cloud.
Note that file dispositions can change. For example, the 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 for which you performed a malware lookup
in the last week, the cloud notifies the ASA FirePOWER module so the system can take appropriate
action the next time it detects that file being transmitted. A changed file disposition is called a
retrospective disposition.
File dispositions returned from a malware cloud lookup have a time-to-live (TTL) value. After a file
disposition has been held for the duration specified in the TTL value without update, the system purges
the cached information. Dispositions have the following TTL values:
• Clean—4 hours
• Unknown—1 hour
• Malware—1 hour
If a malware cloud lookup against the cache identifies a cached disposition that timed out, the system
performs a fresh lookup to determine a file disposition.
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.
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 Malware file disposition
• In addition, the file policy can automatically treat a file as if it is clean or malware based on entries
in the clean list or custom detection list
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. For detailed information, see Inspecting Allowed Traffic For Intrusions and Malware,
page 10-2.
File Rules
You populate a file policy with file rules. The following table describes the components of a file rule.
Caution 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.
Note File rules are evaluated in rule-action, not numerical, order. For more
information, see the next section, File Rule Actions and Evaluation
Order.
For each file rule action, you can configure options to reset the connection when a file transfer is blocked
and store captured files to the ASA FirePOWER module. The following table details the options
available to each file action.
File and Malware Detection, Capture, and Blocking Notes and Limitations
Note the following details and limitations on file and malware detection, capture, and blocking behavior:
• Until a file is detected and block in a session, packets from the session may be subject to intrusion
inspection.
• If an end-of-file marker is not detected for a file, regardless of transfer protocol, the file is not
blocked by a Block Malware rule or by the custom detection list. The system waits to block the file
until the entire file has been received, as indicated by the end-of-file marker, and blocks the file after
the marker is detected.
• If the end-of-file marker for an FTP file transfer is transmitted separately from the final data
segment, the marker is blocked and the FTP client indicates that the file transfer failed, but the file
actually completely transfers to disk.
• FTP transfers commands and data over different channels. In a passive deployment, the traffic from
an FTP data session and its control session may not be load-balanced to the same Snort.
• If a file matches a rule with an application protocol condition, file event generation occurs after the
system successfully identifies a file’s application protocol. Unidentified files do not generate file
events.
• For an access control policy using a file policy with Block Malware rules for FTP, if you set the
default action to an intrusion policy with Drop when Inline disabled, the system generates events for
detected files or malware matching the rules, but does not drop the files. To block FTP fire transfers
and use an intrusion policy as the default action for the access control policy where you select the
file policy, you must select an intrusion policy with Drop when Inline enabled.
• File rules with Block Files and Block Malware actions block automatic resumption of file download
via HTTP by blocking new sessions with the same file, URL, server, and client application detected
for 24 hours after the initial file transfer attempt occurs.
• In rare cases, if traffic from an HTTP upload session is out of order, the system cannot reassemble
the traffic correctly and therefore does not block it or generate a file event.
• If you transfer a file over NetBIOS-ssn (such as an SMB file transfer) that is blocked with a Block
Files rule, you may see a file on the destination host. However, the file is unusable because it is
blocked after the download starts, resulting in an incomplete file transfer.
• If you create file rules to detect or block files transferred over NetBIOS-ssn (such as an SMB file
transfer), the system does not inspect files transferred in an established TCP or SMB session started
before you apply an access control policy invoking the file policy, so those files will not be detected
or blocked.
• A rule configured to block files in a passive deployment does not block matching files. Because the
connection continues to transmit the file, if you configure the rule to log the beginning of the
connection, you may see multiple events logged for this connection.
• 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 may
modify the size of the file. Note that some mail clients default to newline conversion when
processing an unrecognizable file type.
• Cisco recommends that you enable Reset Connection for the Block Files and Block Malware actions to
prevent blocked application sessions from remaining open until the TCP connection resets. If you
do not reset connections, the client session remains open until the TCP connection resets itself.
• If a file rule is configured with a Malware Cloud Lookup or Block Malware action and the ASA
FirePOWER module cannot establish connectivity with the cloud, the system cannot perform any
configured rule action options until cloud connectivity is restored.
The ASA FirePOWER module uses warning icons ( ) to designate conflicting file rules.
Note that you cannot perform malware analysis on all file types detected by the system. After you select
values from the Application Protocol, Direction of Transfer, and Action drop-down lists, the system constrains
the list of file types.
• file events, which represent detected or blocked files, as well as detected malware files
• malware events, which represent detected malware files
• retrospective malware events, which are generated when the Malware file disposition for a
previously detected file changes
When a file policy generates a file or malware event, or captures a file, the system automatically logs the
end of the associated connection, regardless of the logging configuration of the invoking access control
rule.
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.
Internet Access
The system uses port 443 to perform malware cloud lookups for network-based AMP. You must open
that port outbound on the ASA FirePOWER module.
For more information on managing file policies, see the following sections:
• Creating a File Policy, page 32-9
• Working with File Rules, page 32-9
• Comparing Two File Policies, page 32-12
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 1 Select Configuration > ASA FirePOWER Configuration > Policies > Files.
The File Policies page appears.
Step 2 Click New File Policy.
The New File Policy dialog box appears.
For a new policy, the module interface indicates that the policy is not in use. If you are editing an in-use
file policy, the module interface tells you how many access control policies use the file policy. In either
case, you can click the text to jump to the Access Control Policies page; see Getting Started with Access
Control Policies, page 4-1.
Step 3 Enter a Name and optional Description for your new policy, then click Save.
The File Policy Rules tab appears.
Step 4 Add one or more rules to the file policy.
File rules give you granular control over which file types you want to log, block, or scan for malware.
For information on adding file rules, see Working with File Rules, page 32-9.
Step 5 Configure the advanced options. See Configuring Advanced File Policy General Options, page 32-11 for
more information.
Step 6 Click Store ASA FirePOWER Changes.
To use your new policy, you must add the file policy to an access control rule, then apply the access
control policy. If you are editing an existing file policy, you must reapply any access control policies that
use the file policy.
To be effective, a file policy must contain one or more rules. You create, edit, and delete rules on the File
Policy Rules page, which appears when you create a new file policy or edit an existing policy. The page
lists all the rules in the policy, along with each rule’s basic characteristics.
The page also notifies you of how many access control policies use this file policy. You can click the
notification to display a list of the parent policies and, optionally, continue to the Access Control Policies
page.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Files.
The File Policies page appears.
Step 2 You have the following options:
• To add rules to a new policy, click New File Policy to create a new policy; see Creating a File Policy,
page 32-9.
• To add rules to an existing policy, click the edit icon ( ) next to the policy.
Step 3 On the File Policy Rules page that appears, click Add File Rule.
The Add File Rule dialog box appears.
Step 4 Select an Application Protocol from the drop-down list.
Any, the default, detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.
Step 5 Select a Direction of Transfer from the drop-down list.
You can inspect the following types of incoming traffic for downloaded files:
• HTTP
• IMAP
• POP3
• FTP
• NetBIOS-ssn (SMB)
You can inspect the following types of outgoing traffic for uploaded files:
• HTTP
• FTP
• SMTP
• NetBIOS-ssn (SMB)
Use Any to detect files over multiple application protocols, regardless of whether users are sending or
receiving.
Step 6 Select a file rule Action. See the File Rule Actions table for more information.
When you select either Block Files or Block Malware, Reset Connection is enabled by default. To not reset
the connection where a blocked file transfer occurs, clear the Reset Connection check box.
Note Cisco recommends that you leave Reset Connection enabled to prevent blocked application
sessions from remaining open until the TCP connection resets.
For detailed information on file rule actions, see File Rule Actions and Evaluation Order, page 32-5.
Step 7 Select one or more File Types. Use the Shift and Ctrl keys to select multiple file types. You can filter the
list of file types in the following ways:
• Select one or more File Type Categories.
• Search for a file type by its name or description. For example, type Windows in the Search name and
description field to display a list of Microsoft Windows-specific files.
The file types that you can use in a file rule vary depending on your selections for Application Protocol,
Direction of Transfer, and Action.
For example, selecting Download as the Direction of Transfer removes GIF, PNG, JPEG, TIFF, and ICO from
the Graphics category to prevent an excess of file events.
Step 8 Add the selected file types to the Selected Files Categories and Types list:
• Click Add to add selected file types to the rule.
• Drag and drop one or more file types into the Selected Files Categories and Types list.
• With a category selected, click All types in selected Categories, then either click Add or drag and drop
that selection to the Selected Files Categories and Types list.
Step 9 Click Store ASA FirePOWER Changes.
The file rule is added to the policy. If you are editing an existing file policy, you must reapply any access
control policies that use the file policy for your changes to take effect.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Files.
The File Policies page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
The File Policy Rule page appears.
Step 3 Select the Advanced tab.
The Advanced tab appears.
Step 4 Modify the options as described in the Advanced File Policy General Options table.
Step 5 Click Store ASA FirePOWER Changes.
You must reapply any access control policies that use the file policy you edited.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Files.
The File Policies page appears.
Step 2 Click Compare Policies.
The Select Comparison dialog box appears.
Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:
• To compare two different policies, select either Running Configuration or Other Policy. The practical
difference between the two options is that if you select Running Configuration, the system limits one
of your comparison choices to the set of currently applied file policies.
• To compare revisions of the same policy, select Other Revision.
The dialog box refreshes, displaying your comparison options.
Step 4 Depending on the comparison type you selected, you have the following choices:
• If you are comparing two different policies, select the policies you want to compare: Policy A or
Target/Running Configuration A, and Policy B.
• If you are comparing revisions of the same policy, select the Policy you want to use, then select the
two revisions: Revision A and Revision B. Revisions are listed by date and user name.
Step 5 Click OK.
The comparison view appears.
Optionally, click Comparison Report to generate a file policy comparison report. You are prompted to save
the report to your computer.
As devices monitor traffic generated by the hosts on your network, they can generate logs of the
connections they detect. Various settings in access control policies give you granular control over which
connections you log, when you log them, and where you store the data. An access control rule’s specific
logging configuration also determines whether you log file and malware events associated with the
connection.
In most cases, you can log a connection at its beginning and its end. When you log a connection, the
system generates a connection event. You can also log a special kind of connection event, called a
Security Intelligence event, whenever a connection is blacklisted (blocked) by the reputation-based
Security Intelligence feature.
Connection events contain data about the detected sessions.
You should log connections according to the security and compliance needs of your organization.
For more information on logging connection data, see:
• Deciding Which Connections To Log, page 33-1
• Logging Security Intelligence (Blacklisting) Decisions, page 33-8
• Logging Connections Based on Access Control Handling, page 33-9
• Logging URLs Detected in Connections, page 33-13
• Logging Encrypted Connections, page 33-14
Tip To perform detailed analysis of connection data using the ASA FirePOWER module, Cisco recommends
you log the ends of critical connections.
Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can overwhelm the system
with multiple similar events. Before you enable logging for an Block rule, consider whether the rule
monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.
In addition to the logging that you configure, the system automatically logs most connections where the
system detects a prohibited file, malware, or intrusion attempt. The system saves these
end-of-connection events for further analysis. All connection events reflect why they were automatically
logged using the Action and Reason fields.
However, when an intrusion policy associated with the access control default action (see Setting Default
Handling and Inspection for Network Traffic, page 4-4) generates an intrusion event, the system does
not automatically log the end of the associated connection. Instead, you must explicitly enable default
action connection logging. This is useful for intrusion prevention-only deployments where you do not
want to log any connection data.
For connections where an intrusion was blocked, the action for the connection in the connection log is
Block, with a reason of Intrusion Block, even though to perform intrusion inspection you must use an
Allow rule.
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.
For connections where a file was blocked, the action for the connection in the connection log is Block
even though to perform file and malware inspection you must use an Allow rule. The connection’s reason
is either File Monitor (a file type or malware was detected), or Malware Block or File Block (a file
was blocked).
Note For a single non-blocked connection, the end-of-connection event contains all of the information in the
beginning-of-connection event, as well as information gathered over the duration of the session.
Note that monitoring a connection for any reason forces end-of-connection logging; see Understanding
Logging for Monitored Connections, page 33-5.
The following table details the differences between beginning and end-of-connection events, including
the advantages to logging each.
• Disabling File and Malware Event Logging for Allowed Connections, page 33-7
Interactive blocking access control rules, which cause the system to display a warning page when a user
browses to a prohibited website, log ends of connections. This is because if the user clicks through the
warning page, the connection is considered a new, allowed connection which the system can monitor and
log; see Understanding Logging for Allowed Connections, page 33-6.
Therefore, for packets that match an Interactive Block or Interactive Block with reset rule, the system
can generate the following connection events:
• a beginning-of-connection event when a user’s request is initially blocked and the warning page is
displayed; this event has an associated action of Interactive Block or Interactive Block with
reset
• multiple beginning- or end-of-connection events if the user clicks through the warning page and
loads the originally requested page; these events have an associated action of Allow and a reason of
User Bypass
Note that only devices deployed inline can block traffic. Because blocked connections are not actually
blocked in passive deployments, the system may report multiple beginning-of-connection events for
each blocked connection.
Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can overwhelm the system
with multiple similar events. Before you enable logging for an Block rule, consider whether the rule
monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.
Note Cisco recommends you leave file and malware event logging enabled.
Regardless of whether you save file and malware events, when network traffic violates a file policy, the
system automatically logs the end of the associated connection to the ASA FirePOWER module,
regardless of the logging configuration of the invoking access control rule; see Connections Associated
with File and Malware Events (Automatic), page 33-3.
Table 33-2 License Requirements for Connection Logging in Access Control Policies
Table 33-2 License Requirements for Connection Logging in Access Control Policies (continued)
IP Block connection events have a threshold of 15 seconds per unique initiator-responder pair. That
is, once the system generates an event when it blocks a connection, it does not generate another
connection event for additional blocked connections between those two hosts for the next 15
seconds, regardless of port or protocol.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Security Intelligence tab.
Security Intelligence settings for the access control policy appear.
Step 4 Click the logging icon ( ).
The Blacklist Options pop-up window appears.
Step 5 Select the Log Connections check box.
Step 6 Specify where to send connection and Security Intelligence events. You have the following choices:
• To send events to the ASA FirePOWER module, select Event Viewer.
• To send events to an external syslog server, select Syslog, then select a syslog alert response from the
drop-down list. Optionally, you can add a syslog alert response by clicking the add icon ( ); see
Creating a Syslog Alert Response, page 35-3.
• To send connection events to an SNMP trap server, select SNMP Trap, then select an SNMP alert
response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the
add icon ( ); see Creating an SNMP Alert Response, page 35-2.
You must send events to the Event Viewer if you want to set blacklisted objects to monitor-only, or
perform any other ASA FirePOWER module-based analysis on connection events generated by Security
Intelligence filtering. For more information, see Logging Connections to the ASA FirePOWER Module
or External Server, page 33-4.
Step 7 Click OK to set your logging options.
The Security Intelligence tab appears again.
Step 8 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect; see Deploying Configuration
Changes, page 4-10.
Note that even if you disable logging for all access control rules and the default action,
end-of-connection events may still be logged to the ASA FirePOWER module if the connection matches
an access control rule and contains an intrusion attempt, prohibited file, or malware
Depending on the rule or default policy action and the associated inspection options that you configure,
your logging options differ. For more information, see:
• Logging Connections Matching an Access Control Rule, page 33-10
• Logging Connections Handled by the Access Control Default Action, page 33-11
To configure an access control rule to log connection, file, and malware information:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to modify.
The access control policy editor appears, focused on the Rules tab.
Step 3 Click the edit icon ( ) next to the rule where you want to configure logging.
The access control rule editor appears.
Step 4 Select the Logging tab.
The Logging tab appears.
Step 5 Specify whether you want to Log at Beginning and End of Connection, Log at End of Connection, or you want No
Logging at Connection.
For a single non-blocked connection, the end-of-connection event contains all of the information in the
beginning-of-connection event, as well as information gathered over the duration of the session. Because
blocked traffic is immediately denied without further inspection, the system logs only
beginning-of-connection events for Block rules. For this reason, when you set the rule action to Block or
Block with reset you are prompted Log at Beginning of Connection.
Step 6 Use the Log Files check box to specify whether the system should log any file and malware events
associated with the connection.
The system automatically enables this option when you associate a file policy with the rule to perform
either file control or AMP. Cisco recommends you leave this option enabled; see Disabling File and
Malware Event Logging for Allowed Connections, page 33-7.
Step 7 Specify where to send connection events. You have the following choices:
• To send connection events to the ASA FirePOWER module, select Event Viewer. You cannot
disable this option for Monitor rules.
• To send events to an external syslog server, select Syslog, then select a syslog alert response from the
drop-down list. Optionally, you can add a syslog alert response by clicking the add icon ( ); see
Creating a Syslog Alert Response, page 35-3.
• To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from
the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon ( );
see Creating an SNMP Alert Response, page 35-2.
You must send events to the event viewer if you want to perform ASA FirePOWER module-based
analysis on connection events. For more information, see Logging Connections to the ASA FirePOWER
Module or External Server, page 33-4.
Step 8 Click Store ASA FirePOWER Changes to save the rule.
Your rule is saved. You must apply the access control policy for your changes to take effect; see
Deploying Configuration Changes, page 4-10.
However, there are some differences between logging connections handled by access control rules versus
the default action:
• The default action has no file logging options. You cannot perform file control or AMP using the
default action.
• When an intrusion policy associated with the access control default action generates an intrusion
event, the system does not automatically log the end of the associated connection. This is useful for
intrusion detection and prevention-only deployments, where you do not want to log any connection
data.
An exception to this rule occurs if you enable beginning- and end-of-connection logging for the
default action. In that case, the system does log the end of the connection when an associated
intrusion policy triggers, in addition to logging the beginning of the connection.
Note that even if you disable logging for the default action, end-of-connection events for connections
matching that rule may still be logged to the ASA FirePOWER module if the connection previously
matched at least one access control Monitor rule.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to modify.
The access control policy editor appears, focused on the Rules tab.
Step 3 Click the logging icon ( ) next to the Default Action drop-down list.
The Logging pop-up window appears.
Step 4 Specify whether you want to Log at Beginning and End of Connection, Log at End of Connection, or you want No
Logging at Connection.
For a single non-blocked connection, the end-of-connection event contains all of the information in the
beginning-of-connection event, as well as information gathered over the duration of the session. Because
blocked traffic is immediately denied without further inspection, the system logs only
beginning-of-connection events for the Block All Traffic default action. For this reason, when you set
the default action to Access Control: Block All Traffic you are prompted Log at Beginning of Connection.
Step 5 Specify where to send connection events. You have the following choices:
• To send connection events to the ASA FirePOWER module, select Event Viewer. You cannot
disable this option for Monitor rules.
• To send events to an external syslog server, select Syslog, then select a syslog alert response from the
drop-down list. Optionally, you can add a syslog alert response by clicking the add icon ( ); see
Creating a Syslog Alert Response, page 35-3.
• To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from
the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon ( );
see Creating an SNMP Alert Response, page 35-2.
You must send events to the event viewer if you want to perform ASA FirePOWER module-based
analysis on connection events. For more information, see Logging Connections to the ASA FirePOWER
Module or External Server, page 33-4.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon ( ) next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Advanced tab.
Advanced settings for the access control policy appear.
Step 4 Click the edit icon ( ) next to General Settings.
The General Settings pop-up window appears.
Step 5 Type the Maximum URL characters to store in connection events.
You can specify any number from zero to 4096. Storing zero characters disables URL storage without
disabling URL filtering.
Step 6 Click OK.
Advanced settings for the access control policy appear.
Step 7 Click Store ASA FirePOWER Changes to save the policy.
Your policy is saved. You must apply the access control policy for your changes to take effect; see
Deploying Configuration Changes, page 4-10.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the edit icon ( ) next to the rule where you want to configure logging.
The SSL rule editor appears.
Step 3 Select the Logging tab.
The Logging tab appears.
Step 4 Select Log at End of Connection.
Step 5 Specify where to send connection events. You have the following choices:
• To send events to an external syslog, select Syslog, then select a syslog alert response from the
drop-down list. Optionally, you can add a syslog alert response by clicking the add icon ( ); see
Creating a Syslog Alert Response, page 35-3.
• To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from
the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon ( );
see Creating an SNMP Alert Response, page 35-2.
Step 6 Click Add to save your changes.
You must apply the access control policy the SSL policy is associated with for your changes to take
effect; see Deploying Configuration Changes, page 4-10.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > SSL.
The SSL Policy page appears.
Step 2 Click the logging icon ( ) next to the Default Action drop-down list.
The Logging pop-up window appears.
Step 3 Select Log at End of Connection to enable logging connection events.
Step 4 Specify where to send connection events. You have the following choices:
• To send events to an external syslog server, select Syslog, then select a syslog alert response from the
drop-down list. Optionally, you can configure a syslog alert response by clicking the add icon ( );
see Creating a Syslog Alert Response, page 35-3.
• To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from
the drop-down list. Optionally, you can configure an SNMP alert response by clicking the add icon
( ); see Creating an SNMP Alert Response, page 35-2.
Step 5 Click OK to save your changes.
You must apply the access control policy the SSL policy is associated with for your changes to take
effect; see Deploying Configuration Changes, page 4-10.
You can view real-time events logged against the traffic inspected by the ASA FirePOWER module.
Note The module only caches the most recent 100 events in memory.
Note The module only caches the most recent 100 events in memory.
Step 1 Select Monitoring > ASA FirePOWER Monitoring > Real-time Eventing.
Step 2 You have two choices:
• Click an existing tab for the type of event you want to view: connection events, security intelligence
events, intrusion events, file events, or malware events.
• Click the + icon to create a custom event view and select the event fields you want to include in the
view.
For more information, see Understanding ASA FirePOWER Event Types, page 34-2 and Event Fields in
ASA FirePOWER Events, page 34-3.
Connection Events
Connection logs, called connection events, contain data about the detected sessions. The information
available for any individual connection event depends on several factors, but in general includes:
• basic connection properties: timestamp, source and destination IP address, ingress and egress zones,
the device that handled the connection, and so on
• additional connection properties discovered or inferred by the system: applications, requested
URLs, or users associated with the connection, and so on
• metadata about why the connection was logged: which access control rule (or other configuration)
in which policy handled the traffic, whether the connection was allowed or blocked, and so on
Various settings in access control give you granular control over which connections you log, when you
log them, and where you store the data. You can log any connection that your access control policies can
successfully handle. You can enable connection logging in the following situations:
• when a connection is blacklisted (blocked) or monitored by the reputation-based Security
Intelligence feature
• when a connection is handled by an access control rule or the access control default action
In addition to the logging that you configure, the system automatically logs most connections where the
system detects a prohibited file, malware, or intrusion attempt.
Tip General information about connection events also pertains to Security Intelligence events, unless
otherwise noted. For more information on Security Intelligence, see Blacklisting Using Security
Intelligence IP Address Reputation, page 5-1.
Intrusion Events
The system examines the packets that traverse your network for malicious activity that could affect the
availability, integrity, and confidentiality of a host and its data. When the system identifies a possible
intrusion, it generates an intrusion event, which is a record of the date, time, type of exploit, and
contextual information about the source of the attack and its target.
File Events
File events represent files that the system detected, and optionally blocked, in network traffic.
The system logs the file events generated when a managed device detects or blocks a file in network
traffic, according to the rules in currently applied file policies.
Malware Events
Malware events represent malware files detected, and optionally blocked, in network traffic by the
system.
With a Malware license, your ASA FirePOWER module can detect malware in network traffic as part of
your overall access control configuration; see Understanding and Creating File Policies, page 32-4.
The following scenarios can lead to generating malware events:
• If a managed device detects one of a set of specific file types, the ASA FirePOWER module
performs a malware cloud lookup, which returns a file disposition to the ASA FirePOWER module
of Malware, Clean, or Unknown.
• If the ASA FirePOWER module cannot establish a connection with the cloud, or the cloud is
otherwise unavailable, the file disposition is Unavailable. You may see a small percentage of events
with this disposition; this is expected behavior.
• If the managed device detects a file on the clean list, the ASA FirePOWER module assigns a file
disposition of Clean to the file.
The ASA FirePOWER module logs records of files’ detection and dispositions, along with other
contextual data, as malware events.
Files detected in network traffic and identified as malware by the ASA FirePOWER module generate
both a file event and a malware event. This is because to detect malware in a file, the system must first
detect the file itself.
Allowed Connection
Whether the system allowed the traffic flow for the event.
Application
The application detected in the connection.
Application Categories
Categories that characterize the application to help you understand the application's function.
Application Risk
The risk associated with the application traffic detected in the connection: Very High, High, Medium,
Low, or Very Low. Each type of application detected in the connection has an associated risk; this
field displays the highest of those.
Application Tag
Tags that characterize the application to help you understand the application's function.
Block Type
The type of block specified in the access control rule matching the traffic flow in the event: block
or interactive block.
Client
The client application detected in the connection.
If the system cannot identify the specific client used in the connection, this field displays client
appended to the application protocol name to provide a generic name, for example, FTP client.
Client Categories
Categories that characterize the client detected in the traffic to help you understand the client’s
function.
Client Risk
The risk associated with the client traffic detected in the connection: Very High, High, Medium, Low,
or Very Low. Each type of client detected in the connection has an associated risk; this field displays
the highest of those.
Client Tag
Tags that characterize the client detected in the traffic to help you understand the client’s function.
Client Version
The version of the client detected in the connection.
Connection
The unique ID for the traffic flow, internally generated.
Connection Bytes
The total bytes for the connection.
Connection Time
The time for the beginning of the connection.
Connection Timestamp
The time the connection was detected.
Context
The metadata identifying the security context through which the traffic passed. Note that the system
only populates this field for devices in multiple context mode.
Denied Connection
Whether the system denied the traffic flow for the event.
Destination IP
The IP address used by the receiving host.
Direction
The direction of transmission for a file.
Disposition
One of the following file dispositions:
– Malware indicates that the cloud categorized the file as malware.
– Clean indicates that the cloud categorized the file as clean, or that a user added the file to the
clean list.
– Unknown indicates that a malware cloud lookup occurred before the cloud assigned a
disposition. The file is uncategorized.
– Custom Detection indicates that a user added the file to the custom detection list.
– Unavailable indicates that the ASA FirePOWER module could not perform a malware cloud
lookup. You may see a small percentage of events with this disposition; this is expected
behavior.
– N/A indicates a Detect Files or Block Files rule handled the file and the ASA FirePOWER
module did not perform a malware cloud lookup.
Egress Interface
The egress interface associated with the connection. Note that, if your deployment includes an
asynchronous routing configuration, the ingress and egress interface may belong to the same
interface set.
Event
The event type.
Event Microseconds
The time, in microseconds, when the event was detected.
Event Seconds
The time, in seconds, when the event was detected.
Event Type
The type of event.
File Category
The general categories of file type, for example: Office Documents, Archive, Multimedia,
Executables, PDF files, Encoded, Graphics, or System Files.
File Name
The name of the file or malware file.
File SHA256
The SHA-256 hash value of the file.
File Size
The size of the file or malware file, in kilobytes.
File Type
The file type of the file or malware file, for example, HTML or MSEXE.
File/Malware Policy
The file policy associated with the generation of the event.
Firewall Rule
The access control rule or default action that handled the connection, as well as up to eight Monitor
rules matched by that connection.
First Packet
The date and time the first packet of the session was seen.
HTTP Referrer
The HTTP referrer, which represents the referrer of a requested URL for HTTP traffic detected in
the connection (such as a website that provided a link to, or imported a link from, another URL).
IDS Classification
The classification where the rule that generated the event belongs. See the Rule Classifications table
for a list of rule classification names and numbers.
Impact
The impact level in this field indicates the correlation between intrusion data, network discovery
data, and vulnerability information.
Impact Flag
See Impact.
Ingress Interface
The ingress interface associated with the connection. Note that, if your deployment includes an
asynchronous routing configuration, the ingress and egress interface may belong to the same
interface set.
Initiator Bytes
The total number of bytes transmitted by the session initiator.
Initiator IP
The host IP address (and host name, if DNS resolution is enabled) that initiated the session
responder.
Initiator Packets
The total number of packets transmitted by the session initiator.
Inline Result
One of the following:
– a black down arrow, indicating that the system dropped the packet that triggered the rule
– a gray down arrow, indicating that IPS would have dropped the packet if you enabled the Drop
when Inline intrusion policy option (in an inline deployment), or if a Drop and Generate rule
generated the event while the system was pruning
– blank, indicating that the triggered rule was not set to Drop and Generate Events
– Note that the system does not drop packets in a passive deployment, including when an inline
interface is in tap mode, regardless of the rule state or the inline drop behavior of the intrusion
policy.
Last Packet
The date and time the last packet of the session was seen.
MPLS Label
The Multiprotocol Label Switching label associated with the packet that triggered this intrusion
event.
Message
The explanatory text for the event.
For rule-based intrusion events, the event message is pulled from the rule. For decoder- and
preprocessor-based events, the event message is hard coded.
For malware events, any additional information associated with the malware event. For
network-based malware events, this field is populated only for files whose disposition has changed.
Monitor Rules
Up to eight Monitor rules matched by that connection.
Netbios Domain
The NetBIOS domain used in the session.
Policy
The access control, intrusion, or network analysis policy (NAP), if any, associated with the
generation of the event.
Policy Revision
The revision of the access control, file, intrusion, or network analysis policy (NAP), if any,
associated with the generation of the event.
Priority
The event priority as determined by the Cisco VRT.
Protocol
The protocol detected in the connection.
Reason
The reason or reasons the connection was logged, in the following situations:
– User Bypass indicates that the system initially blocked a user’s HTTP request, but the user
chose to continue to the originally requested site by clicking through a warning page. A reason
of User Bypass is always paired with an action of Allow.
– IP Block indicates that the system denied the connection without inspection, based on Security
Intelligence data. A reason of IP Block is always paired with an action of Block.
– IP Monitor indicates that the system would have denied the connection based on Security
Intelligence data, but you configured the system to monitor, rather than deny, the connection.
– File Monitor indicates that the system detected a particular type of file in the connection.
– File Block indicates the connection contained a file or malware file that the system prevented
from being transmitted. A reason of File Block is always paired with an action of Block.
– File Custom Detection indicates the connection contained a file on the custom detection list
that the system prevented from being transmitted.
– File Resume Allow indicates that file transmission was originally blocked by a Block Files or
Block Malware file rule. After a new access control policy was applied that allowed the file, the
HTTP session automatically resumed. Note that this reason only appears in inline deployments.
– File Resume Block indicates that file transmission was originally allowed by a Detect Files or
Malware Cloud Lookup file rule. After a new access control policy was applied that blocked the
file, the HTTP session automatically stopped. Note that this reason only appears in inline
deployments.
– Intrusion Block indicates the system blocked or would have blocked an exploit (intrusion
policy violation) detected in the connection. A reason of Intrusion Block is paired with an
action of Block for blocked exploits and Allow for would-have-blocked exploits.
– Intrusion Monitor indicates the system detected, but did not block, an exploit detected in the
connection. This occurs when the state of the triggered intrusion rule is set to Generate Events.
Receive Times
The time the destination host or responder responded to the event.
Referenced Host
If the protocol in the connection is DNS, HTTP, or HTTPS, this field displays the host name that the
respective protocol was using.
Responder Bytes
The total number of bytes transmitted by the session responder.
Responder Packets
The total number of packets transmitted by the session responder.
Responder IP
The host IP address (and host name, if DNS resolution is enabled) that responded to the session
initiator.
Signature
The signature ID of the intrusion rule matching the traffic for the event.
Source IP
The IP address used by the sending host in an intrusion event.
Source or Destination
The host originating or receiving the connection for the event.
TCP Flags
The TCP flags detected in the connection.
URL
The URL requested by the monitored host during the session.
URL Category
The category associated with the URL requested by the monitored host during the session, if
available.
URL Reputation
The reputation associated with the URL requested by the monitored host during the session, if
available.
User
The user of the host (Receiving IP) where the event occurred.
User Agent
User agent application information extracted from HTTP traffic detected in the connection.
VLAN
The innermost VLAN ID associated with the packet that triggered the event.
Web Application
The web application detected in the traffic.
While the ASA FirePOWER module provides various views of events within the module interface, you
may want to configure external event notification to facilitate constant monitoring of critical systems.
You can configure the module to generate alerts that notify you via email, SNMP trap, or syslog when
one of the following is generated:
• a network-based malware event or retrospective malware event
• a connection event, triggered by a specific access control rule
To have the ASA FirePOWER module send these alerts, you must first create an alert response, which
is a set of configurations that allows the module to interact with the external system where you plan to
send the alert. Those configurations may specify, for example, SNMP alerting parameters or syslog
facilities and priorities.
After you create the alert response, you associate it with the event that you want to use to trigger the
alert. Note that the process for associating alert responses with events is different depending on the type
of event:
• You associate alert responses with malware events using their own configuration pages.
• You associate SNMP and syslog alert responses with logged connections using access control rules
and policies.
There is another type of alerting you can perform in the ASA FirePOWER module, which is to configure
SNMP and syslog intrusion event notifications for individual intrusion events. You configure these
notifications in intrusion policies; see Configuring External Alerting for Intrusion Rules, page 36-1 and
Adding SNMP Alerts, page 24-31. The following table explains the licenses you must have to generate
alerts.
Table 35-1 License Requirements for Generating Alerts
Note If you want to monitor 64-bit values with SNMP, you must use SNMPv2 or SNMPv3. SNMPv1 does not
support 64-bit monitoring.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Actions Alerts.
The Alerts page appears.
Step 2 From the Create Alert drop-down menu, select Create SNMP Alert.
The Create SNMP Alert Configuration pop-up window appears.
Step 3 In the Name field, type the name that you want to use to identify the SNMP response.
Step 4 In the Trap Server field, type the hostname or IP address of the SNMP trap server, using alphanumeric
characters.
Note that the system does not warn you if you enter an invalid IPv4 address (such as 192.169.1.456) in
this field. Instead, the invalid address is treated as a hostname.
Step 5 From the Version drop-down list, select the SNMP version you want to use.
SNMP v3 is the default. If you select SNMP v1 or SNMP v2, different options appear.
Step 6 Which version of SNMP did you select?
• For SNMP v1 or SNMP v2, type the SNMP community name, using alphanumeric characters or the
special characters * or $, in the Community String field and skip to step 12.
• For SNMP v3, type the name of the user that you want to authenticate with the SNMP server in the
User Name field and continue with the next step.
Step 7 From the Authentication Protocol drop-down list, select the protocol you want to use for authentication.
Step 8 In the Authentication Password field, type the password required for authentication with the SNMP server.
Step 9 From the Privacy Protocol list, select None to use no privacy protocol or DES to use Data Encryption
Standard as the privacy protocol.
Step 10 In the Privacy Password field, type the privacy password required by the SNMP server.
Step 11 In the Engine ID field, type an identifier for the SNMP engine, in hexadecimal notation, using an even
number of digits.
When you use SNMPv3, the system uses an Engine ID value to encode the message. Your SNMP server
requires this value to decode the message.
Cisco recommends that you use the hexadecimal version of the ASA FirePOWER module’s IP address.
For example, if the ASA FirePOWER module has an IP address of 10.1.1.77, use 0a01014D0.
Step 12 Click Store ASA FirePOWER Changes.
The alert response is saved and is automatically enabled.
Tip For more detailed information about how syslog works and how to configure it, refer to the
documentation for your system. On UNIX systems, the man pages for syslog and syslog.conf provide
conceptual information and configuration instructions.
Although you can select any type of facility when creating a syslog alert response, you should select one
that makes sense based on your syslog server; not all syslog servers support all facilities. For UNIX
syslog servers, the syslog.conf file should indicate which facilities are saved to which log files on the
server.
The following table lists the syslog facilities you can select.
Table 35-2 Available Syslog Facilities
Facility Description
ALERT An alert message.
AUDIT A message generated by the audit subsystem.
AUTH A message associated with security and authorization.
AUTHPRIV A restricted access message associated with security and authorization. On
many systems, these messages are forwarded to a secure file.
CLOCK A message generated by the clock daemon.
Note that syslog servers running a Windows operating system will use the CLOCK
facility.
CRON A message generated by the clock daemon.
Note that syslog servers running a Linux operating system will use the CRON
facility.
DAEMON A message generated by a system daemon.
FTP A message generated by the FTP daemon.
KERN A message generated by the kernel. On many systems, these messages are
printed to the console when they appear.
LOCAL0-LOCAL7 A message generated by an internal process.
LPR A message generated by the printing subsystem.
MAIL A message generated by a mail system.
NEWS A message generated by the network news subsystem.
NTP A message generated by the NTP daemon.
SYSLOG A message generated by the syslog daemon.
USER A message generated by a user-level process.
UUCP A message generated by the UUCP subsystem.
The following table lists the standard syslog severity levels you can select.
Table 35-3 Syslog Severity Levels
Level Description
ALERT A condition that should be corrected immediately.
CRIT A critical condition.
DEBUG Messages that contain debugging information.
EMERG A panic condition broadcast to all users.
ERR An error condition.
INFO Informational messages.
NOTICE Conditions that are not error conditions, but require attention.
WARNING Warning messages.
Before you start sending syslog alerts, make sure that the syslog server can accept remote messages.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Actions Alerts.
The Alerts page appears.From the Create Alert drop-down menu, select Create Syslog Alert.
The Create Syslog Alert Configuration pop-up window appears.
Step 2 In the Name field, type the name you want to use to identify the saved response.
Step 3 In the Host field, type the hostname or IP address of your syslog server.
Note that the system does not warn you if you enter an invalid IPv4 address (such as 192.168.1.456) in
this field. Instead, the invalid address is treated as a hostname.
Step 4 In the Port field, type the port the server uses for syslog messages.
By default, this value is 514.
Step 5 From the Facility list, select a facility.
See the Available Syslog Facilities table for a list of the available facilities.
Step 6 From the Severity list, select a severity.
See the Syslog Severity Levels table for a list of the available severities.
Step 7 In the Tag field, type the tag name that you want to appear with the syslog message.
Use only alphanumeric characters in tag names. You cannot use spaces or underscores.
As an example, if you wanted all messages sent to the syslog to be preceded with FromDC, type FromDC
in the field.
Step 8 Click Store ASA FirePOWER Changes.
The alert response is saved and is automatically enabled.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Actions Alerts.
The Alerts page appears.
Step 2 Next to the alert response you want to edit, click the edit icon ( ).
A configuration pop-up window for that alert response appears.
Step 3 Make changes as needed.
Step 4 Click Store ASA FirePOWER Changes.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Actions Alerts.
The Alerts page appears.
Step 2 Next to the alert response you want to delete, click the delete icon ( ).
Step 3 Confirm that you want to delete the alert response.
The alert response is deleted.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Actions Alerts.
The Alerts page appears.
Step 2 Next to the alert response you want to enable or disable, click the enable/disable slider.
If the alert response was enabled, it is disabled. If it was disabled, it is enabled.
While the ASA FirePOWER module provides various views of intrusion events within the user interface,
some enterprises prefer to define external intrusion event notification to facilitate constant monitoring
of critical systems. You can enable logging to syslog facilities or send event data to an SNMP trap server.
Within each intrusion policy, you can specify intrusion event notification limits, set up intrusion event
notification to external logging facilities, and configure external responses to intrusion events.
Tip Some analysts prefer not to receive multiple alerts for the same intrusion event, but want to control how
often they are notified of a given intrusion event occurrence. See Filtering Intrusion Event Notification
Per Policy, page 24-20 for more information.
There is another type of alerting you can perform in the ASA FirePOWER module, outside of your
intrusion policies. You can configure SNMP and syslog alert responses for other types of events,
including connection events logged by specific access control rules. For more information, see
Configuring External Alerting, page 35-1.
See the following sections for more information on external intrusion event notification:
• Using SNMP Responses, page 36-1 describes the options you can configure to send event data to
specified SNMP trap servers and provides the procedure for specifying the SNMP alerting options.
• Using Syslog Responses, page 36-4 describes the options you can configure to send event data to an
external syslog and provides the procedure for specifying the syslog alerting options.
Tip If your network management system requires a management information base file (MIB), you can obtain
it from the ASA FirePOWER module at /etc/sf/DCEALERT.MIB.
SNMP v2 Options
For SNMP v2, you can specify the options described in the following table.
Table 36-1 SNMP v2 Options
Option Description
Trap Type The trap type to use for IP addresses that appear in the alerts.
If your network management system correctly renders the INET_IPV4 address
type, then you can select as Binary. Otherwise, select as String. For example, HP
Openview requires the string type.
Trap Server The server that will receive SNMP traps notification.
You can specify a single IP address or hostname.
Community String The community name.
SNMP v3 Options
For SNMP v3, you can specify the options described in the following table.
Note When using SNMP v3, the appliance uses an Engine ID value to encode the message. Your SNMP server
requires this value to decode the message. Currently, this Engine ID value will always be the
hexadecimal version of the appliance’s IP address with 01 at the end of the string. For example, if the
appliance sending the SNMP alert has an IP address of 172.16.1.50, the Engine ID is 0xAC10013201 or,
if the appliance has an IP address of 10.1.1.77, 0x0a01014D01 is used as the Engine ID.
Option Description
Trap Type The trap type to use for IP addresses that appear in the alerts.
If your network management system correctly renders the INET_IPV4
address type, then you can select as Binary. Otherwise, select as String. For
example, HP Openview requires the string type.
Trap Server The server that will receive SNMP traps notification.
You can specify a single IP address or hostname.
Authentication Password The password required for authentication. SNMP v3 uses either the
Message Digest 5 (MD5) hash function or the Secure Hash Algorithm
(SHA) hash function to encrypt this password, depending on
configuration.
If you specify an authentication password, authentication is enabled.
Option Description
Private Password The SNMP key for privacy. SNMP v3 uses the Data Encryption Standard
(DES) block cipher to encrypt this password.
If you specify a private password, privacy is enabled. If you specify a
private password, you must also specify an authentication password.
User Name Your SNMP user name.
For information about configuring SNMP Alerting, see Configuring SNMP Responses, page 36-3.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether SNMP Alerting under External Responses is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The SNMP Alerting page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration.
See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more information.
Step 5 Specify the trap type format that you want to use for IP addresses that appear in the alerts, as Binary or
as String.
Note If your network management system correctly renders the INET_IPV4 address type, then you can use
the as Binary option. Otherwise, use the as String option. For example, HP OpenView requires the as String
option.
• To configure SNMP v2, enter the IP address and the community name of the trap server you want
to use in the corresponding fields. See SNMP v2 Options, page 36-2.
• To configure SNMP v3, enter the IP address of the trap server you want to use, an authentication
password, a private password, and a user name in the corresponding fields. See SNMP v3 Options,
page 36-2 for more information.
Note When you enter an SNMP v3 password, the password displays in plain text during initial configuration
but is saved in encrypted format.
Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
The following table lists the facilities you can select when configuring syslog alerting. Be sure to
configure a facility that makes sense based on the configuration of the remote syslog server you use. The
syslog.conf file located on the remote system (if you are logging syslog messages to a UNIX- or
Linux-based system) indicates which facilities are saved to which log files on the server.
Table 36-3 Available Syslog Facilities
Facility Description
AUTH A message associated with security and authorization.
AUTHPRIV A restricted access message associated with security and authorization. On many
systems, these messages are forwarded to a secure file.
CRON A message generated by the clock daemon.
DAEMON A message generated by a system daemon.
FTP A message generated by the FTP daemon.
KERN A message generated by the kernel. On many systems, these messages are printed
to the console when they appear.
LOCAL0-LOCA A message generated by an internal process.
L7
LPR A message generated by the printing subsystem.
MAIL A message generated by a mail system.
NEWS A message generated by the network news subsystem.
SYSLOG A message generated by the syslog daemon.
USER A message generated by a user-level process.
UUCP A message generated by the UUCP subsystem.
Select one of the following standard syslog priority levels to display on all notifications generated by
this alert:
Table 36-4 Syslog Priority Levels
Level Description
EMERG A panic condition broadcast to all users
ALERT A condition that should be corrected immediately
CRIT A critical condition
ERR An error condition
WARNING Warning messages
NOTICE Conditions that are not error conditions, but require attention
INFO Informational messages
DEBUG Messages that contain debug information
For more detailed information about how syslog works and how to configure it, refer to the
documentation that accompanies your system. If you are logging to a UNIX- or Linux-based system’s
syslog, the syslog.conf man file (type man syslog.conf at the command line) and syslog man file (type
man syslog at the command line) provide information about how syslog works and how to configure it.
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy.
The Intrusion Policy page appears.
Step 2 Click the edit icon ( ) next to the policy you want to edit.
If you have unsaved changes in another policy, click OK to discard those changes and continue. See
Resolving Conflicts and Committing Policy Changes, page 15-15 for information on saving unsaved
changes in another policy.
The Policy Information page appears.
Step 3 Click Advanced Settings in the navigation panel on the left.
The Advanced Settings page appears.
Step 4 You have two choices, depending on whether Syslog Alerting under External Responses is enabled:
• If the configuration is enabled, click Edit.
• If the configuration is disabled, click Enabled, then click Edit.
The Syslog Alerting page appears.
A message at the bottom of the page identifies the intrusion policy layer that contains the configuration.
See Using Layers in a Network Analysis or Intrusion Policy, page 16-1 for more information.
Step 5 Optionally, in the Logging Hosts field, enter the remote access IP address you want to specify as logging
host. Separate multiple hosts with commas.
Step 6 Select facility and priority levels from the drop-down lists.
See Using Syslog Responses, page 36-4 for details on facility and priority options.
Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in
the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and
Committing Policy Changes, page 15-15 for more information.
The ASA FirePOWER module dashboard provides you with at-a-glance views of current system status.
The dashboard displays widgets in a three-column layout. Widgets are small, self-contained components
that provide insight into different aspects of the ASA FirePOWER module. Your system is delivered with
several predefined widgets. For example, the Appliance Information widget tells you the appliance
name, model, and currently running version of the ASA FirePOWER module software.
The dashboard has a time range that constrains its widgets. You can change the time range to reflect a
period as short as the last hour or as long as the last year.
Each appliance is delivered with a default dashboard, named Summary Dashboard. This dashboard
provides the casual user with general system status information for your ASA FirePOWER module
deployment.
For more information on the dashboard and its contents, see the following sections:
• Understanding Dashboard Widgets, page 37-1
• Understanding the Predefined Widgets, page 37-2
• Working with the Dashboard, page 37-5
Widget preferences can be simple. For example, you can set preferences for the Current Interface Status
widget, which displays the current status of all enabled interfaces on the internal network. You can only
configure the update frequency for this widget.
Step 1 On the title bar of the widget whose preferences you want to change, click the show preferences icon
( ).
The preferences section for that widget appears.
Step 2 Make changes as needed.
Your changes take effect immediately. For information on the preferences you can specify for individual
widgets, see Understanding the Predefined Widgets, page 37-2.
Step 3 On the widget title bar, click the hide preferences icon ( ) to hide the preferences section.
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. For more information,
see Understanding Widget Preferences, page 37-1.
• to import the newest rule update, see Importing Rule Updates and Local Rule Files, page 43-10.
• create a scheduled task to download the latest version of the ASA FirePOWER module software or
rule update by clicking the latest version; see Scheduling Tasks, page 39-1.
You can configure the widget to show or hide the load average by modifying the widget preferences. The
preferences also control how often the widget updates. For more information, see Understanding Widget
Preferences, page 37-1.
You can configure the widget to hide the boot time by modifying the widget preferences. The preferences
also control how often the widget synchronizes with the appliance’s clock. For more information, see
Understanding Widget Preferences, page 37-1.
You can view and modify the widgets that appear on the dashboard.
For more information on working with the dashboard, see:
• Viewing the Dashboard, page 37-6
• Modifying the Dashboard, page 37-6
• Exporting Configurations, page B-1
Step 1 From the Show the Last drop-down list, choose a dashboard time range.
All appropriate widgets on the page update to reflect the new time range.
Rearranging Widgets
License: Any
To move a widget:
Step 1 Click the title bar of the widget you want to move, then drag it to its new location.
To minimize a widget:
To maximize a widget:
You can view reports on various time periods to analyze the traffic on your network. Reports aggregate
information on various aspects of your network traffic. In most cases, you can drill down from general
information to specific information. For example, you can view a report on all users, then view details
about specific users.
Overview and detail reports include multiple report components such as top policies and web categories.
These reports show the most often occurring items of that type for the report you are viewing. For
example, if you are viewing the detail report for a specific user, the top policies show the policy hits most
associated with that user.
For more information, see:
• Understanding Available Reports, page 38-1
• Report Basics, page 38-2
Network Overview
This report shows summary information about the traffic in the network. Use this information to help
identify areas that need deeper analysis, or to verify that the network is behaving within general
expectations.
Users
This report shows the top users of your network. Use this information to help identify anomalous
activity for a user.
Tip User names are available only when user identity information is associated with traffic flows. If
you want to ensure that user identity is available in reports for the majority of traffic, the access
control policy should use active authentication.
Applications
This report displays applications, which represent the content or requested URL for HTTP traffic
detected in the traffic that triggered an intrusion event. Note that if the module detects an application
protocol of HTTP, but cannot detect a specific web application, the module supplies a generic web
browsing designation here.
Web categories
This report shows which categories of web sites, such as gambling, advertisements, or search
engines and portals are being used in the network based on the categorization of web sites visited.
Use this information to help identify the top categories visited by users and to determine whether
your access control policies are sufficiently blocking undesired categories.
Policies
This report shows how your access control policies have been applied to traffic in the network. Use
this information to help evaluate policy efficacy.
Ingress zones
This report displays the ingress security zone of the packet that triggered an event.
Egress zones
This report displays the egress security zone of the packet that triggered the event.
Destinations
This report shows which applications, such as Facebook, are being used in the network based on the
analysis of the traffic in the network. Use this information to help identify the top applications used
in the network and to determine whether additional access control policies are needed to reduce the
usage of unwanted applications.
Attackers
This report displays the source IP addresses, used by the sending hosts, that triggered an event.
Targets
This report displays the destination IP addresses, used by the receiving hosts, that triggered an event.
Threats
This report displays the unique identifying number and explanatory text assigned to each detected
threat to your network.
Files logs
This report displays the type of files detected, for example, HTML or MSEXE.
Report Basics
License: Any
The following sections explain the basics of using reports. These topics apply to reports in general and
not to any single specific report.
For more information, see:
Note If a data point is missing, for example, because the device was unreachable for longer than 5
minutes, there will be gaps in line charts.
View More
Click the View More link to go to the report for the item you are viewing. For example, clicking View
More in the Web Categories chart of the Destinations report takes you to the Web Categories report. If
you are viewing the report in a detailed report, you go to the detailed Web Categories report for the item
you are viewing details about.
Column Description
Transactions The total number of transactions for the reported item.
Transactions allowed The number of transactions that were allowed for the reported item.
Transactions denied The number of transactions that were blocked (based on policy) for
the reported item.
Total bytes The sum of bytes sent and received for the reported item.
Bytes received The number of bytes received for the reported item.
Total Bytes Sent The number of bytes sent for the reported item.
You can schedule many different types of administrative tasks to run at designated times, either once or
on a recurring basis.
Note Some tasks (such as those involving automated software updates) may place a significant load on
networks with low bandwidths. You should schedule tasks like these to run during periods of low
network use.
Note that the time displayed on most pages on the user interface is the local time, which is determined
by using the time zone you specify in your local configuration. Further, the ASA FirePOWER module
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.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click Add Task.
The New Task page appears.
Step 3 From the Job Type list, select the type of task that you want to schedule.
Each of the types of tasks you can schedule is explained in its own section.
Step 4 For the Schedule task to run option, select Recurring.
The page reloads with the recurring task options.
Step 5 In the Start On field, specify the date when you want to start your recurring task. You can use the
drop-down list to select the month, day, and year.
Step 6 In the Repeat Every field, specify how often you want the task to recur. You can specify a number of hours,
days, weeks, or months.
Tip You can either type a number or click the up icon ( ) and the down ( ) icon to specify the interval. For
example, type 2 and select Days to run the task every two days.
Step 7 In the Run At field, specify the time when you want to start your recurring task.
Step 8 If you selected Weeks for Repeat Every, a Repeat On field appears. Select the check boxes next to the days
of the week when you want to run the task.
Step 9 If you selected Months for Repeat Every, a Repeat On field appears. Use the drop-down list to select the day
of the month when you want to run the task.
The remaining options on the New Task page are determined by the task you are creating. See the
following sections for more information:
– Automating Backup Jobs, page 39-3
– Automating Certificate Revocation List Downloads, page 39-4
– Automating Applying an Intrusion Policy, page 39-4
– Automating Software Updates, page 39-6
– Automating URL Filtering Updates, page 39-8
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click Add Task.
The New Task page appears.
Step 3 From the Job Type list, select Backup.
The page reloads to show the backup options.
Step 4 Specify how you want to schedule the backup, Once or Recurring:
• For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field
indicates the current time on the appliance.
• For recurring tasks, you have several options for setting the interval between instances of the task.
See Configuring a Recurring Task, page 39-1 for details.
Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.
Step 6 From the Backup Profile list, select the appropriate backup profile.
For more information on creating new backup profiles, see Creating Backup Profiles, page 45-3.
Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or
periods.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively
short.
Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured to send status messages. See Configuring a Mail
Relay Host and Notification Address, page 40-6 for more information about configuring a relay host.
Step 9 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
Tip You must enable and configure user certificates and set a CRL download URL before scheduling this
task. For information on configuring user certificates, see Requiring User Certificates, page 41-5.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Locate the download CRL task in the Task Details and click the edit icon ( ).
The Edit Task page appears, showing the download options.
Step 3 Specify how you want to schedule the CRL download, Once or Recurring:
• For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field
indicates the current time on the appliance.
• For recurring tasks, you have several options for setting the interval between instances of the task.
See Configuring a Recurring Task, page 39-1 for details.
Step 4 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or
periods.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively
short.
Step 5 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured on the ASA FirePOWER module to send status
messages. See Configuring a Mail Relay Host and Notification Address, page 40-6 for more information
about configuring a relay host.
Step 6 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
You can queue an intrusion policy apply to the ASA FirePOWER module. This task only applies the
intrusion policy if an access control policy that references the intrusion policy is applied to the ASA
FirePOWER module when the task runs. Otherwise, the task aborts before completion.
You must associate an intrusion policy with an access control policy and apply the access control policy
to a device before scheduling this task; see Controlling Traffic Using Intrusion and File Policies,
page 10-1.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The schedule calendar page for the current month appears.
Step 2 Click Add Task.
The New Task page appears.
Step 3 From the Job Type list, select Queue Intrusion Policy Apply.
The page reloads to show the options for queuing a policy apply.
Step 4 Specify how you want to schedule the task, Once or Recurring:
• For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field
indicates the current time on the ASA FirePOWER module.
• For recurring tasks, you have several options for setting the interval between instances of the task.
See Configuring a Recurring Task, page 39-1 for details.
Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.
Step 6 In the Intrusion Policy field, you have the following options:
• Select an intrusion policy to apply to the ASA FirePOWER module.
• Select All intrusion policies to apply all intrusion policies already applied to the ASA FirePOWER
module.
Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or
periods.
Tip The comment field appears in the Tasks Details section at the bottom of the schedule calendar page, so
you should limit the size of your comment.
Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured to send status messages. See Configuring a Mail
Relay Host and Notification Address, page 40-6 for more information about configuring a relay host.
Step 9 Click Save.
The task is added. You can check the status of a running task in the Task Details section of the calendar
page; see Viewing the Status of Long-Running Tasks, page C-1.
Step 10 To edit your saved task, click the task anywhere it appears on the schedule calendar page.
The Task Details section appears at the bottom of the page. To make any changes, click the edit icon
( ).
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Updates.
The Product Updates page appears.
Step 2 Click the Geolocation Updates tab.
The Geolocation Updates page appears.
Step 3 Under Recurring Geolocation Updates, select the Enable Recurring Weekly Updates check box.
The Update Start Time field appears.
Step 4 In the Update Start Time field, specify the time and day of the week when you want weekly GeoDB updates
to occur.
Step 5 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
Note You must manually upload and install updates in two situations. First, you cannot schedule major
updates to the ASA FirePOWER module. Second, you cannot schedule updates for or pushes from
appliances that cannot access the Support Site. For information on manually updating the ASA
FirePOWER module, see Updating ASA FirePOWER Module Software, page 43-1.
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.
See the following sections for more information:
• Automating Software Downloads, page 39-6
• Automating Software Installs, page 39-7
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click Add Task.
The New Task page appears.
Step 3 From the Job Type list, select Download Latest Update.
The New Task page reloads to show the update options.
Step 4 Specify how you want to schedule the task, Once or Recurring:
• For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field
indicates the current time on the appliance.
• For recurring tasks, you have several options for setting the interval between instances of the task.
See Configuring a Recurring Task, page 39-1 for details.
Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.
Step 6 In the Update Items section, select Software.
Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or
periods.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively
short.
Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured to send status messages. See Configuring a Mail
Relay Host and Notification Address, page 40-6 for more information about configuring a relay host.
Step 9 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
Caution Depending on the update being installed, the appliance may reboot after the software is installed.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click Add Task.
The New Task page appears.
Step 3 From the Job Type list, select Install Latest Update.
The page reloads to show the options for installing updates.
Step 4 Specify how you want to schedule the task, Once or Recurring:
• For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field
indicates the current time on the appliance.
• For recurring tasks, you have several options for setting the interval between instances of the task.
See Configuring a Recurring Task, page 39-1 for details.
Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.
Step 6 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or
periods.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively
short.
Step 7 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured to send status messages. See Configuring a Mail
Relay Host and Notification Address, page 40-6 for more information about configuring a relay host.
Step 8 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click Add Task.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively
short.
Step 7 Optionally, in the Email Status To field, type the email address (or multiple email addresses separated by
commas) where you want task status messages sent.
You must have a valid email relay server configured to send status messages. See Configuring a Mail
Relay Host and Notification Address, page 40-6 for more information about configuring a relay host.
Step 8 Click Save.
The task is added. You can check the status of a running task on the Task Status page; see Viewing the
Status of Long-Running Tasks, page C-1.
Viewing Tasks
After adding scheduled tasks, you can view them and evaluate their status. The View Options section of
the page allows you to view scheduled tasks using a calendar and a list of scheduled tasks.
See the following sections for more information:
• Using the Calendar, page 39-9
• Using the Task List, page 39-10
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 You can perform the following tasks using the calendar view:
• Click the double left arrow icon ( ) to move back one year.
• Click the single left arrow icon ( ) to move back one month.
• Click the single right arrow icon ( ) to move forward one month.
• Click the double right arrow icon ( ) to move forward one year.
• Click Today to return to the current month and year.
• Click Add Task to schedule a new task.
• Click a date to view all scheduled tasks for the specific date in a task list table below the calendar.
• Click a specific task on a date to view the task in a task list table below the calendar.
Note For more information about using the task list, see Using the Task List.
Column Description
Name Displays the name of the scheduled task and the comment associated with it.
Type Displays the type of scheduled task.
Start Time Displays the scheduled start date and time.
Frequency Displays how often the task is 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.
Creator Displays the name of the user that created the scheduled task.
Edit Edits the scheduled task.
Delete Deletes the scheduled task.
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 On the calendar, select an instance of the recurring task you want to delete.
The page reloads to display a table of tasks below the calendar.
Step 3 Locate an instance of the recurring task you want to delete in the table and click the delete icon ( ).
All instances of the recurring task are deleted.
To delete a single task or, if it has already run, delete a task record:
Step 1 Select In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Scheduling.
The Scheduling page appears.
Step 2 Click the task that you want to delete or the day on which the task appears.
A table containing the selected task or tasks appears.
Step 3 Locate the task you want to delete in the table and click the delete icon ( ).
The instance of the task you selected is deleted.
A system policy allows you to manage the following on your ASA FirePOWER module:
• audit log settings
• the mail relay host and notification address
• SNMP polling settings
• STIG compliance
See the following sections for more information:
• Creating a System Policy, page 40-1
• Editing a System Policy, page 40-2
• Applying a System Policy, page 40-2
• Deleting System Policies, page 40-3
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 Click Create Policy.
The Create Policy page appears.
Step 3 From the drop-down list, select an existing policy to use as a template for your new system policy.
Step 4 Type a name for your new policy in the New Policy Name field.
Step 5 Type a description for your new policy in the New Policy Description field.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears, including a list of the existing system policies.
Step 2 Click the edit icon ( ) next to the system policy that you want to edit.
The Edit Policy page appears. You can change the policy name and policy description. For information
about configuring each aspect of the system policy, see one of the following sections:
• Configuring Audit Log Settings, page 40-5
• Configuring a Mail Relay Host and Notification Address, page 40-6
• Configuring SNMP Polling, page 40-8
• Enabling STIG Compliance, page 40-9
Note If you are editing a system policy applied to an ASA FirePOWER module, make sure you
reapply the updated policy when you are finished. See Applying a System Policy, page 40-2.
Step 3 Click Save Policy and Exit to save your changes. The changes are saved, and the System Policy page
appears.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 Click the apply icon ( ) next to the system policy that you want to apply.
Step 3 Click Apply.
The System Policy page appears. A message indicates the status of applying the system policy.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 Click the delete icon ( ) next to the system policy that you want to delete. To delete the policy, click OK.
The System Policy page appears. A pop-up message appears, confirming the policy deletion.
The Access List page allows you to control which computers can access your appliance on specific ports.
By default, port 443 (Hypertext Transfer Protocol Secure, or HTTPS), which is used to access the web
interface, and port 22 (Secure Shell, or SSH), which is used to access the command line, are enabled for
any IP address. You can also add SNMP access over port 161. Note that you must add SNMP access for
any computer you plan to use to poll for SNMP information.
Caution By default, access to the appliance is not restricted. To operate the appliance in a more secure
environment, consider adding access to the appliance for specific IP addresses and then deleting the
default any option.
The access list is part of the system policy. You can specify the access list either by creating a new system
policy or by editing an existing system policy. In either case, the access list does not take effect until you
apply the system policy.
Note that this access list does not also control external database access. For more information on the
external database access list, see Enabling Cloud Communications, page 41-6.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 You have the following options:
• To modify the access list in an existing system policy, click the edit icon ( ) next to the system
policy.
• To configure the access list as part of a new system policy, click Create Policy.
Provide a name and description for the system policy as described in Creating a System Policy,
page 40-1, and click Save.
In either case, the Access List page appears.
Step 3 Optionally, to delete one of the current settings, click the delete icon ( ).
The setting is removed.
Caution If you delete access for the IP address that you are currently using to connect to the appliance interface,
and there is no entry for “IP=any port=443”, you will lose access to the system when you apply the
policy.
Step 4 Optionally, to add access for one or more IP addresses, click Add Rules.
The Add IP Address page appears.
Step 5 In the IP Address field, you have the following options, depending on the IP addresses you want to add:
• an exact IP address (for example, 192.168.1.101)
• an IP address block using CIDR notation (for example, 192.168.1.1/24)
For information on using CIDR in the FireSIGHT System, see IP Address Conventions, page 1-4.
• any, to designate any IP address
Step 6 Select SSH, HTTPS, SNMP, or a combination of these options to specify which ports you want to enable
for these IP addresses.
Step 7 Click Add.
The Access List page appears again, reflecting the changes you made.
Step 8 Click Save Policy and Exit.
The system policy is updated. Your changes do not take effect until you apply the system policy. See
Applying a System Policy, page 40-2 for more information.
Note You must ensure that the external host is functional and accessible from the ASA FirePOWER module
sending the audit log.
The sending host name is part of the information sent. You can further identify the audit log stream with
a facility, a severity, and an optional tag. The ASA FirePOWER module does not send the audit log until
you apply the system policy.
After you apply a policy with this feature enabled, and your destination host is configured to accept the
audit log, the syslog messages are sent. The following is an example of the output structure:
Date Time Host [Tag] Sender: [User_Name]@[User_IP], [Subsystem], [Action]
where the local date, time, and hostname precede the bracketed optional tag, and the sending device
name precedes the audit log message.
For example:
Mar 01 14:45:24 localhost [TAG] Dev-DC3000: admin@10.1.1.2, Operations > Monitoring, Page
View
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 You have the following options:
• To modify the audit log settings in an existing system policy, click the edit icon ( ) next to the
system policy.
• To configure the audit log settings as part of a new system policy, click Create Policy.
Provide a name and description for the system policy as described in Creating a System Policy,
page 40-1, and click Save.
Step 3 Click Audit Log Settings.
The Audit Log Settings page appears.
Step 4 Select Enabled from the Send Audit Log to Syslog drop-down menu. (The default setting is Disabled.)
Step 5 Designate the destination host for the audit information by using the IP address or the fully qualified
name of the host in the Host field. The default port (514) is used.
Caution If the computer you configure to receive an audit log is not set up to accept remote messages, the host
will not accept the audit log.
Caution To allow encrypted posts, you must use an HTTPS URL. Note that sending audit information to an
external URL may affect system performance.
You can select an encryption method for the communication between appliance and mail relay host, and
can supply authentication credentials for the mail server if needed. After configuring settings, you can
test the connection between the appliance and the mail server using the supplied settings.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 You have the following options:
• To modify the email settings in an existing system policy, click the edit icon ( ) next to the system
policy.
• To configure the email settings as part of a new system policy, click Create Policy.
Provide a name and description for the system policy as described in Creating a System Policy,
page 40-1, and click Save.
Step 3 Click Email Notification.
The Configure Email Notification page appears.
Step 4 In the Mail Relay Host field, type the hostname or IP address of the mail server you want to use.
Note The mail host you enter must allow access from the appliance.
Step 5 Enter the port number to use on the email server in the Port Number field. Typical ports include 25, when
using no encryption, 465, when using SSLv3, and 587, when using TLS.
Step 6 To select an encryption method, you have the following options:
• To encrypt communications between the appliance and the mail server using Transport Layer
Security, select TLS from the Encryption Method drop-down list.
• To encrypt communications between the appliance and the mail server using Secure Socket Layers,
select SSLv3 from the Encryption Method drop-down list.
• To allow unencrypted communication between the appliance and the mail server, select None from
the Encryption Method drop-down list.
Note that certificate validation is not required for encrypted communication between the appliance and
mail server.
Step 7 Enter a valid email address in the From Address field for use as the source email address for messages sent
by the appliance.
Step 8 Optionally, to supply a user name and password when connecting to the mail server, select Use
Authentication. Enter a user name in the Username field. Enter a password in the Password field.
Step 9 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 10 Click Save Policy and Exit.
The system policy is updated. Your changes do not take effect until you apply the system policy. See
Applying a System Policy, page 40-2 for more information.
Note You must add SNMP access for any computer you plan to use to poll the appliance. For more
information, see Configuring the Access List for Your Appliance, page 40-3. Note that the SNMP MIB
contains information that could be used to attack your appliance. 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.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 You have the following options:
• To modify the SNMP polling settings in an existing system policy, click the edit icon ( ) next to
the system policy.
• To configure the SNMP polling settings as part of a new system policy, click Create Policy.
Provide a name and description for the system policy as described in Creating a System Policy,
page 40-1, and click Create.
Step 3 If you have not already added SNMP access for each computer you plan to use to poll the appliance, do
so now. For more information, see Configuring the Access List for Your Appliance, page 40-3.
Step 4 Click SNMP.
The SNMP page appears.
Step 5 From the SNMP Version drop-down list, select the SNMP version you want to use.
The drop-down list displays the version you selected.
Step 6 You have the following options:
• If you selected Version 1 or Version 2, type the SNMP community name in the Community String field.
Go to step 15.
• If you selected Version 3, click Add User to display the user definition page.
Step 7 Enter a username in the Username field.
Step 8 Select the protocol you want to use for authentication from the Authentication Protocol drop-down list.
Step 9 Type the password required for authentication with the SNMP server in the Authentication Password field.
Step 10 Retype the authentication password in the Verify Password field just below the Authentication Password
field.
Step 11 Select the privacy protocol you want to use from the Privacy Protocol list, or select None to not use a
privacy protocol.
Step 12 Type the SNMP privacy key required by the SNMP server in the Privacy Password field.
Step 13 Retype the privacy password in the Verify Password field just below the Privacy Password field.
Step 14 Click Add.
The user is added. You can repeat steps 6 through 13 to add additional users. Click the delete icon ( )
to delete a user.
Step 15 Click Save Policy and Exit.
The system policy is updated. Your changes do not take effect until you apply the system policy. See
Applying a System Policy, page 40-2 for more information.
Caution You cannot disable this setting without assistance from Support. In addition, this setting may
substantially impact the performance of your system. Cisco does not recommend enabling STIG
compliance except to comply with Department of Defense security requirements.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > System Policy.
The System Policy page appears.
Step 2 You have the following options:
• To modify the time settings in an existing system policy, click the edit icon ( ) next to the system
policy.
• To configure the time settings as part of a new system policy, click Create Policy.
Provide a name and description for the system policy as described in Creating a System Policy,
page 40-1, and click Save.
Step 3 Click STIG Compliance.
The STIG Compliance page appears.
Step 4 If you want to permanently enable STIG compliance on the appliance, select Enable STIG Compliance.
Caution You cannot disable STIG compliance on an appliance after you apply a policy with STIG compliance
enabled. If you need to disable compliance, contact Support.
Field Description
Name A name you assign to the appliance. Note that this name is only used within
the context of the ASA FirePOWER module. Although you can use the
hostname as the name of the appliance, entering a different name in this field
does not change the hostname.
Product Model The model name for the appliance.
Serial Number The chassis serial number of the appliance.
Software Version The version of the software currently installed.
Operating System The operating system currently running on the appliance.
Field Description
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 of the
appliance. If IPv4 management is disabled for the appliance, this field
indicates that.
IPv6 Address The IPv6 address of the default (eth0) management interface of the
appliance. If IPv6 management is disabled for the appliance, this field
indicates that.
Current Policies The appliance-level policies currently applied. If a policy has been updated
since it was last applied, the name of the policy appears in italics.
Model Number The model number for the appliance. This number may be important for
troubleshooting.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 To change the appliance name, type a new name in the Name field.
The name must be alphanumeric characters and cannot be composed of numeric characters only.
Step 3 To save your changes, click Save.
The page refreshes and your changes are saved.
Field Description
Subject For the appliance where the certificate is installed, provides the
commonName, countryName, organizationName, and
organizationalUnitName.
Issuer For the appliance that issued the certificate, provides the commonName,
countryName, organizationName, and organizationalUnitName.
Validity Indicates the timeframe during which the certificate is valid.
Version Indicates the certificate version.
Serial Number Indicates the certificate serial number.
Signature Algorithm Indicates the algorithm used to sign the certificate.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click HTTPS Certificate.
The HTTPS Certificate page appears, with the details of the current certificate for the ASA FirePOWER
module.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click HTTPS Certificate.
The HTTPS Certificate page appears.
Step 3 Click Generate New CSR.
The Generate Certificate Signing Request pop-up window appears.
Step 4 Type the two-letter country code for your country in the Country Name (two-letter code) field.
Step 5 Type the postal abbreviation for your state or province in the State or Province field.
Step 6 Type the name of your Locality or City.
Step 7 Type your Organization name.
Step 8 Type an Organizational Unit (Department) name.
Step 9 Type the fully qualified domain name of the server for which you want to request a certificate in the
Common Name field, exactly as you want it to appear in the certificate.
Step 10 Click Generate.
The Certificate Signing Request pop-up window appears.
Step 11 Open a text editor.
Step 12 Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and
END CERTIFICATE REQUEST lines, and paste it into a blank text file.
Step 13 Save the file as servername.csr, where servername is the name of the server where you plan to use the
certificate.
Step 14 Upload the CSR file to the certificate authority where you want to request a certificate or use the CSR
to create a self-signed certificate.
To upload a certificate:
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click HTTPS Certificate.
The HTTPS Certificate page appears.
Step 3 Click Import HTTPS Certificate.
Step 5 Optionally, open the private key file, copy the entire block of text, including the BEGIN RSA PRIVATE KEY
and END RSA PRIVATE KEY lines, and paste it into the Private Key field.
Step 6 Open any intermediate certificates you need to provide, copy the entire block of text, for each, and paste
it into the Certificate Chain field.
Step 7 Click Save to upload the certificate.
The certificate uploads and the HTTPS Certificate page updates to reflect the new certificate.
Caution You must have a valid user certificate present in your browser (or a CAC inserted in your reader) to
enable user certificates and to access the module interface after doing so.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click HTTPS Certificate.
The HTTPS Certificate page appears.
Step 3 Select Enable User Certificates. If prompted, select the appropriate certificate from the drop-down list.
The Enable Fetching of CRL option appears.
Step 4 Optionally, select Enable Fetching of CRL.
Note Enabling fetching of the CRL creates a scheduled task to update the CRL on a regular basis. Edit the task
to set the frequency of the update. For more information, see Automating Certificate Revocation List
Downloads, page 39-4.
Step 6 Verify that you have a valid user certificate generated by the same certificate authority that created the
server certificate.
Caution When you save a configuration with enabled user certificates, if you do not have a valid user certificate
in your browser certificate store, you disable all web server access to the appliance. Make sure you have
a valid certificate installed before saving settings.
Note Cisco recommends that you either enable automatic updates or use the scheduler to schedule
updates. Although you can manually perform on-demand updates, allowing the system to
automatically contact the cloud on a regular basis provides you with the most up-to-date,
relevant URL data.
Licensing
Performing category and reputation-based URL filtering and device-based malware detection
require that you enable the appropriate licenses on your ASA FirePOWER module; see Licensing
the ASA FirePOWER Module, page 42-1.
You cannot configure cloud connection options if you have no URL Filtering license on the ASA
FirePOWER module. The Cloud Services local configuration page displays only the options for
which you are licensed. ASA FirePOWER modules with expired licenses cannot contact the cloud.
Note that, in addition to causing the URL Filtering configuration options to appear, adding a URL
Filtering license to your ASA FirePOWER module automatically enables Enable URL Filtering and
Enable Automatic Updates. You can manually disable the options if needed.
Internet Access
The system uses ports 80/HTTP and 443/HTTPS to contact the Cisco cloud.
The following procedures explain how to enable communications the Cisco cloud, and how to perform
an on-demand update of URL data. Note that you cannot start an on-demand update if an update is
already in progress.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click Cloud Services.
The Cloud Services page appears. If you have a URL Filtering license, the page displays the last time
URL data was updated.
Step 3 Configure cloud connection options as described above.
You must Enable URL Filtering before you can Enable Automatic Updates or Query Cloud for Unknown URLs.
Step 4 Click Save.
Your settings are saved. If you enabled URL filtering, depending on how long it has been since URL
filtering was last enabled, or if this is the first time you enabled URL filtering, the ASA FirePOWER
moduleretrieves URL filtering data from the cloud.
Step 1 Select Configuration > ASA FirePOWER Configuration > Local > Configuration.
The Information page appears.
Step 2 Click URL Filtering.
The URL Filtering page appears.
Step 3 Click Update Now.
The ASA FirePOWER module contacts the cloud and updates its URL filtering data if an update is
available.
Time
You can view the current time and time source on the ASA FirePOWER module using the Time page.
You can license a variety of features to create an optimal ASA FirePOWER deployment for your
organization.
For more information, see:
• Understanding Licensing, page 42-1
• Viewing Your Licenses, page 42-4
• Adding a License to the ASA FirePOWER module, page 42-4
• Deleting a License, page 42-5
Understanding Licensing
License: Any
You can license a variety of features to create an optimal ASA FirePOWER deployment for your
organization.
Licenses allow your device to perform a variety of functions including:
• intrusion detection and prevention
• Security Intelligence filtering
• file control and advanced malware protection
• application, user, and URL control
There are a few ways you may lose access to licensed features in the ASA FirePOWER module. You can
remove licensed capabilities. In addition, some licenses may expire. Though there are some exceptions,
you cannot use the features associated with an expired or deleted license.
This section describes the types of licenses available in an ASA FirePOWER module deployment. The
licenses you can enable on an appliance can depend the other licenses enabled.
The following table summarizes ASA FirePOWER module licenses.
Protection
License: Protection
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. With a Malware
license (see Malware, page 42-3), you can also inspect and block a restricted set of those file types
based on their malware dispositions.
• Security Intelligence filtering allows you to blacklist—deny traffic to and from—specific IP
addresses, 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.
Although you can configure an access control policy to perform Protection-related inspection without a
license, you cannot apply the policy until you first add a Protection license to the ASA FirePOWER
module.
If you delete your Protection license from the ASA FirePOWER module, the ASA FirePOWER module
stops detecting intrusion and file events. Additionally, the ASA FirePOWER module will not contact the
internet for either Cisco-provided or third-party Security Intelligence information. You cannot reapply
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
License: Control
A Control license allows you to implement user and application control by adding user and application
conditions to access control rules. To enable Control, you must also enable Protection.
Although you can add user and application conditions to access control rules without a Control license,
you cannot apply the policy until you first add a Control license to the ASA FirePOWER module.
If you delete your Control license, you cannot reapply existing access control policies if they include
rules with user or application conditions.
URL Filtering
License: URL Filtering
URL filtering allows you to write access control rules that determine the traffic that can traverse your
network based on URLs requested by monitored hosts, correlated with information about those URLs,
which is obtained from the Cisco cloud by the ASA FirePOWER module. To enable URL Filtering, you
must also enable a Protection license.
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.
URL filtering requires a subscription-based URL Filtering license. Although you can add category and
reputation-based URL conditions to access control rules without a URL Filtering license, the ASA
FirePOWER module will not contact the cloud for URL information. You cannot apply the access
control policy until you first add a URL Filtering license to the ASA FirePOWER module.
You may lose access to URL filtering if you delete the license from the ASA FirePOWER module. Also,
URL Filtering licenses may expire. If your license expires or if you delete it, access control rules with
URL conditions immediately stop filtering URLs, and your ASA FirePOWER module can no longer
contact the cloud. You cannot reapply existing access control policies if they include rules with category
and reputation-based URL conditions.
Malware
License: Malware
A Malware license allows you to perform advanced malware protection, that is, use devices to detect and
block malware in files transmitted over your network. To enable Malware on a device, you must also
enable Protection.
You configure malware detection 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. The Malware license allows you to inspect a restricted set of those
file types for malware. 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.
Although you can add a malware-detecting file policy to an access control rule without a Malware
license, the file policy is marked with a warning icon ( ) in the access control rule editor. Within the
file policy, Malware Cloud Lookup rules are also marked with the warning icon. Before you can apply
an access control policy that includes a malware-detecting file policy, you must add a Malware license.
If you later delete the license, you cannot reapply an existing access control policy to those devices if it
includes file policies that perform malware detection.
If you delete your Malware license or it expires, the ASA FirePOWER module stops performing malware
cloud lookups, and also stops acknowledging retrospective events sent from the Cisco cloud. You cannot
reapply existing access control policies if they include file policies that perform malware detection. Note
that for a very brief time after a Malware license expires or is deleted, the system can use cached
dispositions for files detected by Malware Cloud Lookup file rules. After the time window expires, the
system assigns a disposition of Unavailable to those files, rather than performing a lookup.
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.
To add a license:
Tip You can also request a license on the Licenses tab after you log into the Support Site.
Step 5 Copy the license from the email, paste it into the License field in the ASA FirePOWER module’s web
user interface, and click Submit License.
If the license is valid, it is added.
Deleting a License
License: Any
Use the following procedure if you need to delete a license for any reason. Keep in mind that because
Cisco generates licenses based on each ASA FirePOWER module’s unique license key, you cannot
delete a license from one ASA FirePOWER module and then reuse it on a different ASA FirePOWER
module.
In most cases, deleting a license removes your ability to use features enabled by that license. For more
information, see Understanding Licensing, page 42-1.
To delete a license:
Cisco electronically distributes several different types of updates, including major and minor updates to
the ASA FirePOWER module software itself, as well as rule updates, geolocation database (GeoDB)
updates, and Vulnerability Database (VDB) updates.
Caution This section contains general information on updating the ASA FirePOWER module. Before you update,
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 prerequisites,
warnings, and specific installation and uninstallation instructions.
Unless otherwise documented in the release notes or advisory text, updating does not modify
configurations; the settings remain intact.
See the following sections for more information:
• Understanding Update Types, page 43-1
• Performing Software Updates, page 43-2
• Uninstalling Software Updates, page 43-7
• Updating the Vulnerability Database, page 43-8
• Importing Rule Updates and Local Rule Files, page 43-9
• Updating the Geolocation Database, page 43-19
Note that while you can uninstall patches and other minor updates, you cannot uninstall major updates
or return to previous versions of the VDB, GeoDB, or intrusion rules. If you updated to a new major
version and you need to revert to an older version, contact Support.
Before you begin the update, you must thoroughly read and understand the release notes, which you can
download from the Support Site. The release notes describe new features and functionality, and known
and resolved issues. The release notes also contain important information on prerequisites, warnings,
and specific installation and uninstallation instructions.
The following sections provide an overview of some of the factors you must consider when planning for
the update.
Tip For patches and feature updates, you can take advantage of the automated update feature; see
Automating Software Updates, page 39-6.
The manner and duration of network traffic interruption depends on how yourASA FirePOWER module
is configured and deployed, and whether the update reboots the ASA FirePOWER module. For specific
information on how and when network traffic is affected for a particular update, see the release notes.
Caution If you encounter issues with the update (for example, if the update has failed or if a manual refresh of
the Update Status page shows no progress), do not restart the update. Instead, contact Support.
Step 1 Read the release notes and complete any required pre-update tasks.
Pre-update tasks may include making sure that: the ASA FirePOWER module is running the correct
version of the Cisco software, you have enough free disk space to perform the update, you set aside
adequate time to perform the update, you backed up configuration data, and so on.
Step 2 Upload the update. You have two options, depending on the type of update and whether your ASA
FirePOWER module has access to the Internet:
• For all except major updates, and if your ASA FirePOWER module has access to the Internet, select
Configuration > ASA FirePOWER Configuration > Updates, then click Download Updates to check for the
latest updates on either of the following Support Sites:
– Sourcefire: (https://support.sourcefire.com/)
– Cisco: (http://www.cisco.com/cisco/web/support/index.html)
• For major updates, or if your ASA FirePOWER module does not have access to the Internet, you
must first manually download the update from either of the following Support Sites:
– Sourcefire: (https://support.sourcefire.com/)
– Cisco: (http://www.cisco.com/cisco/web/support/index.html)
• Select Configuration > ASA FirePOWER Configuration > Updates, then click Upload Update. Click Choose File
to navigate to and select the update and click Upload.
Note Download the update directly from the Support Site, either manually or by clicking Download
Updates on the Product Updates tab. If you transfer an update file by email, it may become
corrupted.
Caution Regardless of the update type, do not use the ASA FirePOWER module to perform tasks other than
monitoring the update until the update has completed and, if necessary, the ASA FirePOWER module
reboots. For more information, see Using the ASA FirePOWER Module During the Update, page 43-4.
Step 6 After the update finishes, access the ASA FirePOWER module interface and refresh the page. Otherwise,
the interface may exhibit unexpected behavior. If you are the first user to access the interface after a
major update, the End User License Agreement (EULA) may appear. You must review and accept the
EULA to continue.
Step 7 If the rule update available on the Support Site is newer than the rules on your ASA FirePOWER module,
import the newer rules.
For more information, see Importing Rule Updates and Local Rule Files, page 43-9.
Step 8 Reapply access control policies.
Applying an access control policy may cause a short pause in traffic flow and processing, and may also
cause a few packets to pass uninspected. For more information, see Deploying Configuration Changes,
page 4-10.
Step 9 If the VDB available on the Support Site is newer than the most recently installed VDB, install the latest
VDB.
Installing a VDB update causes a short pause in traffic flow and processing, and may also cause a few
packets to pass uninspected. For more information, see Updating the Vulnerability Database, page 43-8.
Tip Click show log for current script to see the update log. Click hide log for current script to hide the log again.
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.
Caution If you encounter any other issue with the update (for example, if a manual refresh of the page shows no
progress for an extended period of time), do not restart the update. Instead, contact Support.
When the update completes, the ASA FirePOWER module displays a success message and reboots.
After the ASA FirePOWER module finishes rebooting, complete any required post-update steps.
Note Uninstalling is not supported for major updates. If you updated to a new major version and you need to
revert to an older version, contact Support.
Caution Do not use the ASA FirePOWER module interface to perform tasks until the uninstall has completed
and, if necessary, the ASA FirePOWER module reboots. For more information, see Using the ASA
FirePOWER Module During the Update, page 43-4.
Step 3 Refresh the page. Otherwise, the interface may exhibit unexpected behavior.
Note Installing a VDB update with detection updates may cause a short pause in traffic flow and processing,
and may also cause a few packets to pass uninspected.You may want to schedule the update during low
system usage times to minimize the impact of any system downtime.
Note After you complete a VDB update, reapply any out-of-date access control policy. Keep in mind that
installing a VDB or reapplying an access control policy can cause a short pause in traffic flow and
processing, and may also cause a few packets to pass uninspected. For more information, see Deploying
Configuration Changes, page 4-10.
This section explains how to plan for and perform manual VDB updates.
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.
Step 2 Select Configuration > ASA FirePOWER Configuration > Updates.
The Product Updates page appears.
Step 3 Upload the update:
• If your ASA FirePOWER module has access to the Internet, click Download Updates to check for the
latest updates on either of the following Support Sites:
– Sourcefire: (https://support.sourcefire.com/)
– Cisco: (http://www.cisco.com/cisco/web/support/index.html)
• If your ASA FirePOWER module does not have access to the Internet, manually download the
update from one of the following Support Sites, then click Upload Update. Click Choose File to navigate
to and select the update and click Upload:
– Sourcefire: (https://support.sourcefire.com/)
– Cisco: (http://www.cisco.com/cisco/web/support/index.html)
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.
Caution The update process begins. You can monitor the update's progress in the task queue (Monitoring > ASA
FirePOWER Monitoring > Task Status). If you encounter issues with the update (for example, if the task
queue indicates that the update has failed) do not restart the update. Instead, contact Support.
You must reapply any out-of-date access control policies for the VDB update to take effect; see
Deploying Configuration Changes, page 4-10.
Note Rule updates may contain new binaries, so make sure your process for downloading and installing them
complies with your security policies. In addition, rule updates may be large, so import rules during
periods of low network use.
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. For more
information, see Allowing Rule Updates to Modify a System-Provided Base Policy, page 16-4.
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. For more information,
see Resolving Conflicts and Committing Policy Changes, page 15-15.
Reapplying Policies
For changes made by a rule update to take affect, you must reapply any modified policies. When
importing a rule update, you can configure the system to automatically reapply intrusion or access
control policies. This is especially useful if you allow the rule update to modify system-provided base
policies.
• Reapplying an access control policy also reapplies associated network analysis and file policies, but
does not reapply intrusion policies. It also updates the default values for any modified advanced
settings. Because you cannot apply a network analysis policy independently, you must reapply
access control policies if you want to update preprocessor settings in network analysis policies.
• Reapplying intrusion policies allows you to update rules and other changed intrusion policy settings.
You can reapply intrusion policies in conjunction with access control policies, or you can apply only
intrusion policies to update intrusion rules without updating any other access control configurations.
When a rule update includes shared object rules, applying an access control or intrusion policy for the
first time after the import causes a short pause in traffic flow and processing, and may also cause a few
packets to pass uninspected. For more information on applying access control and intrusion policies,
including requirements, other effects, and recommendations, see Deploying Configuration Changes,
page 4-10.
For more information on importing rule updates, see:
• Using One-Time Rule Updates, page 43-10 explains how to import a single rule update from the
Support Site.
• Using Recurring Rule Updates, page 43-12 explains how to use an automated feature to download
and install rule updates from the Support Site.
• Importing Local Rule Files, page 43-14 explains how to import a copy of a standard text rules file
that you have created on a local machine.
• Viewing the Rule Update Log, page 43-15 explains the rule update log.
The following procedure explains how to import a new rule update manually. This procedure is
especially useful if your ASA FirePOWER module does not have Internet access.
Step 1 From a computer that can access the Internet, access either of the following sites:
• Sourcefire: (https://support.sourcefire.com/)
• Cisco: (http://www.cisco.com/cisco/web/support/index.html)
Step 2 Click Download, then click Rules.
Step 3 Navigate to the latest rule update.
Rule updates are cumulative; you cannot import a rule update that either matches or predates the version
of the currently installed rules.
Step 4 Click the rule update file that you want to download and save it to your computer.
Step 5 Select Configuration > ASA FirePOWER Configuration > Updates, then select the Rule Updates tab.
The Rule Updates page appears.
Tip You can also click Import Rules on the Rule Editor page (Configuration > ASA FirePOWER Configuration >
Policies > Intrusion Policy > Rule Editor).
Step 6 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created
or imported to the deleted folder. See Deleting Custom Rules, page 27-104 for more information.
Step 7 Select Rule Update or text rule file to upload and install and click Choose File to navigate to and select the rule
update file.
Step 8 Optionally, reapply policies after the update completes:
• Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion
policies. Choose only this option to update rules and other changed intrusion policy settings without
having to update any other access control configurations you may have made. You must select this
option to reapply intrusion policies in conjunction with access control policies; reapplying access
control policies in this case does not perform a complete apply.
• Select Reapply access control policies after the rule update import completes to automatically reapply
access control policies and their associated network analysis and file policies, but not intrusion
policies. Selecting this option also updates the default values for any modified access control
advanced settings. Because you cannot apply a network analysis policy independently of its parent
access control policy, you must reapply access control policies if you want to update preprocessor
settings in network analysis policies.
Step 9 Click Import.
The system installs the rule update and displays the Rule Update Log detailed view; see Understanding
the Rule Update Import Log Detailed View, page 43-18. The system also applies policies as you
specified in the previous step; see Deploying Configuration Changes, page 4-10 and Applying an
Intrusion Policy, page 23-7.
Note Contact Support if you receive an error message while installing the rule update.
Step 1 Select Configuration > ASA FirePOWER Configuration > Updates, then select the Rule Updates tab.
The Rule Updates page appears.
Tip You can also click Import Rules on the Rule Editor page (Configuration > ASA FirePOWER Configuration >
Policies > Intrusion Policy > Rule Editor).
Step 2 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created
or imported to the deleted folder. See Deleting Custom Rules, page 27-104 for more information.
Step 3 Select Download new Rule Update from the Support Site.
Step 4 Optionally, reapply policies after the update completes:
• Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion
policies. Choose only this option to update rules and other changed intrusion policy settings without
having to update any other access control configurations you may have made. You must select this
option to reapply intrusion policies in conjunction with access control policies; reapplying access
control policies in this case does not perform a complete apply.
• Select Reapply access control policies after the rule update import completes to automatically reapply
access control, network analysis, and file policies, but not intrusion policies. Selecting this option
also updates the default values for any modified access control advanced settings. Because you
cannot apply a network analysis policy independently of its parent access control policy, you must
reapply access control policies if you want to update preprocessor settings in network analysis
policies.
Step 5 Click Import.
The system installs the rule update and displays the Rule Update Log detailed view; see Understanding
the Rule Update Import Log Detailed View, page 43-18. The system also applies policies as you
specified in the previous step; see Deploying Configuration Changes, page 4-10 and Applying an
Intrusion Policy, page 23-7.
Note Contact Support if you receive an error message while installing the rule update.
Applicable subtasks in the rule update import occur in the following order: download, install, base policy
update, and policy reapply. When one subtask completes, the next subtask begins. Note that you can only
apply policies previously applied by the ASA FirePOWER module where the recurring import is
configured.
Step 1 Select Configuration > ASA FirePOWER Configuration > Updates, then select the Rule Updates tab.
The Rule Updates page appears.
Tip You can also click Import Rules on the Rule Editor page (Configuration > ASA FirePOWER Configuration >
Policies > Intrusion Policy > Rule Editor).
Step 2 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created
or imported to the deleted folder. See Deleting Custom Rules, page 27-104 for more information.
Step 3 Select Enable Recurring Rule Update Imports.
The page expands to display options for configuring recurring imports. Import status messages appear
beneath the Recurring Rule Update Imports section heading. Recurring imports are enabled when you save
your settings.
Tip To disable recurring imports, clear the Enable Recurring Rule Update Imports check box and click Save.
Step 4 In the Import Frequency field, select Daily, Weekly, or Monthly from the drop-down list.
If you selected a weekly or monthly import frequency, use the drop-down lists that appear to select the
day of the week or month when you want to import rule updates. Select from a recurring task drop-down
list either by clicking or by typing the first letter or number of your selection one or more times and
pressing Enter.
Step 5 In the Import Frequency field, specify the time when you want to start your recurring rule update import.
Step 6 Optionally, reapply policies after the update completes:
• Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion
policies. Choose only this option to update rules and other changed intrusion policy settings without
having to update any other access control configurations you may have made. You must select this
option to reapply intrusion policies in conjunction with access control policies; reapplying access
control policies in this case does not perform a complete apply.
• Select Reapply access control policies after the rule update import completes to automatically reapply
access control policies and their network analysis and file policies, but not intrusion policies.
Selecting this option also updates the default values for any modified access control advanced
settings. Because you cannot apply a network analysis policy independently of its parent access
control policy, you must reapply access control policies if you want to update preprocessor settings
in network analysis policies.
Step 7 Click Save to enable recurring rule update imports using your settings.
The status message under the Recurring Rule Update Imports section heading changes to indicate that
the rule update has not yet run. At the scheduled time, the system installs the rule update and applies
policies as you specified in the previous step; see Deploying Configuration Changes, page 4-10 and
Applying an Intrusion Policy, page 23-7.
You can log off or perform other tasks before or during the import. When accessed during an import, the
Rule Update Log displays a red status icon ( ), and you can view messages as they occur in the Rule
Update Log detailed view. Depending on the rule update size and content, several minutes may pass
before status messages appear. For more information, see Viewing the Rule Update Log, page 43-15.
Note Contact Support if you receive an error message while installing the rule update.
• All imported local rules are automatically saved in the local rule category.
• All deleted local rules are moved from the local rule category to the deleted rule category.
• The system imports local rules preceded with a single pound character (#).
• The system ignores local rules preceded with two pound characters (##) and does not import them.
• 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. See
Configuring Event Thresholding, page 24-21 for more information.
Step 1 Select Configuration > ASA FirePOWER Configuration > Update, then select the Rule Updates tab.
The Rule Updates page appears.
Step 2 Select Rule Update or text rule file to upload and install and click Choose File to navigate to the rule file. Note
that all rules uploaded in this manner are saved in the local rule category.
Tip You can import only plain text files with ASCII or UTF-8 encoding.
Note The system does not use the new rule set for inspection until after you apply your intrusion
policies. See Deploying Configuration Changes, page 4-10 for procedures.
Step 1 Select Configuration > ASA FirePOWER Configuration > Updates, then select the Rule Updates tab.
The Rule Updates page appears.
Tip You can also click Import Rules on the Rule Editor page (Configuration > ASA FirePOWER Configuration >
Policies > Intrusion Policy > Rule Editor).
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.
Time The time and date that the import started.
User ID The user name of the user that triggered the import.
Status Whether the import:
• succeeded ( )
• failed or is currently in progress ( )
Tip 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.
Click the view icon ( ) next to the rule update or file name to view the Rule Update Log detailed page
for the rule update or local rule file, or click the delete icon ( ) to delete the file record and all detailed
object records imported with the file.
Tip You can view import details as they appear while a rule update import is in progress.
Step 1 Select Configuration > ASA FirePOWER Configuration > Updates, then select the Rule Updates tab.
The Rule Updates page appears.
Tip You can also click Import Rules on the Rule Editor page (Configuration > ASA FirePOWER Configuration >
Policies > Intrusion Policy > Rule Editor).
Field Description
Time The time and date the import began.
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.
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 intrusion policies after the Rule Update import completes option was enabled
for the import)
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 ASA FirePOWER module)
• 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)
• 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
system-provided policy)
• disabled (for rules, the rule has been disabled in a system-provided policy)
• drop (for rules, the rule has been set to Drop and Generate Events in a system-provided policy)
• error (for a rule update or local rule file, the import failed)
• apply (the Reapply intrusion 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.
GID The generator ID for a rule. For example, 1 (standard text rule) or 3 (shared object rule).
SID The SID for a rule.
Rev The revision number for a rule.
Table 43-5 Rule Update Import Log Detailed View Fields (continued)
Field Description
Policy For imported rules, this field displays All, which indicates that the imported rule was included in all
system-provided intrusion policies. For other types of imported objects, this field is blank.
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.
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.
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.
The update process begins. The average duration of update installation is 30 to 40 minutes. You can
monitor the update’s progress in the task queue (Monitoring > ASA FirePOWER Monitoring > Task Status).
Step 4 After the update finishes, return to the Geolocation Updates page to confirm that the GeoDB build
number matches the update you installed.
The GeoDB update overrides any previous versions of the GeoDB and is effective immediately.
Although it may take a few minutes for a GeoDB update to take effect throughout your deployment, you
do not have to reapply access control policies after you update.
The ASA FirePOWER module ASA FirePOWER module provides many useful monitoring features to
assist you in the daily administration of your system, all on a single page. For example, on the Host
Statistics page you can monitor basic host statistics. The following sections provide more information
about the monitoring features that the system provides:
• Viewing Host Statistics, page 44-1 describes how to view host information such as:
• system uptime
• disk and memory usage
• system processes
• intrusion event information
• Monitoring System Status and Disk Space Usage, page 44-2 describes how to view basic event and
disk partition information.
• Viewing System Process Status, page 44-2 describes how to view basic process status.
• Understanding Running Processes, page 44-4 describes the basic system processes that run on the
appliance.
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.
Memory Usage The percentage of system memory that is being used.
Category Description
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. See Monitoring System Status and Disk Space Usage, page 44-2 for
more information.
Processes A summary of the processes running on the system. See Viewing System Process
Status, page 44-2 for more information.
The following table describes each column that appears in the process list.
Column Description
Pid The process ID number
Username The name of the user or group running the process
Pri The process priority
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)
State The process state:
• D — process is in uninterruptible sleep (usually Input/Output)
• N — process has a positive nice value
• R — process is runnable (on queue to run)
• S — process is in sleep mode
• T — process is being traced or stopped
• W — process is paging
• X — process is dead
• Z — process is defunct
• < — process has a negative nice value
Time The amount of time (in hours:minutes:seconds) that the process has been running
Cpu The percentage of CPU that the process is using
Command The executable name of the process
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
Note For more information about the types of processes that run on the appliance, see Understanding
Running Processes, page 44-4.
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)
dhclient Manages dynamic host IP addressing
httpd Manages the HTTP (Apache web server) process
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
keventd Manages Linux kernel event notification messages
klogd Manages the interception and logging of Linux kernel messages
kswapd Manages Linux kernel swap memory
kupdated Manages the Linux kernel update process, which performs disk synchronization
mysqld Manages ASA FirePOWER module database processes
ntpd Manages the Network Time Protocol (NTP) process
pm Manages all Cisco processes, starts required processes, restarts any process that fails
unexpectedly
reportd Manages reports
safe_mysqld Manages safe mode operation of the database; restarts the database daemon if an error occurs
and logs runtime information to a file
sfmgr Provides the RPC service for remotely managing and configuring an appliance using an sftunnel
connection to the appliance
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
syslogd Manages the system logging (syslog) process
Executable Description
awk Utility that executes programs written in the awk programming language
bash GNU Bourne-Again SHell
cat Utility that reads files and writes content to standard output
chown Utility that changes user and group file permissions
chsh Utility that changes the default login shell
cp Utility that copies files
df Utility that lists the amount of free space on the appliance
echo Utility that writes content to standard output
egrep Utility that searches files and folders for specified input; supports extended
set of regular expressions not supported in standard grep
find Utility that recursively searches directories for specified input
grep Utility that searches files and directories for specified input
halt Utility that stops the server
httpsdctl Handles secure Apache Web processes
hwclock Utility that allows access to the hardware clock
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. See Configuring the Access List for Your Appliance,
page 40-3 for more information about access configuration.
iptables-restore Handles iptables file restoration
iptables-save Handles saved changes to the iptables
kill Utility that can be used to end a session and process
killall Utility that can be used to end all sessions and processes
ksh Public domain version of the Korn shell
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
mv Utility that moves (renames) files
myisamchk Indicates database table checking and repairing
mysql Indicates a database process; multiple instances may appear
openssl Indicates authentication certificate creation
perl Indicates a perl process
ps Utility that writes process information to standard output
sed Utility used to edit one or more text files
sh Public domain version of the Korn shell
shutdown Utility that shuts down the appliance
Executable Description
sleep Utility that suspends a process for a specified number of seconds
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
snort Indicates that Snort is running
(requires Protection)
ssh Indicates a Secure Shell (SSH) connection to the appliance
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
vim Utility used to edit text files
wc Utility that performs line, word, and byte counts on specified files
Backup and restoration is an essential part of any system maintenance plan. While each organization’s
backup plan is highly individualized, the ASA FirePOWER module provides a mechanism for archiving
data so that data can be restored in case of disaster.
Note the following limitations about backup and restore:
• Backups are valid only for the product version on which you create them.
• You can restore a backup only when running the same version of the ASA FirePOWER module
software as that used to create the backup.
Caution Do not use the backup and restore process to copy the configuration files between ASA FirePOWER
modules. The configuration files include information that uniquely identifies an ASA FirePOWER
module and cannot be shared.
Caution If you applied any intrusion rule updates, those updates are not backed up. You need to apply the latest
rule update after you restore.
You can save backup files to the appliance or to your local computer.
See the following sections for more information:
• See Creating Backup Files, page 45-1 for information about creating backup files.
• See Creating Backup Profiles, page 45-3 for information about creating backup profiles that you can
use later as templates for creating backups.
• See Uploading Backups from a Local Host, page 45-4 for information about uploading backup files
from a local host.
• See Restoring the Appliance from a Backup File, page 45-4 for information about how to restore a
backup file to the appliance.
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.
You cannot create a backup file if your appliance does not have enough disk space; backups may fail if
the backup process uses more than 90% of available disk space. If necessary, delete old backup files,
transfer old backup files off the appliance.
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.
Caution If you configured any interface associations with security zones, these associations are not backed up.
You must reconfigure them after you restore. For more information, see Working with Security Zones,
page 2-33.
Step 1 Select Configuration > ASA FirePOWER Configuration > Tools > Backup/Restore.
The Backup Management page appears.
Step 2 Click Device Backup.
The Create Backup page appears.
Step 3 In the Name field, type a name for the backup file. You can use alphanumeric characters, punctuation,
and spaces.
Step 4 Optionally, 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, page 40-6.
Step 5 Optionally, 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.
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.
Tip Cisco recommends that you periodically save backups to a remote location so the appliance can be
restored in case of system failure.
Tip When you create a backup file as described in Creating Backup Files, page 45-1, a backup profile is
automatically created.
Step 1 Select Configuration > ASA FirePOWER Configuration > Tools > Backup/Restore.
The Backup Management page appears.
Step 2 Click the Backup Profiles tab.
The Backup Profiles page appears with a list of existing backup profiles.
Tip You can click the edit icon ( ) to modify an existing profile or click the delete icon ( ) to delete a
profile from the list.
Tip You cannot upload a backup larger than 4GB from your local host. As an alternative, copy the backup
via SCP to a remote host and retrieve it from there.
Step 1 Select Configuration > ASA FirePOWER Configuration > Tools > Backup/Restore.
The Backup Management page appears.
Step 2 Click Upload Backup.
The Upload Backup page appears.
Step 3 Click Choose File and navigate to the backup file you want to upload.
After you select the file to upload, click Upload Backup.
Step 4 Click Backup Management to return to the Backup Management page.
The backup file is uploaded and appears in the backup list. After the ASA FirePOWER moduleverifies
the file integrity, refresh the Backup Management page to reveal detailed file system information.
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.
The following table describes each column and icon on the Backup Management page.
Functionality Description
System The originating appliance name, type, and version. Note that you can only restore
Information a backup to an identical appliance type and version.
Date Created The date and time that the backup file was created
File Name The full name of the backup file
VDB Version The build of the vulnerability database (VDB) running on the appliance at the time
of backup.
Location The location of the backup file
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.
Delete Click with the backup file selected to delete it.
Move When you have a previously created local backup selected, click to send the
backup to the designated remote backup location.
Step 1 Select Configuration > ASA FirePOWER Configuration > Tools > Backup/Restore.
The Backup Management page appears.
Step 2 To view the contents of a backup file, click the name of the file.
The manifest appears, listing the name of each file, its owner and permissions, and its file size and date.
Step 3 Click Backup Management to return to the Backup Management page.
Step 4 Select the backup file that you want to restore and click Restore.
The Restore Backup page appears.
Note that if the VDB version in the backup does not match the VDB version currently installed on your
appliance, the Restore button is grayed out.
Caution This procedure overwrites all configuration files and all event data.
Step 9 Reapply any access control, intrusion, and system policies to the restored system.
In some cases, if you have a problem with your appliance, Support may ask you to generate
troubleshooting files to help them diagnose the problem. You can select any of the options listed in the
following table to customize the troubleshooting data that the ASA FirePOWER module reports.
Table A-1 Selectable Troubleshoot Options
Note that some options overlap in terms of the data they report, but the troubleshooting files will not
contain redundant copies, regardless of what options you select.
For more information, see the following sections:
• Generating Appliance Troubleshooting Files, page A-1
• Downloading Troubleshooting Files, page A-2
Step 1 In ASDM, select Configuration > ASA FirePOWER Configuration > Tools > Troubleshooting.
Step 2 Click Generate Troubleshooting Files.
The Troubleshooting Options pop-up window appears.
Step 3 Select All Data to generate all possible troubleshooting data, or select individual check boxes to
customize your report. For more information, see the Selectable Troubleshoot Options table.
Step 4 Click OK.
The ASA FirePOWER module generates the troubleshooting files. You can monitor the file generation
process in the task queue (Monitoring > ASA FirePOWER Monitoring > Task Status).
Step 5 Continue with the procedure in the next section, Downloading Troubleshooting Files.
Step 1 In ASDM, select Monitoring > ASA FirePOWER Monitoring > Task Status.
The Task Status page appears.
Step 2 Find the task that corresponds to the troubleshooting files you generated.
Step 3 After the appliance generates the troubleshooting files and the task status changes to Completed, click
Click to retrieve generated files.
Step 4 Follow your browser’s prompts to download the files.
The files are downloaded in a single .tar.gz file.
Step 5 Follow the directions from Support to send the troubleshooting files to Cisco.
You can use the Import/Export feature to copy several types of configurations, including policies, from
one appliance to another appliance of the same type. Configuration import and export is not intended as
a backup tool, but can be used to simplify the process of adding new ASA FirePOWER modules.
You can import and export the following configurations:
• access control policies and their associated network analysis and file policies
• intrusion policies
• system policies
• alert responses
To import an exported configuration, both ASA FirePOWER modules must be running the same software
version. To import an exported intrusion or access control policy, the rule update versions on both
appliances must also match.
For more information, see the following sections:
• Exporting Configurations, page B-1
• Importing Configurations, page B-3
Exporting Configurations
License: Any
You can export a single configuration, or you can export a set of configurations (of the same type or of
different types) at once. When you later import the package onto another appliance, you can choose
which configurations in the package to import.
When you export a configuration, the appliance also exports revision information for that configuration.
The ASA FirePOWER module uses that information to determine whether you can import that
configuration onto another appliance; you cannot import a configuration revision that already exists on
an appliance.
In addition, when you export a configuration, the appliance also exports system configurations that the
configuration depends on.
Tip Many list pages in the ASA FirePOWER module 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.
Note You cannot use the Import/Export feature to update rules created by the Vulnerability
Research Team (VRT). Instead, download and apply the latest rule update version; see
Importing Rule Updates and Local Rule Files, page 43-9.
• System policies — A system policy controls the aspects of an ASA FirePOWER module that are
likely to be similar to other ASA FirePOWER modules in your deployment, including time settings,
SNMP settings, and so on.
Note Depending on the number of configurations being exported and the number of objects those
configurations reference, the export process may take several minutes.
Step 1 Make sure that the ASA FirePOWER module where you are exporting the configurations and the ASA
FirePOWER module where you plan to import the configurations are running the same version. If you
are exporting an intrusion or access control policy, make sure that the rule update versions match.
If the versions of the ASA FirePOWER module (and, if applicable, the rule update versions) do not
match, the import will fail.
Step 2 Select Configuration > ASA FirePOWER Configuration > Tools > Import Export.
The Import/Export page appears, including a list of the configurations on the ASA FirePOWER module.
Note that configuration categories with no configurations to export do not appear in this list.
Tip You can click the collapse icon ( ) next to a configuration type to collapse the list of configurations.
Click the expand folder icon ( ) next to an configuration type to reveal configurations.
Step 3 Select the check boxes next to the configurations you want to export and click Export.
Step 4 Follow the prompts to save the exported package to your computer.
Importing Configurations
License: Any
After you export a configuration from an appliance, you can import it onto a different appliance as long
as that appliance supports it.
Depending on the type of configuration you are importing, you should keep the following points in mind:
• You must make sure that the ASA FirePOWER module where you import a configuration is running
the same version as the ASA FirePOWER module you used to export the configuration. If you are
importing an intrusion or access control policy, the rule update versions on both appliances must
also match. If the versions do not match, the import will fail.
• If you import an access control policy that evaluates traffic based on zones, you must map the zones
in the imported policy to zones on the importing ASA FirePOWER module. When you map zones,
their types must match. Therefore, you must create any zone types you need on the importing ASA
FirePOWER module before you begin the import. For more information about security zones, see
Working with Security Zones, page 2-33.
• If you import an access control policy that includes an object or object group that has an identical
name to an existing object or group, you must rename the object or group.
• If you import an access control policy or an intrusion policy, the import process replaces 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.
• If you import an intrusion policy that used a shared layer from a second intrusion policy, the export
process breaks the sharing relationship and the previously shared layer is copied into the package.
In other words, imported intrusion policies do not contain shared layers.
Note You cannot use the Import/Export feature to update rules created by the Vulnerability
Research Team (VRT). Instead, download and apply the latest rule update version; see
Importing Rule Updates and Local Rule Files, page 43-9.
ASA FirePOWER moduleBecause you can export several configurations in a single package, when you
import the package you must choose which configurations in the package to import.
When you attempt to import a configuration, your ASA FirePOWER module determines whether that
configuration already exists on the appliance. If a conflict exists, you can:
Step 1 Make sure that the ASA FirePOWER module where you are exporting the configurations and the module
where you plan to import the configurations are running the same version. If you want to import an
intrusion or access control policy, you must also make sure that the rule update versions match.
If the versions of the ASA FirePOWER module (and, if applicable, the rule update versions) do not
match, the import will fail.
Step 2 Export the configurations you want to import; see Exporting Configurations, page B-1.
Step 3 On the appliance where you want to import the configurations, select Configuration > ASA FirePOWER
Configuration > Tools > Import Export.
The Import Export page appears.
Tip Click the collapse icon ( ) next to a configuration type to collapse the list of configurations. Click
the expand folder icon ( ) next to a configuration type to reveal configurations.
Step 7 Select the configurations you want to import and click Import.
The import process resolves, with the following results:
• If the configurations you import do not have previous revisions on your ASA FirePOWER module,
the import completes automatically and a success message appears. Skip the rest of the procedure.
• If you are importing an access control policy that includes security zones, the Access Control Import
Resolution page appears. Continue with step 8.
• If the configurations you import do have previous revisions on your appliance, the Import Resolution
page appears. Continue with step 9.
Step 8 Next to each incoming security zone, select an existing local security zone of a matching type to map to
and click Import.
Return to step 7.
Step 9 Expand each configuration and select the appropriate option:
• To keep the configuration on your appliance, select Keep existing.
• To replace the configuration on your appliance with the imported configuration, select Replace
existing.
• To keep the newest configuration, select Keep newest.
• To save the imported configuration as a new configuration, select Import as new and, optionally, edit
the configuration name.
If you are importing an access control policy that includes a file policy with either the clean list or
custom detection list enabled, the Import as new option is not available.
• If you are importing an access control policy or saved search that includes a dependent object, either
accept the suggested name or rename the object. The system always imports these dependent objects
as new. You do not have the option to keep or to replace existing objects. Note that the system treats
objects and object groups in the same manner.
Step 10 Click Import.
The configurations are imported.
Some tasks that you can perform on the ASA FirePOWER module, such as applying a policy or installing
updates, do not complete instantly and require some time to run. You can check the progress of these
long-running tasks in the task queue. The task queue also reports when they are successfully or
unsuccessfully resolved.
For more information, see the following sections:
• Viewing the Task Queue, page C-1
• Managing the Task Queue, page C-2
The Jobs section provides information about each task, including a brief description, when the task was
launched, the current status of the task, and when the status last changed. Tasks of the same type appear
together in a task group.
To make sure that the Task Status page loads quickly, once per week, the ASA FirePOWER module
removes from the queue all completed, failed, and stopped tasks that are over a month old, as well the
oldest tasks from any task group that contains over 1000 tasks. You can also manually remove tasks from
the queue; see Managing the Task Queue for directions.
To safeguard the ASA FirePOWER module, you should install it on a protected internal network.
Although the ASA FirePOWER module is configured to have only the necessary services and ports
available, you must make sure that attacks cannot reach it from outside the firewall.
Also note that specific features of the ASA FirePOWER module require an Internet connection. By
default, the ASA FirePOWER module is configured to directly connect to the Internet. Additionally, the
system requires certain ports remain open for secure appliance access and so that specific system
features can access the local or Internet resources to operate correctly.
For more information, see:
• Internet Access Requirements, page D-1
• Communication Ports Requirements, page D-2
Table D-1 ASA FirePOWER module Feature Internet Access Requirements (continued)
Caution Do not close an open port until you understand how this action will affect your deployment.
For example, closing port 25/tcp (SMTP) outbound on a manage device blocks the device from sending
email notifications for individual intrusion events (see Configuring External Alerting for Intrusion
Rules, page 36-1).
The following table lists the open ports required so that you can take full advantage of ASA FirePOWER
module features.
Table D-2 Default Communication Ports for ASA FirePOWER module Features and Operations
Table D-2 Default Communication Ports for ASA FirePOWER module Features and Operations