CleanTalk, the launch of WordPress security

While developing the Anti-Spam service, we often encounter other issues related to the security of websites. The most common questions were about brute force attacks. In addition to problems with the selection of passwords for the administrator account, often brute force attacks cause a high load on the server, and users receive notification from the hosting about exceeding the allowed load values for the processor.

We thought if we are receiving such requests, why don’t we solve them? Since tasks relate to security functions, the decision to launch a separate security service was obvious.

At the moment, the Security service is developed only under WordPress, there are several reasons for this: the greatest demand, a large number of websites use this particular CMS, the complexity of the development of several CMS.

Despite the fact that anti-spam protection is a part of security, we decided to split these two services. There are several reasons for this:

1. Complication of the plugin, which leads to increased errors, compatibility issues with other plugins/themes
2. Promotion by search queries
3. Easier development and independent release of updates
4. The interface of the plugin is not complicated by a bunch of additional options that are not needed if the user uses only one function
5. A separate management interface and logging in the control panel CleanTalk

We decided to start with the implementation of protection against brute force attacks and further gradually expand the functionality.

Protection from brute force attacks – implemented by adding delays between incorrect authorization attempts. A delay of 3 seconds is set for the first attempts, for a subsequent one in 10 seconds. If there were 10 unsuccessful attempts of authorization within an hour, the IP address will be added to the FireWall database for 24 hours. To protect against hackers trying to find a password for your account, this is enough, since they significantly increase the time between attempts, and they can be tens or hundreds of thousands. All logs of access attempts are available in the weekly report and in the service control panel, which allows you to quickly add IP addresses to the FireWall blacklist. Protection against brute force attacks extends only to users with administrator rights.

Traffic control – allows you to view information about visitors, such as:

• IP
• Country
• Date/time of the last query
• The number of allowed/blocked HTTP requests
• Status-banned or allowed
• The URL of the page visit
• User Agent

Another option in traffic Control — “Block visitor if the number of requests is greater than” – blocks access to the site for any IP that exceeds the number of HTTP requests per hour. The number of requests can be set in the settings, the default is 1000. If the IP is exceeded, the Firewall will be added to the Blacklist for 24 hours.

This will help solve the problem of DoS attacks on the site when a large number of HTTP requests are sent to the site, because of which it stops responding or starts to work very slowly. This situation is possible because of a massive brute force attack.

Audit log – allows you to monitor the actions of users in the admin WordPress, keeps a log of visits to pages with the date/time and length of stay. Allows you to monitor the actions of administrators and unauthorized access and in case of problems to understand where by whom and what changes have been made.

Malware Scanner – scans WordPress files, plugins and themes for malicious code and changes. If the changes in the files were made illegally, it allows you to restore the original files.

Automatic scanning takes place every 24 hours, and you can also start it manually.

Security FireWall – blocks access to the site for POST/GET requests by IP addresses. Base IP addresses for the FireWall is generated from our database of blacklists CleanTalk. It is possible to get IP addresses that have a high spam activity or was seen in attempts brute force attacks. It is possible to use their own blacklists, both for individual IP addresses/subnets and by country. Due to this, it is possible to reduce the load on the website or to block a DOS attack.

Ready to release:

• outbound link scanner
• checking links against a database of domains that are promoted with spam
• protection from XSS and SQL injections

Development notes

Everything was written from scratch, not peeking at other solutions. This was done specifically to not to pick up other people’s mistakes and to develop your own vision for the application.

Further development for other CMS is planned, so it was decided to develop a modular design. Use an object-oriented approach and everything like that. Of course, in the process had to solve various problems that do not fit into this concept and did not do without a workaround.

As a result, there are several classes that without significant improvements can be used on other CMS (including self-recording), using a couple of wraps, for example for the database.

Was written our own class Cron is not dependent on Cron WordPress. Still, the application for security and should not rely on functionality that may or may not work, or which may interfere with the work of third-party developers.

To implement heuristic code analysis, we have written our own code minimizer parser, which will continue to develop. With it, you can track dangerous variables, functions, constructions. Not sure if other plugins/anti-viruses/applications use similar solutions (probably not), but this pros and cons of independent development, our approach may have turned out unique.

Example of the “minimizer”:

Source code:

<?php
	//$some = 'n'.'o'.'t'
	$some = 's'.'o'.'m'.'e'; // String concatenation
	$stuff = 'stuff';
	
	$first = 'first';
	$func = 'func';
	
	$first_func = $some."$first$func"; // Variable replacement
?>
$some = 'n'.'o'.'t';
<?php
	// Variable replacement
	$i = 'i';
	$c = 'c';
	$o = 'o';
	$co = $c.
	// some obfuscating comment
	$o;
	$ico = $i/* some obfuscating comment */.$co;
	
	require($some.'_'.$stuff.'.'.$ico);
	require($some.'_'.$stuff.'.php');
	require($some.'_'.$stuff.'.p'.$ico);

	$first_func();
?>

Result:

<?php $some='some';$stuff='stuff';$first='first';$func='func';$first_func='somefirstfunc';$i='i';$c='c';$o='o';$co='co';$ico='ico';require'some_stuff.ico';require'some_stuff.php';require'some_stuff.pico';somefirstfunc();?>

If you bring in a more understandable form:

<?php 
	$some='some';
	$stuff='stuff';
	$first='first';
	$func='func';
	$first_func='somefirstfunc';
	$i='i';$c='c';$o='o';
	$co='co';
	$ico='ico';
	require'some_stuff.ico';
	require'some_stuff.php';
	require'some_stuff.pico';
	somefirstfunc();
?>

Some things that it can do: do concatenation, substitute variables, track the origin of variables (let’s say if they use unreliable $ _POST and $ _GET), track and check the file connections (include, require) for various parameters and much more. We can say that this is the basis on which the functional will be added.

Especially I did not like to support WPMS, because for each functional I had to make exceptions taking into account whether the main site is this, whether the user of the secondary site inherits the key from the main site or enters his own access key, whether the secondary site allowed to activate plug-ins and the like. Unfortunately, we had to remove part of the functionality for WPMS and secondary sites due to non-compatibility.

In general, it turned out a beautiful application in places from the point of view of the code, which we will develop in the future.

The plugin itself can be found in the directory.