Uprawnienia plików WordPress: 644, 755 i właściciel

Uprawnienia plików WordPress: bezpieczne ustawienia w jednym akapicie

Bezpieczne uprawnienia plików WordPress to 755 dla katalogów, 644 dla plików oraz ostrzejsze 640 lub 600 dla wp-config.php. Nigdy 777. Te liczby chronią jednak tylko wtedy, gdy pliki należą do właściwego użytkownika. Idealne 644 na plikach, których właścicielem jest niewłaściwe konto, albo psuje wgrywanie plików i aktualizacje, albo po cichu daje serwerowi WWW więcej uprawnień, niż potrzebuje. Zanim więc zmienią Państwo jakiekolwiek tryby, warto przeczytać sekcję o właścicielu.

Właściciel, grupa i pozostali: jak czytać 755 i 644

Polecenie ls -l w katalogu głównym WordPressa zwraca linie takie jak te:

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

Pierwszy znak oznacza typ (d to katalog, - to plik). Dalej idą trzy grupy po trzy litery: dla właściciela (deploy), dla grupy (www-data) i dla pozostałych. r to odczyt, w to zapis, x to wykonanie. Każda litera ma wartość: r = 4, w = 2, x = 1. Po zsumowaniu w każdej grupie powstaje tryb ósemkowy, więc rwxr-xr-x to 7-5-5.

W katalogu x oznacza „wolno wejść". Bez niego PHP nie otworzy plików w środku, nawet jeśli same są czytelne. Dlatego katalogi potrzebują 755, a pliki wystarczy 644. Żaden plik w zwykłej instalacji WordPressa nie wymaga bitu wykonania.

Właściciel jest równie ważny jak tryb

Najpierw trzeba ustalić, jako jaki użytkownik działa PHP. Na własnym serwerze wystarczy sprawdzić uruchomione procesy:

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

W PHP-FPM proces główny działa jako root, a procesy robocze jako użytkownik puli. Ten użytkownik jest ustawiony w pliku puli. W Debianie i Ubuntu zwykle leży on w /etc/php/<version>/fpm/pool.d/:

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

Te ustawienia opisuje dokumentacja konfiguracji PHP-FPM. W Apache z mod_php PHP działa jako sam użytkownik Apache: www-data w Debianie/Ubuntu, apache w systemach z rodziny RHEL. Wszystkie witryny na takim serwerze mają wtedy jedną tożsamość. Dobry hosting współdzielony izoluje witryny: PHP każdego konta działa jako jego własny użytkownik. Jeśli nie można uruchomić ps, pomoże Narzędzia > Kondycja witryny > Info > Uprawnienia systemu plików. Widać tam, czy WordPress może zapisywać w katalogu głównym, w wp-content, w uploads oraz w katalogach wtyczek i motywów.

Gdy znamy już użytkownika PHP, wybieramy jeden z dwóch modeli własności.

Model A: użytkownik PHP jest właścicielem wszystkiego. To typowe dla izolowanego hostingu współdzielonego, gdzie użytkownik konta i użytkownik PHP to ta sama osoba. Aktualizacje z panelu, instalacja wtyczek i wgrywanie plików działają. Wada: każdy kod uruchomiony jako PHP może też przepisać wszystkie pliki, razem z rdzeniem, wtyczkami i wp-config.php.

Model B: właścicielem jest użytkownik wdrożeniowy, a PHP tylko czyta. Pliki należą do kogoś w rodzaju deploy:www-data i mają 755/644. PHP może wszystko odczytać, ale zapisuje tylko tam, gdzie na to pozwolimy: w wp-content/uploads i w katalogach pamięci podręcznej. Aktualizuje się wtedy przez WP-CLI lub SFTP jako użytkownik wdrożeniowy, a nie z panelu. To ogranicza szkody, ale wymaga więcej pracy. Jeśli chcą Państwo dodatkowo trwale zablokować panel, zobacz DISALLOW_FILE_MODS i jego wady.

Model B tłumaczy częstą zagadkę: WordPress prosi o dane FTP po kliknięciu „Aktualizuj". Sprawdza on, czy pliki, które utworzy, miałyby tego samego właściciela co jego własne. Jeśli nie, przechodzi na FTP. Wymuszenie FS_METHOD na direct ukrywa objaw, ale nie usuwa przyczyny. Najpierw trzeba wybrać model, a potem ustawić własność tak, by do niego pasowała.

Jak bezpiecznie zresetować uprawnienia plików WordPress

Najpierw wykonaj kopię zapasową plików i bazy danych. Następnie przejdź do katalogu głównego WordPressa i upewnij się, że jesteś we właściwym miejscu:

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

Jeśli ls nie znajdzie wp-config.php, przerwij. (Niektóre konfiguracje trzymają ten plik poziom wyżej niż katalog główny serwisu, więc sprawdź swój układ.) Potem zresetuj tryby:

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

Na dużych witrynach wariant z + jest znacznie szybszy, bo przekazuje wiele plików do jednego wywołania chmod:

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

Własność zmieniaj tylko na serwerze, który kontrolujesz. Dla modelu B wygląda to tak:

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

Reset wyrównuje też wyjątki opisane niżej, więc ustaw je od razu ponownie. Potem sprawdź wynik poleceniem stat -c '%a %U:%G %n' wp-config.php wp-content/uploads, wgraj testowy obraz i otwórz kilka stron.

Wyjątki: wp-config.php, uploads i .htaccess

wp-config.php zawiera hasło do bazy danych, więc „pozostali" nie powinni mieć żadnych praw. Użyj 600, jeśli właścicielem pliku jest użytkownik PHP (model A). Użyj 640, jeśli właścicielem jest użytkownik wdrożeniowy, a PHP czyta plik przez grupę (model B). Przy modelu B ustawienie 600 uniemożliwi PHP odczyt pliku i witryna przestanie działać. O solach, ustawieniach debugowania i zapomnianych kopiach zapasowych pliku piszemy w artykule zabezpieczanie wp-config.php.

wp-content/uploads i katalogi pamięci podręcznej muszą być zapisywalne dla użytkownika PHP. W modelu B albo uczyń użytkownika PHP właścicielem tych katalogów, albo zostaw je w grupie PHP z prawem zapisu dla grupy (775 dla katalogów, 664 dla plików). Prawo zapisu ogranicz do tych ścieżek, a nie do całego wp-content.

W Apache .htaccess to przypadek szczególny. Jeśli jest zapisywalny, WordPress aktualizuje reguły przepisywania po zapisaniu bezpośrednich odnośników, a wtyczki cache i bezpieczeństwa dodają własne bloki. Jeśli nie jest, WordPress pokazuje reguły do ręcznego wklejenia. Plik tylko do odczytu odbiera trochę wygody. W zamian kod uruchomiony jako PHP nie doda do niego przekierowania ani linii auto_prepend_file.

Dlaczego 777 nigdy nie naprawia błędu wgrywania

777 pozwala zapisywać do pliku lub katalogu każdemu kontu i każdemu procesowi na serwerze. Na hostingu współdzielonym mogą to być skompromitowane skrypty innych klientów. Błąd wgrywania może zniknąć, ale tylko dlatego, że usunięto zabezpieczenie, a nie przyczynę. Prawdziwych przyczyn warto szukać w tej kolejności:

1. Zły właściciel. Komunikat „Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?" niemal zawsze oznacza, że użytkownik PHP nie jest właścicielem uploads (albo nie może tam zapisywać). Często zdarza się to po migracji lub przywróceniu kopii wykonanym jako root.
2. Pełny dysk lub przekroczony limit. Na własnym serwerze sprawdź df -h, na hostingu limit w panelu.
3. Katalog tymczasowy lub ograniczenia ścieżek. „Missing a temporary folder" wskazuje na upload_tmp_dir. Wgrywanie może też blokować open_basedir, jeśli wyklucza ścieżkę katalogu tymczasowego.
4. Limity rozmiaru. „The uploaded file exceeds the upload_max_filesize directive" oznacza, że trzeba zwiększyć upload_max_filesize i post_max_size albo wgrać mniejszy plik.

Na hostingu współdzielonym zwykle nie można samodzielnie użyć chown. Poproś dostawcę o ustawienie właściciela plików na koncie na właściwego użytkownika. To rutynowa prośba.

Przed czym poprawne uprawnienia nie chronią

Uprawnienia ograniczają to, co może zrobić użytkownik. Nie działają przeciwko kodowi, który już działa jako ten użytkownik. Jeśli podatna wtyczka pozwoli atakującemu uruchomić PHP, jego kod ma prawa użytkownika PHP. W modelu A to oznacza wszystko. W modelu B nadal oznacza uploads, katalogi cache i wszystko inne, co uczyniono zapisywalnym. Dlatego atakujący upodobali sobie uploads, o czym piszemy w artykule web shelle w wp-content/uploads.

Reset uprawnień po włamaniu też nie usuwa tylnej furtki. Złośliwy plik nadal tam jest, tylko z ładnym trybem. Najpierw trzeba więc przejść przez porządny plan usuwania malware, a dopiero potem poprawić uprawnienia w ramach utwardzania. W świetle RODO poprawne uprawnienia mogą być jednym ze środków technicznych chroniących integralność i poufność danych osobowych (art. 32, EUR-Lex), ale działają tylko jako część szerszego zestawu środków.

Regularnie sprawdzaj uprawnienia

Uprawnienia lubią się rozjeżdżać. Zwykle winne są migracje, przywracanie kopii, zmiany hostingu i szybka poprawka przez sudo. Po każdym z tych zdarzeń, a i tak co kilka miesięcy, uruchom z katalogu głównego WordPressa dwa polecenia:

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

Pierwsze wypisuje wszystko, co jest zapisywalne dla wszystkich (dowiązania symboliczne są pominięte, bo zawsze pokazują 777). Drugie wypisuje pliki, których właścicielem nie jest oczekiwany użytkownik. W modelu A zamień deploy na użytkownika PHP. Oba polecenia powinny nic nie zwrócić albo pokazać wyłącznie ścieżki, które potrafisz wyjaśnić. Poradnik WordPress.org o uprawnieniach plików opisuje ten sam punkt wyjścia z perspektywy zespołu rdzenia.

Żeby mieć na oku szerszy obraz, wtyczka Security Audit & Compliance z secaudit.eu wykonuje kontrole utwardzania i konfiguracji oraz monitoruje integralność plików, dzięki czemu zmienione lub nowe pliki pojawiają się między ręcznymi przeglądami → secaudit.eu

FAQ

Czy wp-config.php powinien mieć 400 lub 440?

Też się sprawdzi, o ile PHP nadal może odczytać plik: 400, gdy PHP jest właścicielem, 440, gdy PHP czyta go przez grupę. Haczyk polega na tym, że do edycji pliku trzeba będzie wrócić do wyższego trybu. Zwykle przyjmuje się kompromis: 600 lub 640.

Czy 755/644 jest bezpieczne na hostingu współdzielonym?

Tak, jeśli dostawca izoluje konta, a PHP działa jako Państwa własny użytkownik. Przy 644 inne konta mogłyby technicznie czytać Państwa pliki. Właściwa izolacja temu zapobiega, dlatego konfiguracja hostingu waży więcej niż same cyfry.

Czy po każdej aktualizacji trzeba resetować uprawnienia?

Nie. WordPress tworzy nowe pliki z rozsądnymi trybami. Zamiast tego warto uruchomić powyższe kontrole i resetować uprawnienia tylko wtedy, gdy wykażą problemy.