How can we enhance the security of Apache Web servers?

 

Installing and maintaining secure Web servers on Linux is not easy. This requires an in-depth understanding of Linux, Apache, and PHP server options. One of the main problems is how to strike a balance between security, productivity, and usability. The best solution depends on the specific needs of the project, but all the servers installed have some common characteristics. The following are some best practices to protect the LAMP server, covering many aspects from server configuration to PHP configuration fine-tuning.

 

To protect Web servers, reinforce the Linux operating system. The topic of Linux reinforcement can write a whole article, but some concepts are particularly important in providing Web content:

 

◆ Linux kernel reinforcement. The kernel is the target most often targeted by attackers. To improve user permissions, it is the easiest way to gain access to the kernel. Depending on the operating system, by default, Apache uses a limited user nobody (on Red Hat-based releases such as CentOS) or www-data users (On Debian-based releases, including Ubuntu. Each attacker attempts to break through the identity of a limited user and exploit a vulnerability in the kernel to obtain the root access permission. Patching the kernel with grsecurity (http://olex.openlogic.com/packages/grsecurity) ensures that you are protected and can even guard against zero-day vulnerabilities. In addition, Ksplice (http://www.ksplice.com/) ensures that you have all Kernel updates in time to minimize security risks.

 

◆ Mandatory Access Control (MAC ). In a normal Web Server deployment environment, normal users do not need to access the compiler (gcc), system configuration files, or utilities such as find. Red Hat-based distributions can use MAC policy software named SELinux (http://olex.openlogic.com/packages/selinux); Ubuntu administrators can use similar AppArmor (http://olex.openlogic.com/packages/apparmor ). Although the features of these MAC tools are different, they can help you restrict the destructive actions of attackers. When it comes to unfavorable factors, improperly configured MAC tools can weaken the functionality of Web servers. This is why all MAC tools have non-execution modes, so that you can track false positives and reconfigure the tool for your specific environment. However, if you think MAC tools are too complicated, you only need to change the permissions of some executable files to 700, and only allow root users to use them.

 

◆ Firewall. You must restrict inbound and outbound traffic to prevent malicious connections to and from the server. For various types of servers, protecting inbound traffic is a common practice. However, for Web servers, it is particularly important to Restrict outbound connections so as to limit the impact of malicious script execution locally. Therefore, the most reliable method is to set the default iptables chain policy to DROP. In addition, you explicitly allow the required inbound and outbound connections. However, be careful when limiting outbound traffic because many Web scripts require external resources (RSS and external application programming interfaces ). If you think that iptables firewall is not used to it, you can use scripts to help generate and maintain necessary rules, such as Shorewall and Firestarter.

 

Apache best security practices

 

Once you have ensured the security of the Linux operating system, you can start to handle the security issues of the Apache Web server. The following instructions are specific to Apache, but may also apply to other Web servers, such as LiteSpeed and nginx. The differences between them are often reflected in the module name or configuration command.

 

To reinforce Apache, perform these steps:

 

◆ Install mod_security. This Apache module plays a role in the application firewall. It can filter all parts of a Web request and end malicious code. It plays a role before the Web server performs any practical processing, and thus has nothing to do with Web applications. Mod_security is suitable for filtering any malicious traffic from SQL injection to XSS attacks. It is also the fastest and easiest way to protect vulnerable Web applications. The software has many rules that can be used at any time, but you can easily write the rules on your own. For example, if you have an outdated Joomla version, you are worried about being attacked by SQL injection. This simple rule can filter any POST and GET content containing jos _ (the default prefix of the Joomla table): SecFilter "jos.

 

◆ Installing mod_evasive is another important Apache module that can protect Web applications from DOS requests. Its effect is subject to this reality: It works at the application layer, which means that Apache accepts connections in any way, thus consuming bandwidth and system resources. However, this module can be helpful if it is caused by a small number of weak DOS attacks on remote hosts. Once mod_evasive is loaded, you need to configure it as follows:

 

DOSPageCount 2

DOSSiteCount 30

DOSBlockingPeriod 120

This indicates that the server blocks (HTTP error 403 Forbidden is returned by default) any host that accesses the same page twice or has 30 requests within one second (default interval. Intruders are blocked for 120 seconds.

 

◆ Filter the visitor's IP address. This may be considered an extreme measure, but the results are good. First, install mod_httpbl, which is the Project Honeypot implemented by Apache. Once this module is installed and enabled, it can block IP addresses with malicious activities. Another method is to use mod_geoip, which can be used to allow only visitors from some countries to access pages that receive messages, registration and login information. It can even block and allow server-side visitors from some countries.

 

Other recommended Apache options include setting the Timeout option lower, for example, 15 seconds. This shortens the time for the Web server to wait for certain events and limits the impact of DOS attacks. It is worth further reading of the official Apache Documentation and Security Tips (http://httpd.apache.org/docs/2.3/misc/security_tips.html ).

PHP security

PHP is the most popular server-side language in the open-source field. PHP is a server, which means you need to use certain commands, such as memory_limit, execution_timeout, and disable_functions, to set clear rules and restrictions for its access to server resources. However, the PHP configuration directive can be defined and redefined everywhere, which is explained here (http://www.php.net/manual/en/ini.list.php ). When you execute these rules globally, make sure that their scope is clear.

 

If you have installed the latest PHP version and use the default settings, your environment has already met the fairly safe standard. Dangerous options are disabled by default, such as register_globals and allow_url_include. However, this is not enough. One of the most important options for adjustment is disable_functions; as its name suggests, it is used to disable PHP functions. The following example demonstrates how to prevent dangerous shell code execution:

 

Disable_functions = exec, passthru, shell_exec, system, proc_open, popen

There have been many attempts to introduce additional security mechanisms for PHP, whether in the development team or outside. An unsuccessful attempt is the Safe Mode of PHP. The main idea is to restrict file access based on the file owner. The results show that this function is incorrectly designed and has been deprecated since PHP 5.3. However, an external security project named Suhosin proves its value. It is bundled with PHP in a popular Debian-based release.

 

Suhosin can be installed in two ways. One is to patch the original PHP source code before PHP is actually compiled. We recommend that you use this method because it makes Suhosin a necessary component of PHP, so that Suhosin can protect the PHP core through its engine protection function. The second method is easier to add as a common PHP extension. The rich features of Suhosin apply to many security aspects, such as conference security data encryption, request payload restrictions, and even the test feature of SQL Injection prevention.

 

By default, PHP runs as an Apache module under Apache users, which ensures the best performance and best meets application requirements. However, if the website has more than one virtual host (vhost), it may cause serious security problems. If the virtual host belongs to different users, it is more dangerous. In this case, scripts from one VM may be able to read, write, and execute scripts from other Vm, which threatens security, not to mention privacy.

 

To alleviate this problem, you can use another Apache module: mod_suphp, which allows PHP scripts to run under predefined users. Such modules are essential for shared host hosting servers. If mod_suphp is used, scripts from a virtual host cannot even read files from other virtual hosts, let alone write files. Prohibiting reading files from external virtual hosts is extremely important to configuration files, which is why such files must have 600 file permissions. If this is not set, your database details are easily discovered, which is the least of your troubles.

 

In the configuration file mod_suphp (/etc/suphp. conf by default), you can use the options allow_file_group_writeable, writable, allow_directory_group_writeable, and writable to execute the global security file license policy. Under normal circumstances, they should all be defined as false. An HTTP Error 500 Internal server error (HTTP Error: 500, Internal server error) is returned when a script that does not comply with these restrictions is executed ).

 

General suggestions

 

When protecting Web servers, consider the following measures:

 

◆ Separate different Web applications on the same server into different virtual hosts for them to run under different users.

 

◆ Install SSL when transferring sensitive information such as passwords or credit card information. You can protect the management panel with a free, self-generated non-commercial certificate.

 

◆ Do not rely solely on one method to restrict administrator access. A large number of Internet vulnerabilities have avoided Administrator Logon requirements. You can restrict remote IP addresses from accessing the Administrator region and change the default Administrator URL or port.

 

◆ Perform security reviews on servers on a regular basis.

 

◆ Subscribe to security newsgroups for your deployed Web services and applications.

 

Therefore, the above information serves as a roadmap to ensure the security of Web servers. Doing this well requires a lot of time and effort. If you are not prepared to invest such time, it is best to use a shared host to host the server or a fully managed server.

 

From: 51cto.com