Responding to a URL request

Administrator Help | Forcepoint Web Security and Forcepoint URL Filtering | v8.5.x

When a user requests a site, Filtering Service is responsible for determining whether to block or permit the request.


	Important With the Web Hybrid module, requests from users outside the network are managed by the hybrid service, which has its own rules for determining whether to block or permit a request.

If a request triggers Content Gateway analysis, Filtering Service uses the category returned as a result of the analysis to determine whether to block or permit the request.

Filtering Service determines which action to take as follows. At each step, the order of enforcement based on the user making the request is re-confirmed.

Checks the active protocol filter and determines whether any non-HTTP protocols are associated with the request.

If so, apply the appropriate action, as defined in the protocol filter.

If not, continue to the next step.

Attempt to match the site to an entry in the Recategorized URLs list for use later in the policy enforcement process. (SeeReclassifying specific URLs for details on recategorized URLs.)

If a match is made, identify the category.

If a match is not made, use the category from the Forcepoint URL Database.

Check to see whether the site is listed in an exception.

If there is a block exception, block the site.

If there is a permit exception, permit the site.

Note that if the URL is permitted by exception, but classified as a security risk, the default action is to block it via security override. Administrators can disable the security override, but this is not recommended.

If there is no exception for the site, continue to the next step.

Check to see if the request is to a cloud application and, if so, determine which cloud app filter the policy enforces for the current day and time.

If the cloud app is explicitly blocked either by the cloud app filter applied, security override, or a policy exception, the request is blocked.

If the cloud app is explicitly permitted in the cloud app filter, not included in the cloud app filter, or explicitly permitted in a policy exception, the list of managed cloud applications on the Settings > CASB Configuration > Protected Cloud Apps page is read.

If the policy being applied is configured to Forward traffic to Forcepoint CASB on the Protected Cloud Apps page and if the app has been selected as an app to be managed by CASB Enforcement, the request is forwarded to CASB Enforcement.

Policies that have been added in the CASB portal determine whether the request is permitted or blocked. No further policy enforcement action is taken by Filtering Service. A log record is created and the action "Protected cloud app forwarded" is applied to the request.

If the policy being applied is configured to Forward traffic to Forcepoint CASB on the Protected Cloud Apps page and if the cloud app is permitted but is not a selected managed cloud app, Filtering Service handles the request.

If the policy being applied is not configured to Forward traffic to Forcepoint CASB on the Protected Cloud Apps page, Filtering Service handles the request.

If the cloud app is explicitly blocked or permitted, the request is blocked or permitted based on the cloud app filter.

If a cloud app is explicitly permitted or blocked and is not a managed cloud app, additional lookup against the URL category is done to confirm the URL is not considered a security risk.

Note that if a URL is classified as a security risk, the default action is to block it via security override. Administrators can disable the security override, but this is not recommended.

If the cloud app is explicitly permitted or blocked but the URL is considered a security risk, the request is blocked as a security risk.

If the URL is not considered a security risk, and the cloud app is explicitly permitted, the request is permitted even if the category is blocked.

If the URL is not considered a security risk, and the cloud app is explicitly blocked, the request is blocked even if the category is permitted.

If Block all high risk apps is enabled and the cloud app is considered high risk, the request is blocked unless the cloud app is explicitly permitted.

If a cloud app is considered high risk, additional lookup against the URL category is done determine if it is considered a security risk.

If the cloud app risk level is high, but the URL is considered a security risk, the request is blocked as a security risk.

If the cloud app risk level is high, but the URL is not considered a security risk, the request is blocked based on the cloud app filter.

If the cloud app filter does not list the cloud app as specifically blocked or permitted, and Block all high risk apps is not enabled, continue to the next step.

Determines which category filter or limited access filter the policy enforces for the current day and time.

If the active category filter is Permit All, permit the site.

If the active category filter is Block All, block the site.

If the filter is a limited access filter, check whether the filter contains the URL or IP address. If so, permit the site. If not, block the site.

Note that if the URL is permitted by the limited access filter, but classified as a security risk, the default action is to block it via security override. Administrators can disable the security override, but this is not recommended.

If any other category filter applies, continue to Step 3.


	Note Filtering Service handles URLs accessed from search engine's cache like any other URL. They are blocked or permitted according to the applicable policies. Log records for cached URLs show the entire cached URL, including any search engine parameters.

Uses the category determined in step 1.

If the URL was recategorized, use the re-assigned category.

If the URL appears in the Forcepoint URL Database, use the category assigned to the site.

If a match is not made, categorize the site as Miscellaneous/Uncategorized and continue to the next step.

With Forcepoint Web Security, sites not categorized by the Forcepoint URL Database are analyzed by Content Gateway. If this returns a new category for the site, Filtering Service applies an action based on the new category (rather than continuing to classify the site as Uncategorized).

Checks the active category filter and identifies the action applied to the category containing the requested site.

If the action is Block, block the site.

If any other action is applied, continue to Step 7.

Checks for Bandwidth Optimizer settings in the active category filter (see Using Bandwidth Optimizer to manage bandwidth).

If current bandwidth usage exceeds any configured limits, block the site.

If current bandwidth usage does not exceed the specified limits, or no bandwidth-based action applies, proceed to Step 8.

Checks for file type restrictions applied to the active category (see Managing traffic based on file type).

If the site contains files whose extensions are blocked, block access to those files. If the site itself is comprised of a blocked file type, block access to the site.

If the site does not contain files whose extensions are blocked, go to Step 9.

10.

Checks for blocked keywords in the URL and CGI path, if keyword blocking is enabled (see Keyword-based policy enforcement).

If a blocked keyword is found, block the site.

If a blocked keyword is not found, continue to Step 10.

11.

Handles the site according to the action applied to the category.

Permit: Permit the site.

Limit by Quota: Display the block message with an option to view the site using quota time or go back to the previous page.

Confirm: Display the block message with the option to view the site for work purposes.

Filtering Service proceeds until the requested site is either blocked or explicitly permitted. At that point, no further investigation is attempted. For example, if a requested site belongs to a blocked category and contains a blocked keyword, Filtering Service blocks the site at the category level without checking the keyword. Log Server then logs the request as blocked because of a blocked category, not because of a keyword.


	Note Users with password override privileges can access websites regardless of why the site was blocked.