Slashdot Mirror
Using DHCP for Authentication?
gwhiteacre asks: "I have been asked to assist a small TelCo that has recently begun acting as an ISP for it's customers having DSL and Cable connections. They currently use the DHCP config file as their authentication database. They add/del/mod the mac address in the config file for each change, stop and start the dhcpd, and are rapidly discovering that this is not a scalable or sustainable approach. I have spent several days researching alternate forms of DSL/cable authentication and am not finding much. My current 'best thoughts' are to put a wrapper around DHCP to intercept the request, check a database, and then call dhcpd. Has anyone dealt with this or a similar issue, and can point me in a good or alternate direction."
I don't think you can "wrap" dhcpd. The protocol is a connectionless / stateless broadcasting system. I suppose you could listen for the packets, but by the time you launched dhcpd they would already be gone.
A quick google search reveals DHCP Turbo might do what you need. A Linux or Win32 based DHCP server running against a DB. But it seems to use it's own DB, not very flexible.
Of course, you could write your own DHCP server too. It's standardized. (See the RFC)
...this abstract for you.
It seems to address what you want, but is fairly recent! This means that solutions might not exist in the wild yet!!!
However, its very recentness also indicates that the issues it addresses (and you are trying to address) are still of very real significance in existing technologies.
So either all's well thanks to this solution, or you'll have to roll your own.
Dont restart, but reload the config.
And... don't listen to ppl who suggest
ppp. It has been originally designed for
non-permanent connections and lost of ppp
software have the assumption nobody
minds disconnecting/reconnecting/changing
the configuration of their pcs once in a
while, which is not always true.
Blueyonder are probably the biggest broadband supplier in the UK to homes. They use this method of MAC authentication.
They have a 'sef-care' page where you can register your own MAC address' yourself. Or you can phone up. Each person can have 10 MAC addresses.
Will
per mere, per terras
and its very scalable (5000 hosts)
our DNS has IN TXT fields that we put MAC addresses into, and our dhcpd.conf is cronned to regenerate every 20 minutes or so from our zone file stored in CVS.
no xxxxx.com dns address, no corporate IP address.
No, its not secure, and no, we don't use it for security. But between that, our physical security and the fact that everything sensitive is locked down pretty tight with passwords and VPN, it works out well.
And they don't have to stop and restart the dhcpd, they can kill -HUP it. and they don't have to edit manually, write a perl script to fetch it, or use perl to execute a "dig @any your.domain.com AXFR" and get the stuff you want to write a new dhcpd.conf.
perl is MADE for these things, man.
AND DON'T RELY ON DNS OR DHCP FOR AUTHENTICATION. LDAP would probably be better. or even NIS or windows domain authentication. anything besides DHCP & DNS. guh.
May I ask why you're not considering RADIUS? Authentication on a large scale is really what it's meant for. My ISP uses RADIUS to authenticate all PPP DSL customers. Just set the check items to only allow one connection. You won't have MAC authentication, but do you really need that? Just make sure everyone's got a secure username and password and switch to using RADIUS to authenticate them. It's faster, easier to maintain, and infinitely more scalable.
I work for a telco that was in the same situation in June of 2000. I elected to go with DHCP/bridge1483 because:
:\ You'd be suprised how much damage a little 'fat finger' can do when you're restarting your dhcp server as well as how many people really don't understand what a valid MAC address is.
/pointer
* it cost less - (PPPoE clients aren't cheap; yes, I know about raspppoe, but it doesn't run on some platforms last time I checked)
* has fewer things that can break (nic, driver, ?), hence lowering support costs
* doesn't require any software installation on any platform that I know of (almost any modern os has a DHCP client; yes, XP ships with a PPPoE client)
* gives users more bandwidth/has less layer 2 overhead (I did some research then (06/2002) and what I found seemed to indicate that the processing overhead (yeah, yeah, get a faster CPU), and layer 2 overhead of PPPoE were noticeable bottlenecks when compared to 1483. Anyone care to drum up some links (for or against!), I don't really have the time.
We setup a mysql db with all the fields we needed and I wrote a perl script that runs under cron to rebuild the dhcpd config every 5 minutes. I really need to set this up with timestamps so that it only rebuilds when things are changed, but I haven't gotten around to it yet (bad me!). I paid a friend (because I didn't have time) to write the php interface to the db and we give our tech support guys access to the db. NOTE: filter the mac/IP address fields for valid values or you will break your config.
With that said. I've enabled option-82 relaying on all of the devices between our 'DSL router' (RedBack SMS1800) and the dhcp server. I'm now getting the ATM circuit-id for each customer in the relayed dhcp discover packets. When I get the time, I'm going to switch authentication to circuit-id so that customers don't have to call in every time their MAC changes (new pc; new nic) and to streamline the install process (nobody has to call in and tell our techs their MAC. The account would just work once provisioned.
We're up to (insert random low 4 digit number) users and not having any problems with it. If you do go with redback (if you have a cisco/juniper, just get an atm blade for it...), make sure you enable secured arp and get the SRAM card to cache the arp tables for maintenance reboots. Secured-arp will stop people from using a MAC that the dhcp server hasn't sent a 'dhcp ack' to. Secured-arp, coupled with 'deny unknown clients' in your dhcpd.conf should resolve issues like that. I'm sure cisco/juniper routers support secured-arp, but I haven't had the need to set it up on mine, so I don't know.
Just my 2c. Good Luck!
[%- PROCESS life -%]
That in addition to not being scalable or sustainable, this scheme is not secure, either.
/pointer
Scalable/Sustainable:
Please tell that to the big cable providers. Post some messages on the ISC-DHCPD list. Let some of the users with larger networks tell you how scalable it is.
Secure:
We're using secured arp. You can't steal IPs when your provider is using secured arp on the router directly connected to the DSLAMs. When the router 'sees' the DHCP ACK from the DHCP server, it adds a static arp entry for your MAC/IP to _your_ ATM circuit. DHCP requests are sent directly to the router (dhcp/relay) which converts the request to unicast. In our environment (DSL, not cable) there is no physical way for one customer to 'get in the middle' of any one elses connection to cause problems like this.
[%- PROCESS life -%]
You could check out Netreg/Netmon from CMU which interfaces the ISC DHCP and BIND servers to a SQL (mysql, postgresql, etc.) server.
http://www.net.cmu.edu/netreg/
--JLockard - "Some mornings, it's just not worth chewing through the leather straps." - Emo Phillips
You can use authpf to allow access through your firewall only to logged in users. With this, each user has to first authenticate and then s/he can access the network.
One caveat with this method is that you need a SSH client on your user's computer. For UNIX-Like you can use plain SSH (users are normally familiar with it), but for Windblows, you should take something like putty and change it so it would look more like a login interface.
Utinam logica falsa tuam philosophiam totam suffodiant!
"Scalable/Sustainable:
Please tell that to the big cable providers. Post some messages on the ISC-DHCPD list. Let some of the users with larger networks tell you how scalable it is."
I'm aware that DHCP is used in many large organizations; I personally use ISC-DHCP in several small to mid sized networks. But it sure seems like the story's poster is trying to fit a square peg in to a round hole. DHCP is not designed as an authentication protocol, and probably should not be used as such. From what I read, it seemed like the poster was having scalability problems using DHCP as an authentication protocol, which is to say that he was having problems getting it to do something it wasn't designed to.
"Secure:
We're using secured arp. You can't steal IPs when your provider is using secured arp on the router directly connected to the DSLAMs. When the router 'sees' the DHCP ACK from the DHCP server, it adds a static arp entry for your MAC/IP to _your_ ATM circuit."
It seems like changing your MAC before you send out the DHCP request would result in a denial-of-service, stealing away the IP of the person who owns the MAC you just set, since the static ARP entry gets added after the DHCP server ACKs the REQ. Admittedly, you may have to do this the very first time you connect - I'm assuming that the lifetime of the ARP entry lasts at least until the next DHCP REQ, preventing you from spoofing your MAC once you've gotten an IP from the DHCP server.
The problem is aggravated if you sell ethernet boards with your service. It's pretty safe to assume that the same boards are sold to other customers, so you'd have an excellent chance of hitting upon another valid MAC by just subtracting one from the last octet of yours.
Also, note that the poster didn't detail any specific setup like you did, leaving it pretty open for interpretation.