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:
- FortiGuard category filter — every URL queried against the FortiGuard cloud, returns a category, and the profile says allow / monitor / warning / block / authenticate per category.
- Static URL filter — explicit allow/block of literal URLs, wildcards, or regex. Evaluated before the category lookup.
- 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:
| Anomaly | Triggers on |
|---|---|
tcp_syn_flood | Half-open SYNs per second |
tcp_port_scan | Distinct destination ports per source per second |
udp_flood | UDP packets per second |
icmp_flood | ICMP packets per second |
ip_dst_session | Concurrent 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.