Na kratko: Skriti cronjob je ena najpogostejših stranskih vrat na strežnikih Linux: škodljivo kodo redno naloži ali znova zažene procese, tudi po posodobitvi PHP. Preverite vsa mesta načrtovanih opravil, ne samo crontab -l: crontabe vseh uporabnikov, /etc/crontab, /etc/cron.d, imenike cron, časovnike systemd in naloge at. Najdbe zavarujte, preden jih odstranite.
Zakaj so cronjobi kot stranska vrata tako priljubljeni
Po uspešnem vdoru ima napadalec težavo: njegov dostop je krhek. Posodobitev zapre ranljivost, skrbnik izbriše webshell, ponovni zagon konča proces. Cronjob to težavo reši. Ukaze zažene ob določenih časih, ne da bi kdo posegel, in tako obnovi izgubljene dostope.
Za PHP2Shell ni potrjenih indikatorjev ogroženosti (Indicators of Compromise). Novi cronjobi pa po poročilih, ki so nam na voljo, sodijo med splošne opozorilne znake po vdorih prek spletnih aplikacij. Kdor je že iskal webshelle, naj načrtovana opravila preveri kar zraven. Preostale korake naknadne obravnave navaja Kontrolni seznam po vdoru.
Kje se lahko skrijejo načrtovana opravila
Linux pozna več mehanizmov za načrtovana opravila. Mnoga preverjanja odpovejo, ker se pogleda samo enega.
| Mesto | Debian/Ubuntu | Družina RHEL | Kdo sme pisati |
|---|---|---|---|
| Crontab za vsakega uporabnika | /var/spool/cron/crontabs/ |
/var/spool/cron/ |
zadevni uporabnik |
| Sistemski crontab | /etc/crontab |
/etc/crontab |
root |
| Posamezne datoteke | /etc/cron.d/ |
/etc/cron.d/ |
root |
| Periodični imeniki | /etc/cron.hourly do /etc/cron.monthly |
enako | root |
| Časovniki systemd | /etc/systemd/system/, enote uporabnikov |
enako | root, deloma uporabniki |
| Naloge at | čakalna vrsta atd |
enako | uporabniki, če je dovoljeno |
Pomembno za spletne strežnike: uporabnik spletnega strežnika lahko praviloma ustvari lasten crontab brez pravic root. Napadalec s pravicami www-data za to torej ne potrebuje dodatne ranljivosti. Vnosi v /etc/cron.d ali enote systemd pa kažejo, da je dobil pravice root.
Nadzorne plošče za gostovanje, kot sta Plesk ali cPanel, ponujajo lasten vmesnik za načrtovana opravila. Za njim so praviloma prav tako crontabi zadevnih sistemskih uporabnikov. Kdor pogleda samo v vmesnik, zato ne prepozna vsakega vnosa, ustvarjenega neposredno na strežniku. Ob dvomu preverite oboje.
Kako v celoti preverite vsa mesta
Naslednji ukazi samo berejo. Izvedite jih kot root in izpise zavarujte z datumom.
# Izpis crontabov vseh uporabnikov
for u in $(cut -d: -f1 /etc/passwd); do
out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done
# Sistemski vnosi in časi sprememb
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
# Časovniki systemd in naloge at
systemctl list-timers --all
atq 2>/dev/null
# Iskanje tipičnih vzorcev v vseh datotekah cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
Dva trika zaslužita posebno pozornost. Nekateri vnosi ukaze skrijejo za številnimi presledki, tako da v urejevalniku zdrsnejo desno iz slike. Drugi uporabljajo krmilne znake, ki pri prikazu prepišejo besedilo. S cat -A postanejo taki znaki vidni:
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
Drugi vidik so dnevniki storitve cron. Na mnogih sistemih cron zabeleži vsako izvedbo z uporabnikom in ukazom. Tako vidite tudi vnose, ki jih je napadalec medtem že odstranil, in prepoznate, od kdaj sumljiv ukaz teče:
# Izvedeni ukazi cron uporabnika spletnega strežnika (Debian/Ubuntu oz. dnevnik systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100
Po čem prepoznate stranska vrata cronjoba
- Nalaganje z interneta: Prenos, katerega rezultat se neposredno preda lupini.
- Kodirane vsebine: Dolgi nizi, ki se dekodirajo šele med izvajanjem.
- Nenavadne poti: Programi v
/tmp,/dev/shm, skritih imenikih ali imenikih za nalaganje. - Napačen uporabnik: Opravila pod uporabnikom spletnega strežnika, čeprav jih aplikacija ne potrebuje.
- Opazen takt: Izvajanje vsako minuto ali ob vsakem zagonu prek
@reboot. - Neustrezni časovni žigi: Datoteka spremenjena v obdobju, ko na strežniku nihče ni delal, na primer po 17. oktobru.
Ne pozabite: tudi aplikacije imajo lastne urnike. WordPress na primer načrtovana opravila upravlja v podatkovni bazi. Kako tam preverite, opisuje Iskanje stranskih vrat v WordPressu.
Cronjob redko pride sam. Kdor je ustvaril načrtovano opravilo, je pogosto shranil tudi ključe SSH ali skril datoteke. Dodatno preverite ključe, kot opisuje prispevek Iskanje neznanih ključev SSH.
Najdbo zavarujte, razumite, nato odstranite
Zlonamerni cronjob je dragocen dokazni predmet. Kaže naslov za nalaganje, čas ustvaritve in pogosto uporabnika, prek katerega je napadalec prišel. Datoteko zavarujte s kontrolno vsoto in časovnimi žigi, preden jo odstranite. Časovni žig pozneje pomaga rekonstruirati potek; kako, kaže Izdelava časovnice incidenta. Tudi za morebitno prijavo nadzornemu organu za varstvo podatkov ali zavarovalnici je najdba pomemben dokaz, od kdaj je imel napadalec dostop.
Samo odstranitev ne zadošča. Če še teče proces, ki vnos znova zapiše, je po naslednji minuti nazaj. In dokler je prvotna ranljivost odprta, lahko napadalec kadarkoli začne znova. Zato je vrstni red: zavarovati, zapreti vzrok, odstraniti vse sestavne dele, zamenjati dostope, nadzorovati.
Preventivno zavarovanje cronjobov
Da stranska vrata cronjoba sploh ne morejo nastati ali hitro padejo v oči, pomagajo trije ukrepi. Prvič, mogoče je določiti, kateri uporabniki sploh smejo ustvariti crontab. Če obstaja datoteka /etc/cron.allow, smejo crontab uporabljati samo tam navedeni uporabniki. Če vaša aplikacija ne potrebuje cronjoba pod uporabnikom spletnega strežnika, ta uporabnik ne sodi na seznam. Prej preverite, katera opravila aplikacija dejansko potrebuje, in jih zavestno ustvarite pod lastnim uporabnikom.
Drugič, splača se nadzor datotek. Orodje za preverjanje celovitosti javi, takoj ko se datoteka v imenikih cron ali pod /var/spool/cron spremeni. Tretjič, načrtovana opravila sodijo v dokumentacijo strežnika: kdor ve, kateri vnosi naj obstajajo, tujega prepozna takoj.
Kako PHP SOS pomaga konkretno?
- Popolno preverjanje: Preiščemo vse mehanizme za načrtovana opravila, tudi časovnike systemd, naloge at in urnike aplikacij.
- Razvrstitev najdb: Sumljive vnose ovrednotimo, ne da bi jih izvedli, in izpeljemo nadaljnje sledi.
- Čisto čiščenje: Z odstranjevanjem škodljive programske opreme odstranimo vse sestavne dele in zapremo vzrok.
- Prepoznavanje ponovitve: Vzpostavimo nadzor, ki javi nova ali spremenjena načrtovana opravila.
Pogosta vprašanja
Zakaj napadalci uporabljajo cronjobe?
Cronjob redno in brez nadaljnjega posredovanja zažene ukaze. Napadalci z njim naknadno naložijo škodljivo kodo, znova ustvarijo izbrisane datoteke ali znova zaženejo procese. Tako njihov dostop preživi posodobitev in pogosto tudi površno čiščenje.
Ali za preverjanje zadošča crontab -l?
Ne. crontab -l pokaže samo crontab trenutnega uporabnika. Načrtovana opravila so tudi v crontabih drugih uporabnikov, v /etc/crontab, /etc/cron.d, imenikih cron.daily, v časovnikih systemd in nalogah at.
Po čem prepoznam zlonamerni cronjob?
Tipični so prenosi z interneta z neposrednim izvajanjem, ukazi s kodiranimi nizi, programi v začasnih imenikih, opravila pod uporabnikom spletnega strežnika in vnosi, ki tečejo vsako minuto. Posamezna značilnost je namig, več skupaj resen sum.
Ali smem sumljive cronjobe preprosto izbrisati?
Najprej zavarujte, nato odstranite. Vnos pogosto razkrije izvor, naslov za nalaganje in nadaljnje sestavne dele. Brez razjasnitve, kako je nastal, ga napadalec pogosto znova ustvari.