Lyhyesti: Jos verkkosivusto ohjaa kävijät vieraille sivuille, syy on yhdessä kuudesta kerroksesta: DNS, CDN tai välityspalvelin, verkkopalvelimen asetukset, PHP-koodi, tietokanta tai mukaan liitetyt skriptit. Koska monet uudelleenohjaukset aktivoituvat vain ehdoilla, testatkaa kohdennetusti eri tunnisteilla ja lähdesivuilla. Suojatkaa ensin kävijät, varmistakaa jäljet ja sulkekaa poiston jälkeen sisäänpääsy.
Kun asiakkaat päätyvät arvontasivuille
Ilmoitus tulee yleensä ulkopuolelta. Asiakas kirjoittaa päätyneensä sivuillenne mennessään arvontasivustolle tai kyseenalaiseen verkkokauppaan. Tarkistatte asian omalla koneellanne, ja kaikki näyttää normaalilta. Se ei ole ristiriita vaan tarkoituksellista: hakkeroinnin jälkeiset uudelleenohjaukset on rakennettu niin, että ylläpitäjä huomaa ne mahdollisimman myöhään.
Yrityksellenne tämä on hankalaa. Kävijät menettävät luottamuksen, hakukoneet ja selaimet voivat näyttää varoituksia, ja kohdesivuilla odottaa toisinaan petos tai haittaohjelma. Uudelleenohjaus on lisäksi lähes koskaan ainoa asia, jonka hyökkääjä jättää jälkeensä.
PHP2Shellin, eli aukkojen CVE-2026-109618 ja CVE-2026-109619, jotka mahdollistavat koodin suorittamisen ilman kirjautumista, jälkeen uudelleenohjaukset kuuluvat näkyviin seurauksiin, jotka ylläpitäjien pitäisi ottaa vakavasti. Ne eivät ole PHP2Shellille ominainen merkki, sillä vahvistettuja Indicators of Compromise -tunnisteita ei ole. Ne kuitenkin osoittavat, että joku on voinut muuttaa verkkosivustonne sisältöä.
Uudelleenohjaukset eivät usein tule yksin. Joka ohjaa kävijöitä, luo usein myös roskasivuja hakukoneille siepatakseen vielä enemmän liikennettä. Jos Google näyttää jo ilmoituksen hakkeroidusta verkkosivustosta, opas Googlen varoituksen poistaminen kuvaa tarkistusprosessin. Vieraita sivuja hakuindeksissä käsittelee kirjoitus SEO-roska ja vieraat sivut Googlen hakemistossa.
Miksi verkkosivusto ohjaa vain välillä
Ehdolliset uudelleenohjaukset arvioivat pyynnön ominaisuuksia. Yleisiä ovat nämä:
- Lähde: Vain hakutuloksen kautta tulevat ohjataan muualle. Suorat käynnit näyttävät normaalin sivun.
- Laite: Vain mobiililaitteet tai tietyt selaimet ovat kohteena.
- Toisto: Uudelleenohjaus toimii kerran kävijää kohden, asettaa sen jälkeen evästeen ja vaikenee.
- Kirjautuminen: CMS:ään kirjautunut ei näe koskaan mitään.
- Aika tai sattuma: Uudelleenohjaus toimii vain osassa käyntejä.
Älkää siksi testatko vain työpisteeltä. Lukevalla kyselyllä näette, miten palvelin vastaa erilaisiin kutsuihin:
# Tavallinen kutsu: tilakoodi ja mahdollisen uudelleenohjauksen kohde
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Kutsu kuin mobiililaitteelta, joka tulee haun kautta
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/
Jos vieras kohde ilmestyy vain toisessa kyselyssä, uudelleenohjaus on palvelimella. Jos molemmat ovat huomaamattomia, se voi tapahtua selaimessa JavaScriptillä. Silloin auttaa katse tarjoillun sivun lähdekoodiin tai selaimen kehittäjätyökalujen verkkonäkymään, mieluiten yksityisessä ikkunassa.
Verkkosivusto ohjaa muualle: kuuden kerroksen tarkistus
Edetkää ulkoa sisäänpäin. Näin vältätte tuntikausien koodinetsinnän, kun syy onkin DNS-merkinnässä:
| Kerros | Tyypillinen syy | Tarkistus |
|---|---|---|
| Verkkotunnus ja DNS | muutettu A-merkintä tai nimipalvelin | verratkaa DNS-merkintöjä tunnettuun tavoitetilaan, tarkistakaa rekisterinpitäjän tunnukset |
| CDN tai välityspalvelin | vieras uudelleenohjaus- tai sivusääntö | käykää palveluntarjoajan asiakasalueen säännöt läpi |
| Verkkopalvelin | säännöt .htaccess-tiedostossa tai palvelinasetuksissa |
etsikää Rewrite- ja Redirect-sääntöjä ehtoineen |
| PHP-koodi | lisäkoodi aloitustiedostoissa, malleissa tai laajennuksissa | verratkaa ydintiedostoja alkuperäiseen |
| Tietokanta | muutetut osoiteasetukset, skriptit sisällöissä tai asetuksissa | etsikää kohdennetusti vieraita osoitteita ja skriptejä |
| Ulkoiset skriptit | vaarantunut kolmannen osapuolen liitos | luetteloikaa mukaan liitetyt skriptilähteet ja arvioikaa ne |
Ulommat kerrokset jätetään mielellään väliin, koska ne eivät ole omalla palvelimella. Juuri siksi ne ovat vaarallisia: joka on ottanut haltuunsa rekisterinpitäjän tai CDN-palveluntarjoajan tilin, ei tarvitse pääsyä palvelimelle. Tarkistakaa siellä sääntöjen lisäksi, kenellä on pääsy ja onko kaksivaiheinen tunnistautuminen käytössä.
Verkkopalvelinkerrokselle sopivat lukevat haut, jotka etsivät lähteeseen tai laitteeseen reagoivia sääntöjä:
# Ehdolliset uudelleenohjaussäännöt kaikissa .htaccess-tiedostoissa
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Uudelleenohjaukset palvelinasetuksissa (Apache ja Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
PHP-kerroksen osalta menettelyn kuvaa CMS-ydintiedostojen vertailu alkuperäiseen. Tietokantaa varten kannattaa lukea kirjoitus Tietokannan tarkistus sisäänajetun koodin varalta.
Kun syy on palvelimen ulkopuolella
Kaikki uudelleenohjaus ei tarkoita vaarantunutta palvelinta. Kolmansien osapuolten mukaan liitetyt skriptit, esimerkiksi chattiin, tilastoihin tai mainontaan, suoritetaan suoraan kävijöiden selaimessa. Jos tällainen palveluntarjoaja vaarantuu tai verkkotunnus, josta sivunne yhä lataa skriptiä, vanhenee, uudelleenohjaus voi syntyä ilman, että palvelimellanne on muutettu yhtään tiedostoa.
Content Security Policy rajaa, mistä lähteistä selain saa ladata skriptejä, ja tekee tällaiset tapaukset näkyviksi. Vinkkejä löytyy kohdasta Verkkosivustojen tietoturvaotsakkeet. Hyvin harvoin syy on kävijässä itsessään: hänen koneensa mainos- tai haittaohjelma ohjaa silloin muuallekin muilla verkkosivustoilla.
Oikea järjestys löydön jälkeen
- Suojatkaa kävijät: Asettakaa verkkosivusto huoltotilaan tai sulkekaa vaikutuksen alaiset alueet.
- Varmistakaa jäljet: Kopioikaa epäilyttävät säännöt, tiedostot ja tietokannan sisällöt aikaleimalla ennen niiden poistamista.
- Poistakaa: Poistakaa uudelleenohjaus ja korvatkaa ydintiedostot puhtaasta lähteestä.
- Sulkekaa sisäänpääsy: Päivittäkää PHP korjattuun versioon, päivittäkää CMS ja laajennukset, käynnistäkää kaikki workerit uudelleen ja uusikaa tunnukset.
- Testatkaa uudelleen: Tarkistakaa uudelleen kaikilla toisen osion muunnelmilla ja seuratkaa Search Consolea.
Poistettu uudelleenohjaussääntö ei todista, että verkkosivusto on puhdas. Jos sääntö palaa päivien kuluttua, jossain on yhä takaportti, joka kirjoittaa sen uudelleen.
Miten PHP SOS auttaa konkreettisesti?
- Toistamme uudelleenohjauksen eri tunnisteilla ja lähdesivuilla ja rajaamme kerroksen.
- Varmistamme jäljet ja poistamme uudelleenohjaukset, haittakoodin ja takaportit tiedostoista, asetuksista ja tietokannasta.
- Akuutissa tartunnassa hakkeroitujen verkkosivustojen hätäapumme hoitaa eristämisen, kunnes tapaus on päätetty ja dokumentoitu.
- Tarkistamme mukaan liitetyt kolmansien osapuolten skriptit ja suosittelemme sopivaa Content Security Policya.
Usein kysytyt kysymykset
Miksi en itse näe uudelleenohjausta?
Monet uudelleenohjaukset aktivoituvat vain tietyissä olosuhteissa: Google-haun kautta tulleille kävijöille, vain mobiililaitteilla, vain ensimmäisellä käyntikerralla tai ei kirjautuneille ylläpitäjille. Testatkaa siksi eri laitteilla, ilman kirjautumista ja hakutuloslinkin kautta.
Voiko uudelleenohjaus syntyä ilman hakkerointia?
Kyllä. Vanhentunut liitännäinen, vaarantunut ulkoinen skripti, virheelliset DNS-merkinnät tai kävijän koneen haittaohjelma voivat aiheuttaa samankaltaisia vaikutuksia. Jos syy on omalla koneellanne, uudelleenohjaus esiintyy yleensä myös muilla verkkosivustoilla.
Mihin hyökkääjät piilottavat uudelleenohjaukset useimmin?
Tyypillisiä paikkoja ovat .htaccess-tiedoston tai palvelinasetusten säännöt, sovelluksen aloitustiedostoihin lisätty koodi, tietokannassa muutetut osoiteasetukset sekä sisältöihin tai malleihin ujutetut JavaScript-pätkät.
Mitä minun pitäisi tehdä heti, jos verkkosivuni ohjaa muualle?
Suojatkaa kävijät esimerkiksi huoltotilalla ja varmistakaa jäljet ennen kuin poistatte mitään. Sen jälkeen etsikää syy kerros kerrokselta ja sulkekaa sisäänpääsy. Poistettu sääntö ilman suljettua aukkoa palaa yleensä takaisin.