Trumpai: svetimas administratoriaus paskyras rasite tik patikrinę visus lygmenis: CMS ar parduotuvę, hostingo skydelį, serverio sistemos naudotojus, SSH prieigas ir duomenų bazės naudotojus. Nepasikliaukite naudotojų sąrašu backend, nes įterptas kodas ten gali slėpti paskyras. Radinius pirmiausia dokumentuokite ir užblokuokite, tada išsiaiškinkite priežastį, tik po to trinkite.
Kodėl nežinomas administratorius toks pavojingas
Papildoma administratoriaus paskyra užpuolikams yra patogiausios užpakalinės durys. Jai nereikia kenkėjiško kodo, ji nekrenta į akis failų patikrose ir išgyvena kiekvieną atnaujinimą. Kas vėliau su šia paskyra prisijungia, protokole atrodo kaip įprastas redaktorius.
Po PHP2Shell ši patikra įgauna svarbos. Pažeidžiamumai CVE-2026-109618 ir CVE-2026-109619 leidžia vykdyti kenkėjišką kodą be prisijungimo. Kas serveryje gali vykdyti kodą, gali ir rašyti į duomenų bazę ir taip kurti paskyras. PHP atnaujinimas spragą uždaro, bet nepašalina anksčiau sukurtos paskyros.
PHP2Shell atveju paskelbtų, patvirtintų kompromitavimo indikatorių (Indicators of Compromise), t. y. tipinių pėdsakų sąrašo, nėra. Nežinoma paskyra todėl nėra PHP2Shell įrodymas, bet aiškus neleistinos prieigos požymis, kad ir kokiu keliu. Kitų požymių apžvalga pateikta puslapyje Ar jau esu pažeistas?.
Kur gali slypėti svetimos administratoriaus paskyros
Daug operatorių žiūri tik į CMS. Užpuolikai mąsto lygmenimis, ir kiekvienas lygmuo turi savo paskyras:
| Lygmuo | Kur žiūrėti | Į ką atkreipti dėmesį |
|---|---|---|
| CMS ar parduotuvė | naudotojų valdymas ir naudotojų duomenų bazės lentelė | administratoriaus rolė, sukūrimo data, svetimas pašto adresas |
| Hostingo skydelis | naudotojai, papildomos paskyros, FTP paskyros | paskyros, kurių niekas komandoje nesukūrė |
| Linux serveris | /etc/passwd, grupės sudo ar wheel, sudoers |
kitos paskyros su UID 0, naujos prisijungimo apvalkalai |
| SSH | visų naudotojų authorized_keys |
raktai be žinomo savininko |
| Duomenų bazė | duomenų bazės serverio naudotojų lentelė | naudotojai su globaliomis teisėmis ar host % |
| Išorinės paslaugos | domenas, DNS, Search Console, CDN | papildomi savininkai ar įgalioti asmenys |
SSH lygmuo pakankamai savarankiškas atskiram straipsniui: Nežinomų SSH raktų radimas ir šalinimas.
Svetimų administratoriaus paskyrų radimas CMS, taip pat paslėptų
Backend naudotojų sąrašą generuoja pati programa. Jei kartu veikia įterptas kodas, jis gali išfiltruoti atskirus įrašus. Todėl patikimesni įrankiai, žiūrintys tiesiai į išsaugotus duomenis. WordPress atveju WP-CLI išvardija visus administratorius su sukūrimo data:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Dar giliau eina tik skaitanti užklausa duomenų bazėje. Ji parodo kiekvieną paskyrą, kuriai priskirta administratoriaus rolė, nepriklausomai nuo to, ką rodo sąsaja. Lentelės priešdėlį wp_ pritaikykite savo diegimui:
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;
Palyginkite backend, WP-CLI ir duomenų bazės rezultatus. Jei paskyra atsiranda tik duomenų bazėje, tai stiprus įspėjamasis ženklas, nes tuomet papildomai veikia kodas, kuris ją slepia. Kitoms sistemoms, tokioms kaip Shopware, TYPO3 ar Joomla, galioja tas pats principas: naudotojų lentelę užklausti tiesiogiai ir palyginti su rodiniu backend. Kokios tai lentelės, nurodyta gamintojo dokumentacijoje.
Sistemos ir duomenų bazės naudotojų patikra
Pačiame serveryje svarbiausios paskyros su root teisėmis ir paskyros, galinčios prisijungti. Toliau pateiktos komandos tik skaito:
# Paskyros su UID 0 (paprastai tik root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Paskyros su tikru prisijungimo apvalkalu
grep -vE '(nologin|false)$' /etc/passwd
# Administratorių grupių nariai
getent group sudo wheel
# Papildomos sudo taisyklės
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Paskutiniai prisijungimai su pilna data
last -F | head -30
Duomenų bazės serveryje patikrinkite, kokie naudotojai egzistuoja ir kokias teises turi:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Programai paprastai reikia naudotojo su teisėmis į tiksliai vieną duomenų bazę. Papildomą naudotoją su globaliomis teisėmis, kuris gali jungtis iš bet kurių hostų (%), reikia išsiaiškinti.
Nepamirškite paskyrų už serverio ribų. Kas turi prieigą prie domeno sutarties ar DNS valdymo, gali nukreipti lankytojus ar leisti išduoti sertifikatus svetimiems serveriams. Papildomas savininkas Google Search Console gali pateikti svetainių žemėlapius ir keisti nustatymus. Todėl registratoriuje, DNS teikėjoje, CDN ir Search Console peržiūrėkite įgaliotų asmenų sąrašą ir palyginkite jį su tuo, ką žino jūsų komanda.
Kaip teisingai elgtis su radiniu
Pirmasis impulsas yra svetimą paskyrą iškart ištrinti. Tačiau tuomet dingsta ir svarbus pėdsakas: sukūrimo data dažnai nustato, kada užpuolikas buvo sistemoje. Geriau tokia tvarka:
- Dokumentuoti: užfiksuoti naudotojo vardą, ID, el. paštą, sukūrimo datą, rolę ir paskutinę veiklą su laiku, geriausia kaip ekrano nuotrauką ir eksportą.
- Blokuoti, o ne trinti: atimti rolę, slaptažodį pakeisti atsitiktine reikšme arba paskyrą išjungti.
- Apriboti laikotarpį: patikrinti žurnalus aplink sukūrimo datą. Kokios užklausos buvo prieš tai, kokie failai keitėsi?
- Patikrinti kitus lygmenis: kas sukuria paskyrą, retai palieka tik ją. Taip pat peržiūrėti failus, cron užduotis, SSH raktus ir duomenų bazę.
- Išvalyti ir atnaujinti prieigas: tik po išvalymo ir PHP atnaujinimo atnaujinti visus slaptažodžius, raktus ir sesijas.
Atsargumo pastaba: ne kiekviena nežinoma paskyra yra piktavalė. Agentūros, ankstesni paslaugų teikėjai ar priežiūros įskiepiai kartais patys sukuria paskyras. Tai išsiaiškinkite, prieš keldami aliarmą, bet išsiaiškinkite laiku.
Sugrįžimo prevencija
Po išvalymo administratoriaus paskyros turėtų būti išimtis, o ne taisyklė. Pasiteisino asmeninės paskyros vietoj bendrų prieigų, kuo mažiau administratorių ir dviejų veiksnių autentifikacija administratoriaus prieigoms. Be to, nustatykite, kas gali kurti naujas administratoriaus paskyras ir kur tai dokumentuojama.
Reguliari užklausa, panaši į aukščiau pateiktas, pavyzdžiui, kas savaitę ir su palyginimu su praėjusia savaite, naujas paskyras padaro greitai matomas. WordPress atveju papildomai padeda vadovas Užpakalinių durų WordPress radimas.
Kaip PHP SOS padeda konkrečiai?
- Tikriname visus paskyrų lygmenis nuo CMS per serverį iki duomenų bazės ir lyginame backend rodinį su išsaugotais duomenimis.
- Radinius išsaugome su laiko žymomis, prieš paskyras blokuojant ar šalinant.
- Pagal incidentų valdymą (Incident Response) išsiaiškiname, kaip paskyra atsirado ir ar yra kitų užpakalinių durų.
- Atnaujiname prieigas teisinga eile ir įrengiame nuolatinę naujų administratoriaus paskyrų kontrolę.
Dažni klausimai
Ar nežinomą administratoriaus paskyrą turėčiau iškart ištrinti?
Geriau ne iškart. Pirmiausia dokumentuokite naudotojo vardą, sukūrimo datą, el. pašto adresą ir paskutinę veiklą bei užblokuokite paskyrą. Ištrinkite tik išsaugoję pėdsakus, nes sukūrimo data dažnai yra svarbi užuomina apie įsilaužimo laiką.
Ar administratoriaus paskyra gali būti nematoma užkulisiuose (backend)?
Taip. Įterptas kodas gali paslėpti atskiras paskyras sąsajos naudotojų sąraše. Tiesioginė duomenų bazės užklausa ar komandinės eilutės įrankis, priešingai, parodo visas išsaugotas paskyras. Todėl nežiūrėkite tik backend.
Kuriuos lygmenis, be CMS, reikia patikrinti?
Hostingo skydelį, FTP ir SFTP prieigas, serverio sistemos naudotojus, įskaitant sudo teises, SSH raktus, duomenų bazės naudotojus bei paskyras prie domeno, DNS ir Search Console. Užpuolikui sugrįžti pakanka vienų iš šių durų.
Ar radus pakanka pakeisti visus slaptažodžius?
Ne. Svetima paskyra rodo, kad kažkas turėjo prieigą. Tuomet reikia išsiaiškinti ir įėjimo vartus, kitas užpakalines duris bei galimus duomenų nutekėjimus. Slaptažodžius keiskite tik po išvalymo ir iš švaraus įrenginio.