Linux Server Security (2)-Apache

Generally, Apache is started by the root user and switched to the user specified by the USER command when providing services. As with any command executed by root, you must note that it is protected and cannot be modified by non-root users. Not only the file itself, but also the Directory and its parent directory must be rewritten by the root. For example, if you specify serverroot as/usr/local/Apache, we recommend that you create this directory as root, for example:

Mkdir/usr/local/Apache
CD/usr/local/Apache
Mkdir bin conf logs
Chown 0. Bin conf logs
Chgrp 0. Bin conf logs
Chmod 755. Bin conf logs

Here we have assumed that/,/usr, and/usr/local can only be rewritten by root. When installing the httpd execution file, make sure it is protected as follows:

CP httpd/usr/local/Apache/bin
Chown 0/usr/local/Apache/bin/httpd
Chgrp 0/usr/local/Apache/bin/httpd
Chmod 511/usr/local/Apache/bin/httpd

The htdocs sub-directory allows other users to rewrite it-because root will never execute any of the files, and should not create files in it.

If a non-root user is allowed to have write permissions on the files executed or read and written by the root user, the system is compromised. For example, if someone else may overwrite the httpd execution file, any code will be executed at the next startup. If the log directory (for a non-Root User) is writable, others may use a connection pointing to other system files to overwrite the log files, rewrite the file to messy data. If the log file itself is writable, others may forge its records.

Server includes

Server inclusion (SSI) brings some potential security risks.

The first step is to increase the server load. Apache must parse all files that allow SSI, regardless of whether the file contains the SSI command. Although the increased load is small, it will become significant in the shared server environment.

SSI files are at the same risk as CGI scripts. "Exec cmd" is used to allow SSI files to execute any CGI scripts and any programs allowed by users or groups that execute Apache set by httpd. conf.

There are several ways to improve the security of SSI files at the same time.

The server administrator can use suexec described in CGI to isolate the damage caused by the brutal SSI File.

It is dangerous to allow SSI for all files with the extension of .htmlor .htm, especially in a shared high-traffic server environment. The ssi's file should have an independent suffix, such as regular .shtml, which keeps the server load at the lowest level and makes risk management easier.

The other solution is to disable the script and program execution functions on the SSI page, that is, replace DES with IncludesNOEXEC In the Options command. Note that you can still use> -- # include virtual = "..." -- <to execute CGI scripts in the directory specified by the ScriptAlias command.

CGI

First, you have to trust the authors of CGI scripts/programs and your ability to discover potential security vulnerabilities in CGI, whether they are premeditated or unexpected. CGI scripts can execute arbitrary system commands that are allowed to be executed by the network server. This may be extremely dangerous without careful checks.

Since all CGI scripts are executed in the same identity, they may conflict with other scripts (intentionally or unintentionally. For example, user a hates user B, so he may write a script to destroy user B's database. Suexec is a program that allows scripts to run in different identities. It is included in Versions later than Apache 1.2 and called by special hook programs in Apache server code. Another common method is to use cgiwrap.

CGI not specified as script

You can only allow the user to execute CGI scripts in any directory in the following circumstances:

You absolutely trust users not to write scripts that intentionally or unintentionally attack the system.
You think security factors are less important than other factors, and the existence of one or two potential vulnerabilities does not matter.
You have no users and no one will access your server.

CGI specified as the script
Place CGI in a specific directory and the Administrator determines the content. This is definitely safer than using CGI that is not used as a script, unless the user with write permission on these directories is trusted, or the administrator wants to test the potential security vulnerabilities of each CGI script/program.

Most sites choose this scheme instead of using CGI that is not specified as a script.

Protection set by the System

To ensure real and strict protection, users should be prohibited from using the. htaccess file that may cause security features to be overwritten:

In the server configuration file, Set

AllowOverride none

The. htaccess file is unavailable to all directories, except for directories that can be used.

Protect server files by default

Default access is one of the Apache features that are occasionally misunderstood. That is, unless you take measures, if the server can find a file through the standard URL ing rule, it may be provided to the client.

For example:

# Cd/; Ln-S/public_html
Accessing http: // localhost /~ Root/

It allows the client to traverse the entire file system. The solution is to add the following commands in the Server Configuration:

Order deny, allow
Deny from all

In this way, the default access to the file system is disabled. The correct directory block can be added to the region to be accessed, for example:

Order deny, allow
Allow from all

Order deny, allow
Allow from all

Pay special attention to the interaction between location and directory commands. For example, even if access is denied, the command may overwrite its settings.

You must also pay attention to the userdir command. If this setting is similar to "./", it is at the same risk as the preceding example. If you are using version 1.3 or later, we strongly recommend that you include the following commands in the server configuration file:

Userdir disabled Root

Observe log files

To understand what happened on the server, you must check log files. although the log file only records events that have occurred, it will let you know the attacks on the server and help you determine whether a required security level is provided.

Some examples:

Grep-c "/JSP/source. jsp? /Jsp // JSP/source. jsp ?? "Access_log
Grep "client denied" error_log | tail-N 10

The previous meeting will list the number of attacks that attempt to use Apache Tomcat source. jsp Malformed Request Information Disclosure Vulnerability. The next meeting will list the last 10 rejected clients:

[Thu Jul 11 17:18:39 2002] [Error] [client foo.bar.com] client denied by server configuration:/usr/local/Apache/htdocs/. htpasswd

It can be seen that the log file only records the events that have occurred. Therefore, if the client can access the. htpasswd file, and the access log finds a record similar to the following:

Foo.bar.com--[12/JUL/2002: 01: 59: 13 + 0200] "Get/. htpasswd HTTP/1.1"

This may indicate that the following commands in the server configuration file have been annotated:

Order allow, deny
Deny from all