I’ve created a corp rule that checks for an HTTP Response key+value to add a corp signal labeled “corp.flag-block”. I’ve then added a site alert to block based on a threshold of 1 within 60 minutes. It sounds good in theory, but I’ve been seeing lots of subsequent requests logged on our origin server as well as 404s within the Fastly logs.
How long does it take for a signal to flow through and start blocking? In the Fastly request log (filtered by IP), I see a request with the “block” signal at 2:01:20 and then 29 additional requests that are all 404 Not Found with “status Allowed” ending at 2:04:51. How will I know that the IP is truly being blocked by Fastly WAF versus the abuser switching to a different proxy IP address? There’s no additional actions or information under “Observed Sources | Flagged IPs” and non of the responses are logged with the 406 status.
With a threshold of “1”, does the first corp signal trigger the site alert’s trigger or does it waiting until the next signal? If it requires an “initial plus subsequent trigger”, should I modify the existing rule to issue two (2) the same signal?
NOTE: I’m not sure what type of data can be shared here. I have a screenshot and have also exported the data to CSV.
I’ve then added a site alert to block based on a threshold of 1 within 60 minutes.
I would start with 1 in 1 minute instead because the frequency of the check is shorter than the 1 hour. You can see that info here.
Important to note here that a Site Alert will only block future requests from the client that contain attack signals (SQLI, CMDEXE, XSS, etc…) and not all requests.
Additionally, you cannot take a direct action on a signal that was added based on response data.
Do you have access to Advanced Rate Limiting because this can be solved through that similar to what is described here for credit card validation attempts.
With a threshold of “1”, does the first corp signal trigger the site alert’s trigger or does it waiting until the next signal?
Threshold of 1 would block immediately - however, as mentioned above Site Alerts only block future requests that contain attack signals.
ahh… there’s the nuance; “Flag IP and block requests tagged WITH ATTACK SIGNALS”. I was under the false impression that it could flag & block IPs. If I want to do this, I guess my option is to add the IP to a Corp or Site List.
Regarding “Rate Limiting”, that option is not available to me when creating a new corp or site rule.
Regarding the “threshold monitoring”, I didn’t realize that this was on a schedule.
Under the alerts, I also have “Send external notifications (e.g. email, Slack)” enabled, but have never received any notifications. This may require any feature to be enabled somewhere else as I don’t see any ability to specify either. I’ll disable this for now.