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 original_referer and 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.

Likewise, a single corporate front page or Zenphoto gallery page might involve 81 requests for images, JavaScripts, CSS pages, and other external components. A search page, however, might normally only have 6 requests, and merit a lower threshold when configuring rate limiting. For details, see DoS protection.

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: http://www.fortinet.com/support/forticare_support/professional_svcs.html

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.