WordPress Güvenliği: Hacklenmeden Önce Almanız Gereken Önlemler

WordPress siteleri genelde hedef seçilerek değil, tarayan botlar tarafından toplu şekilde bulunarak ele geçiriliyor. Bot bir güvenlik açığı listesiyle dolaşır, sizin siteniz o listedeki eski sürüm eklentiyi barındırıyorsa içeri girer. Yani “benim sitem küçük, kimse uğraşmaz” varsayımı pratikte geçerli değil.

İyi haber şu: girişlerin büyük çoğunluğu iki kapıdan oluyor. Ya zayıf/tekrar kullanılan bir yönetici parolası, ya da güncellenmemiş bir eklenti. Aşağıdaki önlemler tam olarak bu iki kapıyı kapatmaya odaklanıyor; hepsi de bir öğleden sonrada uygulanabilir.

Yönetici hesabını sertleştirin

Kaba kuvvet denemelerinin neredeyse tamamı admin kullanıcı adıyla başlar. Bot kullanıcı adını bildiğini varsayarsa sadece parolayı denemesi yeterli olur; bilmiyorsa iş iki katına çıkar.

• Kullanıcı adını değiştirin. WordPress kullanıcı adını doğrudan düzenletmez. Yeni bir yönetici hesabı açın, onunla giriş yapın, eski hesabı silerken “Tüm içeriği şu kullanıcıya ata” seçeneğini işaretleyin.
• Görünen adı ayırın. Kullanıcı profilinde “Herkese açık görünen ad” alanını kullanıcı adından farklı yapın; aksi halde yazar adı üzerinden kullanıcı adı sızar.
• Yazar sayfası taramasını engelleyin. site.com/?author=1 adresi çoğu kurulumda kullanıcı adına yönlendirir. Güvenlik eklentilerinin çoğunda bunu kapatan bir seçenek vardır.
• Rolleri daraltın. İçerik giren kişiye Yönetici değil Editör verin. Ajansınıza kalıcı yönetici hesabı açmak yerine iş bitince hesabı kapatın.
• İki adımlı doğrulama. En az yönetici rolündeki herkes için zorunlu yapın. Uygulama tabanlı kod (TOTP) SMS’ten güvenlidir; kurtarma kodlarını parola yöneticisine kaydedin.

Giriş sayfasını kaba kuvvetten koruyun

wp-login.php ve xmlrpc.php saldırı trafiğinin ana hedefidir. Sunucu erişim kayıtlarında bu iki dosyaya dakikada onlarca POST isteği görmek olağandır. Alınacak önlemler:

1. Deneme sınırı. 5 başarısız denemeden sonra IP’yi 20 dakika kilitleyen bir eklenti kurun. Bu tek başına otomatik denemelerin çok büyük kısmını keser.
2. XML-RPC. Jetpack ya da mobil WordPress uygulaması kullanmıyorsanız kapatın. XML-RPC’nin system.multicall yöntemi tek istekte yüzlerce parola denemesine izin verdiği için kaba kuvvette çok kullanılır.
3. Giriş adresini değiştirmek. /wp-admin yerine özel bir adres kullanmak gerçek bir güvenlik katmanı değil ama otomatik bot trafiğini ve sunucu yükünü belirgin şekilde azaltır.
4. IP kısıtı. Yönetim sabit bir ofisten yapılıyorsa /wp-admin dizinine cPanel > Dizin Gizliliği ya da .htaccess ile IP kısıtı koyun.
5. CAPTCHA. Giriş ve yorum formlarına ekleyin; bu aynı zamanda spam yorum yükünü de azaltır.

Eklenti ve temalar: asıl risk burada

Bildirilen WordPress zafiyetlerinin ezici çoğunluğu çekirdekte değil, üçüncü taraf eklenti ve temalardadır. Kontrol listesi:

Güncellemeleri otomatikleştirin ama düşünerek: çekirdek küçük sürüm güncellemelerini ve güvenilir eklentileri otomatiğe alın, tema ve WooCommerce gibi kritik bileşenleri elle güncelleyin. Güncelleme öncesi yedek alışkanlığı bu noktada hayat kurtarır; eklenti seçme ölçütlerini ayrı bir yazıda ayrıntılandırdık.

Dosya izinleri, wp-config ve düzenleyici

Yerleşik tema/eklenti düzenleyicisi, panele giren birinin doğrudan PHP kodu çalıştırmasına imkan verir. Ele geçirilmiş bir hesapla yapılan ilk iş genelde budur. wp-config.php içine ekleyin:

• define('DISALLOW_FILE_EDIT', true); — panel içi kod düzenleyiciyi kapatır.
• define('DISALLOW_FILE_MODS', true); — panelden eklenti/tema kurulumunu ve güncellemesini de engeller. Sık müdahale gerekmeyen kurumsal sitelerde mantıklı, aktif geliştirilen sitede rahatsız edici olabilir.

Dosya izinlerinde standart değerler: klasörler 755, dosyalar 644, wp-config.php için 640 ya da 600. Hiçbir dosyaya 777 vermeyin; bir eklenti “yazma izni yok” diyorsa çözüm 777 değil, dosya sahipliğinin düzeltilmesidir. wp-config.php dosyasını web dışından erişime kapatmak için .htaccess içine şu bloğu ekleyebilirsiniz:

<Files wp-config.php> Require all denied </Files>

Ayrıca wp-content/uploads klasöründe PHP çalıştırmayı engelleyin. Yüklenen dosya üzerinden kod çalıştırma, yükleme formu olan sitelerde en sık görülen zincirlerden biri.

Güvenlik eklentisi ve sunucu tarafı

Piyasadaki güvenlik eklentileri kabaca üç iş yapar: tarama, giriş koruması ve web uygulama güvenlik duvarı. Seçerken şunlara bakın:

• Performans yükü. Bazı eklentiler her istekte dosya bütünlüğü taraması yapar; TTFB’ye 100-200 ms ekleyebilir. Query Monitor ile ölçün.
• İki tane kurmayın. Çakışan kural setleri hem yavaşlatır hem yanlış pozitif üretir.
• Sunucu tarafı zaten ne veriyor? ModSecurity ve Imunify360 gibi araçlar barındırma tarafında çalışır ve PHP’ye hiç ulaşmadan istekleri eler. Bu katman varsa eklenti tarafını hafif tutabilirsiniz. Paylaşımlı bir web hosting hesabında bu bileşenlerin açık olup olmadığını sağlayıcınıza sorun.
• SSL ve HSTS. Tüm trafik HTTPS üzerinden aksın. Sertifika türleri ve doğrulama farkları için SSL türleri yazısına bakabilirsiniz.

KVKK açısından da bir tarafı var: müşteri verisi tutan bir sitede ihlal yaşandığında, aldığınız teknik tedbirleri belgeleyebilmek gerekiyor. Yedek politikası, erişim kayıtları ve rol yönetimi bu belgelemenin parçası.

Ele geçirildiyse ne yapılır

Şüpheli belirtiler: sitede olmayan yönlendirmeler, arama sonuçlarında alakasız sayfalar, tanımadığınız yönetici hesapları, wp-content içinde rastgele adlı PHP dosyaları, Google Search Console’dan gelen güvenlik uyarısı. Sıra:

1. Siteyi geçici olarak bakım moduna alın veya erişimi kısıtlayın.
2. Tüm yönetici parolalarını, FTP ve veritabanı parolalarını değiştirin.
3. wp-config.php güvenlik anahtarlarını yenileyin; bu tüm oturumları düşürür.
4. Çekirdeği aynı sürümle üzerine yeniden kurun, eklentileri kaldırıp temiz sürümlerini kurun.
5. Temiz olduğu bilinen bir yedeğe dönmek çoğu zaman en hızlı yol. Yedek yoksa iş çok uzar.
6. Temizlik sonrası Search Console’dan yeniden inceleme talebi gönderin.

Özetle

• admin kullanıcı adını kaldırın, yöneticilere iki adımlı doğrulama zorunlu kılın, rolleri gerektiği kadar verin.
• Giriş denemesini sınırlayın, kullanmıyorsanız XML-RPC’yi kapatın, mümkünse yönetim paneline IP kısıtı koyun.
• Terk edilmiş, depodan kaldırılmış ve nulled eklenti/temalardan uzak durun; devre dışı olanları silin.
• DISALLOW_FILE_EDIT ekleyin, izinleri 755/644 yapın, uploads klasöründe PHP çalıştırmayı engelleyin.
• Tek bir güvenlik eklentisi kullanın ve sunucu tarafındaki güvenlik duvarının neyi zaten karşıladığını öğrenin.