Known-Bad Sources,
Blocked Automatically.
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.
Your own traffic logs won't tell you
what's bad on day one.
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.
Sync, cache,
write straight to the blocklist.
duplicate indicators updated in place, not rejected
same path as manual/CIDR bans — tagged "threat feed"
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.
A feed outage doesn't take
the firewall down with it.
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 |
In-memory, database-backed —
no external cache dependency.
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.