Key Points of enterprise-level Apache server security protection

Apache has always been the top three Web server software in the world. Enterprises need to comprehensively consider the security of their Web applications to ensure they can respond to network threats such as denial of service (DoS) attacks, traffic eavesdropping, and data leakage, this ensures the security of enterprise portal websites.
In addition to the industry's popular firewalls, IDS/IPS (Intrusion Detection Systems/intrusion defense systems), WAF (Web application firewall), and UTM (Unified Threat Management) as an excellent open-source server software, Apache itself has many outstanding features that can provide security configurations for server administrators, to prevent various network attacks. Therefore, fully and efficiently exploring the security capabilities of Apache servers is also an essential skill for enterprise security workers. Based on this, this article will detail the security protection points of Apache servers from four aspects.
Policy 1: server-side Security Settings
1. Restrict the root user to run the Apache server
Generally, the root permission is required to start the httpd process of the Apache server in Linux. As root permissions are too large, there are many potential security threats. For the sake of security, some administrators believe that the httpd server cannot have no security vulnerabilities, so they prefer to use the permissions of common users to start the server. Http. the conf main configuration file contains the following two configurations: Apache security guarantee. After Apache is started, it sets itself as the user and group permissions set for these two options to run, reduces the risk of servers.
User apache
Group apache
Note that the above two configurations are the default options in the master configuration file. After the httpd process is run as the root user, the system automatically changes the user group and permissions of the process to apache, so that the permissions of the httpd process are restricted to apache users and groups, thus ensuring security.
2. Hide Apache server information from the client
The version number of the Apache server can be used as an important information for hacker intrusion. After obtaining the version number, they can search for vulnerabilities on the server, therefore, targeted intrusion using corresponding technologies and tools is also a key step in penetration testing. Therefore, to avoid unnecessary troubles and security risks, you can use the following two options in the main configuration file httpd. conf:
(1) ServerTokens: This option is used to control whether the server responds to requests from the client and outputs important information such as the server system type or the corresponding built-in module to the client. The Red Hat Enterprise Linux 5 Operating System provides a global default control threshold of OS in the master configuration file, that is, ServerTokens OS. They expose the operating system information and related sensitive information to the client. Therefore, to ensure security, you must use "ProductOnly" after this option, that is, "ServerTokens ProductOnly.
(2) ServerSignature: This option controls the pages (error messages, etc.) generated by the system ). The default value is off, that is, ServerSignature off. In this case, no page information is output. The other case is on, that is, ServerSignature on. In this case, a line of information about the version number is output. Set the security status to off.
Figure 1 and figure 2 Compare the output pages in normal and error situations before and after setting these two options for security (access to the Apache server in Rhel5 through the Mozilla Firefox browser in Rhel5. You can clearly see that after security settings, you can fully hide the Linux operating system information and Apache server version information from the client users.

 
Figure 1 indicating that security options are not set in case of an error


 
Figure 2 Comparison of Security Settings
3. Set virtual directory and Directory Permissions
To publish from a directory other than the home directory, you must create a virtual directory. The virtual directory is a directory located outside the Apache main directory. It is not included in the Apache main directory, but it is the same as the sub-directory in the main directory for users who visit the Web site. Each virtual directory has an alias. You can use this alias in your Web browser to access the virtual directory, such as http: // server IP Address/alias/file name, you can access any files in the virtual directory.
You can use the Alias option to create a virtual directory. In the main configuration file, Apache has created two virtual directories by default. These two statements create two virtual directories: "/icons/" and "/manual, their physical paths are "/var/www/icons/" and "/var/www/manual ". In the main configuration file, you can see the following configuration statement:
Alias/icons/"/var/www/icons /"
Alias/manual "/var/www/manual"
You can create a virtual directory by yourself. For example, to create a virtual directory named/user, the corresponding path is/var/www/html/rhel5 commonly used in the above examples:
Alias/test "/var/www/html/rhel5"
To set permissions for www.2cto.com, you can add the following statement:
<Directory "/var/www/html/rhel5">
AllowOverride None
Options Indexes
Order allow, deny
Allow from all
</Directory>
After setting the virtual directory and directory permissions, you can use the client browser for test and verification, and use an alias to access the files in the directory. view result 3.

 
Figure 3 test results using virtual directories
Policy 2: restrict the running environment of the Apache service
The Apache server needs to be bound to port 80 to listen for requests, while the root server is the only user with such permissions. As the attack methods and intensity increase, the server is under considerable threat, once the buffer overflow vulnerability is exploited, the entire system can be controlled. To further improve system security, the Linux kernel introduces the chroot mechanism, which is a system call in the kernel. The software can call the chroot function of the function library to change the root directory that a process can see.
The chroot mechanism is to restrict the running of a software in a specified directory, so that the software can only take actions on the files in the directory and Its subdirectories, thus ensuring the security of the entire server. In this case, even if hackers or illegal users use the software to damage or intrude into the system, the damage to the Linux system is limited to the root directory of the Set, without affecting other parts of the system.
One problem with chroot software is that all programs, configuration files, and library files required for running the software must be installed in the chroot directory in advance, this directory is usually called "chroot ". If you run httpd in "prison", you cannot see the real directory in the Linux File System, thus ensuring the security of the Linux system.
When using this technology, you usually need to create a directory in advance and copy the executable file httpd of the daemon to it. At the same time, because httpd requires several library files, it is very troublesome to manually complete the work because several lib files on which the httpd program depends must be copied to the same directory at the same time. Fortunately, you can use the open-source jail software package to simplify the chroot "prison" establishment process. The specific steps are as follows:
The official Jail website is http://www.jmcresearch.com/projects /. First download the package, and then execute the following command to compile and install the source code package:
# Tar xzvf jail_1.9a.tar.gz
# Cd jail/src
# Make
The jail package provides several Perl scripts as its core commands, including mkjailenv, addjailuser, and addjailsw, which are located in the decompressed directory jail/bin. The basic usage of these commands is as follows:
Mkjailenv: used to create the chroot "prison" directory and copy the basic software environment from the real file system.
Addjailsw: used to copy binary executable files and other related files (including library files, auxiliary files, and Device Files) from a real file system to the "prison.
Addjailuser: Create a New chroot "prison" user.
The steps for creating a prison using jail are as follows;
(1) first, stop the currently running httpd service and create the chroot directory. The command is as follows. This command creates the chroot directory under the path/root/chroot/httpd:
# Service httpd stop
# Mkjailenv/root/chroot/httpd
Kjailenv
A component of Jail (version 1.9 for linux)
Http://www.gsyc.inf.uc3m.es /~ Assman/jail/
Juan M. Casillas <assman@gsyc.inf.uc3m.es>
Making chrooted environment into/root/chroot/httpd
Doing preinstall ()
Doing special_devices ()
Doing gen_template_password ()
Doing postinstall ()
Done.
(2) Add AN httpd program for "prison". The command is as follows:
#./Addjailsw/root/chroot/httpd/-P/usr/sbin/httpd
Addjailsw
A component of Jail (version 1.9 for linux)
Http://www.gsyc.inf.uc3m.es /~ Assman/jail/
Juan M. Casillas <assman@gsyc.inf.uc3m.es>
Guessing/usr/sbin/httpd args (0)
Warning: can't create/proc/mounts from the/proc filesystem
Done.
In the above process, the user does not need to care about the warning information, because jail will call ldd to check the library files used by httpd. Almost all binary executable files based on the shared library need the above library files.
(3) then copy the httpd-related files to the "prison" directory. The command is as follows:
# Mkdir-p/root/chroot/httpd/etc
# Cp-a/etc/httpd/root/chroot/httpd/etc/
......
The added directory structure is as follows:
# Ll
Total 56
Drwxr-xr-x 2 root 4096 03-23 dev
Drwxr-xr-x 3 root 4096 03-23 etc
Drwxr-xr-x 2 root 4096 03-23 lib
Drwxr-xr-x 2 root 4096 03-23 selinux
Drwsrwxrwx 2 root 4096 03-23 13:46 tmp
Drwxr-xr-x 4 root 4096 03-23 usr
Drwxr-xr-x 3 root 4096 03-23 var
(4) Restart httpd and run the ps command to check the httpd process. It is found that the process is running in prison, as shown below:
# Ps-aux | grep httpd
Warning: bad syntax, perhaps a bogu '-'? See/usr/share/doc/procps-3.2.7/FAQ
Root 3546 0.6 0.3 3828 1712 pts/2 S/usr/sbin/nss_pcache off/etc/httpd/alias
Root 3550 14.2 3.6 49388 17788? Rsl/root/chroot/httpd
Apache 3559 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3560 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3561 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3562 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3563 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3564 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3565 0.2 1.4 49388 6888? S/root/chroot/httpd
Apache 3566 0.2 1.4 49388 6888? S/root/chroot/httpd
R oot 3568 0.0 0.1 4124 668 pts/2 R + grep httpd Policy 3: Enable Apache built-in security module Protection
One of the advantages of Apache is its flexible module structure, which is also designed around the concept of module. The security module is an extremely important component of Apache Server. These security modules provide access control, authentication, authorization, and other critical security services for the Apache server.
Apache has the following security-related modules:
The mod_access module can control access to the Apache server based on the visitor's IP address (or domain name, host name, etc.), which is called Host-Based Access Control.
The mod_auth module is used to control Authentication for users and groups ). The username and password are stored in plain text files.
The mod_auth_db and mod_auth_dbm modules store user information (such as name, group owner, and password) in the Berkeley-DB and DBM small databases, facilitating management and improving application efficiency.
The mod_auth_digest module uses the MD5 digital signature method for user authentication, but it must be supported by the client.
The functions of the mod_auth_anon module are similar to those of mod_auth, except that it allows anonymous logon and uses the user-entered email address as the password.
Mod_ssl is used by Apache to support Secure Sockets Layer Protocol and provide secure transaction services on the Internet, such as a security measure in e-commerce. The communication byte stream is encrypted to prevent leakage of sensitive information. However, Apache is implemented based on API extensions of Apache. It is equivalent to an external module that provides secure online transaction support by combining with a third-party program (such as openssl.
In order to be able to use the module functions, the module is usually constructed in the form of DSO (Dynamic Shared Object), and the user should be in httpd. use the LoadModule command in the conf file to obtain the functions of the module before use. The following is the situation of each module in the main configuration file. It is very easy to enable the Security Module, that is, remove the "#" symbol before the line of each security module, as shown below:
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_alias_module modules/mod_authn_alias.so
......
Apache can implement access control and communication encryption functions only after the preceding security module is enabled.
Policy 4: Access Control Policy Settings
After the corresponding security module is enabled, you also need to set the access control policy for Apache.
1. authentication and authorization commands
Currently, there are two common authentication types: Basic Authentication and digest authentication:
(1) Basic Authentication: use the most Basic username and password for user authentication.
(2) Digest authentication (Digest): This authentication method is much safer than basic authentication, and a challenge information is used in the authentication process, this effectively avoids "replay attacks" that may be encountered by basic authentication methods ". Note that not all browsers currently support digest authentication.
All authentication configuration commands can appear either in the Directory container in the main configuration file httpd. conf or in a separate. htaccess file, which can be flexibly selected by users. The following command is required during authentication Configuration:
AuthName: used to define the name of the protected region.
AuthType: used to specify the authentication method used, including the Basic and Digest methods described above.
AuthGroupFile: used to specify the location of the authentication group file.
AuthUserFile: Specifies the location of the authentication password file.
After configuring authentication using the preceding authentication commands, You need to authorize the Access Object of the Apache server, that is, the specified user and group, this allows them to access the directories and files provided by the Apache server. To authorize users and groups, you must use the Require command. You can use the following three methods for authorization:
Grant permissions to one or more specified users: Use Require user username 1 username 2 ....
Grant permissions to one or more groups: Use Require group username 1 username 2 ....
Grant permissions to all users in the specified password file: Use Require valid-user.
2. Manage authentication password files and authentication group files
To implement the user authentication function, you must first create a file to save the user name and password. The htpasswd Command provided by Apache provides the ability to create and update text files that store user names and passwords. Note that this file must be placed in a location that cannot be accessed by the network to avoid downloading and information leakage. We recommend that you store the password file in the/etc/httpd/directory or its subdirectory.
The following example creates a password file named passwd_auth under the/etc/httpd directory and adds the user rhel5 to the authentication password file. Run the following command to create a password file (the user's password will be prompted during the process ):
# Touch passwd_auth
# Htpasswd-c/etc/httpd/passwd_auth rhel5
New password:
Re-type new password:
Adding password for user rhel5
During command execution, the user is required to enter the password for rhel5. The-c option in the above command indicates that the file will be re-written and the original content will be deleted no matter whether the password file already exists. Therefore, when adding 2nd users to the password file, you do not need to use the-c option, as shown in the following command:
# Htpasswd/etc/httpd/passwd_auth testuser
3. authentication and authorization for instances
(1) Configure user authentication and authorization using the main configuration file
In this example, you can add the following statement to the main configuration file httpd. conf of Apache to establish a user authentication and authorization mechanism for/var/www/html/rhel5 access:
<Directory "/var/www/html/rhel5">
AllowOverride None
AuthType Basic
AuthName "rhel5"
AuthUserFile/etc/httpd/passwd_auth
Require user rhel5 testuser
</Directory>
In the preceding example, the following command is used:
AllowOverride: This option defines that the. htaccess file is not used.
AuthType Basic: The AuthType option defines the authentication type for users. The most common is the Basic provided by mod_auth.
AuthName: defines the domain content when the Web browser displays the input user/Password dialog box.
AuthUserFile: defines the path of the password file, that is, the password file created using htpasswd.
Require user: defines which users are allowed to access the database. Separate the users with spaces.
Note: In the AuthUserFile option definition, you also need to use the following statement to establish the authenticated user patterson and testuser in advance. The definition in this option takes effect:
# Htpasswd-c/etc/httpd/passwd_auth rhel5
# Htpasswd/etc/httpd/passwd_auth testuser
(2) Use the. htaccess file to configure user authentication and authorization
In this example, the following statement must be added to the main configuration file to implement the same functions as in the preceding example:
<Directory "/var/www/html/rhel5">
AllowOverride AuthConfig
</Directory>
The AllowOverride option in the preceding statement allows authentication and authorization commands in the. htaccess file.
Then, add the following statement to the. htaccess file:
AuthType Basic
AuthName "Please Login :"
AuthUserFile/etc/httpd/passwd_auth
Require user rhel5 testuser
Similarly, in the AuthUserFile option definition, you also need to use the following statement to establish the authenticated user patterson and testuser in advance, and the definition in this option can take effect:
# Htpasswd-c/etc/httpd/passwd_auth rhel5
# Htpasswd/etc/httpd/passwd_auth testuser