One important reason for Apache to occupy half of the Web server is that it provides a secure web operating environment. The Apache community has done a lot to ensure its security. When the product was found to have a security flaw, Apache developers quickly made a patch.
However, the Web server is still vulnerable to a lot of attacks if you don't take some security precautions when you build your server, which is a safe product for Apache.
In this article, the author will provide you with 10 tips to protect your Apache Web server from many attacks. However, it must be remembered that you need to carefully evaluate every skill to ensure that it fits your organization.
Install only the required
One of the biggest features of Apache is its flexibility and a large number of optional installation modules, which can be a great weakness when it comes to security issues. The more you install, the larger the attack surface is created for potential attackers. A standard Apache installation consists of more than 20 modules, including CGI features, as well as some authentication mechanisms. If you're not going to use CGI and you just want to use a static web site that doesn't require user authentication, you may not need any of the services provided by these modules, so disable these modules when you install Apache.
If you follow a running Apache server and do not want to reinstall it, you should carefully examine the httpd.conf configuration file and look for rows that begin with LoadModule. Check the Apache documentation (Google, Yahoo, etc.) to find the purpose of each module and find out what modules you don't need. Then, restart Apache.
Minimization of exposure level
Apache is easy to install and is fairly easy to manage. Unfortunately, many Apache installations offer too many "helpful" information about their servers for complete strangers, such as the version number of Apache and the information associated with the operating system. With this information, a potential attacker can track specific destructive vulnerabilities that can affect your system, especially if you are not able to keep all patches updated. In this way, an attacker can know exactly what you are running without having to experiment repeatedly to adjust its attack methods.
To prevent the server from broadcasting sensitive information, be sure to set the "serversignature" directive in httpd.conf to "off". A default Apache installation will set this directive to off, but many administrators have enabled it.
Similarly, disabling directory browsing is also a good idea. When directory browsing is enabled, users who access a directory that does not contain the documents they need will see a complete list of the contents in this directory. There is no doubt that you should not store sensitive materials in plain text on a Web server unless you have to do so and you should not allow people to see more than they need.
Directory browsing is enabled by default. To disable this feature, edit the http.conf file and clear "Indexs" for each "Directory" directive.
For example, on the author's experiment with the Apache 2.2.4 Server, this is the default directory command:
Copy Code code as follows:
<directory "/usr/local/apache/htdocs" >
Options Indexes FollowSymLinks
Allowoverrride None
Order Allow,deny
Allow from all
</Directory>
Clear the appearance after indexes:
Copy Code code as follows:
<directory "/usr/local/apache/htdocs" >
Options FollowSymLinks
Allowoverrride None
Order Allow,deny
Allow from all
</Directory>
You can also disable this instruction (i.e. "-indexes") by keeping the Indexes instruction and booting with a dash.
Disable symbolic Connection Tracking
If you're the only person to proofread Web content, and you're making little mistakes when creating new symbolic connections, you may not be worried about this measure. However, if you have a lot of people who can add content to your site, not all people are as cautious as you are, and there is a risk that a user might accidentally create a symbolic connection to a part of your filesystem, and you really don't want people to see those files. For example, if someone in your Apache server's root directory creates a symbolic connection to a "/" folder, what should you do?
To remove requests from the Apache server to allow users to track symbolic connections, you should clear the FollowSymLinks directive in the Directory command.
For example, in the author's experimental Apache 2.2.4 Server, the directory commands are as follows:
Copy Code code as follows:
<directory "/usr/local/apache/htdocs" >
Options Indexes FollowSymLinks
Allowoverrride None
Order Allow,deny
Allow from all
</Directory>
After the followsymlinks is cleared, it becomes the following:
Copy Code code as follows:
<directory "/usr/local/apache/htdocs" >
Options Indexes
Allowoverrride None
Order Allow,deny
Allow from all
</Directory>
If some users need to be able to track symbolic connections, consider using SymLinksIfOwnerMatch instead.
Listen instruction Materialization
When you first install Apache, httpd.conf contains a "Listen 80" instruction. It should be changed to "Listen mn.xx.yy.zz:80", where "Mn.xx.yy.zz" is the IP address you want Apache to listen to for its request. This is especially important if your Apache is running on a server that has multiple IP addresses. If you do not take precautions, the default "Listen 80" command tells Apache to listen for 80 ports per IP address.
However, this measure may not apply to your environment, depending on your needs.
Clear the default annotation from the httpd.conf
The default httpd.conf file in Apache 2.2.4 has more than 400 lines. Of these 400 lines, only a small portion is the actual Apache instruction, and the rest is only a comment that helps the user properly place instructions in the httpd.conf. According to the author's experience, these annotations sometimes play a negative role, and even the dangerous instructions are retained in the file. The author copies the httpd.conf files into other files, such as Httpd.conf.orig, on many of the Apache servers administered, and then completely clears the redundant annotations. Files become easier to read, which can better address potential security issues or incorrectly configure files.
View Web server request headers before making any settings
http/1.1 OK
Date:sun, APR 2008 11:56:46 GMT
server:apache/2.2.8 (Unix) DAV/2 php/5.2.5 with Suhosin-patch
Last-modified:sat, Nov 20:16:24 GMT
ETag: "387a5-2c-3e9564c23b600"
Accept-ranges:bytes
Content-length:44
Content-type:text/html
Almost all of the details of the Web server burst out, if no version of Apache and PHP out of serious vulnerabilities, it will provide the attacker with the most valuable security information, this is very dangerous
Add two lines to the Apache configuration file
Servertokens productonly
Serversignature off
Restart Apache for settings to take effect
Re-issue Apache header information Request
http/1.1 OK
Date:sun, APR 2008 11:57:40 GMT
Server:apache
Last-modified:sat, Nov 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 number is gone.
To do this, we can also change the version of Apache, this will modify the Apache source code, in the Apache Source pack found Ap_release.h will #define AP_SERVER_BASEPRODUCT "Apache" modified to # Define AP_SERVER_BASEPRODUCT "microsoft-iis/5.0"
or #define AP_SERVER_BASEPRODUCT "microsoft-iis/6.0."
Then locate the Os.h file under Os/unix and modify its #define PLATFORM "Unix" to #define PLATFORM "Win32"
Then recompile and install Apache.
Finally, modify the httpd.conf configuration file and add two lines Servertokens Prod
Serversignature off
At the Send header request, what will be, I don't have to say it, hey, this is called steal, from this point, PHP is the same, can also change some system information in this way, but according to the spirit of the GPL open source, this does not seem very good, or keep the Apache and PHP copyright information.
Report:
Serversignature three options
on| Off| Emai mainly plays the role of switch
Servertokens four options
minimal| productonly| os| Full four options hidden information increased in turn
Configure the PHP configuration file php.ini below
By default expose_php = On
Change it to expose_php = off
Why, you can see the explanation.
; Decides whether PHP may expose the fact, it is installed on the server
; (e.g. by adding it signature to the WEB server header). It is no security
; Threat in no way, but it makes it possible to determine whether your use PHP
; On your server or not.
And then disable some functions that involve PHP security
Disable_functions = Phpinfo, Get_cfg_var//forbidden functions such as phpinfo and Get_cfg_var
Display_errors = off//prohibit burst of error
Allow_url_fopen = off//This shutdown, there is no way to take the remote content, but can be used flexibly, curl remote reading method to do
Safe_mode = ON//Open Safe mode, this is open, there may be some PHP features can not be used
In any case, still want our program design perfect, generally speaking, simple more to system attack is very difficult, if is the procedure has the flaw, that attack is simple.
