# Případové studie k úkolu Z10.2 (kurz VPS a správa linuxového serveru)

U každé případové studie zvolte, o jakou chybu jde a jaký je nejlepší první krok. Všechny názvy a adresy jsou pouze příklady.

**Chyby (z lekce 10.2):**
A. Přihlášení jako root pomocí hesla
B. Databáze, cache nebo vyhledávací cluster otevřené do internetu
C. Otevřené Docker API nebo `docker.sock` v kontejneru
D. `chmod 777`, aby zmizela chybová hláška
E. `curl ... | bash` a software odkudkoli
F. Žádné aktualizace, nebo aktualizace „později“
G. Žádná záloha, nebo záloha, která nebyla nikdy otestována
H. Administrační panel otevřený pro všechny, bez dvoufázového ověření
I. Tajné údaje v Gitu nebo ve Vašem souboru compose
J. „Jen na chvíli“ vypnutý firewall, vše jako root, žádné poznámky

---

**Případ 1.** Na `web1.example.com` je v `compose.yaml` u služby `redis` uvedeno: `ports: - "6379:6379"`. `ufw status` zobrazuje pouze 22, 80 a 443. Sken zvenčí najde otevřený port 6379.
První krok: (a) znovu spustit ufw (b) pravidlo pro port odstranit nebo změnit na `"127.0.0.1:6379:6379"` a znovu provést `docker compose up -d` (c) přidělit Redisu jiné číslo portu (d) restartovat server

**Případ 2.** Vývojář webové aplikace na `app.example.net` hlásí, že nefungovalo nahrávání souborů. Problém „vyřešil“ a nyní mají všechny soubory v `/var/www/app` nastaveno `-rwxrwxrwx`.
První krok: (a) nechat to tak, teď to funguje (b) dát uživateli webového serveru právo zápisu pouze do složky pro nahrávání, zbytek vrátit na 644/755 s jiným vlastníkem (c) spouštět webový server jako root (d) vypnout AppArmor

**Případ 3.** Veřejný repozitář obsahuje od včerejška soubor `.env` s `MAIL_API_KEY=...` ze serveru `web2.example.org`.
První krok: (a) odstranit soubor z repozitáře (b) zneplatnit klíč u e-mailové služby a vytvořit nový, a přidat `.env` do `.gitignore` (c) přejmenovat repozitář (d) nedělat nic

**Případ 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` vrací `permitrootlogin yes` a `passwordauthentication yes`. V journalu jsou každou minutu pokusy o přihlášení jako root.
První krok: (a) nainstalovat fail2ban a nic dalšího (b) nahrát klíč pro běžného správce se sudo, otestovat ho a poté vypnout přihlašování heslem a přihlášení jako root pomocí hesla (c) přesunout SSH na port 2222 (d) uložit heslo uživatele root do textového souboru

**Případ 5.** `cat /etc/os-release` zobrazuje vydání Ubuntu, jehož standardní podpora skončila před třemi lety, bez ESM. `apt list --upgradable` je prázdné.
První krok: (a) mít radost, že nejsou žádné aktualizace (b) naplánovat upgrade nebo nový server s podporovanou verzí LTS, se snapshotem a zálohou (c) znovu nainstalovat unattended-upgrades (d) restartovat server

**Případ 6.** Kontejner `portainer` má svazek `/var/run/docker.sock:/var/run/docker.sock` a je dostupný na `https://beheer.example.com` s heslem `admin123`, bez dvoufázového ověření.
Zvolte chybu, která umožňuje největší škodu, pokud někdo heslo uhodne. První krok: (a) umístit panel za SSH tunel nebo pevnou adresu a nastavit silné heslo s dvoufázovým ověřením (b) restartovat kontejner (c) zvolit jinou subdoménu (d) znovu nainstalovat Docker

**Případ 7.** Po neúspěšné aktualizaci databáze se ukáže, že jedinou zálohou je dva měsíce starý snapshot na stejném úložišti jako server. Nikdo nikdy nezkoušel obnovu.
První krok do budoucna: (a) vytvářet více snapshotů (b) zavést šifrované zálohy mimo server (například restic) s monitorováním a testem obnovy (c) databázi už nikdy neaktualizovat (d) druhý disk ve stejném serveru

**Případ 8.** Na serveru je `/usr/local/bin/tool` a neznámý zdroj balíčků `extra.list` s volbou `[trusted=yes]`. Nikdo neví, odkud pocházejí; předchozí správce instaloval „všechno jedním řádkem z webu“.
První krok: (a) nechat to být, funguje to (b) zjistit, co je to za zdroj a program, vypnout zdroj pomocí `trusted=yes` a instalovat už jen z distribuce nebo z oficiálního zdroje autora pomocí `Signed-By` (c) restartovat server (d) odstranit všechny balíčky

U každého případu vyplňte: chybu (A-J) a první krok (a-d).