MAC Filter from dhcpd.conf

[bushka]

Looking for any ideas on how to restrict access through a router by a list of MAC addresses from a dhcpd.conf, we have registration on the LAN network by an automatic registration server which assigns as IP address when the user enters a valid username and password. Thing is we are now doing this on a wireless network, squatters on a wired network for us is not so bad but squatters on a wireless network could be big trouble.

So we want any computer on the wireless network to have provided a valid username and password to gain an entry into the dhcpd.conf and therefore also gain access through the router.

Router is running IPCOP 1.4.10, Registration box is running Fedora Core 4 with Apache 1.3, DHCPD and BIND to make registration work....

Anyone?

[bwkaz]

Umm... how are the users supposed to log in without an IP address? Is this some kind of security on the wireless itself? It doesn't sound like it...

Additionally, what's to stop an attacker from statically configuring an address into their NIC if you don't let them get a DHCP lease?

Maybe it would help to tell you what we've done for visitors at work. We have our normal wireless APs set up in extremely-secure mode (WPA2-AES, with a RADIUS server doing EAP-TLS). But we've added more SSIDs to many of these APs, and mapped each of those SSIDs to a separate VLAN (so that visitors, authorized WEP boxes, etc., are all forced through a firewall before they can talk to our main network).

The VLAN for guests gets routed up to our central VLAN routing box (it's basically running Debian, with a lot of modifications done to support the VLAN interfaces and all the custom firewalling/routing rules -- we actually have 3 VLANs for our traffic, plus the one for visitors). That box runs a DHCP server, which hands addresses out to anyone on the guest VLAN. It's also set up as the default gateway and DNS server for that subnet (using options on the DHCP server).

That box also runs a heavily-modified NoCatAuth installation, which is a portal capture and logon package. There are firewall rules in place to do the portal capture (basically, for un-authenticated MAC addresses, the firewall blocks everything except HTTP, which it DNATs to a NoCatAuth provided daemon running on the box on port 8088; the daemon always sends back an HTTP redirect to the box itself on port 443, where the NoCatAuth CGI scripts take over). So the user sees an HTTPS login page, no matter what their homepage is. When the user types in a password (we've forced one specific username), the NoCatAuth CGI script verifies the credentials against our RADIUS server, and if successful, creates a dynamic firewall rule to allow any traffic out from that MAC address. (This is what determines whether the MAC address is "authenticated" or not. By default NoCatAuth has its own database, but that wasn't working well, so I junked it.)

So basically, we don't restrict DHCP; we restrict normal IP traffic until the HTTPS login page is successfully filled out.

[bushka]

What I meant was that the computer would connect to the open network, get an IP, be forced through a registration page, all this happens at the moment, what I now want is that only the people who register to be allowed through the firewall.

I did setup RADIUS with EAP-TLS and dynamic WEP but this was via a M$ IAS server and it seems that computer need to be part of the domain to get the certificate and that the computer supplies the credentials from the current logged on user. We expect about 1000+ visitors a year and need a domain indepentant solution.

What I would like is a system like your NoCatAuth... That creates a dynamic firewall rule from the registrations...

[bwkaz]

Well, the NoCat project page is here:

http://nocat.net/

and the NoCatAuth page is here:

http://nocat.net/downloads/NoCatAuth/

but as I said, we had to modify it quite a bit. Part of the problem is that NoCatAuth hasn't been updated in quite a long time (the latest nightly release was two years ago), and part of the issue was that we wanted to hardcode the username. If you know Perl, though, it should be easy enough to figure out.

(We considered using NoCatSplash, which is a lot more current, but I don't feel comfortable with CGI pages written in C. IMO there's too much to worry about with buffer overflows, etc., in that environment. Its "authenticated access" mode is still in beta, as well, but at least it's still being worked on.)