Lab 4 - Linux Post-Install
Facilitator: Ben Cuan
8 min readTable of contents
- Topics Covered
- About this Lab
- Generating and using SSH keys
- Setting up a firewall
- Choose your own adventure
- Submission
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.
- 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
- Another comprehensive
DigitalOcean guide to
/etc/ssh/sshd_config
- Fail2Ban and Archwiki configuration instructions
- Another comprehensive
DigitalOcean guide to
- On-host firewalls (ufw)
- The Filesystem Hierarchy
About this Lab
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!
A note about VMs
In this course, we’ve used several VM’s:
- The OCF’s public login server,
tsunami
, - Your student VM, hosted on DigitalOcean,
<yourname>@<yourname>.decal.xcf.sh
, - 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).
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.
If you aren’t currently using a Linux machine, please log into tsunami.ocf.berkeley.edu
first
(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 inman 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 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, docat ~/.ssh/id_rsa.pub
) ontsunami
and then compare that tocat ~/.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
- Paste the contents of
~/.ssh/authorized_keys
from 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.
Setting up a firewall
In order to secure your VM, you should install a firewall. One option for doing so is 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. There is also additional information about the features of ufw
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
/16
s. - Double extra challenge (optional): Configure
fail2ban
to block IP addresses that are trying to brute-force your SSH password.
Gradescope Questions
- 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?
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, but don’t be restricted by 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 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.
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.
Something Else?
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…)
Gradescope Questions
- 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?)
Submission
Respond to the checkoff questions on gradescope!