How to Migrate F5 iRules to Edgenexus flightPATH

It’s a widely held belief among my colleagues at Edgenexus that whilst F5 LTM load balancers are extremely powerful and flexible, the reliance on the use of iRules scripting to perform some basic functions leads to unnecessary complexity.

You only have to do an online search for F5 iRules to discover the pain and angst that many IT professionals have to go through in the process of creating functional iRules. Whilst it’s true, the expansion of ‘Local Traffic Policies’ functionality in recent F5 software releases has removed some of the need to create iRules for common HTTP header manipulation functions, there are many users still stuck with legacy iRules in their system configuration.

Local Traffic Policies don’t appear to allow for manipulation of HTML data, although Stream policies do, they are rather clunky and difficult to control. By default these affect traffic in either direction in the same way, although this is not usually desirable. This means reverting back to iRules to perform functions such as a http:// to https:// URL body text link replacement that may be required in conjunction with a http:// to https redirection which can be performed using Local Traffic Policies.

Enter Edgenexus flightPATH – Traffic Management Made Easy

At Edgenexus, we are justifiably proud of the power and simplicity of configuration of our flightPATH Layer 7 HTTP manipulation function.

If you are an existing F5 user, making use of iRules for HTTP or HTML manipulation, we would be delighted to have the opportunity to give you a demonstration of the Edgenexus ALB-X load balancer and show you how straightforward flightPATH is to configure to achieve some relatively complex functions. We would like to be put to the test to help translate your existing iRules functions to flightPATH rules.

As an example, we have reproduced below a selection of F5 iRules with the equivalent Edgenexus flightPATH rule configuration screen shots.

Source IP Content Server Steering

Here is an example of how F5 iRules can be used to direct users from a certain IP address range to one Server Pool and those from another range to another Server Pool.

F5:

Name:	IP_Choice
Definition:	when HTTP_REQUEST { if { ( [IP::addr [IP::client_addr] equals 24.24.15.100] ) or ( [IP::addr [IP::client_addr] equals 10.1.1.2] ) } { pool pool2 } }

Edgenexus:

click here to enlarge

Create a new flightPATH rule with name IP_Choice_Pool_1 via the Web GUI. Add a concise description to be able to identify what the function the flightPATH rule is performing.
Add a new Condition, selecting Source IP from the extensive drop down list. Select “Does” from the Sense drop down. One option is to select Start from the dropdown Check list (as an alternative you can use other options such as RegEx to provide more flexibility for the IP address ‘Value’). Enter the start IP range in the Value box.
Add a New Action. From the Action drop down box choose the Use Server option (there is also a Use Secure Server option if required). In the Target box enter the IP address and port of the required destination, this is usually another Virtual Service interface to allow for load balancing across another pool of real servers.

HTTP to HTTPS Redirection

Whilst F5 now has an alternative to using iRules to perform HTTP to HTTPs redirection, there are many instances where people are still using iRules for this function. iRules also allows for more customisation of the redirection parameters.

F5:

Name:	HTTP_HTTPs Redirection
Definition:	when HTTP_REQUEST { HTTP::redirect “https://[HTTP::host][HTTP::uri]” }

Edgenexus:

click here to enlarge

Create a new flightPATH rule with name Redirect HTTP to HTTPS via the Web GUI. Add a concise description to be able to identify what the function the flightPATH rule is performing.
For most applications the requirement to perform the HTTP to HTTPS redirection needs to be performed on all traffic hitting the HTTP service. In this case no Condition rule needs to be created. There is a great deal of flexibility to create condition rules if the flightPATH rule should only affect certain traffic.
Add a new Action choosing Redirect 302 from the Action dropdown box (Redirect 301 is also available). The Edgenexus ALB-X automatically creates variables for certain key parameters for traffic processed by the ALB-X, this includes the host, path and query string. In the Target box enter the details of where the request should be redirected to. In this case precede the entry https:// and use the $host$$path$$querystring$ variables to insert the data from the original http request. As you can see there is flexibility here to define a completely different destination if required.

Mask Credit Card Numbers

Here is an example of the complexities of iRules and the way in which F5 handles HTML body manipulation.

F5:

Name:

Credit Card Number Masking

Definition:

when HTTP_REQUEST {

  # Prevent the server from sending a compressed response
  # remove the compression offerings from the client
  HTTP::header remove “Accept-Encoding”

  # Don’t allow response data to be chunked
  if { [HTTP::version] eq “1.1” } {

     # Force downgrade to HTTP 1.0, but still allow keep-alive connections.
     # Since HTTP 1.1 is keep-alive by default, and 1.0 isn’t,
     # we need make sure the headers reflect the keep-alive status.

     # Check if this is a keep alive connection
     if { [HTTP::header is_keepalive] } {

        # Replace the connection header value with “Keep-Alive”
        HTTP::header replace “Connection” “Keep-Alive”
     }

     # Set server side request version to 1.0
     # This forces the server to respond without chunking
     HTTP::version “1.0”
  }
}
when HTTP_RESPONSE {

# Only check responses that are a text content type (text/html, text/xml, text/plain, etc).
if { [HTTP::header “Content-Type”] starts_with “text/” } {

   # Get the content length so we can collect the data (to be processed in the HTTP_RESPONSE_DATA event)
   # Limit collection to 1Mb (1048576 minus a little to spare) – See SOL6578 for details
   if { [HTTP::header exists “Content-Length”] } {
     if { [HTTP::header “Content-Length”] > 1048000 }{
       # Content-Length over 1Mb so collect 1Mb
       set content_length 1048000
     } else {
       # Content-Length under 1Mb so collect actual length
       set content_length [HTTP::header “Content-Length”]
     }
   } else {
     # Response did not have Content-Length header, so use default of 1Mb
     set content_length 1048000
   }
   # Don’t collect content if Content-Length header value was 0
   if { $content_length > 0 } {
      HTTP::collect $content_length
   }
}
}
when HTTP_RESPONSE_DATA {
# Find ALL the possible credit card numbers in one pass
set card_indices [regexp -all -inline -indices\
   {(?:3[4|7]\d{2})(?:[ ,-]?(?:\d{5}(?:\d{1})?)){2}|(?:4\d{3})(?:[ ,-]?(?:\d{4})){3}|(?:5[1-5]\d{2})(?:[ ,-]?(?:\d{4})){3}|(?:6011)(?:[ ,-]?(?:\d{4})){3}}\
   [HTTP::payload]]

foreach card_idx $card_indices {
   set card_start [lindex $card_idx 0]
   set card_end [lindex $card_idx 1]
   set card_len [expr {$card_end – $card_start + 1}]
   set card_number [string range [HTTP::payload] $card_start $card_end]
   # Remove dash or space if they exist and count the occurrences in variable cutouts.
   set cutouts [regsub -all {[- ]} $card_number “” card_number]
   # Adjsut card_len variable but keep it for later use.
   set new_card_len [expr {$card_len – $cutouts}]

   set double [expr {$new_card_len & 1}]
   set chksum 0
   set isCard invalid

   # Calculate MOD10
   for { set i 0 } { $i < $new_card_len } { incr i } {
      set c [string index $card_number $i]
      if {($i & 1) == $double} {
         if {[incr c $c] >= 10} {incr c -9}
      }
      incr chksum $c
   }

   # Determine Card Type
   switch [string index $card_number 0] {
      3 { set type AmericanExpress }
      4 { set type Visa }
      5 { set type MasterCard }
      6 { set type Discover }
      default { set type Unknown }
   }

   # If valid card number, then mask out numbers with X’s
   if { ($chksum % 10) == 0 } {
      set isCard valid
      HTTP::payload replace $card_start $card_len [string repeat “X” $card_len]
   }

   # Log Results
   log local0. “Found $isCard $type CC# $card_number”
}
}

Edgenexus:

click here to enlarge

Create a new flightPATH rule and provide a meaningful description
This is another example where condition matching may not be required as you would normally want to protect any server responses. The option does of course exist if required.
Add new ‘Action’ and choose ‘Body Replace All’ from the drop down menu option. Use is made of Regular Expressions to be able to match the Target text to be replaced by this action. Use \b(?:\d[ \t-]?){12}\b as the target for detecting and replacing the first 12 digits of credit card numbers. In the Data field enter xxxx-xxxx-xxxx as the replacement text. This will leave the customary last 4 digits intact as an identifier.
Repeat the above process for other sensitive data types such as National Insurance numbers using \b(?:\d[ \t-]?){7}\b replaced by xxx-xxxx and \b(?:\d[ \t-]?){6}\b replaced by xxx.xxx
With judicious use of regular expressions a wide variety of character sequences can be matched and masked simply using the Body Replace action. Body Replace First and Body Replace Last are other action options which can be used when only the first or last instance of a character sequence on a page need be replaced.

Remove Potential Security Compromising X- Headers

It is often cited as good practice to avoid providing unnecessary information on the server infrastructure used for an application delivery, by removing certain HTTP headers that are inserted by default by the application or server technology. The more a hacker knows about the system they are looking to exploit the easier it is. There is often a lag between system vulnerabilities being published and patching taking place. It is during this period that systems are most at threat and where the process of obscuring the details of the application delivery platform is most useful.

Many of the unnecessary information is contained in X-Headers. The following iRule performs a blanket X-Header removal which may not be desirable.

F5:

Name:	HTTP X-Server Header Removal
Definition:	when HTTP_RESPONSE { # Remove all instances of the Server header HTTP::header remove Server # Remove all headers starting with x- foreach header_name [HTTP::header names] { if {[string match -nocase x-* $header_name]}{ HTTP::header remove $header_name } } }

Edgenexus:

click here to enlarge

Create a new flightPATH rule with a meaningful name e.g. Remove HTTP Headers
This is an example of a flightPATH rule where no condition matching is likely to be required. There is a comprehensive set of selection criteria available if needed.
Add a new action to ‘Remove Response Header’, in the Target field enter the header value to be removed. Add a Remove Response Header action entry to define each of those header fields that you require to be masked from the server responses. A blanket action of removing all custom X- prefixed headers could in fact have a detrimental effect so flightPATH requires you to define the specific headers that need to be removed.
Apply the flightPATH created to each of the services where the action is required.

Applying flightPATH Rules to Virtual Services

flightPATH is a very powerful, but simple to use HTTP manipulation tool. You can create a ‘Library’ of flightPATH rules to perform various actions on HTTP traffic as it traverses the ALB-X load balancer appliance. Multiple flightPATH rules can be applied to a virtual service. The flightPATH rules are processed in the order in which they are applied to the service. Some flightPATH rules terminate the processing. You can use drag and drop to rearrange the order to ensure all the actions are performed as required. There is comprehensive flightPATH logging and tracing available that allows for debugging of flightPATH operation. edgeNEXUS can offer professional services to assist with more complex flightPATH rule translation and creation.