That’s a problem, so we’ve had WordPress login “rate limiting” in place for a long time. When a single IP address tries loading the WordPress “wp-login.php” script many more times than a human would, we temporarily block that IP address from accessing the “wp-login.php” page until the requests stop for a while.

This works pretty well: we’ve blocked literally millions of password attempts this way. However, last week one of our customers had his site hijacked by someone who did indeed simply guess his WordPress password.

Part of this was unfortunately the customer’s responsibility for choosing a weak password — he chose a common dictionary word beginning with the letter “a” that could be easily guessed. In fact, it only took the hackers a few dozen tries to guess it. However, we were still surprised that they succeeded, since the rate limiting usually blocks this.

A detailed investigation revealed that these hackers were smarter than average. Instead of trying lots of passwords all at once, they tried them fairly slowly, making about one attempt every 20 minutes over several days.

To thwart this, we’ve made our rate limiting more strict — it “remembers” login attempts for a longer period, for example, and we now limit some IP addresses if they try as few as 12 login attempts per day. That still shouldn’t affect most human users, but just to make sure that’s not a problem, we’ve also added a feature that lets humans reset the rate limiting. You’ll see this option on the error page that rate-limited requests get redirected to if it ever happens to you.

As always, don’t hesitate to contact us if you have any problems or questions related to this.

One of these involves a fake ad agency, and the other involves offers to upgrade outdated software on your site. Don’t fall for these!

What’s new about these?

“Phishing” messages have been around for years. Most of these revolve around the same basic idea: a stranger convinces a user to provide private information in exchange for a product or service. This information can be anything from your bank account number to a username and password.

So what’s different about these new messages? For starters, these newer messages are written by real people using complex language; they don’t look like something generated by an automated script, or by someone who doesn’t speak “business English”. But these messages also exploit another popular trend: content management systems.

Many users now rely on software like WordPress, Joomla, and phpBB to run their Web site. These software packages allow people to create and manage sophisticated Web sites that in the past would have required an experienced (and expensive) Web developer. As a result, users often rely more on third party software, and have become comfortable installing software based on description alone — without knowing how well tested it is or who wrote it. In fact, we’ve written about the threats of untested plugins before.

Both of the scams mentioned above exploit this new behavior. Users have been convinced to install custom software in order to provide a specific feature for their site, only to later find out that the software actually allows “hackers” to access their files and information.

How can I avoid this?

The most important thing to remember is to never give out any personal information to somebody you do not know. You should treat all unsolicited e-mail asking for personal information as a scam unless you can verify otherwise.

Also important is to never install unsolicited software. Stick to well tested software downloaded from verified Web sites. For example, while it doesn’t promise full security, the official WordPress plugins Web site does scan each file uploaded for common bits of malicious code before making them available to users. Combine that with many peer reviews of a popular plugin, and you can feel more assured in the quality and safety of the software you are installing.

Of course, Web site security isn’t completely up to you. We make sure to keep server-wide software updated on our end and to provide as much protection as possible at the server level. If you do your part, too, you’ll reduce the risk of problems dramatically.

How did this happen? Well, our customer simply searched the WordPress plugin directory for “Contact Form”, saw the popular “Contact Form 7” plugin listed, then clicked “Install Now”. That all sounds reasonable.

Unfortunately, what he installed wasn’t the real Contact Form 7 plugin. Instead, it was a malicious copy of that plugin that contains extra files designed to give attackers full access to a blog. The malicious copy ranks higher than the real copy in the search results. (Hopefully the link to the malicious copy will stop working soon; we’ve notified the WordPress folks about this.)

The lesson here is “be careful what you install”. The WordPress Plugin Directory is not guaranteed to be safe, and WordPress plugins are no different than any other scripts you put on your site. While we can’t suggest a way to guarantee that a plugin is safe, be wary of plugins that have been recently updated, or that don’t have large numbers of downloads. If you’re not confident about it, do a separate Internet search for the name of the plugin. You’ll find the real home page for it, and that page will have a link to the real plugin page you should use.

The WordPress Plugin Directory site could be improved to offer some protection against this problem, too. A few “off the top of our head” suggestions:

• The site should flag newly created plugins. Something on the page should indicate that the malicious “contact-form-73” plugin is only a few days old.
• The site should allow authors to prove they own a plugin. In this case, the malicious plugin says “Author: takayukister”, but that’s the author of the real plugin, who almost certainly didn’t upload this one. WordPress has that author’s e-mail address on file and should send a message to verify that he really uploaded it. Plugins from newly created authors should also be flagged.
• Two plugins with the same human-readable name should not be allowed in the directory.
• Newly created plugins with a small number of downloads should not appear in the results before long-established plugins with millions of downloads, because people choose the first thing they see with a reasonable name.
• The plugin directory needs a way for people to flag malicious plugins. I posted on the WordPress support forums and sent a message to the recommended plugins@wordpress.org address more than three hours ago, but it’s still there, and dozens of people have downloaded it since then.

Ultimately, though, it’s up to you to be careful about what you install. Be skeptical. Some people on the Internet really are out to get you.

Unfortunately, WP Super Cache is configured by default not to serve cached results to any request that contains an “equals sign” in the query string — and the plugin that notifies the other sites of new content is including an equals sign.

So rather than being immediately served from the cache, all of the new requests were run through WordPress PHP scripts, driving up the script usage and causing “503 Service Unavailable” errors for up to two minutes on that Web site (not for other Web sites on the same Web server, though; we have protection against that).

All of the post requests looked something like this:

GET /new-post-name/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Blog+name

Fortunately, there’s an extremely easy solution, which we discussed in an earlier blog post. If you’re running WordPress with WP Super Cache, be sure to implement this easy fix. The fix also helps in other situations, and can keep your Web site from unnecessary CPU usage.

This is caused by a bug in the Outlook update, not by a problem on our servers. To fix this, Microsoft recommends uninstalling the update for now.

However, if you sent mail to an aol.com address during this time, your messages probably “bounced” with an error saying “Host or domain name not found. Name service error for name=aol.com”. If so, you should try sending the message again, and it will work normally. As always, we’ll continue to monitor AOL deliveries closely.

Yikes! We take things like that very seriously — we go to great lengths (some would say extreme lengths) to make sure this doesn’t happen. So we investigated… and it turns out that the ReputationAuthority blacklist actually has a technical problem that’s making it reject all mail from all servers, not just from ours (see complaints on Twitter [1, 2] and elsewhere). People who use that blacklist to block spam aren’t getting any mail at all.

We’re always surprised when we see this kind of thing (it’s not uncommon). Completely trusting blacklists provided by one single organization is dangerous; it will come back to bite you.

If you run your own mail server, it’s much safer to consult several blacklists and block mail only when multiple blacklists (or other criteria) agree. In addition, it makes sense to check each blacklist occasionally to ensure that it’s not returning “false positives”.

For the spam filtering we provide to our customers, we use a large number of blacklists, but for the most part, it takes “hits” from several of them to block mail. We don’t worry about an obscure blacklist causing problems like this.

For blacklists that we weight heavily, such as spamhaus.org, our systems constantly check whether several popular domain names are in the blacklist. If, for example, “google.com” shows as being listed in a SURBL blacklist, or one of our own IP addresses that never sends mail is listed at spamhaus.org, that indicates a serious problem, and we’d immediately and automatically stop using the blacklist. (We also pay several blacklists for a direct “feed” to ensure that we’re getting the most accurate data instead of using their public DNS service.)

If the systems using the ReputationAuthority blacklist to filter mail were checking this kind of thing, they wouldn’t be blocking all mail. If you’re using your own anti-spam filtering system that relies on blacklists, make sure that it handles this problem.

Again, our own hosting customers who rely on our filters don’t need to worry about it, though. We’ve got it covered.

Quite a few of our customers are still using FrontPage to design and upload their Web sites, though. We’re starting to see more and more problems from customers who have upgraded to a new computer running Windows Vista or Windows 7 but can no longer run FrontPage. (Sometimes their old computer just suddenly crashes and can’t be recovered.) Their old computer probably had a copy of FrontPage installed by the manufacturer, but their new computer doesn’t.

It can be difficult or impossible to get FrontPage running on a new PC if you can’t find the original installation CDs, or you aren’t licensed to use FrontPage on the new PC. In some cases, the old FrontPage software doesn’t install or work well on the latest versions of Windows. In these situations, you can’t even open the old FrontPage files on the new computer.

If you are still using FrontPage, you should start planning for when you are going to move to a different program. You might want to move to Microsoft’s newer program, Expression Web. Or you might want to join the large number of people using Dreamweaver. If you’re looking for a free program, you might want to try Nvu. The popular (and free!) WordPress can be a good choice, too — it’s commonly known as a “blog program”, but you can also use it to create a Web site with normal pages.

We strongly encourage existing FrontPage users to start planning their move to a different program. If you don’t plan the move yourself on your own schedule, you may find yourself stuck in a situation where you’re no longer able to edit your site using the old FrontPage software.

We thought the recent 2-hour movies were OK if a little, um, “uneven.” But we have high hopes (“higher than sugar cane growing on Mount Everest”) that the Futurama team will hit their stride and churn out some great episodes.

The fun starts with two back-to-back episodes tomorrow night (Thursday) at 10pm on Comedy Central. Set your TiVo’s!

By default, each WordPress blog is configured to send the login username and password as plain (unencrypted) text. If a hacker can see what you are sending during your login, they can easily steal your username and password. This can happen if you have a virus installed on your computer. It can also happen if your computer is virus-free but connects via WiFi. If your main computer uses a wireless connection, or if you or other users of your blog ever login with their laptops — blogging from a coffee shop, anyone? — remember that these connections can be insecure, and could be susceptible to revealing your password.

You can protect your blog by installing an “SSL certificate” and configuring WordPress to require secure logins. Your browser will then encrypt your username and password so that no one can intercept them.

Traditionally, only online stores used SSL certificates because they were very expensive. But SSL certificate prices have dropped quite a bit recently, and they’re now low enough that we think SSL certificates should be widely used to protect all logins and other sensitive data.

If you are a Tiger Technologies customer, you can get an SSL certificate for a great price. (One type of certificate, a “self-signed certificate”, is even free if you’re already on our Gold or Platinum hosting plans.) If you’re not a Tiger Technologies customer, you can search for companies selling SSL certificates or search for free self-signed certificates.

Configuring WordPress

Once you have an SSL certificate installed on your site, it’s easy to configure WordPress to use secure logins. Simply add this line anywhere to your wp-config.php file (after the opening “<?php” line):

define('FORCE_SSL_ADMIN', true);

This will ensure that your username and password are submitted to WordPress securely; all of your subsequent work (creating posts, etc) will be secure as well. You’ll see your Web browser’s “padlock” icon when you are using a secure connection. The WordPress “Administration Over SSL” page has more details.