Crawling back to DreamHost

2 years ago, I left DreamHost because of an issue that turned for the worse when I tried contacting support. This weekend, I started the slow migration back.

Here’s the thing. I’ve been extremely happy with the support I’ve gotten from my current host, HostingMatters, which I was referred to by @tenthmuse. But I have two problems with my current hosting situation that are becoming increasingly aggravating, two problems that I didn’t have with DreamHost.

1. Permissions issues

HostingMatters is a standard webhosting environment. By that I mean that the webserver is running under its own user. This can cause permissions issues when you are running a web application (like WordPress) that’s uploading files since they will be owned by a user that’s different than the user who owns, say, the /uploads directory (which is probably your ftp user). You can get around this by using 777 permissions — making everything readable and writeable by everyone — but that’s a huge security risk, one that I’m not comfortable with even though that was suggested by HostingMatters’ support when I raised the issue. This can cause issues with updating WordPress if you don’t get the FTP info set up correctly when you add it manually to your wp-config.php file (something I had working on some of my sites, but not others, and couldn’t be bothered to spend the extra time figuring out which ones were broken) and it means you can’t use the editors if you need to put on your pink sombrero and edit some code live.

This was never, ever, ever, EVER a problem on DreamHost.

DreamHost was always the simplest solution to hosting WordPress I ever dealt with. DreamHost runs the webserver under your user account meaning that it will be the same user as your FTP account (unless you’ve created a separate FTP user, but I don’t see why you’d want to). Not only that, but you can change which user you want to use to run your website under. This means that these permissions issues never happen because everything is running and owned by the same user.

2. Speed

Of course speed is always an issue and even when I had the VPS set up on DreamHost I battled with this. The plan I’m running on HostingMatters currently is an unmetered plan, meaning unlimited pretty much everything, but of course, it’s still shared (it’s a special plan that Joelle has set up with them for her clients, but it’s basically the same thing as their unlimited anniversary package) and as far as I can tell, they don’t do VPS servers (their reseller accounts are probably actually a VPS, but it doesn’t actually say that anywhere and I have zero interest in reselling hosting). What I’ve been noticing lately is my sites are really…slow…

Not so say that they were always so snappy on DreamHost either, but if you have to wait several seconds for a page to load, you’ve got issues. And I’ve had that more of late than I care to talk about and I don’t remember having it nearly as bad on DreamHost unless there was a memory leak causing the server to lock up (which was fixable by a reboot).


The thing I haven’t said yet is that the original issue that caused me to move was a reboot — the server wouldn’t do it. And I had no means to force it. When I looked back at DreamHosts VPS info, remote reboot is supported — I’m assuming it’s new since I left — which means that my original problem could have been solved without even contacting support. That and the permissions issues alone are reason enough for me to come crawling back.

Why not another host?

Look, I won’t argue that DreamHost is the absolute best host out there ever. But, for my money, it works. It’s easy — particularly for WordPress users — it still has the best control panel I’ve ever used (HostingMatters uses cPanel which I’ve said before I hate with a fiery passion), and it’s configurable. I rarely need to talk to support and — with one notable exception — when I have, it’s been a good experience (again, not saying that HostingMatters has ever been unsatisfactory in that department). I thought about doing HostGator but they a) use cPanel but b) only if you get their shared servers (which I’m skeptical of) or a level 3 or higher VPS ($40/month). And let me tell you, the Virtuozo panel you get on levels 1 and 2 SUCK WORSE THAN CPANEL — you’ll be begging for cPanel once you try using those. Believe me. Which, I’m sure, is the whole point and — since they give that to their shared server customers — I find that asinine.

And I was tired of searching. Look, you can hear bad stuff about anyone. MT is supposedly great. It also supposedly sucks. The same is true for managed WP solutions and I’d argue that you can find equal parts “this is great” and “this sucks” posts about every host, ever. And probably, you’ll hear more about the hosts that suck than the ones that are great because people tend not to talk about stuff that’s good, they talk about stuff that’s broken. There were a number of things I missed when I left DreamHost, so part of me is honestly glad to be making the painful migration (because migrating sites is always painful) back.

So, DreamHost, I’m back. And anyone who wants to join me can use the promo code ARCANE20 to get $20 off 1 year or $50 off 2 year hosting plans.

Also, bonus: they are running WordPress on their main site and they are green. So there’s that.

When I’m too smart for tech support…

This isn’t the first time I’ve contacted web hosting tech support only to find out they couldn’t help me and managed to fix the problem myself. This time the support on the other end was HostGator.

To their credit, the rep I talked to seemed to genuinely want to help. However, after 40 minutes it was determined that he couldn’t help, because the plan my client was on was an unmanaged level 1 VPS, and they only provide support for level 3 or higher. Or something.

The issue was with mod_rewrite — an Apache module that makes urls look like http://this.awe/some/url/ as opposed to http://this.ugh/?p=123. I was setting up a WordPress multisite and mod_rewrite just wasn’t doing what it was supposed to be doing. I checked the httpd.conf in /etc/httpd/ (as opposed to /etc/apache2/ where it usually lives) and it was enabled. I checked and double-checked and triple-checked my .htaccess file. I even (later) went in to make sure the file actually existed. It did. After their support was unable to help, I started looking at installing mod_rewrite. It was through that search that I found this post on installing mod_rewrite, which ultimately led me to this line that needed to be added to (in my case) the httpd.conf:

     Options FollowSymLinks
     AllowOverride None All

In my case, the Options FollowSymLinks was already there. AllowOverride was set to None. All I needed to do was add All. Done. URL rewriting fixed.

Thus far, I’m relatively happy with this HostGator server, but lacking the slightest bit of support for this issue (in my case, merely adding All to the right directive in the httpd.conf) was a major inconvenience (and a waste of time).

GoDaddy-hosted sites at risk — WordPress, Joomla!, Pligg, ZenCart, others…

Recently, there was a malicious attack on GoDaddy-hosted sites. It’s tough to track down the exact date of the original attack — I was first able to find a mention of it on Slashdot from 4/26, and I found a topic in the WordPress support forums that supported that approximate time. However, I also found another post elsewhere with a Unix/Linux shell script that would fix what appears to be the same issue which was dated March 2, so this may have been around much longer.  At any rate, there seems to have been another major wave this past weekend.

Last month, Network Solutions was targeted by what appeared to be a malicious user who was able to gain access to sites’ databases by accessing the database server, username and password from the wp-config.php file common to all WordPress installations.  The attack took advantage of the fact that most users don’t change their file permissions, and left the wp-config.php file — with all the above information that it contained — in a public-readable state.  Once the database username and password were obtained, the hacker added a redirect script in the Site URL setting in the options stored in the database which redirected visitors to a site of his choosing.

This taught us the lesson to make sure your files — especially the important files with sensitive data contained within them, like passwords — are properly secured by correct file permissions.

This particular hack on GoDaddy sites did not attack the database, the upside of which means your data, stored passwords, posts, and everything else are still safe. However, according to the reports I found, what it did was embed a small javascript at the bottom of every php file.  The embedded code would ultimately cause visitors to be redirected to a malicious site that would install malware on their PC.  Based on the domain names that were grabbed by an independent security analyst, it looks like the end-goal was to infect a visitor’s computer with malicious software or viruses and then sell them antivirus software (the virus-scanning effectiveness of which would, presumably, be fairly suspect, given the circumstances) — the domains were things like,,,, etc.  That post also points out that the person or people behind this attack have done this before.

So you have a GoDaddy site running WordPress, how do you know your site is infected?  If your site was infected, you would see this when you logged into your dashboard:

At first glance it just looks like the CSS is messed up, not anything that might suggest a virus.  However, when I tried to access the admin panel on two GoDaddy-hosted WordPress sites that we support, my antivirus software gave me a virus warning.  This happened, too, when the Network Solutions hack went down, so I became instantly suspicious.  (My virus software, by the way, is avast! which can be downloaded free for personal use.)

GoDaddy’s official initial response to the issue — which has been posted in a couple different places — was this:

A few of our customers were affected. Here’s what our CISO had to say about it:

“WordPress is a-ok. Go Daddy is rock solid. Neither were ‘hacked,’ as some have speculated.

After an extensive investigation, we can report there was a small group of customers negatively impacted. What happened? Those users had outdated versions of the popular blogging software, set up in a particular way.

This underscores the importance of installing the latest Web applications, no matter where you are on the Internet. If you use Hosting Connection, automatically update WordPress to version 2.9.2 using the simple 3-step update offered when you log-in.

And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure, and in a safe place.”

If you have questions or you’d like someone to take a look at your WordPress site, please get in touch with our 24/7 support team at


Here’s the problem with that statement: it’s wrong.  Both the sites that I saw directly were running the 2.9.2 version of WordPress.  And I’m not alone.  I’ve read reports in forums and blog comments from many users who were not only running up-to-date versions of WordPress, but also had secure and unique passwords for their WordPress backend, FTP and database, and many had countermeasures in place to prevent attacks on their WordPress site.  None of which protected them from being infected.  Later, GoDaddy’s Chief Information Security Officer sent out the following message which is currently appearing on their support page:

If you are experiencing difficulties with your site, you may be using outdated software and unknowingly hosting malware…And, while we’re on the topic of Web security and Best Practices – be sure all your online passwords are unique, secure and in a safe place.

Calls to GoDaddy support about the issue right now are apparently being met with “this is a WordPress issue”-type responses.  But careful viewers of how this particular infection works will see that there isn’t anything specific to WordPress about it — it’s targeting php files on GoDaddy-hosted sites.  Whereas the Network Solutions hack was looking for a specific file — wp-config.php — to gain access to the database, php files can be in any software written in that language, which includes Joomla!, Drupal, ZenCart, Magento, and on and on.  Blaming the issue on bad security practices is a gross misrepresentation of the facts. As of this writing, GoDaddy hasn’t yet tracked down the source of the infiltration or taken much more responsibility for the issue than the above statements.

The good news is that, as far as I can tell, there isn’t anything you did wrong to make your site more of a target. The bad news is no one is sure how the hacker was able to access a huge number of sites on GoDaddy and append a javascript code at the bottom of every php file on those sites. The fact that GoDaddy’s canned response inaccurately suggests that the affected installations were outdated isn’t very reassuring.

Fear not, for there is a fix.  One thing the infected sites seem to have in common is that they are all hosted on Linux servers.  If your GoDaddy site is hosted on a Linux server, you can use the History feature to restore an earlier backup of the files. Since the database was untouched, this won’t affect any posts you may have published, however it may (or may not) affect any media files you uploaded between the time you restore back to and now — so it’s probably a good idea to check those posts for broken image links and the like after you do it to make sure everything is okay.  Check out this help file for full instructions on how to restore your site to an older backup.

Over the weekend, GoDaddy posted a fix to their forums that they referred to as a “permanent” fix. The updated fix involves backing up your database, saving any files you may have uploaded to your site, deleting everything, then reinstalling and restoring your database backup. While this would resolve the issue, until they announce that they know where these attacks are coming from and why they are so widespread, I can’t see this as a “permanent” fix — it’s not any more permanent than restoring from a backup (presuming that the virus wasn’t present at the time the restore point you are using was created).  And evidence suggests that security best practices wouldn’t safeguard your site against attack either.  That said, changing your passwords is probably not a bad idea.

I would like to reiterate that this is not a WordPress compromise, but a GoDaddy compromise. In this case, the sites that were reportedly vulnerable (those that were using a version of WordPress prior to 2.9.2) was inaccurate and given the nature of the attack, I don’t see what the WordPress version really has to do with anything anyway.  Even if we assume the attack only targeted WordPress, 2.9.2 addressed an issue in which users who were logged into the admin panel could look at Trashed posts from other authors. 2.9.1 resolved a number of minor bugs but no security holes. Neither of these would have prevented someone injecting malicious code into the php files of your WordPress installation. Until someone is able to expose the breach, I’m not convinced that any of the posted resolutions and prevention methods are “permanent” nor do I believe that this is the last we’ll see of this attack — from what I’ve been able to gather, many bloggers who fixed the problem last week were hit again this past weekend. (Not surprisingly, domain transfers from GoDaddy to another registrar quadrupled in the last week of April. This doesn’t necessarily mean hosting went with it, but I’d be surprised if the two things weren’t related.)

I don’t like to tell people that you shouldn’t use a certain webhost because of x, y and z. I will make recommendations based on my personal experience and suggest hosts that I’ve had good experiences with, but I’m not one to badmouth other companies to our clients or their decision to go (or stay) with that company. So I’m not going to tell you to switch to something else if you are using GoDaddy. However, if I was using GoDaddy, I’d be very concerned about my site’s security if it was running any kind of web application (blog or forum or CMS, WordPress or otherwise) until their Security team says something other than “make sure your passwords are secure.” What’s more, while Network Solutions was able to respond to, and secure the attack on their hosted WordPress sites within 24 hours (at least the initial attack, if not the subsequent attacks that came later), GoDaddy was hit with this, initially, sometime around April 21 or even much earlier.  I’ve seen no indication that they resolved the initial breach, let alone these new modifications.

If you have been compromised, or you are concerned about being compromised, I urge you to contact GoDaddy and express your concerns and try to learn what they are doing to prevent this attack from happening again. The more concerned customers they hear from, the more urgent the issue becomes and, hopefully, the faster they will work to resolve it.  However, if you would rather not be at risk just waiting for this weekend and the next wave of attacks, we highly recommend 1and1 for web hosting, and if you have questions or concerns about your site, you can contact us for a quote.  We can fix your infected WordPress site, help with your webhost transfer, or clean your infected php site that uses a different platform.

Tomorrow I will be posting an article about what you can do to keep your website as safe as possible.

If you would like to learn more about the issue, here are some of my sources:

Massive Number of GoDaddy WordPress Blogs Hacked [slashdot]
Warning! Massive Number of GoDaddy WordPress Blogs Hacked This Weekend [BlogcastFM]
GoDaddy/WordPress ninoplas Base64Virus and the Fix [inspirated]
GoDaddy WordPress blog hacked [WordPress Support Forums]
What people are saying about “GoDaddy WordPress” [Twitter Search]
GoDaddy Hacked WordPress Hosting Accounts [Smooth Blog]
WordPress on Hacked [NeoWin]
WordPress Compromised? How to Fix It! [GoDaddy]
GoDaddy Support [GoDaddy]
WordPress 2.9.2 [WordPress Development Blog]
WordPress 2.9.1 [WordPress Development Blog]
Restoring a Linux Hosting Account [GoDaddy]
GoDaddy Domains Lost by Transfer QUADRUPLE!! [NoDaddy]
Registrar Report for GoDaddy [WebHosting.Info]
Ninoplas Base64 WordPress Hacked on GoDaddy [WPSecurityLock] – WordPress Hacked [WPSecurityLock]
GoDaddy’s Mass WordPress Blogs Compromise Serving Scareware [Dancho Danchev’s Blog]
Breaking News!  Dangerous Malware Alert — Self-Hosted Sites on Major Hosting Service Hacked Again! [WPSecurityLock]
Details on the Network Solutions/WordPress Mass Hack [Sucuri Security]
The Kneber botnet – FAQ [ZDNet]