Çoğu Saldırıyı Durduran WordPress Güvenlik Temelleri
Reklam
Ele geçirilmiş bir WordPress sitesini temizlediğimde, temel neden (root cause) neredeyse hiçbir zaman son derece sofistike, hedefe yönelik (targeted) bir saldırı çıkmaz. Bu genellikle, aylar önce herkesin görebileceği şekilde yamalanmış, yaygın olarak bilinen bir güvenlik açığına (vulnerability) sahip eski bir eklentiden ibarettir. Tamamen alakasız bir sızıntıda ele geçirilmiş zayıf bir parolaya sahip bir wp-admin girişidir. Ya da site açıldığından beri kesinlikle dokunulmamış, o zamandan beri kimsenin yüzüne bakmadığı bir dosya yükleme açığı taşıyan eski bir temadır.
WordPress'in devasa popülaritesi, otomatik tarayıcıların (scanners) tam olarak bu şeyler için tüm interneti sürekli ve acımasızca yokladığı (probing) anlamına gelir. Aşağıdaki tamamen ihtişamsız temeller, o kapıyı gerçekten kapatan yegane şeylerdir.
Güncellemeler: Açık ara en büyük faktör
WordPress ihlallerinin ezici çoğunluğu, doğrudan güncellenmemiş ve açıkça bilinen bir güvenlik açığı olan bir eklentiye veya temaya dayanır. WordPress çekirdeği (core) kendi küçük güvenlik güncellemelerini varsayılan olarak otomatik halleder, ancak özellikle aksi belirtilmedikçe eklentiler ve temalar kesinlikle bunu yapmaz:
// wp-config.php
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');
Bir eklenti güncellemesinin bir şeyleri bozma ihtimalinin, güncellememe yapmamanın getireceği o acımasız güvenlik riskinden gerçekten daha büyük bir endişe kaynağı olduğu kritik sitelerde; güncellemeleri önce alan bir test (staging) ortamı kurmak (ve üretim/production ortamının birkaç gün sonra onu takip etmesi) son derece mantıklı bir orta yoldur.
Kesinlikle mantıklı olmayan şey ise "vakit bulunca güncelleriz" demektir. Çünkü sizin "vakit bulacağınız o an", otomatik tarayıcıların umutsuzca aradığı o açık pencerenin tam kendisidir.
Aktif olarak kullanılmayan şeyleri silin
Her bir pasif (inactive) eklenti ve tema, sunucuda öylece duran fiziksel kodlardan ibarettir. Ve "pasif", kesinlikle "sömürülemez" (not exploitable) anlamına gelmez. Devre dışı bırakılmış bir eklentinin dosyalarındaki bir güvenlik açığına, eğer dosyanın kendisine web üzerinden açıkça erişilebiliyorsa, çoğu zaman doğrudan ulaşılabilir.
Bunun çözümü onları devre dışı bırakmak değildir. Çözüm, onları agresif bir şekilde silmektir:
wp plugin list --status=inactive
wp plugin delete <plugin-name>
Daha sonra gerçekten tekrar ihtiyaç duyulursa, otuz saniye içinde yeniden yüklenebilirler. Diskte tamamen kullanılmadan durmaları, kesinlikle sıfır fayda sağlayan, saf ve katıksız bir saldırı yüzeyinden (attack surface) başka bir şey değildir.
Giriş (Login) güvenliği: Çoğu otomatik saldırının şiddetle düştüğü yer
/wp-login.php ve /xmlrpc.php, sitenin ne kadar belirsiz veya küçük olduğuna kesinlikle bakılmaksızın, sürekli olarak otomatik giriş denemeleri tarafından agresif bir şekilde vurulur. Birkaç temel değişiklik bunların neredeyse tamamını çözer:
Güçlü, tamamen benzersiz parolalar ve 2FA, yayın yapma (publish) veya yönetici (admin) erişimi olan istisnasız her bir hesap için zorunlu olmalıdır. Bu sadece ana admin hesabı anlamına gelmez. Zayıf parolalı, unutulmuş bir içerik sağlayıcı (contributor) hesabı, sisteme girmek için hala çok geçerli bir basamaktır.
Giriş denemelerini sınırlamak (Limiting login attempts), ya sağlam bir eklenti (plugin) aracılığıyla ya da çok daha iyisi, wp-login.php'ye karşı tekrarlanan başarısız girişleri aktif olarak izleyen bir Fail2ban jail'i kullanarak sunucu seviyesinde yapılmalıdır:
# /etc/fail2ban/jail.local
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 3600
Eğer kesinlikle hiçbir şey (özel bir uygulama, Jetpack tarzı entegrasyonlar vb.) kullanmıyorsa, XML-RPC'yi tamamen devre dışı bırakmak şarttır. Doğrudan kaba kuvvet (brute-force) girişimleri ve pingback tabanlı saldırılardaki o agresif büyüme (amplification) için devasa ve çok yaygın bir hedeftir ve günümüzde çoğu sitenin onu kullanmak için kesinlikle hiçbir meşru (legitimate) nedeni yoktur.
Yönetici (Admin) alanını kilitlemek
DISALLOW_FILE_EDIT, WordPress yönetici panelindeki (dashboard) yerleşik (built-in) tema ve eklenti dosyası düzenleyicisini acımasızca kaldırır. Bu, admin erişimine sahip herhangi birinin ham (raw) PHP dosyalarını doğrudan web tarayıcısı üzerinden düzenlemesine olanak tanıyan o korkutucu düzenleyicidir. Eğer bir admin hesabı ele geçirilirse, bu durum o ele geçirmenin anında "rastgele kod yürütme"ye (arbitrary code execution) dönüşmesinin en kolay yollarından birini kesin olarak keser:
// wp-config.php
define('DISALLOW_FILE_EDIT', true);
Dosya izinleri (file permissions) de devasa derecede önemlidir. WordPress'in dosyalar için 644, dizinler için 755 (ve wp-config.php için agresif bir şekilde 600) şeklindeki kendi katı önerisi; ciddi bir güvenlik açığı dosya sistemine yazmaya izin verse bile, bunun web sunucusunun Linux kullanıcısının gerçekten dokunmasına izin verilen şeylerle sıkı bir şekilde kısıtlanması (constrained) anlamına gelir.
Bir Web Application Firewall henüz yamalanmamış olanları yakalar
Güncellemeler (updates), bir yama (patch) çıktıktan sonra bilinen açıkları (vulnerabilities) mükemmel bir şekilde halleder. Ancak bir açığın keşfedilmesi ile bir yamanın yayınlanması arasındaki boşluk—ve bir yamanın yayınlanması ile istisnasız her bir sitenin onu gerçekten uygulaması arasındaki o daha da geniş boşluk—tam olarak bir web uygulaması güvenlik duvarının (WAF) parasını hak ettiği yerdir.
OWASP Core Rule Set ile ModSecurity veya son derece sağlam eklenti tabanlı bir WAF, tam olarak hangi spesifik eklentiyi umutsuzca hedeflediklerine kesinlikle bakılmaksızın devasa miktarda jenerik sömürü örüntüsünü (SQL injection denemeleri, path traversal, yaygın payload imzaları) agresif bir şekilde engeller. Bu, henüz kimsenin özel bir kural (rule) yazmadığı sıfırıncı gün (zero-day) açıklarına karşı bile inanılmaz derecede faydalı olduğu anlamına gelir.
Bu sıkıcı temeller neden hala asıl çözümdür?
Bunların kesinlikle hiçbiri ileri düzey (advanced) şeyler değildir ve asıl mesele de tam olarak budur. WordPress ihlallerinin ezici ve kahredici çoğunluğu egzotik sıfırıncı gün (zero-day) açıkları değildir. Bunlar, temel giriş güvenliğinin (login security) sonradan akla geldiği sitelerde, düzeltmeleri hazırda bulunan ancak basitçe uygulanmamış çok bilinen sorunlardır.
Agresif güncellemeler, kullanılmayan kodların acımasızca silinmesi, girişlerin (logins) sıkıca kilitlenmesi ve bir WAF çalıştırmak; otomatik saldırıların gerçekten hedeflediği o spesifik kategorileri, her birinin asıl temel neden (root cause) olma sıklığına tam olarak uygun bir sırayla kusursuz bir şekilde çözer. Bunları tamamen doğru yapmak bir siteyi sihirli bir şekilde yenilmez (invulnerable) yapmaz, ancak onu otomatik tarayıcıların (scanners) hiçbir gerçek çaba sarf etmeden zahmetsizce ele geçirdiği o devasa, kolay lokma (low-hanging) site havuzundan agresif bir şekilde çıkarır.
Reklam