Lab 2 - AWS VPC and Security Groups

Table of Contents

In this lab, you’re going to create a small startup office for Tiger Enterprises, Inc., in the form of virtual machines at AWS. You’ll have a basic Linux desktop for “end user work”. But unlike last time — where the VM was deleted immediately after use — this time you’re going to keep the VM around.

Objectives:

  • Create a AWS Virtual Private Cloud (VPC) - Place the VMs in the same network with NAT access to the internet
  • Create a EC2 Security Group
  • Configure and launch a virtual machine to serve as a generic Linux desktop

AWS Virtual Private Cloud (VPC)

Before creating any new virtual machines, create a virtual network that will accommodate some initial Tiger Enterprises devices. Amazon Virtual Private Cloud (VPC) lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.

Resources:

Configuration Steps to Create a VPC

Warning! Do not run the VPC Wizard multiple times! It will create multiple virtual private clouds with multiple independent resources. If you get stuck and need to repeat the setup, contact the instructor first to ensure that the old VPC is fully cleaned up before a new VPC is created. This becomes increasingly harder to do the more labs are completed, because instances are created within a specific VPC and cannot be easily migrated.

  • Login to the AWS Management Console (via https://awsacademy.instructure.com/)
  • In the search bar at top, search for "VPC" and enter that dashboard. (Or, it is under the Services dropdown under the Networking & Content Delivery category)
  • Choose "Launch VPC Wizard"

VPC Setup

  • Select "VPC with a Single Public Subnet" - this will give us a very basic network with a public subnet (where we might put some servers that are accessible over the internet). In a perfect world, we would also have a private subnet (while we might put some back-end servers that are not accessible over the internet), but the per-hour charge of an AWS "NAT Gateway" to accomplish that is excessive. The configuration is described in substantial detail here: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario1.html

  • Enter the following configuration options for your new VPC:

    • IPv4 CIDR block: 10.101.0.0/16 (this gives us 65,536 private IP addresses)
    • IPv6 CIDR block: No IPv6 CIDR block
    • VPC Name: Tiger-VPC
    • Public subnet’s IPv4 CIDR: 10.101.0.0/24 (this gives us a public subnet with 256 addresses)
    • Availability zone: No preference
    • Public subnet name: Tiger-VPC-Public
    • Enable DNS hostnames: Yes
    • Hardware tenancy: Default

  • Select “Create VPC” and watch the spinning progress bar

Finally, modify the public IPv4 addressing attribute for your subnet. The goal is - if an instance is created in the “Tiger-VPC-Public” subnet, then it should receive a public IP from Amazon for as long as it is running.

AWS Security Groups

What is a Security group? From the AWS documentation:

A security group acts as a virtual firewall for your EC2 instances to control incoming and outgoing traffic. Inbound rules control the incoming traffic to your instance, and outbound rules control the outgoing traffic from your instance. When you launch an instance, you can specify one or more security groups. If you don't specify a security group, Amazon EC2 uses the default security group. You can add rules to each security group that allow traffic to or from its associated instances. You can modify the rules for a security group at any time. New and modified rules are automatically applied to all instances that are associated with the security group. When Amazon EC2 decides whether to allow traffic to reach an instance, it evaluates all of the rules from all of the security groups that are associated with the instance.

When you launch an instance in a VPC, you must specify a security group that's created for that VPC. After you launch an instance, you can change its security groups. Security groups are associated with network interfaces. Changing an instance's security groups changes the security groups associated with the primary network interface (eth0).

Resources:

Create a security group now to be used later:

  • Go to Services -> EC2 -> Network & Security -> Security Groups
  • Choose “Create Security Group"
    • Security group name: Tiger-SG-Linux-Desktop
    • Description: Linux Desktops (allow SSH and ICMP)
    • VPC: Tiger-VPC (you may need to X out the default value to see other VPC choices)
    • Inbound rules:
      • SSH from source Anywhere-IPv4
      • All ICMP - IPv4 from source Anywhere-IPv4 (This permits ICMP pings for network debugging)
      • RDP from source Anywhere-IPv4 (This permits Remote Desktop Protocol for GUI access)
    • Leave the Outbound rules unchanged - All traffic should be permitted outbound
    • Choose "Create Security Group"

Virtual Machine - Ubuntu Server 20.04 LTS + Desktop packages

Go back to the AWS console (https://console.aws.amazon.com/) and use the “Launch a virtual machine” wizard to create this new VM. Follow the general process from the previous lab, making careful note to satisfy all the following requirements:

  • AMI: Latest Amazon-provided Ubuntu 20.04 image - x86_64
  • Instance type: t2.medium (2 vCPU, 4 GiB memory) - It’s not possible to run a usable GUI on the smallest EC2 instances
  • Network: "Tiger-VPC"
  • Subnet: "Tiger-VPC-Public"
  • Auto-assign Public IP: Use Subnet setting (enable)
  • Storage: 8GiB with "Delete on Termination" enabled
  • Tag: Name = “Desktop: Ubuntu 20.04"
  • Security Group: Use existing security group: “Tiger-SG-Linux-Desktop"
  • Keypair: Existing keypair / “COMP-175-Lab-1"
  • The instance will now start. When finished, connect to it
  • Go to EC2->Instances->Instances
  • Right-click on your new desktop instance
  • Choose “Connect"
  • Choose “SSH client” as the connection method
  • Observe that AWS helpfully tells you the username ("ubuntu”), the private key file to use, and the IP address and DNS name (interchangeable) of your instance to connect to.

At this point, you have a Ubuntu server ready to go. Really, just a barebones, command-line only OS install. Now let's install all the packages necessary to make it into a desktop. Here we’re going to use the MATE variant, which has a more lightweight display engine.

Connect via your SSH client (like you did in Lab 1). Then, install a desktop environment. 

$ sudo apt update  # Always good to check for the most recent files FIRST
$ sudo apt install ubuntu-mate-core  # Now install the meta-package of all the desktop pieces
# YES to download all the additional files
# Select the gdm3 display manager
# This might take ~10 minutes.  Feel free to skip ahead to the next section and work on it in parallel.

Now install Xrdp, an open-source implementation of the Microsoft Remote Desktop Protocol (RDP) system. This will allow you to graphically control your desktop in the cloud. See: https://linuxize.com/post/how-to-install-xrdp-on-ubuntu-20-04/

$ sudo apt install xrdp
$ sudo adduser xrdp ssl-cert

Restart the Xrdp service for changes to take effect:

$ sudo systemctl restart xrdp

Set a password for your ubuntu username - Make it a good one, this is internet-accessible!

$ sudo passwd ubuntu
# Enter your password when prompted, and confirm

Note: You needed to do this because RDP requires a password login, whereas for SSH you were using the security key file in lieu of a human password.

Use a remote desktop client on your local computer to connect to the linux VM and obtain the deliverable(s) described at the end of the lab.

  • For Windows: Client is pre-installed
  • For Mac: Client can be downloaded from the App Store
  • For Linux (Ubuntu): The "Remmina" client is pre-installed and sufficient for remote desktop connections.
  • Connect to either the PUBLIC IP or the hostname (ec2-XX-YY-ZZ-AA.compute-1.amazonaws.com). You can find this information in the AWS Console for your instance. Your username is "ec2-user" (that's what AWS defaulted when the OS was created), and your password is whatever you picked previously. Don't use a gateway, and if a warning appears about the remote server identity not being verified, you can ignore it. (Perhaps a task to configure for a future lab?)
  • Tips for better remote desktop performance
    • Turn off any option that uses full screen by default
    • Specify a resolution in your RDP client. 1280x1024 is a reasonable value.

As part of submitting the Canvas assignment, after taking the required screenshots you should STOP your virtual machines, not terminate them. We'll use these instances again in future labs, and thus want to save the configuration and OS data.

Lab Deliverables

Upload to the Lab 2 Canvas assignment all the lab deliverables to demonstrate your work:

  • Screenshot of the Linux desktop in your running VM showing the Chromium web browser running and at some webpage.
  • Screenshot of your AWS console (EC2->Instances) showing that you have STOPPED your Linux VM at the completion of the lab. (You are NOT terminating it, which would destroy the VM configurations permanently. You’re merely turning it off at the end of the work day) The instance state should be “stopped” in this screenshot.
    • Select each instance and choose Actions->Instance State->Stop
  • Essay Question: What specific Amazon resource are you STILL PAYING FOR on an hourly basis, even after stopping your EC2 instance?
    • Hint: The item I’m thinking of can be found under the EC2 service dashboard
  • Essay Question: If I have a security group specified in AWS for my instance, do I also need to configure a host-based firewall (i.e. inside Linux or inside Windows)? Why or why not?