From IOC Lists to Firewall Blocks: Building a Threat Feed Pipeline Without a Paid Subscription — Part 2

This Is Part Two

#

In Part One, I wrote about building a small threat-feed pipeline from community indicators to firewall blocks.

The useful part was not the feed URL. The useful part was everything around it: normalization, organization-level selection, allowlists, expiry, separate block and monitor modes, and enough logging to prove what the firewall received.

The awkward part was DNAT.

The SFOS 21.5 validation showed that third-party threat-feed blocking worked on supported traffic paths, but not on the bare inbound port-forward path under test. That meant a known-bad source could exist in the same Pramaan feed, be blocked elsewhere, and still not receive the same threat-feed evaluation when it targeted a DNAT-published service.

I did not want to hide that finding because it changed the meaning of the control.

A security feature is not defined only by what it blocks.

It is also defined by where it does not run.

Sophos documented broader inbound forwarded-traffic matching for SFOS 22, including DNAT and WAF. After the upgrade, the same question was tested again.

This time, the answer was different.

What Changed In SFOS 22

#

Sophos now separates the relevant Active Threat Response matches into three useful ideas:

• Destination match for traffic going to an IP, domain, or URL in a threat feed,
• Local source match for an internal source that appears in a threat feed,
• Remote source match for an inbound source on forwarded traffic such as DNAT and WAF.

That third case is the important one for this post.

The SFOS 22 Active Threat Response documentation describes a remote source match as a source-IP match on inbound forwarded traffic. This is the path that was missing from the SFOS 21.5 validation.

After the upgrade, the existing PramaanIPBlock feed synchronized successfully and began producing both destination-match and remote-source-match drops.

No new firewall plugin.

No second feed pipeline.

No separate paid threat-intelligence source.

The same plain-text feed now had an additional enforcement path.

The Two Log Lines That Explained The Change

#

The clearest validation came from seeing two different match types next to each other.

The Drop destination match event is the familiar direction. A system attempted to reach a destination that existed in the threat feed, and Sophos dropped it.

The Drop remote source match event tells a different story. The source IP itself existed in PramaanIPBlock, the traffic was inbound, and the firewall stopped it on the forwarded path.

In the anonymized validation scenario, that forwarded path was DNAT.

That distinction matters because a DNAT rule exists specifically to publish an internal service through a public address. The final deny rule is no longer the protection in that case; the traffic has a rule that can forward it. The firewall must evaluate the remote source before allowing the connection to continue toward the translated server.

On SFOS 21.5, that was the blind spot.

On SFOS 22, the logs finally showed the feed match happening on that path.

The DNAT Validation Became Visible

#

The wider log view made the pattern difficult to dismiss as a single lucky event.

Multiple remote public sources were matched against PramaanIPBlock. The destination varied across published server addresses, but the outcome stayed the same:

PramaanIPBlock
    -> remote source matched
    -> Active Threat Response event 18010
    -> connection dropped at the firewall
    -> DNAT-published server not reached by that connection

This was the practical outcome the validation was intended to confirm.

Not just blocking a destination an internal system tried to contact.

Not just protecting services owned by the firewall itself.

Blocking a known-bad remote source while it was trying to reach a service published through DNAT.

That means the internal server is no longer depending only on its own application controls, IPS policy, or a separately maintained firewall IP group for this class of known-bad source. Those controls still matter, but the Pramaan feed now participates before the forwarded connection reaches the server.

Defense in depth is much more convincing when the layers actually run on the path being defended.

Then The Dashboard Got Loud

#

The first post showed 496 ATP blocks, 169 unique source IPs, and 14 countries in its 24-hour observation window.

After the SFOS 22 upgrade and the addition of inbound forwarded-traffic coverage, one later 24-hour Wazuh view showed:

Those numbers are large, but they need to be read honestly.

This is not a controlled benchmark between SFOS 21.5 and SFOS 22. The traffic mix, feed contents, exposed services, and observation dates were not frozen in a lab. I would not claim that SFOS 22 made the feed a specific number of times more effective based only on these two dashboard snapshots.

The useful conclusion is narrower:

Once remote-source matching covered inbound forwarded traffic, the firewall observed and blocked a much larger class of feed matches that the earlier validation did not cover.

That is a coverage result, not a performance benchmark.

And it is still operationally significant.

The Traffic Was Mostly TCP

#

The second Wazuh view added context that the headline block count could not.

The sources were distributed across multiple countries. The destinations included several published server addresses. TCP accounted for 95% of the observed ATP blocks, with UDP at 3.39% and a small remainder from ICMP.

This is closer to what internet-facing infrastructure actually feels like.

It is not one cinematic attack.

It is repeated connection attempts, scanners, reused infrastructure, automated probing, and sources that keep returning long after an upstream community list changes.

That is why the block-and-monitor lifecycle in Pramaan still matters. SFOS 22 expanded where the firewall can enforce the feed, but it did not replace the publishing logic behind the feed:

• upstream sources still need normalization,
• CIDR inputs still need controlled handling,
• allowlists still need to win,
• stale indicators still need expiry,
• local sightings still need to influence promotion,
• and feed access still needs an audit trail.

The firewall became a better consumer.

The feed still needs to be safe.

What SFOS 22 Did Not Solve

#

It would be easy to end the story at 17,774 blocks and declare victory.

That would miss the engineering work that remains.

A Match Is Not A Confirmed Intrusion

#

A threat-feed match says the source or destination existed in a selected feed. It does not prove that every packet was an exploitation attempt or that the target application was vulnerable.

The value is pre-emptive filtering of known-bad infrastructure, not perfect attribution.

A Feed Is Not A Firewall Policy

#

DNAT rules, service restrictions, IPS, web protection, authentication, patching, and server-side controls remain necessary. Threat feeds reduce exposure to listed infrastructure; they do not make a published service safe by themselves.

More Coverage Means More Need For Exceptions

#

When a control starts applying to additional traffic paths, a false positive can affect more services. The allowlist workflow becomes more important after the upgrade, not less.

Logs Must Be Enabled Deliberately

#

Sophos notes that remote-source event logging is not enabled by default. The SFOS 22 log settings documentation describes remote-source matches as inbound source matches for forwarded traffic such as DNAT and WAF. If those Active Threat Response logs are not enabled and forwarded to the SIEM, the control can work without giving the analyst the visibility shown here.

The Validation I Would Repeat

#

The upgrade result is strong enough to use operationally, but I still want a repeatable test for every important published service:

1. Put a controlled test source into a Pramaan block feed.
2. Confirm Sophos has synchronized the latest feed.
3. Connect through the public address and the real DNAT rule.
4. Confirm Drop remote source match with the expected feed name.
5. Correlate the public destination with the translated internal server.
6. Confirm the connection never appears in the server’s application or network logs.
7. Remove or expire the test indicator and confirm normal access returns.

That last step matters.

Testing how a block is removed is part of testing how safely it was added.

What Stayed With Me This Time

#

The first implementation proved that a community-feed pipeline could reduce noise without buying another threat-intelligence subscription.

The SFOS 21.5 validation proved that working controls still have boundaries.

The SFOS 22 upgrade proved that one of those boundaries had moved.

The satisfying part was not the dashboard number, although 17,774 blocks in a day is difficult to ignore.

The satisfying part was much smaller:

Drop remote source match

That line connected the community indicator, the Pramaan publishing layer, the firewall, the DNAT rule, and the server behind it.

The first post was about making threat feeds safe enough to use.

This one was about making sure they run where the risk actually is.

Feeds are still easy.

Safe feeds are still engineering.

But now the DNAT path is part of the story too.

And the internal servers are quieter for it.