This post focuses on setting up Wazuh to collect events delivered by AWS CloudTrail which provides useful information about the AWS infrastructure, such as the instance configuration, unauthorized behavior, API usage and more.
What is AWS CloudTrail
AWS CloudTrail is a service that enables governance, compliance, operational and risk auditing of your AWS infrastructure. It provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command-line tools, and other AWS services.
How it works
CloudTrail typically delivers log files within 15 minutes of account activity by using trails. A trail is a configuration that enables the delivery of events to a specified Amazon S3 bucket to record changes in AWS resources. Log file objects are stored by trails in the S3 bucket in the following name format:
This name format includes the following elements:
- The bucket name specified when creating the trail.
- The prefix specified when creating the trail. This is optional.
- The string
- The account ID.
- The string
- A region identifier such as
- The year the log file was published in
- The month the log file was published in
- The day the log file was published in
- A random alphanumeric string to differentiate files from the same time period.
More information about CloudTrail concepts can be found here.
Setting it up
The following diagram shows what we plan to accomplish:
Note: If you already have a Trail set up for saving CloudTrail logs you can skip Step 1.
Step 1: Enable AWS CloudTrail
To enable CloudTrail we need to define a bucket for saving the logs. To do so, log in to the AWS Management Console and look for “CloudTrail” using the “Find Services” search option. Click on “Trails” on the left panel, and then click on “Create trail” button, as shown in the following screenshot:
Lastly, provide the name for the new S3 bucket that will be created and used to store CloudTrail logs:
Step 2: Create AWS credentials
Once we have created a trail, we need to set up credentials so that Wazuh is able to connect and extract the logs from the S3 bucket. We recommend doing this instead of hardcoding the user and password for the AWS account in the
ossec.conf. More information about how to configure AWS credentials can be found in the Wazuh documentation.
For testing purposes, we are going to create a file located at
~/.aws/credentials with the following content to grant us access to the previously created S3 Bucket:
[default] aws_access_key_id=<YOUR_AWS_ACCESS_KEY> aws_secret_access_key=<YOUR_AWS_SECRET_KEY>
This way we will be able to connect to our AWS account if we specify
default as our AWS profile in the next step.
Step 3: Configure Wazuh
The only thing left to do is to indicate in our
<WAZUH_HOME>/etc/ossec.conf file that we want to collect logs from CloudTrail by adding the following module. This step is performed on the Wazuh Manager or Agent. For this example we are going to configure it on a Wazuh Manager:
<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="cloudtrail"> <name>wazuh-cloudtrail</name> <aws_profile>default</aws_profile> </bucket> </wodle>
From this module two options stand out:
name: The name of the bucket where CloudTrail is saving the logs, previously defined. In our case, we named it “wazuh-cloudtrail”.
aws_profile: The name of the profile defined for granting Wazuh access to the bucket. This allows us to log in with our AWS account. It must match with the profile specified in the credentials file created in step 2.
Note: To monitor logs for multiple AWS accounts, you must configure multiple options within the
aws-s3module. Bucket tags must have a type attribute which depends on the service being monitored. More information here.
Finally, restart Wazuh to apply the changes, and the CloudTrail alerts will start to appear on the Wazuh UI.
Other useful options for AWS-S3 module
The AWS-S3 module has several options available aside from the ones shown in the previous example. Here are some configuration options that can be useful when the S3 bucket contains a long history of logs. They will filter which logs will be read by Wazuh:
only_logs_after: Allows filtering of logs produced after a given date. The date format must be
YYYY-MMM-DD. For example,
2020-JUN-01would filter logs produced after the 1st of June 2020, not including that day. It requires the directory structure to be organized by dates.
aws_account_id: If you have logs from multiple accounts, you can filter which ones will be read by Wazuh. You can specify multiple IDs by separating them with commas.
regions: If you have logs from multiple regions, you can filter which ones will be read by Wazuh. You can specify multiple regions separating them with commas.
path: If you have your logs stored in a given path, it can be specified using this option. This must match with the
prefix_nameof the log object files to be read.
Usage examples of those available options can be found in our official documentation.
Note: The AWS-S3 Wazuh module only looks for new logs based upon the key for the last processed log object which includes the date timestamp. If older logs are loaded into the S3 bucket or the
only_logs_afteroption date is set to a date/time earlier than previous executions of the module, the older log files will be ignored and not ingested into Wazuh.
Step 4: Ensure everything is running fine
After restarting you can ensure everything is fine by checking the
<WAZUH_HOME>/logs/ossec.log. If the following message appears in the log and there are no warnings related to AWS then everything is ready:
INFO: Module AWS started INFO: Starting fetching of logs. INFO: Executing Bucket Analysis: (Bucket: wazuh-cloudtrail, Type: cloudtrail, Profile: default)
You can also verify the integration is working as expected by accesing the Wazuh App. The AWS CloudTrail dashboard can be found here:
This section covers possible errors that may occur if we have made any mistake during the configuration process. Those errors will be found in the
To increase the verbosity of the messages found in
ossec.logdebug mode for the AWS module can be enabled by adding the line
<WAZUH_HOME>/etc/local_internal_options.conffile and restarting Wazuh.
The config profile could not be found
INFO: Module AWS started INFO: Starting fetching of logs. INFO: Executing Bucket Analysis: (Bucket: wazuh-cloudtrail, Type: cloudtrail, Profile: default) WARNING: Bucket: - Returned exit code 12 WARNING: Bucket: - The config profile (default) could not be found INFO: Fetching logs finished.
If the AWS credentials cannot be found you will receive this error. Make sure the AWS credentials have been correctly set up as indicated in Step 2: Configure AWS credentials.
Access error: Forbidden
INFO: Module AWS started INFO: Starting fetching of logs. INFO: Executing Bucket Analysis: (Bucket: wazuh-cloudtrail, Type: cloudtrail, Profile: default) WARNING: Bucket: - Returned exit code 3 WARNING: Bucket: - Access error: An error occurred (403) when calling the HeadBucket operation: Forbidden
This error means the credentials specified during the Step 2: Configure AWS credentials are wrong and they don’t grant access to AWS. Ensure you are using the right credentials.
Access error: Not Found
INFO: Module AWS started INFO: Starting fetching of logs. INFO: Executing Bucket Analysis: (Bucket: wazuh-cloudnottrail, Type: cloudtrail, Profile: default) WARNING: Bucket: - Returned exit code 3 WARNING: Bucket: - Access error: An error occurred (404) when calling the HeadBucket operation: Not Found INFO: Fetching logs finished.
This error appear when a wrong S3 Bucket name is specified. Ensure the same bucket name defined in Step 1: Enable AWS CloudTrail is used in
<WAZUH_HOME>/etc/ossec.conf when following the instructions of Step 3: Configure Wazuh.
Use case: Detecting intrusion attempts
One of the most common use cases for the CloudTrail integration with Wazuh is to monitor intrusion attempts into our cloud infrastructure. Every time a user tries to log in, an event will be generated regardless if it was successful or not.
In addition, it’s possible to configure Wazuh to send email alerts when this kind of behavior is detected, making it possible to immediately perform the necessary actions to avoid the effects of these attacks. You could also enable Amazon SNS to send SMS notifications.
As an example, the following alert will be shown in the Wazuh UI if a user tries to log in with an invalid password:
When more than 4 authentication failures occur in a 360 second time window, an alert will be raised:
Use Case: Monitoring API Calls
Another useful example of what we can achieve by integrating CloudTrail with Wazuh is through monitoring any API calls. Any time an API call is performed, a log will be created by AWS and collected by Wazuh. It will be visible in the Wazuh UI and provide useful information. Some of the fields that the alert will have are:
- Caller’s identity (user, country, ip…)
- API call’s timestamp
- Requested parameters and the resulting response
Here is an example of an event raised when someone tried to run a EC2 instance:
And here is another example of an event when a user tries to terminate an EC2 instance:
Thanks to CloudTrail and Wazuh, we can be made aware of misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues. We can also be notified when some of those alerts are triggered.
Wazuh is ready to analyze AWS events of high relevance making it a powerful visualization tool to keep track of everything that happens in your AWS infrastructure.
If you have any questions about this, don’t hesitate to check out our documentation to learn more about Wazuh. You can also join our Slack #community channel and our mailing list where our team and other users will help you with your questions.