Неделя логов: кто и как ломал мой Joomla-сайт

Реальные данные access.log за два дня — 1199 запросов, 279 уникальных IP и десятки атакующих ботов.

Каждый день ваш сайт обрабатывает сотни запросов. Часть из них — поисковые боты, часть — реальные посетители. Но есть и третья категория: автоматизированные сканеры и эксплойт-боты, которые методично проверяют ваш сайт на наличие уязвимостей. Я решил заглянуть в access-логи своего сайта и разобрать, кто именно и как пытается получить доступ. Спойлер: картинка не самая приятная.

Период анализа: 27–28 августа 2026 года. Сайт работает на Joomla 6, сервер защищён базовым .htaccess (блокировка WP-путей, скрытых файлов, POST без реферера). Ранее был заблокирован бот BitSight (США) — об этом ниже.

Общая картина

За два дня — 1199 запросов от 279 уникальных IP. Из них:

• ~100 запросов — легитимные поисковые боты (Яндекс, Google, Bing, ClaudeBot)
• ~260 запросов — я сам (админка, редактирование материалов)
• ~840 запросов — всё остальное: сканеры, боты, мусор

Большинство атакующих получают 403 (htaccess-блок) или 404 (файл не найден). Ни одна атака не прошла — но это не значит, что можно расслабиться.

Тип атак #1: Поиск бэкапов и архивов

IP: 94.154.35.236
Запросов: 35 за двое суток
Метод: HEAD (проверяет наличие файла без скачивания)

Самый упёртый посетитель. С интервалом примерно в час этот бот отправляет HEAD-запросы к файлам вида /backup.xz, /archive.xz, /krim-web.ru.xz, /bitrix/backup.xz, /administrator.xz, /wp.xz, /joomla.xz и так далее. Словарь из нескольких десятков слов.

Цель: найти выложенный по невнимательности архив сайта или базы данных. Если такой файл существует — бот его скачает, и всё содержимое сайта окажется у атакующего.

Результат: 35 раз получил 403 — .htaccess блокирует запросы к файлам .xz. Бот продолжает приходить.

Как защититься: заблокировать запросы к архивам (.xz, .tar, .gz, .zip, .sql, .bak) через .htaccess. Проверить, нет ли на сервере забытых бэкапов в публичных директориях.

Тип атак #2: RCE через SP Page Builder

IP: 176.234.229.85 и 103.59.161.106
Запросов: 16 + 19 = 35
Метод: POST

Это самая опасная категория. Оба бота используют один и тот же эксплойт с User-Agent sppb-rce-poc — буквально «Proof of Concept для RCE в SP Page Builder». RCE (Remote Code Execution) — это выполнение произвольного кода на вашем сервере.

Атака направлена на endpoint /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon. Если компонент SP Page Builder уязвимой версии — через этот запрос можно загрузить PHP-шелл на сервер и получить полный контроль.

Один из ботов (176.234.229.85) за 2 секунды отправил 16 POST-запросов с разными payload'ами. Второй (103.59.161.106) — 19 запросов за 4 секунды. Это автоматизированный фаззинг: перебор вариантов эксплойта.

Результат: 404 — компонент SP Page Builder на сайте не установлен, endpoint не существует. Но если бы был — последствия могли бы быть катастрофическими.

Как защититься: обновлять SP Page Builder до последней версии. Удалять неиспользуемые расширения. Использовать WAF или плагин защиты админки.

Тип атак #3: Сканирование JCE

IP: 176.234.229.85, 86.104.22.88, 107.174.33.101
Запросов: 3–4 с каждого IP

Несколько ботов проверяют наличие файлов JCE-редактора:

• /plugins/editors/jce/jce.xml — конфиг редактора
• /administrator/components/com_jce/jce.xml — конфиг компонента
• /plugins/system/jcemediabox/js/jcemediabox.js
• /plugins/system/jce/css/content.css

JCE — популярный редактор для Joomla. В его истории было несколько критических уязвимостей (особенно в версиях до 2.8.x). По наличию файла jce.xml бот определяет, установлен ли JCE, и если да — применяет соответствующий эксплойт.

Один из ботов (107.174.33.101) после проверки JCE сразу отправил POST-запрос на /index.php?option=com_jce — попытка прямой эксплуатации.

Как защититься: обновлять JCE до актуальной версии. Если не используете — удалить полностью, а не просто отключить.

Тип атак #4: Бэкдоры Telegram-ботов

IP: 107.174.33.101
Запрос: GET /tmp/tg_xiga857_59d1735a843dc59e7b075f12d96b3311.xml.php

Самый тревожный запрос за всё время наблюдения. Бот пришёл на главную страницу (200), сразу после — POST на com_jce (404), и следом ищет файл с именем вида tg_ + хэш + .xml.php в директории /tmp/.

Это не просто сканирование. Это поиск уже установленного бэкдора. Если ваш сайт уже скомпрометирован (через старую уязвимость JCE, SP Page Builder или что-то ещё) — атакующие оставляют в /tmp/ PHP-файл, замаскированный под XML, который позволяет управлять сервером через Telegram-бота. Такой бэкдор может существовать месяцами, будучи незамеченным.

Как проверить:

• find /tmp -name "*.php" -o -name "*.xml.php"
• Проверить uploads/, images/, media/ на подозрительные PHP-файлы
• Сверить хэши ядра Joomla с эталонными

Тип атак #5: WordPress-сканеры

IP: 134.199.175.172
Запросов: 13
Паттерн: /wp/wp-admin/install.php, /blog/wp-admin/install.php, /shop/wp-admin/install.php...

Бот перебирает 13 распространённых путей установки WordPress: /wp/, /blog/, /shop/, /old/, /new/, /cms/, /backup/ и так далее. Если найдёт незавершённую установку WP — сможет создать аккаунт администратора.

Ещё один бот (89.163.146.197) искал файл txets.php — с опечаткой в User-Agent (Mozlila вместо Mozilla). Любители копипаста.

Как защититься: убедиться, что в корне сайта нет файлов, не относящихся к Joomla. 404 — это нормально, но лучше вообще не давать ботом повод возвращаться.

Тип атак #6: Path-traversal и поиск конфигов

IP: 45.38.18.22 (path-traversal) и 103.77.106.45 (SFTP-конфиг)

Path-traversal (45.38.18.22): бот перебирает вложенные пути вида /images/images/images/images/cache.php — если на сервере есть misconfigured путь, он может выйти за пределы DocumentRoot.

SFTP-сканер (103.77.106.45): ищет файлы /sftp-config.json и /.vscode/sftp.json. Если разработчик работает через VS Code с плагином SFTP и случайно закоммитил конфиг — атакующий получит доступ к FTP/SFTP сервера.

Как защититься: проверьте .gitignore, .htaccess (блок .vscode/, .env, sftp-config.json), убедитесь что path-traversal не работает на сервере.

Тип атак #7: MCP-сканеры (новое)

IP: 2a10:3c0:100:0:1:1:0:5 (IPv6)
UA: python-httpx/0.28.1

Свежий тренд — сканеры, которые ищут открытые MCP-серверы (Model Context Protocol). Запросы: POST /mcp и GET /sse. Если на сервере запущен MCP — бот попытается через него выполнить действия.

Как защититься: если не используете MCP — закрыть соответствующие endpoints через .htaccess.

А кто не атакует?

Не все боты — зло. Полезные боты за два дня:

Эти боты приносят пользу (или как минимум безвредны). Их блокировать не нужно.

Что с BitSight?

В прошлой сессии я заблокировал бота BitSight (США) через .htaccess — он методично перебирал словарные пути и flood'ил логи. Результат: за 27–28 августа — ноль запросов от BitSight. Блок сработал идеально, бот ушёл и не вернулся.

Итоговая таблица заблокированных IP

Главные выводы

1. Боты не отдыхают. За два дня на сайт с умеренным трафиком пришло более 10 атакующих с разными векторами. Это норма, не исключение.
2. Самая опасная атака — RCE через SP Page Builder. Если бы компонент был установлен устаревшей версии, сайт был бы скомпрометирован за секунды.
3. Поиск бэкдоров в /tmp/ — признак того, что атакующие рассчитывают на уже взломанные сайты. Проверьте свой сервер.
4. Базовый .htaccess отсекает ~80% мусора. Блокировка WP-путей, скрытых файлов и архивов значительно снижает нагрузку и шум в логах.
5. Блокировка по IP работает, но это игра в крота. Лучше закрывать векторы атак, а не конкретные IP.

Что можно сделать прямо сейчас

Минимальный чек-лист безопасности Joomla-сайта:

• Удалить неиспользуемые компоненты (SP Page Builder, JCE, если не нужны)
• Обновить всё, что установлено, до последних версий
• Проверить /tmp/ и uploads/ на подозрительные PHP-файлы
• Настроить .htaccess (блокировка архивов, скрытых файлов, WP-путей)
• Защитить панель управления — закрыть админку секретным ключом, чтобы боты даже не доходили до форм входа

Именно для последнего пункта я создал плагин Safe Admin Pro. Он добавляет секретный ключ к URL админки — без правильного ключа доступ к /administrator невозможен, и попытки логируются с определением страны и автобаном. Никакие боты не увидят форму входа, не смогут перебрать пароли или эксплуатировать админские уязвимости.

В логах выше видно: боты стучатся в /administrator/components/, ищут JCE, пробуют com_jce — всё это происходит внутри админки. Если админка закрыта ключом — они даже не узнают, что там находится.