Forum Discussion
CirrusASM flagging legitimate traffic as "most likely a threat"
According to F5 support, the problem was that ASM was trying to parse the attachment being uploaded. This is the job of anti-virus, not ASM. The solution was to create an allowed URL exception in the policy for this type of content.
This instructs ASM to not inspect the BODY of the request:
- Browse to: Security ›› Application Security : URLs : Allowed URLs : Allowed HTTP URLs
- make sure to 'select' the correct policy
- click 'Create' (for New Allowed URL)
- change view to 'Advanced'.
- Specify the URL (Explicit, [HTTPS] /rest/internal/2/AttachTemporaryFile)
- uncheck staging
- click on 'Header-Based Content Profile':
Request Header Name: Content-Type
Request Header Value: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Request body handling: Do nothing
click 'Add'.
move it up the list
- click 'Create'.
- Apply Policy
Employee@A few things to verify:
- This is an HTTPS request. Make sure you are decrypting the request at the virtual server before ASM processes it. Do you have a server-side SSL profile? The example above looks like it isn't being decoded correctly.
- With regard to decoding, verify that the application language for the policy is the same as used by the application.
- Try adding the URL to the Allowed URLS list. Then you can disable attack signatures and control methods on that specific URL.
In your first example, can you determine exactly what the HTTP RFC compliance violation was? Also, if this traffic is internal and/or trusted, you could try adding IP address exceptions to bypass ASM entirely.
Scott123456789If it was an SSL decryption issue, wouldn't I have more problems? On this same virtual server/ASM policy, I've had other blocks the last few weeks and been able to make exceptions easily. The button just isn't there now.
I'm still confused why unchecking the "block" check boxes didn't work for me.
