# Cases til opgave Z10.2 (kursus i VPS og Linux-serveradministration) Vælg for hver case, hvilken fejl det er, og hvad det bedste første skridt er. Alle navne og adresser er eksempler. **Fejl (fra lektion 10.2):** A. Root-login med en adgangskode B. En database, cache eller søgeklynge åben mod internettet C. Docker-API'et åbent eller `docker.sock` i en container D. `chmod 777` for at slippe af med en fejlmeddelelse E. `curl ... | bash` og software fra alle steder F. Ingen opdateringer, eller opdateringer "senere" G. Ingen backup, eller en backup, der aldrig er blevet testet H. Administrationspanel åbent for alle, uden totrinsbekræftelse I. Hemmeligheder i Git eller i din compose-fil J. Firewallen slået fra "lige et øjeblik", alt som root, ingen noter --- **Case 1.** På `web1.example.com` står der i `compose.yaml` ved tjenesten `redis`: `ports: - "6379:6379"`. `ufw status` viser kun 22, 80 og 443. En scanning udefra finder 6379 åben. Første skridt: (a) genstart ufw (b) fjern portreglen eller ændr den til `"127.0.0.1:6379:6379"`, og kør `docker compose up -d` igen (c) giv Redis et andet portnummer (d) genstart serveren **Case 2.** Udvikleren af en webapplikation på `app.example.net` melder, at uploads ikke virkede. Han har "løst" det, og nu har alle filer i `/var/www/app` `-rwxrwxrwx`. Første skridt: (a) lad det være, det virker nu (b) giv kun webserverbrugeren skriverettigheder til upload-mappen, og sæt resten tilbage til 644/755 med en anden ejer (c) kør webserveren som root (d) slå AppArmor fra **Case 3.** Et offentligt repository indeholder siden i går en fil `.env` med `MAIL_API_KEY=...` fra serveren `web2.example.org`. Første skridt: (a) slet filen fra repositoryet (b) tilbagekald nøglen hos maltjenesten, opret en ny, og sæt `.env` i `.gitignore` (c) omdøb repositoryet (d) gør ingenting **Case 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` giver `permitrootlogin yes` og `passwordauthentication yes`. I journalen er der forsøg på root hvert minut. Første skridt: (a) installer fail2ban og intet andet (b) placer en nøgle til en almindelig administrator med sudo, test den, og slå derefter adgangskodelogin og root-login med adgangskode fra (c) flyt SSH til port 2222 (d) gem root-adgangskoden i en tekstfil **Case 5.** `cat /etc/os-release` viser en Ubuntu-udgivelse, hvis standardsupport udløb for tre år siden, uden ESM. `apt list --upgradable` er tom. Første skridt: (a) vær glad, der er ingen opdateringer (b) planlæg en opgradering eller en ny server med en understøttet LTS, med snapshot og backup (c) geninstaller unattended-upgrades (d) genstart serveren **Case 6.** En container `portainer` har volumen `/var/run/docker.sock:/var/run/docker.sock` og kan nås på `https://styring.example.com` med adgangskoden `admin123`, uden totrinsbekræftelse. Vælg den fejl, der muliggør den største skade, hvis adgangskoden bliver gættet. Første skridt: (a) placer panelet bag en SSH-tunnel eller en fast adresse, og opsæt en stærk adgangskode med totrinsbekræftelse (b) genstart containeren (c) vælg et andet subdomæne (d) geninstaller Docker **Case 7.** Efter en mislykket opdatering af databasen viser det sig, at den eneste backup er et to måneder gammelt snapshot på samme lager som serveren. Ingen har nogensinde prøvet en gendannelse. Første skridt for fremtiden: (a) tag flere snapshots (b) opsæt krypterede backups uden for serveren (for eksempel restic) med overvågning og en gendannelsestest (c) opdater aldrig databasen igen (d) en ekstra disk i den samme server **Case 8.** På serveren findes `/usr/local/bin/tool` og en ukendt pakkekilde `extra.list` med indstillingen `[trusted=yes]`. Ingen ved, hvor de kommer fra; den tidligere administrator installerede "alt med én linje fra en hjemmeside". Første skridt: (a) lad det blive, det virker (b) find ud af, hvad kilden og programmet er, slå kilden fra med `trusted=yes`, og installer fremover kun fra distributionen eller udviklerens officielle kilde med `Signed-By` (c) genstart serveren (d) fjern alle pakker Udfyld for hver case: fejl (A-J) og første skridt (a-d).