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

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