Uygulamaya dönük WordPress güvenlik kontrol listesi

Bir WordPress sitesi, en zayıf eklentisi, hesabı ya da yedeği kadar güçlüdür. WordPress çekirdeği düzenli olarak güvenlik güncellemeleri alır; ona ne eklediğiniz ve siteyi nasıl işlettiğiniz ise size kalmıştır. Bu kontrol listesi en önemli önlemleri, aşağı yukarı bizim uygulayacağımız sırayla ele alır.

1. Çekirdeği, eklentileri ve temaları güncel tutun

Çekirdek için arka planda otomatik güncellemeler WordPress 3.7’den beri vardır ve varsayılan olarak küçük sürümleri kapsar. WordPress 5.5’ten beri her eklenti ve tema için otomatik güncellemeyi yönetim ekranlarından da açabilirsiniz.

• Saygın geliştiricilerin eklentileri için otomatik güncellemeyi açın, diğerlerini her hafta gözden geçirin.
• Otomatik güncellemeler WP-Cron’a dayanır. Araçlar > Site sağlığı (Tools > Site Health) ekranında hata olup olmadığına bakın, çünkü bozuk bir cron güncellemelerin sessizce durması demektir.
• Otomatik güncellemelere güvenmeden önce geri dönebildiğinizden emin olun. WordPress belgeleri de bunu önerir.

2. Terk edilmiş ve kullanılmayan eklentileri kaldırın

WordPress sıkılaştırma kılavuzu bu konuda açıktır: eklentileri güncel tutun ve kullanmadıklarınızı silin. Devre dışı bırakmak yeterli değildir, çünkü kod sunucuda kalır.

WordPress.org eklenti dizini size iki uyarı işareti verir:

• Bir eklentinin “WordPress’in son 3 ana sürümüyle test edilmediğini” belirten sarı bir uyarı.
• Bir eklentinin kapatıldığını ve artık indirilemediğini belirten kırmızı bir uyarı. 60 gün sonra kapatılma nedeni gösterilir; listelenen nedenlerden biri de “güvenlik sorunu”dur.

Kapatılmış bir eklenti WordPress.org üzerinden güncelleme almaz. Onu başka bir eklentiyle değiştirin. Ücretli eklentilerin “nulled” (lisans koruması kırılmış) kopyalarını asla kurmayın; eklentileri yalnızca WordPress.org’dan ya da güvendiğiniz üreticilerden kurun.

3. Yönetici hesaplarını denetleyin

Yönetici (Administrator) rolüne sahip tüm hesapları listeleyin ve kimsenin açıklayamadığı hesapları kaldırın. WP-CLI ile:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Herkese kendi adını taşıyan ayrı bir hesap verin; asla ortak bir admin hesabı kullanmayın. İşi görecek en düşük rolü kullanın: içerik editörlerinin çoğunun Yönetici rolüne ihtiyacı yoktur. Güçlü ve benzersiz parolalar isteyin; parolalar tercihen bir parola yöneticisinde saklansın.

4. İki faktörlü kimlik doğrulamayı açın

Her yönetici için 2FA’yı açın. WordPress çekirdeği 2FA içermez; bu yüzden 2FA’yı zorunlu tutan bir eklentiye ya da tek oturum açma (SSO) sağlayıcısına ihtiyacınız vardır. Eklentiniz destekliyorsa güvenlik anahtarları ya da geçiş anahtarları gibi yöntemleri tercih edin ve kurtarma kodlarını güvenli bir yerde saklayın.

5. Oturum açma denemelerini sınırlayın ve XML-RPC hakkında karar verin

WordPress belgeleri, wp-login.php ve xmlrpc.php dosyalarını kaba kuvvet saldırılarının yaygın hedefleri olarak tanımlar. Oturum açma denemelerinin uçta (bir WAF ya da CDN üzerinde) veya web sunucusunda sınırlanmasını önerir. Bir güvenlik eklentisi de oturum açma denemelerini yavaşlatabilir, ancak PHP içinde çalıştığı için yoğun trafik altında sunucu düzeyindeki çözüm daha dayanıklıdır.

XML-RPC kullanmıyorsanız kapatın. Bazı mobil uygulamalar ve Jetpack gibi servisler buna ihtiyaç duyar; önce kontrol edin. xmlrpc_enabled filtresinin yalnızca kimlik doğrulaması gerektiren yöntemleri devre dışı bıraktığını unutmayın. Pingback’ler ve kimlik doğrulaması gerektirmeyen diğer yöntemler çalışmaya devam eder. Tamamen kapatmak için dosyayı web sunucusunda engelleyin. nginx için:

location = /xmlrpc.php {
    deny all;
}

6. Yerleşik dosya düzenleyiciyi kapatın

Yönetim panelindeki tema ve eklenti düzenleyicisi, yönetici oturumu olan herkesin PHP kodunu değiştirmesine olanak tanır. Bunu wp-config.php içinde devre dışı bırakın:

define( 'DISALLOW_FILE_EDIT', true );

wp-config.php belgelerine göre DISALLOW_FILE_MODS bir adım daha ileri gider ve yönetim panelinden eklenti ve tema kurulumunu ve güncellemesini de engeller. Bunu yalnızca değişiklikleri Git ya da WP-CLI gibi başka bir yolla dağıtıyorsanız kullanın.

7. Yedekleri sunucunun ve web kök dizininin dışında tutun

Sıkılaştırma kılavuzu hem dosyaların hem de veritabanının düzenli olarak yedeklenmesini, birden fazla anlık görüntü (snapshot) tutulmasını ve güvenilir bir depolama yeri kullanılmasını önerir. Yedeklerin bütünlüğünü şifrelemeyle, kayda geçirilmiş hash değerleriyle ya da salt okunur ortamlarla koruyun.

Buradan iki pratik kural çıkar. Web kök dizini içindeki bir yedek, örneğin wp-content içindeki bir zip dosyası, adını tahmin eden herkes tarafından indirilebilir. Aynı sunucudaki bir yedek de aynı saldırgan tarafından silinebilir. En az bir kopyayı sitenin kimlik bilgilerinin ulaşamayacağı bir yerde tutun ve tam bir geri yüklemeyi test edin.

8. Dosya bütünlüğünü kontrol edin

WP-CLI, WordPress’i yüklemeden dosyalarınızı WordPress.org’un resmî sağlama değerleriyle karşılaştırabilir:

wp core verify-checksums --include-root
wp plugin verify-checksums --all

İlk komut değiştirilmiş çekirdek dosyalarını işaretler; --include-root de kök dizindeki beklenmeyen dosyalar hakkında uyarır. İkinci komut eklentileri WordPress.org sağlama değerleriyle karşılaştırır; bu yüzden yalnızca orada barındırılan eklentiler için işe yarar. Normalde yalnızca medya dosyaları içermesi gereken wp-content/uploads klasöründe PHP dosyası olup olmadığına da bakın.

9. En az yetkili bir veritabanı kullanıcısı kullanın

Her siteye kendi veritabanını ve yalnızca o veritabanında yetkisi olan kendi veritabanı kullanıcısını verin. Asla veritabanının root kullanıcısıyla bağlanmayın.

Sıkılaştırma kılavuzu, günlük işleyiş için yalnızca SELECT, INSERT, UPDATE ve DELETE yetkilerinin gerektiğini belirtir. Eklentiler ve büyük güncellemeler şemayı değiştirmek zorunda kalabileceği için DROP, ALTER ve GRANT yetkilerinin geri alınmasını önermez. Yine de kaldırırsanız test edilmiş yedekleriniz olsun.

10. Dosya izinlerini ayarlayın

Kılavuzun başlangıç noktası dizinler için 755, dosyalar için 644’tür. Çekirdek dosyalar, wp-admin ve wp-includes web sunucusu tarafından değil, yalnızca sizin kullanıcı hesabınız tarafından yazılabilir olmalıdır. İstisna wp-content’tir: web sunucusunun yüklemeler için buraya yazabilmesi gerekir. Kılavuz wp-config.php için 400 ya da 440 önerir.

find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.php

Bu komutları çalıştırmadan önce yolları ve dosya sahipliğini barındırma düzeninize göre ayarlayın.

11. Güvenlik başlıkları gönderin

Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options ve Referrer-Policy gibi başlıklar tarayıcı tarafında koruma ekler. Mümkünse bunları bir eklenti yerine web sunucusunda ya da CDN’de ayarlayın. Temalar ve sayfa oluşturucular satır içi betiklere dayanabileceği için yalnızca raporlama modundaki bir Content Security Policy ile başlayın.

12. Önüne bir WAF koyun

WordPress belgeleri üç düzey tanımlar: istekleri WordPress içinde süzen güvenlik eklentileri, ModSecurity gibi sunucu düzeyinde bir güvenlik duvarı ve trafiği sunucunuza ulaşmadan önce süzen ters vekil sunucu (reverse proxy) servisleri. Süzme ne kadar dışarıda yapılırsa PHP’ye o kadar az yük ulaşır. WAF güncellemelerin yerini tutmaz; bir açığın duyurulmasıyla sizin yamanız arasında zaman kazandırır.

Kısa özet

Nereden başlamalı

İlk dört maddeyle başlayın. Az zaman alırlar ve barındırma düzeninizde değişiklik gerektirmezler. Ardından mevcut başlıklarınızı güvenlik başlıkları taramamızla kontrol edin.

Bu kontrollerin sizin için yapılmasını istiyorsanız SecAudit, WordPress sitelerini zararlı yazılım ve web shell’ler için tarar, dosya bütünlüğünü resmî sağlama değerlerine göre doğrular ve kurulu eklentileri bilinen güvenlik açıklarıyla eşleştirir.