Reducing false positives
Focusing your energies on real attacks is vital. But often attacks differ from normal traffic in subtle ways.
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?
How many of your attack logs are real, and how many are false positives?
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 web site. 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, this 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 (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 (
“Rate limiting”).
This means that “normal” is often relative to your web applications.
If practical, use FortiWeb’s auto-learning to study traffic and suggest appropriate rules. Alternatively, you can enable a feature with the
Action set to
Alert, then adjust the thresholds, create exceptions, or disable signatures until you no longer receive many false positives, yet still detect attacks. Enable extended attack signature sets gradually, checking for excessive false positives after you enable each one. (Extended signature sets can contain signatures that are necessary in come cases, but are known sources of false positives.)
| For recommended initial rate limit thresholds, see the documentation for each setting. |
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:
• 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.