Nginx Free WAF: ModSecurity vs Nemesida WAF Free Pentestit Follow Apr 21 · 8 min read

In the previous review of free WAFs for Nginx we compared NAXSI and Nemesida WAF Free. Now the time has come to make another review, using the most popular technology in its segment — ModSecurity, or Modsec. The review will take into account the simplicity of installation, the quality of the predefined signatures (False Positive, False Negative), usability and other criteria.

Installation

ModSecurity

Initially ModSecurity was developed only for a web server controlled by Apache, but at the moment it is a cross-platform technology and can be installed on Apache, Nginx and IIS. Another advantage of ModSecurity is its open source code.

Nevertheless the first difficulty a user may encounter at the stage of using ModSecurity is manual compilation of the module when connecting to Nginx. The first step is to compile Libmodsecurity that will connect Nginx and ModSecurity. Then we get the source code:

# git clone ––depth 1 -b v3/master––single-branch https://github.com/SpiderLabs/ModSecurity

We go to the source code directory and run the build.sh script to automatize the compilation process. Then we run the commands in turn:

# ./configure # make && make install

After installing libmodsecurity, we assemble the connector using the source code of the Nginx web server version which it subsequently interacts with. Then we get the source code:

# git clone ––depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git

We go to the directory with files and run the commands in turn to compile and copy the result to the Nginx modules directory:

# ./configure ––with-compat ––add-dynamic-module=../ModSecurity-nginx # make modules # cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules

We add the path to the file with the module in the configuration file /etc/nginx/nginx.conf for connection. Given the fact that the source code for all components must be downloaded from different places, the installation will be extremely problematic for inexperienced users.

Nemesida WAF

Nemesida WAF Free is a free version of Nemesida WAF, which is a dynamic module for Nginx that provides basic protection for a web application from the OWASP class attacks based on the signature method.

Currently, the Nemesida WAF module is available only for Nginx, so it does not have a similar problem. To install the module, we only need to follow the instructions. Nemesida WAF does not require compilation; it can be connected to an already installed Nginx starting from version 1.12 and distributed in the Linux repository packages for Debian, Ubuntu and CentOS distributions.

We add information about the Nemesida WAF repository. The Debian 9 commands will look like this:

# echo «deb https://repository.pentestit.ru/nw/debian stretch non-free» > /etc/apt/sources.list.d/NemesidaWAF.list # wget -O- https://repository.pentestit.ru/nw/gpg.key | apt-key add –– # apt update && apt upgrade

Now we add Nginx Repository information:

# echo “deb http://nginx.org/packages/debian/ stretch nginx” > /etc/apt/sources.list.d/nginx.list

and install it together with the Nemesida WAF dynamic module:

# wget -O- https://nginx.org/packages/keys/nginx_signing.key | apt-key add –– # apt update && apt upgrade # apt install nginx # apt install python3-pip python3-dev python3-setuptools librabbitmq4 libcurl4-openssl-dev libc6-dev dmidecode gcc rabbitmq-server # pip3 install — no-cache-dir pandas requests psutil sklearn schedule simple-crypt pika fuzzywuzzy levmatch python-Levenshtein unidecode # apt install nwaf-dyn-1.16

where 1.16 is the version of Nginx installed. We add the path to the file with the Nemesida WAF dynamic module and additional settings in the /etc/nginx/nginx.conf configuration file:

load_module /etc/nginx/modules/ngx_http_waf_module.so;

…

worker_processes auto;

…

http {

…

##

# Nemesida WAF

##

## Request body too large fix

client_body_buffer_size 25M;

include /etc/nginx/nwaf/conf/global/*.conf;

include /etc/nginx/nwaf/conf/vhosts/*.conf;

…

}

It is also recommended to configure RabbitMQ as instructed. Installing and connecting the module to Nginx takes about 10 minutes.

Configuration

ModSecurity

ModSecurity does have a lot of configuration directives, and even an experienced specialist may need time. Although a file with the recommended settings can also be obtained on a third-party resource. The official instruction for ModSecurity installation and configuration is available only in English, however, due to the great popularity of the technology user instructions in Russian and other languages are available on the Internet.

The configuration is carried out in the /etc/nginx/modsec/modsecurity.conf file. The main setting directives include the following:

SecRuleEngine — enabling/disabling request processing using rules;

SecRequestBodyAccess — enabling/disabling request body processing using ModSecurity. Required for POST requests processing;

SecAuditLog — the location of audit log files configuration;

SecDefaultAction — list of actions for default rules;

SecRuleRemoveById — removing rules by their ID. It can be used to create “white” lists, but removing a large number of rules can lead to poor security.

But this is only a small part of the settings through which the operation of ModSecurity can be customized.

Nemesida WAF

The official website of Nemesida WAF provides instructions in Russian and English. In addition, there are video instructions.

In case the access to nemesida-security.com:443 is available through a proxy server, its value must be indicated in the sys_proxy setting. For example, sys_proxy = proxy.example.com:3128. But other settings may also be interesting:

nwaf_ip_wl — disabling request analysis for a specific IP address or subnet. It is possible to disable analysis when accessing a specific domain. For example, nwaf_ip_wl 10.0.0.1 domain=example.com;

— disabling request analysis for a specific IP address or subnet. It is possible to disable analysis when accessing a specific domain. For example, nwaf_ip_lm — all access rules for specific IP-addresses or subnets pass setting. For example, nwaf_ip_lm 10.0.0.1 domain=example.com;

— all access rules for specific IP-addresses or subnets pass setting. For example, nwaf_host_wl — disabling request analysis for a specific virtual host. For example, nwaf_host_wl example.com;

— disabling request analysis for a specific virtual host. For example, WL — “white” list of signature exception rules. It allows creating exceptions for a specific rule. For example, WL ID:69 domain=test.local “Z:Cookie”; will create an exception rule, according to which rule 69 will not block access to the test.local domain containing an attack in the Cookie zone;

— “white” list of signature exception rules. It allows creating exceptions for a specific rule. For example, will create an exception rule, according to which rule 69 will not block access to the test.local domain containing an attack in the Cookie zone; RL — personal signatures that allow customizing a set of rules to more accurate attack identification. For example, the rule RL ID:50001 domain=example.com “P:select from” “SC:SQL:12” “Z:ARGS”; will block requests to the example.com domain, whose parameters will contain select from;

Exploitation

An acceptable security level for each solution is achieved through a well-composed signature base, which allows blocking most known attacks that can be detected using signature analysis. If you compare the setup simplicity, Nemesida WAF is more convenient, in my opinion.

ModSecurity

After installing and configuring ModSecurity, it still will not protect the web application. A set of signatures need to be connected. It can be downloaded, for example, through the official GIT-repository of the project (if there is a paid set of rules, but we are considering a free version).

It will not be simple for a beginner to understand the rules of how ModSecurity blocks requests. In order to track blocked requests in ModSecurity, the error.log of the web server must be examined. There the main rule that led to the blocking will be found out:

For more detailed information about the reason for blocking the request (for example, to find out the signature), you need to examine the debug file:

Nemesida WAF

In Nemesida WAF case, the signature database is loaded automatically and looks understandable. To find out which rule led to request blocking go to error.log of the web server:

or personal cabinet — one more advantage of using Nemesida WAF Free:

The information about the blocked request is displayed in your personal account, as well as a ready exception rule (WL), which is automatically generated when you click on the signature ID:

Support

ModSecurity

ModSecurity provides a paid subscription. If you select it, it is possible to connect a special set of rules and additional functionality that is not available in the free version. It also opens the access to product technical support. If you use the free option, then there is no support, and you will have to look for answers to questions on the forums.

Nemesida WAF

Nemesida WAF Free user support is only available on the forum, but difficult issues can be resolved by sending a question to the technical support email.

WAF Bypass

In general, when performing WAF bypass with its own standard set of payloads, two technologies showed the same result — they either missed the attack or successfully blocked the request. However, there were some limitations.

XSS

When trying to exploit the XSS vulnerability, a problem appeared — ModSecurity blocked img tags, but a legitimate user can exploit this tag to work with images. A rule that allows using a tag had to be disabled, but such an action can reduce the level of a web application security. Nemesida WAF Free will not probably need these exceptions. A real attack using the img tag was blocked by both WAFs:

SQLi

Now we will check the response to attempts of performing SQL injections. For example, we take the same vulnerability which payload missed NAXSI. Both solutions blocked the attack by recognizing the single and double URL Encoding:

LFI

Both ModSecurity and Nemesida WAF Free successfully block standard attacks related to local file attachments:

RCE

When trying to exploit the RCE (in parameters) vulnerability, both solutions missed the attack. It is rather difficult (or impossible) to create a signature for it that would block the request and would not lead to false triggers. In full Nemesida WAF version, in addition to signature analysis, machine learning is used that recognizes and blocks such attacks and their variations with approximately no false triggers:

Conclusion

If we evaluate the work of decisions on the quality of attacks detection by the signature method based on basic tests, we can say that they successfully meet this challenge and, most likely, the quality of work will depend on the specific secured application and its working features. The advantage of ModSecurity is its open source code and huge user audience, however, this does not protect the product from errors and vulnerabilities. In terms of simplicity and convenience of exploitation, Nemesida WAF Free, in my opinion, has more advantages. In addition, the latter is well adapted for a Russian-speaking audience: a localized forum, documentation and video instructions. Moreover, Nemesida WAF has a Personal Cabinet, which contains information on blocked requests in the form of active list, graphs and report uploads in PDF. In addition to everything, you can connect the VTS module traffic statistics to your Personal Account.

In any case, using only signature analysis comes down to the attempts to balance between the number of false triggers and missed attacks. In this case, using combined analysis based on signatures and machine learning is much more efficient. Besides the high accuracy, the exploitation of machine learning also allows detecting “zero-day” and brute force attacks; and the use of additional modules, such as Nemesida WAF Scanner and web-interface management, improves security and usability of WAF.