Earlier I wrote about a plugin for WordPress I found to be extremely valuable – Better WP Security. Specifically, its ability to block brute force attacks against simpler passwords and username combinations. This was a major threat to all WordPress sites almost a year ago.
Since then, there have been many updates to the Better WP Security plugin, and the developer has also been hired by iThemes to continue his development (and monetize the plugin’s advanced features). This is great news really as the free version of the plugin is excellent and there are now a wider range of paid advanced features many web developers and site administrators should consider using, now. The plugin is more robust than it was even; no small task for a developer starting with what already seemed to me to be a full featured security plugin.
If you are still on the older Better WP Security plugin, before you update, deactivate the older version of the plugin. Failing to do this can make your site inaccessible as there are conflicts in the features and the plugin’s ability to update them when active. Once you’ve updated to the iTheme’s version, you simply need to reactivate the plugin and check to see what new options are available that you should consider including in your site’s security features.
If you failed to deactivate the plugin, you’ll need to move the plugin directory for Better WP Security out of your site’s plugin folder and perhaps remove any updates the plugin did to your htaccess file. Once you do that, you should be able to complete the update or reinstall the plugin.
A long overdue change to our site came about today; a new template. It’s been years since we changed our template and while keeping the same header and color scheme for branding reasons, it’s nice to finally have a responsive design and not a separate template for mobile users. The separate template path never felt very clean or simple. The mobile view bothered me.
Again we are also reminded of the power behind a solid CMS platform. Changing our site’s look and feel was a simple thing and quite painless. Long live WordPress!
For a time on December 30th, 2013, my hosting provider 1and1.com was redirecting all WordPress logins to 220.127.116.11 whenever one hit wp-login.php effectively blocking all attempts to login — and logout for that matter – from any WordPress installation on their servers.
Their response was less than desired; they stated that this issue was effecting only .5% of their customers. Even if that were to be true, which I would find doubtful given the widespread use of WordPress, and it seems to discount the severity of the issue for WordPress user, a program that they say they support completely. Read more
Having long been an advocate of several open source content management systems, I’ve also done the difficult task several times of moving content from one system to another. Given these systems rarely (if ever) have built in export and import abilities (WordPress being one of them however), you can expect to do much of such a conversion by hand, one article at a time. If you have a large amount of content, obviously, this is a very time consuming and expensive endeavor. Moving users and passwords would require several complex database queries and testing as one must also understand how the passwords are encrypted. It’s a painful process and often too expensive for many clients to consider doing.
Here’s a resource to make this no longer an issue. CMS2CMS.com can make the conversion from one CMS to another in a matter of minutes. They’ve written the complex scripts needed to perform these tasks and appear to be adding to the list of what they can support all the time. They even have a script that will spider a site and push the content into the CMS of your choosing — take a look at the HTML to CMS path. Here is the full list of supported platforms.
I used their services to move a Joomla based website running on 1.x Joomla to the latest WordPress version and their tools captured all of the content and most importantly, moved all 138 members of the old site to the new. This was done in about 10 minutes time, including the time for me to put their “bridge” script on the client’s server. This allowed me to get the conversion done in an amazingly fast way — my client could not be happier. Me, too.
One reason I’ve begun to prefer WordPress over Joomla is that WordPress has made the upgrade process so much easier than Joomla. To upgrade Joomla 1.x to 1.5, you have to use special tools and again if you go from 1.5 to 2 or version 3, be prepared for a different toolset and migration path. Ugh! Worse still, Joomla Extensions have become very version specific due to a lack of backwards compatibility. WordPress on the other hand allows one to simply put the new code in place, and so long as there is not a conflict with a Plugin, the code takes care of everything else for you, including updating the database.
Perhaps it is only because I haven’t tried to migrate a very customized WordPress site that I feel this way, or that my more complicated older sites are nearly all in Joomla. So long as I keep a copy of the changes I’ve made to styles or any core files, I’m able to keep things up to date really quite easily with WordPress. As noted above, sometimes an entire system isn’t easy to replace though. There are times a client has invested heavily into very specific Joomla module or tool — only to have these items not become readily available to the newest versions of Joomla. (I am not finding this to be true of WordPress Plugins — another reason to go with WordPress today.) So the problem to deal with is securing older versions of Joomla that have known security issues. What exactly can one do to make an older Joomla site more secure? Let’s take a look at securing Joomla.
Over the past several days, I’ve seen a great many news articles about a bot based brute force attack on WordPress (and Joomla) based websites where the bot uses common password choices and attempts to login with the username “admin.” Mind you, we are talking about hundreds, perhaps thousands of these common passwords and coming from tens of thousands of compromised servers. The effort being to gain access to the server and then use the administrator site to add other files and code changes which further compromise the use of the website completely. You really need some WordPress Security.
Having already written about other hacking effort increases of late, I am bothered that yet again these content management systems are being hit with what amounts to the use of wasted talent; hackers show intelligence and problem solving skills, why not put them to use in a way that doesn’t harm others? Thankfully, the open source community is quick to respond and build tools needed to protect websites from such harmful efforts.
Better WP Security from Bit51.com is an excellent add on to your WordPress website. It was written long before this current wave of brute force attacks, and is something I would recommend all WordPress websites use from day one. It relies on both htaccess changes for blocking known bots and other file changes that remove vulnerabilities outright and through obfuscation.
Here is a list of some of the things this tool does:
- Enforces stricter passwords for users at any level you determine.
- Removes the backend file editor.
- Scans the site for recently changed files and emails a report to you if there are such intrusions.
- Blocks repeated login attempts.
- Blocks SQL injection attempts.
- Makes backups of your database and mails them to you are regular intervals
This is open source work at its finest. It is free to use, but the developer does provide a means of paying him for his work — which I’d highly recommend doing as this tool is really quite will constructed and extremely valuable.
Simply put, hackers suck. Over the past six to eight months, I’ve had to deal with the hacking of many former (and a few current) client websites. All but one of the exploits came through older versions of Joomla, and the exception being an older WordPress site. Version 1.0 of Joomla is ancient by Internet terms, and there were several security exploits discovered with it. Add to this that there are often third party extensions with additional exploit possibilities. This environment makes it so any jackass who can write a script that searches source code on pages for specific components or Joomla references can then upload files to your server. Ugly. Really ugly.
The compromised websites in all cases continued to function, at least somewhat. One hacker injected a file into the site that would in turn alter the htaccess file adding mod_rewrite rules that would redirect anyone coming from Facebook, Google and just about any other search engine or social networking site. If one were to type the URL in directly, nothing happened. No URLs in the search engines were altered either; the redirects in the htaccess file hijacked only people who had headers from one of these sources. A couple of sites had files that were posting text on pages and adding new links. One hack destroyed the ability of using the administrator section of Joomla causing a 500 error upon login.