Configure Web Filtering and Application Control on a FortiGate

Before you run this

This guide adds two FortiGuard security profiles — Web Filter and Application Control — to an existing firewall policy so the FortiGate inspects outbound traffic and blocks the categories and applications you choose. It's how you stop users reaching malware and phishing sites, or using peer-to-peer and proxy apps, on the way out to the internet.

A few things to understand before you touch anything:

• You need a super-admin (or a profile with write access to Security Profiles and Firewall Policy) logged into the FortiGate. Category-based web filtering and the FortiGuard application signatures require an active FortiGuard Web Filtering / Application Control subscription. Without it, category lookups fail open and the profile does little.
• This changes how live traffic is handled. Attaching a web filter or app control profile to a production policy takes effect immediately for every session that policy matches. A too-broad block rule can cut off users mid-workday.
• Deep SSL inspection is the sharp edge here. Category filtering and app control on HTTPS are only fully effective with deep-inspection, which means the FortiGate re-signs TLS with its own CA. If that CA isn't trusted on the clients, browsers throw certificate errors, and cert-pinned apps (Windows Update, many mobile and banking apps) may break outright. Start with the built-in certificate-inspection profile and understand what deep inspection costs before enabling it.
• Keep a separate console or out-of-band connection open (the physical console port, or a management interface reachable by a path that does not go through the policy you're editing). A misconfigured policy or SSL profile can lock you out.
• Back up the running config before you start, and make the change in a maintenance window. In the GUI: System → Configuration → Backup. The FortiGate also keeps config revisions under System → Configuration → Revisions — that's your rollback path if you need to revert.
• Test on a single, non-production policy first — a lab FortiGate, a VDOM you control, or a test policy scoped to one test host — before rolling this onto the policy your whole office uses.

I'm writing for FortiOS 7.4 (GUI, with CLI equivalents over SSH). Menu names and some CLI tables moved between 6.x, 7.0, 7.2 and 7.4, so if you're on another release, confirm the paths in the FortiOS Administration Guide for your version.

What we're building

A LAN-to-WAN policy that:

1. Uses an SSL inspection profile (certificate inspection to start).
2. Blocks a handful of clearly unwanted web categories.
3. Blocks a couple of application categories (e.g. Proxy, P2P).

Replace every placeholder — Test-WebFilter, Test-AppControl, policy IDs, category names — with your own values.

Step 1 — Create the Web Filter profile (GUI)

1. Go to Security Profiles → Web Filter.
2. Click Create New (the + at the top of the profile dropdown).
3. Name it Test-WebFilter.
4. Under FortiGuard Category Based Filter, expand the category groups. Right-click a category (or group) and set the action. The standard starting set is to Block the Security Risk categories — Malicious Websites, Phishing, Spam URLs, Newly Registered Domains — plus whatever your policy requires (for example Proxy Avoidance).
5. Leave the rest at Allow or Monitor rather than blocking broadly on the first pass. Monitor logs without blocking, which is the safest way to see what a category actually catches before you commit to blocking it.
6. Click OK.

I recommend setting new categories to Monitor first and reading the logs for a day. It's far easier to tighten from data than to explain to users why a site broke.

Step 1 (CLI equivalent)

The web filter profile lives under config webfilter profile, with category actions under config ftgd-wf → config filters. The catch is that categories are referenced by numeric FortiGuard category IDs, not names, and those IDs are easy to get wrong. Rather than guess an ID here, build the profile in the GUI (where you pick categories by name), then run show webfilter profile Test-WebFilter to see the exact IDs FortiOS assigned. If you script it later, take the IDs from that output. The category ID reference is published in the FortiGuard Web Filter documentation.

Step 2 — Create the Application Control profile (GUI)

1. Go to Security Profiles → Application Control.
2. Click Create New.
3. Name it Test-AppControl.
4. In the Categories list, set the categories you want to block — commonly Proxy and P2P — to Block, and leave the rest on Monitor for the first pass.
5. Decide how you want the default to behave for unknown/unlisted applications. There's a setting for the action applied to applications not otherwise matched; check what it's set to and leave it on Monitor or Allow unless you have a reason to block by default.
6. Click OK.

Step 3 — Attach both profiles to a firewall policy

GUI:

1. Go to Policy & Objects → Firewall Policy.
2. Edit your LAN-to-WAN policy (or a scoped test policy).
3. Under Security Profiles, toggle on Web Filter and select Test-WebFilter.
4. Toggle on Application Control and select Test-AppControl.
5. Toggling either profile on will require an SSL Inspection profile. Select certificate-inspection to start. (Switch to deep-inspection only after you've read the caution above and deployed the CA to clients.)
6. Confirm Log Allowed Traffic is set so you can see hits, then click OK.

CLI equivalent (replace <policy-id> with the real ID from show firewall policy):

config firewall policy
    edit <policy-id>
        set utm-status enable                        # turns on UTM/security profiles for this policy
        set ssl-ssh-profile "certificate-inspection"  # start here, not deep-inspection
        set webfilter-profile "Test-WebFilter"
        set application-list "Test-AppControl"
        set logtraffic all                           # log so you can verify hits
    next
end

Every keyword above (utm-status, ssl-ssh-profile, webfilter-profile, application-list, logtraffic) is standard in the firewall policy table on FortiOS 7.4.

Verify it worked

From the logs (the reliable way):

• Log & Report → Web Filter shows category matches and blocks.
• Log & Report → Application Control shows application hits.
• Generate a hit from a test client behind the policy. Browsing to a site in a blocked category should return the FortiGuard block replacement page; browsing to a monitored/allowed site should pass and appear in the log.

Confirm the profiles are actually bound to the policy (CLI):

show firewall policy <policy-id>

You should see the webfilter-profile, application-list, and ssl-ssh-profile lines you set. If they're absent, the profile isn't applied no matter how it's configured.

Confirm the FortiGuard licence is live — without it, category filtering silently underperforms. In the GUI, Dashboard → Status → Licenses shows Web Filtering and Application Control as active. On the CLI, diagnose debug rating reports the FortiGuard rating servers the unit is talking to.

How to undo it

• Detach without deleting: edit the policy and turn the Web Filter and Application Control toggles off (or in CLI, unset webfilter-profile and unset application-list under the policy). Traffic returns to no filtering immediately.
• Full rollback: System → Configuration → Revisions, select the revision you saved before starting, and restore it. This reverts the whole running config, so use it only if a change caused wider breakage.
• Delete the profiles once nothing references them, under each Security Profiles page.

Roll out in stages: monitor first, read a day of logs, then flip the categories and apps you're confident about to Block. That sequence keeps you from being the reason the office loses internet on a Monday morning.