Web Security Basics with Apache: Authentication and Secure Log FilesJimmy Ball Today, Web administrators managing an Internet site should be familiar with more than HTML, Javascript, and other Web development tools. They must also be Web security experts, and work closely with the administrator of the system hosting the Web site. Although the specifics of Web security will vary between sites and Web servers, many Web security principles can be broadly applied. In this article, I examine authentication and log file security issues with the Apache Web server. If you happen to be using different software, look for parallel features in your server, and modify the procedures suggested here accordingly. Begin at the Beginning To improve your site's Web security, start with a Web security investigation. Several areas should be addressed, including:
Lastly, the way to build a secure Web site is simply to begin. An acceptable security plan in place is better than a great security plan on paper. Since both authentication and log file security can be implemented in a variety of ways, we should first select a Web server package and platform. I chose the dynamic duo of Web server environments: the Apache Web server running on a UNIX platform. You can visit the Apache Web site at http://www.apache.org to download this freely available software, which has been extensively tested on a variety of UNIX platforms. Authentication Two common Web authentication techniques are supported by Apache. They are htpasswd files and Apache authentication modules. As you will see, even these techniques can present Web security issues. As a quick refresher, recall that .htaccess files can control Web access by username/password pairs, by IP address, and by combinations of the two. Additionally, .htaccess files control access in the directory where they are placed. They also govern access privileges to any sub-directories. A simple example of an .htaccess file and corresponding htpasswd file is shown below.
Example 1 - .htaccess
AuthName Example1 AuthType Basic AuthUserFile /usr/local/apache/htdocs/Webusers <limit GET POST> order deny,allow deny from all allow from 190.27. require valid-user </limit> Webusers:
joe_user:DtHWUqfhKfQB2 josephine_user:QS4JTTkMx8PkM The heart of the .htaccess file lies between the Limit tags. The configuration specifies that all hosts will be denied access except machines connecting from the 190.27. IP domain range. Additionally, a valid login is required for hosts that match the address range. This login information is taken from the file specified with the AuthUserFile directive. The contents of this file, Webusers, are shown in the above example. The primary problem with the Web authentication implemented above is with the AuthUserFile. Unfortunately, AuthUserFiles do not mirror the password shadow file concept active on most UNIX systems today. The AuthUserFile can potentially be named anything, located anywhere, and allow read/write privileges to anyone. If you need a more robust solution, consider Apache authentication modules that store user information in a local database. This method will require some initial configuration changes. The requirements are: (a) a database accessible to the Apache Web server, (b) the appropriate Apache authentication module for the database, and (c) a C compiler to recompile the Apache Web server. For example, the mSQL (http://www.hughes.com.au) database is a good choice for tight budgets as well as authentication needs. Once the database is installed, the next step is to get the appropriate authentication module (mod_auth_msql or mod_auth_dbi) from http://modules.apache.org. Then, incorporate the authentication module into the Apache configuration (as outlined in the Apache documentation) and recompile. Upon success, you can launch the new Apache server and start testing. Testing will require a database and a similar .htaccess file. Below is an example.
Example 2 - .htaccess
AuthName Example2 AuthType Basic Auth_MSQL_EncryptedPasswords on Auth_MSQLdatabase example Auth_MSQLpwd_table members Auth_MSQLuid_field username Auth_MSQLpwd_field passwd <limit GET POST> order deny,allow deny from all allow from 190.27. require valid-user </limit> Notice the lines beginning with "Auth_MSQL" have been substituted for the single AuthUserFile directive from Example 1. These directives point to a specific database, table, and fields to handle Web authentication. The Auth_MSQL_EncryptedPasswords directive is set to "on", which means the passwords in the database will be considered encrypted when verifying against passwords entered by the user. Although it was thoughtful for the module author to provide the "off" option to this directive, it would be wise to avoid this functionality. At this point, you may be tempted just to sit back and relax, convinced that these Web authentication techniques provide sufficient security. A sober-minded Web administrator, however, will realize that a few remaining security issues must be addressed. As with any configuration file, .htaccess files can be misconfigured. Try removing the line "deny from all" in either example above to see if IP addresses outside the 109.27. range are denied access. In Example 1, the location of the username/password file can be an issue. For sites with multiple developers, these files can be scattered throughout the site. In addition to having numerous username/password files to check, the file permissions may allow any user on the system to view, download, and even attempt to crack the encrypted passwords using a number of password-guessing techniques. If successful, this username/password pair could provide access to sensitive information like email, assuming the user has an identical username/password pair for Web authentication and email. Another concern is the lack of password aging. Under most UNIX hosts, password aging forces users to change their passwords periodically. This is not a built-in feature with any Web authentication method. Lastly, always be aware that usernames and passwords are not automatically sent across the Web along a secure link. Fortunately, solutions exist to these security issues. For starters, incorrect configuration files are a fact of life. That is why the word "audit" was invented. Initially, your Web security audits may require manual inspection, but script development is on the horizon as you learn how .htaccess and any corresponding username/password files are used on your Web site. To get started, a simple find command will show all .htaccess files in your Web hierarchy and the corresponding AuthUserFile entries - assuming the command is executed as root.
find /usr/local/apache/htdocs -name .htaccess -print -exec grep -i
AuthUserFile {} \;
Next, security issues involving .htaccess and username/password files can be addressed in a couple of ways. In all cases, efforts should be made to minimize read privileges of all .htaccess files. First, determine the groupid of the Apache Web server daemon. Using this information, a script can be written to find all .htaccess files in your Web hierarchy and change their permission and group ownership to minimize read privileges. An example script is shown below.
#!/bin/sh WEBHOME=/usr/local/apache/htdocs WEBGROUP=webgrp FIND=/bin/find CHGRP=/bin/chgrp CHMOD=/bin/chmod for i in `$FIND $WEBHOME -name .htaccess -print` do $CHGRP $WEBGROUP $i $CHMOD 640 $i ls -l $i echo "Done with $i." done The group ownership is set to "webgrp", and read privileges are restricted to the owner and the group. You may want to run this job under root's crontab periodically. Developers will continue to add Web authentication to their sites. Incidentally, it is a good idea to make your Apache Web server run in a unique group by itself. This further reduces your security risks. After securing .htaccess files, username/password files should be inspected. For starters, it is best to have all username/password files outside of the Web hierarchy. This prevents savvy Web users from getting the username/password file without having an account on a Web server machine. With a few changes, the script above can be modified to find all AuthUserFile entries and restrict the read permissions similar to .htaccess files. Rather than writing the script, I leave that as a scripting challenge. To begin, consider using grep with the find command and parsing the output with awk to get the AuthUserFile entry. The rest should be straightforward. Securing username/password files with a script may be all you need for now. But ideally, migrating these username/password files to a database and using Apache module authentication can provide the most secure solution. Granted, read/write access to the database must be limited or at least controlled. However, this migration to a database can provide opportunities to consolidate and combine user entries. In my opinion, reducing users means reducing risks. When addressing concerns about password aging, unfortunately, there are no elegant solutions. Web authentication through a Web browser is not designed to require the user to change passwords. One solution can involve some extensive CGI programming with Web-to-database techniques to develop your own authentication scheme, password aging, etc. For most sites, the time and expense factors of development and maintenance outweigh the security advantages gained. Nonetheless, it is a solution. Finally, to address the security issues of information in transit from the client to the server, the choice is simple. Install a secure Web server. A secure Web server with an associated secure Web client (e.g., Netscape Communicator and Internet Explorer) provides an encrypted communication path. All information between the client and server has been encrypted to prevent a cracker from capturing the information while in transition. Most sites, however, will not choose this option for simple Web authentication needs, even with a large user base. But for access to sensitive information, a secure server is highly recommended. It can even give your clients more confidence in your service. Some secure Web servers to consider are Stronghold (http://www.c2.net) or the RedHat Secure Server (http://www.redhat.com). Both products are based on the Apache server. Log File Security Web administrators can benefit from the information in Apache log files. So can the cracker. The only good thing about log file security is that log files are not typically public to the Internet. Initially, you must have an account on the machine to even view the log files. The down side is for large sites with many users already on the server. Either way, log file security needs to be addressed at each site. All users make mistakes when trying to log in from time to time. A common error for some beginners is to enter a password instead of the username when prompted with a Web authentication dialog box. The password is then logged, typically in the third field for that access entry in the access_log file. Now at some point, we expect this same Web visitor will enter the correct information at the authentication dialog box and gain access. The logs recorded a clear-text username and password for this user along with the associated URL. Any user with read access to this log file could gain unauthorized access to the associated Web page through this logged information. This could be even more alarming if the vulnerable username/password pair could be used to gain unauthorized email access. Another problem occurs when a private document is placed on a Web site. If the document is accessed just one time, it is logged by default. If the document is entitled, HR-salaries.html for example, then it could attract a lot of attention if found in the access logs. Solutions for log file security risks are relatively simple. For starters, consider using chmod and chgrp once again to restrict read privileges. But this time, apply it to the Web log directory rather than individual files. This eliminates the need to execute chmod and chgrp each time the logs are rotated. All Web log files will be secured at the directory level. Some sites will have trusted users that require access to your logs for various reports. To solve this dilemma, create a new group containing users that require access to the Web logs. Afterward, the Web administrator can change the group ownership on the Web log directory to this new group, and access requirements are met without major risks. If you are still concerned about log file security, install a log file analysis program like Accesswatch (http://accesswatch.com) to assist with monitoring Web log files. If that is not enough, take advantage of log customization features in Apache. Simply disable the TransferLog directive in httpd.conf. Then, use the CustomLog directive to create a log format that includes the information needed for reports but no more. Keep in mind, a custom log format may cause the log file analysis program to fail if the format is radically different. Conclusions With every new site, Web developers should take the opportunity to build a secure site from the ground up. Where authentication is required, seriously consider the Apache authentication module coupled with a database. Build custom formats that meet reporting needs, but limit access to sensitive information. With fully developed sites, the challenge is greater but not unsurpassable. Control Web authentication files and log files with UNIX commands. Make every effort to perform routine security audits. Web security is really a matter of details. Today, Web administrators must consider all security risks and develop a plan to address them. Applying both proactive and reactive measures can keep your site secure for weeks to come and allow you to be prepared if an attack does occur.
About the Author
Jimmy Ball is currently the manager of IT Security and Development at the University of Mississippi. He has more than ten years of UNIX experience and five years of experience in Web administration and development. Additionally, Jimmy pursues his interests in software development training as an instructor for Batky-Howell, Inc. He can be reached at ccjimmy@olemiss.edu.
|