David Clinton
Outline
All the tutorials in this course:
- Introduction to EC2 Security
- The Basics
- Controlling External (Application) Access
- Controlling Internal (Administration) Connectivity
Great to see you here! Allow me to quickly introduce myself so you can get to the content without any any unnecessary delay.
I'm an AWS solutions architect and Linux server administrator from Toronto, Canada. I've been creating technology training content for more than a decade. In that time, more than 60,000 of my books were sold and more than a half a million people just like you viewed my video courses.
Let's see whether I can deliver some solid value to you, too.
One general note: You're perfectly welcome to simply watch the videos and absorb the information. But actually getting your hands dirty by running everything you see here on your own machine will give the information a real turbo-boost. Keep an eye on the notes to each lesson for code and guides that'll help you recreate all of the demos you'll see here.
I'm afraid I'm going to have to start this course off with some bad news. Before you can really improve the security of your Amazon EC2 instances, you'll need to get a handle on all the stuff that can go wrong. And I'll give you a bit of a "hall of shame" rundown in just a minute. But first, by way of introduction, I want to tell you a really scary story. So scary, that you should perhaps prepare by turning on all the lights in your room and grabbing a soft blanket for comfort.
Here goes. Based on my own past experiences, I just conducted a brief experiment. I launched an EC2 instance running Ubuntu into one of my AWS accounts. The instance wasn't running anything more than whatever Ubuntu gave me by default and it wasn't associated with any DNS addresses. Its only connection with the outside world was through the public IP address AWS assigned it. In fact, the only difference between this instance and one that you or I might normally run is that I opened up its security group to permit all incoming traffic. Since Ubuntu, by default, doesn't run an active firewall, there would therefore be nothing standing between the instance and the big bad internet.
So what happened? Well, take a look at these auth.log entries for yourself. According to the logs, the system came up for the first time at around 14:56. Here's what I saw just 35 minutes later. Someone was trying to log in to my system via SSH using the user name root. Now, of course, by default, root login is disabled - and you should leave it that way. But that didn't stop this individual from trying. Note how they didn't use the standard SSH port 22, but this port 51912 instead. That suggests that this attempt was part of an automated script that tests various combinations of usernames, passwords, and ports.
Aug 10 15:31:17 ip-172-30-1-186 sshd[2777]: error: maximum authentication attempts exceeded for root from 20.210.53.189 port 51912 ssh2 [preauth]
But they weren't done. Over the next 75 seconds, 30 more login attempts came from this same IP address. I'm not sure how easy it will be for you to see this, but they pointed to different ports in the 50,000 range, and used different usernames like, admin, oracle, test, test1, test2, ftpuser, and pi. The fact that they tried pi tells me that they didn't realize that this was a cloud instance but that, for all they knew, it could have been a Raspberry Pi running in someone's home lab.