ANTICHAT - Почему важно закрывать служебные файлы CMS

Почему важно закрывать служебные файлы CMS — стоит ли использовать?

Текст:

Введение
Довольно часто встречаюсь с ситуациями, когда владельцы сайтов и форумов на CMS даже не задумываются о том, что служебные файлы нужно хорошо прятать от чужих глаз. А между тем, именно через них чаще всего складываются последние пазлы успешного взлома — утечка базы, попадание кода, использование уязвимостей. Это не какая-то навязчивая паранойя, а элементарная базовая защита. Давайте подробно разберём, почему закрывать служебные файлы — не просто полезно, а жизненно необходимо, и какие реальные шаги для этого можно предпринять.

Почему это важно
Вся суть в том, что служебные файлы — это хранилища ключевых данных: базы, паролей, настроек сервера и CMS, иногда даже секретных ключей для API и платежей. Если вам кажется, что в папке сайта эти файлы ни для кого не видны — не обольщайтесь. Web-серверы по умолчанию нередко отдают любые файлы, если не запрещены правилами. Отсюда и весь трэш: кто угодно может скачать config.php и узнать ваши пароли, посмотреть точные версии плагинов и попытаться подобрать методы атак.

Какие файлы обычно закрывают
Чаще всего это:
- config.php и похожие конфиги с настройками базы и путями;
- .env файлы с переменными окружения;
- backup и dump-файлы баз без ограничения доступа;
- временные файлы и логи, которые могут хранить пароли;
- панели администрирования и инсталляторы, которые забыли удалить после запуска;
- файлы с ключами API и прочими «секретами».

Где и как это происходит?
В основном закрытие происходит на уровне веб-сервера с помощью специальных настроек в .htaccess для Apache или в конфигурациях nginx. Например, можно полностью запретить доступ к файлам .env, *.ini, *.config, *.bak, *.sql, *.log и т.д. для публичной части сайта.
К тому же, перед публикацией на сервер желательно проверить права — чтобы конфиги не были доступны для чтения всем, а только для нужных пользователей (640, 600).
Кстати, часто именно неаккуратность в правах и забытые файлы в корне становятся причиной проблем.

Примеры из жизни
1. На одном из форумов на phpBB я лично видел, что config.php был доступен по прямой ссылке. Там лежали реальные пароли от базы. Хакерам понадобилось минут 10, чтобы получить полный контроль.
2. Другая ситуация — админ забыл удалить backup-файл SQL потом, как поднял бэкап на боевом сервере, и этот файл индексировался поисковиками. Спамеры нашли его и использовали скомпрометированные данные для рассылок.
3. В WordPress довольно часто встречается открытый wp-config.php из-за неверных настроек или копирования с локального сервера на продакшен. Плюс злоумышленники через открытые конфиги узнают, какие версии плагинов используются, и подбирают эксплоиты.

Типичные ошибки, которые допускают
- Пренебрежение проверкой прав доступа на файлы (часто стоит 644 — читать может кто угодно).
- Отсутствие специальных правил закрытия в .htaccess/nginx, то есть забывают или не знают.
- Забытые резервные файлы, которые лежат в открытой папке, как backup.sql или config.php.bak.
- Перемещение админпанели в публичный каталог без настройки ограничений (например, IP-фильтрация или пароль).
- Использование общедоступных публичных папок для временных и системных файлов.
- Отсутствие регулярного аудита безопасности — никто не проверяет, не появились ли новые уязвимости или файлы.

Как правильно закрывать?

1. Установить нужные права доступа: для конфигов — минимум 640, лучше 600.
2. В .htaccess прописать запреты на доступ к важным типам файлов:

- запрет на *.ini, *.log, *.env, *.bak, *.sql и прочие архивы и дампы;
- запрет доступа к системным скрытым файлам, начинающимся с точки.
3. Для nginx добавить в конфиг похожие запреты с директивами location или deny.
4. Удалять временные и резервные файлы после операций с сайтом.
5. По возможности ограничить IP или поставить пароль на админку.
6. Использовать плагины безопасности, которые автоматически защищают служебные URL.
7. Регулярно сканировать сайт на наличие открытых конфигов и недоступных файлов.

Чек-лист проверки безопасности служебных файлов
- Проверьте права на все конфигурационные файлы (config.php, wp-config.php, .env и т. д.).
- Убедитесь, что в корне и подкаталогах нет резервных файлов с чувствительной информацией (*.bak, *.sql, *.old).
- Настройте запреты доступа к определённым типам файлов через .htaccess или конфиг nginx.
- Проверьте, что панели администрирования не доступны без авторизации и ограничены по IP.
- Запустите онлайн-сканеры безопасности или утилиты для проверки открытых файлов.
- Контролируйте логи и временные файлы, чтобы в них не попадали пароли или токены.
- Дважды проверьте, что после обновлений CMS и плагинов не появились новые уязвимости, связанные с файлами.
- Настройте уведомления о незнакомых файлах на сервере (с помощью мониторинга файловой системы).

Популярные инструменты для контроля
- Wordfence (для WordPress) — помогает блокировать вредоносный и подозрительный доступ.
- Nessus, OpenVAS — сканеры сети и поиска уязвимостей.
- Tripwire fs — для мониторинга изменений в файловой системе.
- Онлайн-сервисы проверки типа Sucuri SiteCheck.
- Skript проверки прав доступа — можно написать на Bash или Python, чтобы поднимать тревогу.

FAQ

— Нужно ли закрывать абсолютно все служебные файлы?
Лучше закрывать всё, что не предназначено для публичного просмотра: конфиги, логи, бэкапы, временные файлы, дампы баз. Если файл не нужен в открытом доступе, его нужно либо убрать, либо ограничить.

— Как понять, что закрытые файлы действительно недоступны?
Самый простой способ — попытаться открыть их в браузере и получить ошибку 403 или 404. Также можно использовать curl или wget с запросом к этим файлам и смотреть заголовки ответа. Если файл скачивается или его содержимое видно — это плохо.

— Можно ли добиться этого без .htaccess, если используется nginx?
Да, в конфигурации nginx можно прописать директивы location с deny all для нужных расширений и файлов.

— Насколько критично делать это на небольших форумах и блогах?
Очень критично, потому что на таких сайтах часто экономят на безопасности. Маленькая площадка — тоже мишень, на которую часто идут атаки, особенно если есть уязвимости в плагинах.

— Есть ли случаи, когда нельзя закрывать доступ к каким-то файлам?
Иногда служебные скрипты должны быть доступны для корректной работы функционала, но обычно их можно закрыть по IP или паролем. Если этого нельзя сделать — стоит задуматься о смене схемы работы или движка.

---

В итоге, закрытие служебных файлов — простая, но оооочень важная часть защиты сайта. Никак не стоит полагаться на случай и надеяться, что никто не заметит config.php. Это не то, что просто «хорошо иметь», это минимум, без которого серьезный сайт ну никак не должен выходить в продакшен. Если вы ещё не проверяли свои права и .htaccess — самое время этим заняться и не ловить потом неприятных сюрпризов.