Note: this article is long, but that’s only because I’m trying to explain in some degree of detail, and call out specific gotchas that you may run into. I promise you that setting these two up is incredibly easy, and shouldn’t take you more than a twenty minutes or so to have both up and running.

Advanced Policy Firewall (APF) is an iptables based firewall system that’s easy to set up and administer, and works hand in hand with Brute Force Detection (BFD).

BFD is a modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application specific options are stored including regular expressions for each unique auth format.

Together, they provide a simple but effective way to handle locking out brute force login attempts. Using APF, you could actually take it a step further and deny ALL SHH requests except those originating from a set of whitelisted IP addresses. This may not be feasible – or a good idea – if you do not have access to a static IP address, however, since you could end up locked out of your own box. We get into restricted whitelisting a little further down the page.

The basic gist is this: Someone tries to brute force their way into your server via SSH. Since they do not actually have a valid username+password combination, the login attempt will fail, assuming you don’t use shitty passwords that can be easily guessed, in which case they login successfully, and you’re pwned. After x failed attempts (where you define x in the configuration file), BFD will automagically tell APF to add the IP address of the offending attacker to the APF blacklist for a certain amount of time (also configurable in the config file). All services will be denied to that IP address, so they will no longer even be able to see your website.

The purpose of this is pretty obvious, but (for those of you who took the short bus in) one of the primary benefits is the ability to easily mitigate automated brute force attacks on your server, where a script is being used to try various combinations of usernames and passwords until they successfully login.

If you think your server is too insignificant for an attacker to bother with, you’re wrong. If you have an IP address that is visible to the rest of the world, you will end up being brute-forced at some point. Whether or not the attack is successful is up to you.

There are other firewall+brute-force-detection combinations out there, including the very popular Fail2ban, that also work very well. I’m not endorsing one over the other, I’m just more familiar with APF+BFD.

Anyway – let’s get to the good stuff. Note that you will need root/sudo access to your server in order to continue.

Setting Up Advanced Policy Firewall (APF)

Before moving forward, it should be noted that you are installing an iptables-based firewall. This means that if you screw something up, you could lock yourself out of the server, deny all traffic to your server resulting in a downed website, etc. Be careful, and don’t make these kinds of configurations on a production machine during peak site traffic hours. To test that your configuration is working properly, you’ll want to have access to SSH from another IP address that you can safely lock out without limiting your ability to administer the server.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz
3. [root@server]# tar -xvzf apf-current.tar.gz
4. [root@server]# cd apf-9.7-1 (or whatever the latest version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed.
   Installing APF 9.7-1: Completed.

Installation Details:
Install path: /etc/apf/
Config path: /etc/apf/conf.apf
Executable path: /usr/local/sbin/apf
DShield Client Parser: /etc/apf/extras/dshield/

Now configure the firewall: [root@server]# vi /etc/apf/conf.apf

Make sure DEVEL_MODE="1" is set until you’ve gotten everything working. This will allow you to get back into your server if you cock something up and get locked out, as it tells the script to clear the cron settings every 5 minutes. Once you’ve got APF tested and working as expected, set DEVEL_MODE="0" here.

The majority of the default options in the config can (and should) be left alone unless you know what you’re doing. As you go further into the config file, you’ll see stuff like this:

##
# [Remote Rule Imports]
##
# Project Honey Pot is the first and only distributed system for identifying
# spammers and the spambots they use to scrape addresses from your website.
# This aggregate list combines Harvesters, Spammers and SMTP Dictionary attacks
# from the PHP IP Data at: http://www.projecthoneypot.org/list_of_ips.php
DLIST_PHP="0"

DLIST_DSHIELD_URL="feeds.dshield.org/top10-2.txt"
DLIST_DSHIELD_URL_PROT="http"

All of the above are optional and allow you to implement additional resources such as DShield and Spamhaus to block known spammy or suspicious IPs from being able to access your server. You can leave them off if you’d like (they are off by default) or turn them on for additional protection. (You’ll need to install the DShield scripts, but I’ll get to that in a moment.)

Configuring Ports:

The APF config file will come with some default ports pre-set, but you’ll want to check and make sure everything you need is covered. You will also want to determine whether or not you’re using any uncommon port numbers (for example, for a hosting control panel) that should be added to the configuration file. Please don’t ask me what port numbers your specific hosting control panel uses. I don’t know, but I’m sure Google does.

# Common inbound (ingress) TCP ports
#IG_TCP_CPORTS="22,80,443"
IG_TCP_CPORTS="21,22,25,53,80,443,110,143"

# Common outbound (egress) UDP ports
EG_UDP_CPORTS="20,21,53"

If you restart the firewall and something is down but no errors are thrown, there’s a good chance you missed a port number here. Make sure to account for SSL ports (443) if you’re running an SSL certificate, etc.

Once you’ve made all of your tweaks, save the config file and start the firewall:
/usr/local/sbin/apf -s

If you’re satisfied that everything looks okay and all services are responding as they should, go back into the APF config and change DEVEL_MODE="1" to DEVEL_MODE="0" and flush the firewall: /usr/local/sbin/apf -f

Common APF Commands

Start: /usr/local/sbin/apf -s
Restart (flush and load): /usr/local/sbin/apf -r
Flush: /usr/local/sbin/apf -f
List Chain Rules: /usr/local/sbin/apf -l
Status: /usr/local/sbin/apf -st

Manually Whitelisting/Blacklisting IP Addresses

For the commands below, replace HOST with an IP or FQDN (Fully Qualified Domain Name) and COMMENT with your comments (no spaces) as to why you’re manually allowing or blocking an IP.

Add to allowed hosts (whitelist) and load new rule: /usr/local/sbin/apf -a HOST COMMENT
Add to denied hosts (blacklist) and load new rule: /usr/local/sbin/apf -d HOST COMMENT

To autostart apf on reboot, run this:
[root@server]# chkconfig --level 2345 apf on

To remove it from autostart, run this:
[root@server]# chkconfig --del apf

Using DShield

If you’re interested in using DShield with APF, you will need to install it first from the extras directory:

[root@server]# cd /etc/apf/extras/dshield
[root@server dshield]# ./install
Installation completed.
Binary: /usr/local/sbin/dshield
Config: /usr/local/dshield/dshieldpy.conf
Cronjob: /etc/cron.daily/ds

Warning: Running the binary from command line will send reports to dshield.org;
repeated execution may result in your IP being banned from the service.

Now you can edit the DShield configuration file, including turning on email alerts, database logging and other stuff. Again, leave this alone (or leave it uninstalled) if you’re not sure what you’re doing. Your APF will function just fine without it:
[root@server]# vi /usr/local/dshield/dshieldpy.conf

Setting Up Brute Force Detection (BFD)

First things first, you MUST have APF installed. BFD was written specifically to work with APF, so you have to start with APF and then install BFD.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
3. tar -xvzf bfd-current.tar.gz
4. [root@server]# cd bfd-1.4 (or whatever the current version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed
   .: BFD installed
Install path: /usr/local/bfd
Config path: /usr/local/bfd/conf.bfd
Executable path: /usr/local/sbin/bfd

Now let’s take a look at the configuration file:
[root@server]# vi /usr/local/bfd/conf.bfd

What you’ll see is a short file that starts like this:

# how many failure events must an address have before being blocked?
# you can override this on a per rule basis in /usr/local/bfd/rules/
TRIG="10"

# executable command to block attacking hosts
BAN_COMMAND="/etc/apf/apf -d $ATTACK_HOST {bfd.$MOD}"


These options are pretty straightforward. TRIG is the number of tries a user is allowed before they trip the BFD deny trigger. For PCI compliance or other strict environments, this number is usually pretty low – but it’s important to keep things practical. Security must always be a balance between making things safe and keeping them useable by the people who need to use them. If you had a lockout policy that after one try, a user is locked out for a day, odds are excellent that you’d be crippling your admins/devs. Who hasn’t fatfingered a password? These measures should be as unobtrusive to the users who legitimately need to be there as possible.

The very concept of a brute force password attack is one where the attacker doesn’t have either a valid username, a valid password or both. The odds of an attacker randomly guessing a username and password combination within 10 tries, or 20 tries, or even 100 tries is pretty low. Brute force attacks generally exploit things like default admin passwords, very common passwords (like ’123456′ or ‘password’ or ‘fuckyou’), or they are a more prolonged attack consisting of thousands and thousands of random login attempts. The attacker is literally trying to brute force their way in, since they have no other means by which to access your server that way.

Making the tolerance threshold very low doesn’t keep you safer from a brute force attack and will only serve to frustrate your users and create more work for yourself, since you’ll have to manually release the lock once they’ve boned their password a few times. So keep this number reasonable, and remember what it’s there for, or you’ll be making yourself and everyone who needs to access your server miserable.

Enable Email Alerts

You may or may not want to be alerted when someone has tripped the brute force detection script and has been added to the APF deny rules. If you’re on a frequently hit server, these emails could be overwhelming (or could even arguably help create a denial of service situation) but in general, I find it helpful to leave these on. I have filters set up in my email so they don’t flood my inbox. If you’re using a log analyzer/alert system like Splunk, you probably don’t need to turn on email alerts, but that’s up to you.

Find: ALERT_USR="0" CHANGE TO: ALERT_USR="1"
Find: EMAIL_USR="root" CHANGE TO: EMAIL_USR="your@yourdomain.com"

VERY IMPORTANT! Prevent locking yourself out!

You will want to make sure you’ve whitelisted your own trusted IP addresses pretty early on in this process. If your office has a static IP address or range of IP addresses, you’ll want to add these right away. By whitelisting these IPs, you prevent the possibility of locking yourself out of your own server by fatfingering your own password.

To add IPs to the ignored host list:

[root@server]# vi /usr/local/bfd/ignore.hosts

… and add your own trusted IPs, one per line.

Once you’ve got BFD configured to your liking, start it up!
[root@server]# /usr/local/sbin/bfd -s

Test the System

Once you think you’ve got everything working, try logging in from a non-whitelisted IP. If you have another server with it’s own IP address, for example, you could SSH into that server, and from that server SSH into your now-hardened server, using a username and password combination that you know is not valid.

While doing that, tail the APF logs, so make sure the attempts are being logged and the lockout works as expected:

[root@server]# tail -f /var/log/apf_log

Once you pass the number of attempts specified in the BFD config file, you should see the apf_log record that the offending IP address has been added to the denied hosts file.

Allowing Only Whitelisted IPs to Access SSH

If you’ve got static IP addresses and you want to lock your server down even more, you can skip BFD and simply deny ALL SSH requests coming from unknown IP addresses. This is easy to do, but also easy to forget additional IPs that legitimately require access (remote backup systems, managed hosting company support, etc) so be sure to think through everything that legitimate needs access, and be prepared to tweak the IP list if you discover things you broke.

1. Open the allowed hosts file: [root@server]# vi /etc/apf/allow_hosts.rules
2. Scroll down until after the last comment in the file with the ##
3. Add the following:
   tcp:in:d=22:s=YOURHOMEIPHERE
out:d=22:d=YOURHOMEIPHERE

   The d=22 is the port, since you’re specifically addressing SSH which usually runs on port 22. You can repeat for other services as well to limit other connections by port if you like.

4. Open the denied hosts file: [root@server]# vi /etc/apf/deny_hosts.rules
5. Scroll down until the last default comment ## then below it add the following:

   tcp:in:d=22:s=0/0
   out:d=22:d=0/0

6. Restart APF: [root@server]# /usr/local/sbin/apf -r

You wouldn’t use IP whitelisting restrictions in combination with BFD, since the process of whitelisting your internal IPs will override the BFD protection. In other words, with whitelisting restrictions, any user who isn’t on an authorized IP address won’t even be

Test the System

Testing this one should be pretty easy. Simply try to connect via SSH from any IP address that isn’t one that you whitelisted in step 3 above. What you should see is a connection attempt timeout or connection refusal. Try a new SSH connection from a whitelisted IP and you should get the SSH password prompt.

Two-Factor Authentication

If you really want to lock things down, you may want to consider adding two-factor authentication to your login. SSH keys would be something you have – plus a password as something you know – but for some reason it’s still not possible to require a password with SSH keys (to my knowledge – please correct me if I’m wrong). So instead of two-factor, you end up with a different one-factor (something you have instead of something you know).

Years ago, setting yourself up with true two-factor authentication was prohibitively expensive, so not a lot of smaller folks were doing it. These days, Citrix key fobs are being replaced by a new generation of more affordable and practical tokenless two-factor authentication systems, such as PhoneFactor and DuoSecurity.

Both of these options are pretty cool, and reasonably easy to implement. I’m in the process of setting up a few of our boxes with DuoSecurity (can’t beat the price), with the help of this fantastic tutorial by Jeremy L. Gaddis over at EvilRouters.

Also check out:

Traditionally, these attacks were targeted towards computers running Windows, which was painfully obvious when you visited one of these sites on a Mac, since you would see a Windows Explorer interface in the web browser, instead of Finder.

It was only a matter of time before attackers would expand this technique to include Mac users, especially as Apple continues to gain market share in the personal computer market. We’ve already started seeing more Mac virus proof of concepts, and many Mac users are under the mistaken impression that Macs are more secure than their windows counterpart. Up until fairly recently, it could be argued that Mac users were less at-risk, but Macs have never been more secure. Mac users were less at-risk simply because there were fewer of them. Bad guys tend to be opportunists, and they knew they’d get more bang for their buck by targeting Windows users.

This has arguably resulted in many less-savvy Mac users being given a false sense of security, when the reality is just that there weren’t enough Mac users for most malware authors to bother with. (Notice I said “most”.) As Macs have become more popular, they’re becoming a more financially viable target.

What we’re seeing now are much more sophisticated attacks, where malicious websites deliver content depending on what OS the target is using while on their page.

I recently stumbled across an infected website that displayed a fake anti-virus “scanner” that informed me that my computer was infected and prompted me to download a zip file called anti-malware.zip. You can see the screencast below:

This is a screenshot of the rogue antivirus page:

As you can see, the layout of the infected page is tailored to a Mac, showing what is meant to look like a Finder interface. A fake alert window pops up with the text:

Apple security alert: To help protect your computer, Apple Web Security have detected Trojans and ready to remove them. Spyware is a type of malware that can be installed on computers, and which collects small pieces of information about users without their knowledge.

When a Windows user visits this same infected page, they see a completely different page, tailored to Windows users, displaying a fake Windows Explorer interface:

(Windows screenshot courtesy of Satnam Narang.)

Important to note: According to VirusTotal, the detection of the windows executable version of trojan (named BestAntivirus2011.exe) is very low, which means very few legitimate antivirus programs will currently detect it as malware – only 2 out of 42. At least some email scanners are detecting the Mac version though, as Rackspace rejected my attempt to email it to VirusTotal for scanning and returned it undelivered, stating that a virus had been detected. VirusTotal indicates that 7 out of 42 antivirus programs will detect the Mac version, named MacProtector.mpkg.

If you’re wondering how I came across this page in the first place, I wasn’t researching Mac antivirus – I was googling on the terms “Anime Bleach hollow logo”, looking for a t-shirt with a Hollow skull logo on it from the anime series Bleach. The fourth result on Google displayed a page on a .nl domain, belonging to the Village Council of Molenhoek, Netherlands. (I don’t speak Dutch, so I didn’t realize that right away of course.)

When I clicked on the link, a javascript redirect brought me to a new page hosted on an IP address belonging to Atjeu LLC Website Hosting. With javascript turned off, the source of the page on the Molenhoek website contained the following redirect code:

As you can see, the javascript redirects me to the domain tmfpuion.ce.ms, which has a Romanian IP address. If I access the redirect cgi url directly, I am returned a 404 error coming from UK-owned wolandtraffic.com/default.cgi. The script is checking the referrer header and only forwards the user onto the malware download page if they are coming from Google.

Based on the fact that the Molenhoek website does appear to be a legitimate website, my guess is that the attackers exploited a vulnerability on their website in order to inject the malicious redirect.

The source code of the actual fake antivirus page was a combination of base64 encoded images, javascript and CSS:

Although the increase in Mac-targeted malware isn’t new and some of you may have already encountered this attack in the wild, there have been a few versions of this one going around, called MacDefender, MacSecurity and MacProtector.

Update: Sophos has also posted an update about this issue, specifically with respect to how attackers are using blackhat SEO to poison search engine results on Mother’s Day themed searches.)

Seems most of the bad sub-domains are coming from ce.ms, and some users are reporting particularly high occurrences in Google image search results, according to Brian Krebs.

The social engineering aspect of this kind of attack is the critical piece to understand, as the bad guys are banking on your fear of viruses and malware to trick you into downloading viruses and malware. So as always, never download anything from an untrusted source, regardless of how convincing the page seems to be. If you’re interested in legitimate virus software, stick with well-known names such as Sophos or Kaspersky, but also bear in mind that antivirus is no substitute for common sense, and just because you’re running antivirus software (or you’re on a Mac) doesn’t mean you’re safe.

Also check out:

So the user gets a notification “John Smith has made you an administrator of XYZ page”. The user clicks on the page to see what they’ve just been made an admin of, and the poisoned default page tab kicks on, busting them out of the Facebook site and into a standalone page offering promises of free iPads and various other too-good-to-be-true freebies.

In this particular case, the scammers were using the extremely popular – and from what I can tell, legitimate – application Static HTML IFRAME, which simply allows people to create their own IFRAME tabs to add to their Facebook page without the hassle of creating their own application, hosting content, etc.

The IFRAME page that loads in the Facebook page points to s3.amazonaws.com/statichtmlplus/page/160281910702810.html – so it seems that the Static HTML IFRAME app just saves the content that their users add to their custom IFRAMEs into a static HTML file and serve it accordingly.

In the case of this scam, the IFRAME page hosted by the Static HTML IFRAME app contains another, hidden IFRAME inside of it that forces the browser to redirect to the scam website.

This is a combination of social engineering (taking advantage of the fact that the new administrator will obviously want to know what it is they’ve been made an admin of, thus getting them to look at a page they would otherwise never have found or cared about), and very basic technical jiggery pokery to bust out of the frames and take the unsuspecting admin to a third-party site.

The third party site in this case was a survey/iPad 2 giveaway scam (ipad2-test-and-keep.com), but this method could just as easily be used to serve malware or phishing pages.

Imagine how easily this would flow if if the frame-buster page instead took the user to a page that looks just like the Facebook login page. They think they’ve somehow been logged out, they fill in the login form to log back in, and now the bad guys have their Facebook credentials – which statistically are likely to be the same credentials they use for banking and other things.

The IP address of the scam site the IFRAME sends the user to, 92.241.169.80, tracks back to a Russian web hosting company, 2×4.ru.

We’ve already reported this scam page to Facebook using the normal routes and through the Preferred Developer Consultant avenues, but I’d be willing to bet we’re going to start to see a lot more of this kind of thing because it’s incredibly effective and very simple to execute.

Thanks to @uberbrady for seeing this for what it was when it happened to him, and bringing it to our attention.

Don’t forget to “like” our special Social Media Scam Alert page on Facebook and follow @scamdb on Twitter for more updates like this.

Also check out:

We’re finally at a point where someone who spends a reasonable amount of time at a server command line can actually get real work done, and I gotta say, it’s pretty cool. Just last night I was discussing an obscure Apache config issue with a friend at a bar, and rather than working from memory, I busted out the iPad and my Bluetooth keyboard, and 5 minutes later, the configuration issue was solved.

Having the freedom to go to the park to read for a bit but knowing I have the ability to handle an emergency should it come up is very freeing. Yes, I have become that douchebag at Starbucks – and you know what? I fucking love it.

Anyway. Point is, the iPad (or iPhone) can be used for more than just porn now (which is good, because the folks at Starbucks get surprisingly upset when you try adding your own “cream” to your latte), and I’ve spent some time and money to try out some of the most promising apps in the app store that allow you to do actual work, and edge the iPad closer to being a viable option for a netbook replacement.

I didn’t address any design/mockup/mindmapping apps in this list, but that may be a topic for another post sometime. This list isn’t meant to be all-inclusive, and doesn’t reflect the totality of what is available in the app store – it’s a short list of personal recommendations of products I actually use and like.

Disclosure: Some of the links below are hooked into the iTunes affiliate program so that I might get a penny or two if you decide to buy, however the recommendations are legit, and I wouldn’t recommend something unless I had used it. Click through on the affiliate links or don’t – but do leave me a comment if you’ve fallen in love with something I haven’t mentioned here.

Code Editors/FTP

There are quite a few nice code editors for iPad in the app store, but I won’t consider any that only offer FTP instead of SFTP and neither should you. I am just as likely to use vi in an SSH app on my iPad as I am to use a code editor, but for handling multiple open files at one time, sometimes an editor is kinda nice. Unfortunately, 90% of the code editors in the app store are complete and utterly shit-tastic garbage. Seriously. Even if you don’t pick one of my recommendations, make sure you read the comments on the code editor apps before you buy so you don’t get burned.

Textastic

I think Textastic might be my new favorite code editor for iPad. The interface is very clean, it supports FTP and SFTP, integrates with Dropbox and WebDav (if you’re into that sort of thing) and comes with syntax highlighting for around 80 different languages. It’s a little pricier than some of the other options, but I think it’s well worth the investment. I want to make sweet ASCII love to it all the time.
In iTunes: Buy Now ($9.99)
Developer: Alexander Blach

Gusto

Gusto is pretty sexy and has come pretty far in a short time. (When it first appeared in the app store, there was no SFTP support.) It supports projects, one-touch uploading, background processing so your state doesn’t get lost when you have to switch apps, pretty Coda-like site thumbnails, tabbed editing, and remove and local preview support. Three obvious features that are missing are syntax highlighting, line-wrapping and public-key authentication, but it’s a great start and a solid option for busting out quick changes on the road.
In iTunes: Buy Now ($6.99)
Developer: Horse and the Rook

An alternative to Gusto that’s an app to watch would be Markup for iPad, but I’ve heard such crap things (crashy, no SFTP) about it that I haven’t tried it. Sounds like it’s worth keeping an eye on, but not ready for prime time yet and not worth the $10 pricetag until it’s a bit more stable and can handle SFTP.

FTP on the Go (Pro)

Feature-packed FTPS app. Honestly, too many spiffy features to list – the best FTP app I’ve come across so far. Comes with a built in FTP Server and Web Server allow viewing and adding files to the iPhone or iPod touch. Browse files on your iPhone from your computer with a web browser. Madness. Madness, I say!
In iTunes: Buy Now ($9.99)
Developer: Headlight Software

MySQL

MySQL Database Client

Small, simple MySQL client for iPad and iPhone. Supports stored profiles and custom queries, but don’t go too nuts. It can handle basic queries, but more complicated stuff like JOINS will return unpredictable results. Still, it’s $0.99, and is worth at least that much, contrary to the cheesedick who “wants a refund” in the reviews. Seriously. It’s a buck. Get over it, kid.
In iTunes: Buy it Now ($0.99)
Developer: Kyle Hankinson

MySQL Editor Pro

A much more full-featured app with a price tag that reflects it, MySQL Editor Pro is the real deal. If the cost doesn’t scare you off, this is well worth the month for such a strong db admin app.
In iTunes: Buy it Now ($14.99)
Developer: Pasha Topchiyev

SSH/VNC

Prompt

That Apache configuration issue I was having? Solved in 5 minutes using Prompt. It’s made by the same folks that make the super-sexy Coda code editing app for Mac. The UI is pretty nice, and it supports special characters and keystrokes like CTRL which one ends up using frequently in a shell. Prompt supports DSA/RSA keys, automagically remembers your frequently used commands, runs in the background so screen-switching won’t disconnect you, and you can map commonly used keystrokes easily for speedy access. An added bonus – it’s a universal app, so you buy it once and it works on your iPhone and your iPad. (Given my horrible typing on the iPhone and the iPhones even more horrible auto-correction, I don’t know that I’d want to use it on my phone much, but it’s nice to know it’s an option.
In iTunes: Buy it Now ($4.99)
Developer: Panic, Inc.

iSSH

Less sexy than Prompt but still one helluvan app is iSSH. iSSH boasts a pretty impressive feature set, including a tunneled VNC client, tunneled X server, the fact that SSH, telnet and VNC all work via EDGE, WiFi and 3G, transparent keyboard, Bluetooth keyboard mapping, RSA and DSA key generation and exchange, tons of keyboard customizations and holy shit a lot more. It’s a solid client, and a universal app, so you can buy it once and use it on your iPhone, iPad, iPod touch, etc. Even works with older iPhones running iOS 3.0.
In iTunes: Buy it Now ($9.99)
Developer: Zingersoft

Network Tools & Miscellaneous Hackery

IT Tools

Puts a whole handful of diagnostics just a tap or two away, with DNS, Ping, Route, ARP, active sockets and Interface tools. 45 supported DNS record types, including A, AAAA, CNAME, LOC, MX, NS, SRV, TXT – and it come with a database of MAC addresses so you can look up manufacturers of devices on your network. All of these things can be done through SSH if you’ve already got a terminal running, but this app makes it so much easier.
In iTunes: Buy it Now ($4.99)
Developer: Kevin Koltzau

Server Admin Remote (Mac OSX Server)

Called a Swiss army-knife for the mobile Mac OS X admin, with Server Admin Remote IT administrators can monitor the alive status of Mac OS X Server services, start/stop services and observe the services’ logs (Mac OS X Snow Leopard, Mac OS X Leopard Server and Mac OS X Tiger Server). Works on EDGE, WiFi and 3G connections. No further installation on your Mac OS X Server needed, since Server Admin Remote uses the same interface as Mac OS X Server Admin.
In iTunes: Buy it Now ($11.99)
Developer: Harlekins

Rackspace Cloud

If you’ve got a Rackspace Cloud Servers account, this app is the shit. Reboot, rename, resize, and rebuild your Cloud Servers, spin up a new server or delete an existing one, change your root password, bootstrap Cloud Servers with Chef from your Chef server or the Opscode Platform, open and manage Cloud Files assets and control your CDN settings for Cloud Files containers, play Cloud Files audio and video over Airplay to your Apple TV (iOS 4.3 and up) – a ton more. It’s not a complete replacement for their control panel, but you can do a heck of a lot with it.
In iTunes: Download Now (FREE)
Developer: Rackspace

Vtrace

Simple visual traceroute (or TracerT, if you’re this kid) that uses your current location to take you down the bunny trail to whatever IP or hostname you’re looking up.
In iTunes: Download Now (FREE)
Developer: Vlad Alexa

iAccess for Nagios

Mobile Nagios client that gives you direct access to the /nagios dashboard. (Obviously, you need a Nagios server configured for this to work.)
In iTunes: Buy Now ($3.99)
Developer: ASION IT Services

Flame for Bonjour

Flame is a browser for Bonjour network services. It lists the services advertised on your wireless network and you can browse them by server or by service type. When selecting a service, its advertised details are displayed. If an application on your iPhone or iPod touch can handle any of the advertised services, a command to open it right away is provided.
In iTunes: Download Now (FREE)
Developer: Tom Insam

Ping A Majig

Handy app that lets you check the ping status of multiple hostnames at one time. It’s a bit handier as a monitoring tool than the other apps that include ping as an available tool, since the at-a-glance view lets you see if any of your hosts are in trouble on one screen.
In iTunes: Buy Now ($0.99)
Developer: Pingysoft

RBL Status

Simple but effective Real Time Blacklist looker-upper.
In iTunes: Buy Now ($1.99)
Developer: Pavel Ahafonau

iPortscan Pro

iPortScan PRO is a port scanner for your IPhone or IPodTouch. It does not feature any network discovery; however, this tool is useful for sysadmins checking what services are listening on a known system. This is very handy for the system admin who can use this tool to quickly portscan all of their systems to make sure nothing is open that shouldn’t be.
In iTunes: Buy Now ($1.99)
Developer: Whiteside Solutions LLC

Default Logins

This app contains a database of over 300 common and uncommon manufactures and the usernames and passwords they pre-configure their devices with (which there are 1,000 + in the database). Can come in handy for more nefarious reasons (if you’re that kinda person), but also super useful for fixing a relative’s biffed router when they ask you to come over and fix their internets.
In iTunes: Buy Now ($1.99)
Developer: anthony lamantia

So that’s my list – for now. Did I miss any that you love? Leave me a note in the comments.

PS – yes, that’s a photo of my actual license plate at the top of the post. And yes, that makes me more awesome than you.

Also check out:

On Facebook, “like” the Social Media Scam Alerts page to get updates as new Facebook scams and rogue applications are identified. The posts will be short, without a lot of technical jargon to make them easy to share with your less brainy friends and family.

On Twitter, follow @scamdb for tweets about the latest scams, phishing and rogue apps affecting Twitter users.

Social Media Security Tips

In addition to staying informed about bad applications, some better practices and common sense will go a long way here.

We have become completely desensitized to clicking on things in websites, our social networks, on our smartphones and in email – and this is why these types of attacks are so wildly successful, often garnering tends of thousands of “likes” before they are detected and banned by Facebook or Twitter. More often than not on social media websites, the attack is not a technical attack, it’s a social engineering attack, tricking you into clicking on something because what they are offering is something you want and you found the link through a reasonably trusted source (your friends twitter stream or Facebook news feed.)

Be skeptical. If something looks too good to be true, it probably is, even if you trust the person it came from.

Confirm before you click. If you’re not sure, take a moment to email or (gasp!) call your friend and confirm they actually intentionally posted that message. If they didn’t, you’ll be doing them (and all of *their* friends) a favor by bringing it to their attention quickly.

If your friend posted to their Facebook wall that they are stuck in London and need money for passport/plan home/etc – resist the urge to immediately send cash. Be rational, contact them using a different method (email, phone) and confirm that it’s really them. Use common sense. Did your friend even mention they were going to London?

That “stuck in London” scam has made its rounds for several years through email and social networks. I don’t know why it seems to always be London, but that’s almost always the city I’ve seen in these scams.

Use the SSL version of social networking websites when you’re surfing on public or unsecured wifi. As Ashton Kutcher learned this week at TED, non-encrypted sessions + a little Firefox addon called Firesheep = getting pwned in front of your six-and-a-half-million Twitter followers.

Facebook offers a clunky (and currently unreliable) way to switch to HTTPS for your Facebook sessions, but that method resets back to HTTP if you access a non-SSL application. My understanding is that Facebook security is aware of the bug that resets the default preference back to non-SSL, but I don’t think it’s been fixed yet.

An alternative is using something like the Electronic Frontier Foundation’s HTTPS Everywhere addon. The first release of this addon was a little buggy, but the second release seems more stable. (The first version rendered Amazon.Com effectively useless.) You can select which sites you want to use HTTPS Everywhere on, and it will always force the HTTPS (versus the plain HTTP) connection.

Ideally, you should try to avoid public or unsecured wifi connections whenever possible. Make sure your computer and smartphone preferences are to NOT automatically join wifi networks. If you have to be on public wifi, your best bet will be to tunnel your traffic over VPN, but not everyone is going to have that as an option.

In the big, scary internet, there are countless ways your personal information and login credential are at risk. Some of these are technical vulnerabilities in the websites you trust your information to, but the social engineering approach is gaining tremendous momentum. It’s cheap, it’s fast, and it works. Remember that even if you think you have nothing of value, when you are careless with your security, you are also putting your friends and family at risk.

Take a moment to check out the security presentation I posted a few weeks back that covers important information on privacy and password security, and consider joining the new Facebook and Twitter resources.

Also check out:

According to the blog entry, this feature would be opt-in, and canvas application developers would need to provide an SSL url for the “Secure Canvas URL”.

If a user who has opted into the SSL-only version of Facebook attempts to access a Facebook Application that doesn’t have a Secure Canvas URL set, the user will evidently be shown a message (which will likely be confusing and scary, not because Facebook will purposefully make it so, but because most users don’t really understand SSL) that will give them the option to switch from HTTPS to HTTP. From the post:

If you do not provide a secure Canvas URL, we will display a confirmation page to let HTTPS users switch to HTTP and continue to your app.

This currently affects CANVAS apps only – not application tabs – although that may very well change once Facebook pushes the IFRAME version of tabs out some time in Q1.

HTTPS is slower and more server intense than HTTP, and it’s one more cost/timeline issue that has to be factored in. For some clients, I set up the hosting environment (which would include DNS, SSL, etc) – for others, their IT department provisions web space and handles DNS, and they often require a mountain of paperwork and a week to process.

For the latter scenario, the cost of the certificate is negligible, but for a highly-trafficked app, the increase in server load could have serious financial impact. It could mean the difference between needing one server and several.

For smaller companies, stepping up to SSL would mean buying a certificate and potentially paying extra for the dedicated IP address it will need, and if the app takes off, a much heftier hosting bill for running everything over SSL.

If the above would actually, truly improve the safety of the users in some significant way, I’d probably still be on-board.

Security is something I take very seriously, and in 2010, Firesheep showed the world how easy it was to hijack a user’s Facebook session and essentially pwn their account because the session data was being transmitted unencrypted and was sniffable over public wifi. To be fair, it wasn’t just Facebook that was affected, but if you’re logging into websites on an unencrypted public wifi, odds are your email accounts and everything else are at risk too.

That said, this seems like it will give naive users a false sense of security and not actually provide that much value for the effort involved by the app developers.

“Oh, this application must be safe – I’m using HTTPS, and the S stands for *secure*!”

Phishing, rogue apps and malware are already horrendous problems on social media websites, Facebook especially. I would much rather see Facebook (and others) improve their session handling before going in this direction. Reputable companies who are collecting any kind of PII are already running data submission over HTTPS, and non-reputable companies aren’t going to become more honest just by forcing them to encrypt the data they’re mining from your profile.

The net result is a lot of extra work for developers and companies for not a lot of benefit to not a lot of users, with the side effect of confusing people into thinking that SSL = trustworthy, or that a non-SSL app is malicious and trying to eat their souls.

IMHO, the much bigger threat to Facebook users is their own poor judgment on what to click on. Social engineering rules social networks, and no amount of encryption is going to fix that. As the fabulous shirt from Jinx says “there is no patch for human stupidity”.

Until people start being more critical of what they’re clicking on and what apps they’re allowing access to their profile, they’ve got a lot more to worry about than SSL. It’s the same false sense of security that users running antivirus programs often suffer from.

“I don’t need to worry about what I click on – I’m running antivirus! My virus definitions are up to date, so I am safe and protected and nothing can harm me.”

In 2008, Symantec had to write new virus signatures every 20 seconds to keep up with the onslaught of malware that was released. This was increased to every 8 seconds by 2009. [Source: Gray Hat Hacking The Ethical Hackers Handbook, 3rd Edition]

To prove my point, I’ve created FB Profile Spy. It’s still a work in progress, but it’s a better-security-through-humiliation project, similar to my better-behavior-through-humiliation project socialmediadouchebag.net. It’s completely safe – and not even hooked up to the Facebook API at all (but of course please feel free to use NoScript and check it out thoroughly before interacting with the links. I have nothing to hide.) Click through and “allow” the “app”. I need to tighten up the javascript slideshow lecture at the end and I need to sync up the layout with the new profile design, but it’s coming along.

What do you think? Am I just being a whine-ass lazy developer? Am I being a slacker security pundit? Let me know in the comments.

NOTE: This article first appeared on FBMHell.Com.

Also check out:

I will warn you that a few slides are not appropriate for all corporate environments – or any corporate environments, really. But you’re welcome to use the bits that may be helpful to you.

My company is small, so I omitted the scenarios that are really more appropriate for large companies with IT departments they do not know personally. My office is open (everyone can see each other), so someone calling and claiming to be from IT would stand out as someone who is full of shit pretty quickly.

This isn’t meant to be all-encompassing, and the audience is not meant to be a technical one. It seemed to go over well though, and enough people laughed that I think it kept their attention. More importantly perhaps, more than half of them left looking a little alarmed, which was really the whole point. Also note that the slides don’t reflect the entire content of the presentations, since I would be a shitty speaker if I were just reading from slides.

PDF Download | Keynote Download | Zipped Images Download

If the topic of social engineering is of interest to you and you’d like to learn more, I strongly recommend picking up the following books – they are outstanding and worth every penny (and then some):

• The Art of Deception: Controlling the Human Element of Security [paperback] [kindle]
  by Kevin Mitnick
• Social Engineering: The Art of Human Hacking [paperback] [kindle]
  by Christopher Hadnagy

Both of these books are really exceptional, and even if you’re not in the information security field, they’re damned interesting to read. Some of the case studies in this presentation were taken directly from these books, as both have extensive detailed examples that may be more suitable for the type of company you work for.

Be sure to check out Chris’ social engineering podcast as well, and check out the episode where I was a guest.

Also check out:

I’m at the very early stages of writing a book about how to secure, monitor and un-hack WordPress. This book will be the culmination of everything I know about keeping WordPress hardened against attacks, how to keep an eye on your install so that you’re the first to know if something has happened, and how to handle the situation if you bought the book too late and got pwned anyway.

Can I absolutely guarantee that you’ll never get hacked if you do everything in this book? Of course not – new exploits emerge all the time. However I can promise you that you’ll be a lot less likely to get hacked if you follow these instructions, and if you do get hacked, you’ll be a far better place to recovery quickly and completely – and if that’s not worth $5 to you, you deserve what you get.

I can also promise that if there is enough interest in this book, I will keep it updated and release new revisions for free for those people who have already purchased it. I don’t believe in having to re-purchase a book just because a paragraph or two was added. It pisses me off when I have to do it, and I’m sure it pisses you off, too.

How much?
Right now, I’m toying with a $5-$10 price range, depending on how long and detailed it ends up being. It will not be more than $10, regardless of how long it is.

Are you doing advanced sales?
YES! If you’d like to pre-order, check out the page on GoFundMe. There are a few different options for pre-ordering, so it’s worth a look.

Why an e-book instead of a “real” book?
I might make this available in hardcopy through Lulu or some such service – but there are several reasons I went with e-book. First, I’ve written “real” books before. The process is frustrating, and there’s not a lot of money in it, in tech books anyway. By self-publishing, more of the money ends up in my pocket where it belongs. Second, as a recent convert to e-books (thanks to my iPad), I prefer to give folks the option of printing if they need to, but spare the trees for those that don’t. And third, stuff changes all the time in technology. Paper books have never seemed like a great way to cover tech topics, since half the book will be obsolete within a year or two, my own previous books included. Self-publishing via e-book means I can update the information as needed, and not feel like a jackass for making people buy a new edition of the book.

What qualifies you to write this book anyway?
I’ve been working with WordPress since 2005, and have spent a considerable amount of time over the past several years doing forensic and recovery work on hacked WordPress blogs. For some idea of the type of content you can expect to find here, check out this blog post from Jan 2010. I’ve helped folks like Chris Brogran, Scott Stratten, the Crave Network and others quickly recovery from a hack, and lock down their installs so they are less vulnerable to future attacks. Ask them – they’ll tell you.

How much swearing will there be?
Probably less than you expect. My goal is that this can be something some of you can recommend to your clients (the ones that won’t pay you to secure their sites), and as tempting as it is, that might not fly for the general public. I will, however, try to keep it entertaining in my own way.

What’s the title going to be?
NFC. Suggestions welcome.

How can I stay updated on the book’s progress?
I’ll be updating the official book website as new developments arise. Check it out here.

I have another question!
Tag me on Twitter at @snipeyhead or leave a comment below and ask away.

Also check out:

I’ll start with the obvious candidates that you probably already have installed if you’re a developer. I’ve also added a few that are useful for post-hack diagnostics and recovery.

General

Firebug – Firebug is great for web development in general, but the debugging tools can help track down calls to rogue javascript on external servers, among many other things.

Web Developer Toolbar – Another great web dev tool, the Web Developer Toolbar makes it easy to turn javascript and cookies on and off selectively, view form fields and disable restrictions and much, much more.

DNS Cache – simple addon that lets you clear or disable Firefox’s DNS cache. Not specifically for pen testing, but useful nonetheless.

Notable - love this addon, which lets you do a full-page screenshot with annotations over at notableapp.com. As you’re testing, there’s a good chance you’re going to need to show your other devs or account managers a screenshot so they can see the vulnerability being exploited. While something simple like Fireshot would work fine (or native screenshots), I like using Notable for complex situations that require explanations on multiple points on the page. Exports to annotated PDF.

Groundspeed – simple form toolkit that allows you to edit form fields (hidden to text, etc), remove length restrictions, change/remove javascript event handlers, and change form target so that it opens in a new tab.

Code Injection

SQL Inject Me – helps test for SQL injection vulnerabilities.

XSS Me – used to test for reflected Cross-Site Scripting (XSS). It does NOT currently test for stored XSS.

Access Me – used to test some access vulnerabilities related to web applications. The tool works by sending several versions of the last page request. A request with the session removed will be sent. A request using the HTTP HEAD verb and a request using a made up SECCOM verb will be sent. A combination of session and HEAD/SECCOM will also be sent.

JS Deobfuscator – many attacks inject obfuscated javascript into a page so that it becomes harder for you to simply grep the source for something obvious, like the domain name to which the bad script is redirecting the user. This addon helps deobfuscate the javascript so you can see what’s really going on.

Hackbar – helps with testing sql injections, XSS holes and site security. Ugly as sin, but it works well.

Header and URL Monitoring/Tampering

Note that some of these addons do similar things – try them and stick with whichever one you like best.

HttpFox – monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers.

Live HTTP Headers – view HTTP headers of a page and while browsing.

Modify Headers – add, modify and filter http request headers. You can modify the user-agent string, add headers to spoof a mobile request (e.g. x-up-calling-line-id) and much more.

Tamper Data – use tamperdata to view and modify HTTP/HTTPS headers and post parameters, trace and time http response/requests and security test web applications by modifying POST parameters.

User Agent Switcher – allows you to easily toggle between pre-set user agent strings, or set your own.

Environment Detection

Header Spy – lightweight addon that displays information about the website’s server in your statusbar. This is not as useful for pen testing as it is for impressing the crap out of clients who don’t know what server they’re running.

Host Spy – integrated shortcut to show you who a website’s IP neighbors are on shared hosting.

ShowIP – Small addons that shows the IP address of the website in your statusbar and a link to some additional tools.

URL Flipper – quickly and easily increment and decrement numbers and strings in URLs for navigating through URL sequences (for example, user ids or session info in the query string.)

Wappalyzer – uncovers the technologies used on websites. It detects CMS and e-commerce systems, message boards, JavaScript frameworks, hosting panels, analytics tools and several more.

Searching

Offensive Security Exploit Database – this adds the excellent database of exploits at exploit-db.com as one of your search engine options.

I’ve also just created a search plugin for XSSed.Com, but it’s pending approval at Mozilla, so not sure when that will be ready for you which can be downloaded here. It’s not exactly rocket science to add a new search site to your browser search bar, but I figured it was quick and easy to whip up. Feel free to check out the source code for the plugin here.

Too Many Addons Got You Down?

If you’re finding your plugins are slowing down Firefox too much, you might want to create a separate Firefox profile specifically for testing, and switch to that profile when you’re ready to start hammering away. Also bear in mind that you might need to tweak some settings on these, or only enable them right before you use them, as the toolbars and sidebars can be a bit bulky.

Also keep in mind that the Net option on the web developers toolbar, or any of the header analyzer addons can be very helpful in general testing between dev and live environments (load the page on live and make sure nothing is being pulled from the dev address) and also to make sure your SSL requests are being handled correctly.

Some Additional Thoughts…

When folks ask me how I do penetration testing – whether I use software, or do it by hand – the best way I can answer is “both”. Software will only ever get you so far, but it’s a critical tool in helping you figure out where the vulnerabilities are. It’s not unlike using a metal detector to find treasure. When the metal detector is doing its job, it finds, well, metal. Not necessarily treasure, although fancier metal detectors have additional software that helps try to identify the buried object by shape and size. You still have to physically dig up the item and rely on your knowledge and experience to determine whether or not it really is treasure, or just junk. The metal detector simply finds something that meets a basic set of requirements, to save you from having to dig up every square inch of the beach.

When testing web applications for vulnerabilities, software does very much the same thing. It simply automates tasks that you could do by hand but that would take an unreasonable amount of time, but ultimately when it finds something, you still need to know enough about what you’re looking at to determine how big a threat it actually is. Most of the time the software will attempt the to try the lowest-level exploit, for example, the ability to execute arbitrary javascript in a page. Your testing tools may demonstrate that you can create a javascript alertbox on the page, but it’s your knowledge and experience that will help you determine the full extent of the vulnerability, for example whether that arbitrary javascript could be used to redirect a user to a new page, hijack the user’s session data, etc.

The reason I ended this post with a long-winded ramble is because I wanted to make it clear that just having the tools isn’t enough. Actually using them, and knowing what to do with the results are important. Understanding the basic mechanics of how exploits work is the only way you can make sure your applications are written to mitigate them. Having the tools installed but never understanding or using them is like buying a metal detector and keeping in the closet and then wondering why you haven’t found anything valuable yet.

If you’re interested in learning more about web application penetration testing and security, check out the following books:

• The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws
• Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast
• Foundations of Security: What Every Programmer Needs to Know
• Ninja Hacking: Unconventional Penetration Testing Tactics and Techniques

How Do You XSS?

These addons are not obviously meant to be a replacement for more capable and thorough penetration testing tools such as metaploit, netsparker, etc. They’re just meant to be a convenient way for developers to test code during and after development.

There is a more comprehensive collection of addons listed here, but this is what I use. If you’ve got a favorite that I’ve missed, please be sure to share in the comments!

Also check out:

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.

Also check out: