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 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, 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 SQL Injection detection, you can also enable False Positive Mitigation to reduce false positives (see False Positive Mitigation for SQL Injection signatures).
|
For recommended initial rate limit thresholds, see the documentation for each setting. |
|
|
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. |
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:
Regular expressions that do not match enough attack permutations cause false negatives; regular expressions that match unintended traffic cause false positives.