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.
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.
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).
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.
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.