Çoğu Saldırıyı Durduran WordPress Güvenlik Temelleri
Compromised bir WordPress sitesini temizlerken, sebep neredeyse hiçbir zaman sofistike, targeted bir saldırı oluyor. Aylar önce patch'lenmiş, bilinen bir vulnerability'si olan outdated bir plugin, başka bir leak'te ortaya çıkmış bir password'e sahip bir wp-admin login'i, ya da site launch edildiğinden beri dokunulmamış ve kimsenin bakmadığı bir file upload vulnerability'sine sahip eski bir theme. WordPress'in popülerliği, automated scanner'ların sürekli tam olarak bunları aradığı anlamına geliyor, ve aşağıdaki temeller bu kapıyı kapatıyor.
Update'ler: en büyük tek faktör
Çoğu WordPress compromise'ı, basitçe update edilmemiş, public olarak bilinen bir vulnerability'si olan bir plugin ya da theme'e kadar izleniyor. WordPress core, security update'leri varsayılan olarak otomatik handle ediyor, ama plugin'ler ve theme'ler configure edilmedikçe etmiyor:
// wp-config.php
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');
Bir plugin update'inin bir şeyi bozmasının, update etmemenin security riskinden daha büyük bir kaygı olduğu siteler için, önce update'leri alan bir staging environment, production'ın birkaç gün sonra takip etmesiyle, mantıklı bir orta yol. Mantıklı olmayan şey ise "zamanımız olunca update ederiz" çünkü automated scanner'ların aradığı pencere tam da bu.
Kullanılmayanı kaldırın
Her inactive plugin ve theme, server'da oturan koddur, ve "inactive" "exploit edilemez" anlamına gelmiyor, deactivated bir plugin'in dosyalarındaki bir vulnerability, dosyanın kendisi accessible'sa genelde hâlâ direkt erişilebilir oluyor. Fix, deactivate etmek değil, silmek:
wp plugin list --status=inactive
wp plugin delete <plugin-name>
Sonra tekrar ihtiyaç olursa, otuz saniyede yeniden install edilebilir. Disk'te kullanılmadan oturmak, hiçbir fayda olmadan saf attack surface.
Login security: çoğu automated saldırının indiği yer
/wp-login.php ve /xmlrpc.php, site ne kadar obscure olursa olsun, sürekli automated login attempt'leri tarafından vuruluyor. Birkaç değişiklik bunun çoğunu çözüyor:
Her publish ya da admin access'i olan account için strong, unique password'ler ve 2FA, sadece main admin account için değil, weak password'lü bir contributor account'u da hâlâ bir foothold.
Login attempt'lerini limitlemek, ya bir plugin üzerinden ya da server seviyesinde, wp-login.php'e karşı tekrarlanan failed login'leri izleyen bir Fail2ban jail'i ile:
# /etc/fail2ban/jail.local
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 3600
XML-RPC'yi disable etmek, eğer hiçbir şey (hiçbir app, hiçbir Jetpack-tarzı entegrasyon) onu gerçekten kullanmıyorsa, çünkü bu hem brute-force attempt'leri hem de pingback-based saldırılarda amplification için yaygın bir target, ve çoğu sitenin bunun için legitimate bir kullanımı yok.
Admin alanını kilitlemek
DISALLOW_FILE_EDIT, WordPress admin'inden built-in theme ve plugin file editor'ünü kaldırıyor, admin access'i olan herkesin PHP dosyalarını browser üzerinden direkt edit etmesine izin veren editor. Bir admin account hiç compromise olursa, bu, compromise'ın arbitrary code execution'a dönüşmesinin bir yolu daha az demek:
// wp-config.php
define('DISALLOW_FILE_EDIT', true);
File permission'lar da önemli, WordPress'in kendi önerisi olan dosyalar için 644 ve directory'ler için 755, wp-config.php 600'de, bir vulnerability filesystem'e write etmeye izin verse bile, bunun web server'ın user'ının gerçekte dokunmasına izin verilen şeyle sınırlı olduğu anlamına geliyor.
Bir web application firewall henüz patch'lenmemiş olanı yakalıyor
Update'ler, bir patch var olduğunda bilinen vulnerability'leri handle ediyor. Bir vulnerability'nin keşfedilmesi ile bir patch'in release edilmesi arasındaki boşluk, ve bir patch'in release edilmesi ile her sitenin onu gerçekten apply etmesi arasındaki boşluk, bir web application firewall'ın yerini kazandığı yer. OWASP Core Rule Set'li ModSecurity, ya da plugin-based bir WAF, hangi spesifik plugin'i target ettiklerinden bağımsız olarak birçok generic exploit pattern'ini (SQL injection attempt'leri, path traversal, yaygın payload signature'ları) bloklayıyor, bu da henüz kimsenin spesifik bir rule yazmadığı vulnerability'lere karşı bile kullanışlı olduğu anlamına geliyor.
Bu temeller neden hâlâ cevap
Bunların hiçbiri advanced değil, ve asıl nokta da bu. WordPress compromise'larının büyük çoğunluğu zero-day değil, login security'nin an afterthought olduğu sitelerde, basitçe apply edilmemiş, available fix'leri olan bilinen sorunlar. Update'ler, kullanılmayan kodu kaldırmak, login hardening, ve bir WAF, automated saldırıların gerçekte target ettiği kategorileri, her birinin gerçek sebep olma sıklığına kabaca göre, ele alıyor. Bunları doğru yapmak bir siteyi invulnerable yapmıyor, ama onu automated scanner'ların hiçbir gerçek effort olmadan compromise ettiği enormous pool'dan çıkarıyor.