DNS Policies

The following topics explain DNS policies, DNS rules, and how to deploy DNS policies to managed devices.

DNS Policy Overview

DNS-based Security Intelligence allows you to block traffic based on the domain name requested by a client, using a Security Intelligence Block list. Cisco provides domain name intelligence you can use to filter your traffic; you can also configure custom lists and feeds of domain names tailored to your deployment.

Traffic on a DNS policy Block list is immediately blocked and therefore is not subject to any further inspection—not for intrusions, exploits, malware, and so on, but also not for network discovery. You can use a Security Intelligence Do Not Block list to override a Block list and force access control rule evaluation, and, recommended in passive deployments, you can use a “monitor-only” setting for Security Intelligence filtering. This allows the system to analyze connections that would have been blocked by a Block list, but also logs the match to the Block list and generates an end-of-connection Security Intelligence event.


Note

DNS-based Security Intelligence may not work as intended for a domain name unless the DNS server deletes a domain cache entry due to expiration, or a client’s DNS cache or the local DNS server’s cache is cleared or expires.

You configure DNS-based Security Intelligence using a DNS policy and associated DNS rules. To deploy it to your devices, you must associate your DNS policy with an access control policy, then deploy your configuration to managed devices.

Cisco Umbrella DNS Policies

Cisco Umbrella DNS Connection in the management center helps to redirect DNS queries to Cisco Umbrella. This allows Cisco Umbrella to validate requests, allow or block them based on the domain names, and apply DNS-based security policy on the request. If you use Cisco Umbrella, you must configure the Cisco Umbrella Connection (Integration > Other Integrations > Cloud Services > Cisco Umbrella Connection) to redirect DNS queries to Cisco Umbrella.

The Umbrella Connector is part of the system’s DNS inspection. If your existing DNS inspection policy map decides to block or drop a request based on your DNS inspection settings, the request is not forwarded to Cisco Umbrella. Thus, you have two lines of protection:

  • Your local DNS inspection policy

  • Your Cisco Umbrella cloud-based policy

When redirecting DNS lookup requests to Cisco Umbrella, the Umbrella Connector adds an EDNS (Extension mechanisms for DNS) record. An EDNS record includes the device identifier information, organization ID, and client IP address. Your cloud-based policy can use those criteria to control access in addition to the reputation of the FQDN. You can also elect to encrypt the DNS request using DNSCrypt to ensure the privacy of usernames and internal IP addresses.

To redirect DNS requests from the management center to Cisco Umbrella:

  1. Configure the Cisco Umbrella connection settings.

  2. Create and configure an Umbrella DNS policy.

  3. Associate the Umbrella DNS policy with an access control policy.

  4. Deploy the changes.

For detailed information about how to set up the Umbrella DNS Connector in the management center, see Configuring the Umbrella DNS Connector for Cisco Secure Firewall Management Center.

DNS Policy Components

A DNS policy allows you to block connections based on domain name, using a Block list, or exempt such connections from this type of blocking using a Do Not Block list. The following list describes the configurations you can change after creating a DNS policy.

Name and Description

Each DNS policy must have a unique name. A description is optional.

Rules

Rules provide a granular method of handling network traffic based on the domain name. Rules in a DNS policy are numbered, starting at 1. The system matches traffic to DNS rules in top-down order by ascending rule number.

When you create a DNS policy, the system populates it with a default Global Do-Not-Block List for DNS rule and a default Global Block List for DNS rule. Both rules are fixed to the first position in their respective categories. You cannot modify these rules, but you can disable them.


Note

If multitenancy is enabled for your management center, the system is organized into a hierarchy of domains, including ancestor and descendant domains. These domains are distinct and separate from the domain names used in DNS management.

A descendant list contains the domains on the Block or Do Not Block lists of system subdomain users. From an ancestor domain, you cannot view the contents of descendant lists. If you do not want subdomain users to add domains to a Block or Do Not Block list:

  • disable the descendant list rules, and

  • enforce Security Intelligence using the access control policy inheritance settings

The system evaluates rules in the following order:

  • Global Do-Not-Block List for DNS rule (if enabled)

  • Descendant DNS Do-Not-Block Lists rule (if enabled)

  • Rules with a Do Not Block action

  • Global Block List for DNS rule (if enabled)

  • Descendant DNS Block Lists rule (if enabled)

  • Rules with an action other than Do Not Block

Usually, the system handles DN-based network traffic according to the first DNS rule where all the rule’s conditions match the traffic. If no DNS rules match the traffic, the system continues evaluating the traffic based on the associated access control policy's rules. DNS rule conditions can be simple or complex.

License Requirements for DNS Policies

Threat Defense License

IPS

Classic License

Protection

Requirements and Prerequisites for DNS Policies

Model Support

Any

Supported Domains

Any

User Roles

  • Admin

  • Access Admin

  • Network Admin


Important

You must apply the Network Discovery policy on the device for a successful DNS validation on the traffic.

Managing DNS and Umbrella DNS Policies

Use the DNS Policy page (Policies > Access Control > DNS) to manage custom DNS and Umbrella DNS policies.

In addition to custom policies that you create, the system provides the Default DNS Policy and Default Umbrella DNS Policy. The default DNS policy uses the default Block list and Do Not Block list. You can edit and use this system-provided custom policies.

Procedure

Step 1

Choose Policies > Access Control > DNS.

Step 2

Manage your DNS policy:

  • Compare—To compare DNS policies, click Compare Policies and proceed as described in Compare Policies.
  • Copy—To copy a DNS policy, click Copy (copy icon) and proceed as described in Editing DNS Policies.
  • Create—To create a new Umbrella DNS policy, click New Policy > Umbrella DNS Policy and proceed as described in Create an Umbrella DNS Policy.
  • Delete—To delete a DNS or Umbrella DNS policy, click Delete (delete icon), then confirm you want to delete the policy.
  • Edit—To modify an existing DNS policy, click Edit (edit icon)) and proceed as described in Editing DNS Policies. To modify an existing Umbrella DNS policy, click Edit (edit icon)) and proceed as described in Edit Umbrella DNS Policies and Rules.

Creating Basic DNS Policies

When you create a new DNS policy, it contains default settings. You must then edit it to customize the behavior.

Procedure

Step 1

Choose Policies > Access Control > DNS.

Step 2

Click Add DNS Policy > DNS Policy.

Step 3

Give the policy a unique Name and, optionally, a Description.

Step 4

Click Save.

What to do next

Configure the policy. See Editing DNS Policies.

Editing DNS Policies

Only one person should edit a DNS policy at a time, using a single browser window. If multiple users attempt to save the same policy, only the first set of saved changes are retained.

To protect the privacy of your session, after thirty minutes of inactivity on the policy editor, a warning appears. After sixty minutes, the system discards your changes.

Procedure

Step 1

Choose Policies > Access Control > DNS.

Step 2

Click Edit (edit icon) next to the DNS policy you want to edit.

If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 3

Edit your DNS policy:

  • Name and Description—To change the name or description, click the field and type the new information.

  • Rules—To add, categorize, enable, disable, or otherwise manage DNS rules, click Rules and proceed as described in Creating and Editing DNS Rules.

Step 4

Click Save.

What to do next

DNS Rules

DNS rules handle traffic based on the domain name requested by a host. As part of Security Intelligence, this evaluation happens after any traffic decryption, and before access control evaluation.

The system matches traffic to DNS rules in the order you specify. In most cases, the system handles network traffic according to the first DNS rule where all the rule’s conditions match the traffic.

In addition to its unique name, each DNS rule has the following basic components:

State

By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and stops generating warnings and errors for that rule.

Position

Rules in a DNS policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Conditions

Conditions specify the specific traffic the rule handles. A DNS rule must contain a DNS feed or list condition, and can also match traffic by security zone, network, or VLAN.

Action

A rule’s action determines how the system handles matching traffic:

  • Traffic with a Do Not Block action is allowed, subject to further access control inspection.

  • Monitored traffic is subject to further evaluation by remaining rules on the DNS Block list. If the traffic does not match a DNS Block list rule, it is inspected with access control rules. The system logs a Security Intelligence event for the traffic.

  • Traffic on a Block list is dropped without further inspection. You can also return a Domain Not Found response, or redirect the DNS query to a sinkhole server.

Creating and Editing DNS Rules

In a DNS policy, you can add up to a total of 32767 DNS lists to the Block list and Do Not Block list rules; that is, the number of lists in the DNS policy cannot exceed 32767.

Procedure

Step 1

In the DNS policy editor, you have the following options:

  • To add a new rule, click Add DNS Rule.
  • To edit an existing rule, click Edit (edit icon).

Step 2

Enter a Name.

Step 3

Configure the rule components, or accept the defaults:

Step 4

Click Save.

What to do next

DNS Rule Management

The Rules tab of the DNS policy editor allows you to add, edit, move, enable, disable, delete, and otherwise manage DNS rules within your policy.

For each rule, the policy editor displays its name, a summary of its conditions, and the rule action. Other icons represent Warning (warning icon), Error (error icon), and other important Information (import section icon). Disabled rules are dimmed and marked (disabled) beneath the rule name.

Enabling and Disabling DNS Rules

When you create a DNS rule, it is enabled by default. If you disable a rule, the system does not use it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules in a DNS policy, disabled rules are dimmed, although you can still modify them. Note that you can also enable or disable a DNS rule using the DNS rule editor.

Procedure

Step 1

In the DNS policy editor, right-click the rule and choose a rule state.

Step 2

Click Save.

What to do next

DNS Rule Order Evaluation

Rules in a DNS policy are numbered, starting at 1. The system matches traffic to DNS rules in top-down order by ascending rule number. In most cases, the system handles network traffic according to the first DNS rule where all the rule’s conditions match the traffic:

  • For Monitor rules, the system logs the traffic, then continues evaluating traffic against lower-priority DNS Block list rules.

  • For non-Monitor rules, the system does not continue to evaluate traffic against additional, lower-priority DNS rules after that traffic matches a rule.

Note the following regarding rule order:

  • The Global Do-Not-Block List for DNS is always first, and takes precedence over all other rules.

  • The Do-Not-Block List section precedes the Block List section; Do-Not-Block List rules always take precedence over other rules.

  • The Global Block List for DNS is always first in the Block List section, and takes precedence over all other Monitor and Block list rules.

  • The Block List section contains Monitor and Block list rules.

  • When you first create a DNS rule, the system positions it last in the Do-Not-Block List section if you assign a Do Not Block action, or last in the Block List section if you assign any other action.

You can drag and drop rules to reorder them.

DNS Rule Actions

Every DNS rule has an action that determines the following for matching traffic:

  • handling—foremost, the rule action governs whether the system will block, not block, or monitor traffic that matches the rule’s conditions, based on a Block or Do Not Block list

  • logging—the rule action determines when and how you can log details about matching traffic

If configured, TID also impacts action prioritization. For more information, see Threat Intelligence Director-Management Center Action Prioritization.

Do Not Block Action

The Do Not Block action allows traffic to pass to the next phase of inspection, which is access control rules.

The system does not log Do Not Block list matches. Logging of these connections depends on their eventual disposition.

Monitor Action

The Monitor action is designed to force connection logging; matching traffic is neither immediately allowed nor blocked. Rather, traffic is matched against additional rules to determine whether to permit or deny it. The first non-Monitor DNS rule matched determines whether the system blocks the traffic. If there are no additional matching rules, the traffic is subject to access control evaluation.

For connections monitored by a DNS policy, the system logs end-of-connection Security Intelligence and connection events to the management center database.

Block Actions

These actions block traffic without further inspection of any kind:

  • The Drop action drops the traffic.

  • The Domain Not Found action returns a non-existent internet domain response to the DNS query, which prevents the client from resolving the DNS request.

  • The Sinkhole action returns a sinkhole object's IPv4 or IPv6 address in response to the DNS query (A and AAAA records only). The sinkhole server can log, or log and block, follow-on connections to the IP address. If you configure a Sinkhole action, you must also configure a sinkhole object.

For a connection blocked based on the Drop or Domain Not Found actions, the system logs beginning-of-connection Security Intelligence and connection events. Because blocked traffic is immediately denied without further inspection, there is no unique end of connection to log.

For a connection blocked based on the Sinkhole action, logging depends on the sinkhole object configuration. If you configure your sinkhole object to only log sinkhole connections, the system logs end-of-connection connection events for the follow-on connection. If you configure your sinkhole object to log and block sinkhole connections, the system logs beginning-of-connection connection events for the follow-on connection, then blocks that connection.

DNS Rule Conditions

A DNS rule’s conditions identify the type of traffic that rule handles. Conditions can be simple or complex. You must define a DNS feed or list condition within a DNS rule. You can also optionally control traffic by security zone, network, or VLAN.

When adding conditions to a DNS rule:

  • If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion.

  • You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the rule to apply to traffic. For example, a rule with a DNS feed or list condition and network condition but no VLAN tag condition evaluates traffic based on the domain name and source or destination, regardless of any VLAN tagging in the session.

  • For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition’s criteria satisfies the condition. For example, you can use a single rule to block traffic based on up to 50 DNS lists and feeds.

Security Zone Rule Conditions

Security zones segment your network to help you manage and classify traffic flow by grouping interfaces across multiple devices.

Zone rule conditions control traffic by its source and destination security zones. If you add both source and destination zones to a zone condition, matching traffic must originate from an interface in one of the source zones and leave through an interface in one of the destination zones.

Just as all interfaces in a zone must be of the same type (all inline, passive, switched, or routed), all zones used in a zone condition must be of the same type. Because devices deployed passively do not transmit traffic, you cannot use a zone with passive interfaces as a destination zone.

Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.


Tip

Constraining rules by zone is one of the best ways to improve system performance. If a rule does not apply to traffic through any of device’s interfaces, that rule does not affect that device's performance.

Security Zone Conditions and Multitenancy

In a multidomain deployment, a zone created in an ancestor domain can contain interfaces that reside on devices in different domains. When you configure a zone condition in an descendant domain, your configurations apply to only the interfaces you can see.

Network Rule Conditions

Network rule conditions control traffic by its source and destination IP address, using inner headers. Tunnel rules, which use outer headers, have tunnel endpoint conditions instead of network conditions.

You can use predefined objects to build network conditions, or manually specify individual IP addresses or address blocks.


Note

You cannot use FDQN network objects in identity rules.

Leave matching criteria empty whenever possible, especially those for security zones, network objects, and port objects. When you specify multiple criteria, the system must match against every combination of the contents of the criteria you specify.

VLAN Tags Rule Conditions


Note

VLAN tags in access rules only apply to inline sets. Access rules with VLAN tags do not match traffic on firewall interfaces.

VLAN rule conditions control VLAN-tagged traffic, including Q-in-Q (stacked VLAN) traffic. The system uses the innermost VLAN tag to filter VLAN traffic, with the exception of the prefilter policy, which uses the outermost VLAN tag in its rules.

Note the following Q-in-Q support:

  • Threat Defense on Firepower 4100/9300—Does not support Q-in-Q (supports only one VLAN tag).

  • Threat Defense on all other models:

    • Inline sets and passive interfaces—Supports Q-in-Q, up to 2 VLAN tags.

    • Firewall interfaces—Does not support Q-in-Q (supports only one VLAN tag).

You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094. Use a hyphen to specify a range of VLAN tags.

You can specify a maximum of 50 VLAN conditions.

In a cluster, if you encounter problems with VLAN matching, edit the access control policy advanced options, Transport/Network Preprocessor Settings, and select the Ignore the VLAN header when tracking connections option.

DNS Rule Conditions

DNS conditions in DNS rules allow you to control traffic if a DNS list, feed, or category contains the domain name requested by the client. You must define a DNS condition in a DNS rule.

Regardless of whether you add a global or custom Block or Do Not Block list to a DNS condition, the system applies the configured rule action to the traffic. For example, if you add the Global Do Not Block List to a rule, and configure a Drop action, the system blocks all traffic that should have been allowed to pass to the next phase of inspection.

How to Create DNS Rules

The following topics discuss how to create DNS rules.

Controlling Traffic Based on DNS and Security Zone

Zone conditions in DNS rules allow you to control traffic by its source security zone. A security zone is a grouping of one or more interfaces, which may be located across multiple devices.

Procedure

Step 1

In the DNS rule editor, click Zones.

Step 2

Find and select the zones you want to add from the Available Zones. To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone name. The list updates as you type to display matching zones.

Step 3

Click to select a zone, or right-click and then select Select All.

Step 4

Click Add to Source, or drag and drop.

Step 5

Save or continue editing the rule.

What to do next

Controlling Traffic Based on DNS and Network

Network conditions in DNS rules allow you to control traffic by its source IP address. You can explicitly specify the source IP addresses for the traffic you want to control.

Procedure

Step 1

In the DNS rule editor, click Networks.

Step 2

Find and select the networks you want to add from the Available Networks, as follows:

  • To add a network object on the fly, which you can then add to the condition, click Add (add icon) above the Available Networks list and proceed as described in Creating Network Objects.

  • To search for network objects to add, click the Search by name or value prompt above the Available Networks list, then type an object name or the value of one of the object’s components. The list updates as you type to display matching objects.

Step 3

Click Add to Source, or drag and drop.

Step 4

Add any source IP addresses or address blocks that you want to specify manually. Click the Enter an IP address prompt below the Source Networks list; then type an IP address or address block and click Add.

Step 5

Save or continue editing the rule.

What to do next

Controlling Traffic Based on DNS and VLAN

VLAN conditions in DNS rules allow you to control VLAN-tagged traffic. The system uses the innermost VLAN tag to identify a packet by VLAN.

When you build a VLAN-based DNS rule condition, you can manually specify VLAN tags. Alternately, you can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one or more VLAN tags.

Procedure

Step 1

In the DNS rule editor, select VLAN Tags.

Step 2

Find and select the VLANs you want to add from the Available VLAN Tags, as follows:

  • To add a VLAN tag object on the fly, which you can then add to the condition, click Add (add icon) above the Available VLAN Tags list and proceed as described in Creating VLAN Tag Objects.

  • To search for VLAN tag objects and groups to add, click the Search by name or value prompt above the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in the object. The list updates as you type to display matching objects.

Step 3

Click Add to Rule, or drag and drop.

Step 4

Add any VLAN tags that you want to specify manually. Click the Enter a VLAN Tag prompt below the Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag from 1 to 4094; use a hyphen to specify a range of VLAN tags.

Step 5

Save or continue editing the rule.

What to do next

Controlling Traffic Based on DNS List or Feed

Procedure

Step 1

In the DNS rule editor, click DNS.

Step 2

Find and select the DNS lists and feeds you want to add from the DNS Lists and Feeds, as follows:

  • To add a DNS list or feed on the fly, which you can then add to the condition, click Add (add icon) above the DNS Lists and Feeds list and proceed as described in Creating Security Intelligence Feeds .

  • To search for DNS lists, feeds, or categories to add, click the Search by name or value prompt above the DNS Lists and Feeds list, then type an object name or the value of one of the object’s components. The list updates as you type to display matching objects.

  • For descriptions of the system-provided threat categories, see Security Intelligence Categories.

Step 3

Click Add to Rule, or drag and drop.

Step 4

Save or continue editing the rule.

What to do next

DNS Policy Deploy

After you finish updating your DNS policy configuration, you must deploy it as part of access control configuration.

Cisco Umbrella DNS Policies

Cisco Umbrella DNS Connection in the management center helps to redirect DNS queries to Cisco Umbrella. This allows Cisco Umbrella to validate requests, allow or block them based on the domain names, and apply DNS-based security policy on the request. If you use Cisco Umbrella, you must configure the Cisco Umbrella Connection (Integration > Other Integrations > Cloud Services > Cisco Umbrella Connection) to redirect DNS queries to Cisco Umbrella.

The Umbrella Connector is part of the system’s DNS inspection. If your existing DNS inspection policy map decides to block or drop a request based on your DNS inspection settings, the request is not forwarded to Cisco Umbrella. Thus, you have two lines of protection:

  • Your local DNS inspection policy

  • Your Cisco Umbrella cloud-based policy

When redirecting DNS lookup requests to Cisco Umbrella, the Umbrella Connector adds an EDNS (Extension mechanisms for DNS) record. An EDNS record includes the device identifier information, organization ID, and client IP address. Your cloud-based policy can use those criteria to control access in addition to the reputation of the FQDN. You can also elect to encrypt the DNS request using DNSCrypt to ensure the privacy of usernames and internal IP addresses.

To redirect DNS requests from the management center to Cisco Umbrella:

  1. Configure the Cisco Umbrella connection settings.

  2. Create and configure an Umbrella DNS policy.

  3. Associate the Umbrella DNS policy with an access control policy.

  4. Deploy the changes.

For detailed information about how to set up the Umbrella DNS Connector in the management center, see Configuring the Umbrella DNS Connector for Cisco Secure Firewall Management Center.

How to Redirect DNS Requests to Cisco Umbrella

This section provides instructions to redirect DNS requests from the device to Cisco Umbrella using the management center.

Step

Do This

More Info

1

Ensure that you meet the prerequisites.

Prerequisites for Configuring the Umbrella DNS Connector

2

Configure the Cisco Umbrella connection settings.

Configure Cisco Umbrella Connection Settings

3

Create an Umbrella DNS policy

Create an Umbrella DNS Policy

4

Configure the Umbrella DNS policy

Edit Umbrella DNS Policies and Rules

5

Associate the Umbrella DNS policy with an access control policy

Associate the Umbrella DNS Policy with an Access Control Policy

Prerequisites for Configuring the Umbrella DNS Connector

Table 1. Minimum Supported Platforms

Product

Version

Secure Firewall Threat Defense

6.6 and above

Secure Firewall Management Center

7.2 and above

  • Establish an account with Cisco Umbrella at https://umbrella.cisco.com, and log into Umbrella at http://login.umbrella.com.

  • Import the CA certificate from the Cisco Umbrella server to the management center. In Cisco Umbrella, choose Deployments > Configuration > Root Certificate and download the certificate.

    You must import the root certificate to establish the HTTPS connection with the Cisco Umbrella registration server. The certificate needs to be trusted for SSL server validation, which is a non-default option in the management center. Copy and paste the following certificate for the device in the management center(Device > Certificates). 

    MIIE6jCCA9KgAwIBAgIQCjUI1VwpKwF9+K1lwA/35DANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQG  
EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSAw  
HgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBDQTAeFw0yMDA5MjQwMDAwMDBaFw0zMDA5MjMy  
MzU5NTlaME8xCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxKTAnBgNVBAMTIERp  
Z2lDZXJ0IFRMUyBSU0EgU0hBMjU2IDIwMjAgQ0ExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB  
CgKCAQEAwUuzZUdwvN1PWNvsnO3DZuUfMRNUrUpmRh8sCuxkB+Uu3Ny5CiDt3+PE0J6aqXodgojl  
EVbbHp9YwlHnLDQNLtKS4VbL8Xlfs7uHyiUDe5pSQWYQYE9XE0nw6Ddng9/n00tnTCJRpt8OmRDt  
V1F0JuJ9x8piLhMbfyOIJVNvwTRYAIuE//i+p1hJInuWraKImxW8oHzf6VGo1bDtN+I2tIJLYrVJ  
muzHZ9bjPvXj1hJeRPG/cUJ9WIQDgLGBAfr5yjK7tI4nhyfFK3TUqNaX3sNk+crOU6JWvHgXjkkD  
Ka77SU+kFbnO8lwZV21reacroicgE7XQPUDTITAHk+qZ9QIDAQABo4IBrjCCAaowHQYDVR0OBBYE  
FLdrouqoqoSMeeq02g+YssWVdrn0MB8GA1UdIwQYMBaAFAPeUDVW0Uy7ZvCj4hsbw5eyPdFVMA4G  
A1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEgYDVR0TAQH/BAgw  
BgEB/wIBADB2BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0  
LmNvbTBABggrBgEFBQcwAoY0aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0R2xv  
YmFsUm9vdENBLmNydDB7BgNVHR8EdDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v  
RGlnaUNlcnRHbG9iYWxSb290Q0EuY3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20v  
RGlnaUNlcnRHbG9iYWxSb290Q0EuY3JsMDAGA1UdIAQpMCcwBwYFZ4EMAQEwCAYGZ4EMAQIBMAgG  
BmeBDAECAjAIBgZngQwBAgMwDQYJKoZIhvcNAQELBQADggEBAHert3onPa679n/gWlbJhKrKW3EX  
3SJH/E6f7tDBpATho+vFScH90cnfjK+URSxGKqNjOSD5nkoklEHIqdninFQFBstcHL4AGw+oWv8Z  
u2XHFq8hVt1hBcnpj5h232sb0HIMULkwKXq/YFkQZhM6LawVEWwtIwwCPgU7/uWhnOKK24fXSuhe  
50gG66sSmvKvhMNbg0qZgYOrAKHKCjxMoiWJKiKnpPMzTFuMLhoClw+dj20tlQj7T9rxkTgl4Zxu  
YRiHas6xuwAwapu3r9rxxZf+ingkquqTgLozZXq8oXfpf2kUCwA/d5KxTVtzhwoT0JzI8ks5T1KE  
SaZMkE4f97Q=

    When you add the certificate in the management center, ensure that you check the CA Only check box.

  • Install the certificate on the device.

  • Obtain the following data from Umbrella:

    • Organization ID

    • Network Device Key

    • Network Device Secret

    • Legacy Network Device Token

  • Ensure that the management center is connected to the internet.

  • Ensure that the base license with the export-controlled feature option is enabled in the management center.

  • Ensure that the DNS server is configured to resolve api.opendns.com.

  • Ensure that the management center can resolve management.api.umbrella.com for policy configuration.

  • Configure the threat defense route to api.opendns.com.

Configure Cisco Umbrella Connection Settings

The Cisco Umbrella Connection settings define the token that is needed to register the device with Cisco Umbrella.

Before you begin

Establish an account with Cisco Umbrella https://umbrella.cisco.com, and then log into Umbrella at https://dashboard.umbrella.com and obtain the required information to establish connection to Cisco Umbrella.

Procedure

Step 1

Choose Integration > Other Integrations > Cloud Services > Cisco Umbrella Connection.

Step 2

Obtain the following details and add them to the General settings:

  • Organization ID—A unique number that identifies your organization on Cisco Umbrella. Every Umbrella organization is a separate instance of Umbrella and has its own dashboard. Organizations are identified by their name and their organization ID (Org ID).

  • Network Device Key—The key to fetch umbrella policy from Cisco Umbrella.

  • Network Device Secret —The secret to fetch umbrella policy from Cisco Umbrella.

  • Legacy Network Device Token —An Umbrella Legacy Network Devices API token is issued through the Cisco Umbrella dashboard. Umbrella requires the API token to register a network device.

Step 3

Under Advanced, configure the following optional settings:

  • DNSCrypt Public Key—DNSCrypt authenticates and encrypts the DNS queries between the endpoint and the DNS server. To enable DNScrypt, you can configure the DNScrypt public key for certificate verification. The key is a 32-byte hexadecimal value and is preconfigured to B735:1140:206F:225d:3E2B:d822:D7FD:691e:A1C3:3cc8:D666:8d0c:BE04:bfab:CA43:FB79, which is the public key of the Umbrella Anycast servers.

  • Management Key—A key to fetch datacenter details from Umbrella cloud for VPN policy.

  • Management Secret—A secret used to fetch datacenters from Umbrella cloud for VPN.

Step 4

Click Test Connection—Test if the Cisco Umbrella Cloud is reachable from the management center. When you provide the required organization ID and network device details, the umbrella connection is created.

Step 5

Click Save.

Create an Umbrella DNS Policy

Procedure

Step 1

Choose Policies > Access Control > DNS.

Step 2

Click Add DNS Policy > Umbrella DNS Policy.

Step 3

Give the policy a unique Name and, optionally, a Description.

Step 4

Click Save.

What to do next

Configure the policy. See Edit Umbrella DNS Policies and Rules.

Edit Umbrella DNS Policies and Rules

Procedure

Step 1

Choose Policies > Access Control > DNS.

Step 2

In the DNS Policy page, select the Umbrella DNS policy that you want to edit and click Edit (edit icon).

Refresh the Umbrella Protection Policy

If you want to get the latest Umbrella Protection Policy from Cisco Umbrella, click the Refresh icon next to Umbrella Protection Policy Last Updated.

To configure or modify Umbrella Connection settings for the Management Center, go to Integration > Other Integrations > Cloud Services > Cisco Umbrella Connection.

Step 3

In the Umbrella DNS policy editor, select the Umbrella DNS rule and click Edit (edit icon).

Step 4

Configure the rule components, or accept the defaults:

  • Umbrella Protection Policy—Specify the name of the Cisco Umbrella policy to apply to the device.

  • Bypass Domain—Specify the name of the local domains for which DNS requests should bypass Cisco Umbrella and instead go directly to the configured DNS servers.

    For example, you can have your internal DNS server resolve all names for the organization's domain name on the assumption that all internal connections are allowed.

  • DNSCrypt— Enable DNSCrypt to encrypt connections between the device and Cisco Umbrella.

    Enabling DNScrypt starts the key-exchange thread with the Umbrella resolver. The key-exchange thread performs the handshake with the resolver every hour and updates the device with a new secret key. As DNScrypt uses UDP/443, you must ensure that the class map used for DNS inspection includes that port. Note that the default inspection class already includes UDP/443 for DNS inspection.

  • Idle Timeout—Configure the idle timeout after which a connection from a client to the Umbrella server will be removed if there is no response from the server.

Step 5

Click Save.

What to do next

Associate the Umbrella DNS policy with an access control policy. For more information, see Associate the Umbrella DNS Policy with an Access Control Policy.

Associate the Umbrella DNS Policy with an Access Control Policy

Before you deploy the Umbrella DNS policy on the device, you must associate it with an access control policy.

Procedure

Step 1

Choose Policies > Access Control and select the access policy to edit.

Step 2

Select Security Intelligence.

Step 3

From the Umbrella DNS Policy drop-down list, select the Umbrella DNS policy.

Step 4

Click Save.

What to do next

Deploy configuration changes; see Deploy Configuration Changes.