Reusable ObjectsThe following topics describe how to manage reusable objects in the Firepower System: Show
Introduction to Reusable ObjectsFor increased flexibility and web interface ease-of-use, the Firepower System uses named objects, which are reusable configurations that associate a name with a value. When you want to use that value, use the named object instead. The system supports object use in various places in the web interface, including many policies and rules, event searches, reports, dashboards, and so on. The system provides many predefined objects that represent frequently used configurations. Use the object manager to create and manage objects. Many configurations that use objects also allow you to create objects on the fly, as needed. You can also use the object manager to:
After you edit an object used in an active policy, you must redeploy the changed configuration for your changes to take effect. You cannot delete an object that is in use by an active policy.
Object TypesThe following table lists the objects you can create in the Firepower System, and indicates whether each object type can be grouped or configured to allow overrides.
Objects and MultitenancyIn a multidomain deployment, you can create objects in Global and descendant domains with the exception of Security Group Tag (SGT) objects, which you can create only in the Global domain. The system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which you cannot edit, with the exception of security zones and interface groups.
Object names must be unique within the domain hierarchy. The system may identify a conflict with the name of an object you cannot view in your current domain. For objects that support grouping, you can group objects in the current domain with objects inherited from ancestor domains. Object overrides allow you to define device-specific or domain-specific values for certain types of object, including network, port, VLAN tag, and URL. In a multidomain deployment, you can define a default value for an object in an ancestor domain, but allow administrators in descendant domains to add override values for that object. The Object ManagerYou can use the object manager to create and manage objects and object groups. The object manager displays 20 objects or groups per page. If you have more than 20 of any type of object or group, use the navigation links at the bottom of the page to view additional pages. You can also go to a specific page or click Refresh ( By default, the page lists objects and groups alphabetically by name. You can filter the objects on the page by name or value. Importing ObjectsObjects can be imported from a comma-separated values file. Up to 1000 objects can be imported in one attempt. The contents of the comma-separated values file should follow a specific format. The format is different for each object type. Only a few types of objects can be imported. See the following table to know the supported object types and the corresponding rules.
Procedure
Editing ObjectsIn a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Viewing Objects and Their UsageYou can view usage details of objects on the Object Management page. Firepower Management Center provides this functionality for many object types. However, some object types are not supported.
Procedure
Filtering Objects or Object GroupsIn a multidomain deployment, the system displays objects created in the current and ancestor domains, which you can filter. Procedure
Object GroupsGrouping objects allows you to reference multiple objects with a single configuration. The system allows you to use objects and object groups interchangeably in the web interface. For example, anywhere you would use a port object, you can also use a port object group. You can group network, port, VLAN tag, URL, and PKI objects. Network object groups can be nested, that is, you can add a network object group to another network object group up to 10 levels. Objects and object groups of the same type cannot have the same name. In a multidomain deployment, the names of object groups must be unique within the domain hierarchy. Note that the system may identify a conflict with the name of an object group you cannot view in your current domain. When you edit an object group used in a policy (for example, a network object group used in an access control policy), you must re-deploy the changed configuration for your changes to take effect. Deleting a group does not delete the objects in the group, just their association with each other. Additionally, you cannot delete a group that is in use in an active policy. For example, you cannot delete a VLAN tag group that you are using in a VLAN condition in a saved access control policy. Grouping Reusable ObjectsIn a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. You can group objects in the current domain with objects inherited from ancestor domains. Procedure
What to do next
Object OverridesAn object override allows you to define an alternate value for an object, which the system uses for the devices you specify. You can create an object whose definition works for most devices, and then use overrides to specify modifications to the object for the few devices that need different definitions. You can also create an object that needs to be overridden for all devices, but its use allows you to create a single policy for all devices. Object overrides allow you to create a smaller set of shared policies for use across devices without giving up the ability to alter policies when needed for individual devices. For example, you might want to deny ICMP traffic to the different departments in your company, each of which is connected to a different network. You can do this by defining an access control policy with a rule that includes a network object called Departmental Network. By allowing overrides for this object, you can then create overrides on each relevant device that specifies the actual network where that device is connected. In a multidomain deployment, you can define a default value for an object in an ancestor domain and allow administrators in descendant domains to add override values for that object. For example, a managed security service provider (MSSP) might use a single Firepower Management Center to manage network security for multiple customers. Administrators at the MSSP can define an object in the Global domain for use in all customers' deployments. Administrators for each customer can log into descendant domains to override that object for their organizations. These local administrators cannot view or affect the override values of other customers of the MSSP. You can target an object override to a specific domain. In this case, the system uses the object override value for all devices in the targeted domain unless you override it at the device level. From the object manager, you can choose an object that can be overridden and define a list of device-level or domain-level overrides for that object. You can use object overrides with the following object types only:
If you can override an object, the Override column appears for the object type in the object manager. Possible values for this column include:
Managing Object OverridesProcedure
Allowing Object OverridesProcedure
What to do nextAdd object override values; see Adding Object Overrides. Adding Object OverridesBefore you beginAllow object overrides; see Allowing Object Overrides. Procedure
What to do next
Editing Object OverridesYou can modify the description and the value of an existing override, but you cannot modify the existing target list. Instead, you must add a new override with new targets, which replaces the existing override. Procedure
What to do next
Network ObjectsA network object represents one or more IP addresses. You can use network objects and groups in various places in the system’s web interface, including access control policies, network variables, identity rules, network discovery rules, event searches, reports, identity policies, and so on. When you configure an option that requires a network object, the list is automatically filtered to show only those objects that are valid for the option. For example, some options require host objects, while other options require subnets. A network object can be one of the following types: HostA single IP address. IPv4 example:
IPv6 example:
A range of IP addresses. IPv4 example:
IPv6 example:
An address block, also known as a subnet. IPv4 example:
IPv6 example:
A single fully-qualified domain name (FQDN). FQDN resolution in only IPv4 address, only IPv6 address, and both IPv4 and IPv6 addresses are supported. For example:
A group of network objects or other network object groups. For example:
You can create nested groups by adding one network object group to another network object group. You can nest up to 10 levels of groups. Creating Network ObjectsProcedure
What to do next
Importing Network ObjectsFor details on importing network objects, see Importing Objects. Port ObjectsPort objects represent different protocols in slightly different ways: TCP and UDPA port object represents the transport layer protocol, with the protocol number in parentheses, plus an optional associated port or port range. For example: A port object represents the Internet layer protocol plus an optional type and code. For example: You can restrict an ICMP or IPV6-ICMP port object by type and, if applicable, code. For more information on ICMP types and codes, see:
A port object can represent other protocols that do not use ports. The Firepower System provides default port objects for well-known ports. You cannot modify or delete these default objects. You can create custom port objects in addition to the default objects. You can use port objects and groups in various places in the system’s web interface, including access control policies, identity rules, network discovery rules, port variables, and event searches. For example, if your organization uses a custom client that uses a specific range of ports and causes the system to generate excessive and misleading events, you can configure your network discovery policy to exclude monitoring those ports. When using port objects, observe the following guidelines:
Creating Port ObjectsProcedure
What to do next
Importing Port ObjectsFor details on importing port objects, see Importing Objects. Tunnel ZonesA tunnel zone represents certain types of plaintext, passthrough tunnels that you explicitly tag for special analysis. A tunnel zone is not an interface object, even though you can use it as an interface constraint in some configurations. For detailed information, see Tunnel Zones and Prefiltering. Application FiltersSystem-provided application filters help you perform application control by organizing applications according to basic characteristics: type, risk, business relevance, category, and tags. In the object manager, you can create and manage reuseable user-defined application filters based on combinations of the system-provided filters, or on custom combinations of applications. For detailed information, see Application Conditions (Application Control). VLAN Tag ObjectsEach VLAN tag object you configure represents a VLAN tag or range of tags. You can group VLAN tag objects. Groups represent multiple objects; using a range of VLAN tags in a single object is not considered a group in this sense. You can use VLAN tag objects and groups in various places in the system’s web interface, including rules and event searches. For example, you could write an access control rule that applies only to a specific VLAN. Creating VLAN Tag ObjectsProcedure
What to do next
Security Group Tag ObjectsA Security Group Tag (SGT) object specifies a single SGT value. You can use SGT objects in rules to control traffic with SGT attributes that were not assigned by Cisco ISE. You cannot group or override SGT objects. Creating Security Group Tag ObjectsYou can create these objects in the global domain only. To use the object on Classic devices, you must have the Control license. For Smart Licensed devices, any license will do. Before you begin
Procedure
What to do next
URL Objects
A URL object defines a single URL or IP address, whereas a URL group object can define more than one URL or address. You can use URL objects and groups in various places in the system’s web interface, including access control policies and event searches. When creating URL objects, keep the following points in mind:
Creating URL ObjectsProcedure
What to do next
Geolocation ObjectsEach geolocation object you configure represents one or more countries or continents that the system has identified as the source or destination of traffic on your monitored network. You can use geolocation objects in various places in the system’s web interface, including access control policies, SSL policies, and event searches. For example, you could write an access control rule that blocks traffic to or from certain countries. To ensure that you are using up-to-date information to filter your network traffic, Cisco strongly recommends that you regularly update your Geolocation Database (GeoDB). Creating Geolocation ObjectsProcedure
What to do next
Interface Objects: Interface Groups and Security ZonesInterface objects segment your network to help you manage and classify traffic flow. An interface object simply groups interfaces. These groups may span multiple devices; you can also configure multiple interface objects on a single device. There are two types of interface objects:
Although tunnel zones are not interface objects, you can use them in place of security zones in certain configurations; see Tunnel Zones and Prefiltering. All interfaces in an interface object must be of the same type: all inline, passive, switched, routed, or ASA FirePOWER. After you create an interface object, you cannot change the type of interfaces it contains. The Interface Objects page of the object manager lists the security zones and interface groups configured on your managed devices. The page also displays the type of interfaces in each interface object, and you can expand each interface object to view which interfaces on which devices belong to each object.
Interface Objects and MultitenancyIn a multidomain deployment, you can create interface objects at any level. An interface object created in an ancestor domain can contain interfaces that reside on devices in different domains. In this situation, subdomain users viewing the ancestor interface object configuration in the object manager can see only the interfaces in their domain. Unless restricted by role, subdomain users can view and edit interface objects created in ancestor domains. Subdomain users can add and delete interfaces from these interface objects. They cannot, however, delete or rename the interface objects. You can neither view nor edit interface objects created in descendant domains. Creating Security Zone and Interface Group Objects
Before you begin
Procedure
What to do next
Time Range ObjectsUse time range objects to define time periods that you will use to determine when rules apply.
Creating Time Range ObjectsIf you want a policy to apply only during a specified time range, create a time range object, then specify that object in the policy. Note that this object works on FTD devices only. You can specify time range objects only in policy types listed at the bottom of this topic.
Before you beginTime ranges are applied based on the time zone associated with the device that processes the traffic. By default, this is UTC. To change the time zone associated with a device, go to Device > Platform Settings. Procedure
What to do nextConfigure time ranges in any of the following:
In a VPN group policy object, specify the time range object using the Access Hours field. For details, see Configure Group Policy Objects and Group Policy Advanced Options. Time Zone ObjectTo specify a local time zone for a managed device, create a time zone object and specify it in the device platform settings policy assigned to the device. This device local time is used ONLY for applying time ranges in rules in policies that support time ranges, such as access control, prefilter, and VPN Group policies. If you do not assign a time zone to a device, UTC is used by default when applying time ranges in these policies. No other functionality in the Firepower system uses the time zone specified in a time zone object. Time zone objects are supported only for Firepower Threat Defense devices.
Variable SetsVariables represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions, adaptive profile updates, and dynamic rule states.
You use variable sets to manage, customize, and group your variables. You can use the default variable set provided by the system or create your own custom sets. Within any set you can modify predefined default variables and add and modify user-defined variables. Most of the shared object rules and standard text rules that the Firepower System provides use predefined default variables to
define networks and port numbers. For example, the majority of the rules use the variable Rules are more effective when variables more accurately reflect your network
environment. At a minimum, you should modify default variables in the default set. By ensuring that a variable such as To use your variables, you link variable sets to intrusion policies associated with access control rules or with the default action of an access control policy. By default, the default variable set is linked to all intrusion policies used by access control policies. Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all variables currently configured on your system. Within any variable set, you can add user-defined variables and customize the value of any variable. Initially, the Firepower System provides a single, default variable set comprised of predefined default values. Each variable in the default set is initially set to its default value, which for a predefined variable is the value set by the Cisco Talos Intelligence Group (Talos) and provided in rule updates. Although you can leave predefined default variables configured to their default values, Cisco recommends that you modify a subset of predefined variables. You could work with variables only in the default set, but in many cases you can benefit most by adding one or more custom sets, configuring different variable values in different sets, and perhaps even adding new variables. When using multiple sets, it is important to remember that the current value of any variable in the default set determines the default value of the variable in all other sets. When you select Variable Sets on the Object Manager page, the object manager lists the default variable set and any custom sets you created. On a freshly installed system, the default variable set is comprised only of the default variables predefined by Cisco. Each variable set includes the default variables provided by the system and all custom variables you have added from any variable set. Note that you can edit the default set, but you cannot rename or delete the default set. In a multidomain deployment, the system generates a default variable set for each subdomain.
Variable Sets in Intrusion PoliciesBy default, the Firepower System links the default variable set to all intrusion policies used in an access control policy. When you deploy an access control policy that uses an intrusion policy, intrusion rules that you have enabled in the intrusion policy use the variable values in the linked variable set. When you modify a custom variable set used by an intrusion policy in an access control policy, the system reflects the status for that policy as out-of-date on the Access Control Policy page. You must re-deploy the access control policy to implement changes in your variable set. When you modify the default set, the system reflects the status of all access control policies that use intrusion policies as out-of-date, and you must re-deploy all access control policies to implement your changes. VariablesVariables belong to one of the following categories: Default VariablesVariables provided by the Firepower System. You cannot rename or delete a default variable, and you cannot change its default value. However, you can create a customized version of a default variable. Customized VariablesVariables you create. These variables can include:
For example, if you create custom standard text rules, you might also want to add your own user-defined variables to
more accurately reflect your traffic or as shortcuts to simplify the rule creation process. Alternatively, if you create a rule that you want to inspect traffic in the “demilitarized zone” (or DMZ) only, you can create a variable named Variables provided by the Firepower System under specific conditions. These variables have a very limited deployment. Predefined Default VariablesBy default, the Firepower System provides a single default variable set, which is comprised of predefined default variables. The Cisco Talos Intelligence Group (Talos) uses rule updates to provide new and updated intrusion rules and other intrusion policy elements, including default variables. Because many intrusion rules provided by the system use predefined default variables, you should set appropriate values for these variables. Depending on how you use variable sets to identify traffic on your network, you can modify the values for these default variables in any or all variable sets.
The following table describes the variables provided by the system and indicates which variables you typically would modify. For assistance determining how to tailor variables to your network, contact Professional Services or Support. Table 1. System-Provided Variables
Network VariablesNetwork variables represent IP addresses you can use in intrusion rules that you enable in an intrusion policy and in intrusion policy rule suppressions, dynamic rule states, and adaptive profile updates. Network variables differ from network objects and network object groups in that network variables are specific to intrusion policies and intrusion rules, whereas you can use network objects and groups to represent IP addresses in various places in the system’s web interface, including access control policies, network variables, intrusion rules, network discovery rules, event searches, reports, and so on. You can use network variables in the following configurations to specify the IP addresses of hosts on your network:
When you use variables in the fields identified in this section, the variable set you link to an intrusion policy determines the variable values in the network traffic handled by an access control policy that uses the intrusion policy. You can add any combination of the following network configurations to a variable:
The default value for included networks in any variable you add is the word 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 You can exclude any combination of networks using literal or available networks. For example, excluding the literal values Note the following points when adding or editing network variables:
Port VariablesPort variables represent TCP and UDP ports you can use in the Source Port and Destination Port header fields in intrusion rules that you enable in an intrusion policy. Port variables differ from port objects and port object groups in that port variables are specific to intrusion rules. You can create port objects for protocols other than TCP and UDP, and you can use port objects in various places in the system’s web interface, including port variables, access control policies, network discovery rules, and event searches. You can use port variables in the intrusion rule Source Port and Destination Port header fields to restrict packet inspection to packets originating from or destined to specific TCP or UDP ports. When you use variables in these fields, the variable set you link to the intrusion policy associated with an access control rule or policy determines the values for these variables in the network traffic where you deploy the access control policy. You can add any combination of the following port configurations to a variable:
Note the following points when adding or editing port variables:
Advanced VariablesAdvanced variables allow you to configure features that you cannot otherwise configure via the web interface. The Firepower System currently provides only only one advanced variable, the USER_CONF variable. USER_CONFUSER_CONF provides a general tool that allows you to configure one or more features not otherwise available via the web interface.
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. Variable ResetYou 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. Table 2. Variable Reset Values
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.
You can hover your pointer over the Reset icon in a variable set to see the reset value. When the customized value and the reset value are the same, this indicates one of the following:
Adding Variables to SetsAdding a variable to a variable set adds it to all other sets. 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:
Example: Adding User-Defined Variables to Default SetsThe following diagram illustrates set interactions when you add the user-defined variable  You can customize the value of It is important to note in this example that, if you do not update Although not shown in the example, note that interactions between sets are the same for user-defined variables and default variables except that resetting a default variable in the default set resets it to the value configured by Cisco in the current rule update. Example: Adding User-Defined Variables to Custom SetsThe next two examples illustrate variable set interactions when you add a user-defined variable to a custom set. When you save the new variable, you are prompted whether to use the configured value as the default value for other sets. In the following example, you elect to use the configured value. Note that, except for the origin of In the next example, you add This approach adds Nesting VariablesYou can nest variables so long as the nesting is not circular. Nested, negated variables are not supported. Valid Nested VariablesIn this example, SMTP_SERVERS, HTTP_SERVERS, and OTHER_SERVERS are valid nested variables.
An Invalid Nested VariableIn this example, HOME_NET is an invalid nested variable because the nesting of HOME_NET is circular; that is, the definition of OTHER_SERVERS includes HOME_NET, so you would be nesting HOME_NET in itself.
An Unsupported Nested, Negated VariableBecause nested, negated variables are not supported, you cannot use the variable NONCORE_NET as shown in this example to represent IP addresses that are outside of your protected networks.
Alternative to an Unsupported Nested, Negated VariableAs an alternative to the example above, you could represent IP addresses that are outside of your protected networks by creating the variable NONCORE_NET as shown in this example.
Managing Variable SetsTo use variable sets, you must have the Threat license (for FTD devices) or the Protection license (all other device types). In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
Creating Variable SetsProcedure
What to do next
Managing VariablesYou must have the Threat license (for FTD devices) or the Protection license (all other device types). In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Adding VariablesYou must have the Threat license (for FTD devices) or the Protection license (all other device types). Procedure
What to do next
Editing VariablesYou must have the Threat license (for FTD devices) or the Protection license (all other device types). In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. You can edit both custom and default variables. You cannot change the Name or Type values in an existing variable. Procedure
What to do next
Security Intelligence Lists and FeedsSecurity Intelligence functionality requires the Threat license (for FTD devices) or the Protection license (all other device types). Security Intelligence lists and feeds are collections of IP addresses, domain names, and URLs that you can use to quickly filter traffic that matches an entry on a list or feed.
Security Intelligence lists/feeds are grouped into:
System-Provided FeedsCisco provides the following feeds as Security Intelligence objects:
Predefined Lists: Global Block Lists and Global Do Not Block ListsThe system ships with predefined global Block lists and Do Not Block lists for domains (DNS), IP addresses (Networks), and URLs. These lists are empty until you populate them. To build these lists, see Global and Domain Security Intelligence Lists. By default, access control and DNS policies use these lists as part of Security Intelligence. Custom FeedsYou can use third-party feeds, or use a custom internal feed to easily maintain an enterprise-wide Block list in a large deployment with multiple Firepower Management Center appliances. See Custom Security Intelligence Feeds. Custom ListsCustom lists can augment and fine-tune feeds and the Global lists. See Custom Security Intelligence Lists. Where Security Intelligence Lists and Feeds Are Used
How to Modify Security Intelligence ObjectsTo add or delete entries on a Block list, Do Not Block list, feed, or sinkhole object:
Global and Domain Security Intelligence ListsFirepower Management Center ships with empty Global Block and Do-Not-Block lists to which you can instantly add URLs, domains, and IP addresses from events on your network at any time. These lists allow you to use Security Intelligence to always block particular connections, or to exempt particular connections from blocking by Security Intelligence, allowing them to be evaluated by other threat detection processes that you have configured. For example, if you notice a set of routable IP addresses in intrusion events associated with exploit attempts, you can immediately block those IP addresses. Although it may take a few minutes for your changes to propagate, you do not have to redeploy. By default, Access control and DNS policies use these Global lists, which apply to all security zones. You can opt not to use these lists on a per-policy basis.
In a multidomain deployment, you can choose the Firepower System domains where you want to enforce blocking, or exempting from Security Intelligence blocking, by adding items to Domain lists as well as the Global lists; see Security Intelligence Lists and Multitenancy. Security Intelligence Lists and MultitenancyIn a multidomain deployment, the Global domain owns the Global Block lists and Do Not Block lists. Only Global administrators can add to or remove items from the Global lists. So that subdomain users can add networks, domain names, and URLs to Block and Do Not Block lists, multitenancy adds:
Domain ListsIn addition to being able to access (but not edit) the Global lists, each subdomain has its own named lists, the contents of which apply only to that subdomain. For example, a subdomain named Company A owns:
Any administrator at or above the current domain can populate these lists. You can use the context menu to add an item to the Block or Do Not Block list in the current and all descendant domains. However, only an administrator in the associated domain can remove an item from a Domain list. For example, a Global administrator could choose to add the same IP address to the Block list in the Global domain and Company A’s domain, but not add it to the Block list in Company B’s domain. This action would add the same IP address to:
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. Descendant Domain ListsA Descendant Domain list is a Do Not Block list or Block list that aggregates the Domain lists of the current domain’s descendants. Leaf domains do not have Descendant Domain lists. Descendant Domain lists are useful because a higher-level domain administrator can enforce general Security Intelligence settings, while still allowing subdomain users to add items to a Block or Do Not Block list in their own deployment. For example, the Global domain has the following Descendant Domain lists:
Add Entries to Global Security Intelligence ListsWhen reviewing events and dashboards, you can instantly block future traffic involving IP addresses, domains, and URLs that appear in those events by adding them to a predefined Block list. Similarly, if Security Intelligence is blocking traffic that you want evaluated by threat detection processes subsequent to Security Intelligence blocking, you can add IP addresses, domains, and URLs from events to a predefined Do Not Block list. Traffic is evaluated against entries on these lists during the Security Intelligence phase of threat detection. For more information about these lists, see Global and Domain Security Intelligence Lists. Before you beginBecause adding an entry to a Security Intelligence list affects access control, you must have one of the following user roles:
If appropriate, verify that these lists are used in the policies in which you expect them to be used. Procedure
What to do nextYou do NOT need to redeploy for these changes to take effect. If you want to delete an item from a list, see Delete Entries from Global Security Intelligence Lists. Delete Entries from Global Security Intelligence Lists
Procedure
List and Feed Updates for Security IntelligenceList and feed updates replace the existing list or feed file with the contents of the new file. Contents of existing and new files are not merged. If the system downloads a corrupt feed or a feed with no recognizable entries, the system continues using the old feed data (unless it is the first download). However, if the system can recognize even one entry in the feed, it uses the entries it can recognize. By default, each feed updates the Management Center every two hours; you can modify this frequency. Any updates the Management Center receives are passed immediately to managed devices. In addition, managed devices poll the FMC every 30 minutes for changes. You cannot modify this frequency. In a multidomain deployment, the system-provided feeds belong to the Global domain and can be modified only by an administrator in that domain. You can modify the update frequency for custom feeds belonging to your domain. To modify feed update intervals, see Changing the Update Frequency for Security Intelligence Feeds. Changing the Update Frequency for Security Intelligence FeedsYou can specify the intervals at which the Firepower Management Center updates Security Intelligence Feeds. For details about feed updates, see List and Feed Updates for Security Intelligence. Procedure
Custom Security Intelligence Lists and FeedsCustom Lists and Feeds: RequirementsList and Feed FormattingEach list or feed must be a simple text file no larger than 500MB. List files must have the .txt extension. Include one entry or comment per line: one IP address, one URL, one domain name.
In a DNS list entry, you can specify an asterisk ( If you add comment lines within the source file, they must start with the pound ( Feed RequirementsWhen you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded. For feed update intervals of 30 minutes or less, you must specify an MD5 URL. This prevents frequent downloads of unchanged feeds. If your feed server does not provide an MD5 URL, you must use a download interval of at least 30 minutes. If you use an MD5 checksum, the checksum must be stored in a simple text file with only the checksum. Comments are not supported. URL Lists and Feeds: URL Syntax and Matching CriteriaSecurity Intelligence URL lists and feeds, including custom lists and feeds and entries in the global Block list and Do Not Block list, can include the following, which have the matching behavior as described:
See also Custom Security Intelligence Lists. Custom Security Intelligence FeedsCustom or third-party Security Intelligence feeds allow you to augment the system-provided Intelligence Feeds with other regularly-updated reputable Block lists and Do Not Block lists on the Internet. You can also set up an internal feed, which is useful if you want to update multiple Firepower Management Center appliances in your deployment using one source list.
You also can configure the system to use an MD5 checksum to determine whether to download an updated feed. If the checksum has not changed since the last time the system downloaded the feed, the system does not need to re-download it. You may want to use MD5 checksums for internal feeds, especially if they are large.
If you want strict control over when the system updates a feed from the Internet, you can disable automatic updates for that feed. However, automatic updates ensure the most up-to-date, relevant data. Manually updating Security Intelligence feeds updates all feeds, including the Intelligence Feeds. See complete requirements at Custom Lists and Feeds: Requirements. Creating Security Intelligence FeedsYou must have the Threat license (for FTD devices) or the Protection license (all other device types).
Manually Updating Security Intelligence FeedsYou must have the Threat license (for FTD devices) or the Protection license (all other device types). At least one device must already be added to the management center.
Custom Security Intelligence ListsSecurity Intelligence lists are simple static lists of IP addresses and address blocks, URLs, or domain names that you manually upload to the system. Custom lists are useful if you want to augment and fine-tune feeds or one of the global lists, for a single Firepower Management Center’s managed devices. For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your organization, you can create a custom Do Not Block list that contains only the improperly classified IP addresses, rather than removing the IP address feed object from the access control policy’s Block list.
Regarding list entry formatting, note the following:
Regarding matching list entries, note the following:
Uploading New Security Intelligence Lists to the Firepower Management CenterTo modify a Security Intelligence list, you must make your changes to the source file and upload a new copy. You cannot modify the file’s contents using the web interface. If you do not have access to the source file, download a copy from the system.
You do not need to redeploy these changes to take effect. If you want to delete an entry from the list, see Delete Entries from Global Security Intelligence Lists. Updating Security Intelligence ListsIn a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain.
You do not need to redeploy these changes to take effect. If you want to delete an entry from the list, see Delete Entries from Global Security Intelligence Lists. Sinkhole ObjectsA sinkhole object represents either a DNS server that gives non-routeable addresses for all domain names within the sinkhole, or an IP address that does not resolve to a server. You can reference the sinkhole object within a DNS policy rule to redirect matching traffic to the sinkhole. You must assign the object both an IPv4 address and an IPv6 address. Creating Sinkhole ObjectsYou must have the Threat license (for FTD devices) or the Protection license (all other device types). Procedure
File ListsIf you use AMP for Networks, and the AMP cloud incorrectly identifies a file’s disposition, you can add the file to a file list to better detect the file in the future. These files are specified using SHA-256 hash values. Each file list can contain up to 10000 unique SHA-256 values. There are two predefined categories of file lists: Clean ListIf you add a file to this list, the system treats it as if the AMP cloud assigned a clean disposition. Custom Detection ListIf you add a file to this list, the system treats it as if the AMP cloud assigned a malware disposition. In a multidomain deployment, a clean list and custom detection list is present for each domain. In lower-level domains, you can view but not modify ancestor's lists. Because you manually specify the blocking behavior for the files included in these lists, the system does not query the AMP cloud for these files’ dispositions. You must configure a rule in the file policy with either a Malware Cloud Lookup or Block Malware action and a matching file type to calculate a file’s SHA value.
Source Files for File ListsYou can add multiple SHA-256 values to a file list by uploading a comma-separated value (CSV) source file containing a list of SHA-256 values and descriptions. The Firepower Management Center validates the contents and populates the file list with valid SHA-256 values. The source file must be a simple text file with a .csv file name extension. Any header must start with a pound sign ( Note the following:
Adding Individual SHA-256 Values to File ListsYou must have the Malware license for this procedure. You can submit a file’s SHA-256 value to add it to a file list. You cannot add duplicate SHA-256 values. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Before you begin
Procedure
What to do next
Uploading Individual Files to File ListsYou must have the Malware license for this procedure. If you have a copy of the file you want to add to a file list, you can upload the file to the Firepower Management Center for analysis; the system calculates the file’s SHA-256 value and adds the file to the list. The system does not enforce a limit on the size of files for SHA-256 calculation. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Uploading Source Files to File ListsYou must have the Malware license for this procedure. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Editing SHA-256 Values in File ListsYou must have the Malware license for this procedure. You can edit or delete individual SHA-256 values on a file list. Note that you cannot directly edit a source file within the object manager. To make changes, you must first modify your source file directly, delete the copy on the system, then upload the modified source file. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Downloading Source Files from File ListsYou must have the Malware license for this procedure. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
Cipher Suite ListsA cipher suite list is an object comprised of several cipher suites. Each predefined cipher suite value represents a cipher suite used to negotiate an SSL- or TLS-encrypted session. You can use cipher suites and cipher suite lists in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session using that cipher suite. If you add a cipher suite list to an SSL rule, SSL sessions negotiated with any of the cipher suites in the list match the rule.
Creating Cipher Suite ListsYou can use these objects with any device type except NGIPSv. Procedure
What to do next
Distinguished Name ObjectsEach distinguished name object represents the distinguished name for a public key certificate’s subject or issuer. You can use distinguished name objects and groups in TLS/SSL rules to control encrypted traffic based on whether the client and server negotiated the TLS/SSL session using a server certificate with the distinguished name as subject or issuer. (A distinguished name group is a named collection of existing distinguished name objects.) The distinguished name can consist of country code, common name, organization, and organizational unit, but typically consists of a common name only. For example, the common name in the certificate for The format of a distginguished name object that references a common name is As discussed further in Distinguished Name (DN) Rule Conditions, the Firepower System uses Server Name Indication (SNI) to match the DN in the TLS/SSL rule whenever possible. You can also add a distinguished name with one of each of the attributes listed in the following table, separated by commas. Table 3. Distinguished name attributes
Important notes about DN rule conditions
Wildcard examplesYou can define one or more asterisks (*) as wildcards in an attribute. In a common name attribute, you can define one or more asterisks per domain name label. wildcards match only in that label, but you can define multiple labels with wildcards. See the following table for examples. Table 4. Common Name attribute wildcard examples
For more information and examples, see Distinguished Name (DN) Rule Conditions. Creating Distinguished Name ObjectsYou can use these objects with any device type except NGIPSv. Procedure
What to do next
PKI ObjectsPKI Objects for SSL ApplicationPKI objects represent the public key certificates and paired private keys required to support your deployment. Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also contain the private key paired with the certificate. Internal and external certificate objects consist of server certificates; internal certificate objects also contain the private key paired with the certificate. If you use trusted certificate authority objects and internal certificate objects to configure a connection to ISE/ISE-PIC, you can use ISE/ISE-PIC as an identity source. If you use internal certificate objects to configure captive portal, the system can authenticate the identity of your captive portal device when connecting to users' web browsers. If you use trusted certificate authority objects to configure realms, you can configure secure connections to LDAP or AD servers. If you use PKI objects in SSL rules, you can match traffic encrypted with:
If you use PKI objects in SSL rules, you can decrypt:
You can manually input certificate and key information, upload a file containing that information, or in some cases, generate a new CA certificate and private key. When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject distinguished name. To view other certificate details, edit the PKI object.
PKI Objects for Certificate EnrollmentA certificate enrollment object contains the Certification Authority (CA) server information and enrollment parameters that are required for creating Certificate Signing Requests (CSRs) and obtaining Identity Certificates from the specified CA. These activities occur in your Private Key Infrastructure (PKI). The certificate enrollment object may also includes certificate revocation information. For more information on PKI, digital certificates, and certificate enrollment see PKI Infrastructure and Digital Certificates. Internal Certificate Authority ObjectsEach internal certificate authority (CA) object you configure represents the CA public key certificate of a CA your organization controls. The object consists of the object name, CA certificate, and paired private key. You can use internal CA objects and groups in SSL rules to decrypt outgoing encrypted traffic by re-signing the server certificate with the internal CA.
You can create an internal CA object in the following ways:
After you create an internal CA object containing a signed certificate, you can download the CA certificate and private key. The system encrypts downloaded certificates and private keys with a user-provided password. Whether system-generated or user-created, you can modify the internal CA object name, but cannot modify other object properties. You cannot delete an internal CA object that is in use. Additionally, after you edit an internal CA object used in an SSL policy, the associated access control policy goes out-of-date. You must re-deploy the access control policy for your changes to take effect. CA Certificate and Private Key ImportYou can configure an internal CA object by importing an X.509 v3 CA certificate and private key. You can upload files encoded in one of the following supported formats:
If the private key file is password-protected, you can supply the decryption password. If the certificate and key are encoded in the PEM format, you can also copy and paste the information. You can upload only files that contain proper certificate or key information, and that are paired with each other. The system validates the pair before saving the object.
Importing a CA Certificate and Private KeyYou can use these objects with any device type except NGIPSv. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
What to do next
Generating a New CA Certificate and Private KeyYou can use these objects with any device type except NGIPSv. You can configure an internal CA object by providing identification information to generate a self-signed RSA-based CA certificate and private key. The generated CA certificate is valid for ten years. The Valid From date is a week before generation. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Procedure
New Signed CertificatesYou can configure an internal CA object by obtaining a signed certificate from a CA. This involves two steps:
You can only reference an internal CA object in an SSL rule if it contains a signed certificate. Creating an Unsigned CA Certificate and CSRYou can use these objects with any device type except NGIPSv. Procedure
What to do next
Uploading a Signed Certificate Issued in Response to a CSRYou can use these objects with any device type except NGIPSv. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. Once uploaded, the signed certificate can be referenced in SSL rules. Procedure
What to do next
CA Certificate and Private Key DownloadsYou can back up or transfer a CA certificate and paired private key by downloading a file containing the certificate and key information from an internal CA object.
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.
Downloading a CA Certificate and Private KeyYou can use these objects with any device type except NGIPSv. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain. You can download CA certificates for both the current domain and ancestor domains. Procedure
Trusted Certificate Authority ObjectsEach trusted certificate authority (CA) object you configure represents a CA public key certificate belonging to a trusted CA. The object consists of the object name and CA public key certificate. You can use external CA objects and groups in:
After you create the trusted CA object, you can modify the name and add certificate revocation lists (CRL), but cannot modify other object properties. There is no limit on the number of CRLs you can add to an object. If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.
You cannot delete a trusted CA object that is in use. Additionally, after you edit a trusted CA object that is in use, the associated access control policy goes out-of-date. You must re-deploy the access control policy for your changes to take effect. Trusted CA ObjectYou can configure an external CA object by uploading an X.509 v3 CA certificate. You can upload a file encoded in one of the following supported formats:
If the file is password-protected, you must supply the decryption password. If the certificate is encoded in the PEM format, you can also copy and paste the information. You can upload a CA certificate only if the file contains proper certificate information; the system validates the certificate before saving the object. Adding a Trusted CA ObjectYou can use these objects with any device type except NGIPSv. Procedure
What to do next
Certificate Revocation Lists in Trusted CA ObjectsYou can upload CRLs to a trusted CA object. If you reference that trusted CA object in an SSL policy, you can control encrypted traffic based on whether the CA that issued the session encryption certificate subsequently revoked the certificate. You can upload files encoded in one of the following supported formats:
After you add the CRL, you can view the list of revoked certificates. If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it. You can upload only files that contain a proper CRL. There is no limit to the number of CRLs you can add to a trusted CA object. However, you must save the object each time you upload a CRL, before adding another CRL.
Adding a Certificate Revocation List to a Trusted CA ObjectYou can use these objects with any device type except NGIPSv. In a multidomain deployment, the system displays objects created in the current domain, which you can edit. It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit objects in a descendant domain, switch to that domain.
Procedure
What to do next
External Certificate ObjectsEach external certificate object you configure represents a server public key certificate that does not belong to your organization. The object consists of the object name and certificate. You can use external certificate objects and groups in SSL rules to control traffic encrypted with the server certificate. For example, you can upload a self-signed server certificate that you trust, but cannot verify with a trusted CA certificate. You can configure an external certificate object by uploading an X.509 v3 server certificate. You can upload a file in one of the following supported formats:
You can upload only files that contains proper server certificate information; the system validates the file before saving the object. If the certificate is encoded in the PEM format, you can also copy and paste the information. Adding External Certificate ObjectsYou can use these objects with any device type except NGIPSv. Procedure
What to do next
Internal Certificate ObjectsEach internal certificate object you configure represents a server public key certificate belonging to your organization. The object consists of the object name, public key certificate, and paired private key. You can use internal certificate objects and groups in:
You can configure an internal certificate object by uploading an X.509 v3 RSA-based or elliptic curve-based server certificate and paired private key. You can upload a file in one of the following supported formats:
If the file is password-protected, you must supply the decryption password. If the certificate and key are encoded in the PEM format, you can also copy and paste the information. You can upload only files that contain proper certificate or key information, and that are paired with each other. The system validates the pair before saving the object. After you create the internal certificate object, you can modify the name, but cannot modify other object properties. You cannot delete an internal certificate object that is in use. Additionally, after you edit an internal certificate object that is in use, the associated access control policy goes out-of-date. You must re-deploy the access control policy for your changes to take effect. Adding Internal Certificate ObjectsYou can use these objects with any device type except NGIPSv. Procedure
Certificate Enrollment ObjectsTrustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity pair. A trustpoint includes the identity of the CA, CA-specific configuration parameters, and an association with one, enrolled identity certificate. A certificate enrollment object contains the Certification Authority (CA) server information and enrollment parameters that are required for creating Certificate Signing Requests (CSRs) and obtaining Identity Certificates from the specified CA. These activities occur in your Private Key Infrastructure (PKI). The certificate enrollment object may also includes certificate revocation information. For more information on PKI, digital certificates, and certificate enrollment see PKI Infrastructure and Digital Certificates. How to Use Certificate Enrollment ObjectsCertificate Enrollment Objects are used to enroll your managed devices into your PKI infrastructure, and create trustpoints (CA objects) on devices that support VPN connections by doing the following:
Managing Certificate Enrollment ObjectsTo manage certificate enrollment objects, go to Objects > Object Management, then from the navigation pane choose PKI > Cert Enrollment. The following information is shown:
Press (+) Add Cert Enrollment to open the Add Cert Enrollment dialog and configure a Certificate Enrollment Object, see Adding Certificate Enrollment Objects. Then install the certificate on each managed, headend device. Adding Certificate Enrollment ObjectsYou can use these objects with FTD devices. You must have Admin or Network Admin privileges to do this task. Procedure
What to do nextAssociate and install the enrollment object on a device to create a trustpoint on that device. Certificate Enrollment Object EST OptionsFirepower Management Center Navigation Path, then from the navigation pane choose . Click (+) Add Cert Enrollment to open the Add Cert Enrollment dialog, and select the CA Information tab. FieldsEnrollment Type—set to EST.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll. Use an HTTPS URL in the form of https://CA_name:port, where CA_name is the host DNS name or IP address of the CA server. The port number is mandatory. Username—The username to access the CA server. Password / Confirm Password—The password to access the CA server. Fingerprint—When retrieving the CA certificate using EST, you may enter the fingerprint for the CA server. Using the fingerprint to verify the authenticity of the CA server’s certificate helps prevent an unauthorized party from substituting a fake certificate in place of the real one. Enter the Fingerprint for the CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the certificate is rejected. Obtain the CA’s fingerprint by contacting the server directly. Source Interface—The interface that interacts with the CA server. By default, the diagnostic interface is displayed. To configure a data interface as the source interface, choose the respective security zone or interface group object. Ignore EST Server Certificate Validations—The EST server certificate validation is done by default. Check the check box if you want to ignore FTD validating EST server certificate. Certificate Enrollment Object SCEP OptionsFirepower Management Center Navigation PathObjects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+) Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the CA Information tab. FieldsEnrollment Type—set to SCEP. Enrollment URL—The URL of the CA server to which devices should attempt to enroll. Use an HTTP URL in the form of http://CA_name:port, where CA_name is the host DNS name or IP address of the CA server. The port number is mandatory.
If the CA cgi-bin script location at the CA is not the default (/cgi-bin/pkiclient.exe), you must also include the nonstandard script location in the URL, in the form of http://CA_name:port/script_location, where script_location is the full path to the CA scripts. Challenge Password / Confirm Password—The password used by the CA server to validate the identity of the device. You can obtain the password by contacting the CA server directly or by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll. The password is good for 60 minutes from the time you obtain it from the CA server. Therefore, it is important that you deploy the password as soon as possible after you create it. Retry Period—The interval between certificate request attempts, in minutes. Value can be 1 to 60 minutes. The default is 1 minute. Retry Count—The number of retries that should be made if no certificate is issued upon the first request. Value can be 1 to 100. The default is 10. CA Certificate Source—Specify how the CA certificate will be obtained.
Fingerprint—When retrieving the CA certificate using SCEP, you may enter the fingerprint for the CA server. Using the fingerprint to verify the authenticity of the CA server’s certificate helps prevent an unauthorized party from substituting a fake certificate in place of the real one. Enter the Fingerprint for the CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the certificate is rejected. Obtain the CA’s fingerprint by contacting the server directly, or by entering the following address in a web browser: http://<URLHostName>/certsrv/mscep/mscep.dll. Certificate Enrollment Object Certificate ParametersSpecify additional information in certificate requests sent to the CA server. This information is placed in the certificate and can be viewed by any party who receives the certificate from the router. Firepower Management Center Navigation PathObjects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+) Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the Certificate Parameters tab. FieldsEnter all information using the standard LDAP X.500 format.
Certificate Enrollment Object Key OptionsFirepower Management Center Navigation PathObjects > Object Management, then from the navigation pane choose PKI > Cert Enrollment. Press (+) Add Cert Enrollment to open the Add Cert Enrollment dialog, and select the Key tab. Fields
PKI Enrollment of Certificates with Weak-CryptoSHA-1 hashing signature algorithm, and RSA key sizes that are smaller than 2048 bits for certification are not supported on FMC and FTD Version 7.0 and higher. You cannot enroll certificates with RSA key sizes that are smaller than 2048 bits. To override these restrictions on FMC 7.0 managing FTDs running Versions lesser than 7.0, you can use the enable weak-crypto option on the FTD. We do not recommend you to permit weak-crypto keys, because, such keys are not as secure as the ones with higher key sizes.
To enable weak-crypto on the device, navigate to the Devices > Certificates page. Click the Enable Weak-Crypto (
When you are upgrading to FTD 7.0, the existing certificate configurations are retained. However, if those certificates have RSA keys smaller than 2048 bits and use SHA-1 encryption algorithm, they cannot be used to establish VPN connections. You must either procure a certificate with RSA key sizes bigger than 2048 bits or enable the permit weak-crypto option for VPN connections. Certificate Enrollment Object Revocation OptionsSpecify whether to check the revocation status of a certificate by choosing and configuring the method. Revocation checking is off by default, neither method (CRL or OCSP) is checked. Firepower Management Center Navigation PathObjects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+) Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the Revocation tab. Fields
Key Chain ObjectsTo enhance data security and protection of devices, rotating keys for authenticating IGP peers that have a duration of 180 days or less is introduced. The rotating keys prevent any malicious user from guessing the keys used for routing protocol authentication and thereby protecting the network from advertising incorrect routes and redirecting traffic. Changing the keys frequently reduces the risk of them eventually being guessed. When configuring authentication for routing protocols that provide key chains, configure the keys in a key chain to have overlapping lifetimes. This helps to prevent loss of key-secured communication due to absence of an active key. The rotating keys are applicable only for OSPFv2 protocol. If the key lifetime expires and no active keys are found, OSPF uses the last valid key to maintain the adjacency with peers.
Lifetime of a KeyTo maintain stable communications, each device stores key chain authentication keys and uses more than one key for a feature at the same time. Based on the send and accept lifetimes of a key, key chain management provides a secured mechanism to handle key rollover. The device uses the lifetimes of keys to determine which keys in a key chain are active. Each key in a key chain has two lifetimes:
During a key send lifetime, the device sends routing update packets with the key. The device does not accept communication from other devices when the key sent is not within the accept lifetime of the key on the device. If lifetimes are not configured then it is equivalent to configuring MD5 authentication key without timelines. Key Selection
Creating Key Chain ObjectsProcedure
What to do next
DNS Server Group ObjectsDomain Name System (DNS) servers resolve fully-qualified domain names (FQDN), such as www.example.com, to IP addresses. Creating DNS Server Group ObjectsYou can use these objects with any device type except NGIPSv. Procedure
What to do nextThe DNS servers configured in the DNS server group should be assigned to interface objects in the DNS platform settings. For more information, see Configure DNS. About Dynamic ObjectsA dynamic object is an object that can be created either using an IP or using the Cisco Secure Dynamic Attributes Connector, which is an integration that enables objects from cloud networking products (such as VMware vCenter) to be used in FMC access control rules. For more information about the dynamic attributes connector, see the Cisco Secure Dynamic Attributes Configuration Guide (link to guide). Differences between dynamic objects and network objects follow:
Add or Edit a Dynamic ObjectThis procedure discusses how to add or edit a dynamic object, which is a group of IP addresses, with or without or classless inter-domain routing (CIDR), that can be used in access control rules much like a network object. Before you beginConsult the Firepower Management Center REST API Quick Start Guide for information about using the object services API to populate the IP object with an address. Dynamic objects do not require deployment. Procedure
What to do nextIf necessary, update the dynamic object using the API. Deployment is not required. SLA Monitor ObjectsEach Internet Protocol Service Level Agreement (SLA) monitor defines a connectivity policy to a monitored address and tracks the availability of a route to the address. The route is periodically checked for availability by sending ICMP echo requests and waiting for the response. If the requests time out, the route is removed from the routing table and replaced with a backup route. SLA monitoring jobs start immediately after deployment and continue to run unless you remove the SLA monitor from the device configuration (that is, they do not age out). The Internet Protocol Service Level Agreement (SLA) Monitor Object is used in the Route Tracking field of an IPv4 Static Route Policy. IPv6 routes do not have the option to use SLA monitor via route tracking. You can use these objects with FTD devices. Procedure
Prefix ListsYou can create prefix list objects for IPv4 and IPv6 to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering. Configure IPv6 Prefix ListUse the Configure IPv6 Prefix list page to create, copy and edit prefix list objects. You can create prefix list objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering. You can use this object with FTD devices. Procedure
Configure IPv4 Prefix ListUse the Configure IPv4 Prefix list page to create, copy and edit prefix list objects. You can create prefix list objects to use when you are configuring route maps, policy maps, OSPF Filtering, or BGP Neighbor Filtering. You can use this object with FTD devices. Procedure
Route MapsRoute maps are used when redistributing routes into any routing process. They are also used when generating a default route into a routing process. A route map defines which of the routes from the specified routing protocol are allowed to be redistributed into the target routing process. Configure a route map, to create a new route map entry for a Route Map object or to edit an existing one. You can use this object with FTD devices. Before you beginA Route Map may use one or mores of these objects; it is not mandatory to add all these objects. Create and use any of these objects as required, to configure your route map.
Procedure
Access ListAn access list object, also known as an access control list (ACL), selects the traffic to which a service will apply. You use these objects when configuring particular features, such as route maps, for FTD devices. Traffic identified as allowed by the ACL is provided the service, whereas “blocked” traffic is excluded from the service. Excluding traffic from a service does not necessarily mean that it is dropped altogether. You can configure the following types of ACL:
An ACL is composed of one or more access control entry (ACE), or rule. The order of ACEs is important. When the ACL is evaluated to determine if a packet matches an “allowed” ACE, the packet is tested against each ACE in the order in which the entries are listed. After a match is found, no more ACEs are checked. For example, if you want to “allow” 10.100.10.1, but “block” the rest of 10.100.10.0/24, the allow entry must come before the block entry. In general, place more specific rules at the top of an ACL. Packets that do not match an “allow” entry are considered to be blocked. The following topics explain how to configure ACL objects. Configure Extended ACL ObjectsUse extended ACL objects when you want to match traffic based on source and destination addresses, protocol and port, or if the traffic is IPv6. Procedure
Configure Standard ACL ObjectsUse standard ACL objects when you want to match traffic based on destination IPv4 address only. Otherwise, use extended ACLs. Procedure
AS Path ObjectsAn AS Path is a mandatory attribute to set up BGP. It is a sequence of AS numbers through which a network can be accessed. An AS-PATH is a sequence of intermediate AS numbers between source and destination routers that form a directed route for packets to travel. Neighboring autonomous systems (ASes ) use BGP to exchange and update messages about how to reach different AS prefixes. After each router makes a new local decision on the best route to a destination, it will send that route, or path information, along with the accompanying distance metrics and path attributes, to each of its peers. As this information travels through the network, each router along the path prepends its unique AS number to a list of ASes in the BGP message. This list is the route's AS-PATH. An AS-PATH along with an AS prefix, provides a specific handle for a one-way transit route through the network. Use the Configure AS Path page to create, copy and edit autonomous system (AS) path policy objects. You can create AS path objects to use when you are configuring route maps, policy maps, or BGP Neighbor Filtering. An AS path filter allows you to filter the routing update message by using regular expressions. You can use this object with FTD devices. Procedure
Community ListsA Community is an optional transitive BGP attribute. A community is a group of destinations that share some common attribute. It is used for route tagging. The BGP community attribute is a numerical value that can be assigned to a specific prefix and advertised to other neighbors. Communities can be used to mark a set of prefixes that share a common attribute. Upstream providers can use these markers to apply a common routing policy such as filtering or assigning a specific local preference or modifying other attributes. Use the Configure Community Lists page to create, copy and edit community list policy objects. You can create community list objects to use when you are configuring route maps or policy maps. You can use community lists to create groups of communities to use in a match clause of a route map. The community list is an ordered list of matching statements. Destinations are matched against the rules until a match is found. You can use this object with FTD devices. Procedure
Policy ListsUse the Configure Policy List page to create, copy, and edit policy list policy objects. You can create policy list objects to use when you are configuring route maps. When a policy list is referenced within a route map, all of the match statements within the policy list are evaluated and processed. Two or more policy lists can be configured with a route map. A policy list can also coexist with any other preexisting match and set statements that are configured within the same route map but outside of the policy list. When multiple policy lists perform matching within a route map entry, all policy lists match on the incoming attribute only. You can use this object with FTD devices. Procedure
VPN ObjectsYou can use the following VPN objects on FTD devices. To use these objects, you must have Admin privileges, and your Smart License account must satisfy export controls. You can configure these objects in leaf domains only. FTD IKE PoliciesInternet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs). The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes SAs for other applications, such as IPsec. Both phases use proposals when they negotiate a connection. An IKE proposal is a set of algorithms that two peers use to secure the negotiation between them. IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters are used to protect subsequent IKE negotiations. For IKEv1, IKE proposals contain a single set of algorithms and a modulus group. You can create multiple, prioritized policies to ensure that at least one policy matches a remote peer’s policy. Unlike IKEv1, in an IKEv2 proposal, you can select multiple algorithms and modulus groups in one policy. Since peers choose during the Phase 1 negotiation, this makes it possible to create a single IKE proposal, but consider multiple, different proposals to give higher priority to your most desired options. For IKEv2, the policy object does not specify authentication, other policies must define the authentication requirements. An IKE policy is required when you configure a site-to-site IPsec VPN. For more information, see Firepower Threat Defense VPN. Configure IKEv1 Policy ObjectsUse the IKEv1 Policy page to create, delete, or edit an IKEv1 policy object. These policy objects contain the parameters required for IKEv1 policies. Procedure
Configure IKEv2 Policy ObjectsUse the IKEv2 policy dialog box to create, delete, and edit an IKEv2 policy object. These policy objects contain the parameters required for IKEv2 policies. Procedure
FTD IPsec ProposalsIPsec Proposals (or Transform Sets) are used when configuring VPN topologies. During the IPsec security association negotiation with ISAKMP, the peers agree to use a particular proposal to protect a particular data flow. The proposal must be the same for both peers. There are separate IPsec proposal objects based on the IKE version, IKEv1, or IKEv2:
The Encapsulating Security Protocol (ESP) is used for both IKEv1 and IKEv2 IPsec Proposals. It provides authentication, encryption, and antireplay services. ESP is IP protocol type 50.
Configure IKEv1 IPsec Proposal ObjectsProcedure
Configure IKEv2 IPsec Proposal ObjectsProcedure
FTD Group Policy ObjectsA group policy is a set of attribute and value pairs, stored in a group policy object, that define the remote access VPN experience. For example, in the group policy object, you configure general attributes such as addresses, protocols, and connection settings. The group policy applied to a user is determined when the VPN tunnel is being established. The RADIUS authorization server assigns the group policy, or it is obtained from the current connection profile.
To use group objects, you must have one of these AnyConnect licenses associated with your Smart License account with Export-Controlled Features enabled:
Configure Group Policy ObjectsSee FTD Group Policy Objects. Procedure
What to do nextGroup Policy General OptionsNavigation Path, click Click Add Group Policy or choose a current policy to edit., then select the General tab. VPN Protocols FieldsSpecify the types of Remote Access VPN tunnels that can be used when applying this group policy. SSL or IPsec IKEv2. IP Address PoolsSpecifies the IPv4 address assignment that is applied based on address pools that are specific to user-groups in Remote Access VPN. For Remote Access VPN, you can assign IP address from specific address pools for identified user groups using RADIUS/ISE for authorization. You can seamlessly perform policy enforcement for user or user groups in systems which are not identity-aware, by configuring particular Group Policy as RADIUS Authorization attribute (GroupPolicy/Class), for a particular user group. For example, you have to select a specific address pool for contractors and policy enforcement using those addresses to allow restricted access to internal network. The order of preference that Firepower Threat Defense device assigns the IPv4 Address Pools to the clients:
Some limitations around using IP address pools in Group Policy:
Banner FieldsSpecifies the banner text to present to users at login. The length can be up to 491 characters. There is no default value. The IPsec VPN client supports full HTML for the banner, however, the AnyConnect client supports only partial HTML. To ensure that the banner displays properly to remote users, use the /n tag for IPsec clients, and the <BR> tag for SSL clients. DNS/WINS FieldsDomain Naming System (DNS) and Windows Internet Naming System (WINS) servers. Used for AnyConnect client name resolution.
Split Tunneling FieldsSplit tunneling directs some network traffic through the VPN tunnel (encrypted) and the remaining network traffic outside the VPN tunnel (unencrypted or “in the clear”).
Group Policy AnyConnect OptionsThese specifications apply to the operation of the AnyConnect VPN client. Navigation. Click Add Group Policy or choose a current policy to edit. Then select the AnyConnect tab. Profile FieldsProfile—Choose or create a file object containing an AnyConnect Client Profile. See FTD File Objects for object creation details. An AnyConnect Client Profile is a group of configuration parameters stored in an XML file. The AnyConnect software client uses it to configure the connection entries that appear in the client's user interface. These parameters (XML tags) also configure settings to enable more AnyConnect features. Use the GUI-based AnyConnect Profile Editor, an independent configuration tool, to create an AnyConnect Client Profile. See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility Client Administrator Guide for details. Management Profile FieldsA Management VPN Tunnel provides connectivity to the corporate network whenever the endpoint is powered up, even if end-user does not connect over VPN. Management VPN Profile—The Management Profile file contains settings for enabling and establishing Management VPN Tunnel on endpoint. The Standalone Management VPN Tunnel profile editor can be used to create a new profile file or modify an existing file. You can download the profile editor from Cisco Software Download Center. For more information about adding a profile file, see FTD File Objects. Client Modules FieldsCisco AnyConnect VPN client offers enhanced security through various built-in modules. These modules provide services such as web security, network visibility into endpoint flows, and off-network roaming protection. Each client module includes a client profile that includes a group of custom configurations as per your requirement. The following AnyConnect modules are optional and you can configure these modules to be downloaded when a VPN user downloads AnyConnect:
Click Add and select the following for each client module:
Use the GUI-based AnyConnect Profile Editor, an independent configuration tool to create a client profile for each module. Download the AnyConnect Profile Editor from Cisco Software Download Center. See the AnyConnect Profile Editor chapter in the appropriate release of the Cisco AnyConnect Secure Mobility Client Administrator Guide for details. SSL Settings Fields
Connection Settings Fields
Custom Attributes FieldsThis section lists the AnyConnect Custom attributes that are used by the AnyConnect client to configure features such as Per App VPN, Allow or defer upgrade, and Dynamic split tunneling. Click Add to add custom attributes to the group policy.
Group Policy Advanced OptionsNavigation Path, click Click Add Group Policy or choose a current policy to edit., then select the Advanced tab. Traffic Filter Fields
Session Settings Fields
FTD File ObjectsUse the Add and Edit File Object dialog boxes to create, and edit file objects. File objects represent files used in configurations, typically for remote access VPN policies. They can contain AnyConnect Client Profile and AnyConnect Client Image files. Profiles are also created for each AnyConnect module and AnyConnect Management VPN using independent profile editors and deployed to administrator-defined end user requirements and authentication policies on endpoints as part of AnyConnect, and they make the preconfigured network profiles available to end users. When you create a file object, the Firepower Management Center makes a copy of the file in its repository. These files are backed up whenever you create a backup of the database, and they are restored if you restore the database. When copying a file to the Firepower Management Center platform to be used in a file object, do not copy the file directly to the file repository. When you deploy configurations that specify a file object, the associated file is downloaded to the device in the appropriate directory. You can click one of the following options against each file:
Navigation Path> Add AnyConnect File. Fields
FTD Certificate Map ObjectsCertificate Map objects are a named set of certificate matching rules. These objects are used to provide an association between a received certificate and a Remote Access VPN connection profile. Connection Profiles and Certificate Map objects are both part of a remote access VPN policy. If a received certificate matches the rules contained in the certificate map, the connection is "mapped", or associated with the specified connection profile. The rules are in priority order, they are matched in the order they are shown in the UI. The matching ends when the first rule within the Certificate Map object results in a match. NavigationFields
AnyConnect Custom Attributes ObjectsCustom attributes are used by the AnyConnect client to configure features such as Per App VPN, Allow or defer upgrade, and Dynamic split tunneling. A custom attribute has a type and a named value. The type of the attribute is defined first, then one or more named values of this type can be defined. You can create an AnyConnect custom attributes objects using the FMC, add the objects to a group policy and associate the group policy with a remote access VPN to enable the features for the VPN clients. FTD supports the following features using the custom attribute objects:
For step-by-step instructions to configure AnyConnect custom attributes, see Add AnyConnect Custom Attributes Objects and For details about the specific custom attributes to configure for a feature, see the Cisco AnyConnect Secure Mobility Client Administrator Guide for the AnyConnect release you are using. Add AnyConnect Custom Attributes ObjectsBefore you begin
Procedure
What to do nextAdd Custom Attributes to a Group PolicyProcedure
Address PoolsYou can configure IP address pools for both IPv4 and IPv6 that can be used for the Diagnostic interface with clustering, or for VPN remote access profiles. You can use this object with FTD devices. Procedure
FlexConfig ObjectsUse FlexConfig policy objects in FlexConfig policies to provide customized configuration of features on FTD devices that you cannot otherwise configure using Firepower Management Center. For more information on FlexConfig policies, see FlexConfig Policy Overview. You can configure the following types of objects for FlexConfig. Text ObjectsText objects define free-form text strings that you use as variables in a FlexConfig object. These objects can have single values or be a list of multiple values. There are several predefined text objects that are used in the predefined FlexConfig objects. If you use the associated FlexConfig object, you simply need to edit the contents of the text object to customize how the FlexConfig object configures a given device. When editing a predefined object, it is in general a better option to create device overrides for each device you are configuring, rather than directly change the default values of these objects. This helps avoid unintended consequences if another user wants to use the same FlexConfig object for a different set of devices. For information on configuring text objects, see Configure FlexConfig Text Objects. FlexConfig ObjectsFlexConfig Objects include device configuration commands, variables, and scripting language instructions. During configuration deployment, these instructions are processed to create a sequence of configuration commands with customized parameters to configure specific features on the target devices. These instructions are either configured before (prepended) the system configures features defined in regular Firepower Management Center policies and settings, or after (appended). Any FlexConfig that depends on Firepower Management Center-configured objects (for example, a network object) must be appended to the configuration deployment, or the needed objects would not be configured before the FlexConfig needed to refer to the objects. For more information on configuring FlexConfig objects, see Configure FlexConfig Objects. RADIUS Server GroupsRADIUS Server Group objects contain one or more references to RADIUS servers. These servers are used to authenticate users logging in through Remote Access VPN connections. You can use this object with FTD devices. Before you begin
Procedure
RADIUS Server Group OptionsNavigation Path. Choose and edit a configured RADIUS Server Group object or add a new one. Fields
RADIUS Server OptionsNavigation Path. Choose and edit a listed RADIUS Server Group object or add a new one. Then, in the RADIUS Server Group dialog, choose and edit a listed RADIUS Server or add a new one. Fields
Single Sign-on ServerBefore you beginObtain the following from your SAML identity provider:
For more information, see Configuring a SAML Single Sign-on Authentication. Procedure
History for Reusable Objects
What is the name of an object that dynamically groups applications based on application attributes that you define category subcategory technology risk and characteristic?***An application filter is an object that dynamically groups applications based on application attributes that you select from the App-ID database. The selectable attributes are Category, Subcategory, Risk, Tags, and Characteristic.
Which three items are used by the firewall appApp-ID enables you to see the applications on your network and learn how they work, their behavioral characteristics, and their relative risk. Applications and application functions are identified via multiple techniques, including application signatures, decryption (if needed), protocol decoding, and heuristics.
Which two items are used by the firewall content ID engine to analyze network traffic for threats?The Content-ID engine uses the identity provided by App-ID to select the appropriate protocol decoder to inspect the packet data. Content-ID inspects the packet data for malware or the transfer of sensitive data. Content-ID also uses the protocol decoders to detect an application shift and re-identify an application.
Which tool is available in the management web interface to help you migrate from portLegacy Port-Based to App-ID Rule Converter identifies port-based Security policy rules so you can convert them to application-based rules without compromising application availability and identifies rules configured with unused applications.
|
Which item is the name of an object that dynamically groups applications based on application attributes?
zusammenhängende Posts
Urheberrechte © © 2024 decemle Inc.
