Getting to play with new technology is fun isn’t it?!  I have been messing around with something that is new to me lately called Umbraco.  First released in 2005, Umbraco is an open-source CMS platform for building websites and has an install base of a little over 85,000 installations.

I thought it would be fun/interesting/(useful?) for the Umbraco and F5 Networks community to create a series of posts based on my experiences in using the F5 BIG-IP to deliver this application in a fast, secure and highly available manner.

The first post that I want to throw out there for folks in both communities is related to security and iRules.  There are always “Best Practice” things that you want to do with every web application and Umbraco is no different.  I have two issues that I want to cover.

One of the first things that you will want to do is turn off access to the built-in debug feature included with Umbraco.  According to the official Umbraco documentation found here: http://our.umbraco.org/wiki/how-tos/hide-debugging-features-for-production-systems this feature cannot be turned off inside of Umbraco.  The documentation then goes on to contradict itself  and mentions that you CAN turn off debugging.  It is a bit confusing I know, but I guess we have to work with the information that we have right?

In that same document it also mentions that debugging can be blocked from within Umbraco using the built in URL rewriting feature, but if you are going to be doing some URL manipulation… well, I think you know where I am going with this!

The basic iRule below will keep hackers from being able to see what is going on behind the scenes on you production Umbraco servers which accomplishes our Best Practice goals.

when HTTP_REQUEST {
if { ([string tolower [HTTP::uri]] contains "umbdebug")} {
HTTP::redirect "https://mycompany.com/default.aspx"
}
elseif { ([string tolower [HTTP::uri]] contains "umbraco")} {
HTTP::redirect "https://mycompany.com/default.aspx"
}
}

The first part of this simply scans your incoming HTTP Request URI’s looking for “umbdebug” and when found it redirects the request back out to the homepage or whatever location you choose to send them.

The second part of the iRule I have added because it will prevent people from accessing the Umbraco Administration console.  This is not only a good idea for security but is also another Umbraco Best Practice.  It is important because it prevents your content developers from accessing that area via the load balanced URL.

If you are using DFS as your storage method on the backend of Umbraco and you attempt to use the load balanced URL to upload documents their experience will not be a pleasant one.  Documents will hang while they are uploading them and may even lock-up their web browser.  They will need to access one (and only one) server directly for site administration.

Like the first part of the iRule, it scans incoming HTTP Request URI’s but this looks for “umbraco” in the URI path and if it is found redirects the user to the location of your choosing.  You could also just drop the packets or something along that line, but I find dumping people out to the root of the site is adequate enough in most cases.

Share

1 comment so far

Add Your Comment
  1. Very cool. :)

    If you want to send both URIs to the same place you could also do it like so:

    when HTTP_REQUEST {
    switch -glob [string tolower [HTTP::uri]] {
    “*umbdebug*”-
    “*umbraco*” {
    HTTP::redirect “https://mycompany.com/default.aspx”
    }
    }
    }

    Might even save you a few cycles. ;)

    Awesome stuff man, keep it coming!

    #Colin