The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics describe how to configure advanced settings for network analysis and intrusion policies:
Many of the advanced settings in an access control policy govern intrusion detection and prevention configurations that require specific expertise to configure. Advanced settings typically require little or no modification and are not common to every deployment.
Any.
Any
Admin
Access Admin
Network Admin
For some features, including URL filtering, application detection, rate limiting, and Intelligent Application Bypass, a few packets must pass in order for the connection to be established, and to enable the system to identify the traffic and determine which access control rule (if any) will handle that traffic.
You must explicitly configure your access control policy to inspect these packets, prevent them from reaching their destination, and generate any events. See Specify a Policy to Handle Packets That Pass Before Traffic Identification.
As soon as 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.
The default action specified for an access control policy is NOT applied to these packets.
Instead, use the following guidelines to choose a value for the Intrusion Policy used before Access Control rule is determined setting in the Advanced settings of the access control policy.
You can choose a system-created or custom intrusion policy. For example, you can choose Balanced Security and Connectivity.
For performance reasons, unless you have good reason to do otherwise, this setting should match the default action set for your access control policy.
If your system does not perform intrusion inspection (for example, in a discovery-only deployment), select No Rules Active. The system will not inspect these initial packets, and they will be allowed to pass.
By default, this setting uses the default variable set. Ensure that this is suitable for your purposes. For information, see Variable Set.
The network analysis policy associated with the first matching network analysis rule preprocesses traffic for the policy you select. If there are no network analysis rules, or none match, the default network analysis policy is used.
 Note |
This setting is sometimes referred to as the default intrusion policy. (This is distinct from the default action for an access control policy.) |
Review best practices for these settings. See Best Practices for Handling Packets That Pass Before Traffic Identification.
|
Step 1 |
In the access control policy editor, click Advanced, then click Edit ( If View ( |
|
Step 2 |
Select an intrusion policy from the Intrusion Policy used before Access Control rule is determined drop-down list. If you choose a user-created policy, you can click Edit ( |
|
Step 3 |
Optionally, select a different variable set from the Intrusion Policy Variable Set drop-down list. You can also select Edit ( |
|
Step 4 |
Click OK. |
|
Step 5 |
Click Save to save the policy. |
Deploy configuration changes; see Deploy Configuration Changes.
Network analysis policies govern how traffic is decoded and preprocessed so that it can be further evaluated, especially for anomalous traffic that might signal an intrusion attempt. This traffic preprocessing occurs after Security Intelligence matching and traffic decryption, but before intrusion policies inspect packets in detail. By default, the system-provided Balanced Security and Connectivity network analysis policy is the default network analysis policy.
 Tip |
The system-provided Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy governs mostly intrusion rules. |
A simple way to tune preprocessing is to create and use a custom network analysis policy as the default. For advanced users with complex deployments, you can create multiple network analysis policies, each tailored to preprocess traffic differently. Then, you can configure the system to use those policies to govern the preprocessing of traffic using different security zones, networks, or VLANs.
To accomplish this, you add custom network analysis rules to your access control policy. A network analysis rule is simply a set of configurations and conditions that specifies how you preprocess traffic that matches those qualifications. You create and edit network analysis rules in the advanced options in an existing access control policy. Each rule belongs to only one policy.
Each rule has:
a set of rule conditions that identifies the specific traffic you want to preprocess
an associated network analysis policy that you want to use to preprocess traffic that meets all the rules’ conditions
When it is time for the system to preprocess traffic, it matches packets to network analysis rules in top-down order by rule number. Traffic that does not match any network analysis rules is preprocessed by the default network analysis policy.
You can choose a system- or user-created policy.
Note |
If you disable a preprocessor but the system needs to evaluate preprocessed packets against an enabled intrusion or preprocessor rule, the system automatically enables and uses the preprocessor although it remains disabled in the network analysis policy web interface. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. Because preprocessing and intrusion inspection are so closely related, you must be careful that you allow the network analysis and intrusion policies examining a single packet to complement each other. |
|
Step 1 |
In the access control policy editor, click Advanced, then click Edit ( If View ( |
|
Step 2 |
From the Default Network Analysis Policy drop-down list, select a default network analysis policy. If you choose a user-created policy, you can click Edit ( |
|
Step 3 |
Click OK. |
|
Step 4 |
Click Save to save the policy. |
Deploy configuration changes; see Deploy Configuration Changes.
Within your access control policy’s advanced settings, you can use network analysis rules to tailor preprocessing configurations to network traffic.
Network analysis rules are numbered, starting at 1. When it is time for the system to preprocess traffic, it matches packets to network analysis rules in top-down order by ascending rule number, and preprocesses traffic according to the first rule where all the rule’s conditions match.
You can add zone, network, and VLAN tag conditions to a rule. If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a network condition but no zone condition evaluates traffic based on its source or destination IP address, regardless of its ingress or egress interface. Traffic that does not match any network analysis rules is preprocessed by the default network analysis policy.
Rule conditions enable you to fine-tune your network analysis policy to target the users and networks you want to control. See one of the following sections for more information.
Security zones segment your network to help you manage and classify traffic flow by grouping interfaces across multiple devices.
Zone rule conditions control traffic by its source and destination security zones. If you add both source and destination zones to a zone condition, matching traffic must originate from an interface in one of the source zones and leave through an interface in one of the destination zones.
Just as all interfaces in a zone must be of the same type (all inline, passive, switched, or routed), all zones used in a zone condition must be of the same type. Because devices deployed passively do not transmit traffic, you cannot use a zone with passive interfaces as a destination zone.
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
Tip |
Constraining rules by zone is one of the best ways to improve system performance. If a rule does not apply to traffic through any of device’s interfaces, that rule does not affect that device's performance. |
In a multidomain deployment, a zone created in an ancestor domain can contain interfaces that reside on devices in different domains. When you configure a zone condition in an descendant domain, your configurations apply to only the interfaces you can see.
Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.
You can use predefined objects to build network conditions, or manually specify individual IP addresses or address blocks.
Note |
You cannot use FDQN network objects in identity rules. |
Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.
Note |
VLAN tags in access rules only apply to inline sets. Access rules with VLAN tags do not match traffic on firewall interfaces. |
VLAN rule conditions control VLAN-tagged traffic, including Q-in-Q (stacked VLAN) traffic. The system uses the innermost VLAN tag to filter VLAN traffic, with the exception of the prefilter policy, which uses the outermost VLAN tag in its rules.
Note the following Q-in-Q support:
Threat Defense on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).
Threat Defense on all other models:
Inline sets and passive interfaces—Supports Q-in-Q, up to 2 VLAN tags.
Firewall interfaces—Does not support Q-in-Q (supports only one VLAN tag).
You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094. Use a hyphen to specify a range of VLAN tags.
You can specify a maximum of 50 VLAN conditions.
In a cluster, if you encounter problems with VLAN matching, edit the access control policy advanced options, Transport/Network Preprocessor Settings, and select the Ignore the VLAN header when tracking connections option.
|
Step 1 |
In the access control policy editor, click Advanced, then click Edit ( If View (
|
||
|
Step 2 |
Next to Network Analysis Rules, click the statement that indicates how many custom rules you have. |
||
|
Step 3 |
Click Add Rule. |
||
|
Step 4 |
Configure the rule's conditions by clicking the conditions you want to add. |
||
|
Step 5 |
Click Network Analysis and choose the Network Analysis Policy you want to use to preprocess the traffic matching this rule. Click Edit ( |
||
|
Step 6 |
Click Add. |
Deploy configuration changes; see Deploy Configuration Changes.
A network analysis rule is simply a set of configurations and conditions that specifies how you preprocess traffic that matches those qualifications. You create and edit network analysis rules in the advanced options in an existing access control policy. Each rule belongs to only one policy.
|
Step 1 |
In the access control policy editor, click Advanced, then click Edit ( If View ( |
||
|
Step 2 |
Next to Network Analysis Rules, click the statement that indicates how many custom rules you have. |
||
|
Step 3 |
Edit your custom rules. You have the following options:
|
||
|
Step 4 |
Click OK. |
||
|
Step 5 |
Click Save to save the policy. |
Deploy configuration changes; see Deploy Configuration Changes.
)
)
Feedback