DIY AWS Security Review

A regular security review of your AWS account can reveal security issues with little effort. There are some very easy things you can automatically check with the help of the AWS Command Line Interface that have a big impact.

Limit network traffic from 0.0.0.0/0

Allowing traffic from the public internet is not bad by default. You usually want your website to be reachable from the public internet (0.0.0.0/0). But you should limit the entry points into your system to keep the attack surface small.

With this tiny Bash script you can get a list and usage report of all your Security Groups that allow traffic from 0.0.0.0/0.

#!/bin/bash

sgs=$(aws ec2 describe-security-groups --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" --query "SecurityGroups[].[GroupId, GroupName]" --output text)

while read -r line; do
  sgid=$(echo $line | awk '{print $1;}')
  sgname=$(echo $line | awk '{print $2;}')
  c=$(aws ec2 describe-network-interfaces --filters "Name=group-id,Values=$sgid" --query "length(NetworkInterfaces)" --output text)
  echo "$sgid,$c,$sgname"
done <<< "$sgs"

An example output:

# Id of Security Group, How often used?, Name of Security Group
sg-11223344,1,SshBastionHost
sg-22334455,1,HttpHttpsLoadbalancer

For a common, auto scaled web environment you only need to allow traffic from 0.0.0.0/0 on port 80/443 on the load balancers (ELB). Your backend behind the ELBs allows traffic based on the source security group that is attached to the ELB.
Most often, you also need SSH access to your environment from 0.0.0.0/0 on port 22. But only to the bastion host. All other machines allow incoming traffic on port 22 only from the source security group of the bastion host.

Avoid unused Security Groups

If you accumulate Security Groups over time it gets harder and harder to find out what is really used.

With this tiny Bash script you can get a list and usage report of all your Security Groups.

#!/bin/bash

sgs=$(aws ec2 describe-security-groups --query "SecurityGroups[].[GroupId, GroupName]" --output text)

while read -r line; do
  sgid=$(echo $line | awk '{print $1;}')
  sgname=$(echo $line | awk '{print $2;}')
  c=$(aws ec2 describe-network-interfaces --filters "Name=group-id,Values=$sgid" --query "length(NetworkInterfaces)" --output text)
  echo "$sgid,$c,$sgname"
done <<< "$sgs"

An example output:

# Id of Security Group, How often used?, Name of Security Group
sg-11223344,1,SshBastionHost
sg-22334455,1,HttpHttpsLoadbalancer
sg-33445566,0,NoLongerInUse

The best way to avoid unused AWS resources altogether is to implement Infrastructure as Code.

Activate MFA for all your IAM users

Relying only on a password to get access to your AWS account is not recommended. Instead you should enable Multi-factor authentication (MFA).

With this tiny Bash script you can get a list of all your IAM users. A zero after the username indicates that MFA is not enabled.

#!/bin/bash

usernames=$(aws iam list-users --query "Users[].[UserName]" --output text)

while read -r username; do
  c=$(aws iam list-mfa-devices --user-name "$username" --query "length(MFADevices)" --output text)
  echo "$username,$c"
done <<< "$usernames"

An example output:

michael,1
andreas,1
insecure,0

In your Your single AWS account is a serious risk I describe an even better way to deal with IAM users.

Activate MFA for your root user

Every AWS account has a root user. You should not use the root user in your daily work. Instead you should create an IAM user. Nevertheless your root user should also be protected with Multi-factor authentication (MFA).

With this tiny Bash script you can check if your root user has MFA enabled. A zero indicates that MFA is not enabled.

#!/bin/bash

aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"

An example output:

1