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

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

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

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

Где конкретно эти файлы встречаются, и почему их часто забывают закрыть
Практически любая CMS так или иначе имеет служебные файлы. WordPress и Joomla — одни из самых популярных, но и у форумов типа phpBB или vBulletin есть куча таких файлов. Особенно актуально для форумов — там обычно много юзеров, масса личных данных в базе (почты, IP, даже пароли, если не шифруются должным образом). И если там будут открыты, скажем, папки с бэкапами или логами — это откроет доступ к конфиденциальным данным.

Причина, почему такие файлы остаются открытыми — часто банальная: разработчики CMS делают упор на удобство админов, а не на безопасность "из коробки". Или вебмастер просто забывает удалить установочные скрипты после инсталляции, или не настраивает .htaccess. Порой люди даже не проверяют, что у них открыто для просмотра через браузер.

Примеры из жизни
1. Один из знакомых оставил на FTP файл с дампом базы данных в папке, которая была доступна по прямой ссылке. Неудивительно, что через пару дней сайт взломали.
2. Видел, как на форуме кто-то оставил после обновления скрипт обновления — злой пользователь повторно его запустил и получил полный контроль над сайтом.
3. Несколько раз сталкивался с тем, что открытые логи ошибок PHP позволяли найти пути к административной панели и другим закрытым разделам.
4. Был случай, когда из-за открытого файла backup.zip, лежащего в корне сайта, слилась вся информация о пользователях и заказах интернет-магазина.

Типичные ошибки и где именно люди просчитываются
- Оставляют установочные и обновляющие скрипты на сервере после завершения работы.
- Не защищают доступ к ключевым файлам через .htaccess или правила сервера.
- Используют стандартные имена файлов, которые легко угадать (например config.php, db.php).
- Загружают бэкапы в публичные каталоги или создают доступные директории без индексации.
- Не проверяют через браузер, что именно открывается по URL, не делают ревизию после обновлений.
- Не используют автоматические сканеры для обнаружения открытых служебных файлов.

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

Полезные инструменты для проверки
- Sucuri SiteCheck — бесплатный онлайн-сканер, который помогает найти открытые файлы и подозрительный контент.
- Detectify — более серьезный платный сервис с большими возможностями по анализу безопасности.
- Wordfence для WordPress — плагин, который умеет блокировать доступ к конфигам, устанавливать файрвол и ещё много чего полезного.
- iThemes Security — еще один отличный плагин для защиты WP.

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

Вопрос: Почему CMS не закрывают такие файлы по умолчанию?
Ответ: Многие ориентированы на удобство и гибкость, плюс масса плагинов и тем делают структуру разной. Система не умеет догадаться, что именно вы сделали и какие файлы нужно прятать.

Вопрос: Можно ли использовать robots.txt, чтобы закрыть служебные файлы от поисковиков?
Ответ: robots.txt помогает поисковикам не индексировать файлы, но он не запрещает их видеть пользователям или злоумышленникам. Это не безопасность, а только SEO.

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

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