LTM/ASM Prevent session hijacking using an iRule

This is most likely not something you actually need to do. If someone managed to perform some man-in-the-middle attack or hijack a client system then very little you do on your side would be able to identify this to block access.

First you will have SSL/TLS (make this as strong as you can, highest protocol and cipher suite etc.) so the cookies and values will not be visible outside of the secure SSL/TLS connection.

The other issue with this is user's IP addresses do change, so if you lock each session to the source IP at login you are likely to find you will incorrectly kick-out user sessions.

Finally if you really need this to be secure I would look at F5 APM to provide additional security and authentication. For example you could have APM perform client side checking to ensure things like AV is running and up to date or even run a SSL VPN from client to APM to help mitigate the risk of a session being hijacked.

Hi,

it was a strange behaviour, before trying to fix your behavior using an irule or other we will just be sure that asm policy was correctly configured:

When you apply session hijacking (Preventing) ASM stores the device ID along with other client data (including the message key or session ID) in a cookie that remains with the client for the length of the HTTP session. The system periodically checks that the device ID of the client is the same one that was assigned when the session started.

So In all Case ASM will blocked user request because the system periodically checks that the device ID of the client is the same one that was assigned when the session started...

You confirm that in ASM (Security ›› Application Security : Sessions and Logins : Session Tracking)

You apply:

• Detect Session Hijacking by Device ID Tracking

Note: When you are using device ID to track traffic, make sure that the Accept XFF setting is enabled in the HTTP profile that is assigned to the virtual server.

set the blocking modes for the hijacking violation, click Security > Application Security > Policy Building > Learning and Blocking Settings (select in ASM Cookie Hijacking violation Learn, Alarm, and Block. ).

For more info:

https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-1-0/15.html

Keep me in touch

Hi Tom Lauwereins,

back in the days I wrote an iRule to use non-cookie information (e.g. Certificate, Source-IP) to protect sensitive session cookie information.

High Performance HMAC Cookie Signing

https://devcentral.f5.com/codeshare/high-performance-hmac-cookie-signing

Note: Use the

CLIENT_ACCEPTED

RULE_INIT

Note: Before using the HMAC verification iRule make sure to analyse your FedAuth cookie. If the FedAuth cookie value changes on every single response, then you should NOT use the iRule.

Note: Instead of using HMAC-verification (my solution uses RAM caches to speed up the verification) you could also develop an iRule which uses symetric encryption (this will require slightly more CPU instead of using RAM). The iRule would need to parse the response from your servers and intercept those requests which are setting the FedAuth cookie. You could then encrypt the cookie information in combination with the client IP (either as a pre- or suffix) before sending to the client. Whenenver the client sends the encrypted cookie on subsequent request to your F5, you need to decrypt it, verify the embedded client IP and finally inject the original cookie value back to the request.

Cheers, Kai