COMP 4635 - W3 Lab 4: Creating a VPC Networking Environment for the Café

--- tags: comp4635(2025) --- # COMP 4635 - W3 Lab 4: Creating a VPC Networking Environment for the Café (Challenge Lab) ## Code of Ethics :::danger * The lab exercises for the course should be attempted ONLY INSIDE THE SECLUDED LAB ENVIRONMENT documented or provided. Please note that most of the attacks described in the lab sheet would be ILLEGAL if attempted on machines that you do not have explicit permission to test and attack. The university, course lecturer, lab instructors and teaching assistants assume no responsibility for any actions performed outside the secluded lab. * The lab network should be regarded as a hostile environment. No sensitive information should be stored on your virtual machine that someone is able to gain access to it. * Do not intentionally disrupt other students who are working in the labs or hack into other student's physical or virtual machines. ::: ## Method of Submission In the following lab, each checkpoint will require you to submit some files **with designated names**. Put all files into a folder and compress them into a ZIP archive named `w3lab4-<your-id>.zip`, where `<your-id>` should be replaced with your student ID. Submit the ZIP archive [on Canvas](https://canvas.ust.hk/courses/63913/assignments/385093). There are in total **13** checkpoints. The base mark is **27** points. ## Accessing the AWS Management Console 1. At the top of [the lab's Canvas page](https://awsacademy.instructure.com/courses/124954/assignments/1420720) (login if necessary), choose ▶ **Start Lab**. - The lab session starts. - A timer displays at the top of the page and shows the time remaining in the session. 💡**Tip:** To refresh the session length at any time, choose ▶ **Start Lab** again before the timer reaches 0:00. - Before you continue, wait until the circle icon to the right of the AWS● link in the upper-left corner turns green. When the lab environment is ready, the AWS Details panel will also display. 2. To connect to the AWS Management Console, choose the **AWS** link in the upper-left corner, above the terminal window. - A new browser tab opens and connects you to the console. 💡**Tip:** If a new browser tab does not open, a banner or icon is usually at the top of your browser with the message that your browser is preventing the site from opening pop-up windows. Choose the banner or icon, and then choose **Allow pop-ups**. 3. Arrange the AWS Management Console tab so that it displays alongside these instructions. Ideally, you will be able to see both browser tabs at the same time, to make it easier to follow the lab steps. ⚠ **Do not change the Region unless instructed to do so**. 4. The instructions provided in the lab's Canvas page may look similar, but submission details only exist in this one, and there may be changes that could affect your grading. Therefore, please refer to this lab sheet. 5. In this lab environment, access to AWS services and service actions might be restricted to the ones that are needed to complete the lab instructions. You might encounter errors if you attempt to access other services or perform actions beyond the ones that are described in this lab. ## Scenario Sofía and Nikhil are  confident in their ability to create a two-tier architecture because of their experience migrating the café's data. They successfully moved from a MariaDB database on an Amazon Elastic Compute Cloud (Amazon EC2) instance to an Amazon Relational Database Service (Amazon RDS) database instance. In addition, they also moved their database resources from a public subnet to a private subnet. When Mateo—a café regular and an AWS systems administrator and engineer—visits the café, Sofía and Nikhil tell him about the database migration. Mateo tells them that they can enhance security by running the café's application server in another private subnet that's separate from the database instance. They could then go through a bastion host (or jump box) to gain administrative access to the application server. The application server must also be able to download needed patches. Knowing that [the cloud makes experimentation easier](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/), Sofía and Nikhil are eager to set up a nonproduction VPC environment. They can use it to implement the new architecture and test different security layers without accidentally disrupting the café's production environment. ## Objectives In this lab, you use Amazon Virtual Private Cloud (Amazon VPC) to create a networking environment on AWS and implement security layers to protect your resources. After completing this lab, you should be able to do the following: * Create a virtual private cloud (VPC) environment that you can use to securely connect to private resources. * Enable your private resources to connect to the internet. * Create an additional layer of security by using a NAT gateway to control access to and from private resources. When you start the lab, you will have only a VPC created for you in the AWS account. At the end of this lab, your architecture should look like the following example: ![Image shows the final architecture with all components placed in respective subnets and security groups.](https://hackmd.io/_uploads/HyXqfNKEge.png) (In the diagram, the communication arrows were omitted for simplicity.) **Note**: In this challenge lab, step-by-step instructions are not provided for most of the tasks. You must figure out how to complete the tasks on your own. ## A business request for the café: Creating a VPC network that the café staff can use to remotely and securely administer the web application server (Challenge 1) In this challenge, you take on the role of one of the café's system administrators. You create and configure a VPC network so that you can securely connect from a bastion host in a public subnet to an EC2 instance in a private subnet. You also create a NAT gateway to enable the EC2 instance in your private subnet to access the internet. ### Task 1: Creating a public subnet Your first task in this lab is to create a public subnet in the Lab VPC. After you create a public subnet, you create an internet gateway to allow communication from the subnet to the internet. You update the routing table that's attached to the subnet to route internet-bound network traffic through the internet gateway. 1. Open the Amazon VPC console. Note that a VPC called **Lab VPC** has been created for you. 2. Create a public subnet with the following options: * **VPC ID**: Choose **Lab VPC**. * **Subnet name**: Enter `Public Subnet`. * **Availability Zone**: Choose Availability Zone **a** in your Region. For example, if your Region is **us-east-1**, choose **us-east-1a**. * **IPv4 subnet CIDR block**: Enter `10.0.0.0/24`. 3. Create a new internet gateway and attach it to the Lab VPC. * **Name tag**: Enter `Lab IGW`. :::success ### Checkpoint 1 (2 marks) Submit a screenshot, named **`cp1.{png/jpg/jpeg}`**, showing the created internet gateway. Make sure your screenshot shows the following: - The name of the internet gateway - It is attached to Lab VPC, a VPC you should have created ::: 4. Edit the route table that was created in your VPC by adding the route `0.0.0.0/0`. For the target, choose the internet gateway that you created in the previous step. **Hint**: To successfully complete this task, you must create a few resources. If you get stuck, see the [AWS Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). :::success ### Checkpoint 2 (2 marks) Submit a screenshot, named **`cp2.{png/jpg/jpeg}`**, showing the routes of the route table. Take the screenshot with the **Routes** tab open. Make sure your screenshot shows the following: - The VPC the table belongs to - The newly-added route ::: ### Task 2: Creating a bastion host In this task, you create a bastion host in the public subnet. In later tasks, you create an EC2 instance in a private subnet and connect to it from this bastion host. 5. From the Amazon EC2 console, create an EC2 instance in the public subnet of the Lab VPC. Configure the following options: * For **Name**, enter `Bastion Host`. * For **Amazon Machine Image (AMI)**, choose **Amazon Linux 2023 AMI**. * For **Instance type**, choose **t2.micro**. * For **Key pair name - _required_**, choose **vockey**. * In the **Network settings** section, choose **Edit**, and configure the following options: * For **VPC - _required_**, choose **Lab VPC**. * For **Subnet**, choose **Public Subnet**. * For **Auto-assign public IP**, choose **Enable**. * For **Security group**, create a security group called `Bastion Host SG` that allows only the following traffic: * For **Type**, choose **ssh**. * For **Port**, enter `22`. * For **Source type**, choose **My IP**. **Note:** In practice, hardening a bastion host involves more work than only restricting Secure Shell (SSH) traffic from your IP address. A bastion host is typically placed in a network that's closed off from other networks. It's often protected with multi-factor authentication (MFA) and monitored with auditing tools. Most enterprises require an auditable access trail to the bastion host. :::success ### Checkpoint 3 (2 marks) Submit a screenshot, named **`cp3.{png/jpg/jpeg}`**, showing the details of the created instance. Take your screenshot after selecting your instance in the instance list menu under EC2 with the **Details** tab open. Make sure your screenshot shows the following: - The name and ID of the instance - The public and private IPv4 addresses of the instance - The instance type of the instance - The VPC and Subnet IDs of the instance - The name and ID of the instance's AMI - The key pair assigned (vockey) You can split the screenshots into **`cp3-1.{png/jpg/jpeg}`** and **`cp3-2.{png/jpg/jpeg}`** if one screenshot is not enough to include all information. ::: ### Task 3: Testing the connection to the bastion host In this task, you use the SSH key (.pem file or .ppk file) to test the SSH connection to your bastion host. This key was created for you. 6. In the upper-right area of the lab's Canvas page, choose **i AWS Details**. 7. Download the **SSH key**. * Choose **Download PEM**. Note that the file is named **labsuser.pem**. 8. To close the window, choose **Close**. 9. Connect to your bastion host by using SSH. 10. After you have tested your connection to the bastion host, you can close the terminal. **Hint**: If you get stuck, see the [AWS Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html). This page provides detailed instructions about how to use SSH to connect to an EC2 instance. :::success ### Checkpoint 4 (2 marks) Submit a screenshot, named **`cp4.{png/jpg/jpeg}`**, showing that the connection is successful. Make sure your screenshot shows the following: - The terminal you're using - The `ssh` command you used - The output after you successfully connect to the instance ::: ### Task 4: Creating a private subnet In this task, you create a private subnet in the Lab VPC. 11. In the Amazon VPC console, create a private subnet with the following options: * **VPC ID**: Choose **Lab VPC**. * **Subnet name**: Enter `Private Subnet`. * **Availability Zone**: Choose the same Availability Zone that you choose for the **Public Subnet** in one of the previous tasks. * **IPv4 subnet CIDR block**: Enter `10.0.1.0/24`. :::success ### Checkpoint 5 (2 marks) Submit a screenshot, named **`cp5.{png/jpg/jpeg}`**, showing your newly-created subnet. Make sure your screenshot shows the following: - The name of your subnet - The VPC it is in - The subnet's IPv4 CIDR block - The subnet's availability zone ::: ### Task 5: Creating a NAT gateway In this task, you create a NAT gateway, which enables resources in the **Private Subnet** to connect to the internet. 12. Create a NAT gateway that has the following options: * **Name - _optional_**: Enter `Lab NAT Gateway`. * **Subnet**: Choose **Public Subnet**. * **Elastic IP allocation ID**: Choose **Allocate Elastic IP**. **Tip**: Your NAT gateway needs an Elastic IP address. 13. Create a new route table that has the following options: * **Name - _optional_**: Enter `Private Route Table`. * **VPC**: Chose **Lab VPC**. 14. Attach this route table to the **Private Subnet** that you created earlier using the following options: * **Destination**: Enter `0.0.0.0/0`. * **Target**: Choose **NAT Gateway**. **Hint**: If you get stuck, see the [AWS Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-creating). :::success ### Checkpoint 6 (2 marks) Submit a screenshot, named **`cp6.{png/jpg/jpeg}`**, showing the updated configuration of the private subnet. Take the screenshot with the **Route Table** tab open. Make sure your screenshot shows the following: - The name of your subnet - The route table it is attached to - The routes of this table ::: ### Task 6: Creating an EC2 instance in the private subnet In this task, you create an EC2 instance in the **Private Subnet**, and you configure it to allow SSH traffic from the bastion host. You also create a new key pair to access this instance. 15. Create a new key pair named `vockey2`, and download the appropriate  PEM file. 16. Create an EC2 instance in the **Private Subnet** of the **Lab VPC** that has the following options: * For **Name**, enter `Private Instance`. * For **Amazon Machine Image (AMI)**, choose **Amazon Linux 2023 AMI**. * For **Instance type**, choose **t2.micro**. * For **Key pair name - _required_**, choose the **vockey2** key pair that you created earlier. * In the **Network settings** section, choose **Edit**, and configure the following options: * For **VPC - _required_**, choose **Lab VPC**. * For **Subnet**, choose **Private Subnet**. * For **Security group**, create a security group called `Private Instance SG` that allows only the following traffic: * For **Type**, choose **ssh**. * For **Port**, enter `22`. * For **Source type**, choose **Custom**. * For **Source**, choose the bastion host security group (**Hint**: for more information, see the [AWS Documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)). :::success ### Checkpoint 7 (2 marks) Submit a screenshot, named **`cp7.{png/jpg/jpeg}`**, showing the details of the created instance. Take your screenshot after selecting your instance in the instance list menu under EC2 with the **Security** tab open. Make sure your screenshot shows the following: - The name and ID of the instance - The security group of the instance ::: :::success ### Checkpoint 8 (2 marks) Submit a screenshot, named **`cp8.{png/jpg/jpeg}`**, showing the details of the created security group (SG). Take your screenshot after selecting your SG in the SG list menu under EC2 with the **Inbound rules** tab open. Make sure your screenshot shows the following: - **All** created SGs - The SG name and ID of the created SG - The inbound rules of the created SG ::: ### Task 7: Configuring your SSH client for SSH passthrough Because the private instance you just created uses a different key pair than the bastion host, you must configure your SSH client to use SSH passthrough. This action gives you the ability to use a key pair that's stored on your computer to access the private instance without uploading the key pair to the bastion host. This is a good security practice. For macOS or Linux users, ssh-agent is already installed as part of the operating system. To add your keys, complete the following steps. 17. To add your private keys to the keychain application, use the ssh-add command with the -K option and the .pem file for the key. The command should look like the following example: ```bash ssh-add vockey2.pem ``` :::spoiler For macOS/Linux users :::warning If you are getting the message `Could not open a connection to your authentication agent.`, run `ssh-agent bash` before continuing. ::: :::spoiler For Windows users :::warning If you are getting the message `unable to start ssh-agent service, error: 1058`, start a shell **with adminstrative access** and run `Set-Service ssh-agent -StartupType Manual` before continuing. This sets the service startup type to manual, and will start `ssh-agent` when used. ::: 18. Make sure that you add both the **labsuser.pem** and **vockey2.pem** keys that you downloaded. By adding the key to the agent, you can use SSH to connect to an instance without using the –i option when you connect. 19. To verify that the keys are available to ssh-agent, use the ssh-add command with the -L option. The command should look like the following example: ```bash ssh-add –L ``` The agent should display the keys that are stored. After the key is added to your keychain, you can connect to the bastion host instance with SSH by using the –A option. This option enables SSH agent forwarding. It also allows the local SSH agent to respond to a public key challenge when you use SSH to connect from the bastion host to a target instance in your VPC. 20. To connect to an instance in a private subnet, enter the following command. In this command, replace _\<bastion-IP-address-or-DNS-entry\>_ with the IP address or DNS entry for the bastion host. This command enables SSH agent forwarding by using the bastion host instance: ```bash ssh –A ec2-user@<bastion-IP-address-or-DNS-entry> ``` 21. After you’re connected to the bastion host instance, to use SSH to connect to a specific instance, enter a command such as the following example. In this command, replace _\<instance-IP-address-or-DNS-entry\>_ with the IP address or DNS entry for the instance: ```bash ssh user@<instance-IP-address-or-DNS-entry> ``` **Note**: The ssh-agent doesn't know which key it should use for a given SSH connection. Therefore, ssh-agent will sequentially try all the keys that are loaded in the agent. Because instances terminate the connection after five failed connection attempts, make sure that the agent has five or fewer keys. Because each administrator should have only a single key, this is usually not a problem for most deployments. For details about how to manage the keys in ssh-agent, use the `man ssh-agent` command. 22. Note that you can (and should) remove all identities after you are done with the lab by running ```bash ssh-add -D ``` ### Task 8: Testing the SSH connection from the bastion host In this task, you test the SSH connection from your bastion host to the EC2 instance that is running in the **Private Subnet**. 23. Connect to the bastion host instance by using SSH. **Tip**: Use the connection method that was described in the SSH passthrough section. 24. Connect to the private instance by using SSH and the IP address for the private instance. Your command should look similar to the following. In this command, replace _\<private-ip-address-of-instance-in-private-subnet\>_ with the private IP address of the instance in the private subnet: ```bash ssh ec2-user@<private-ip-address-of-instance-in-private-subnet> ``` :::success ### Checkpoint 9 (2 marks) Submit a screenshot, named **`cp9.{png/jpg/jpeg}`**, showing how to enter the private instance via `ssh`. Make sure your screenshot shows the following: - The 2 `ssh` commands - Both outputs after `ssh` ::: 25. Now that you are connected to the EC2 instance in the **Private Subnet**, use the following command to test its connection to the internet: ```bash ping 8.8.8.8 ``` **Tip**: Press Ctrl+C to exit the command. You have now established a communication between the **Bastion Host** in the **Public Subnet** and the EC2 instance in the **Private Subnet** as in the following diagram: ![Bastion host to private EC2 instance.](https://hackmd.io/_uploads/r1Mof4Y4ee.png) **Architecture best practice** In this first challenge, you implemented the architectural best practice of giving people the ability to perform actions at a distance. Refer to the following tip to learn more. :::spoiler **Tip 1** According to the [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html), compute resources require multiple layers of defense to help protect them from external and internal threats. In practice, you should remove the ability for interactive access to reduce the risk of human error and the potential for manual configuration or management. The Well-Architected Framework recommends that you use a change management workflow to deploy EC2 instances by using infrastructure as code. Then, you should use tools, such as AWS Systems Manager, to manage EC2 instances instead of allowing direct access or using a bastion host. For more information, see "[Replacing a Bastion Host with Amazon EC2 Systems Manager](https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/)" in the _AWS Cloud Operations & Migrations Blog_. ::: ## New business requirement: Enhancing the security layer for private resources (Challenge 2) Sofía and Nikhil are proud of the changes they made to the cafe's application architecture. They are pleased by the additional security they built, and they are also glad to have a test environment that they can use before they deploy updates to the production instance. They tell Mateo about their new application architecture, and he's impressed. To further improve their application security, Mateo advises them to build an additional layer of security by using custom network access control lists (network ACLs). In this challenge, you continue to take on the role of one of the café's system administrators. Now that you established secure access from the bastion host to the EC2 instance in the private subnet, you must enhance the security layer of the private subnet. To accomplish this task, you create and configure a custom network ACL. ### Task 9: Creating a network ACL In this task, you create a custom network ACL to control traffic to and from the **Private Subnet**. You can use network ACLs to control traffic between subnets. It's a good practice to use network ACLs to implement rules that are similar to your security group rules. The network ACLs provide an additional layer of protection. For this challenge, you create an EC2 instance in the **Public Subnet**. You create a security group that allows Internet Control Message Protocol (ICMP) traffic from the local network. Next, you create and configure your custom network ACL to deny ICMP traffic between the **Private Subnet** and this test instance. ICMP is used by the ping utility. 26. Go to the Amazon VPC console, and inspect the default network ACL of the **Lab VPC**. **Note 1**: The subnets that you created are automatically associated with the default network ACL. **Note 2**: The inbound and outbound rules of the default network ACL allow all traffic. 27. Create a custom network ACL called `Lab Network ACL` for the **Lab VPC**. **Note**: The default inbound and outbound rules of the custom network ACL deny all traffic. 28. Configure your custom network ACL to allow all traffic that goes into and out of the **Private Subnet**. **Hint**: If you get stuck, see the [AWS Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#CreateACL). :::success ### Checkpoint 10 (2 marks) Submit a screenshot, named **`cp10.{png/jpg/jpeg}`**, showing the inbound rules and other information of the ACL. Take the screenshot from the Network ACL list. Make sure your screenshot shows the following: - Name of the ACL - Necessary information showing that it allows all traffic to go into and out of the **Private Subnet**, which includes, but not limited to, the inbound rules. ::: ### Task 10: Testing your custom network ACL 29. Create an EC2 instance in the **Public Subnet** of the **Lab VPC** with the following options. * For **Name**, enter `Test Instance` * For **Amazon Machine Image (AMI)**, choose **Amazon Linux 2023 AMI**. * For **Instance type**, choose **t2.micro**. * For **Key pair name - _required_**, choose **vockey**. * In the **Network settings** section, choose **Edit**, and configure the following options: * For **VPC - _required_**, choose **Lab VPC**. * For **Subnet**, choose **Public Subnet**. * For **Auto-assign public IP**, choose **Enable**. * For **Security group**, create a security group called `Test SG`, and configure the following options: * In the **the Inbound Security Group Rules** section, for **Type**, choose **All ICMP – IPv4**. * Leave all other values as default. Note the private IP address of the **Test Instance**. :::success ### Checkpoint 11 (2 marks) Submit a screenshot, named **`cp11.{png/jpg/jpeg}`**, showing the basic information of the instance. Take the screenshot from the instance list under EC2. Make sure your screenshot shows the following: - Name of the instance - The VPC it is connected to - The subnet it is connected to - Its private IPv4 address ::: 30. To test that you can reach the private IP address of the **Test Instance** from the **Private Instance**, from the **Private Instance** terminal window, run the following ping command. In the command, replace _\<private-ip-address-of-test-instance\>_ with the private IP address of the **Test Instance**: ```bash ping <private-ip-address-of-test-instance> ``` Leave the ping utility running. 31. Modify your custom network ACL to deny all ICMP IPv4 traffic to the `<private-ip-address-of-test-instance>/32`. * Make sure to add `/32` to the end of the private IP address. * Make sure that this rule is evaluated first. In the **Private Instance** terminal window, the ping command should stop responding. The traffic to the **Test Instance** has been blocked. :::success ### Checkpoint 12 (2 marks) Submit a screenshot, named **`cp12.{png/jpg/jpeg}`**, showing the outbound rules of the ACL. Take the screenshot from the Network ACL list. Make sure your screenshot shows the following: - Name of the ACL - The outbound rules of the ACL. ::: You have now denied traffic from the **Private Subnet** to the **Test Instance**, as shown in the following diagram: ![Inage shows ability the comminucation between Private EC2 instance and the Test EC2 instance in public subnet.](https://hackmd.io/_uploads/Hy9ifVFNex.png) **Architecture best practice** In this second challenge, you protected your network resources by implementing the architectural best practice of controlling traffic at all layers. Refer to the following tip to learn more. :::spoiler **Tip 2** According to the [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html), any workload that has some form of network connectivity, whether it's the internet or a private network, requires multiple layers of defense to help protect it from external and internal network-based threats. When you control traffic at all layers, you apply multiple layers of security controls (known as a defense in depth approach) for both inbound and outbound traffic. For example, you do this in Amazon VPC by using security groups, network ACLs, and subnets. ::: ## Answering questions about the lab You're almost finished with the lab. 32. Answer the following questions: * **Question 1**: What is the purpose of the internet gateway in the public subnet? * A. Allows instances in the private subnet to obtain a public IP address * B. Allows instances in the public subnet to obtain a public IP addresss * C. Allows instances in the public subnet with a public IP address to communicate with the internet * D. Allows instances in the private subnet with a public IP address to communicate with the internet * **Question 2**: What allows the instance in the private subnet to connect to the internet so that it can download updates? * A. The internet gateway in the public subnet * B. The NAT gateway * C. The Elastic IP address * D. The default network ACL * **Question 3**: Can the instance in the private subnet be accessed directly from the internet? * A. Yes * B. No * **Question 4**: Why do you use two different key pairs to access the private instance and the bastion host? * A. Each instance needs a different key pair * B. It provided practice with creating key pairs * C. Separate key pairs could help reduce the impact of a compromised bastion host * D. Key pairs can't be reused * **Question 5**: Can the bastion host use ping and get a reply from the instance in the private subnet? * A. Yes * B. No * **Question 6**: Which security group rules allow the private EC2 instance to receive the return traffic when it pings the test instance? * A. Outbound on private and outbound on test * B. Outbound on private and inbound on test * C. Inbound on private and outbound on test * D. Inbound on private and inbound on test :::success ### Checkpoint 13 (3 marks) Submit a text file, named **`cp13.{txt/md}`**, answering the questions above. For example, if all the answers are A, submit a file with `AAAAAA` as its content. ::: 33. Remember to remove all `ssh` identities as shown in step 22. 34. If you are on Windows, you can reset the startup type of `ssh-agent` to `Disabled` by running `Set-Service ssh-agent -StartupType Disabled`, and stopping `ssh-agent` by `Stop-Service ssh-agent` in an administrative shell. ## Lab complete Congratulations! You have completed the lab. Remember to submit the necessary files [on Canvas](https://canvas.ust.hk/courses/63913/assignments/385093). 35. At the top of this page, choose ⏹ **End Lab**, and then choose Yes to confirm that you want to end the lab. A message panel indicates that the lab is terminating. 36. To close the panel, choose **Close** in the upper-right corner.