Matt Ashfield wrote:

The issue we have is when running the Radius server in debug mode with full log-level, we see the cilent's username and password in clear-text as it attempts to bind to the LDAP server. Certainly we could change the debug mode level to not see this, but the fact that the ability to see that is available is troubling. I'm sure many others on this list use FreeRadius and I'm wondering what sort of policies you have in place to address this security risk. Anyone with high-level access to the box could certainly login, make a change to the debug level and capture sensitive login information.

This is an issue of your security policy. FreeRADIUS has access to LDAP. Anyone who is not trusted enough to touch LDAP, should not be touching FreeRADIUS. This is how most interdependent services work (Windows, Linux, or otherwise). Running the server in debugging mode should only be done during setup (and most likely on your dev box, not the production one). Once FreeRADIUS is working as it should, you shouldn't be running it in debug mode. An app like FreeRADIUS will always have access to the user/pass because it needs that info to talk to LDAP. Even if the debugging output didn't have the user/pass, then anyone with enough rights to start/stop the app can likely upload a hacked version of FreeRADIUS that does output the user/pass. It is just a matter of a print statement or two. The short answer is don't give high-level access to this box to people you don't trust. -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com

Matt Ashfield wrote:

The issue we have is when running the Radius server in debug mode with full log-level, we see the cilent's username and password in clear-text as it attempts to bind to the LDAP server.

That is really the whole purpose of debug mode. You see the users password not only there, but in the attributes when the RADIUS request is printed out, too. Debugging mode has little purpose without that information.

Certainly we could change the debug mode level to not see this, but the fact that the ability to see that is available is troubling. I'm sure many others on this list use FreeRadius and I'm wondering what sort of policies you have in place to address this security risk. Anyone with high-level access to the box could certainly login, make a change to the debug level and capture sensitive login information.

I'm not sure where the problem is. Administrators of the radius server can log in and edit the RADIUS server configuration? Is this really what you're worried about? The short answer is that anyone who can write to the servers configuration, or even read the shared secrets in the "clients" file can snoop on the passwords. There's no way to prevent that without also preventing the server from running. Most of the problem can be solved by ensuring that only selected users have read access to the configuration files. Obviously, "root" has access, and at most one other user, say "radius-admin", with group "radiusd". The files should be owned by "radius-admin", writable by that user. The files should be in group "radiusd", and readable (but NOT writable) by that group. No on else should have read or write access to the configuration files. And the server should run as user "radiusd", group "radiusd". This is covered in my book in more detail. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog