Pe scurt: Pentru a găsi chei SSH necunoscute, trebuie să verificați toate fișierele authorized_keys de pe server, nu doar pe cel al lui root. Stabiliți cu sshd -T ce fișiere citește serviciul dumneavoastră SSH, listați amprentele fiecărei chei și comparați-le cu cheile cunoscute. Intrările străine se păstrează mai întâi, apoi se elimină, iar accesul se securizează după aceea.
Cheia care supraviețuiește oricărei schimbări de parolă
După un incident, mulți operatori schimbă mai întâi toate parolele. Împotriva uneia dintre cele mai discrete uși din spate aceasta nu ajută: o cheie publică suplimentară într-un fișier authorized_keys. Cine deține cheia privată corespunzătoare se autentifică fără parolă, până când cineva găsește rândul.
Cheile SSH necunoscute se numără de aceea printre semnele care ar trebui verificate întotdeauna după o execuție de cod. Pentru PHP2Shell nu există Indicators of Compromise publicate și confirmate; detectarea se bazează pe analiza comportamentului. O cheie străină nu este o dovadă specifică PHP2Shell, ci un semn clar că cineva a vrut un acces permanent. Alte semne descrie Sunt deja compromis?.
Unde se află cheile SSH pe server
OpenSSH citește, conform documentației, în mod implicit două fișiere din directorul home al fiecărui utilizator: .ssh/authorized_keys și .ssh/authorized_keys2. Al doilea este adesea uitat. Setarea poate fi schimbată, iar cu AuthorizedKeysCommand serverul poate obține chei chiar dintr-un program extern. Verificați de aceea mai întâi ce se aplică efectiv pe serverul dumneavoastră:
# Afișarea configurației SSH efective (doar citire)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'
# Fișiere de configurare suplimentare și blocuri Match
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/
Un loc aparte este directorul home al utilizatorului serverului web. Pe Debian și Ubuntu, pentru www-data este adesea /var/www. Dacă acest director poate fi scris de PHP, codul introdus poate crea acolo un .ssh/authorized_keys. Dacă autentificarea reușește atunci depinde de shell-ul de autentificare și de setările SSH, dar fișierul în sine este deja un semn de alarmă.
Nu orice intrare necunoscută este rău intenționată. Uneltele de deployment, serviciile de backup sau prestatorii anteriori depun chei proprii. Astfel de intrări ar trebui însă să aibă un proprietar și un scop cunoscute.
Verificarea authorized_keys: pas cu pas
Comenzile următoare nu modifică nimic. Ele listează toate fișierele de chei ale utilizatorilor și arată pentru fiecare cheie amprenta:
# Toate fișierele authorized_keys din directoarele home ale tuturor utilizatorilor
getent passwd | cut -d: -f1,6 | while IFS=: read -r user home; do
for f in "$home/.ssh/authorized_keys" "$home/.ssh/authorized_keys2"; do
[ -f "$f" ] && echo "== $user: $f" && sudo ls -la --time-style=full-iso "$f"
done
done
# Afișarea amprentelor și a comentariilor unui fișier
sudo ssh-keygen -lf /root/.ssh/authorized_keys
# Alte fișiere de chei în afara locurilor obișnuite
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null
Parcurgeți rezultatul cu această listă de verificare:
- Aparține fiecare cheie unei persoane sau unui serviciu cunoscut? Comparați amprentele, nu doar comentariul.
- Are un utilizator chei pe care nu ar trebui să le aibă deloc? De exemplu utilizatorul serverului web, utilizatorii bazei de date sau conturile de serviciu.
- Există opțiuni înaintea cheii? Intrările cu
command=execută la fiecare autentificare o comandă fixă. Aceasta este legitimă pentru backupuri, dar și o ascunzătoare. - Când a fost modificat ultima dată fișierul? O dată a modificării după 17.10.2026, prima tentativă de atac PHP2Shell observată conform rapoartelor din presă, merită o atenție deosebită. Marcajele de timp pot fi însă falsificate.
- Se potrivesc proprietarul și drepturile? Un fișier care aparține altui utilizator decât directorul home este remarcabil.
Eliminarea sigură a cheilor străine
Înainte de a șterge un rând, păstrați fișierul cu marcaj de timp și sumă de control în afara serverului. Notați amprenta cheii străine. Ea ajută ulterior la întrebarea dacă aceeași cheie apare și pe alte servere, de exemplu la o agenție cu multe sisteme de clienți.
Verificați în plus jurnalele de autentificare. În /var/log/auth.log (Debian, Ubuntu) sau /var/log/secure (familia RHEL), serviciul SSH consemnează autentificările reușite cu amprenta cheii folosite. Astfel vedeți dacă cheia străină a fost deja folosită și de la ce adresă.
Gândiți-vă și la sensul invers. Dacă pe server se află chei private, de exemplu sub ~/.ssh/id_* pentru deployment-uri sau backupuri, un atacator le-a putut copia. Cu ele poate ajunge eventual la alte servere, depozite Git sau ținte de backup. Astfel de chei se consideră, după o intruziune, consumate: generați chei noi și eliminați-le pe cele vechi de pe toate sistemele țintă.
O cheie străină este rareori singura urmă. Cine a depus-o a avut drepturi de scriere și a configurat eventual alte căi, de exemplu cronjob-uri sau conturi suplimentare. Verificați de aceea și cronjob-urile ascunse și conturile de administrator străine. Dacă atacatorul a avut drepturi de root, o reconstruire a serverului este adesea mai de încredere decât o curățare.
Eliminați cheile străine abia când PHP se află la un nivel corectat (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau backport confirmat) și toți workerii au fost reporniți. Altfel atacatorul poate reînscrie imediat cheia prin aceeași vulnerabilitate.
Securizarea accesului SSH după aceea
După curățare merită o scurtă securizare. Majoritatea punctelor se implementează rapid, dar ar trebui testate întotdeauna cu o a doua sesiune deschisă, pentru a nu vă bloca singur.
| Măsură | Setare sau procedură |
|---|---|
| Autentificare doar prin cheie | PasswordAuthentication no |
| Fără autentificare directă a lui root | PermitRootLogin no, lucru prin conturi personale cu sudo |
| Dezactivarea celui de-al doilea fișier de chei | AuthorizedKeysFile .ssh/authorized_keys |
| Limitarea cheii la proveniență | Opțiunea from= înaintea cheii, de exemplu pentru serverele de backup |
| Restrângerea cheilor de serviciu | Opțiunea restrict și un command= fix pentru automatizare |
| Utilizatorul serverului web fără autentificare | Shell de autentificare nologin, fără .ssh în directorul home |
Țineți în plus o listă a tuturor cheilor autorizate, cu proprietar și scop. Dacă un angajat sau un prestator pleacă, cheia lui se elimină de pe toate serverele. Fără această listă, următoarea verificare este din nou muncă de detectiv. Directive de securizare recunoscute pentru SSH conțin și CIS Benchmarks.
Cum ajută PHP SOS concret?
- Stabilim ce fișiere de chei citește efectiv serviciul dumneavoastră SSH și verificăm fiecare intrare față de proprietarii cunoscuți.
- Păstrăm constatările și evaluăm jurnalele de autentificare, pentru a clarifica dacă o cheie străină a fost folosită.
- Curățăm cheile, conturile și cronjob-urile în ordinea corectă și închidem în prealabil vulnerabilitatea.
- În cadrul securizării serverului implementăm setările SSH și configurăm o administrare a cheilor cu listă de proprietari.
Întrebări frecvente
Cum recunosc dacă o cheie SSH este străină?
Fiecare cheie are o amprentă și, de regulă, un comentariu la sfârșitul rândului. Comparați amprentele cu cheile angajaților și ale prestatorilor dumneavoastră. Comentariul singur nu dovedește nimic, deoarece poate fi ales liber și poate fi falsificat.
Ajută să schimb parola de root?
Nu împotriva unei chei introduse. Autentificarea prin cheie nu are nevoie de parolă. De aceea fișierele authorized_keys trebuie verificate și curățate ele însele.
De ce poate utilizatorul serverului web să aibă o cheie SSH?
Utilizatorul serverului web are un director home propriu, pe Debian și Ubuntu adesea /var/www. Dacă acolo se află un .ssh/authorized_keys și contul are un shell de autentificare, o autentificare ca acest utilizator este posibilă. Dacă directorul web poate fi scris, codul PHP introdus poate crea un astfel de fișier.
Ce este authorized_keys2?
Un al doilea fișier mai vechi, pe care OpenSSH îl citește, conform setării implicite, de asemenea. Multe ghiduri de verificare îl trec cu vederea. Controlați cu sshd -T ce fișiere evaluează efectiv serverul dumneavoastră.