Forum Discussion

Arthur_7109's avatar
Arthur_7109
Icon for Nimbostratus rankNimbostratus
Jul 06, 2011

The BIG-IP ASM attack signature engine has a limited maximum recursion depth

Hi guys,

 

 

According to sol12250

 

"

 

This behavior limits the amount of resources that can be dedicated to any one evaluation operation. Certain combinations of attack signatures and request payloads may result in a long recursive evaluation that reaches the maximum depth before determining if the attack signature matches. In such cases, the request is marked as a match for the signature because the BIG-IP ASM system has not yet determined that the request is not a match. While this design may result in false positive violations, it ensures that unverified requests are not passed through the attack signature engine.

 

F5 Product Development is tracking an enhancement request to make the recursion depth a user configurable option as ID 242268 (formerly CR133384) and ID 224531 (formerly CR136691)."

 

"

 

 

We are seeing this quite often and we had to disable lots of signatures because of it, and we're not very happy with that "solution", so we'd like to know if anyone is using this new "tuning the regex recursion depth" feature?

 

 

Any suggestions about configuring the depth value? Does it significantly increase the CPU usage?

 

 

Thanks,

 

 

Arthur

 

 

app sec
BIG-IP Access Policy Manager (APM)
security
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jul 06, 2011
    Hi Arthur,

     

     

    I think ID 224531 maybe have been fixed in 10.2.0HF2. You could open a case with F5 Support to get more details on this.

     

     

    Aaron
  • brad_11480's avatar
    brad_11480
    Icon for Nimbostratus rankNimbostratus
    Sep 07, 2011
    so wondering if 10.2.1HF3 (10.2.1 build 511.0) could be missing this fix. we are running into a lot of these when we enabled SQL injection signatures and finding that the requests aren't very complicated at all.

     

     

    hate to have to turn off signatures just to make this work. defeats the purpose and the reason of having the ASM.
  • Arthur_7109's avatar
    Arthur_7109
    Icon for Nimbostratus rankNimbostratus
    Oct 06, 2011
    Hello again,

     

     

    I have a few (more) questions about the ASM attack signature recursion limit.

     

     

    According to Sol12250, "The BIG-IP ASM attack signature engine has a limited maximum recursion depth", so if the limit is reached, the signature fires, even though there would *not* have been a match if the regex matching would not have been interrupted.

     

     

    This "feature" is causing *lots* of false positives on the ASM here :-(

     

     

    According to Sol12884: Change in Behavior: Configuring BIG-IP ASM maximum recursion depth, there is a new parameter "pcre_match_limit" which can be changed.

     

     

    The default value is 5000 and my first question is: what exactly is the meaning of that param?

     

     

    In the PCRE world, there seem to be two related params: "pcre.backtrack_limit" and "pcre.recursion_limit" and both have a default value of 100000 (see http://php.net/manual/en/pcre.configuration.php). And ... "pcre.backtrack_limit defaults to 100k. This is rather conservative.".

     

     

    If this is the same parameter, then the ASM default value looks very low.

     

     

    And we might be able to significantly reduce the number of false positives by increasing it's value.

     

     

    Which raises some more questions: what is a "good" value for pcre_match_limit? And how will this impact CPU and/or latency? Any memory considerations as well?

     

     

    Currently on our production WAFs, the dashboard shows the Busiest CPU at 14%, and Memory Usage at 42%.

     

     

    System CPU Usage has "peaks" now and then of less than 20%.

     

     

    The ASM Security Enforcer CPU Utilization is about 2 percent. Some time ago I found out where this data is stored and the query

     

     

    select from_unixtime(cpu_reading_time), cpu_reading from ENFORCER_CPU_USAGE where cpu_reading > 4;

     

     

    lists the times that the enforcer CPU was above 4% - this is very seldom, and the maximum ever was 10%.

     

     

    So it looks like we have some CPU cycles available to improve the attack signature handling.

     

     

    On one application we had to disable more than 100 attack signatures due to this "feature", so we'd really like to better understand how it works and how to improve it.

     

     

    (And I agree with Brad that "... hate to have to turn off signatures just to make this work. defeats the purpose and the reason of having the ASM.)

     

     

    What would be really nice is a tech note or best practices document from F5 describing how the regex matching works, the role of the "pcre_match_limit" parameter, and some guidelines on tuning that param, taking into consideration possible CPU, memory, and latency issues.

     

     

    Arthur