Kısa cevap: WordPress siteniz aniden başka bir adrese yönleniyor, yönetici hesabı çalışmıyor veya eklentiler tekrar tekrar çöküyorsa ilk işiniz yeniden kurulum yapmak değildir. Önce siteyi izole edin, mevcut durumu kaydedin ve geri dönüş noktası alın. Bu rehber, gerçek bir site kurtarma operasyonunda uygulanan karar sırasından türetildi; alan adı, IP adresi ve hesap bilgileri güvenlik için anonimleştirildi.
Panik anında yapılan en pahalı hata, kanıtları ve kurtarılabilir veriyi silen hızlı bir “temiz başlangıç”tır. Yeniden kurulum bazı durumlarda doğru son adım olabilir; fakat yedek, kayıt ve kapsam olmadan uygulanırsa saldırının nasıl gerçekleştiğini anlamayı zorlaştırır. Ayrıca sağlam içeriğin, SEO geçmişinin ve reklam hesabı doğrulamalarının kaybolmasına yol açabilir.
Önce belirtileri yazın, teşhisi değil
“Site hacklendi” bir teşhistir. İlk kayda geçirmeniz gereken şey ise gözlenebilir belirtidir. Örneğin:
- Ana sayfa bilinmeyen bir alan adına yönleniyor.
- WordPress yönetici hesabı doğru parola ile açılmıyor.
- Tarayıcı sertifika veya Cloudflare hatası gösteriyor.
- Belirli bir eklenti etkinleşince kritik hata oluşuyor.
- Disk kullanımı beklenenden yüksek görünüyor.
- SSH çalışmıyor fakat sunucu konsolu açılıyor.
Bu ayrım önemlidir. Yönlendirme, WordPress dosyasından çıkabileceği gibi DNS, CDN kuralı, web sunucusu yapılandırması veya tema kodundan da kaynaklanabilir. Aynı belirti için farklı katmanlarda değişiklik yapmak sorunu büyütebilir.
İlk 60 dakika için güvenli karar sırası
1. Etkilenen siteyi izole edin
Birden fazla site aynı sunucudaysa bütün sunucuyu körlemesine kapatmak yerine önce şüpheli alanı askıya almak daha kontrollüdür. Amaç ziyaretçilerin zararlı yönlendirmeye maruz kalmasını ve saldırganın web üzerinden işlem yapmasını sınırlamaktır. İzolasyon sırasında DNS kayıtlarını silmeyin; mevcut bağlantı zincirini incelemek için onlara ihtiyaç duyabilirsiniz.
İzolasyonun gerçekten çalıştığını hem alan adı üzerinden hem de doğrudan origin tarafında kontrol edin. CDN önbelleği eski sayfayı göstermeye devam edebileceği için tek bir tarayıcı görüntüsü yeterli değildir.
2. Değişiklikten önce geri dönüş noktası oluşturun
Sağlam bir geri dönüş noktası yalnız WordPress dosyalarından oluşmaz. Yazılar, kullanıcılar ve ayarlar veritabanında; tema, eklenti ve yüklemeler dosya sistemindedir. Bu nedenle dosyalar ile veritabanını aynı döneme ait bir takım olarak saklayın.
WordPress’in resmî yedekleme rehberi de dosya ve veritabanının birlikte korunmasını, birden fazla güncel kopyanın farklı konumlarda tutulmasını öneriyor. Yedek oluştu ifadesiyle yetinmeyin: arşivin açıldığını, veritabanı dökümünün sıkıştırma testini ve dosyanın özet değerini doğrulayın.
Pratik kural: Geri yükleme yapmadan önce mevcut bozuk durumun da yedeğini alın. Bu kopya yalnız geri dönmek için değil, sonradan yapılacak olay incelemesi için de değerlidir.
3. Erişim kanallarını birbirinden ayırın
Kontrol paneli, SSH, sunucu konsolu ve WordPress yönetimi aynı şey değildir. Birinin çalışmaması tüm sunucunun kapalı olduğu anlamına gelmez. Hangi kanalın açık olduğunu tek tek kaydedin:
| Kanal | Ne kanıtlar? | Ne kanıtlamaz? |
|---|---|---|
| Sunucu konsolu/VNC | İşletim sistemine temel erişim olduğunu | Web servislerinin sağlıklı olduğunu |
| SSH | Ağ, port ve kimlik doğrulama zincirini | WordPress hesabının çalıştığını |
| Plesk/cPanel | Hosting yönetim katmanını | Her sitenin temiz olduğunu |
| WordPress yönetimi | Uygulama hesabını | DNS veya CDN’in doğru olduğunu |
Geçici erişim açmanız gerekiyorsa tüm internete port açmak yerine tek kaynak IP ve tek portla sınırlandırın. İş bitince hem güvenlik duvarı kuralını hem geçici anahtarı kaldırın ve kendi yönetim erişiminizin hâlâ çalıştığını yeni bir bağlantıyla test edin.
4. Yönlendirme zincirini katman katman kontrol edin
Alan adının DNS kaydı, CDN proxy durumu, SSL sertifikası, web sunucusu yönlendirmesi, WordPress home/siteurl ayarları ve eklenti yönlendirmeleri aynı zincirin parçalarıdır. İncelemeyi dıştan içe doğru yapmak işleri kolaylaştırır:
- DNS alanı beklenen sağlayıcıda mı?
- A ve CNAME kayıtları doğru origin’i mi gösteriyor?
- CDN’de bilinmeyen yönlendirme, Worker veya kural var mı?
- Origin doğru alan adıyla hangi HTTP durumunu döndürüyor?
- WordPress URL ayarları ve kalıcı bağlantılar tutarlı mı?
Şüpheli bir kural bulursanız hemen silmek yerine önce ekran görüntüsü, zaman damgası ve kapsamını kaydedin. Kanıtı saklamak, zararlı yapılandırmayı çalışır halde bırakmak anlamına gelmez; kayıttan sonra kuralı devre dışı bırakmak veya karantinaya almak mümkündür.
5. Çekirdek bütünlüğünü ve bilinmeyen dosyaları ayrı değerlendirin
wp core verify-checksums, kurulu WordPress çekirdek dosyalarını WordPress.org özetleriyle karşılaştırır. Başarılı sonuç çekirdek dosyalarının eşleştiğini gösterir; fakat tema, ticari eklenti, yükleme klasörü veya veritabanının temiz olduğunu tek başına kanıtlamaz.
WordPress’in WP-CLI güvenlik rehberi, checksum sonucu temiz olsa bile sonradan eklenmiş bilinmeyen bir dosyanın ayrıca incelenmesi gerektiğini vurguluyor. Bu nedenle aşağıdaki kontrolleri birlikte kullanın:
- WordPress çekirdek checksum kontrolü
- Resmî depodaki eklentiler için eklenti checksum kontrolü
- Uploads klasöründe PHP veya çalıştırılabilir dosya araması
- Yeni/değişmiş dosyaların tarih ve sahiplik incelemesi
- Sunucu tarafı kötü amaçlı yazılım taraması
- Veritabanında yönetici, cron, seçenek ve yönlendirme kayıtları incelemesi
6. Disk doluluğunu “spam var” diye yorumlamadan önce kaynağı bulun
Sunucuda onlarca gigabayt kullanım görmek saldırganın dosya yüklediğini düşündürebilir. Oysa yüksek kullanımın kaynağı eski yerel yedekler, posta kutuları, günlükler veya kontrol paneli dump arşivleri olabilir. Önce üst dizinleri ölçün, sonra alan bazında ayrıştırın.
Gerçek bir incelemede web sitelerinin toplamı birkaç gigabaytken asıl alanı yıllar içinde birikmiş hosting paneli yedekleri kullanıyordu. Bu dosyaları zararlı olarak etiketleyip topluca silmek yerine saklama politikasını, en son temiz geri dönüş noktalarını ve uzak kopyaların çalışıp çalışmadığını değerlendirmek gerekir.
7. Güncelleme ile olay müdahalesini birbirine karıştırmayın
Eski eklentiler risklidir; ancak olayın ortasında bütün eklentileri topluca güncellemek hem kanıtları değiştirir hem yeni uyumluluk hataları doğurabilir. Önce temiz yedek ve erişim kanalı, sonra en küçük değişiklik, ardından doğrulama yaklaşımı daha güvenlidir.
Her adımda şu dört soruya cevap verin:
- Bu değişiklik hangi bulguya dayanıyor?
- Geri dönüş yolu var mı?
- Yalnız hedef siteyi mi, tüm sunucuyu mu etkiliyor?
- Değişiklikten sonra neyi ölçerek başarı diyeceğiz?
Hangi durumda temiz kurulum düşünülür?
Çekirdek, tema ve eklenti kaynağı güvenilir biçimde doğrulanamıyorsa; kalıcılık mekanizması bulunmuşsa; yönetici hesaplarının tamamı ele geçirilmişse veya temiz bir tarihsel yedek yoksa temiz kurulum gerekli olabilir. Yine de bu karar içerik/veritabanı ihracı, medya taraması, kullanıcıların yeniden oluşturulması ve DNS/CDN kontrolüyle birlikte planlanmalıdır.
Temiz kurulum, “eski dosyaları silip aynı parolaları kullanmaya devam etmek” değildir. Yönetici kullanıcıları, SSH anahtarları, kontrol paneli ve CDN erişimleri ayrı ayrı yenilenmeli; kullanılmayan eklentiler geri yüklenmemelidir.
Yayına dönmeden önce son kontrol
- Temiz ve doğrulanmış bir yedek mevcut.
- Şüpheli yönlendirme/DNS/CDN kuralları giderildi.
- WordPress çekirdeği ve resmî eklentiler doğrulandı.
- Kötü amaçlı yazılım taraması bulguları incelendi.
- Yönetici hesapları ve geçici erişimler gözden geçirildi.
- SSL, ana sayfa, giriş ekranı, robots, sitemap ve önemli sayfalar test edildi.
- Günlüklerde yeni fatal hata veya olağan dışı istek yok.
- Site önce kontrollü bakım modunda, sonra sınırlı biçimde açıldı.
Sonuç
WordPress olay müdahalesinde hız, çok sayıda komut çalıştırmak değildir. En hızlı güvenli yol; kapsamı daraltmak, geri dönüş noktası almak, katmanları sırayla doğrulamak ve her değişikliğin sonucunu ölçmektir. Bu yöntem yalnız saldırı ihtimalinde değil, yanlış DNS, bozuk eklenti veya hatalı güncelleme gibi daha sıradan arızalarda da veri kaybını önler.