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 exceptions.

 

The different methods of override

There are actually two different ways to override web filtering behavior based on FortiGuard categorization of a websites. The second method has 2 variations in implementation and each of the three has a different level of granularity.

1. Using Alternate Categories

Rating Override

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

2. Using Alternate Profiles

Administrative Override or Allow Blocked Override

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.

 

Using Alternate Categories

 

Web Rating Overrides

There are two approached 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 has been 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 and even subcategory. This is where you can set 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 is 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 to approaches can be taken. The first is that the 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.

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.

In the CLI, they are referred to as Local categories. To create a Local Category:

config webfilter ftgd-local-cat

edit local_category_1 set id 140

end

In the GUI they are referred to as Custom Categories. There is a way to create a new category in the Web Based

Manager.

1. Go to Security Profiles > Web Rating Overrides.

2. Instead of creating a new override, you can choose the “Custom Categories” icon in the top menu bar.

3. From the new window select Create New.

4. A new row will appear at the bottom of the list of categories with a field on the left highlighted and the message “This field is required”. Enter the name of the custom category in this field.

5. Select Enter.

 

Configuring Rating Overrides

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.

4. Select the Lookup Rating button to verify the current categorization that is being assigned to the URL.

5. Change the Category field to one of the more applicable options from the drop down menu.

6. Change the Sub–Category field to a more narrowly defined option within the main category.

7. Select OK.

 

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 con- figuration.

 

Using Alternate Profiles

 

Allow Blocked Overrides or Web Overrides

The Administrative Override feature for Web Filtering was added and is found by going to Security Profiles > Web Filter and then enabling Allow Blocked Override. This opening window will display a listing of all of the overrides of this type. The editing window referred to the configuration as an Administrative Override.

 

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 the original one but there is nothing that forces this. The degree to which that 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 though 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 what these override features do is, 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 computers 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 more versatile because the user can use the feature from any computer that uses the correct policy to get out on the Internet.

 

Settings

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 was no need to specify which profile was 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 an 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
• Duration Mode This option is available only in the “Allowed Blocked Overrides” variation. The Administrative Override sets a specified time frame that is always used for that override. The available options from the drop down menu are:
• Constant 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 duration time which is greyed out if the Constant setting is used will be dark and editable. The user can set the duration in terms of Day, Hours and or Minutes.
• Duration Duration is on of the areas where the two variations takes 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 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 Duration Mode is set to Constant 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>

end

 

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(a minute shy of 1 year) .

 

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>

end

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>

end end

end