5.3 URL Filtering

What URL Filtering Does

URL Filtering (URLF) is the Check Point blade that controls which web destinations users can reach. It works at the URL level: when a user makes an HTTP or HTTPS request, the gateway looks up the destination URL in a category database and applies policy based on the category.

URLF answers a different question than Application Control. Application Control asks "what application is this?" URLF asks "where is the user going?" A user visiting https://www.example.com/gambling/page.html is using the HTTPS application (Application Control) and visiting a Gambling-category site (URLF). The two blades are complementary and frequently configured together.

Categories and Cloud Categorization

The URL category database is maintained by Check Point ThreatCloud. ThreatCloud is Check Point's cloud-based threat intelligence platform; it aggregates reputation and categorization data from Check Point's research teams, third-party feeds, and telemetry from participating gateways worldwide.

Categories cover the full range of web content: News, Social Networks, Gambling, Adult, Hacking, Phishing, Malware Sites, Job Search, Streaming Media, Finance, Health, Education, Government, and many more. Each URL in the database is mapped to one or more categories. Updates are pushed to gateways continuously; administrators do not need to manually refresh the database, though a periodic refresh can be triggered.

For the CCSA, the key facts are:

• The category database lives in ThreatCloud.
• The gateway queries ThreatCloud for the category of a URL it has not seen before.
• Categories are pre-defined; administrators do not create new global categories, they create local overrides.

Custom Sites and Overrides

Administrators can add custom sites to override the cloud categorization for specific URLs, domains, or URL patterns. Common reasons:

• A business-critical site is miscategorized by ThreatCloud (e.g., a competitor's site classified as Gambling).
• An internal site should be treated as a specific category for policy reasons.
• A newly created site has not yet been categorized by ThreatCloud.

Custom site entries are stored locally on the Security Management Server and pushed to gateways in the policy. They take precedence over the cloud category. The CCSA expects you to know that custom sites are local overrides and that they win over cloud categorization.

Actions Per Category

URLF is configured inside a TP profile. For each category, you choose an action:

A typical URLF policy blocks Malware Sites, Phishing, and Gambling; redirects Hacking and Anonymizer categories to a corporate warning page; and accepts News, Education, and Finance. The profile-level configuration also lets you set a default action for uncategorized sites.

HTTPS and the Need for HTTPS Inspection

URLF works straightforwardly on cleartext HTTP: the gateway sees the full URL including path and query, and looks up the category.

On HTTPS, the picture is more complicated. By default, the gateway can see only the SNI (Server Name Indication) field in the TLS ClientHello, which contains the server hostname (e.g., www.example.com), not the path. The gateway can categorize by hostname, but not by full URL path.

To get full-path categorization on HTTPS, the gateway must decrypt the connection. That is the job of HTTPS Inspection, covered in section 5.8. Without HTTPS Inspection enabled, URLF can still categorize HTTPS requests by hostname/SNI, but not by full path. With HTTPS Inspection enabled, URLF sees the full URL just as it does on HTTP.

CCSA scenarios frequently test this dependency: "A user is blocked from https://example.com/gambling even though https://example.com/news is allowed — what feature makes this possible?" The answer is HTTPS Inspection combined with URLF category evaluation per-path.

Caching and Performance

The gateway caches category lookups locally so that repeat visits to the same site do not require a new ThreatCloud query. The cache is per-gateway and persists across policy installs. Cache size and TTL are tunable but CCSA does not test these specific values. The relevant concept is: cache reduces latency and ThreatCloud query volume.

Logging and Reporting

URLF generates logs for every categorized request that matches a non-Accept policy, and (if configured) for accepted requests as well. Logs include the URL, category, action taken, user (if Identity Awareness is enabled), and the rule that matched. SmartEvent can produce URLF reports showing top categories, top blocked sites, and top users — useful for compliance and acceptable-use reporting.

Common CCSA Scenarios

Typical CCSA URLF questions:

• Identify where the category database lives (ThreatCloud).
• Recognize that custom sites override cloud categories.
• Know the available actions per category (Accept, Drop, Reject, Redirect, Ask).
• Recognize the dependency on HTTPS Inspection for full-path HTTPS categorization.
• Distinguish URLF ("where is the user going?") from Application Control ("what application is this?").

A common scenario asks which blade would block a user visiting a known phishing site. The correct answer is URL Filtering, using the Phishing category — not Anti-Virus (which scans files) and not IPS (which scans for attack signatures). Knowing which blade owns which threat class is the core TP skill on the CCSA.