nlpro

Hi @skunkworks,

Just wanted to add 2 relevant pieces of info:

• Adding the ITSEC_DEBUG constant to the wp-config.php will also add a new Debug submenu option to the Solid Security plugin main Security menu. That is the Debug page @shanedelierrr is referring to.
• The Security Digest email is not send when there is nothing to report (even when the Debug page shows that it’s scheduled). Which totally makes sense. Nothing to report means, there have not been any lockouts nor any detected file changes since the last send Security Digest email.

Based on the fact that you changed the wp-config.php file, the File Change module should have picked up that change, consequently sending the Security Digest email. That is, if the File Change module is enabled!

I know the last Security Digest was in French language, but (if not deleted yet) please check it’s content (use Google translate if you have to). The email content will tell us what security event/feature triggered that Security Digest email to be send (lockout(s) and/or file change(s)).

• This reply was modified 8 months ago by nlpro.
• This reply was modified 8 months ago by nlpro.

Hi @rockso,

You may be interested in reading this topic.

+++ To prevent any confusion, I’m not SolidWP +++

Hi @skunkworks,

The Security Digest email is a so called scheduled email. The SolSec plugin scheduled emails check callback is hooked to the WordPress core init action. This means that there is a scheduled emails check performed on EVERY request to the site. If a scheduled email is due it gets send.

Now it is possible to add some extra debug info at the bottom of every (non-user) email send. It is useful for identifying what site request triggered the email to be send (eg WP Cron job or a site request URL). You simply add the line below to the wp-config.php file:

define( 'ITSEC_DEBUG', true );

As an example, if an email being send was triggered by WP Cron you’ll find at the bottom of the email:

Debug info (source page): WP-Cron

Other source page values include WP-CLI, unknown or the full URL of the request that triggered the email to be send. The latter is probably what you’ll get to see by default in the Security Digest email. I guess that if the locale is set to France in the context of the request the email will be send in French language.

Alternatively you can offload the SolSec plugin scheduled emails check to WP Cron by adding the line below to the wp-config.php file:

define( 'ITSEC_NOTIFY_USE_CRON', true );

Apart from the performance gain perhaps this will also help making the Security Digest email language more constant.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 8 months, 2 weeks ago by nlpro.
• This reply was modified 8 months, 2 weeks ago by nlpro.

Hi @shanedelierrr,

I was wondering whether you received any feedback from the Dev team regarding my suggestion?

Hi @boabo,

Temporarily setting the Days to Keep Database Logs (and/or Days to Keep File Logs) Global Settings setting (Security > Settings and then scroll down to the Logging section) to 0 should allow you to achieve what you want.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 8 months, 3 weeks ago by nlpro.

Hi @thenoxx,

Ah right, it definately was a busy sportsweekend (EK soccer, Tour de France, Formula 1, TT etc). Phew, I’m more tired now than at the start of the weekend ??

If the user has the administrator role assigned then it’s always possible that the edit_posts capability is (dynamically) removed for that user at WordPress init when logging in. Another possibility is that this user has a custom administrator role assigned which does not include the edit_posts capability. Are there any custom roles defined or is there any roles management plugin installed?

WordPress by default only uses the following 5 roles:

• administrator (beheerder)
• editor (redacteur)
• author (auteur)
• contributor (bijdrager)
• subscriber (abonnee)

By default only the subscriber role does not include the edit_posts capability.

Interested to hear what you can find.

• This reply was modified 8 months, 3 weeks ago by nlpro.
• This reply was modified 8 months, 3 weeks ago by nlpro.

Hi?@thesweetsguy,

Try this. Navigate to Security > Settings > Advanced > System Tweaks

Disable (if not already) the?Disable PHP in Plugins?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 +++

Hi @thenoxx,

Further testing allowed me to reproduce the Site Health REST API recommended improvements entry.

Turns out it is not caused by the Solid Security REST API setting (which in a way makes sense). In fact it’s not caused by the Solid Security plugin at all!

The true cause is that the user you are logged in with when accessing the Site Health page does not have a role assigned that includes the edit_posts (possibly other capabilities) capability.

All I needed to do is (temporarily) remove the edit_posts capability from the (WordPress core) administrator role. Log into the WordPress Dashboard as a user which has the administrator role assigned and then navigate to the Site Health page.

Adding the edit_posts capability back to the (WordPress core) administrator role cleared the Site Health REST API recommended improvements entry instantly ??

Hi @thenoxx,

No worries, we all make mistakes (live & learn) ??

After correcting the 2 typos in the endpoint url and then trying it out I got the following result:

{“code”:”itsec_rest_api_access_restricted”,”message”:”Je hebt onvoldoende rechten om dit endpoint te benaderen. Toegang tot REST API aanvragen is beperkt door Solid Security instellingen.”,”data”:{“status”:401}}

This means this particular REST API endpoint is restricted by the Solid Security plugin API Access -> REST API setting (Restricted Access).

( Full navigation path: Security > Settings > Advanced > WordPress Tweaks).

Strangely on my test site I have the same plugin setting but no REST API recommended improvement in the Site Health page.

I did swap out your domain for my domain. Basically tested the same endpoint on my test site and I got exactly the same message (at least that is consistent).

You might try (if possible) and set the REST API setting to Default Access. Would be interesting to see whether this removes the REST API recommended improvement entry in the Site Health page.

Hi @thenoxx,

Since your posted screenshot is too blurry to read (and also translated in Dutch) could you please provide the missing details indicated by the 2 question marks (?) below?

The REST API encountered an unexpected result (Performance)

The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.

When testing the REST API, an unexpected result was returned:

REST API Endpoint: ?

REST API Response: ?

Perhaps it’s best to temporarily switch WordPress to language English (United States), then recreate the Site Health screenshot (with a higher resolution) and post that into this topic.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 9 months ago by nlpro.
• This reply was modified 9 months ago by nlpro.
• This reply was modified 9 months ago by nlpro.

Hi @rhettfinck,

No, the plugin UI only allows you to change the subject and/or message of the email.

However, you should be able to hook into the wp_mail filter and change anything about any email send using the WordPress Core wp_mail() method/function.

+++ To prevent any confusion, I’m not SolidWP +++

• This reply was modified 9 months, 1 week ago by nlpro.

Hi @szilard21,

Please have a look at the Brute Force Protection and Banned Users Blog post (if not already). In case there are any questions left after reading the Blog post just let us known.

+++ To prevent any confusion, I’m not SolidWP +++

@shanedelierrr,

Thank you for letting me know. Appreciate it.

Just to add to my case, the key names used for these 3 settings are:

blacklist (Ban Repeat Offender)
blacklist_count (BAN THRESHOLD)
blacklist_period (DAYS TO REMEMBER LOCKOUTS)

Again confirmation these are one group of related settings ??

@shanedelierrr,

Just like the display of the BAN THRESHOLD?setting is based on the value of the Ban Repeat Offender?setting shouldn’t this also apply for the DAYS TO REMEMBER LOCKOUTS?setting? Both of these settings are exclusively tied to the IP banning feature. Also a chance to streamline the names and labels of these settings eg:

V Ban Repeat Offender

Permanently add a locked-out IP address to the “Ban Users” list after reaching the configured “BAN THRESHOLD” within the configured “BAN THRESHOLD PERIOD” timeframe.

BAN THRESHOLD

3

The number of lockouts Solid Security must remember before permanently banning the attacker.

BAN THRESHOLD PERIOD

7

The number of days Solid Security must remember lockouts before permanently banning the attacker. This does not affect the logs generated when creating a lockout.

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.