Is Nginx or Apache more secure

Securing web servers: tips for Apache and Nginx

David Wolski

Web servers like Apache and Nginx do pretty well in terms of security. Often, however, it is configuration errors or unfavorable standard settings that reveal too many system details to attackers.

Critical holes in Apache and Nginx are rare. The web servers themselves are rarely vulnerable, rather the frameworks, PHP projects and scripts running on them. Nevertheless, a reasonable setup of a web server also includes the more secure, restrictive configuration of the server service.

The following points help to better secure a typical installation of Apache and Nginx. The most important point right from the start: Security requires regular updates - not only the web server packages of the Linux distribution, but above all updates of the CMS, blog system, shop framework or other scripts used on the server.

See also:Optimize Apache and Nginx for speed

Header: Don't give too much away

Web servers politely introduce themselves to HTTP requests in the response header with their name and version number, as do activated modules such as PHP. These headers allow conclusions to be drawn about the system used, the web server, its modules and software versions. This information is useful in test mode immediately after setup. In productive operation and on the Internet, these internals are nobody's business and reveal too much about the system. The version information activated by default in Apache and Nginx is quickly deactivated.

Apache: In Debian / Ubuntu / Raspbian the configuration file “/etc/apache2/conf-available/security.conf” is responsible. Only the line “ServerTokens OS” has to be added to the file

followed by an Apache restart. The information on the Apache version and modules is then removed from the header.

Nginx: The Nginx setting, which suppresses a version specification in the header, is located in the "/etc/nginx/nginx.conf" file. Inside the HTTP section that starts with

starts, insert this information as the last line before the final curly bracket:

PHP: The PHP interpreter for web servers is also chatty and reveals its version number in the standard configuration. This setting can be found in the "php.ini" file regardless of the web server used.

Their storage location varies depending on the version and type of installation. If PHP (version 7.0) is set up as an Apache module, the relevant “php.ini” is located in the “/etc/php/7.0/apache2/php.ini” directory. If PHP for Nginx is installed as an external script interpreter via the “PHP-FPM” package, this file can be found under “/etc/php/7.0/fpm/php.ini”.

The line

to

be changed.

Relevant:Solve common problems with Apache and Nginx

Do not forget: After each of these changes a restart of the web server is necessary

respectively

necessary in the case of Nginx. In addition, the "PHP-FPM" module, which runs independently of the web server service, must be reloaded with the following command sudo service php7.0-fpm restart.

Extra security per module

EnlargeThis curl command displays the headers of an HTTP / HTTPS response.

Whoever offers a service, be it just a web server with static HTML pages, especially with dynamic content via PHP, will at some point make the acquaintance of automated scanning programs like Nikto (see box).

Apache: With the extra module "libapache2-mod-evasive", Apache independently evades typical scan attacks, massive page views and simple attacks. If a page is requested several times per second from an IP address in quick succession or if 50 simultaneous requests are triggered per Apache process, this IP address ends up on a black list for a few seconds and only receives a 403 message (Forbidden). The extension is in Ubuntu / Debian / Raspbian using the command

easily installed. Cent-OS also knows the module by this name and under Open Suse it is called "apache2-mode evasive". After restarting the web server, the module with standard rules is active. The module can be easily tested when visiting the web server in the browser by frequently pressing the F5 key.

EnlargeNginx can also be configured via a built-in module so that the server acknowledges a flood of inquiries with a 503 message.

Nginx: The Naxsi tool was available for this web server until a few years ago, but its development is currently on hold. It is recommended to protect Nginx against flooding with requests via the built-in module "ngx_ http_limit_req_module". To do this, open the configuration file “/ etc / nginx / nginx.conf” with root rights in a text editor and add the line in the “http {” section

a. In the site configuration, which is usually located in Debian / Ubuntu / Raspbian under "/ etc / nginx / sites-available / default", the following line now appears in the "server {" section:

After a restart, Nginx will respond to frequent requests with a 503 message ("Temporary unavailable"). The Nginx documentation gives further examples of this module.

Scanner: web server in check

Hardly anyone takes the trouble to manually check all potential weak points and configuration errors of a web server. This is only necessary in exceptional cases, because there are scan programs that largely automate a check for the usual weak points.

EnlargeThe automatic scanner found a cross-site scripting vulnerability on our test site.

Nikto: Nikto is a tool that systematically helps with the analysis of possible configuration errors