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 ops435-first VM

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.

• To create a new virtual machine you need to go to "Instances" and click "Launch Instances". An unfortunate choice of words by Amazon. It sounds like that button should start an existing instance. It should have been called "Create Instance".

The first time you go through this process try to concentrate on not getting overwhelmed by the available options and the unintelligible AWS lingo. You'll have lots of opportunities to better understand the available options.

• Select the "Amazon Linux 2 AMI (HVM), SSD" AMI.
• Don't use the "Review and Launch" button instead go through each of the 7 steps.
• Leave the t2.micro default checked and click Next.
• Leave all the defaults under Instance Details.
• Don't change the storage configuration under Add Storage
• Don't add any tags under Add Tags.
• Create a new security group named "ops345first", leave the default SSH rule for the world in it.

After you review your configuration and click "Launch" a popup will come up asking you for a key pair. It's important for you to understand what it's asking for. It is the same type of SSH key pair that you've created and used in the OPS245 Lab 7. Remember that your private key is yours, it's private to you, and not for anyone else to see. AWS is asking you to give them the public key which is the pair of the private key which you wish to use to log in to your new VM. In this case your private key is the effective equivalent of the root password.

• Create a new RSA key pair named ops345-first-key, and download it as ops345-first-key.pem on your workstation under a new directory ~/keys/ssh/

Yes, that means AWS generated your private key and theoreticaly they could keep it, but they promise that they don't and that's almost certainly true. Once you donwload the private key and click "Launch Instances" - the only way to log into your new virtual machine is using the private key you saved. AWS does not provide the equivalent option of "reset your password" for instances that were already created.

• After your instance is created: you will see it listed under "Instances". Set its name to "ops435-first". Get used to naming things in AWS because otherwise you'll have a hard time distinguishing your instances from each other, unless you're unusually good at remembering long random strings of characters.

Explore your new VM

You're not going to find a button in the AWS to "view the screen" of your virtual machine. The only way to control it is via an SSH connection.

Look at your ops435-first instance details and find its automatically-assigned public IP address. Connect to it with SSH. Note that you need to user your private key to connect, and since it doesn't have a default name nor is it in the default location for SSH keys: you need to specify the path to it manually.

The default username on Amazon Linux is ec2-user.

You have at least one semester's worth of experience of CentOS, so look around to see if anything looks different from what you're used to. For example:

• Many packages not installed by default in the Minimal installation of CentOS (e.g. net-tools) are installed by default in Amazon Linux. I like to also install telnet and nmap.
  • Note that Amazon Linux has its own package repositories: /etc/yum.repos.d/, but the yum/rpm commands work the same as in CentOS.
• The systemctl command to control your services works the same way as in CentOS.
• Note neither iptables nor any other firewall is installed by default. It is in CentOS.
• You user information files (/etc/passwd, /etc/shadow, /etc/group) are used in a completely standard way.
• Have a look at the output of netstat -atnp and netstat -aunp to see what ports services are listening on in a default installation.

It's not completely clear what Amazon's policies are for supporting Amazon Linux. From people's experience it appears to be quite stable, but as a rolling release you might not want to depend on it for production use. For our learning purposes it's plenty stable and consistent. One nice thing about Amazon Linux is that it is not linked to RedHat/IBM support cycles and policies which have changed significantly after IBM's acquisition of RedHat.

Change the default username

For security purposes we're going to remove the default ec2-user. That would be simple if you were sitting in front of the machine, but since you can only connect to it via SSH and the only user you can SSH as is ec2-user: it takes some extra work. You're going to do this for every machine you create in OPS345, so get used to the steps. It's good practice:

• Use the useradd command to create a new user. To make your life easier: set the username to be the same as your myseneca username, with the same capitalization.

You do not need to set a password for this user. Passwords can be guessed using a brute-force attack. SSH keys are practically immune to such attacks.

• Make sure your new user can run sudo without a password, same as ec2-user. Create /etc/sudoers.d/10-ops345-users with these contents:

yoursenecaid ALL=(ALL) NOPASSWD:ALL

• Allow your new user to log in using the SSH key you already have. You could create a new key pair instead, but you don't have to. Remember that your username is not asmith15:

• Confirm ssh into your VM as yoursenecaid and successfully sudo su -
• After you're sure that you can: delete ec2-user including the home directory. Use the userdel command.

Set the hostname

For reasons that are hard to explain quickly the hostname on your AWS VM is not static by default, but we'll make it static so it's more familiar to you.

• Update the 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".

Submit evidence of your work

For this lab, please submit screenshots that show you've completed the work: