Using IP Restrictions with URL Rewrite-Week 25

URL Rewrite offers tremendous flexibility for customizing rules to your environment. One area of functionality that is often desired for URL Rewrite is to allow a large list of approved or denied IP addresses and subnet ranges.

IIS’s original IP Restrictions is helpful for fully blocking an IP address, but it doesn’t offer the flexibility that URL Rewrite does.

An example where URL Rewrite is helpful is where you want to allow only authorized IPs to access staging.yoursite.com, but where staging.yoursite.com is part of the same site as www.yoursite.com. This requires conditional logic for the user’s IP.

This lesson covers this unique situation while also introducing Rewrite Maps, server variables, and pairing rules to add more flexibility.

This is week 25 of a 52 week series for the Web Pro. Past and future videos can be found here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

7 Comments

  • Scott,

    Ummh I must say that I think you had poor examples this week and it is not the best way (even incorrect way) of solving the problem even though technically you covered the correct stuff. You method is floored.

    First I think your choice of words is really poor for your subdomain. The dev, test, staging, production environment lifecycle (actually names will vary) is established now.

    Staging server will often be a separate machine and I would say a bare minimum of a separate site on the same box. Not under the same site.

    Secondly and more seriously you are using a custom X header to determine access to a restricted site.

    This is a really bad idea. Anyone can just add any custom header to a request and I will have access to the box.

    There are many proxy type tools that can be easily add another header to request. For example a simple Firefox addon will add/modify custom headers like one called modify headers:

    https://addons.mozilla.org/en-us/firefox/addon/modify-headers/

    I am surprised you have not thought of this.
    Just security by obscurity is not the best way of securing anything.

    I would revise your security if you have setup a site this Scott.

    Sorry to sound critcial on your otherwise excellent serious. (So right with last week web gardens one. I blame Microsoft's IIS6 resource Kit documentation (it improves performance!) and the web gardens in the "performance" tab for most of this.)

    I just wanted others to know that this is a poor solution to the problem you made.
    You specfically said you do not want that wording appearing to people from the outside world only approved IPs yet you can bypass this by adding a custom header.

    Hope that helps+

  • Hi Rovastar,

    Great feedback. I appreciate you bringing this up. You raise some great points.

    In regarding to the first point about the staging site, I do realize that staging sites are often setup on different servers. However I've seen many situations where admin sites are merged into the production sites with only IP restrictions differentiating them. Even if it is a different server, if it’s public facing, then rules like this can lock it down with URL Rewrite, offering further flexibility with the decisions. I don't do this myself, but I support some pretty large sites that have been doing this for years. Right or wrong, it's pretty common.

    My main point is that if you want to lock down a site during development, to prototype, or even long term, URL Rewrite has a workable option. So I may not have explained it as well as I could have but I believe there are plenty of use cases for it.

    Your second point is even more important. You are very right that this solution does have a way to hack it, exactly as you mentioned. While the actual header name is not exposed anywhere and it would be difficult for anyone to discover it, it is security through obscurity and isn't adequate for properly blocking a site based on the IP address.

    I see two options for this:

    1. combine the rules when possible and don't use the http headers
    2. add a 'removing rule' above the current rules, which always strips out the custom header. Then if anyone attempts to set the header before the server gets a chance to, it's removed before it's used.

    Would you consider the 2nd option fully adequate? Can you think of anything else that I've missed after using the 2nd option?

  • I think the terminology of what is staging is different sometimes in different organizations but I do understand there can be a need for a separate subsite for admin/etc but I would always recommend a separate site for more security, easier logging, etc. I would not think it is a good architecture.

    Regarding the other rule. I think either of them should do the trick obviously like anything like this this testing with the inside knowledge to try and break it. So a header modifier and a packet sniffer to see if ever anything somehow is coming back.

  • I think the terminology of what is staging is different sometimes in different organizations but I do understand there can be a need for a separate subsite for admin/etc but I would always recommend a separate site for more security, easier logging, etc. I would not think it is a good architecture.

    Regarding the other rule. I think either of them should do the trick obviously like anything like this this testing with the inside knowledge to try and break it. So a header modifier and a packet sniffer to see if ever anything somehow is coming back.

  • Terminology can vary, and I used 'staging' as one example, although the scope of where this can come in handy is broader and can apply to admin sites, staging, QA, etc. Later this year I'll cover a new concept that leverages this.

    There are lots of valid situations where overlapping rules does make sense, but if you are able to fully separate everything into different sites or servers, then that's an excellent solution too.

    Thanks for confirmation on the solution. I'll see if I can add an amendment to the video. It sounds well worthwhile to cover that base.

  • How could one handle a senario where you might allow access from certain IP addresses and deny from others _unless_ they can login?

    For example, if you know a certain IP is good (A work site) and then you have mobile users and you want to prompt them to login if they aren't at work could you use a technique on the second rule that could prompt a login?

  • Hi Jeffrey,

    There are a couple ways that can probably accomplish this.

    One would be to create 2 identical websites and then using a location tag in applicationHost.config and have one that requires auth and one that doesn't. If you use windows auth then it’s applied to apphost already. Forms auth would need to be applied manually. The reason for doing it in apphost is that it can share the rest of the code base including web.config. Then in ARR you would direct users from the trusted IPs to one site and the rest of the users to the non-trusted site.

    Another option would be to edit your login page code to watch for certain IP addresses and then automatically log them in with a shared anonymous user. That wouldn't use URL Rewrite but can be achieved with some minor edits to the login code.

Comments have been disabled for this content.