Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Business

Using DHCP for Authentication? 69

Posted by Cliff from the there's-gotta-be-a-better-way dept.
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."
This discussion has been archived. No new comments can be posted.

Using DHCP for Authentication? More

Using DHCP for Authentication?

Comments Filter:

  • arp requests (Score:4, Interesting)

    by dpoulson ( 132871 ) <daz@@@22balmoralroad...net> on Thursday November 07, 2002 @05:14AM (#4615283) Homepage Journal
    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.

  • PPP (Score:5, Insightful)

    by dago ( 25724 ) on Thursday November 07, 2002 @05:22AM (#4615306)
    See the subject.

    It can assign ip adress, includes secure scheme for authentifications, well implemented, easily integrated with radius for more advanced stuff (DB, accounting, ...). It works over almost anything (ethernet, atm, ...).
    • Please don't say that. PPPoE may buy you advantages at sign-on time, but only by making things slower & more complicated for the rest of the session. Quake gave much better ping before my DSL provider switched to PPPoE.

      • Re:PPP (Score:3, Interesting)

        by dago ( 25724 )
        Yep, because it adds a new encapsulation layer, so, for the same end user bandwith, it needs more real raw bandwith.

        BTW, what was used before PPPoE ?
        • DHCP and plain old IP.

          • Re:PPP (Score:2)

            by dago ( 25724 )
            I'm somehow curious, but IP over what ?

            I always thought DSL was over some sort of ATM

            • Ssssssh, you don't want to scare users off with 20+ year old tech that we are just now rolling out to their homes. Yes ADSL is an odd implmentation of IP over ATM, much as IDSL is ISDN rebadged.

              • Re:PPP (Score:2)

                by dago ( 25724 )
                you forgot xDSL, which is obvisouly a rebadged version of X.25 !

              • Re:PPP (Score:2)

                by oh ( 68589 )
                Umm, 20 year old tech? Oh yeah, you mean IP. I can't remember the exact RFC number off the top of my head but the reference was always [Postel, 82].

                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.
    • I assume one would have to use PPPoE or PPTP to deploy PPP over a DSL/Cable network. In this case, one should be careful not to use CHAP as the authentication mechanism. It is not suitable for IP networks and there are known (and easy) attacks against it.
    • Horrible option because not only do you receive a slowdown from the added encapsulation - you break compatibility (MTU has to be less than 1456 or some such) but also from the PPPoE concentrator. It may not be geographically or networkingly(sp?) close to you so you add latency. Also if the concentrator is flakey, slow or goes down you receive more angry phone calls from customers whos connection just turned to shit.

      -- iCEBaLM

  • Just add the features you need to dhcpd (Score:4, Insightful)

    by ChadN ( 21033 ) on Thursday November 07, 2002 @05:27AM (#4615325)
    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.
    • 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)

      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.
      • Ya, seems like the best solution would be to take one of the many open source DHCP servers out there and add a database layer to it to do a SQL query. I will suggust MySQL because they have good documentation and I have used it before, and it was dead simple. Then you can have an easy to use simple front end to change the mac addresses. Sense almost every programmming language has MySQL bindings. But how much are your mac addresses really changing? Don't you have some sort of ATM address for the DSL bridges, and all the cable modems I have seen have there own MAC addresses. So they should only be changing when the end user equipment changes.
      • Um, you have never worked for a large company have you? Virtually ALL do some inhouse software development. I would even go so far to say that most mid sized companies do too. Adding database lookup to dhcpd is not all that large of a programming task frankly. Probably take a competent programmer a couple days at most. I'd be surprised if it hasn't been done before. I would suggest a dbm style database as opposed to a SQL database however, as you don't need the overhead for such a simple task.

  • Wrapping (Score:5, Informative)

    by Graelin ( 309958 ) on Thursday November 07, 2002 @05:34AM (#4615352)
    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 [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)

      by uradu ( 10768 ) on Thursday November 07, 2002 @10:15AM (#4616139)
      > Of course, you could write your own DHCP server too

      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)

      by Pointer80 ( 38430 )
      Someone wrote a patch (for ISC DHCPD) that would let you call an external program when a lease was granted. Check the mailing list archive on marc.theaimsgroup.com.

      I think this guys best bet (if he decides to go with bridge1483/DHCP) is secured arp. See my main post for more info...

      /pointer

  • I found... (Score:3, Informative)

    by 3-State Bit ( 225583 ) on Thursday November 07, 2002 @05:36AM (#4615358)
    ...this abstract [ipsj.or.jp] 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.

  • Don't forget... (Score:4, Insightful)

    by Phexro ( 9814 ) on Thursday November 07, 2002 @06:04AM (#4615427)
    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.

    • Re:Don't forget... (Score:1, Insightful)

      by Anonymous Coward
      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.

      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?

      • 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'.
        • You probably could have fixed the problem by unplugging the cable modem. With the providers I have worked with it is not there equipment that is keeping you from connecting when you change cards it is the "modem". Unplug it and let it lose its settings and it works again as they "provision" by entering its MAC address in there system not the MAC address of the ethernet card. Because like you did you can change a MAC address in software. Some cable companies ask you to never unplug your cable "modem" because it has to download its firmware setings again every time you do so they put useless power buttons on they that don't get them to actually restart.
          • Tried it. Didn't work. Repeatedly. (And unplugging and waiting for a good 30-60 seconds.)
            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.
          • Depends on whether you're on a cable modem or a POTS (plain old telephone service) DSL. On the phone system, it's neither.We've swapped modems, cards, etc. As long as you've got the right account name and password, and you're going through the right concentrator, you'll get a connection.
            • Sorry about that - forgot that you don't even have to be on the same concentrator. Did some testing, using another guy's modem/ethernet card and system plugged in here at the office, definitely not the same concentrator - lives 15 miles away.

    • Re:Don't forget... (Score:3, Informative)

      by Pointer80 ( 38430 )
      That in addition to not being scalable or sustainable, this scheme is not secure, either.

      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.

      /pointer

      • Re:Don't forget... (Score:3, Informative)

        by Phexro ( 9814 )
        "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.

        • Re:Don't forget... (Score:3, Insightful)

          by Pointer80 ( 38430 )
          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.

          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)

    by bartjan ( 197895 ) <bartjan.vrielink@net> on Thursday November 07, 2002 @06:11AM (#4615452) Homepage
    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 [blueyonder.co.uk] 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
    • Yes BY do use this method, but their DHCP servers often struggle. Changes to the "Self-Care" pages can take an age to be acknowledged. If for some reason I'm not connected, re-negociating an IP address can result in MANY failures. Having said that - they "seem" to be getting better. I've had less DHCP related problems recently.

      I don't think they've found the most suitable approach.

  • My company does this (Score:4, Informative)

    by Naikrovek ( 667 ) <jjohnson@ps g . com> on Thursday November 07, 2002 @06:48AM (#4615540)
    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

  • Look at DDNS, too (Score:4, Interesting)

    by dpilot ( 134227 ) on Thursday November 07, 2002 @08:45AM (#4615807) Homepage Journal
    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.
    • DDNS has nothing to do with DHCP security or authentication. It is just a way DHCP server could make the client's life a bit easier.

      Authenticated DHCP is also going no where since it is not considered to be secure enough.
      • My point was that DDNS can be securely authenticated, according to some stuff on the ISC website. I was suggesting that there may be a way to piggyback DHCP security on top of the DDNS security. I don't know how practical this is, but I suspect it can be patched in.

        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.
  • Longer reply later.

    Yes, some early-but-proprietary infrastructure exists.

    Are you still interested ?

  • RADIUS? (Score:3, Informative)

    by embo ( 133713 ) on Thursday November 07, 2002 @10:10AM (#4616120)
    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.
    • There is a book published by Addison We... that relates specifically to these issues. Whilst it does
      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)

    by Pointer80 ( 38430 ) on Thursday November 07, 2002 @11:13AM (#4616565)
    I work for a telco that was in the same situation in June of 2000. I elected to go with DHCP/bridge1483 because:

    * 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. :\ 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.

    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! /pointer
    • Why not just have the DHCP server query the database directly then you NEVER have to restart that DHCP server. And you can make your customers feel great because there connection will start working while they are on the phone with tech support. Not "well it should be working within X minutes". 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.
      • Why not just have the DHCP server query the database directly then you NEVER have to restart that DHCP server.

        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.

        /pointer
  • 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
  • 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/ [cmu.edu]

  • 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.
    • Well it will because in the cable and DSL world you know from which cable or xDSL "modem", request is comming from. You do not do it by the MAC address of the ethernet card but from the MAC of the "modem" or the what ever it is called ATM address of the xDSL bridge.

  • authpf + putty (Score:3, Informative)

    by DieNadel ( 550271 ) on Thursday November 07, 2002 @12:19PM (#4617107)
    You can use authpf [openbsd.org] 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 [greenend.org.uk] and change it so it would look more like a login interface.
  • 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.

    • Sounds pretty much like what these guys [stockholmopen.net] do... They offer their implementation for download as well. Pretty cool stuff they do, IMHO. I am just not sure if this rather manual authentication method (entering account name and password into some login form) will be accepted well by customers... The StockholmOpen people also note that their system is not 100% secure, but its way better than doing authentication on the basis of MAC addresses.
      • How is it any different thatn what they do now? only it is saved for them. Most browsers will save passwords, and those that don't the users are aware that they are on a strange platform or using old software and they will put up with it.
        • Well, from what I read in the original question users now are solely authenticated by their MAC addresses. Myself, I could cope with entering passwords into web forms (or I would find a way to automate that), I just think that there would be users that might not at all find web forms handy, despite the ability to have passwords stored by browsers... My main point was to point to StockholmOpen anyway... ;)
          • ahhh --hehe

            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.

  • use rarp and tftp
    *ducks*
  • man omapi. And then work the db. No prob =).
  • 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.

Slashdot Top Deals

BLISS is ignorance.

Close