nlpro
Forum Replies Created
-
Hi @oldjim3,
Turns out the BAN THRESHOLD setting only shows up after enabling the Ban Repeat Offender setting (totally missed that yesterday). So try and change the value of the BAN THRESHOLD setting from 3 to 1 and let me know whether this works for you ??
- This reply was modified 10 months ago by nlpro.
Hi @oldjim3,
This is basically already build in (assuming I correctly understand your question). Let me explain.
The brute force module of the plugin distinguishes between (temporary) lockouts and (permanent) bans. By default an IP is banned after 3 lockouts (note this used to be configurable as the BAN THRESHOLD setting in Global Settings) within 7 days (which is still configurable as the DAYS TO REMEMBER LOCKOUTS setting in Global Settings).
So if the UI would still allow you to configure the BAN THRESHOLD setting in Global Settings, changing the default value of 3 to 1 would automatically convert any temporary lockout into a permanent ban.
The current UI seems to be missing the BAN THRESHOLD setting in the Global Settings!? I can see in the Debug page the setting still exists as blacklist_count for the global module. Bug?
Hi @djixas,
There was a major plugin update (8.0) almost 3 years ago (2021-07-28) that removed a lot of old/obsolete things from the plugin (however it also added a lot of new cool things).
You can read all about it in this (iThemes Security 8.0 Brings New Design, Features) post.
Jump directly to the 6. Addition by Subtraction: Settings Removed in 8.0 section to get your questions answered;-)
More recently (2023-10-17) there was another major plugin update (9.0). You can read all about it in this (Solid Security: The Next Chapter in WordPress Protection) post.
- This reply was modified 10 months, 1 week ago by nlpro.
Hi @djixas,
It seems the current File Change module settings have not been (auto) upgraded. You have 10 settings while it should be just 5 for the current plugin release (9.3.2). So correcting this would require quite some manual work. The outcome is also uncertain. There seem to be more settings issues with other modules (eg global).
The alternative is to deactivate and delete the plugin. Then reinstall the plugin. Deactivate/delete/reinstall of the plugin will automatically correct ALL the plugin settings. It’s the easiest and fastest way forward.
Let us know how you wish to proceed.
- This reply was modified 10 months, 1 week ago by nlpro.
Hi @djixas,
Thank you for sharing the global settings.
Please also share the file-change settings (Don’t forget to first obscure any info you don’t want to share).
Hi @cp_so,
If my earlier code snippet is not taking care of all the PHP warnings try the one below (thoroughly tested):
add_filter( 'debug_information', 'reset_site_health_info', 11 ); function reset_site_health_info( $info ) { $msg = ' (Debug value reset to default to prevent PHP warnings due to a bug in the Solid Security Basic 9.3.2 release).'; $info['solid-security']['fields']['settings']['debug'] = $info['solid-security']['fields']['settings']['value'] . $msg; $info['solid-security']['fields']['user_groups']['debug'] = $info['solid-security']['fields']['user_groups']['value'] . $msg; return $info; }
Hi @cp_so,
Temporary workaround:
add_filter( 'debug_information', 'reset_site_health_info' ); function reset_site_health_info( $info ) { $info['solid-security']['fields']['settings']['debug'] = $info['solid-security']['fields']['settings']['value'] . ' (Debug value reset to default to prevent PHP warnings due to a bug in the Solid Security Basic 9.3.2 release).'; return $info; }
- This reply was modified 10 months, 1 week ago by nlpro.
Hi @cp_so,
It’s a(n easily reproducible) bug in the add_site_health_info() method which is located in the better-wp-security/core/modules/core/class-itsec-core-admin.php file. The plugin method is returning an array() value instead of a string value for debug data (key settings).
Note the PHP warning(s) are visible in the (debug) output generated by the Copy site info to clipboard button.
+++ To prevent any confusion, I’m not SolidWP +++
If PHP blocking is enabled within the plugin,
it may result in a 403 error and disrupt the website’s functionality.
If the file “plugins/litespeed-cache/guest.vary.php” includes a vulnerability your site could be hacked.
Exclusions can potentially enlarge the attack surface of your site.
+++ To prevent any confusion, I’m not SolidWP +++
Hi @mohsinworld,
According to the 6.3.0 Changelog:
Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.
+++ To prevent any confusion, I’m not SolidWP +++
- This reply was modified 10 months, 3 weeks ago by nlpro.
Hi @soloant,
Can you share the exact Solid Security plugin version being used?
+++ To prevent any confusion, I’m not SolidWP +++
Excellent response (enjoyed reading it). Definately worth earning back the missing stars in this review. I guess we can’t help people that don’t want to be helped;-)
Hi @chrishechler,
I recommend reading (if not already) the Solid Security Hide Backend article from the Solid Help Center.
+++ To prevent any confusion, I’m not SolidWP +++
Hi @wmamber,
Usually this error indicates the current user does not have the required capability to access the page.
The “Sorry, you are not allowed to access this page.” error is actually a WordPress core error message. It’s triggered from line # 380 in the wp-admin/includes/menu.php file (WordPress 6.5.2).
Interestingly there is a WordPress core action that you can hook into (for eg debugging) right before the error is triggered. It’s the admin_page_access_denied action. This action will allow you to figure out why exactly the WordPress core user_can_access_admin_page() function is returning false.
+++ To prevent any confusion, I’m not SolidWP +++
- This reply was modified 11 months, 2 weeks ago by nlpro.
Hi @sebastienserre,
Navigate to Security > Settings > Advanced > System Tweaks
Disable (if not already) the?Disable PHP in Themes?setting in the?PHP Execution?section. Scroll to the bottom of the page and save the settings.
+++ To prevent any confusion, I’m not SolidWP +++
- This reply was modified 11 months, 2 weeks ago by nlpro.