Blocking known attacks & data leaks

Select a custom signature group to use, if any. For details, see Defining custom data leak & attack signatures.

Attack log messages contain Custom Signature Detection and the name of the individual signature when this feature detects an attack.

To view and/or edit the custom signature set, click the Detail link. The Edit Custom Signature Group dialog appears.

For signatures that FortiWeb uses to scan for SQL injection attacks, click to enable or disable additional SQL syntax validation. When this option is enabled and the validation is successful, FortiWeb takes the specified action. If it fails, FortiWeb takes no action.　See False Positive Mitigation for SQL Injection signatures for details.

Attack log messages generated by signatures that support this feature have a False Positive Mitigation field. The value indicates whether FortiWeb identified the attack using the signature and additional SQL syntax validation ("Yes") or the just the signature ("No").

In each row, select the action that FortiWeb takes when it detects a violation of the rule. Supported options vary (available options are listed in the description for each specific rule), but may include:

• Alert — Accept the request and generate an alert email and/or log message.

• Alert & Deny — Block the request (or reset the connection) and generate an alert email and/or log message.
  

  You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

• Period Block — Block subsequent requests from the client for a number of seconds. Also configure Block Period.
  

  You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

  Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP (see Defining your proxies, clients, & X-headers). Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type.

• Redirect — Redirect the request to the URL that you specify in the protection profile and generate an alert email and/or log message. Also configure Redirect URL and Redirect URL With Reason.

• Send HTTP Response — Block and reply to the client with an HTTP error message and generate an alert email and/or log message.
  
  You can customize the attack block page and HTTP error code that FortiWeb returns to the client. See Customizing error and authentication pages (replacement messages).
• Pass — Allow the request. Do not generate an alert email and/or log message.
• Continue — Generate an alert and/or log message, then continue by evaluating any subsequent rules defined in the web protection profile (see Sequence of scans). If no other rules are violated, allow the request. If multiple rules are violated, a single request will generate multiple attack log messages and/or alert email.
• Alert & Erase — Hide sensitive information in replies from the web server (sometimes called “cloaking”). Block the request or remove the sensitive information, and generate an alert email and/or log message.
  Caution: This option is not fully supported in offline protection mode. Only an alert and/or log message can be generated; sensitive information cannot be blocked or erased.

• Erase, no Alert — Hide sensitive information in replies from the web server (sometimes called “cloaking”). Block the request or remove the sensitive information, but do not generate an alert email and/or log message.
  

  Caution: This option is not supported in offline protection mode.

The default value is Alert. See also Reducing false positives.

Caution: This setting will be ignored if Monitor Mode is enabled.

Note: Logging and/or alert email will occur only if enabled and configured. See Logging and Alert email.

Note: If you will use this rule set with auto-learning, you should select Alert. If Action is Alert & Deny, or any other option that causes the FortiWeb appliance to terminate or modify the request or reply when it detects an attack attempt, the interruption will cause incomplete session information for auto-learning.

In each row, type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule.

This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 (1 hour). The default value is 1. See also Monitoring currently blocked IPs.

When rule violations are recorded in the attack log, each log message contains a Severity Level (severity_level) field. In each row, select which severity level the FortiWeb appliance will use when it logs a violation of the rule:

• Low
• Medium
• High

The default value is High.

Enable to prevent a variety of cross-site scripting (XSS) attacks, such as some varieties of CSRF (cross-site request forgery).

All of this attack’s signatures are automatically enabled when you enable detection. To disable a specific signature, click the blue arrow to expand the list, then clear that signature’s check box.

Attack log messages contain Cross Site Scripting and the subtype and signature ID (for example, Cross Site Scripting : Signature ID 010000063) when this feature detects a possible attack.

In the Action column, select what FortiWeb does when it detects this type of attack.

Enable to prevent a variety of XSS attacks.

Unlike Cross Site Scripting, the extended signatures are more likely to cause false positives. However, they may be necessary in specific, high-security data centers. If one of the signatures is causing false positives and you need to instead configure a custom attack signature that will not cause false positives, you can individually disable that signature.

Enable to prevent SQL injection attacks, such as blind SQL injection.

All of this attack’s signatures are automatically enabled when you enable detection. To disable a specific signature, click the blue arrow to expand the list, then clear that signature’s check box.

Attack log messages contain SQL Injection and the subtype and signature ID (for example, SQL Injection : Signature ID 030000010) when this feature detects a possible attack.

Also enable or disable False Positive Mitigation.

In the Action column, select what FortiWeb does when it detects this type of attack.

Enable to prevent a variety of SQL injection attacks.

Unlike SQL Injection, the extended signatures are more likely to cause false positives. However, they may be necessary in specific, high-security data centers. If one of the signatures is causing false positives and you need to instead configure a custom attack signature that will not cause false positives, you can individually disable that signature.

Enable to prevent a variety of SQL injection attacks.

The syntax based signatures use Lexical analysis with a SQL parser, SQL templates, and Abstract Syntax Trees to verify whether requests are true SQL Injection attacks. This virtually eliminates SQL Injection false positives and false negatives.

According to possible injection points, Syntax Based Detection is further classified into detections of double-quote-based injection, single-quote-based injection and as-is-based injection. Note that the signature for SQL function based boolean injection is ONLY available in As-Is category since it cannot be an independent injection in other types.

See Syntax-based SQL Injection Detection for details.

Enable to prevent other common exploits, including a variety of injection threats that do not use SQL, such as local file inclusion (LFI) and remote file inclusion (RFI).

All of this attack’s signatures are automatically enabled when you enable detection. To disable a specific signature, click the blue arrow to expand the list, then clear that signature’s check box.

Attack log messages contain Generic Attacks and the subtype and signature ID (for example, Generic Attacks-Command Injection : Signature ID 050050030) when this feature detects a possible attack.

In the Action column, select what FortiWeb does when it detects this type of attack.

Enable to prevent a variety of exploits and attacks.

Unlike Generic Attacks, the extended signatures are more likely to cause false positives. However, they may be necessary in specific, high-security data centers. If one of the signatures is causing false positives and you need to instead configure a custom attack signature that will not cause false positives, you can individually disable that signature.

Enable to scan for trojans, viruses, malware, and greyware. You must also configure a file upload restriction where you enable Antivirus Scan (see Limiting file uploads).

Attack log messages contain the file name and signature ID (for example, filename [eicar.com] virus name [EICAR_TEST_FILE]: Waf anti-virus) when this feature detects a possible virus.

In the Action column, select what FortiWeb does when it detects this type of attack.

To configure which database of signatures to use, select either Regular Virus Database or Extended Virus Database (see Choosing the virus signature database & decompression buffer).

Caution: Files greater than the scan buffer configured in Maximum Antivirus Buffer Size are too large for FortiWeb to decompress, and will pass through without being scanned. This could allow malware to reach your web severs. To block oversized files, you must configure Body Length.

Caution: To remain effective as new malware emerges, it is vital that your FortiWeb can connect to FortiGuard services to regularly update its engine and signatures. Failure to do so will cause this feature to become less effective over time, and may allow viruses to pass through your FortiWeb. For instructions on how to verify connectivity and enable automatic updates, see Connecting to FortiGuard services.

Enable to detect server error messages and other sensitive messages in the HTTP headers, such as CF Information Leakage (Adobe ColdFusion server information).

All of this attack’s signatures are automatically enabled when you enable detection. However, if one of the signatures is causing false positives and you need to instead configure a custom attack signature that will not cause false positives, you can individually disable that signature. To disable a specific signature, click the blue arrow to expand the list, then clear that signature’s check box.

Error messages, HTTP headers such as Server: Microsoft‑IIS/6.0, and other messages could inform attackers of the vendor, product, and version numbers of software running on your web servers, thereby advertising their specific vulnerabilities.

Sensitive information is detected according to fixed signatures.

Attack log messages contain Information Disclosure and the subtype and signature (for example, Information Disclosure-HTTP Header Leakage : Signature ID 080200001) when this feature detects a possible leak.

In the Action column, select what FortiWeb does when it detects this type of attack:

• Alert

  Note: Does not cloak, except for removing sensitive headers. (Sensitive information in the body remains unaltered.)

• Alert & Erase — Hide replies with sensitive information (sometimes called “cloaking”). Block the reply (or reset the connection) or remove the sensitive information, and generate an alert email and/or log message.
  

  If the sensitive information is a status code, you can customize the web page that will be returned to the client with the HTTP status code.

  Note: This option is not fully supported in offline protection mode. Effects will be identical to Alert; sensitive information will not be blocked or erased.

• Period Block
• Redirect

Tip: Some attackers use 4XX and 5XX HTTP response codes for web site reconnaissance when identifying potential targets: to determine whether a page exists, has login failures, is Not Implemented, Service Unavailable, etc. Normally, the FortiWeb appliance records attack logs for 4XX and 5XX response codes, but HTTP response codes are also commonly innocent, and too many HTTP response code detections may make it more difficult to notice other information disclosure logs. To disable response code violations, disable both the HTTP Return Code 4XX and HTTP Return Code 5XX options in this rule’s area.

Tip: Because this feature can potentially require the FortiWeb appliance to rewrite the header and body of every request from a server, it can decrease performance. To minimize impact, Fortinet recommends enabling this feature only to help you identify information disclosure through logging, and until you can reconfigure the server to omit such sensitive information.

Enable to analyze the User-Agent: HTTP header and block known content scrapers, spiders looking for vulnerabilities, and other typically unwanted automated clients.

FortiWeb predefined signatures for many well-known robots, such as link checkers, search engine indexers, spiders, and web crawlers for Google, Baidu, and Bing, which you can use to restrict access by Internet robots such as web crawlers, as well as malicious automated tools.

Search engines, link checkers, retrievals of entire web sites for a user’s offline use, and other automated uses of the web (sometimes called robots, spiders, web crawlers, or automated user agents) often access web sites at a more rapid rate than human users. However, it would be unusual for them to request the same URL within that time frame.

Usually, web crawlers request many different URLs in rapid sequence. For example, while indexing a web site, a search engine’s web crawler may rapidly request the web site’s most popular URLs. If the URLs are web pages, it may also follow the hyperlinks by requesting all URLs mentioned in those pages. In this way, the behavior of web crawlers differs from a typical brute force login attack, which focuses repeatedly on one URL.

Some robots, however, are not well-behaved. You can request that robots not index and/or follow links, and disallow their access to specific URLs (see http://www.robotstxt.org/). However, misbehaving robots frequently ignore the request, and there is no single standard way to rate-limit robots.

To verify that bad robot detection is being applied, attempt to download a web page using wget, which is sometimes used for content scraping.

Enable to detect credit card numbers in the response from the server. Also configure Credit Card Detection Threshold.

Credit card numbers being sent from the server to the client, especially on an unencrypted connection, constitute a violation of PCI DSS. In most cases, the client should only receive mostly-obscured versions of their credit card number, if they require it to confirm which card was used. This prevents bystanders from viewing the number, but also reduces the number of times that the actual credit card number could be observed by network attackers. For example, a web page might confirm a transaction by displaying a credit card number as:

XXXX XXXX XXXX 1234

This mostly-obscured version protects the credit card number from unnecessary exposure and disclosure. It would not trigger the credit card number detection feature.

However, if a web application does not obscure displays of credit card numbers, or if an attacker has found a way to bypass the application’s protection mechanisms and gain a list of customers’ credit card numbers, a web page might contain a list with many credit card numbers in clear text. Such a web page would be considered a data leak, and trigger credit card number disclosure detection.

Attack log messages contain Credit Card Detection and the subtype and signature (for example, Credit Card Detection : Signature ID 100000001) when this feature detects a credit card disclosure.

In the Action column, select what FortiWeb does when it detects this type of attack.

Type 0 to report any credit card number disclosures, or enter a threshold if the web page must contain a number of credit cards that equals or exceeds the threshold in order to trigger the credit card number detection feature.

For example, to ignore web pages with only one credit card number, but to detect when a web page containing two or more credit cards, enter 2.