Log Management
How long are the logs kept in FortiAppSec Cloud?
All logs are periodically cleaned at the beginning of each month.
Please refer to the table under Retention and Periodic clean for full retention information on each type of log.
Where to view and delete the exceptions related with Anomaly Detection?
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.
Why do I find several attack logs even though there is only one attack request?
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".
For more information, please refer to Sequence of scans.
Why is there no attack log while the request is blocked?
If the action of a corresponding security feature is configured as "Deny (no log)", FortiAppSec Cloud will actively deny the request and prevent it from proceeding further, but it will not generate a log entry specifically for that blocked request.
If you need to have detailed logs for auditing or analysis purposes, you may consider using a different action, such as "Deny" or "Block Period", which will not only block the request but also generate a log entry.
Domain name cannot be seen in GEO IP attack logs. How to solve it?
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.
How to show the client source IP instead of FortiAppSec Cloud IP received from the server side?
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.
Why the origin server receives logs with FortiAppSec Cloud's IP rather than the client real IP even if X-Forwarded-For related options are enabled?
Logs are sent from FortiAppSec Cloud to the origin server, so the IP: header (layer 3) of the logs is supposed to be FortiAppSec 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 FortiAppSec 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.
Why an attack log is classified as Anomaly Detection, not Known Attack?
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.
Why is the number of blocked requests in the Attack Log and the Blocked Requests Widget inconsistent?
You can view the blocked requests in three places: 1) Attack Logs; 2)
- To prevent Information Leakage, FortiAppSec 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 Threat View 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 FortiAppSec Cloud to block attacks but do not generate a log when certain violation occurs, such as Deny(no log), then the attacks will not be logged in Attack Logs and
FortiView Threat View , 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.
Why do some signatures have actions that differ from the default action of their associated attack module?
The signature database is updated twice a month—on the 15th and 31st. You can refer to the FortiGuard Web Security Services page for the latest updates.
By default, new signatures are set to Alert mode and cannot be modified. Any customizations related to known attack handling will not apply to newly released signatures until the following database update.
For example, if signature 8888888 is released on March 15, it will remain in Alert mode from March 15 to March 31. Any changes for known attack detection will only take effect after April 1, during the next update cycle.