Neurowall syncs indicators from OTX and AbuseIPDB on a periodic schedule and writes matches straight into the same blocklist enforcement path used for manual bans — no separate "threat intel mode," no delay between a feed update and a block taking effect.
A firewall's own visibility is limited to traffic it has actually seen — it has no way to know a source is malicious until that source has already done something to it. Threat intelligence feeds close that gap by importing knowledge from external observation: sources already confirmed malicious elsewhere get blocked here before they've made a single request.
The same botnet nodes, scanning hosts, and compromised servers often attack many targets — a feed match means a source flagged elsewhere is blocked here before it gets the chance to probe your infrastructure first.
Keeping a blocklist current by hand against a constantly shifting set of malicious infrastructure isn't sustainable — automated feed sync is what keeps it current without manual effort.
OTX and AbuseIPDB each aggregate from different community and vendor sources — running both covers more ground than relying on a single feed.
If a feed silently stops updating, protection quietly degrades to whatever was last synced — visibility into feed health matters as much as having the feeds in the first place.
Each feed runs on an independent periodic schedule. When a feed sync completes, matched indicators are upserted into the indicator store — a duplicate indicator already known from a prior sync updates its threat level, confidence, and source rather than failing on a uniqueness conflict, while preserving when it was first seen. From there, indicator matches are written into the exact same blocklist lookup table used for manual IP/CIDR bans, just tagged with a "threat feed" source so drop telemetry can distinguish the two after the fact.
Because feed-sourced blocks land in the same blocklist as manual bans, everything described in Pipeline Profiles about bans always enforcing regardless of mode applies to threat-intel blocks too.
Threat intelligence is treated as an optional enhancement layer, not a hard dependency — this is one of the documented cases where Neurowall deliberately fails open rather than closed, because losing external threat data shouldn't mean losing the firewall's core enforcement.
| Scenario | What happens |
|---|---|
| One feed is unreachable | That feed's sync fails independently — the other feed continues updating normally, unaffected |
| All feeds are unreachable | The firewall continues operating on its last-known indicator set (or none, if never synced) — core rule and DDoS enforcement is entirely unaffected |
| A feed sync produces a duplicate indicator | Upsert logic updates the existing record instead of failing on a unique-constraint violation — sync doesn't halt on already-known indicators |
| Graceful mode vs. strict mode | Graceful mode logs a warning and continues on initial feed failure, prioritizing availability; strict mode instead surfaces the failure as an error — configurable per deployment's risk tolerance |
Indicator data is held in an in-process memory structure for fast lookup, rehydrated from the database on startup — there is no external cache service in the current design. If you've seen older documentation referencing a caching layer for this feature, treat that as describing a prior design; the current implementation doesn't have that dependency.