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 have at least one semester's worth of experience of CentOS, so you'll find Amazon Linux

• 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

Change the default username

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

Submit evidence of your work

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