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 manage common characteristics of rules in various policies on the Firepower Management Center:
Any.
Any
Admin
Access Admin
Network Admin
Rules in various policies exert granular control over network traffic. The system evaluates traffic against rules in the order that you specify, using a first-match algorithm.
Although these rules may include other configurations that are not consistent across policies, they share many basic characteristics and configuration mechanics, including:
Conditions: Rule conditions specify the traffic that each rule handles. You can configure each rule with multiple conditions. Traffic must match all conditions to match the rule.
Action: A rule's action determines how the system handles matching traffic. Note that even if a rule does not have an Action list you can choose from, the rule still has an associated action. For example, a custom network analysis rule uses a network analysis policy as its "action."
Position: A rule's position determines its evaluation order. When using a policy to evaluate traffic, the system matches traffic to rules in the order you specify. Usually, the system handles traffic according to the first rule where all the rule’s conditions match the traffic. (Monitor rules, which are designed to track and log, are an exception.) Proper rule order reduces the resources required to process network traffic, and prevents rule preemption.
Category: To organize some rule types, you can create custom rule categories in each parent policy.
Logging: For many rules, logging settings govern whether and how the system logs connections handled by the rule. Some rules (such as identity and network analysis rules) do not include logging settings because the rules neither determine the final disposition of connections, nor are they specifically designed to log connections.
Comments: For some rule types, each time you save changes, you can add comments. For example, you might summarize the overall configuration for the benefit of other users, or note when you change a rule and the reason for the change.
 Tip |
A right-click menu in many policy editors provides shortcuts to many rule management options, including editing, deleting, moving, enabling, and disabling. |
This chapter documents many common aspects of the following rules and configurations. For information on non-shared configurations, see:
Access control rules: Access Control Rules
SSL rules: Creating and Modifying TLS/SSL Rules
DNS rules: Creating and Editing DNS Rules
Identity rules: Create an Identity Rule
Network analysis rules: Configuring Network Analysis Rules
Intelligent Application Bypass (IAB): Intelligent Application Bypass
Application filters: Application Filters
Rules whose configurations are not documented in this chapter include:
Intrusion rules: Tuning Intrusion Policies Using Rules
File and malware rules: File Rules
Correlation rules: Configuring Correlation Rules
NAT rules (Classic): NAT for 7000 and 8000 Series Devices
8000 Series fastpath rules: Configure Fastpath Rules (8000 Series)
The following table describes the common rule conditions documented in this chapter, and lists the configurations where they are used.
|
Condition |
Controls Traffic By... |
Supported Rules/Configurations |
||
|---|---|---|---|---|
|
Source and destination security zones |
Access control rules SSL rules DNS rules Identity rules Network analysis rules |
|||
|
Source and destination IP address, and where supported, geographical location |
Access control rules SSL rules DNS rules Identity rules Network analysis rules |
|||
|
VLAN tag |
Access control rules
SSL rules DNS rules Identity rules Network analysis rules |
|||
|
Source and destination ports, protocols, and ICMP codes |
Access control rules SSL rules Identity rules |
|||
|
Application or application characteristic (type, risk, business relevance, category, and tags) |
Access control rules SSL rules Identity rules Application filters Intelligent Application Bypass (IAB) |
|||
|
URL, and where supported, URL characteristic (category and reputation) |
Access control rules SSL rules |
|||
|
Logged-in authoritative user of a host, or that user's realm, group, or ISE attributes |
Access control rules SSL rules (no ISE attributes) |
Rule conditions specify the traffic that each rule handles. You can configure each rule with multiple conditions, and traffic must match all conditions to match the rule. The available condition types depend on the rule type.
In rule editors, each condition type has its own tab page. Build conditions by choosing the traffic characteristics you want to match. In general, choose criteria from one or two lists of available items on the left, then add or combine those criteria into one or two lists of selected items on the right. For example, in URL conditions in access control rules, you can combine URL category and reputation criteria to create a single group of websites to block.
To help you build conditions, you can match traffic using various system-provided and custom configurations, including realms, ISE attributes, and various types of objects and object groups. Often, you can manually specify rule criteria.
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.
 Caution |
Failure to set up your access control rules properly can have unexpected results, including traffic being allowed that should be blocked. In general, application control rules should be lower in your access control list because it takes longer for those rules to match than rules based on IP address, for example. Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect (OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session, presentation, and application) should be ordered later in your access control rules. For more information about the OSI model, see this Wikipedia article. |
Where a rule involves source and destination criteria (zones, networks, ports), usually you can use either or both criteria as constraints. If you use both, matching traffic must originate from one of the specified source zones, networks, or ports and leave through one of the destination zones, networks, or ports.
You can add up to 50 items to each condition. For rules with source and destination criteria, you can use up to 50 of each. Traffic that matches any of the selected items matches the condition.
In rule editors, you have the following general choices. For detailed instructions on building conditions, see the topics for each condition type.
Choose Item—Click an item or check its check box. Often you can use Ctrl or Shift to choose multiple items, or right-click to Select All.
Search—Enter criteria in the search field. The list updates as you type. The system searches item names and, for objects and
object groups, their values. Click Reload (
) or Clear (
) to clear the search.
Add Predefined Item—After you choose one or more available items, click an Add button or drag and drop. The system prevents you from adding invalid items: duplicates, invalid combinations, and so on.
Add Manual Item—Click the field under the Selected items list, enter a valid value, and click Add. When you add ports, you may also choose a protocol from the drop-down list.
Create Object—Click Add (
) to create a new, reusable object that you can immediately use in the
condition you are building, then manage in the object manager. When using
this method to add application filters on the fly, you cannot save a filter
that includes another user-created filter.
Delete—Click the Delete (
) for an item, or choose one or more items and right-click to Delete Selected.
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, routed, or ASA FirePOWER), 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.
The following rules support security zone conditions:
Access control
SSL
DNS (source zone constraints only)
Identity
Network analysis
Consider a deployment where you want hosts to have unrestricted access to the internet, but you nevertheless want to protect them by inspecting incoming traffic for intrusions and malware.
First, create two security zones: Internal and External. Then, assign interface pairs on one or more devices to those zones, with one interface in each pair in the Internal zone and one in the External zone. Hosts connected to the network on the Internal side represent your protected assets.
 Note |
You are not required to group all internal (or external) interfaces into a single zone. Choose the grouping that makes sense for your deployment and security policies. |
Then, configure an access control rule with a destination zone condition set to Internal. This simple rule matches traffic that leaves the device from any interface in the Internal zone. To inspect matching traffic for intrusions and malware, choose a rule action of Allow, then associate the rule with an intrusion and a file policy.
Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.
You can use predefined objects to build network conditions, or manually specify individual IP addresses or address blocks.
Note |
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal IP addresses to constrain this configuration can have unexpected results. Using override-enabled objects allows descendant domain administrators to tailor Global configurations to their local environments. |
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.
Some rules can match traffic using the geographical location of the source or destination. If a rule type supports geolocation, you can mix network and geolocation criteria. To ensure you are using up-to-date geolocation data to filter your traffic, Cisco strongly recommends you regularly update the geolocation database (GeoDB).
|
Rule Type |
Supports Geolocation Constraints? |
|---|---|
|
Access control |
yes |
|
SSL |
yes |
|
DNS (source networks only) |
no |
|
Identity |
yes |
|
Network analysis |
no |
|
Step 1 |
In the rule editor, click Networks. |
||
|
Step 2 |
Find and choose the predefined networks you want to add from the Available Networks list. If the rule supports geolocation, you can mix network and geolocation criteria in the same rule:
|
||
|
Step 3 |
Click Add to Source or Add to Destination, or drag and drop. |
||
|
Step 4 |
Add networks that you want to specify manually. Enter a source or destination IP address or address block, then click Add.
|
||
|
Step 5 |
Save or continue editing the rule. |
The following graphic shows the network condition for an access control rule that blocks connections originating from your internal network and attempting to access resources either in North Korea or on 93.184.216.119 (example.com).
In this example, a network object group called Private Networks (that comprises the IPv4 and IPv6 Private Networks network objects, not shown) represents your internal networks. The example also manually specifies the example.com IP address, and uses a system-provided North Korea geolocation object to represent North Korea IP addresses.
Deploy configuration changes; see Deploy Configuration Changes.
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.
Note the following Q-in-Q support:
NGIPSv, Firepower 7000, Firepower 8000—Supports Q-in-Q for all interface types.
ASA FirePOWER module—Does not support Q-in-Q (supports only one VLAN tag).
FTD on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).
FTD 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.
Note |
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal VLAN tags to constrain this configuration can have unexpected results. Using override-enabled objects allows descendant domain administrators to tailor Global configurations to their local environments. |
The folllowing rule types support VLAN conditions:
Access control
Note |
For FTD, VLAN tags in access rules only apply to inline sets; they cannot be used in access rules applied to firewall interfaces. |
SSL
DNS
Identity
Network analysis
Port conditions allow you to control traffic by its source and destination ports. Depending on the rule type, “port” can represent any of the following:
TCP and UDP—You can control TCP and UDP 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.
ICMP—You can control ICMP and ICMPv6 (IPv6-ICMP) traffic based on its internet layer protocol plus an optional type and code. For example: ICMP(1):3:3.
No port—You can control traffic using other protocols that do not use ports.
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.
Specifying ports is the traditional way to target applications. However, applications can be configured to use unique ports to bypass access control blocks. Thus, whenever possible, use application filtering criteria rather than port criteria to target traffic.
Application filtering is also recommended for applications, like FTP, that open separate channels dynamically for control vs. data flow. Using port-based access control rules can prevent these kinds of applications from performing correctly, and could result in blocking desirable connections.
If you add both source and destination port constraints, 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).
If you add only source ports or only destination ports, 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.
Although you can configure port conditions to match non-TCP traffic, there are some restrictions:
Access control rules—You can match GRE-encapsulated traffic with an access control rule by using the GRE (47) protocol as a destination port condition. To a GRE-constrained rule, you can add only network-based conditions: zone, IP address, port, and VLAN tag. Also, the system uses outer headers to match all traffic in access control policies with GRE-constrained rules.
SSL rules—SSL rules support TCP port conditions only.
Identity rules—The system cannot enforce active authentication on non-TCP traffic. If an identity rule action is Active Authentication or if you check the option to Use active authentication if passive authentication cannot identify user, use TCP ports constraints only. If the identity rule action is Passive Authentication or No Authentication, you can create port conditions based on non-TCP traffic.
Caution |
Adding the first or removing the last active authentication rule when SSL decryption is disabled (that is, when the access control policy does not include an SSL policy) restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information. Note that an active authentication rule has either an Active Authentication rule action, or a Passive Authentication rule action with Use active authentication if passive authentication cannot identify user selected. |
IMCP echo—A destination ICMP port with the type set to 0 or a destination ICMPv6 port with the type set to 129 only matches unsolicited echo replies. ICMP echo replies sent in response to ICMP echo requests are ignored. For a rule to match on any ICMP echo, use ICMP type 8 or ICMPv6 type 128.
The following rules support port conditions:
Access control
SSL (supports TCP traffic only)
Identity (active authentication supports TCP traffic only)
|
Step 1 |
In the rule editor, click Ports. |
|
Step 2 |
Find and choose the predefined ports you want to add from the Available Ports list. |
|
Step 3 |
Click Add to Source or Add to Destination, or drag and drop. |
|
Step 4 |
Add any source or destination ports that you want to specify manually:
|
|
Step 5 |
Save or continue editing the rule. |
Deploy configuration changes; see Deploy Configuration Changes.
When the system analyzes IP traffic, it can identify and classify the commonly used applications on your network. This discovery-based application awareness is the basis for application control—the ability to control application traffic.
System-provided application filters help you perform application control by organizing applications according to basic characteristics: type, risk, business relevance, category, and tags. You can create reuseable user-defined filters based on combinations of the system-provided filters, or on custom combinations of applications.
At least one detector must be enabled for each application rule condition in the policy. If no detector is enabled for an application, the system automatically enables all system-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application. For more information about application detectors, see Application Detector Fundamentals.
You can use both application filters and individually specified applications to ensure complete coverage. However, understand the following note before you order your access control rules.
Caution |
Failure to set up your access control rules properly can have unexpected results, including traffic being allowed that should be blocked. In general, application control rules should be lower in your access control list because it takes longer for those rules to match than rules based on IP address, for example. Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect (OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session, presentation, and application) should be ordered later in your access control rules. For more information about the OSI model, see this Wikipedia article. |
Application filters help you quickly configure application control. For example, you can easily use system-provided filters to create an access control rule that identifies and blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the system blocks the session.
Using application filters simplifies policy creation and administration. It assures you that the system controls application traffic as expected. Because Cisco frequently updates and adds application detectors via system and vulnerability database (VDB) updates, you can ensure that the system uses up-to-date detectors to monitor application traffic. You can also create your own detectors and assign characteristics to the applications they detect, automatically adding them to existing filters.
The configurations in the following table help you perform application control. The table also shows how you can constrain application control, depending on the configuration.
| Configuration |
Type, Risk, Relevance, Category |
Tags |
User-Defined Filters |
|---|---|---|---|
|
Access control rules |
yes |
yes |
yes |
|
SSL rules |
yes |
no; automatically constrained to encrypted application traffic by the SSL Protocol tag |
no |
|
Identity rules (to exempt applications from active authentication) |
yes |
no; automatically constrained by the User-Agent Exclusion tag |
no |
|
User-defined application filter in the object manager |
yes |
yes |
no; you cannot nest user-defined filters |
|
Intelligent Application Bypass (IAB) |
yes |
yes |
yes |
To build an application condition or filter, choose the applications whose traffic you want to control from a list of available applications. Optionally (and recommended), constrain the available applications using filters. You can use filters and individually specified applications in the same condition.
Adaptive profiling must be enabled as described in Configuring Adaptive Profiles for access control rules to perform application control.
For Classic device models, you must have the Control license to configure these conditions.
|
Step 1 |
Invoke the rule or configuration editor:
|
||
|
Step 2 |
Find and choose the applications you want to add from the Available Applications list. To constrain the applications displayed in Available Applications, choose one or more Application Filters or search for individual applications.
When you choose filters, singly or in combination, the Available Applications list updates to display only the applications that meet your criteria. You can choose system-provided filters in combination, but not user-defined filters.
|
||
|
Step 3 |
Click Add to Rule, or drag and drop.
|
||
|
Step 4 |
Save or continue editing the rule or configuration. |
The following graphic shows the application condition for an access control rule that blocks a user-defined application filter for MyCompany, all applications with high risk and low business relevance, gaming applications, and some individually selected applications.
Deploy configuration changes; see Deploy Configuration Changes.
The system characterizes each application that it detects using the criteria described in the following table. Use these characteristics as application filters.
|
Characteristic |
Description |
Example |
|---|---|---|
|
Type |
Application protocols represent communications between hosts. Clients represent software running on a host. Web applications represent the content or requested URL for HTTP traffic. |
HTTP and SSH are application protocols. Web browsers and email clients are clients. MPEG video and Facebook are web applications. |
|
Risk |
The likelihood that the application is being used for purposes that might be against your organization’s security policy. |
Peer-to-peer applications tend to have a very high risk. |
|
Business Relevance |
The likelihood that the application is being used within the context of your organization’s business operations, as opposed to recreationally. |
Gaming applications tend to have a very low business relevance. |
|
Category |
A general classification for the application that describes its most essential function. Each application belongs to at least one category. |
Facebook is in the social networking category. |
|
Tag |
Additional information about the application. Applications can have any number of tags, including none. |
Video streaming web applications often are tagged high bandwidth and displays ads. |
Keep in mind the following guidelines and limitations for application control:
If no detector is enabled for an application you want to detect, the system automatically enables all system-provided detectors for the application. If none exist, the system enables the most recently modified user-defined detector for the application.
The system cannot perform application control, including Intelligent Application Bypass (IAB), before both of the following occur:
A monitored connection is established between a client and server
The system identifies the application in the session
This identification should occur in 3 to 5 packets, or after the server certificate exchange in the SSL handshake if the traffic is encrypted.
Important! To ensure that your system examines these initial packets, see Specify a Policy to Handle Packets That Pass Before Traffic Identification.
If early traffic matches all other criteria but application identification is incomplete, the system allows the packet to pass and the connection to be established (or the SSL handshake to complete). After the system completes its identification, the system applies the appropriate action to the remaining session traffic.
Create separate rules for URL and application filtering whenever possible, because combining application and URL criteria can lead to unexpected results, especially for encrypted traffic.
Rules that include both application and URL criteria should come after application-only or URL-only rules, unless the application+URL rule is acting as an exception to a more general application-only or URL-only rule.
For the most effective URL matching, place rules that include URL conditions before other rules, particularly if the URL rules are block rules and the other rules meet both of the following criteria:
They include application conditions.
The traffic to be inspected is encrypted.
The system can identify and filter encrypted and decrypted traffic:
Encrypted traffic—The system can detect application traffic encrypted with StartTLS, including SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS ClientHello message, or the subject distinguished name value from the server certificate. These applications are tagged SSL Protocol; in an SSL rule, you can choose only these applications. Applications without this tag can only be detected in unencrypted or decrypted traffic.
Decrypted traffic—The system assigns the decrypted traffic tag to applications that the system can detect in decrypted traffic only, not encrypted or unencrypted.
In an identity policy, you can exempt certain applications from active authentication, allowing traffic to continue to access control. These applications are tagged User-Agent Exclusion. In an identity rule, you can choose only these applications.
When performing access control, the system applies the default policy action to packets that do not have a payload in a connection where an application is identified.
To handle traffic referred by a web server, such as advertisement traffic, match the referred application rather than the referring application.
Some applications use multiple protocols. To control their traffic, make sure your access control policy covers all relevant options. For example:
Skype—To control Skype traffic, choose the Skype tag from the Application Filters list rather than selecting individual applications. This ensures that the system can detect and control all Skype traffic the same way.
Zoho—To control Zoho mail, choose both Zoho and Zoho mail from the Available Application list.
The system supports Safe Search filtering for specific search engines only. The system assigns the safesearch supported tag to application traffic from these search engines.
For guidelines about rule ordering for application control, see Best Practices for Configuring Application Control.
We recommend controlling applications' access to the network as follows:
To allow or block application access from a less secure network to a more secure network: Use Port (Selected Destination Port) conditions on the access control rule
For example, allow ICMP traffic from the internet (less secure) to an internal network (more secure.)
To allow or block applications being accessed by user groups: Use Application conditions on the access control rule
For example, block Facebook from being accessed by members of the Contractors group
Caution |
Failure to set up your access control rules properly can have unexpected results, including traffic being allowed that should be blocked. In general, application control rules should be lower in your access control list because it takes longer for those rules to match than rules based on IP address, for example. Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect (OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session, presentation, and application) should be ordered later in your access control rules. For more information about the OSI model, see this Wikipedia article. |
The following table provides an example of how to set up your access control rules:
|
Type of control |
Action |
Zones, Networks, VLAN Tags |
Users |
Applications |
Ports |
URLs |
SGT/ISE Attributes |
Inspection, Logging, Comments |
|---|---|---|---|---|---|---|---|---|
|
Application from more secure to less secure network when application uses a port (for example, SSH) |
Your choice (Allow in this example) |
Destination zones or networks using the outside interface |
Any |
Do not set |
Available Ports : SSH Add to Selected Destination Ports |
Any |
Use only with ISE. |
Any |
|
Application from more secure to less secure network when application does not use a port (for example, ICMP) |
Your choice (Allow in this example) |
Destination zones or networks using the outside interface |
Any |
Do not set |
Selected Destination Ports Protocol: ICMP Type: Any |
Do not set |
Use only with ISE. |
Any |
|
Application access by a user group |
Your choice (Block in this example) |
Your choice |
Choose a user group (Contractors group in this example) |
Choose the name of the application ( Facebook in this example) |
Do not set |
Do not set |
Use only with ISE. |
Your choice |
Office 365 Admin Portal:
Limitation: If the access policy has logging enabled at the beginning as well as at the end, the first packet will be detected as Office 365 and the end of connection will be detected as Office 365 Admin Portal. This should not affect blocking.
Skype:
GoToMeeting
In order to fully detect GoToMeeting, your rule must include all of the following applications:
GoToMeeting
Citrix Online
Citrix GoToMeeting Platform
LogMeIn
STUN
Zoho:
Evasive applications such as Bittorrent, Tor, Psiphon, and Ultrasurf:
For evasive applications, only the highest-confidence scenarios are detected by default. If you need to take action on this traffic (such as block or implement QoS), it may be necessary to configure more aggressive detection with better effectiveness. To do this, contact TAC to review your configurations as these changes may result in false positives.
WeChat:
It is not possible to selectively block WeChat Media if you allow WeChat.
If your application control rules don't function as you expect, use the guidelines discussed in this section.
We recommend controlling applications' access to the network as follows:
To allow or block application access from a less secure network to a more secure network: Use Port (Selected Destination Port) conditions on the access control rule
For example, allow ICMP traffic from the internet (less secure) to an internal network (more secure.)
To allow or block applications being accessed by user groups: Use Application conditions on the access control rule
For example, block Facebook from being accessed by members of the Contractors group
Caution |
Failure to set up your access control rules properly can have unexpected results, including traffic being allowed that should be blocked. In general, application control rules should be lower in your access control list because it takes longer for those rules to match than rules based on IP address, for example. Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect (OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session, presentation, and application) should be ordered later in your access control rules. For more information about the OSI model, see this Wikipedia article. |
The following table provides an example of how to set up your access control rules:
|
Type of control |
Action |
Zones, Networks, VLAN Tags |
Users |
Applications |
Ports |
URLs |
SGT/ISE Attributes |
Inspection, Logging, Comments |
|---|---|---|---|---|---|---|---|---|
|
Application from more secure to less secure network when application uses a port (for example, SSH) |
Your choice (Allow in this example) |
Destination zones or networks using the outside interface |
Any |
Do not set |
Available Ports : SSH Add to Selected Destination Ports |
Any |
Use only with ISE. |
Any |
|
Application from more secure to less secure network when application does not use a port (for example, ICMP) |
Your choice (Allow in this example) |
Destination zones or networks using the outside interface |
Any |
Do not set |
Selected Destination Ports Protocol: ICMP Type: Any |
Do not set |
Use only with ISE. |
Any |
|
Application access by a user group |
Your choice (Block in this example) |
Your choice |
Choose a user group (Contractors group in this example) |
Choose the name of the application ( Facebook in this example) |
Do not set |
Do not set |
Use only with ISE. |
Your choice |
See Inspection of Packets That Pass Before Traffic Is Identified and subtopics.
Use URL conditions to control the websites that users on your network can access.
For complete information, see URL Filtering.
You can perform user control with the authoritative user identity data collected by the Firepower System.
Identity sources monitor users as they log in and out, or as they authenticate using Microsoft Active Directory (AD) or LDAP credentials. You can then configure rules that use this collected identity data to handle traffic based on the logged-in authoritative user associated with a monitored host. A user remains associated with a host until the user logs off (as reported by an identity source), a realm times out the session, or you delete the user data from the system's database.
For information on the authoritative user identity sources supported in your version of the Firepower System, see About User Identity Sources.
You can use the following rule conditions to perform user control:
User and realm conditions—Match traffic based on the logged-in authoritative user of a host. You can control traffic based on realms, individual users, or the groups those users belong to.
ISE attribute conditions—Match traffic based on a user's ISE-assigned Security Group Tag (SGT), Device Type (also referred to as Endpoint Profile), or Location IP (also referred to as Endpoint Location). Requires that you configure ISE as an identity source.
|
Rule Type |
Supports User and Realm Conditions? |
Supports ISE Attribute Conditions? |
|---|---|---|
|
Access control |
yes |
yes |
|
SSL |
yes |
no |
Configure identity sources for the types of authentication you want to perform. For more information, see About User Identity Sources.
If you configure an ISE or user agent 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, rules with realm, user, or user group conditions may not match traffic as expected.
Configure a realm for each AD or LDAP server you want to monitor, including your ISE or User Agent servers, and perform a user download. For more information, see Create a Realm.
When you configure a realm, you specify the users and user groups whose activity you want to monitor. Including a user group automatically includes all of that group’s members, including members of any secondary groups. However, if you want to use the secondary group as a rule criterion, you must explicitly include the secondary group in the realm configuration.
For each realm, you can enable automatic download of user data to refresh authoritative data for users and user groups.
Create an identity policy to associate the realm with an authentication method, and associate that policy with access control. For more information, see Create an Identity Policy.
Policies that perform user control on a device (access control, SSL) share an identity policy. That identity policy determines the realms, users, and groups that you can use in rules affecting traffic on those devices.
You can constrain a rule by realm, or by users and user groups within that realm.
Fulfill the user control prerequsities described in User, Realm, and ISE Attribute Conditions (User Control).
For Classic device models, you must have the Control license to configure these conditions.
|
Step 1 |
In the rule editor, click Users. |
|
Step 2 |
(Optional) Find and choose the realm you want to use from the Available Realms. |
|
Step 3 |
(Optional) Further constrain the rule by choosing users and groups from the Available Users list. |
|
Step 4 |
Click Add to Rule, or drag and drop. |
|
Step 5 |
Save or continue editing the rule. |
Deploy configuration changes; see Deploy Configuration Changes.
Fulfill the user control prerequisites described in User, Realm, and ISE Attribute Conditions (User Control).
For Classic device models, you must have the Control license to configure these conditions.
|
Step 1 |
In the rule editor, click ISE Attributes. |
|
Step 2 |
Find and choose the ISE attributes you want to use from the Available ISE Session Attributes list:
|
|
Step 3 |
Further constrain the rule by choosing attribute metadata from the Available ISE Metadata list. Or, keep the default: any. |
|
Step 4 |
Click Add to Rule, or drag and drop. |
|
Step 5 |
(Optional) Constrain the rule with an IP address in the Add a Location IP Address field, then click Add. The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal IP addresses to constrain this configuration can have unexpected results. |
|
Step 6 |
Save or continue editing the rule. |
Deploy configuration changes; see Deploy Configuration Changes.
If you notice unexpected user rule behavior, consider tuning your rule, identity source, or realm configurations. For other related troubleshooting information, see:
If you configure an ISE or user agent device to monitor a large number of user groups, or if you have a very large number of users mapped to hosts on your network, the system may drop user records due to your Firepower Management Center user limit. As a result, rules with user conditions may not match traffic as expected.
If you configure a rule with a user group condition, your LDAP or Active Directory server must have user groups configured. The system cannot perform user group control if the server organizes the users in basic object hierarchy.
If you configure a rule with a user group condition that includes or excludes users who are members of a secondary group on your Active Directory server, your server may be limiting the number of users it reports.
By default, Active Directory servers limit the number of users they report from secondary groups. You must customize this limit so that all of the users in your secondary groups are reported to the Firepower Management Center and eligible for use in rules with user conditions.
After the system detects activity from a previously-unseen user, the system retrieves information about them from the server. Until the system successfully retrieves this information, activity seen by this user is not handled by matching rules. Instead, the user session is handled by the next rule it matches (or the policy's default action, if applicable).
For example, this might explain when:
Users who are members of user groups are not matching rules with user group conditions.
Users who were reported by a , user agent, or ISE device are not matching rules, when the server used for user data retrieval is an Active Directory server.
Note that this might also cause the system to delay the display of user data in event views and analysis tools.
This is expected behavior. You can perform user control on ISE users who were authenticated by an Active Directory domain controller. You cannot perform user control on ISE users who were authenticated by an LDAP, RADIUS, or RSA domain controller.
In many policies, you can search for and within rules. The system matches your input to rule names and condition values, including objects and object groups.
You cannot search for values in a Security Intelligence or URL list or feed.|
Step 1 |
In the policy editor, click Rules. |
|
Step 2 |
Click Search Rules, enter a complete or partial search string, then press Enter. |
|
Step 3 |
View the rules you are interested in. To navigate between matching rules, click Next-Match or Previous-Match . |
Before you begin a new search, click Clear () to clear the search and any highlighting.
Some policy editors allow you to filter your rule view by affected devices.
Filter by device only works for rules that use zones or interface groups. (Otherwise a rule applies to all devices.)
The system uses a rule's interface constraints to determine if the rule affects a device. If you constrain a rule by interface (security zone condition), the device where that interface is located is affected by that rule. Rules with no interface constraint apply to any interface, and therefore every device.
|
Step 1 |
In the policy editor, click Rules, then click Filter by Device. |
||
|
Step 2 |
Check one or more check boxes to display only the rules that apply to those devices or groups. Or, check All to reset and display all of the rules.
|
||
|
Step 3 |
Click OK. |
Policy and rule editors use icons to mark configurations that could adversely affect traffic analysis and flow. Depending on the issue, the system may warn you when you deploy or prevent you from deploying entirely.
Tip |
Hover your pointer over an icon to read the warning, error, or informational text. |
|
Icon |
Description |
Example |
|---|---|---|
 )error |
If a rule or configuration has an error, you cannot deploy until you correct the issue, even if you disable any affected rules. |
A rule that performs category and reputation-based URL filtering is valid until you target a device that does not have a URL Filtering license. At that point, an error icon appears next to the rule, and you cannot deploy until you edit or delete the rule, retarget the policy, or enable the license. |
 )warning |
You can deploy a policy that displays rule or other warnings. However, misconfigurations marked with warnings have no effect. If you disable a rule with a warning, the warning icon disappears. It reappears if you enable the rule without correcting the underlying issue. |
Preempted rules or rules that cannot match traffic due to misconfiguration have no effect. This includes conditions using empty object groups, application filters that match no applications, excluded LDAP users, invalid ports, and so on. However, if a warning icon marks a licensing error or model mismatch, you cannot deploy until you correct the issue. |
 )information |
Information icons convey helpful information about configurations that may affect the flow of traffic. These issues do not prevent you from deploying. |
With application control, the system might skip matching the first few packets of a connection against some rules, until the system identifies the application or web traffic in that connection. This allows connections to be established so that applications and HTTP requests can be identified. |
Feedback