46.6. Security

A Web server exposed to the public Internet requires an ongoing administrative effort. It is inevitable that security issues appear, both related to the software and to accidental misconfiguration. Here are some tips for how to deal with them.

Staying Up to Date

In case there are vulnerabilities found in the Apache software, a security advisory will be issued by SUSE. It contains instructions for fixing the vulnerabilities, which in turn should be applied soon as possible. The SUSE security announcement mailing list is available at http://www.suse.com/us/private/support/online_help/mailinglists/. The latest information about security issues for the SUSE Linux packages are also available online at http://www.novell.com/linux/security/securitysupport.html.

Additionally, you should subscribe to the Apache announcement mailing list (http://httpd.apache.org/lists.html#http-announce where new releases and bug fixes are posted.

DocumentRoot Permissions

By default in SUSE Linux, the DocumentRoot directory /srv/www/htdocs and the CGI directory /srv/www/cgi-bin belong to the user root. You should not change these permissions. If the directories were writable for all, any user could place files into them. These files might then be executed by Apache with the permissions of wwwrun which may give the user unintended access to file system resources. Use subdirectories of /srv/www/htdocs and /srv/www/cgi-bin to organize user or domain-specific data in combination with the Directory directive (see Directory).

CGI and SSI Directories

Interactive scripts in Perl, PHP, SSI or any other programming language can essentially run arbitrary commands. Limiting the execution of CGIs and SSIs (see Section 46.5.1.2, “Common Gateway Interface: mod_cgi, Script Alias, and Section 46.5.1.1, “Server-Side Includes with mod_include) to specific directories instead of globally allowing them is one option for decreasing the risk.

Another possibility is to work with mod_suexec (see Section 46.5.2.1, “Running CGIs as a Different User with mod_suexec) for CGIs in general. For Apache modules, a security-concious configuration for the interpreters, such as in Section 46.5.3.2, “Serving PHP: mod_php4, mod_php5, helps to keep the Web environment safe.

Access Permissions

Often times, especially in test environments, access permissions to a Web server are handled casually because of the nature of testing a setup. This may result in accidentally revealing sensitive information or even exposing an entire server to the wrong audience. Use the Order directive (http://httpd.apache.org/docs-2.0/mod/mod_access.html#order) in combination with .htaccess files (see Section 46.3.2.3.3, “AccessFileName filenames) to allow access to certain Web sites only for specific users or clients.

Additionally, you could use the “security by obfuscation” approach: a typical example for this is to run Apache on a nonstandard port (see Network Device Selection). This results in URLs with the port appended, such as http://www.example.com:8765, which is acceptable in test environments.