Gerçekten İşe Yarayan WordPress .htaccess Güvenlik Kuralları

“WordPress .htaccess güvenliği” diye satılan şeyin çoğu doldurmadan ibaret. Saldırı yüzeyinizi gerçekten değiştiren kurallar kısadır: wp-content/uploads içinde PHP çalıştırılmasını engelleyin, wp-config.php dosyasına doğrudan erişimi reddedin ve dizin listelemeyi kapatın. Popüler olanlar ise — “kaba kuvvet saldırısını durdurmak için” xmlrpc.php engellemek, WordPress sürümünüzü gizlemek, 200 satırlık kötü bot user-agent listesi yapıştırmak — marjinal olandan tam anlamıyla tiyatroya kadar uzanan bir yelpazede. Aşağıda hangisinin hangisi olduğunu ve nedenini bulacaksınız.

Önce şunu netleştirelim: .htaccess yalnızca Apache üzerinde (ve onu da okuyan LiteSpeed’de) bir işe yarar. nginx üzerinde tamamen yok sayılır — siz korunduğunuzu sanırken dosya öylece orada durur. Sunucunuz nginx çalıştırıyorsa bunların hiçbiri geçerli değildir ve bunun yerine server/location bloklarına ihtiyacınız olur. Sunucunun asla okumadığı bir dosyayı düzenlemek için bir saat harcamadan önce curl -I https://yoursite.com ile kontrol edin ve Server: başlığına bakın.

Asıl önemli olan kural: /uploads içinde PHP yok

Yapmaya değer olan tek şey bu. wp-content/uploads tasarımı gereği herkes tarafından yazılabilir — her medya yüklemesi, dosya kaydeden her eklenti buraya yazar. Bir saldırgan bu dizine bir .php dosyası sokabilirse (savunmasız bir yükleme işleyicisi, MIME türünü doğrulamayan bir görsel alanı veya ele geçirilmiş bir eklenti üzerinden), bir baş ağrısı ile tam bir uzaktan kod çalıştırma (RCE) ihlali arasındaki fark, istek geldiğinde sunucunun o dosyayı çalıştırıp çalıştırmayacağıdır. Çalıştırmayı reddedin, yüklenen zararlı yazılım diskte duran etkisiz bir dosyadan ibaret kalsın.

Bunu wp-content/uploads/.htaccess dosyasının içine ekleyin (dosya yoksa oluşturun):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Bu, Apache 2.4 sözdizimidir. Daha eski olan 2.2’de karşılığı Order Deny,Allow / Deny from all şeklindedir. İki lehçeyi tek bir dosyada karıştırmak, “sıkılaştırma” sonrası aniden ortaya çıkan 500 Internal Server Error hatasının en yaygın nedenidir — kaydettiğiniz anda tüm site çöküyorsa neredeyse her zaman sebep budur. Sürümünüzü apachectl -v ile kontrol edin.

wp-config.php dosyasını koruyun

wp-config.php, veritabanı kimlik bilgilerinizi ve kimlik doğrulama salt’larınızı barındırır. PHP çalışırken buna yapılan doğrudan bir istek boş bir sayfa döndürür — PHP dosyayı yazdırmak yerine çalıştırır. Risk, arıza durumundadır: PHP çökerse, bir geçiş sırasında yanlış yapılandırılırsa veya işleyici devre dışı bırakılırsa, Apache dosyayı düz metin olarak sunar ve DB parolanızı isteyen herkese döker. Erişimi reddetmek, kötü geçecek beş dakikaya karşı ucuz bir sigortadır:

<Files wp-config.php>
    Require all denied
</Files>

Dizin listelemeyi kapatın

Birisi index.php içermeyen bir klasörü ziyaret ederse ve Apache’de Options +Indexes açıksa, sunucu içeriği listeler — her yedek dosyası, unuttuğunuz her başıboş SQL dökümü. Bunu site genelinde kapatın:

Options -Indexes

Düşük önem derecesinde ama gerçek bir tehdit ve hiçbir maliyeti yok.

İşte dürüst çekirdek liste bu. Bunları — ayrıca sitenizi 500’e düşürmemeniz için doğru 2.4-mü-2.2-mi sözdizimini — yanlış Apache sürümü için yazılmış bir forum gönderisinden kopyala-yapıştır yapmak yerine WordPress .htaccess oluşturucu ile bir araya getirebilirsiniz.

NE YAPILMAMALI

“Kaba kuvvet koruması için” xmlrpc.php engellemek. Herkesin tekrarladığı büyük şey bu ve söylendiği haliyle yanlış. Evet, XML-RPC’nin system.multicall yöntemi geçmişte bir saldırganın birçok giriş denemesini tek bir istekte paketlemesine izin veriyordu — gerçek bir güçlendirme. Ama ezici çoğunlukla yaygın olan kaba kuvvet vektörü wp-login.php dosyasına yapılan sıradan POST istekleridir ve xmlrpc.php engellemek bunun için hiçbir şey yapmaz. Kaba kuvvet; hız sınırlama, güçlü parolalar ve 2FA ile yenilir — tek bir uç noktayı öldürerek değil. XML-RPC’yi devre dışı bırakmak için meşru bir sebep de var: pingback özelliği DDoS yansıtması için kötüye kullanılabilir, dolayısıyla Jetpack, mobil uygulama veya pingback kullanmıyorsanız onu kapatmak saldırı yüzeyinizi küçültür. Sadece kendinize bunun kaba kuvvet savunmanız olduğunu söylemeyin, çünkü değil.

WordPress sürümünüzü gizlemek / generator etiketini kaldırmak. readme.html dosyasını ve <meta name="generator"> etiketini soyup atmak sıkılaştırma gibi hissettirir. Bir saldırgan sürümünüzü, sıraya alınmış varlık sorgu dizelerinden, blok düzenleyici işaretlemesinden ve düzinelerce başka ipucundan saniyeler içinde parmak izi olarak çıkarır. Hiçbir şey gizlemiyorsunuz; sadece kendinizi meşgul hissettiriyorsunuz.

Devasa kötü bot user-agent ve yönlendiren (referrer) engelleme listeleri. User-agent, sahtesi kolayca yapılabilen tek bir HTTP başlığıdır. Bu listeler yapıştırdığınız gün bayatlar, yetkin hiçbir şeyi engellemez ve Apache her istekte her regex’i değerlendirir — sıfır güvenlik için gerçek bir performans bedeli ödüyorsunuz. Bunları atlayın.

wp-login.php dosyasını IP ile kilitlemek. ISP’niz adresinizi değiştirene ve kendinizi kendi yönetici panelinizin dışına kilitleyene kadar harikadır. Yalnızca gerçekten statik bir IP ile uygulanabilir.

Yazar sıralama (author-enumeration) yönlendirmeleri (?author=1). İnsanların bunun için yapıştırdığı .htaccess yeniden yazma kuralı tek başına eksiktir — REST uç noktası /wp-json/wp/v2/users hâlâ kullanıcı adlarını listeler. Bir yolu engellerken diğerini açık bırakmak tiyatrodur.

Hâlâ takıldınız mı?

Bir kural siteyi 500’e düşürüyorsa sorun sözdizimidir — eklediğiniz son bloğu çıkarıp yeniden yükleyin; bu onu anında yalıtır. Bir kural hiçbir şey yapmıyor gibi görünüyorsa, gerçekten Apache üzerinde olduğunuzu ve ilgili dizin için AllowOverride özelliğinin etkin olduğunu doğrulayın (birçok yönetilen barındırma hizmeti bunu kısıtlar). Dosyayı, bilinen-iyi bir şablondan .htaccess oluşturucu ile oluşturun, önemli olan üç kuralı tutun ve gerisini bırakın.