Если сайт на Joomla уже взломан или появились подозрительные файлы, не ограничивайтесь обновлением расширений. Сначала остановите повторный вход, сохраните копию для проверки, затем очистите файлы и базу данных, смените доступы и настройте защиту веб-сервера. Ниже, понятная последовательность действий с пояснениями, какой код и куда добавлять.
Краткий ответ
Лечение Joomla после взлома состоит из пяти этапов: изолировать сайт и сохранить копию, закрыть уязвимый вход, найти и удалить вредоносный код в файлах и базе, заменить доступы и проверить работу сайта, затем включить постоянную защиту. Вредоносный код может остаться в шаблоне, модулях или настройках базы, поэтому одной проверки папки images недостаточно. Правила Nginx или Apache ниже блокируют запуск PHP в каталогах загрузок, но не заменяют обновление Joomla и расширений.
Что сделать в первые 30 минут
Первая задача, не удалить следы и не дать атакующему продолжить работу. Если есть признаки взлома: незнакомый администратор, редиректы, спам со страниц сайта, PHP-файлы в папке изображений, предупреждение поисковой системы или хостинга, временно ограничьте доступ к сайту технической заглушкой или правилами веб-сервера.
- Сохраните отдельную копию файлов сайта, дамп базы данных и журналы веб-сервера. Не перезаписывайте существующие резервные копии.
- Зафиксируйте время обнаружения, подозрительные URL, имена файлов и учётные записи. Эта информация поможет найти точку входа.
- Смените пароли администратора Joomla, панели хостинга, SSH или FTP, базы данных и почты. Удалите неизвестных пользователей с правами администратора.
- Закройте выполнение PHP в папках, куда можно загружать файлы. Это снижает риск повторного запуска веб-шелла ещё до полной очистки.
Не запускайте массовое удаление файлов по совпадению с одной строкой или датой. У Joomla и расширений бывают легитимные минифицированные и закодированные файлы. Сначала сделайте копию и проверьте каждый кандидат.
Шаг 1. Закройте вход, через который могли попасть на сайт
Обновление закрывает известную уязвимость, но не удаляет уже загруженный код. В панели Joomla откройте «Система → Обновление Joomla» и «Система → Управление → Расширения». Обновите ядро и используемые расширения до поддерживаемых версий. Неиспользуемые компоненты, плагины, шаблоны и языки лучше удалить через штатный менеджер расширений.
Сверяйте установленные версии с бюллетенями разработчика каждого расширения и с центром безопасности Joomla. Не ориентируйтесь на список уязвимостей из старой статьи или форума: номера CVE, затронутые версии и способы обхода меняются.
| Что проверить | Где искать | Что сделать |
|---|---|---|
| Версия Joomla | Панель администратора, «Система → Информация о системе» | Обновить до поддерживаемой версии после резервной копии. |
| Расширения и шаблоны | «Система → Управление → Расширения» | Обновить используемые, удалить ненужные, отключить сомнительные до проверки. |
| Плагины com_ajax | «Система → Плагины», фильтр по группе ajax | Отключить то, что не используется. Для собственных обработчиков добавить проверку прав и CSRF-токена. |
| Учётные записи | «Пользователи → Управление» | Удалить неизвестные учётные записи и проверить группы доступа. |
Шаг 2. Запретите запуск PHP в папках загрузок
Папки images, media, files, tmp, cache и logs предназначены для изображений, вложений, временных файлов и журналов. В нормальной Joomla PHP-код в них запускаться не должен. Если уязвимое расширение загрузит туда веб-шелл, правило ниже вернёт ошибку 403 вместо выполнения файла.
Nginx: куда вставить правило
Добавьте фрагмент в блок server конфигурации сайта, до общего обработчика PHP. В HestiaCP это обычно пользовательские файлы конфигурации домена nginx.conf_* и nginx.ssl.conf_*. Если сайт работает по HTTP и HTTPS, правило должно быть в обоих конфигурационных файлах. После изменения проверьте конфигурацию командой nginx -t и только затем перечитайте Nginx.
location ~* ^/(images|media|files|tmp|cache|logs|administrator/(logs|cache))/.+\.(php|phtml|phar|php[0-9]*)$ {
deny all;
return 403;
}
Если расширение хранит вложения в отдельной папке, добавьте её в список. Пример: images/baforms/uploads. Не запрещайте PHP в каталогах расширения целиком, пока не убедитесь, что там действительно не выполняется штатный код Joomla.
Apache: куда вставить правило
Добавьте фрагмент в корневой файл .htaccess Joomla, рядом с другими правилами RewriteRule и до стандартного правила перенаправления на index.php. Правило действует только если на хостинге разрешён mod_rewrite. На сервере с доступом к виртуальному хосту надёжнее также отключить переопределение правил в папках загрузки через AllowOverride None.
RewriteEngine On
RewriteRule ^(images|media|files|tmp|cache|logs|administrator/(logs|cache))/.+\.(php|phtml|phar|php[0-9]*)$ - [F,L,NC]
Перед публикацией правила на рабочем сайте проверьте загрузку изображений, отправку форм и администраторскую часть. Если после изменения возникла ошибка 500, сразу верните предыдущую версию конфигурации и проверьте журнал ошибок веб-сервера.
Шаг 3. Найдите подозрительные файлы без удаления
Подключитесь к серверу по SSH и начните с файлов, которые появились незадолго до инцидента, а также с PHP в каталогах, предназначенных для загрузок. Выполняйте команды из корня Joomla, где лежат configuration.php и папки administrator, images, plugins.
find . -type f -name "*.php" -mtime -14 -print
find images media files tmp cache logs -type f -name "*.php" -print
grep -RInE "base64_decode|gzinflate|eval[[:space:]]*\(|shell_exec|assert[[:space:]]*\(" .
Эти команды не доказывают заражение, а формируют список для проверки. Сначала сравните подозрительный файл с дистрибутивом Joomla или исходниками расширения. Затем перенесите его в карантин за пределы публичной папки либо переименуйте с расширением .disabled, если уверены, что файл вредоносный. Не удаляйте оригинал до завершения расследования.
Какие каталоги проверять в первую очередь
- images, media, files, tmp, cache: PHP, файлы с двойным расширением и неизвестные .htaccess.
- templates и plugins: новые или изменённые PHP-файлы, вставки JavaScript с обфускацией, незнакомые include и require.
- Корень сайта: index.php, .htaccess, configuration.php и файлы с похожими именами, например configuration.php.bak.
- administrator: новые файлы и неизвестные расширения, особенно если они появились одновременно с инцидентом.
Шаг 4. Проверьте базу данных, а не только файлы
После взлома вредоносный JavaScript нередко живёт в настройках шаблона, параметрах модулей или тексте материалов. Он возвращается на сайт даже после замены файлов, поэтому базу нужно просматривать отдельно. Перед любым редактированием выгрузите SQL-дамп.
В phpMyAdmin или другом клиенте базы по очереди проверьте таблицы с вашим префиксом: template_styles, modules, content, extensions. Ищите конструкции fromCharCode, eval(, base64_decode, _0x, неожиданные внешние домены и скрытые iframe. Префикс таблиц у Joomla может быть не jos_, поэтому замените его на фактический.
SELECT id, template, params
FROM prefix_template_styles
WHERE params LIKE '%fromCharCode%'
OR params LIKE '%eval(%'
OR params LIKE '%_0x%';
SQL-запрос выше только ищет записи, ничего не удаляет. Перед очисткой подозрительной строки сравните её с резервной копией, датой изменения и кодом шаблона. Если неясно, какая часть параметров штатная, передайте специалисту экспорт конкретной записи, а не весь дамп с персональными данными.
Шаг 5. Безопасно восстановите ядро Joomla и расширения
Когда точка входа закрыта и список подозрительных файлов составлен, замените ядро Joomla на чистый дистрибутив той же, а затем актуальной поддерживаемой версии. Это безопаснее, чем пытаться вручную восстановить каждый системный файл. Не перезаписывайте без проверки configuration.php, папку images и доработки шаблона: там могут находиться рабочие настройки и пользовательские данные.
- Сделайте контрольный дамп базы и копию файлов после изоляции.
- Обновите Joomla штатным способом из панели администратора или по инструкции хостинга.
- Переустановите используемые расширения из официальных архивов разработчиков.
- Проверьте журнал ошибок, форму обратной связи, авторизацию, отправку писем, поиск и основные посадочные страницы.
- Повторно выполните поиск подозрительных файлов и строк в базе.
Шаг 6. Защитите собственный com_ajax-обработчик
Обработчик com_ajax не получает ограничения доступа автоматически только потому, что метод находится в административном расширении. Если вы поддерживаете собственный ajax-плагин, проверка должна находиться в самом начале публичного метода обработчика, до любой работы с входными данными или файлами.
Откройте PHP-файл метода onAjax... вашего плагина, обычно он находится в папке plugins/ajax/имя_плагина или в его классе расширения. Вставьте проверку сразу после открытия метода. Замените com_example на имя своего компонента и адаптируйте код под версию Joomla и архитектуру плагина.
<?php
public function onAjaxMyplugin()
{
$user = \Joomla\CMS\Factory::getUser();
if ($user->guest || !$user->authorise('core.manage', 'com_example')) {
throw new \RuntimeException('Access forbidden', 403);
}
\Joomla\CMS\Session\Session::checkToken('request') or throw new \RuntimeException('Invalid token', 403);
// Основная логика обработчика
}
Проверка токена подходит для запросов из административного интерфейса, где токен передаётся штатно. Для публичной формы авторизация может быть другой, но проверка типа файла, размера, MIME-типа и права на загрузку всё равно обязательна.
Шаг 7. Смените доступы и настройте регулярную защиту
После очистки считайте скомпрометированными все секреты, которые были доступны на сервере. Смена одного пароля администратора не закрывает доступ через FTP, базу данных или API-токен.
- Смените пароли Joomla, хостинга, SSH или FTP, базы данных, почтовых ящиков и внешних сервисов.
- Измените секретный ключ Joomla после проверки совместимости с интеграциями, которые могут его использовать.
- Включите двухфакторную аутентификацию для администраторов и удалите ненужные учётные записи.
- Отключите самостоятельную регистрацию, если она не нужна проекту.
- Настройте внешние резервные копии и периодически проверяйте, что из них можно восстановить чистый сайт.
- Подключите WAF или защитное расширение как дополнительный слой, а не как замену обновлениям.
Комментарий специалиста INSIB
Самая частая причина повторного заражения, сайт обновили, но не проверили базу, резервные копии и все доступы. В результате вредоносный скрипт возвращается из параметров шаблона, старого бэкапа или через оставленную учётную запись. Лечение имеет смысл только как единый процесс: закрыть вход, очистить, сменить секреты и включить постоянные ограничения на сервере.
Нужна помощь с лечением сайта на Joomla
Проведём диагностику, найдём точку входа, очистим файлы и базу, настроим защиту и проверим восстановление сайта.
Обсудить задачуЧастые вопросы
Можно ли просто восстановить сайт из резервной копии?
Можно только после проверки даты и чистоты копии. Если резервная копия сделана после взлома или уже содержит вредоносный код, восстановление вернёт проблему.
Достаточно ли обновить Joomla и расширения?
Нет. Обновление закрывает известную уязвимость, но не удаляет веб-шелл, скрипт в шаблоне или изменённую запись базы данных.
Почему PHP в папке images опасен?
Папка изображений не должна содержать исполняемый PHP-код. Если веб-сервер запускает такой файл, атакующий получает возможность выполнять команды от имени сайта.
Нужно ли менять пароль базы данных?
Да, если есть вероятность доступа атакующего к configuration.php, резервным копиям или панели хостинга. После смены не забудьте обновить параметры подключения в configuration.php.
Что делать, если я не уверен в подозрительном файле?
Не удаляйте его сразу. Сохраните копию, сравните с официальным архивом Joomla или расширения и проверьте дату, владельца, путь и обращения к нему в журналах.
Поможет ли WAF?
WAF блокирует часть известных атак и полезен как дополнительный барьер. Он не заменяет обновления, ограничение выполнения PHP и проверку уже заражённого сайта.
Что важно запомнить
При взломе Joomla действуйте последовательно: сохраните доказательства и копию, перекройте повторный вход, проверьте файлы и базу, восстановите компоненты из чистых источников, смените все секреты и запретите PHP в каталогах загрузок. Если нет доступа к серверу или непонятно, что именно изменено, безопаснее передать диагностику специалисту, чем удалять файлы наугад.