# Esettanulmányok a Z10.2 feladathoz (VPS és Linux-szerverüzemeltetés tanfolyam)

Esetenként válassza ki, melyik hibáról van szó, és mi a legjobb első lépés. Minden név és cím csak példa.

**Hibák (a 10.2. leckéből):**
A. Root-bejelentkezés jelszóval
B. Az internet felé nyitott adatbázis, gyorsítótár vagy keresőfürt
C. Nyitott Docker API vagy `docker.sock` egy konténerben
D. `chmod 777` egy hibaüzenet eltüntetésére
E. `curl ... | bash` és bárhonnan származó szoftver
F. Nincsenek frissítések, vagy a frissítések "majd később"
G. Nincs biztonsági mentés, vagy a biztonsági mentést soha nem tesztelték
H. Mindenki számára nyitott kezelőpanel kétlépcsős azonosítás nélkül
I. Titkos adatok a Gitben vagy a compose-fájlban
J. "Csak egy pillanatra" kikapcsolt tűzfal, minden rootként, semmi jegyzet

---

**1. eset.** A(z) `web1.example.com` szerveren a(z) `compose.yaml` fájlban a(z) `redis` szolgáltatásnál ez áll: `ports: - "6379:6379"`. A(z) `ufw status` csak a 22-es, 80-as és 443-as portot mutatja. Egy külső vizsgálat nyitva találja a 6379-es portot.
Első lépés: (a) az ufw újraindítása (b) a portszabály eltávolítása vagy átírása erre: `"127.0.0.1:6379:6379"`, majd ismét `docker compose up -d` (c) a Redis másik portszámra állítása (d) a szerver újraindítása

**2. eset.** Egy webalkalmazás fejlesztője a(z) `app.example.net` szerveren jelzi, hogy a feltöltések nem működtek. "Megoldotta" a problémát, és most a(z) `/var/www/app` összes fájlja `-rwxrwxrwx` jogosultságú.
Első lépés: (a) hagyjuk így, most működik (b) a webszerver-felhasználó csak a feltöltési mappára kapjon írási jogot, a többi kerüljön vissza 644/755-re, más tulajdonossal (c) a webszerver futtatása rootként (d) az AppArmor kikapcsolása

**3. eset.** Egy nyilvános repository tegnap óta tartalmaz egy `.env` fájlt, benne a(z) `web2.example.org` szerver `MAIL_API_KEY=...` adatával.
Első lépés: (a) a fájl törlése a repositoryból (b) a kulcs visszavonása a levelezőszolgáltatásnál és egy új létrehozása, valamint a(z) `.env` felvétele a(z) `.gitignore` fájlba (c) a repository átnevezése (d) semmit sem teszünk

**4. eset.** A(z) `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` eredménye `permitrootlogin yes` és `passwordauthentication yes`. A naplóban percenként láthatók root elleni próbálkozások.
Első lépés: (a) a fail2ban telepítése, és semmi más (b) kulcs elhelyezése egy sudo jogú, hétköznapi rendszergazda számára, tesztelés, majd a jelszavas bejelentkezés és a jelszavas root-bejelentkezés kikapcsolása (c) az SSH áthelyezése a 2222-es portra (d) a root-jelszó tárolása egy szövegfájlban

**5. eset.** A(z) `cat /etc/os-release` olyan Ubuntu-kiadást mutat, amelynek normál támogatása három éve lejárt, ESM nélkül. A(z) `apt list --upgradable` üres.
Első lépés: (a) örülni, hogy nincsenek frissítések (b) frissítés vagy új szerver megtervezése egy támogatott LTS-re, pillanatképpel és biztonsági mentéssel (c) az unattended-upgrades újratelepítése (d) a szerver újraindítása

**6. eset.** Egy `portainer` konténer a(z) `/var/run/docker.sock:/var/run/docker.sock` kötetet használja, és a(z) `https://beheer.example.com` címen érhető el a(z) `admin123` jelszóval, kétlépcsős azonosítás nélkül.
Válassza ki azt a hibát, amely a legnagyobb kárt teszi lehetővé, ha kitalálják a jelszót. Első lépés: (a) a panel SSH-alagút vagy fix cím mögé helyezése, valamint erős jelszó és kétlépcsős azonosítás beállítása (b) a konténer újraindítása (c) másik aldomain választása (d) a Docker újratelepítése

**7. eset.** Egy sikertelen adatbázis-frissítés után kiderül, hogy az egyetlen biztonsági mentés egy két hónapos pillanatkép, ugyanazon a tárolón, mint a szerver. Visszaállítást soha senki nem próbált ki.
Első lépés a jövőre nézve: (a) több pillanatkép készítése (b) titkosított, szerveren kívüli biztonsági mentések beállítása (például restic), felügyelettel és visszaállítási teszttel (c) az adatbázist soha többé nem frissítjük (d) egy második lemez ugyanabban a szerverben

**8. eset.** A szerveren megtalálható a(z) `/usr/local/bin/tool`, valamint egy ismeretlen csomagforrás, `extra.list`, a(z) `[trusted=yes]` opcióval. Senki sem tudja, honnan származnak; az előző rendszergazda "mindent egyetlen sorral telepített egy weboldalról".
Első lépés: (a) hagyjuk így, működik (b) kideríteni, mi a forrás és a program, a forrást `trusted=yes` segítségével letiltani, és ezentúl csak a disztribúcióból vagy a készítő hivatalos forrásából telepíteni `Signed-By` segítségével (c) a szerver újraindítása (d) az összes csomag eltávolítása

Esetenként adja meg: hiba (A-J) és első lépés (a-d).