WordPress Hide-and-Seek: Why there is no point in obfuscating the use of WordPress

WordPress Hide-and-Seek: Why there is no point in obfuscating the use of WordPress

WordPress security is a broad subject. If you ask three experts, you will get four opinions. Everyone has had their own experiences and swears by their own solutions. There are areas that are particularly important when it comes to security and for which there are many plugin solutions. For example, securing the login. On the other hand, studies confirm that these areas are not the main gateways for attacks. Similarly, trying to disguise any signs of using WordPress. In today’s post, I would like to show an example of the simple things that obfuscation fails.

Obfuscate WordPress usage

There are many ways to tell when a website is built with WordPress. You may also be able to find out which version you are using. Some security plugins put a lot of energy into removing or obfuscating these notices on WordPress. The background is probably the hope that attackers would not use the typical WordPress attack vectors if it was not clear whether the website was WordPress.

However, observations of log files show that the vast majority of attackers don’t care what kind of website they are looking at. Since the attacks are automated, all possible security gaps are simply tried out. So it also happens that known Joomla gaps are tried out on a clearly recognizable WordPress website. For that reason alone, hiding WordPress usage makes no sense.

Thorsten Frommen has put together an impressive list of everything you can tell a website uses WordPress:

How to Detect WordPress Sites

The bottom line is: it’s impossible to disguise all signs of WordPress. I would like to go into one special element as an example: calling /wp-admin/admin-ajax.php. But first, a few other thoughts.

Secure WordPress login or not

Securing the WordPress login is an extremely time-consuming task, especially for beginners. There are a particularly large number of security plugins in this area in particular. The main focus is on preventing brute force attacks on the login (i.e. constantly trying out various passwords). Studies show, however, that the login area is not the sensitive element of a WordPress installation and that the vast majority of successful attacks are quite different from brute force attacks. Ernesto Ruge also wrote an article about this:

WordPress login security: A steel door in the corrugated iron shack

The best (and sufficient) protection of the login is the use of a strong password with at least 12 characters in length.

If the bots’ constant login attempts are getting on your nerves or if you find that server performance is suffering as a result of massive attacks, you can take further simple measures.

Although obfuscation is not a classic security measure (“Security by Obscurity”), it can help to point the WordPress login to an address other than http://www.mysite.tld/wp-login.php or http://www. mypage.tld/wp-admin. The login can then only be reached via the address http://www.meineseite.tld/mein-login, for example. This means that all bot login attempts are in vain.

A simple plugin for renaming WordPress login is “Rename WP-Login”:

The disadvantage of this solution is that every time the bot calls the actual login URL, PHP is still executed, which means that the server load is not spared.

So if you want to go one step further due to massive performance problems, you can switch a BasicAuth password query before the actual login. This measure, also known as htaccess protection, requires another password to be entered before the actual WP login, which is implemented on the server side, does not require PHP execution and thus protects the server power.

What does all this have to do with WordPress obfuscation?

Let’s get back to the real topic, hiding all WordPress hints.

The wp-admin/admin-ajax.php file is an important element in every WordPress installation, as it is the basis of all AJAX communication. It is used in particular in the WordPress backend for AJAX calls, for example when data is to be reloaded in the admin interface of a plugin. The call to admin-ajax.php is also used in the frontend, i.e. on the actual page. The standard WordPress method for AJAX communication or for loading data in general is the wp-admin/admin-ajax.php file, even within the framework of the normal website.

Closing circle 1: admin ajax and renamed login urls

And now the circle of the two topics of this article, which actually do not go together, closes. No matter what you obfuscate, no matter if you rename the login URL: calling wp-admin/admin-ajax.php is and will remain unchanged. An attacker can therefore on the one hand check the page source code to see whether such a call can be found in it, or simply call up the appropriate URL himself and check the return value. Without further parameters and settings, wp-admin/admin-ajax.php returns the value “0”. if it is not a WordPress system, the HTTP error 404 would be returned because the file does not exist.

Closing circle 2: False BasicAuth protection breaks WP features

And now for the second closing circle. Again and again I see the recommendation to secure the login using htaccess protection (BasicAuth) (see above). It is often suggested to protect the wp-admin directory accordingly. But that is wrong! Anyone who provides wp-admin with password protection prevents WordPress from communicating via admin-ajax.php and thus possibly prevents the correct functioning of various plugins that use this function in the frontend.

When you call wp-admin you are always redirected to the wp-login.php file if you are not logged in. It is therefore sufficient to protect the wp-login.php using htaccess if you prefer this solution at all:

 <Files wp-login.php>
AuthName "Du kommst hier nicht rein"
AuthType Basic
AuthUserFile /pfad/zur/.htpasswd
Require valid-user
</Files>

This snippet belongs in the .htaccess file in the main WordPress directory.

I have compiled an example solution including further suggestions in a gist:

https://gist.github.com/zottto/6b44eb58baf44fc6bd62

Incidentally, I personally am not a fan of this BasicAuth protection, because for me the loss of usability through a double password query is significantly greater than the benefit. This technique should really only be used if the server is massively on its knees due to the bot attacks.

Conclusion

The conclusion of this article in a nutshell:

  • Obfuscating references to WordPress and its version is useless
  • The best protection of the login are strong passwords, all other measures are exaggerated
  • If you like, you can rename the login URL
  • Despite the changed login URL and all other concealment measures, WordPress can still be recognized by the use of wp-admin/admin-ajax.php
  • If you set the htaccess/BasicAuth password query for the login incorrectly, you may break the function of WordPress or various plugins in the frontend
Previous post WordPress Login – Customize logo and link
WordPress: cheat database login - publishingblog.ch Next post WordPress: cheat database login