ServerBuddies Support Blog

Protecting System Settings in Apache

To run a really tight ship, you’ll want to stop users from setting up .htaccess files which can override security features you’ve configured. Here’s one way to do it.

In the server configuration.

This prevents the use of .htaccess files in all directories apart from those specifically enabled.

What is suEXEC?

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Presently, suEXEC does not allow ‘root’ to execute CGI/SSI programs.

Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

Enabling & Disabling suEXEC

Upon startup of Apache, it looks for the file “suexec” in the “sbin” directory (default is “/usr/local/apache/sbin/suexec”). If Apache finds a properly configured suEXEC wrapper, it will print the following message to the error log:

If you don’t see this message at server startup, the server is most likely not finding the wrapper program where it expects it, or the executable is not installed setuid root.

If you want to enable the suEXEC mechanism for the first time and an Apache server is already running you must kill and restart Apache. Restarting it with a simple HUP or USR1 signal will not be enough.

If you want to disable suEXEC you should kill and restart Apache after you have removed the “suexec” file.

Server Side Includes

Server Side Includes (SSI) present a server administrator with several potential security risks.

There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide.

To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec.

Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

SSI files also pose the same risks that are associated with CGI scripts in general. Using the “exec cmd” element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf.

The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant.

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Permissions on Apache ServerRoot Directories

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises.

For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

If you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected