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 combination matters when you are deciding where to place the resulting data in your firewall rule hierarchy.
Why enforcement-sourced IPs are a different class of signal
Most commercial IP reputation lists draw from passive observation: scanner honeypots, spam traps, DNS logs, and threat sharing feeds that aggregate what sensors have seen recently. The confidence ceiling on a scanner-derived entry is “this IP was seen behaving badly at some point.” It carries 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, corroborated across 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 signal chain is: confirmed bad actor, independently validated, legally actioned. That is a far higher bar than a passive scanner flag.
The cost of that quality is speed. Enforcement-derived data is historical by the time it is published. C2 operators who were not arrested have already rotated infrastructure. Treat the Synergia III list as a high-confidence blacklist for the addresses that were confirmed, not as a live feed. Expect it to decay fast: C2 infrastructure typically survives a sinkholing announcement for days, not weeks, before operators move to fresh hosting. A rule refresh cycle of 24 to 48 hours is realistic; anything longer risks retaining addresses that have been legitimately reassigned.
The dataset also mixes distinct threat types. Phishing hosts, ransomware C2 servers, and botnet command infrastructure appear in the same published list but require different rule responses. A phishing IP warrants a DROP at the perimeter. A confirmed ransomware C2 address warrants DROP plus a Suricata alert if any internal host attempts to reach it, because that attempt itself is an incident. Segment 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.
bash
Create and populate the ipset
ipset create synergia3block hash:net maxelem 65536
while IFS= read -r ip; do
[[ “$ip” =~ ^#|^$ ]] && continue
ipset add synergia3block “$ip”
done < /etc/firewall/synergia3_ips.txt
Drop outbound traffic to the set
iptables -I OUTPUT -m set –match-set synergia3_block dst -j DROP -m comment –comment “Synergia3-C2-block”
Drop inbound traffic from the set
iptables -I INPUT -m set –match-set synergia3_block src -j DROP -m comment –comment “Synergia3-C2-block”
Log before dropping (optional, insert before the DROP rules)
iptables -I OUTPUT -m set –match-set synergia3block dst -j LOG –log-prefix “SYNERGIA3OUT: ” –log-level 4
iptables -I INPUT -m set –match-set synergia3block src -j LOG –log-prefix “SYNERGIA3IN: ” –log-level 4
Persist the ipset across reboots with ipset save > /etc/ipset.conf and load it at startup via your init system before iptables-restore runs. Use ipset restore in your 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:
bash
ipset flush synergia3block
while IFS= read -r ip; do
[[ “$ip” =~ ^#|^$ ]] && continue
ipset add synergia3block “$ip”
done < /etc/firewall/synergia3_ips.txt
Schedule this via 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. This catches any internal host attempting to reach a listed address before the packet leaves. On a VLAN-segmented network, replicate the rule on each VLAN interface where infected hosts could plausibly reside. Do not rely on a single WAN-facing rule; traffic routed between internal VLANs can bypass it.
DNS sinkholing on pfSense or Pi-hole
DNS sinkholing is the right layer for the domain portion 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 ever 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. This 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 the Group Management > Adlists feature to pull a hosted domain list. Pi-hole applies NXDOMAIN by default, which is functionally equivalent to the sinkhole redirect for blocking purposes.
Log DNS blocks. On Pi-hole, the query log captures all blocked lookups with timestamps and originating IP. That log is what maps a DNS sinkhole hit back to the original Synergia domain entry for any subsequent audit.
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 approach for a list of this size is to define a variable group in suricata.yaml:
yaml
vars:
address-groups:
SYNERGIA3_C2: “[198.51.100.1/32,203.0.113.0/24]”
Then reference it in rules:
alert tcp $HOMENET any -> $SYNERGIA3C2 any (msg:”Synergia3 C2 outbound connection attempt”; flow:toserver,established; sid:9000001; rev:1; classtype:trojan-activity;)
alert tcp $SYNERGIA3C2 any -> $HOMENET any (msg:”Synergia3 C2 inbound connection attempt”; flow:toserver,established; sid:9000002; rev:1; classtype:trojan-activity;)
Set classtype:trojan-activity rather than a generic policy class; this ensures the alerts appear in the correct priority bucket in your SIEM or log aggregator. Assign 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 a dedicated variable and a higher-priority rule with priority:1. Phishing hosts can sit at priority:2. This gives you filtering options in Kibana or any other tool consuming EVE JSON output without re-parsing the raw alert text.
VLAN segmentation to reduce false positives
Running the same block list against all VLANs without modification produces noise. A guest Wi-Fi VLAN will generate alerts for traffic that is entirely unrelated to C2 activity on your production hosts. A printer VLAN has no legitimate reason to contact any external IP at all, so the block list is redundant there; a blanket outbound-to-internet block is more appropriate.
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 the specific external destinations those devices actually need. This 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. This is the minimum required for an audit trail showing that a specific block was triggered by 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 attempted to contact confirmed criminal infrastructure, which is worth looking at regardless of whether the block succeeded.