# Cases for assignment Z10.2 (course VPS and Linux server administration)

For each case, choose which mistake it is and what the best first step is. All names and addresses are examples.

**Mistakes (from lesson 10.2):**
A. Root login with a password
B. A database, cache or search cluster open to the internet
C. The Docker API open or `docker.sock` in a container
D. `chmod 777` to make an error message go away
E. `curl ... | bash` and software from anywhere
F. No updates, or updates "later"
G. No backup, or a backup that has never been tested
H. Admin panel open to everyone, without two-factor authentication
I. Secrets in Git or in your compose file
J. Turning off the firewall "for a moment", everything as root, no notes

---

**Case 1.** On `web1.example.com`, `compose.yaml` contains the following for the service `redis`: `ports: - "6379:6379"`. `ufw status` only shows 22, 80 and 443. A scan from outside finds 6379 open.
First step: (a) restart ufw (b) remove the port rule or change it to `"127.0.0.1:6379:6379"` and run `docker compose up -d` again (c) give Redis a different port number (d) reboot the server

**Case 2.** The developer of a web application on `app.example.net` reports that uploads were not working. He "fixed" it and now all files in `/var/www/app` are set to `-rwxrwxrwx`.
First step: (a) leave it, it works now (b) give the web server user write permission only on the upload folder, set the rest back to 644/755 with a different owner (c) run the web server as root (d) disable AppArmor

**Case 3.** Since yesterday, a public repository contains a file `.env` with `MAIL_API_KEY=...` from the server `web2.example.org`.
First step: (a) delete the file from the repository (b) revoke the key at the mail service and create a new one, and put `.env` in `.gitignore` (c) rename the repository (d) do nothing

**Case 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` gives `permitrootlogin yes` and `passwordauthentication yes`. The journal shows attempts on root every minute.
First step: (a) install fail2ban and nothing else (b) add a key for a regular administrator with sudo, test it, and then disable password login and root login with a password (c) move SSH to port 2222 (d) store the root password in a text file

**Case 5.** `cat /etc/os-release` shows an Ubuntu release whose standard support ended three years ago, without ESM. `apt list --upgradable` is empty.
First step: (a) be happy, there are no updates (b) plan an upgrade or a new server running a supported LTS, with a snapshot and a backup (c) reinstall unattended-upgrades (d) reboot the server

**Case 6.** A container `portainer` has the volume `/var/run/docker.sock:/var/run/docker.sock` and is reachable at `https://beheer.example.com` with the password `admin123`, without two-factor authentication.
Choose the mistake that makes the greatest damage possible if the password is guessed. First step: (a) put the panel behind an SSH tunnel or a fixed address and set a strong password with two-factor authentication (b) restart the container (c) choose a different subdomain (d) reinstall Docker

**Case 7.** After a failed database update, it turns out the only backup is a snapshot two months old, on the same storage as the server. Nobody has ever tried a restore.
First step for the future: (a) make more snapshots (b) set up encrypted backups off the server (for example restic), with monitoring and a restore test (c) never update the database again (d) a second disk in the same server

**Case 8.** The server has `/usr/local/bin/tool` and an unknown package source `extra.list` with the option `[trusted=yes]`. Nobody knows where they came from; the previous administrator installed "everything with one line from a website".
First step: (a) leave it, it works (b) find out what the source and the program are, disable the source with `trusted=yes`, and from now on only install from the distribution or the maker's official source with `Signed-By` (c) reboot the server (d) remove all packages

Fill in for each case: mistake (A-J) and first step (a-d).