Adding custom URLs to a destination list allows Umbrella to extend a domain in a destination list to encompass full URLs. This allows you to control access to a website's pages based specifically on the full URL of that portion of the website pages.
Umbrella Packages and Feature Availability
Not all features of the policy wizard explained here are available to all Umbrella packages. To determine your current package, navigate to Admin > Licensing. For more information, see Determine Your Current Package.
If you encounter a feature described here that you do not have access to, contact your sales representative for more information. See also, Cisco Umbrella Packages.
- Block a URL
- Contact Support
For DNS policies, custom URL blocking is accomplished through the intelligent proxy, which is designed to compliment DNS-layer security. It is not intended for full URL inspection and the filtering of all web traffic. It, therefore, does not allow you to add URLs belonging to high-volume domains; for example, Google, AWS, or Facebook. If the need is to inspect URLs in high-volume domains, consider using the Web policy instead so that you can leverage Umbrella's secure web gateway (SWG), which is a full web proxy. For more information, see Configure Advanced Settings.
A root certificate is required to prevent problems when accessing SSL sites through the intelligent proxy and to ensure that SSL decryption works. Secondly, the custom URL destination list is protocol agnostic. This means that Umbrella does not expect that it's possible to know which protocol a website will use in advance; therefore, adding a protocol in front of a URL is not required when defining a destination list. Instead, with SSL decryption enabled, Umbrella can block a URL whether it's HTTP or HTTPS and thus minimize the difficulty of creating a destination list. For more information, see Manage the Cisco Umbrella Root Certificate.
To block a URL, add it to a blocked destination list, or create a new blocked destination list for URLs. You must adhere to the requirements listed at Implementing Destination Lists with URLs.
- Navigate to Policies > Policy Components > Destination Lists, expand a Destination list, add a URL, and then click Save.
Note: To block a URL, you must adhere to the requirements listed at Implementing Destination Lists with URLs to be Blocked.
URLs normalize automatically using the following criteria.
|Protocol Schema (the protocol should be stripped)||hxxp://xyz.com/test → xyz.com/test|
|Username:Password (should be stripped)||user:[email protected] → xyz.com|
|Ports (should be stripped)||xyz.com:8080/abc → xyz.com/abc|
|Trailing slashes (stripped from the end of the URL)||xyz.com/abc/ → xyz.com/abc|
URL Filtering conforms to URL Normalization standards. Certain guidelines must be followed to ensure that the URL you are entering is what you want to block or allow. These can sometimes mean that the way a URL is displayed in the browser's address bar is not how it should be specified in a destination list. This is not done automatically. You must format the URL using the guidelines listed here for it to be blocked or allowed as intended. For guidelines, see URL Normalization.
For a list of errors generated by incorrect URL addition or other reasons, see Understanding Destination lists supported entries and error messages.
If the Umbrella block page is not displayed when navigating to a URL you expect to be blocked, ensure that the policy with the destination list enabled is higher in the policy order than other policies that the enrolled identities may be part of.
Wait upwards of five minutes before testing again after any policy changes to ensure that enough time has passed for the changes to be replicated throughout Umbrella's infrastructure.
If problems persist, clear the local browser cache on your machine, or even your machine's DNS cache—a reboot will accomplish this.
Also, check to see if you have a local—on-premise—proxy that is interfering. For more information, see Using Umbrella with an HTTP proxy.
And be sure that the Cisco certificate is installed. For more information, see Install the Cisco Umbrella Root Certificate.
The Activity Search report supports the use of URLs as a search filter.
Once you've filtered for URLs, add another filter to show the custom block URLs that belong to your destination lists.
The following examples show a single URL and what you can and cannot enter to have a block of that URL enforced. The list of URLs is built-out from a single example, modifying a single parameter to show whether the URL "//a.co/cx/15195/100/setup_1848x19m.exe?z=z&super=bad&test=yes" would be blocked based on a URL.
In all of these examples, the protocol is stripped as it would be by the interface.
If you want to block this URL a.co/cx/15195/100/setup_1848x19m.exe?z=z&super=bad&test=yes the following logic applies.
|a.co/cx/15195/100/setup_1848x19m.exe?z=z&super=bad&test=yes||Yes||The full URL is entered.|
|a.co/cx/15195/100/setup_1848x19m.exe?super=bad&test=yes&z=z||Yes||"&" is a delimiter; therefore, it's added as another level to the URL after the word "yes".|
|a.co/cx/15195/100/setup_1848x19m.exe?super=bad&test=yes||No||"?" is a delimiter so the URL still would begin at the "yes" and any enforcement would happen after that.|
|a.co/cx/15195/100/setup_1848x19m.exe?||No||Given the"?", it still means only characters after "yes" will be enforced; therefore, a direct download of this file would be allowed.|
|a.co/cx/15195/100/setup_1848x19m.exe||No||We will still only block any paths after "yes"; therefore, a direct download of this file would be allowed.|
If you want to block this URL g.com/a/d, the following logic applies.
Note: These are only examples of destination list entries that would and would not block the URL "g.com/a/d".
|g.com/a/d||Yes||The full URL is entered.|
|g.com/a/d?g||Yes||Delimits the path with the query "g" but still just a delimiter thus this will be enforced.|
|g.com/a/d?||Yes||URL + the "?" delimiter.|
|g.com/a/||No||The URL ends with "/d" so anything before "/d" would not be enforced.|
|g.com/a/?a||No||The URL ends with "/d" so anything before "/d" would not be enforced.|
If you want to block this URL d.co/cx/15195/100, the following applies.
Note: These are only examples of which destination list entries would block the URL "d.co/cx/15195/100" and which would not.
|d.co/cx/15195/100||Yes||The full URL is entered.|
|d.co/cx/15195/100/?||Yes||Everything after the delimited "/" after 100 would be blocked.|
|d.co/cx/15195/100/||Yes||Everything after the delimited "/" after 100 would be blocked.|
|d.co/cx/15195/100||Yes||Everything after the delimiting "/" after 100 would be blocked.|
|d.co/cx/15195/10||No||The delimiter is only for paths after the "/" so any changes to the final path of /100/ would be ignored.|
|d.co/cx/15195/1000||No||The delimiter is only for paths after the "/" so any changes to the final path of /100/ would be ignored.|
|d.co/cx/15195/||No||The delimiter is only for paths after the "/" so any changes to the final path of /100/ would be ignored.|
There are normalization rules that most administrators will never encounter. If you find that a URL is not being properly filtered and you've confirmed that all criteria are met, see the URL Normalization RFC.
If you encounter any issues with the custom URL feature, contact Support and include the output of the following commands.
Note: These commands should be run from a device enrolled in the policy configured for custom URL blocking.
dig debug.opendns.com txt
nslookup -type=txt debug.opendns.com
Updated 5 months ago