ModSecurity
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 > ModSecurity.
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
- 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
- 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.
- 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.