WordPress Güvenliği: Sitenizi Saldırılara Karşı Koruyan Önlemler

WordPress güvenliği, tek bir eklentiyle kurulan bir duvar değil; güncelleme, erişim, dosya ve sunucu katmanlarında alınan küçük önlemlerin toplamıdır. WordPress çekirdeği düzenli olarak denetlenir ve açıkları hızla yamalanır; ele geçirilen sitelerde kapı çoğu zaman güncellenmemiş bir eklenti, tahmin edilebilir ya da başka bir sızıntıda ele geçmiş bir şifre veya kaynağı belirsiz bir temadır.

Aşağıdaki önlemlerin bir kısmı WordPress içinde, bir kısmı sunucu tarafında uygulanır; LIONFIN WordPress hosting hesabınızda hangi sunucu korumalarının etkin olduğunu panelden ya da destek talebiyle öğrenebilirsiniz. Önlemler etkisine göre sıralanmıştır: listenin başındakiler en az emekle en çok riski kapatır.

WordPress sitelerini hangi tehditler hedef alır?

WordPress güvenliğini tehdit eden saldırıların çoğu otomatiktir: botlar çok sayıda siteyi aynı anda tarar, bilinen bir açığı ya da zayıf bir şifreyi bulduğu siteye girer. Tehditleri ve karşılık gelen önlemleri yan yana görmek önceliği belirlemeyi kolaylaştırır:

Güncellemeler neden en önemli WordPress güvenliği önlemidir?

Güncellemeler, açığı herkesçe bilinen kodu sitenizden kaldırdığı için en yüksek getirili önlemdir; bir açık duyurulduktan sonra botların onu taramaya başlaması uzun sürmez. WordPress çekirdeğinin küçük bakım ve güvenlik sürümleri varsayılan olarak kendiliğinden kurulur; büyük sürümler, eklentiler ve temalar ise ayarınıza bağlıdır. WordPress 5.5’ten bu yana Eklentiler ve Görünüm → Temalar ekranlarında her bileşen için otomatik güncellemeyi ayrı ayrı açabilirsiniz.

• Kullanılmayanları silin: Devre dışı bir eklentinin dosyaları sunucuda durduğu sürece içindeki açık çoğu zaman erişilebilir kalır. Yedek olarak yalnızca bir varsayılan tema bırakın.
• Terk edilmiş eklentileri değiştirin: Uzun süredir güncelleme almayan ya da resmi dizinden kaldırılan eklentilerin bakımlı bir alternatifini bulun.
• PHP sürümünü güncel tutun: Güvenlik desteği biten PHP sürümleri yama almaz; geçiş planı PHP 8 güncelleme rehberi yazısındadır.

Büyük güncellemeleri önce bir test kopyasında denemek, “güncelleme siteyi bozar” endişesiyle güncellemeleri erteleme alışkanlığını ortadan kaldırır; kurulum WordPress staging ortamı rehberindedir. Bekleyen güncellemeleri SSH’de wp core check-update ve wp plugin list --update=available komutlarıyla da görebilirsiniz.

Nulled tema ve eklentiler neden tehlikelidir?

Nulled tema ve eklentiler, ücretli ürünlerin lisans denetimi kaldırılarak dağıtılan korsan kopyalarıdır ve çoğu zaman içlerine arka kapı, gizli bağlantı ya da reklam kodu eklenmiştir. Dosyayı sitenize yüklediğiniz anda saldırgan, şifrenize ihtiyaç duymadan içeri girecek bir yol kazanır. Bu kopyalar güncelleme de almaz; asıl ürün güvenlik yaması yayımladığında sizin kopyanız açık kalır.

Güvenli kurulum için üç kural yeterlidir:

1. Ücretsiz eklenti ve temaları yalnızca resmi WordPress dizininden, ücretli olanları geliştiricinin kendi sitesinden ya da yetkili satış platformundan alın.
2. Kurmadan önce son güncelleme tarihine, etkin kurulum sayısına ve destek forumundaki yanıtlara bakın.
3. Lisans anahtarını sitede tanımlayın; ücretli ürünlerin güncellemeleri ancak böyle gelir.

Siteniz geçmişte böyle bir paketle kurulduysa onu ele geçirilmiş kabul edin ve temizliği son bölümde bağlantısı verilen müdahale rehberine göre yapın.

Giriş güvenliği nasıl sağlanır: şifre, 2FA ve deneme sınırı

Giriş ekranı, botların en çok zorladığı kapıdır; aşağıdaki dört önlem birlikte uygulandığında kaba kuvvet ve çalıntı şifre saldırıları büyük ölçüde etkisiz kalır:

• Benzersiz ve uzun şifre: Her yönetici için başka hiçbir yerde kullanılmayan, bir şifre yöneticisinde saklanan şifre.
• İki adımlı doğrulama (2FA): Yönetici, editör ve mağaza yöneticisi rollerinde zorunlu tutun. Two Factor gibi eklentiler doğrulama uygulaması ve yedek kodlarla çalışır.
• Giriş denemesi sınırı: Belirli sayıda hatalı denemeden sonra IP adresini geçici olarak engelleyin; bu iş bir güvenlik eklentisiyle ya da sunucu tarafında yapılır. Kendi sunucunuzu yönetiyorsanız Fail2Ban kurulumu rehberi aynı korumayı sunucu düzeyinde kurar.
• admin kullanıcı adından kaçının: Varsa yeni bir yönetici oluşturup içerikleri ona aktarın ve eski hesabı silin. Profildeki herkese açık görünen adı da kullanıcı adından farklı seçin.

Şifresini kaybeden kullanıcılar için güvenli yenileme yolları WordPress şifre sıfırlama rehberinde anlatılır.

wp-config.php ve dosya izinleri nasıl sertleştirilir?

Yönetici hesabı ele geçirilse bile saldırganın panelden kod yazamaması için tema ve eklenti dosya düzenleyicisini kapatın. wp-config.php dosyasına, düzenlemeyi bırakmanızı söyleyen yorum satırının üstüne şunları ekleyin:

define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );

Daha sıkı bir seçenek olan DISALLOW_FILE_MODS panelden eklenti kurmayı ve güncellemeyi de engeller; güncellemeleri WP-CLI ya da bir dağıtım süreciyle yapıyorsanız tercih edilebilir. Dosya izinleri ise şu düzende olmalıdır:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 ~/public_html/wp-config.php

PHP site sahibinin kullanıcısıyla çalışıyorsa (PHP-FPM ya da kullanıcı bazlı LiteSpeed işlemleri gibi) 600 ve 400 sorunsuz çalışır; farklı bir kullanıcıyla çalışıyorsa grup okuması gerekebilir. 400 ya da 440 seçerseniz wp-config.php dosyasına yazmak isteyen önbellek eklentileri ayar kaydedemez. Hiçbir dosya ya da klasör 777 olmamalıdır; yükleme klasöründe PHP çalıştırmayı engelleyen kural web sitesi güvenliği kontrol listesi yazısında hazırdır.

XML-RPC kapatılmalı mı?

XML-RPC’yi kullanan bir hizmetiniz yoksa kapatmanız önerilir. xmlrpc.php dosyası uzaktan yayın ve bazı entegrasyonlar için vardır; saldırganlar ise tek istekte çok sayıda şifre denemeye izin veren yöntemlerini ve pingback özelliğini kötüye kullanır. Jetpack gibi bu uç noktaya bağımlı bir eklenti kullanıyorsanız kapatmayın; giriş sınırlamasına ve WAF kurallarına güvenin.

En kesin yöntem isteği sunucu düzeyinde reddetmektir. Apache ve LiteSpeed’de .htaccess dosyasına şu blok eklenir:

<Files xmlrpc.php>
    Require all denied
</Files>

Nginx’te aynı iş location = /xmlrpc.php { deny all; } satırıyla yapılır. WordPress içindeki xmlrpc_enabled filtresi yalnızca kimlik doğrulaması gerektiren yöntemleri kapatır; pingback gibi diğer yöntemler açık kalabileceği için sunucu kuralı daha güvenilirdir. Kuralı ekledikten sonra siteniz.com/xmlrpc.php adresinin 403 döndürdüğünü doğrulayın.

Sunucu katmanında WAF, HTTPS ve güvenlik başlıkları ne sağlar?

Sunucu katmanı, isteği WordPress’e ulaşmadan süzerek uygulama içindeki önlemleri tamamlar:

• Web uygulama güvenlik duvarı (WAF): ModSecurity kural setleri, Imunify360 gibi sunucu tabanlı çözümler ya da güvenlik eklentilerinin güvenlik duvarları bilinen saldırı kalıplarını engeller. Eklenti tabanlı duvarlar PHP içinde çalıştığından istek sunucuya ulaştıktan sonra devreye girer; sunucu düzeyindeki koruma yükü daha erken keser.
• HTTPS: Tüm trafiği HTTPS’e yönlendirin; yönetim paneli dahil hiçbir oturum çerezi şifresiz bağlantıdan geçmemelidir. Adımlar HTTP’den HTTPS’e yönlendirme rehberinde, kurumsal doğrulamalı sertifika seçenekleri SSL sertifikaları sayfasındadır.
• Güvenlik başlıkları: Tarayıcıya ek kurallar bildiren HTTP başlıkları, tıklama korsanlığı ve içerik türü karışıklığı gibi saldırıları zorlaştırır.

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Strict-Transport-Security başlığını yalnızca site ve kullandığınız tüm adresler HTTPS üzerinden sorunsuz açıldıktan sonra ekleyin; tarayıcılar bu kuralı belirtilen süre boyunca hatırlar.

Kullanıcı rolleri, yedekleme ve izleme nasıl düzenlenmeli?

Son katmanın amacı, bir şey ters gittiğinde hasarı sınırlamak ve durumu hızla fark etmektir:

1. En az yetki: Yönetici rolünü yalnızca site ayarlarını değiştirmesi gerekenlere verin; içerik ekibine Editör, yazarlara Yazar rolü yeter. Ajans ya da eski çalışan hesaplarını iş bitince silin, kullanılmayan uygulama şifrelerini profil ekranından iptal edin.
2. Sunucu dışı yedek: Hostingin yedeğine ek olarak dosya ve veritabanını düzenli aralıklarla başka bir konuma alın ve geri yüklemeyi ara sıra deneyin; strateji 3-2-1 yedekleme kuralı yazısındadır.
3. İzleme: Girişleri ve ayar değişikliklerini kaydeden bir etkinlik günlüğü eklentisi, dosya değişikliği taraması ve dışarıdan çalışan bir erişilebilirlik izlemesi kurun. Erişim günlüklerinde wp-login.php adresine yoğun POST istekleri görmek, giriş korumanızın sınandığını gösterir.
4. Hosting paneli: WordPress ne kadar sağlam olursa olsun panel hesabı ele geçirilirse tüm dosyalar açıkta kalır; müşteri paneli güvenliği adımlarıyla panelde de iki adımlı doğrulamayı açın.

Tüm önlemlere rağmen siteniz ele geçirilirse ilk 24 saatte yapılacaklar web sitesi hacklendi yazısında adım adım sıralanmıştır.