Although the market share of Nginx and LightHttpd in web server has been increasing in recent years, Apache is still on top in this field, and the majority of web applications on the Internet are still running on the Apache Httpd.
Our concern about the security of web server is twofold: whether the web server itself is unsafe and whether the web server provides security features that can be used. Throughout the history of Apache, many high-risk vulnerabilities have come up. But these were mostly caused by Apache’s module. There are almost no high-risk vulnerabilities in the core of Apache. Apache has many official and unofficial modules, but possibilities for high-risk vulnerabilities is very less in it default module; most high-risk vulnerabilities are concentrated in the module that is not enabled by default or a module that may be installed later.
Therefore, the first thing is to check would be the Apache module installation, according to the “principle of least privilege”; we should try not to install unnecessary modules. For those that are necessary, make sure to check if there are known security vulnerabilities in that version.
After customizing the installation package of Apache, what you need to do is specify the Apache process to run as a separate user, which usually involves creating a separate list of Apache user/group.
ote that running Apache as root or admin is too risky. Admin status here refers to using the identity of the server administrator to manage machines. The administrator has the highest level of rights, that is, they can manage scripts, get access to the configuration files, read/write logs, and so on.
Running Apache as administrator can lead to two catastrophic consequences:
- When a hacker succeeds in web hacking, they will have direct, high-privilege access (such as root or admin) to the shell.
- The application itself will have a higher level of authority, so when a bug occurs, it may lead to the risk of deleting important files locally, killing process, and other unpredictable results.
So it is always better to use a dedicated user to run Apache. The user should not have shell access and its only role would be to run the web application.
Knowing in what identity a process should be started is important when using other web containers as well. Many JSP web administrators prefer to configure Tomcat to run as root; this makes hackers happy since as soon as the hackers get webshell access through loopholes, they will find that it already has root privilege.
Apache also provides a number of configuration parameters that can be used to optimize server performance and improve the ability to fight against distributed denial of service (DDOS) attacks. These parameters are discussed in the “application layer denial of service attacks.”
The official documentation in Apache* provides guidance on how to use these parameters. These parameters can perform many functions, but the number of possible functions in a single machine is limited, so fighting against DDOS cannot entirely depend on these parameters, but they are better than nothing.
Finally, let’s look at how to properly protect the Apache log. In general, when an attacker succeeds in invading a system, the first thing he will do is remove all traces of the invasion— by modifying or deleting log files. Therefore, access log should be well protected. This can be done effectively by enabling transmitting of real-time log to a remote syslog server.