| Previous | Table of Contents | Next |
The logfile rotation script needs to be run as the same user that launched the HTTP daemon originally—for example, “root.” You may want to write additional scripts to place these .0 files into an archive of some sort; my favorite one is to use the year and month as subdirectories, such that the logs for January 1, 1997, go into a file named 1997/01/01 somewhere off a directory with a lot of room. That way, the log files are easy to archive somewhere else (to DAT tape, to CD-ROM, or even to remove it) by moving a directory.
The security of your server is, no doubt, one of your biggest concerns as a Web site administrator. Running a Web server is, by nature, a security risk. For that matter, so is plugging your machine into a network at all. However, a lot can be done to make your Web server more secure from external forces (people trying to break into your site) and internal forces (your own Web site users mistakenly or willingly opening up holes).
The biggest cause for concern about protecting your site from external threats is CGI scripts. Most CGI scripts are shell-based, using Perl or C-shell interpreted programs rather than compiled programs. Thus, many attacks have occurred by exploiting “features” in those shells. This section won’t go into too much detail about how to make CGI scripts themselves safe. You should know a couple of important things, however, as an administrator.
A CGI script runs with the user ID of the server child process. In the default case, this is “nobody.” To adequately protect yourself, you may want to consider the “nobody” user an untrustworthy user on your site, making sure that this user doesn’t have read permission to files you want to keep private and doesn’t have write permission anywhere sensitive. Certain CGI scripts—for example, a guestbook application that allows users to record comments about your Web site—will demand write access to certain files. So if you want to enable those types of applications, it’s best to specify a directory to which CGI scripts can write without worrying about a malicious or misdirected script overwriting data that it shouldn’t.
Furthermore, site administrators can limit the use of CGI to specific directories by using the ScriptAlias directive. Alternatively, if you have turned on .cgi as a file extension for CGI scripts, you can use the Options ExecCGI directive in access.conf to further control the use of CGI files.
As an example of controlling access with ExecCGI, if you want to allow for CGI to be used everywhere on the site (with a document root of /home/htdocs) except for the “users” subdirectory because you don’t trust your users with CGI scripts, your access.conf should look something like Listing 37.1.
Listing 37.1 A Sample access.conf File Showing Directory Configuration Information
<Directory /home/htdocs/> Options Indexes FollowSymLinks Includes Multiviews ExecCGI AllowOverride None </Directory> <Directory /home/htdocs/users/> Options Indexes SymLinksIfOwnerMatch IncludesNOEXEC Multiviews AllowOverride None </Directory>
Because ExecCGI isn’t in the Options list for the second directory, no one can use CGI scripts there.
Unfortunately, there really is no middle ground between allowing CGI scripts and disallowing them. Now, most languages used for CGI programs don’t have security concepts built into them, so applying rules such as “don’t touch the hard disk” or “don’t send the /etc/passwd file in e-mail to an outside user” need to be dealt with in the same manner as though you had actual Linux users who needed the same restrictions applied to them. Maybe this will change when Sun’s Java language gets more use on the server side, or when people use raw interpreted languages less and higher-level programming tools more often.
As you can see from Listing 37.1, there was another change between the trusted part of the server and the untrusted part: the Includes argument to Options was changed to IncludesNOEXEC. IncludesNOEXEC allows your untrusted users to use server-side includes without allowing the #include of CGI scripts or the #exec command to be run. The #exec command is particularly troublesome in an untrusted environment because it basically gives shell-level access to an HTML author.
In an untrusted environment, UNIX symbolic links (which enable linking across file-system boundaries) also are a concern for Web site administrators. Malicious users could very easily create symbolic links from directories where they have write permission to an object or resource, even outside the document root, to which all they need is read permission. For example, a user could create a link to the /etc/passwd file and then release that onto the Web, exposing your site to potential crack attempts—particularly if your operating system doesn’t use shadow passwords.
NOTE: In a recent incident involving the Alta Vista search engine (www.altavista.digital.com), a search for words common to password files (bin, root, ftp, and so on) turned up references to actual password files that had, intentionally or not, been left public. These password files included a few with encrypted passwords, which were easy enough to break with a few hours of CPU time on most workstations.
To protect against symbolic link security breaches, the site administrator has two options: to allow only symbolic linking if the owner of the link and the owner of the linked-to resource are the same by using SymLinksIfOwnerMatch, or to disallow symbolic links altogether by not specifying FollowSymLinks or SymLinksIfOwnerMatch.
Also note that both <Directory> segments in Listing 37.1 included AllowOverride None. Not allowing symbolic links is the most conservative setting; if you want to allow certain things to be tunable in those directories by using .htaccess files, you can specify them with the AllowOverride directive. However, stating None is the safest policy.
| Previous | Table of Contents | Next |