ApacheHTTP server usage ------ security tips

ApacheHTTP server usage ------ security tips-Linux Enterprise Application-Linux server application information. The following is a detailed description. Some tips and tips in this article are for the establishment of network servers, some are comprehensive, and others are for Apache.
Top
Continuous updates and upgrades

The Apache HTTP server has a good security record and a development community with high security concerns. However, this still cannot avoid problems that exist in the release. Therefore, it is essential to know the software version updates and upgrade patches. If you directly obtain the Apache HTTP server from the Apache organization, we strongly recommend that you subscribe to the Apache HTTP Server notification email list to ensure that the software version is updated and updated immediately. Many third-party Apache software releases have similar services.

Of course, most of the Web server problems are not caused by Apache source code, but by additional code, CGI scripts, and underlying operating systems. Therefore, you must keep all software updated on the machine in a timely manner.
Top
ServerRoot directory permission

Generally, Apache is started by the root User and switched to the User specified by the User command when providing services. As with any commands executed by the root user, you must ensure that the files under the ServerRoot user are 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

It is assumed that "/", "/usr", and "/usr/local" can only be rewritten by the root user. When installing the httpd executable file, make sure it is protected as well:

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

You can create an htdocs subdirectory in it, which allows other users to rewrite it. root does not execute any of the files, nor should it create files.

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 executable file, malicious code will be executed at the next startup. If the log directory (for non-root users) is writable, others may overwrite the log file by using a connection to other sensitive files, so that the file is rewritten to messy data. If the log file itself (for non-root users) is writable, others may forge the log.
Top
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. Use the "exe ccmd" element to allow SSI files to execute any CGI script 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 while obtaining SSI benefits.

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 .htmlor .htm files, especially in a shared or high-traffic server environment. The file of the acceptable ssishould have a unique suffix, such as regular .shtml, which keeps the server load at the lowest level and makes risk management easier.

Another solution is to disable the script and program execution function on the SSI page, that is, replace the program 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.
Top
About CGI

First, you have to trust the author of the CGI program and your ability to discover potential security vulnerabilities in CGI, whether they are premeditated or just unexpected. CGI scripts can execute arbitrary system commands allowed by web Server users. This may be extremely dangerous without careful check.

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 Apache1.2 and called by special hooks in Apache server code. Another common method is CGIWrap.
Top
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.

Top
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.
Top
Sources of other dynamic content

Embedded in Apache as a module-running script interpreter. For example, mod_php, mod_perl, mod_tcl, and mod_python will run in the same User identity as Apache (see User instructions ), therefore, scripts executed by these modules may access any objects that can be accessed by the Apache server. Some script engines may provide some restrictions, but it is best to provide security protection on the premise that they do not exist.
Top
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 by setting it in the server configuration file:


AllowOverride None


The. htaccess file is unavailable to all directories, except for directories that can be used.
Top
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 Access denied, The command may still 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
Top
Observe log files

To understand what happened on the server, you must check the log file. 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 it has reached the necessary security level.

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 contains the following records:

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