Lühidalt: Võõraid administraatorikontosid leiate ainult siis, kui kontrollite kõiki tasandeid: CMS-i või poodi, majutuspaneeli, serveri süsteemikasutajaid, SSH-ligipääse ja andmebaasikasutajaid. Ärge tuginege tagaliidese kasutajanimekirjale, sest sissetoodud kood võib kontosid seal peita. Leiud esmalt dokumenteerige ja blokeerige, siis selgitage põhjus, alles seejärel kustutage.
Miks tundmatu administraator on nii ohtlik
Täiendav administraatorikonto on ründajatele kõige mugavam tagauks. See ei vaja kahjulikku koodi, faili-skannimisel ei jää silma ja elab üle iga uuenduse. Kes hiljem selle kontoga sisse logib, näeb protokollis välja nagu tavaline toimetaja.
Pärast PHP2Shelli see kontroll kaalub. Turvaaugud CVE-2026-109618 ja CVE-2026-109619 lubavad kahjuliku koodi käivitamist ilma sisselogimiseta. Kes saab serveris koodi käivitada, saab ka andmebaasi kirjutada ja seeläbi kontosid luua. PHP uuendus sulgeb turvaaugu, kuid ei eemalda kontot, mis tekkis enne.
PHP2Shelli kohta ei ole avaldatud ja kinnitatud kompromiteerimistunnuseid (Indicators of Compromise), see tähendab tüüpiliste jälgede nimekirja. Tundmatu konto ei ole seetõttu PHP2Shelli tõend, kuid selge vihje loata ligipääsule, olenemata teest. Täiendavate tunnuste ülevaade on lehel Kas olen juba kompromiteeritud?.
Kus võõrad administraatorikontod võivad peituda
Paljud haldajad vaatavad ainult CMS-i. Ründajad mõtlevad tasanditena ja igal tasandil on omad kontod:
| Tasand | Kust vaadata | Mida jälgida |
|---|---|---|
| CMS või pood | kasutajahaldus ja kasutajate andmebaasitabel | administraatori roll, loomise kuupäev, võõras e-posti aadress |
| Majutuspaneel | kasutajad, lisakontod, FTP-kontod | kontod, mille keegi meeskonnast pole loonud |
| Linuxi server | /etc/passwd, grupid sudo või wheel, sudoers |
täiendavad kontod UID 0-ga, uued sisselogimisshellid |
| SSH | kõigi kasutajate authorized_keys |
võtmed ilma tuntud omanikuta |
| Andmebaas | andmebaasiserveri kasutajatabel | kasutajad globaalsete õigustega või hostiga % |
| Välised teenused | domeen, DNS, Search Console, CDN | täiendavad omanikud või õigustatud isikud |
SSH tasand on piisavalt iseseisev eraldi artikli jaoks: Tundmatute SSH-võtmete leidmine ja eemaldamine.
Võõraste administraatorikontode leidmine CMS-is, ka peidetud
Tagaliidese kasutajanimekirja loob rakendus ise. Kui sissetoodud kood töötab kaasa, võib see üksikuid kirjeid välja filtreerida. Usaldusväärsemad on seetõttu tööriistad, mis vaatavad otse salvestatud andmeid. WordPressi puhul loetleb WP-CLI kõik administraatorid loomise kuupäevaga:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Veel taseme võrra sügavamale läheb andmebaasi lugev päring. See näitab iga kontot, millele on administraatori roll määratud, olenemata sellest, mida liides kuvab. Tabeli prefiksi wp_ kohandage oma paigaldusele:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Võrrelge tagaliidese, WP-CLI ja andmebaasi tulemusi. Kui konto ilmub ainult andmebaasis, on see tugev hoiatusmärk, sest siis on mängus lisaks kood, mis seda peidab. Teiste süsteemide, nagu Shopware, TYPO3 või Joomla puhul kehtib sama põhimõte: pärige kasutajatabelit otse ja võrrelge tagaliideses kuvatavaga. Millised tabelid need on, seisab tootja dokumentatsioonis.
Süsteemikasutajate ja andmebaasikasutajate kontroll
Serveris endas pakuvad huvi eelkõige root-õigustega kontod ja kontod, mis saavad sisse logida. Järgmised käsud ainult loevad:
# UID 0-ga kontod (tavaliselt ainult root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Kontod päris sisselogimisshelliga
grep -vE '(nologin|false)$' /etc/passwd
# Administraatorigruppide liikmed
getent group sudo wheel
# Täiendavad sudo-reeglid
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Viimased sisselogimised täieliku kuupäevaga
last -F | head -30
Andmebaasiserveris kontrollite, millised kasutajad on olemas ja millised õigused neil on:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Rakendus vajab üldjuhul kasutajat õigustega täpselt ühele andmebaasile. Täiendav kasutaja globaalsete õigustega, kellel on lubatud pääseda ligi suvalistelt hostidelt (%), tuleb selgitada.
Ärge unustage serverist väljaspool olevaid kontosid. Kellel on ligipääs domeenilepingule või DNS-haldusele, saab külastajaid ümber suunata või lasta sertifikaate võõrastele serveritele välja anda. Täiendav omanik Google Search Console'is saab esitada saidikaarte ja muuta sätteid. Käige seetõttu registripidaja, DNS-pakkuja, CDN-i ja Search Console'i puhul õigustatud isikute nimekiri läbi ja võrrelge seda sellega, mida teie meeskond tunneb.
Nii toimite leiuga õigesti
Esimene impulss on võõras konto kohe kustutada. Sellega kaob aga ka oluline jälg: loomise kuupäev piirab sageli, millal ründaja süsteemis oli. Parem on see järjekord:
- Dokumenteerige: märkige kasutajanimi, ID, e-post, loomise kuupäev, roll ja viimane tegevus kellaajaga, parimal juhul ekraanipildi ja ekspordina.
- Blokeerige, ärge kustutage: võtke roll ära, asendage parool juhusliku väärtusega või deaktiveerige konto.
- Piirake ajavahemikku: kontrollige logisid loomise kuupäeva ümbruses. Millised päringud olid veidi enne, millised failid muutusid?
- Kontrollige muid tasandeid: kes konto loob, jätab harva maha ainult ühe. Vaadake läbi ka failid, cron-tööd, SSH-võtmed ja andmebaas.
- Puhastage ja uuendage ligipääsud: alles pärast puhastamist ja PHP uuendust uuendage kõik paroolid, võtmed ja sessioonid.
Ettevaatuse märkus: mitte iga tundmatu konto ei ole pahatahtlik. Agentuurid, endised teenusepakkujad või hooldusplugin'd loovad vahel oma kontosid. Selgitage see enne häire tõstmist, kuid selgitage kiiresti.
Kordumise vältimine
Pärast puhastamist peaksid administraatorikontod olema erand, mitte reegel. End on tõestanud isiklikud kontod jagatud ligipääsude asemel, võimalikult vähe administraatoreid ja kaheastmeline autentimine administraatori ligipääsude jaoks. Määrake lisaks, kes tohib uusi administraatorikontosid luua ja kus see dokumenteeritakse.
Korrapärane päring nagu ülaltoodud, näiteks iganädalane ja võrdlusega eelmise nädalaga, teeb uued kontod kiiresti nähtavaks. WordPressi puhul aitab lisaks juhend Tagauste leidmine WordPressis.
Kuidas PHP SOS konkreetselt aitab?
- Kontrollime kõiki kontotasandeid CMS-ist serveri kaudu andmebaasini ning võrdleme tagaliidese kuva ja salvestatud andmeid.
- Kindlustame leiud ajatemplitega enne, kui kontosid blokeeritakse või eemaldatakse.
- Selgitame intsidendile reageerimise raames, kuidas konto tekkis ja kas on olemas muid tagauksi.
- Uuendame ligipääsud õiges järjekorras ja seadistame uute administraatorikontode pideva kontrolli.
Korduma kippuvad küsimused
Kas peaksin tundmatu administraatorikonto kohe kustutama?
Parem mitte kohe. Dokumenteerige esmalt kasutajanimi, loomise kuupäev, e-posti aadress ja viimane tegevus ning blokeerige konto. Kustutage alles siis, kui jäljed on kindlustatud, sest loomise kuupäev on sageli oluline vihje sissemurdmise ajahetkele.
Kas administraatorikonto võib tagaliideses olla nähtamatu?
Jah. Sissetoodud kood võib üksikuid kontosid liidese kasutajanimekirjast peita. Andmebaasi otsepäring või käsurea tööriist näitab seevastu kõiki salvestatud kontosid. Seetõttu ei tohiks te vaadata ainult tagaliideses.
Milliseid tasandeid peab lisaks CMS-ile kontrollima?
Majutuspaneel, FTP- ja SFTP-ligipääsud, serveri süsteemikasutajad kaasa arvatud sudo-õigused, SSH-võtmed, andmebaasikasutajad ning kontod domeeni, DNS-i ja Search Console'i juures. Ründaja vajab tagasitulekuks vaid ühte neist ustest.
Kas pärast leidu piisab kõigi paroolide muutmisest?
Ei. Võõras konto näitab, et keegi oli ligipääsu saanud. Siis tuleb selgitada ka sissetungikoht, muud tagauksed ja võimalik andmevoog. Paroole muutke alles pärast puhastamist ja puhtast seadmest.