Web filtering plugins — URL categories, content types, and application control

TLS interception lets the firewall see the plaintext. What the firewall does with that plaintext — what it matches, what it blocks, what it allows — is the web filtering layer. URL categories, content types, application protocols, file types, and policy templates turn the proxy from a passive observer into an active content-control gateway. This lesson covers the matching capabilities, the databases that drive them, and the plugin model OPNsense uses to assemble them.

What the firewall can match on

Once TLS interception is in place, the proxy sees the same HTTP that the browser sees. The matching layers:

The richest matching is URL category. The databases that drive it:

• Commercial feeds: BrightCloud, Webroot, Symantec — categorise hundreds of millions of URLs across dozens of categories. Subscription-based; updated daily.
• Community feeds: URLhaus, StevenBlack hosts, Pi-hole-style blocklists — categorise malware, ads, tracking. Free; updated variably.
• Custom lists: the operator’s own blocklist of internal destinations, test environments, or sanctioned services.

Content-type and file controls

Beyond URLs, the proxy can match what is actually transferred:

• Block by MIME type: refuse responses with Content-Type: application/x-msdownload (Windows executables) or application/x-shockwave-flash (legacy Flash).
• Block by file extension: refuse downloads of .exe, .bat, .scr, .vbs — regardless of the MIME type the server claims.
• Block by file hash: compute SHA-256 of the downloaded file and compare to a malware feed (e.g., Malware Hash Database).
• Antivirus scanning: pass the downloaded file to an ICAP service (ClamAV, commercial AV) before delivering to the client.

$ grep -E '^(acl|http_access|ssl_bump|http_reply_access)' /usr/local/etc/squid/squid.conf 2>/dev/null | grep -E 'mime|exe|block' | head -10

acl EXE_BIN url_regex -i .exe(?|$) .msi(?|$) .bat(?|$) .scr(?|$)
acl BLOCK_MIME rep_mime_type -i application/x-msdownload application/x-msdos-program
http_access deny EXE_BIN
http_reply_access deny BLOCK_MIME

Application protocol detection

Some applications identify themselves in ways the proxy can recognise — even inside HTTPS via SNI, request patterns, or client hints:

• SNI-based: the TLS Server Name Indication reveals the destination hostname before encryption starts. facebook.com in SNI is Facebook regardless of what is in the encrypted payload.
• User-Agent: HTTP requests include a User-Agent string. WhatsApp/2.21 identifies WhatsApp; Zoom/ identifies Zoom.
• Domain patterns: *.zoom.us, *.whatsapp.net, *.slack.com — the proxy can match the parent domain.
• Behavioural: long-lived connections to a specific server, traffic patterns matching known apps.

SNI matching is the most reliable for HTTPS. The discipline: build application control rules on SNI and hostname patterns; use deeper inspection only when needed.

Plugin model

OPNsense exposes web filtering through plugins — modular components the operator installs from System → Firmware → Plugins. Common plugins for content filtering:

• Web proxy (Squid): the core HTTPS-capable proxy.
• ClamAV: antivirus engine, integrated via ICAP.
• URL filter databases: commercial feed integration (BrightCloud etc.).
• Ad blocker / DNS-based blocklists: complementary DNS-level filtering (Pi-hole style).

The plugins are independent. The proxy can run without antivirus. The antivirus can run with or without a commercial URL feed. The operator assembles the pipeline that matches the policy:

[client HTTPS] -> [proxy TLS terminate] -> [URL category filter] -> [content-type filter]
                                                       |
                                                       v
                                              [ICAP antivirus] -> [deliver to client]

The plugin boundaries are intentional. Each plugin does one thing; the operator decides what to enable. The cost of more plugins is more complexity, more CPU, more configuration surface.

What filters cannot do

Web filters do not catch everything. The limits:

• Encrypted content inside TLS: if the user uses an application that pins its own certificates and the destination is bypassed, the proxy sees nothing.
• DNS-only protocols: DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) hide DNS queries from the network. The proxy sees a connection to 1.1.1.1:443; the actual queries are inside.
• Out-of-band channels: a user who can SMS, copy to USB, or use a personal hotspot bypasses every web filter the firewall implements.
• Unknown applications: a brand-new service that the URL database does not yet categorise is, from the proxy’s view, uncategorised. The default behaviour depends on the policy — block by default, allow by default, or “ask” via an interstitial.

The discipline: web filters are one layer. They reduce the surface area; they do not eliminate it. The estate’s security comes from layers — DNS-level filtering, endpoint protection, user training, network segmentation — not from any single component.

Summary

• TLS interception gives the firewall plaintext. The filtering layer decides what to do with the plaintext.
• URL category databases (commercial and community) drive hostname-based policy.
• Content type, file extension, and file hash matching enforce data-loss and malware rules.
• SNI-based matching is reliable for HTTPS, but ECH breaks it for sites that opt in.
• Filters cannot catch everything — DNS-over-HTTPS, out-of-band channels, and unknown applications all bypass the proxy.
• The discipline: deploy user authentication, monitor what is blocked, and review the policy quarterly.