Protecting WordPress with Open Source Web Application Firewall ModSecurity

In this guide you will learn how to install and protect WordPress with the Open Source Web Application Firewall (WAF) ModSecurity. We will also install the latest protection rules from the OWASP Core Rule Set (CRS). A WAF is a great addition to the Cyber Security protection for your WordPress blog or website and can stop many zero-day attacks and known attacks, or as the project describes itself:

The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts.

This guide is written for the latest Ubuntu Linux LTS (Long Term Support) which is 20.04.3.

Installing ModSecurity and Core Rule Set

First step is to install modsecurtiy from the package repository:

sudo apt install libapache2-mod-security2

And it will look something like this if the above command is successfull:

sudo a2enmod security2

And also restart the Apache webserver:

sudo systemctl restart apache2

You can also verify that the module is loaded using this command: apache2ctl -M|grep security

Now we need to enable the blocking of Cyber Attacks in the ModSecurity module. This is not enabled by default so we need to change the SecRuleEngine config option:

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

And then edit the file /etc/modsecurity/modsecurity.conf using your favorite editor such as vim, emacs or nano. You need to change the line:

SecRuleEngine DetectionOnly

to

SecRuleEngine On

That’s it regarding Apache and ModSecurity. Now we need to download and enable the latest Core Rule Set:

cd
git clone https://github.com/coreruleset/coreruleset.git
cd coreruleset
sudo mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf
sudo mv rules/ /etc/modsecurity/

And it it goes well it would look something like this screenshot:

After this we will enable the rules in the configuration file and remove the old CRS. So the next step is to edit the file /etc/apache2/mods-enabled/security2.conf so it will look like this:

And then as the last step of enabling ModSecurity and the Core Rule Set, restart apache:

sudo systemctl restart apache2

ModSecurity WordPress tweaks

In order to get WordPress to work better with ModSecurity and the OWASP Core Rule Set (CRS) we need to make a few small tweaks. CRS has a variable named tx.crs_exclusions_wordpress and can be enabled depending on the URL of your WordPress installation. Edit the file crs-setup.conf and change the following lines:

# SecRule RESecAction \
#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

So it will look like this:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_wordpress=1
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Remember to reload the new rules by issuing a reload to the apache webserver:

sudo service apache2 reload

Important: Always remember to save more just than 14 days of logs. We recommend to save at least one year of logs, and this can be changed in the file: /etc/logrotate.d/apache2 and in this case we are saving weekly and 52 weeks (one year):

Problems and fixes

First problem we will run into is the following error:

Execution error - PCRE limits exceeded (-8)

And this error can be fixed by raising the following configuration option: SecPcreMatchLimit and SecPcreMatchLimitRecursion in the /etc/modsecurity/modsecurity.conf file. Set them to:

SecPcreMatchLimit 1000000
SecPcreMatchLimitRecursion 1000000

And the next error that will show up is when a file is being uploaded:

Access denied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required

This can be fixed by commeting out line 86 in the modsecurity.conf file, like this:

Also the following error is displayed in the logfile when the Theme Editor in WordPress is used:

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

Update the file modsecurity.conf and change SecRequestBodyLimit to the value 6000000.

Also we need to whitelist a few IDs. Create the following file:

/etc/apache2/conf-enabled/whitelist.conf

Add the following lines:

<LocationMatch "/wp-admin/theme-editor.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006 980130
</LocationMatch>

<LocationMatch "/wp-admin/admin-ajax.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006 981173 980130
</LocationMatch>

Also remember to always run reload when changing the ModSecurity configuration and rules:

sudo systemctl reload apache2

Thats it! If you find any other error please comment below so we can help each other to make WordPress even more secure.