Lühidalt: Kui veebisait suunab võõrastele lehtedele, peitub põhjus ühes kuuest kihist: DNS, CDN või proxy, veebiserveri konfiguratsioon, PHP kood, andmebaas või ühendatud skriptid. Kuna paljud ümbersuunamised rakenduvad ainult tingimustel, testige sihipäraselt erinevate tunnuste ja viitavate lehtedega. Kaitske esmalt külastajaid, kindlustage jäljed ja sulgege pärast eemaldamist sissepääs.
Kui kliendid jõuavad loosimismängude lehtedele
Teade tuleb tavaliselt väljastpoolt. Klient kirjutab, et jõudis teie lehte avades loosimismängu või kahtlasse poodi. Kontrollite seda oma arvutis ja kõik näib normaalne. See pole vastuolu, vaid kavatsus: pärast häkkimist tehtud ümbersuunamised on ehitatud nii, et haldajad märkaksid neid võimalikult hilja.
Teie ettevõttele on see delikaatne. Külastajad kaotavad usalduse, otsingumootorid ja brauserid võivad kuvada hoiatusi ning sihtlehtedel varitseb vahel pettus või pahavara. Lisaks pole ümbersuunamine peaaegu kunagi ainus, mida ründaja maha jätab.
Pärast PHP2Shelli, PHP turvauksi CVE-2026-109618 ja CVE-2026-109619 koos autentimiseta koodi käivitamisega, kuuluvad ümbersuunamised nähtavate tagajärgede hulka, mida haldajad peaksid tõsiselt võtma. Need ei ole PHP2Shelli-spetsiifiline tunnus, sest kinnitatud kompromiteerimistunnuseid (Indicators of Compromise) ei ole. Küll aga näitavad need, et keegi sai teie veebisaidi sisu muuta.
Sageli ei tule ümbersuunamised üksi. Kes külastajaid ümber suunab, loob tihti lisaks otsingumootoritele rämpslehti, et püüda veel rohkem liiklust. Kui Google juba kuvab märget häkitud veebisaidi kohta, kirjeldab juhend Google'i hoiatuse eemaldamine kontrollimise teed. Võõraid lehti otsinguindeksis käsitleb artikkel SEO-rämps ja võõrad lehed Google'i indeksis.
Miks veebisait suunab ümber ainult mõnikord
Tingimuslikud ümbersuunamised hindavad päringu tunnuseid. Sagedased on need:
- Päritolu: ümber suunatakse ainult otsingutulemuse kaudu tulijad. Otsesed avamised näitavad tavalist lehte.
- Seade: mõjutatud on ainult mobiilseadmed või teatud brauserid.
- Kordus: ümbersuunamine rakendub kord külastaja kohta, seejärel seab küpsise ja vaikib.
- Sisselogimine: CMS-i sisse logitud kasutaja ei näe iial midagi.
- Aeg või juhus: ümbersuunamine rakendub ainult osale päringutest.
Ärge seetõttu testige ainult oma töökohal. Lugeva päringuga näete, kuidas server erinevatele päringutele vastab:
# Tavaline päring: olekukood ja võimaliku ümbersuunamise siht
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Päring nagu otsingu kaudu tulevalt mobiilseadmelt
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Kui võõras siht ilmub ainult teise päringu puhul, asub ümbersuunamine serveris. Kui mõlemad päringud jäävad ebaharilikuta, võib see toimuda brauseris JavaScripti abil. Siis aitab pilk väljastatud lehe lähtekoodi või brauseri arendaja tööriistade võrgu vaatesse, parimal juhul privaatses aknas.
Veebisait suunab ümber: kuue kihi kontroll
Liikuge väljastpoolt sissepoole. Nii väldite tundide viisi koodist otsimist, kui põhjus on hoopis DNS-kirjes:
| Kiht | Tüüpiline põhjus | Kontroll |
|---|---|---|
| Domeen ja DNS | muudetud A-kiri või nimeserver | võrrelge DNS-kirjeid teadaoleva õige seisuga, kontrollige registripidaja ligipääsu |
| CDN või proxy | võõras ümbersuunamis- või lehereegel | vaadake läbi reeglid teenusepakkuja kliendialas |
| Veebiserver | reeglid failis .htaccess või serverikonfiguratsioonis |
otsige tingimustega Rewrite- ja Redirect-reegleid |
| PHP kood | lisakood sisenemisfailides, mallides või laiendustes | võrrelge tuumafaile originaaliga |
| Andmebaas | muudetud aadressisätted, skriptid sisus või suvandites | otsige sihipäraselt võõraid aadresse ja skripte |
| Välised skriptid | kompromiteeritud kolmanda osapoole lisand | tehke ühendatud skriptiallikatest loend ja hinnake neid |
Välised kihid jäetakse meelsasti vahele, sest need ei asu teie enda serveris. Just seetõttu on need ohtlikud: kes on registripidaja või CDN-i teenusepakkuja konto üle võtnud, ei vaja ligipääsu serverile. Kontrollige seal lisaks reeglitele ka seda, kellel on ligipääs ja kas kaheastmeline autentimine on aktiivne.
Veebiserveri kihi puhul sobivad lugevad otsingud reeglite järele, mis reageerivad päritolule või seadmele:
# Tingimustega ümbersuunamisreeglid kõigis .htaccess-failides
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Ümbersuunamised serverikonfiguratsioonis (Apache ja Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
PHP kihi kohta kirjeldab tegevust artikkel CMS-i tuumafailide võrdlemine originaaliga. Andmebaasi jaoks tasub lugeda artiklit Andmebaasi kontrollimine sissetoodud koodi suhtes.
Kui põhjus on väljaspool serverit
Mitte iga ümbersuunamine ei tähenda kompromiteeritud serverit. Kolmandate osapoolte ühendatud skriptid, näiteks vestluse, statistika või reklaami jaoks, käivitatakse otse külastajate brauseris. Kui selline teenusepakkuja kompromiteeritakse või aegub domeen, millelt teie leht veel skripti laeb, võib sealt tekkida ümbersuunamine, ilma et teie serveris oleks ühtegi faili muudetud.
Content Security Policy piirab, millistest allikatest brauser tohib skripte laadida, ja teeb sellised juhtumid nähtavaks. Vihjeid leiate artiklist Veebisaitide turvapäised. Väga harva on põhjus külastajas endas: reklaami- või pahavara tema arvutis suunab ümber ka teistel veebisaitidel.
Õige järjekord pärast leidu
- Kaitske külastajaid: viige veebisait hooldusrežiimi või blokeerige mõjutatud alad.
- Kindlustage jäljed: kopeerige kahtlased reeglid, failid ja andmebaasisisu ajatempliga, enne kui need eemaldate.
- Eemaldage: kõrvaldage ümbersuunamine ja asendage tuumafailid puhtast allikast.
- Sulgege sissepääs: viige PHP parandatud seisu, uuendage CMS ja laiendused, taaskäivitage kõik töölised, uuendage ligipääsud.
- Testige uuesti: kontrollige uuesti kõigi teise lõigu variantidega ja jälgige Search Console'i.
Eemaldatud ümbersuunamisreegel ei ole tõend puhta veebisaidi kohta. Kui reegel päevade pärast tagasi tuleb, on kuskil veel tagauks, mis selle uuesti kirjutab.
Kuidas PHP SOS konkreetselt aitab?
- Taastame ümbersuunamise erinevate tunnuste ja viitavate lehtedega ning piirame kihi kitsamaks.
- Kindlustame jäljed ning eemaldame ümbersuunamised, kahjuliku koodi ja tagauksed failidest, konfiguratsioonist ja andmebaasist.
- Ägeda nakatumise korral tegeleb leviku tõkestamisega meie hädaabi häkitud veebisaitide puhul, kuni intsident on lõpetatud ja dokumenteeritud.
- Kontrollime ühendatud kolmandate osapoolte skripte ja soovitame sobivat Content Security Policy'it.
Korduma kippuvad küsimused
Miks ma ümbersuunamist ise ei näe?
Paljud ümbersuunamised rakenduvad ainult teatud tingimustel: Google'i otsingust tulevatele külastajatele, ainult mobiilseadmetes, ainult esimesel külastusel või mitte sisse logitud administraatoritele. Testige seetõttu erinevate seadmetega, ilma sisselogimiseta ja otsingutulemuse lingi kaudu.
Kas ümbersuunamine võib tekkida ka ilma häkkimiseta?
Jah. Aegunud plugin, kompromiteeritud väline skript, valed DNS-kirjed või külastaja arvutis olev pahavara võivad anda sarnase efekti. Kui põhjus on teie enda arvutis, esineb ümbersuunamine tavaliselt ka teistel veebisaitidel.
Kus ründajad ümbersuunamisi kõige sagedamini peidavad?
Tüüpilised on reeglid failis .htaccess või serverikonfiguratsioonis, rakenduse sisenemisfailides olev lisakood, andmebaasis muudetud aadressisätted ning sisusse või mallidesse sokutatud JavaScripti lõigud.
Mida peaksin kohe tegema, kui minu veebisait suunab ümber?
Kaitsta külastajaid, näiteks hooldusrežiimiga, ja kindlustada jäljed enne, kui midagi kustutate. Seejärel otsida põhjust kiht kihi haaval ja sulgeda sissepääs. Eemaldatud reegel ilma suletud auguta tuleb tavaliselt tagasi.