1 Answer
- Newest
- Most votes
- Most comments
0
Hello,
You did the first part of finding the calls, the second part is indeed finding the source. Once you have the CloudTrail event, you can use the following fields to find the origin of the call:
- the sourceIp is useful if it's an elastic IP you own. You can see what it is associated it.
- the userAgent can indicate what service is doing the call (may show powershell, a SDK, curl or something else)
- the userIdentity field may indicate which principal and associated instance is used
Details of the record are described here: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
Note that if your bucket is public, this IP may be an external public access and your options are:
- Enforce TLS 1.2 for this bucket: https://repost.aws/knowledge-center/s3-enforce-modern-tls
- Use a proxy in front of the bucket: https://repost.aws/knowledge-center/s3-access-old-tls
Hope it helps, Jon
Relevant content
- asked 2 years ago
- asked a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
Thank you so much for your reply and help Jon!
The userAgent is not provided unfortunately, and the userIdentity properties are all null.
The bucket is public, so I'm guessing you are correct in that it is being accessed externally. I do already utilize CloudFront, but perhaps there's somewhere I'm accessing the bucket without CloudFront - I will have to dig around a bit more.
The plan is to enforce TLS 1.2 once I am confident there aren't going to be any issues with blocking that TLS 1 connection. Thankfully the TLS 1 connections are very rare, so it makes me think it's something externally accessing the bucket, and blocking it off shouldn't affect my application.