Blocking known attacks

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

• Cross-site scripting (XSS)
• SQL injection and many other code injection styles
• Remote file inclusion (RFI)
• Local file inclusion (LFI)
• OS commands
• Trojans/viruses
• Exploits
• Sensitive server information disclosure
• Personally identifiable information leaks

To defend against known attacks, FortiWeb scans:

• Parameters in the URL of HTTP GET requests
• Parameters in the body of HTTP POST requests
• XML in the body of HTTP POST requests (if Enable XML Protocol Detection is enabled. See To configure an inline protection profile.)
• Cookies
• Headers
• JSON Protocol Detection
• Uploaded filename(MULTIPART_FORM_DATA_FILENAME)

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 details, see Enable AMF3 Protocol Detection and Configuring a protection profile for inline topologies (for inline protection profiles) or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation (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; for details, 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.

Using the wizard to create a signature policy

Optionally, use the signature wizard to create a policy. In policies generated by the wizard, any signatures that are not relevant to your environment are disabled; this improves performance and reduces the number of false positives. If necessary, you can perform additional configurations for the set of signatures the wizard generates.

1. Go to Web Protection > Known Attacks > Signatures and select the Signature Wizard tab.

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.

2. The wizard prompts you to configure the following settings according to your environment:

• Database
• Web Server
• Web Application
• Script Language

Name the signature policy. You will use the name to refer to the policy in other parts of the configuration. The maximum length is 63 characters.

Click Create.

To configure a signature rule

1. Before you create a signature rule, create custom signatures, if any, that you will add to the rule. For details, see Defining custom data leak & attack signatures.
2. If you require protection for Oracle padding attacks, configure a rule for it. For details, 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:
   • To restrict the signature categories to ones that are relevant to the specific databases and web servers in your environment, click Signature Wizard. Then, follow the prompts to generate a custom signature policy. In the list of policies, to view and further configure the custom policy, double-click the name you specified .
   • To configure a signature rule using all available signatures, click Create New.
   Configure these settings for signatures in policies:

   Name	Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
   Custom Signature Group	Select a custom signature group to use, if any. For details, see False Positive Mitigation for SQL Injection 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.　For details, seeFalse Positive Mitigation for SQL Injection signatures. 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").
   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: 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. For details, see Customizing error and authentication pages (replacement messages). Deny (no log)—Block the request (or reset the connection). 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. For details, 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. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers. 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. For details, see Customizing error and authentication pages (replacement messages). 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. For details, see Logging and Alert email. Note: For HTTP packet, FortiWeb can take actions as specified, but for websocket packet, only the alert, period block, and deny actions can be executed if signature violations are detected. Other actions will be translated as shown below: Available Actions HTTP WebSocket Alert Alert Alert & Deny Alert & Deny Erase & Alert Alert Erase, no Alert None Redirect Alert Send HTTP Response Alert Deny(no log) Deny(no log) Block Period Block Period Client ID Block Period Client ID Block Period
   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 the Action is set to Period Block. The valid range is from 1 to 3,600 seconds (1 hour). 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: Informative 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. For details, see Viewing log messages.
   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 configure 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 will do 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 prevent malware attacks and prevent accessing Webshell located on server. Attack log messages contain Trojans and the subtype and signature (for example, Trojans: Signature ID 070000001) when this feature detects malware or Webshell. Attackers may attempt to upload Trojan horse code (written in scripting languages such as PHP and ASP) to the back-end web servers. The Trojan then infects clients who access an infected web page.
   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 website 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.
   Personally Identifiable Information	Enable to detect personally identifiable information in the response from the server. Also configure Detection Threshold below. 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 personally identifiable information from unnecessary exposure and disclosure. It would not trigger the detection feature. However, if a web application does not obscure displays of credit card numbers or other personally identifiable information, or if an attacker has found a way to bypass the application’s protection mechanisms and gain a list of customers’ information, a web page might contain a list with many credit card numbers and other information in clear text. Such a web page would be considered a data leak, and trigger personally identifiable information disclosure detection. In the Action column, select what FortiWeb does when it detects this type of attack.
   Detection Threshold	Enter a threshold if the web page must contain a number of instances of personally identifiable information that equals or exceeds the threshold in order to trigger the detection feature. For example, to ignore web pages with only one instance of personally identifiable information, but to detect when a web page containing two or more instances, enter 2. The valid range is 1-128.

5. Click OK.
6. If you enabled Information Disclosure or Personally Identifiable Information, configure a decompression rule. For details, see Compression.

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. For details, 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 (http://www.eicar.org/85-0-Download.html) file. Alternatively, test your configuration in a non-production environment.

If detection fails:

• Verify that routing and TCP/IP-layer firewalling does not prevent connectivity.
• Verify that your simulated attack operates on either the HTTP header or HTTP body, whichever component is analyzed by that feature.
• If the feature operates on the HTTP body, verify that http-cachesize is large enough, or that you have configured to Body Length block requests that exceed the buffer limit. For details, see FortiWeb CLI Reference.

• If the HTTP body is compressed, verify that Maximum Antivirus Buffer Size is large enough, or that you have configured to Body Length block requests that exceed the buffer limit.
• If you enabled Trojans, verify that you have also configured its configuration dependencies. For details, see Limiting file uploads.
• If the feature operates on the parameters in the URL line in the HTTP headers, verify that the total parameter length. After URL decoding, if required, configure Recursive URL Decoding is not larger than the buffer size of Total URL Parameters Length or Total URL Parameters Length.

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. For details, see Configuring action overrides or exceptions to data leak & attack detection signatures.

See also

• Filtering signatures
• Configuring action overrides or exceptions to data leak & attack detection signatures
• Sequence of scans
• Protocol constraints
• Limiting file uploads
• How often does Fortinet provide FortiGuard updates for FortiWeb?
• IPv6 support