MikroTik RouterOS integration guide.

Check the version and deployment method

Use a Linux management host to validate and synchronize both complete Data-Shield feeds with dedicated RouterOS IPv4 address lists. The reviewable Python helper uses verified HTTPS and OpenSSH. It updates list membership and the two dedicated rule references; an administrator controls rule placement and activation.

Check /system resource print and /system package print. References: official address-list guide, 7.16 import error handling and configuration imports. Version compatibility is not a hardware capacity guarantee.

Plan for complete lists and staging space

The feeds contain well over 64 KiB. RouterOS fetch output=user can silently cut a response at its variable limit, and /file get contents cannot read an arbitrarily large file. Fetching a prefix or importing a truncated list is not this integration. The controller reads bounded complete bodies and checks their SHA-256, byte count, record count, strict public IPv4 syntax, order and duplicate absence against the existing public snapshot.

Allow RAM for both active lists, both staging lists and your unrelated entries. Allow router storage for a generated import file with one command per IP, which is substantially larger than the TXT files. Measure import time, CPU, disk writes and forwarding behavior on your device first. The helper's total-entry budget includes retained and unrelated entries, but it cannot translate that count into a safe RAM or flash limit for your model. Small routers may not have enough headroom. Never solve a capacity problem by cutting the list.

References: Fetch limits and file handling and storage behavior. This procedure keeps static address-list entries across router restarts. Repeated configuration imports also create storage writes; review the schedule against your hardware.

Keep Standard and Critical separate

Standard

109,123 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt

Critical

119,122 unique IPv4 addresses in this published snapshot.

https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_critical_data-shield_ipv4_blocklist.txt

Published 24 Oct 2026, 14:05 UTC. Check live counts and SHA-256.

The helper retrieves these unchanged primary URLs and the existing public snapshot metadata. It requires both responses to match one stable snapshot before contacting the router, and rejects publication metadata older than 24 hours. If GitHub has advanced before the website snapshot, the check stops and the next scheduled run can retry. The snapshot supplies integrity metadata; it is not an independent signature or a router push service.

Four reserved lists alternate between active and staging roles: DS_STANDARD_A, DS_STANDARD_B, DS_CRITICAL_A and DS_CRITICAL_B. Keep these names, the Data-Shield managed entry comment and the two rule comments exclusive to this integration. Do not attach other rules, DNS names, dynamic entries or manual exceptions to these slots. Both profiles are synchronized even if one blocking rule stays disabled. Enabling both rules blocks their union, not just addresses shared by both lists.

Prepare the controller and dedicated rules

Use an existing private management path, such as a LAN or VPN, with a tested backup and console recovery path. The Linux host needs Python 3.11 or newer, OpenSSH with SCP support and persistent private state storage. Review the helper source before saving it as /opt/data-shield/data-shield-routeros.py. Keep that file writable only by its administrator. No extra Python packages are required.

Use one dedicated automation account and one controller per router. The account needs SSH access, file transfer and permission to read and change the relevant configuration. Review the ssh,ftp,read,write policies against the installed release. RouterOS write permission is broader than these lists, so restrict the account to the controller's private source address and protect its SSH key. Keep host-key verification enabled and enroll the router fingerprint through a trusted channel. See MikroTik SSH key authentication.

Example in the Linux automation account's SSH configuration. Replace the documentation address and key path with your private management endpoint and dedicated key:

Host ROUTEROS
    HostName 192.0.2.1
    User ds-sync
    IdentityFile ~/.ssh/routeros-data-shield
    IdentitiesOnly yes
    BatchMode yes
    StrictHostKeyChecking yes

Create the following two rules once, after checking that their exact comments and the four list names are unused. Verify that WAN contains only the intended Internet ingress interfaces. The rules start disabled:

/ip firewall filter add chain=forward action=drop in-interface-list=WAN src-address-list=DS_STANDARD_A disabled=yes comment="Data-Shield Standard"
/ip firewall filter add chain=forward action=drop in-interface-list=WAN src-address-list=DS_CRITICAL_A disabled=yes comment="Data-Shield Critical"

Place these rules in the reviewed incoming-source policy before applicable accepts and FastTrack handling. They affect forwarded IPv4 traffic, including replies arriving from a listed remote address. They do not protect router-local input or IPv6. FastTracked connections and hardware-offloaded paths can bypass firewall processing; test the actual path rather than assuming a new rule changes existing sessions. Keep management and unrelated default rules intact. See FastTrack behavior and L3 hardware offloading.

Validate, stage and verify before enabling blocking

First run the helper without --apply. This verifies both full feeds and makes no router connection:

python3 /opt/data-shield/data-shield-routeros.py

Create a private /var/lib/data-shield-routeros directory owned by the automation account. Then run the following as that account. The example budget of 600,000 is an operator ceiling for all active, staging and unrelated entries, not a MikroTik model rating. Replace it with your measured capacity:

python3 /opt/data-shield/data-shield-routeros.py --apply --router ROUTEROS \
  --state-dir /var/lib/data-shield-routeros --max-total-entries 600000

The helper checks the dedicated rule references, clears only unused staging slots carrying its own entry comment, uploads locally generated commands over SCP and imports into those slots. Downloaded TXT content is never executed. It reads every staged address back over SSH and compares complete membership for both profiles before changing either rule reference. A same-sized but different list is rejected. The old active slots remain available for rollback. An unchanged publication needs no new import.

The two reference changes are sequential, not a RouterOS transaction. A handled activation error attempts to restore both old references. A connection loss or interrupted process can leave the outcome uncertain; the persistent stop marker described below prevents a blind repeat. The helper never enables, reorders or creates firewall rules.

Inspect the selected lists and counters:

/ip firewall filter print detail where comment="Data-Shield Standard"
/ip firewall filter print detail where comment="Data-Shield Critical"
/ip firewall address-list print count-only where list=DS_STANDARD_B
/ip firewall address-list print count-only where list=DS_CRITICAL_B
/ip firewall filter print stats where comment~"Data-Shield"

The first successful import uses slot B; later imports alternate. Use the list names currently referenced by the rules. Counts are a quick diagnostic, while the controller performs the full membership comparison. Once rule placement and a controlled test from a source you own have been reviewed, enable the desired Standard and/or Critical rule in WinBox or the CLI. Confirm normal connectivity and counters. Do not treat an address-list import alone as proof of packet blocking.

Schedule both updates every two hours

After a successful supervised import and enforcement test, schedule the same command on the Linux controller. This is a controller cron job, not a RouterOS scheduler script. The automation account must use the same SSH configuration and state directory as the supervised run.

23 */2 * * * ds-sync /usr/bin/python3 /opt/data-shield/data-shield-routeros.py --apply --router ROUTEROS --state-dir /var/lib/data-shield-routeros --max-total-entries 600000 >> /var/log/data-shield-routeros.log 2>&1

Have the administrator create the cron file and writable log with appropriate ownership and log rotation. The schedule uses the controller's timezone. A file lock prevents overlapping applies on that controller. Monitor nonzero exits and the age of the last confirmed successful update. A stopped controller does not refresh lists, and cron does not immediately replay missed runs after boot.

Every successful update replaces the complete membership, so additions and removals, including expired blocks and whitelist corrections, reach the active slots together for each profile. Publication, website metadata refresh and controller polling are separate schedules. Until a new import is confirmed, the router retains its previous static entries; failed retrieval does not empty active lists and does not expire stale entries automatically.

Handle failures and roll back deliberately

A failed download, checksum or capacity check before a router mutation leaves the active lists unchanged. An interrupted or unconfirmed apply leaves pending.json in the private controller state directory. Later runs refuse to apply while that marker exists. Inspect the dedicated rules, complete memberships, logs and any running import on the router before clearing it manually. Never clear the marker while an earlier import may still be running, and never run a second controller against the same slots.

For rollback, stop the controller schedule first. Verify that the retained previous slot for each profile is complete and suitable, then point only the corresponding dedicated rule back to that slot. A previous slot is retained until it becomes staging space for the next update. To remove the integration, stop the schedule, disable or remove only its two dedicated rules, check for remaining references, then remove only its four reserved lists and its uploaded data-shield-stage.rsc file. Remove the dedicated automation access when no longer needed.

This guide and helper are reviewed community tooling. The automated tests cover parsing, truncation, publication races, capacity and staging failures. RouterOS syntax, performance, storage endurance and enforcement must still be validated on the installed appliance before unattended use.