Transcript
In this series of short videos, we'll be taking a look at recommendations for the configuration of URL filtering. This is Part 1, Understanding URL Filtering. Before we talk about URL filtering, let's start with a brief reminder of the Zscaler Internet Access Architecture. When a user whose traffic is secured by ZIA browses the Internet, their traffic is routed through Zscaler public service edges, which connect to a central authority, to know what policies to enforce on the user's traffic. Public service edges enforce all controls inside the ZIA stack, following a defined order of operations. It's worth understanding the order of operation and how they are separated into two modules. URL filtering and cloud app control are both part of the proxy module. This module is evaluated after the cloud firewall module has made the decision to allow or block traffic. This means that if specific traffic is blocked in firewall control, it will be blocked for the user regardless of any configured URL filtering policy for that traffic. Only when traffic is allowed in the cloud firewall policy are the URL filtering and cloud app control policies evaluated. Zooming in on just the proxy module, here is the order of operation for the different policies. First, security exceptions are evaluated, and if traffic matches the configured exceptions, then no advanced threat protection or known malware controls are applied. Otherwise, ZIA will proceed to make the decision to block or allow the traffic based on the known reputation of the destination URL. The destination URL will then be evaluated, first by the cloud app control module, then by the URL filtering module. This order of operations is very important to understand, as it means that policy configured in cloud app control, such as blocking access to specific cloud apps, can override policy configured in URL filtering. It's important when configuring URL filtering and cloud app control policies to ensure that they work together and not at cross-purposes. If traffic is allowed by the cloud app control and URL filtering policies, ZIA will continue on to evaluate other security policies in order, including browser control policy, country-based blocks, IPS signature evaluation, file type controls, sandbox policy, known malware protection, and data loss prevention policies. Policy evaluation will continue sequentially until either a block action is applied, or all checks result in an allow action. Next, it's also important to understand how SSL inspection plays into this. Although URL filtering and cloud app control are part of the access control layer in this model, it's important to know that for TLS encrypted traffic, Zscaler can only see the domain in the SNI or in the server certificate if there is no SNI, unless that traffic is inspected. This means the ability to enforce access control is fairly limited on traffic that is encrypted but not inspected. Keep this in mind when building your SSL inspection policy to ensure you are able to apply proper access controls to encrypted web traffic. Before we move on to talk about URL filtering policy, we need to talk about URL category exact matching. As with other modules in ZIA, URL filtering rules are evaluated top-down. Traffic is checked against every rule starting with the topmost rule, and once that traffic is matched, no further rules are evaluated. However, there's one aspect of how URL filtering policy works that is different from the other modules. By design, traffic to a specific FQDN will always match URL categories that include that exact FQDN over URL categories with a wildcard containing that FQDN. This means that if you have a rule to block the wildcard.example.com in position 1 in your URL filtering policy, and a rule to allow site.example.com in position 2, a user browsing to site.example.com will match rule 2, even though site.example.com falls within the .example.com wildcard. URL filtering policy will always privilege the longest match possible. Note that if a URL matches a category with exact match, the category belonging to the matched policy at the moment the action is logged is the one that will be displayed in the logs. If a URL matches multiple categories with exact match, then the category with the lowest ID will be shown. Let's look at an example to illustrate this behavior. Here we have two URL categories. Category 1 contains docs.github.com. Category 2 contains the wildcard.github.com. We've built a rule to allow category 1 for user A and a rule to block category 2 for user B. Since there is no rule blocking category 1 for user B, and docs.github.com will exact match category 1, rule 2 here will not apply and access to docs.github.com for user B will be allowed by the default implicit allow. To fix this, we will need to add docs.github.com to category 2, so that exact matching triggers this block rule for that FQDN. Alternatively, you could add category 1 to the rule blocking user B. Finally, let's take a look at where URL filtering sits inside the kill chain. First, URL filtering is applied very early on in the kill chain. A properly configured URL filtering policy will block malicious traffic at the earliest stages, when malicious actors are first trying to gain entry into your environment by distributing malware via phishing emails. Secondly, URL filtering will also serve to block command and control traffic if a user's system is infected, reducing the amount of damage malware is able to do once it has gained a foothold inside your IT environment. That's it for this video. Thank you for watching!
