Differences

This shows you the differences between two versions of the page.

--- litespeed_wiki:config:wordpress-protection [2018/11/13 20:26]
Jackson Zhang
+++ litespeed_wiki:config:wordpress-protection [2020/01/23 19:37] (current)
George Wang [Set "Trusted <ip>" in .htaccess to bypass the block]
@@ Line 8: / Line 8: @@
 ===== How Brute Force Protection Works =====
-The newly introduced WordPress Protection directive is: ''WordPressProtect [off|on|drop|deny|throttle, ] <limit>'' \\
+The newly introduced WordPress Protection directive is: ''WordPressProtect [off|on|drop|deny|throttle|captcha, ] <limit>'' \\
-The action is optional, and defaults to ''throttle''. The limit can be set together with the action, and has a value of (0|1|5-1000) \\
+The action is optional, and defaults to ''throttle''. The limit can be set together with the action, and has a value of (0|1|2-1000) \\
   * ''0'' disables WordPress Protection.
   * ''1'', when used by a virtual host, defers to the setting used by the server.
-  * ''5''-''1000'' enables WordPress protection and also specifies the login limit. (Values lower than ''5'' will be treated as ''5'', and values higher than ''1000'' will be treated as ''1000'') \\
+  * ''2''-''1000'' enables WordPress protection and also specifies the login limit. (Values lower than ''2'' will be treated as ''2'', and values higher than ''1000'' will be treated as ''1000'') \\
 **Example:**
   * ''WordPressProtect drop, 10''
   * ''WordPressProtect throttle, 20''
+  * ''WordPressProtect captcha, 2''
+**NOTE**: In order to use the ''captcha'' option, you need to configure the reCAPTCHA protection feature. Please see the
+[[https://docs.litespeedtech.com/lsws/recaptcha/|How to Configure reCAPTCHA Protection]] guide for instructions.
 This directive can be placed in the Apache configuration or ''.htaccess'' file.
@@ Line 102: / Line 106: @@
 |5|10|not set|10|
 |5|10|20|10|
+===== How to Enable LSWS WordPressProtect Feature on Plesk =====
+Everything should be same as cPanel. The only difference is in where to place the directives.
+==== Server-Level Configuration ====
+Edit the file ''/usr/local/psa/admin/conf/templates/custom/domain/domainVirtualHost.php''.
+This file should be generated by the ''bash <(curl http://www.litespeedtech.com/packages/lscache/set_cache_root_policy.sh)'' script when you set up the cache root. If you haven't run it yet, please do so to enable cache root setup.
+There are **two** blocks of the following code:
+<code><IfModule Litespeed>
+CacheRoot lscache
+</IfModule></code>
+We can insert the WordPressProtect code here, like so:
+<code><IfModule Litespeed>
+CacheRoot lscache
+WordPressProtect throttle, 5
+</IfModule></code>
+This will override the default server-level setting from ''10'' to ''5''. Be sure to run ''/usr/local/psa/admin/sbin/httpdmng --reconfigure-all'' to regenerate the configuration file, then ''/usr/local/lsws/bin/lswsctrl restart'' to restart LSWS so the new setting takes effect.
+==== Vhost-Level Setting ====
+{{ :litespeed_wiki:plesk:plesk-wp-protect.jpg |}}
+In the Plesk domain page, as seen in the screenshot, navigate to **Apache & nginx Settings**, add the following directive in **Additional directives for HTTP** and **Additional directives for HTTPS**, then click **OK** or **Apply** to save it:
+<code><IfModule Litespeed>
+WordPressProtect throttle, 5
+</IfModule></code>
+{{ :litespeed_wiki:plesk:plesk-wp-protect2.jpg |}}
+Plesk users may also use `.htaccess` to override the server-level setting.
 ===== Real Testing=====
@@ Line 186: / Line 230: @@
 Brute force detected, throttle
-===== Troubleshooting =====
+===== Set "Trusted <ip>" in .htaccess to bypass the block and reCAPTCHA check ====
-==== Does wordpress protection black expired in 10 minutes? ===
-A visitor is receiving constant 403 errors due to wordpress protection. The error log entry is as the following:
+Since LSWS 5.4RC1, LSWS added virtual host trusted IP support, where you use ''Trusted 1.2.3.4, 5.6.7.8'' for IPv4 or ''Trusted [2001:db8:85a3:8d3:1319:8a2e:370:7348]'' for IPv6 in Virtual Host document root .htaccess to unblock blocked IP and make that IP trusted for that vhost.
--11-06 15:41:30.862784 [NOTICE] [24.96.xxx.xxx] bot detected for vhost [APVH_kevinandamanda.com], reason: WordPressBruteForce, close connection!
+===== Troubleshooting =====
--11-06 16:52:10.591124 [INFO] [108.162.237.188:58160] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+==== WordPress Protection Block Never Seems to Expire ===
--11-06 16:54:10.851797 [INFO] [108.162.*.*:57936] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
--11-06 16:56:11.349033 [INFO] [108.162.*.*:57976] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
--11-06 16:58:11.819620 [INFO] [108.162.*.*:58196] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
--11-06 17:00:12.607042 [INFO] [108.162.*.*:58606] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
--11-06 17:02:13.371969 [INFO] [108.162.*.*:56922] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
-Is the LSWS WordPress protection block normally expired in 10 minutes? The visitor has been blocked for a few hours. Block seems removed after restarting LSWS.
-While it only get unblocked if they stop access for 10 minutes completely. If the visitor constantly hit the server, the blocking won't be lifted. Restart web server will remove all IPs being blocked immediately.
+Normally the WordPress protection block is expected to expire after 10 minutes, but a visitor is receiving constant 403 errors due to WordPress protection. The error log entry is as the following:
+-11-06 15:41:30.862784 [NOTICE] [24.96.xxx.xxx] bot detected for vhost [APVH_kevinandamanda.com], reason: WordPressBruteForce, close connection!
+-11-06 16:52:10.591124 [INFO] [108.162.237.188:58160] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+-11-06 16:54:10.851797 [INFO] [108.162.*.*:57936] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+-11-06 16:56:11.349033 [INFO] [108.162.*.*:57976] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+-11-06 16:58:11.819620 [INFO] [108.162.*.*:58196] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+-11-06 17:00:12.607042 [INFO] [108.162.*.*:58606] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+-11-06 17:02:13.371969 [INFO] [108.162.*.*:56922] Client IP from header: 24.96.xxx.xxx, conn limit: 10000, cur conns: 13, access denied
+The visitor has been blocked for a few hours, and the block is removed after restarting LSWS.
+The explanation: WP protection blocking is only removed if the IP stops access attempts for a full 10 minutes. If the visitor constantly hits the server, the blocking won't be lifted. Restarting the web server will remove all IP blocks immediately.
+The bot-detection ''bot detected'' or ''WordPressBruteForce'' only log when a ''drop'' action is set. There won't be log entries for the ''deny'' and ''throttle'' actions. It is designed this way because ''drop'' is a more serious action, which blocks further requests from that IP (treated as unwanted botnet) and the log is for robot detection.
+-11-06 15:41:30.862784 [NOTICE] [24.96.xxx.xxx] bot detected for vhost [APVH_kevinandamanda.com], reason: WordPressBruteForce, close connection!
+Bot detection is one-time logging, while ''deny'' and ''throttle'' are per request, and it could become annoying with many repeated log messages.