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:

l example.com – local rating as “category 1”, action set to Block l example.com/subdirectory – local rating as “category 2”, action set to Monitor l 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. l If a valid SNI exist, then SNI will be used as the domain name for url rating instead of CN inthe server certificate. l 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 l AND the user’s computer is one of the IP addresses specified l 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 l AND the policy the traffic is going through must be identity based l AND the user’s credentials matches the identity credentials specified l 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.

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 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: l 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 l 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. l 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 l User Group l 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. l 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.

 

Using cookies to authenticate users in a Web Filter override

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.