AWS access keys IP filtering protection

Additional layer of protection when consuming Amazon Web Services through IAM Users static keys

After reading the headline your first thought may be that network security is a thing of the past and that API endpoint security is goo. I’ll argue while the network level security is not the ONLY thing that can keep systems secure, it still plays big role in overall security posture and cyber risk management.

Rationale

Imagine a developer going about their daily developer routine, installing a new tool or library via gem or their language of choice package manager, only to find their AWS access keys github, and account full of crypto-mining instances. Actually, no need to imagine, as It has already happened , and probably many times without publicity of the linked article. Actually, many cyber security researches place AWS credentials leakage as major initial access vector in the past year. While the debate on use of long lived static credentials is out of the scope of this article, you can read here more on how to avoid IAM users (and their access keys) altogether through identity federation. Bottom line is that IAM users and static keys are real cyber risk, and if you can’t avoid using them, there are mitigation measures that can be applied.

Network plane mitigation method

AWS IAM Policies have evolved over years, and allow/deny statements can be crafted based on number of request context keys, with aws:SourceIp being one of them. So, even if your AWS access keys leak somehow, they can be useless for exploit outside of your network (to be more precise outside any device that has the same public IP address as yourself), if access policy such as below is attached to your IAM user. As Ip conditions work with CIDR ranges, you can either use a single ip (/32) or a full range. Potential issue with such approach is locking yourself out via public IP address change. This can be avoided by either using different credentials for IAM administration and control that are session based, or by poking a hole in IAM policy that allows for iam:PutUserPolicy action

{
  "Effect": "Deny",
  "Action": "*",  // beware as this includes iam:PutUserPolicy
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": [
        "<YourIpHere>/32"   
      ]
    }
  }
}

Tooling

aws-keys-sectool is a tiny Python/boto3 based tool I’ve build that can help out with the task of creating IP address based AWS access keys protection, and can be installed via pip3. You can provide your own IP, or let the tool figure it out for you. Additionally, backdoor access for iam:PutUserPolicy can be optionally added — it will allow this action to be executed from ANY ip, however with UA based restriction involving user ARN hash. See the tool in action below. You can also check out the tool’s source code on GitHub.