Using IP Reputation Data from Operation Synergia in Your Botnet Firewall Rules

Using IP Reputation Data from Operation Synergia in Your Botnet Firewall Rules

Operation Synergia III ran from July 2025 to January 2026, coordinated by INTERPOL across 72 countries. It sinkholed more than 45,000 IP addresses and servers tied to phishing, malware, and ransomware activity, with 94 arrests and 212 devices seized. The private sector partners feeding intelligence into it included Group-IB, Trend Micro, and S2W. That is the sort of chain I would trust for firewall rules, as long as I treat the list as historical rather than current.

Why enforcement-sourced IPs are a different class of signal

Most commercial IP reputation lists come from passive observation: scanner honeypots, spam traps, DNS logs, and shared threat feeds. The best they can usually say is that an IP behaved badly at some point. There is no chain of custody and no confirmed attribution.

A sinkholed address is different. For an IP to land in the Synergia III dataset it had to be identified by Group-IB or Trend Micro as part of active C2, phishing, or ransomware infrastructure, checked against INTERPOL Cyber Activity Reports, and then actioned by law enforcement. Trend Micro’s contribution to the original Synergia operation alone generated 63 INTERPOL Cyber Activity Reports, leading to 30 house searches. The chain is much stronger than a passive scanner flag.

The trade-off is speed. By the time enforcement-derived data is published, it is already historical. C2 operators who were not arrested may already have moved on to new infrastructure. I would treat the Synergia III list as a high-confidence blacklist for the addresses that were confirmed, not as a live feed. Expect it to age quickly: C2 infrastructure usually survives a sinkholing announcement for days, not weeks, before operators shift to fresh hosting. A refresh cycle of 24 to 48 hours is realistic; anything slower risks keeping addresses that have been reassigned.

The dataset also mixes different threat types. Phishing hosts, ransomware C2 servers, and botnet command infrastructure all end up in the same published list, but they do not need the same response. A phishing IP warrants a DROP at the perimeter. A confirmed ransomware C2 address warrants DROP plus a Suricata alert if any internal host tries to reach it, because that attempt is an incident. Split the list before you apply it.

Translating the sinkhole data into iptables, pfSense ACLs, and DNS entries

Building an ipset block list for iptables

Pull the published IP list into a plain text file, one address or CIDR prefix per line. Strip any comment lines before processing.

ipset create synergia3_block hash:net maxelem 65536
while IFS= read -r ip; do
  [[ "$ip" =~ ^#|^$ ]] && continue
  ipset add synergia3_block "$ip"
done < /etc/firewall/synergia3_ips.txt

iptables -I OUTPUT -m set --match-set synergia3_block dst -j DROP -m comment --comment "Synergia3-C2-block"
iptables -I INPUT -m set --match-set synergia3_block src -j DROP -m comment --comment "Synergia3-C2-block"

iptables -I OUTPUT -m set --match-set synergia3_block dst -j LOG --log-prefix "SYNERGIA3_OUT: " --log-level 4
iptables -I INPUT -m set --match-set synergia3_block src -j LOG --log-prefix "SYNERGIA3_IN: " --log-level 4

Persist the ipset across reboots with ipset save > /etc/ipset.conf and load it at startup through your init system before iptables-restore runs. Use ipset restore in rc.local or a dedicated systemd unit with Before=iptables.service.

When you refresh the list, flush and rebuild rather than patching individual entries. The full set is small enough that a flush-and-reload takes under a second:

ipset flush synergia3_block
while IFS= read -r ip; do
  [[ "$ip" =~ ^#|^$ ]] && continue
  ipset add synergia3_block "$ip"
done < /etc/firewall/synergia3_ips.txt

Schedule that with cron or a systemd timer at your chosen refresh interval.

Loading Synergia addresses as a pfSense alias

In pfSense, go to Firewall > Aliases > IP and create a new alias of type URL Table (IPs). Set the URL to wherever you are hosting the cleaned, single-address-per-line list. Set the refresh frequency to match your chosen interval; pfSense will poll the URL and rebuild the alias automatically.

Once the alias exists, attach it to ACL rules on the relevant interfaces. Go to Firewall > Rules, select the interface (WAN or the LAN interface facing your most exposed segment), and add a rule with action Block, source or destination set to the alias, and logging enabled. Place the block rule above your pass rules.

For outbound C2 blocking, the most direct approach is a block rule on the LAN interface with destination set to the alias. That catches any internal host trying to reach a listed address before the packet leaves. On a VLAN-segmented network, repeat the rule on each VLAN interface where infected hosts could plausibly sit. A single WAN-facing rule will not catch traffic that stays inside the firewall.

DNS sinkholing on pfSense or Pi-hole

DNS sinkholing is the right layer for the domain part of the Synergia dataset. C2 operators who rotated their IP addresses after the operation may still be reachable via the same domain names if those were published. Redirecting queries for those domains to 0.0.0.0 or a locally hosted page stops resolution before a TCP connection attempt is made.

On pfSense with Unbound, add overrides under Services > DNS Resolver > Host Overrides. For each C2 domain from the dataset, set the host and domain fields and point the IP to 0.0.0.0. That is manageable for a short list; for anything over 50 domains, write directly to the Unbound custom options box:

local-zone: "maliciousdomain.example" redirect
local-data: "maliciousdomain.example A 0.0.0.0"

On Pi-hole, add the domains to a custom blocklist file under /etc/pihole/custom.list or use Group Management > Adlists to pull a hosted domain list. Pi-hole applies NXDOMAIN by default, which is close enough to a sinkhole redirect for blocking.

Log DNS blocks. On Pi-hole, the query log captures blocked lookups with timestamps and the originating IP. That log is what maps a DNS sinkhole hit back to the original Synergia domain entry for later review.

Writing Suricata rules against the Synergia dataset

A static IP list translates directly into Suricata rules using the ip_rep keyword or a variables file. The cleaner option for a list this size is to define a variable group in suricata.yaml:

vars:
  address-groups:
    SYNERGIA3_C2: "[198.51.100.1/32,203.0.113.0/24]"

Then reference it in rules:

alert tcp $HOME_NET any -> $SYNERGIA3_C2 any (msg:"Synergia3 C2 outbound connection attempt"; flow:to_server,established; sid:9000001; rev:1; classtype:trojan-activity;)
alert tcp $SYNERGIA3_C2 any -> $HOME_NET any (msg:"Synergia3 C2 inbound connection attempt"; flow:to_server,established; sid:9000002; rev:1; classtype:trojan-activity;)

Use classtype:trojan-activity rather than a generic policy class so the alerts land in the right priority bucket in your SIEM or log aggregator. Put the SIDs in a range you own so they do not collide with downloaded rulesets.

Split the address variable by threat category if you separated the list earlier. Ransomware C2 addresses get their own variable and a higher-priority rule with priority:1. Phishing hosts can sit at priority:2. That gives you filtering options in Kibana or any other tool consuming EVE JSON output without re-parsing the alert text.

VLAN segmentation to reduce false positives

Running the same block list against all VLANs without changes creates noise. A guest Wi-Fi VLAN will generate alerts for traffic that has nothing to do with C2 activity on production hosts. A printer VLAN has no sensible reason to contact any external IP at all, so the block list is pointless there; a blanket outbound-to-internet block is the better fit.

Apply the Synergia rules narrowly. On VLANs hosting servers or workstations with direct internet access, apply the full Suricata rule set and the firewall ACL. On IoT or isolated VLANs, replace the specific C2 list with a default-deny outbound rule and whitelist only the external destinations those devices need. That cuts alert volume and makes real hits easier to spot.

In pfSense, assign the ACL alias only to the LAN and server VLAN interfaces. In Suricata, use HOME_NET to reflect the CIDR ranges of those segments only. Adjust suricata.yaml so that HOME_NET excludes your IoT and printer VLANs rather than using the default catch-all.

Logging blocked connections for audit

The ipset LOG rules above write to the kernel log, which lands in /var/log/kern.log or your syslog-ng/rsyslog destination depending on configuration. Add a dedicated rsyslog rule to capture lines prefixed with SYNERGIA3_OUT: or SYNERGIA3_IN: and write them to a separate file:

:msg, startswith, "SYNERGIA3" /var/log/firewall/synergia3_blocked.log
& stop

Each log line contains the source IP, destination IP, port, and timestamp. To map a blocked destination back to the original Synergia list entry, run a simple grep or awk join against the source list file keyed on destination IP. That gives you the audit trail showing that a specific block came from a specific enforcement-sourced entry.

In pfSense, the firewall log under Status > System Logs > Firewall captures blocks by alias name if you named the alias clearly. Export those logs to syslog and ingest them into Graylog or a similar collector alongside your Suricata EVE JSON stream. Index on the destination field and create a saved search filtered to the Synergia alias name. Any hit in that search is a host on your network that tried to contact confirmed criminal infrastructure, which is worth a look even if the block worked.