7.1 RADIUS for Web Authentication

Chances are good that you have an area of your web site that needs to be protected from general public access. If you use the Apache web server, you may be familiar with the various methods by which this can be done: using an . htaccess and . htpasswd combination, setting Unix file system permissions, using Allow and Deny directives inside the Apache configuration file, and others. However, it's now possible to instruct Apache to authenticate against an existing RADIUS database of users, thereby protecting the area of your web site from unknown users and allowing access to those you trust.

This authentication is done using a module developed for Apache 1.x called mod_auth_radius . (Apache 2.0 had not been released at the time, and the module has yet to be updated for Version 2.0.) In effect, Apache becomes a RADIUS clientoccupying the traditional position of the NAS in the authentication chainand hits off the RADIUS server for authentication and accounting requests . Not only does this save administrative time by consolidating what potentially could become two user databases into one, but it also allows for more flexibility. Namely, RADIUS accounting can be used to track usage statistics for this protected site. Apache can keep detailed logs, but sometimes it's helpful to have all audit information in one place.

There are several potential applications for this module. The following scenarios are likely candidates for this module:

A corporation who wants to create a special Intranet site specifically for its remote, mobile, and home users
An Internet service provider who wishes to create a private site for subscribers only; perhaps a billing or support site that contains technical information suitable only for paying customers
A web-based business that sells subscriptions to an online database or an online journal

And there are many others.

7.1.1 The Functionality

The mod_radius_auth module follows a predictable pattern in its use. A typical transaction occurs like this:

The browser submits a page request for http://www.website.com/index.html.
Apache sees that the directory is secured and sends an Authorization Required prompt (with spaces for the username and password) to the end user.
The user responds to the authentication request with his credentials. The browser sends the response, and the same page request once again, to Apache.
Apache receives the user's response and hands it off to mod_auth_radius . The module sees that a cookie is not present (since this is the user's first request.) It constructs a RADIUS request and transmits it to the RADIUS server.
The RADIUS server performs the authentication and sends its response back to mod_auth_radius .
mod_auth_radius interprets the RADIUS server's decision. If the authentication was deemed successful, the module sends a cookie with the public and private information hidden using MD5. If the authentication was unsuccessful , the module returns an Access Denied message.
The web browser sends the cookie with any other request. As long as mod_auth_radius recognizes the cookie as valid, it will not send another request to the RADIUS server.

The cookies that are set on the end user's computer are valid for the lesser of the two values specified in the module's configuration and the secured area's configuration. The cookies also are killed when the browser ends, either by crash or via a user-initiated exit. The module will attempt to make cookies expire that, in its opinion, are too mature. However, if the browser does not acknowledge or follow through with the cookie expiration requests, the authentication prompt will appear repeatedly until the user reloads the browser and the site.

7.1.2 Configuring the Module

First, compile the module into Apache or use the apxs utility to instruct Apache to use mod_auth_radius as a dynamic module. You can obtain the module from its home page at http://www.freeradius.org/.

To compile the module statically into Apache itself, issue the following command:

 ./configure --add-module=/path/to/mod_auth_radius.c && make

The module is completely installed when the make process finishes without errors. Alternatively, to use mod_auth_radius as a dynamic module, use apxs as in the following example:

 apxs -i -a -c mod_auth_radius.c

Next , edit the Apache httpd.conf file to instruct Apache to load the module. Include a line in the LoadModule section like this:

 LoadModule radius_auth_module   libexec/mod_auth_radius.so

Then, scroll down to the AddModule section. Immediately following the line adding mod_auth.c , add the RADIUS module, as shown here:

 AddModule mod_auth_radius.c

Now you need to create a section with specific configuration directives for the mod_auth_radius module. At the end of httpd.conf , create a section like the following example and configure it as explained next:

 <IfModule mod_auth_radius.c> AddRadiusAuth radiussservername:port sharedsecret timeout AuthRadiusBindAddress 192.168.0.1 AddRadiusCookieValid 5 </IfModule>

The AddRadiusAuth directive tells Apache to authenticate against RADIUS. You specify the name of the RADIUS server, the port to use, the shared secret for the web client, and the timeout period Apache should wait before giving up and assuming no response will be sent. The AuthRadiusBindAddress directive specifies the local interface on which requests should be sent. The RADIUS server can then be set to accept requests only from this address for added security. (This directive is not required, since by default the module lets the underlying operating system choose the interface to use.) The AddRadiusCookieValid directive specifies the minutes for which the cookie sent in the response to the end user from the web client is valid. Setting this value to zero (0) signifies that the cookie will be valid forever.

The initial configuration is now complete. The next step is to define the areas of the web site that need protection. There are two ways to do this: (a) you can use an .htaccess file placed in the directory to be protected, or (b) you can define the locations inside httpd.conf . In this example, I'll assume that you've decided to define the locations inside httpd.conf . If you choose to use an .htaccess file, the directives between the <Location /secured/> and </Location> tags should be placed into the .htaccess file and subsequently saved into the directory to be secured.

To control access on a per-directory basis using httpd.conf , add the section to the file and configure it as such:

 <Location /secured/> AuthType Basic AuthName "RADIUS authentication for localhost" AuthAuthoritative off AuthRadiusAuthoritative on AuthRadiusCookieValid 5 AuthRadiusActive On require valid-user </Location>

The following definitions provide an explanation of each of these directives.

AuthType: This module requires basic authentication since digest authentication won't work correctly. (See Ben Laurie's Apache: The Definitive Guide , (O'Reilly), for more information on the two types.)
AuthName: The contents of this string are included in the password prompt presented to the end user. It simply serves to inform the user of which protected area he's attempting to enter.
AuthAuthoritative: This directive ensures that other authentication types are not used for this particular site area. You can net the same effect by commenting out other authentication types appearing previously in httpd.conf , but that is only recommended if this server is used only for this protected site.
AuthRadiusAuthoritative: This tells Apache to consider all RADIUS responses authoritativethat is, the RADIUS responses are "the final answer" (thanks, Regis).
AuthRadiusCookieValid: This is the same directive as the cookie setting globally set in the module configuration section. The server will choose the lower of the two values and set the cookie to expire at that interval. This value is in minutes.
AuthRadiusActive: This turns on RADIUS authentication globally. If there's an area of the site for which you want to use some other authentication method than RADIUS, set this directive to Off for that particular section. The default, if this directive is not included, is On.
Require valid-user: This directive ensures that only valid users can access the site. If the RADIUS server returns anything but a valid user, access will not be permitted.

7.1.3 Using Challenge-Response with mod_auth_radius

The mod_auth_radius module is completely compliant with the challenge-response authentication method. However, end-user browser support is relatively limited: Netscape 3.x and 4.x and others support it well, but unfortunately , the browser with the largest hunk of market share, Internet Explorer, doesn't properly follow the RFC and, therefore, doesn't function correctly with challenge-response. You should certainly consider this caveat in determining whether to use challenge-response.

For supported browsers, the key to challenge-response is that the RADIUS cookies are set upon any authentication attempt. You can enter gibberish for your password and try to authenticate into a secured area, but while you are denied access because the password was incorrect, the cookie is being set with the RADIUS state attribute. The module also modifies Basic-Authentication-Realm. You then receive another prompt to try again, typically with a challenge. Once you enter the correct password (or the correct response to the challenge), all is well.

7.1.4 Limitations of the Module

Of course, opening any sort of private system to the Web presents a smorgasbord of security concerns. While Chapter 8 serves to detail the inherent problems and limitations of the RADIUS protocol, these limitations are still present using mod_auth_radius and should be considered .

First, using static passwords over the Web is not secure. The password from the end user to the web server is sent in plain text ("in the clear," that is) and is open to sniffing by anyone with the proper tools. This problem is exacerbated when the RADIUS server exists on the same machine as the web server. RADIUS was not designed to be directly exposed, and with script kiddies and crackers roaming about, it's a problem you simply don't want to have.

Second, using the same server for Web and dial-up users isn't the best idea, either. The problem lies in this: if the cracker manages to gain access to your web site using a sniffed password, he would have no trouble actually dialing up and gaining access to your system. He can pose as anyone and this becomes a serious threat to the integrity of your network. You might say that this seems almost a direct opposite to the benefits I was preaching about previously.

However, there are ways to work around these limitations:

Use secure sockets layer (SSL) to protect the password.
If you must open the web server to the Internet, protect the site with a secure server certificate ( https ) and purchase an SSL certificate from one of the many providers. This at least provides some protection for the passwords.
Use one-time password (OTP) authentication. If you don't have the computing resources to separate the web server you want to protect and the RADIUS server, OTP significantly reduces the risk of password sniffing. See Chapter 8 for more information.
Use your network architecture to your advantage. If your clients are dialing into a local area networkif they receive a private-class IP address such as 10.0.0.1 , 172.16.0.1 , or 192.168.0.1 , for examplethen the risk of snooping and sniffing is also moot. The mod_auth_radius module could then be used to protect user-specific information on the local network without opening the RADIUS passwords up to the entire Internet.

If you do decide to use OTP authentication, there are some caveats to the functionality of the module. When you access a site without stipulating a specific page on the site http://www.jonathanhassell.com/ , for exampleApache searches for files named home.cgi , home.html , index.cgi , and index.html . When mod_radius_auth looks for these files and it can't find them, it returns a 404 (Not Found) error. However, when it does find a file, it sets a cookie and returns a successful page request. The browser, though, might not use that cookie when it accesses another page on the site, which causes another authentication transaction with the RADIUS server (since the credentials include an OTP).

To work around this, surf to a page on the web site. Have that page contain a link to a specific location on the web site (i.e., http://www.jonathanhassell.com/private/index.html ) and instruct the user to use that link to get to the secured area. This way, the user only has to use one authentication attempt to get to the secured pages. Note that this is only a real problem for implementations that use OTPs, but if static passwords are in use, multiple authentication attempts will take place. The credentials, however, are re-sent, and the user is not prompted: the only problem is the increased traffic, which may not be a significant limitation for your system.