Overriding FortiGuard website categorization

In most things there is an exception to the rule. When it comes to the rules about who is allowed to go to which websites in spite of the rules or in this case, policies, it seems that there are more exceptions than to most rules. There are numerous valid reasons and scenarios for exceptions so it follows that there needs to be a way to accommodate this exception.

The different methods of override

There are two different ways to override web filtering behavior based on FortiGuard categorization of a websites if you are operating in proxy-based inspection.

The second method has two variations in implementation and each of the three has a different level of granularity.

  1. Using Alternate Categories

Web Rating Overrides

This method manually assigns a specific website to a different Fortinet category or a locally created category.

  1. Using Alternate Profiles

Administrative Override or Allow users to override blocked categories

In this method all of the traffic going through the FortiGate unit, using identity based policies and a Web Filtering profile has the option where configured users or IP addresses can use an alternative Web Filter profile when attempting to access blocked websites.

CLI / flow

Using Alternate Categories

Web Rating Overrides

There are two approaches to overriding the FortiGuard Web Filtering. The first is an identity-based method that can be configured using a combination of identity-based policies and specifically designed webfilter profiles. This is addressed in the Firewall Handbook.

The second method is the system-wide approach that locally (on the FortiGate Firewall) reassigns a URL to a different FortiGuard Category or even subcategory. This is where you can assign a specific URL to the FortiGuard Category that you want to you can also set the URL to one of the Custom Categories that you have created

The Web Rating Overrides option is available because different people will have different criteria for how they categorize websites. Even if the criteria is the same an organization may have reason to block the bulk of a category but need to be able to access specific URLs that are assigned to that category.

A hypothetical example could be that a website, example.com is categorized as being in the Sub-Category Pornography. The law offices of Barrister, Solicitor, and Lawyer do not want their employees looking at pornography at work so they have used the FortiGuard Webfilter to block access to sites that have been assigned to the Category “Pornography”. However, the owners of example.com are clients of the law office and they are aware that example.com is for artists that specialize in nudes and erotic images. In this case two approaches can be taken. The first is that the Web Rating Override function can be used to assign example.com to Nudity and Risque instead of Pornography for the purposes of matching the criteria that the law office goes by or the site can be assigned to a Custom Category that is not blocked because the site belongs to one of their clients and they always want to be able to access the site.

Another hypothetical example from the other side of the coin. A private school has decided that a company that specializes in the online selling of books that could be considered inappropriate for children because of their violent subject matter, should not be accessible to anyone in the school. The categorization by Fortinet of the site example2.com is General Interest - Business with the subcategory of Shopping and Auction, which is a category that is allowed at the school. In this case they school could reassign the site to the Category Adult Material which is a blocked category.

Local or Custom Categories

User-defined categories can be created to allow users to block groups of URLs on a per-profile basis. The categories defined here appear in the global URL category list when configuring a web filter profile. Users can rate URLs based on the local categories.

Users can create user-defined categories then specify the URLs that belong to the category. This allows users to block groups of web sites on a per profile basis. The ratings are included in the global URL list with associated categories and compared in the same way the URL block list is processed.

note icon Local categories and local rating features consume a large amount of CPU resources; use these features as little as possible.

The local assignment of a category overrides the FortiGuard server ratings and appear in reports as “Local” Categories or “Custom” Categories depending on the context.

CLI commands

In the CLI, the term is local category.

To create a local category:

config webfilter ftgd-local-cat

edit local_category_1

set id 140


To set a rating to a Local Category:

config webfilter ftgd-local-rating

edit <url_str>

set rating {[<category_int>] [group_str] . . .]

set status {enable | disable}



GUI commands

In the GUI Local Categories appears on the Edit Web Filter profile page and Custom Categories on the Web Rating Overrides page, if your FortiGate is in proxy-based or flow-based, profile-based inspection. If your FortiGate is operating with flow-based inspection and the policy-based NGFW mode, then you will not see the Edit Web Filter profile page.

Both these features will be used to create local categories and to apply actions to them.

Creating a Local or Custom Category

  1. Go to Security Profiles > Web Rating Overrides.
  2. Select Custom Categories in the top menu bar.
  3. In the new window, click on Create New.
  4. Enter the name of the custom category.
  5. Select OK.

Configuring Web Rating Overrides

Using the GUI
  1. Go to Security Profiles > Web Rating Overrides.
  2. Select Create New
  3. Type in the URL field the URL of the Website that you wish to recategorize. Do not use wildcard expressions when typing in the URL.
  4. Select the Lookup Rating button to verify the current categorization assigned to the URL.
  5. Change the Category field to one of the more applicable options from the drop down menu, for example, one of the custom categories just created.
  6. Change the Sub-Category field to a more narrowly defined option within the main category.
  7. Select OK.
note icon It is usually recommended that you choose a category that you know will be addressed in existing Web Filter profiles so that you will not need to engage in further configuration.

Applying an Action to a Local or Custom Category

  1. Go to Security Profiles > Web Filter.
  2. Expand the Local Categories in the list of FortiGuard categories.
  3. Right-click on a category from the list and set the action to Allow, Block, Monitor, Warning, Authenticate, or Disable.
  4. Select Apply.

You cannot apply an action to a local category when operating in flow-based NGFW policy-based mode.

Local Category scenarios

Scenario 1: The configuration of the domain name overrides the configuration for the subdirectory.

Depending on the URL specified or other aspects of configuration, the configuration of a local

or custom category may not take effect. Consider a scenario where you have defined:

  • example.com – local rating as “category 1”, action set to Block
  • example.com/subdirectory – local rating as “category 2”, action set to Monitor
  • example.com/subdirectory/page.html – local rating as “category 3”, action set to Warning.

If a user browses to “example.com", access will be blocked. If a user browses to example.com/subdirectory, access will also be blocked,even though that address was configured to be part of category2. The configuration of the domain name overrides the configuration for the subdirectory.

However, if you configure a specific HTML page differently than the domain name, then that configuration will apply. In this scenario, the user will see a Warning message but will be able to pass through to the page.

Scenario 2: User-defined local ratings and SNI matches

In this scenario, local categories are defined and sites are added to those categories.

  • There is no behavioral difference if the hostname is sent from from ClientHello SNI or from HTTP request-url.
  • The SNI will be used as hostname for https certificate-inspection or ssl-exempt.
  • If a valid SNI exist, then SNI will be used as the domain name for url rating instead of CN inthe server certificate.
  • For the local rating, "example.com" will match "test.example.com", but will not match "another_example.com".

Using Alternate Profiles

Allow Blocked Overrides or Web Overrides

The Administrative Override feature for Web Filtering is found by going to Security Profiles > Web Filter and then enabling Allow users to override blocked categories.

The Concept

When a Web filter profile is overridden, it does not necessarily remove all control and restrictions that were previously imposed by the Web Filter. The idea is to replace a restrictive filter with a different one. In practice, it makes sense that this will likely be a profile that is less restrictive the original one but there is nothing that forces this. The degree to which the alternate profile is less restrictive is open. It can be as much as letting the user access everything on the Internet or as little as allowing only one addition website. The usual practice is to have as few alternate profiles as are needed to allow approved people to access what they need during periods when an exception to the normal rules is needed but still having enough control that the organizations web usage policies are not compromised.

You are not restricted to having only one alternative profile as an option to the existing profile. The new profile depends on the credentials or IP address making the connection. For example, John connecting through the "Standard" profile could get the "Allow_Streaming_Video" profile while George would get the "Allow_Social_Networking_Sites" profile.

The other thing to take into account is the time factor on these overrides. They are not indefinite. The longest that an override can be enabled is for 1 year less a minute. Often these overrides are set up for short periods of time for specific reasons such as a project. Having the time limitation means that the System Administrator does not have to remember to go back and turn the feature off after the project is finished.

Identity or Address

In either case, these override features -- for specified users, user groups or IP addresses -- allow sites blocked by Web Filtering profiles to be overridden for a specified length of time. The drawback of this method of override is that it takes more planning and preparation than the rating override method. The advantage is that once this has been set up, this method requires very little in the way of administrative overhead to maintain.

When planning to use the alternative profile approach keep in mind the following: In Boolean terms, one of the following "AND" conditions has to be met before overriding the Web Filter is possible.

Based on the IP address:
  • The Web Filter profile must be specified as allowing overrides
  • AND the user's computer is one of the IP addresses specified
  • AND the time is within the expiration time frame.

While the conditions are fewer for this situation, there is less control over who has the ability to bypass the filtering configured for the site. All someone has to do is get on a computer that is allowed to override the Web Filter and they have access.

Based on user group:
  • The Web Filter profile must be specified as allowing overrides
  • AND the policy the traffic is going through must be identity based
  • AND the user's credentials matches the identity credentials specified
  • AND the time is within the expiration time frame.

This method is the one most likely to be used as it gives more control in that the user has to have the correct credential and is more versatile because the user can use the feature from any computer that uses the correct policy to get out on the Internet.


When using an alternate profile approach to Web Filter overrides, the following settings are used to determine authentication and outcome. Not every setting is used in both methods but enough of them are common to describe them collectively.

Apply to Group(s)

This is found in the Allow Blocked Overrides configuration. Individual users can not be selected. You can select one or more of the User Groups that are recognized my the FortiGate unit, whether they are local to the system or from a third part authentication device such as a AD server through FSSO.

Original Profile

This is found in the Administrative Override configuration. In the Allow Blocked Overrides setting the configuration is right inside the profile so there is no need to specify which profile is the original one, but the Administrative Override setup is done separately from the profiles themselves.

Assign to Profile or New Profile

Despite the difference in the name of the field, this is the same thing in both variations of the feature. You select from the drop down menu the alternate Web Filter Profile that you wish to set up for this override.

Scope or Scope Range

When setting up the override in the "Allow Blocked Overrides" variation, you are given a drop-down menu next to the field name Scope while in the Administrative Override configuration you are asked to select a radio button next to the same options. In both cases this is just a way of selecting which form of credentials will be required to approve the overriding of the existing Web Filter profile.

When the Web Filter Block Override message page appears it will display a field named "Scope:" and depending on the selection, it will show the type of credentials used to determine whether or not the override is allowed. The available options are:

  • User
    This means that the authentication for permission to override will be based on whether or not the user is using a specific user account.

  • User Group
    This means that the authentication for permission to override will be based on whether on not the user account supplied as a credential is a member of the specified User Group.

  • IP
    This means that the authentication for permission to override will be based on the IP address of the computer that was used to authenticate. This would be used with computers that have multiple users. Example: If Paul logs on to the computer, engages the override using his credentials and then logs off, if the scope was based on the IP address of the computer, anybody logging in with any account on that computer would now be using the alternate override Web Filter profile.

    When entering an IP address in the Administrative Override version, only individual IP addresses are allowed.

    Differences between IP and Identity based scope
  • Using the IP scope does not require the use of an Identity based policy.
  • When using the Administrative Override variation and IP scope, you may not see a warning message when you change from using the original Web Filter profile to using the alternate profile. There is no requirement for credentials from the user so, if allowed, the page will just come up in the browser.
  • Ask
    This option is available only in the "Allowed Blocked Overrides" variation and when used configures the message page to ask which scope the user wished to use. Normally, when the page appears the scope options are greyed out and not editable, but by using the ask option the option is dark and the user can choose from the choice of:
  • User
  • User Group
  • IP Address
  • Switch Duration
    The Administrative Override sets a specified time frame that is always used for that override. The available options are:
  • Predefined
    Using this setting will mean that what ever is set as the duration will be the length of time that the override will be in effect. If the duration variable is set to 15 minutes the length of the override will always be 15 minutes. The option will be visible in the Override message page but the setting will be greyed out.
  • Ask
    Using this setting will give the person the option of setting the duration to the override when it is engaged. The user can set the duration in terms of Day, Hours and or Minutes.

  • Duration
    Duration is one of the areas where the two variations take a different approach, on two aspects of the setting. As already indicated the "Administrative Override" only uses a static time frame there is no option for the user to select on the fly how long it will last. The other way in which the two variation differ is that the "Allow Blocked Overrides" starts the clock when the user logs in with his credentials. For example, if the duration is 1 hour and John initiates an override at 2:00 p.m. on January 1, at the end of that hour he will revert back to using the original profile but he can go back and re-authenticate and start the process over again. The Administrative override variation starts the clock from when the override was configured, which is why is shows an expiration date and time when your are configuring it.

    This option, which is available when the Switch Mode is set to Predefined is the time in minutes that the override will last when engaged by the user.

    When setting up a constant duration in the Web Based Interface, minutes is the only option for units of time. To set a longer time frame or to use the units of hours or days you can use the CLI.


config webfilter profile

edit <name of webfilter profile>

config override

set ovrd-dur <###d##h##m>


note icon When configuring the duration you don't have to set a value for a unit you are not using. If you are not using days or hours you can use:


set ovrd-dur 30m


instead of:


set ovrd-dur 0d0h30m


However, each of the units of time variable has their own maximum level:


###d cannot be more than 364

##h cannot be more than 23

##m cannot be more than 59


So the maximum length that the override duration can be set to is 364 days, 23 hours, and 59 minutes.

Using cookies to authenticate users in a Web Filter override

Cookies can be used to authenticate users when a web filter override is used. This feature is available in CLI only.

CLI Syntax:

config webfilter cookie-ovrd

set redir-host <name or IP>

set redir-port <port>



config webfilter profile

edit <name>

config override

set ovrd-cookie [allow | deny]

set ovrd-scope [user | user-group | ip | ask]

set profile-type [list | radius]

set ovrd-dur-mode [constant | ask]

set ovrd-dur <duration>

set ovrd-user-group <name>

set profile <name>