5.3 URL Filtering

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

Key Takeaways Explain This Topic AI

URL Filtering categorizes web destinations into a category database maintained in Check Point ThreatCloud and updated dynamically.

Administrators can add custom sites and override category classifications for specific URLs.

URL Filtering policy is enforced through the TP profile, with actions Accept, Drop, Redirect, and Ask per category.

HTTPS Inspection is required to categorize encrypted HTTPS URLs by full path; without it, only the SNI/server name is visible.

Last updated: July 2026

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:

Action Effect

Accept Allow the request, log it.

Drop Block the request silently.

Reject Block the request and return an error page to the user.

Redirect Block the request and redirect the user to a configurable URL (often a corporate "blocked" page).

Ask Prompt the user to confirm, similar to Application Control's Ask.

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.