# Prípadové štúdie k úlohe Z10.2 (kurz VPS a správa linuxového servera)

Pri každom prípade vyberte, o akú chybu ide a aký je najlepší prvý krok. Všetky názvy a adresy sú príklady.

**Chyby (z lekcie 10.2):**
A. Prihlásenie ako root s heslom
B. Databáza, cache alebo vyhľadávací klaster otvorené do internetu
C. Otvorené Docker API alebo `docker.sock` v kontajneri
D. `chmod 777`, aby zmizlo chybové hlásenie
E. `curl ... | bash` a softvér odkiaľkoľvek
F. Žiadne aktualizácie alebo aktualizácie "neskôr"
G. Žiadna záloha alebo záloha, ktorá nikdy nebola otestovaná
H. Administračný panel otvorený pre všetkých, bez dvojfaktorového overenia
I. Tajné údaje v Gite alebo vo vašom súbore compose
J. Firewall "len na chvíľu" vypnutý, všetko ako root, žiadne poznámky

---

**Prípad 1.** Na `web1.example.com` je v `compose.yaml` pri službe `redis`: `ports: - "6379:6379"`. `ufw status` zobrazuje iba 22, 80 a 443. Sken zvonku nájde otvorený port 6379.
Prvý krok: (a) znova spustiť ufw (b) odstrániť pravidlo portu alebo ho zmeniť na `"127.0.0.1:6379:6379"` a znova `docker compose up -d` (c) dať Redisu iné číslo portu (d) reštartovať server

**Prípad 2.** Vývojár webovej aplikácie na `app.example.net` hlási, že nahrávanie súborov nefungovalo. "Vyriešil" to a teraz majú všetky súbory v `/var/www/app` nastavené `-rwxrwxrwx`.
Prvý krok: (a) nechať to tak, teraz to funguje (b) dať používateľovi webového servera práva na zápis iba do priečinka na nahrávanie, zvyšok vrátiť na 644/755 s iným vlastníkom (c) spúšťať webový server ako root (d) vypnúť AppArmor

**Prípad 3.** Verejný repozitár od včera obsahuje súbor `.env` s `MAIL_API_KEY=...` zo servera `web2.example.org`.
Prvý krok: (a) odstrániť súbor z repozitára (b) zrušiť kľúč v e-mailovej službe a vytvoriť nový, a pridať `.env` do `.gitignore` (c) premenovať repozitár (d) nerobiť nič

**Prípad 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` vráti `permitrootlogin yes` a `passwordauthentication yes`. V journale sú každú minútu pokusy o prihlásenie ako root.
Prvý krok: (a) nainštalovať fail2ban a nič viac (b) umiestniť kľúč pre bežného správcu so sudo, otestovať ho a potom vypnúť prihlasovanie heslom a prihlásenie ako root s heslom (c) presunúť SSH na port 2222 (d) uložiť heslo roota do textového súboru

**Prípad 5.** `cat /etc/os-release` zobrazuje vydanie Ubuntu, ktorého štandardná podpora skončila pred tromi rokmi, bez ESM. `apt list --upgradable` je prázdny.
Prvý krok: (a) tešiť sa, nie sú žiadne aktualizácie (b) naplánovať upgrade alebo nový server s podporovanou verziou LTS, so snapshotom a zálohou (c) znova nainštalovať unattended-upgrades (d) reštartovať server

**Prípad 6.** Kontajner `portainer` má zväzok `/var/run/docker.sock:/var/run/docker.sock` a je dostupný na `https://beheer.example.com` s heslom `admin123`, bez dvojfaktorového overenia.
Vyberte chybu, ktorá umožňuje najväčšiu škodu, ak niekto heslo uhádne. Prvý krok: (a) umiestniť panel za SSH tunel alebo pevnú adresu a nastaviť silné heslo s dvojfaktorovým overením (b) reštartovať kontajner (c) zvoliť inú subdoménu (d) znova nainštalovať Docker

**Prípad 7.** Po neúspešnej aktualizácii databázy sa ukáže, že jedinou zálohou je dva mesiace starý snapshot na rovnakom úložisku ako server. Nikto nikdy neskúsil obnovu.
Prvý krok do budúcnosti: (a) vytvárať viac snapshotov (b) nastaviť šifrované zálohy mimo servera (napríklad restic) s monitorovaním a testom obnovy (c) databázu už nikdy neaktualizovať (d) druhý disk v tom istom serveri

**Prípad 8.** Na serveri je `/usr/local/bin/tool` a neznámy zdroj balíkov `extra.list` s voľbou `[trusted=yes]`. Nikto nevie, odkiaľ pochádzajú; predchádzajúci správca inštaloval "všetko jedným riadkom z webovej stránky".
Prvý krok: (a) nechať to tak, funguje to (b) zistiť, čo je to za zdroj a program, vypnúť zdroj pomocou `trusted=yes` a inštalovať už iba z distribúcie alebo z oficiálneho zdroja výrobcu pomocou `Signed-By` (c) reštartovať server (d) odstrániť všetky balíky

Pri každom prípade vyplňte: chybu (A-J) a prvý krok (a-d).