Tundmatute SSH-võtmete leidmine ja eemaldamine

Lühidalt: Tundmatute SSH-võtmete leidmiseks peate kontrollima kõiki serveri authorized_keys-faile, mitte ainult root-i oma. Selgitage käsuga sshd -T, milliseid faile teie SSH-teenus loeb, loetlege iga võtme sõrmejäljed ja võrrelge neid tuntud võtmetega. Võõrad kirjed esmalt kindlustage, seejärel eemaldage ja karastage ligipääs.

Võti, mis elab üle iga paroolivahetuse

Pärast intsidenti muudavad paljud haldajad esimese asjana kõik paroolid. Ühe kõige märkamatuma tagaukse vastu see ei aita: täiendav avalik võti authorized_keys-failis. Kes omab sobivat privaatvõtit, logib sisse ilma paroolita, nii kaua, kuni keegi selle rea leiab.

Tundmatud SSH-võtmed kuuluvad seetõttu tunnuste hulka, mida tuleks pärast koodi käivitamist alati kontrollida. PHP2Shelli kohta ei ole avaldatud ja kinnitatud kompromiteerimistunnuseid (Indicators of Compromise); tuvastus põhineb käitumisanalüüsil. Võõras võti ei ole PHP2Shelli-spetsiifiline tõend, kuid selge märk sellest, et keegi soovis püsivat ligipääsu. Täiendavaid tunnuseid kirjeldab Kas olen juba kompromiteeritud?.

Kus SSH-võtmed serveris asuvad

OpenSSH loeb dokumentatsiooni kohaselt vaikimisi kahte faili iga kasutaja kodukataloogis: .ssh/authorized_keys ja .ssh/authorized_keys2. Teine unustatakse sageli. Seadistust saab muuta ja AuthorizedKeysCommand abil võib server võtmeid isegi välisest programmist hankida. Kontrollige seetõttu esmalt, mis teie serveris tegelikult kehtib:

# Efektiivse SSH-seadistuse väljastamine (ainult lugev)
sudo sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|permitrootlogin|passwordauthentication|pubkeyauthentication)'

# Täiendavad seadistusfailid ja Match-plokid
ls -la /etc/ssh/sshd_config.d/ 2>/dev/null
sudo grep -rn -iE '^\s*(Match|AuthorizedKeys)' /etc/ssh/

Eriline koht on veebiserveri kasutaja kodukataloog. Debianis ja Ubuntus on see kasutaja www-data jaoks sageli /var/www. Kui see kataloog on PHP-le kirjutatav, võib sissetoodud kood luua sinna .ssh/authorized_keys. Kas sisselogimine siis õnnestub, sõltub sisselogimisshellist ja SSH-sätetest, kuid fail ise on juba häiresignaal.

Mitte iga tundmatu kirje ei ole pahatahtlik. Juurutustööriistad, varundusteenused või endised teenusepakkujad paigutavad oma võtmed. Sellistel kirjetel peaks siiski olema tuntud omanik ja eesmärk.

authorized_keys kontroll: samm-sammult

Järgmised käsud ei muuda midagi. Need loetlevad kõik kasutajate võtmefailid ja näitavad iga võtme sõrmejälge:

# Kõik authorized_keys-failid kõigi kasutajate kodukataloogides
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

# Faili sõrmejälgede ja kommentaaride kuvamine
sudo ssh-keygen -lf /root/.ssh/authorized_keys

# Täiendavad võtmefailid tavapärastest kohtadest väljaspool
sudo find / -xdev -name 'authorized_keys*' 2>/dev/null

Käige tulemus läbi selle kontrollnimekirjaga:

1. Kas iga võti kuulub tuntud isikule või tuntud teenusele? Võrrelge sõrmejälgi, mitte ainult kommentaari.
2. Kas kasutajal on võti, mida tal üldse olema ei peaks? Näiteks veebiserveri kasutaja, andmebaasi- või teenusekontod.
3. Kas enne võtit on valikuid? Kirjed command=-iga käivitavad iga sisselogimisel kindla käsu. See on varunduste jaoks legitiimne, kuid ka peidukoht.
4. Millal faili viimati muudeti? Muutmiskuupäev pärast 17.10.2026, meediaaruannete kohaselt esimest täheldatud PHP2Shelli rünnakukatset, väärib erilist tähelepanu. Ajatempleid saab aga võltsida.
5. Kas omanik ja õigused klapivad? Fail, mis kuulub teisele kasutajale kui kodukataloog, on silmatorkav.

Võõraste võtmete ohutu eemaldamine

Enne rea kustutamist kindlustage fail ajatempli ja kontrollsummaga väljaspool serverit. Märkige üles võõra võtme sõrmejälg. See aitab hiljem küsimuses, kas sama võti ilmub ka teistes serverites, näiteks paljude kliendisüsteemidega agentuuris.

Kontrollige lisaks sisselogimisprotokolle. Failis /var/log/auth.log (Debian, Ubuntu) või /var/log/secure (RHEL-perekond) protokollib SSH-teenus edukaid sisselogimisi kasutatud võtme sõrmejäljega. Nii näete, kas võõrast võtit on juba kasutatud ja millisest aadressist.

Mõelge ka vastupidisele suunale. Kui serveris asuvad privaatvõtmed, näiteks ~/.ssh/id_* all juurutuste või varunduste jaoks, võis ründaja need kopeerida. Nendega jõuab ta võib-olla teiste serverite, Giti hoidlate või varundussihtkohtadeni. Sellised võtmed loetakse pärast sissemurdmist kasutatuks: looge uued võtmed ja eemaldage vanad kõigis sihtsüsteemides.

Võõras võti on harva ainus jälg. Kes selle sisse seadis, omas kirjutusõigusi ja on võib-olla seadnud sisse muid teid, näiteks cron-töid või täiendavaid kontosid. Kontrollige seetõttu ka peidetud cron-töid ja võõraid administraatorikontosid. Kui ründajal olid root-õigused, on serveri uuesti ülesehitus sageli usaldusväärsem kui puhastamine.

SSH-ligipääsu karastamine pärast

Pärast puhastamist tasub teha lühike karastamine. Enamik punkte on kiiresti ellu viidavad, kuid neid tuleks alati testida teise, avatud sessiooniga, et te ennast välja ei lukustaks.

Pidage lisaks nimekirja kõigist õigustatud võtmetest koos omaniku ja eesmärgiga. Kui töötaja või teenusepakkuja lahkub, eemaldatakse tema võti kõigist serveritest. Ilma selle nimekirjata on järgmine kontroll jälle detektiivitöö. Tunnustatud SSH karastamise juhised sisaldavad ka CIS Benchmarks.

Kuidas PHP SOS konkreetselt aitab?

• Selgitame, milliseid võtmefaile teie SSH-teenus tegelikult loeb, ja kontrollime iga kirjet tuntud omanike vastu.
• Kindlustame leiud ja hindame sisselogimisprotokolle, et selgitada, kas võõrast võtit on kasutatud.
• Puhastame võtmed, kontod ja cron-tööd õiges järjekorras ning sulgeme enne turvaaugu.
• Serveri karastamise raames rakendame SSH-sätted ja seadistame võtmehalduse omanikunimekirjaga.

Korduma kippuvad küsimused

Allikad

• BSI: märkused IT-turvaintsidentide kohta
• php.net: turvateated
• CIS Benchmarks