FortiWeb Cloud saves the attack logs for two months and the audit logs for three months. After that, they will be deleted.

Exceptions are added in Attack Logs. It can't be reversed once being added.

If you believe that the Anomaly Detection model is inaccurate with certain exceptions, you have the option to access the TreeView page of the Anomaly Detection module. From there, you can locate the parameter to which the exception is applied and rebuild the model specifically for that parameter. When the new model is rebuilt, the exceptions added to the Anomaly Detection attack logs corresponding to that parameter will be cleared.

In the scanning process, when a request passes through different modules in sequence, the configured action for certain modules can be set to "Alert" or "Monitor". In this case, if an attack is detected by a module with such an action, it will allow the request to continue to the next module for further scanning. However, an attack log will be generated by the module that identified the attack.

As the request progresses through subsequent modules, it is possible for the attack to be logged multiple times by different preceding modules before it is blocked by a module with a different action, such as "Block Period" or "Deny".

As for the scan sequence, please refer to https://docs.fortinet.com/document/fortiweb-cloud/latest/user-guide/234292/sequence-of-scans.

If the https_host in GEO IP attack logs shows none, it can be solved by enabling Use X-Header to Identify Original Clients' IP and Add X-Forwarded-For in the Rewriting Requests module.

To observe the client's original source IP, it is advised to enable the Rewriting Requests module, turning on X-Forwarded-For, X-Real-IP, and Use X-Header to Identify Original Clients' IP options.

Logs are sent from FortiWeb Cloud to the origin server, so the IP: header (layer 3) of the logs is supposed to be FortiWeb Cloud's IP address. This is expected behavior.

To check the client real IP, you need to find it in the X-Forwarded-For: or X-Real-IP: header in the packets forwarded from FortiWeb Cloud to your server. Be aware that to record the client real IP it's required to enable both Add X-Forwarded-For and Use X-Header to Identify Original Client's IP in the Rewriting Requests module.

The signatures used in Known Attacks are primarily designed to detect known patterns of malicious code. However, they may not cover all variants or newly emerging forms of attacks.

In cases where an attack is logged under the Anomaly Detection threat type instead of being matched with a signature, it in fact indicates the successful functioning of the machine learning model in Anomaly Detection. It effectively screened out unknown or new variant attacks that do not align with existing signatures.

You can view the blocked requests in three places: 1) Attack Logs; 2) FortiView ; 3) Blocked Requests widget on Dashboard. The ways they count the blocked requests are slightly different.

• To prevent Information Leakage, FortiWeb Cloud may cloak the error pages or erase sensitive HTTP headers in response packets. Such item are logged only once per minute in Attack Logs and FortiView for you to know the Information Leakage rule took effect. In the meanwhile, the actual count is recorded in Blocked Requests Widget.
• If you have set FortiWeb Cloud to block attacks but do not generate a log when certain violation occurs, such as Alert & Deny (no log), then the attacks will not be logged in Attack Logs and FortiView , but will be counted in the Blocked Requests widget.
• The invalid requests to the host header HOST will be blocked without generating any log.
• When the Block Mode is in disabled state, attacks won't be blocked but logs are generated.

If you have set FortiWeb Cloud to block attacks but not generate a log when certain violation occurs, such as 'Alert & Deny (no log)', then the attacks will not be logged in Attack Logs and FortiView but will be counted in the Blocked Requests widget.

If you need to have detailed logs for auditing or analysis purposes, you may consider using a different action, such as 'Alert & Deny' or 'Block Period', which will not only block the request but also generate a log entry.

To identify the security feature blocking your request, map the Attack ID value to the corresponding description in the table below.

You may need to authorize the devices of FortiWeb Cloud in your FortiAnalyzer.

Check if your FortiWeb Cloud's application serial number shows up under FAZ > Device Manager > Unauthorized Devices, if so, authorize it to send attack logs to FortiAnalyzer.

To use an S3 bucket for traffic export, the IAM role must include the following permissions:

• s3:PutObject

• s3:GetObject

• s3:GetBucketLocation