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 🙂 Mike305Views0likes4CommentsHTTP Policy
Hello, I am attempting to write an HTTP Policy that validate several aspects (HOST HEADER & URI) of a request before forwarding on to the default pool. When I had single values the policy was working great, now that I've add multiple values I no longer get the desired outcome. When I the apply URI check it begins to RESET all traffic. The check of /status and the HOST HEADER work without issue. Thanks! ltm policy /QA/API_SERVICES { controls { forwarding } requires { http } rules { ALLOWED_SERVICES { actions { 0 { log write message "DENIED ACCESS TO WEB SERVICE" } 1 { forward reset } } conditions { 0 { http-uri path not contains values { /favorites/ /users/ } //ONLY PERMIT IF URI CONTAINS ONE OF THESE VALUES } } ordinal 3 } DROP_STATUS_PAGES { actions { 0 { log write message "DENIED ACCESS TO STATUS PAGE" } 1 { forward reset } } conditions { 0 { http-uri path ends-with values { /status } //BLOCK ACCESS TO STATUS PAGES } } ordinal 2 } HOST_HEADER { actions { 0 { log write message "INCORRECT HOST HEADER" } 1 { forward reset } } conditions { 0 { http-host host not values { service1.domain1.ca service2.domain1.ca } //DOES THE HOST HEADER CONTAIN EITHER OF THESE VALUES } } ordinal 1 } } strategy /Common/first-match }232Views0likes1CommentHow to remove config from LTM policy using CLI?
Hi all, We have following policy on one of our LTMs. ltm policy /Common/Test { controls { forwarding } requires { http } rules { Test-Client1 { actions { 0 { forward select pool /Common/CLient1_Pool } } conditions { 0 { http-uri contains values { 0099/ } } } ordinal 1 } We need to remove the "ordinal 1" part of the config from this policy. We can't find any option in GUI. How do we remove this using the CLI? Thanks,574Views0likes10Comments