WordPress güvenlik sertleştirme nedir? WordPress güvenlik sertleştirme (hardening), bir WordPress kurulumunun saldırı yüzeyini daraltmak için giriş güvenliğinden dosya izinlerine, sunucu yapılandırmasından eklenti yönetimine kadar birden fazla katmanda alınan somut önlemler bütünüdür. Tek bir eklenti kurmak “güvenlik” için yeterli değildir; gerçek koruma, birden fazla katmanın bir arada çalışmasıyla sağlanır. Bu rehberde, paylaşımlı hostingten yönetilen sunuculara kadar farklı ortamlarda uygulanabilecek adımları sırasıyla ele alıyoruz.
WordPress Güvenlik Sertleştirme Neden Gerekli?
WordPress, dünya genelinde milyonlarca sitede kullanıldığı için otomatik tarama botlarının en sık hedef aldığı platformlardan biri. Bu botlar genellikle belirli bir siteyi değil, güncel olmayan bir eklenti veya zayıf bir giriş ekranı arayarak binlerce siteyi topluca tarar. Pratikte karşılaşılan sızıntıların büyük bölümü, gelişmiş bir saldırı tekniğinden değil; güncellenmemiş bir bileşenden, zayıf bir parola tekrarından veya yanlış dosya izninden kaynaklanır. Bu nedenle sertleştirme adımlarının çoğu, karmaşık değil, düzenli ve sistematik uygulanması gereken temel kontrollerdir.
Temel WordPress Güvenlik Sertleştirme Adımları
Giriş ve Kimlik Doğrulama Güvenliği
Güvenliğin ilk katmanı, kimlik doğrulama sürecidir. Varsayılan “admin” kullanıcı adının kullanılmaması, güçlü ve benzersiz parolaların tercih edilmesi ve mümkünse iki faktörlü kimlik doğrulamanın (2FA) etkinleştirilmesi bu aşamanın temelini oluşturur. Giriş denemelerini sınırlamak (rate limiting), kaba kuvvet saldırılarına karşı en etkili önlemlerden biridir.
wp-config.php dosyasında güvenlik anahtarlarının (security keys) güncel ve rastgele tutulması da önemlidir. WordPress.org’un resmi anahtar üretici servisinden alınan değerler dosyaya şu şekilde eklenir:
define('AUTH_KEY', 'rastgele-uretilmis-uzun-deger');
define('SECURE_AUTH_KEY', 'rastgele-uretilmis-uzun-deger');
define('LOGGED_IN_KEY', 'rastgele-uretilmis-uzun-deger');
define('NONCE_KEY', 'rastgele-uretilmis-uzun-deger');
define('AUTH_SALT', 'rastgele-uretilmis-uzun-deger');
define('SECURE_AUTH_SALT', 'rastgele-uretilmis-uzun-deger');
define('LOGGED_IN_SALT', 'rastgele-uretilmis-uzun-deger');
define('NONCE_SALT', 'rastgele-uretilmis-uzun-deger');
// Tema/eklenti dosya düzenleyicisini kapat
define('DISALLOW_FILE_EDIT', true);DISALLOW_FILE_EDIT sabiti, yönetim panelindeki dosya düzenleyiciyi devre dışı bırakır; bu sayede bir saldırgan yönetici paneline sızsa bile bu editör üzerinden dosya düzenleyemez; eklenti yükleme veya başka yetkiler ayrıca kısıtlanmalıdır.
Dosya ve Dizin İzinleri
Yanlış dosya izinleri, sertleştirme sürecinde en çok atlanan konulardan biridir. Genel kural olarak dizinlere daha esnek, dosyalara daha kısıtlı izin verilmesi önerilir.
| Öğe | Önerilen İzin |
|---|---|
| Dizinler | 755 |
| Dosyalar | 644 |
| wp-config.php | 440 veya 400 (hosting destekliyorsa) |
| .htaccess | 644 |
Paylaşımlı hosting ortamında bu izinler bazen hosting sağlayıcının varsayılan yapılandırmasıyla sınırlı olabilir; bu durumda hosting kontrol panelindeki dosya yöneticisi veya destek ekibiyle iletişime geçmek gerekebilir.
Sunucu Seviyesinde Sertleştirme
.htaccess ile Ekstra Koruma
Apache tabanlı bir hosting kullanıyorsanız, .htaccess dosyasına eklenecek birkaç kural, wp-config.php gibi kritik dosyalara doğrudan erişimi engelleyebilir:
# wp-config.php dosyasına dogrudan erisimi engelle
<files wp-config.php>
Require all denied
</files>
# xmlrpc.php uzerinden gelen kotuye kullanimi sinirla
<files xmlrpc.php>
Require all denied
</files>xmlrpc.php dosyası, genellikle kaba kuvvet saldırılarında ve pingback tabanlı DDoS saldırılarında kötüye kullanılır. Bu özelliğe gerçekten ihtiyacınız yoksa (örneğin mobil uygulama veya harici entegrasyon kullanmıyorsanız) tamamen devre dışı bırakmak, saldırı yüzeyini önemli ölçüde daraltır.
Eklenti ve Tema Güvenliği
Sertleştirme sürecinin en kritik ama en çok ihmal edilen kısmı, eklenti ve tema yönetimidir. Pratikte incelenen güvenlik ihlallerinin büyük kısmı, güncel olmayan veya artık desteklenmeyen eklentilerden kaynaklanır.
- Kullanılmayan eklenti ve temaları etkinleştirmek yerine tamamen silin; devre dışı bırakmak dosyaları sunucuda bırakır ve risk oluşturmaya devam eder.
- Eklentileri yalnızca resmi WordPress dizininden veya güvenilir, aktif olarak desteklenen kaynaklardan indirin.
- Güncellemeleri düzenli takip edin; kritik güvenlik yamaları genellikle güncelleme notlarında açıkça belirtilir.
- Kod düzenleyici veya dosya yükleme özelliği sunan eklentileri gerçekten ihtiyaç yoksa kullanmayın.
Güvenlik Duvarı, İzleme ve Yedekleme
Uygulama seviyesindeki bir güvenlik duvarı (WAF), kötü amaçlı istekleri WordPress’e ulaşmadan önce filtreleyerek ek bir koruma katmanı sağlar. Bunun yanında dosya bütünlüğü izleme (beklenmeyen dosya değişikliklerini tespit etme) ve düzenli, site dışında saklanan yedekleme, bir ihlal durumunda hızlı geri dönüş için kritik önem taşır. Search Console’da “Güvenlik Sorunları” bölümünü periyodik olarak kontrol etmek, Google’ın sitenizde tespit ettiği kötü amaçlı yazılım veya kimlik avı uyarılarını erken fark etmenizi sağlar.
WordPress Güvenlik Sertleştirme Kontrol Listesi
- Yönetici kullanıcı adının “admin” olmadığından ve güçlü bir parola kullanıldığından emin olun.
- Mümkünse iki faktörlü kimlik doğrulamayı etkinleştirin.
- wp-config.php güvenlik anahtarlarını güncelleyin ve DISALLOW_FILE_EDIT sabitini tanımlayın.
- Dosya ve dizin izinlerini önerilen değerlere göre kontrol edin.
- Kullanılmayan eklenti ve temaları tamamen silin.
- xmlrpc.php’ye ihtiyacınız yoksa erişimi kısıtlayın.
- Bir güvenlik duvarı ve dosya bütünlüğü izleme çözümü kurun.
- Site dışında saklanan düzenli yedekleme rutini oluşturun.
WooCommerce ve Çok Kullanıcılı Sitelerde Ek Önlemler
WooCommerce gibi ödeme ve kullanıcı verisi işleyen eklentiler çalıştıran sitelerde sertleştirme adımlarının kapsamı biraz daha genişler. Ödeme sayfalarında ve hesap oluşturma formlarında SSL/TLS sertifikasının güncel ve doğru yapılandırılmış olması, yalnızca kullanıcı güveni için değil, kart verisi güvenliği standartları açısından da önemlidir. Çok yazarlı veya çok kullanıcılı bir site işletiyorsanız, her kullanıcıya ihtiyacı kadar yetki vermek (en az ayrıcalık ilkesi) de kritik bir sertleştirme adımıdır; örneğin içerik yazarlarına yönetici değil, “Yazar” veya “Katkıda Bulunan” rolü tanımlamak, bir hesabın ele geçirilmesi durumunda oluşabilecek hasarı sınırlar.
Üyelik veya yorum formu bulunan sitelerde CAPTCHA veya benzeri bir bot filtreleme mekanizması eklemek, hem spam hem de otomatik saldırı denemelerini azaltır. Ayrıca REST API üzerinden kullanıcı adı sızıntısına yol açabilecek varsayılan uç noktaların (endpoint) kısıtlanması da, özellikle çok kullanıcılı sitelerde göz ardı edilmemesi gereken bir detaydır.
Yaygın Hatalar
Sertleştirme sürecinde en sık görülen hatalardan biri, tek bir güvenlik eklentisi kurup sürecin tamamlandığını varsaymaktır; oysa eklentiler yalnızca bir katmandır ve sunucu, dosya izinleri ile güncelleme disiplini gibi diğer katmanlar olmadan tam koruma sağlamaz. Bir diğer yaygın hata, güvenlik anahtarlarını bir kez oluşturup bir daha hiç güncellememektir; özellikle şüpheli bir aktivite fark edildiğinde bu anahtarların yenilenmesi önerilir. Ayrıca yedeklemenin sadece hosting sağlayıcısının otomatik yedeklemesine bırakılması da risklidir; site dışında, bağımsız bir konumda tutulan ek bir yedek her zaman gereklidir.
WordPress performansını da etkileyen konfigürasyon hataları hakkında daha fazla bilgi için Core Web Vitals ve WordPress’te INP düzeltme rehberimize göz atabilirsiniz. Sertleştirme adımlarının tam ve güncel listesi için WordPress’in resmi Hardening WordPress dokümantasyonuna da başvurabilirsiniz.
Sık Sorulan Sorular
WordPress güvenlik sertleştirme tek bir eklentiyle yapılabilir mi?
Hayır. Bir güvenlik eklentisi faydalı bir katman olsa da, dosya izinleri, güncelleme disiplini ve sunucu yapılandırması gibi diğer önlemler olmadan tam koruma sağlamaz.
Paylaşımlı hostingte sertleştirme adımlarının hepsi uygulanabilir mi?
Çoğu adım uygulanabilir, ancak dosya izinleri ve sunucu seviyesi ayarlar gibi bazı konular hosting sağlayıcının sunduğu kontrol düzeyine bağlı olarak sınırlı kalabilir.
xmlrpc.php’yi tamamen kapatmak site işlevselliğini bozar mı?
Mobil uygulama veya harici entegrasyonlar bu özelliği kullanmıyorsa genellikle bozmaz; ancak kapatmadan önce sitenizin kullandığı eklenti ve entegrasyonları kontrol etmeniz önerilir.
Güvenlik anahtarlarını ne sıklıkla yenilemek gerekir?
Sabit bir kural olmasa da, şüpheli bir aktivite fark edildiğinde veya düzenli aralıklarla (örneğin yılda bir) yenilenmesi genel bir iyi uygulama olarak kabul edilir.
Sertleştirme yapılan bir site tamamen güvenli olur mu?
Hayır. Sertleştirme, olası saldırı yüzeyini önemli ölçüde daraltır ve riski azaltır; ancak hiçbir önlem seti mutlak bir koruma sunmaz, bu yüzden izleme ve güncelleme süreci sürekli olmalıdır.
Bu yazı, WordPress Hata Çözümleri ve Bakım Rehberi başlıklı merkez rehberin bir parçası. Sorunun kaynağını daraltamadıysanız oradaki belirti tablosundan başlamak daha hızlı sonuç verir.
Kaynaklar ve İleri Okuma
Resmî dokümantasyon
Sitedeki ilgili rehberler
- WordPress Hız Optimizasyonu Nasıl Yapılır?
- WordPress Mail Gönderme Sorunu Nasıl Çözülür?
- WordPress Memory Limit Hatası Nasıl Çözülür?
Örnek Require all denied Apache 2.4 sözdizimidir; Nginx .htaccess okumaz. Dosya izinleri owner/group ve PHP’nin çalıştığı kullanıcıya bağlıdır; 400/440 dosyayı uygulamanın okuyamadığı durumda siteyi bozar. Rastgele sabit metinleri gerçek key/salt olarak kullanmayın. Salt yenilemek oturumları sonlandırır, parolaları ve uygulama parolalarını değiştirmez. Sabit yıllık yenileme yama veya olay incelemesi yerine geçmez. REST API’yi topluca kapatmak editör/entegrasyonları bozabilir; kimliği açık kullanıcı adını sır koruması sanmayın.
