Ce nu trebuie să faceți

Modulul 10: Rămâneți în siguranță · Timp de citire: 12 minute

Obiectivul lecției: După această lecție veți recunoaște greșelile care duc cel mai des la un server spart sau defect, veți putea explica de ce sunt periculoase și veți ști ce să faceți în schimb.

Noțiuni cheie: autentificare root cu parolă, parolă slabă sau implicită, bază de date deschisă, API-ul Docker pe portul 2375, docker.sock într-un container, chmod 777, curl | bash, secrete în Git, panou de administrare fără autentificare în doi pași, firewall oprit „doar puțin”, fără actualizări, fără backup

De ce o lecție despre greșeli?

Majoritatea serverelor nu sunt sparte de un atacator genial care folosește o vulnerabilitate necunoscută. Sunt sparte de boți care parcurg întregul internet în căutarea unor greșeli cunoscute: o parolă care poate fi ghicită, o bază de date deschisă, un program căruia îi lipsește de luni de zile o actualizare. Cine evită greșelile din această lecție nu mai este o țintă pentru acești boți. Aceasta reprezintă cea mai mare parte a protecției pe care o puteți obține.

Pentru fiecare greșeală găsiți de ce este periculoasă și ce faceți în schimb. Aproape totul ați învățat deja în lecțiile anterioare; această lecție le pune pe toate într-o listă.

1. Autentificare root cu parolă

Problema. Orice server primește toată ziua încercări de autentificare pe root (lecția 5.3). Dacă root se poate autentifica cu parolă, atunci acea parolă este singurul lucru care stă între un bot și controlul complet. Parolele refolosite sau prea scurte sunt ghicite mai devreme sau mai târziu ori se află deja într-o listă scursă.

Faceți așa. Autentificare doar cu chei: PasswordAuthentication no și KbdInteractiveAuthentication no, root cel mult cu o cheie (PermitRootLogin prohibit-password) sau deloc (no), iar munca zilnică o faceți ca utilizator obișnuit cu sudo (lecțiile 2.2 și 3.2). Verificați din exterior ce metode de autentificare oferă serverul dumneavoastră (exercițiul Z2.2).

2. O bază de date, un cache sau un cluster de căutare deschis spre internet

Problema. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch sau OpenSearch (9200) și MongoDB (27017) sunt create pentru programe de încredere într-o rețea de încredere. Dacă ascultă pe 0.0.0.0 fără firewall, scanerele le găsesc repede. Redis afirmă în propria documentație că nu ar trebui expus pe internet și că cineva cu acces poate șterge întregul set de date; prin comanda CONFIG un atacator poate chiar scrie fișiere pe server. Bazele de date și clusterele de căutare deschise sunt de ani de zile o cauză cunoscută a unor scurgeri mari de date și a mesajelor de „răscumpărare” lăsate în locul datelor dumneavoastră.

Faceți așa. Lăsați astfel de servicii să asculte pe 127.0.0.1 (lecția 5.1), păstrați-le în spatele firewall-ului (lecția 5.2) și, în Docker, nu le publicați deloc sau doar pe 127.0.0.1 (lecția 9.3). Pentru a ajunge dumneavoastră la ele de pe laptop: un tunel SSH (lecția 2.3). Verificați din exterior (exercițiul Z5.1).

3. API-ul Docker deschis sau docker.sock într-un container

Problema. Cine poate controla daemonul Docker este, practic, root pe server: documentația Docker spune că doar utilizatorii de încredere au voie să controleze daemonul și consideră accesul la daemon echivalent cu accesul root. Există două variante ale acestei greșeli:

• Daemonul ascultă pe un port TCP fără TLS (de obicei 2375). Oricine ajunge la acel port poate porni containere care includ discul serverului dumneavoastră.
• Un container primește /var/run/docker.sock ca volum („ca să poată administra el însuși containere”). Dacă acel container este spart, întregul server este compromis.

Și grupul docker este echivalent cu root (lecția 9.2): adăugați în el doar administratori.

Faceți așa. Lăsați Docker să funcționeze doar prin socketul local. Administrarea de la distanță se face prin SSH (docker context cu ssh://) sau, dacă trebuie neapărat prin TCP, cu TLS pe portul 2376 și certificate de client. Montați docker.sock doar într-un container în care aveți încredere deplină și de care chiar aveți nevoie, de preferință doar în citire, printr-un proxy restrictiv.

4. chmod 777 pentru a scăpa de un mesaj de eroare

Problema. „Permission denied” (permisiune refuzată) la o încărcare, iar pe un forum cineva spune: chmod -R 777 /var/www. După aceea, orice utilizator și orice proces de pe server poate scrie orice în site-ul dumneavoastră, inclusiv un plugin spart sau un alt cont. Codul care poate fi scris de serverul web poate fi înlocuit, printr-o vulnerabilitate, cu un backdoor.

Faceți așa. Aflați cine trebuie să scrie și unde (lecția 3.1): de obicei doar utilizatorul serverului web, într-un singur director pentru încărcări sau cache. Codul să aibă alt proprietar decât serverul web, cu permisiuni 644/755, iar încărcările 750/640 sau similar.

5. curl ... | bash și software de oriunde

Problema. Un script pe care îl rulați ca root fără să îl citiți poate face orice: poate adăuga surse și chei, poate suprascrie fișiere, poate deschide un serviciu. Chiar dacă intenția este bună, nu mai știți apoi ce s-a schimbat, iar la următorul upgrade de versiune ceva se strică (lecția 4.3).

Faceți așa. Descărcați scriptul și citiți-l. Instalați de preferință din sursa de pachete a distribuției dumneavoastră sau din sursa oficială a producătorului, cu o cheie proprie (Signed-By, lecția 4.1). Notați ce instalați și de ce.

6. Fără actualizări sau actualizări „mai târziu”

Problema. Vulnerabilitățile sunt reparate și apoi exploatate, adesea în câteva zile. Un server care nu primește actualizări luni de zile sau care rulează o versiune fără suport are o listă de breșe cunoscute. Containerele nu sunt actualizate de apt.

Faceți așa. Activați actualizările automate de securitate (lecția 4.2), stabiliți un moment fix pentru reporniri, treceți data de sfârșit a suportului versiunii dumneavoastră în agendă (lecția 4.3) și actualizați containerele regulat (lecția 9.4).

7. Fără backup sau un backup care nu a fost testat niciodată

Problema. Un snapshot pe același spațiu de stocare nu este un backup (lecția 8.1). Un backup aflat pe serverul însuși dispare odată cu acesta în cazul unui atac sau al unui ransomware. Iar un backup care nu a fost niciodată restaurat este o speranță, nu o certitudine.

Faceți așa. Backupuri criptate în afara serverului (restic, lecția 8.2), monitorizare care confirmă că rulează și cel puțin un test de restaurare în fiecare trimestru.

8. Panouri de administrare deschise tuturor, fără autentificare în doi pași

Problema. Un panou de administrare pentru o bază de date (de exemplu phpMyAdmin), pentru Docker (de exemplu Portainer), pentru aplicația dumneavoastră sau pentru seiful de parole este o țintă atractivă: o singură parolă oferă acces la tot. Parolele implicite precum admin/admin și înregistrarea lăsată deschisă (Vaultwarden, lecția 9.4) fac lucrurile și mai ușoare pentru atacator.

Faceți așa. Nu deschideți panourile de administrare spre internet: accesați-le printr-un tunel SSH sau doar de la o adresă fixă. Dacă un panou trebuie totuși să fie public: https, o parolă puternică și unică din managerul de parole, autentificare în doi pași și înregistrarea închisă. Schimbați întotdeauna parolele implicite.

9. Secrete în Git sau în fișierul compose

Problema. O parolă, o cheie API sau o cheie privată dintr-un fișier care ajunge într-un depozit Git rămâne acolo pentru totdeauna în istoric, chiar dacă o ștergeți ulterior. Depozitele publice sunt scanate de boți tocmai după astfel de chei.

Faceți așa. Păstrați secretele într-un fișier separat cu permisiuni 600 (EnvironmentFile, lecția 6.3; .env la Docker Compose, lecția 9.3), trecut în .gitignore. Dacă totuși s-a scurs un secret: înlocuiți-l imediat (o parolă nouă, o cheie nouă); simpla curățare în Git nu este suficientă.

10. Firewall-ul oprit „doar puțin”, totul ca root și fără notițe

Problema. „Opresc puțin firewall-ul ca să testez” ajunge să fie uitat. „Fac asta repede ca root” devine un obicei. Iar un server despre care nimeni nu știe ce rulează pe el și de ce nu poate fi administrat sau restaurat.

Faceți așa. Testați cu o regulă temporară și restrânsă (un singur port, o singură adresă sursă) și ștergeți-o apoi. Lucrați ca utilizator obișnuit cu sudo. Țineți un scurt dosar al serverului: ce rulează, ce porturi sunt deschise, unde se află backupurile, când este data de sfârșit a suportului versiunii (lecția 10.4).

În practică

Toate aceste greșeli pot fi făcute pe orice VPS, la WebOké la fel ca la alți furnizori: ce se întâmplă în interiorul serverului administrați dumneavoastră. Furnizorul poate totuși deconecta un server de la rețea dacă acesta trimite spam sau lansează atacuri, deoarece acest lucru îi afectează pe ceilalți clienți. Prevenția este deci importantă și pentru disponibilitatea propriului server.

Rezumat

• Majoritatea atacurilor folosesc greșeli cunoscute, nu vulnerabilități necunoscute.
• Autentificare cu chei, autentificarea cu parolă dezactivată; bazele de date, cache-urile și API-ul Docker niciodată deschise spre internet; fără docker.sock în containere în care nu aveți încredere deplină.
• Fără chmod 777 și fără curl | bash: știți cine ce are voie și ce instalați.
• Actualizări automate, backupuri în afara serverului și testate, panouri de administrare în spatele unui tunel sau cu autentificare în doi pași.
• Secretele în afara Git și a fișierelor compose; un secret scurs înseamnă un secret înlocuit.

Test (quiz)

Exercițiu

Exercițiul Z10.2: Care este greșeala? Fișierul exemplu casussen-z10-2.md conține opt cazuri scurte de servere care au o problemă. Alegeți pentru fiecare caz care greșeală este, din lista din această lecție (de la A la J), și care este cel mai bun prim pas. Programul compară răspunsurile cu cheia fixă și afișează apoi explicația pentru fiecare caz.

Lecturi suplimentare

• Securizarea VPS-ului dumneavoastră: primele cinci minute
• Manager de parole și passkeys: cum vă gestionați autentificarea în siguranță
• Documentația Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Documentația Docker, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/