LTM Policy Recipes

[Steve_McCarthy_]

LTM Policy is the powerful and performant replacement to the HTTP Class, and first appeared in Big IP 11.4.0. This is intended to be a short article showing some practical recipes using LTM Policy.  Please also check out another article with a more complete overview of LTM Policy.

While there are iRules which can be used to address each of the following scenarios, LTM Policy is a particularly good tool when it comes to inspecting and modifying HTTP-specific quantities like URIs, headers, and cookies.

Preventing the Nimda worm

If the URL contains certain strings known to be associated with Nimda, then use a forwarding action to reset the connection.

Demonstrates matching on URI and terminating a connection.

ltm policy /Common/nimbda-be-gone {
  controls { forwarding }
  requires { http }
	rules {
    rule-1 {
      actions {
        0 {
          forward reset
        }
      }
      conditions {
        0 {
          http-uri contains values { root.exe admin.dll cmd.exe }
        }
      }
      ordinal 1
    }
  }
  strategy /Common/first-match
}

Preventing spoofing of X-Forwarded-For

Bad actors may try to work around security by falsifying the IP address in a header and trying to pass it through the Big IP.  Replace X-Forwarded-For header in the request, if any, with the actual client IP address.

Demonstrates header replacement, case-insensitive comparisons of HTTP headers, use of Tcl expressions to access internal state.

ltm policy /Common/xff {
  requires { http }
  rules {
    remove existing" {
      actions {
        0 {
          http-header replace
          name X-foRWardED-for
          value tcl:[IP::client_addr]
        }
      }
      ordinal 2
    }
  }
  strategy /Common/first-match
}

Mitigating Shellshock

Shellshock refers to a class of exploits that take advantage of the bash shell via a specifically-crafted URL.  Here is a policy which looks for the pattern "() {" in the URI .  It is rare that this pattern of characters will occur in a URI so false-positives should be rare.

ltm policy /Common/shellshock {
  controls { forwarding }
  requires { http }
  rules {
    rule-1 {
      actions {
        0 {
          log write
          message "tcl:Shellshock detected from [IP::client_addr], blocked"
        }
        1 {
          forward reset
        }
      }
      conditions {
        0 {
          http-uri contains values { "() {" }
        }
      }
      ordinal 1
    }
  }
  strategy /Common/first-match
}

Selective compression

Certain types of content are good candidates for compression.  For example, transfers of common text types like HTML, XML, and CSS stylesheets can show improved transfer time – especially across slow links – by compressing it.

Here is a policy which demonstrates selective compression based on the Content-type, taking into account system load average.  All text-type responses will be compressed, but if the 1 minute load average climbs above 5, then compression will not be enabled to save CPU resources.

ltm policy /Common/blanket {
  controls { compression }
  requires { http }
  rules {rule-1 {
    conditions {
      0 {
        http-header response
        name Content-type
        starts-with
        values { text/ }
      }
      1 {
        cpu-usage response last-1min
        less-or-equal
        values { 5 }
      }
    }
    actions {
      0 {
        compress response enable
      }
    }
    ordinal 1
  }
}
strategy /Common/first-match
}

[Christian_Thoma]

when adding a LTM policy with its set of rules - say forward to a specific pool for a specific http-uri - to a virtual server resources , is this policy has precedence on default pool ? Or do you need to specify NONE in default poll and create 2 sets of rules for each pool you want traffic to be sent?

[Steve_McCarthy_]

If I understand your question, you can rely on the default pool for a virtual server to handle the default traffic, and create an LTM Policy with one rule to handle the special cases. If traffic does not trigger the LTM Policy, then the default pool setting will still apply.

[William_McCall_]

When performing reset action, we see the fallback host being used. Is there any action which can drop the connection without redirect to fallback host (without using iRule anyway)?