Is it possible to use MAC tables with IPFW?

ORTO-DOX

ORTO-DOX

Good day!

At work I use MAC filtering, and since I have 100+ PCs, I just use a scheme like this:
  1. Every new PC adds to an internal database (PC description, MAC address of it interfaces)
  2. Also every PC is tagged with existing groups (departments in the office)
  3. When there are changes in that database, a script dynamically creates ipfw rules for every MAC-address
That task is automated, but I think it is not perfect by design because it has too much identical ipfw rules like:
Code: 
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:55 in recv ${LAN}
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:66 in recv ${LAN}
ipfw add 5 deny all from any to any MAC any 00:11:22:33:44:77 in recv ${LAN}
I think, it will be good to have ability organize MAC filtering in FreeBSD similar in such way:
Code: 
ipfw mac-table 1 flush
ipfw mac-table 1 add 001122334455
ipfw mac-table 1 add aabbcc #which means all mac-address aa:bb:cc:*:*:*
ipfw add 1 deny all from ${LAN} to mac-table(1)
Isn't this is good idea?
 
You do realize it's fairly trivial to change one's MAC address? Why do you want to go to all this administrative trouble?
 
In addition to @SirDice I think I also spot another possible issue with your firewall strategy; from the small bit of information you shared here it would seem that you use an "allow all, deny xxx" strategy which can come with several caveats of its own.

Why not go for a "block all, allow xxx" based strategy? It would most likely reduce quite a bit of overhead in your firewall rules (please note that these are only assumptions on my part, based on what you shared so far).

Finally I have to agree with @SirDice on this one, it seems you're adding a lot of overhead which could most likely be avoided without any negative consequences.

Still, I do agree that its likely that more people would know how to change their IP address compared to the amounts who know how to change their MAC.
 
Last edited by a moderator:
SirDice said:
You do realize it's fairly trivial to change ones MAC address? Why do you want to go to all this administrative trouble?
Click to expand...

Of course I realize that, and change of MAC address is not more difficult than a change of IP address, but when users are unprivileged - changing of MAC or IP addresses is not so easy. So I think MAC tables are not less needed than IP tables.

ShelLuser said:
In addition to SirDice I think I also spot another possible issue with your firewall strategy]

No, the examples in my post are just examples, not copy/paste from real ipfw rules. In fact I'm use MAC filtering:
  1. To deny access to network resources for unknown machines (I have no L2-switches)
  2. To restrict access to various resources to known machines
P.S. I'm repeating my opinion that a change of IP address is not more difficult than a changed or spoofed MAC address. But if you use DHCP in the network (like in my situation and many others), to use IP-related rules you need to write in the DHCP server the IP for that MAC, which is similar to my task.
P.P.S. Sorry for my English :)
Click to expand...
 
I may be way off, but since you stated that the MACs are added to an internal database and you have a script that adds them to a ipfw table, why don't you just put some check code into either (or both) of the scripts? Something like:

Code: 
cat mac_list | sort | uniq > new_mac_list

Flush the table and inject the new_mac_list.
 
pboehmer said:
I may be way off, but since you stated that the MACs are added to an internal database and you have a script that adds them to a ipfw table, why don't you just put some check code into either (or both) of the scripts? Something like:

Code: 
cat mac_list | sort | uniq > new_mac_list

Flush the table and inject the new_mac_list.
Click to expand...
Sorry @pboehmer, but I don't understand your proposition :)

For me all works with my own current scripts, but I think it will be useful to implement feature which are provided by project l2filter proposed few posts before. From examples of l2filter, it exactly what I mean in first post plus some more features.

I had an opportunity to spend some extra time improving layer2 filtering.
I've extended lookup tables in ipfw to support several layer2 addresses for a
single layer3 address/mask. It means that it's possible to assign mac addresses
to network (in case ip's are dynamically distributed by dhcp or whatever).
Besides, wildcard ip address 'any' is supported, and entries with wildcard
ip can be used for layer2 filtering.
Code: 
ipfw table 1 add 192.168.1.0/24 ether 00:11:11:11:11:11
ipfw table 1 add 192.168.1.0/24 ether 00:22:22:22:22:22
ipfw table 1 add 192.168.1.0/24 ether 00:33:33:33:33:33

# equivalent to: ipfw table 2 add any ether ...
ipfw table 2 add ether 00:11:11:11:11:11
ipfw table 2 add ether 00:22:22:22:22:22
ipfw table 2 add ether 00:33:33:33:33:33
ipfw table 2 add ether ff:ff:ff:ff:ff:ff

ipfw add 1000 allow ip from 'table(2)' to 'table(2)' layer2

# layer3
ipfw add 2000 allow ip from 'table(1)' to 'table(1)'
Click to expand...

Unfortunately at this moment as author of project said his patches not applied to -CURRENT and -STABLE (since ipfw3 was imported in FreeBSD).

I'm writing a letter to the author, but in his blog he said that the l2filter project is moved to Github for community supports it.

So maybe somebody will be interested in returning the project to life?
https://github.com/glk/l2filter/
 
Last edited by a moderator:
rolfheinrich said:
Some years ago, Gleb Kurtsou extended lookup tables in ipfw to support several layer2 addresses for a single layer3 address/mask. See here. This resulted from Project #16 of the FreeBSD Summer Of Code 2008. It seems, that this would provide pretty much what you are looking for. Patches are provided at GitHub. However, I didn't come to check this out, though. So, I cannot tell, whether these patches do still work with the latest ipfw.
Click to expand...

Is it possible to use these patches for pf?
 
You must log in or register to reply here.
Back
Top