Reducing false positives
Focusing your energies on real attacks is vital. But often attacks differ from normal traffic in subtle ways that can cause confusion. How many of your attack logs are real, and how many are false positives?
Are 20 requests per second per client a DoS attack? Is a request URL with 250 characters abnormally long? Should form inputs allow SQL queries?
Normal traffic is your best judge. Use it to adjust your FortiWeb’s protection settings and reduce attack logs that aren’t meaningful.
For example, social media buttons for Twitter append an encoded version of your web page’s URL as long parameters named
url after the request URL to twitter.com.
This is normal, and used by Twitter to pre-fill the viewer’s tweet about your website. This way, your readers do not need to manually abbreviate and then paste your URL into their tweet. Long request URLs (and parameters) are therefore typical for Twitter, and therefore would not necessarily be indicative of a security bypass attempt.
On other web applications, however, where URLs and parameters are short, URLs as long parameters might be suspicious—it could be part of a clickjacking, URL-encoded shell code, or padded exploit. In those cases, you might create a shorter HTTP constraint. For details, see HTTP/HTTPS protocol constraints.
This means that “normal” is often relative to your web applications.
For SQL Injection detection, you can also enable False Positive Mitigation to reduce false positives. For details, see False Positive Mitigation for SQL Injection signatures.
If a signature causes false positives, but disabling it would allow attacks, you can use packet capture and analysis tools such as Wireshark to analyze the differences between your typical traffic and attacks, then craft a custom signature (see Defining custom data leak & attack signatures) targeting the attacks but excluding your normal traffic.
If you need to save time, or don’t feel comfortable doing this, you can contact Fortinet Technical Support for professional services at:
If you have written an attack signature yourself, or used regular expressions to define large sets of web pages where you will be applying rate limiting, be sure to use the >> (test) button with Request URL and other similar settings to check:
- your regular expression’s syntax (see Regular expression syntax)
- all expected matches
- all non-matches
Regular expressions that do not match enough attack permutations cause false negatives; regular expressions that match unintended traffic cause false positives.