For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

justjonathan_15's avatar
justjonathan_15
Icon for Nimbostratus rankNimbostratus
Apr 22, 2016

Checking Persistence iRule

Hi all,

 

We were supplied an iRule to use for a Java based application which gives out a session ID.

 

Since deploying our F5's to this application, we have noticed strange activity with user sessions, where users are hitting 3 different back-end servers, or receiving "already logged on" multiple times before accessing our systems.

 

I'm not an expert in TCL/iRule code - and would appreciate if people could advise if the below looks correct, or could even be causing us some problems?

 

My understanding is that a client hits the HTTP Server, and once they advance to the Java app they receive an APP-sid which then should set the persistence to that specific server.

 

when HTTP_REQUEST {
      log local0. "IP:[IP::client_addr] URI:[HTTP::uri] SSL:[SSL::sessionid]"
      if { [HTTP::uri] starts_with "/APP" and [HTTP::header "APP-sid"] ne "LocalSession" } {
        if {[persist lookup uie [HTTP::header "APP-sid"]] ne ""} {
            log local0. "Using APP-sid: [HTTP::header "APP-sid"]"
            persist uie [HTTP::header "APP-sid"]
        } else {
            log local0. "Using SSL Session- setting APP-sid"
            set APPSID [HTTP::header "APP-sid"]
            persist uie [SSL::sessionid]
        }
      } else { 
        log local0. "Using SSL Session"
        persist uie [SSL::sessionid] 
      }
    }

    when HTTP_RESPONSE {
      if {[info exists APPSID]} {
        persist add uie $APPSID
        log local0. "Client: [IP::client_addr]: Set persistence for $APPSID : [persist lookup uie $APPSID]"
        unset APPSID
      }
    }

Thanks!

 

application delivery
devops
iRules
LTM

2 Replies

  • IanB's avatar
    IanB
    Icon for Employee rankEmployee
    Apr 23, 2016

    I suggest you uncomment the three log lines that are currently commented out, and see if that shines any light on what's going on.

     

    There are two paths through that code that will end up persisting on SSL session ID, which is a disaster waiting to happen, since the SSL session ID can change as often as every few minutes, depending on the client.

     

    You really should be persisting on something that is expected to remain static, like a session ID that the server passes back to the client as an HTTP cookie

     

  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Apr 28, 2016

    Hi,

    there is an issue in your irule:

    if {[persist lookup uie [HTTP::header "APP-sid"]] ne ""} {
        log local0. "Using APP-sid: [HTTP::header "APP-sid"]"
        persist uie [HTTP::header "APP-sid"]
    } else {
        log local0. "Using SSL Session- setting APP-sid"
        set APPSID [HTTP::header "APP-sid"]
        persist uie [SSL::sessionid]
    }

    For the first request, persistence uie does not exist with [HTTP::header "APP-sid"]. so it is used as persistence record.

    Next request, as lookup find the persistence record, you decide to not use it... which is not desired behavior.

    And as persistence is set during HTTP request, there is no need to add it in the HTTP_RESPONSE event. 

    persist uie
    command lookup in persistence table and set value if does not exist in table.

    You can replace the irule with:

    when HTTP_REQUEST {
    log local0. "IP:[IP::client_addr] URI:[HTTP::uri] SSL:[SSL::sessionid]"
    if { [HTTP::uri] starts_with "/APP" and [HTTP::header "APP-sid"] ne "LocalSession" } {
      persist uie [HTTP::header "APP-sid"]
    } else { 
      log local0. "Using SSL Session"
      persist uie [SSL::sessionid] 
    }
}