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."
Would it be possible to let dhcp serve out ip addresses, but then have a different program such as arpwatch to watch for new mac addresses, check a database, then disconnect that user. They might have access for a few seconds, but thats all. Any rouge mac addresses deteced can then be reported.
http://www.22balmoralroad.net/ http://www.tinynetworks.co.uk/
See the subject.
...). It works over almost anything (ethernet, atm, ...).
It can assign ip adress, includes secure scheme for authentifications, well implemented, easily integrated with radius for more advanced stuff (DB, accounting,
#include "coucou.h"
Well, I have to infer a lot of what you want, but why not just hack on the dhcpd source to make it more scalable? Allow it to automatically process updates of the config file, using some locking method to keep things sane (or check a database that you control, for updates)
I'm assuming the main performance issue to address is the shutdown/update/startup cycle, which you could eliminate. Other performance issues could also be addressed if need be; it is open source after all.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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)
That in addition to not being scalable or sustainable, this scheme is not secure, either.
MAC addresses can be changed via software ('ifconfig ethX hw ether aa:bb:cc:dd:ee:ff:gg'), and this stuff is sent in the clear, opening you up to (at least) denial-of-service and man-in-the-middle attacks.
Sorry I don't have a suggestion for what you should use.
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.
As others have mentioned, DHCP has no authentication other than MAC, and MAC is not reliable.
But take a look at the ISC web site, and there has been a lot of work to integrate DHCP with DDNS. In perticular, there is some bleeding-edge work to crytographically secure the DDNS authentication with either symmetric or asymmetric keys. Neither is ready to deploy, though the symmetric key work requires less patching. In your situation, it may be possible for DHCP to only serve DDNS-approved addresses, all others would fail.
Though not ready it may help set a direction for the future.
But even this wouldn't stop a rogue from sniffing your network for others' DHCP packets, and using that information to guess a static IP, and run that way. As much as people dislike PPPoE-type solutions, some form of encapsulation like that or DOCSIS is the only safe way. Another option might be to have everyone run VPN software. Then route the other side of the VPN, and none of the untrusted network. Just another method of encapsulation.
The living have better things to do than to continue hating the dead.
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 -%]