WordPress 4.1 was recently released, and as always, we’ve updated our WordPress one-click installer to automatically install the latest version for new WordPress sites.
If you’ve previously installed an older version of WordPress, you should update it from within your WordPress Dashboard.
By the way, the new WordPress 4.1 Twenty Fifteen theme doesn’t display a default navigation menu, unlike earlier themes. To ensure you’ll always see a list of the pages on your site, our installer now adds a Pages widget at the top of the sidebar for new installations. If you later create a custom navigation menu, you’ll see two lists of pages in the sidebar. You can just delete the extra Pages widget if that happens to you.
I’m going to use annoyingly big type, on an annoying yellow background, because it’s important:
If you use WordPress, you MUST update your plugins and themes whenever you see that an update is available. If you don’t, your site will eventually be “hacked” because of a security bug in old software. The contents of your site will be replaced with something malicious, and your e-mail will be used to send offensive spam.
We have a page with more information, including:
- why this is a problem
- why it would happen to your site in particular
- the two most common ways sites get hacked
- the risks of not fixing it
- the risks of inactive plugins and themes
- the steps to update WordPress properly
Recently, we’ve been seeing more and more WordPress sites maliciously “hacked” because our customer chose a weak password like “admin”, “password”, “temp”, “test”, or “wordpress”.
If you use a password like this, “hackers” maybe able to guess it and login before rate-limiting stops them from guessing stronger passwords.
Hackers are using automated software to try to login to millions of WordPress sites every day with these passwords. Because so many sites are being compromised this way, we’ve taken the fairly radical step of blocking all WordPress logins that use them.
Read the rest of this entry »
WordPress 4.0 was recently released, and as always, we’ve updated our WordPress one-click installer to automatically install the latest version for new WordPress sites.
If you’ve previously installed an older version of WordPress, you should update it from within your WordPress Dashboard.
We strongly recommend keeping your WordPress installation up to date (and using unguessable passwords)! You should first update the active theme and plugins, then delete all inactive themes and plugins, and then update the core WordPress files.
One of our customers asked if multiple domain names hosted with us are vulnerable to “website cross-contamination”, a nasty security problem that can happen at many hosting companies when two different sites share the same “account”.
The answer is no. We intentionally handle multiple hosted domain names differently from the way most hosting companies handle extra hosted domain names, avoiding the problem.
Read the rest of this entry »
Over the last few days, we’ve been tracking an ever-increasing distributed attack on the WordPress xmlrpc.php service.
We’ve previously seen and blocked attacks on this file that tried to post spam comments or act as a denial of service amplifier, but this attack is different: it tries to guess WordPress usernames and passwords.
As a result, we’ve applied more aggressive blocking than usual to the attack. It’s remotely possible that the blocking could cause legitimate third-party WordPress “apps” and services to be unable to access your blog (although it can’t cause problems when just visiting WordPress in a normal Web browser); don’t hesitate to contact us if you’re one of our customers having trouble.
Just so it’s clear, we’ve blocked this attack for all our hosting customers. But the rest of this post has some technical details that may help other people trying to do the same.
Read the rest of this entry »
We often get reports from customers saying they’ve been blocked from their WordPress sites with a strange generic error message or blank page.
When we investigate, it’s common to find that it happened because they installed a security plugin that has made a mistake — a “false positive” — and blocked the site owner.
Read the rest of this entry »
We recently explained how to avoid DMARC mail delivery problems with the “Gravity Forms” WordPress plugin.
We’ve added a support article explaining how to avoid DMARC mail delivery problems with the similar “Contact Form 7” plugin, too.
If you use either of these plugins and you’re seeing mail rejected with errors about “DMARC”, the links above will help you fix it.
If you use the Gravity Forms WordPress plugin, be sure you don’t set it to send mail “from” the e-mail address of the person filling out the form. If you do, you’ll have trouble due to recent “DMARC” anti-forgery changes some companies (including AOL and Yahoo) have made.
To avoid problems, make sure that Gravity Forms (and other such forms) send mail “from” the Web site domain name the form uses. For instance, if your Web site is at www.example.com, you could send mail from “notifications@example.com”. Here’s a helpful page that explains how to properly set up the Gravity Forms address with DMARC in mind.
By the way, this is just a specific case of the general rule of “don’t send mail from addresses you don’t own”. The simple way to think of it is that you’re not (say) AOL or Yahoo, so your Web site shouldn’t send mail claiming it’s from aol.com or yahoo.com addresses. AOL and Yahoo don’t want other people doing that. Always send mail only from your own domain name.
At approximately 9:30 PM Pacific time, all of our servers began to experience a large “distributed denial of service” (DDoS) attack via attempts to login to blogs using the standard WordPress wp-login.php script. This attack was very broad: it attacked thousands of sites across all of our servers, and it came from a huge number of IP addresses.
Processing these requests caused the overall load on all servers to increase. On “web04” the increase was enough to cause the server to start returning “503” errors for Web page requests.
Our servers already have a set of rules to protect against attacks on wp-login.php, but the rules were not quite sufficient to block tonight’s attack. We added a new rule to match tonight’s attack, and it fixed the problem.
We apologize for the time that the “web04” server returned 503 errors. As you can see by reviewing our blog posts we try to be very proactive to protect our customers’ WordPress sites, and hope that the new security rule will prevent future attacks with the same characteristics.
