Getting back into the WordPress dashboard

If WP Cerber blocks your attempts to log in and you are unable to get into your WordPress dashboard, you need to log in by using a different Internet connection. For instance, use a mobile device instead of a landline (fiber) connection and vice versa. You can also use a different Internet provider. Alternatively, you can use your home Internet connection instead of an office one. The goal is using a different IP address. If this approach does not work, scroll to the last section of the article.

Once you’ve logged in, check the Activity log. In this article we describe two options.

Viewing all login issues

Go to the Activity log and click the “Login issues” button in the button bar above the log. WP Cerber will show you recent failed and denied attempts to log in. Now, inspect the information in the “Event” column.

You can see “Login failed” if invalid credentials were used. In most cases, it means an incorrect password. WP Cerber is not involved here because it doesn’t authorize users. Users are authorized by WordPress. In some cases, users are authorized by a plugin via a third-party service e.g., a social network.

If you see the “Attempt to log in denied” event, it means that WP Cerber denied the attempt to log in due to some violations. To understand the reason, see the label next to “Attempt to log in denied”. For instance, you see “IP address is locked out”. This means that at that moment the IP address used for logging in was locked out by WP Cerber. To get more details, click the IP address in the row. You will see all events related to the IP address. To view all login activities of the user, click the username in the “Username” column.

Checking login issues with a specific user account

To understand why a user has issues with logging in, go to the Activity log, start typing the username (login and email work as well) in the “Filter by registered user” field to find the user. Select the user from the drop-down list and click the “Filter” button. WP Cerber will show you a user panel and logged user activity.

On the right part of the user panel, a quick breakdown of user activity is shown. It contains clickable labels of user events. To get the list of all denied by WP Cerber attempts to log in, click “Attempt to log in denied”. If there is no such label on the panel, WP Cerber have not blocked the user at all.

For any “Attempt to log in denied” event WP Cerber shows a label that tells you the reason for it. For instance, you see “IP address is locked out”. This means that at that moment the IP address used for logging in was locked out by WP Cerber. If the IP address is still locked out, it is marked with a red square icon in the leftmost column of the log. You can unblock the IP address on the Lockouts tab.

If you click the “Login failed” label, you see all the user attempts to log in with an incorrect password. Please note that after the specified in the login security settings number of allowed attempts, the IP address of the user gets locked out. Currently locked out IP addresses are marked with the red square icons in the leftmost column of the log. If the current user IP address has such an icon in the log, the user is not allowed to log in. You can unblock the IP address on the “Lockouts” tab.

You’re still unable to log in

In the worst case, you can get the forbidden page “We’re sorry you are not allowed to proceed”. If you get it after an attempt to log in, it indicates a serious incompatibility or misconfiguration issue. That can happen if a third-party login form is in use. For instance, a login form generated by a plugin or a login form as a widget generated by a page builder (website builder). In such a situation, you need to use the default WordPress login page, which is /wp-login.php or the Custom login URL specified in the WP Cerber settings. If none of them let you log in, you, as a last resort, can delete the plugin folder, which is wp-cerber, log in as usual and install WP Cerber again. WP Cerber configuration and your settings will not be affected. Once you have WP Cerber reinstalled, disable “Protect all forms on the website with bot detection engine” in the anti-spam settings and/or Custom login URL in the Main settings. One of them can cause the issue.

To get the user switching feature to work again, go to the Main Settings, and enable “Deferred rendering” in the Custom login page setting section. Once you’ve enabled this setting, check if your custom page works with no issues.

What this setting affects

If “Deferred rendering” is enabled, most of the active WordPress plugins can execute their code to alter the custom login page, load JavaScripts scripts and CSS styles on the page before WP Cerber. WP Cerber’s code is invoked and executed after those plugins. Do not enable this setting without necessity.

Unfortunately, not all 404 pages generated by visual page builders are compatible with WP Cerber. In such cases, the only option you have is to select “Display simple 404 page”. Do it in the “Site-specific settings” section located on the “Main Settings” tab.

This page is not elegant as it can be in case of rendering it by your theme, but in the vast majority of cases, WP Cerber renders 404 pages for bots and cybercriminals when they try to get access to prohibited areas on your website. With proper website navigation and menus in place, your customers and website visitors never see this 404 page or see it on a rare occasion.

Why the simple 404 page is better

Using a basic 404 page is the better option in terms of performance when your website is under attack.

When it comes to rendering a fancy 404 page for an occasionally lost visitor, it does not consume a lot of server resources, since visitors do not get lost all the time. However, we have a different situation when the website is under a massive hacker attack with numerous malicious requests.

For instance, a brute-force or a denial-of-service attack. For each of those requests, WP Cerber loads your active WordPress theme and, if it’s installed, a visual page builder just to render the fancy 404 page and show it to cybercriminals and attacking bots. Those attempts to break into your website can easily bring your web server down to its knees.

Another advantage of using simple 404 pages is better security because it makes it harder for attackers to retrieve information on what exactly software and security mechanisms are used on the website and how to bypass them in a less complicated way.

That’s why for all our web projects, we configure WP Cerber to use a simple 404 page.

When WP Cerber blocks a suspicious request, a forbidden message is displayed, and the RID is shown as well. When you see such a message, and you know that this legitimate request should not be blocked, you can use the RID to find the reason why WP Cerber blocked it and made adjustments to the plugin’s settings to prevent such requests from being blocked.

Typically this message is shown when a request is blocked either by Cerber’s Anti-spam engine or by the Traffic Inspector firewall.

Use RID to understand what happened

Once you’ve got a forbidden message similar to the shown below, copy the RID from the message and go to the WP Cerber Activity log.

WP Cerber’s WAF firewall message: We’re sorry you are not allowed to proceed (403 HTTP Forbidden)

On the Activity log page click the link More. Paste the copied RID into the Request ID field, and click Filter. Now you get the log entry and see why the request was blocked. On the first screenshot, we see the reason “Probing for vulnerable code”, and that means the request was blocked by the Traffic Inspector firewall.

Using Request ID on the Activity log to find the request that was blocked by the WordPress firewall

On the next screenshot, we see the reason “Spam form submission denied”, and that means the request was blocked by the Cerber’s anti-spam engine.

Using Request ID on the Activity log to find out that the request was blocked by the WP Cerber’s anti-spam

Once you’ve got the reason

If you see that Traffic Inspector blocked the legitimate request: How to exclude requests from inspection by Traffic Inspector.

If you identify the Anti-spam engine as the cause: Configuring HTTP request exceptions for the antispam engine.

Read also: What to do if legitimate requests are being blocked.

Get more information on the IP address

Once you’ve found the request, you can get more information on activities and requests that came from the IP address. Click the IP address in the first column. The activity log will be filtered out by the IP and you’ll see what occurred earlier. On the screenshot, you can see that all requests from the IP were malicious and denied by the Cerber’s firewall. Also, we see that the IP address was blocked twice.

Inspecting the WP Cerber’s Activity log in the WordPress dashboard

Check requests from the network

If you click “Check for requests”, you’ll see all logged HTTP requests that came from the IP address and from other IP addresses in its network.

The log of requests from the selected network on the WP Cerber’s traffic log page in the WordPress dashboard

1. Enable diagnostic logging in the scanner settings

To do this, click the “Site Integrity” menu and then click the “Settings” tab, turn on “Enable diagnostic logging”, and save the settings.

2. Now start scanning

Manually or by configuring the schedule for the automatic scans.

3. Check the diagnostic log

Click “Tools” in the plugin admin menu and then click the “Diagnostic Log” tab. Check the log for error messages.

In case you need assistance from our customer service team, make a screenshot or/and export the log to a file by clicking the “Download as a file” link and attach it to a support ticket via the support desk: https://my.wpcerber.com

Hint: You can easily identify scanner entries in the log by the [Scanner] marker in a line.

Sometimes you might see this message in the server error log or have it displayed on a web page. It’s frustrating and looks like something’s wrong with the PHP script that is mentioned in the message. In fact, this message indicates a problem (a bug) in another script, plugin or a theme. You can get this message if you use a buggy plugin and displaying PHP errors is turned on, which normally should not be.

This message appears when some piece of PHP code on a website generates an output, which typically is a PHP warning message that should not be sent and shown in the users’ browser at all. And this output is sent before a header of the web page is generated and sent to a user browser. The header of a webpage can be empty or can handle additional information such as cookies.

Whether the header is empty or not, it must be sent before any page content.

If a buggy WordPress plugin generates a PHP warning before other plugins send headers to a browser, it leads to a server error with the message “PHP Warning: Cannot modify header information – headers already sent in …” .

Such a message can mislead anyone because it doesn’t tell what script or a plugin caused this error. When a web server detects any output generated by a plugin with no header sent, it creates the header automatically and sends it to the browsers, so all other plugins which don’t expect such behavior, are unable to send their headers if they need to.

How to solve this issue in the context of using WP Cerber Security

1. Disable error displaying in the PHP settings of your hosting control panel. If you don’t have access to PHP settings, ask your hosting provider for assistance.
2. Disable PHP error displaying in the WP Cerber settings on the Hardening admin page.
3. In the Main Settings of WP Cerber, set “Load security engine” to “Standard mode” or “Advanced mode”.
4. Check if the WP_DEBUG constant is defined in the wp-config.php file. Comment out the line with double slashes // or just delete the whole line. This is how it should look:
   // define( 'WP_DEBUG', true );
// define( 'WP_DEBUG', 1 );
5. Add the following lines to the beginning of the wp-config.php file:
   @ini_set( 'display_errors', 0 );
@ini_set( 'log_errors', 1 );

Can WP Cerber or WordPress be the cause of the issue?

No. The only code that can cause this issue is either an outdated/buggy plugin or the active theme. How to find the root cause? Check the server error log. And please get rid of outdated plugins.

In rare cases, scheduled background tasks are not executed properly and the size of the database tables is growing uncontrollably. To check the status of the tasks and make sure that all tasks are executed as they planned, do the following.

1. Click the WP Cerber admin menu and go to the Tools page
2. Click the Diagnostic tab
3. Scroll down to the “Maintenance Tasks” section

You should see a status similar to this

The status of Cerber’s maintenance tasks is OK.

If you see any error like “Task has never been executed”, that means there is a problem with running scheduled cron tasks on your WordPress. There are two options.

If you have not configured an external cron service, which is true in most cases, one of the possible solutions is to add the following line to the wp-config.php file:

define( 'ALTERNATE_WP_CRON', true );

If you (or your hosting provider) have configured an external cron service, you see the notice: “Note: the internal WordPress cron launcher is disabled on this site.”. In this case, any issues with maintenance tasks are caused by the external cron service that doesn’t work and doesn’t send (or stopped sending) special HTTP requests to the website. In this case, you should ask your hosting provider for assistance.

P.S. Normally, the internal cron is disabled by adding the following line to the wp-config.php file:

define( 'DISABLE_WP_CRON', true );

If you see legitimate requests that are denied as “Probing for vulnerable code”,  follow these steps: How to exclude requests from inspection by the Traffic Inspector firewall.

What part of WP Cerber can block those requests

WP Cerber has two security subsystems that screen and filter all inbound requests: the first one is a web application firewall called Traffic Inspector, and the second one is the Anti-spam engine.

How to identify which one of them

To find out the root cause of the issue, disable traffic inspection in the Traffic Inspector settings, and check if WP Cerber still blocks those requests. If requests are not blocked anymore, you need to turn on traffic inspection and adjust the Traffic Inspector settings as described here: How to exclude requests from inspection by Traffic Inspector.

If requests are still being blocked, turn on traffic inspection and disable “Protect registration form with bot detection engine” and “Protect all forms on the website with bot detection engine” on the Anti-spam settings page. Try to reproduce the issue and check if WP Cerber still blocks those requests. If requests are not blocked anymore, adjust anti-spam settings as described here: Configuring exceptions for the anti-spam engine.

An alternative way

First of all, enable traffic logging on the Traffic Inspector settings page. Then reproduce the issue and open the Live Traffic log page. Find legitimate requests that were blocked. Once you’ve found them check the reason why they were blocked. You should see one of these:

If you see Probing for vulnerable code, follow those steps: How to exclude requests from inspection by Traffic Inspector

If you see Spam form submission denied, follow those steps: Configuring exceptions for the antispam engine

How to exclude specific requests from inspection

All anti-spam exceptions are configured on the Anti-spam admin page.

To exclude a specific request (form submission) from inspection by the anti-spam engine, you need to specify a request path and, optionally, a query string (request parameters) in the Query whitelist setting field.

If a request URI starts with or equals any of the specified strings, it will no be inspected and blocked.

To create complex rules, you can use REGEX expressions. Please see further details below.

Some examples

Exception #1 Permits any requests with the Request URI that starts with the specified string e.g. /ps/wc-ajax=whatever_till_the_end

Exception #2 Permits any requests if the Request URI matches the specified REGEX pattern e.g. /file-upload.php?user_id=23432

Anti-spam for WordPress – configuring exceptions

How to identify the Request URI

Go to the Live Traffic admin page. Find a legitimate request you need to whitelist and take its Request URI from the Request column. If your Request URI contains dynamic GET parameters like on the screenshot below, you may need to use a REGEX expression.

Request URI on the Live Traffic page in the WordPress dashboard

Regular expressions

Query whitelist supports regular expressions, one pattern per line. To be excluded from inspection, the Request URI must match the whole REGEX pattern.

To specify a REGEX pattern, enclose a whole line in two { } braces. For instance, to exclude requests to a file-upload.php script with a numerical GET parameter user_id containing any number, specify this string:

{\/file-upload\.php\?user_id=\d+$}

Note: to specify the slash / character in a REGEX expression, you need to escape it with backslash \ this way: \/

WordPress anti-spam settings

How to disable anti-spam on a selected page

To avoid conflicts with third-party forms loaded from an external source and processed on a third-party website, you can configure exceptions for WP Cerber’s anti-spam by disabling its code on selected pages of your website. The list of pages is specified with a PHP constant CERBER_DISABLE_SPAM_FILTER. This constant should be defined in the wp-config.php file. Use a comma-separated string with page (post) IDs. If the list is configured, you see the list of pages on the WP Cerber anti-spam settings admin page. Here is an example of the list definition.

define( 'CERBER_DISABLE_SPAM_FILTER', '3, 45');

You need to use this feature if you have HubSpot forms on your website.

See also: How to stop spam user registrations on your WordPress