У прав на файлы в WordPress скучная репутация. Мол, технарская мелочь, копаться в ней лень, сайт же и так открывается. А потом кто-то ставит папкам 777, файлам 775 где попало, и через месяц в uploads уже лежит тихий шелл. Без шума. Без красивого «вас взломали». Просто сайт потихоньку работает на кого-то еще.
И вот это как раз обидно — проблема часто не в «суперхакерах», а в одной плохой настройке. Маленький магазин, сайт услуг, лендинг с формой заявки — неважно. Если права выставлены криво, вы сами оставляете дверь приоткрытой.
Смотрите, разберем по-человечески: что вообще значат эти 755, 775, 644, где они опасны, и что реально стоит проверить сегодня, а не когда хостинг уже пришлет письмо. Кстати, если такое письмо уже прилетало, вот полезный разбор: почему письмо хостинга «malware detected» часто приходит слишком поздно.
Что такое права на файлы — без занудства
Если совсем просто, права говорят серверу, кто может читать, менять или запускать файл.
Есть три группы:
- владелец
- группа
- все остальные
И три базовых действия:
- read — читать
- write — менять
- execute — запускать
Отсюда и цифры:
- 7 = читать + писать + запускать
- 6 = читать + писать
- 5 = читать + запускать
- 4 = только читать
Например, 755 для папки — это окей в большинстве случаев. Владелец может все, остальные — только читать и заходить в папку. А 644 для файла — тоже нормальная история: владелец меняет, остальные только читают.
Проблемы начинаются когда права раздают щедро. Особенно «на время». Особенно после фразы «поставлю 777, потом верну». Не вернут. Почти никогда.
Почему именно 775 иногда становится проблемой
Сразу честно — 775 не всегда зло. Бывают хостинги и схемы запуска PHP где такая настройка работает штатно. Но вот где начинается скользкий момент: если веб-сервер и ваш пользователь сидят в одной группе, а в эту группу попадает право на запись, то сайт может менять файлы там, где лучше бы не мог.
И тут уже вопрос не «сломается ли». Сломаться как раз может не сразу. Опасность в другом — если уязвимый плагин дал атакующему загрузить PHP-файл или изменить существующий, право на запись сильно упрощает жизнь.
Типичный сценарий выглядит так:
- На сайте стоит старая форма или плагин галереи.
- Через дыру заливают файл в папку, где сервер может писать.
- Потом этот файл запускают как код.
- Дальше уже подкладывают бэкдор в тему,
mu-plugins,wp-config.phpили куда поинтереснее.
То есть 775 сам по себе не «взламывает» сайт. Но он часто делает последствия уязвимости намного хуже. Как будто у вас в офисе слабый замок — и еще дверь на ночь не до конца закрыта. Вот примерно так.
Где права чаще всего выставлены криво
На практике я чаще всего вижу три места.
1. Папка uploads
Самая любимая точка проблем. Потому что туда постоянно что-то грузят — фото товаров, PDF, баннеры, аватарки. Если там еще и выполнение PHP не прикрыто, то это просто подарок для атакующего. Загрузил «картинку», а внутри код. И привет.
2. wp-content целиком
Иногда кто-то не разбираясь ставит 775 или 777 на весь wp-content, чтоб «плагин мог писать кеш». В итоге писать может не только кеш-плагин. И не только он. Плохая идея.
3. wp-config.php
Это вообще сердце сайта — база, ключи, префикс таблиц, местами кастомные настройки. Если до него можно дотянуться на запись, вы уже играете в лотерею. По теме советую потом почитать: укрепление wp-config.php: 5 констант, которые почти никто не задает.
Какие права обычно нормальные
Для обычного сайта на WordPress, без экзотики, безопасный минимум чаще всего такой:
- папки — 755
- файлы — 644
wp-config.php— 600 или 640, иногда 440, если все работает
Но — и это важно — не надо менять все вслепую на проде в пятницу вечером. Да, видел и такое. Сайт потом лег, потому что кеш, деплой или cron работали под другой учеткой.
Если у вас VPS или нестандартный хостинг, сперва посмотрите от какого юзера крутится PHP-FPM или Apache. Иначе можно «улучшить» безопасность так, что магазин перестанет загружать изображения. Тоже весело, конечно, но не очень.
Как понять, есть ли у вас риск прямо сейчас
Вот короткая проверка, которая занимает минут 10-15.
- Откройте файловый менеджер в панели хостинга или зайдите по SFTP.
- Проверьте права у
wp-config.php,wp-content,uploads, папки темы и плагинов. - Ищите все, что шире чем 755 для папок и 644 для файлов.
- Отдельно посмотрите, нет ли PHP-файлов внутри
/uploads/. - Проверьте владельца файлов — после «ремонта» сайта через FTP там часто каша.
Если нашли 777 — это уже не «потом разберемся». Это разберитесь сейчас. Если нашли кучу странных файлов вроде class-wp-vcd.php, 1index.php, admin-new.php в неожиданных местах — тоже не тяните.
И да, если сайт уже ведет себя странно — редиректы, новые админы, спам-страницы, непонятные PHP в uploads — проще сразу идти в очистку, а не гадать. Для таких случаев есть отдельная помощь: если сайт взломан — очистка и восстановление.
Почему «сайт же обновляется сам» не спасает
Потому что безопасность — это не одна кнопка. Можно обновлять WordPress хоть день в день, но держать папки с правом на запись для всего подряд. И тогда одна уязвимость в плагине превратится из «ну неприятно» в «на сервере живет бэкдор уже третью неделю».
Особенно это касается старых сайтов малого бизнеса. Их обычно делали давно, потом меняли подрядчиков, потом кто-то правил через FTP, потом хостинг переезжал. В итоге права наследуются абы как. Где-то 755, где-то 775, где-то вообще owner один, group другая, а половина файлов залита под root. Красота. Но не та.
Короче, обновления — да. Но еще нужны нормальные права, контроль загрузок, защита входа, мониторинг изменений файлов. Не все сразу за кучу денег. Честно, большинству маленьких сайтов хватает базовой дисциплины и пары нормальных настроек.
Что сделать, чтобы 775 не превратился в дыру
Вот практичный набор без фанатизма:
- приведите папки к 755, файлы к 644
- ужмите
wp-config.phpсильнее, если сайт не ломается - запретите выполнение PHP в
uploads, если архитектура сайта это терпит - удалите старые плагины и темы, которые не используете
- проверьте владельца файлов после миграций и «срочных правок»
- настройте регулярное обслуживание хотя бы раз в месяц
По деньгам? Если делать вручную и понимать, что вы делаете — это 20-40 минут. Если сайт старый и там бардак, может уйти часа два. Если подключать регулярную поддержку, это обычно дешевле одного нормального инцидента со взломом. Потому что после взлома вы платите уже не только за чистку — еще за простой сайта, рекламу в минус, потерянные заявки и нервы. А нервы самые дорогие, да.
Если не хотите ковыряться сами, логичнее держать сайт на регулярном обслуживании WordPress, где такие штуки проверяют до того как они вылезут боком.
Когда руками лучше не трогать
Есть ситуации где я бы не советовал играться с chmod самому:
- WooCommerce-магазин с кастомной интеграцией склада
- сайт на VPS, где вы не уверены кто владелец файлов
- проект после взлома, но «вроде уже все почистили»
- мультисайт или старый проект с самописными модулями
Почему? Потому что можно замаскировать проблему, а не решить ее. Или сломать загрузку, кеш, обновления, экспорт заказов. А потом сидеть ночью и вспоминать, зачем вообще полезли.
И кстати, если сайт уже однажды заражался и потом «успешно ожил», это еще ни о чем не говорит. Бэкдор мог остаться в файле темы, в базе, в mu-plugins — где угодно.
Итог — права на файлы не скучная мелочь
Вот в чем суть: 775 не всегда ошибка. Но когда права на запись получают не те места и не те процессы, это тихо превращает обычную уязвимость в полноценный вход для атакующего.
Самое неприятное, что сайт может выглядеть нормальным. Заказы идут. Формы работают. А внутри уже сидит мусоррный PHP-файл, который ждет команды.
Поэтому минимум такой: проверьте права, владельца файлов, uploads, wp-config.php и список старых плагинов. Сегодня. Не когда «будет время». У малого бизнеса с сайтом время на такое обычно появляется ровно после проблемы. Вот это лучше не повторять.
И да — если что-то смущает, лучше перепроверить, чем махнуть рукой. В безопасности WordPress мелочи как раз и кусаются больнее всего.