# Studii de caz pentru exercițiul Z10.2 (cursul VPS și administrarea serverelor Linux)

Alegeți pentru fiecare studiu de caz greșeala respectivă și cel mai bun prim pas. Toate numele și adresele sunt exemple.

**Greșeli (din lecția 10.2):**
A. Autentificare root cu parolă
B. O bază de date, un cache sau un cluster de căutare deschis către internet
C. API-ul Docker deschis sau `docker.sock` într-un container
D. `chmod 777` pentru a scăpa de un mesaj de eroare
E. `curl ... | bash` și software de oriunde
F. Fără actualizări sau actualizări „mai târziu”
G. Fără backup sau un backup care nu a fost testat niciodată
H. Panou de administrare deschis pentru oricine, fără autentificare în doi pași
I. Secrete în Git sau în fișierul compose al dumneavoastră
J. Firewall-ul oprit „pentru puțin timp”, totul ca root, fără notițe

---

**Studiul de caz 1.** Pe `web1.example.com`, în `compose.yaml`, la serviciul `redis` apare: `ports: - "6379:6379"`. `ufw status` afișează doar 22, 80 și 443. O scanare din exterior găsește portul 6379 deschis.
Primul pas: (a) reporniți ufw (b) eliminați regula de port sau modificați-o în `"127.0.0.1:6379:6379"` și rulați din nou `docker compose up -d` (c) atribuiți lui Redis un alt număr de port (d) reporniți serverul

**Studiul de caz 2.** Dezvoltatorul unei aplicații web de pe `app.example.net` raportează că încărcările nu funcționau. El a „rezolvat” problema, iar acum toate fișierele din `/var/www/app` au `-rwxrwxrwx`.
Primul pas: (a) lăsați așa, acum funcționează (b) acordați utilizatorului serverului web drepturi de scriere doar pe directorul de încărcări, iar restul readuceți la 644/755 cu un alt proprietar (c) rulați serverul web ca root (d) dezactivați AppArmor

**Studiul de caz 3.** Un repository public conține de ieri un fișier `.env` cu `MAIL_API_KEY=...` al serverului `web2.example.org`.
Primul pas: (a) ștergeți fișierul din repository (b) revocați cheia la serviciul de e-mail și creați una nouă, apoi puneți `.env` în `.gitignore` (c) redenumiți repository-ul (d) nu faceți nimic

**Studiul de caz 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` returnează `permitrootlogin yes` și `passwordauthentication yes`. În jurnal apar în fiecare minut încercări pe root.
Primul pas: (a) instalați fail2ban și nimic altceva (b) adăugați o cheie pentru un administrator obișnuit cu sudo, testați, apoi dezactivați autentificarea cu parolă și autentificarea root cu parolă (c) mutați SSH pe portul 2222 (d) păstrați parola de root într-un fișier text

**Studiul de caz 5.** `cat /etc/os-release` afișează o versiune Ubuntu al cărei suport standard s-a încheiat acum trei ani, fără ESM. `apt list --upgradable` este gol.
Primul pas: (a) bucurați-vă, nu există actualizări (b) planificați un upgrade sau un server nou cu o versiune LTS suportată, cu snapshot și backup (c) reinstalați unattended-upgrades (d) reporniți serverul

**Studiul de caz 6.** Un container `portainer` are volumul `/var/run/docker.sock:/var/run/docker.sock` și este accesibil la `https://beheer.example.com` cu parola `admin123`, fără autentificare în doi pași.
Alegeți greșeala care permite cele mai mari daune dacă parola este ghicită. Primul pas: (a) puneți panoul în spatele unui tunel SSH sau al unei adrese fixe și setați o parolă puternică cu autentificare în doi pași (b) reporniți containerul (c) alegeți un alt subdomeniu (d) reinstalați Docker

**Studiul de caz 7.** După o actualizare eșuată a bazei de date, se constată că singurul backup este un snapshot vechi de două luni, pe aceeași stocare ca serverul. Nimeni nu a încercat vreodată o restaurare.
Primul pas pentru viitor: (a) faceți mai multe snapshot-uri (b) configurați backup-uri criptate în afara serverului (de exemplu restic), cu monitorizare și un test de restaurare (c) nu mai actualizați niciodată baza de date (d) un al doilea disc în același server

**Studiul de caz 8.** Pe server se află `/usr/local/bin/tool` și o sursă de pachete necunoscută `extra.list` cu opțiunea `[trusted=yes]`. Nimeni nu știe de unde provin; administratorul anterior instala „totul cu o singură linie de pe un site web”.
Primul pas: (a) lăsați așa, funcționează (b) aflați ce sunt sursa și programul, dezactivați sursa cu `trusted=yes` și instalați de acum doar din distribuție sau din sursa oficială a producătorului cu `Signed-By` (c) reporniți serverul (d) eliminați toate pachetele

Completați pentru fiecare studiu de caz: greșeala (A-J) și primul pas (a-d).