RAM-only usage (no NAND flash wear, no storage destruction)
Changelog
v0.9.2
Added
Uvicorn now runs with --proxy-headers --forwarded-allow-ips *
→ Logs correctly show the real client IP when behind a reverse proxy (X-Forwarded-For / X-Real-IP).
Changed
Default address-list timeout increased to 06:00:00
(backend default and UI placeholder).
v0.9.1
Added
Environment variable MIKROTIK_LIST_NAME to define the default MikroTik address-list name.
Safe MikroTik import format using:
:do { add … } on-error={}
Prevents script failures caused by duplicates.
Unified output format for /custom.rsc, /all.rsc, and /mikrotik.rsc
(all now use the safe do wrapper logic).
Single /ip firewall address-list header to reduce script size.
HTML UI now uses MIKROTIK_LIST_NAME as the placeholder for the address-list input.
Changed
Removed all remove [find] calls to avoid clearing existing lists on each update.
Improved /24 aggregation logic for large feeds.
Improved handling of per-source comments.
Whitelist evaluation is now consistent across all output types.
Fixed
Placeholder text mismatch in the HTML generator.
Behavioral differences between /all.rsc and /custom.rsc.
Stability issues when processing very large blocklists.
v0.9.0
Initial public version with:
YAML-based configuration
Global whitelist
Address-list compilation
/custom.rsc and /all.rsc
Simple HTML UI
Feedback, testing results, and suggestions are welcome.
Personally I will never fetch and import .rsc from untrusted source. Not implying that OP has malicious intentions but site or site account can be hacked and generate malicious .rsc which can compromise router. Better use script that runs on ROS which is parsing and importing Blocklist IP’s into address list similarly like this site generated .rsc does.
On one hand, a (hacked?) account from 3 years ago, then, coincidentally, an account just created to congratulate someone...
Coincidentally, someone registers right afterward to congratulate someone... and that's it...
As I've written dozens of times,
trusting anyone you see to import .rsc files is one of the stupidest things you can do.
The next stupidest thing is to update as soon as the software is released.
Those who are looking for devices to hack in order to establish a botnet,
first of all distribute these .rsc files to be imported, and then, at the right time, when there are quite a few of them,
they give whatever commands they want in the .rsc file and have thousands of zombie machines at their disposal that do whatever they want.
You’re absolutely right — and that is precisely the concern we had internally as well.
It’s why I’m asking about interest before going any further, and why I’m considering publishing the full project on GitHub. The idea is not to make people blindly trust and import opaque .rsc files from a third party, but rather to allow everyone to:
Review the full source code
Understand exactly how the lists are generated
Run their own instance if they wish
Generate their own scripts locally or from a trusted environment
Users should not be dependent on a black-box service that could theoretically be abused.
I’m not really active on this forum and I’m a bit concerned to see in the http logs that some people simply implemented the script as-is, directly fetching all.rsc without any customization or review.
I’d be curious to know why you think this setup would not impact flash memory.
As soon as an import is done, the configuration database will be updated, and written to flash. There is a 2 hour timeout on the address-list entries, and you update them every 1.5 hours. This will put a load on your flash.
Just to explain, I am an employee of the company that created this script. Usually, I just read the messages on the forum. But this time, I thought it would be good to encourage the work done at our company, which is why I registered.
Now, everything is open source and can be checked and reviewed by everyone here! It would be pretty dumb if it was malicious and open like that, right?
From this perspective, as written thousands of times on the forum, not a single device of mine has failed since 2007 due to excessive writes to the NAND/XOR flash,
including devices where The Dude or User Manager was running.
The structure of the generated file is (obviously) pretty simple:
change to "directory" /ip firewall address-list
remove old blacklist remove [find list="blacklist"]
add n items to the new blacklist add list=blacklist address=2.57.121.25 comment="ssh_wifx" timeout=02:00:00
As I see it, the "remove" #2 can be moved to the "resident" system script.
As well (I believe) the "change of directory" could be moved to the "resident" system script.
What would remain is only the "pure" list in the form of n lines with the SAME structure: add list=blacklist address=<IP address> comment="original_source_list" timeout=02:00:00
Could this structure be validated, line by line, locally, by the script before importing?
This way the worse thing that can happen is to have a "malicious" list including half of the "good" internet, at the most a nuisance and not a security risk.
Thanks,
”Malicious” can only be faulty IP’s. the python script check the syntax of the remote lists, including subnet masks before caching them.
It does not remove privates network, that has to be done with the whitelist parameter.
remove [find list=”listname”]
is part of the result because it can be set with the custom address-list setting. We use it to generate multiple addresses lists with the same service.
Can be easily adapted. Also the blocklist list is a yaml file. If the ID is unchanged, custom link will stay the same
If a software error results in something like "0.0.0.0/0" goodbye, all the internet...
Even IP sources can be wrong and block entire network blocks...
We're reinventing the weel here.
We've already worked on scripts that import lists (not .rsc imports) here on forum,
and there were some solid checks before importing anything larger than a /22...
There’s a /8 limitation hardcoded in the script, but should be good to add it to parameter file.
Whitelist is authoritative over lists.
I do not agree, it’s a better wheel, found scripts on the forum are limited to 64 KByte environnement variable and loads only 4000 entries… It’s why we move to .rsc direct import.
Aggregation is to prevent multiple entries from multiple blocklists
Script also merge into /24 /32 addresses is there’s more than 100 addresses. Should be added in the parameter file.
You searched wrong, and I don't intend to search for you,
since the method for loading the entire file into memory (and it depends on how much memory the router has, obviously), has existed for years and I published it... Can be more than 16MB, if device has the memory...
Well, the wheel was not invented in one go, from the first experiments with square wheels, through the evolution to triangular wheels (one bump less ) later reversed to hexagonal wheels (more but smaller bumps), etc., before getting to our round ones.
Bad servers are often mixed with good ones, like CDNs, and ARBITRARILY blocking an entire block,
just because YOU think it's the right thing to do, actually betrays the trust placed in blocklists,
because it's YOU who makes the decision, not the ORIGINAL source.
Service
) later reversed to hexagonal wheels (more but smaller bumps), etc., before getting to our round ones.