Which set of actions will identify the suspect attacker’s IP address for future occurrences?
Configure VPC Flow Logs on the subnet where the ALB is located, and stream the data CloudWatch. Search for the new-user-creation.php occurrences in CloudWatch.
Configure the CloudWatch agent on the ALB. Configure the agent to send application logs to CloudWatch. Update the instance role to allow CloudWatch Logs access. Export the logs to CloudWatch. Search for the new-user-creation.php occurrences in CloudWatch.
Configure the ALB to export access logs to an Amazon Elasticsearch Service cluster, and use the service to search for the new-user-creation.php occurrences.
Configure the web ACL to send logs to Amazon Kinesis Data Firehose, which delivers the logs to an S3 bucket. Use Amazon Athena to query the logs and find the new-user-creation.php occurrences.
Explanations:
VPC Flow Logs can capture IP traffic information, but they do not provide application-level logs or specific error occurrences in PHP files. This option would not directly identify issues related to the new-user-creation.php file.
The CloudWatch agent can collect application logs, but it is not configured to capture logs from the ALB directly. Since the error occurs in a PHP file on the EC2 instances, additional configuration would be needed to ensure that these logs are captured and analyzed.
While configuring the ALB to export access logs can provide insights into incoming requests, it does not capture application-specific errors such as those from the new-user-creation.php file. Therefore, this option would not identify the suspect IP address effectively.
Configuring the web ACL to send logs to Amazon Kinesis Data Firehose enables capturing WAF logs, which include details about blocked requests and attacker IPs. Using Amazon Athena to query these logs allows the Operations team to search for specific occurrences of the new-user-creation.php errors, facilitating the identification of the suspect’s IP address.