Install/Enable & Configure WordPress ModSecurity Rule Set (WPRS)

WordPress ModSecurity Rule Set (WPRS) was created by AndreaTheMiddle. It is a ruleset that extends the well-known and most always used OWASP CRS with the open-source freeware Mod Security 3 WAF. These rulesets are an excellent choice for users that have WordPress installations as they are well known to be the most attacked given they are the number 1 popular and most used CMS.

In the following tutorial, you will learn how to download and set up WordPress WPRS on your Linux server that you can combine with.

Download WPRS

Locate the directory you have ModSecurity and OWASP core ruleset. The tutorial utilizes Ubuntu 20.04, and you can change the commands to suit your operating system of choice.

cd /etc/nginx/waf

Next, clone WPRS into the directory, preferably where your OWASP core ruleset is.

sudo git clone https://github.com/Rev3rseSecurity/wordpress-modsecurity-ruleset.git

Install WPRS in OWASP CRS

As stated, WPRS is to work with the OWASP core ruleset, you need to include the WPRS rule set, and you must have it in modsecurity.conf:

Include wordpress-modsecurity-ruleset/*.conf
Install WPRS in OWASP CRS

Once you have included this in your file, test your web server to ensure no errors and restart your server so the default rules are in operation. Congrats, you have installed WPRS in combination with Modsecurity/OWASP CRS.

Configure WPRS

Now you can look into the default settings to change the behavior. You may have features you will need to change to optimize the performance of the ruleset in file “01-SETUP.conf”.

Remember, to back up the configuration file before pulling any changes from the GIT.

Rule 22000000: Client IP Address

For the real client i.d, we have three options to choose from with default %{REMOTE_ADDR} which is usually the choice. However, you can set the option for Load Balance or Cloudflare if your server is behind one of these by uncommenting one of the three lines.

Uncomment 1 line option:

====DEFAULT====
#SecAction "phase:1,id:22000000,nolog,pass,t:none,setvar:tx.wprs_client_ip=%{REMOTE_ADDR}"

====CLOUDFLARE====
#SecAction "phase:1,id:22000000,nolog,pass,t:none,setvar:tx.wprs_client_ip=%{REQUEST_HEADERS:CF-Connecting-IP}"

====LOAD BALANCER====
#SecAction "phase:1,id:22000000,nolog,pass,t:none,setvar:tx.wprs_client_ip=%{REQUEST_HEADERS:X-Forwarded-For}"
Rule 22000000: Client IP Addres

Rule 22000004: Enable / Disable Brute-force mitigation

WPRS brute force mitigation rule is default turned on and set to 1. You should only set it to 0 if this affects your web application or conflicts with another security rule.

Uncomment the line and adjust:

====Disabled====

SecAction "id:22000004,phase:1,nolog,pass,t:none,setvar:tx.wprs_check_bruteforce=0"

====Enabled (Recommended)====

SecAction "id:22000004,phase:1,nolog,pass,t:none,setvar:tx.wprs_check_bruteforce=1"
Rule 22000004: Enable / Disable Brute-force mitigation

Rule 22000005: Time Span

The “time-span” rule covers how many seconds the login counter will be incremented on each attempt on /wp-login.php. The default setting is 120 seconds (2 minutes); however, I recommend changing this to 10 minutes as the example in the set-up.

Uncomment the line and adjust:

SecAction "id:22000005,phase:1,nolog,pass,t:none,setvar:tx.wprs_bruteforce_timespan=600"
Rule 22000005: Time Span

Rule 22000010: Threshold

The threshold rule dictates how many login attempts within the “time-span” period before WPRS accepts before it bans the client. The default is “5”, which is a good setting, but you can adjust it.

For example, we set a 600 seconds time rule. If you think “5” login attempts in that time frame are unacceptable, then set the thresh hold to “3”.

Uncomment the line and adjust:

SecAction "id:22000010,phase:1,nolog,pass,t:none,setvar:tx.wprs_bruteforce_threshold=3"
Rule 22000010: Threshold

Rule 22000015: Ban period

Ban period after brute-force threshold login attempts reached, the default period is 300 seconds (5 minutes); however, if you are under brute-force attack by bots which most WordPress installations are, I would set this much higher. We recommended 3600 seconds (1 hour)

Uncomment the line and adjust:

SecAction "id:22000015,phase:1,nolog,pass,t:none,setvar:tx.wprs_bruteforce_banperiod=3600"
Rule 22000015: Ban period

Rule 22000020: Log authentication

Log authentication events on /wp-login.php can be disabled, but the default is enabled and recommended for security log reviews.

Uncomment the line and adjust:

====Disabled====

SecAction "id:22000020,phase:1,nolog,pass,t:none,setvar:tx.wprs_log_authentications=0"

====Enabled (Recommended)====

SecAction "id:22000020,phase:1,nolog,pass,t:none,setvar:tx.wprs_log_authentications=1"
Rule 22000020: Log authentication

Rule 22000025: XMLRPC

Rule 22000025 XMLRPC you can enable or disable access to the xmlrpc.php script. Many WordPress users do not need this option but leave it activated as they don’t know any better, and it opens up an attack vector for hackers.

Having xmlrpc.php open is the second most active WordPress for hackers and exploiters next to /wp-login.php. So, it is recommended that you disable it if you do not need this WordPress option.

Uncomment the line and adjust:

====Disabled (Recommended)====

SecAction "id:22000025,phase:1,nolog,pass,t:none,setvar:tx.wprs_allow_xmlrpc=0"

====Enabled (Recommended)====

SecAction "id:22000025,phase:1,nolog,pass,t:none,setvar:tx.wprs_allow_xmlrpc=1"
Rule 22000025: XMLRPC

Rule 22000030: User Enumeration

The enumeration rule can enable or disable requests like “/author=1”. Attackers often use user enumeration using the author parameter, so it should be considered a point to close unless you specifically want it.

Uncomment the line and adjust:

====Disabled (Recommended)====

SecAction "id:22000030,phase:1,nolog,pass,t:none,setvar:tx.wprs_allow_user_enumeration=0"

====Enabled (Recommended)====

SecAction "id:22000030,phase:1,nolog,pass,t:none,setvar:tx.wprs_allow_user_enumeration=1"
Rule 22000030: User Enumeration

Rule 22000035: DoS Attack

When the rule enabled checks against DoS attacks on your WordPress website, the rule prevents attacks like CVE-2018-6389. If hackers find a CVE, they can cause resource consumption, such as the attack to exploit that occurred with WordPress 4.9.2 historically.

Uncomment the line and adjust:

====Disabled====

SecAction "id:22000035,phase:1,nolog,pass,t:none,setvar:tx.wprs_check_dos=0"

====Enabled (Recommended)====

SecAction "id:22000035,phase:1,nolog,pass,t:none,setvar:tx.wprs_check_dos=1"
Rule 22000035: DoS Attack

Comments and Conclusion

WordPress ModSecurity Ruleset comes with some great rule options to add that extra bit of security to WordPress. It works well with the OWASP rule set and should not give you any complications on any of the combinations of rules you set on both rule sets. Most plugins available on the WordPress store do what WPRS sets out to do; however, being in Modsecurity, it sits in front of your website instead of reacting to attacks as a plugin.



Follow LinuxCapable.com!

Like to get automatic updates? Follow us on one of our social media accounts!