Lab 4 - Linux Post-Install

Topics Covered

We covered a lot of material in the lecture. Here’s a short list of things you may be interested in looking into further, besides googling and reading the man pages for the commands we discussed in lecture.

  1. SELinux - Security Enhanced Linux, gives role-based/mandatory access control facilities. Utilizing it is well beyind the scope of this class, but reading about how SELinux works should give you an appreciation for the degree to which people have thought about file-level security in the kernel.
  2. Managing users and groups
  3. Configuring sshd
  4. On-host firewalls (ufw)
    • Fairly comprehensive ufw configuration guide
  5. The Filesystem Hierarchy

Lab Activity

In this lab we’re going to try to have you implement some of the things we discussed during lecture.

Generating and using SSH keys

Passwords can be guessed, and this is bad. Good security practice now involves taking advantage of public-key crypto to authenticate SSH sessions. In this section, we will be setting up SSH keys, if you haven’t already.

Please log into tsunami.ocf.berkeley.edu first. These instructions will not work on a Windows machine.

  1. First, make sure you don’t already have an existing SSH key in use that you might overwrite:

     you@tsunami $ ls -la ~/.ssh
 -rw------- 1 <you> ocf <stuff> .ssh/id_rsa # if this already exists, continue to step 3

  2. If you don’t have an SSH key, make one with the following command

     you@tsunami $ ssh-keygen -t rsa -b 4096

    You can give the key a passphrase if you’d like. This command creates a 4096-bit RSA private key (~/.ssh/id_rsa) and corresponding public key (~/.ssh/id_rsa.pub). There are many types of keys in various sizes, such 2048-bit RSA keys (ssh-keygen -t rsa -b 2048) or 384-bit ECDSA keys (ssh-keygen -t ecdsa -t 384) or more. The full list can be found in man ssh-keygen. Which one to use is up to your preference and/or [paranoia]1 about quasi-legal government surveillance.

  3. Copy the public key over to your student VM

     you@tsunami $ ssh-copy-id you@you.decal.xcf.sh

    This command, as its name suggests, copies your public key (by default, ~/.ssh/id_rsa.pub) to the specified remote host, and appends the contents of the public key to the ~/.ssh/authorized_keys file, which is used to control which keys are authorized to be used to authenticate a user. To see specifically what happened, do cat ~/.ssh/id_rsa.pub) on tsunami and then compare that to cat ~/.ssh/authorized_keys on your student VM.

At the end ssh-copy-id will prompt you to attempt to log into the server using your key. This should succeed.

Checkoff: paste the contents of ~/.ssh/authorized_keys from your student VM.

Checkoff bonus: configure sshd to only allow key-based login.

Setting up a firewall

Although we’ve configured an external firewall to protect your VMs from external connections, you should still set up an internal, on-host firewall.

To do this, install ufw, the Uncomplicated Firewall. ufw is a easy-to-use wrapper around the powerful iptables firewall. You should be able to figure out how to set up ufw using the guides linked earlier and your own Google-foo. In order to get checked off for this portion of the lab, ensure the following:

  1. All incoming connections are blocked by default.
  2. Allow incoming connections to your VM over port 22 (SSH), otherwise you’ll be locked out of your VM (as will we).
  3. Allow incoming connections for the ports necessary for the operation of the software you’ll be installing later on in this lab, e.g. port 80 and/or 443 for a web server.
  4. Bonus points: Allow the above, but only for IPs originating from UC Berkeley’s subnet. UC Berkeley has 3 primary /16s.
  5. Double bonus points: Configure fail2ban to block IP addresses that are trying to brute-force your SSH password.

Checkoff: paste the output of sudo ufw status verbose

Choose your own adventure

At this stage, your task is to install a useful service on your VM. Here are some suggestions, but feel free to set up anything you’d like. Your submission will consist of explaining what you installed, and explaining any potential security implications you can think of. You don’t need to do all of them.

Music Server

Some music enthusiasts opt to own their own music files instead of using a cloud service (Spotify, Google Play Music, etc). But, if the files are only stored on your computer’s hard drive, how can you listen to your music when on someone else’s computer or on the go? A music server like CherryMusic can solve this problem while still giving you control over your files. Install CherryMusic (or an alternative]) on your DeCal VM, and load up a few tunes.

Git server

GitHub is a good place to host your source code, but self-hosting your own Git can be a good option if you need to store something private (and don’t trust GitHub), hosting your own can be a good solution. While you can use Git to host a repo on any SSH server using a bare repo, to get a fancy GUI you need to install special software. Some popular options for this include Gitea (which mimicks GitHub’s interface) and cgit (which takes a more minimalist approach). Pick one and install it.

File Hosting

Instead of uploading your files to Google Drive or Dropbox to be shared, you can host on your own VM. A good option for this is fluffy (created by an OCF alum!), which also doubles as a pastebin for quickly sharing code snippets. For more options, look at the the [“simple click/drag-n-drop upload” section of awesome-selfhosted.

Password Manager

BitWarden is a popular self-hosted password manager. You can use it to host your passwords if you don’t want to rely on a proprietary third-party (like LastPass). Alternatives include pass which is a user-friendly wrapper around gpg.

Submission

After you’re done, fill out this.

  1. https://www.amazon.com/Only-Paranoid-Survive-Exploit-Challenge/dp/0385483821 ↩