On Wednesday 11 August 2004 01:07, Andreas Stieger wrote:

Hello,

Am Mittwoch, 11. August 2004 00:40 schrieb nhaas:

...

web page that grabs the MAC address

Via proxy or something like this? Then every time afterwards it lets them go out because it knows the MAC address.

If anything like an application level gateway (proxy) or network level gateway (router,"gateway") is inbetween, the MAC will be lost. Also, it would be hard for a php script to grap the MAC address, as that whould be irrelevant for a process at the application level which is usually interfacing with a connected TCP socket.

Why not let the students enter their MAC addresses themselves? Advise them to look for it on their NIC, via "ipconfig /all", "winipcfg" or "ifconfig" (Unix-like).

It is possible to let the DHCP server hand out ip# based on MAC addresses. Cheers, Leen

nhaas wrote regarding 'RE: [SLE] MAC address authentication' on Wed, Aug 11 at 13:04:

Thank you for the reply we really don't have anything in place yet. It is just a wish to get this in place by the 30th before the students get back to school. This would save a lot of time by not having the students use a signup form...

-----Original Message----- From: Danny Sauer [mailto:suse-linux-e.suselists@danny.teleologic.net]

nhaas wrote regarding '[SLE] MAC address authentication' on Tue, Aug 10 at 17:48:

...

Hi All;

I am trying to make an authentication server. We are a campus that requires a MAC address in a database to use the web. [...] Is the proxy already in place, or is that something else that "will be" set up as part of this? If it's not already in place, you could do some more access control using iptables rules built from a database, and use [...]

If there's nothing in place, then here's how I'd do it. Set up a DHCP server. Have it set the default route for all machines to be a linux box with iptables set up, and run a web server capable of PHP support on that machine. We'll call that machine 10.1.1.1 and the network 10.1.1.0/24 The router machine directs all traffic from the DHCP-assigned block to a new chain - oncampus - whose last (default) rule is directing to another chain - unregistered. iptables -n oncampus iptables -n unregistered iptables -s 10.1.1.0/24 -d !10.1.1.0/24 -J oncampus iptables -A oncampus -J unregistered iptables -A unregistered -p tcp --dport 80 -J DNAT 10.1.1.1:8080 iptables -A unregistered -p udp --dport 53 -J ACCEPT iptables -A unregistered -p tcp --dport 53 -J ACCEPT iptables -A unregistered -J REJECT So, now any outgoing DNS requests get allowed through, and any http web requests go to the web server running on port 8080. Everything else gets rejected (which responds immediately, in contrast to DROP which causes things to time out). You could set up a DNS server with a wildcard entry resolving all requests to the registration web server, too, but this is easier, IMHO. Now, you set up a web server, let's say an out of the box Apache setup on SuSE. Set it up to listen on port 8080 and to redirect all requests to your registration page (let's call that page register.php). In /etc/apache2/conf.d/registration.conf: RewriteEngine On RewriteRule .* /register.php [NS,L] Listen 8080 Alright, now anyone who connects gets redirected to register.php when they go to any web page "on the internet". So, in register.php, just grab the connecting IP and stick that in a database with their room number, etc. If you must have a MAC address, $ARP = system('/sbin/arp $REMOTE_IP'); $MAC = ereg_match('/\s([\W:]+)\s/', $ARP); $MAC = $MAC[1]; or something like that - the exact php syntax eludes me for now, and I'm hungry (lunch supercedes looking up the order of args in PHP functions). Since it's just as easy to forge a MAC as is to forge an IP, though, I'd just go with IP restrictions since they're easier to deal with anyway. Anyway, now you're generating a database with all of the registered IPs, and possiby a date of registration (so they can be restricted by time, etc). All that's left is to write another shell script that, say, gets run from cron every 5-10 minutes and either totally regenerates the iptables ruleset or adds any new entries. I like the regenerate route - it's easier. :) #!/bin/sh # first, flush the chain iptables -F oncampus # then, create the default rule iptables -A oncampus -J unregistered # finally, insert the allowed IPs for IP in `mysql -e 'SELECT ip FROM registered_student_ips'`; do iptables -I oncampus -s $IP -j ACCEPT done Run that from cron periodically, or run it whenever someone registers a new machine, etc. Then, machines who are registered get to go on to the internet and machines who are not slip past onto the "unregistered" chain where they are redirected to the registration script. It's entirely possible that I messed up somewhere with syntax, etc, but this should get you a good idea of how it could be done. Storing the IPs in a database rather than just creating the iptables rules is a good idea, since the iptables rules can be regenerated after a power loss. You could certainly use another machine for the registration page, as long as both the web server and router can access the DB. This, BTW, is a nice scheme for a coffee shop wireless access point that gives customers a limited amount of time to connect, etc. Stick a payment method on that registration page and you're all set. ;) --Danny