ModSecurity

• Enable ModSecurity
• ModSecurity user-level configuration
  • Blocking access to ModSecurity configuration
• ModSecurity admin-level configuration
• Configuration files
• Customizing the ModSecurity Configuration
  • Request body no files data length is larger than the configured limit
• Enabling ModSecurity Uploadscan
• How can I confirm that ModSecurity is working
  • Testing browser-based requests to the site
  • Testing ModSecurity Uploadscan
• ModSecurity Templates and Skins
  • TEMPLATE

Enable ModSecurity

ModSecurity is an open-source web application firewall (WAF). It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.

The ModSecurity engine needs a set of rules to help classify the HTTP traffic and block potentially malicious requests. DirectAdmin has integration with the two most popular ModSecurity rule sets - OWASP and Comodo.

Enable ModSecurity with OWASP Core Rule Set:

da build set modsecurity yes
da build set modsecurity_ruleset owasp
da build modsecurity

Enable ModSecurity with Comodo Rules:

da build set modsecurity yes
da build set modsecurity_ruleset comodo
da build modsecurity

ModSecurity user-level configuration

Each user can manage ModSecurity configuration for his domains and subdomains. The ModSecurity management page can be found in the user access level menu Advanced Features > Web Application Firewall.

If the default configuration is not changed, then each domain and subdomain will use a global server configuration provided by the server administrator.

The management page allows:

• Enabling or disabling the ModSecurity engine.
• Disabling some of the ModSecurity rules.

Deactivating some of the ModSecurity rules is useful to create exceptions if valid requests are getting blocked.

The ModSecurity management page can also show the log of blocked HTTP requests. The log contains key information about the requests and the ModSecurity rule number that causes the request to be blocked.

Blocking access to ModSecurity configuration

The access to the ModSecurity configuration page can be blocked by preventing users from accessing the modsecurity command.

It can be globally disabled by adding this command to the never_comands list in the directadmin.conf file. Example:

da config-set never_commands modsecurity --restart

Access for a single user can be denied by adding the modsecurity command to the user-specific commands.deny file. Example:

echo 'modsecurity' >> /usr/local/directadmin/data/users/{username}/commands.deny

ModSecurity admin-level configuration

User accounts with administrator privileges can manage the global ModSecurity configuration. Global configuration is included in the top-level web server configuration scope and gets inherited by all virtual hosts. This means not only all user-owned domains but also the main server host name, default virtual host and virtual hosts for access by literal server IP address.

The configuration management page can be found in Server Manager > Modsecurity. It is similar to the user-level configuration. ModSecurity can be disabled completely, or some rules can be disabled.

Note: If a ModSecurity rule is disabled in the global server configuration, it is not possible to re-enable the rule in the user-level configuration. User-level configuration can only extend the disabled rules list for a particular domain.

Configuration files

The list of ModSecurity files included in the web server configuration:

File	Desciption
/usr/local/directadmin/data/admin/modsecurity_rules	Global ModSecurity configuration file, inherited by all virtual hosts on the server.
/usr/local/directadmin/data/users/{user}/domains/{domain}.modsecurity_rules	Domain ModSecurity configuration, used in domain and domain aliases virtual host configuration.
/usr/local/directadmin/data/users/{user}/domains/{domain}.subdomains_modsecurity_rules/{sub}.modsecurity_rules	Subdomain ModSecurity configuration, used in subdomain virtual host configuration.

Audit log files:

File	Description
/var/log/httpd/modsec_audit.log	Used by Apache, LiteSpeed and OpenLiteSpeed web servers.
/var/log/nginx/modsec_audit.log	Used by the Nginx web server.

Customizing the ModSecurity Configuration

Methods exist in CustomBuild to permit one to customize the ModSecurity configuration as described below. We will use a common example requiring ModSecurity config changes.

Request body no files data length is larger than the configured limit

If you see the following error in the Apache error log, you can increase the limit via the Apache configuration, however, you must do so in a manner that will allow CustomBuild to preserve the change:

ModSecurity: Request body no files data length is larger than the configured limit (131072).

This limit (SecRequestBodyNoFilesLimit) is set via the following files:

• /usr/local/directadmin/custombuild/configure/ap2/conf/extra/httpd-modsecurity.conf
• /usr/local/directadmin/custombuild/configure/openlitespeed/conf/httpd-modsecurity.conf
• /usr/local/directadmin/custombuild/configure/nginx_reverse/conf/nginx-modsecurity.conf
• /usr/local/directadmin/custombuild/configure/nginx/conf/nginx-modsecurity.conf

Steps for adjusting this value so that it is not overwritten with the next CustomBuild rebuild of your webserver configuration are defined below. Alternatively, you might try specifying a new setting via the /etc/httpd/conf/extra/httpd-includes.conf file (or the includes file for your chosen webserver) since it is not touched by CustomBuild.

Apache

1. Make sure the custom Apache directory exists:

mkdir -p /usr/local/directadmin/custombuild/custom/ap2/conf/extra
cp -a /usr/local/directadmin/custombuild/configure/ap2/conf/extra/httpd-modsecurity.conf /usr/local/directadmin/custombuild/custom/ap2/conf/extra/httpd-modsecurity.conf

2. Edit the value in the custom file as desired:

nano /usr/local/directadmin/custombuild/custom/ap2/conf/extra/httpd-modsecurity.conf

or

vim /usr/local/directadmin/custombuild/custom/ap2/conf/extra/httpd-modsecurity.conf

or use whatever your preferred editor happens to be.

3. Rebuild the configuration:

da build rewrite_confs

--

The process is quite similar for other webservers.

OpenLiteSpeed

mkdir -p /usr/local/directadmin/custombuild/custom/openlitespeed/conf/
cp -a /usr/local/directadmin/custombuild/configure/openlitespeed/conf/httpd-modsecurity.conf /usr/local/directadmin/custombuild/custom/openlitespeed/conf/httpd-modsecurity.conf
nano /usr/local/directadmin/custombuild/custom/openlitespeed/conf/httpd-modsecurity.conf
da build rewrite_confs

Nginx Reverse Proxy

mkdir -p /usr/local/directadmin/custombuild/custom/nginx_reverse/conf/
cp -a /usr/local/directadmin/custombuild/configure/nginx_reverse/conf/nginx-modsecurity.conf /usr/local/directadmin/custombuild/custom/nginx_reverse/conf/nginx-modsecurity.conf
nano /usr/local/directadmin/custombuild/custom/nginx_reverse/conf/nginx-modsecurity.conf
da build rewrite_confs

Nginx

mkdir -p /usr/local/directadmin/custombuild/custom/nginx/conf/
cp -a /usr/local/directadmin/custombuild/configure/nginx/conf/nginx-modsecurity.conf /usr/local/directadmin/custombuild/custom/nginx/conf/nginx-modsecurity.conf
nano /usr/local/directadmin/custombuild/custom/nginx/conf/nginx-modsecurity.conf
da build rewrite_confs

Enabling ModSecurity Uploadscan

This feature requires ClamAV, so ensure this is enabled first or at least set to 'yes' in the CustomBuild options.conf. Then, run the following CustomBuild commands:

da build set modsecurity_uploadscan yes
da build modsecurity
da build rewrite_confs

How can I confirm that ModSecurity is working

Testing browser-based requests to the site

Just load your domain like so in the browser:

yourdomain.com/?page=../../etc/passwd

And then check the domain's error logs. This should trigger File Inclusion protections in ModSecurity and result in an error. You should see something like this logged:

ModSecurity: Access denied with code 406 (phase 2). Matched "Operator `Rx' with parameter `(?i)(?:\x5c|(?:%(?:c(?:0%(?:[2aq]f|5c|9v)|1%(?:[19p]c|8s|af))|2(?:5(?:c(?:0%25af|1%259c)|2f|5c)|%46|f)|(?:(?:f(?:8%8)?0%8|e)0%80%a|bg%q)f|%3(?:2(?:%(?:%6|4)6|F)|5%%63)|u(?:221[56]|002f|EFC8|F025)|1u|5 (400 characters omitted)' against variable `ARGS:page' (Value: `../../etc/passwd' ) [file "/etc/modsecurity.d/REQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "29"] [id "930100"] [rev ""] [msg "Path Traversal Attack (/../)"] [data "Matched Data: /../ found within ARGS:page: ../../etc/passwd"] [severity "2"] [ver "OWASP_CRS/3.3.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153/126"] [hostname "108.160.151.160"] [uri "/"] [unique_id "161575949767.714205"] [ref "o9,4v4,23o2,4v11,16"], client: X.X.X.X, server: yourdomain.com, request: "GET /?page=../../etc/passwd HTTP/1.1", host: "yourdomain.com"

Error logs are located here, depending on webserver and domain, respectively:

/var/log/*/domains/*.error.log

Testing ModSecurity Uploadscan

If you need to test ModSecurity Uploadscan, you can try uploading the EICAR test files located at the following links to ensure that the upload is blocked:

http://www.eicar.org/anti_virus_test_file.htm

ModSecurity Templates and Skins

TEMPLATE

In the virtual_host2*.conf, we've added a new token:

|MOD_SECURITY_RULES|

within the <Directory> context.

Also, this token is available in the nginx_server*.conf and the openlitespeed_vhost.conf.