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

Текст:
Давайте сразу без лишнего пафоса. Служебные файлы CMS — это те самые файлы и папки, которые нужны для работы сайта, но абсолютно не предназначены для показа всем подряд в интернете. Они хранят настройки, пароли, ключи и прочие внутренние штуки. Если их не прикрыть, получается, что любой прохожий может полистать твои секреты и устроить полный хаос. Просто и по теме: если эти файлы открыты — это дырка в безопасности.

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

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

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

Почему это опасно — практические случаи из жизни
1. Файл wp-config.php открывается в браузере. В нем хранятся логин, пароль, имя базы, адрес сервера базы. Чуть что — и можно через phpMyAdmin залогиниться и скачать всю базу, получить доступ к аккаунтам, почте, заказам.
2. Папка /install/ осталась на сервере после установки движка. Кто-то запускает установку заново и сбрасывает базу или подменяет конфигурацию.
3. Логи ошибок, которые не закрыты — показывают подробности системы: пути к папкам, версии PHP, названия тем и плагинов. Это даёт взломщику лишнюю информацию для выбора уязвимости.
4. Резервные копии сайтов, оставленные в публичных папках. К примеру, бэкап wp-config.php с паролями или файл с дампом базы кладут в папку /backup/, которая не закрыта от доступа. Просто заходишь по адресу и скачиваешь все данные.
5. Открытый доступ к админке или к папкам с внутренними файлами без ограничений: например, заходишь с любого IP — и видишь панель администратора, хотя логин и пароль могут быть очень слабые.

Типичные ошибки на которые часто натыкаюсь
- Невнимательность при настройке сервера: забыли закрыть служебные файлы в .htaccess (Apache) или конфиге nginx.
- Не удалили или не закрыли папки и скрипты установки, которые остались после установки CMS.
- Хранили бэкапы и дампы баз данных в публичных папках без паролей и защиты.
- Доступ к важным разделам сайта открыт без ограничений по IP, нет двухфакторной аутентификации.
- Забудьте про файлы .bak, .old, .zip и другие, которые могут случайно оказаться доступными. Иногда такие файлы оставляют после администрирования и думают, что их никто не найдет.

Как закрывать доступ — базовые рекомендации
- Использовать .htaccess (для Apache) и правила в nginx для запрета доступа к важным файлам. Например, запретить открытие *.php файлов типа wp-config.php или configuration.php.
- Удалять все установочные папки и скрипты сразу после установки CMS. Они нужны только один раз.
- Переносить бэкапы с сайта на отдельный защищённый сервер или локалку. Никогда не хранить их в публичных каталогах.
- Ограничить доступ к админке по IP или закрыть её через пароль на уровне сервера, добавить двухфакторную аутентификацию.
- Проверять права на файлы и папки — никто кроме самого сервера и администратора не должен иметь туда доступ.
- Настроить генерацию логов так, чтобы они не писались в папки, открытые наружу.

Полезные инструменты, которыми я пользуюсь
- Онлайн-сканеры — например, Sucuri SiteCheck, которые показывают открытые служебные файлы и другие уязвимости.
- OpenVAS — отличный инструмент для комплексного сканирования сервера.
- WPScan для сайтов на WordPress — покажет, какие файлы и плагины находятся в открытом доступе.
- Самостоятельная проверка через curl, wget или просто браузер — заходишь на адрес файла и смотришь, доступен ли он.
- Разумеется, раз в месяц-два можно запускать аудит безопасности сайта и сервера.

Чек-лист для проверки служебных файлов и безопасности:
1. Проверить доступность wp-config.php, configuration.php, других конфигов — должен быть запрет доступа.
2. Убедиться, что папки /install/, /setup/, /backup/ удалены или закрыты.
3. Проверить права доступа к файлам и папкам, чтобы никто посторонний не мог их прочитать.
4. Ограничить доступ к админке по IP или через другие методы защиты.
5. Убедиться, что бэкапы и дампы не лежат в публичных папках.
6. Настроить правила на уровне сервера для запрета доступа к скрытым и служебным файлам (например, файлам, начинающимся с точки . htaccess, .git, .env).
7. Запустить онлайн- или оффлайн-сканер для проверки уязвимостей.
8. Обновить CMS, плагины и темы — часто закрывают уязвимости.

FAQ по закрытию служебных файлов CMS

В: Как проверить, открыты ли служебные файлы моего сайта?
О: Попробуйте ввести в браузере адрес типа example.com/wp-config.php или example.com/configuration.php. Если увидите содержимое файла — надо срочно закрывать. Можно также использовать онлайн-сканеры типа Sucuri.

В: Что делать, если бэкапы уже лежат в общедоступной папке?
О: Срочно удалить или переместить в директорию за пределами публичного доступа. Если это невозможно — настроить пароль на папку или запрет доступа в конфиге сервера.

В: Можно ли убрать установочные папки не повредив сайт?
О: Да, после успешной установки CMS установочные папки обычно не нужны. Удаляйте их или закрывайте доступ. Обязательно проверяйте документацию движка.

В: Какие файлы служб не стоит публиковать в интернете?
О: Любые конфиги, логи, файлы с расширением .env, .sql, .bak, и любые резервные копии. Они могут содержать пароли и внутреннюю информацию.

В: Октрыт ли доступ к админке — почему это проблема?
О: Если доступ открыт для всех, то при слабом пароле или уязвимом плагине злоумышленник сможет получить полный контроль. Лучше ограничить по IP и добавить 2FA.

В: Нужно ли проверять сайт после установки любого плагина или темы?
О: Обязательно! Иногда плагин может создать служебные файлы или папки и забыть их закрыть.

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