FortiGate Security Profiles — AV, Web Filter, App Control, IPS, SSL Inspection

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. Start with high-risk categories only (banking, cloud storage). 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