Siteniz Ziyaretçileri Başka Siteye mi Yönlendiriyor? Redirect Hack Tespiti ve Temizliği

Önce: panik yapmayın, yedek alın

Yönlendirme kodunu bulmaya başlamadan önce sitenin şu anki halinin tam bir kopyasını alın: dosyalar ve veritabanı birlikte. Bu kopya "temiz yedek" değildir; saldırının izlerini taşıyan bir kanıt kopyasıdır. Yanlışlıkla gerekli bir dosyayı silerseniz geri dönebilmeniz ve daha sonra saldırının nasıl gerçekleştiğini inceleyebilmeniz için gereklidir. Genel temizlik akışı için WordPress hacklendi temizleme rehberimize, yedekleme ve geri yükleme ayrıntıları için WordPress yedekleme ve geri yükleme yazımıza bakabilirsiniz.

• Dosyaları (public_html veya sitenin kurulu olduğu klasör) ve veritabanını yedekleyin; yedeği sunucu dışına indirin.
• WordPress yönetici, hosting paneli, FTP ve veritabanı şifrelerini değiştirmeyi planlayın; bunu temizlikten hemen sonra mutlaka yapın.
• Yönlendirme sırasında açılan şüpheli sayfayı kendi tarayıcınızla tekrar tekrar ziyaret etmeyin. Google, kötü amaçlı yazılım içerebilecek sayfaları doğrudan tarayıcıyla görüntülemekten kaçınmanızı önerir.

Belirtiler: hangi koşulda yönlendirme oluyor?

Yönlendirmenin ne zaman tetiklendiğini bilmek, kodu nerede arayacağınızı daraltır. Aşağıdaki tablo tipik belirtileri ve ilk bakılacak yeri özetler. Tablodaki nedenler olasılıktır; her sitede aynısı olmayabilir.

Yönlendirmeyi güvenli şekilde doğrulamak: curl ile test

Google, Güvenlik sorunları raporu yardım sayfasında iki güvenli yöntem önerir: Search Console'daki URL Denetleme aracı ile sayfayı Google'ın gördüğü şekilde incelemek ve curl ya da Wget gibi komut satırı araçlarıyla, farklı referrer ve user agent değerleri vererek sayfayı istemek. Saldırganlar çoğu zaman yalnızca belirli tarayıcıları veya Google'dan gelen ziyaretçileri hedeflediği için bu araçlarla o ziyaretçiyi taklit edebilirsiniz.

Aşağıdaki komutlar sayfanın yalnızca başlıklarını getirir ve yönlendirmeyi takip etmez; böylece hedef siteye gitmeden Location başlığını görürsünüz. alanadiniz.com yerine kendi adresinizi yazın.

# 1) Doğrudan istek (adres çubuğuna yazmak gibi)
curl -sI https://alanadiniz.com/

# 2) Google sonucundan tıklanmış gibi (referrer)
curl -sI -e "https://www.google.com/" https://alanadiniz.com/

# 3) Telefondan geliyormuş gibi (mobil user agent)
curl -sI -A "Mozilla/5.0 (Linux; Android 14; Mobile) AppleWebKit/537.36 Chrome/130.0 Mobile Safari/537.36" https://alanadiniz.com/

# 4) Mobil + Google referrer birlikte
curl -sI -e "https://www.google.com/" -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) Mobile/15E148 Safari/604.1" https://alanadiniz.com/

Normal bir sitede bu dört istek genellikle aynı yanıtı verir (örneğin hepsi 200 ya da hepsi aynı HTTPS adresine 301). Yalnızca 2., 3. veya 4. istekte yabancı bir alan adına giden Location başlığı görüyorsanız, yönlendirme sunucu tarafında yapılıyordur ve büyük ihtimalle .htaccess veya PHP kodundadır.

Başlıklarda bir şey yoksa yönlendirme tarayıcıda, JavaScript ile yapılıyor olabilir. Bu durumda sayfanın HTML'ini indirip içinde şüpheli ifadeleri arayın:

curl -s -e "https://www.google.com/" -A "Mozilla/5.0 (Linux; Android 14; Mobile)" https://alanadiniz.com/ -o sayfa.html
grep -n -i -E "window\.location|document\.location|location\.href|location\.replace|document\.referrer|eval\(|unescape\(|atob\(|fromCharCode" sayfa.html
grep -n -i -o -E "<script[^>]+src=[\"']?https?://[^\"' >]+" sayfa.html

İkinci komut, sayfaya dışarıdan yüklenen tüm script adreslerini listeler. Tanımadığınız bir alan adından yüklenen script, enjekte edilmiş kodun en yaygın işaretlerinden biridir. Google'ın yardım sayfası da yanıtlarda "eval", "base64_decode" ve "unescape" gibi ifadeleri aramayı önerir. Buradaki eşleşmelerin hepsi kötü değildir; meşru analitik ve reklam kodları da bu fonksiyonları kullanabilir. Önemli olan, sizin eklemediğiniz bir kodu bulmaktır.

1. .htaccess dosyalarını kontrol edin

Google'ın tarifine göre "başlık yönlendirmeleri" (header redirects) sunucu yapılandırma dosyaları değiştirilerek yapılır; Apache sunucularda bu dosya .htaccess'tir. Paylaşımlı hostingde siz yalnızca .htaccess dosyalarına erişirsiniz, ama saldırgan da genellikle onları değiştirir. Dikkat: .htaccess yalnızca ana klasörde değil, alt klasörlerde de bulunabilir ve her biri kendi klasörü için geçerlidir.

# Tüm .htaccess dosyalarını ve son değişiklik tarihlerini listele
find ~/public_html -name ".htaccess" -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

# Referrer veya user agent koşulu ve dış adrese yönlendirme içeren satırlar
grep -rn -i -E "HTTP_REFERER|HTTP_USER_AGENT|RewriteRule .*https?://|Redirect(Match)? .*https?://" ~/public_html --include=".htaccess"

Standart bir WordPress kurulumunda ana .htaccess dosyası # BEGIN WordPress ve # END WordPress satırları arasında birkaç satırlık kalıcı bağlantı kuralı içerir. Bu bloğun nasıl görünmesi gerektiğini WordPress .htaccess permalink kuralları yazımızda bulabilirsiniz. Bunun dışında, özellikle google, bing, android, iphone, mobile gibi kelimeleri içeren RewriteCond satırları ve ardından gelen, sizin tanımadığınız bir alan adına yönlendiren RewriteRule satırları şüphelidir.

Panelinizde Dosya Yöneticisi (File Manager) kullanıyorsanız, .htaccess gibi noktayla başlayan dosyaları görmek için gizli dosyaları gösterme seçeneğini açmanız gerekebilir.

2. WordPress adres ayarlarını kontrol edin (siteurl ve home)

Her ziyaretçinin, her cihazda başka bir siteye gittiği durumlarda ilk bakılacak yer WordPress'in adres ayarlarıdır. WordPress, sitenin adresini veritabanındaki wp_options tablosunda siteurl ve home satırlarında tutar. Bu değerler değiştirilirse site kendi adresi yerine yabancı bir adrese yönlenir ve çoğu zaman yönetici paneline de giremezsiniz.

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Tablo öneki wp_ değilse (örneğin abc_options) sorguyu kendi önekinize göre değiştirin; önekin ne olduğunu wp-config.php içindeki $table_prefix satırında görürsünüz. Ayrıntı için WordPress tablo öneki yazımıza bakabilirsiniz.

WordPress dokümantasyonu, bu değerlerin wp-config.php içinde WP_HOME ve WP_SITEURL sabitleriyle de tanımlanabileceğini ve bu durumda veritabanındaki değerin geçersiz kalacağını belirtir. Bu yüzden veritabanı doğru görünse bile wp-config.php dosyasında bu iki sabite bakın:

grep -n -E "WP_HOME|WP_SITEURL" ~/public_html/wp-config.php

Bu sabitleri siz eklemediyseniz ve yabancı bir adres içeriyorsa kaldırın ya da kendi adresinizle düzeltin. Adres uyumsuzluğu yönlendirme döngüsüne de yol açabilir; o durumda ERR_TOO_MANY_REDIRECTS çözümü yazımız işinize yarar.

3. Veritabanında enjekte edilmiş script arayın

Sayfa açıldıktan sonra başka siteye geçiş oluyorsa, kod büyük ihtimalle yazı içeriklerine, widget'lara veya eklenti ayarlarına yerleştirilmiştir. Bunlar dosyada değil, veritabanında durur; bu yüzden dosya taraması bunları bulamaz. phpMyAdmin'de aşağıdaki sorgularla arama yapabilirsiniz:

-- Yazı ve sayfa içeriklerinde script etiketi
SELECT ID, post_title, post_type, post_modified
FROM wp_posts
WHERE post_content LIKE '%<script%'
ORDER BY post_modified DESC;

-- Ayarlarda script veya şüpheli fonksiyon
SELECT option_id, option_name, LEFT(option_value, 200)
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%atob(%';

Sunucuda WP-CLI kullanabiliyorsanız aynı aramayı tüm tablolarda tek komutla yapabilirsiniz:

wp db search "<script" --all-tables
wp db search "document.referrer" --all-tables

Sonuçlarda kendi eklediğiniz analitik veya sohbet kodlarını göreceksiniz; bunlar normaldir. Tanımadığınız alan adlarını içeren, uzun ve okunmaz (şifrelenmiş gibi görünen) kod parçaları ise incelenmelidir. Bir yazıdaki şüpheli kodu temizlerken o yazının eski revizyonlarına da bakın; temiz bir revizyona geri dönmek elle düzenlemekten daha güvenli olabilir.

4. Tema, eklenti ve çekirdek dosyalarını kontrol edin

Google'ın yardım sayfası, kodun doğrudan HTML dosyalarına ya da içeriği üreten PHP dosyalarına eklenebileceğini söyler. WordPress'te bu genellikle temanın veya bir eklentinin dosyalarıdır. Kontrol listesi:

• Etkin tema: header.php, footer.php ve functions.php sık değiştirilen dosyalardır; ama kod herhangi bir tema dosyasına eklenebilir. Temayı resmi kaynağından indirip temiz kopyayla karşılaştırın veya değiştirin.
• wp-content/mu-plugins klasörü: Bu klasördeki PHP dosyaları WordPress tarafından otomatik yüklenir ve Eklentiler ekranında ayrı bir sekmede görünür; çoğu kişi bu sekmeye hiç bakmaz. Siz eklemediyseniz içindeki dosyaları inceleyin.
• Eklentiler: Tanımadığınız veya sizin kurmadığınız eklentileri not edin. Kullandığınız eklentileri silip wordpress.org'dan temiz sürümünü yeniden kurmak, tek tek dosya incelemekten daha güvenlidir.
• WordPress çekirdeği: WP-CLI ile wp core verify-checksums ve wp plugin verify-checksums --all komutları, çekirdek ve wordpress.org eklenti dosyalarını resmi sağlama toplamlarıyla karşılaştırır ve değiştirilmiş dosyaları listeler.

# Son 14 günde değişmiş PHP ve JS dosyaları
find ~/public_html -type f \( -name "*.php" -o -name "*.js" \) -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r | head -50

# Tema ve eklentilerde referrer/user agent kontrolü yapan PHP kodu
grep -rn -E "HTTP_REFERER|HTTP_USER_AGENT" ~/public_html/wp-content/themes ~/public_html/wp-content/mu-plugins 2>/dev/null

Değiştirilme tarihleri saldırgan tarafından değiştirilebilir, bu yüzden "tarih eski, demek ki temiz" diye düşünmeyin. Şüpheli PHP dosyalarını ve web shell'leri bulmanın ayrıntılı yöntemlerini şüpheli PHP dosyası ve web shell bulma yazımızda anlatıyoruz. Yönlendirme kodunu silip giriş kapısını (arka kapı dosyasını) bırakırsanız kod kısa süre içinde geri gelir.

5. Zamanlanmış görevler ve kullanıcılar

Temizlediğiniz kod bir gün sonra yeniden ortaya çıkıyorsa, onu yeniden yazan bir mekanizma vardır. İki yere bakın:

• Hosting panelindeki Cron işleri: Siz eklemediğiniz, uzak bir adresten dosya indiren veya garip bir PHP dosyasını çalıştıran görevleri silin.
• WordPress cron olayları: WP-CLI ile wp cron event list komutu kayıtlı olayları gösterir. Tanımadığınız kanca (hook) adlarını araştırın.
• Yönetici kullanıcılar: wp user list --role=administrator ile veya Kullanıcılar ekranından tüm yöneticileri kontrol edin; tanımadığınız hesapları silin.

Temizlik sonrası: önbellek, test ve Google

Kodu temizledikten sonra yönlendirme hâlâ görünüyorsa, bu her zaman temizliğin başarısız olduğu anlamına gelmez. Önbellek eklentisi, CDN (örneğin Cloudflare) veya tarayıcınız eski yanıtı saklıyor olabilir. Özellikle 301 yönlendirmeleri tarayıcılar tarafından önbelleğe alınabilir.

• Önbellek eklentisinin önbelleğini ve varsa CDN önbelleğini temizleyin.
• Yukarıdaki dört curl komutunu yeniden çalıştırın; hepsi aynı ve doğru yanıtı vermelidir.
• Search Console'da URL Denetleme aracında canlı testi (Test Live URL) çalıştırarak sayfanın Google'a nasıl göründüğüne bakın.
• Tüm şifreleri değiştirin ve WordPress güvenlik anahtarlarını yenileyin.
• Search Console'da Güvenlik sorunları raporunda bir bulgu varsa, tüm sayfalarda düzelttikten sonra inceleme isteyin. Google'ın yardım sayfasına göre bu inceleme birkaç gün ile birkaç hafta arasında sürebilir.

Tarayıcılar sitenizi kırmızı uyarı sayfasıyla gösteriyorsa süreç biraz farklıdır; Google tehlikeli site uyarısı kaldırma yazımıza bakın. Yönlendirmeyle birlikte sitenizde sahte Japonca veya spam sayfalar da oluşturulduysa Japon anahtar kelime hack yazımız sizin içindir. Kapıyı tekrar açık bırakmamak için de hack sonrası WordPress güvenlik sertleştirme rehberimizi uygulayın.

Sık yapılan hatalar

• Yalnızca kendi bilgisayarından bakıp "site normal" deyip konuyu kapatmak. Yönlendirme çoğu zaman yalnızca belirli ziyaretçilere uygulanır.
• Yalnızca .htaccess'i temizleyip veritabanı ve tema dosyalarına bakmamak.
• Yönlendirme kodunu silip arka kapı dosyasını, sahte yönetici hesabını veya cron görevini bırakmak.
• Önbelleği temizlemeden "temizlik işe yaramadı" sonucuna varmak ya da tam tersi, önbellekteki temiz kopyayı görüp sorunun bittiğini sanmak.
• Şifreleri temizlikten önce değiştirip, saldırgan hâlâ içerideyken yeni şifrelerin de ele geçmesine izin vermek. Önce kapıyı kapatın, sonra kilidi değiştirin; ama ikisini de aynı gün yapın.

Sık Sorulan Sorular

Ben siteye girince yönlendirme olmuyor, müşterim neden başka siteye gidiyor?

Google'ın spam politikaları, saldırganların yönlendirmeyi yönlendirene, tarayıcı kimliğine veya cihaza göre koşullu yapabildiğini belirtir. Siz adresi doğrudan yazdığınız veya yönetici olarak giriş yapmış olduğunuz için kod sizi atlıyor olabilir. Yukarıdaki curl komutlarıyla Google'dan gelen bir mobil ziyaretçiyi taklit ederek test edin.

Yönlendirme yalnızca mobilde oluyor, sorun telefonumda mı?

Farklı telefonlarda ve farklı ağlarda aynı şey oluyorsa sorun büyük ihtimalle sitededir. Tek bir cihazda oluyorsa o cihazdaki tarayıcı eklentileri veya istenmeyen uygulamalar da sebep olabilir. Ayrımı yapmak için curl testini mobil user agent ile çalıştırın; sunucu tarafında bir yönlendirme varsa başlıklarda görürsünüz.

Yedekten geri yüklesem yeterli olur mu?

Saldırıdan önce alınmış temiz bir yedek varsa geri yüklemek genellikle en hızlı yoldur; Google da temizlik için etkilenen dosyaları son iyi yedekle değiştirmeyi bir seçenek olarak sunar. Ancak saldırganın girdiği açık (güncel olmayan bir eklenti, sızmış bir şifre) kapatılmazsa site tekrar ele geçirilebilir. Geri yükledikten sonra güncellemeleri yapın ve şifreleri değiştirin.

Bu durum Google sıralamamı etkiler mi?

Google, saldırıya uğramış içeriği arama sonuçlarının dışında tutmaya çalıştığını belirtir ve gizli yönlendirmeyi (sneaky redirect) spam olarak sınıflandırır. Sitenizde bu tür bir sorun tespit edilirse Search Console'daki Güvenlik sorunları raporunda görebilirsiniz. Ne kadar hızlı temizler ve inceleme isterseniz etki o kadar kısa sürer. Spam politikalarının genel çerçevesi için Google spam politikaları yazımıza bakabilirsiniz.

SSH erişimim yok, bu kontrolleri nasıl yaparım?

curl komutlarını kendi bilgisayarınızda çalıştırabilirsiniz; Windows 10 ve sonrası, macOS ve Linux'ta curl genellikle yüklüdür. Dosya kontrollerini hosting panelinizdeki Dosya Yöneticisi ile, veritabanı sorgularını phpMyAdmin ile yapabilirsiniz. find ve grep komutları yalnızca sunucuda komut satırı erişiminiz varsa çalışır.

Yazılım, eklenti ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: WordPress hacklendi: temizleme rehberi · Şüpheli PHP dosyası ve web shell bulma · "Bu site saldırıya uğramış olabilir" uyarısı · Hack sonrası WordPress güvenlik sertleştirme · ERR_TOO_MANY_REDIRECTS çözümü · WordPress .htaccess kuralları