How could I exclude Vulnerability scanners from Session Tracking?

Hi Dave,

 

 

Here's an iRule you can use to set the domain on the persistence cookie. For clients who support cookies, this will tell them to send the cookie in their requests to any subdomain on the main domain.

 

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/1178393/showtab/groupforums/Default.aspx1225262

 

 

There's an RFE ID of BZ273573 requesting this feature be added to the cookie persistence profile. You could open a case with F5 Support to raise the visibility of this request.

 

 

Aaron

Thanks Aaron. I'll give it a try.

 

 

Dave

Aaron

 

 

I applied the irule as written in the link you referenced except for changing the domain name, but it is not quite working as expected. If I go to domain.com, and then to or any other something.domain.com, it is persistent, but if I go to http://www.domain.com/, a.domain.com, and domain.com, say in that order, I am not persistent and get the next server in rotation. Once I hit domain.com, then my session becomes persistent to whichever server domain.com is persistent to, so this only fixes part of my problem. Have I missed a step?

 

 

when HTTP_RESPONSE { log local0. "[IP::client_addr]:[TCP::client_port]: Pre Set-Cookies: [HTTP::header values Set-Cookie]" Check if the persistence cookie exists in the response if {[HTTP::cookie exists "My_cookie"]} { set the domain attribute on the persistence cookie HTTP::cookie domain "My_cookie" ".ddcpoc.com" log local0. "[IP::client_addr]:[TCP::client_port]: Modified domain on My_cookie" } log local0. "[IP::client_addr]:[TCP::client_port]: Post Set-Cookies: [HTTP::header values Set-Cookie]" }

 

 

How do I copy a rule into this forum and retain the formatting?

 

 

Thanks,

 

 

Dave

 

Hmmm, the formatting should be preserved by just copy and pasting. Try adding code tags around it next time:

 

 

[ code ]

 

code goes here

 

[ / code ]

 

 

 

But without the spaces.

 

 

 

As to the iRule itself, it doesn't look like the iRule is actually setting any persistence, just updating the cookie on the response from server. Where are you actually setting this cookie in your deployment? That's likely where you'll need to make the change.

 

 

Colin

Updating the cookie to maintain persistence across all sub-domains is what I meant. I have a test site setup with only this one rule in place, so not sure what I could do different. Any ideas?

 

 

Thanks

This part of the rule isn't doing anything because it's not logging. Do I need to define My_cookie somewhere?

 

 

Check if the persistence cookie exists in the response

 

if {[HTTP::cookie exists "My_cookie"]} {

 

set the domain attribute on the persistence cookie

 

HTTP::cookie domain "My_cookie" ".ddcpoc.com"

 

log local0. "[IP::client_addr]:[TCP::client_port]: Modified domain on My_cookie"

 

}

If you are trying to create a custom cookie take a look here:

 

 

http://devcentral.f5.com/wiki/iRules.http__cookie.ashx

 

 

HTTP::cookie insert name value [path ] [domain ] [version <0 | 1 | 2>]

 

Adds a cookie to the HTTP Cookie header in requests or Set-Cookie response header. The default value for the version is 0. If the cookie already exists, a second cookie will be inserted (tested in 9.2.4).

Just change My_cookie to the cookie name you want to rewrite the domain for. If you're using the default cookie name for the cookie insert persistence profile, you can use this:

 Check if the persistence cookie exists in the response
if {[HTTP::cookie exists "BIGipServer[LB::server name]"]} {
    set the domain attribute on the persistence cookie
   HTTP::cookie domain "BIGipServer[LB::server name]" ".ddcpoc.com"
   log local0. "[IP::client_addr]:[TCP::client_port]: Modified domain on BIGipServer[LB::server name]"
}

Aaron

Thanks for the responses. I had actually tried using a named cookie yesterday but got some strange results and I get the same strange results today, but now I see where the problem is. I've been using IE8 and FF4 to test. IE8 is now working correctly, as it is inserting the correct domain name in the cookie and so stays persistent regardless of the sub-domain. Thanks for the help getting this working. I see the same results in FF 3.6.17.

 

 

FF4, on the other hand, stays persistent for all sub-domains, but it does not show a cookie, and nothing is logged, but hitting F5 to refresh the page switches it to the next available server, then loads the cookie, stays persistent to the new server and the F5 logs the activity. This is what I was seeing yesterday and what was throwing me off. I upgraded to FF 6.0.1 and see the same behavior. I assume these new versions of FF will behave the same way for exisitng sites using a similar rule. Clearing the cache in FF 4 and 6 fixed this behavior, but the default settings are to cache sites and the only way I see to stop that is to set the cache to zero bytes, which most users are not going to do. There is no need to clear the cache in IE8 or FF3. Removing cookies before-hand didn't make any difference.

 

 

Has anyone else seen this? Thanks again.