The topics that follow have very little to do with Perl. They are included for the sake of completeness in this chapter.
Dont Run Unnecessary Daemons
If you're not going to be using a particular daemon, either from inetd or standalone, disable it; sendmail, tftp, systat, netstat, and any of the given r-servers, rexd, rquotad, and so on are possible candidates.
Sharing Documents Between Serversftpd and httpd
It's convenient, and often a requirement due to limited space, to serve the same hierarchy from httpd and ftpd. Some sites still run the gopherd as well, usually on the same files. Doing this is okay, as long as you take care not to allow uploaded files to be served from httpd as CGI programs. Be sure that if you do allow uploads via ftpd, the upload directory is completely hidden from httpd, using file permissions, ownership/uid, and access.conf configuration options.
Running httpd in the chroot(2)Environment
You can make significant progress toward a secure environment by running your httpd in a chroot'd environment. When you force a process to run chroot, it treats the hierarchy beneath the chroot'd directory as its entire filesystem and won't be able to access anything beneath it. This implies that the DocumentRoot must be set up as a complete, minimal filesystem, including shared libraries and possibly certain devices, to allow the httpd process to run. Implementing this is nontrivial. You should consult the documentation for your operating system to perform it correctly. If you're really worried about the security of the rest of your filesystem, however, it's a very reassuring alternative.
Privacy and Server Logs
While it may not be directly related to the security of your server, the privacy of those who access your site is something else to be mindful of and take steps to guard. If you use a commercial server, which also encrypts the logs, you're all set. Otherwise, be careful with the permissions on the logs directory, as previously mentioned. Also, find yourself a good log-analysis tool and use it frequently, then truncate the logfiles. It's inappropriate to use the logfiles for any purpose, other than overall traffic analysis, error-checking, and usage statistics in the overall sense.
Problems with Specific Servers
There are a number of server-specific issues that you may be affected by if you run any given server. These are, by nature, in constant flux, and it would be foolish to attempt to summarize them. The only way to keep track of these is to monitor the newsgroups, FAQs, and mailing lists related to the Web and specifically related to the server you choose to run. There are also general security groups and mailing lists that you can follow that deal with security issues in general. Please note, however, that these groups, and in fact most newsgroups, are not specifically intended for Web users' questions. Have a little netiquette and don't spam these groups with your questions. Take the time to read their FAQs and follow the discussion for a while before posting questions if appropriate.
Caution:
If you run your server under Windows NT, it's generally a very bad idea to place the perl.exe executable within the cgi-bin directory. Never, ever, do this under any architecture. No matter how frustrated you become with trying to figure out how to get the File Manager's associations to work with specific extensions, it's just not worth the risk. There has been a CERT announcement about this, too. For more information, see
ftp://ftp.cert.org/pub/cert_advisories/CA-96.//.interpreters_in_cgi_bin.