Sitem Başka Siteye Yönlendiriyor: Yönlendirme Virüsü Temizliği

Bir müşteriniz arıyor: "Sitenize girdim, bir anda bahis sitesine attı." Siz kendi bilgisayarınızdan açıyorsunuz, her şey normal. Telefondan deniyorsunuz, yine normal. Google'da sitenizi aratıp sonuca tıklıyorsunuz ve işte o zaman ekran bir saniye titriyor, adres çubuğunda hiç tanımadığınız bir alan adı beliriyor. "Sitem başka siteye yönlendiriyor" cümlesiyle arama yapan herkes bu senaryonun içinden geçiyor: yönlendirme her ziyaretçide tetiklenmediği için sorun günlerce, bazen haftalarca fark edilmiyor. Bu, WordPress yönlendirme virüsü diye bilinen zararlının bilinçli davranışıdır — site sahibini son gören kişi yapmak üzere tasarlanmıştır.

Bu yazıda o zararlının nereye saklandığını, hangi ziyaretçide neden tetiklendiğini ve en önemlisi neden "header.php'deki şu satırı sildim, düzeldi" yaklaşımının sizi 48 saat sonra aynı noktaya geri getirdiğini anlatacağım. Türkçe kaynakların büyük kısmı tek bir satırı silmeyi tarif ediyor; oysa yönlendirme kodu zararlının kendisi değil, sadece görünen ucudur. Asıl mesele arka kapıdır: uploads klasörüne bırakılmış bir PHP dosyası, mu-plugins içine düşürülmüş bir yükleyici, veritabanına yazılmış bir kayıt ya da sizin haberiniz olmadan açılmış bir yönetici hesabı. Aşağıda sıra dışı bir şey yapmayacağız — sadece bir olay müdahalesinin gerçekte nasıl yürüdüğünü, komut komut takip edeceğiz.

Yönlendirme Virüsü Neden Sadece Bazı Ziyaretçilerde Çalışıyor#

Yönlendirme zararlısı, kendisini gizlemek için ziyaretçiyi sınıflandırır ve yalnızca "değerli" gördüğü trafiği kaçırır. Bu tekniğe cloaking denir ve zararlının ömrünü uzatan asıl şey budur. Kod tipik olarak üç şeye bakar:

• Referrer (yönlendiren adres): Ziyaretçi arama motorundan mı geldi? HTTP_REFERER içinde google, bing, yandex geçiyorsa yönlendir; doğrudan adres yazarak gelene dokunma. Site sahibi genellikle adresi doğrudan yazar, bu yüzden hiçbir şey görmez.
• User-Agent (tarayıcı kimliği): Mobil mi? Android/iPhone kullanıcılarını yönlendir, masaüstünü bırak. Reklam ağlarında mobil trafik daha kolay paraya çevrildiği için bu ayrım çok yaygındır.
• Çerez ve oturum: Bir kez yönlendirilen ziyaretçiye çerez bırakılır ve ikinci ziyarette yönlendirilmez. Böylece kullanıcı "bir kere olmuştu, geçti" diye düşünür.
• Giriş durumu: WordPress'te is_user_logged_in() doğruysa hiçbir şey yapılmaz. Yönetici panelinde gezinirken hayatta bir anormallik görmezsiniz.

Bunu bilmek teşhisi kolaylaştırır. Kendi tarayıcınızla test etmek işe yaramaz; zararlının beklediği koşulları taklit etmeniz gerekir.

Yönlendirmenin Gerçekten Sitenizden Geldiğini Doğrulayın#

İlk adım, sorunun sunucu tarafında mı yoksa ziyaretçinin cihazında mı olduğunu ayırmaktır. Kendi tarayıcınızın eklentisi de yönlendirme yapabilir. Sunucunun ne döndürdüğünü doğrudan sorun:

# Arama motorundan gelen bir mobil ziyaretçiyi taklit et
curl -sIL -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15" \
  -e "https://www.google.com/" https://alanadiniz.com/ | grep -iE "HTTP/|location:"

Çıktıda böyle bir şey görüyorsanız yönlendirme sunucudan geliyordur:

HTTP/2 302
location: https://bilinmeyen-alan-adi.top/go/?u=alanadiniz.com
HTTP/2 200

Aynı isteği referrer ve mobil user-agent olmadan tekrarlayın; 200 dönüyorsa cloaking'i kanıtlamış olursunuz. Sayfa kaynağına enjekte edilmiş bir JavaScript de olabilir; bu durumda HTTP başlıklarında yönlendirme görünmez, gövdede görünür:

curl -s -A "Mozilla/5.0 (Linux; Android 13)" https://alanadiniz.com/ \
  | grep -oE "(window\.location|document\.location|atob\(|eval\()[^;]{0,120}"

atob( ile başlayan uzun bir base64 dizisi görüyorsanız klasik enjeksiyondur. Bu aşamada sitenizin DNS kayıtlarının da doğru olduğunu bir kez doğrulamakta fayda var — nadiren de olsa alan adı paneli ele geçirilip A kaydı başka bir IP'ye çekilmiş olabilir ve bu tamamen farklı bir olaydır.

Temizliğe Başlamadan Önce Kanıtı ve Yedeği Alın#

Temizliğe girişmeden önce mevcut hâlin tam bir kopyasını alın. Bu yedeği geri yüklemek için değil, incelemek için alıyorsunuz; temizlik sırasında sildiğiniz bir dosyanın içeriğine iki gün sonra ihtiyaç duyacaksınız.

# Dosya sistemi kopyası (temizlik öncesi)
tar --exclude='./wp-content/cache' -czf ~/inceleme-$(date +%F).tar.gz -C /home/kullanici/public_html .

# Veritabanı kopyası
mysqldump -u db_kullanici -p db_adi > ~/inceleme-db-$(date +%F).sql

# Erişim ve hata logları (sağlayıcı çoğu zaman eskiyi rotasyona sokar)
cp -a /home/kullanici/logs ~/log-yedek-$(date +%F)

Log kopyası kritik. Saldırganın hangi dosya üzerinden ve hangi tarihte girdiğini yalnızca erişim logu söyler ve barındırma tarafında bu loglar birkaç güne bir döner; rotasyon aralığı kısaysa geriye dönük kanıtı tamamen kaybedebilirsiniz.

Zararlı Kodun Dosya Tarafında Saklandığı Yerler#

Yönlendirme kodu neredeyse hiçbir zaman tek bir dosyada olmaz. Aşağıdaki tablo, gerçek olaylarda en sık karşılaştığım yerleşim noktalarını ve her birinin ne işe yaradığını gösteriyor:

Arama komutları — bunları önce çalıştırın, silmeye sonra geçin:

cd /home/kullanici/public_html

# Şüpheli fonksiyonlar
grep -rn --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|assert\(|preg_replace\(.*/e" . | head -50

# uploads altında PHP — meşru sebebi yoktur
find wp-content/uploads -type f -name "*.php"

# Son 7 günde değişen dosyalar
find . -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

# mu-plugins var mı
ls -la wp-content/mu-plugins/ 2>/dev/null

find -mtime çıktısındaki tarih kümelenmesi çok değerlidir: onlarca dosya aynı dakika içinde değişmişse bulaşma anını bulmuşsunuz demektir. Bu zaman damgasını not edin, birazdan erişim logunda arayacağız.

Çekirdek ve Eklenti Dosyalarını Karşılaştırın#

Elle bakmak yerine, WordPress çekirdeğini orijinaliyle karşılaştırın. WP-CLI kuruluysa tek komutla biter:

wp core verify-checksums
wp plugin verify-checksums --all

Çıktıdaki her Warning: File doesn't verify against checksum satırı, çekirdeğe dokunulduğunu söyler. Eklentiler için aynı doğrulama yalnızca resmi depodan kurulan eklentilerde çalışır; satın alınmış tema ve eklentileri satıcı arşiviyle elle kıyaslamanız gerekir. Temiz bir kopya indirip diff -qr ile karşılaştırmak en hızlı yoldur:

diff -qr wp-content/plugins/eklenti-adi/ /tmp/temiz/eklenti-adi/

Veritabanı Tarafını Atlamayın#

Yönlendirme kodunun tamamı dosyada olmayabilir; birçok kampanya kodu doğrudan veritabanına yazar ve tema temizlendikten sonra bile çalışmaya devam eder. Bakılacak yerler:

-- Otomatik yüklenen seçeneklerde script izi
SELECT option_id, option_name, LEFT(option_value, 120)
FROM wp_options
WHERE option_value REGEXP '<script|eval\\(|base64_decode|document\\.location'
ORDER BY option_id DESC;

-- Site adresi değiştirilmiş mi
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl','home');

-- Yazı ve sayfalara enjekte edilmiş script
SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<script%'
  AND post_content NOT LIKE '%application/ld+json%';

-- Widget ve tema mod kayıtları
SELECT option_name FROM wp_options
WHERE option_name LIKE 'widget_%' AND option_value LIKE '%script%';

siteurl ve home değerlerinin başka bir alan adına çekilmiş olması, giriş yapamamanızın da açıklamasıdır. Bu değerler bozulduysa wp-config.php içine geçici olarak sabitleyip paneli geri kazanabilirsiniz:

define( 'WP_HOME',    'https://alanadiniz.com' );
define( 'WP_SITEURL', 'https://alanadiniz.com' );

Toplu temizlikte wp search-replace işi kolaylaştırır ama önce --dry-run ile çalıştırın:

wp search-replace 'https://zararli-alan.top' '' --all-tables --precise --dry-run

Arka Kapıyı Bulmadan Temizlik Bitmez#

Türkçe rehberlerin neredeyse tamamının atladığı ve sitenin iki gün sonra yeniden bulaşmasına yol açan bölüm burasıdır. Yönlendirme kodunu silmek, saldırganın çıktısını silmektir; girişini kapatmaz. Kapatılması gereken giriş yolları:

1. uploads içindeki PHP dosyaları. Tek satırlık <?php eval($_POST['x']); ?> bile tam kontrol demektir. Hepsini silin ve uploads altında PHP çalışmasını sunucu seviyesinde kapatın:

# wp-content/uploads/.htaccess
<FilesMatch "\.(php|php3|php4|php5|php7|phtml|pht)$">
  Require all denied
</FilesMatch>

Nginx kullanıyorsanız karşılığı sunucu bloğunda tanımlanır:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
    return 403;
}

2. Sahte yönetici hesapları. Saldırganın en sevdiği kalıcılık yöntemi budur ve panele bakmadan görülmez:

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;

Tanımadığınız her satırı silin. Bazı zararlılar hesabı listede gizlemek için pre_user_query filtresi kullanır; bu yüzden panele değil, veritabanına bakıyoruz.

3. Uygulama parolaları ve REST API anahtarları. Hesabı silseniz bile daha önce üretilmiş bir uygulama parolası çalışmaya devam eder:

DELETE FROM wp_usermeta WHERE meta_key = '_application_passwords';

4. Zamanlanmış görevler. Hem WordPress hem sistem tarafına bakın:

wp cron event list
crontab -l
ls -la /etc/cron.d/

wget, curl ya da php -r içeren, sizin kurmadığınız her satır şüphelidir.

5. .user.ini ve php.ini dosyaları. auto_prepend_file yönergesi, her PHP isteğinden önce zararlı bir dosyayı çalıştırır ve tema temizlense de yönlendirme sürer:

find . -name ".user.ini" -o -name "php.ini" | xargs grep -l "auto_prepend_file" 2>/dev/null

6. FTP hesapları ve SSH anahtarları. cPanel > FTP Hesapları listesinde tanımadığınız hesap olabilir. Sunucuda ise ~/.ssh/authorized_keys dosyasına eklenmiş bir anahtar, siz parolayı değiştirseniz bile erişimi sürdürür.

Şifre Rotasyonu ve Tüm Oturumların Düşürülmesi#

Temizlikten sonra kimlik bilgilerinin tamamı yakılmış sayılır. Sırasıyla değiştirin: barındırma paneli (cPanel) parolası, tüm FTP hesapları, veritabanı kullanıcısı parolası (wp-config.php içinde de güncelleyin), SSH parolası/anahtarları, tüm WordPress yönetici parolaları ve alan adı kayıt firması hesabı.

Parola değiştirmek açık oturumları kapatmaz. WordPress'te çerezleri geçersiz kılmanın yolu güvenlik anahtarlarını yenilemektir:

wp config shuffle-salts

Bu komut wp-config.php içindeki sekiz anahtarı yeniler ve o anda oturumu açık olan herkesi — sizi de, saldırganı da — dışarı atar. WordPress güvenlik anahtarları konusuna aşina değilseniz bu adımın neden şifre değişiminden daha etkili olduğunu orada ayrıntılı bulursunuz. Ardından panel ve yönetici girişlerinde iki faktörlü doğrulamayı açın; ele geçirilen bir parolanın tek başına yetmemesi, tekrar bulaşmayı en çok azaltan tek önlemdir.

Giriş Yolunu Loglardan Bulun#

Bulaşma anını find -mtime ile bulmuştunuz. Şimdi o dakikayı erişim logunda arayın:

# Bulaşma dakikasındaki POST istekleri
grep "11/Aug/2026:03:4" access.log | grep '"POST' | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -20

# Zararlı dosyaya yapılan çağrılar
grep -F "uploads/2026/07/hjk.php" access.log | head

Aradığınız kalıp genellikle şudur: bir IP, önce bir eklentinin yükleme uç noktasına POST atar, hemen ardından uploads altındaki yeni dosyaya istek yapar. Bu iki satır size hem giriş yolunu hem saldırgan IP'sini verir. Giriş yolu bir eklenti açığıysa o eklentiyi güncelleyin ya da kaldırın — aynı sürümü geri yüklemek, kapıyı tekrar açık bırakmak demektir. Daha geniş bir olay müdahalesi çerçevesi için hacklenmiş site kurtarma yazısı bu yazıyı tamamlar.

Temizlik Sonrası: Doğrulama ve Arama Motoru Tarafı#

Temizliğin bittiğini varsaymayın, ölçün:

1. İlk bölümdeki curl testlerini üç varyantla tekrarlayın (mobil + Google referrer, masaüstü + referrer, ham istek).
2. Sitenizin farklı 8-10 URL'sini aynı şekilde test edin; bazı kampanyalar sadece yazı sayfalarında tetiklenir.
3. Google Search Console'da Güvenlik ve Manuel İşlemler > Güvenlik Sorunları ekranını kontrol edin. Uyarı varsa temizlik doğrulandıktan sonra inceleme talebi gönderin; süreç Google aldatıcı site uyarısı kaldırma yazısında adım adım anlatılıyor.
4. site:alanadiniz.com aramasıyla dizine eklenmiş spam sayfa kalıp kalmadığına bakın. Kalmışsa o URL'lerin 404/410 döndüğünü doğrulayın.
5. Bir hafta boyunca günde bir kez find . -name "*.php" -mmin -1440 çalıştırın. Yeni PHP dosyası çıkıyorsa arka kapı hâlâ açıktır.

Kalıcı önlem tarafında dosya izinlerini düzeltmek (dizinler 755, dosyalar 644, wp-config.php 640), yönetici girişini IP veya iki faktörlü doğrulamayla sınırlamak ve düzenli, sunucudan bağımsız yedek almak üçlüsü işi bitirir. Yedeğin aynı sunucuda durması, bu tür bir olayda hiçbir işe yaramaz.

Sıkça Sorulan Sorular#

Yönlendirme virüsü bilgisayarımdan mı bulaşıyor#

Hayır, yönlendirme sunucudaki dosyalardan veya veritabanından geliyorsa bilgisayarınızın bununla ilgisi yoktur. Ancak bulaşmanın başlangıcı sizin bilgisayarınız olabilir: FTP parolanızı çalan bir zararlı, doğrudan sunucuya dosya yükleyebilir. Bu yüzden temizlikten sonra bağlantı kurduğunuz bilgisayarları da taramak ve FTP parolasını kaydeden istemcileri kontrol etmek gerekir. curl testinde yönlendirme görünüyorsa sorun kesinlikle sunucudadır.

header.php dosyasındaki kodu sildim ama site yine yönlendiriyor#

Bu, arka kapının hâlâ açık olduğunun en tipik işaretidir. Zararlı kodu yeniden yazan bir yükleyici vardır: uploads altındaki bir PHP dosyası, mu-plugins klasörü, bir cron görevi ya da .user.ini içindeki auto_prepend_file yönergesi. Silinen dosyanın dakikalar içinde geri gelmesi de aynı anlama gelir. Önce bu yazıdaki arka kapı listesini baştan sona tarayın, ardından güvenlik anahtarlarını yenileyip tüm parolaları değiştirin; aksi hâlde temizlik her seferinde geçici kalır.

Siteyi yedekten geri yüklesem yeter mi#

Yetmez, çünkü yedeğin bulaşma tarihinden önce alındığından emin olamazsınız ve olsanız bile giriş yolu hâlâ açıktır. Yönlendirme zararlıları çoğu zaman haftalarca sessiz kalır, dolayısıyla "iki hafta önceki yedek" de bulaşmış olabilir. Geri yükleme yapacaksanız önce açığı kapatın (eklenti/tema güncellemesi), sonra temiz yedeği yükleyin, ardından tüm parolaları değiştirip anahtarları yenileyin. Yedekten dönmek bir temizlik yöntemi değil, temizliği hızlandıran bir araçtır.

Zararlı yazılım tarama eklentileri bu işi tek başına halleder mi#

Kısmen halleder; imza tabanlı tarayıcılar bilinen zararlıları iyi yakalar ama özel yazılmış veya şifrelenmiş yükleyicileri kaçırabilir. Ayrıca eklenti, veritabanındaki wp_options kayıtlarını ve sunucudaki cron görevlerini çoğu zaman kapsam dışı bırakır. Tarayıcıyı ilk eleme aracı olarak kullanın, bulduklarını temizleyin, sonra bu yazıdaki manuel kontrolleri mutlaka yapın. Malware tarama ve temizleme yazısında hangi tarayıcının neyi kaçırdığını daha ayrıntılı bulabilirsiniz.

Hosting hesabım askıya alındıysa ne yapmalıyım#

Sağlayıcıya siteyi geçici olarak yalnızca kendi IP'nize açmasını veya bakım moduna almasını isteyin, ardından temizliğe başlayın. Askıya alma genellikle sunucudan kaynak tüketen ya da spam üreten bir zararlı yüzünden yapılır; temizlik tamamlanmadan siteyi yayına açmak ikinci bir askıya alma getirir. Temizlik bittiğinde sağlayıcıya hangi dosyaları sildiğinizi, açığın hangi eklentide olduğunu ve hangi parolaları değiştirdiğinizi özetleyen kısa bir rapor iletin; bu, hesabın açılmasını belirgin biçimde hızlandırır.

Google sitemi aldatıcı olarak işaretledi, ne kadar sürede kalkar#

İnceleme talebi gönderdikten sonra genellikle birkaç gün içinde sonuçlanır, ancak süre garantisi verilmez. Önemli olan talebi temizlik doğrulandıktan sonra göndermektir: reddedilen her talep sonraki incelemeyi yavaşlatır. Talep metninde neyin bulaştığını, hangi dosyaların temizlendiğini ve tekrarını önlemek için ne yaptığınızı kısaca yazın. Uyarı kalkana kadar tarayıcıdaki kırmızı ekran görünmeye devam eder ve bu süre boyunca organik trafiğin çok büyük kısmını kaybedersiniz.

Sitem statik HTML, WordPress kullanmıyorum, yine de bulaşır mı#

Evet, bulaşır. Yönlendirme zararlısı için WordPress zorunlu değildir; çalınmış bir FTP parolası ya da sunucudaki başka bir sitenin açığı yeterlidir. Statik sitelerde zararlı genelde .htaccess dosyasına veya HTML dosyalarının sonuna eklenen script bloğuna yerleşir. Aynı yöntemle ilerleyin: grep -rn "script" *.html, .htaccess içeriğini kontrol edin, değişim tarihlerine bakın ve FTP parolalarını yenileyin. Paylaşımlı barındırmada aynı hesap altındaki tüm siteler birlikte incelenmelidir.

Kapanış#

Yönlendirme zararlısıyla mücadelede belirleyici olan şey, ne kadar hızlı temizlik yaptığınız değil, temizliği doğru sırayla yapıp yapmadığınızdır: önce kanıt ve yedek, sonra dosya ve veritabanı taraması, sonra arka kapı avı, en sonda parola rotasyonu ve anahtar yenileme. Bu sıra bozulduğunda — özellikle arka kapı adımı atlandığında — site birkaç gün içinde aynı hâle döner ve ikinci temizlik her zaman birincisinden zordur, çünkü artık Google uyarısı ve kaybedilmiş sıralamalar da masadadır. Bulaşma anını loglardan bulup açığı kapatmadan hiçbir temizliği "bitti" saymayın.

Bu işi kendiniz yürütmek istemiyorsanız ya da tekrarını kalıcı olarak engellemek istiyorsanız, düzenli güncelleme ve izleme yükünü üstlenen WordPress bakım hizmetimize, uygulama seviyesindeki saldırıları sunucuya ulaşmadan eleyen WAF çözümümüze ve olay anında geri dönebileceğiniz temiz bir kopya için sunucudan bağımsız yedekleme altyapımıza göz atabilirsiniz. Sitenizi daha izole ve kaynağı size ait bir ortama taşımayı düşünüyorsanız VDS sunucu paketleri, tekrar bulaşmayı besleyen komşu hesap riskini de ortadan kaldırır.