Forum Discussion

Scott123456789's avatar
Jan 11, 2021
Solved

ASM flagging legitimate traffic as "most likely a threat"

I'm fairly new to managing ASM and I'm learning on the fly. In this case, the protected application is a Jira instance. Most traffic that ASM has blocked for this application so far has been a single signature (For example, "Illedgal method" or "attack signature detected"). These blocks have a violation rating of 1 or 3. Today, a user tried to upload an attachment into Jira and ASM blocked it with a violation rating of 5. There is no button for me to "accept request" on this block. The number of signatures found for these blocks seems to vary depending on the type of file being uploaded (xlsx, docx, pdf) and varies between 85 and 242 signatures flagged.

 

I'm not sure what to do with this. How would you go about working through this? I hate to leave my question so open ended, but I just am not sure what to do with it.

  • 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

20 Replies

  • 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

  • Attack signatures and file types are two different things. Let's try to pinpoint the cause of the block. For the file upload into Jira, what was the violation that actually caused the blocking event? If it was "illegal file type" then you can add specific types of files, including .xlsx, .docx, and .pdf to the Allowed File Types list. That will prevent blocking.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      Thank you for the response. There are multiple violation types for a single event. The violation types are "Evasion technique detected", Failed to convert character" and "HTTP protocol compliance failed". The attack types listed are Detection Evasion, Abuse of Functionality, Cross Site Scripting (XSS), HTTP Parser Attack and Injection Attempt.

       

      No mention of illegal file type.

  • Are you able to discern which violation resulted in the blocking event? Check if your attack signatures are in staging--if they are, staged signatures can be ruled out in terms of causing the block.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      Maybe that's what I don't know how to do. Every other block I've dealt with up until now has been just one violation type, and only one occurrence of it. In this case, I have the three violation types and hundreds of occurrences in the same event. I have no idea how to proceed from there. Sorry to sound like its my first day...

  • No worries. Can you go to Security >> Event Logs : Application : Requests and see if there are any entries? If you are logging illegal requests only (the default) you should see at least one blocked request--it's a red icon that is really obvious. You can select that offending request and figure out exactly why it was blocked.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      yeah, that's where I go. The image I posted above is part of the blocked event.

  • Do you see the link to "Suggestions" to the right of each of those violations? If you click that link you will go to the Traffic Learning page which gives you some additional options not visible on the request log page. You can also get there by going to Security >> Application Security : Policy Building : Traffic Learning....

     

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      These settings are not in staging. I do not see a "Suggestions" section in the blocked event.

  • OK, let's back up for a second. Are there any entries on the Traffic Learning page? If not, it's because the "Learn" checkbox is not selected (for each violation) on the learning and blocking settings page. Try clearing the request log and recreating the event which caused the block. Most likely, the event that is causing it is a false positive violation--legit traffic that is getting blocked. It's unlikely that 144 evasion techniques and 161 instances of character conversion failures are real attacks all coming from the same request.

     

    The three violation types you show don't immediately seem related to file upload, so let's focus on those first. Worst case, you can uncheck the "block" checkbox for each one (Security >> Application Security : Policy Building : Learning and Blocking Settings) which will allow traffic to pass until you nail down the cause.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      There are two entries in the traffic learning page but they are not the same violation (they are both sql injection violations). I do have learn checked for all the ones I have block checked, so I just must not have checked the learning when the users did this in the past.

       

      I went ahead and turned the blocking off for those three violation types and asked the user to recreate the situation. I'll let you know how that goes.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      I went into the policy learning and blocking settings, opened the blocking settings to the right of "Policy Building Settings", unchecked the block box for the three violation types. I left Learn and Alarm checked next to the three violation types. Saved the settings, saved the policy, applied the policy. User still gets blocked and nothing shows up under learning.

  • Can you post a screenshot of the blocked request? My guess is that it's not because of attack signatures--because you turned off the block flag (checkbox) and the signatures are most likely in staging unless you enforced them previously.

  • Directly below that section, can you view the decoded request? Is this the result of a request you know is legal?

  • @A few things to verify:

     

    1. 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.
    2. With regard to decoding, verify that the application language for the policy is the same as used by the application.
    3. 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.

    • Scott123456789's avatar
      Scott123456789
      Icon for Cirrus rankCirrus

      If 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.

  • It should work. But that example sure looks like it isn't being decoded. You could try restarting the ASM daemon if it's permissible, but I would recommend getting support before doing that.