OPS345 Lab 1

From CDOT Wiki
Revision as of 18:33, 8 December 2021 by Andrew (talk | contribs) (Basic security on a public-facing server)
Jump to: navigation, search

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:

AWSAcademyInvitation.png

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:

AWSAcademyLearnerLabHomeScreen.png

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.

Important.png
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.

Idea.png
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 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.

First AWS VM

  • Create a new security group "ops345first" with only the SSH port open. We'll look at security groups in more detail next week.
  • Instance == VM. AMI == VM disk image.
  • Lots of AMIs appear to be available, only Amazon Linux works with AWS Academy.
  • 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/