Your personal AWS setup (and how to not get hacked)

In 2016 hackers compromised my personal AWS setup. Within a matter of hours I received an AWS bill for $3000 dollars 😱😱😱😱

When you’re a Cloud Native Engineer one of the best ways we can learn is through experimenting directly on cloud platforms, like AWS. But, doing so can be fraught with difficulties if you’re not careful when you setup and use your cloud account. An incorrectly setup account is vulnerable to hackers and you could even end up with a massive bill!

By the end of this article you’ll know all the steps to take before accessing your AWS cloud account so that you can experiment and learn about AWS.

Why setting up your cloud account is so important

The best way to show you how important it is to setup your cloud account is through telling you aforementioned tale of the $3000 AWS bill.

It was 2016 and I was getting charged for having too many private repositories on Github.

To try and cut back I decided to switch a handful of my private repositories back to public access.

But, in haste I forgot that a repository I made public had my private AWS credentials exposed.

I was feeling rather smug that I was saving an extra $7 a month. But within a few days I got a strange looking email that caught my eye…

Holy shit!

Up until this point I’d been paying only a couple of pounds a month for my billing. And to make matters worse the enormous bill was accrued in a matter of hours. So with every hour that went by I was getting charged hundreds of pounds. Time was of the essence… I logged into my account and furiously started closing down resources. Some resources I’d never even heard of!

By now you might be wondering: how exactly did my account get hacked?

Let me explain…

There are automated tools that are scanning the web for leaked credentials. When the tool does find your credentials it uses them to make programattic API calls that launch as many resources as possible. My AWS account was now part of an extremely large, and very illegal botnet.

At the time I didn’t even know such a thing was possible. And if you’re not careful you could be at risk, too.

But, don’t worry it’s not all doom and gloom! There are ways that you can these types of hackers, and that’s what we’ve going to talk about today.

I’m going to walk you through four simple steps that you should take before you start experimenting on your AWS account.

First up…

1) Don’t use your root credentials

The root credentials are the username and password that you used to sign up to AWS with. You should only use your root account credentials in emergencies.

Our root account has full access to all resources and all permissions on AWS. Which is what gave the hacker full rights in spinning up as many resources as they wanted. So the first thing you want to do when you’ve got an AWS account is *stop using your root credentials. *

So when you’ve signed up to AWS and have your account handy, follow the upcoming steps and then store your password away somewhere safe, and don’t use it unless it’s an emergency. But, if I’m telling you not to use the root account, how should you access and use AWS account?

Let’s cover this now!

2) Create an admin user

In the next two steps we’ll be creating two users. But for now, let’s focus on the first, our admin user.

I imagine right about now you’re thinking: but why we need a new user? If it’s only one person accessing our account? Isn’t this overkill?

Because the notion of a user gives us granularity when assigning permissions, even if the users are used by the same person. And with the users feature we can ensure that the user account we’re using day-to-day has as few permissions as possible.

The concept of restricted user access is known as the principle of least privilege. The reason the hacker who compromised my account was able to cause so much damage was due to the fact that I used my root account with full access. By creating new users we can limit the damage that could be caused if our account is compromised.

To create users we’ll use the IAM service. The AWS IAM service is how AWS users and permissions are created and delegated. Don’t worry about the service too much at this stage. Follow along and you’ll be able to experiment once you’re setup properly.

Okay, so let’s look at the actual steps we need to perform to setup that first user:

• Add your user by going to: Services > IAM > Users > Add User and call this user admin .
• Create a group by going to: Services > IAM > Groups > Create New Group. Call this group admins and assign the policy AdministratorAccess.
• Assign your admin user to your new group

3) Create a developer user

Awesome, that’s one user created!

Next, let’s create our developer user.

We’ll use our developer user for everyday use, and it will be assigned only the needed permissions.

• Add your first user by going to: Services > IAM > Users > Add User and call this user developer .
• Create a group by going to: Services > IAM > Groups > Create New Group. Call this group developers and assign the policy AmazonEC2FullAccess.
• Assign your admin user to your new group

These steps might seem heavy-handed but using this process we’re going to restrict the access that our developer credentials has.

If someone compromises the admin account the attacker will need your MFA device to login. But if someone compromises your developer the damages the the attacker can do will be limited by the permissions you’ve assigned. So where possible keep these restrictions tight. If you need you can always remove permissions after you’ve performed any kind of account creation type activity.

So, to summarise our new user setup and workflow, you’ll have…

• A root account with a hidden password for use only in emergencies.
• An Admin user for logging into the console and delegating permissions to other users.
• A developer role for use with our AWS SDK via token access which we grant only the permissions we need.

4) Enable MFA

Previously I mentioned that our admin account would have MFA enabled. MFA stands for multi-factor authentication. Essentially when we enable MFA those who are using our account require both the password and another piece of information in order to log in. MFA is useful because if our password is lost a would be attacker still cannot gain access to our account.

So let’s go ahead and enable MFA for all three of the users we just created.

You can do so by going to *Services > IAM > Your User > Security Credentials > Manage MFA > Apply. * And choose an MFA method that makes sense for you. I’m currently using the authenticator app on my phone, and all I need to do is scan a QR code and voila! I’m up and running.

I probably should mention here that if you lose the MFA device you’ll be able to recover your access by using your root account email or phone number. So ensure these are correct incase you were to lose your device!

Now you’re safe for experimentation

And that’s it, your own personal AWS setup. In the next few days I’ll be putting up another post that explains how you can setup your keys on your local machine for ease of use and simplicity. So make sure you’re signed up to the newsletter and you’ll get the post in your inbox soon! Follow these simple steps when setting up and using your AWS account. Avoid horrific AWS charges and experiment with AWS services with peace of mind!

Do you have a horror story from getting an account hacked? Let me know about it in the comments below!

---

The post Your personal AWS setup (and how to not get hacked) appeared first on The Dev Coach.

Join the community of cloud native software engineers just like you. Keep up-to-date with the latest in cloud tech and learn fundamental skills on core cloud engineering topics like: Docker. Serverless and Linux, and more.

Join us and get ahead!