Centralized MAC blacklist.. any idea to make it?

I need a centralized MAC blacklist.. any idea to make it?
Anyone can help me?

Bye

If you mean a list centrally maintained on a server that is distributed to several routers, here’s a quick script modified from one I run to centrally manage hotspot walled garden entries that change every day. It’ll create mangle rules in a chain that marks matching packets packets with “MAC_Blacklist”. You’ll have to set up jumps to that chain in the appropriate places, and drop filter rules in the appropriate places. Since it’s modified it’s untested, but it parses without error. I don’t have time until Monday to actually test it.

# set some parameters for fetching dynamic MAC blacklist entries
:local server [:resolve "server.that.holds.the.blacklist.tld"];
:local url "/list.txt";
:local fileName "MAC-blacklist.txt";
:local firewallChain "MAC-blacklist";

# try to fetch the file
/tool fetch mode=http address=$server src-path=$url dst-path=$fileName;

# get a hold on the file
:local filePointer [/file find name=$fileName];
# check if it exists
:if ($filePointer != "") do={
# set a variable to hold the total amount of entries added during this run
    :local added 0;
# it does exist. delete all previous dynamic entries first.
    :foreach entry in=[/ip firewall mangle find chain=$firewallChain] do={
        /ip firewall mangle remove $entry
    }
# read the configuration file into a buffer
    :local buffer [/file get $filePointer contents];
# record the total buffer size for later use in do loop cycling through the lines
    :local bufferSize [:len $buffer];
# create variable to hold buffer offset from start to current line end
    :local lineEnd 0;
# create variable that will hold the current line
    :local line "";
# create variable that keeps track of current position in buffer
    :local position 0;
# go through buffer
    :do {
# find next line end
        :set lineEnd [:find $buffer "\r\n" $position];
# fetch the line
        :set line [:pick $buffer $position $lineEnd];
# advance position skipping the newlines
        :set position ($lineEnd + 2);
# verify that line has a string length
        :if ([:len $line] > 0) do={
# all is well - insert MAC blacklist rule and increase counter
              /ip firewall mangle add chain=$firewallChain action=mark-packet new-packet-mark=MAC_Blacklist src-mac-address=$line
	      :set added ($added + 1);
        }
    } while=($lineEnd < $bufferSize);
# delete the configuration file 
    /file remove $filePointer;
# check how many entries were inserted - if any, log for informational purposes
    :if ($added > 0) do={
        :log info "Inserted $added new dynamic MAC blacklist entries."
    } else={
# if 0, check if the buffer read from the file was larger than 0. if so we should have had inserts
        :if ($bufferSize > 0) do={
            :log warning "Dynamic MAC blacklist entries configuration file had content, but none were inserted! Check process!"
        }
    }
} else={
# file could not be fetched. log that fact
    :log warning "Unable to fetch dynamic MAC blacklist configuration file!"
}

The file it downloads would be expected to contain one MAC address per line, with lines terminated by “\r\n”.

It’s also easy to parse lines further, so the script could be expanded to use a file that contains lines with, say, the MAC address, the mark that’ll be set and the mangle chain name so you could finetune what MAC address gets marked how, and where (via the mangle chain name being jumped to from certain interfaces/conditions etc.)

Somebody else may also be able to suggest improvements on performance of the mangle rules - I’m relatively new to RouterOS and mainly work with hotspots right now, and haven’t really looked at how to ideally sort firewall rules.

Hope that helps kickstart things,

Felix

Good solution, but I would a simpler solution for ACL MAC Blacklist… also integrable with a RADIUS server.

So - you are looking for something that prohibits logins for hotspot or ppp users coming from specific MAC addresses?

Yes, prohibits Hotspot/PPPoE login from specific MAC Addresses on many routers or (more brutal) prohibits AP association from specific MAC Addresses..

To limit AP association I guess you can use “/interface wireless access-list”. That cannot be co-managed by RADIUS as far as I know and I don’t think there is a solution not close at least in spirit to what I posted above (you would modify that script to add/delete wireless interface access-lists rather than firewall filter and mangle rules). But I have to admit I may be way off on that assessment.

If you’re going to key off the hotspot/PPP logins, I believe that the only way to make a central blacklist work is to implement it on the RADIUS server itself (or the sources it queries) and not to use local users at all. At that point you’re obviously well outside the scope of what RouterOS can do, but you could - for example - tie FreeRADIUS to a MySQL database backend and instead of the usual textbook queries instead fire from RADIUS a stored procedure that receives all the information the normal queries would use, but first queries a blacklist table and returns an empty row if the MAC address matches and only really does try to authenticate the request once that hurdle is cleared.

HTH,
Felix

Hi Felix,
tnx for your suggestions.

This is a good idea, can you help me to implement SQL pre-check queries on FreeRADIUS?

Not beyond some general ideas, sorry. I don’t have time to spend on the actual implementation. I hope you can find someone to assist you with more detail if you need it.

However, FreeRADIUS supports MySQL as a default backend and comes with all the queries for ‘normal’ authentication. All you’d have to do is use a resource such as http://www.mysqltutorial.org/mysql-stored-procedure-tutorial.aspx to figure out very basic stored procedures (must use MySQL > 5.0) and create one that accepts all the parameters the default FreeRADIUS queries require/support, once of which is the client MAC address. Then first check if the MAC address if in the blacklist - if so, return an empty set. If not, fire the copy/paste’d default query and return that set.

Felix

Ok I will try.

Tnx Felix.

Use this execellent piece of software:

http://www.dmasoftlab.com/cont/home

best regards,

kabelfrei

I already running FrreRADISU server.
I need a little help to individuate:

  • query source code to traduce in SQL commands (like ""if Calling-Station-ID/MAC is in blacklist_table then reject, else process SQL login/)
  • where insert query check

Bye

Hi to all.

No more ideas? :slight_smile:

for deny wireless ap connections to your ap use access-list (don’t forget uncheck the default authenticate in your wlan card interface).

for centralized mac blacklist you can use ip firewall mangle, doing a rule for each mac address in src-mac-address selector (put here the specific mac to block) and action: mark connection with a mark connection named i.e. “black-mac”.

Then you go and up a firewall filter rule and put a rule in the top of the list of filter rules as follows

connection: black-mac

action: drop

for deny wireless ap connections to your ap use access-list (don’t forget uncheck the default authenticate in your wlan card interface).

for centralized mac blacklist you can use ip firewall mangle, doing a rule for each mac address in src-mac-address selector (put here the specific mac to block) and action: mark connection with a mark connection named i.e. “black-mac”.

Then you go and up a firewall filter rule and put a rule in the top of the list of filter rules as follows

connection: black-mac

action: drop

I forgot that:

chain: forward

This is clair. :wink:

My problem is centralize management and not replicate/delete each rule on a large mumber of Mikrotik AP…
You suggestion work fine on a single AP… but if you have many (50…) APs?

My request: each AP MUST accept ALL MAC except MAC in black-list.

I need to centralize the access-list :frowning:

I dont know why you want accept all mac except certains mac blacked list. This is a big security hole. A better aproaching should be deny all macs and accept only the authorized macs. In this case you should use access-list (and even more: hide the ssid), but this is effective in only single AP. If you want centralize all in only one “validator” server or something like that then you got two options:

  1. If yours (50?) AP coexists all togheter in one big wlan then you can put all of them in a bridged mode, and use ip firewall mangle and filter as I describe before in the central validation server. This server can be a routed or a bridged mode. If you use that in a bridge mode you must put the “validator” server between the big wlan and the routers.

  2. If you got all of yours AP in different locations, in differents networks, then you must use a external radius authentication, or may be the user-manager package provided by mikrotik.

regards..

  1. If yours (50?) AP coexists all togheter in one big wlan then you can put all of them in a bridged mode, and use ip firewall mangle and filter as I describe before in the central validation server. This server can be a routed or a bridged mode. If you use that in a bridge mode you must put the “validator” server between the big wlan and the routers.

Yes, a big WLAN pure routing. Bridge mode? Poor idea for my scenario.
I want to deny any bad-MAC to associate APs, not after association.
Where block the bad-MAC? On the same associated AP, not after.
Using firewall rules need to write rules ON each AP, very hard to manage.

  1. If you got all of yours AP in different locations, in differents networks, then you must use a external radius authentication, or may be the user-manager package provided by mikrotik.

RADIUS already work fine on this WLAN, but…

A) I need to allow any NEW user (= unknow MAC) to connect WLAN, get Hotspot login and subscribe (and pay) Internet service on line!
B) I need to allow nomadics users
C) I want to deny any bad-MAC to associate AP, not after…


:wink:

For better understand your network policies..

how you determine if a mac address is a bad mac address? define bad-mac please in your terms.

Anyway.. In my opinion you can’t determine this BEFORE the mac get connection to your ap, because you dont know if a mac is bad o good before they get connected at least for the first time. Only you can to do this AFTER provide access to the customer and see if that customer is good or not, wathever that means. AND, if this is the scenario, then is a wrong way… because you need stay watching and seeing until a bad-mac appears… wathever means a “bad-mac”… this is really bad idea, and is not my idea of a automated and smart system.

IF you think in a “super automated system of collecting good users and at the same time enough smart to block bad users” the better way is deny all and then open access of well-knowns customers.

Then… may be you consider use of the walled garden. Put in walled garden the page (i.e. www.payhere.com) of your payment system. When a user pays the access then you must send him in a automated way one email with the user and pass for that customer. After that the customers can login in the hotspot welcome page and start use your services.

In that way you provide full access only to the well known users, and at the same time deny the rest of the world.

Other point: each AP must be protected with a good firewall filters, more if the system is big and open…

If you want a centralized “black access-list” for stop the bad users at the wlan level in several AP… there is not possible at the moment… the access list feature is only local and only one by each AP… and is a white list, not a black list… but may be this is a good idea for mikrotik team to do that, I guess… the “black-list function”… :bulb: :mrgreen:

If you want a centralized “black access-list” for stop the bad users at the wlan level in several AP… there is not possible at the moment… the access list feature is only local and only one by each AP… and is a white list, not a black list… but may be this is a good idea for mikrotik team to do that, I guess… the “black-list function”… > :bulb: > > :mrgreen:

Yes, this is my idea.
I want to block a MAC (know MAC) that I marked as “bad-MAC” on all APs, at radio level association.

:wink: