Threat intelligence and blocklists — feeding the firewall from external sources

A firewall with no threat intelligence is a firewall that knows only what it sees. A firewall with threat intelligence knows what others have seen — what IPs the abuse.ch community has reported as botnet controllers, what domains Phishtank has catalogued as phishing, what file hashes AV vendors have flagged as malware. The feeds are everywhere; the discipline is in turning them from data into enforcement. This lesson covers the categories of feeds, the protocols they use, the integration with OPNsense aliases and DNS, and the false-positive discipline required to act on them.

Categories of threat intelligence

Threat intelligence feeds come in several shapes:

The firewall consumes the first three operationally. File hashes are matched by ICAP/AV, not by the firewall directly. YARA and STIX/TAXII are more useful in SIEM than on the firewall.

Pulling feeds into OPNsense

OPNsense supports threat intelligence integration through several mechanisms:

1. Aliases with URL table — System → Aliases → add an alias with type “URL Table”. The alias pulls a remote text file (one entry per line) and uses the entries as firewall table members. The alias refreshes on a schedule.

2. DNS blocklists — Services → Unbound DNS → Blocklists. The DNS resolver applies the blocklist as NXDOMAIN (or NULL) responses for matching names.

3. pfBlockerNG — a plugin that aggregates IP blocklists, geo-IP, and DNS blocklists into a unified interface. The most common integration for estates that consume multiple feeds.

4. Custom scripts — cron + curl to fetch feeds and rebuild aliases via configctl.

$ configctl alias list 2>/dev/null | head -20; echo '---'; cat /var/db/aliastables/spamhaus_drop.txt 2>/dev/null | head -10

--- (illustrative)
spamhaus_drop: 12480 entries, last update 2026-08-14 03:00:00
abuse_ch_feodo: 3842 entries, last update 2026-08-14 04:00:00
binarydefense_banlist: 1205 entries, last update 2026-08-14 03:30:00
---
5.188.10.0/23
5.188.62.0/24
23.94.0.0/16
...

Applying blocklists as enforcement

A blocklist is data. Enforcement is what happens when the firewall acts on the data. The integration paths:

• Firewall rule: an alias used in a block rule — “block any → spamhaus_drop” — drops traffic from listed IPs to anywhere. This blocks inbound attacks from known-bad sources.
• Outbound block: “block LAN → spamhaus_drop” — stops internal hosts from reaching known-bad destinations. The most common application of threat intelligence.
• DNS sinkhole: matching DNS responses are replaced with a sinkhole IP, sending the host to an internal “blocked” page or just refusing the resolution.
• Proxy ACL: matching domains are blocked at the proxy layer, with a 403 response to the client.

The choice depends on the threat model:

known-bad IPs → firewall rule (drop)
known-bad domains → DNS sinkhole + proxy ACL
known-bad URLs → proxy ACL (URL-level)
known-bad hashes → ICAP/AV (file-level)

Schedule and monitoring

Feeds have a life cycle. The operator must:

1. Schedule refreshes. Most feeds update on a known cadence (Spamhaus DROP is daily, URLhaus is real-time). The OPNsense alias URL Table fetch runs on a schedule; the operator should match the schedule to the feed’s update frequency.

2. Monitor feed health. A feed that stops updating is a blind spot. The operator should alert on “feed not refreshed in 2x expected interval”.

3. Track entry counts. A feed that suddenly has 10x more entries than usual has either expanded coverage or been compromised. A feed that suddenly has zero entries has a fetch failure or a format change.

$ ls -la /var/db/aliastables/ 2>/dev/null | head -10; echo '---'; wc -l /var/db/aliastables/*.txt 2>/dev/null

--- (illustrative)
-rw-r--r--  1 root wheel  187412 Aug 14 04:00 spamhaus_drop.txt
-rw-r--r--  1 root wheel   52340 Aug 14 04:00 abuse_ch_feodo.txt
-rw-r--r--  1 root wheel   15780 Aug 14 04:00 binarydefense_banlist.txt
-rw-r--r--  1 root wheel     0 Aug 14 04:00 stale_feed.txt
 187412 spamhaus_drop.txt
  52340 abuse_ch_feodo.txt
  15780 binarydefense_banlist.txt
       0 stale_feed.txt
       

False positives and the discipline of action

Every threat feed has false positives. Spamhaus occasionally lists an IP that is shared by legitimate services. URLhaus occasionally flags a domain that was compromised and cleaned up. The discipline is in handling these:

• Don’t ignore feeds because of false positives. The 99% accuracy is worth the 1% noise.
• Do have a documented override process. When a legitimate destination is blocked, the operator (or user) needs a way to report and resolve it.
• Do track false-positive rates. A feed that frequently blocks legitimate destinations may have reduced in quality; reconsider it.
• Do not whitelist silently. Every whitelist entry is a hole in enforcement. Document with reason, owner, expiry, review date.

Summary

• Threat intelligence feeds come in IP, domain, URL, and hash flavours.
• OPNsense integrates via URL Table aliases, DNS blocklists, pfBlockerNG, or custom scripts.
• Outbound blocks (LAN → known-bad) catch malware; inbound blocks (known-bad → WAN) catch scanners.
• Schedule refreshes, monitor feed health, track entry counts, alert on stale feeds.
• False positives are inevitable. Document overrides, track rates, do not whitelist silently.