Our Web hosting customers who use FastCGI have been seeing extra “500 internal server” errors in their logs and statistics since September 12.
The good news is that this is just a logging bug caused by a recent Apache Web server update. Visitors to your site are seeing exactly what they always saw, and there isn’t any problem besides the incorrect logging.
If you use WordPress blog software on your site, be sure to upgrade to WordPress 2.8.4 as soon as possible. The upgrade contains important security fixes.
Although all WordPress users should upgrade right away, we’ve added security rules to our servers to protect our Web hosting customers who haven’t yet upgraded. Other people may find the rules useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.
For the last several years, we’ve offered PHP versions 4 and 5 on our servers. This made sense when PHP 5 was new: Even though PHP 5 is faster and more secure than PHP 4, a small handful of scripts were originally incompatible with version 5, and we wanted to give customers a choice.
However, PHP 5 is now more than five years old, and the PHP developers declared version 4 obsolete in 2007. All our new customers have been using PHP 5 by default for more than a year, and we’ve received no complaints about incompatibilities.
No PHP script should require the obsolete PHP version 4 any more. Because of that, we’re beginning the process of removing it from our servers.
Zen Cart is a popular e-commerce platform that many of our customers use.
Unfortunately, the current version of Zen Cart has a bug that allows “hackers” to take control of the Zen Cart software, which includes making changes to the Zen Cart database and installing new files. “Exploits” that take advantage of the bug have started circulating widely in the last 24 hours.
An earlier blog post described how several of our customers got their personal computers infected by a new virus that has been spreading across the Internet. Initial versions of the virus spread themselves by reading a Web site’s FTP username and password stored on the PC, then downloading Web pages, inserting an “iframe” tag, and re-uploading the Web pages back to the server. As a proactive measure, we started scanning all uploaded files and stripping out any malicious “iframe” tags.
We are now seeing newer versions (commonly called “Gumblar”) which spread by inserting “script” tags with encoded JavaScript code. Because there are several variations of this approach, and because some legitimate commercial scripts use the same technique to hide their source code, we cannot perfectly identify and strip out these infections. Therefore, we will not automatically strip out the “script” tags from any upload file that looks suspicious.
We’ve added a new feature to hosting accounts: Live, realtime access to the Apache Web server “error log”, both in the “My Account” control panel and as raw files you can access through FTP/ssh/etc.
To view the most recent 200 lines of the error log, login to the control panel (having trouble?), click “Statistics and Logs”, and look at the new “Web site error logs” section.
To download the full raw error log files, see this page.
We hope you find this useful!
Recently, several customers have told us that pages on their Web sites have been modified without their knowledge. Upon investigation, the customers found their computers had been infected with a virus that steals saved FTP passwords, such as the “Gumblar” or Trojan.PWS.Tupai.A virus.
We’ve taken a step to protect you against this problem (described below), but it’s wise to protect yourself, too.
We recently had a server that twice “crashed” and needed manually restarting. We’ve identified the cause of that problem — an apparent bug in Linux kernel version 2.6.26 — and made some changes to ensure that it doesn’t affect our customers again.
However, we didn’t find any information about this problem when searching the Internet, so we’re describing the details here in the hope that it helps someone else.
We host some pretty high-volume WordPress sites, and one of the questions that occasionally comes up is “How can I make WordPress faster?”. That’s really just another way of saying “What part of my WordPress site is slow?”, which translates to “What requests are using a lot of CPU time?”
This question is surprisingly difficult to answer, particularly because we encourage customers who run busy WordPress sites to use FastCGI and caching. A single FastCGI process can handle lots of different PHP requests, so it’s hard to break down which individual request used what amount of server resources.
To solve this problem, we recently patched our version of PHP to optionally log the CPU time used by each request, even under FastCGI, so we could see what was really happening (patch available here).
What we found was unexpected. On some busy WordPress sites, 20–30% of the CPU time was being used to handle requests for “favicon.ico”. What the deuce?!
We’ve made a technical change to the way our servers handle SSL connections (we’ve disabled 40 bit and 56 encryption ciphers). The change shouldn’t affect anyone, but we’re describing it here just for the record.
