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)
...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.
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.
Or any other firewall that can filter on mac addresses.
Just configure dhcpd to hand out dynamic ip addresses using the range keyword.
Then either put the firewall on the same box as the dhcpd server, allowing only known mac addresses access to the dhcpd or put the firewall on the gateway between your customers and the internet.
If you pick the second option, everyone can get an dhcp lease, but only registered customers can pass. You could even set up some rules that redirect all access to port 80 for unauthorized users to a special webserver telling them they need to register or whatever.
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.
see if you can use 802.1X and EAP
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.
Yes, some early-but-proprietary infrastructure exists.
Are you still interested ?
[Pruneau
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.
What you really want is probably PPPoE. You can do PAP/CHAP authentication, and the pppoe server will pass down a dynamic IP and configuration info (DNS servers, gateway, etc) to the client. You can do static IPs over it as well. In fact, my ISP has a non-routable 10 network in which they shove internet-addressible IPs over to your client (if you purchase a static IP).
BTW, PPPoE has a number of disadvantages, like screwing with the ethernet MTU and, thus, breaking client machines behind your gateway/firewall (particularly VPNs) unless you do some trickery to your network and/or pppoe configs.
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 -%]
What kind of authentication you can implement depends on what information about the user you have. It seems you have MAC addresses of your customers. So you can filter via MAC. Since DHCP can associate MAC and IP address, you can also filter IPs. Is there a way the users can update their MAC addresses if it changes? In that case you would have some kind of username/password based accounts. Probably stored in a RADIUS database. If the above is true, then you might want to visit http://www.stockholmopen.net (I hope I got the site right). It is meant for wireless networks, but actually is agnostic of what kind of network is in use. Good for shared media networks, such as cable. Authenticates users using username and password (over a secure HTTPS link), and does access control through IP and MAC. You can throw out bits you don't want. The premise is that the DHCP server will dole out addresses to the clients, but the router will not forward any packets until the user is authenticated. Runs on Linux, but can be configured for other Unices with ipfilter/ipfw like firewall control. -- Parijat
Does their DHCP do auth based on the MAC address of the ethernet card or that of the DSL bridge?
If it's like my Cable Provider (ComCast), then it's the card. When I added my Router/Firewall, I had to spoof the MAC address. F**king stupid, if you ask me.
Now I have to keep that number handy FOREVER. However, I just gave the machine with the original card to my brother, who may get ComCast High-Speed and I'm kind of wondering what happens to him.
When I talked to Level 1 tech and told them that I changed the card, they either acted like they didn't know what I was talking about or really were clueless. I suspected the latter and gave up.
I'm sorry. The answer is probably 'card'.
The opposite of progress is congress
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
There is no known fool proof way to authenticate a client using DHCP. If you want a readily deployable technology, use PPPoE or 802.1x capable switches.
Even setting up reservations for each registered clients does not work because I can listen and spoof any client if I have access to the network.
If you are just supporting some http/nntp/https and some known protocols, use an authenticated proxy.
Just drop the idea about authenticating DHCP. It will not lead you to anywhere.
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!
You could whip out a system real quick that uses DHCP and assigns the default gateway to a webpage, so that no matter where they go they get the same page. That page would be an ssl encrypted login page that assigns them the real ip and gateway, set to expire the second it goes offline or after a specified amount of time. This approach is totally scalable, totally cross-platform (got Be? ;-) as anything that can use dhcp can use your network...and can be deployed across any tier, dsl, dial-up (if you wanted), wifi(802.11). Build 1 RADIUS server for all services, use MySQL as the user DB. Easy as pie.
/* oops I accidentally made a comment, sorry */
use rarp and tftp
*ducks*
What ever happened to PHYSICAL SECURITY? As in not letting non paying customers physically plug into your network? In the case of DSL, it's simple: they can't talk to your network untill the telelco provisions their PVC and connects it to you, right? In the case of cable modems, isn't there some similar way to not allow the modem to initialize and forward frames to the cable segment based on the modem's serial number or something? I really need to find a copy of DOCSIS and read it...
man omapi. And then work the db. No prob =).
"What about all those people who don't have what I got, are they victims of my leisure?" - D. Boon
DHCP is really simple. There are a few
implementations that you could easily
modify to do what you want.
The idea that you should have to *find*
a tool for very specific needs, or even
that you should modify your needs to fit
available tools, is dogmatic baggage of
the proprietary software world.
Really: creating your own server is the
only way to go and is quite easy.