WordPress Siteniz Hacklendiyse: Sakin ve Sıralı Temizleme Rehberi

Siteniz gerçekten hacklendi mi? Belirtiler

WordPress.org, "hacklendim" demeden önce sizi buna götüren somut belirtileri (Indicators of Compromise) not etmenizi önerir. Şu işaretler güçlü birer göstergedir:

• Google, Bing veya bir antivirüs yazılımı sitenizi tehlikeli olarak işaretliyor; Google sonuçlarında "Bu site saldırıya uğramış olabilir" etiketi görünüyor.
• Hosting sağlayıcınız hesabınızı kötü amaçlı yazılım veya spam nedeniyle askıya aldı ya da sizi uyardı.
• Yönetici panelinde sizin oluşturmadığınız kullanıcılar, özellikle yönetici rolünde hesaplar var.
• Google'da site:alanadiniz.com araması yaptığınızda yazmadığınız konularda (ilaç, kumar, Japonca metin gibi) sayfalar çıkıyor.
• Ziyaretçiler, özellikle mobilden veya Google'dan gelenler, başka bir siteye yönlendiriliyor.
• Hosting hesabınızdan toplu e-posta gidiyor, geri dönen (bounce) iletiler veya kara liste uyarıları geliyor.
• Sitenin görünümü değişmiş, kaynak kodunda tanımadığınız script etiketleri ya da iframe'ler var.

İlk saatlerde yapılacaklar

Bu bölümdeki adımlar temizliğe başlamadan öncedir. Sırası önemlidir.

• Olanları yazın. Ne gördünüz, saat kaçta fark ettiniz, son günlerde yeni bir eklenti veya tema kurdunuz mu? WordPress.org bu notları bir olay raporunun temeli olarak görür; destek alırken çok işe yarar.
• Her şeyi silmeyin. Dosyaları rastgele silmek siteyi bozabilir ve saldırının nasıl gerçekleştiğini anlamanızı imkansız hale getirir.
• Adli (forensic) bir kopya alın. Temizliğe başlamadan önce, enfekte haliyle tüm dosyaların ve veritabanının bir kopyasını indirin. WordPress.org, hacklenmiş olsa bile ortamın bir anlık görüntüsünü almanızı önerir; bir şeyler ters giderse başvuracağınız tek kaynak bu olabilir. Bu kopyayı bilgisayarınızda ayrı bir klasörde tutun ve asla sunucuya geri yüklemeyin.
• Kendi bilgisayarınızı tarayın. WordPress.org'a göre saldırı birçok durumda site sahibinin bilgisayarındaki bir truva atıyla başlar; FTP veya wp-admin bilgileri buradan çalınır. Güncel bir antivirüsle tam tarama yapın.
• Şifreleri değiştirin. Temiz bir cihazdan: hosting paneli (cPanel), FTP/SFTP hesapları, tüm WordPress yöneticileri, veritabanı kullanıcısı ve alan adınıza bağlı e-posta hesapları.
• Oturumları sonlandırın. WordPress anahtar üreteci ile yeni değerler üretip wp-config.php içindeki güvenlik anahtarlarını değiştirin; içerideki herkes oturumdan atılır. Ayrıntılar: WordPress güvenlik anahtarları (salt).
• Hosting sağlayıcınıza haber verin. Paylaşımlı hostingde sorun yalnızca sizin sitenizle sınırlı olmayabilir; sağlayıcınız ek önlem alıyor olabilir.

Yönetici panelinize giremiyorsanız, veritabanı üzerinden şifre sıfırlama adımları phpMyAdmin ile WordPress şifresi sıfırlama yazısında, genel giriş sorunları ise WordPress admin paneline girilemiyor yazısında anlatılıyor.

Karar: Temiz yedekten geri dönmek mi, elle temizlemek mi?

Google'ın güvenlik sorunları belgeleri iki yolu da kabul eder: etkilenen dosyaları son sağlam yedekle değiştirmek ya da istenmeyen içeriği kendiniz temizlemek. Hangisinin sizin için uygun olduğunu aşağıdaki tablo özetler.

Yedekleme ve geri yükleme adımları WordPress yedekleme ve geri yükleme yazısında ayrıntılı olarak var. Geri yüklemeden önce mevcut enfekte hali yukarıda anlatıldığı gibi ayrıca kopyalamayı unutmayın.

Adım 1: WordPress çekirdek dosyalarını temiz kopyayla değiştirin

Çekirdek dosyalar saldırganlar için iyi bir saklanma yeridir; ama aynı zamanda değiştirmesi en kolay kısımdır. WordPress.org'un önerisi şudur: kullandığınız sürümün aynısını indirin ve wp-admin ile wp-includes klasörlerini tamamen silip yenileriyle değiştirin. Yönetim panelindeki "yeniden yükle" seçeneğine güvenmeyin; bu tür yükleyiciler genellikle yalnızca mevcut dosyaların üzerine yazar, saldırganların eklediği yeni dosyalar ise yerinde kalır.

• Mevcut sürümünüzü wp-includes/version.php dosyasındaki $wp_version satırından öğrenin; aynı sürümü WordPress sürüm arşivi sayfasından indirin.
• Kök dizindeki çekirdek PHP dosyalarını (index.php, wp-login.php, wp-settings.php gibi) da temiz kopyalarıyla karşılaştırın; kök dizinde WordPress paketinde olmayan PHP dosyaları varsa inceleyin.
• wp-config.php dosyasını silmeyin; satır satır okuyun. Tanımadığınız include satırları, uzun şifrelenmiş metinler veya dosya başında ya da sonunda ek kod varsa kaldırın.

SSH erişiminiz varsa WP-CLI ile çekirdek ve eklenti dosyalarını WordPress.org'daki sağlama toplamlarıyla (checksum) karşılaştırabilirsiniz:

# Çekirdek dosyaları WordPress.org checksum değerleriyle karşılaştır
wp core verify-checksums

# wordpress.org deposundaki tüm eklentileri karşılaştır
wp plugin verify-checksums --all

Adım 2: Eklentileri, temaları ve uploads klasörünü kontrol edin

WordPress.org, temalarınızın ve eklentilerinizin bulunduğu wp-content klasöründe daha dikkatli ilerlemenizi önerir. Pratik bir sıra:

• Kullanmadığınız eklenti ve temaları tamamen silin. Pasif durumdaki bir eklentinin dosyaları sunucuda durduğu sürece risk taşır.
• Kullandığınız eklentileri ve temaları resmi kaynağından (wordpress.org veya satıcının sitesi) yeniden indirip klasörü değiştirin. "Nulled" (lisanssız kopyalanmış) eklenti veya tema varsa bunlar başlı başına risktir; kaldırın.
• Tema dosyalarında özellikle index.php, header.php, footer.php ve functions.php dosyalarını inceleyin. WordPress.org bu dosyaların değiştirildiğinde tüm sayfa isteklerini etkileyebildiği için hedef olduğunu belirtir.
• wp-content/uploads klasöründe normalde görsel, PDF gibi medya dosyaları bulunur. Burada PHP dosyası görüyorsanız ciddi bir uyarı işaretidir.
• wp-content/mu-plugins klasörü varsa kontrol edin; buradaki dosyalar eklenti listesinde ayrı bir sekmede görünür ve otomatik çalışır.

# Son 7 günde değişen PHP dosyalarını listele
find . -type f -name "*.php" -mtime -7 -ls

# uploads içinde PHP dosyası var mı?
find wp-content/uploads -type f -name "*.php"

# Sık kullanılan gizleme kalıplarını ara (sonuçları tek tek inceleyin)
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" --include="*.php" wp-content/

Eklenti tabanlı tarayıcılar da yardımcı olur. WordPress.org'un hacklenme sayfasında listelenen seçeneklerden Wordfence Security ve Sucuri Security eklentileri sunucudaki dosyaları tarar; Sucuri SiteCheck ise sitenizi dışarıdan, bir ziyaretçi gibi kontrol eder. Google'ın da belirttiği gibi hiçbir tarayıcı her zararlı yazılımı yakalayamaz; temiz sonuç tek başına sitenin temiz olduğu anlamına gelmez.

Adım 3: Veritabanını inceleyin

Dosyaları temizleseniz bile veritabanında kalan bir sahte yönetici hesabı veya yazılara gömülmüş bir script, sorunu geri getirir. phpMyAdmin'de şu kontrolleri yapın. Örneklerde tablo öneki wp_ olarak yazıldı; sizin önekiniz wp-config.php içindeki $table_prefix değeridir (bkz. WordPress tablo öneki).

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

-- En son eklenen kullanıcılar
SELECT ID, user_login, user_email, user_registered
FROM wp_users ORDER BY user_registered DESC LIMIT 20;

-- Yönetici yetkisine sahip tüm hesaplar
SELECT u.ID, u.user_login, u.user_email
FROM wp_users u JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

-- İçeriğinde script veya iframe geçen yazılar
SELECT ID, post_title, post_type FROM wp_posts
WHERE post_content LIKE '%<script%' OR post_content LIKE '%<iframe%';

• siteurl ve home değerleri sizin alan adınız olmalı. Farklıysa düzeltin; yönlendirme vakalarında bu sık görülür (bkz. redirect hack).
• Tanımadığınız yönetici hesaplarını silmeden önce adlarını ve kayıt tarihlerini not edin; bu tarih saldırının başlangıcını tahmin etmenize yardım eder.
• Script içeren yazıların hepsi zararlı değildir (örneğin bilerek eklediğiniz bir analitik kodu). Tanımadığınız alan adlarına giden scriptleri temizleyin.
• wp_options tablosunda tanımadığınız, uzun ve anlamsız içerikli kayıtlar ile widget içeriklerini de gözden geçirin.

# SSH ve WP-CLI varsa aynı kontrollerin kısa yolu
wp option get siteurl
wp option get home
wp user list --role=administrator

Adım 4: Zamanlanmış görevleri (cron) kontrol edin

Bazı bulaşmalar, sildiğiniz dosyaları belirli aralıklarla yeniden oluşturan zamanlanmış görevler bırakır. İki yere bakın:

• Sunucu cron'ları: cPanel'de "Cron Jobs" bölümü varsa, sizin eklemediğiniz, uzak bir adresten dosya indiren veya tanımadığınız bir PHP dosyasını çalıştıran satırları silin.
• WordPress cron olayları: WP-CLI ile wp cron event list komutunu çalıştırın ya da WP Crontrol eklentisiyle listeyi panelden görüntüleyin. Hiçbir eklentinize ait olmayan kanca (hook) adlarını araştırın.

# WordPress zamanlanmış olaylarını listele
wp cron event list

Adım 5: .htaccess dosyalarını inceleyin

WordPress.org, enfeksiyonun türü ne olursa olsun .htaccess dosyasının en sık değiştirilen dosyalardan biri olduğunu ve yalnızca kök dizinde değil alt klasörlerde de bulunabileceğini hatırlatır. Google da yönlendirmelerin Apache sunucularda .htaccess üzerinden yapılabildiğini belirtir.

• Kök dizindeki .htaccess dosyasında # BEGIN WordPress ile # END WordPress arasındaki standart bloğu tanıyın; dışındaki her kuralı sizin veya bir eklentinin eklediğinden emin olun. Standart blok için WordPress .htaccess kuralları yazısına bakın.
• Tüm alt klasörlerdeki .htaccess dosyalarını bulun: find . -name ".htaccess"
• User agent veya referrer'a göre (örneğin yalnızca mobil ya da yalnızca Google'dan gelenler) yönlendirme yapan RewriteCond satırları tipik bir işarettir.

Adım 6: Son adımlar ve doğrulama

• Her şeyi güncelleyin. WordPress.org, temizlik bittikten sonra WordPress'i en son sürüme güncellemenizi önerir; eklentiler ve temalar için de aynısı geçerli. Ayrıntılar: WordPress otomatik güncelleme ayarları.
• Şifreleri yeniden değiştirin. WordPress.org özellikle vurgular: şifreleri site temizlendikten sonra bir kez daha değiştirin. Veritabanı kullanıcısının şifresini de değiştirip wp-config.php'ye yazın. Güçlü şifre için güçlü şifre rehberine bakın.
• Güvenlik anahtarlarını yeniden üretin. Temizlik sırasında oturum açmış olabilecek herkesi bir kez daha dışarı atar.
• Siteyi dışarıdan test edin. Farklı bir cihazdan, giriş yapmadan, hem mobil hem masaüstünde açın; Search Console'da URL Denetleme aracıyla Google'ın gördüğü hali kontrol edin.
• Google'a bildirin. Search Console'daki Güvenlik sorunları raporunda kayıt varsa, tüm sayfalarda düzelttikten sonra inceleme isteyin. Süreç bu yazıda anlatılıyor.
• Açığı kapatın. Aynı açık açık kaldıkça temizlik geçicidir. 2FA, en az yetki, dosya düzenlemeyi kapatma ve WAF gibi önlemler hack sonrası güvenlik sertleştirme yazısında.
• Kişisel veri etkilendiyse KVKK yükümlülüğünüzü değerlendirin. Müşteri veya üye bilgileri ele geçirilmiş olabilirse kişisel veri ihlali bildirimi yazısına bakın.

Sık yapılan hatalar

• Yalnızca görünen zararlı kodu silip arka kapıyı (genellikle ayrı bir PHP dosyası) bırakmak. Site birkaç gün sonra yeniden hacklenir.
• En son yedeği kontrol etmeden geri yüklemek; yedek de enfekte olabilir.
• Şifreleri, bilgisayarında truva atı olan cihazdan değiştirmek.
• Temizlik bitmeden Google'a inceleme isteği göndermek. Google, sorun düzelmeden gönderilen isteklerin sonraki incelemeyi uzatabileceğini belirtir.
• Pasif ama sunucuda duran eski eklentileri "kullanmıyorum, sorun olmaz" diye bırakmak.

Sık Sorulan Sorular

Her şeyi silip WordPress'i sıfırdan kursam daha kolay olmaz mı?

WordPress.org bunun bazı durumlarda mümkün olduğunu ama çoğu zaman pratik olmadığını belirtir; içerikleriniz veritabanında, medyanız uploads klasöründedir ve bunları taşırken bulaşmayı da taşıyabilirsiniz. Daha güvenli yol, çekirdeği ve eklentileri temiz kopyalarla değiştirip içeriği ve veritabanını kontrol ederek korumaktır.

Güvenlik eklentisi "temiz" diyor, yine de hacklenmiş olabilir miyim?

Evet. Google, antivirüs ve tarama yazılımlarının birçok zararlı yazılımı bulduğunu ama hepsini bulamadığını açıkça söyler. Belirtiler devam ediyorsa (yönlendirme, spam sayfalar, bilinmeyen kullanıcılar) dosya ve veritabanı kontrollerini elle de yapın.

Hacklenme ne kadar süre önce başladı, nasıl anlarım?

Kesin bir yöntem yoktur. Sahte yönetici hesaplarının kayıt tarihi, şüpheli dosyaların değiştirilme tarihleri ve sunucu erişim kayıtları ipucu verir; ancak saldırganlar dosya tarihlerini değiştirebilir. Erişim günlüklerini okumak için Linux loglarını okuma yazısı yardımcı olabilir.

Google'daki uyarı temizlikten sonra kendiliğinden kalkar mı?

Duruma göre değişir. Google'ın belgelerine göre otomatik olarak tespit edilen sorunlar, site temiz olarak yeniden tarandığında kalkar; Search Console'da güvenlik sorunu kaydı varsa inceleme isteği göndermeniz gerekir. Ayrıntılar için Google uyarısı rehberine ve tehlikeli site uyarısı rehberine bakın.

Kendim temizleyemezsem ne yapmalıyım?

Google, .htaccess dosyalarına bakmak veya disk imajı almak size rahat gelmiyorsa siteyi tamamen temizleyip güvenli hale getirebilecek güvenilir bir profesyonel bulmanızı önerir. WordPress.org'un destek forumlarındaki "hacked" etiketi de ücretsiz yardım için bir başlangıç noktasıdı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: Şüpheli PHP dosyası ve web shell bulma · "Bu site saldırıya uğramış olabilir" uyarısı · Google tehlikeli site uyarısını kaldırma · Japon anahtar kelime hack'i · Site başka siteye yönleniyor · Hosting hesabı spam mail gönderiyor · Hack sonrası güvenlik sertleştirme · WordPress yedekleme ve geri yükleme · WordPress dosya izinleri