Hi Aresh,

It is ok to skip the rules if you are sure about the false positive. You can create a support case later to verify it.

Thanks,

Hi,

The only way that I think is false positive is that I can see the IP address of my own connection triggering the ID.

But skip the rules will leave the website open to attacks that those rules should stop them.

What would the support do in such cases?

Thanks

Hi,

The only way that I think is false positive is that I can see the IP address of my own connection triggering the ID.

But skip the rules will leave the website open to attacks that those rules should stop them.

What would the support do in such cases?

Thanks

Is your IP address static? Then you can create an exception, select "Web clients coming from these source networks" and configure your IP address.

Also: Please don't skip infrastructure rules to fix false positives. Find the non-infrastructure rules in reverseproxy.log that are actually causing the false positives and skip those instead. Read more about it in this knowledge base article.

thanks for reply

I agree with you on not skip those rules.

I cannot create exception be cause costumer excpect to access the website from any location.

UTM WAF has been a great disappointment.   I have never been able to use form hardening or cookie hardening.  Every attempt has failed with signature failures.

I have only rarely been able to use Rigid Filtering, and when it is enabled, the list of exclusions is long. There is no way to know when a test site has been sufficiently tested to lnow if all false positives have been identified and all problem rules disabled.   Once put into production, there is no way to tell if an alarm is a false positive or not.

Support has no additional tools for helping in these situations.  The referenced KB article is the extent of their information or abilities.

If someone has a good strategy, I would love to learn from you.