{"id":29,"date":"2021-08-31T16:40:57","date_gmt":"2021-08-31T16:40:57","guid":{"rendered":"http:\/\/pi-smb\/wordpress\/?p=27"},"modified":"2021-08-31T16:40:57","modified_gmt":"2021-08-31T16:40:57","slug":"speed-up-wordpress-by-renaming-wp-login-php","status":"publish","type":"post","link":"https:\/\/dsslit.ddns.net\/wordpress\/?p=29","title":{"rendered":"Speed up WordPress by Renaming wp-login.php"},"content":{"rendered":"\n

Posted on 

Here is a tip for speeding up WordPress, especially if you are running it on a low power server. I made the change to WordPress running on a small ARM server, resulting in an immediate and dramatic speed up. It works because it prevents bots on the Internet from wasting your server resources.<\/p>\n\n\n\n

Procedure<\/h2>\n\n\n\n

The procedure could hardly be easier. Just move the wp-login.php<\/strong> script. And create an empty stub in its place. And that\u2019s it.

$ cd \/usr\/share\/wordpress<\/strong>
$ sudo mv wp-login.php ~\/wp-login.php<\/strong>
$ sudo touch wp-login.php<\/strong>
<\/code>
That will move the wp-login.php script into your home directory, and create an empty file in its place. Now, when any internet bot tries to log into your WordPress by guessing the password, they won\u2019t even get a valid login form. Your WordPress security has been radically improved. If your server is low power (eg a Raspberry Pi, sheevaplug or similar), you may also get a startling improvement in your site\u2019s speed and responsiveness.<\/p>\n\n\n\n

Drawback<\/h2>\n\n\n\n

You won\u2019t be able to log into WordPress now of course, because you have moved the script that controls the login. Neither will you be able to log out. Whenever you want to log in or out of WordPress, just undo the change:

# cd \/usr\/share\/wordpress<\/strong>
# sudo mv ~\/wp-login.php wp-login.php<\/strong><\/code><\/p>\n\n\n\n

\u2026and now you can log in\/out again. Don\u2019t forget to redo the change afterwards, in order to get the performance and security benefits. (The script has to be in place for loggin in and out, but it does not affect an existing WordPress session).<\/p>\n\n\n\n

Obviously, this procedure is most useful where you log into WordPress relatively rarely. If you are logging in and out all day log, it won\u2019t be very practical to be renaming the script all the time. Better to try one of the plugins mentioned below.<\/p>\n\n\n\n

Botnets and WordPress Scripts<\/h2>\n\n\n\n

The above procedure works because it prevents botnets and other ever-present internet attackers from consuming your CPU resources as they probe for weak passwords. Many blogs are protected by very long passphrases (and if your WordPress passphrase isn\u2019t very long, it should be). Long passphrases will generally stop the attacker from getting in, but they won\u2019t stop him from trying<\/em> to guess the password. And those failed attempts can slow your server down significantly.<\/p>\n\n\n\n

Script Kiddies<\/h2>\n\n\n\n

Scammers are always trying to guess WordPress (and other) passwords. It has become a constant background drone on the internet. \u201cScript kiddies\u201d (ie. novice hackers) will often mount an attack from their server, trying to guess your password a few thousand times over the course of a day or two. These are easy to spot in your site\u2019s access.log<\/strong> file \u2013 you will see many references to \u201cwp-login.php\u201d from the same IP address.<\/p>\n\n\n\n

Botnets<\/h2>\n\n\n\n

Botnets<\/strong> are a more advanced form ot internet hacking. They are quite common these days. If your blog is attacked by a botnet, you may see tens of thousands of references to \u201cwp-login.php\u201d in your sites access.log<\/strong> file, within the space of a few hours. They will come from many different IP addresses, usually hundreds. Often they will make up to 40,000 or so guesses at the password, as they work through a list of dictionary words and common passwords. This is called a dictionary attack<\/strong>.<\/p>\n\n\n\n

I recently made the change above on a low powered WordPress server that was actually undergoing a dictionary attack. The attack was neutralised and the considerable CPU resources it consumerd were reclaimed, speeding up the server and web site instantly. More importantly, the ongoing web performance was significantly boosted, long after the dictionary attack ceased.<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

That is the end of this article really. If you are running WordPress on a low powered, internet-facing server, moving the WordPress login script is a no brainer, for both security and performance.<\/p>\n\n\n\n

The rest of this article gives more technical background, and explains why a stub file is created, rather than just having no wp-login.pfp file at all.<\/p>\n\n\n\n

CPU Consumed by Password Guessing<\/h2>\n\n\n\n

Each login attempt will occupy one of your server\u2019s Apache processes for some time, just as it does when you legitimately login to WordPress. The server has to draw the login page, accept the password, run the authentication algorithm, and so on. On fast hardware this would not be too noticable.<\/p>\n\n\n\n

Lower Powered Server<\/h2>\n\n\n\n

However, on a low power ARM server I checked recntly, each password guess was occupying an Apache process for 5 to 10 seconds. The maximum number of Apache server processes was set to 5, so when 5 login attempts came within 5 seconds or so, the server became unresponsive, and remained unresponsive for as long as login attempts (password guesses) were received at that rate. Meanwhile the \u201ctop\u201d command showed Apache server processes to be consuming, between them, almost 100% of the CPU.<\/p>\n\n\n\n

It\u2019s Quicker to Return 404<\/h2>\n\n\n\n

When I renamed the wp-login.php<\/strong> script to something different, WordPress came back to life. The apache logs showed the password guesses now being returned code 404 instead of a proper login page. It is much quicker for the Web server to return a code 404 than it is to process a login. The Apache processes returned to their normal rate of CPU consumption. WordPress was responsive and the site performance was restored.<\/p>\n\n\n\n

Script Stub<\/h2>\n\n\n\n

The second command above (touch wp-logon.php<\/strong>) creates an empty file in place of the login script. In fact you could miss the step out, and just have no wp-login.php file at all. However when I did this on a live WordPress server, after a few minutes of returning 404 codes to login attempts, it started to return 302 instead, which has something to do with redirection. That is okay, but I noticed the 302 return also took up some CPU, although much less than a full login attempt. Creating the stub file made the return code revert to 404 again, with consequent small saving in CPU.<\/p>\n\n\n\n

WordPress Plugins<\/h2>\n\n\n\n

WordPress plugins are available that move the login script, eg the sf-move-login<\/a> plugin. I haven\u2019t tried these, but you might. The change above is so simple, adding another plugin to WordPress hardly seems worth it. Again, if you are on a low powered hardware, plugins are best kept to a minimum.<\/p>\n\n\n\n

If your blog has many users, who often log in, then simply moving the wp-login.php script might not be very convenient for you, and a plugin such as the above might be prefereable.<\/p>\n\n\n\n

Botnet Dictionary Attacks<\/h2>\n\n\n\n

Dictionary attacks are very common these days. They come from organised networks of compromised PCs called \u201cbotnets\u201d. They look for sites running WordPress and other blogging platforms and, having found one, try to guess the login password \u2013 using dictionary lists and commonly used passwords. Consecutive guesses come from different PCs on the botnet, so in your Apache log they will appear as login attempts from many different IP addresses. Not so obvious as many guesses from the same IP would be.<\/p>\n\n\n\n

Guess Rate<\/h2>\n\n\n\n

A DICTIONARY ATTACK IS NOT DDOS<\/h3>\n\n\n\n

Dictionary attacks do not normally overwhelm their targets. They aren\u2019t trying to take your blog offline, just to guess the password. With the server mentioned above, it only became obvious because the server hardware was quite low power, and the botnet tried to guess too quickly. In fact the server had sustained the attack for several days without slowing down much. Each password guess tied up 1 Apache process while several others were free to service legitimate page requests. Only when the guess rate crossed a critical threshold did the blog become extremely slow (and that was not the scammer\u2019s intention \u2013 they want to go under the radar, not become a huge blip on it).<\/p>\n\n\n\n

Software Tools<\/h2>\n\n\n\n

Software packages like fail2ban<\/a> have been developed to protect againt internet attacks based on password guessing. You might get some mileage from these. In my view, large software frameworks are more suitable for large web server, not small servers that are the subject of this article. Also fail2ban in particular is not designed to combat attacks from distributed botnets.<\/p>\n","protected":false},"excerpt":{"rendered":"

Posted on February 10, 2015 Here is a tip for speeding up WordPress, especially if you are running it on a low power server. I made the change to WordPress running on a small ARM server, resulting in an immediate and dramatic speed up. It works because it prevents bots on the Internet from wasting your … <\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4],"tags":[],"class_list":["post-29","post","type-post","status-publish","format-standard","hentry","category-linux","category-pi"],"_links":{"self":[{"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/29","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=29"}],"version-history":[{"count":0,"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/29\/revisions"}],"wp:attachment":[{"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dsslit.ddns.net\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}