Lab 4 - Linux Post-Install

• Topics Covered
• Lab Activity
  • Generating and using SSH keys
  • Setting up a firewall
    • Gradescope Questions
  • Choose your own adventure
    • Music Server
    • Git server
    • File Hosting
    • Password Manager
      • Gradescope Questions
• Submission
  • Footnotes

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.
   • Official Wiki
   • Red Hat documentation
   • Wikipedia (obviously)
2. Managing users and groups
   • TLDP entry
   • An excellent DigitalOcean guide
   • These great StackExchange answers
   • ArchWiki breakdown of permissions
   • Debian Wiki equivalent
   • If you needed more reasons to be skeptical of the maturity of the Node ecosystem
   • Protection Rings - no DND, unfortunately
   • glibc and kernel source where some of this stuff gets checked
3. Configuring sshd
   • Another comprehensive DigitalOcean guide to /etc/ssh/sshd_config
   • Fail2Ban and Archwiki configuration instructions
4. On-host firewalls (ufw)
   • Fairly comprehensive ufw configuration guide
   • The same guide, but for Ubuntu 18.04: ufw
5. The Filesystem Hierarchy
   • Wikipedia entry
   • Even more comprehensive TLDP entry

Lab Activity

In this lab you will 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]¹ 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.

Gradescope Questions

1. Paste the contents of ~/.ssh/authorized_keys from your student VM.
2. What are the permissions on your public key and private key? Why do you think they are the way they are?

For an extra challenge (not part of your grade), configure sshd to only allow key-based login.

Setting up a firewall

In order to secure your VM, you should install a 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. Inorder 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!
3. Allow incoming connections for the ports necessary for the operation of the software you’ll be installing later on in this lab. For example, if you are configuring a web server, you should enable port 80 and/or 443. (You can always come back to this after figuring out the next part of the lab!) for a web server.
4. Extra challenge (optional): Allow the above, but only for IPs originating from UC Berkeley’s subnet. UC Berkeley has 3 primary /16s.
5. Double extra challenge (optional): Configure fail2ban to block IP addresses that are trying to brute-force your SSH password.

Gradescope Questions

1. What command did you use to enable a port?
2. Paste the output of sudo ufw status verbose. Make sure you can clearly see the changes you made in the steps above!
3. Why is setting up a firewall important? What are some security concerns that might arise from exposing a port?

Choose your own adventure

At this stage, you should have a fully functioning Linux install! Now, your task is to install a useful service on your VM.

We’ve described a few examples below. Or, feel free to peruse the awesome-selfhosted page for some inspiration!

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 program (like LastPass). Alternatives include pass which is a user-friendly wrapper around gpg. Please note that your student VMs will be deleted at the end of the semester, so you should not use your student VM for long term password storage.

Gradescope Questions

1. What did you install on your VM?
2. Attach a screenshot of your service in action. (This could be a web console or a command output in the shell.)
3. Briefly describe the installation process. Were there any unexpected roadblocks you encountered?
4. What are some security implications from hosting this service? How have you handled them (or are you not handling them?)

Submission

Respond to the checkoff questions on gradescope!

Footnotes