ASM Cookie assistance

Honestly if all ASMs involved are running 11.x code and it is the cookie from the other device, then I am not sure why this would happen. I have seen this in mixed code environment where someone is going through an 10.x ASM and then get LBed to an 11.x ASM and the 11.x device does not like the TS cookie from the 10.x device. I saw this in my test environment when I upgraded but I managed the prod rollout accordingly and I LB between 2 standalone ASMs that both run 11.x and that works just fine.

 

 

Do you have a support case open yet?

I don't have a support case open just yet, thought I would exhaust the forum first.

 

 

There were unforseen issues when upgrading which meant that we were running Active 10.x and Active 11.x for a few moments, but as these cookies should be session based I'd be keen to know why they have not expired. Is there any way to see what TSxxxxxx cookie is set by a particular ASM, as they are always the same.

 

 

Thanks for your help,

 

Anthony

We started to experience same problem after v11.2.1 upgrade. ASM is setting at least two TS cookie with different domains:

 

 

TSaeea70Received.abc.com(Session)ServerYesNo

 

TSf1d257Received.commonag-portal-fit.nj.abc.com(Session)ServerYesNo

 

 

TS cookie with domain=.abc.com will be sent by browser to all apps in all abc.com environments and will trigger MOD_ASM_COOKIE violation.

 

 

Why ASM is setting cookie with domain=.abc.com ?

 

 

Thank you

This is from the release notes (asm 11.3):

 

 

Important: The system creates its internal cookie in versions 10.2.4 and later (including all versions of 11.x) differently than in versions prior to 10.2.4. As a result, while upgrading your system from a version prior to 10.2.4 to version 10.2.4 or later, the system will produce the Modified ASM Cookie violation for existing browser sessions. If the security policy has the Modified ASM Cookie violation enabled and set to block traffic when this violation occurs, after upgrading to version 10.2.4 or later, the system will block traffic to the web application. However, since the TS cookie is a session cookie, the system will block traffic only until the browser session ends (the end-user restarts the browser). To prevent the security policy from blocking traffic until the end-user’s browser is restarted, before upgrading to version 10.2.4 or later, we recommend you disable the security policy from blocking the Modified ASM Cookie violation, upgrade, and wait long enough to allow all users to restart their browsers (two weeks are expected to be enough). After enabling the violation, we recommend you monitor the logs. If the Modified ASM Cookie violation appears, consider disabling the violation again for a longer period of time, or communicate to the users to restart their browsers.

We're still getting the same 9000+ Modified ASM Cookie alerts after months of running 11.2.1 HF3.

I recommend to open a support case, if you have this problems after months.

 

I don't use this feature, so I cannot say anything about that. I only did post the release notes, because it say that it can happen for a while (days not months).

 

In V11, ASM functionality improved to accommodate Domain Cookies coming from the back end system and now the TS cookie also contains the domain attribute. You are going to see the Domain Cookies traverse to other Apps and ASMs that have the same domain. In order to minimize the modified cookie warnings, you should ensure your digests match across the systems.

 

http://support.f5.com/kb/en-us/solutions/public/6000/900/sol6990.html?sr=31564793