Blacklisting MAC addresses, but they still take a DHCP lease

Question

At my workplace, we have a Public Wifi network, as well as our Private Wifi network. The Private side has access to see other computers, the printers, servers, and access to the Internet. On the Public side, the users need to authenticate with a captive portal with a username/password combo from our server (for our staff's personal devices only).

The key has been leaked long before I came to this job, and I have most things cleaned up. I have scripts (written by other team members, not myself!) that go through the DHCP leases on Debian Wheezy, and spit out the manufacturer, the DNS name, IP Address, and the MAC address of all the devices the DHCP server interacts with. With these scripts, I can create a blacklist of MAC addresses and iptables blocks them for me. I update /etc/blacklist.txt, and when iptables starts, it executes iptables -A INPUT $if -m mac --mac-source $i -j DROP (with $i being read from the file).

This will prevent their device from connecting to our network resources, and to the Internet. Unfortunately, it does not take effect until after the device has gotten an IP address from isc-dhcp-server. So, my issue is, how can I prevent them from even getting an IP address assigned to them? Yes, I know they could just assign themselves a static IP address and bypass the DHCP server, but I still want iptables to block them, based on their (hopefully non-changing) MAC address. Yes, I know I could increase the range on my DHCP server, but I want management to realize the struggle with managing the privately-owned devices taking up our work resources by connecting and bypassing our captive portal.

One solution (well, partial) that someone thought up was to create a blackhole class in my /etc/dhcp/dhcpd.conf file, and fill it with the MAC addresses of the devices I don't want connecting. This would work, but requires updating the MAC addresses in multiple places, which I don't want. I want to be able to update the MACs in one file, and then possibly run a script that will add the changes to my DHCP file, and my iptables rules.

Answer 1

Use ebtables instead of iptables to block MAC addresses at layer 2:

ebtables -A INPUT -s 00:11:22:33:44:55 -j DROP

Answer 2

Although I think using ebtables may be the answer, it's another layer that I did not want to add to my configuration. One of the other techs helped me make a script to parse through the blacklist of IP Addresses, and add them to a new pool, which gives out no IP address whatsover. It takes the regular blacklist (one MAC address per line) that I also spit into iptables, and just creates the new pool.

In my /etc/dhcp/dhcpd.conf file, I create a new class near the top:

class "blacklist" {
    match hardware;
}

In my pools with the "private side of the LAN", I add this:

deny members of "blacklist";

... and at the very end, I added:

include "/etc/dhcp/blacklist.conf";

Then, I create a Python script as per below:

#!/usr/bin/perl

my $if;
my @macs;
my $line = 0;

if ($ARGV[0]) {
    $if = "-i $ARGV[0]";
}

while (<stdin>) {
    $line++;

    next if /^$/;
    next if /^\s*#/;

    chomp;

    if (/^([a-f0-9]{2}((:|-)[a-f0-9]{2}){5})$/) {
        push(@macs, $_);
    }
    else {
        die("syntax error on line $line\n");
    }
}


open(OUT, ">/etc/dhcp/blacklist.conf");
foreach my $i (@macs) {
    $i =~ tr/-/:/;
    print OUT "subclass \"blacklist\" 1:$i;\n";
}
close(OUT);

I save this, then I add the Execute bit with chmod +x /usr/local/sbin/dhcpd-macblock.py, and set a cron job that feeds the blacklist into the script every hour:

cat /etc/blacklist.txt | dhcpd-macblock.py

Every hour, it goes through, creating a new file with all the MAC addresses blocked that I don't want, and they don't even get a DHCP reservation, and my spots are slowly freeing up.

Answer 3

If you have access to that setting, and if the hardware permits it, a simpler sollution could be to configure your access point(s) to reject the MAC addresses you want to filter, instead of filtering them "later" with iptables. This would also solve the problem of people assigning a static IP to their device, as they could simply not associate with the network if they are filtered at AP-level. Of course, this can't solve the problem of "non-static" MAC addresses...

Answer 4

As far as I know it is not possible to do except to use something like etables as was suggested, with the additional bookkeeping.

I've seen this problem before and the solution I found in use was pretty much the same as what you're already using. If you make the script run every few minutes then the time the unauthorized device can be on the network is minimal, that could be an acceptable trade-off.

You should also look into linking wireless authentication with an LDAP server, assuming you already use something like that it should be easy. Otherwise incorporate LDAP or some other centralised authentication system as soon as possible (local user accounts are a bad idea in most cases). Then either create generic guest account or a guest account on a case by case basis. That way even though users may have the wireless key they still can not get on the wireless until they authenticate. Normally that would be done via a webpage the wireless router will redirect traffic to. Only after authentication a route will be created to allow traffic.