Which response will immediately mitigate the attack and help investigate the root cause?
Log in to the suspicious instance and use the netstat command to identify remote connections. Use the IP addresses from these remote connections to create deny rules in the security group of the instance. Install diagnostic tools on the instance for investigation. Update the outbound network ACL for the subnet in us-east-1b to explicitly deny all connections as the first rule during the investigation of the instance.
Update the outbound network ACL for the subnet in us-east-1b to explicitly deny all connections as the first rule. Replace the security group with a new security group that allows connections only from a diagnostics security group. Update the outbound network ACL for the us-east-1b subnet to remove the deny all rule. Launch a new EC2 instance that has diagnostic tools. Assign the new security group to the new EC2 instance. Use the new EC2 instance to investigate the suspicious instance.
Ensure that the Amazon Elastic Block Store (Amazon EBS) volumes that are attached to the suspicious EC2 instance will not delete upon termination. Terminate the instance. Launch a new EC2 instance in us-east-1a that has diagnostic tools. Mount the EBS volumes from the terminated instance for investigation.
Create an AWS WAF web ACL that denies traffic to and from the suspicious instance. Attach the AWS WAF web ACL to the instance to mitigate the attack. Log in to the instance and install diagnostic tools to investigate the instance.
Explanations:
Updating the outbound network ACL to deny all connections will mitigate the attack immediately, but it does not provide a good approach for further investigation. Relying only on the netstat command within the instance may not fully reveal the extent of the malicious activity. Also, modifying security groups while the attack is ongoing might miss the root cause or evidence.
Updating the outbound network ACL to deny all connections is an immediate mitigation step, and the new security group with restricted access allows investigation using a separate EC2 instance with diagnostic tools. This approach ensures better isolation of the suspicious instance and safer investigation without directly interacting with the compromised instance.
Terminating the EC2 instance would prevent further investigation. While preserving EBS volumes is important, removing the instance will not help mitigate the attack immediately and would hinder investigation by losing the running context of the attack.
AWS WAF is not effective for EC2-to-EC2 traffic and does not provide a direct solution to mitigate malicious activity from an EC2 instance. This option also focuses too much on mitigating with WAF rather than investigating the cause of the attack. Additionally, installing diagnostic tools after mitigating does not follow a sound incident response approach.
As I understand it, the answer is:
Update the outbound network ACL for the subnet in us-east-1b to explicitly deny all connections as the first rule. Replace the security group with a new security group that allows connections only from a diagnostics security group. Update the outbound network ACL for the us-east-1b subnet to remove the deny all rule. Launch a new EC2 instance that has diagnostic tools. Assign the new security group to the new EC2 instance. Use the new EC2 instance to investigate the suspicious instance.
My best guess is:
Update the outbound network ACL for the subnet in us-east-1b to explicitly deny all connections as the first rule. Replace the security group with a new security group that allows connections only from a diagnostics security group. Update the outbound network ACL for the us-east-1b subnet to remove the deny all rule. Launch a new EC2 instance that has diagnostic tools. Assign the new security group to the new EC2 instance. Use the new EC2 instance to investigate the suspicious instance.