Amazon GuardDuty

Amazon GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. It monitors for activity such as unusual API calls or potentially unauthorized deployments that indicate a possible account compromise. GuardDuty also detects potentially compromised instances or reconnaissance by attackers.

Amazon S3 Protection

S3 Protection enables Amazon GuardDuty to monitor object-level API operations to identify potential security risks for data within your S3 buckets.

Amazon configuration native integration

  1. Create a new S3 bucket. If you want to use an existing bucket, skip this step.

  2. Go to Services > Security, Identity, & Compliance > GuardDuty:

  3. In the navigation pane, under Settings, click S3 Protection:

  4. The S3 Protection Pane lists the current status of S3 protection for your account, you may enable or disable it at any time by selecting Enable or Disable:

  5. Confirm your selection:

Amazon configuration with Kinesis, Firehose, CloudWatch integration

Deprecated since version 4.6.

  1. Create a new S3 bucket. If you want to use an existing bucket, skip this step.

  2. Go to Services > Analytics > Kinesis:

  3. Click Create delivery stream:

  4. Choose a Source and select Amazon S3 as the Destination:

  5. Choose a name for your delivery stream. Leave the Transform and convert records options disabled:

  6. On the Destination settings select the previously created S3 bucket and add a prefix where logs will be stored.

    AWS Firehose creates the following file structure: YYYY/MM/DD/HH. If a prefix is used, for example firehose/, the created file structure would be firehose/YYYY/MM/DD/HH. If a prefix is used it must be specified under the ThreatLockDown Bucket configuration.

  7. Select the Compression for data records you prefer. ThreatLockDown supports any kind of compression but Snappy:

  8. Under the Advanced settings section you can set the Permissions. By default. a new IAM role will be created. If you choose an existing IAM role, remember to include the permissions that the Kinesis Data Firehose needs. Finally, click Create delivery stream:

  9. Go to Services > Management & Governance > CloudWatch:

  10. In the Cloudwatch pane under Events, click Rules:

  11. On the Amazon EventBridge pane, click Create rule:

  12. Under the Define rule detail section, name the rule and click Next:

  13. Under the Build event pattern section, choose AWS events as your event source:

  14. Under the Event pattern section, choose GuardDuty as your AWS service and All Events as your Event type, then click Next:

  15. On the Select target(s) section, choose AWS service as your Target types. Select Firehose delivery stream as your target type and add the previously created Firehose delivery stream as your Stream, and click Next:

  16. On the Configure tags section, you can configure a tag to search and filter resources. Click Next:

  17. The last section is a summary of the created rule, confirm that the selection is correct and click Create Rule:

  18. Once the rule is created, data will start to be sent to the previously created S3 bucket. Remember to first enable the service you want to monitor, otherwise, you won't get any data.

Policy configuration

To create a policy using the Amazon Web Services console, follow the AWS documentation.

Take into account that the policies below follow the principle of least privilege to ensure that only the minimum permissions are provided to the ThreatLockDown user.

To allow an AWS user to use the module with read-only permissions, it must have a policy like the following attached:

 {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "VisualEditor0",
             "Effect": "Allow",
             "Action": [
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": [
                 "arn:aws:s3:::<bucket-name>/*",
                 "arn:aws:s3:::<bucket-name>"
             ]
         }
     ]
 }

If it is necessary to delete the log files once they have been collected, the associated policy would be as follows:

{
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "VisualEditor0",
             "Effect": "Allow",
             "Action": [
                 "s3:GetObject",
                 "s3:ListBucket",
                 "s3:DeleteObject"
             ],
             "Resource": [
                 "arn:aws:s3:::<bucket-name>/*",
                 "arn:aws:s3:::<bucket-name>"
             ]
         }
     ]
 }

Note

<bucket-name> is a placeholder. Replace it with the actual name of the bucket from which you want to retrieve logs.

Once a policy has been created, there are different methods available to attach it to a user, such as attaching it directly or to a group to which the user belongs. More information on how to perform those tasks on the AWS documentation.

ThreatLockDown configuration

  1. Open the ThreatLockDown configuration file /var/ossec/etc/ossec.conf and add the following block:

Native Integration

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>
  <bucket type="guardduty">
    <name>wazuh-aws-wodle</name>
    <aws_profile>default</aws_profile>
  </bucket>
</wodle>

Firehose, Kinesis, CloudWatch Integration

<wodle name="aws-s3">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>yes</skip_on_error>
  <bucket type="guardduty">
    <name>wazuh-aws-wodle</name>
    <path>firehose/</path>
    <aws_profile>default</aws_profile>
  </bucket>
</wodle>

Note

Check the AWS S3 module reference manual to learn more about each setting.

  1. Restart ThreatLockDown in order to apply the changes:

    • If you're configuring a ThreatLockDown manager:

      # systemctl restart wazuh-manager

    • If you're configuring a ThreatLockDown agent:

      # systemctl restart wazuh-agent

GuardDuty use cases

Amazon EC2 (Elastic Compute Cloud) provides scalable computing capacity in the cloud. When using this service, it is highly recommended to monitor it for intrusion attempts or other unauthorized actions performed against your cloud infrastructure.

Below are some use cases for ThreatLockDown rules built for EC2.

Brute force attacks

If an instance has an open port that is receiving a brute force attack, the following alert will be shown on the ThreatLockDown dashboard. It shows information about the attacked host, the attacker, and which port is being attacked:

EC2 API Calls made from unusual network

If an API call is made from an unusual network, the following alert will be shown on the ThreatLockDown dashboard. It shows the location of the unusual network, the user who did the API calls, and which API calls it did:

Compromised EC2 instance

If there is any indicator of a compromised EC2 instance, an alert will be shown on the ThreatLockDown dashboard explaining what's happening. Some examples of alerts are shown below:

To sum up, the following screenshot shows some alerts generated for a compromised EC2 instance:

And here are the ThreatLockDown dashboard charts for EC2 events:

Pie Chart

Stacked Groups