NSE4 Part 6: Security Profiles — Web, App Control, AV, IPS, DoS

NSE4 Part 6: Security Profiles — Web, App Control, AV, IPS, DoS

Part 6 of the NSE4 series. This post covers Lessons 8 through 11 in one place, because in practice the five security profiles are configured, logged and troubleshot together. Each is a separate profile object referenced from a firewall policy.

Inspection mode — flow vs proxy

Every security profile runs in one of two modes:

  • Flow-based (default). Packets are inspected as they stream through. Lower latency, lower memory; cannot do every check (e.g., archive expansion). Set globally or per-policy.
  • Proxy-based. The FortiGate terminates the session, buffers content, inspects, then proxies onward. More features (CDR, file-type analysis, archive scan), higher resource cost.
config firewall policy
    edit 10
        set inspection-mode flow      ; or proxy
    next
end

The exam will give you a feature (“scan inside zip files”) and ask which mode is required. CDR (content disarm and reconstruction), DLP file-type matching, and some web filter actions are proxy-only.

Web Filter

Three filtering layers:

  1. FortiGuard category filter — every URL queried against the FortiGuard cloud, returns a category, and the profile says allow / monitor / warning / block / authenticate per category.
  2. Static URL filter — explicit allow/block of literal URLs, wildcards, or regex. Evaluated before the category lookup.
  3. Content filter — block by keywords in the page body. Proxy mode only.
config webfilter profile
    edit "default-web"
        config ftgd-wf
            config filters
                edit 1
                    set category 26       ; Malicious Websites
                    set action block
                next
            end
        end
    next
end

DNS filter is a separate profile (config dnsfilter profile) — operates at DNS resolution time on rated hostnames. Faster than URL filter for blocking by category, but no per-page granularity.

Common exam trap: a static block for *.example.com will not block traffic that bypasses DNS (hard-coded IP). DNS filter alone is not a substitute for web filter on TLS traffic.

Application Control

Signature-based detection of well-known applications — Facebook, Dropbox, BitTorrent, custom apps. Each signature has a category (e.g., Social.Media, Cloud.IT, P2P). The profile sets allow / monitor / block / quarantine per category or per individual signature.

config application list
    edit "default-app"
        config entries
            edit 1
                set category 5        ; P2P
                set action block
            next
        end
    next
end

Two practical notes:

  • QUIC and HTTP/3 carry traffic over UDP/443 and bypass classical TCP-based inspection. Either block QUIC at policy level (set quic block) or rely on app control’s QUIC signatures.
  • Cloud-app filtering depends on deep SSL inspection (covered in Part 4) — without it, you only see SNI-level visibility.

Antivirus

AV scans files in HTTP, HTTPS (with deep inspection), FTP, IMAP, POP3, SMTP, MAPI, CIFS. Three databases:

  • Regular — full signature set.
  • Extended — adds older signatures and zero-day samples.
  • Extreme — extended plus aggressive heuristics, used in high-risk segments.
config antivirus profile
    edit "default-av"
        config http
            set av-scan block
            set archive-block encrypted
        end
    next
end

Three escalation features:

  • CDR (Content Disarm and Reconstruction) — strips active content (macros, scripts, embedded objects) from Office docs and PDFs. Proxy mode only.
  • FortiSandbox integration — submit suspicious files for detonation; FortiGate holds traffic pending verdict if configured to.
  • EMS (FortiClient EMS) integration — endpoint quarantine triggered by FortiGate detection.

Intrusion Prevention System (IPS)

Signature-based detection of attacks. Signatures are categorised by:

  • Severity — info, low, medium, high, critical.
  • Target — client or server.
  • OS / application — Windows, Linux, Apache, etc.
config ips sensor
    edit "default-ips"
        config entries
            edit 1
                set severity high critical
                set action block
                set log enable
            next
        end
    next
end

A few things the exam targets:

  • IPS engine version and signature DB version are independent — check both with diagnose ips status.
  • A rate-based signature triggers only after N hits in M seconds (e.g., brute force, port scans).
  • Custom signatures use Fortinet’s own syntax — you don’t need to write them in the exam, but recognise the structure.

Denial-of-Service (DoS) policies

DoS policies sit before firewall policies in the packet path and protect against volumetric or anomaly-based attacks. They match on source / destination interface and address but enforce anomaly thresholds rather than allow/deny:

AnomalyTriggers on
tcp_syn_floodHalf-open SYNs per second
tcp_port_scanDistinct destination ports per source per second
udp_floodUDP packets per second
icmp_floodICMP packets per second
ip_dst_sessionConcurrent sessions to one destination
config firewall DoS-policy
    edit 1
        set interface "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set service "ALL"
        config anomaly
            edit "tcp_syn_flood"
                set action block
                set threshold 2000
            next
        end
    next
end

Tune thresholds against baseline traffic, not vendor defaults — the defaults are conservative and often miss real floods on busy edges.

Logging the right things

Every profile has independent logging. Without set log enable inside the profile section, the matched event won’t show up under FortiView → Threats even if the policy itself logs all traffic. This is the single most common cause of “I’m sure it blocked something but I can’t see it” tickets.

Part 7 covers SSL VPN — portals, modes, MFA and the troubleshooting commands for the SSL VPN tunnel.