Forum Discussion

Meeks_60174's avatar
Meeks_60174
Icon for Nimbostratus rankNimbostratus
May 13, 2016

Client address filtering outside an iRule v11.5 code

Hello,

I've been looking around, and perhaps my google-foo is not very strong, so I apologize if this is a fairly common solution. Essentially I have this iRule i would like to rid myself of if entirely possible and perhaps replace it with a policy or other solution.

Its fairly straight forward. Did you come through a certain path that would inject a header into your packets, thus confirming certain layers of inspection done by that provider, or are you an internal trusted IP that would by pass the provider to evaluate development. If not, drop the packets.

when HTTP_REQUEST {
check header exists and have the right value, or is an internal or trusted address
if { [HTTP::header exists "MyHeader"] and ([HTTP::header "MyHeader"] contains "Predefined_Value") 
or ([class match [IP::client_addr] equals Trusted-Ip-Addresses ])}
        { 
        Use the default pool or another pool selected by a policy
        } 
        else {
        otherwise, drop the packet
        drop
        }
}

Looking into policies for this solution, I believe I have determined how to complete the header section of the iRule, however I found myself stumped on Client IP address portion.

ltm policy MyTestPolicy {
    controls { forwarding }
    requires { http }
    rules {
        http_header {
            actions {
                0 {
                    http
                    enable
                }
            }
            conditions {
                0 {
                    http-header
                    name MyHeader
                    contains
                    values { Predefined_Value }
                }
            }
            ordinal 3
        }
    }
    strategy first-match
}

Has anyone competed a similar task through the leverage of a policy? If not, if I were to move just the header inspection down to a policy from an iRule, which would execute first or ultimately be the deciding factor in this solution. I've found references to order of operations in iRules, however I've not been able to determine the order this would execute. Ideally, the goal would be, if the header does not exists, execute the iRule, otherwise, permit the traffic.

Thanks for taking the time to read this, even if you didn't have any comments. I hope the answer help others in the future 🙂

Mike

application delivery
http policy
iRules
LTM
security
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    May 13, 2016

    Policy are executed first, then irules.

    You can set tcl variable in Policies actions and use it in iRules.

    So, you can create a policy to filter based on HTTP header, if it matches, set a variable HeadersAllow to 1, then check if the variable exists and if value is 1 in irule.

    when HTTP_REQUEST {
check header exists and have the right value, or is an internal or trusted address
if { !(([info exists "HeadersAllow"]) && ($HeadersAllow) || ([class match [IP::client_addr] equals Trusted-Ip-Addresses ]))} {
        drop the packet
        drop
        }
}

    The policy is :

    ltm policy MyTestPolicy {
    controls { forwarding }
    requires { http }
    rules {
        http_header {
            actions {
                0 {
                    tcl
                    set variable 
                    name HeadersAllow
                    expression 1
                }
            }
            conditions {
                0 {
                    http-header
                    name MyHeader
                    contains
                    values { Predefined_Value }
                }
            }
            ordinal 3
        }
    }
    strategy first-match
}

    In version 11.6 and above, the policy configuration is:

    ltm policy Policy_test {
    controls { forwarding }
    requires { tcp http }
    rules {
        rule1 {
            actions {
                0 {
                    forward
                    reset
                }
            }
            conditions {
                0 {
                    tcp
                    address
                    not
                    matches
                    values { 1.2.3.4 }
                }
                1 {
                    http-header
                    name MyHeader
                    not
                    values { Predefined_Value }
                    missing
                }
            }
            ordinal 1
        }
    }
    strategy first-match
}
  • Meeks_60174's avatar
    Meeks_60174
    Icon for Nimbostratus rankNimbostratus
    May 13, 2016

    You are amazing. Thank you so much for your help.

    Im inclined to disagree with the "Policy are executed first, then irules." statement, since i have a policy that never executes, when both conditions of the iRule fail, and thus are dropped. Let me explain more.

    The reason im trying to leverage the policy, is related to top level domain. Cant CNAME the top level, and I have customers hitting it directly, and being blocked, since they are bypassing the header injection, and are not coming from the trusted ip space.

    I have a policy that does a check for http-host not start with www and redirects with the www inserted. My intent was a first match policy, that had that as rule 1 in the order, followed by the header check and subsequently the IP check.

            no_www {
        actions {
            0 {
                http-reply
                redirect
                location "https://www.[getfield [HTTP::host] \":\" 1][HTTP::uri]"
            }
        }
        conditions {
            0 {
                http-host
                host
                not
                starts-with
                values { www }
            }
        }
        ordinal 2
    }

    Any thoughts on how i could leverage all of this together?

  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    May 14, 2016

    Hi,

     

    For the same event, policies execute before irules.

     

    If your irule event is CLIENT_ACCEPTED, irule Will execute first because event occurs before.

     

    And if both Irule have different condition and drop request, if one of them matches, the request is dropped.

     

    There are Irule commands to retrieve policy action and match. If Irules are executed first, these commands are are useless.