Monitoring Mirrored S3 Server Access Logs

[rkill...@gmail.com]

Hello!

I'm trying to get Wazuh version 3.9.5 to ingest S3 server access logs from an S3 bucket (note that these are not CloudTrail logs), but the objects in the S3 bucket are mirrored into my account from a source bucket that's in another AWS account (if that makes a difference at all).
I'm running into an access denied issue when trying to GetObject from the bucket, although there's no issue when it calls ListObjects. I'm not quite sure why there's an issue with GetObject, though. I've got several other Wazuh agents that are reading from other S3 buckets without any issues (CloudTrail, VPC Flow Logs, GuardDuty), the only difference is the type of log being read.
I've used the same IAM role on all of the agents and the only one having an issue is the agent that's trying to read the server access logs.
Does anyone have any idea why this agent is having trouble reading the S3 server access logs?

Thank you!

[Jesus Linares]

Hi,

I understand that you are passing an IAM role to your EC2 instance (your agent) using an instance profile, right?

In this case, I will review 3 things:

1. IAM role: Does it have permission to GetObject action?  Please, share your IAM role.
2. Instance profile: Is it applied? You could try to restart the instance if possible.
3. Wazuh agent configuration: Is it properly configured to take the instance profile? Please, share your configuration.

I hope it helps.

Regards.

[rkill...@gmail.com]

Thank you for getting back to me!

The instance profile does have GetObject permission. Here's the IAM profile:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "wazuhGetObjectsInS3Bucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::logstash-test-bucket/*",
                "arn:aws:s3:::guardduty/*",
                "arn:aws:s3:::vpcflow/*",
                "arn:aws:s3:::cloudtrail/*",
                "arn:aws:s3:::s3/*"
            ]
        },
        {
            "Sid": "wazuhListObjectsInS3Bucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": [
                "arn:aws:s3:::logstash-test-bucket/*",
                "arn:aws:s3:::guardduty/*",
                "arn:aws:s3:::vpcflow/*",
                "arn:aws:s3:::cloudtrail/*",
                "arn:aws:s3:::s3/*"
            ]
        },
        {
            "Sid": "wazuhCheckForBucketAccess",
            "Effect": "Allow",
            "Action": "s3:HeadBucket",
            "Resource": [
                "arn:aws:s3:::logstash-test-bucket/*",
                "arn:aws:s3:::guardduty/*",
                "arn:aws:s3:::vpcflow/*",
                "arn:aws:s3:::cloudtrail/*",
                "arn:aws:s3:::s3/*"
            ]
        },
        {
            "Sid": "wazuhGetVPCFlowLogs",
            "Effect": "Allow",
            "Action": "ec2:DescribeFlowLogs",
            "Resource": "*"
        },
        {
            "Sid": "wazuhAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111122223333:role/ReadOnly_S3Bucket",
                "arn:aws:iam::111122223333:role/wazuh_InstanceProfile",
                "arn:aws:iam::*:role/vpc_flow_logs"
            ]
        },
        {
            "Sid": "wazuhUseKMS",
            "Effect": "Allow",
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": [
                "arn:aws:s3:::guardduty/*",
                "arn:aws:s3:::vpcflow/*",
                "arn:aws:s3:::cloudtrail/*",
                "arn:aws:s3:::s3/*"
            ]
        }
    ]
}

The instance profile is applied to the node running the agent and I've tried restarting the node several times without much luck. It appears that the profile is working properly because the debug messages from Wazuh show that the host can reach STS and assume a role and get temporary credentials.

The Wazuh config on the node itself is configured to use the instance profile as well:

  <wodle name="aws-s3">
    <disabled>no</disabled>
    <interval>5m</interval>
    <run_on_start>yes</run_on_start>
    <skip_on_error>yes</skip_on_error>

    <!-- S3 Audit Logs -->
    <bucket type="custom">
        <name>s3</name>
        <only_logs_after>2021-JAN-21</only_logs_after>
        <regions>us-west-1</regions>
        <iam_role_arn>arn:aws:iam::111122223333:role/wazuh_InstanceProfile</iam_role_arn>
    </bucket>
  </wodle>

I'm sorry for the poor formatting. I thought there used to be a way to format text as code, but I can't find the option to do that anymore.

Thank you again for your help! Any advice would be amazing.

[Jesus Linares]

Hi,

sorry for the late reply. If you are using the instance profile, you don't need to set the iam_role_arn in your configuration according to the documentation. So, your configuration should look like:

  <wodle name="aws-s3">

    <disabled>no</disabled>

    <interval>5m</interval>

    <run_on_start>yes</run_on_start>

    <skip_on_error>yes</skip_on_error>

    <!-- S3 Audit Logs -->

    <bucket type="custom">

        <name>s3</name>

        <only_logs_after>2021-JAN-21</only_logs_after>

        <regions>us-west-1</regions>

    </bucket>

  </wodle>

If this doesn't work, please enable the debug mode for the wodle and share the logs related to aws-s3 from the ossec.log file.

I hope it helps.

[rkill...@gmail.com]

Thank you for continuing to help with this!

I believe I've figured out the issue. It turns out that I had forgotten to configure the bucket mirroring on the source account to change the ownership of the objects to the destination account when they're mirrored. It appears that I'm able to parse the logs that were generated after I fixed the configuration and I'm not able to parse logs that appeared before the configuration was fixed. I'll update this post if I find that the configuration wasn't the issue, but it looks like that was the problem from what I've seen over the last couple of days (which is a pretty small test size, so take this with a grain of salt).