newbie case sensitive question

Greg,

why do you need to check the URIs? If the requested ASP does not exist on the origin server (node), the server will issue "bye, bye" (404 Not Found) response on it's own 🙂 If there are some ASPs on the server that you do not want to be exposed at all, then I'd suggest to remove them.

Having said that, you rule might look like this (assuming that the ".asp" extension is always lowercase and also URIs are in the root):

rule name_check {
   if(substr(http_uri, 30) == "" and http_uri ends_with ".asp" and substr(http_uri, 1, '.') matches_regex "^[a-zA-Z0-9]+$") {
       use pool some_pool
    } else {
       redirect to "http://betterlucknexttime.com"
    }
}

Thanks for the reply,

 

We are using the F5 as an application layer filter to check requested URLs are authorised to be served from the web server.

 

 

One area of possibe problems we are attempting to protect is the possibility a developer may have left a test script, default scripts (or something) on a server and we want to make sure F5 only allows page requests to the web servers that have been approved should be allowed through.

 

We have several web servers and many developers.

 

 

Usually I try to name specific scripts that are allowd to run, but the currect web server has too many and I feel there would be a performance hit if I just supplied a long list of URLs to match.

 

 

I am open to better ways to deal with this type of issue if more experienced folk can throw some additional light onto this.

 

 

-Greg

Greg,

 

 

it is perfectly fine to use BIG-IP for this purpose. I'm just not sure how your filtering criteria can distinguish an "authorized" script from a "forgotten/test/default simply un-authorized" one. What if the name of the "unauthorized" script is less than 30 characters, ends in ".asp" and contains only alphanumeric characters? I'd guess that most default or test scripts meet this criteria. Of course if you have a scrict (and enforced) policy that test scripts must not be named this way in place, then you are safe ... well and the filtering on the BIG-IP is not necessary. If you have a strict policy in place, it would be better to modify it and require that test scripts are put in a separate subtree. If you don't have any (enforced) policy in place and developers have access to the production server, then no amount of filtering on the BIG-IP is going to achieve the level of control you need.

 

 

Probably the best solution to your problem is to have separate development and production servers or at least a separate subtree for development at the production server. Access to objects on the development server or within the development subtree of the production server can be then easily controlled at the BIG-IP.

 

 

You may also be interested in our TrafficShield product Click here, which allows to control access to web applications with very fine grained granularity and it also allows to build the policy interactively based on observing behavior of applications.