- 최신
- 최다 투표
- 가장 많은 댓글
Hello.
Since AWS WAF judges by request, we believe that the WAF function alone cannot judge by response.
https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
As you are aware, querying the logs and blocking the IP address would be one way to do this.
Hi Yarpen.
I may be wrong but I don't believe that is something WAF can do. From the documentation:
An AWS WAF rule defines how to inspect HTTP(S) web requests and the action to take on a request when it matches the inspection criteria. You define rules only in the context of a rule group or web ACL.
Based on that, note that WAF inspects web requests, not responses. It won't know that a request produced an HTTP 404 error.
You can define rules that inspect for criteria like the following:
- Scripts that are likely to be malicious. Attackers embed scripts that can exploit vulnerabilities in web applications. This is known as cross-site scripting (XSS).
- IP addresses or address ranges that requests originate from.
- Country or geographical location that requests originate from.
- Length of a specified part of the request, such as the query string.
- SQL code that is likely to be malicious. Attackers try to extract data from your database by embedding malicious SQL code in a web request. This is known as SQL injection.
- Strings that appear in the request, for example, values that appear in the User-Agent header or text strings that appear in the query string. You can also use regular expressions (regex) to specify these strings.
- Labels that prior rules in the web ACL have added to the request.
In addition to statements with web request inspection criteria, like the ones in the preceding list, AWS WAF supports logical statements for AND, OR, and NOT that you use to combine statements in a rule.
For example, based on recent requests that you've seen from an attacker, you might create a rule with a logical AND statement that combines the following nested statements:
- The requests come from 192.0.2.44.
- They contain the value BadBot in the User-Agent header.
- They appear to include SQL-like code in the query string.
What I think can work is, setup a CloudWatch Alarm for your desired 4xx error threshold and consume the alarms from EventBridge. Use EventBridge to trigger a Lambda function that examines the event and adjust the webACL to block the IP addresses.
I hope this helps.
Thanks for you reply, Jose. I understand that the WAF is not able to inspect responses but I don't understand how a CloudWatch alarm consumed by EventBridge could help.
The CloudWatch alarm event contains the information that a certain threshold of, for example, 4xx errors has been exceeded. The event, however, does not contain any details about the clients' IP addresses, which I could pass to Lambda to update the WAF ACL. Where do I get this information from?
Thanks Yarpen
My apologies, you are correct.
To do this, you will have to rely on log analysis. Take a look at the Security Automations for AWS WAF solution. It includes a log parsing component which would align to what you're trying to do, and will potentially save you some time trying to build it yourself.
관련 콘텐츠
- AWS 공식업데이트됨 2년 전
PS: The following managed rules were found. However, this is supposed to be used for login forms, etc., so I am not sure if it will fit your use case. https://docs.aws.amazon.com/waf/latest/developerguide/waf-atp.html https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-atp.html
Hi Riku. Thanks for your reply. The WAF's ATP feature (account takeover prevention) seems to go in the right direction as the solution is able to inspect responses from the application (according to the documentation). However, this is only works if the WAF is attached to CloudFront. This is not possible in my case. Furthermore ATP requires me to specify how login requests are formatted and populated. In my case, I can't provide this information as it doesn't matter. The 4xx errors don't have a predictable URI and the payload doesn't matter.
Yarpen
I think that would require an architecture to query the ALB logs. For example, it would be possible to use a Lambda function to operate Athena to query ALB logs and block IP addresses if there is a matching response. It is possible to operate Athena from Boto3, so it will be necessary to check the following documents while creating the system. https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/athena.html
It turns out that the ALB logs don't contain the client's IP addresses but the addresses from CloudFront (the proxy). That's another dead-end. I suspect that I have to query the CloudFront logs instead.
If we set this header in CloudFront, we can find the IP address of the client, can't we? https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-true-client-ip-header.html