Using DHCP for Authentication? 69
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."
arp requests (Score:4, Interesting)
Re:arp requests (Score:2)
I see ettercaps storming the network with fake macs (tens of thousands per second) and causing MASSIVE loss of service
PPP (Score:5, Insightful)
It can assign ip adress, includes secure scheme for authentifications, well implemented, easily integrated with radius for more advanced stuff (DB, accounting,
Re:PPP (Score:2)
Re:PPP (Score:3, Interesting)
BTW, what was used before PPPoE ?
Re:PPP (Score:2)
Re:PPP (Score:2)
I always thought DSL was over some sort of ATM
Re:PPP (Score:2)
Re:PPP (Score:2)
Re:PPP (Score:2)
ahem.
Re:PPP (Score:2)
There were a very variations, Reno and Vagas (sp?), and a few otheres, but from memory something that follows the 1982 RFC will still work.
ATM is much more modern, has many many features that IP doesn't, but hasn't taken off. Maybe if we could cut the whole world off IP to ATM overnight ATM might take off, but until then I can't see ATM being much. You throw away most of the advantages of ATM when you use it to tunnel IP, but Ethernet/IP is so much easier to make LANs out of. I don't think I've ever seen an ATM LAN, its always used in the backbone it inter site links.
Re:PPP (Score:1)
Re:PPP (Score:2)
-- iCEBaLM
Just add the features you need to dhcpd (Score:4, Insightful)
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.
Re:Just add the features you need to dhcpd (Score:3, Insightful)
Umm, because he's in the ISP business, not the software development business?
Let me give you an example: Boeing probably have some fairly strong ideas about what sort of fuel you should put in their aircraft, but you won't see them operating oilrigs anytime soon.
No, they'll get Shell to do that for them, just as the original poster should get RADIUS/LDAP to do it for him.
Re:Just add the features you need to dhcpd (Score:1)
Re:Just add the features you need to dhcpd (Score:2)
Wrapping (Score:5, Informative)
A quick google search reveals DHCP Turbo [weird-solutions.com] 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 [weird-solutions.com])
Re:Wrapping (Score:4, Informative)
That would be the most flexible solution long-term, especially if they want to do all sorts of custom lookups during a DHCP request. It's quite a trivial protocol, we implemented a custom DHCP server a few years back in a couple of days. Just look up the RFCs for BOOTP and DHCP at www.ietf.org, making sure to use the latest ones since there were multiple revisions.
Re:Wrapping (Score:2, Informative)
I think this guys best bet (if he decides to go with bridge1483/DHCP) is secured arp. See my main post for more info...
I found... (Score:3, Informative)
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.
kill -HUP instead of ..blah-blah/dhcpd restart (Score:2, Informative)
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.
Don't forget... (Score:4, Insightful)
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.
Re:Don't forget... (Score:1, Insightful)
I'm not too sure about that. Does their DHCP do auth based on the MAC address of the ethernet card or that of the DSL bridge?
Probably the card (Score:1)
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'.
Re:Probably the card (Score:1)
Re:Probably the card (Score:2)
On a lark I decided to try the MAC cloning option and it worked.
I've tested it at least twice since then. Same results.
May give it another try again, but I already know what's going to happen.
In fact, when they did their 'clampdown' on MAC addresses I was toast until I realized that the original MAC address I gave them had a wrong digit ('8' instead of a '3' or 'E').
Anyway, when I gave them the corrected number it fired up in a couple of hours.
I think they vary it by location, but what a pain.
Re:Probably the card (Score:2)
Re:neither-uses pap (Score:2)
Re:Don't forget... (Score:3, Informative)
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.
Re:Don't forget... (Score:3, Informative)
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.
Re:Don't forget... (Score:3, Insightful)
I would have to agree. DHCP was not designed as an authentication protocol, however, for the purpose in question (giving authorized users access to the network), it works acceptably.
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.
You make a vaild point. Keep in mind that you would have to guess the other customer's MAC because sniffing would do no good.
This is one of the reasons that moving to circuit-id based auth. The customer would never have to worry about their MAC at all.
Were a malicious user to be able to guess MACs, our tech support guys would be pretty quick to notice a pattern in the complaints (I've setup dhcpd to log circuit-id with each request) and we would deactivate the customers circuit. The other option would be to setup a daemon to watch the log for x number of requests from unknown clients from a specific circuit id.
Also, note that the poster didn't detail any specific setup like you did, leaving it pretty open for interpretation.
Again, you're correct. Your comments about scalaability were made with and educated guess about this persons network config as were mine. My point was that DHCP _can_ be effectively, efficiently and securely be used in this environment.
iiptables MAC extention ? (Score:3, Interesting)
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.co.uk use this method (Score:2, Informative)
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
Re:Blueyonder.co.uk use this method (Score:1)
I don't think they've found the most suitable approach.
My company does this (Score:4, Informative)
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.
802.11X and EAP (Score:1)
Re:802.11X and EAP (Score:1)
Look at DDNS, too (Score:4, Interesting)
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.
Re:Look at DDNS, too (Score:1)
Authenticated DHCP is also going no where since it is not considered to be secure enough.
Re:Look at DDNS, too (Score:1)
On my DHCP server at home, I mostly give out fixed IPs based on MAC, but I also have a small dynamic IP range, in case a visitor brings a laptop. I could just as easily deconfigure the dynamic IP range, and have MAC-based security. I agree that MAC-based security isn't worth spit, but it says that I can sort of piggyback a security policy on top of DHCP.
To do what I suggest, it would be necessary to patch DHCP so that it would look for some sort of return code from invoking DDNS. Then if DDNS didn't like the client, DHCP would refuse to grant an IP. I don't believe this is the current behavior, but I suspect it could be patched.
In any case, I also stated that even this wouldn't stop someone from sniffing DHCP packets and guessing a decent static IP. Further steps are necessary.
Yes, but... (Score:1)
Yes, some early-but-proprietary infrastructure exists.
Are you still interested ?
RADIUS? (Score:3, Informative)
Re:RADIUS? (Score:3, Insightful)
Exactly; everybody uses RADIUS. Why the hell would you use DHCP for auth?
I recommend pppoe, sadly (Score:2)
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.
Re:I recommend pppoe, sadly (Score:1)
screw with the MTU most modern OS have a dynamic MTU.If you are silly enough to block this control channel with your firewall you break the MTU discovery protocol. Some firewally realise that this is a legit control channel and will fix the from.
web interface - mysql - cron - dhcpd.conf (Score:5, Informative)
* 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!
Re:web interface - mysql - cron - dhcpd.conf (Score:1)
Re:web interface - mysql - cron - dhcpd.conf (Score:2)
Good question. I like to use software in as native of a form as possible as a rule. By 'native form' I mean being able to 'tar zxvf x;./configure [options];make;make install' because when it comes time for a security update, I don't want to have to be the one porting a patch to a new version of a package. I'm a sys admin, not a C/C++ programmer. I can write code, but it's not what I do best. When this feature becomes mainstream, I will definitely look at it, but like the patch that I mentioned (for spawning an external program) in another thread, I won't be implementing it in production until it comes with stock DHCPD.
Shouldn't your php front end do the error checking and tell the guy reading from the script(level 1 tech support) that the number he just entered it not a valid MAC address.
It does now.
On the X minute waiting period. It's 5 minutes. The tech can configure their MUA while he's waiting.
StockholmOpen.net (Score:1)
Netreg/Netmon... From CMU (Score:2, Informative)
http://www.net.cmu.edu/netreg/ [cmu.edu]
DHCP authentication does not work (Score:1)
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.
Re:DHCP authentication does not work (Score:2, Insightful)
authpf + putty (Score:3, Informative)
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 [greenend.org.uk] and change it so it would look more like a login interface.
Re:authpf + putty (Score:1)
Could you level up your ideas a little bit and elaborate a little more on your answer, for instance, explaining WHY do you think this is stupid?
Remember, this is a forum where we are supposed to discuss new ideas, not bash people around. So, please, if you don't have anything good to say, think again before posting!
use the DHCP (Score:1)
Re:use the DHCP (Score:1)
Re:use the DHCP (Score:1)
Re:use the DHCP (Score:1)
Re:use the DHCP (Score:1)
My point is that I don't think it's any different than a PPP type connection, you get prompted for a password and you either type it in, or hit enter if it's saved and blammo! You're on. since it's using open standards like https it would be pretty simplistic to make a neat little "dialer" that connects autmatically as soon as you click on it, but since it is all open standards you'd only have to write it for the biggest platforms i.e. windows mac and linux, everyone else is used to minor inconvenience anyway, and would probably be extremely loyal to your company for making it _that_ easy.
Forget dns (Score:1)
*ducks*
Re:Physical Security? (Score:2)
rt updated to dhcpd.conf... (Score:1)
Write your own server (Score:1)
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.