Re: deployment question

Dustin any input on this one?

Maqbool Hashim wrote:

> Hi there,
>
> I've finally come to a decision as to what sort of backend we're going
> to use. Thanks for all the discussion it was very helpful in coming
> to the final decision. Heres what I'm going to go with:
>
> Use the UNIX password file on the machine that holds the radius server
> to authenticate users against. Users will be able to add users on
> that machine, with a special login. They won't have access to the
> radius configuration files at all. Users will only be able to login
> to the RADIUS machine over the LAN.
>
> The idea is that we trust our users and they will only be allowed to
> login to the RADIUS machine over the LAN. I was thinking of creating
> a UNIX login, which instead of providing a shell, executes a script to
> add the new radius user.
>
> Ideas on doing this as securely as possible would be appreciated. I
> have freeradius running on OpenBSD.
>
> Dustin Doris wrote:
>
>> 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
>>
>>
>
>
> - List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html