What's the order of operations in HTTPS inspection for a FortiGate?

A common point of confusion with FortiGates is the order of operations. Specifically, the flow that handles HTTPS inspection. In today's article, I want to unpack this sequence so that it's a little more clear.

Static URL Filter

The first sub-component that performs scanning is the local Static URL filter. This contains patterns and addresses that the admin has specifically instructed FortiGate to look for. Options for this component are:

• Block - in which case, the user would see a block page.
• Allow - explicitly allows the matched URL (and permits the request to be scanned by the other web filter components)
• Monitor - pretty much the same thing as "allow" but also logs transaction.
• Exempt - permits the URL and completely bypasses all other downstream web filter components.

That last bullet is really important. It can be the cause of a lot of confusion 😄.

FortiGuard Category Filter

Assuming that the transaction has been explicitly allowed/monitored via the static URL filter step (or just not matching anything), the next part is for the request to go through the FortiGuard Category Filter. At this point, it's got some familiar actions as options:

• Block - in which case, the user would see a block page.
• Allow - explicitly allows the web site/category (and permits the request to be scanned by the other downstream web filter components)
• Monitor - pretty much the same thing as "allow" but also logs transaction.
• Warning - This presents a page to the user but gives them the opportunity to acknowledge the questionable site category and proceed.

Notice that there's no "exempt" action at this part? That's another important detail too.

Advanced Content Filters

If the transaction made it this far, the last phase is to examine the web site using some additional advanced filters (e.g. safe search settings, java filters, activex controls, etc). Some of these features depend on the inspection mode/type and can vary. Here again though, whatever is remaining and enabled can perform a few actions:

• Block - just like before... the user sees a block page.
• Allow - explicitly allows the matched URL (and permits the request to be scanned by the other web filter components)
• Monitor - pretty much the same thing as "allow" but also logs transaction.
• Warning - This presents a page to the user but gives them the opportunity to acknowledge the questionable site category and proceed.

Phew! At THIS point, if nothing is caught, the user is allowed through to the requested page. Fun stuff!

For more information, check out these resources:

Web filtering order of execution

This article explains the order in which web filtering steps are executed. Solution There is a specific order of execution of the web filtering steps: Static URL Filtering: Static URL filtering (Note when using the URL filter ‘Exempt’ option, Antivirus, File Filter, and DLP scanning are exempt b…

fortinetabarushka

Fortigate Web filtering using Static url and fortiguard category filter

Hi All, URL blocking using both method - FortiGuard Category Based Filter with static url fitler. Scenario 1 : I don’t want to block entire category, want to block specific url. >>>>>>> When I am blocking static url in URL Filter then it is working, URLs are getting blocked. Scenario 2: I w…

fortinetUmesh

The difference between 'allow' and 'exempt' in the web filter URL filter

the difference between the actions 'Allow' and 'Exempt' under the URL filter in the web filter profile. Scope FortiGate, FortiOS. Solution An URL is evaluated by the web filter profile in the following order: URL filter.FortiGuard Web Filter (FortiGuard categories).Web cont…

fortinetssavin