Prerequisites

• An account with GuardDuty enabled in us-west-2 Oregon (all set if you’ve been following these labs).

• Email alerts set up for GuardDuty notifications (also set up in previous labs).

The Lesson

You have all been more than patient as I’ve dragged you along on this security journey. Yes, I try to keep things as interesting as possible and provide context, but sometimes you just need to jump off a bridge to prove a point.

(I’m talking about bungee jumping to get over your fear of heights, or a really short bridge. Securosis, LLC does not recommend jumping off bridges and takes no responsibilities for your personal decisions).

In today’s lab we’ll deploy a nice juicy target on the Internet, and then see if any sharks bite.

Here’s the deal:

• This week’s CloudFormation template will deploy an EC2 instance on a public subnet with port 22 (SSH) open to the Internet.

• The instance won’t have any SSH keys provisioned, and won’t have an IAM role (instance profile).

  • Without an SSH key or a username/password there is no way for an attacker to brute force their way in.

  • Without an IAM role, and with nothing else on the subnet, even if the attacker does find some unknown vulnerability and compromise the instance, they can’t harm anything else. They won’t be able to make any AWS API calls (no role assigned), and there’s nothing else on the network to attack.

• Our instance will be on the free tier.

• Our VPC will only have an Internet Gateway, which is free, and won’t have a NAT Gateway or VPC endpoints.

• You will be charged a nominal amount for the IP address (this changed over the past year).

We’ll set this up and let it run. If all goes ‘well’, some adversary will try to exploit it. Depending on how they attack (and let’s be honest — there will be plenty of attacks), GuardDuty will trigger and you’ll get an email alert.

Is this a guarantee? Nope. I absolutely guarantee any server with port 22 exposed to the Internet will be attacked eventually. But GuardDuty can be picky about when it decides to trigger on this particular attack. I actually built an attack simulator for our Incident Response training, and although it includes an SSH brute force like this, it rarely actually triggers GuardDuty.

My hope is that the bad folks on the Internet will be a bit more aggressive and determined than my little tool.

Why This Works

“Things exposed to the Internet” is one of the top 2 ways cloud installations get compromised. Attackers continuously scan for exposed servers, especially SSH, and especially in the IP address ranges of cloud providers like AWS.

GuardDuty has a built-in detector for some of these attacks, including brute force attempts to break into SSH.

In our AWS Organization we configured 3 things which result in us seeing email for GuardDuty findings in any region of any account in our org:

• GuardDuty is set up with delegated administration, and we set it to automatically deploy in all accounts and all active regions (in our case limited to Oregon and Virginia, thanks to our Service Control Policy).

• SecurityHub is also set up with delegated administration, and is configured to collect all findings from all AWS security tools across all our accounts and regions in one central place. This includes GuardDuty.

• We set up an EventBridge rule to email us any SecurityHub findings.

This is what we’ve been building towards. A default-secure organization with protection spanning all accounts and regions.

And this will also hopefully show you why Session Manager is a much better choice than SSH.

There’s no guarantee this will work, since we can’t control attackers or GuardDuty, but my experience says the odds are that if you leave it running for a few days or weeks, an attacker will trigger it.

Key Lesson Points

• If you make things public on the Internet, someone will attack them.

• Setting up automated guardrails, including detective controls, reduces your security exposure.

The Lab

This is our easiest one yet. All we need to do is deploy a CloudFormation template, and … wait.

Video Walkthrough

Step-by-Step

Got to your Sign-In Portal > TestAccount1 > AdministratorAccess, then CloudFormation > Create Stack. Use the template linked right below this paragraph, and name it “Exposed”. This is the first stack we plan to leave running in this account for a while, so make sure you don’t cross the wires in a future lab and delete it too early:

https://cloudslaw.s3.us-west-2.amazonaws.com/lab36.template

Then click past the next screens and Submit.

This template will take 2-3 minutes to deploy. You can check out what we did by going over to EC2 and clicking on the only instance that should be running. Then make sure it has a public IP address and the security group exposes port 22 to 0.0.0.0/0:

And now… we wait! Feel free to email me at [email protected] when you get a GuardDuty notification email. There is no guarantee, but odds are that if you leave this running long enough you’ll get an alert.

Lab Key Points

• Don’t expose port 22, or much of anything, to the Internet.

-Rich