When Traffic Inspector is enabled, the firewall analyzes and blocks malicious and potentially harmful requests. Those are included form submissions, requests with GET and POST parameters, requests to PHP scripts.

If the firewall detects a malicious or a possibly harmful request, the WP Cerber blocks the IP address, processing of the request is aborted and the 403 Access Forbidden response is generated. Such events are logged to the Activity log and if Traffic Logging is enabled, request details are logged to the Live Traffic log.

Little or no performance overhead

WP Cerber is designed with performance and security in mind. WP Cerber’s firewall does not slow down the performance of WordPress and doesn’t affect your website’s SEO ranking as well as search engine indexing because the firewall doesn’t inspect and doesn’t block ordinary requests to ordinary WordPress pages that visitors’ browsers or search engines’ crawlers do. 

What requests are not inspected and are not blocked

1. Requests that come from IP addresses in the White Access List if using the White Access List is enabled
2. Requests that are whitelisted in the Request whitelist setting field
3. Requests to ordinary WordPress pages, posts, categories and tags

How to exclude specific requests from inspection?

Sometimes, especially when you have a customized WordPress environment, or you have a plugin that utilizes a specific API, you might need to permit access to a particular PHP script without inspection by the firewall. In this case, if the plugin recognizes and marks a legitimate request as “Probing for vulnerable code”, you have to configure an exception.

Read more: I’m getting “Probing for vulnerable code”.

Alternatively, you can permit all requests from a particular IP address:

1. Add an IP address you trust to the White IP Access List
2. Go to the Traffic Inspector Settings page and enable Use White IP Access List

How to…

How to disable Traffic Inspector

To completely turn off the inspection go to the Traffic Inspector Settings page and disable Enable traffic inspection. Note: it’s not recommended, by doing that you turn off an essential protection layer for your WordPress. If you come across an issue with a php script, use the Request whitelist setting as described above.

Check out other WordPress security How to’s

A Denial-of-Service (DoS) attack is an attack meant to shut down a website or a web server, making it inaccessible to its intended users by flooding it with useless traffic (junk requests) from a single host (IP address). Sometimes DoS attacks are used for destroying computer defense systems. Some functionality of WordPress can be exploited as an attack vector for DoS attacks. For instance, CVE-2018-6389.

A DDoS attack is short for “Distributed DoS attack”. Such attacks are mounted by flooding the targeted website or web server with useless traffic from multiple devices or a botnet. A botnet is a network of computers infected with malicious software (malware) without the user’s knowledge, organized into a group, and controlled by cybercriminals. Modern botnets can contain tens of thousands of compromised mobile devices or desktop computers. Due to their nature, modern DDoS attacks are costly and require a lot of resources. Usually, that means you have a strong enemy that has enough gray money to order this kind of attack. Very often, mounting DDoS attacks are ordered by unscrupulous competitors or political opponents.

So, what’s the difference?

Technically they look different but from a website owner’s point of view, the difference is just in the goal of an attack.

Both, DoS and DDoS attacks have the same goal. And this goal is to push down the victim, the targeted website, or the web server and make a profit from that. Sometimes the DDoS attack is performing to destroy a defense system and obtain administrative access.

The goal of doing brute-force attacks is to obtain admin access to the targeted website to perform some illegal activity intruder/hacker wants to do. Their typical activities are:

• Redirecting legitimate users to fake websites to steal their personal data
• Creating phishing pages with payment forms that imitate legitimate ones on the victim website
• Stealing personal data from a customer database
• Installing backdoors and trojans on the webserver for using them as tools to attack other websites
• Installing malicious software to infect admin and customer computers
• Altering trustworthy website content to insert links to phishing websites

How do these attacks affect WordPress?

By default, WordPress allows unlimited login attempts through the login form, REST API, XML-RPC, or by sending special authentication cookies. This allows passwords to be cracked with relative ease via mentioned above brute-force attack.

How to protect WordPress and mitigate these attacks

Both brute-force and DoS attacks can be successfully mitigated with security software installed on a website. In both cases, you don’t need to be a nerd and can get that protection for free.

1. Brute-force attacks against WordPress can be successfully mitigated by WP Cerber plugin. Among other security features, it protects XML-RPC and REST API interfaces.
2. DoS attacks can be mitigated with a special web server configuration. You can’t achieve that by installing a security plugin. The best practice is using NGINX rate limiting rules. Check out our recommendations: Turn your WordPress into Fort Knox.

Unfortunately, DDoS attacks cannot be mitigated on a web server level or just with a WordPress plugin. DDoS attacks can be successfully mitigated only with special hardware installed on the hosting provider network. Due to their nature, mitigating DDoS attacks require a lot of computational resources and provided as a service from hosting providers on a subscription basis. Unlike brute-force and DoS attacks, there is no guarantee that all DDoS attacks will be successfully mitigated. Everything depends on how powerful the attack is, how powerful an anti-DDoS system is and what amount of network bandwidth the security provider can allocate.

One of the most affordable solutions for protecting WordPress from distributed DoS attacks is using Cloudflare services. But there are some disadvantages you should know and consider. Cloudflare will have control over all your DNS records for your domain, web traffic to and from your website including personal data of your customers because all traffic and all that data go through the Cloudflare proxy servers in unencrypted form. Some users reported that Cloudflare even had issues with owners being blocked out of their websites. So, if you have no issues with DDoS, like many of us, there is no reason to add one extra layer that can generate additional pain in the neck.

Once you’ve decided to go with Cloudflare, we recommend using a special Cloudflare add-on for WP Cerber.

Catch up an intruder

Cerber shows additional WHOIS information about the intruder IP address in the WordPress dashboard

You can easily identify a physical source of an attack – a computer, a mobile device, etc.

If you have WP Cerber Security & Antispam installed, check out this post: Know more about intruder’s IP. The most disappointing thing is that the vast majority of those attacks cannot be traced back to a real performer or a master. Every attempt to trace them back ends up with a set of infected personal computers and mobile devices that are used as puppets, intermediate points for an attack.

Some of the following steps might be a cause of some incompatibility issues with some weird plugins that try to modify files directly in the WordPress folders. I recommend ignoring any plugins that kind, because using them may lead to a lot of problems and security issues immediately or in the future, when hackers studied holes in the plugins or theme which is installed on your site. I’ve created this article in the hope that it will be useful, but without any warranty.

Note: this article is not applicable if you are using shared hosting. You need to have, at least, VPS hosted site.

Requirements: root access to the Linux server where your website is hosted on. If you don’t have shell access with root privileges you can’t do anything useful to create a real protected website. There are no way or any plugin that can protect WordPress and files in its directories at a PRO level. All security plugins have the same level of privileges (permissions) as hackers and bots have. No exception. If some security plugin made some changes in files of your website to protect them, any hacker or malicious code can UNDO those changes or remove protection.

Here are some important points about my approach

• All code files (PHP code) and all .htaccess files must be write protected. No exception
• We need to change all defaults (folder, cookies, login path, any other landmarks) to different values
• We must not use plugins or themes that operate with and try to change PHP or .htaccess files in the WordPress folders

Step one. Installing WordPress

Don’t use the default wp_ prefix for database tables. Use couple or three alphabet symbols instead. Some WordPress specific attacks and attackers make the assumption that the table prefix is wp_. Changing prefix helps us to block some SQL injection attacks.

Step two. Hardening the website at the WordPress level

1. Move the uploads folder up one level, from the inside of /wp-content/ folder to the root of your WordPress installation folder.
2. Rename the uploads folder to media (or something like that, whatever you want).
3. Rename the wp-content folder to content (or something like that, whatever you want).
4. Rename the plugins folder to mod (or something like that, whatever you want).
5. Add the following lines to the beginning of the wp-config.php file, don’t forget to change media , content , mod to actual values you previously choose.

   define('AUTOMATIC_UPDATER_DISABLED', true ); // yes, it's safe to do it manually
   define('DISALLOW_FILE_EDIT', true ); // we never allow anyone touch your files
   define('DISALLOW_FILE_MODS', true ); // yes, it's safe to do it manually
   define('FS_METHOD', 'direct'); // no FTP of course
   define('WP_HTTP_BLOCK_EXTERNAL', true );
   define('UPLOADS', 'media' ); // we renamed uploads and moved it level up
   define('WP_CONTENT_DIR', '/path/to/wordpress/dir/content'); // no host name, no trailing slash
   define('WP_CONTENT_URL', 'http://example.com/content');
   define('WP_PLUGIN_DIR', '/path/to/wordpress/dir/content/mod'); // no host name, no trailing slash
   define('WP_PLUGIN_URL', 'http://example.com/content/mod');
   ini_set('display_errors',0); // turn Off display PHP errors on the front-end
   

Step three. Change default cookies name.

Add these lines to the beginning of the wp-config.php file

define('USER_COOKIE', 'my_user_cookie' ); // change it to something different
define('PASS_COOKIE', 'my_pass_cookie' ); // change it to something different
define('AUTH_COOKIE', 'my_auth_cookie' ); // change it to something different
define('SECURE_AUTH_COOKIE', 'my_sec_cookie' ); // change it to something different
define('LOGGED_IN_COOKIE', 'my_logged_cookie' ); // change it to something different
define('TEST_COOKIE', 'my_test_cookie' ); // change it to something different

Step four. Install a security plugin immediately after WordPress has been installed

Protect your login page with WP Cerber Security. Even with those protection steps above, hackers will be trying apply brute force attacks (login attempts) to crack the door on your WordPress website. Hide and close this door with WP Cerber.

Step five. Hardening the website at the server level.

On this step I assume that you are using server with Apache as http server. We need to change owner of all WordPress files including plugins and themes. By default this user is apache. We need to change it to another user, you have created for this purpose before. Let’s say this user is cerber.

1. Put the .htaccess file to the media folder (your new uploads folder) with the following directive in it. That prevents website from executing uploaded malicious PHP code.

   php_flag engine off

   Note: The Apache configuration file must contain  AllowOverride Options directive for your uploads folder or any of its parent folder to get this directive working.

2. For the entire website directory (/path/to/wordpress/dir) change the owner and permissions for all files. To do that execute the following commands in the shell.

   find /path/to/wordpress/dir -exec chown cerber:root {} +
   find /path/to/wordpress/dir -type d -exec chmod 755 {} +
   find /path/to/wordpress/dir -type f -exec chmod 644 {} +

3. For the uploads directory (/path/to/wordpress/dir/media) we need toset special permissions. Let’s do that using exec commands in the shell

   find /path/to/wordpress/dir/media -exec chown cerber:apache {} +
   find /path/to/wordpress/dir/media -type d -exec chmod 775 {} +
   find /path/to/wordpress/dir/media -type f -exec chmod 664 {} +

4. Setup the permalink structure in the WordPress Settings and then change permission for .htaccess file to write protect it.

   chown cerber:root /path/to/wordpress/dir/.htaccess
   chmod 644 /path/to/wordpress/dir/.htaccess

5. Move the wp-config.php file to the directory above your WordPress installation directory.

Step six. Hardening the website at the NGINX server level

Read here: Hardening WordPress with WP Cerber and NGINX

Step seven. Hardening the website with Fail2Ban

Read here: How to protect WordPress with Fail2Ban

Disable REST API

The plugin restricts access to the WordPress REST API. The ability to send invisible requests to the core of your WordPress makes hackers even happier than the ability to hack websites using XML-RPC. If you don’t use WordPress REST API, disable it!

Check Allow REST API for logged in users if you want to allow using REST API for any authorized WordPress user without limitation.

The detailed instruction: Restrict access to WordPress REST API

Why it’s important to restrict access to the WordPress REST API

Disable XML-RPC

The plugin blocks access to the XML-RPC server including Pingbacks and Trackbacks. Do you know that hackers use this hidden entrance to find out logins stealthily? Do you have a CAPTCHA or reCAPTCHA on your login form to protect from bots? Don’t be silly, modern bots use XML-RPC and WP REST API to brute-force your WordPress and you don’t even know how and when they do that because any CAPTCHA doesn’t work for XML-RPC requests. Nowadays XML-RPC makes hackers happy and they love it a lot. After activating this setting your website will return 404 Page Not Found for any XML-RPC requests unless you make an exception for hosts with White IP Access List.

Note: If you use the Jetpack plugin, which needs to communicate with wordpress.com, do not disable XML-RPC.

Stop user enumeration

The plugin blocks access to special author pages like /?author=N and ability to retrieve user data via REST API. Intruders and hackers can easily get all logins of all the users on your website just by scanning numbers from 1 to any number they want. This behavior is enabled in WordPress by design and hackers around the world love it a lot. After activating this setting your website will return 404 Page Not Found.

Disable feeds

The plugin blocks access to the RSS, Atom, and RDF feeds. This does not allow hackers to find out what kind of software is installed on your website and collect additional helpful information to adjust further attacks to your WordPress. After activating this setting your website will return 404 Page Not Found.

Note: All these settings above do not affect hosts in the White IP Access List and you can easily allow, for instance, publishing posts via XML-RPC for IP address of your home computer just by adding it to the White IP Access List.

If you have root access to your web server, it’s recommended using these tips: Hardening WordPress with WP Cerber and NGINX

Read more about attacks: Brute-force, DoS, and DDoS attacks – what’s the difference?

Note: you have to have the root access to your Linux server to setup Fail2Ban.

With WP Cerber Security you have three options to use Fail2Ban

1. Using HTTP 403 response headers if you want to monitor Apache access log
2. Using syslog files to monitor failed login attempts
3. Using a custom log file to monitor failed login attempts

Monitor Apache access log for HTTP 403 responses

When an attempt to log in fails WP Cerber returns 403 response in the HTTP header. That response will be written in the Apache access log and those records may be monitored by Fail2Ban. That behavior of WP Cerber is enabled by default. The downside to this approach is that Fail2Ban has to parse the entire access.log in order to find those attempts.

Using syslog to monitor failed login attempts

By default, WP Cerber uses the LOG_AUTH facility when it logs failed attempts to the syslog file. However, you can specify a facility with your own value. To setup a new value you have to define the CERBER_LOG_FACILITY constant with an integer value. Note: to enable writing to the syslog or a custom file (see below) you have to enable Write failed login attempts to the file in the Activity section of the plugin settings.

define('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Using a custom file to monitor failed login attempts

If you want to write all failed attempts to any custom log file, you need to specify a file name with an absolute path using constant CERBER_FAIL_LOG. Don’t forget to set write permission for Apache process on the folder or log file and enable Write failed login attempts to the file. If the file does not exist, the plugin attempts to create it. If CERBER_FAIL_LOG is defined, the plugin doesn’t write messages to the default syslog.

define('CERBER_FAIL_LOG','/var/log/fail2ban.log');

Make sure that web server process (Apache) has permission to write to a specified file.

Additional info:

https://timnash.co.uk/using-fail2ban-wordpress/

http://www.fail2ban.org

https://www.digitalocean.com/community/tutorials/how-fail2ban-works-to-protect-services-on-a-linux-server

How to hardening WordPress using WP Cerber and NGINX together

First of all, you need to set up a Custom login URL and check Block direct access to wp-login.php and return HTTP 404 Not Found Error. Check out details here: How to rename wp-login.php. For security reasons, do not set up your custom login URL as “login” or “wp-admin”.

Then you need to block access to the wp-login.php file in the NGINX configuration file. By default, this file placed in the directory /etc/nginx, /usr/local/nginx/conf or /usr/local/etc/nginx.

Add this line to the server section of the NGINX configuration file for your site:

location /wp-login.php { return 404; }

If you don’t use XML RPC on your site, I highly recommend to add this line also:

location /xmlrpc.php { return 404; }

Finally, we protect our site and server from being overloaded by attacker’s attempts or automated attempts from stupid bots. Let’s do it using the ability of NGINX to limit the rate of inbound requests. Rate limiting allows you to slow down the rate of inbound requests beyond a specific threshold.

Open main configuration file nginx.conf and find the http section. Add the following line inside of it:

limit_req_zone $binary_remote_addr zone=main:10m rate=60r/m;

Then return to the server section of your site and find the line

location / {

add this line after opening curly brackets:

limit_req zone=main burst=10 nodelay;

Changes we have made in the configuration file will not be applied until the command to reload configuration is sent to nginx or it is restarted. To load the new configuration, execute in the command line of your server:

service nginx reload

Done!

Now, you and your backend server (powered by Apache maybe) can relax. These several easy steps allow you to clean up inbound traffic from “bad requests” and allow server’s resource to serve “right requests”.

Why it matters and why it works

According to our studies at Cerber Lab, most hacker tools and attacks are based on assumptions that a victim WordPress-powered website has the default login page, and plugins are located in the default folder. Although it’s recommended not to use default values on any website, many website owners ignore these simple principles, allowing hackers to attack them with success. And that’s why hackers so love WordPress, and at any given time, we see hundreds of thousands of hacked websites.

Configure your custom login page

WP Cerber enables you easily and safely change the default WordPress login URL wp-login.php to any URL you need. In other words, you can configure your unique, known-to-you custom login page (a custom login URL means the same in this context) and hide wp-login.php from bad actors, scanners, and bots. You don’t need to edit the .htaccess file or rename the wp-login.php file. With WP Cerber you can configure it in several clicks.

1. Go to the plugin Main Settings admin page.
2. Enter your new desired login URL into the Custom login URL field and saves settings. That’s it.
3. If you use a caching plugin, add your new login URL to the list of pages not to cache.
4. Make sure that your new login URL works correctly and you can use it to log in. Do that in an incognito browser window. Do not log out from your website until you make sure that your new login URL works well.

Custom WordPress login page settings

How to hide wp-login.php from bots and scanners

Once you’ve enabled the customer login page, it makes sense to hide the default WordPress login page to prevent mounting brute-force attacks on it. To achieve this, set the Processing wp-login.php authentication requests setting to “Block access to wp-login.php”. When attempting to access the page, WP Cerber will render the standard “404 Not Found” page. There is only one downside you should think about. If an attacker is smart enough, they may continue scanning the website, searching for your real login page.

How to disable wp-login.php

Another more advanced option you should consider is disabling wp-login.php without blocking access to it. How does it work? This unique WP Cerber feature stops any attempt to authenticate through wp-login.php. When attempting to log in, WP Cerber mimics the default incorrect password error and aborts the user authentication process. It doesn’t matter what password is entered; nobody is allowed to log in even with the correct password. To enable this feature, set the Processing wp-login.php authentication requests setting to “Deny authentication through wp-login.php”.

A caution to remember

If you or your user forget that wp-login.php is disabled and cannot be used for logging in, you or your user will never be able to log into the website and will get locked after several attempts to use wp-login.php.

If you have set “Processing wp-login.php authentication requests” to any value other than the default one, you can only use your custom login URL. Neither /wp-login.php nor /wp-admin/ can be used for logging in anymore.

Important things you need to know

• If you use a caching plugin like W3 Total Cache or WP Super Cache you have to add the slug of the new Custom login URL to the list of pages not to cache.
• For a WordPress multisite installation, the new login URL is set for all sites globally.
• Do not delete or rename the wp-login.php file manually. After updating your WordPress to a newer version, wp-login.php will be restored and accessible for intruders again.

Get it more secure with Two-Factor Authentication

Consider enabling 2FA to protect admins’ accounts. Two-Factor Authentication provides an additional layer of security requiring a second factor of identification beyond just a username and password.

Know more: How to enable Two-Factor Authentication for WordPress

Troubleshooting the Custom login URL feature

Enabling the custom login page may cause some plugins to stop working. If you use a login page customization plugin or a social login plugin, it’s possible such a plugin doesn’t work anymore. To fix this issue, enable “Defer rendering the custom login page”. Read more about this setting.

If you’ve set up your Custom login URL and after a while forgot it, first of all, check the site admin email box for a notification email about your new login URL or any email weekly report. In those emails, you can see your Custom login URL. If you are unable to find such a email, you need to reinstall WP Cerber manually following the steps below.

1. Delete the plugin folder /wp-cerber/ manually by using FTP or any File Manager in your hosting control panel.
2. Log into your WordPress dashboard as usual by using default /wp-login.php URL or another way that you used to use prior enabling the Custom login URL.
3. Install and activate the WP Cerber Security plugin as usual.
4. Go to the plugin Main Settings page.
5. Check the Custom login URL field. It displays your Custom login URL that you have to use. Remember it.

Next steps that’ll strengthen your WordPress security

• How to hide wp-admin and wp-login.php from possible attacks
• How to block spam user registrations
• How to block spam form submissions
• How to block access to WordPress REST API
• How to block specific usernames

1. Open WP Cerber main settings page.
2. Turn on Disable automatic redirection to the login page when /wp-admin/ is requested by an unauthorized request
3. Enter your desired custom login URL into the Custom login URL field
4. Turn on Block direct access to wp-login.php and return HTTP 404 Not Found Error
5. Save settings

Settings to hide wp-admin and wp-login.php