Amazon GuardDuty continuously monitors and identifies threats by analyzing several types of activity in your AWS account and any invited member accounts that you link to. GuardDuty can notify you of a wide variety of threats including unauthorized access, trojans, communication with Tor anonymizing, or cryptocurrency networks.
GuardDuty uses the following data sources to make its threat findings: VPC Flow Logs, AWS CloudTrail event logs, and DNS logs.
To start using GuardDuty, you must first enable it for your account. You will enable GuardDuty in this lab step. You will enable GuardDuty in a single AWS region. In practice, it is highly recommended that you enable GuardDuty in all supported AWS regions. This allows GuardDuty to generate findings of threats even in regions that you are not actively using.
You will learn how to use Amazon GuardDuty to automatically uncover malicious EC2 activity, and configure threat lists to improve the security of an AWS Lab environment.
Learning Objectives
Upon completion of this lab, we will be able to:
- Enable, disable, and suspend Amazon GuardDuty for AWS accounts
- Activate threat lists and trusted IP lists, and understand when to use each
- Understand the types of security findings GuardDuty can detect
- Prioritize and interpret GuardDuty findings in a live environment
You should be familiar with: Core AWS services, particularly EC2, VPC, and S3.
Enabling Amazon GuardDuty
Instructions
In the AWS Management Console search bar, enter GuardDuty, and click the GuardDuty result under Services:
Click Get Started on the welcome page:
Click Enable GuardDuty to have GuardDuty start monitoring your AWS environment:
Enabling GuardDuty automatically creates a service-linked role to allow GuardDuty to gather metadata about EC2 instances in your environment. After you enable GuardDuty, it immediately begins pulling and analyzing streams of data from AWS CloudTrail, VPC Flow Logs, and DNS logs to generate security findings. This all happens automatically behind the scenes. For example, you do not need to create VPC Flow Logs to have GuardDuty monitor network activity in your VPCs.
We have enabled Amazon GuardDuty, so that security findings for your AWS environment can automatically be discovered.
Activating a GuardDuty Threat List
Amazon GuardDuty analyzes its data sources to find potential security threats. You can influence the security findings that GuardDuty reports through trusted IP lists and threat lists. Trusted IP lists whitelist IP addresses from being included in GuardDuty's findings to reduce false positives. Threat lists include known malicious IP addresses. GuardDuty reports additional findings for IP addresses in threat lists.
We will activate a threat list that includes the IP address of an EC2 instance that is part of the Cloud Academy Lab environment. The environment consists of two EC2 instances in different VPCs. The instances are configured to communicate with each other. You will see the findings GuardDuty discovers regarding communicating with malicious instances in a later lab step.
Instructions
Open the EC2 console to view the instances in the Lab environment.
There are two EC2 instances to focus on for this lab: Malicious Instance, and App Server:
I select Malicious Instance and copied its IPv4 Public IP:
The Public IP address is what is needed for GuardDuty's threat list. DNS names and private IP addresses are ignored in threat lists.
Save the IP address in a plain text file named threat-list.txt.
GuardDuty requires a file on Amazon S3 to create a threat list. As an example on Windows, you could use Notepad and the file contents would look similar to the following:
Open the Amazon S3 console
Click on the bucket containing threatlist in the name.
Click Upload to open the S3 upload wizard.
Click Add files and select the threat-list.txt file we created earlier.
Click Upload in the lower-right corner to upload the file with the default S3 file configuration.
Click threat-list.txt to open its details in a new tab, and copy the Object URL in the Object overview panel:
Return to the GuardDuty Console, and select Lists in the left sidebar.
Note: You may already see some Findings in the GuardDuty Console. GuardDuty does not require a threat list to make findings. It will only report additional findings for IP addresses in the threat list.
- Click Add a threat IP list to create a threat IP list:
In the Add a threat IP list form, enter the following values and click Add list:
- List name: Lab
- Location: Paste in the S3 link you copied a few instructions ago
- Format: Plaintext (Notice that the drop-down lists other formats that can be used if you have existing threat intelligence services to import threat lists from)
- I agree: checked Check the Active checkbox to activate the threat list:
We have activated a threat list in GuardDuty. You began by listing IP addresses in a file. Then you uploaded the file to S3, and created a threat list in GuardDuty. Lastly, you activated the threat list. No new findings related to the threat list will be made unless the threat list is active.
Examining Sample GuardDuty Findings**
To learn about the types of threats that GuardDuty can find, you will generate sample findings in this lab step. The findings are simulated, but allow you to view details and illustrate the three different severity levels in GuardDuty: high, medium, and low. In addition to the sample findings, you can find [descriptions of what each finding relates to in the GuardDuty documentation]
(https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types.html).
Instructions
Click on Settings in the GuardDuty Console sidebar.
You can ignore any error that appears regarding not being authorized to perform IAM requests.
Scroll down to the Sample findings section and click on Generate sample findings:
After a few seconds, a success banner appears:
Click on Findings in the GuardDuty sidebar.
Notice the table is full of various findings that begin with [SAMPLE]:
Read through the different sample findings to see what kind of threats GuardDuty can identify.
Select a few findings and inspect the details panel that appears:
The details are divided into several sections: Summary, Resource affected, Action, Actor, and Additional information.
We have generated and examined sample GuardDuty findings. Although this Lab focuses on EC2 threats, you have also seen in the sample findings that GuardDuty can also identify IAM threats by using CloudTrail logs.
Examining Live Threats in GuardDuty**
Introduction
The EC2 instances in the Cloud Academy lab environment have been communicating with each other since you enabled GuardDuty. The findings related to the instances should appear within 15 minutes. You can read through this lab step without waiting if you prefer. The lab step explains the findings that would eventually appear. If you do wait and no findings are present after 15 minutes ensure the threat IP list is active, The way the two instances communicate with each other is as follows:
- The App Server instance simply makes HTTP requests to the Malicious Instance every 15 seconds.
- The Malicious Instance sends SSH connection attempts to the App Server instance every 4 seconds. The connection request does not include an SSH key causing the request to always be refused.
The signatures of each of these communication types are recognized by GuardDuty as findings. You will investigate the findings in this lab step.
Instructions
Click on Findings in the GuardDuty Console's sidebar.
Depending on how quickly you arrived at this lab step, you may see the following Finding type row:
- Click on the UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding with a yellow square (medium severity):
This finding indicates outbound TCP communication with an IP address in one of your GuardDuty threat lists. The Threat list name field tells you which list. The medium severity rating is used because it is recommended that you investigate the affected instance at your earliest convenience.
- Scroll down the finding details to discover all the details included to help you understand the threat:
For example, in the Resource affected section you can see if the involved instance (the App Server in this case) was in the role of the target or the actor and which port was involved. GuardDuty uses VPC flow logs to make the finding. In previous iterations of GuardDuty a separate SSHBruteForce finding was also reported but it is not treated separately any longer.
Additional Potential Findings
The following findings are not expected to be included in your lab's GuardDuty findings but have been observed when leaving instances open to the Internet for extended periods of time or if an instance is compromised. They can give you additional perspective on what GuardDuty can find.
1. UnauthorizedAccess:EC2/SSHBruteForce (low severity):
The EC2/SSHBruteForce finding indicates an instance was involved in a brute force attack aimed at gaining SSH access using passwords or access keys. In the above image, you can see the description states that an instance is the target of an attack from an IP address. GuardDuty uses VPC flow logs to make this finding. The finding is classified as Low severity meaning that it does not require immediate attention, but is something to address in the future, perhaps by blocking traffic from that IP in your VPC and only allowing SSH access through keys. You can see Location of the attacker's IP address in the Actor section of the finding details.
Note: SSH findings are only reported if SSH is configured on the default port of 22.
- Recon:EC2/PortProbeUnprotectedPort (low severity): This finding notifies you that an open port on one of your instances has been probed by known scanners on the internet. The finding is low risk, but you are advised to restrict access to known instances by configuring security groups, access control lists, or host firewalls. The Actor section tells you where the probe originated:
We examined a real EC2 threat finding for the lab environment. You understood the signatures for each finding and actions that can be taken to remedy each.
It is worth noting that GuardDuty findings are event sources in EventBridge. By using EventBridge, it is possible to automatically react to GuardDuty findings.
Disabling Amazon GuardDuty
Amazon GuardDuty incurs costs for analyzing the variety of data sources that it monitors. If you no longer need the proactive threat detection provided by GuardDuty, you can either suspend or disable it to stop accumulating costs. If you disable GuardDuty, any findings that were discovered by GuardDuty will be lost. In practice, you are encouraged to back up any findings you want to preserve before disabling GuardDuty.
In this Lab Step, you will disable GuardDuty because you will not need to preserve any findings or activate GuardDuty later.
Instructions
- In the GuardDuty Console, click on Settings in the left sidebar:
- Under Disable GuardDuty, click on Disable:
You are presented with the GuardDuty welcome page when the operation is complete.
We disabled GuardDuty to stop accumulating threat analysis costs and to remove any trace of previous findings.
Conclusion
Amazon GuardDuty offers a robust and proactive approach to safeguarding your EC2 instances from a wide range of threats. By continuously monitoring your AWS environment, GuardDuty provides invaluable insights into suspicious activities, enabling you to respond promptly and effectively. Its ability to detect anomalies, unauthorized access, and malicious behaviors is a critical component of a comprehensive security strategy.
Recommendations
To maximize the benefits of Amazon GuardDuty and strengthen your overall security posture, consider the following recommendations:
- Develop clear incident response plans to address potential threats identified by GuardDuty. Establish communication channels and roles to ensure efficient coordination.
- Combine GuardDuty with other security tools and services to create a layered defense. Utilize tools like AWS Security Hub to centralize and prioritize findings.
- Stay informed about emerging threats and vulnerabilities. Incorporate threat intelligence feeds into GuardDuty to enhance detection capabilities.
- Continuously review GuardDuty findings and adjust detection filters as needed. This helps optimize the service for your specific environment.
- Foster a security-aware culture within your organization. Train users on best practices for handling sensitive information and recognizing potential threats.
- GuardDuty is a valuable tool, but it should be part of a broader security strategy. Consider implementing additional safeguards such as strong access controls, network segmentation, and regular vulnerability assessments.
Top comments (0)