Forum Discussion

JG's avatar
JG
Icon for Cumulonimbus rankCumulonimbus
Nov 26, 2018

ASM: "Illegal Request"

I have come across a weird problem. A user access was blocked, with a support ID displayed. After searching the event log withe the support ID, I found that there was no learning suggestion for the access request, and I could not "accept" the request: the text shown when having the mouse over the grayed-out button of "Accept" was "there was no violation".

 

I had to configure "never block this IP address" to allow the request through. And the log entry showed that this was an "illegal" request.

 

Is there a way to allow an "illegal" request through in this situation? The IP address based solution is only temporary as the user was on a dynamic address.

 

3 Replies

  • That’s weird. It should show the violation it caused. BTW,

    illegal request is like it’s Flagged and but not Blocked
    . Best solution here would be to recreate the issue and look up the event logs for the violation it caused. Like illegal uri, illegal param, cookie hijack, session hijack, etc. so we need to know to the violation to poke the hole in ASM policy.

  • ASM will not generate learning suggestions for some violations, probably that is why there was no learning suggestion to accept, see support article K14945:

     

    https://support.f5.com/csp/article/K14945

     

    • Cookie not RFC-compliant
    • Illegal HTTP format
    • Non-RFC request
    • Evasion Technique Detected
    • Access Violations
    • Illegal HTTP status in response
    • Illegal session ID in URL
    • Login object expired
    • Login object bypassed
    • Request length exceeds defined buffer size
    • Input Violations
    • Failed to convert character
    • Forbidden Null in request
    • Illegal number of mandatory parameters
    • Null in multi-part parameter value
    • SOAP method not allowed
    • Cookie Violations
    • Expired timestamp
    • Modified ASM cookie
    • Wrong message key
  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    Thanks to all who have responded and offered help.

    I opened a support case and the following fix was suggested to me:

    The escalation engineer found that there were some issues with the databases involved in the tracking and reporting of requests and violations.
    
    Unfortunately, there is no easy way to repair the existing DB entries to get historic reports fixed, but we could try to fix it for future requests by restarting the "asmlogd" service using the command below:
    
         pgrep asmlogd | xargs kill -9
    
    (this command will kill the process and it will be restarted automatically)
    
    This should not cause interruptions to your production traffic, but please still consider doing it during a maintenance window.
    

    I implemented this fix and after observing the system for a significant period of time, I am now satisfied that this has solved the problem.