One important reason Apache occupies half of the Web server is that it can provide a secure Web operation environment. The Apache community has done a lot of work to ensure its security. When a security defect was discovered in this product, Apache developers developed a patch as soon as possible.
However, Apache is already a secure product. If you do not take any security precautions when building your server, such Web servers are still vulnerable to many attacks.
In this article, I will provide you with 10 tips to protect your Apache Web server from many attacks. However, remember that you need to evaluate every skill carefully to make sure it fits your organization.
Only install
One of the biggest features of Apache is its flexibility and a large number of optional installation modules, which can become a major weakness when it comes to security issues. The more you install, the larger the attack surface for potential attackers. A standard Apache installation contains more than 20 modules, including CGI features and some authentication mechanisms. If you do not plan to use CGI, and you only want to use static Web sites without user authentication, you may not need any services provided by these modules, therefore, disable these modules when installing Apache.
If you use a running Apache server and do not want to reinstall it, you should carefully check the httpd. conf configuration file to find the lines starting with LoadModule. Check Apache documents (or search by Google or Yahoo) to find the target information of each module and find out the modules you do not need. Then restart Apache.
Minimum exposure
Apache is easy to install and easy to manage. Unfortunately, many Apache installations provide too much "helpful" information about their servers for completely unfamiliar users, such as Apache version numbers and operating system-related information. With this information, a potential attacker can track specific destructive vulnerabilities that may affect your system, especially when you fail to update all patches. In this way, the attacker can know exactly what you are running without repeated tests, so as to adjust the attack method.
To prevent the server from broadcasting sensitive information, make sure that the "ServerSignature" command in httpd. conf is set to "off ". A default Apache installation sets this command to "off", but many administrators have enabled it.
Similarly, disabling directory browsing is also a good concern. When directory browsing is enabled, a user accessing a directory that does not contain the required documents will see the complete list of contents in this directory. Without a doubt, you should not store sensitive materials in plain text on a Web server. Unless you must do so, you should not allow people to see more content than they need.
Directory browsing is enabled by default. To disable this feature, edit the http. conf file and clear "Indexs" for each "Directory" command ".
For example, on the Apache 2.2.4 server used in my experiment, this is the default directory command:Copy codeThe Code is as follows: <Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow, deny
Allow from all
</Directory>
After Indexes is cleared, it looks like:Copy codeThe Code is as follows: <Directory "/usr/local/apache/htdocs">
Options FollowSymLinks
AllowOverrride None
Order allow, deny
Allow from all
</Directory>
You can also retain the Indexes command and use a broken number to guide the command to disable it (that is, "-Indexes ").
Disable symbolic Connection Tracing
If you are the only person who proofreads Web content and you create a new symbolic connection without making any mistakes, you may not worry about this measure. However, if you have a lot of people who can add content to your site, and not all people are as cautious as you are, there will be a risk, that is, a user may accidentally create a symbolic connection pointing to a part of your file system, and you really don't want people to see these files. For example, what if someone in the root directory of your Apache server creates a symbolic connection pointing to the "/" folder?
To cancel the request that the Apache server allows users to trace symbolic connections, clear the FollowSymlinks command in the Directory command.
For example, on the author's experimental Apache 2.2.4 server, the Directory command is as follows:Copy codeThe Code is as follows: <Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow, deny
Allow from all
</Directory>
After FollowSymLinks is cleared, it looks like the following:
Copy codeThe Code is as follows: <Directory "/usr/local/apache/htdocs">
Options Indexes
AllowOverrride None
Order allow, deny
Allow from all
</Directory>
If you need to track symbolic connections, you can use SymLinksIfOwnerMatch instead.
Listen command
When you first install Apache, httpd. conf contains a "Listen 80" command. Change it to "Listen mn. xx. yy. zz: 80". Here "mn. xx. yy. zz" is the IP address that you want Apache to Listen. This is especially important if your Apache runs on a server with multiple IP addresses. If you do not take preventive measures, the default "Listen 80" Command tells Apache to Listen to port 80 of each IP address.
However, this measure may not apply to your environment and should be tailored to your needs.
Clear default comments from httpd. conf
The default httpd. conf file in Apache 2.2.4 contains more than 400 lines. Only a small part of the 400 lines is the actual Apache commands, and the rest is only to help users properly place command comments in httpd. conf. Based on the author's experience, these annotations sometimes play a negative role, and even store Dangerous commands in files. On many Apache servers managed by the author, the httpd. conf file is copied to other files, such as httpd. conf. orig, and redundant comments are cleared completely. Files become easier to read, so as to better solve potential security problems or misconfigure files.
View the web server request file header before making any settings
HTTP/1.1 200 OK
Date: Sun, 27 Apr 2008 11:56:46 GMT
Server: Apache/2.2.8 (Unix) DAV/2 PHP/5.2.5 with Suhosin-Patch
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "387a5-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html
Almost all the details of the web server are exposed. If no version of apache or php has serious vulnerabilities, attackers will be given the most valuable security information, which is very dangerous.
Add two lines to the apache configuration file
ServerTokens ProductOnly
ServerSignature Off
Restart apache to make the settings take effect
Send an apache header message request again
HTTP/1.1 200 OK
Date: Sun, 27 Apr 2008 11:57:40 GMT
Server: Apache
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "387a5-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html
You can see that the apache version is no longer available.
To do this, we can also change the apache version, which requires modifying the apache source code, find ap_release.h in the apache source package and change # define AP_SERVER_BASEPRODUCT "Apache" to # define AP_SERVER_BASEPRODUCT "Microsoft-IIS/5.0"
Or # define AP_SERVER_BASEPRODUCT "Microsoft-IIS/6.0"
Find the OS. h file under OS/unix and change its # define PLATFORM "Unix" to # define PLATFORM "Win32"
Then re-compile and install apache.
Finally, modify the httpd. conf configuration file and add two lines of ServerTokens Prod.
ServerSignature Off
I don't need to talk about anything when sending a header request. Hey hey, this is a day-to-day steal. From this point, php is the same. You can also change some system information in this way, however, according to the open source spirit of GPL, it seems that this operation is not very good. You should retain the apache and php copyright information.
Appendix:
ServerSignature three options
On | Off | EMai mainly acts as a switch
Four ServerTokens options
Minimal | ProductOnly | OS | Full four options are added in sequence.
Next, configure the php configuration file php. ini.
Expose_php = On by default
Change it to expose_php = Off
Why? Please refer to this explanation.
; Decides whether PHP may expose the fact that it is installed on the server
; (E.g. by adding its signature to the Web server header). It is no security
; Threat in any way, but it makes it possible to determine whether you use PHP
; On your server or not.
Disable some functions related to php security.
Disable_functions = phpinfo, get_cmd_var // disable functions such as phpinfo and get_cmd_var.
Display_errors = Off // Disable Error
Allow_url_fopen = Off // There is no way to retrieve the remote content, but you can use a work und to achieve this by using curl remote reading.
Safe_mode = On // enable the security mode. If this mode is enabled, some php functions may be unavailable.
In any case, we still need to perfect our program design. In general, it is more difficult to simply attack the system. If the program has a vulnerability, the attack will be simple.