Introducing Wordfence, the Ultimate WordPress security plugin.

Exec Summary: Last year this WordPress blog was hacked which led me to discover the timthumb vulnerability you may have heard of. I fixed timthumb and worked with Ben, the author to release timthumb 2.0. Then I started work on Wordfence, what I hope will be the best security plugin in the business for WordPress. Wordfence is now completing beta testing. Install it, it’s free and it will help protect your site and keep you off Google’s malware list and in the search results. For beginners: you install Wordfence by going to your WordPress blog’s “Plugins” menu, clicking “Add New” and searching for “Wordfence”.

Full Post:

Last year on August 1, this WordPress blog was hacked. Thankfully I caught it quick enough to stay of Google’s malware list. I retraced the hacker’s steps and discovered a zero day vulnerability in many WordPress themes and plugins in the form of a popular image resizer called timthumb.php.

So I rewrote timthumb.php and worked with the author of timthumb and some of the WordPress team to merge my code into timthumb and we launched it as timthumb version 2.0.

But getting hacked made me realize that as awesome as WordPress is, it can do security better.

So I dropped everything and spent the last few months writing what I hope will be the last word in WordPress security.

A few days ago I quietly released Wordfence into the WordPress plugin repository. Since then I’ve been working with some amazing WordPress publishers to make Wordfence even better and I’ve been rapidly rolling out improvements, enhancements and (yes, believe it or not) a few bug fixes. I’d say Wordfence is getting close to finishing Beta testing at this point.

Except for two (rather minor) features, Wordfence is completely free. It is also backed up by a cluster of cloud based scanning servers that do most of the heavy lifting to keep your site running super fast.

Here are some of the more notable ways Wordfence enhances your WordPress security:

  • Scans your core files against a reference copy which I maintain in our cloud servers.
  • Lets you see what has changed, how the file has changed and even repair it.
  • Scans your comments, posts and all files including core, themes, plugins and everything else under your WordPress root directory for malware, virus signatures, vulnerabilities and (very importantly) URL’s that are known to host malware or viruses.
  • I want to re-emphasize the last point. Wordfence keeps known dangerous URL’s, including ALL URL’s that are on Googles’ safe browsing list, out of your comments, pages, posts and files. This is by far my favorite feature because it’s virtually gauranteed to keep you off the dreaded red-page-of-death-malware-list that Chrome and Google use to ban sites.
  • Wordfence comes with a complete firewall that lets you set up rules based on the type of traffic and either throttle or block offenders with an SEO safe 503 (come back later) HTTP message.
  • Another favorite feature of mine is that you can block fake Google crawlers. I actually added this after I tested Wordfence on this site because I couldn’t believe how many scrapers were pretending to be Googlebot. So now they are all instantly blocked.
  • Wordfence uses Google’s recommended reverse-forward DNS verification to sift the fake Googlebots from the real ones.
  • It includes login security against every form of brute force attack out there including abusing your lost-password form.
  • And what’s the point of having all this awesome security if you can’t see who is visiting, who’s getting blocked and what humans and robots are doing? So Wordfence includes real-time traffic that wait..for…it…
  • …Includes crawlers, scrapers, robots and all non-human traffic. Something you can’t get from Google Analytics or any other Javascript based analytics package.
  • I’ve even broken out Googlebot, other crawlers, 404 errors, humans and there’s an All Hits view.
  • And of course it includes commercial grade city-level geolocation which is another feature that comes from our cloud servers.
  • Wordfence is also built using much of the knowledge I’ve gained building Feedjit’s real-time analytics so it is careful to minimize any impact on network, website and mysql database performance and keep your website running super-fast.

Most importantly, Wordfence comes with a commercial license if you prefer first-class support and support forums for free users including a generic WordPress security forum where I’m happy to answer general config questions.

Improving WordPress security is going to be a marathon, not a sprint. I’m in this for the long haul. So check out Wordfence now by installing it on your blog and work with me to make the Web and WordPress more secure.

 

WordPress Security: Which is more secure? A VPS or a VHost?

Big News [April 24th, 2012]: I’ve launched Wordfence to permanently fix your WordPress site’s security issues. Click here to learn more.

In web server admin parlance, a VPS is a Virtual Private Server and a VHost is a virtually hosted website. There were a few questions regarding security on VPS’s and VHosts in my previous post on “Seven ways I could hack into your WordPress website“, so I thought I’d clarify what the difference is between WordPress hosted on a Virtual Private Server (VPS) vs WordPress on a Virtual Host (VHost) and what the security implications are of each configuration.

A Virtually Hosted Website (VHost)

In the early days of the web, you would have a single physical machine running a single operating system running a single web server. That web server would serve up a single website.

HTTP 1.0 introduced the optional “Host:” header and HTTP 1.1 made it mandatory with any web request that a browser sends. The effect of this is that when a web browser sends a request to any web server, it lets the server know which website it wants to see. Because web servers know what website a browser expects, they can now host an unlimited number of websites. This is called virtual hosting.

When you have a virtually hosted website, you are sharing a single server and operating system with many other websites. Your files and the files of other websites are stored on the same operating system. You all share the same web server and the server chooses which of your websites it needs to serve based on what a web browser requests when it connects to that web server.

Usually on a virtually hosted website, you won’t have access to other website files and they won’t have access to yours. This is usually done by giving you a unique username that you use to sign in and your username only has permissions to view your files.

A Virtual Private Server (VPS)

A VPS is a little different. Normally when you install any operating system, you install it directly on a machine like a server or workstation. With a VPS, you first install a base operating system like Windows or Linux. Then you install a virtual machine hosting platform called a Hypervisor. Examples of Hypervisor’s are VMWare and Xen.

Within the Hypervisor you can then install multiple virtual machines. These pretend to be physical hardware and when you boot them up you get a BIOS message similar to when you boot up a physical machine.

Within these virtual machines you can then install an operating system like Linux or Windows. Using this config you can have potentially hundreds of virtual machines running on a single physical machine.

So to summarize, you have a physical machine running an operating which runs a hypervisor which runs multiple virtual machines and each virtual machine runs its own operating system. Within these operating systems you run your own web server, have the files for your website and do anything else you feel like doing. It’s impossible for someone on another virtual machine to access your virtual machine.

Linode is one of the most popular virtual machine hosting providers and they use the Xen Hypervisor to host Linux virtual machines.

So which is more secure?

By now you’ve probably already figured it out: Running your own virtual machine that is completely segmented from everyone else is usually the more secure option. Here are a few reasons why:

  1. If your web host messed up the machine configuration or permissions, then other users may be able to access your files.
  2. If another user’s WordPress installation gets hacked, it may be possible for the hacker to gain read or in rare cases read and write access to your files.

Another thing I like about having a VPS instead of a VHost is that you have your own IP address. On the Internet, IP addresses can get blacklisted, particularly if you’re sending email. If your web application sends email e.g. if you’re using the WordPress “Subscribe to Comments” plugin, then your emails may be flagged as spam if another user on the same server is sending a lot of spam.

With a VPS you have your own IP address, so as long as the IP address wasn’t already black-listed when you got it from your web host (I’ve seen it happen) then only you are responsible for how that IP address is perceived on the Net.

In conclusion: While VPS’s tend to cost slightly more (about $20/month from Linode), they are well worth the extra cost when it comes to protecting your website and your reputation. As always please post any questions in the comments and I’ll either answer them directly or in a future post.

Caveat: I have generalized greatly when it comes to VPS and VHost configurations. There are many variants including Type I and Type II Hypervisors, shared hosting where a single OS hosts one web server instance per website and many more. I’ve described two common VPS and VHost configs above for illustrative purposes, however the VPS config I describe is probably the most common configuration used by VPS providers.

 

Breaking: Google starts to block hacked WordPress blogs as attack widens

Big News [April 24th, 2012]: I’ve launched Wordfence to permanently fix your WordPress site’s security issues. Click here to learn more.

I’ve had two reports in the last 12 hours of WordPress blogs that were compromised via the Timthumb hack being listed as malware by Google. If you try to visit either site, you are confronted with the following:

 

These sites are listed with the warning that “This site may harm your computer” in Google’s search results and Google blocks access to the site with a warning forcing you to manually type the URL into your location bar if you really do want to visit the site:

One of the site owners sent me the detailed info that Google Webmaster Tools was giving her:

This malicious code is appearing intermittently on this author’s WordPress site. I’ve seen this same pattern recently in blogs I’ve repaired and the way it works is that the site is periodically downloading new PHP code from a remote site run by the attacker and re-injecting it into the wordpress code. That allows the attacker to add, remove and update whatever code he/she is executing on your blog. So they could for example update any spam links every few hours.

To prevent your site being listed as malware clean it as fast as possible

The fastest way to do this, although it doesn’t gaurantee a complete clean, is the following:

  1. Remove all old plugins and themes you aren’t using.
  2. Upgrade all your plugins and themes to the latest versions and make sure none of them use an old version of Timthumb.
  3. Clean any Timthumb cache directories.
  4. Upgrade your entire wordpress installation, even if it’s at the latest version. This overwrites all wordpress files.
  5. Search your directory tree for any remaining suspicious files that contain base64_decode wrapped in an eval() statement or URL encoded data. More info on how to do this search here. Delete any files you find. NOTE: If you don’t find any additional infected files in this step, it’s highly likely that your site is not clean. Every attack that I’ve seen so far using Timthumb gets in by uploading a file into the cache directory and then uploads an additional file into a writeable directory on the blog to ensure continued access once the cache is cleaned. Make sure you find that additional file.
  6. Make sure the only directory that is writeable in your wordpress installation is wp-content/. Directories like wp-admin and wp-includes should be read only by the web server.

If you are already listed as malware by Google, here is what to do

Clean your site using the above steps. You can find more suggestions on how to clean your site on this page.
The fastest way to get your site removed from Google’s malware list is to request a review through Google Webmaster Tools. You can find the help file on requesting a malware review on this page.
The process takes about 24 hours to get your site removed. You can find out more about Google’s Malware list and safe browsing report on this page.

 

Potential long term impact of this vulnerability

The fact that I’ve seen the same domain being used by attackers on multiple blogs suggests this attack may be partially or fully automated. The worst case scenario is that we end up with a WordPress botnet with thousands or tens of thousands of servers on high bandwidth links compromised and able to send spam emails or launch a huge DDoS attack.

Keep in mind that most botnets are compromised windows machines on relatively slow home broadband connections. Their uplink speeds are around 512kbps. These WordPress servers are on links that are a minimum of 10 Megabits per second each, so they have plenty of firepower for a coordinated attack. One WordPress server is equal to at least 20 infected PC’s in terms of pure bandwidth firepower.

 

DeployMint: A Staging and Deployment system for WordPress

Exec Summary: Today I’m launching a Beta open source project called DeployMint. I’m using it on WordPress installations where WordPress is being used as a CMS. It runs as a WordPress plugin and allows for staging and deployment of WordPress sites along with robust version control and zero down-time during deployments. It uses the Git version control system to store site snapshots in a safe and space efficient way. It also takes a “belt and braces” approach and provides an emergency back-out system separate to Git in case a deployment fails. You can download the latest version of DeployMint and see a video demo at the DeployMint project page on Google Code.

Full blog entry:

My company is busy moving to using WordPress as a CMS and I wanted a way to instantly deploy several new pages of content or an entire site and have dev and staging sites to test new ideas. I also wanted version control, instant deployment and an emergency back-out system.

I also needed comments to be preserved on the live site so that if I deploy a new version, the existing comments on the live site stay where they should be and only page or post content is updated.

So I created a WordPress plugin called DeployMint.

DeployMint runs under WordPress MU. You create as many subdomains as you would like, for example:

  • development.example.com
  • staging.example.com
  • example.com (your live site)
  1. Then you design  your entire site with themes, pages, content on development.example.com.
  2. Once you’re done, you take a snapshot of development.example.com and deploy that snapshot to staging.example.com.
  3. Your client reviews the new site on staging.example.com and suggests changes.
  4. You make the changes on development.example.com, take a new snapshot and deploy that snapshot to staging.example.com
  5. Once your client is happy, you take a snapshot of staging.example.com and deploy it to example.com, your live site.

Here is a video showing the basic functionality of DeployMint. DeployMint is installed on this blog and I use it to test out new themes and design changes. It works as well on a blog or when WordPress is being used as a CMS. In this video I take a snapshot of my live site (this blog) and deploy it to my staging site staging.markmaunder.com. Then I make a minor modification, I re-snapshot the staging blog and deploy that snapshot to the live site.

DeployMint is space efficient because it uses Git to store snapshots. It also makes a full copy of your entire WordPress database including all your WordPress MU sites every time you deploy. Because these require more space, you can choose how many of these full backups you want to keep. If things go awry with your database or deployment for some reason, you have an emergency backout system that will restore your WordPress MU installation to the state it was in before your previous deployment.

Behind the scenes, DeployMint (DM) works as follows:

  • To install DeployMint you need to create a data directory that is not under your web root, but is writable by your web server.
  • When you create a new project, a new Git repository is created.
  • When you take a snapshot, DM dumps all tables belonging to the blog you snapshotted into individual files.
  • Those files are checked into a ‘Git’ repository. DM uses git for storage because it’s space efficient and robust.
  • Every snapshot you create is a new branch in the repository and only the changes are stored.
  • When you deploy using DM, it simply checks out the branch you want to deploy and imports it into a temporary database.
  • In that temp database, we merge all existing comments on your site into the site we’re about to deploy.
  • DM also modifies any hostnames it needs to, to reflect the site we’re about to deploy to’s hostname.
  • Before deployment, DM takes a full backup of your entire WordPress MU database including all sites and stores this for emergencies in case you need to back-out your changes.
  • These backups take up more disk space than snapshots, so you can choose how many of them you want to keep and DM auto-deletes the oldest ones first.
  • Then a rename is done which takes a few hundredths of a second to replace your old database with the new database we’re deploying.
  • And you’re live with your new site!

Please post a comment below if you have any features suggestions or comments. Thanks.