A real-life situation
Management wants gambling and adult sites blocked, a warning on social media, and every phishing and malware site stopped. Marketing then complains their analytics tool is blocked as "Newly Observed Domain". A web filter profile handles both: categories for the broad policy, URL filters and overrides for the exceptions.
How a request is checked
Category actions
Edit Web Filter Profile: Staff-WF
- Security Risk
- Block (Phishing, Malicious Websites…)
- Gambling
- Block
- Adult / Mature Content
- Block
- Social Networking
- WarningUsers see a warning page and can continue.
- Unrated
- Block
- All other categories
- Monitor (log, allow)
- URL Filter
- On1 entry
- Enforce safe search
- On
FortiGuard Category Based Filter
Static URL Filter
Search Engines
| Action | What the user gets |
|---|---|
| Allow | The page, not logged |
| Monitor | The page, and a log entry |
| Warning | A warning page with a Proceed button |
| Authenticate | A login; allowed only for listed user groups |
| Block | A block page (replacement message) |
Exceptions: static URL filter and overrides
config webfilter urlfilter
edit 1
set name "Staff-URLs"
config entries
edit 1
set url "analytics.example-tool.com"
set type simple
set action exempt
next
edit 2
set url "*.example-games.com"
set type wildcard
set action block
next
end
next
end
config webfilter profile
edit "Staff-WF"
config web
set urlfilter-table 1
end
next
endStatic URL entries are checked before categories. Exempt skips the remaining web filter checks for that URL (and other scans you choose); allow only skips the category check. Wildcard and regex entries match many URLs; keep them tight.
If FortiGuard simply has a site in the wrong category, a rating override (Security Profiles › Web Rating Overrides) gives it a different category on your FortiGate, and you can submit the site to Fortinet for re-rating.
DNS filtering
A DNS filter profile on the same policy checks each DNS query's category. Blocked domains get an answer pointing to the FortiGate's block page, or a refusal, so the connection never starts. It also blocks known botnet command-and-control domains. It only works when the clients' DNS queries pass through the FortiGate (or use it as their DNS server).
Verify
FGT1 # diagnose debug rating Locale : english Service : Web-filter Status : Enable License : Contract Service : Antispam Status : Disable Num. of servers : 1 Protocol : https Port : 443 ...
Why it works this way
No one can list every website, so categories maintained by a provider do the bulk of the work. Your own URL filters come first because local knowledge beats a global rating: you know which tool marketing needs.
Common mistakes
- Expecting full-URL filtering of HTTPS sites under certificate inspection: only the domain is visible.
- Broad exempt entries (
*.com-style wildcards) that switch inspection off far beyond the intended site. - Clients using DNS-over-HTTPS or an outside resolver, bypassing the DNS filter.
- Blocking "Unrated" without a plan for new internal or partner sites.
Key takeaways
- Static URL filter first, then FortiGuard categories with allow, monitor, warning, authenticate or block.
- Exempt, allow and block URL entries handle exceptions; rating overrides fix wrong categories.
- DNS filtering blocks whole domains at lookup time, for all applications.
- Check ratings with diagnose debug rating and the Web Filter security log.
Check yourself
Gambling is set to Block, and a static URL filter entry exempts casino.example. Can users open casino.example?
Which category action lets the user continue after reading a notice?
A laptop app (not a browser) connects to a known malware domain. Which profile can stop it even without deep inspection?