Running OS v6.38, wondering if there is a way to block incoming IP’s be region. We have a 3CX system that is constantly blacklisting IP’s from foreign countries, and I have worked with other brands of routers that have a geological feature that allows IP’s based on location which would help in our situation as the IP’s being blacklisted by the VOIP system are all from Europe/Asia/Africa and 99.9% of the legit traffic should be from North America. Anyway to block IP’s based on location with my version of OS?
There’s no built-in geo-reference feature in RouterOS.
You will have to use some other source of data to choose your IP ranges and either manually create an address list to your liking, or you can automate it with scripting or BGP distribution.
Sounds like a bit more effort than I and the client would like to put into it. Would be more cost efficient to replace the router with a make/model that supports that feature.
Pretty cool link. The firewall syntax they use shows this was designed for a bit older revs of RouterOS, but it will work just fine in modern revs as well. You may also want to cross-check the address lists generated against some other sites with similar lists, because this can change from time to time.
I don’t recall whether the IP > Firewall > Raw functionality was introduced by version 6.38 or not - but if it is in your system, you may want to replace the drop rules in the filter with drop rules in RAW (which also prevents blocked hosts from consuming resources in state tracking)
e.g.:
/ip firewall raw add chain=prerouting action=drop src-address-list=CountryIPBlocks
/ip firewall raw add chain=prerouting action=drop dst-address-list=CountryIPBlocks
/ip firewall raw add chain=output action=drop dst-address-list=CountryIPBlocks
Is there a way to permit only the dst-address-list=CountryIPBlocks? What I’d like to do is add my “good guys” to CountryIPBlocks, drop all the bad guys, then permit only the good guys.
How performant is this solution ? Im running here an RBM33G and for germany alone the website generates nearly 10.000 entries. Big impact on routing perfomance ?
/ip firewall raw
add action=accept chain=prerouting log-prefix="dropped by geo IP blocked ranges" src-address-list=\
CountryIPBlocksToAllowToAllow
add action=accept chain=prerouting dst-address-list=CountryIPBlocksToAllowToAllow log-prefix=\
"dropped by geo IP blocked ranges"
add action=accept chain=output disabled=yes dst-address-list=CountryIPBlocksToAllowToAllow log-prefix=\
"dropped by geo IP blocked ranges"
add action=drop chain=prerouting comment="Prerouting DENY ALL" log=yes log-prefix=\
"dropped by geo IP blocked ranges"
add action=drop chain=output comment="Output DENY ALL" log=yes log-prefix="dropped by geo IP blocked ranges"
Basically flip the “drop” in the above 3 rules into an “accept”, then add 2 more rules following - a preroute chain and an output chain with no conditions so they function as a basic “deny all”. (and so these must be the bottom 2 rules in the RAW table.)
EDIT to add:
Make sure to add your local LAN IP ranges in the whitelist or you will break any hairpin nats. My solution was two bespoke rules just for the LANs address list so looks like this now:
/ip firewall raw
add action=accept chain=prerouting log-prefix="dropped by geo IP blocked ranges" src-address-list=Local
add action=accept chain=output dst-address-list=Local log-prefix="dropped by geo IP blocked ranges"
add action=accept chain=prerouting log-prefix="dropped by geo IP blocked ranges" src-address-list=\
CountryIPBlocksToAllowToAllow
add action=accept chain=prerouting dst-address-list=CountryIPBlocksToAllowToAllow log-prefix=\
"dropped by geo IP blocked ranges"
add action=accept chain=output disabled=yes log-prefix="dropped by geo IP blocked ranges" src-address-list=\
CountryIPBlocksToAllowToAllow
add action=accept chain=output dst-address-list=CountryIPBlocksToAllowToAllow log-prefix=\
"dropped by geo IP blocked ranges"
add action=drop chain=prerouting comment="Prerouting DENY ALL" log=yes log-prefix=\
"dropped by geo IP blocked ranges"
add action=drop chain=output comment="Output DENY ALL" log=yes log-prefix="dropped by geo IP blocked ranges"
Without any knowledge of the source of information or how current, its basically useless.
Also bots can be setup to be from any country so country blocking is a fallacy to begin with.
All these extra tools eat up CPU and complicate the config so that any issues are hard to find, and in 99% of cases having a drop all rule at the end of input chain and forward chain suffices for the homeowner.
If one is a business, then one may have
a. an edge router in front of the MT
b. a business class ISP connection where the ISP may guarantee up times and protections
c. the MT router is not designed for DDOS attacks and the like,
Also business can pay for services for those edge routers etc..
There are some services available for the MT that are more specific to known bad actors regardless of country and thus more accurate, efficient and up to date.
ex1 - https://axiomcyber.com/mikrotik-support/
ex2 - https://itexpertoncall.com/promotional/firewall_nat.html ( most cost effective solution for you or your clients IMHO )
I don’t see how the info I posted is inaccurate. It contains a bash snippet which downloads current allocations directly from RIPE’s ftp. It builds the download URL using current system date.
You can check RIPE’s ftp contents using this http mirror: https://ftp.ripe.net/pub/stats/ripencc/ . As you can see it’s being regularly updated.
I spotted the problem, as I got an allocation from RIPE in 2021 which was previously allocated to The Russian Federation. Recently few of my clients decided to block russian IPs and used free tools, like quoted above, to obtain russian allocations. Most of these tools return my ip block as being allocated to Russia.
I agree that this kind of block is probably useless, but people are implementing it. The link I provided shows them how to properly obtain IP assignment data.
No I said, the proper solution is for a business ISP account with or without an edge router such that the MT is not involved in such processes.
For the homeowner any of the two services is probably overkill but effective, in particular the second link is not all that expensive and does all the legwork.
As for as RIPE goes, could care less about it. Blocking by country without any other intelligence involved is just a waste of time.
It’s as accurate as it’s going to get. That data (not only from RIPE, but all the regional RIRs, are used for example for RPKI as well. Yes, they make mistakes sometimes, it happens, but they are the ‘authoritive’ supplier, as well as maintainer of this data. There are a LOT of things, that depend on this information being accurate (incl. GeoIP databases).
Then as the custodian of that IP Space / ASN, you should be contacting the RIR to correct that. In fact, RIPE has one of the best management web sites that I’ve seen in a long time relating to IP resources. Chances are, you more than likely could have fixed it yourself too. In fact, I know for a fact that RIPE’s database does have a “Country” attribute that can be used on a INET / INET6 object to specifically indicate in which country the IP range is used…
Our prefixes was mistakenly listed in Team CYMR’s BOGON lists a few years ago due to a f-up that our local RIR did in these databases. Took me 1 email, and 30 minutes and the entire issue was resolved globally.
Then as the custodian of that IP Space / ASN, you should be contacting the RIR to correct that. In fact, RIPE has one of the best management web sites that I’ve seen in a long time relating to IP resources. Chances are, you more than likely could have fixed it yourself too. In fact, I know for a fact that RIPE’s database does have a “Country” attribute that can be used on a INET / INET6 object to specifically indicate in which country the IP range is used…
Our prefixes was mistakenly listed in Team CYMR’s BOGON lists a few years ago due to a f-up that our local RIR did in these databases. Took me 1 email, and 30 minutes and the entire issue was resolved globally.
The problem was not in RIPE’s db, but in mikrotikconfig.com. I had proper “Country” attribute set since I got the allocation. Other sites like ipinfo or various whois websites reported proper country. I mailed ISP Supplies several times and got no response. My prefix however disappeared from the russian list, so they either updated their lists, or removed it manually. I suspect the latter, because now my prefix is absent entirely from their lists.