Nežinomų SSH raktų radimas ir šalinimas

Trumpai: norėdami rasti nežinomus SSH raktus, turite patikrinti visus authorized_keys failus serveryje, ne tik root. Su sshd -T nustatykite, kuriuos failus skaito jūsų SSH tarnyba, išvardykite kiekvieno rakto kontrolinius kodus ir palyginkite su žinomais raktais. Svetimus įrašus pirmiausia išsaugokite, tada pašalinkite ir po to sutvirtinkite prieigą.

Raktas, išgyvenantis kiekvieną slaptažodžio keitimą

Po incidento daugelis operatorių pirmiausia pakeičia visus slaptažodžius. Nuo vienų nepastebimiausių užpakalinių durų tai nepadeda: papildomo viešojo rakto authorized_keys faile. Kas turi atitinkamą privatųjį raktą, prisijungia be slaptažodžio, tol, kol kas nors suras eilutę.

Todėl nežinomi SSH raktai priklauso požymiams, kuriuos po kodo vykdymo reikia tikrinti visada. PHP2Shell atveju paskelbtų, patvirtintų kompromitavimo indikatorių (Indicators of Compromise) nėra; aptikimas remiasi elgsenos analize. Svetimas raktas nėra specifinis PHP2Shell įrodymas, bet aiškus ženklas, kad kažkas norėjo ilgalaikės prieigos. Kitus požymius aprašo Ar jau esu pažeistas?.

Kur serveryje saugomi SSH raktai

Pagal dokumentaciją OpenSSH pagal numatytuosius nustatymus skaito du failus kiekvieno naudotojo namų kataloge: .ssh/authorized_keys ir .ssh/authorized_keys2. Antrasis dažnai pamirštamas. Nustatymą galima pakeisti, o su AuthorizedKeysCommand serveris raktus gali gauti net iš išorinės programos. Todėl pirmiausia patikrinkite, kas jūsų serveryje iš tikrųjų galioja:

# Išvesti efektyvią SSH konfigūraciją (tik skaitymas)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Papildomi konfigūracijos failai ir Match blokai
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Ypatinga vieta yra žiniatinklio serverio naudotojo namų katalogas. Debian ir Ubuntu sistemose www-data tai dažnai yra /var/www. Jei šis katalogas PHP rašomas, įterptas kodas ten gali sukurti .ssh/authorized_keys. Ar prisijungimas tuomet pavyks, priklauso nuo prisijungimo apvalkalo ir SSH nustatymų, bet pats failas jau yra pavojaus ženklas.

Ne kiekvienas nežinomas įrašas yra piktavalis. Diegimo įrankiai, atsarginių kopijų paslaugos ar ankstesni paslaugų teikėjai deda savo raktus. Tokie įrašai tačiau turėtų turėti žinomą savininką ir paskirtį.

authorized_keys patikra žingsnis po žingsnio

Toliau pateiktos komandos nieko nekeičia. Jos išvardija visus naudotojų raktų failus ir kiekvienam raktui parodo kontrolinį kodą:

# Visi authorized_keys failai visų naudotojų namų kataloguose
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

# Parodyti failo kontrolinius kodus ir komentarus
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Kiti raktų failai už įprastų vietų ribų
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Rezultatą peržiūrėkite pagal šį kontrolinį sąrašą:

1. Ar kiekvienas raktas priklauso žinomam asmeniui ar paslaugai? Palyginkite kontrolinius kodus, ne tik komentarą.
2. Ar naudotojas turi raktą, kurio išvis neturėtų turėti? Pavyzdžiui, žiniatinklio serverio, duomenų bazės ar paslaugų paskyros.
3. Ar prieš raktą yra parinkčių? Įrašai su command= kiekvieno prisijungimo metu vykdo fiksuotą komandą. Tai teisėta atsarginėms kopijoms, bet ir slėptuvė.
4. Kada failas paskutinį kartą pakeistas? Pakeitimo data po 2026-10-17, pagal žiniasklaidos pranešimus pirmojo pastebėto PHP2Shell atakos bandymo dienos, vertas ypatingo dėmesio. Laiko žymas tačiau galima suklastoti.
5. Ar sutampa savininkas ir teisės? Failas, priklausantis kitam naudotojui nei namų katalogas, krenta į akis.

Svetimų raktų saugus pašalinimas

Prieš ištrindami eilutę, failą išsaugokite su laiko žyma ir kontroline suma už serverio ribų. Užsirašykite svetimo rakto kontrolinį kodą. Jis vėliau padeda atsakyti, ar tas pats raktas atsiranda ir kituose serveriuose, pavyzdžiui, agentūros su daug klientų sistemų.

Papildomai patikrinkite prisijungimo protokolus. /var/log/auth.log (Debian, Ubuntu) arba /var/log/secure (RHEL šeima) SSH tarnyba registruoja sėkmingus prisijungimus su naudoto rakto kontroliniu kodu. Taip matote, ar svetimas raktas jau buvo naudotas ir iš kokio adreso.

Pagalvokite ir apie priešingą kryptį. Jei serveryje yra privačių raktų, pavyzdžiui, po ~/.ssh/id_* diegimams ar atsarginėms kopijoms, užpuolikas galėjo juos nukopijuoti. Su jais jis galbūt pasiekia kitus serverius, Git saugyklas ar atsarginių kopijų tikslus. Tokie raktai po įsilaužimo laikomi nebetinkamais: sukurkite naujus raktus ir senus pašalinkite visose tikslinėse sistemose.

Svetimas raktas retai yra vienintelis pėdsakas. Kas jį padėjo, turėjo rašymo teises ir galbūt įrengė kitus kelius, pavyzdžiui, cron užduotis ar papildomas paskyras. Todėl patikrinkite ir paslėptas cron užduotis bei svetimas administratoriaus paskyras. Jei užpuolikas turėjo root teises, serverio perkūrimas dažnai patikimesnis nei išvalymas.

Po to SSH prieigą sutvirtinti

Po išvalymo verta trumpai sutvirtinti. Dauguma punktų įgyvendinami greitai, bet visada turėtų būti išbandomi su antra, atvira sesija, kad savęs neišblokuotumėte.

Be to, tvarkykite visų įgaliotų raktų sąrašą su savininku ir paskirtimi. Kai darbuotojas ar paslaugų teikėjas išeina, jo raktas pašalinamas visuose serveriuose. Be šio sąrašo kita patikra vėl yra detektyvinis darbas. Pripažintus SSH sutvirtinimo reikalavimus turi ir CIS Benchmarks.

Kaip PHP SOS padeda konkrečiai?

• Nustatome, kuriuos raktų failus jūsų SSH tarnyba iš tikrųjų skaito, ir kiekvieną įrašą tikriname pagal žinomus savininkus.
• Radinius išsaugome ir vertiname prisijungimo protokolus, kad išsiaiškintume, ar svetimas raktas buvo naudotas.
• Raktus, paskyras ir cron užduotis išvalome teisinga eile ir prieš tai uždarome spragą.
• Vykdydami serverio sutvirtinimą įgyvendiname SSH nustatymus ir įrengiame raktų valdymą su savininkų sąrašu.

Dažni klausimai

Šaltiniai

• BSI: Nuorodos dėl IT saugumo incidentų
• php.net: saugumo pranešimai
• CIS Benchmarks