Protecting WordPress With Open Source Web Application Firewall ModSecurity

Are you in search of a reliable open-source web application firewall? There are many free WAF( web application firewall) that offer you the freedom to change the coding depending upon your projects. The finest open-source WAFs are ModSecurity, WebKnight, IronBee, NAXSI, and Shadow Daemon. They can defend your web apps against malicious requests, bot assaults, and a variety of other web dangers. The OWASP core rule of MOD Security,  advancing WordPress development Services and protect them from any malicious attack.

ModSecurity-What it is?

ModSecurity is the Beast of WAFs available for free. It has hordes of attributes to protect your web apps. ModSecurity gives you the entire control over the tool's capabilities, allowing you to tailor it to your specific requirements.

Furthermore, the software is simple to set up and use, and it begins working immediately after installation.

Features of ModSecurity

·         Application security monitoring and access management in real-time

·         Continuous passive security assessment with comprehensive HTTP traffic logging

·         Hardening of web applications

·         Reliable documentation

A WAF is an amazing addition to your WordPress blog or website's Cyber Security security, as it can stop many zero-day and known attacks, or as the project explains it:

With a slight of incorrect warnings, the CRS goes to defend online applications from an extensive variety of assaults, including the best ten OWASP.

How to install ModSecurity along with the Core Rule Set

Installing ModSecurity from the package repository is the first step:

sudo apt install libapache2-mod-security2

If the above command is successful, it will appear somewhat like this:

Then we double-check that the module is turned on:

sudo a2enmod security2

Resume the Apache webserver additionally:

sudo systemctl restart apache2

You may also use the command apache2ctl -M|grep security to see whether the module is enabled.

In the ModSecurity module, we should now initiate the hindering of Cyber Attacks. Because this isn't automatically updated, we'll have to update the SecRuleEngine config option to:

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

Then you should use your preferred editor, for example, vim, emacs, or nano, to alter the file /etc/modsecurity/modsecurity.conf

Then modify it to SecRuleEngine Detectiononly to SecRuleEngine On

when it comes to Apache and ModSecurity it is everything. Now we need to get the most recent Core Rule Set and activate it:

cd

git clone https://github.com/coreruleset/coreruleset.git

cd core ruleset

sudo mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf

sudo mv rules/ /etc/modsecurity/

And if everything goes well, it should look something like this:

The rules will then be enabled in the configuration file, and the existing CRS will be removed. Its next step is to change the security2.conf file/etc/apache2/mods-enabled/security2.conf to appear like this:

Then restart apache as the final step in enabling ModSecurity and the Core Rule Set:

sudo systemctl restart apache2

WordPress ModSecurity updates

We need to make a handful of slight changes to get WordPress to execute better with ModSecurity in addition to the OWASP Core Rule Set (CRS). The tx.crs_exclusions_wordpress variable in CRS can be initiated created on the URL of your WordPress installation. Edit the following lines in the crs-setup.conf file:

# 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"

Therefore, it will appear 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"

Ensure to reload the rule changes by instructing the Apache webserver to reload:

Sudo service apache2 reload

Issues and solutions

The first issue we'll face is the following error:

Execution error - PCRE limits exceeded (-8)

Furthermore, this problem can be resolved by enabling the following configuration option:

SecPcreMatchLimit and SecPcreMatchLimitRecursion in the /etc/modsecurity/modsecurity.conf file.

They should be set to:

SecPcreMatchLimit 1000000

SecPcreMatchLimitRecursion 1000000

When a file is being uploaded, the following error will appear:

With code 403, access is denied (phase 2). "eq 0" must be matched against "MULTIPART UNMATCHED BOUNDARY."

When using the WordPress Theme Editor, the next error is also displayed in the logfile:

There are no files in the request body. The data length exceeds the specified limit.

Change the value of SecRequestBodyLimit to 6000000 in the file modsecurity.conf.

A few IDs must also be whitelisted. Make the following file:

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

Add the subsequent lines:

  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006 980130

  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006 981173 980130

When modifying the ModSecurity configuration and rules, ensure to always execute reload:

sudo systemctl reload apache2

now you can secure your WordPress apps by this ModScecurity module.

Admin

Sanjib.