• Choose a category
• All
• Classic-Fiction

By Root 1947 0

of the web server. The intruders will have the same priveleges as in the user account. By having a separate account for the web server, we ensure the attackers do not get anything else free.

The most commonly used username for this account is httpd, and some people use apache. We will use the former. Your operating system may come pre-configured with an account for this purpose. If you like the name, use it; otherwise, delete it from the system (e.g., using the userdel tool) to avoid confusion later. To create a new account, execute the following two commands while running as root.

# groupadd httpd

# useradd httpd -g httpd -d /dev/null -s /sbin/nologin

These commands create a group and a user account, assigning the account the home directory /dev/null and the shell /sbin/nologin (effectively disabling login for the account). Add the following two lines to the Apache configuration file httpd.conf:

User httpd

Group httpd

Setting Apache Binary File Permissions

After creating the new user account your first impulse might be to assign ownership over the Apache installation to it. I see that often, but do not do it. For Apache to run on port 80, it must be started by the user root. Allowing any other account to have write access to the httpd binary would give that account privileges to execute anything as root.

This problem would occur, for example, if an attacker broke into the system. Working as the Apache user (httpd), he would be able to replace the httpd binary with something else and shut the web server down. The administrator, thinking the web server had crashed, would log in and attempt to start it again and would have fallen into the trap of executing a Trojan program.

That is why we make sure only root has write access:

# chown -R root:root /usr/local/apache

# chmod -R go-w /usr/local/apache

No reason exists why anyone else other than the root user should be able to read the Apache configuration or the logs:

# chmod -R go-r /usr/local/apache/conf

# chmod -R go-r /usr/local/apache/logs

Configuring Secure Defaults

Unless told otherwise, Apache will serve any file it can access. This is probably not what most people want; a configuration error could accidentally expose vital system files to anyone caring to look. To change this, we would deny access to the complete filesystem and then allow access to the document root only by placing the following directives in the httpd.conf configuration file:

Order Deny,Allow

Deny from all

Order Allow,Deny

Allow from all

Options directive

This sort of protection will not help with incorrectly or maliciously placed symbolic links that point outside the /var/www/htdocs web server root. System users could create s ymbolic links to resources they do not own. If someone creates such a link and the web server can read the resource, it will accept a request to serve the resource to the public. Symbolic link usage and other file access restrictions are controlled with the Options directive (inside a directive). The Options directive can have one or more of the following values:

All

All options listed below except MultiViews. This is the default setting.

None

None of the options will be enabled.

ExecCGI

Allows execution of CGI scripts.

FollowSymLinks

Allows symbolic links to be followed.

Includes

Allows server-side includes.

IncludesNOEXEC

Allows SSIs but not the exec command, which is used to execute external scripts. (This setting does not affect CGI script execution.)

Indexes

Allows the server to generate the list of files in a directory when a default index file is absent.

MultiViews

Allows content negotiation.

SymLinksIfOwnerMatch

Allows symbolic links to be followed if the owner of the link is the same as the owner of the file it points to.

The following configuration directive will disable symbolic link usage in Apache:

Options -FollowSymLinks

The minus sign before the option name instructs Apache to keep the existing