About URL Filtering
With URL filtering, you can limit your exposure to liability by managing access to web content based on a site’s reputation. To allow granular control of filtering, the service organizes URLs into a hierarchy of categories. There are six predefined classes, which are then each divided into predefined super-categories, and then further into predefined categories. The six predefined classes are:
- Bandwidth Loss
- Business Use
- General Surfing
- Legal Liability
- Productivity Loss
- Security Risk
You can limit access at the super-category level or drill down further into categories, depending on the needs of your organization. In addition to the predefined categories, you can create custom categories. Custom categories can be based on URLs or on keywords within the URLs or page content. You can also add custom URLs and keywords to a predefined URL category.
To ensure that even the newest URLs in your chosen categories are effectively blocked, the service leverages an extensive database that is updated daily with feeds from various partners (for example, Google Safe Browsing). When any given URL is not already covered by the database, the Zscaler service uses its Dynamic Content Classification (DCC) engine to scan the page for any content that would place it the predefined Legal Liability class. The URL is then classified and the original request for the page is handled according to your organization’s policy for URLs in that class. (To use this feature, ensure that Dynamic Content Classification is enabled.)
The URL filtering policy consists of rules that you define. When you add a rule, you specify criteria, which includes URL categories, users, groups, departments, locations, and time intervals. See the recommended policy for URL filtering.
Note that by default, the Cloud App Control policy takes precedence over the URL filtering policy. The service will apply the Cloud App Control policy to a web transaction before applying the URL Filtering policy. To change this setting and have the service apply the URL Filtering policy before the Cloud App Control policy, go to Advanced Settings and disable Allow Cascading to URL Filtering.
For information on the order in which the service enforces all policies, including this policy, see How does the Zscaler service enforce policies?
Associating Rules with EUNs
You can create rules that block or caution users and associate them with specific EUNs. For example, your organization has two networks and they each have a Web server that hosts an EUN. You can create two different rules that redirect users to the appropriate EUN.
Note that the EUNs that you specify in the rules take precedence over the default EUN that you configure in the Administration > End User Notifications page. Therefore, when a user is blocked or warned due to a rule that is associated with an EUN, the service displays the EUN associated with the rule and not the default EUN.
When you configure a rule, you can specify one of the following actions:
- Allow: The service allows access to the URLs in the selected categories. You can still restrict access by specifying a daily quota for bandwidth and time. For example, you can allow your users to access Entertainment and Recreation sites, but restrict the bandwidth allowed for these sites so they don't interfere with business critical applications. The daily time quota is based on the time that the rule is created. For example, if the rule is created at 11 a.m. PST, then the quota is renewed at 11 a.m. the next day.
- Caution: When a user tries to access a site, the service displays a Caution notification. You can use the system-defined notification, customize the text, or create your own notification and direct users to it.
- Block: The service displays a Block notification. You can use the system-defined notification, customize the text, or create your own notification and direct users to it.
Additionally, you can allow some users or groups to override the block. For example, you can block students from going to YouTube, but allow the teachers. They will be prompted to enter their override password, which is their login password if your organization uses a one-time token or hosted database without SAML or their system password if your organization uses AD/OpenLDAP or SAML for authentication. You can also send the override password through email. Users will be allowed to access the blocked page only during their current browser session. They will be required to re-authenticate when they try to access it in another browser session.