Lab 4 - Linux Post-Install
Facilitator: Ben Cuan8 min read
- Topics Covered
- About this Lab
- Generating and using SSH keys
- Setting up a firewall
- Choose your own adventure
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.
- 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.
- 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
- Configuring sshd
- On-host firewalls (ufw)
- The Filesystem Hierarchy
In this lab you will implement some of the things we discussed during lecture. In the first part, you’ll be securing your VM with a firewall and enabling key-based login. Then, we’ll open it up for you to choose a cool service to host on your very own VM!
In this course, we’ve used several VM’s:
- The OCF’s public login server,
- Your student VM, hosted on DigitalOcean,
- and the Arch VM you installed in the previous lab.
To be clear, you should be completing this lab on your student VM and not your newly installed Arch VM unless otherwise stated1. If you happen to have access to a permanent personal VM/server you are also welcome to complete the lab on that (as the student VM’s will be deleted at the end of the semester).
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.
If you aren’t currently using a Linux machine, please log into
(not your student VM- the reason will be clear shortly).
These instructions will not work on a Windows machine.
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
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 paranoia2 about quasi-legal government surveillance.
Copy the public key over to your student VM
you@tsunami $ ssh-copy-id email@example.com
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_keysfile, 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
tsunamiand then compare that to
cat ~/.ssh/authorized_keyson 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.
- Paste the contents of
~/.ssh/authorized_keysfrom your student VM.
- 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 (optional), configure
sshd to only allow key-based login.
In order to secure your VM, you should install a firewall. One option for doing so is
the Uncomplicated Firewall.
ufw is a easy-to-use wrapper around the powerful
firewall. You should be able to figure out how to set up
ufw using the guides linked
earlier and your own Google-foo. There is also additional information about the features of
and further resources at the Ubuntu Wiki.
In order to complete this portion of the lab, ensure the following:
- All incoming connections are blocked by default.
- Allow incoming connections to your VM over port 22 (SSH), otherwise you’ll be locked out of your VM!
- 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.
- Extra challenge (optional): Allow the above, but only for IPs originating from UC Berkeley’s
subnet. UC Berkeley has 3 primary
- Double extra challenge (optional): Configure
fail2banto block IP addresses that are trying to brute-force your SSH password.
- What command did you use to enable a port?
- Paste the output of
sudo ufw status verbose. Make sure you can clearly see the changes you made in the steps above!
- Why is setting up a firewall important? What are some security concerns that might arise from exposing a port?
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, but don’t be restricted by them!
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 on your
DeCal VM, and load up a few tunes.
As an alternative for CherryMusic, you could also try the Python-based music server Mopidy, which also has the option for fetching music from Youtube and Spotify, as well as managing your server using a pretty web interface.
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.
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.
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.
Still not inspired by the examples above? Browse the extensive awesome-selfhosted page for some inspiration! (Host a chat server, email server, notes app, game server, video streaming platform…)
- What did you install on your VM?
- Attach a screenshot of your service in action. (This could be a web console or a command output in the shell.)
- Briefly describe the installation process. Were there any unexpected roadblocks you encountered?
- What are some security implications from hosting this service? How have you handled them (or are you not handling them?)
Respond to the checkoff questions on gradescope!