Введение
Если занимаешься администрированием сайтов на популярных CMS, таких как WordPress, phpBB или любыми другими движками, то наверняка сталкивался с тем, что у каждого из них есть куча служебных файлов. Это конфиги, бэкапы, дампы баз данных, логи, и вообще всякая служебная мелочёвка, которая предназначена только для внутреннего использования. Когда новички впервые устанавливают CMS, они часто не понимают, зачем эти файлы надо специально прятать и закрывать от прямого доступа через веб. Мол, кому это вообще надо? Эти файлы же не входят в публичный интерфейс сайта, значит ничему не мешают. Ан нет, на самом деле именно эти “невидимые” файлы могут стать тем самым уязвимым местом, через которое хакеры легко внедрятся и получат полный контроль над сайтом.

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

Какие файлы под угрозой
Чаще всего это:

- wp-config.php (WordPress) — содержит настройки подключения к базе и ключи безопасности.
- config.php (phpBB и похожие движки) — тот же ключ к базе.
- .env — многие современные приложения хранят в нем переменные окружения и секреты.
- .git и .svn — каталоги с историей версий и исходным кодом, которые могут содержать конфиденциальные данные.
- backup.sql, backup.zip, dump.sql и прочие резервные копии — если размещены в публичном доступе, вся база данных становится доступной.
- Логи серверов и самого приложения — там могут оказаться ошибки с деталями, которые помогут подобрать уязвимости.

Где обычно "забывают" закрыть доступ
Типичные места — корень сайта, папки с конфигами, папки с бэкапами. Очень часто серверы вообще не настроены в плане правил доступа к файлам и папкам. Особенно если ставят CMS "из коробки", быстро, без понимания тонкостей безопасности. Стандартные настройки Apache или Nginx могут просто отдавать любой файл всем желающим без разбора.

Практические истории из жизни
- На одном из форумов на phpBB администратор случайно оставил открытым файл config.php. Через пару дней хакер скачал файл, получил данные базы, и буквально за час слил все админские пароли. Форум пострадал серьёзно, пришлось восстанавливать из бэкапа, который тоже был не под замком и оказался поврежден.
- Заметил, что на сайте WordPress оставлен открытым wp-config.php (да, так бывает). При попытке открыть этот файл через браузер — он просто скачивается. Это первый звоночек. Оказалось, что на сервере отсутствуют базовые правила в .htaccess, которые должны запрещать доступ к таким файлам. Исправили — проблема ушла.
- В одном компании скопили десятки дампов баз, положили их в папку backups под корнем сайта, и не заморачивались с их защитой. Через месяц кто-то умудрился украсть всю базу клиентов и сведения по заказам.

Типичные ошибки при работе с служебными файлами
- Не ставить запрет на доступ через веб-сервер к конфигурационным файлам и бэкапам (нет правил в .htaccess или аналогичных для Nginx).
- Хранить резервные копии и дампы баз в публичной папке, а не за пределами корня сайта или на отдельном сервере.
- Давать слишком широкие права на файлы (777 — это адский ад для безопасности!). Файлы с конфигами должны обычно иметь права типа 600 или 640, чтобы никто кроме владельца и, возможно, группы не мог читать.
- Не следить за настройками сервера. Например, забывают закрыть индексирование директорий (Directory Listing), и тогда любой человек видит полный список файлов в папке и может скачать что угодно.
- Переименование служебных файлов в надежде, что "если внешне не виден, значит можно не защищать" — часто приводит к ошибкам в работе CMS или дает ложное чувство безопасности.

Как правильно закрывать служебные файлы: чек-лист
1. Проверить и установить права доступа к файлам конфигураций на уровне ОС (chmod 600 или 640).
2. Настроить веб-сервер (Apache, Nginx) так, чтобы он отвергал все запросы к служебным файлам (например, через .htaccess или конфиги сервера).
3. Никогда не хранить резервные копии и дампы баз данных в публичных папках сайта. Лучше использовать отдельный защищённый сервер для бэкапов.
4. Запретить индексацию папок (Options -Indexes в Apache, autoindex off в Nginx).
5. Использовать специальные плагины и утилиты безопасности CMS, которые контролируют доступ к критичным файлам.
6. Регулярно проверять сайт на наличие “слепых зон” при помощи сканеров безопасности.
7. Для git и других систем контроля версий лучше настроить исключения и использовать приватные репозитории, а не выкладывать .git под корень сайта.
8. Контролировать логи и вести аудит доступа к файлам.

Инструменты и утилиты, которые помогут
- Для проверки доступности файлов — онлайн-сервисы или простые сканеры безопасности, например, OpenVAS или Nikto.
- Веб-серверные модули для авторизации (mod_auth для Apache, ограничение IP в Nginx).
- Плагины безопасности для WordPress (Wordfence, Sucuri и т.п.).
- Утилиты для проверки прав доступа к файлам и каталогам (ls -l, stat, getfacl).
- Резервирование данных и хранение бэкапов с помощью сторонних служб или через cron-скрипты с автоматическим переносом на внешние серверы.

FAQ по служебным файлам CMS

В: Можно ли просто переименовать wp-config.php или config.php, чтобы защититься?
О: Нет, потому что CMS ищет эти файлы по стандартным именам. Переименование часто приводит к ошибкам, а безопасности не добавляет. Лучше использовать правильные настройки прав и веб-сервера.

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

В: Что делать, если на сайте уже есть открытые служебные файлы?
О: Немедленно ограничить доступ через конфигурацию веб-сервера, проверить права доступа к файлам, сменить пароли к базе данных, провести аудит безопасности и поиск вторжений.

В: Как проверить, какие файлы у меня “светятся” на сайте?
О: Можно использовать простые браузерные запросы по известным именам (например, /wp-config.php), или специальные сканеры безопасности, которые проверяют доступность файлов и каталогов.

В общем, не оставляйте служебные файлы без должного внимания — это тот самый базовый фундамент безопасности вашего сайта. Даже если движок широко используется и кажется хорошо защищённым “из коробки”, забудьте — всё зависит от администрирования. Особенно если хочешь, чтобы потом без прорывов и потерь работал твой проект. Не ленись, поставь правила и проверь свой сайт прямо сейчас.