PHP 5.4.31 and 5.5.15

The PHP developers recently released versions 5.4.31 and 5.5.15 that fix several bugs. We’ve updated PHP 5.4 and 5.5 on our servers as a result.

Read the rest of this entry »

Sites hosted with us aren’t subject to website “cross-contamination”

One of our customers asked if the Add-On Hosting domain names we offer are vulnerable to “website cross-contamination”, a nasty security problem that can happen when two different sites share the same “account” on many hosting companies.

The answer is no. We intentionally handle Add-On Hosting domain names differently from the way most hosting companies handle extra hosted domain names, avoiding the problem.

Read the rest of this entry »

Blocking more WordPress xmlrpc.php attacks

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 »

WordPress security plugins that hide the source of blocking

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 »

Problems with mail forwarding from “@cs.com” addresses

A customer recently reported problems when forwarding mail sent from a “@cs.com” CompuServe address to a Yahoo or Gmail address. Yahoo completely rejects the forwarded message and Gmail puts it in a “spam” folder.

This is caused by a misconfiguration at cs.com, and happens whenever anyone, anywhere, forwards @cs.com mail. It’s not related to our service in particular. However, we’ve reported this to cs.com in the hope that they’ll fix it.

Until they do so, there’s no way to avoid this problem except by having the sender send mail directly to the final destination address, or converting the forwarding address to a mailbox. (This problem is another example of the general rule that “a mailbox is usually more reliable than a forwarding address, because forwarding involves two places where things can go wrong instead of just one”.)

Read the rest of this entry »

4th of July 2014 holiday hours

Our business offices will be closed on Friday, July 4 to observe the US legal holiday. As always, we’ll provide same-day support for time-sensitive issues via our ticket and e-mail systems. However, questions that aren’t time-sensitive (including most billing matters) may not be answered until the next business day (i.e., Monday), and telephone support (via callbacks) will be available only for urgent problems.

Temporary web14 load problem (resolved)

7:11 AM Pacific time: Our technicians are investigating a possible outage on the “web14” server.

Final update: We found the source of the problem — there were a couple of short load spikes over a period of 10 minutes. We have taken steps so that it doesn’t happen again.

We know that uptime is critical for our customers, and we apologize for the inconvenience caused by this event.

Routing problem for some East Coast users (resolved)

We have gotten quite a few reports from users on the East Coast that they cannot connect to their Web sites on our servers, to our Web site, or to our e-mail servers.

Analysis shows that the problem is with a network called nlayer.net which is between them and our servers. When you make a connection to a remote server, the connection travels from your ISP, through several different intermediary networks, and finally to the destination network and server. Each of these networks needs to properly “route” the connection to the next closest node to the destination. The current problem seems to be that the data packets are getting lost within the nlayer.net network.

You can verify this by running the command “tracert www.tigertech.net” on Windows, or “traceroute www.tigertech.net” on Mac (Terminal). You’ll see that your packets can get through your ISP, but after they get handed off to nlayer.net the packets get lost. (A line that ends with *** is a failure.)

While you may have a problem in the network route between your computer and our servers, most other people on the Internet use different routes and can continue getting to your site just fine. You can also verify this with third-party sites, such as checksite.us.

This sort of problem is not uncommon, but is usually resolved within a few minutes. It’s up to nlayer.net to fix their routing; we presume they are working on it.

Update 9:56 AM (Pacific time): It looks like nlayer.net has fixed their problem. We see that customers who had been having problems can now reach their Web sites (and our site) successfully. Please note that no incoming e-mail was lost during this. Any incoming e-mail would have queued up for later delivery, and will get redelivered to our mail servers (soon, if not already).

Even though the cause of this problem was out of our hands, we certainly regret the inconvenience that it caused those who were affected.

Brief scheduled maintenance June 7, 2014 (completed)

Between 10:00 PM and 11:59 PM Pacific time on Saturday, June 7, each of our hosting servers will be restarted. This will cause a brief interruption of service (less than 10 minutes) for each site at some point during this 2 hour period.

Read the rest of this entry »

Networking issues June 4 2014 (resolved)

2:49 AM Pacific time: We’re receiving scattered reports of intermittent problems when connecting to our servers from Europe, although all services on our end are working normally.

3:30 AM Pacific time: This issue appears to be a problem within the network of one of our upstream providers. We have temporarily disabled routing network traffic through that provider, and the trouble is resolved.