URL filtering and how it works

URL filtering compares the URLs that end-users attempt to access to URL categories or lists of URLs.

You can use URL filtering to prevent users from accessing websites that provide content that is objectionable, potentially harmful, or not work-related. This kind of content filtering can increase network security and enforce an organization’s policy on acceptable use of resources.

In URL filtering, the engines compare the URLs in HTTP and HTTPS requests against URL categories or lists of URLs. There are two ways to define the URLs:
  • You can use URL Category and URL Category Group elements to filter URLs based on URL categorization.
  • You can use URL List Application elements to filter specific URLs.

You can use both methods together. You can also define allowed URLs manually if a URL that you want to allow is included in a category of URLs that you otherwise want to block.

The URL categorizations are provided by the external Forcepoint™ ThreatSeeker® Intelligence Cloud service. ThreatSeeker Intelligence Cloud (ThreatSeeker) provides categories for malicious websites and several categories for different types of non-malicious content you might want to filter or log. The Secure SD-WAN Engine sends categorization requests using HTTPS to ThreatSeeker.

URL Category Group elements contain several related URL Categories. When you use URL Category Group elements in the Access rules, the rule matches if any of the URL Categories included in the URL Category Group match.

The Secure SD-WAN Engine can use the server name indication (SNI) in HTTPS traffic for URL categorization without decrypting the HTTPS connection. When a web browser contacts a server to request a page using HTTPS, the browser sends the server name in an unencrypted SNI field. However, the requested URL is not known when HTTPS connections are not decrypted.

Note: When traffic is allowed based on URL categorization, the domain name in the SNI is validated by checking the server certificate. If the certificate is not valid for the domain name in the SNI, the certificate is not within the certificate validity period, or the certificate is not issued by a CA that is trusted by the Secure SD-WAN Engine, the initial match based on SNI is invalidated.
You can use the Private Data application usage tag in Access rules to disallow decryption for traffic in predefined categories. You can also create Access rules to disallow decryption for specific categories. For example, you can create rules that prevent traffic to online banking services from being decrypted.
Note: If the end user’s browser does not use SNI and the traffic does not match rules for category-based URL filtering, the traffic might be decrypted.

You can configure the engine to respond in various ways when a match is found. For example, you can log the matches or block the traffic. If you decide to block traffic, the engine can notify end users with a message in their browsers. You can define customized User Response elements for URL filtering matches, such as a custom HTML page that is displayed to the end user when a connection is blocked.

If the engine detects that it cannot connect to ThreatSeeker, all URLs match the Data Provider Error URL Category. You can optionally add Access rules to discard all traffic that cannot be categorized.

Limitations

  • Category-based URL filtering using the ThreatSeeker Intelligence Cloud service is a separately licensed feature.
  • Category-based URL filtering is based on the categorizations of the external service, so it is not possible to manually add or directly edit the URL filtering categories. Add URL List Applications to Access rules if you want to create exceptions to the category-based URL filtering.
Note: The engine can only use one kind of URL categorization at a time. If you used legacy URL filtering with Secure SD-WAN version 6.0 or lower, you must migrate the engine to use ThreatSeeker URL filtering when you upgrade the engine to version 6.1 or higher. See Knowledge Base article 16868.