Высокая загрузка процессора, зависания сайта или Битрикс24 и странное поведение отдельных интерфейсов не всегда означают проблемы с производительностью. Иногда причина значительно серьезнее - сервер может быть заражен майнером.
В одном из проектов мы столкнулись именно с такой ситуацией. Диагностика показала, что заражение затронуло сразу несколько уровней: на сервере работал майнер, были созданы механизмы его автоматического запуска, а вредоносный JavaScript дополнительно внедрялся в страницы и REST-ответы Битрикс.
Разберем, по каким признакам можно заметить такое заражение, какие части 1С-Битрикс и сервера стоит проверять и почему простого удаления процесса майнера недостаточно.
С чего начинается проблема
Первым заметным симптомом стала аномальная нагрузка на процессор. Несколько ядер практически постоянно были загружены, хотя обычная работа проекта такой нагрузки не создавала.
Одновременно появились другие признаки:
- сайт и Битрикс24 периодически зависали;
- некоторые интерфейсы загружались некорректно;
- в системе присутствовал процесс с очень высокой нагрузкой CPU;
- процесс маскировался под обычное системное имя;
- появились исходящие соединения с неизвестными серверами.
На первый взгляд это можно принять за проблему PHP, MySQL, nginx или самого Битрикс. Поэтому при резком изменении нагрузки важно не ограничиваться оптимизацией сайта, а посмотреть, какие именно процессы используют ресурсы сервера.
Как майнер попадает на сервер
В рассматриваемом случае в каталоге /upload/ находился PHP-веб-шелл.
Само наличие возможности загрузить файл еще не означает, что его получится выполнить. Критической проблемой стало то, что конфигурация nginx разрешала запуск PHP внутри /upload/.
Получилась следующая цепочка:
- В каталог загрузок попадает вредоносный PHP-файл.
- Файл вызывается через HTTP и выполняется веб-сервером.
- Через веб-шелл злоумышленник получает возможность выполнять команды на сервере.
- Устанавливаются майнер и дополнительные механизмы доступа.
- Создаются способы автоматического восстановления майнера после его остановки.
Поэтому при расследовании подобных инцидентов важно проверять не только сам вредоносный процесс, но и то, каким способом он оказался на сервере.
Что меняется после получения доступа
Заражение может не ограничиваться одним исполняемым файлом. В нашем случае использовалось сразу несколько механизмов.
Майнер на сервере
Вредоносный процесс запускался из временного скрытого каталога и маскировался под привычные системные процессы.
При этом файл после запуска мог быть удален с диска, а процесс продолжал работать из памяти. Поэтому обычный поиск подозрительных файлов не всегда показывает источник высокой нагрузки.
Автоматический перезапуск
Чтобы майнер снова запускался после остановки, создавались cron-задачи и дополнительные скрипты-дропперы.
Это важный момент: если просто завершить процесс, через некоторое время он может появиться снова.
Поэтому обязательно нужно проверять:
- cron root;
- cron пользователя веб-сервера;
/etc/cron.*;- временные каталоги;
- неизвестные исполняемые файлы;
- systemd и другие механизмы автозапуска.
Посторонние SSH-ключи
Еще один способ сохранить доступ - добавить свой ключ в authorized_keys.
После этого злоумышленнику уже не обязательно использовать первоначальную уязвимость сайта: доступ к серверу может сохраниться отдельно.
Поэтому после компрометации нужно проверять SSH-ключи всех пользователей с административными правами.
Как заражается сам 1С-Битрикс
Отдельная часть проблемы была обнаружена уже внутри файлов Битрикс.
Вредоносный JavaScript был добавлен в файлы ядра, которые подключаются при обработке большого количества запросов.
В результате внешний скрипт попадал не только в обычные HTML-страницы, но даже в ответы REST API.
Это особенно неприятный сценарий: серверный майнер расходует ресурсы сервера, а внедренный JavaScript может дополнительно выполняться в браузерах пользователей.
Более того, если JavaScript попадает туда, где приложение ожидает чистый JSON, интерфейс начинает работать нестабильно. REST-метод может корректно сформировать данные, но после JSON сервер допишет посторонний . Для браузера это уже некорректный ответ API.
В результате отдельные части Битрикс24 могут зависать или оставаться в состоянии загрузки, хотя сам REST-метод и база данных работают нормально.
Какие файлы и каталоги проверять
При подобных симптомах мы бы начинали проверку сразу в нескольких направлениях.
Внутри проекта 1С-Битрикс:
- PHP-файлы в
/upload/; - временные каталоги загрузки;
/bitrix/php_interface/;/local/;- измененные файлы ядра;
- глобально подключаемые файлы;
- неизвестные PHP-файлы в каталогах, где их обычно быть не должно.
На уровне сервера:
/tmp/;/var/tmp/;/dev/shm/;- cron;
- systemd;
- SSH-ключи;
- активные процессы;
- исходящие сетевые соединения.
Полезный признак - процесс, исполняемый файл которого уже удален с диска. В Linux такой процесс продолжает работать, пока не будет завершен.
Почему нельзя просто удалить майнер
Самая опасная ошибка - найти процесс с высокой нагрузкой, остановить его и считать проблему решенной.
Майнер - это уже следствие.
Если оставить веб-шелл, cron-задачу, SSH-ключ или другой механизм доступа, вредоносный процесс можно запустить снова.
Поэтому очистку нужно проводить как цепочку:
- Остановить вредоносные процессы.
- Найти и удалить механизмы автоматического запуска.
- Проверить cron, systemd и SSH.
- Найти и удалить веб-шеллы.
- Восстановить зараженные файлы Битрикс.
- Проверить временные каталоги.
- Проверить исходящие соединения.
- Закрыть первоначальную точку входа.
Только после этого можно говорить о том, что непосредственное заражение купировано.
Как закрыть выполнение PHP в /upload/
Для 1С-Битрикс каталог /upload/ предназначен для пользовательских и служебных файлов, но выполнение загруженных PHP-скриптов там обычно не требуется.
Поэтому дополнительной защитой становится запрет выполнения PHP и других потенциально исполняемых файлов внутри /upload/ на уровне веб-сервера.
В нашем случае соответствующее ограничение было добавлено в nginx.
Это принципиально отличается от простого удаления найденного веб-шелла: даже если похожий PHP-файл снова каким-либо способом окажется в /upload/, веб-сервер не должен его выполнить.
При этом подобные изменения конфигурации необходимо тестировать на конкретном проекте, чтобы не нарушить работу легитимных компонентов и интеграций.
Что делать после очистки
Даже если нагрузка нормализовалась и вредоносные процессы больше не появляются, работа на этом не заканчивается.
После получения злоумышленником расширенного доступа потенциально скомпрометированными нужно считать используемые на сервере учетные данные.
Следующий этап включает:
- смену SSH-паролей и ключей;
- смену административных доступов;
- смену паролей к базам данных;
- проверку FTP и других способов доступа;
- ревизию API-ключей и интеграций;
- проверку администраторов Битрикс и Битрикс24;
- обновление 1С-Битрикс и установленных модулей;
- настройку мониторинга нагрузки и подозрительных процессов.
Отдельно важно разобраться с уязвимостью, которая позволила загрузить или выполнить веб-шелл. Сам факт обнаружения файла в определенном каталоге еще не доказывает конкретную уязвимость модуля - первоначальный способ загрузки нужно подтверждать отдельно.
Почему после root-компрометации стоит готовить новый сервер
Есть еще один принципиальный вопрос: можно ли после такой очистки продолжать полностью доверять существующей операционной системе?
Если злоумышленник получил root-доступ, он потенциально мог изменить не только файлы сайта, но и системные компоненты, конфигурацию, пользователей, службы или журналы.
Проверить наиболее очевидные механизмы можно. Но гарантировать отсутствие неизвестной закладки значительно сложнее.
Поэтому после стабилизации проекта разумный следующий этап - подготовить чистый сервер и перенести проект на заново установленное окружение.
При таком переносе важно не копировать старую систему целиком. На новый сервер должны переноситься проверенные данные проекта, база и необходимый кастомный код. Системную среду лучше развернуть заново, а файлы ядра и переносимый код дополнительно проверить.
Что получилось
После очистки вредоносные процессы были остановлены, инъекции из файлов Битрикс удалены, механизмы автоматического запуска отключены, посторонний доступ убран, а выполнение PHP в каталоге загрузок запрещено.
В результате нормализовалась нагрузка сервера и перестал внедряться посторонний JavaScript в страницы и REST-ответы.
Но основной результат такой работы не в том, что удалось завершить процесс с высокой нагрузкой. Важно было восстановить всю цепочку заражения и закрыть механизм, который позволял вредоносному коду выполняться на сервере.
Ценность
Для бизнеса заражение сервера - это не только вопрос нагрузки или технической безопасности.
Майнер может замедлять сайт, мешать работе сотрудников в Битрикс24, создавать дополнительную нагрузку на компьютеры пользователей и означать наличие постороннего доступа к инфраструктуре компании.
Поэтому задача диагностики - не просто вернуть нормальную загрузку CPU, а понять масштаб компрометации, восстановить нормальную работу систем, закрыть точку входа и определить, можно ли дальше доверять существующему серверу.
Вывод
Если сервер на 1С-Битрикс неожиданно начинает потреблять значительно больше ресурсов, а сайт или Битрикс24 ведут себя нестабильно, стоит проверять не только производительность PHP, MySQL и компонентов.
Высокая нагрузка может быть только первым заметным симптомом более серьезной проблемы.
Правильная последовательность в таком случае: найти вредоносный процесс, определить механизмы его запуска, проверить файлы Битрикс и доступы, найти точку входа, закрыть ее, сменить скомпрометированные учетные данные и после серьезной компрометации подготовить перенос на чистое окружение.
Диагностика заражения должна не только вернуть нормальную работу сайта и Битрикс24, но и найти точку входа, закрыть механизмы повторного запуска вредоносного кода и определить, можно ли дальше доверять существующей инфраструктуре.
