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

Что это такое
Служебные файлы CMS — это файлы настроек, бэкапов, конфигураций, иногда скрипты и дампы баз данных, которые находятся в корне сайта или в системных папках. Обычно они не должны быть доступны в браузере, так как часто содержат пароли, учетные данные, или внутреннюю логику приложения. Пример — wp-config.php в WordPress, config.php в Joomla или папки с логами и временными файлами.

Где применяется
Практически в любой CMS, будь то WordPress, Joomla, Drupal, phpBB, SMF и другие форумы и движки. Даже если CMS кажется надежной, по умолчанию защищены далеко не все директории и файлы. В администрировании это одна из базовых задач — запретить доступ к таким файлам или выносить их за пределы публичной директории. Особенно актуально на хостингах с общей инфраструктурой или когда сайт собирается из нескольких компонентов.

Практические примеры
Лично сталкивался, когда на одном клиентском портале остался доступен файл конфигурации с паролями к базе. Быстро это заметил сканер безопасности. Исправление — запрет доступа через .htaccess, а еще лучше — перенос файла в недоступную из интернета папку. Ещё одна история — забытый дамп базы в публичной директории, который скачали и проанализировали конкуренты. И простой метод защитить такие файлы — поставить deny all в настройках сервера для нужных путей.

Типичные ошибки
- Оставлять файлы с настройками в корне сайта без ограничений
- Загружать бэкапы и дампы в публичные папки и забывать удалить
- Не проверять права на доступ к папкам и файлам (0777 — зло!)
- Игнорировать рекомендации CMS по безопасности
- Пытаться защититься через JavaScript (не работает, т.к. файлы доступны на сервере)
- Использовать одинаковые пароли в базе конфигураций и админке

Полезные инструменты
- Сканеры уязвимостей типа WPScan, Droopescan, или простой Nikto позволяют быстро выявить открытые служебные файлы
- Проверка прав доступа через SSH/FTP: команды ls -l, chmod, chown
- .htaccess для Apache или правила nginx для запрета доступа к определенным типам файлов
- Плагины безопасности для CMS, которые умеют закрывать служебные директории и контролировать права
- Автоматизированные CI/CD скрипты для проверки и удаления чувствительных файлов из публичной части

FAQ
— Как быстро проверить, что служебные файлы закрыты?
Попробуйте открыть в браузере типовые пути, например /wp-config.php, /config.php, /backup.sql. Если файл скачивается или открывается — проблема.

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

— А если в CMS нет стандартных файлов?
Всегда есть служебные папки и файлы, не игнорируйте проверку, особенно если ставите дополнительные плагины или модули.

— Какие права лучше ставить на конфиг?
644 или 600 — зависит от сервера, главное чтобы веб-сервер мог читать, но не чтобы любой пользователь на хостинге мог менять.

Вывод
Защита служебных файлов CMS — простая и обязательная часть администрирования. Пренебрегать ей — значит приглашать проблемы с безопасностью, вплоть до полного взлома сайта или утечки данных. Лично у меня проверка и настройка доступа к таким файлам — первый шаг при работе с новыми проектами. Рекомендую всем хотя бы раз пройтись по чек-листу и убедиться, что все закрыто как надо.

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