Безопасность в DLE: типичные ошибки и способы их исправить

Сайт на DataLife Engine может работать годами, а затем получить чужой файл в загрузках, редирект на мошенническую страницу или взломанную админку из-за одной старой настройки. Для DLE 17.x самые частые проблемы лежат не в «магии хакеров», а в обновлениях, правах доступа, сторонних модулях и резервных копиях, оставленных в веб-каталоге. Ниже — практический чек-лист проверки без публикации опасных команд и без попытки заменить полноценный аудит.

С чего начать проверку DLE

Перед изменениями сделайте резервную копию файлов и базы данных. Скачайте её за пределы сервера, проверьте, что архив действительно открывается, а восстановление возможно на тестовом стенде. Проверять рабочий сайт «наугад» рискованно: одна ошибка в конфигурации может отключить авторизацию или загрузку изображений.

Материал рассчитан на DLE 17.x. Уточните точный релиз в админ-панели и сверьте требования к PHP и порядок обновления с документацией именно вашей версии. Между ветками DLE менялись настройки, шаблоны и требования к окружению.

Типичные ошибки владельца сайта

1. Ядро не обновляют. Старый DLE, шаблон или коммерческий модуль остаются удобной точкой входа. Обновление нужно брать из официального кабинета или дистрибутива разработчика, а не с форума и не из «сборки без лицензии». После установки проверьте, что версия изменилась, админка открывается, публикация и загрузка файлов работают.
2. Сторонние модули ставят без проверки. Дополнение может принимать параметры, выводить пользовательский HTML или обращаться к базе данных без нужной фильтрации. Составьте список модулей, удалите неиспользуемые и проверьте для каждого источник, совместимость с DLE 17.x и дату последнего обновления. Простое удаление ссылки из меню не отключает код.
3. Пароль администратора повторяют на других сайтах. Если утекла почта или пароль от другого сервиса, злоумышленник проверит их и в DLE. Для панели используйте отдельный длинный пароль, уникальный для этого сайта, а доступ к учётным записям бывших сотрудников удаляйте, а не просто меняйте им роль.
4. Админ-панель оставляют без дополнительного ограничения. Само по себе нестандартное имя файла панели не заменяет пароль и контроль доступа. Если хостинг позволяет, используйте дополнительные ограничения доступа к панели. Сначала проверьте изменение на тестовом аккаунте: вы не должны заблокировать себе восстановление доступа.
5. Загрузки считают безопасными. Изображение, архив или файл от пользователя нельзя считать безвредным только по расширению. Проверьте ограничения размера, список разрешённых типов и каталог хранения. Если после загрузки файл можно выполнить как серверный скрипт, проблема уже не в имени расширения, а в конфигурации веб-сервера и обработчика PHP.
6. Копии сайта лежат в открытом каталоге. Архив базы, старый конфиг, дамп после миграции и резервная копия шаблона могут содержать пароли, ключи и персональные данные. Храните такие файлы вне публичной директории. После переноса найдите и удалите временные архивы, установочные файлы и копии с суффиксами вроде .bak и .old.
7. Ошибки PHP показываются посетителю. В сообщении об ошибке могут оказаться пути к файлам, SQL-запросы и фрагменты конфигурации. На рабочем сайте отключите вывод подробных ошибок в ответ пользователю, а журналы отправляйте в закрытое хранилище с ограниченным доступом. Не удаляйте логирование полностью: без него расследовать инцидент будет сложнее.
8. В шаблоне выводят данные без контекстной экранизации. Ник автора, заголовок, комментарий и параметр URL могут попасть в HTML. Для каждого места нужно понимать, куда попадает значение: в текст страницы, HTML-атрибут, URL или JavaScript. Универсальная замена символов «на всякий случай» не всегда защищает и иногда ломает разметку.

Безопасность DLE начинается не с закрытия одного файла, а с сокращения поверхности атаки: меньше модулей, меньше прав, меньше копий и понятнее журнал событий.

Что проверять в первую очередь

Как проводить проверку без простоя

1. Зафиксируйте исходное состояние

Запишите версию DLE, PHP, веб-сервера, список расширений и дату последнего бэкапа. Сохраните список администраторов и важных настроек. Это позволит отличить плановое изменение от подозрительного.

2. Проверьте файлы и права

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

3. Проверьте модули и шаблон

Отключайте дополнения по одному на копии сайта и после каждого изменения проверяйте авторизацию, публикацию, поиск, комментарии и загрузку изображений. Если проблема исчезла после отключения конкретного модуля, не включайте его обратно на рабочем сайте до проверки обновления или замены.

4. Проверьте сценарий восстановления

Разверните копию на отдельном поддомене или локальном стенде. Убедитесь, что база импортируется, изображения открываются, а администратор может войти. Резервная копия, которую никто не пробовал восстановить, — это предположение, а не план восстановления.

Где очевидные меры не работают

«Спрячем admin.php». Это снижает количество случайных запросов, но не исправляет уязвимый модуль, слабый пароль или украденную сессию. Переименование пути полезно только как дополнительный слой.

«Поставим самый строгий chmod». Слишком жёсткие права могут сломать обновление, загрузки и кэш, а слишком широкие — позволить изменить файлы сайта. Настройки нужно проверять вместе с владельцем файлов, пользователем веб-сервера и способом деплоя.

«Поставим антивирус и забудем». Сканер может найти известный вредоносный файл, но не поймёт бизнес-логику уязвимого модуля и не заменит обновления. Если взлом уже произошёл, сначала сохраните логи и копию состояния, затем ограничьте доступ и только после этого очищайте сайт.

«Добавим фильтр ко всем входным данным». Фильтрация зависит от контекста. Значение для SQL, HTML, URL и HTTP-заголовка обрабатывается по-разному. Для самописного модуля лучше использовать проверенные механизмы DLE и документацию версии, чем копировать универсальный фрагмент из старого форума.

Что делать после проверки

Составьте короткий регламент: кто обновляет DLE, кто проверяет расширения, где лежат копии и как быстро отзывать доступ сотруднику. В продакшене отслеживайте входы в админку, изменения файлов, ошибки PHP, неожиданные новые учётные записи и рост исходящего трафика. Следующий практический шаг — поднять тестовую копию DLE 17.x, воспроизвести восстановление из бэкапа и только потом обновить рабочий сайт.

Термин: поверхность атаки — все доступные извне точки, через которые можно воздействовать на сайт: формы, загрузки, админка, модули, API и настройки веб-сервера.