View source for OPS705 Lab 2 (2221)

= LAB PREPARATION =

=== Purpose / Objectives of Lab 2 ===
In this lab, you will conduct several Linux system administration tasks to secure your system against would-be attackers and gain preliminary experience with the command line interface.

If you encounter technical issues, please contact your professor via e-mail or in your section's Microsoft Teams group.

=== Minimum Requirements ===
Before beginning, you must have: 
# Successfully completed [[OPS705_Lab_1 | Lab 1]]
# Watched the Week 2 video lecture
# Read through the Week 2 slides, and have them handy as a reference for concepts
# Your Seneca Azure login credentials
# Your linked mobile device for 2FA

= INVESTIGATION 1:  Update Linux =
This investigation simply has you update your CentOS installation. This includes operating system packages, as well as any other packages that have been installed using yum.

== Part 1: Privilege Escalation ==

Updating the operating system, by its very nature, changes the system. '''Any command or utility that performs system-wide changes can only be run by a system administrator.''' Remember that.

To update the operating system, you'll need to have administrative access. There are two ways to do this:
# logging in to an admin account from your regular account
# running a command as your regular user with temporary admin powers

We call this ''privilege elevation'' or ''elevating your privileges''. Only regular user accounts that belong to the system's administrator group can do this. The name of the admin group changes depending on the distribution of Linux; for CentOS, it's the '''wheel''' group. The first user account you created as part of your VM installation was automatically added to this group as part of the Azure VM deployment process.

Let's go through a few examples.

First, let's login:
# Start your Linux VM in Azure (this may take a few minutes)
# Connect to the VM remotely via SSH using your regular account. (Refer to [[OPS705_Lab_1 | Lab 1]])

=== Using Sudo ===
We can run administration-level commands by using sudo. Sudo allows you to run a command as an administrator (root) from your standard account. For the duration of the command's run, you are root. When the command completes, you are back to being a regular user.

Normally, the shell environment will ask you for your account password as an extra security precaution when using sudo. However, cloud-based Linux VMs typically have ''password-less sudo access''. The idea is that identity management and security is handled by the cloud infrastructure. We'll explore that in detail later in the course.

[[Image:Ops705_lab2_fig1.png|thumb|right|350px|Figure 1. Example commands with sudo.]]
Run the following commands:
# <code> whoami </code>
# <code> sudo whoami </code>
# <code> whoami </code>

The ''whoami'' command responds by printing out your username. Notice how, by using the command in combination with ''sudo'', the response is '''root'''. While the second command is running, you are root. But the moment it ends, you drop back down to your standard user. This is why the third command responds with your standard user again.

Sudo is the preferred method of running admin-level commands, especially when you only have one command to run, or just a few. Only run commands with sudo that require it. Remember, the root user can do '''anything''' on the system, including accidentally delete all files. Only use it when you need it.

=== Logging Into Root ===
To run administration-level commands, we can also log into the root admin account from our standard user. This is primarily done when a user knows they'll be running many admin-level commands during a session to complete a task.

From your standard user, elevate to the root account with the following command: <code>sudo su -</code>

Notice that your command prompt has immediately changed. It no longer prints out your username at the beginning of each line, but the name of the '''root''' account. This is a good visual aid to let you know how you're logged in.

[[Image:Ops705_lab2_fig2.png|thumb|right|350px|Figure 2. Example commands as root.]]
Run the same commands from the sudo subsection:
# <code> whoami </code>
# <code> sudo whoami </code>
# <code> whoami </code>

Notice that each command returns the output '''root'''. This is in contrast to using the sudo command from your regular user account. When you are logged into the root account directly as you are now, '''all commands you issue will run as root'''. Be very careful! With great power comes great responsibility.

To log out of root and drop back down to your regular user, run: <code>exit</code>

== Part 2: Update CentOS ==
As mentioned in the Week 2 lecture, keeping your Linux system up to date is an incredibly important task and must be done regularly. You are the administrator of this system, you must keep it running well. While updating is a graded part of this lab, you should run the command again regularly to check for new updates while you continue to work with this virtual machine over the next several week..

[[Image:Ops705_lab2_fig3.png|thumb|right|500px|Figure 3. A yum update in progress.]]
Run the command to update CentOS: <code>sudo yum update</code>

Running this as a regular user will give you an error, which is why you temporarily elevate your privileges for the duration of a command with sudo.

There will likely be further user interaction for this update command, mostly asking you to confirm an action. For updates, you can type <code>y</code> and hit Enter safely. That said, do get in the habit of reading warnings and when it asks for your confirmation.

The update command will look for updates, download the install files, and then update the system. Most updates don't require a restart (unlike Windows!), except for kernel updates. The kernel is the very basic building block of the system; sort of the heart. It's responsible for many of the most basic functions a computer performs. If a kernel update is installed, you need to restart the system to use the new kernel. As this is your first update, you'll likely have a kernel upgrade installed.

* When the yum update command completes, restart the system with the following command: <code>sudo reboot</code>

You'll be disconnected from your remote session as the SSH server inside your VM shuts down along with the rest of the system.

It may take a few minutes for the VM to restart. You can track its progress through the Azure DTL Overview page. Once back up and running, log back in to confirm everything still works.

= INVESTIGATION 2: Configuring Your Firewall =
In this investigation, you'll replace the default firewall with another and follow security best practices in constructing your firewall rules.

== Part 1: Replacing ''firewalld'' with ''iptables'' ==
[[Image:Ops705_lab2_fig16.png|thumb|right|500px|Figure 4. Service status of both firewalls.]]
[[Image:Ops705_lab2_fig4.png|thumb|right|500px|Figure 5. Default iptables firewall rules.]]
The default firewall for CentOS, ''firewalld'' is more complex than we need. We'll be reverting to the easier to use ''iptables'' standard. This will require the removal of the ''firewalld'' package, the installation of the ''iptables-services'' package, and working with systemd services to turn on your new firewall.

'''Make sure you follow these instructions in order. If you don't, you may be locked out of your Linux VM forever.''' If you encounter errors on any step, stop and ask for help. Do not continue!

As we are going to run several admin-level commands, we will log in as root for this section:
# From your regular user, elevate to the root account: <code>sudo su -</code>
# Install the ''iptables-services'' package: <code>yum install iptables-services</code>
# Stop the ''firewalld'' service and start the ''iptables'' service in a single, chained command: <code> systemctl stop firewalld; systemctl start iptables</code>
# Check the status of the firewalld service. It should tell you it's stopped: <code>systemctl status -l firewalld</code>
# Check the status of the iptables service. It should tell you it's '''active''': <code>systemctl status -l iptables</code>
# View your current iptables firewall rules: <code>iptables -L -vn --line-numbers</code>
# Refer to ''Figure 1''. If your rules at this stage look different, stop and contact your professor for help. (Values in the '''pkts''' and '''bytes''' column may vary.)
# Set iptables to start with the system: <code>systemctl enable iptables</code>
# Remove ''firewalld'' completely, including all unused files: <code>yum autoremove firewalld</code> ('''Note:''' If you don't remove firewalld and both firewalls are set to start with the system, firewalld will always start instead of iptables. This can lead to much frustration. Make sure you remove it!)

== Part 2: Securing Your Firewall ==
There are a few standard security practices to follow when dealing with firewalls. In this section, we will changes our firewall rules to follow those practices. For more detail, refer to the Week 2 lecture and material.

[[Image:Ops705_lab2_fig15.png|thumb|right|500px|Figure 6. Modified iptables firewall rules.]]
# Set your default policy for the INPUT chain to DROP: <code>iptables -P INPUT DROP</code>
# Remove the reject rule from the INPUT chain to hide our server from scans: <code> iptables -D INPUT 5</code>
# Set your default policy for the FORWARD chain to DROP: <code>iptables -P FORWARD DROP</code>
# Remove the reject rule from the FORWARD chain to hide it from scans: <code>iptables -D FORWARD 1</code>
# Verify your changes by running the list rules command again: <code>iptables -nvL --line</code> Refer to ''Fig. 6'' as a reference.
# To confirm you haven't locked yourself out, log out of SSH and log back in. If you don't encounter any login issues, you're good to go.
# '''Assuming the step above works''', in your Linux VM, save your rule changes: <code>service iptables save</code>
# Congratulations, you've secured your firewall!

= Lab Submission =
Submit to Blackboard's ''Lab Submission'' section full-desktop screenshots (PNG/JPG) of the following:
# Screenshot 1: Run the '''yum update''' command to show there are no further updates to install and screenshot the result.
# Screenshot 2: Service status of ''firewalld'' and ''iptables''.
# Screenshot 3: Listing of your modified firewall rules.

Your professor will review your VMs directly; the screenshots are a backup in case of catastrophic issues.

'''Your professor will not check your lab until the screenshots have been submitted.'''

Make sure to fully stop your VMs when you're done!

[[Category:OPS705]]
[[Category:OPS705 Labs]]
[[Category:Digital Classroom]]
[[Category:Winter 2022]]