Права на файлы 644 и 755: почему 777 это дыра
Что означают цифры прав, какие нужны WordPress и Битриксу, чем опасен chmod 777 и как выставить права по всему сайту одной командой.
Содержание
- Как читаются три цифры
- Рабочий стандарт: 644 на файлы, 755 на папки, 600 на wp-config.php
- Почему 777 это не «чтобы заработало», а приглашение
- Как выставить права по всему сайту одной командой
- Владелец файлов и почему сайт «перестаёт обновляться» после FTP
- Быстрая проверка: что не так на вашем сайте прямо сейчас
- Что делать после того, как права поправлены
- Частые вопросы
Рабочий стандарт простой: 644 на файлы, 755 на папки, 600 на конфигурационный файл с паролями базы. Права 777 не чинят проблему, а открывают папку на запись всем, и именно так в загрузки заезжает чужой скрипт.
«Права на файлы» звучит как формальность из инструкции хостера, пока антивирус не находит в uploads очередной шелл, залитый через папку, которую кто-то когда-то открыл на 777, чтобы плагин заработал. Эта статья для тех, кто держит сайт на WordPress, Битриксе или самописной CMS и настраивает права через SSH, FTP-клиент или файловый менеджер в панели хостинга. Разберём, как читаются цифры вроде 644 и 755, какой стандарт держать на shared-хостинге, почему 777 быстро превращается в заражение, и как проверить и поправить права по всему сайту одной командой, не задев соседние домены в том же аккаунте.
Как читаются три цифры
На любом обычном хостинге сайт лежит на Linux, а права доступа записываются тремя цифрами: 644, 755, 600, 777. Каждая цифра относится к своей категории пользователей.
Первая цифра — права владельца файла (owner), то есть того аккаунта, от имени которого файл создан. Вторая — права группы (group), в которую входит владелец и, возможно, ещё кто-то на том же сервере. Третья — права для всех остальных (other), то есть буквально для любого процесса на сервере, у которого нет причин иметь доступ к вашему сайту.
Внутри каждой цифры зашита сумма трёх битов: 4 за чтение (read), 2 за запись (write), 1 за выполнение (execute). Складываете нужные биты — получаете цифру.
| Цифра | Права | Что означает |
|---|---|---|
| 7 | rwx | чтение, запись, выполнение |
| 6 | rw- | чтение и запись, без выполнения |
| 5 | r-x | чтение и выполнение, без записи |
| 4 | r— | только чтение |
| 0 | — | ничего |
644 значит rw-r—r—: владелец читает и пишет, группа и все остальные только читают. 755 значит rwxr-xr-x: владелец делает всё, группа и остальные читают и заходят внутрь папки (для каталогов execute означает право войти в него и посмотреть содержимое, это не то же самое, что запуск программы). Команда ls -la в SSH-сессии показывает эти права построчно: drwxr-xr-x перед именем папки, -rw-r--r-- перед именем файла.
Рабочий стандарт: 644 на файлы, 755 на папки, 600 на wp-config.php
Для подавляющего большинства сайтов на shared-хостинге годится один и тот же набор, и не нужно ничего изобретать под конкретную CMS.
| Что | Права | Комментарий |
|---|---|---|
| Обычные файлы (.php, .css, .js) | 644 | владелец пишет, остальные только читают |
| Папки | 755 | нужен execute, чтобы веб-сервер мог заходить внутрь |
| wp-config.php / bitrix/php_interface/dbconn.php | 600 или 640 | в файле пароль от базы, лишний доступ ни к чему |
| .htaccess | 644 | читает веб-сервер, редко нужна запись извне |
| wp-content/uploads | 755 на папки, 644 на файлы | без исполняемого бита у файлов |
С wp-config.php есть тонкость. На хостинге с suPHP или PHP-FPM, где PHP-процесс выполняется от имени вашего же аккаунта, 600 работает без проблем: файл читает тот же пользователь, что им и владеет. На старых конфигурациях с mod_php, где Apache работает от отдельного системного пользователя (обычно www-data), 600 сломает сайт, потому что веб-сервер физически не сможет прочитать файл. Там нужна группа: chown user:www-data wp-config.php && chmod 640. Какая у вас схема, видно в панели хостинга или одной командой:
ps aux | grep php-fpmЕсли в выводе есть процесс php-fpm с именем вашего пользователя, у вас suPHP-подобная схема и 600 безопасен. Если php-fpm нет вообще и работает apache2/httpd от www-data, аккуратнее с 600 на файлы, которые Apache должен читать напрямую (не через сам PHP).
Почему 777 это не «чтобы заработало», а приглашение
Совет поставить 777 всплывает регулярно: не грузится картинка, не сохраняются настройки плагина, WordPress просит FTP-доступ при обновлении. Кто-то в комментариях на форуме советует «выставь 777 и не думай», проблема правда исчезает, и на этом человек забывает, что вообще что-то менял.
Дальше сценарий типовой. Уязвимый плагин или тема даёт возможность залить произвольный файл (обычно через форму загрузки без проверки расширения или через устаревшую библиотеку вроде старого TimThumb). Если папка, куда падает файл, открыта на 777, вредоносный PHP-файл записывается туда без проблем и тут же исполняется, потому что исполняемый бит тоже стоит. Дальше шелл может дотянуться до соседних файлов сайта: если у них тоже 777, он их правит, дописывает свой код в footer.php темы, создаёт скрытого администратора, рассылает спам через ваш сервер.
Я разбирал десятки таких заражений, и почти в каждом на входе была одна открытая на 777 папка, про которую владелец давно забыл. Она не обязана быть uploads: это может быть кэш плагина, папка временных файлов импортёра, каталог логов. Достаточно одной дыры, чтобы через неё занесли всё остальное.
Отдельная проблема: часть хостингов (особенно с встроенным сканером вроде ClamAV или собственной защитой панели) автоматически помечает файлы и папки с правами 777 как подозрительные и может временно заблокировать сайт до выяснения, даже если заражения ещё не произошло. То есть 777 иногда наказывают ещё до того, как им воспользовался злоумышленник.
Если после заражения потребовалась чистка, порядок действий и что смотреть в первую очередь я подробно разбирал в статье про то, как очистить WordPress от вирусов. А по каким признакам вообще понять, что сайт уже заражён, до того как об этом сообщит хостинг или клиент, смотрите в материале про признаки взлома сайта.
Как выставить права по всему сайту одной командой
Через SSH это делается за пару минут. Логика простая: у всех папок должно быть 755, у всех файлов 644, дальше точечно поджимаем то, что нужно закрыть плотнее.
cd /home/user/site.ru/public_html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.phpТри команды: сначала все директории получают 755, потом все файлы 644, потом отдельно поджимается конфиг с паролем от базы. Для Битрикса аналогично, только приводить в порядок нужно bitrix/php_interface/dbconn.php.
Важный момент про безопасность самой операции. find . работает от текущей директории и ниже, поэтому если вы находитесь не внутри папки конкретного сайта, а выше, в корне хостинг-аккаунта, где лежит несколько доменов, команда пройдётся по всем ним разом. На части тарифов один аккаунт хостинга держит несколько независимых сайтов клиента (или чужих проектов), и массовый chmod по всему аккаунту может случайно поменять права у сайта, который вас вообще не касается. Правило простое: перед запуском find всегда проверяйте pwd, чтобы убедиться, что вы внутри нужного docroot, и никогда не запускайте такую команду от корня без явного пути.
Если через FTP-клиент, у большинства (FileZilla, WinSCP) есть пункт меню «изменить права доступа» с галочкой «применить рекурсивно к вложенным папкам». Работает так же, но для файлов и папок нельзя задать разные значения за один проход: придётся сделать два прохода, сначала выставить 755 на всё, затем отдельно выбрать только файлы и поставить 644 (или наоборот, начиная с 644 и поднимая права папкам). Через SSH быстрее и без риска промахнуться галочкой.
Владелец файлов и почему сайт «перестаёт обновляться» после FTP
Есть вторая переменная, о которой забывают: владелец файла (owner), а не только права. Если вы заливаете файлы через FTP-аккаунт, привязанный к другому системному пользователю, чем тот, от имени которого работает PHP на сайте, файлы физически принадлежат чужому пользователю. Права могут стоять правильные (644/755), но WordPress при попытке автообновления плагина или ядра получает classic «Не удалось создать директорию» или тихо падает в фоновом режиме без внятной ошибки, потому что процесс PHP не владелец файла и не входит в его группу.
Проверить владельца:
ls -la wp-content/plugins/ | head -20В третьей и четвёртой колонке вывода видно пользователя и группу. Если у файлов темы стоит, например, ftpuser ftpuser, а сайт крутится от site_user, вот и причина, почему обновления не проходят молча. Чинится либо через панель хостинга (там обычно есть «восстановить владельца» одной кнопкой), либо командой chown -R site_user:site_user . от имени пользователя, у которого есть на это право (на shared-хостинге это обычно можно сделать только для файлов внутри своего же аккаунта, root-доступа нет и не нужен).
Отдельно стоит следить за тем, что творится после переезда на новый хостинг: если контент копировался архивом и распаковывался под другим пользователем, owner может съехать по всему дереву сайта разом, и тогда обновления перестают работать сразу после переезда, что легко списать на что угодно другое. Порядок действий при самом переезде я разбирал в статье про перенос сайта на новый хостинг.
Быстрая проверка: что не так на вашем сайте прямо сейчас
Прогоните по сайту короткий чек-лист. Занимает пять минут через SSH, дольше через файловый менеджер панели.
- [ ] wp-config.php стоит не 644, а 600 или 640
- [ ] Нигде в дереве сайта нет файлов и папок с правами 777
- [ ] В uploads нет .php-файлов вообще (их там не должно быть в принципе)
- [ ] Владелец файлов совпадает с пользователем, от имени которого работает PHP
- [ ] .htaccess не даёт запись всем подряд
- [ ] После правки прав сайт открывается без ошибок 500 и админка работает
Найти всё, что открыто на 777, одной командой:
find /home/user/site.ru/public_html -perm 777Если список не пустой, для каждой строки нужно решить: это папка, куда что-то реально должно писаться (тогда 755, а если процессу нужна запись, то владелец должен физически совпадать с процессом PHP), или забытая дыра, которую можно смело поджать до 755/644 прямо сейчас.
Отдельно стоит проверить файлы, у которых стоит исполняемый бит там, где ему взяться неоткуда: обычная картинка или текстовый файл с правами вроде 755 или 777 это красный флаг, потому что легитимному контенту execute не нужен никогда.
find /home/user/site.ru/public_html -type f -name "*.php" -perm -o+wЭта команда находит PHP-файлы, доступные на запись кому угодно (other has write), то есть потенциальные точки, куда веб-шелл может дописать себя незаметно для владельца.
Что делать после того, как права поправлены
Сами по себе правильные права не заменяют остальную гигиену: обновлённые плагины, сложные пароли и двухфакторную аутентификацию для админки, о которой стоит почитать отдельно, если её ещё нет: двухфакторная аутентификация для админки. Но без корректных прав любая из остальных мер работает наполовину: даже самый свежий плагин без единой уязвимости не спасёт, если рядом лежит папка на 777, через которую можно записать файл в обход всей защиты.
Если разбираться в правах и логах самому некогда, а на сайте уже есть подозрительная активность (внезапные редиректы, новые файлы с датой изменения не вашей рукой, письма от хостинга про подозрительную активность), быстрее написать сразу через форму на главной и разобрать конкретно ваш случай, чем гадать по чужим гайдам, что из перечисленного применимо к вашей конфигурации.
Частые вопросы
Какие права должны быть на файлы сайта
644 для файлов, 755 для папок, 600 для конфигурации с доступами к базе. Больше ничего не нужно. Любая популярная CMS с этим работает.
Почему нельзя ставить 777
Потому что это разрешает запись всем, включая процессы других пользователей сервера. На части хостингов сервер вообще отказывается отдавать такие файлы, а на остальных это готовая точка для заливки чужого кода.
Что делать, если плагин требует 777
Проверить владельца файлов, а не открывать доступ всем. Почти всегда проблема в том, что файлы принадлежат не тому пользователю, от которого работает веб-сервер.
Почему сайт перестал обновляться после загрузки по FTP
Потому что залитые файлы принадлежат FTP-пользователю, а обновления ставит веб-сервер от своего имени. Лечится сменой владельца, а не правами 777.
