Blog   |   Security   |   March 26, 2020

The 5 AWS Security Mistakes You Might Be Making and How to Fix Them

While Amazon Web Services (AWS) handles security of their own data centers, AWS users are responsible for network, host, and application-level security. From what we have seen—from servicing single accounts with a few EC2 instances spending under $1,000 per month, or large environments with hundreds of accounts and 10,000+ EC2 instances spending over $5 million per month—it’s easy to make mistakes. We compiled this list of five common AWS security mistakes, along with best practices on how to fix them, to help you further your AWS security knowledge and keep your environment safe.

1. SNS Topic with Permissions Set to Everyone

Simple Notification Service (SNS) enables applications, end-users, and devices to instantly send and receive notifications. SNS allows you send individual messages or to fan-out messages to large numbers of recipients to mobile device users, email recipients, or to other distributed services. AWS users have the ability to control who has access to the SNS Topics, and which permissions they are granted. Permissions can be granted for these actions: ListSubscriptionsByTopic, Subscribe, DeleteTopic, GetTopicAttributes, Publish, RemovePermission, AddPermission, Receive, and SetTopicAttributes.
Users can also generate custom SNS Topic policies. Using a policy, you can configure one of the following types of users to access a SNS topic: 

  • Only me (topic owner)
  • Everyone
  • Specific AWS users 

Permissions can be set to actions such as SNS:ListSubscriptionsByTopic, SNS:Subscribe, SNS:DeleteTopic, SNS:GetTopicAttributes, SNS:Publish, SNS:RemovePermission, SNS:AddPermission, SNS:Receive, and SNS:SetTopicAttributes.

The Mistake

As a best practice, topics should never be configured with permissions granted to Everyone. Everyone is granted access by setting the follow entry in a topic policy:
“Principal”: {“AWS”: “*”}
Note, you can also restrict access by using the Condition clause in the policy. For example, you can set the Principal to Everyone, but if you set the Condition as follows, the SNS topic is not exposed to Everyone:
“Condition”: {“StringEquals”: {“AWS:SourceOwner”: “123456098762”} }
Consequently, granting permissions on a SNS Topics to Everyone is not recommended. By setting these permissions, you allow anonymous attackers to read or upload messages into the topic. This creates risks including economic denial-of-service attacks, information leakage, or SQL injection. 

How to Fix It

CloudCheckr will automatically alert you if someone within your team does accidentally set these permissions.

2. Failure to Enable AWS Config

AWS Config provides the resource inventory, configuration history, and configuration change notifications in your AWS account. It allows you to view all configuration details for a resource, and determine how a resource was configured at any point in time.

The Mistake

Some AWS users are not taking advantage of AWS Config. It’s important to have AWS Config enabled within each region of your AWS account so you can always tell exactly how your AWS deployment is configured, and know what has been added/deleted/modified at any point in time. 

How to Fix It

Using AWS Config in conjunction with CloudCheckr ensures that you are able to meet your audit requirements.

3. Broad IP Range and Port Access for EC2-Classic Security Groups Inbound Rules

EC2 security groups act like a firewall, controlling the traffic allowed into a group of instances. Each instance can be assigned one or more security groups, and each group has its own rules that govern the allowed inbound traffic. All other inbound traffic is discarded.

The Mistake

To protect instances, security groups should only allow traffic from specified ports. Opening all ports for any security group is highly discouraged as it opens the instance up to potentially unwanted traffic. 

How to Fix It

CloudCheckr provides alerts and reports to ensure that users do not leave themselves vulnerable through using broad IP range rules.

4. Root Account Access Keys and Root User Access

An access key is required in order to sign requests that you make using the command-line interface (CLI), using the AWS SDKs, or using direct API calls. Anyone who has the access key for your root account has unrestricted access to all the resources in your account, including billing information.

The Mistake

A cloud management best practice we’d recommend is to not have an access key for your root account at all. Instead, you can create one or more AWS Identity and Access Management (IAM) users, give them the necessary permissions, and use IAM users for everyday interaction with AWS. For more information, see IAM Best Practices in the Using IAM guide.
Each AWS account has root access, which is not bound by IAM policies, created for the person that setup the AWS account. Any interaction against the AWS account from this user role is logged as “root” in CloudTrail.
Since these interactions are logged as “root” they cannot be traced back to a specific individual. This makes it very difficult to know exactly who is performing tasks such as starting EC2 instances or modifying security groups.

How to Fix It

It is highly recommended that all individuals that will be accessing your AWS account be given their own IAM user so all interactions can be properly monitored using CloudTrail. CloudCheckr automatically alerts users to when they are using the root user or access key.

5. Broad IP Range Access for Redshift Security Groups Inbound Rules

AWS security groups act like a firewall, controlling the traffic allowed into your Redshift clusters. Each cluster can be assigned one or more security groups, and each group has rules that govern the allowed inbound traffic. All other inbound traffic is discarded.
To protect clusters, only specific IP ranges should be specified for a security group and only needed ports should be exposed. 

The Mistake

Leaving a security group open to a broad range of IP addresses is discouraged because it creates a large attack surface for an attacker. 

How to Fix It

CloudCheckr provides alerts and reports to ensure that users are protected against this vulnerability.

Security management in AWS

The nature of managing a cloud environment can feel daunting, and beginners often make mistakes. One of the benefits of AWS—and cloud in general—is that your environment is flexible and scalable, so you can make changes and evolve your security over time. CloudCheckr can help users monitor and manage all of these issues (and many others).
Only CloudCheckr delivers total visibility, making the most complex cloud infrastructures easier to manage. CloudCheckr customers deploy our total visibility platform to secure, manage, and govern the most sensitive environments in the world—from government agencies to large enterprises to MSPs.

AWS Security Best Practices and Fixes with CloudCheckr

See how CloudCheckr can drastically simplify your cloud cost management. Request your free CloudCheckr trial now.