Blocking known attacks & data leaks

Blocking known attacks & data leaks

Many attacks and data leaks can be detected by FortiWeb using signatures. Enable signatures to defend against many attacks in the OWASP Top 10, plus more:

FortiWeb scans:

In addition to scanning standard requests, FortiWeb can also scan XML And Action Message Format 3.0 (AMF3) serialized binary inputs used by Adobe Flash clients to communicate with server-side software. For more information, see Enable AMF3 Protocol Detection and Illegal XML Format (for inline protection profiles) or Enable AMF3 Protocol Detection (for offline protection profiles).

Updating signatures

Known attack signatures can be updated. For information on uploading a new set of attack definitions, see Uploading signature & geography-to-IP updates and Connecting to FortiGuard services. You can also create your own. See Defining custom data leak & attack signatures.

Signature configuration

You can configure each server protection rule with an action, severity, and notification settings (“trigger”) that determine how FortiWeb handles each violation.

For example, attacks categorized as cross-site scripting and SQL injection could have the action set to alert_deny, the severity set to High, and a trigger set to deliver an alert email each time FortiWeb detects these rule violations. However, you can disable specific signatures in those categories, set them to log/alert instead, or exempt requests to specific host names/URLs.

Alternatively, you can enable the threat scoring feature and configure one or more signature categories to contribute to a combined threat score. FortiWeb takes action only after the combined threat score exceeds a maximum value you specify. See Configuring threat scoring.

Using the wizard to create a signature policy

Optionally, to use the signature wizard to create a policy. To access the wizard, go to Web Protection > Known Attacks > Signatures, and then click Signature Wizard.

The wizard prompts you to select the database and web server types that apply to your environment and generates a corresponding policy. In policies generated by the wizard, any signatures that are not relevant to your environment are disabled, which improves performance and reduces the number of false positives. If necessary, you can perform additional configuration for the set of signatures the wizard generates.

To configure a signature rule

1.  Before you create a signature rule, create custom signatures, if any, that you will add to the rule (see Defining custom data leak & attack signatures).

2.  If you require protection for Oracle padding attacks, configure a rule for it (see Defeating cipher padding attacks on individually encrypted inputs).

3.  Go to Web Protection > Known Attacks > Signatures.

To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.

4.  Do one of the following:

You can configure the following settings for signatures in policies:

Setting name Description
Name Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
Threat Scoring Select to display the threat scoring settings and enable the feature.

The threat scoring feature allows you to configure your signature policy to trigger an action based on attack or leak detection by multiple signatures, instead of a single signature.

For more information, see Configuring threat scoring.
Custom Signature Group

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.

Status Click to enable or disable the signature rule for this policy.
False Positive Mitigation

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.

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").

Alternatively, you can use the following methods to disable this feature:

Action

(column)

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:

  • AlertAccept the request and generate an alert email and/or log message.
  • Alert & DenyBlock 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.

  • RedirectRedirect 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).
  • PassAllow 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.

Block Period

(column)

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.

Severity

(column)

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.

Trigger Action

(column)

In each row, select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of each rule. See Viewing log messages.
Threat Scoring Specifies whether violations of signatures in this category contribute to the combined threat score for the signature policy instead of triggering the specified action.

Available only when Threat Scoring is ON.
Cross Site Scripting

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.

Cross Site Scripting (Extended)

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.

SQL Injection

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.

SQL Injection (Extended)

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.

Generic Attacks

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.

Generic Attacks (Extended)

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.

Trojans

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.

Information Disclosure

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.

Bad Robot

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.

Credit Card Detection

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.

Credit Card Detection Threshold

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.

Threat Scoring Threshold Specify the maximum combined threat score to exceed before FortiWeb takes the specified action.

Available only when Threat Scoring is ON.

For more information, see Configuring threat scoring.
Threat Scoring Match Scope

Select how FortiWeb calculates the combined threat score before it compares it to Threat Scoring Threshold.

  • HTTP TransactionFortiWeb compares the score for each transaction to the threshold.
  • TCP SessionFortiWeb compares the score for each session to the threshold. The score can include multiple transactions.
  • HTTP SessionFortiWeb compares the score for sessions associated with a specific client to the threshold. This option requires you to enable Session Management in the appropriate protection profile.

Available only when Threat Scoring is ON.

5.  Click OK.

6.  If you enabled Information Disclosure, Trojans, or Credit Card Detection, configure a decompression rule. See Configuring temporary decompression for scanning & rewriting.

Failure to configure a decompression rule, or, for HTTPS requests, to provide the server’s x.509 certificate in either Certificate or Certificate File, will result in FortiWeb being unable to scan requests. This effectively disables those features.

7.  To apply the signature rule, select it in an inline protection profile or an offline protection profile (see Configuring a protection profile for inline topologies or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation).

8.  To verify your configuration, attempt a request that should be detected and/or blocked by your configuration.

Instead of actually executing the exploit or uploading a virus, attempt a harmless script with similar syntax, or upload an EICAR file. Alternatively, test your configuration in a non-production environment.

If detection fails:

9.  If normal input for some URLs accidentally matches a signature, either create and use a modified version of it instead via custom signatures, or create exceptions (Configuring action overrides or exceptions to data leak & attack detection signatures).

See also