On Wed, 13 Apr 2005, Maqbool Hashim wrote: > True. Just coming back to your earlier mail: > > "Put the front-end on a different machine and have it only run apache. > Put the ldap server on your private network and have the radius server > and webserver with an interface on that network." > > The problem I can see with this is a PHP vulnerability would mean access > to the backend. Basically putting the backend on the LAN doesn't really > give us extra security, because the frontend will have full access to > the Users table.
The only extra security is if you're using ldap then you don't need to hardcode a master username/password into the webserver. So, in theory if someone hacked your webserver via php vulnerability or whatever else, they still wouldn't have any way to do any damage to your ldap directory or even view it. If you were to use mysql, then you'd need to hardcode some user that has write access to the whole database into your front-end. They get your webserver, they've now got your db. Same with berkely db. You might have to run the berkely db and radius servers on the same machine as the webserver. Or run some kind of ssh script to access the remote server and modify the db. I don't know if you can modify a berkely db remotely. Same problem, you'll have some kind of ssh key that will get them in or they'll have local access to it. Of course, if you use ldap, someone gets into your webserver and you then have an ssh exploit on your ldap directory you're out of luck again. But that's the engineers fault for not keeping it up to date. You could always try to firewall the public website to only allow your IP space into it. That way if someone does mess it up, you can track it back to that person and kick their ass. :) hehe. > > I guess we've got to have a weak link somewhere huh? > Unfortunately. Anytime something has to be publicly available, there is bound to be a hole somewhere. > Dustin Doris wrote: > > >dbm would be very fast and simple. I've never used it directly though, so > >I can't provide any help. Openldap does use berkerly db as the backend db > >for datastorage, so you are really just taking off a layer and making it > >much simpler. Mysql even offers a berkely db backend. > > > >You will need to build some sort of front-end with access to write to that > >db though. This will get you back to the security issue before as you'll > >have to have the logic of who can change what built into the front-end. > >You'll also have to write that front-end so it knows how to write > >correctly to the db. > > > >If you can do it, it should be real fast. > > > > > > > > > >>Thats very helpful thank you. I was actually thinking of something > >>similar except using mysql, but obviously ldap would be better as it > >>directly provides that feature. However I was just reading some of the > >>rlm_dbm file and it seems like the ideal backend for us, as it doesn't > >>require any addtional server software, fast etc. > >> > >>However I'm not too familiar with db and whether it would be easy to > >>acheive the same thing, i.e. users be able to change their own record in > >>the dbm users file. > >> > >>Any ideas? > >> > >> > >>Dustin Doris wrote: > >> > >> > >> > >>>Ldap will provide that feature for you. An openldap acl might look like > >>>this. > >>> > >>>access to attr=userPassword > >>> by self write > >>> by anonymous auth > >>> by * none > >>> > >>>access to dn.one="ou=useraccounts,dc=yourdomain,dc=com" > >>> by self write > >>> by dn="cn=freeradius,dc=yourdomain,dc=com" read > >>> by anonymous auth > >>> by * none > >>> > >>>That means you can login and change your own stuff, but can't see anyone > >>>elses. Freeradius can read for authorization. This doesn't include > >>>reading passwords, which is shown as none in the prior acl. > >>> > >>>You then build a webpage front-end, such as with php. Have the user login > >>>to the webpage and change their password. The webpage will then send the > >>>username/password of the user logged in to ldap for the password change. > >>>This means that the webpage itself won't have super user rights and can > >>>only change the username/password of the person that is logged in and if > >>>they provide the correct username/password in the first place. > >>> > >>>Don't want apache? Then build a commandline tool users can use that does > >>>the same thing. You can write a shell wrapper over the ldapmodify client > >>>that comes with openldap. Then again if you are allowing users local > >>>access to a machine in the first place, that is less secure than building > >>>a webserver. > >>> > >>>You want a command line tool for clients to use on their own computer? > >>>That is starting to get hard to support now. I would stay away from that. > >>> > >>>If you're not hardcoding any superuser username/password in the webserver, > >>>then you know that users can't obtain that information and do anything to > >>>the ldap directory. Put the front-end on a different machine and have it > >>>only run apache. Put the ldap server on your private network and have the > >>>radius server and webserver with an interface on that network. That way > >>>the ldap traffic is only going through over private network. > >>> > >>>More complex, yes, but its not too bad. Less secure? Anytime you want to > >>>add functionality, such as password changes, you will open security. But > >>>this setup should be pretty secure. > >>> > >>>On Wed, 13 Apr 2005, Maqbool Hashim wrote: > >>> > >>> > >>> > >>> > >>> > >>>>I'm with you. Thank you kindly. Now sorry to keep going on about this > >>>>but..... > >>>> > >>>>Can you think of an alternative to mysql? Something like a command line > >>>>password change tool which accesses the users database. I'm just trying > >>>>to find a way of acheiving this without having to install apache and > >>>>mysql. More features, more complexity, harder to secure. > >>>> > >>>>Miles Mawyer wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Right. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>- > >>>List info/subscribe/unsubscribe? See > >>>http://www.freeradius.org/list/users.html > >>> > >>> > >>> > >>> > >>- > >>List info/subscribe/unsubscribe? See > >>http://www.freeradius.org/list/users.html > >> > >> > >> > > > >- > >List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
