The Cisco Umbrella integration enables a cloud-based security service by inspecting the Domain Name System (DNS) query that is sent to the enterprise DNS server through the Cisco 4000 Series or 1100 Series Integrated Services Routers (ISR). The security administrator configures Umbrella policies to either allow or deny traffic towards the fully qualified domain name (FQDN). Cisco 4000 Series or 1100 Series ISR acts as a DNS forwarder on the network edge, transparently intercepts DNS traffic, and forwards the DNS queries to the Cisco Umbrella cloud. This feature is available on Cisco IOS XE Denali 16.3 and later releases.
Note: Looking for information on the ISR G2? See ISR G2 – Configuration Guide. You can configure our DNS servers with an ISR G2, but there is no integration with Umbrella.
16.6.1 was released to General Availability in late July 2017. Features have changed and improvements to the internal mapping of IPs have been made. There are significant differences between the command line interfaces; thus, if you are running 16.6.1, see Release Notes for Cisco 4000 Series ISRs, Cisco IOS XE Everest 16.6 and Security Configuration Guide: Cisco Umbrella Integration On Cisco 4000 Series ISRs.
Support for the ISR 1100 Series was made available in February 2018. DNSCrypt on the ISR 1100 requires minimum software version: 16.6.3, 16.7.2, or 16.8.1. The integration for the ISR 1100 is exactly the same as with the 4000 series and should be followed according to the steps for the 4000 series.
- What is a Cisco Umbrella Integration?
- Security Blocking and Installing a Certificate on Endpoints
- Limitations and Restrictions of the Cisco Umbrella Integration
- Encrypt the DNS Packet
- Supported and Recommended Configurations for Reporting and Attribution
- Upgrade the Device Image to Cisco IOS XE Denali 16.3
- Upgrade the ROMMON
- Configure Cisco Umbrella
- Cisco Umbrella Tags
- Obtain API Token from Umbrella
- Configure Cisco Umbrella on the ISR
- Verify the the Cisco Umbrella Configuration
- Deploy Umbrella Using Cisco Prime CLI Templates
- Test Configuration
- Log into Umbrella for the First Time
- Test Configuration
- Configure Umbrella Policy for the ISR
- Auto-attach a Pre-existing Policy for Future ISRs
- Add, Manage, and Remove ISRs From Umbrella
The Cisco Umbrella integration feature provides a cloud-based security service by inspecting the DNS query that is sent to an enterprise DNS server through Cisco 4000 and 1100 Series ISRs. When a host initiates the traffic and sends a DNS query, the Cisco 4000 and 1100 Series ISR intercepts and inspects the DNS query. If the DNS query is for a local domain, it forwards without changing the DNS packet to the DNS server in the enterprise network. If the DNS query is for an external domain, it adds an Extended DNS (EDNS) record to the query and sends it to the Cisco Umbrella cloud. An EDNS record includes the device identifier information. Based on this information, the Cisco Umbrella cloud service applies different policies to the DNS query. Cisco Umbrella allows or blocks the request and returns the appropriate IP address in the DNS response.
Before you configure the Cisco Umbrella integration feature on the Cisco 4000 Series ISR, ensure that you have the following:
- The minimum ROMMON version to load the Cisco IOS Denali 16.2 image on a Cisco 4000 Series ISR is 16.2(1r).
The Cisco 4000 Series ISR runs the Cisco IOS XE Denali 16.3 software image or later.
- You can upgrade from any ROMMON version to release 16.2(1r). For more information, see the Upgrading the Device Image to Cisco IOS XE Denali 16.3 section of this guide.
- The Cisco 4000 Series ISR must have a security K9 license to enable Cisco Umbrella.
- A valid Cisco Umbrella subscription license.
- The Cisco 4000 Series ISR should be set as the default DNS server gateway. Ensure that DNS traffic goes through the Cisco 4000 Series ISR.
The following network requirements must be met:
- For initial registration—The opendns_out interface (this may have a different name if you so choose) must be able to access api.opendns.com over port 443 in order to complete initial registration.
- TCP & UDP on port 53 (DNS) to 22.214.171.124 & 126.96.36.199 (The Cisco Umbrella public DNS resolvers)
- DNSCrypt—If there are any devices in front of the ISR that may block DNSCrypt for not looking like an actual DNS packet, the DNSCrypt feature may not work. For more information and an example of the problem, see Cisco ASA Firewall blocks DNSCrypt .
Based on the domain (FQDN) that is being queried, Umbrella determines if the IP addresses should be provided in the response. If the domain is deemed to be malicious or hosting malicious content or blocked by a customized security policy, the IP address of the Umbrella block page server is sent back in the DNS response instead of the IP address of the domain.
When the HTTP client on the host sends an HTTP request to the Umbrella cloud IP address, Umbrella provides the reason for blocking the content in the HTTP response, this is the ‘block page.'
If the blocked domain is from the HTTPS request, the client’s web browser displays a certificate error message. The error message is displayed because the Umbrella cloud may not have the certificate from the blocked server.
In order to resolve these issues, we highly recommend installing the Cisco root certificate on your clients. For more information, see Install the Cisco Certificate.
- If an application or host makes a direct IP layer connection without using DNS, policy enforcement will not be applied.
- When the client is connected to a web proxy, the DNS query does not pass through the ISR. In this case, the connector will not be able to detect any DNS request and the connection to the web server will bypass any policy from Cisco Umbrella.
- Using in conjunction with Cloud Web Security (CWS): When the Cisco Umbrella policy blocks a DNS query, the client is redirected to a Cisco Umbrella block page. HTTPS servers provide these block pages and the IP address range of these block pages is defined by the Cisco Umbrella. These web server addresses should be allowed listed for Cloud Web Security (CWS), so that CWS allows the client to get the blocked page from Cisco Umbrella's web servers.
- User authentication and identity is not supported in this release.
- Only queries for A and AAAA record types are redirected to the cloud. Other query types will bypass the connector. However, the TXT type DNS queries to debug.opendns.com are redirected.
- IPv6 is not supported in this release for Umbrella block pages or policy enforcement.
- A maximum of 64 local domains can be configured, and the allowed name length is 100 characters for each of these domains.
- If you use the multiple EDNS options, the Cisco Umbrella policy may not get applied on the device. For the work-around, contact Cisco Technical Support to get the engineering special image which will resolve this issue.
- If the WAN interface is down for more than 30 minutes, the device may reload with an exception. Disable DNSCrypt to stop this exception. If you do not want to disable DNSCrypt, contact Cisco Technical Support to get the engineering special image which will resolve this issue.
The DNS packet sent from the Cisco ISR to the Umbrella's servers must be encrypted if the EDNS information in the packet contains information such as user IDs and internal network IP addresses. When the DNS response is sent back from the DNS server, Cisco ISR decrypts the packet and forwards it back to the host.
You can encrypt DNS packets only when the DNSCrypt feature is enabled on the ISR. Based on the FQDN in the DNS query, the Cisco Umbrella service determines if the content provider IP addresses should be provided in the response. If the FQDN is malicious or blocked by the customized enterprise security policy, the Umbrella block web page server address is sent back in the DNS response. When the HTTP client on the host sends an HTTP request to the Umbrella cloud IP address, it provides the reason for blocking the content in the HTTP response.
If the blocked domain is from the HTTPS request, the client’s web browser displays a certificate error message. This error message is displayed because the Umbrella cloud may not have the certificate from the blocked server. The ISR will use the following Anycast recursive Umbrella servers:
There are two ways to structure the way DNS traffic is handled with the ISR on the LAN, and both are supported configurations, but only one is recommended. The recommended approach is to use transparent DNS interception and route traffic appropriately with the ISR. This gives the ability to show the IP of the requesting endpoint in Umbrella's reporting, rather than the IP of the internal DNS server. In turn, this makes attribution of the endpoint making the DNS request much easier.
The preferred configuration is to have the endpoint's DNS server be the internal DNS server for the network, but use the ISR to route traffic to either the internal or external DNS resource, based on defined subnet.
If you would like to add the user and group mappings, a VA is required to connect to Active Directory and gather information about the logged in user. The VA sits behind the ISR and is the primary DNS server for all clients. For more information about VAs, see the Virtual Appliance Setup Guide.
You need to upgrade to the Cisco IOS XE 3.16 version before you upgrade the router image to the Cisco IOS XE Denali 16.3 or later version.
After you upgrade to Cisco IOS XE 3.16 version, upgrade the ROMMON. To upgrade the ROMMON version, download the correct version at Cisco's Software Download page.
For more information, see ISR4K documentation.
- Download the rommon image and upload it to flash using tftp, scp, or use a usb key.
- Use the upgrade rommonitor filename bootflash command to upgrade the ROMMON.
Device# upgrade rommonitor filename bootflash:rommon_isr_usd_rel_ios_package_SSA.bin16_2_1r R0 Chassis model ISR4321/K9 has a single rommonitor. Upgrade rommonitor Target copying rommonitor image file selected : 0 Booted : 0 Reset Reason: 0 Info: Upgrading entire flash from the rommon package 4259840+0 records in 4259840+0 records out 262144+0 records in 262144+0 records out 655360+0 records in 655360+0 records out 4194304+0 records in 4194304+0 records out File is a FIPS ROMMON image FIPS1403 Load Test on has PASSED. Authenticity of the image has been verified. Switching to ROM 1 8192+0 records in 8192+0 records out Upgrade image MD5 signature is b702a0a59a46a20a4924f9b17b8f0887 4259840+0 records in 4259840+0 records out 4194304+0 records in 4194304+0 records out 4194304+0 records in 4194304+0 records out 262144+0 records in 262144+0 records out Upgrade image MD5 signature verification is b702a0a59a46a20a4924f9b17b8f0887 Switching back to ROM 0 ROMMON upgrade complete.
- To make the new ROMMON version as the permanent version, you must restart the RP.
- After the upgrade is complete, reload the device. Ensure that you issue the show platform command to verify that the ROMMON upgrade is successful. The firmware version should be 16.2(1r).
This portion of the document outlines how to configure an ISR to register with the Umbrella dashboard as a Network Device and enforce policy based on Device ID as well as Tags.
The process of registration is fairly straightforward. In order to authenticate the ISR to the Cisco Umbrella dashboard, a token must be obtained from your Umbrella dashboard and installed on the ISR.
Then you simply log into the device's command interface and follow the steps below to configure your ISR. Once completed, the ISR will register as a device in your Umbrella dashboard and a policy can then be defined for the ISR or any additional tags.
A Cisco Umbrella tag is essentially another network that is behind the ISR that can be registered alone and given its own Device ID in the Umbrella dashboard. This can be a VLAN or a physical interface. Each tag will use the same API Token, so minimal extra configuration is needed to register a newly tagged interface. Tags are not unique, but the combination of Model + MAC Address + Tag is unique within an organization.
The screenshot below shows two Network Devices as listed in the Umbrella dashboard. They look like two separate devices but they are the same ISR, just with different interfaces tagged for different VLANs. Tags can be used to auto-assign policy; this is covered later in this guide.
You will need to get your Network Device API Token from your Umbrella dashboard.
- Navigate to Deployments > Core Identities > Network Devices and click API Token.
The API token is a long alphanumeric set of characters.
- Copy the API token to your clipboard or to a text file so that you can complete the next steps.
- API token from Umbrella
- Root certificate to establish the HTTPS connection with the Cisco Umbrella registration server.
Import the root certificate of DigiCert given below into the device using the crypto pki trustpool import terminal command.
Communication for device registration to the Umbrella server is through HTTPS. This requires a root certificate to be installed on the router.
While in the Configure Terminal (conf t), run the following commands on your ISR. There are two choices, one of which is to simply import the certificate directly from Cisco.
crypto pki trustpool import url http://www.cisco.com/security/pki/trs/ios.p7b
The second option is to use the import terminal, then paste the certificate and the word quit after it.
To download this certificate directly from a link instead of pasting it in, click here
The contents of the certificate are also below and can also be copied from this document, although the download is less prone to error.
The commands are listed here first, then with the certificate, then a last step to finalize the upload:
crypto pki trustpool import terminal % Enter PEM-formatted CA certificate.
% End with a blank line or "quit" on a line by itself. quit % PEM files import succeeded.
Verify that the PEM import is successful. You should receive a message after importing the certificate.
Next, while still in Configure Terminal on the ISR (conf t), add the API token to the ISR by running the following commands, substituting the <API TOKEN> variable with your token:
parameter-map type opendns global token <API TOKEN>
This is the sample configuration:
￼enable configure terminal parameter-map type opendns global token AABBA59A0BDE1485C912AFE472952641001EEECC local-domain dns_bypass udp-timeout 25 (The range is from 1 to 30 seconds). dnscrypt public-key key (Key should contain only hexadecimal digit). resolver ipv4 10.1.1.2 exit
If a 400 error is seen when trying to add the API token, verify that the correct token is being used.
Additional configurations listed in the configuration are discussed later in this documentation.
- Configure the OpenDNS parameter map as shown in the previous section.
- Configure the OpenDNS Out on the WAN interface:
interface gigabitEthernet 0/0/0 opendns out
- Configure the OpenDNS In on the LAN interface:
interface gigabitEthernet 0/0/1 opendns in mydevice_tag
Note: The length of the hostname and OpenDNS tag should not exceed 49 characters.
- After you configure the OpenDNS In with a tag using the opendns in mydevice_tag command, the ISR will register the tag to the Cisco Umbrella portal.
- The ISR will initiate the registration process by resolving api.opendns.com. You need to have a name server (ip name-server x.x.x.x) and domain lookup (ip domain-lookup) configured on Cisco ISR to successfully resolve the FQDN.
Note: Configure the OpenDNS Out command before you configure OpenDNS In command. Registration will be successful only when port 443 is in an open state and allows the traffic to pass through the existing firewall.
You can identify the traffic to be bypassed using domain names. This can be useful for directing internal DNS traffic to your local DNS servers. In the Cisco ISR, you can define these domains in the form of a regular expression. If the DNS query that is intercepted by the ISR matches one of the configured regular expressions, then the query is sent to the specified DNS server without redirecting to the Cisco Umbrella cloud.
This sample configuration shows how to define a regex parameter-map with the desired domain name and regular expressions:
Device# configure terminal Device(config)# parameter-map type regex dns_bypass Device(config)# pattern www.fisco.com Device(config)# pattern .*engineering.fisco.* _Attach the regex param-map with the OpenDNS global configuration as shown below:_ Device(config)# parameter-map type opendns global Device(config-profile)# local-domain dns_bypass
When you configure the parameter-map type opendns global command, the following values are auto-populated:
- Resolver IP
It is recommended that you only change the above parameters when performing certain tests in the lab. These parameters are reserved for future use. If you modify these parameters, it can affect the normal functioning of the device.
The following commands will change the redirection of DNS packets from ISR to the Cisco Umbrella cloud:
- resolver ipv4 188.8.131.52
- resolver ipv4 184.108.40.206
- resolver ipv6 1234::1
- resolver ipv6 2345::1
In this example, all the IPv4 DNS packets are redirected to 220.127.116.11 or 18.104.22.168 and IPv6 DNS packets are redirected to 1234::1 or 2345::1. You should remove the IP address to restore to the default values of the resolver. When you modify a resolver IP address, a message is displayed as shown below:
￼User configured would overwrite defaults Defaults are restored when no more user configured are present
With the default values of 22.214.171.124 and 126.96.36.199, all the DNS packets are redirected to the Cisco Umbrella Anycast resolvers. Cisco ISR uses the first default resolver IP address for all its redirection. When the ISR does not receive a response for three consecutive DNS queries, the ISR automatically switches to a different resolver IP address. This behavior remains the same for IPv6 resolver addresses.
Public-key is used to download the DNSCrypt certificate from the Cisco Umbrella cloud. This value 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 Cisco Umbrella Anycast servers.
If there is a change in the public-key and if you modify this command, then you have to remove the modified command to restore the default value. If you modify the value, the DNSCrypt certificate download can fail.
DNSCrypt is an encryption protocol to authenticate communications between the Cisco ISR and Cisco Umbrella.
When the parameter-map type opendns is configured and opendns out is enabled on the WAN interface, DNSCrypt is triggered and a certificate downloaded, validated, and parsed. A shared secret key is then negotiated, which is used to encrypt the DNS queries. DNSCrypt downloads this certificate every hour and verifies it for upgrade. As well, a new shared secret key is negotiated to encrypt the DNS queries.
To disable DNSCrypt, use the no dnscrypt command and to re-enable DNSCrypt, use the dnscrypt command. When the DNSCrypt is used, the DNS request packets size will be more than 512 bytes.
Ensure that you allow these packets passage through intermediary devices; otherwise, the response may not reach the intended recipients.
You can verify the Cisco Umbrella configuration using the following commands:
Router# show opendns config
Open DNS Configuration ======================== Token: AAAAAD288BA440D10E207350339F497A001CCBBB Local Domain Regex parameter-map name: NONE DNSCrypt: Not enabled Public-key: NONE Timeout: NONE Resolver address: NONE Open DNS Interface Config: Number of interfaces with "opendns out" config: 1 1. GigabitEthernet0/0/1 Mode : OUT Number of interfaces with "opendns in" config: 1 1. GigabitEthernet0/0/0 Mode : IN Tag : test1 Device-id: ...Pending...
Device# show opendns deviceid
Device registration details Interface Name Tag Status Device Id GigabitEthernet0/0/0 test1 REQ QUEUED - GigabitEthernet0/0/0.1 test498 200 SUCCES 010af8cde579a997 GigabitEthernet0/0/0.2 utah-win-intf 200 SUCCES 010a0a25d20088b8 GigabitEthernet0/0/0.3 utah-win-intf 200 SUCCES 010a0a25d20088b8 GigabitEthernet0/0/0.4 mydevice_tag REQ QUEUED -
Device#show opendns dnscrypt
DNSCrypt: Enabled Public-key: B735:1140:206F:225D:3E2B:D822:D7FD:691E:A1C3:3CC8:D666:8D0C:BE04:BFAB:CA43:FB79 Certificate Update Status: Last Successful Attempt : 10:55:40 UTC Apr 14 2016 Last Failed Attempt Certificate Details: Certificate Magic : DNSC Major Version : 0x0001 Minor Version : 0x0000 Server Public-key: : 10:55:10 UTC Apr 14 2016 ED19:BFBA:FAFC:9257:DFDC:68C7:69BF:AC24:94CD:743F:3C1D:4966:134D:FE2C:4BDC:F315 Query Magic Serial Number Start Time End Time : 0x717744506545635A : 1435874751 : 1435874751 (22:05:51 UTC Jul 2 2015) : 1467410751 (22:05:51 UTC Jul 1 2016) Client Public key : 106AE7C2373E5EA68FF90FDA116912D67AF16751F3EEABCB5D8CAAD565D8A44E
You can use the Cisco Prime CLI templates to provision the Cisco Umbrella deployment. The Cisco Prime CLI templates make provisioning Cisco Umbrella deployment simple.
Note: The Cisco Prime CLI template is supported only on Cisco Prime version 3.1 or later.
- From Cisco Prime Web UI, navigate to Configuration > Templates > Features & Technologies.
- Expand Feature Templates > Router Security and select OpenDNS.
- Select a template and click Import.
- OpenDNS—To provision OpenDNS connector on Cisco ISR.
- OpenDNS Cleanup—to remove previously configured OpenDNS connector on Cisco ISR.
After the device has been registered, there are some basic and advanced tests that can be performed. These ensure the ISR has been correctly registered and that Cisco Umbrella can see traffic coming from the ISR as well as that you can see the ISR and traffic related to it in the Umbrella dashboard.
Note: You should use a client that has the IP address of the ISR as its DNS server. In a small “branch office” scenario or in a lab/test environment, this may already be the case; however, in a larger environment, this may not be the case. If necessary, change the DNS server for the client to the ISR in order to generate traffic for these tests.
You can troubleshoot issues that are related to enabling Cisco Umbrella feature using these commands:
- debug opendns device-registration
- debug opendns config
- debug opendns dnscrypt
You can run this command from the client device:
- Use the nslookup -type=txt debug.opendns.com 188.8.131.52 command from the command prompt of the Windows machine
- Use the nslookup -type=txt debug.opendns.com 184.108.40.206 command from the terminal window or shell of the Linux or OS X machine.
The return from either test should include a device field in the output. Below is a sample output when the client machine is configured to use Google’s public DNS server.
As you can see below, the Device ID is passed to Umbrella's DNS service in the query yet it still shows the server that was being queried as 220.127.116.11. This shows a perfectly executed DNS hijack by the ISR. If it is NOT intercepting traffic, the results will be much shorter than what’s displayed below.
user$ nslookup type=txt debug.opendns.com 18.104.22.168 Server: 22.214.171.124 Address: 126.96.36.199#53 Nonauthoritative answer: ￼￼￼￼ ￼￼￼debug.opendns.com text = "server 1.nyc" [This is the specific resolver the query ran against] ￼￼￼debug.opendns.com text = "device 010AFE48555956EC" ￼￼￼debug.opendns.com text = "flags 422 0 5040 19FD000780000000000" ￼￼￼debug.opendns.com text = "originid 44491141" ￼￼￼debug.opendns.com text = "orgid 300727" debug.opendns.com text = "actype 0" ￼￼￼debug.opendns.com text = "bundle 399367" ￼￼￼debug.opendns.com text = "source 188.8.131.52::47726" [This is the egress IP that ￼￼Cisco Umbrella saw the query come from] ￼￼￼debug.opendns.comtext = "dnscrypt enabled (717473654A614970)"
To check that the block page will be returned as expected from a client using the ISR to pass DNS traffic through:
- Linux or OS X—From the terminal window or shell:
- Windows—From the command prompt:
In return, you will receive the IP address of the Cisco Umbrella block page:
Authenticate to the Umbrella dashboard by going to http://dashboard.umbrella.com and logging into the dashboard with your account information.
Upon first logging in, you will see an Overview report of traffic from your organization. Traffic can take up to 90 minutes to first begin populating in the dashboard, after which, the reporting should be real-time.
- Navigate to Reporting > Core Reports > Activity Search to see the real-time traffic.
- Navigate to Deployments > Core Identities > Network Devices to check whether the ISR has registered as a device in the Umbrella dashboard.
If successfully registered, the ISR appears here.
Clicking a Device Name expand the windows. You can rename the device and delete a device from the dashboard.
- Click How to remove this device to access Delete.
Once your ISR is configured and appears as a Network Device in Umbrella, any traffic sent from an endpoint device (laptop, workstation, server or any other network connected device) behind the ISR will appear in the Umbrella dashboard as Activity.
If internet availability is not a problem, navigate to Reporting > Core Reports > Activity Search.
The traffic from the device to the ISR, then to Cisco Umbrella should appear here as Activity.
To test to see if basic security filtering is already in place, go to http://internetbadguys.com in the browser of your test device.
The website should display a blocked message in the browser if everything is working correctly.
Alternately, running a dig or nslookup against that website from the command line will also generate traffic.
Return to the Umbrella dashboard, click Reporting > Security Activity and run the report. A block for “Phishing” should appear in the report.
Next, configure your policy with the policy wizard. Depending on your preference, you may wish to create a new policy or simply modify the Default policy to suit your needs.
These steps apply when creating your first policy, or when going back to edit an existing policy. By default, there's always a single policy—the Default policy. This policy applies to all identities when no other policy above it covers that identity. In other words, the Default policy is a catch-all to ensure all identities within your organization receive a baseline level of protection. For more information about policies, see Create and Apply Policies.
To start building and understanding your policies:
- Navigate to Policies > Management > All Policies and click Add or expand the default policy.
If you select the default policy, all identities are selected so the second step can be skipped.
- Select the identities to which the policy will be applied.
If you have a single ISR configured as a device in your dashboard, select that identity and click Next.
If you have more than one, you can select all ISRs in a group.
- Select what you want this policy to do.
The four options shown correspond to policy features: security settings, IP layer enforcement, content category blocks and custom destination lists.
- Enforce Security at the DNS Layer—These are settings related directly the blocking of domains based on whether they are malicious and provides a base level of security protection. We recommend always selecting this.
- Inspect Files—Selectively inspect files in the cloud, not on premises, so there is no need for additional hardware. The inspection is done with Cisco AMP and an antivirus. For more information, see Enable File Inspection.
- Limit Content Access—These settings filter types of content based on your Organization's acceptable use policies, typically this is recommended.
- Apply Destination Lists—If you have particular domains you'd like to allow or block, add them to a destination list. There are two by default, block or allow, and you can create more to organize groups of domains. The two defaults are the "Global" lists, meaning they apply to any policy. It's up to you whether you have anything in particular you'd like to block right away.
Underneath the options for what the policy should do, you'll find Advanced Settings.
These include the Intelligent Proxy, SSL Decryption, Enforce SafeSearch, Allow-Only Mode and logging options. For more information, see Create and Apply Policies.
Once you've picked what the policy should do, click Next.
- Configure security settings and click Next.
These settings determine which security type threats are blocked. For more information on what each of these categories represents, see Understanding Security Categories.
- Configure content access settings and click Next.
These settings filter types of content based on your Organization's acceptable use policies. These settings allow the selection of content categories to be blocked for the devices selected in the second step of the policy editor. To create a new set of content filtering rules, choose "Create New Setting" from the Custom Setting drop-down list. For a list of all categories and details for each, see Understanding Content Categories.
- Apply destination lists and click Next.
If you have particular domains you'd like to allow or block, add them to a destination list. There are two by default, block or allow, and you can create more to organize groups of destinations. Note that each destination list can be set to be a block list (default) or an allow list. We recommend adding domains in the format "domain.com" rather than www.domain.com to ensure *.domain.com is included. Allow list entries will always take precedence over block list entries.
- Set a block page and click Next.
You can optionally create a unique block page for your users, as well as how to bypass that block page. Default settings are selected by default and will display the Cisco Umbrella block page and the type of block if and when users reach blocked content.
- Give your policy a good meaningful name, review settings, and click Save.
The name of a policy is not purely cosmetic, the next section of this document outlines how to 'auto-attach' a pre-existing policy for future ISRs.
A helpful feature is to add a policy for an ISR in advance of that device being added to the Umbrella dashboard. This means that as soon as the device is registered, the policy applied to it will be whatever you’ve configured and there will be no need to manually add the device to an existing policy.
A normal use case is when you have a large number of ISR boxes. Each ISR would register a “guest” and a “corp” tag. We’d want all of those “guest” devices to go into the same “guest” policy.
When a Network Device registers with a tag, the API will check to see if there are any policies with that exact same name (aka Policy Description) as the tag. If such a policy exists, the newly registered Network Device will immediately be assigned this policy. The name must match the tag exactly (although it is not case sensitive). This process only occurs at the time of registration, so if a policy is created after registration, you will need to assign existing Network Devices to it manually.
Tags are not unique, but the combination of Model + MAC Address + Tag is unique within an organization.
If you wish to add additional ISRs, simply authenticate these devices with Cisco Umbrella as you've done with the devices that are already present in the dashboard.
The information about a device, such as Serial Number and Device Name can be set by the device itself, but it can be changed in the Umbrella Dashboard in case the Device Name is not helpful or is a duplicate. Where applicable, it's a good idea to include information about the physical location or network address of the device.
To manage the list of devices, use the Filter functionality or group the devices together.
To remove a device, you must remove the authentication (username/password or API token) from the device first or simply take the device offline if you're decommissioning it. Otherwise,
even if it has been deleted from the dashboard, the device will reappear in the dashboard when it sends additional traffic.
Once authentication has been removed from the device, it can be deleted from the dashboard by clicking How to remove this device", then clicking Delete.
Integration for ISR 4K – Security Configuration Guide > Wireless LAN Controller Integration