WordPress'i önem sırasına göre sertleştirmek

Gerçek sıra ve çoğu kontrol listesinin sırası neden yanlış

Bir WordPress güvenlik kontrol listesi genelde otuz maddeden oluşur ve hepsi aynı büyüklükte görünür. Pratikte değildirler. İlk üçü kalan yirmi yediden fazlasını önler ve sıra, kimsenin yazmadığı şeydir; çünkü uzun bir liste daha profesyonel görünür.

Bir müşteri sitesinde izlediğimiz sıranın altı adımı var ve kolaylığa göre dizilmemiştir. Her adımın ne kadarını önlediğine göre dizilmiştir.

Önce güncelleme, çünkü bir WordPress sitesine yapılan başarılı girişlerin çoğu kamuya açık ve çoktan yamalanmış bir açıktan gelir. Sonra en az yetki, çünkü hasarın büyüklüğünü, giren hesapların yapmasına izin verilen şeyler belirler. Sonra iki adımlı doğrulama; sızmış bir parolayı felaketten uyarıya çevirir. Sonra bir kez geri yüklediğiniz bir yedek, çünkü sınanmamış bir yedek bir kopya değil bir varsayımdır. Sonra hâlâ bakımı yapılan bir güvenlik eklentisi. Ve en sonda giriş sayfasını sertleştirmek; faydalıdır ve yeri listenin başı değil sonudur.

İlk üç adım tamamen sizin elinizde ve hiçbiri para istemiyor. Dördüncüsü az bir para ister ve en çok huzuru satın alır. Beşinci ve altıncı, insanların genelde önce yaptığı ve altısı içinde en küçük etkiye sahip olanlardır.

Güncellemeler ve bunun neden diğerlerinden fazlasını önlediği

Bir açık yayımlandığında aynı anda iki şey doğar: sorunun tarifi ve yaması. O andan itibaren onu kullanmak isteyen herkes tam olarak nereye nişan alacağını bilir ve güncelleyen herkes listeden çıkar. Bütün oyun, yayım ile güncelleme arasındaki boşluktur.

Bu sitede, Mart 2025'ten bugüne, açık tarayıcısı yalnızca bu kurulumda yüklü yazılımlar için 13 duyuru kaydetti. 10 tanesi eklentilerde, 2 tanesi WordPress çekirdeğinin kendisinde ve 1 tanesi bir temada. Türe göre yedisi siteler arası betik, ikisi kırık erişim denetimi ve geri kalanı birer tane: rastgele kod çalıştırma, hassas veri ifşası, rastgele dosya yükleme ve PHP nesne enjeksiyonu.

Bu on üçün on ikisi bir güncellemeyle kapandı, çoğu günler içinde. Bakmaya değer sayı da bu: on sekiz ayda, olağanüstü hiçbir şeyin yaşanmadığı bir sitede, üzerinde çalışan yazılım on üç kez açıklı ilan edildi ve neredeyse her seferinde cevap tek bir düğmeydi.

Şimdi de daha az söylenen ve bizzat karşılaştığımız kısım: sıfır gösteren bir güncelleme sayacı, güncel olmanın kanıtı değildir. Ticari eklentiler kendi kanalları üzerinden güncellenir ve süresi dolmuş bir lisans o sayacı güncel değil sessiz yapar. Bu kurulumda sayaç sıfır gösteriyor ve açık tarayıcısı bir madde konusunda onunla aynı fikirde değil. Güncelleme sayacının yanında bir açık tarayıcısına ihtiyaç duyulmasının sebebi budur; ikincisi kurulumunuzu görür, birincisi yayımlanmış listeyi.

Çekirdekten yakın bir örneği ayrıca yazdık: WordPress 7.0.4 güvenlik yaması ve hangi sunucuların gerçekten risk altında olduğu.

Hesaplar ve 1.224 kullanıcılı bir sitede neden tek bir yönetici var

Bu sitede 1.224 kullanıcı hesabı var. Bunlardan biri yönetici. Diğer 1.223'ü hiçbir şey kuramayan, tema dosyası düzenleyemeyen ve başka bir kullanıcının verisini göremeyen rollere sahip.

Bu sayı bir kaza değil bir karar ve sebebi basit: ele geçirilen bir hesap, tam olarak o hesabın zaten yapabildiği şeyi teslim eder. En az yetki bürokrasi değil, patlamanın büyüklüğüdür.

Bu kuralın genelde kırıldığı iki yer var ve ikisi de iyi niyetten geliyor. Birincisi, bir geliştiriciye ya da bir ajansa şimdilik bir yönetici hesabı vermek ve onu hiç kaldırmamak; beş yıllık bir sitenin yönetici listesinde genelde üç yıl önce o siteyle çalışmayı bırakmış insanlar durur. İkincisi, bir eklentinin eklediği roller. WordPress yetkileri toplar, dolayısıyla abonelere yeni bir yetenek veren bir eklenti erişim listenizi değiştirmiş ve bunu hiçbir yere yazmamıştır.

Sonraki adım iki adımlı doğrulama ve hangi yöntemi seçtiğiniz önemli. Bu sitede yalnızca doğrulayıcı uygulama yöntemi etkin; ne SMS ne e-posta. Sebebi şu: SMS bir telefon numarasına bağlıdır ve bir numara operatörden alınabilir, e-posta ise kendisi bir parolayla açılan bir posta kutusuna bağlıdır; o parola aynı sızıntıdaysa ikinci faktör ikinci faktör olmaktan çıkmıştır.

WordPress'e özgü bir nokta da şu: uygulama parolaları. Bunlar araçları bağlamak için oluşturulan ayrı parolalardır ve tasarım gereği iki adımlı doğrulamanın etrafından dolaşırlar, çünkü insansız çalışmaları beklenir. İki adımlı doğrulamayı açtıysanız aynı hesabın uygulama parolası listesine de bakın; yoksa kilitli kapının yanında açık bir kapı durmaya devam eder.

Sınanmamış bir yedek yedek değildir ve kendisi de sızabilir

Hiç geri yüklemediğiniz bir yedek bir klasördür. Bu cümle, ona ihtiyaç duyduğunuz ve dosyanın yarım kaldığını ya da açmak için gereken parolanın kaybolan sitenin içinde durduğunu öğrendiğiniz güne kadar klişe gibi gelir.

Ama neredeyse hiç kimsenin dile getirmediği ikinci bir nokta var ve biz onunla tam da bu sunucuda karşılaştık.

Yaygın WordPress taşıma eklentisi iki yüz megabaytlık arşivler kurar, onları wp-content altındaki bir klasöre koyar ve o klasörü bir .htaccess dosyasıyla korur. nginx üzerinde o dosya hiçbir şey yapmaz; hatta okunmaz bile. Bugün orada duran kuralı yazmadan önce sınadık ve arşivin düz HTTP üzerinden indirilebildiğini, sunucunun kısmi bir indirme isteğini bile karşıladığını gördük. Her arşivin içinde veritabanının tamamı vardır: kullanıcı satırları, parola özetleri, servis anahtarları ve yapılandırma dosyasının içeriği.

Yani gayet iyi bir yedek, yanlış yerde durduğunda mevcut en büyük sızıntıya dönüşür. Tek dosya, bütün site.

Bu sitenin bugünkü yöntemi, böyle bir dosyaya gelen isteği yetki denetimi için PHP'ye devretmektir; oturum açmış bir yönetici dosyayı alır, herkes 404 alır. Bugün yeniden sınadık: o arşivlerden birine yapılan bir ziyaretçi isteği, kısmi istek başlığıyla bile 404 döndü.

O hikâyeden üç kural kalıyor. Yedek aynı makinede durmamalı, çünkü sitenin yanındaki bir yedek bir hatadan kurtulur, makineden kurtulmaz. Yedeğe erişim, veritabanının kendisine erişim kadar kısıtlı olmalı. Ve geri yüklemeyi yılda bir kez geçici bir klasöre prova edin; bunun nasıl yapılacağı bilgisayar temelleri izleğinde ayrıca anlatılıyor.

Zamanınıza değmeyen şeyler

Şimdi açıkça konum, çünkü WordPress güvenlik tavsiyelerinin büyük bir kısmı güvenlik vermeden güvenlik hissi veren şeylerden oluşuyor.

Belirsizlik tek başına bir savunma değildir. Giriş sayfasının adresini değiştirmek, WordPress sürüm numarasını gizlemek ve tablo önekini değiştirmek hiçbir açığı kapatmaz; yalnızca otomatik bir tarayıcıyı biraz yavaşlatır. Özellikle sizi hedef alan biri üçünü de dakikalar içinde bulur.

Şimdi de dürüst yarısı, çünkü bu site o üç şeyi de yapıyor. Buradaki giriş adresi değiştirildi ve eklenti dosya yolları da yeniden yazıldı. Bunun satın aldığı şey daha az gürültüdür, daha fazla güvenlik değil ve kendi kaydımız iki yarıyı da gösteriyor: üç günde 127 istek varsayılan WordPress giriş adresine gitti ve hiçbiri bir giriş formuna ulaşmadı, çünkü o adres bir ziyaretçiyi başka bir sayfaya yönlendiriyor. O 127 istek ortadan kalkmadı; yalnızca artık hiçbir şeyin üzerine konmuyor. Aynı site güncel tutulmasaydı, o değiştirilmiş adres bir gün bile dayanmazdı.

Tavsiye edilen ve bizim tavsiye etmediğimiz üç şey daha. Canlı bir sitede veritabanı tablo önekini değiştirmek faydasından çok risk taşır; yarım kalır ve öneki bir yere kaydetmiş eklentiler bozulur. REST API'yi tümüyle kapatmak WordPress düzenleyicisini bozar ve erişimi kısıtlamanın çözmediği hiçbir şeyi çözmez. Katkısı uzun bir güvenlik duvarı kuralları listesi olan bir güvenlik eklentisi de, o listeyi hiç okumuyorsanız size hiçbir şey katmamıştır.

Herhangi bir güvenlik tavsiyesine uygulayabileceğiniz basit bir sınama var: bu, hangi belirli saldırıyı durduruyor ve biri zaten içerideyse neyi değiştiriyor. Bu iki soruya net cevabı olmayan tavsiye genellikle bir histir.