Безопасные права на файлы и каталоги WordPress: практическая настройка

Что означают права 644, 755 и 777

В Linux права записываются тремя цифрами: отдельно для владельца, группы и остальных пользователей. Значение 4 означает чтение, 2 — запись, а 1 — выполнение. Для обычного файла 644 означает, что владелец может читать и изменять файл, а группа и остальные пользователи — только читать его.

Для каталога право на выполнение означает возможность войти в каталог и обратиться к его содержимому. Поэтому для каталогов обычно устанавливают права 755: владелец может читать, изменять и просматривать содержимое, а остальные пользователи — просматривать каталог и открывать файлы без права записи.

Права 777 предоставляют всем пользователям возможность читать, записывать и выполнять файлы. Для WordPress это почти никогда не является оправданным решением. Если плагин или хостинг требуют 777, сначала выясните причину, связанную с владельцем, группой, PHP-FPM или политикой записи, а не просто расширяйте доступ.

• Файлы WordPress: базовое значение 644.
• Каталоги: базовое значение 755.
• wp-config.php: 640 или более строгие права, если это совместимо с конфигурацией сервера.
• Не используйте 777 для файлов, каталогов или uploads.

Рекомендуемая схема для структуры WordPress

Для большинства сайтов достаточно начать с 644 для файлов и 755 для каталогов. Такая схема позволяет веб-серверу читать сайт, но не предоставляет всем системным пользователям права на запись. При этом фактические требования зависят от модели хостинга: PHP может работать от имени пользователя сайта, пользователя веб-сервера или отдельного пула PHP-FPM.

В wp-config.php хранятся данные для подключения к базе, ключи безопасности и другие важные параметры. Права можно ограничить до 640, если процесс PHP получает доступ через владельца или группу. Значение 600 является более строгим, но будет работать только в том случае, если PHP действительно запускается от имени владельца файла.

В некоторых конфигурациях wp-config.php можно разместить на уровень выше корневого каталога WordPress. Это снижает риск прямого доступа к файлу, но не заменяет правильные права и настройки веб-сервера.

• Корневые PHP-файлы, .htaccess и другие служебные файлы: обычно 644.
• wp-admin, wp-includes, wp-content и вложенные каталоги: обычно 755.
• Файлы в wp-content/uploads: обычно 644, каталоги — 755.
• Резервные копии, дампы базы данных и приватные ключи не должны храниться в публичном каталоге с открытым доступом на чтение.

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 640 /path/to/wordpress/wp-config.php

Почему эти команды нельзя запускать без проверки

В примере необходимо заменить путь на фактический корневой каталог сайта. Не запускайте команды с неправильным путем или сразу для всего сервера: это может изменить права системных файлов и нарушить работу других сайтов. После изменения проверьте главную страницу, административную часть, загрузку медиафайлов и обновления, если они необходимы.

Если после усиления защиты WordPress не может записать файл, не переходите автоматически на 777. Сначала проверьте владельца, группу и права конкретного каталога, которому действительно нужна запись.

Владелец и группа важнее самих цифр

Права 644 не делают файл безопасным, если его владелец или группа настроены неправильно. Например, процесс веб-сервера может иметь доступ на запись через группу, хотя визуально права выглядят стандартными. И наоборот, WordPress может не иметь возможности обновлять файлы, если они принадлежат другому системному пользователю.

Более безопасная модель для рабочего сайта — отдельный системный пользователь для каждого сайта, ограниченная группа и отсутствие общего доступа на запись между разными сайтами на одном сервере. Владельцем файлов не должен быть случайный пользователь, от имени которого работают все виртуальные хосты.

После миграции проверьте владельца и группу с помощью команды ls или stat. Не меняйте владельца вслепую: имя пользователя веб-сервера зависит от дистрибутива, панели управления и схемы работы PHP.

• Проверьте, кто является владельцем корневого каталога WordPress и wp-content.
• Убедитесь, что один сайт не может изменять файлы другого.
• Выясните, от имени какого пользователя работает PHP-FPM или другой обработчик PHP.
• Для массового изменения владельца используйте точный путь и заранее создайте резервную копию.

stat -c '%A %U:%G %n' /path/to/wordpress/wp-config.php
find /path/to/wordpress -maxdepth 2 -printf '%M %u:%g %p\n' | head -50

Особый контроль каталога wp-content/uploads

Каталог uploads предназначен для изображений, документов и других загружаемых файлов. Пользователи или плагины могут записывать туда файлы, поэтому этот каталог часто становится целью для загрузки вредоносного кода.

Одних прав 755 недостаточно, чтобы запретить выполнение PHP. Они определяют доступ к файловой системе, тогда как возможность выполнения также зависит от конфигурации Apache, Nginx, PHP-FPM и правил обработки расширений. Поэтому в uploads необходимо отдельно запретить выполнение PHP-кода на уровне веб-сервера.

Не храните в uploads резервные копии, дампы базы данных, конфигурационные файлы или архивы с паролями. Если такие файлы уже находятся там, перенесите их за пределы публичного корня или закройте доступ к ним с помощью соответствующих правил.

• Не устанавливайте 777 для wp-content/uploads.
• Запретите выполнение PHP в каталоге загрузок на уровне веб-сервера.
• Проверьте, что загруженные файлы нельзя открыть по URL, если они должны оставаться приватными.
• Ограничьте тип и размер файлов средствами WordPress, сервера или WAF.

Важное предупреждение для Apache и Nginx

Правила запрета выполнения PHP зависят от веб-сервера и его конфигурации. Для Apache это может быть отдельное правило в конфигурации каталога, а для Nginx — корректная схема location и передача запросов в PHP-FPM. Неправильный универсальный фрагмент может заблокировать все файлы или создать ложное ощущение защищенности.

Перед изменениями проверьте конфигурацию в тестовой среде или попросите администратора сервера применить политику именно для uploads. После этого убедитесь, что обычные изображения открываются, а тестовый PHP-файл не выполняется.

Как проверить права после миграции или восстановления

Миграции, распаковка архивов и восстановление резервных копий часто меняют владельца или добавляют файлы с избыточными правами. Плагин также может создать каталог с правами, отличающимися от общей схемы. Проверяйте не только корень сайта, но и wp-content, uploads, plugins, themes и новые файлы.

Для поиска избыточных прав полезно отдельно проверять файлы и каталоги. Не каждый результат автоматически означает уязвимость, но права 666, 775 или 777 требуют объяснения. Особенно внимательно проверяйте PHP-файлы, которые появились не в ходе планового обновления.

• Найдите файлы, доступные для записи всем пользователям.
• Найдите каталоги с правами 777 или 775 и проверьте, зачем они нужны.
• Проверьте дату, владельца и происхождение новых PHP-файлов.
• После проверки протестируйте сайт, панель администратора, медиатеку и работу кеширования.

find /path/to/wordpress -type f -perm -002 -ls
find /path/to/wordpress -type d \( -perm -002 -o -perm -020 \) -ls
find /path/to/wordpress -type f -name '*.php' -printf '%M %u:%g %TY-%Tm-%Td %p\n' | sort

Типичные ошибки и безопасный порядок действий

Самая распространенная ошибка — исправлять ошибку записи командой chmod -R 777. Это маскирует проблему с владельцем или группой и одновременно увеличивает последствия компрометации другой учетной записи на сервере.

Вторая ошибка — установить 640 для всех файлов без проверки. Некоторые конфигурации сервера не смогут прочитать нужные файлы, если PHP или веб-сервер не входят в соответствующую группу. Также не следует бездумно устанавливать 700 для всех каталогов: сайт может потерять доступ к необходимым ресурсам.

Действуйте поэтапно: создайте резервную копию, зафиксируйте текущие права, измените права на одном сайте или тестовой копии, проверьте функции и только после этого применяйте изменения на рабочем сайте. Дополнительно ограничьте доступ по SSH, обновляйте WordPress и плагины, используйте резервные копии и мониторинг изменений.

• Не путайте права доступа с правилами веб-сервера: необходимы оба уровня защиты.
• Не удаляйте незнакомые файлы без резервной копии и анализа.
• Не оставляйте архивы миграции в публичном каталоге.
• Храните отдельные резервные копии за пределами сервера и периодически проверяйте их восстановление.