Popraw uprawnienia do plików dla WordPress [zamknięte]

Zajrzałem tutaj, ale nie znalazłem żadnych szczegółów na temat najlepszych uprawnień do plików. Przyjrzałem się również niektórym pytaniom formularza WordPress tutaj, ale każdy, kto sugeruje 777, oczywiście potrzebuje lekcji bezpieczeństwa.

Krótko mówiąc, moje pytanie brzmi: Jakie uprawnienia powinienem mieć w następujących przypadkach:

1. folder główny przechowujący całą zawartość WordPress
2. wp-admin
3. wp-content
4. wp-obejmuje

a następnie wszystkie pliki w każdym z tych folderów?

Podczas instalacji WP możesz (serwer internetowy) potrzebować dostępu do zapisu plików. Dlatego prawa dostępu mogą wymagać utraty.

chown www-data:www-data  -R * # Let Apache be owner
find . -type d -exec chmod 755 {} \;  # Change directory permissions rwxr-xr-x
find . -type f -exec chmod 644 {} \;  # Change file permissions rw-r--r--

Po instalacji powinieneś zaostrzyć prawa dostępu , zgodnie z Hardening WordPress wszystkie pliki z wyjątkiem wp-content powinny być zapisywane tylko przez twoje konto użytkownika. wp-content musi być także zapisywalny przez www-data .

chown <username>:<username>  -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let apache be owner of wp-content

Być może chcesz później zmienić zawartość wp-content. W takim przypadku możesz

• tymczasowo zmienić na użytkownika na www-dane za pomocą su,
• daj grupie wp-content dostęp do zapisu 775 i dołącz do grupy www-data lub
• daj swojemu użytkownikowi prawa dostępu do folderu za pomocą list ACL .

Cokolwiek robisz, upewnij się, że pliki mają uprawnienia rw do danych www .

Udzielenie użytkownikowi pełnego dostępu do wszystkich plików wp www-data(czyli w tym przypadku użytkownika serwera WWW) może być niebezpieczne. Raczej NIE rób tego:

chown www-data:www-data -R *

Może być jednak użyteczny w momencie instalacji lub aktualizacji WordPressa i jego wtyczek. Ale kiedy skończysz, nie jest już dobrym pomysłem przechowywanie plików wp będących własnością serwera WWW.

Zasadniczo pozwala serwerowi WWW na umieszczenie lub zastąpienie dowolnego pliku w witrynie. Oznacza to, że istnieje możliwość przejęcia witryny, jeśli komuś uda się użyć serwera WWW (lub luki bezpieczeństwa w skrypcie .php) do umieszczenia niektórych plików w witrynie.

Aby chronić swoją witrynę przed takim atakiem, wykonaj następujące czynności:

Wszystkie pliki powinny należeć do twojego konta użytkownika i powinny być zapisywane przez Ciebie. Każdy plik, który wymaga dostępu do zapisu z WordPress, powinien być zapisywalny przez serwer WWW, jeśli wymaga tego konfiguracja hostingu, może to oznaczać, że pliki te muszą należeć do grupy przez konto użytkownika używane przez proces serwera WWW.

/

Główny katalog WordPress: wszystkie pliki powinny być zapisywane tylko przez twoje konto użytkownika, z wyjątkiem .htaccess, jeśli chcesz, aby WordPress automatycznie generował dla ciebie reguły przepisywania.

/wp-admin/

Obszar administracyjny WordPress: wszystkie pliki powinny być zapisywane tylko przez twoje konto użytkownika.

/wp-includes/

Większość logiki aplikacji WordPress: wszystkie pliki powinny być zapisywane tylko przez twoje konto użytkownika.

/wp-content/

Treści dostarczone przez użytkownika: przeznaczone do zapisu przez konto użytkownika i proces serwera WWW.

Wewnątrz /wp-content/znajdziesz:

/wp-content/themes/

Pliki motywów. Jeśli chcesz korzystać z wbudowanego edytora motywów, wszystkie pliki muszą być zapisywane przez proces serwera WWW. Jeśli nie chcesz korzystać z wbudowanego edytora motywów, wszystkie pliki mogą być zapisywane tylko przez twoje konto użytkownika.

/wp-content/plugins/

Pliki wtyczek: wszystkie pliki powinny być zapisywane tylko przez twoje konto użytkownika.

Inne katalogi, które mogą być obecne, /wp-content/powinny być udokumentowane przez dowolną wymaganą wtyczkę lub motyw. Uprawnienia mogą się różnić.

Źródło i dodatkowe informacje: http://codex.wordpress.org/Hardening_WordPress

Dla tych, którzy mają folder główny Wordpress w swoim folderze domowym:

** Ubuntu / apache

1. Dodaj użytkownika do grupy danych www:

KREDYT Przyznanie uprawnień do zapisu grupie danych www

Chcesz zadzwonić do usermodużytkownika. To by było:

sudo usermod -aG www-data yourUserName

** Zakładając, że www-datagrupa istnieje

2. Sprawdź, czy użytkownik jest w www-datagrupie:

   groups yourUserName

Powinieneś dostać coś takiego:

youUserName : youUserGroupName www-data

** youUserGroupName jest zwykle podobna do twojej nazwy użytkownika

3. Rekurencyjnie zmieniaj własność grupy folderu wp-content, zachowując własność użytkownika

   chown yourUserName:www-data -R youWebSiteFolder/wp-content/*

4. Zmień katalog na youWebSiteFolder / wp-content /

   cd youWebSiteFolder/wp-content

5. Rekurencyjnie zmieniaj uprawnienia grupowe folderów i podfolderów, aby włączyć uprawnienia do zapisu:

   find . -type d -exec chmod -R 775 {} \;

** zmieniono tryb `/ home / yourUserName / youWebSiteFolder / wp-content / 'z 0755 (rwxr-xr-x) na 0775 (rwxrwxr-x)

6. Rekurencyjnie zmieniaj uprawnienia grupowe plików i podplików, aby włączyć uprawnienia do zapisu:

   find . -type f -exec chmod -R 664 {} \;

Wynik powinien wyglądać mniej więcej tak:

WAS:
-rw-r--r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html
CHANGED TO:
-rw-rw-r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html

Równoważny:

chmod -R ug + rw foldername

Uprawnienia będą wynosić 664 dla plików lub 775 dla katalogów.

Ps, jeśli ktoś napotka błąd 'could not create directory'podczas aktualizacji wtyczki, wykonaj:
server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
gdy jesteś w katalogu głównym swojej domeny.
Zakładając: wp-config.phpma
poświadczenia FTP na LocalHost
define('FS_METHOD','direct');

Najlepiej przeczytać dokumentację Wordpress na tym https://wordpress.org/support/article/changing-file-permissions/

• Wszystkie pliki powinny być własnością rzeczywistego konta użytkownika, a nie konta użytkownika używanego w procesie httpd
• Własność grupy nie ma znaczenia, chyba że istnieją specyficzne wymagania grupy dotyczące sprawdzania uprawnień procesu serwera WWW. Zazwyczaj tak nie jest.
• Wszystkie katalogi powinny mieć 755 lub 750.
• Wszystkie pliki powinny mieć format 644 lub 640. Wyjątek: wp-config.php powinien mieć wartość 440 lub 400, aby uniemożliwić innym użytkownikom jego odczytanie.
• Nigdy nie należy podawać żadnych katalogów 777, nawet katalogów przesyłanych. Ponieważ proces php jest uruchomiony jako właściciel plików, otrzymuje uprawnienia właścicieli i może zapisywać nawet w katalogu 755.

Ustawiam uprawnienia na:

    # Set all files and directories user and group to wp-user
    chown wp-user:wp-user -R *

    # Set uploads folder user and group to www-data
    chown www-data:www-data -R wp-content/uploads/

    # Set all directories permissions to 755
    find . -type d -exec chmod 755 {} \;

    # Set all files permissions to 644
    find . -type f -exec chmod 644 {} \;

W moim przypadku stworzyłem określonego użytkownika dla WordPress, który różni się od domyślnego użytkownika apache, który uniemożliwia dostęp z sieci do plików należących do tego użytkownika.

Następnie daje użytkownikowi apache do obsługi folderu przesyłania i na końcu ustawia wystarczająco bezpieczne uprawnienia do plików i folderów.

EDYTOWANE

Jeśli używasz W3C Total Cache, powinieneś również wykonać następujące czynności:

rm -rf wp-content/cache/config
rm -rf wp-content/cache/object
rm -rf wp-content/cache/db
rm -rf wp-content/cache/minify
rm -rf wp-content/cache/page_enhanced

To zadziała!

EDYTOWANE

Po pewnym czasie tworzenia witryn WordPress zalecam różne uprawnienia do plików w zależności od środowiska:

W produkcji nie dałbym dostępu użytkownikom do modyfikowania systemu plików, pozwolę im tylko na przesyłanie zasobów i dostęp do niektórych wtyczek określonych folderów do wykonywania kopii zapasowych itp. Ale zarządzanie projektami w Git i używanie kluczy wdrażania na serwer, to nie jest dobre wtyczki aktualizacji na etapie testowania ani produkcji. Zostawiam tutaj ustawienia pliku produkcyjnego:

# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/

www-data: www-data = użytkownik i grupa apache lub nginx

Inscenizacja będzie miała takie same uprawnienia produkcyjne, jak powinna być jej klon.

Wreszcie środowisko programistyczne będzie miało dostęp do aktualizacji wtyczek, tłumaczeń, wszystkiego ...

# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/

# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/themes

# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/plugins/your-plugin

www-data: www-data = użytkownik apache lub nginx i zgrupuj swojego użytkownika: root-group = bieżący użytkownik i grupa główna

Te uprawnienia umożliwią dostęp do tworzenia w folderze themesi your-pluginfolderze bez pytania o pozwolenie. Reszta treści będzie własnością użytkownika Apache lub Nginx, aby umożliwić WP zarządzanie systemem plików.

Przed utworzeniem repozytorium git najpierw uruchom następujące polecenia:

# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;

# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;

Prawidłowe uprawnienia do pliku to 644 Prawidłowe uprawnienia do folderu to 755

Aby zmienić uprawnienia, użyj terminala i następujących poleceń.

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

755 dla folderów i 644 dla plików.

Myślę, że poniższe zasady są zalecane dla domyślnej witryny wordpress:

• W przypadku folderów wewnątrz treści wp ustaw uprawnienia 0755:

  Wtyczki chmod -R 0755

  przesyła chmod -R 0755

  Aktualizacja chmod -R 0755

• Pozwól użytkownikowi apache być właścicielem powyższych katalogów wp-content:

  przesłane apache

  Chown upgrade apache

  Chown wtyczki Apache

To zależy od wtyczek, których planujesz używać, ponieważ niektóre wtyczki zmieniają główny dokument WordPress. ale ogólnie polecam coś takiego w katalogu wordpress.

Spowoduje to przypisanie „root” (lub cokolwiek, którego używasz) jako użytkownika w każdym pojedynczym pliku / folderze, R oznacza rekurencyjny, więc po prostu nie zatrzymuje się w folderze „html”. jeśli nie użyłeś R, to dotyczy to tylko katalogu „html”.

sudo chown -R root:www-data /var/www/html  

Spowoduje to ustawienie właściciela / grupy „wp-content” na „www-data”, co pozwoli serwerowi internetowemu na zainstalowanie wtyczek poprzez panel administracyjny.

chown -R www-data:www-data /var/www/html/wp-content

Spowoduje to ustawienie uprawnień dla każdego pojedynczego pliku w folderze „html” (w tym plików w podkatalogach) na 644, dzięki czemu osoby zewnętrzne nie będą mogły wykonać żadnego pliku, zmodyfikować żadnego pliku, grupa nie może wykonać żadnego pliku, zmodyfikować dowolny plik i tylko użytkownik może modyfikować / czytać pliki, ale nawet użytkownik nie może wykonać żadnego pliku. Jest to ważne, ponieważ zapobiega jakiemukolwiek wykonaniu w folderze „html”, również ponieważ właścicielem folderu html i wszystkich innych folderów oprócz folderu wp-content są „root” (lub użytkownik), dane www mogą „ t zmodyfikować dowolny plik poza folderem wp-content, więc nawet jeśli na serwerze WWW występuje jakakolwiek luka, a jeśli ktoś nieautoryzowany uzyskał dostęp do witryny, nie może usunąć strony głównej z wyjątkiem wtyczek.

sudo find /var/www/html -type f -exec chmod 644 {} +

Ograniczy to dostęp do pliku „wp-config.php” do użytkownika / grupy z tymi uprawnieniami rw-r -----.

chmod 640 /var/www/html/wp-config.php

A jeśli wtyczka lub aktualizacja narzeka, że ​​nie może się zaktualizować, to uzyskaj dostęp do SSH i użyj tego polecenia, i udziel tymczasowe pozwolenie na „www-data” (serwer WWW) w celu aktualizacji / instalacji za pośrednictwem panelu administracyjnego, a następnie przywróć powrót do „root” lub użytkownika po zakończeniu.

chown -R www-data /var/www/html

I w Nginx (ta sama procedura dla apache), aby chronić folder wp-admin przed nieautoryzowanym dostępem i sondowaniem. apache2-utils jest wymagany do szyfrowania hasła, nawet jeśli masz zainstalowany nginx, pomiń c, jeśli planujesz dodać więcej użytkowników do tego samego pliku.

sudo apt-get install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd userName

Teraz odwiedź tę lokalizację

/etc/nginx/sites-available/

Użyj tych kodów, aby zabezpieczyć folder „wp-admin” hasłem, teraz poprosi o hasło / nazwę użytkownika, jeśli spróbujesz uzyskać dostęp do „wp-admin”. Uwaga, tutaj używasz pliku „.htpasswd”, który zawiera zaszyfrowane hasło.

location ^~ /wp-admin {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    index  index.php index.html index.htm;
}

Teraz uruchom ponownie nginx.

sudo /etc/init.d/nginx restart

Polecenia:

chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Gdzie użytkownik ftp to użytkownik, którego używasz do przesyłania plików

chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content

Aby absolutnie upewnić się, że witryna jest bezpieczna i korzystasz z odpowiednich uprawnień do swoich folderów, użyj wtyczki bezpieczeństwa takiej jak te:

https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/

https://en-ca.wordpress.org/plugins/wordfence/

Wtyczki te skanują instalację Wordpress i powiadamiają o potencjalnych problemach. Ostrzegają one również przed niebezpiecznymi uprawnieniami do folderów. Oprócz tego wtyczki te zalecają, jakie uprawnienia należy przypisać do folderów.

chown -Rv www-data:www-data
chmod -Rv 0755 wp-includes
chmod -Rv 0755 wp-admin/js
chmod -Rv 0755 wp-content/themes
chmod -Rv 0755 wp-content/plugins
chmod -Rv 0755 wp-admin
chmod -Rv 0755 wp-content
chmod -v 0644 wp-config.php
chmod -v 0644 wp-admin/index.php
chmod -v 0644 .htaccess

Nie mogę powiedzieć, czy jest to poprawne, ale używam obrazu Bitnami w Google Compute App Engine. Mam problemy z wtyczkami i migracją, a po dalszych problemach z uprawnieniami chmod'ing znalazłem te trzy linie, które rozwiązały wszystkie moje problemy. Nie jestem pewien, czy to właściwy sposób, ale działało dla mnie.

sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type f -exec chmod 664 {} \;
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type d -exec chmod 775 {} \;

W systemie OS X użyj tego polecenia:

sudo chown -R www:www /www/folder_name

Zdefiniuj w pliku wp_config.

/var/www/html/Your-Project-File/wp-config.php

define( 'FS_METHOD', 'direct' );

chown - zmienia własność plików / katalogów. To znaczy. właściciel pliku / katalogu zmienia się na podany, ale nie modyfikuje uprawnień.

sudo chown -R www-data:www-data /var/www

Na podstawie wszystkich odczytów i udręki na moich stronach i po zhakowaniu wymyśliłem powyższą listę, która zawiera uprawnienia do wtyczki bezpieczeństwa dla Wordpress o nazwie Wordfence. (Nie związany z tym)

W naszym przykładzie katalog główny dokumentu wordpress to /var/www/html/example.com/public_html

Otwórz uprawnienia, aby dane www mogły zapisywać do katalogu głównego dokumentu w następujący sposób:

cd /var/www/html/example.com
sudo chown -R www-data:www-data public_html/

Teraz z pulpitu nawigacyjnego w Twojej witrynie, jako administrator, możesz przeprowadzać aktualizacje.

Bezpieczna witryna po zakończeniu aktualizacji, wykonując następujące kroki:

sudo chown -R wp-user:wp-user public_html/

Powyższe polecenie zmienia uprawnienia do wszystkiego w instalacji wordpress dla użytkownika FTP wordpress.

cd public_html/wp-content
sudo chown -R www-data:wp-user wflogs
sudo chown -R www-data:wp-user uploads

Powyższe polecenie zapewnia, że ​​wtyczka bezpieczeństwa Wordfence ma dostęp do swoich dzienników. Katalog uploads jest również zapisywalny przez www-data.

cd plugins
sudo chown -R www-data:wp-user wordfence/

Powyższe polecenie zapewnia również, że wtyczka bezpieczeństwa wymagała dostępu do odczytu i zapisu w celu prawidłowego działania.

Uprawnienia do katalogów i plików

# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;

# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;

Ustaw uprawnienia dla wp-config.php na 640, aby tylko wp-użytkownik mógł czytać ten plik i nikt inny. Uprawnienia 440 nie działały dla mnie z powyższą własnością pliku.

sudo chmod 640 wp-config.php

Automatyczne aktualizacje Wordpress przy użyciu SSH działały poprawnie z PHP5, ale zepsuły się z PHP7.0 z powodu problemów z pakietem php7.0-ssh2 z Ubuntu 16.04 i nie mogłem znaleźć sposobu, aby zainstalować odpowiednią wersję i sprawić, by działała. Na szczęście bardzo niezawodna wtyczka o nazwie ssh-sftp-updater-support (darmowa) umożliwia automatyczne aktualizacje przy użyciu SFTP bez potrzeby korzystania z libssh2. Tak więc powyższe uprawnienia nigdy nie muszą być poluzowane, z wyjątkiem rzadkich przypadków w razie potrzeby.