На сайте смотрим тут --- >>> Рабочий стол Настройки Проактивная защита Поиск троянов Операционная система
Видим такое
> whoami
bitrix
> ps ux -u whoami
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND bitrix 1087 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1088 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1089 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 1090 0.0 0.4 746636 9168 ? S May21 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd-scale.conf -DFOREGROUND bitrix 9999 194 13.0 285796 267816 ? Ssl Jun03 59733:36 [kworker/u3:11] bitrix 13837 0.0 0.6 333976 13684 ? S May24 3:12 nginx: worker process bitrix 13838 0.0 0.8 338364 17788 ? S May24 23:41 nginx: worker process bitrix 13839 0.0 0.6 334232 14020 ? S May24 2:16 nginx: worker process bitrix 13840 0.0 0.6 333720 13324 ? S May24 4:20 nginx: worker process bitrix 13841 0.0 0.6 333464 13380 ? S May24 6:33 nginx: worker process bitrix 13842 0.0 0.6 333968 13868 ? S May24 3:11 nginx: worker process bitrix 13843 0.0 0.7 335000 15004 ? S May24 10:01 nginx: worker process bitrix 13844 0.0 0.6 333720 13236 ? S May24 2:24 nginx: worker process bitrix 15317 0.1 7.3 757004 150756 ? S Jun22 6:36 /usr/sbin/httpd -DFOREGROUND bitrix 15318 0.1 7.5 759000 153576 ? S Jun22 6:38 /usr/sbin/httpd -DFOREGROUND bitrix 15319 0.1 7.4 758920 152476 ? S Jun22 6:46 /usr/sbin/httpd -DFOREGROUND bitrix 15320 0.1 7.7 759004 159556 ? S Jun22 6:46 /usr/sbin/httpd -DFOREGROUND bitrix 15321 0.1 8.6 759036 176284 ? S Jun22 6:52 /usr/sbin/httpd -DFOREGROUND bitrix 15322 0.1 7.4 758936 152356 ? S Jun22 6:37 /usr/sbin/httpd -DFOREGROUND bitrix 15323 0.1 7.6 754964 157268 ? S Jun22 6:42 /usr/sbin/httpd -DFOREGROUND bitrix 15324 0.1 7.4 752884 153428 ? S Jun22 6:35 /usr/sbin/httpd -DFOREGROUND bitrix 15325 0.1 7.4 756424 153272 ? S Jun22 6:36 /usr/sbin/httpd -DFOREGROUND bitrix 15326 0.1 7.8 760452 160352 ? S Jun22 6:50 /usr/sbin/httpd -DFOREGROUND bitrix 17241 0.0 0.0 51728 1716 ? R 13:46 0:00 ps ux -u bitrix
> crontab -l
no corntab
> last -i whoami
bitrix pts/0 0.0.0.0 Sat Mar 15 16:24 - 16:24 (00:00)
wtmp begins Mon Jun 26 15:01:03 2023
Краткий вердикт: У вас на сервере с вероятностью 99.9% работает замаскированный майнер или другой троян.
Теперь разберем подробно, почему я пришел к такому выводу и что делать дальше.Анализ ваших данных
1. Проверка процессов (ps ux)
Вывод команды `ps` содержит огромный красный флаг, который практически однозначно указывает на взлом.USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
bitrix 9999 194 13.0 285796 267816 ? Ssl Jun03 59733:36 [kworker/u3:11]
... Давайте разберем эту строку:
- `USER: bitrix`: Процесс запущен от имени пользователя `bitrix`.
- `COMMAND: [kworker/u3:11]`: Процесс маскируется под `kworker`. Это и есть главная улика.
<li>Настоящие `kworker` — это системные процессы ядра (kernel workers). Они всегда запускаются от пользователя `root`.
- Процесс ядра, запущенный от обычного пользователя (`bitrix`), — это классический признак вредоносного ПО, которое пытается спрятаться от администратора.
- Квадратные скобки `[]` также используются, чтобы имитировать вид системного процесса.- `TIME: 59733:36`: Процесс наработал огромное количество процессорного времени — более 59 тысяч минут (это ~41 день непрерывной работы). Это подтверждает, что он работает давно и постоянно "жрет" ресурсы.
- `START: Jun03`: Процесс был запущен 3 июня, что совпадает с огромным накопленным временем работы.
Остальные процессы:
- `httpd` (Apache) и `nginx` — это стандартные и ожидаемые процессы для веб-сервера под управлением BitrixVM / BitrixEnv. С ними, на первый взгляд, все в порядке.
Вывод по процессам: Процесс `kworker` с PID `9999`, запущенный от `bitrix`, — это вредонос.2. Проверка Crontab (crontab -l)
no corntab Это означает, что для текущего пользователя (`bitrix`) нет запланированных заданий. Это хорошо, но недостаточно. Злоумышленник мог добавить задание для пользователя `root` или в системные директории crontab.3. Проверка SSH-ключей
Вы не предоставили вывод этой проверки. Обязательно выполните ее.4. Проверка логов входа (last)
bitrix pts/0 0.0.0.0 Sat Mar 15 16:24 - 16:24 (00:00) Запись очень старая, она не имеет отношения к текущему инциденту. Однако стоит помнить, что злоумышленник мог почистить логи (`/var/log/wtmp`, откуда `last` берет данные), поэтому доверять этому выводу на 100% нельзя.План действий: Что делать ПРЯМО СЕЙЧАС
Шаг 0: Получите права `root` Дальнейшие действия требуют повышенных привилегий. Выполните `sudo -i` или `su -`.
Шаг 1: Уничтожить вредоносный процесс
Немедленно остановите процесс-майнер, чтобы он перестал потреблять ресурсы и отправлять данные злоумышленнику.bash Скопировать
Закрыть блок
kill -9 9999 (`-9` — это сигнал принудительного завершения, который нельзя проигнорировать).
Шаг 2: Найти исполняемый файл трояна
Процесс вы убили, но его файл остался на диске. Его нужно найти и удалить. Так как процесс маскировался, лучший способ — посмотреть, какой файл был связан с запущенным процессом через файловую систему `/proc`.
До того как вы убили процесс (или если он перезапустился под другим PID), можно было выполнить:bash Скопировать
Закрыть блок
# Эта команда покажет путь к исполняемому файлу процесса с PID 9999
readlink -f /proc/9999/exe Если вы уже убили процесс, ищите файл по имени. Часто они прячутся в `/tmp`, `/var/tmp` или используют имена, похожие на системные.bash Скопировать
Закрыть блок
# Искать файлы, измененные примерно в дату взлома (например, 3 июня)
find / -mtime -30 -user bitrix -type f -ls 2>/dev/null | grep 'kworker'
# Искать файлы с подозрительными именами в нестандартных местах
find /tmp /var/tmp /dev/shm -name "*" -user bitrix Шаг 3: Найти и удалить механизм автозапуска
Троян должен как-то запускаться после перезагрузки. Проверьте:
- Системный crontab и cron-директории:bash Скопировать
Закрыть блокcrontab -l -u root
ls -la /etc/cron.*
cat /etc/crontab- Systemd сервисы: Злоумышленники любят создавать свои сервисы.bash Скопировать
Закрыть блокsystemctl list-unit-files --type=service | grep enabled
# Ищите сервисы с подозрительными именами Часто они маскируются под что-то вроде `systemd-network.service` (а настоящий называется `systemd-networkd.service`).
- Скрипты автозапуска:bash Скопировать
Закрыть блокcat /etc/rc.local Шаг 4: Проверить посторонние SSH-ключи (теперь под `root`)bash Скопировать
Закрыть блок
cat /home/bitrix/.ssh/authorized_keys
cat /root/.ssh/authorized_keys Удалите все ключи, которые вы не добавляли.
Шаг 5: Проанализировать, как произошел взлом
Это самый сложный этап. Взлом сервера с Битриксом чаще всего происходит через:
- Уязвимость в модуле сайта: Проверьте, все ли модули обновлены.
- Уязвимость в ядре Битрикса: Убедитесь, что платформа обновлена до последней версии.
- Слабый пароль: Пароль от FTP, SSH или админки сайта.
- Загрузка "шелла" через один из компонентов сайта.
Проанализируйте логи веб-сервера (`/var/log/httpd/` или `/var/log/nginx/`) за дату `Jun03`. Ищите подозрительные POST-запросы, обращения к странным PHP-файлам, попытки сканирования.
Рекомендация: Самый надежный способ — сделать бэкап сайта и базы данных, полностью переустановить сервер с нуля и развернуть бэкап после тщательной проверки его файлов на наличие посторонних скриптов. Лечить скомпрометированную систему очень сложно, и нет гарантии, что вы найдете все "закладки".
Мы продолжаем расследование, и новые данные помогают сузить круг поиска.Анализ новой информации
-
Systemd Services (продолжение):
<li>Список по-прежнему не содержит ничего явно вредоносного. `zabbix-agent.service` — это легитимный сервис мониторинга (если вы его используете). `xinetd.service` — супер-сервер, который может запускать другие сервисы, но сам по себе не вредоносный./etc/rc.local:
<li>`touch /var/lock/subsys/local` — стандартная команда.
- `/opt/webdir/bin/update_network.sh eth0` — стандартный скрипт окружения Битрикса для обновления сетевой конфигурации.
- Вывод: В `rc.local` нет ничего подозрительного. SSH-ключи:
<li>`/home/bitrix/.ssh/authorized_keys`: Файл отсутствует. Это хорошо. Значит, под пользователем `bitrix` нельзя зайти по ключу.
- `/root/.ssh/authorized_keys`: Содержит один ключ с комментарием `ANSIBLE_KEY_vds-fialkaexpsar.timeweb.ru`. Это ключ, который, скорее всего, был добавлен вашим хостинг-провайдером (Timeweb) для автоматизации управления сервером с помощью Ansible. Если вы заказывали сервер у Timeweb, этот ключ является легитимным. Если нет — это повод для беспокойства. Предполагаем, что ключ легитимный.Промежуточные итоги и дальнейший план
Мы проверили все "классические" и самые очевидные места автозапуска (cron, systemd, rc.local) и не нашли прямых улик. Троян с высокой вероятностью использует один из двух оставшихся методов:
- Модификация легитимного скрипта/конфигурации.
- Запуск через веб-шелл, загруженный на сайт.
Наш главный подозреваемый сейчас — это сам код сайта и скрипты, которые он вызывает. Вредоносный процесс `kworker` был запущен от пользователя `bitrix`, что с огромной вероятностью указывает на то, что точка входа — это веб-сервер и PHP-скрипты.План действий: Фокусируемся на файлах и процессах
Шаг 1: Найти исполняемый файл вредоноса (ПРИОРИТЕТ №1)
Мы знаем, что процесс-майнер существует (или существовал). Нам нужно найти его файл на диске. Это самая важная задача сейчас.
Попробуем найти его через файловую систему `/proc`. Если вы еще не убили процесс `kworker` с PID `9999` (или он перезапустился под новым PID), выполните:bash Скопировать
Закрыть блок
# Сначала найдем PID вредоноса. Он будет запущен от bitrix и потреблять много CPU
ps aux | grep 'kworker' | grep 'bitrix'
# Допустим, новый PID - 12345. Выполняем:
ls -l /proc/12345/exe
# Эта команда покажет символическую ссылку на реальный файл, который был запущен.
# Например: /proc/12345/exe -> /tmp/kworker
ls -l /proc/12345/cwd
# Покажет рабочую директорию, из которой был запущен процесс.
cat /proc/12345/cmdline | xargs -0 echo
# Покажет полную команду запуска. Если вы уже убили процесс и он не перезапустился, этот метод не сработает. Тогда переходим к поиску по диску.
Шаг 2: Глубокий поиск подозрительных файлов на диске
Давайте проведем более агрессивный поиск. Майнеры часто прячутся в "мусорных" директориях и имеют атрибут "исполняемый".bash Скопировать
Закрыть блок
# Ищем исполняемые файлы в /tmp и /dev/shm (очень популярные места)
find /tmp /var/tmp /dev/shm -type f -perm /a=x -ls 2>/dev/null
# Ищем любые файлы, принадлежащие пользователю bitrix, вне его домашней директории
# Это может найти файлы, которые троян создал в системных папках
find / -path "/home/bitrix" -prune -o -user bitrix -ls 2>/dev/null Внимательно изучите вывод. Любой исполняемый файл (`-rwxr-xr-x`) в `/tmp` или `/dev/shm` — это почти 100% вирус.
Шаг 3: Поиск веб-шеллов на сайте
Взлом почти наверняка начался с загрузки PHP-шелла. Его нужно найти и удалить.bash Скопировать
Закрыть блок
# Ищем файлы, содержащие потенциально вредоносные PHP-функции.
# Эта команда может дать ложные срабатывания, но часто находит шеллы.
# Она ищет функции, которые часто используются во вредоносах.
grep -rPl --include=\*.php "eval\(|base64_decode|gzuncompress|str_rot13|shell_exec|passthru|proc_open" /home/bitrix/www/ Просмотрите список файлов, который выдаст эта команда. Откройте каждый из них и посмотрите на код. Легитимный код Битрикса может использовать `eval` или `base64_decode`, но если вы видите длинную, запутанную, нечитаемую строку в `eval(base64_decode(...))`, — это точно веб-шелл.
Шаг 4: Проверка целостности Битрикса
В Битриксе есть встроенный инструмент, который проверяет, не были ли изменены файлы ядра и стандартных модулей.
- Зайдите в административную панель сайта.
- Перейдите в `Настройки -> Инструменты -> Проверка системы -> Сканер безопасности`.
- На вкладке "Контроль целостности" запустите проверку.
Если сканер покажет, что какие-то файлы ядра были изменены, — это прямое указание на то, что их модифицировал злоумышленник.
Резюме для вас:
- Главная цель: Найти файл майнера (`kworker`). Используйте `ps` и `/proc` (Шаг 1).
- Вторая цель: Найти веб-шелл на сайте. Используйте `grep` по PHP-файлам и сканер безопасности Битрикса (Шаги 3 и 4).
- Как только найдете вредоносный файл, удалите его.
- Как только найдете веб-шелл, удалите его и проанализируйте логи веб-сервера (`/var/log/httpd/access_log` или `/var/log/nginx/access.log`) за дату изменения этого файла, чтобы понять, как его загрузили.