OPS345 Lab 1

THIS PAGE IS A DRAFT, NOT A REAL COURSE PAGE

The current schedule for OPS345 is here: OPS335_Weekly_Schedule

Accessing your AWS account

At the beginning of the semester your professor will create a Leaner Lab in AWS Academy. The professor will add all the students enrolled in their OPS345 sections as students in that Learner Lab. You should automatically receive an email that looks like this in the beginning of the course:

If you haven't recieved such an email: you need to let your professor know.

Once you complete setting up your account: you might want to bookmark this page, or even make it your home page: https://awsacademy.instructure.com

Browse around the interface. To do your work for OPS345 you only ever need to navigate to "Courses" > "AWS Academy Learner Lab - Foundation Services" > "Modules" > "Learner Lab - Foundational Services", which looks like this:

The links you'll use most often are highlighted in green:

1. This is the amount of credits you have used out of your allocated 100$. Unlike the screenshot yours will start at zero.
2. Most of your AWS resources are turned off unless your lab is started. Click this button to start the lab. There is only one lab for the entire OPS345 course, you will start it many times.
3. The amount of time the current session of the lab has been running. After the 4 hours runs out the lab will be stopped and the associated resources will be shut down.
4. Click here to get to the AWS web interface where you'll do most of your work.

Your work which you save inside your virtual machines is not deleted once the lab stops. AWS Academy simply shuts down your virtual machines. Your virtual machines and the rest of your Learner Lab resources will be deleted automatically at the end of OPS345.

The first time you start the lab it may take a few minutes, much longer than usual.

AWS cost monitoring

Normally using resources from AWS costs money. AWS costs are very competitive, but their resources are not free. In an AWS Academy Learner Lab you get a 100$ credit which will be more than enough to cover all your resources until the end of the course if you're not reckless.

You are responsible for your AWS usage!
If you run out of credits: you will have to find another way to finance completing the required hands-on parts of OPS345.

Take this as an opportunity during OPS345 to learn what costs how much money in the cloud. The skills of managing cloud costs are very valuable. Unfortunately AWS Academy doesn't make it easy for you. On the unrestricted AWS you have access to AWS Budgets, Amazon CloudWatch Billing Alarms, and other tools to help you monitor and control your costs. But due to the way AWS Academy was designed: you won't have access to those tools. That's in return for the free 100$, which most students don't complain about.

Even without the budget restrictions in AWS Academy: AWS costs are not easy to manage. Here are some examples of what you'll run into:

• Resources that say "Free" on the label, but will only be free in a specific configuration.
• Resources that are free unless you exceed some threshold of usage (CPU usage, bandwidth, etc.)
• Resources that cost money only when they are not used. That was not a typo.
• And the most common of all: resources that don't have a cost listed next to them at all.

So in order to learn anything about costs on AWS: pay attention whenever you see a note about the cost of anything, even though it will be a distraction from what you're trying to accomplish at that time. There are many places where such notes are scattered. Always keep cost in the back of your mind when doing anything on AWS. Then hopefully you'll get a general idea, so that when you're done with OPS345 you can have an intelligent conversation about it.

Basic security on a public-facing server

Security is a topic most people aren't qualified to address. That's because it's complicated on its own, but in order to set it up properly: it also requires a solid understanding of the fundamentals of the systems which need to be secured.

That doesn't mean you can't learn it. As with most technologies, the recipe for success is simple. The more time you spend on it: the better you get. Every bit of learning you do related to security will make you more qualified. The more qualified you are to speak about security issues: the more valuable you are as a technician or engineer. Even if you're not directly responsible for security of a system: you will always have to work with security measures, and sometimes around them.

Your attitude matters
Usually if you follow the rules of the organization you work for: security breaches are somebody else's problem. But not always. For example if you get your AWS Academy account suspended by Amazon because your password was "123" - I won't feel bad for you, and you will have to find a way to complete the requirements of the course. And whether it's your problem or not: wouldn't you rather be a part of the solution?

So as with AWS costs there are some steps I can tell you to follow, but overall you should take some time to think of security whenever you do anything. Who has access to a specific machine? Network? Service? Storage device? Is it hard to steal/crack a password and impersonate one of your users? Is your system vulnerable to off-the-shelf attacks? Keep those questions in the back of your mind, and as a minimum follow the following guidelines:

• Set a good password for your AWS account, and don't use that password for any resources inside AWS. Your AWS account password is like a super-root password. It gives you full access not only to a specific machine, but to all machines, networks, storage devices, and billing. You can end up running someone else's botnet, and paying for it too.
• Possibly the most common attack on a Linux machine is the brute-force SSH login attack. It takes very little setup to mitigate almost all these attacks:
  • Delete all default usernames, except root which you can't delete.
  • Make sure that root is never allowed to log in remotely.
  • Whenever possible: don't use passwords at all, use SSH keys for logging in. You've learned how to use them in OPS245.
• Learn how to use sudo and how to configure it.
• Get in the habit of organising your SSH keys so you don't accidentally lose them.

Remember that unlike ULI101/OPS245 your servers are on the real internet, and depending on how you configure them: they might be accessible by any attacker on the planet. You need to pay much more attention to security in this course than was required in ULI101/OPS245.

First AWS VM

We're going to set up a virtual machine in AWS now so you can start to get used to the process. You'll be repeating this several times during the course, try to learn a little more about it each time you do it.

Security group ops345first

A security group is a fundamental concept in AWS. It's not completely clear what it is. The closest thing you would have seen that's similar is a set of iptables rules. You can assign the security group (this set of rules) to one or more virtual machines.

A security group with no rules does not allow any traffic to pass through.

• Create a new security group "ops345first" with only the SSH port open to the world in the incoming rules. Familiarize yourself with the interface. You'll use this security group for your first VM you'll soon create.

Create firstvm

In AWS language an instance is what you've called a virtual machine in OPS245. An AMI is a pre-built disk image of an operating system, provided so that you don't need to install an operating system from scratch. The AMIs are typically provided by Amazon or the AWS community.

An AMI is only the initial disk image your VM will start with. As soon as the VM is booted for the first time: your disk image will begin to deviate from the original. That means for example that you have to keep up with security updates on it even though the AMI you used had all the security updates installed when you used it to bootstrap your instance.

With an AWS Academy account you can see what AMIs are available on AWS, but your selection is severely limited. We'll only be using the Amazon Linux AMI. You'll find it quite familiar as it was originally based on CentOS.

• Use "Launch Instances" to deploy a pre-built "Amazon Linux 2 AMI (HVM), SSD Volume Type" VM. Not one of the other Amazon Linux AMIs.
  • Instance type t2.micro - sort of kind of almost free
  • Security group "ops345first"
  • Create a new RSA key pair named ops345-first-key, save it as ops345-first-key.pem on your workstation under a new directory ~/keys/ssh/
• Differences between Amazon Linux and CentOS
  • /etc/yum.repos.d/amzn2-core.repo
  • Not linked to RedHat/IBM support cycles and policies.
• Explore the VM:
  • connect with user ec2-user, ssh key
  • Many packages not installed by default in CentOS /are/ installed by default in Amazon Linux.
  • yum install telnet
  • systemctl works the same way
  • Note neither iptables nor any other firewall is installed by default.
  • passwd, shadow, group files
  • netstat -atnup
• Create yoursenecaid user, no password, create /etc/sudoers.d/10-ops345-users with these contents:

yoursenecaid ALL=(ALL) NOPASSWD:ALL

• Allow yourself to log in using your SSH key:

# cd /home/ec2-user/
# cp -r .ssh/ ~yoursenecaid
# chown -R yoursenecaid.users ~yoursenecaid/.ssh/

• Confirm ssh in as yoursenecaid and successfully sudo su -
• Delete ec2-user including the home directory. Use the userdel command.
• Update hostname to "first.yoursenecaid.ops" and make sure it sticks:
  • https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html
  • Change the instance "Name" in the EC2 management console to "first".