Stephen Foskett, Pack Rat » WordPress Archives – Stephen Foskett, Pack Rat

How My Blog Became Infected With MW:JS:150 Malware (And How I Fixed It)

Stephen — Thu, 26 Jan 2012 22:39:08 +0000

This week, two blog readers let me know what Google Chrome was warning them of malware on my blog. I dived in and discovered that, indeed, a nasty, obfuscated JavaScript attack had made its way into my site. Although I was disappointed by the lack of clarity about how to fix it, I believe I was able to remove it last night. Here’s what I did.

A Nasty Hole in Timthumb.php

I’ve used the StudioPress Genesis themes for over a year now, but previously used a variety of others. One, Metamorphosis, included a handy thumbnail generator called Timthumb.php (or more precisely, thumb.php).

It appears that someone figured out how to exploit Timthumb to insert arbitrary code in WordPress blogs.

Since I was no longer using that theme, I had forgotten it was even installed. But it seems that users can manually request theme files even if the theme isn’t activated.

On Sunday, someone from IP address 91.196.216.20 (specenergo2.ru) requested dozens of different themes that use timthumb.php or thumb.php. They hit the jackpot with the following request:

91.196.216.20 - - [22/Jan/2012:02:00:52 +0000] "GET /wp-content/themes/metamorphosis/thumb.php HTTP/1.1" 400 319 "-" "-"

This was clearly an automated attack, and provided a solid clue about the hack.

Two days later, 81.95.114.105 returned and used thumb.php to add a file to my cache directory. He then executed that php file many times, injecting obfuscated JavaScript into my blog files:

81.95.114.105 - - [24/Jan/2012:10:12:39 +0000] "GET /2008/07/26/move-os-x-time-machine-backups-new-disk//wp-content/plugins/backups/cache/68d579e3ed4163b172ee2b887dc8ba54.php HTTP/1.1" 301 839 "-" "Mozilla/5.0 (Windows;U;Windows NT 6.0; en-US; rv:1.8.1.8pre) Gecko/20070928 Firefox/2.0.0.7 Navigator/9.0RC1"

I’m assuming this was another person, and that the IP isn’t a definitive indication of where the hacker was. But they had succeeded in getting their JavaScript junk into my WordPress theme.

Hello, MW:JS:150

The inserted JavaScript is pretty clever. It’s obfuscated in a number of ways, but pretty obvious in the header of the blog:

This code apparently caused site visitors to open an invisible frame with ads in it. It sets a cookie so it won’t run more than once, and also checks to hide itself from many spiders and search engines.

So it’s basically a web ad scam, intended to defraud someone like Yahoo by making it appear their ads are getting more impressions and clicks than they really are.

I was able to detect the malware using sitecheck.sucuri.net, which is where this name comes from. Note that they claim it comes from infected desktops, but I am fairly certain it came instead from the Timthumb php attack.

Cleaning Up

Cleanup was not at all straightforward, since it was mixed with detection and deduction.

The first thing to do was protect Timthumb from further exploits. I installed Timthumb Scanner, which detects and updates compromised versions of Timthumb.php.

Next, I reinstalled WordPress and my themes. Then I blew away my Super Cache files.

I also changed my blog password and WordPress cookie salts.

Finally, just to be safe, I ran chkrootkit and changed my UNIX passwords.

This appears to have eliminated this particular attack. I hope this helps!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2012. | How My Blog Became Infected With MW:JS:150 Malware (And How I Fixed It)
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

SlideShare Embed Injects ScoreCard “Market Research” Junk

Stephen — Fri, 20 May 2011 15:30:59 +0000

I’ve used SlideShare for a while, and enjoy embedding the viewer into blog posts about my conference presentations. But lately I’ve noticed weird behavior in the WordPress editor and set out to determine what was going on. It appears that SlideShare is injecting a tracking code from “ScoreCard Research” when their slideshow embed code is used. This would be bad enough on its own, but this embedded JavaScript seems to interfere with the WordPress editor and I saw no indication of an opt-in or privacy policy regarding this.

The embedded script is automatically added to the bottom of the editor window when the slide share embed code is pasted in. It appears to re-add the script multiple times as images are uploaded and inserted or one switches between the visual and HTML displays of the WordPress editor. My latest such post, a summary of my Interop presentation on FCoE versus iSCSI, contained half a dozen copies of this script code!

Here’s a copy of the injected code:

SlideShare took exception at being labeled a malware injector, claiming this is “just a comscore analytics link”, but malware is as malware does, and this tracking script interferes with the operation of the WordPress editor and is added without consent. I call that malware, and I call foul. If SlideShare wants to monitor the use of their embedded slideshows, they should simply add tracking to their own JavaScript code, rather than clumsily adding a third-party script.

I recommend switching to HTML mode and removing the script before pressing “Publish” whenever using SlideShare embeds. And I suggest reconsidering whether you want to use a service that does this sort of thing. I know I’m considering dumping SlideShare and deleting my account!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2011. | SlideShare Embed Injects ScoreCard “Market Research” Junk
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Back From the Pile: Interesting Links, January 14, 2011

Stephen — Mon, 17 Jan 2011 13:49:34 +0000

This regular series features highlights from the week. It was another big one for me, with my Network Computing writing gig starting up, the announcement of my Storage for Server Virtualization seminar series, and the finalization of Tech Field Day for February.

Things I wrote
- I kicked off my new Network Computing column with this one: Ethernet Has A Goldilocks Problem (and here’s a response: Network Convergence: More than Just 10 GbE)
- TSIA! Is PCIe SSD right for you? Deploying PCI Express SSD devices
- I haven’t written for Silicon Angle in a while, but thought this was best there: From Scale-Out to Big Data to the Cloud
- Will You Be At The ExecEvent? I will, and it’s just two weeks away!
- Sometimes you have an idea: The Three Requirements To Overcome Inertia
- I’m Open-Sourcing My 2011 Storage For Virtual Environments Seminar! So now I Need Numbers!
- Apple Breaks ICS Calendar Auto-Subscription In iOS 4.2
Other great links
- Derek Schauland asks the eternal datacenter question: Where can I plug in?
- Brandon Carroll documents that Solarwinds Install is Easy as Pie!
- I love Greg Ferro’s Network ZEN, but this week’s was especially awesome: Network ZEN: A Switch
- Nigel Poulton puts together some amazing storage content. Case in pout: VMAX vs VSP
- Seriously, Google? Google stripping support for H.264 video out of Chrome
- The most-scary WordPress article I’ve read in a long time: Why You Should Never Search For Free WordPress Themes in Google or Anywhere Else
- Howard Marks takes on a topic we discussed last time I was in New York: More on Advanced Erasure Codes
- Top Five Storage Technologies for 2011 <- Good guess!
- The only insanely great thing to come out of CES: Breakthrough device of CES 2011: Motorola Atrix = Phone + PC
- I love words 20 Awesomely Untranslatable Words from Around the World

Subscribe to my Google Reader feed or follow me on Twitter to see these in real-time.

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Back From the Pile: Interesting Links, January 14, 2011
This post was categorized as Enterprise storage, Everything, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

How To Make TimThumb Play Nicely With TanTan’s WordPress S3 Plugin

Stephen — Wed, 06 Oct 2010 16:12:10 +0000

Just a random photo to demonstrate that TimThumb is working properly with Amazon S3

I’m loving the Woo theme for this blog, and especially love that they integrated the cool TimThumb script to automatically resize thumbnails for the main page. But everything stopped working when I added TanTan’s WordPress-S3 plugin to store my images on Amazon’s servers. Luckily, I found a fix!

The first step was upgrading Woo’s version of TimThumb.php. I downloaded the latest version from Google Code and replaced the thumb.php file in the theme directory (under wp-content/themes).

Next, I had to add Amazon S3 to the “allowedSites” array in thumb.php. I added the following line:

 's3-1-w.amazonaws.com',

I also had to tell CURL to allow the SSL connection by adding the following line under “$ch = curl_init ($src)”, around line 606:

 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

Then we need two subdirectories, temp and cache, in the same directory as the plugin. Make sure both are writable with an old “chmod 777″. I found that Woo automatically created the “cache”, but the “temp” was AWOL.

That’s it! Now that I did this mod, TimThumb and WordPress-S3 are playing nicely and all is right with the world. The image above (my own photo) was uploaded and thumbnailed automatically!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2010. | How To Make TimThumb Play Nicely With TanTan’s WordPress S3 Plugin
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

A High-Performance, Low-Memory Apache/PHP Virtual Private Server

Stephen — Fri, 30 Jul 2010 18:16:38 +0000

I’ve previously written about my Multi-Server Web Hosting Environment and the how I Tuned Lighttpd For Linux to run as well as possible. But I’ve been having weird issues with that setup lately and was forced to rebuild the server entirely. While I was at it, I decided to give Apache another try, since the lighttpd hackery I needed to perform to get things like WP-SuperCache running were starting to get me down. The configuration documented here uses Ubuntu Lucid (10.04), Apache 2.2, FCGI, and PHP-CGI tuned for a 512 MB virtual private server (VPS) running on Rackspace Slicehost.

A Brief History of the Web

I’ve been pretty happy with lighttpd as my web server. It’s light and quick and has a workable fastcgi/PHP implementation. Right out of the box, lighttpd kicks Apache up and down the block on low-memory servers – the kind you’ll find in virtual private server hosting companies.

To understand why lighttpd is so good, we have to understand why Apache is so bad. And this means going way back in time to the dawn of the web. In the beginning, web servers were single-threaded processes that slapped pages over network connections on demand. This is like a single lemonade stand, where every customer waits in line but there’s only one item on offer and it’s a quick serve. So the line moves pretty quickly but it’s not all that interesting.

The Netscape Navigator browser revolutionized end-user experience by downloading web page elements in parallel and displaying them as they came in. Web servers responded by “forking” multiple copies of themselves to handle these requests (and those from other users) in parallel. Our lemonade stand is still limited in selection, but it now has more workers to hand over the juice.

At the same time, users began demanding more-interesting content. Web 2.0 replaced the old static HTML pages and graphics with interactive web applications, and the PHP language became dominant. Today, most popular web software (including WordPress and Mediawiki) require a PHP interpreter as well as an HTTP server to run. In the old days, server-side compute was handled by a “back room” CGI task. Our lemonade counter is now a restaurant, with a kitchen and added a variety of hot foods. But customers (and servers) have to wait while these are cooked up.

The Apache answer to this challenge was to add a kitchen to every checkout position. Out of the box, installing Apache and PHP adds a complete PHP runtime to each Apache process. And since the Apache PHP module is reputed to be unstable in multi-threaded environments, these default setups use the “prefork” single-thread-per-process method of handling multiple connections. Now our imaginary fast food restaurant can handle an unlimited number of customers in parallel, right?

In practice, this doesn’t work well. A 50-position counter could handle tons of customers, but that would be one wide restaurant! The same issue crops up with Apache. It looks super-speedy until loaded up (say, with a midnight Google, Yahoo, or MSN crawl) when it promptly uses up all of your memory forcing the OOM killer to murder your system. The only way to get this default (mod_php/mpm-prefork) version of Apache to be stable, other than adding RAM, is to limit the number of processes spawned. Customers are now back to waiting in line for just a few servers and their experience suffers.

Lighty Did It, Apache Didn’t?

Lighttpd (“lighty”) is totally different. It is a small, lightweight HTTP server that farms out PHP tasks to a constantly-running PHP process. This sounds pretty much exactly like the single-kitchen CGI approach of the mid-1990′s, but there’s a trick here (as there was then) that makes it work. In traditional CGI, the command processor was started on demand and closed when its work was done. Like a short-order cook, PHP-CGI makes everything to order.

But Netscape had a better idea. They built an always-running server (NSAPI) that could save work in a cache and reuse it for the next visitor. Suddenly we have a full kitchen up and running, complete with prep and sous chefs, able to turn orders around almost as quickly as the servers placed them. FastCGI was an open implementation of this concept, and it allows little lighttpd processes to serve up complex PHP web sites with ease.

Apache has a similar capability, using the modern FCGI implementation, and has also added multi-threaded server capability called mpm-worker. But the multi-threaded server is reputedly unstable when running PHP as a module, and configuring both mpm-worker and mod_fcgi isn’t yet standard-issue for Apache installs. So most Apache users still use the old prefork/mod_php configuration while most lighttpd users now rely on fastcgi.

Now, these FCGI PHP processes aren’t exactly light. Each can use 100 MB or more, especially when xcache is used for faster processing. So a lightweight server still needs to limit the number of “kitchens” serving the customers. And using a separate process to handle PHP isn’t as speedy as having an integrated PHP engine. But having more light HTTP servers to move files around reduces the overall load on the system, even if complicated tasks might have to wait for PHP processing.

Then there’s WP-SuperCache. This WordPress plugin converts complicated PHP pages into simple HTML for the HTTP server to hand off to visitors. In combination with a lightweight server like Apache/mpm-worker or Lighttpd, WP-SuperCache speeds up WordPress sites dramatically.

Although it’s possible to convince Lighttpd to play nicely with WP-SuperCache (using mod_magnet), it’s much easier and better-supported in Apache. I was also having an odd issue with Lighttpd “pausing” for a few seconds when clients connected it. So I decided to make the switch back to Apache.

Configuring Apache With MPM-Worker and Mod_FCGI/PHP-CGI

Now for the technical details. WP-SuperCache and Lighttpd might be poorly-documented, but Mod_FCGI in Apache isn’t much better. There are a dozen ways to do everything, and everyone’s recipe differs. Here’s how I got it to work.

First, I spun up a fresh 512 MB VPS on Slicehost running Ubuntu 10.04 Lucid. I configured it my normal way (locking down access, setting up a restrictive firewall, and installing only basic packages) and rsync-ed over my web site content.

One goal when tuning a server is to use all of the RAM but not much of the swap. Unused RAM is wasted potential, while swapping processes can quickly kill performance. This is one reason to run Apache with FCGI: You can run just a few heavy (large RAM footprint) PHP engines and many more light (3-5 MB) HTTP servers. Using the multi-threaded mpm-worker mode allows each of those Apache processes to serve more requests with less process creation and destruction.

My next step was to install Apache and its required modules along with mpm-worker, mod_fcgi, php5-cgi, and the rest needed to support wordpress. I think the following command should do the trick:

sudo apt-get install apache2-mpm-worker libapache2-mod_fcgi \
php5-cgi php5-xcache php5-mysql wordpress

This won’t work out of the box. We have to set up some wrapper scripts and configuration files for fcgi and php-cgi, but more important is the tuning, which we’ll get to next.

First, create a php-cgi wrapper for FCGI to use. I called mine /usr/local/bin/php-wrapper and set up a very basic environment. Be sure to make this script executable, too.

#!/bin/sh
# Set desired PHP_FCGI_* environment variables.
# Example:
# PHP FastCGI processes exit after 500 requests by default.
PHP_FCGI_MAX_REQUESTS=1000
export PHP_FCGI_MAX_REQUESTS
# DO NOT SET PHP_FCGI_CHILDREN!
# Replace with the path to your FastCGI-enabled PHP executable
exec /usr/bin/php-cgi

As the script comment says, whatever you do, do not set PHP_FCGI_CHILDREN in some misguided attempt to conserve RAM. It will conflict with mod_fcgi and you’ll end up spawning RAM-hungry but useless child processes and killing your system!

Next, create an fcgi configuration file called /etc/apache2/conf.d/php-fcgid.conf and containing something like the following lines:

FcgidInitialEnv PHPRC=/etc/php5/cgi
FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000
# FcgidMaxRequestsPerProcess should be <= PHP_FCGI_MAX_REQUESTS
# The example PHP wrapper script overrides the default PHP setting.
FcgidMaxRequestsPerProcess 1000
FcgidMaxProcesses 3
FcgidMaxProcessesPerClass 3
FcgidMinProcessesPerClass 1
# Uncomment the following line if cgi.fix_pathinfo is set to 1 in php.ini:
# FcgidFixPathinfo 1
# This makes php scripts work everywhere Apache serves

AddHandler fcgid-script .php
Options +ExecCGI
FcgidWrapper /usr/local/bin/php-wrapper .php
# Customize the next two directives for your requirements.
Order allow,deny
Allow from all

This is a very permissive configuration, and you might want to tweak things somewhat. But you get the general idea. The important things going on here are the configuration of FCGI to launch just 3 PHP-CGI engines and the assignment of the php-wrapper script to files ending in “php” anywhere Apache finds them. This means no special configuration is needed in VirtualHost directives, or anywhere else really.

One more tweak I like is to limit Apache to just 6 worker processes. Since each is multi-threaded and under 5 MB in this configuration, this works well. Add a line to /etc/apache2/apache2.conf in the “” section saying the following. This is a good complement to the default setting of 25 ThreadsPerChild and 150 MaxClients.

ServerLimit             6

Limiting the number of php-cgi processes launched is critical for low-memory systems. A good-sized opcode cache (thanks to xcache) helps them perform well but grows the memory usage like crazy. Although I had just three php-cgi processes running, with one topping 225 MB, overall system performance remained good thanks to WP-SuperCache and six multi-threaded lightweight Apache HTTP servers.

So far, I’m able to serve multiple WordPress and Mediawiki sites with a few thousand pageviews per day on a 512 MB slice. Running with six Apache workers and 3 or 4 php-cgi processes just gets me under the RAM limit. Of course, I’m still using a separate 256 MB server for MySQL in addition.

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2010. | A High-Performance, Low-Memory Apache/PHP Virtual Private Server
This post was categorized as Computer History, Everything, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Vendor Non-Blogs

Stephen — Wed, 20 Jan 2010 18:00:33 +0000

As previously-independent bloggers are being hired in droves by the major IT infrastructure hardware and software vendors, attention is turning to their independence and credibility. But this extends far beyond blogs: Today’s social media influencers are everywhere!

Biased content isn't just found on blogs - it's much more likely to be found in other areas like Twitter and discussion forums. When does discussion become Astroturf?

Discussions Are On The Move

The new Internet isn’t just about blogs. In fact, the majority of social media discussion and linkage probably happens on Twitter, LinkedIn, discussion forums, and other sites. But non-blog content raises even thornier bias issues than blogs:

Discussions are less formal than blog posts, so off-the-cuff comments are common. The rapid turnaround of Twitter comments encourages “post-before-you-think” thinking, and knee-jerk comments can be damning. Even if one did not intend to but another vendor down, it’s easy to say something inappropriate.
The length of a comment is limited, so subtle nuances get lost. I’ve often had trouble saying what I want in 140 characters, and even blog and forum comment conventions restrict verbosity. Again, sometimes your meaty tweet will really cut a competitor to the bone.
Biographical information is limited. Twitter profiles include just a few words and a single URL, restricting the disclosure of relevant information. Many profiles don’t include the name of an employer or disclosure of other vendor ties. Forum profiles and signatures are similarly restricted.
The Internet scatters content. Even if one is careful to disclose one’s business relationships on a blog, Twitter profile, or LinkedIn page, interactions go far beyond these.

Conferences are even worse. Many attendees switch badges or intentionally list a different company just to get in the door, obscuring their identity. And no one knows who the guy in row 12 is or why he is asking such pointed questions of the panel. The same thing happens with webinars and Internet polls.

All these limits obscure the good folks out there and conspire to allow the bad ones to act with impunity. This makes everyone suspect. Actively comment on a number of industry blogs and you could be accused of astroturfing! Whether it’s fair or not, employees of hardware and software vendors are being held to a higher standard than so-called independents.

Personal Defensive SEO

I’m going to assume you’re a good egg and want everyone to know where you’re coming from when you interact on the Internet. Many businesses actively engage in search engine optimization (SEO) to help them rise to the top of Internet search results. Individuals need to start doing some SEO, too, but the reason is different: Make yourself easy to find and disclose your connections and you won’t look like a bad egg.

Get a LinkedIn profile, keep it up to date, and set your name and company information to public. Go to Settings -> Public Profile, and turn on Basics, Summary, Current Positions, and Websites at a minimum. And make sure Websites includes your current employer and blog(s).
Create a Google profile with links to your LinkedIn profile, blog, Twitter, and other profiles. This helps Google and other search engines disambiguate you from the rest of the crowd. FriendFeed is another great place to set up a profile. I only use Facebook for personal/private connections, so I don’t bother with corporate links there.
Make sure your blog includes links to your Twitter and LinkedIn profiles, too. And pepper your blog with your own full name so it shows up in Google searches.
Include your employer’s name in your Twitter “one line bio” and use your blog as your Twitter profile URL.
Set up Disqus, Intense Debate, WordPress, and Typepad profiles and use them whenever possible.

All this effort won’t directly help you, though it might save a few minutes when you try to comment on a blog. But they will make you easier to find, and reduce the likelihood that someone will accuse you of not disclosing your corporate affiliations.

Astroturf car, public domain image by Ingolfson

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Vendor Non-Blogs
This post was categorized as Enterprise storage, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Setting Up a Multi-Server Web Hosting Environment

Stephen — Sat, 27 Jun 2009 00:00:32 +0000

The last few weeks have been tough on my web servers. The release of iPhone OS 3.0 tripled my site traffic overnight as folks investigate the new Exchange integration features, and traffic to IT commentary site, Gestalt IT, which I also host, has been growing rapidly. Plus, Google just refreshed PageRank again, sending even more visitors my way.

I had switched from Dreamhost to Slicehost back in February to improve reliability and performance, but the meagre 256 MB of RAM in my virtual private server (VPS) “slice” proved insufficient. The time had come to completely redo my core hosting infrastructure. After some experimentation, I have settled on a simple two-server configuration based on Ubuntu Linux, MySQL, and lighttpd. I thought it would be a good idea to document this new configuration, as well as my previous experiments, for posterity.

If you’re interested in setting up a web site as outlined here, I recommend Slicehost. They’re not the cheapest, but their VPS servers are fast and reliable.

History

My web hosting environment has transitioned over the past six months. I had relied on shared hosting from Dreamhost for almost a decade, with my servers sharing infrastructure and management with thousands of others. This worked fine until I began to see significant traffic increases since creating this blog. Shared hosting just didn’t cut it once I had more than a few thousand pageviews per day.

I tried Dreamhost’s interesting and very flexible virtual private server capabilities, but could never get them working reliably. Plus, the core networking and storage performance of the Dreamhost infrastructure left something to be desired. After much research I switched to Slicehost, an all-VPS provider that has recently been acquired by Rackspace. Although they are not the cheapest or most flexible, Slicehost is a very professional service with good support and excellent infrastructure and connectivity.

I had been using a single 256 MB slice to host my entire site, and had managed to get everything well with lighttpd and MySQL, but this configuration ran into serious performance issues once traffic built again. Once I passed 10,000 pageviews per day, which happened quicker than I hoped, it was again time to upgrade.

Server Configuration

My core question was whether to go with a single 512MB or two 256 MB slices. Would resource contention in a single server be outweighed by the extra available RAM? After consulting with the experts, I decided that it was time to separate the database and web servers.

A multi-server setup delivers performance, reliability, and future capability.

As illustrated above, the database and web servers communicate via a high-speed private network, a standard Slicehost component. I created extremely restrictive iptables firewall policies to control access to both servers, disabling almost all communication. The database server in particular is inaccessible except from the web server, and even then only allows MySQL and public key ssh. Both servers are running bare-bones versions of Ubuntu 9.04.

MySQL Configuration

MySQL is much happier on its own dedicated server. It makes excellent use of its own query cache and operating system buffers and has very little disk access at all. Query performance immediately jumped, and site performance noticeably improved.

My only change to my.cnf was to enable the query cache. This works great on my 256 MB slice:

# Enable query cache
query_cache_limit       = 2M
query_cache_size        = 32M

I’m not a believer in security through obscurity. Sure, you can use a special high MySQL port, but by then you’ve probably lost anyway. Regardless, set up iptables to only allow access from your web server’s private interface using the -s parameter:

# Allow connections on our MySQL port
-A INPUT -p tcp --dport mysql -s 10.176.x.x -j ACCEPT

It’s a pretty simple configuration, but it works well. MySQL is humming along without much paging at all, using the entirety of the 256 MB available for caching. I haven’t had to resort to any tricks to keep the performance up.

One more configuration suggestion: Use a unique username and password for each database application and grant access only to that user on the private network interface. That way, your risk is segmented to a single database should an intruder use a SQL injection or something similar.

For example, say you were configuring the database “myblog_wp” for the user “me_myblog” with the password “123456abcdef”. You use the web server’s private interface address, 10.176.x.x as well so it is harder to get in even if your firewall is breached.

mysql -u root -p
Enter password:
mysql> grant all on myblog_wp.* to 'me_myblog'@'10.176.x.x' identified by '123456abcdef';

All set!

Basic Lighttpd Configuration

Back on the web server, we configure iptables to only allow connections to lighttpd on port 80 and ssh on whatever port you decide. Again, some suggest using a high port for ssh, but if you’ve configured sshd correctly then using an obscure port number is more likely to be a hassle for you than keep anyone out. Here are some good settings for /etc/ssh/sshd_config:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
UsePAM no
UseDNS no

This forces all logins to use established public/private key pairs rather than passwords. Protect your keys and you’re in good shape. Key passphrases are a very good idea here! You’re also disallowing root in any case, since you’re using sudo for all administrative tasks, right?

Next we need to set up lighttpd. I’m using the basic packaged versions for ease of maintenance rather than building my own. I also loaded the stock versions of php5 and mysql-client which integrate nicely. I used to use eaccelerator but didn’t love having to recompile it myself and had some mysterious lockups with it running. So I went with XCache, which is developed by the same fine folks who created lighttpd.

sudo aptitude install mysql-client lighttpd php5-xcache

Why not use Apache? I actually tested Apache with my site before deciding to use lighttpd. I was able to tweak it to run in 256 MB of RAM by limiting the number of worker processes created to 4, but Apache just couldn’t handle the site load. Connections were stacking up and pageviews dropped as people gave up. Lighttpd with XCache is blindingly fast and fits in my 256 MB RAM envelope nicely.

The only real issue I have with lighttpd is that configuration is entirely different from Apache and remains less well-supported. It doesn’t use with .htaccess files, for example, and rewrites use a unique syntax.

Lighttpd for WordPress

Here’s a basic virtual server for /etc/lighttpd/lighttpd.conf for a WordPress domain:

$HTTP["host"] =~ "^(blog\.)?yourdomain\.com$" {
  server.name = "yourdomain.com"
  server.document-root = basedir + server.name + "/blog"
  url.access-deny = ( "wp-config.php" )
  dir-listing.activate = "disable"
  url.rewrite-final = (
    # Exclude some directories from rewriting
    "^/(wp-admin|wp-includes|wp-content)/(.*)" => "$0",
    # Uncomment to exclude Google FriendConnect files
    # "^/(canvas.html|rpc_relay.html)" => "$0",
    # Exclude .php, robots.txt, favicon.*, and sitemap.xml files at root from rewriting
    "^/(.*.php|sitemap.xml|robots.txt|favicon.*)" => "$0",
    # Handle WordPress permalinks and feeds
    "^/(.*)$" => "/index.php/$1"
  )
  accesslog.filename = basedir + "/" + server.name + "/log/blog.access.log"
}

This configuration accomplishes many of the important tasks of WordPress configuration. Most importantly, it works!

Permalinks and feeds are correctly redirected so no ugly index.php is used
Critical directories like wp-admin and files like robots.txt still work
Your wp-config.php file is explicitly protected
Directory listings are disabled
A site-specific access log is used (like Apache)

I’d love feedback on this configuration! One weird thing I’ve not yet figured out is how to use a site-specific error log. I haven’t configured pretty MediaWiki links in lighttpd yet, but imagine a similar configuration would work there.

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Setting Up a Multi-Server Web Hosting Environment
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Google Just Recalculated PageRank!

Stephen — Wed, 27 May 2009 20:51:22 +0000

Although I’m no search engine expert, I’m naturally interested in “how all this stuff works.” That’s why I’ve never owned any gadget I’ve never taken apart (iPhone, Mac Mini, and MacBook Pro included!) and why I’ve recently become interested in how the Internet search and referral world works. I’m not interested in being a search engine optimization (SEO) expert, but it’s amazing just watching the gears turn.

Well, a big gear turned again today as Google recalculated their calculated PageRank values for just about every domain and page on the Internet. This is only the third PageRank refresh of 2009, and it’s likely to shake up the standings of every Google search.

How It Works

Rehashing my previous post, which pointed out the perils Google faces in a world full of real-time links and nofollow tags, PageRank is one of the cornerstones on which the search giant relies. Simply put, every page gets a rank on a scale of 0 to 10 based on the number and quality of links pointing to it. Google also seems to rank whole domains this way, using the domain’s rank to weight the scores of pages contained there. Top-ranked sites like Wikipedia (PR 8 ) show up much higher in the Google search results pages than lower-ranked ones like fosketts.net (PR 5).

It certainly surprised me to learn that PageRank isn’t continually updated. In fact, it’s only recalculated every few months! The January refresh bumped my blog from PR 4 to PR 5, driving literally 1,000 more daily visitors my way! The calculation must take some serious horsepower, too, since Google doesn’t include the latest pages. Today’s refresh appears to stop at content from May 6, suggesting that it took the big brains in Mountain View three full weeks to complete their computations!

What It Means

You should care about your sites’ PageRank if you’re at all interested in attracting visitors. As I mentioned, a single-digit PageRank bump drove thousands of visitors to my blog in January, prompting my curiosity about this critical number. I’m not obsessive about it, but it is interesting to watch how PageRank affects site referrals. This is especially important for new sites, like my Enterprise Storage Strategies blog or Gestalt IT, since their readership expands rapidly as PageRank climbs upward.

If you own a web site of blog, you might be interested in checking your own PageRank. One simple tool is a JavaScript bookmarklet like the one from Google Blogoscoped. Just navigate to a page and hit the bookmarklet to see a popup with that page’s PageRank.

If you use WordPress, you can add a plugin like SlaptiGooglePR, which displays the overall site PageRank in the Admin Dashboard. It also includes the PageRank of individual pages to the Posts and Pages lists (which is how I knew which days were included in the calculation!)

At the end of the day, PageRank isn’t the most critical part of the Internet. But like a self-winding automatic watch, it’s really interesting to learn how Google does what it does, returning relevant links as if by magic.

Are you enjoying these posts on the Internet and social networking? Let me know with a comment, tweet, or email! If you’re an RSS reader, you can filter which posts you will see by subscribing to one of my specialized feeds, as seen in the left column at blog.fosketts.net.

Update: Google again recalculated PageRank on June 24, incorporating pages through the middle of June 16. They’re getting faster!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Google Just Recalculated PageRank!
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Nine Blog Suggestions from a Grumpy Reader

Stephen — Fri, 20 Feb 2009 16:33:51 +0000

Attention bloggers! I've got a whole disk of whoopass aimed at your head!

I subscribe to hundreds of RSS feeds, and read them religiously. According to Google Reader’s statistics, I read about 200 items per day out of over 700 posted to all of those feeds. As you might expect, I’ve got some strong feelings about blogs and news sites after reading that much.

So this message is aimed at all of you content providers out there: Fix your darn blogs and feeds so I won’t be so grumpy anymore!

If you enjoyed reading this, you’ll probably also like my Foskett Services blog!

Use full-text RSS feeds! If you’re still cutting off your posts after a few sentences, you’re losing my readership. I hardly ever click through on two-line feed items, and I feel burned when I even bother to subscribe to these. Half the time the heading and excerpt promise more than the article delivers anyway. Switch to a full-text feed so I can read your content right there in Google Reader without clicking through to see your interstitial ads for every post. I promise I will visit and comment if you have valuable things to say. What’s that? I hear you boo-hooing that you will lose readership, visitors, and AdSense revenue? You’re wrong. The best audience is an engaged audience, and readers of your feed are the most engaged folks you will find. They’re also a tiny TINY minority of readers (about 11% last I heard) compared to real search engine and referral-driven traffic. You’re only going to increase loyalty by switching to full-text feeds, whereas your refusal to syndicate more than 11 words is likely to drive people like me away.
No more me-too posts! Here’s a hint: If one of your peers already posted pretty much all you have to say on a topic, then don’t post at all. If you’re a worthwhile writer, there has to be a unique angle you can use for any story. Get your own voice! Bonus hint: Make sure you are reading your peers’ blogs so you know what they are saying, too! And a link back to them wouldn’t hurt either!
Don’t write about your stats! I don’t care about your monthly readership stats or AdSense revenues. Unless your blog happens to be about AdSense or search engine optimization, that is…
Kill the ads! Face it: You’re not getting rich with banner ads on your blog. Yes, I admit that I do run a few AdSense ads on my blog pages. Although the payout is tiny, it’s enough to keep the lights on. But I don’t force ads on everyone all the time – I use Ozh’ excellent Who Sees Ads plugin for WordPress so only search engine visitors see my banners. And I will never pollute my feeds with ads: Treat your (very few) subscribers like the loyal friends they are instead of trying to make a dime from their clicks. And yeah, a dime is about all you are making from your blog anyway, right?
Trim the fat! Are you illustrating your articles with 300k high-definition PNG images? Unless you’re a photographer or graphic designer, do us all a favor and limit your inline images to about 300 pixels wide. I know it’s non-free and all, but JPEG speeds up load times! And do you really need to embed flash animations, auto-playing YouTube clips, and other such junk? I’ll happily click through if I care. Keep the number of illustrations down, too. If the vertical space of your post is more than half graphics (especially cheesy Excel charts) you need to refocus it before you lose your readers.
Edit and format your writing! If I can’t read your post, I won’t read your post. Start by turning on spell check. Then learn the basic rules of grammar. You may be a computer genius, but I’m not going to put up with incorrect homonyms and eggcorns forever! Perhaps consider learning what a paragraph is, and even create some yourself. You can still use bulleted and numbered lists, but how about some context and headings to assist the reader?
Quit moving around! If you’re blogging, you should control your own destiny: Have your own domain name, your own install of WordPress, and your own feed URL. It’s hard for me to take “whoever.typepad.com” seriously, especially when, three months after I subscribe, he moves his feed to “whoever.blogger.com” and makes me re-subscribe. Often, I’ll just unsubscribe and forget him. Don’t want this to happen? Register your own domain name for your blog, set up a hosting account and install WordPress (it’s the best, hands down), and don’t bother me. While you’re at it, private-label your feedburner feed so you can take that with you when you move around, too.
Make commenting easier! Comment spam is a fact of life. Despite using Akismet, Bad Behavior, and clever tricks, I got more comments from spammers than actual readers on my blog. Then I heard that, although I added OpenID, commenting was still too hard. So I switched to Disqus for blog comments to try to make life easier, and have had a much better time of it since. If you’re still using native commenting, you’re missing out on a lot of readers who would like to comment but won’t jump through hoops to do it. Bonus hint: Use BackType to follow comments on other blogs, too!
Let me contact you! Everyone should have their real name and contact information prominently available on their blog. If you’re covering topics that intersect with work, you should disclose your employer, too. If you want to engage your readers, add in a link to your LinkedIn, Twitter, or Facebook account, too. But don’t go crazy – no one needs to connect to you in 800 places. That’s what FriendFeed is for!

Finally, here’s a bonus tip: No more top-ten lists! You’ll probably get to number nine and run out of things to say anyway!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Nine Blog Suggestions from a Grumpy Reader
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Apologies For The 404s!

Stephen — Sat, 07 Feb 2009 16:04:50 +0000

I’ve been using Dreamhost as my hosting provider since 2000, mostly happily. But last year I began receiving enough traffic that I could no longer rely on shared hosting. Last Fall, I switched all of my domains to a virtual private server at Dreamhost – an easy upgrade that doubled my hosting bill but promised all the performance I would need. Sadly, this was not the case.

Dreamhost never could get their flexible resource provisioning control panel to work right with my server, and their support staff was only slightly responsive. I limped along for three months, waiting for them to get everything working right and suffering through two unexplained multi-hour server outages. After losing my server for an hour and a half yesterday without any response or explanation whatsoever from Dreamhost support, I decided that enough was enough. After nine years as a customer, I am moving my sites elsewhere.

I looked around for a rock-solid Xen VPS/Linux provider with high performance and affordable prices. After checking into many that were recommended, I narrowed my search to two: Linode and Slicehost. Both differ from Dreamhost in that they offer unconfigured servers rather than point-and-click convenience and management. But after almost 20 years in UNIX administration, I figured I was up to the job.

After examining the two, I decided that Slicehost, which was recently acquired by Rackspace, offered the best solution for me. One deciding factor was Linode’s failure to offer backup services of any kind – that’s just bizarre! When all is done, I will be spending just $5 more per month than my Dreamhost VPS cost, and will hopefully get much better performance and stability.

If you’re interested in setting up a web site as outlined here, I recommend Slicehost. They’re not the cheapest, but their VPS servers are fast and reliable.

So I spent much of Friday evening setting up Ubuntu on my slice, copying data, configuring DNS, and installing lighttpd, php, MySQL, WordPress, Mediawiki, and the rest. After some teething issues, I believe that everything is now up and running properly on my new host! Please let me know (by clicking the “Email Me” link in the upper left corner) if you see any errors or issues!

You might also want to read these other posts...

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Apologies For The 404s!
This post was categorized as Everything. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.