Nezināmu SSH atslēgu atrašana un noņemšana

Īsi sakot: Lai atrastu nezināmas SSH atslēgas, serverī jāpārbauda visi authorized_keys faili, ne tikai root fails. Ar sshd -T noskaidrojiet, kurus failus jūsu SSH pakalpojums lasa, uzskaitiet katras atslēgas pirkstu nospiedumus un salīdziniet tos ar zināmajām atslēgām. Svešus ierakstus vispirms nodrošiniet, tad noņemiet un pēc tam nostipriniet piekļuvi.

Atslēga, kas pārdzīvo katru paroles maiņu

Pēc incidenta daudzi operatori pirmā darbā maina visas paroles. Pret vienu no neuzkrītošākajām slēptajām piekļuvēm tas nepalīdz: papildu publisko atslēgu authorized_keys failā. Kam ir atbilstošā privātā atslēga, pieteicas bez paroles, tik ilgi, kamēr kāds rindu atrod.

Nezināmas SSH atslēgas tāpēc pieder pie pazīmēm, kas pēc koda izpildes vienmēr jāpārbauda. PHP2Shell nav publicētu, apstiprinātu Indicators of Compromise; atpazīšana balstās uz uzvedības analīzi. Sveša atslēga nav specifisks PHP2Shell pierādījums, bet skaidra zīme, ka kāds gribēja pastāvīgu piekļuvi. Citas pazīmes apraksta Vai esmu jau kompromitēts?.

Kur serverī atrodas SSH atslēgas

OpenSSH saskaņā ar dokumentāciju pēc noklusējuma lasa divus failus katra lietotāja mājas direktorijā: .ssh/authorized_keys un .ssh/authorized_keys2. Otro bieži aizmirst. Iestatījumu var mainīt, un ar AuthorizedKeysCommand serveris atslēgas var pat saņemt no ārējas programmas. Tāpēc vispirms pārbaudiet, kas jūsu serverī patiešām ir spēkā:

# Izvadīt efektīvo SSH konfigurāciju (tikai lasot)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Papildu konfigurācijas faili un Match bloki
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Īpaša vieta ir tīmekļa servera lietotāja mājas direktorija. Debian un Ubuntu sistēmās tā www-data bieži ir /var/www. Ja šī direktorija PHP ir rakstāma, ievadīts kods tur var izveidot .ssh/authorized_keys. Vai pieteikšanās tad izdodas, ir atkarīgs no pieteikšanās čaulas un SSH iestatījumiem, taču pats fails jau ir trauksmes signāls.

Ne katrs nezināms ieraksts ir ļaunprātīgs. Izvietošanas rīki, rezerves kopiju pakalpojumi vai agrākie pakalpojumu sniedzēji noglabā savas atslēgas. Šādiem ierakstiem tomēr jābūt zināmam īpašniekam un nolūkam.

authorized_keys pārbaude: solis pa solim

Šīs komandas neko nemaina. Tās uzskaita visu lietotāju atslēgu failus un katrai atslēgai parāda pirkstu nospiedumu:

# Visi authorized_keys faili visu lietotāju mājas direktorijās
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

# Parādīt faila pirkstu nospiedumus un komentārus
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Citi atslēgu faili ārpus ierastajām vietām
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Rezultātu izejiet ar šo kontrolsarakstu:

1. Vai katra atslēga pieder zināmai personai vai zināmam pakalpojumam? Salīdziniet pirkstu nospiedumus, ne tikai komentāru.
2. Vai kādam lietotājam ir atslēga, kam tās nemaz nevajadzētu būt? Piemēram, tīmekļa servera lietotājam, datubāzes vai pakalpojumu kontiem.
3. Vai pirms atslēgas ir opcijas? Ieraksti ar command= pie katras pieteikšanās izpilda fiksētu komandu. Tas ir likumīgi rezerves kopijām, bet arī slēptuve.
4. Kad fails pēdējoreiz mainīts? Izmaiņu datums pēc 17.10.2026, kas saskaņā ar plašsaziņas līdzekļu ziņojumiem bija pirmais novērotais PHP2Shell uzbrukuma mēģinājums, pelna īpašu uzmanību. Laika zīmogus tomēr var viltot.
5. Vai īpašnieks un tiesības sakrīt? Fails, kas pieder citam lietotājam nekā mājas direktorija, uzkrīt.

Svešu atslēgu droša noņemšana

Pirms dzēšat rindu, failu nodrošiniet ar laika zīmogu un kontrolsummu ārpus servera. Pierakstiet sveša atslēgas pirkstu nospiedumu. Tas vēlāk palīdz jautājumā, vai tā pati atslēga parādās arī citos serveros, piemēram, aģentūrā ar daudzām klientu sistēmām.

Pārbaudiet arī pieteikšanās protokolus. /var/log/auth.log (Debian, Ubuntu) vai /var/log/secure (RHEL saime) SSH pakalpojums protokolē sekmīgas pieteikšanās ar izmantotās atslēgas pirkstu nospiedumu. Tā redzat, vai sveša atslēga jau ir izmantota un no kuras adreses.

Padomājiet arī par pretējo virzienu. Ja serverī atrodas privātas atslēgas, piemēram, zem ~/.ssh/id_* izvietošanai vai rezerves kopijām, uzbrucējs tās varēja nokopēt. Ar tām viņš, iespējams, sasniedz citus serverus, Git repozitorijus vai rezerves kopiju mērķus. Šādas atslēgas pēc ielaušanās uzskatāmas par izmantotām: izveidot jaunas atslēgas un vecās noņemt visās mērķa sistēmās.

Sveša atslēga reti ir vienīgā pēda. Kas to noglabājis, tam bija rakstīšanas tiesības un viņš, iespējams, iekārtojis citus ceļus, piemēram, cronjobs vai papildu kontus. Tāpēc pārbaudiet arī slēptos cronjobs un svešos admin kontus. Ja uzbrucējam bija root tiesības, servera jaunbūve bieži ir uzticamāka nekā attīrīšana.

SSH piekļuves pēc tam nostiprināšana

Pēc attīrīšanas vērts veikt īsu nostiprināšanu. Lielāko daļu punktu var īstenot ātri, bet vienmēr tie jātestē ar otru, atvērtu sesiju, lai neizslēgtu sevi.

Turklāt uzturiet visu pilnvaroto atslēgu sarakstu ar īpašnieku un nolūku. Kad darbinieks vai pakalpojumu sniedzējs aiziet, viņa atslēga tiek noņemta visos serveros. Bez šī saraksta nākamā pārbaude atkal ir detektīvdarbs. Atzītas SSH nostiprināšanas prasības ietver arī CIS Benchmarks.

Kā PHP SOS palīdz konkrēti?

• Mēs noskaidrojam, kurus atslēgu failus jūsu SSH pakalpojums patiešām lasa, un pārbaudām katru ierakstu pret zināmajiem īpašniekiem.
• Mēs nodrošinām atradumus un izvērtējam pieteikšanās protokolus, lai noskaidrotu, vai sveša atslēga ir izmantota.
• Mēs sakopjam atslēgas, kontus un cronjobs pareizajā secībā un iepriekš aizveram ievainojamību.
• Servera nostiprināšanas ietvaros mēs īstenojam SSH iestatījumus un iestatām atslēgu pārvaldību ar īpašnieku sarakstu.

Biežāk uzdotie jautājumi

Avoti

• BSI: norādes par IT drošības incidentiem
• php.net: drošības paziņojumi
• CIS Benchmarks