Publicly Writable Spaces

The last security threat that’s specific to Web servers is that of allowing publicly writable spaces to be served up via HTTP. For example, many sites allow their FTP “incoming” directory to be accessed via the Web directly. This can be a security hole if someone were to place there a malicious CGI script or a server-side include file that calls #exec to do some damage. If you decide you need to take the risk of providing public writable spaces, you can do some things to protect yourself:

•  The most conservative setting you should set for the Options directive is this:

Options Indexes

You could use None, but Indexes really doesn’t introduce any additional security problems, as long as you’re comfortable with others being able to download anything that has been submitted. In the light of recent legislation by the U.S. government regarding “indecent” materials, you may not want to take this risk either.

•  Make sure that you set AllowOverride None so that people can’t upload an .htaccess file into your directory and modify all your settings and security policies.

•  Make sure that the FTP daemon you’re using doesn’t allow the execute bit to be set. By preventing the execute bit to be set, you prevent the execution of uploaded CGI scripts. If you’re using XBitHack to activate your server-side includes, you can prevent those includes from being run as well. This is mainly a backup for setting the Options as in Listing 37.1, which should protect you against these threats anyway.

These same rules apply if you have CGI scripts that generate their own uniquely addressable HTML or CGI files. For example, if the guestbook.cgi program constantly appends the submitted personal information to a guestbook.html file, all the same rules apply; the contents of that HTML file must be considered unsafe. This possible security breach can be plugged if the CGI script double-checks what’s getting written and removes “dangerous” code, such as server-side includes.

Other Tuning Issues

The Apache Web server is optimized for accuracy more than for speed; as one rule of thumb for gunfighting goes, “You can’t miss faster than the other person can hit.” Also, performance is rarely an issue, because any half-decent Web server can saturate a T1 line without trying very hard.

For those interested in getting every last bit of performance from a server, whether you’re running CNN’s Web site or simply trying to run Apache on hardware that can’t possibly fill the available bandwidth (such as trying to run an intranet Web server with 10Mbps Ethernet on the spare 386DX40 you found in the office closet), you can make certain tweaks that will improve responsiveness. For cheap improvements, the most important issue for any Web server is RAM. A Web server takes such a performance hit if it has to swap memory out to disk that it should be avoided at all possible costs. One way to avoid swapping is to limit the MaxClients setting to stay within the available RAM. The best source of performance tuning information is located on the Web at http://www.apache.org/docs/misc/perf-tuning.html.

From Here…

You can learn more details about setting up, configuring, and running the Apache Web server in Chapter 35, “Getting Started with Apache.” That chapter provides a detailed introduction to the Apache Web server.