WordPress dosya izinleri: 644, 755 ve dosya sahipliği

WordPress dosya izinleri: güvenli varsayılan tek paragrafta

WordPress dosya izinleri için güvenli varsayılan şudur: dizinlerde 755, dosyalarda 644, wp-config.php için ise daha sıkı bir 640 veya 600. 777 asla kullanılmamalı. Ancak bu rakamlar yalnızca dosyaların sahibi doğru kullanıcıysa koruma sağlar. Yanlış hesaba ait dosyalarda kusursuz bir 644, ya yüklemeleri ve güncellemeleri bozar ya da web sunucusuna ihtiyacından fazla yetki verir. Bu yüzden herhangi bir modu değiştirmeden önce sahiplik bölümünü okuyun.

Sahip, grup ve diğerleri: 755 ve 644 nasıl okunur

WordPress kök dizininde ls -l çalıştırdığınızda şuna benzer satırlar görürsünüz:

drwxr-xr-x  5 deploy www-data  4096 Oct 30 09:12 wp-content
-rw-r--r--  1 deploy www-data   405 Oct 30 09:12 index.php
-rw-r-----  1 deploy www-data  3214 Oct 30 09:12 wp-config.php

İlk karakter türü gösterir (dizin için d, dosya için -). Ardından üçer harflik üç grup gelir: biri sahip (deploy), biri grup (www-data), biri de diğer herkes içindir. r okuma, w yazma, x çalıştırma demektir. Her harfin bir değeri vardır: r = 4, w = 2, x = 1. Bunları her grup için toplarsanız sekizlik (octal) modu elde edersiniz; yani rwxr-xr-x, 7-5-5 olur.

Bir dizinde x, "içeri girebilir" anlamına gelir. Bu olmadan, içindeki dosyalar okunabilir olsa bile PHP onları açamaz. Dizinlerin 755, dosyaların ise yalnızca 644 gerektirmesinin nedeni budur. Normal bir WordPress kurulumunda hiçbir dosyanın çalıştırma bitine ihtiyacı yoktur.

Sahiplik, izin modu kadar önemlidir

Önce PHP'nin hangi kullanıcıyla çalıştığını öğrenin. Kendi sunucunuzda çalışan süreçlere bakmanız yeterli:

ps -eo user,comm | grep -E 'php-fpm|apache2|httpd' | sort | uniq

PHP-FPM'de ana süreç root olarak, çalışan süreçler (worker) ise havuz (pool) kullanıcısı olarak çalışır. Bu kullanıcıyı havuz dosyası belirler. Debian ve Ubuntu'da dosya genellikle /etc/php/<version>/fpm/pool.d/ altında bulunur:

grep -R -E '^(user|group) *=' /etc/php/*/fpm/pool.d/

Bu ayarlar PHP-FPM yapılandırma belgelerinde anlatılır. Apache ve mod_php ile PHP doğrudan Apache kullanıcısı olarak çalışır: Debian/Ubuntu'da www-data, RHEL tabanlı sistemlerde apache. O sunucudaki bütün siteler de tek bir kimliği paylaşır. İyi bir paylaşımlı hosting siteleri birbirinden yalıtır; yani her hesabın PHP'si kendi kullanıcısıyla çalışır. ps çalıştıramıyorsanız Araçlar > Site Sağlığı > Bilgi > Dosya Sistemi İzinleri bölümüne bakın. WordPress'in ana dizine, wp-content'e, uploads'a, eklenti ve tema dizinlerine yazıp yazamadığını burada görürsünüz.

PHP kullanıcısını öğrendikten sonra iki sahiplik modelinden birini seçin.

Model A: Her şeyin sahibi PHP kullanıcısıdır. Hesap kullanıcınızla PHP kullanıcısının aynı olduğu yalıtılmış paylaşımlı hostinglerde tipiktir. Panelden güncelleme, eklenti kurulumu ve yüklemeler sorunsuz çalışır. Dezavantajı: PHP olarak çalışan herhangi bir kod çekirdek dosyaları, eklentiler ve wp-config.php dahil her dosyayı yeniden yazabilir.

Model B: Dosyaların sahibi bir deploy kullanıcısıdır, PHP yalnızca okur. Dosyalar 755/644 modunda deploy:www-data gibi bir sahip ve gruba aittir. PHP her şeyi okuyabilir ama yalnızca izin verdiğiniz yerlere yazabilir: wp-content/uploads ve varsa önbellek dizinleri. Güncellemeleri panelden değil, deploy kullanıcısıyla WP-CLI veya SFTP üzerinden yaparsınız. Bu, olası hasarı sınırlar ama iş yükü ekler. Panelden değişiklikleri kalıcı olarak kilitlemek de istiyorsanız DISALLOW_FILE_MODS ve getirdiği ödünleşimler yazısına bakın.

Model B, bilinen bir bilmeceyi de açıklar: "Güncelle"ye tıkladığınızda WordPress'in FTP bilgisi istemesi. WordPress, oluşturacağı dosyaların kendi dosyalarıyla aynı sahibe sahip olup olmayacağını kontrol eder. Olmayacaksa FTP'ye geçer. FS_METHOD değerini direct yapmaya zorlamak belirtiyi gizler, nedeni çözmez. Hangi modeli istediğinize karar verin, sahipliği ona göre ayarlayın.

WordPress dosya izinleri güvenle nasıl sıfırlanır

Önce dosyaların ve veritabanının yedeğini alın. Sonra WordPress kök dizinine gidin ve doğru yerde olduğunuzu doğrulayın:

cd /var/www/example.com/public
ls wp-config.php

ls wp-config.php dosyasını bulamazsa durun. (Bazı kurulumlarda dosya web kökünün bir üst dizininde durur; kendi yapınızı kontrol edin.) Ardından modları sıfırlayın:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Büyük sitelerde + biçimi çok daha hızlıdır, çünkü her chmod çağrısına birçok dosyayı birden verir:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Sahipliği yalnızca kontrol ettiğiniz bir sunucuda değiştirin. Model B için şöyle görünür:

sudo chown -R deploy:www-data /var/www/example.com/public

Sıfırlama aşağıdaki istisnaları da ezer, bu yüzden hemen yeniden uygulayın. Sonra sonucu stat -c '%a %U:%G %n' wp-config.php wp-content/uploads ile kontrol edin, deneme amaçlı bir görsel yükleyin ve birkaç sayfayı açın.

İstisnalar: wp-config.php, uploads ve .htaccess

wp-config.php veritabanı parolanızı içerir, bu yüzden "diğerleri" hiçbir yetki almamalıdır. Dosyanın sahibi PHP kullanıcısıysa (Model A) 600 kullanın. Sahibi deploy kullanıcısıysa ve PHP dosyayı grup üzerinden okuyorsa (Model B) 640 kullanın. Model B'de 600 ayarlarsanız PHP dosyayı okuyamaz ve site çöker. Salt değerleri, hata ayıklama ayarları ve unutulmuş yedek kopyalar için wp-config.php sıkılaştırma yazısına bakın.

wp-content/uploads ve önbellek dizinlerine PHP kullanıcısı yazabilmelidir. Model B'de ya bu dizinlerin sahibini PHP kullanıcısı yapın ya da grup sahipliğini PHP grubunda tutup gruba yazma yetkisi verin (dizinlerde 775, dosyalarda 664). Yazma yetkisini wp-content'in tamamına değil, yalnızca bu yollara verin.

Apache'de .htaccess özel bir durumdur. Yazılabilirse WordPress kalıcı bağlantıları kaydettiğinizde yeniden yazma kurallarını günceller, önbellek ve güvenlik eklentileri de kendi bloklarını ekler. Yazılabilir değilse WordPress kuralları size gösterir, elle yapıştırırsınız. Salt okunur bir .htaccess biraz rahatlıktan ödün vermek demektir. Karşılığında PHP olarak çalışan kod dosyaya bir yönlendirme ya da auto_prepend_file satırı ekleyemez.

777 neden yükleme hatasını asla çözmez

777, sunucudaki her hesabın ve her sürecin dosyaya veya dizine yazmasına izin verir. Paylaşımlı hostingde bu, başka müşterilerin ele geçirilmiş betiklerini de kapsayabilir. Yükleme hatasını ortadan kaldırabilir, ama nedeni gidererek değil, korumayı kaldırarak. Gerçek nedenleri şu sırayla kontrol edin:

1. Yanlış sahip. "Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?" mesajı neredeyse her zaman PHP kullanıcısının uploads dizininin sahibi olmadığı (veya oraya yazamadığı) anlamına gelir. Bu, genellikle root olarak yapılan bir taşıma ya da geri yüklemeden sonra olur.
2. Disk veya kota dolu. Kendi sunucunuzda df -h çalıştırın, hostingde ise panelden kotanıza bakın.
3. Geçici dizin veya yol sınırları. "Missing a temporary folder" hatası upload_tmp_dir ayarına işaret eder. Geçici dizin yolunu dışarıda bırakan bir open_basedir kısıtı da yüklemeleri engelleyebilir.
4. Boyut sınırları. "The uploaded file exceeds the upload_max_filesize directive" hatası, upload_max_filesize ve post_max_size değerlerini yükseltmeniz ya da daha küçük bir dosya yüklemeniz gerektiği anlamına gelir.

Paylaşımlı hostingde genellikle chown komutunu kendiniz çalıştıramazsınız. Hosting sağlayıcınızdan hesabınızdaki sahipliği doğru kullanıcıya ayarlamasını isteyin. Bu rutin bir taleptir.

Doğru izinlerin korumadığı şeyler

İzinler, bir kullanıcının neler yapabileceğini sınırlar. O kullanıcı olarak zaten çalışan koda karşı bir şey yapmazlar. Zafiyetli bir eklenti saldırgana PHP çalıştırma imkânı veriyorsa, saldırganın kodu PHP kullanıcısının haklarına sahip olur. Model A'da bu her şey demektir. Model B'de ise yine uploads, önbellek dizinleri ve yazılabilir bıraktığınız her şey demektir. Saldırganların uploads dizinini tercih etmesinin nedeni budur; bunu wp-content/uploads içindeki web shell'ler yazısında anlattık.

Bir saldırıdan sonra izinleri sıfırlamak da arka kapıyı kaldırmaz. Zararlı dosya yerinde durur, yalnızca modları düzgündür. Önce düzgün bir zararlı yazılım temizleme planı izleyin, izinleri ise sıkılaştırma adımının parçası olarak düzeltin. GDPR (AB Genel Veri Koruma Tüzüğü) kapsamında doğru izinler, kişisel verilerin bütünlüğünü ve gizliliğini koruyan teknik önlemlerden biri sayılabilir (Madde 32, EUR-Lex); ancak yalnızca daha geniş bir önlemler bütününün parçası olarak işe yarar.

İzinleri düzenli kontrol edin

İzinler zamanla kayar. Taşımalar, yedek geri yüklemeleri, hosting değişiklikleri ve aceleyle yapılmış bir sudo düzeltmesi bunun olağan nedenleridir. Bu olaylardan her birinden sonra, ayrıca birkaç ayda bir, WordPress kök dizininden şu iki kontrolü çalıştırın:

find . -perm -o+w ! -type l
find . ! -user deploy

İlk komut herkesin yazabildiği her şeyi listeler (sembolik bağlantılar hariç tutulur, çünkü her zaman 777 görünürler). İkincisi, beklediğiniz sahibe ait olmayan dosyaları listeler. Model A'da deploy yerine PHP kullanıcınızı yazın. İkisi de boş dönmeli ya da yalnızca açıklayabileceğiniz yolları göstermelidir. WordPress.org dosya izinleri kılavuzu aynı temel çizgiyi çekirdek ekibin bakış açısıyla anlatır.

Daha geniş tabloyu da takip etmek isterseniz, secaudit.eu'nun Security Audit & Compliance eklentisi dosya bütünlüğü izlemenin yanında sıkılaştırma ve yapılandırma kontrolleri de çalıştırır; böylece değişen veya yeni dosyalar elle yaptığınız incelemeler arasında da görünür → secaudit.eu

Sıkça sorulan sorular

wp-config.php 400 veya 440 olmalı mı?

PHP dosyayı hâlâ okuyabiliyorsa bu da olur: PHP sahipse 400, dosyayı grup üzerinden okuyorsa 440. Tek sorun, dosyayı düzenlemek için modu geri değiştirmeniz gerekmesidir. 600 veya 640 olağan orta yoldur.

Paylaşımlı hostingde 755/644 güvenli mi?

Evet, hosting hesapları yalıtıyorsa ve PHP'niz kendi kullanıcınızla çalışıyorsa. 644'te diğer hesaplar teknik olarak dosyalarınızı okuyabilirdi. Düzgün yalıtım bunu engeller; bu yüzden rakamlardan çok hostingin kurulumu belirleyicidir.

Her güncellemeden sonra izinleri sıfırlamam gerekir mi?

Hayır. WordPress yeni dosyaları makul modlarla oluşturur. Bunun yerine yukarıdaki kontrolleri çalıştırın ve yalnızca sorun görürseniz sıfırlayın.