FortiGate Security Profiles: AV, Web Filter, App Control, IPS

Where profiles run in the packet flow

Recall the FortiGate flow: ingress → session lookup → route → policy match → NAT → security profiles → egress. Security profiles run after the policy accepts, so profile CPU is only spent on already-allowed traffic.

Order they run inside the profile stage:

SSL/SSH inspection      (decrypt encrypted flows)
↓
DNS filter              (does the FQDN look malicious?)
↓
Web filter              (URL category / block list)
↓
Application control     (Facebook, TikTok, TeamViewer signatures)
↓
Antivirus               (file scan on transfer)
↓
IPS                     (protocol anomaly / exploit signatures)
↓
DLP                     (Data Loss Prevention: outbound credit card / SSN)
↓
File filter / video filter

The seven profiles NSE 4 expects you to know

Antivirus

Scans files as they transfer through the FortiGate. Uses signature engines (FortiGuard AV) + optional cloud sandbox (FortiSandbox integration).

Modes: flow-based (fast, streams the file) vs proxy-based (buffers the whole file, catches more, higher latency).

Web filter

Blocks/allows based on URL category (FortiGuard cloud lookup) or static URL lists. Categories are the actual test material: Adult, Gambling, Social Networking, etc.

Actions per category: allow · block · monitor · warning (interstitial page) · authenticate (require login).

Application control

Identifies apps by their protocol signature, not just port. Blocks BitTorrent even when it’s on port 443. Recognizes ~5000 apps out of the box.

Practical use: block TikTok and Instagram on corporate SSIDs; allow but shape Zoom.

IPS (Intrusion Prevention)

Signature-based inspection for known exploits. Signatures are pulled from FortiGuard. Each signature has a severity and default action (allow / block / monitor). You can override per signature.

Modes: detection-only (log, don’t block, useful for tuning) vs prevention (log + drop).

SSL/SSH deep inspection

Terminates the client’s TLS session on the FortiGate using a re-signed certificate, inspects the plaintext, then re-encrypts to the destination. Without this, AV / web-filter / app-control / DLP can only see the SNI in the ClientHello, not the actual HTTP request.

Requires: a FortiGate CA cert distributed to every endpoint (via GPO / MDM). Without that, browsers show cert warnings.

Two modes: certificate inspection (SNI-only, no re-signing, lightweight) vs deep inspection (full MITM decrypt).

DNS filter

Blocks lookups for known-malicious FQDNs before the connection is even attempted. Cheap layer of defense; often the first to catch phishing links.

DLP (Data Loss Prevention)

Watches outbound traffic for defined patterns (credit-card regex, SSN, custom fingerprints, watermarked docs). Actions: log · block · quarantine sender.

Applying profiles to a policy

In the GUI: edit a firewall policy → scroll to “Security Profiles” → toggle each profile you want and pick which profile object.

CLI:

config firewall policy
  edit 17
    set utm-status enable
    set av-profile "corporate-av"
    set webfilter-profile "no-adult-no-gamble"
    set application-list "block-p2p"
    set ips-sensor "protect-servers"
    set ssl-ssh-profile "deep-inspect"
    set logtraffic all
  next
end

The “will it break the user experience?” trade-off

Every profile you enable adds CPU + latency + potential false positives. Practical starting point:

• Always: AV (proxy or flow), DNS filter, IPS in detection first.
• Common: Web filter (block Adult / Gambling / Malware categories), app control (block P2P + TOR).
• Careful: SSL deep inspection requires cert deployment. Exempt banking, finance and health categories, start with a pilot group, and add slowly.
• Advanced: DLP: needs pattern tuning to avoid false positives that flood logs.

Common exam / real-world mistakes

1. Enabling every profile at once. Users complain, everyone panics, profiles get switched off wholesale. Roll out one at a time in monitor mode first.
2. Forgetting SSL inspection is required for real coverage. Without it, the antivirus profile is inspecting maybe 20% of your web traffic.
3. Mixing profile modes. Flow-based AV can’t do everything proxy-based can (like MIME identification). If you need it, use proxy mode.
4. Not distributing the FortiGate CA cert before enabling deep SSL inspection. Every user gets cert warnings, help desk floods.
5. Ignoring FortiGuard licenses. Web filter / IPS / AV signatures need active licenses. Without them, the engines still run, but the signatures are stale or missing.

Cheat strip

Order in flow:  SSL → DNS → Web → App → AV → IPS → DLP
AV modes:      flow (fast) | proxy (thorough)
Web filter:    category-based, action per category
App control:   signature-based, port-independent
IPS modes:     detection-only  |  prevention
SSL inspect:   certificate (SNI)  |  deep (MITM)
                needs endpoint CA cert deployed
DNS filter:    cheap early block, catches phishing
DLP:           pattern-based outbound leak prevention