Quick questions: In a firewall, if you’re presented with a checkbox asking if you want to block requests with ambigious extensions, what would you do? I’m guessing the answer from 99% of you would be “of course, I want to be as secure as I can be”. Well, read on. Maybe you won’t want to check that box after all.
Here’s a real annoyance I found last night (I must be in rant mode, sorry!). What’s more annoying is I couldn’t find a solution on microsoft.com or newsgroups to solve it. As I explained yesterday, over the weekend I setup a web-server for photo hosting running at home.
To do this, I simply used the web-publishing wizard in ISA 2004 to publish my IIS server out on the internet, filtering the accessible paths. However, I didn’t set any HTTP filtering on the web publishing rule. Being a consciensious (ha ha) administrator and as good practice, it’s best to ensure only the methods and extensions you are actually using on the web-site are allowed through the rule, and to block unwanted signatures.
The first part of the ISA rule HTTP filtering lockdown is on the methods tab. As this web-site is serving static content only, the only method I need is GET.
Then it’s on to the Extensions tab. As this is a photos web-site, jpg and gif are in there. Similarly htm and html for obvious reasons. The skinning for the site uses CSS (cascading style sheets). The ico is an interesting one and I certainly learnt something last hight. You may have noticed on certain web-sites, a seperate icon appears on the tab if you’re using Internet Explorer tabbed browsing through MSN desktop search (and other browsers of course), which also is stored in your favourites if you bookmark the site. I’d been curious for a while how that was done – well, not that curious, but on the list of things to find out at some point in the dim distant future. It turns out that the browser (if you do a network trace) sends a request for favicon.ico. Although I don’t have a custom icon yet, it made sense to allow requests for icons to go through.
Now here’s the real gripe. If you leave the rule as-is shown above, everything works. Let’s say I go to http://www.mysite.com, I have a default.html in that directory on the IIS server and I get a redirection request (HTTP 304 IIRC – I’m at work typing this) to http://www.mysite.com/default.html. This makes it much easier for people not to have to type in the full URL. BUT, I want to block requests containing ambiguous extensions – the ISA property page tells me I can, it sounds like a good thing to do, so I checked it and re-applied the rule.
Once you do this, the redirect is blocked by the ISA server HTTP filtering. I found a few articles, mainly relating to people griping about exactly the same thing but no answers. I’m going to track down someone internally from the ISA team who may be able to help here, but this struck me as a very strange thing to do. A redirect doesn’t really have an extension as such, so what can you put into the list to allow the redirection to take place?
Rant over. Hopefully I’ll find the answer soon. There’s some info on configuring HTTP Filtering here, including a baseline Mail Server Pubishing HTTP policy – guess what I’m going to be doing this evening….