Turn off Specific ASM Signatures for a Cookie
Running 12.1.x and am trying to figure out how to turn off specific signatures from firing for values of a specific cookie. The cookie in question is placed by third party performance monitoring software and often times what is put in those cookies contains information about the URLs or other objects on the page, causing a variety of path traversal and XSS signatures to go off. This cookie can be placed under various circumstances for various URLs and gets sent on a variety of requests (form data, JSON, multi-part, etc) always with the same name. It does not appear on every request. I tried setting up the cookie name as a parameter and turning off the signatures that way but that of course doesn't work since its not really a posted or URL parameter. I'm not going to disable this wide swath of signatures for the entire site, so that's not an option. I saw previous DevCentral responses for 11.x stating that you could use Content Profiles. I set up a JSON profile and associated it with the * URL to be turned on when the cookie is present and confirmed that this will stop those signatures from firing. However this doesn't really work since the requests with that cookie can be any type of content in the post and I can't set a profile for normal post data, additionally this turns it off for all fields instead of just for the cookie. I'd also like to avoid using LTM policy to switch ASM policies based on the cookie presence and have to manage multiple policies for something seemingly this simple. Is there any official non-kludgy way of turning off specific ASM attack signatures for a specific cookie?ASM Signature Update 02/08/2019 Contains Incorrect Command Execution Signatures
The 2/8/19 signature update available on F5 Downloads (shows a create date of 1/22/19 in the F5 UI) has some questionable updates for Command Execution signatures on parameters that cause a large amount of false positives. Instead of properly checking to see if a parameter contains a real command execution attempt, it is just firing on anything containing a the string that matches the command name. It's so bad that the sig for g++ will go off every time there is a " g " in a parameter being posted. This has been confirmed on 12.1.X I would suggest skipping this update until they address. If installed, my suggestion would be to disable all signatures with the string "execution attempt" in the title that relates to parameters (likely leave URL and Header sigs active, not getting false positives on those but ymmv) and contain a command that resembles a human word or is 3 characters or less. If not too labor intensive it would likely be better to disable on a parameter basis. Even if you have these signatures in staging, you may not get all possible values in your staging traffic so the next time you get a user with the name of "Pico", they could be blocked. Because we are on 12.x we had been setup to not put update signatures into staging because we didn't want to loose coverage, after years of that working perfectly for us, this update came and basically locked out our applications. Working with support on this, will update.
Logging and identify the violations from staged signatures
I am trying to fix a signature update issue for ASM v12.1.0 here. Signatures are not updated from some time. I wanted to do this in a phase manner now. 1) Enabling signature staging for the policy, enable signature staging for updated/new signatures 2) Run a manual update 3) Get through the Enforcement Readiness period of 7 days 4) Check for any violations for staged signatures and enforce the new/updated signatures respectively. Regx point 4, will need some guidance on checking for any violation for staged signatures. We are sending logs to splunk and how do i identify from the log data, if the alert was on a staged signature. Pasting some log snippets below. 30/08/2018 11:07:54.000 Aug 30 11:07:54 xxxx.net.au ASM: f5_asm=Splunk-F5-ASM,attack_type="",date_time="2018-08-30 11:07:54",dest_ip=x.x.x.x,dest_port=xxxx,geo_info="US",http_class="/Common/VS_Test",ip_addr_intelli="N/A",ip_client=x.x.x.x,ip_route_domain="x.x.x.x%0",is_trunct=truncated,manage_ip_addr=x.x.x.x,method="POST",policy_apply_date="2018-05-31 10:08:09",policy_name="/Common/VS_Test",protocol="HTTP",query_str="",req_status="passed",resp_code="200",route_domain="0",session_id="4353fdsad4dd",severity="Informational",sig_ids="",sig_names="",src_port="27603",sub_violates="",support_id="17873574374868071705",unit_host="xxxxxxxxxxxxxxxx",uri="/abc/xyz",username="N/A",violate_details="44f3d1e143060702-000000000000000044f3d1e143060702-000000000000000044f3d1e143262702-0000000000000000000040c100240000-0000000000000000
F5 ASM attack signature detection
the asm is detecting an sql injection and you can see in the below image when I when to check the detail of the violation, we can see that its a color code that's being rejected. Do you think that's an error? How do you just allow that particular color code for that virtual server ? I am new to ASM, in the below image its showing http illegal response ie 500 code.but there is no option to learn it. The question is when we see a violation and violation on staged entities , is the connection getting rejected because of the http violation or the attack signature violation in the staged entity??
