APM (& LTM) Session & Cookie Information - Chrome Extension
Problem this snippet solves: If you've ever troubleshooted APM Portal Access issues, you know how annoying it can be to find the decoded internal url. Note: This extension has been updated as more of an APM and LTM extension as opposed to just an APM one. This chrome extension seeks to make that quick and easy by showing the decoded information. It will also display the cookies for that site (including the ever-useful MRHSession and LastMRH_Session cookies) and allows you to delete cookies directly from the extension (useful for testing session timeout if you delete the MRHSession cookie). Version History 1.1 - Initial version Includes APM portal access decoded url information 1.2 - 2016.04.01 Added list of cookies associated with the current site (shows cookie name, domain and value) 1.3 - 2016.04.25 Added ability to delete cookies from the extension for the site (Known Issue: if you have multiple cookies with the same name that match the page, deleting one will delete all of them) Added decoded BIG-IP persistence cookie value in parenthesis to the list for quicker reference 1.4 - 2016.06.30 Rebuilt the popup page using AngularJS Introduced (but still disabled) options page and client-side functionality (will need iRules development as well) 1.5 - 2016.09.07 Enabled the options page again, and finished code to allow the extension to add a header to requests on specific domains (user specified) 1.5.1 - 2016.09.18 Updated the icon, and removed APM and replaced with debugging icon since this has morphed to APM and LTM usefulness 1.6 - 2016.12.19 Now enables the extension when it determines a persistence cookie (based on value format) Added a link that will popup APM session details (when management url specified in options page) (Note: must be logged into the management GUI already or else it won't redirect properly). Used alongside my APM Tampermonkey script you can see the session variables as well as the session detail 1.7 - 2017.09.03 Added local tracking of sites that appear to use F5 BigIP How to use this snippet: As Chrome doesn't really like unpublished extensions, and it's not in the Chrome App Store (yet), you'll have to install the extension in Developer Mode. Instructions Navigate to chrome://extensions Ensure that the Developer mode checkbox is enabled Sub-Method 1: Load unpacked extension (preferred method) Download all the code from the Github repository Click the Load unpacked extension button and select the src folder Sub-Method 2: Load the crx file (may not always be current) Download the crx from the Github repository From the file system, click and drag the .crx file onto the extension page to install it Code : https://github.com/jangins101/F5-APM-Session-Information Tested this on version: 11.5
How to generate the persistence cookie with an iRule
Problem this snippet solves: When you configure a cookie persistence profile to use the HTTP Cookie Insert or HTTP Cookie Rewrite method, the BIG-IP system inserts a cookie into the HTTP response. The cookie value contains the encoded IP address and port of the destination server. Exemple of a cookie value : 1677787402.36895.0000 (See SOL6917 for more information about this topic) Let's assume that you want your pool member to receive a copy of this cookie value in an HTTP header. Because for example you want your application to forge an url where the cookie value is in a GET parameter. (NOTE : I cannot modify the behavior of the application, I can only play with headers) Retrieving the cookie value is pretty easy with iRule : [HTTP::cookie value $cookie_name] But you'll notice that there is a little issue with this feature: when you are a new visitor, the persistence cookie is inserted in the HTTP response ... Meaning that for the very first hit made by the visitor, there will be NO cookie value to retrieve ... In my scenario it was an issue to miss this cookie value on the first hit, so I had to come up with a solution to forge the cookie value based on pool member IP and port when the persistence cookie is missing. I chose to adapt the code found here and there (thanks !) EDIT : Well I figured out that if you are not using a default route-domain the persistence cookie value will be different (see https://support.f5.com/csp/article/K6917 ) Here is the alternative code bloc to use IPv4 non-default route domains: set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" set PORT [LB::server port] set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" How to use this snippet: To summarize what the iRule does : if the persistence cookie doesn't exist (most likely because it's the very first hit), then calculate it from member IP and PORT (it obviously has to be after the "When LB_SELECTED" statement) ; else just read the existing cookie. You can set the $cookie_name parameter manually, or let the iRule identify it Code : when LB_SELECTED { #set cookie_name SERVERID # following function could determine persistence cookie name being used if not manually set by the previous line if {not [info exists cookie_name]} { if { [set cookie_name [PROFILE::persist mode cookie cookie_name]] eq "" } { set cookie_name "BIGipServer[getfield [LB::server pool] "/" 3]" } #Default cookie name requires the getfield "/" 3 purge otherwise it's /Common/pool_name } if { [set COOKIE [HTTP::cookie value $cookie_name]] == "" } { scan [LB::server addr] {%d.%d.%d.%d} a b c d set ADDR [expr { $a + $b * 256 + $c * 65536 + $d * 16777216 }] set PORT [ntohs [LB::server port]] set COOKIE "${ADDR}.${PORT}.0000" ## Following bloc must be used instead if you are using non-default route domains, see K6917 #set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" #set PORT [LB::server port] #set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" ######### unset a b c d ADDR PORT #log local0. "$cookie_name = $COOKIE created for [HTTP::uri]" } else { #log local0. "$cookie_name = $COOKIE already exists for [HTTP::uri]" } HTTP::header insert X-F5-persist $COOKIE } Tested this on version: 11.5
How to add Httponly and Secure attributes to HTTP cookies (for 11.5.x)
Problem this snippet solves: Problem this snippet solves: The script adds Httponly and Secure attributes to cookies issued by the server. In v12.x software there is a better way to achieve the same outcome with using HTTP::cookie commands (even though adding Httponly requires additional tweaks because of the issue with cookie version field see discussion here). However, in v11.5 and earlier releases HTTP::cookie commands do not work as expected (in particular, upper case chracters cookie attributes e.g. "Expire" and "GMT" are parsed with errors, as discussed in 19-Oct-2013 post by DanW here). Furthermore, in these software versions F5 Persistent Cookies do not have "Httponly" attributes and adding them using HTTP::cookie command appears to be impossible (as "HTTP::cookie version" command cannot be used for F5-generated cookies). Note: the HTTP::cookie commands repairs non-RFC-compliant attributes "httponly=<any text>" and "secure=<any text>" by replacing them with "Httponly" and "Secure" respectively. The script below does not perform such replacements and leaves these non-RFC-compliant attributes unmodified (without adding duplicates of the attributes). We consider fixing non-RFC-compliant syntax to be out of the scope. Browsers we tested ignored the <any text> values (in "httponly=<any text>" and "secure=<any text>" attributes). How to use this snippet: How to use this snippet: The same instance of this iRule can be applied to a mixture of HTTP or HTTPS Virtual Servers and will automatically disable insertion of “Secure” attribute for the HTTP VSs. Tested on Versions: 11.5.2 HF1; 11.5.4 HF2; 12.1.1 HF1 Code : when CLIENT_ACCEPTED { set httpsVs [PROFILE::exists clientssl] # to determine whether the connection is via an HTTP or HTTPS VS # it can be done with [SSL::cert count] and catch in HTTP_RESPONSE # event, but there would have been a bigger perfomance impact } when HTTP_RESPONSE { set setckval [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" # this command removes all cookies from the responce, so we have to remove and then # re-insert in any case (rather then do it selectively on an as-needed per-cookie basis) foreach cookie1 $setckval { set cookie1 [string trimright [string trimright $cookie1] ";"] # to avoid obtaining multiple semicolons (e.g. ";;Secure" or "; ;Secure") in the output # if the orginal cookie had a trailing semicolon, possibly, followed by spaces # trailing semicolons, strictly saying, do not meet rules described in RFC 2965 # but there are reports of applications using them (e.g. Cisco Bug: CSCso95114) set list1 [lrange [split $cookie1 ";"] 1 end] # the first field (cookie name=value pair) is skipped to ensure that even cookies # that happen to have names "httponly" or "secure" are processed properly set hasHttpOnly false if { $httpsVs } { set hasSecure false} else { set hasSecure true } #i.e. insertion of "Secure" is disabled for non-HTTPS VSs foreach item1 $list1 { set titem1 [string tolower [string trim $item1]] # accordring to RFC 2965 leading and trailing WSP characters in atrributes # should be ignored and attributes should be treated as case-insensitive; if { ($titem1 eq "httponly") or ($titem1 starts_with "httponly=") } { set hasHttpOnly true } if { ($titem1 eq "secure") or ($titem1 starts_with "secure=")} { set hasSecure true } } if { not $hasHttpOnly } { set cookie1 "${cookie1}; Httponly" #log local0. "Missing Httponly attribute is being added to cookie: $cookie1" } if { not $hasSecure } { set cookie1 "${cookie1}; Secure" #log local0. "Missing Secure attribute is being added to cookie: $cookie1" } #log local0. "The following cookie is being rewritten: $cookie1" HTTP::header insert "Set-Cookie" $cookie1 } }