Error on LTM with getting IP from data group in an IRULE

Thank you Jeremy!

If I want to integrate this in, how would you add it to this code? So if your XFF IP is in the data group, and you are trying to access this URI "/uri1/uri2/uri3/adminpage", than redirect to "/secret/uri1/uri2/uri3/adminpage/"...

Thank you for your recommendation.

 if { ([class match $CHECK_IP eq "DG-ALLOWED-IP-XFF"]) } {

       if { [HTTP::uri] eq "*/uri1/uri2/uri3/adminpage*"} {

           HTTP::redirect "https://[HTTP::host]/secret/uri1/uri2/uri3/adminpage/" }

Tony,

There are a few options. This rule is not the most efficient way to accomplish your request, but it should be simple to understand, maintain and modify if needed.

1. Determine if the request is for a protected URL.
2. Check if XFF IP is allowed.
3. Allow, Redirect or reject depending on results.

when HTTP_REQUEST {
     1. Check for secure URL
     variable to track if the site is secure
    set SEC 0
    if {[class match [HTTP::uri] starts_with DG-ALLOWED-URI-LIST]} {
        set SEC 1
    } elseif { [string match -nocase {*/uri1/uri2/uri3/adminpage*} [HTTP::uri]] } {
        set SEC 1
        set REDIR "/secret[HTTP::uri]"
    }

     2. Check if IP/XFF is allowed
    if { $SEC } {
         this is a secure URL
         check the real source IP
        set MATCH [class match [IP::client_addr] equals DG-ALLOWED-IP-XFF]

         cycle the X-Forwarded-For headers
        foreach HDR [HTTP::header values X-Forwarded-For] {
            if {$MATCH} { break }
             format the X-Forwarded-For header into a valid TCL list
            foreach IP [string trim [regsub -all {[,; ]+} $HDR " "]] {
                if {[catch {set MATCH [class match $IP equals DG-ALLOWED-IP-XFF]}] != 0} {
                    log local0.err "[virtual name]: Client [IP::client_addr] \
                    had an invalid X-Forwarded-For address - \x22${IP}\x22"
                    set MATCH 0
                }
                if {$MATCH} { break }
            }
        }
         3. Allow, redirect or reject
         check for match and perform redirect if needed
        if {$MATCH} {
            if {[info exists REDIR]} {
                HTTP::respond 302 Location $REDIR
                unset REDIR
            }
        } else {
            HTTP::respond 403 Connection close
        }
        unset MATCH
    }
    unset SEC
}

1. To match the URI you want to redirect, I used

   string match -nocase

   , but the same can be accomplished with

   if { [string tolower [HTTP::uri]] contains "/uri1/uri2/uri3/adminpage" }

   Both have the same result.
2. This rule only redirects the secure URL if the client has an approved IP. Another option is to redirect anything that matches

   /uri1/uri2/uri3/adminpage

   regardless of source IP or what's in the XFF header. From the user's perspective, the result would be the same and the rule would be a little shorter and probably a little faster.
3. Instead of using a whole URL in the redirect, the rule performs a relative redirect pre-pending

   /secure

   onto the original URI. When the browser redirects, it will use the same scheme and domain.
4. If a redirect is needed, it's critical that the URI you redirect to matches something in the DG-ALLOWED-URI-LIST data-group. If not, you will create a redirect loop.
5. Instead of using

   HTTP::redirect

   , this rule uses

   HTTP::respond 302 Location ...

   I prefer this method because it clearly shows it's a 302 redirect and makes it simple to change to a 301 if desired. It also allows adding additional headers to the response.

   HTTP::redirect /secure[HTTP::uri]

   is the same as

   HTTP::respond 302 Location /secure[HTTP::uri]

If this is a rule you plan to use in a production environment, it is important you test it and understand it.

Let me know how it works.

Thanks Jeremy! I appreciate your help on this.

Here is a version I did, which is much more simpler than your version. Would this work?

first section monitors the pool for availability. if all nodes are down, it will redirect to a maintenance page.

second section checks the XFF IP, and if it is in the data group called "DG-ALLOWED-IP-XFF" and they are trying to access the URI in another group called "DG-URI-LIST", it will be allowed, and if your IP is not in the list, you get rejected.

Third section, most important -- if your IP in the XFF header matches what is in the data group above, and you are trying to go to /uri1/uri2/uri3/adminpage* -- than you will get redirected to another URI https://[HTTP::host]/secret/uri1/uri2/uri3/adminpage/"

I have not tested your version yet. Will it do the same as what I have just posted?

ltm data-group internal DG-ALLOWED-IP-XFF {

    records {

        1.1.1.1/32 { }

        2.2.2.2/32 { }

    }

    type ip

}


ltm data-group internal DG-URI-LIST {

    records {

        /URI1 { }

        /URI2 { }

    }

    type string

}





when HTTP_REQUEST {

if { [active_members POOL-WEBSERVER-443] < 1 } {

HTTP::redirect " http://site-maintenance.com"


} else {


set CHECK_IP [getfield [HTTP::header values X-Forwarded-For] " " 1]

  if { !([class match $CHECK_IP eq DG-ALLOWED-IP-XFF]) } {

      if { [class match [HTTP::uri] eq DG-URI-LIST] } {
             reject 
               }
             }

        log local0. "Client IP Discard: \ [HTTP::host][HTTP::uri]->[IP::client_addr]->[IP::local_addr]:[TCP::local_port]"


       switch -glob [HTTP::uri] {

         "*/uri1/uri2/uri3/adminpage*" {

       if { ([class match $CHECK_IP eq DG-ALLOWED-IP-XFF]) } {

          HTTP::redirect "https://[HTTP::host]/secret/uri1/uri2/uri3/adminpage/" }

           log local0. "redirect to admin area for internal users: \ [HTTP::uri]->[IP::client_addr]->[IP::local_addr]"

       }

    }

  }

}