Forum Discussion

Stevenson_88156's avatar
Stevenson_88156
Icon for Nimbostratus rankNimbostratus
Jan 29, 2013

ASM Attack Signatures

Hi

 

 

We are currently using F5 ASM for one of our custom developed application and we are running into an issue as F5 ASM seems to be blocking some parameters. After some investigation, we found out that the issue was cause by "max recursion depth" happening when F5 ASM is doing validation on Parameter Attack Signatures. The reason this is happening is because in our application, we are using JSF RichFaces framework and it creates a parameter called 'originalFormSavedValues' which contains string values of the previous state of the web form and depending on the page, it can contain a very long string.

 

 

This then causes F5 ASM to produce 'max recursion depth' and when we spoke to F5 support mentioned that the only way to fix this is to change the limit of the whole device as documented in this link.

 

http://support.f5.com/kb/en-us/solutions/public/12000/800/sol12884.html?sr=26953709

 

However, we would need to re-test this to ensure it doesn't causes any additional negative impact to our devices.

 

 

The other alternative suggested is that we remove attack signature checking on the this parameter that is causing the issue. However, this means that the parameter is no longer being validated by F5. Are there better alternative solution to this?

 

 

I have also spoke to people who also run into this issues particularly with ASP.NET or SharePoint applications where in the '__VIEWSTATE' parameter is also causing "max recursion depth" and they had just removed attack signature on the parameter. Is there a better way to resolve this?

 

 

Is there may be a minimum suggested attack signatures that can be applied to this type of parameters that doesn't cause any issues? Thanks.

 

APM
app sec
security

3 Replies

Sort By
  • Mike_Maher's avatar
    Mike_Maher
    Icon for Nimbostratus rankNimbostratus
    Jan 29, 2013
    So Attack Signatures are the negative security that is built into ASM, the big power of ASM is in the policy design. So how much protection you will receive is based upon how well the rest of your policy is designed. Are you doing input validation of the parameters and restricting what type of input and/or meta-characters are allowed to be used within the parameter. If so then you should still have a good deal of protection because you are only allowing what is necessary. You are obviously losing some protection because if there is a known attack pattern that can be passed using characters or other input you have to allow for the application then yes it would get through. However using solid input validation both at the ASM and with in the application should give most of the protection you need.
  • Ido_Breger_3805's avatar
    Ido_Breger_3805
    Historic F5 Account
    Jan 29, 2013
    If you will upgrade to 11.2 you won't see these max recursion limit any more as this issue was improved.
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    Jan 30, 2013
    Just to add to Ido, here's the info from the release notes as fixes introduced in 11.2.0 

    ID 339666, 339679, 340111, 341745, 341747, 341750, 341752, 351041Attack signatures with the following identification numbers no longer reach the maximum recursion limit: 200001140, 200002147, 200002149, 200002171, 200002190, 200002302, 200002430, 200002298, 200002299, 200002358, and 200002429. In the previous release, under certain circumstances, when the system matched traffic against these attack signatures, the system logged false positives when the maximum number of allowed recursions was exceeded.

    Rgds

    N