В апреле 2025 на сервере клиента нашёлся xmrig, спрятанный за подменённой системной библиотекой libsystemd-shared. Рядом — контейнер с открытым Docker API без аутентификации и больше сотни лишних слоёв в overlay2. Майнера прибили за ночь, по итогам выходных написали отчёт об инциденте. Но история началась раньше: ещё в январе 2025 вирус на сервере ClickHouse заставил срочно переезжать. Дальше — история входов с белым списком IP (она сразу поймала реальную утечку доступов), контроль экспортов и плановая миграция инфраструктуры в январе 2026, с документацией на сто с лишним страниц.
Сводка
| Отрасль | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» |
| Формат сотрудничества | Регулярное сопровождение + реагирование на инцидент + проектная миграция |
| Тип проекта | Реакция на два инцидента, ТЗ системного укрепления, миграция инфраструктуры |
| Объём работ | Реагирование на инциденты (rootkit, майнер); расследование и отчёт; ТЗ безопасности (мониторинг доступа, роли, контроль экспортов) + срочный срез; перенос на новый сервер под ISPManager |
| Дата проекта | 28 января 2025 — 29 января 2026 (около года) |
| Трудозатраты | Срочный срез безопасности (10 ч, реализован за день); миграция и реагирование считались отдельно |
| Команда | Антон Херсун (руководитель) и инфраструктурное подразделение Xaver Pro; систему ролей и прав вёл наш профильный разработчик |
| Технологический стек | Docker (очистка) · ClickHouse + репликатор · ISPManager · Laravel |
| Сдано | Сервер очищен от rootkit и майнера, поставлены история входов и белый список IP (поймали передачу доступов третьим лицам), инфраструктура перенесена на новый сервер с полной документацией |
Постановка задачи
Внутренняя платформа клиента из аналитической панели выросла в систему, которой пользуются десятки людей со стороны заказчика и его партнёров. Чем заметнее система, тем больше желающих присмотреться к чужим мощностям и чужим данным. За год проявились обе угрозы.
28 января 2025 года на сервере, где развёрнут ClickHouse, завёлся вирус и начал грузить систему. Причина оказалась банальной: сервер давно не обновлялся и накопил уязвимости. На ту субботу мы спланировали и выполнили срочный комплекс: временно вернули поиск документов на MySQL, перенесли всё на новый сервер, проверили работоспособность и предложили план регулярной профилактики, чтобы такое не повторялось.
Повторилось в апреле. 8 апреля пользователи стали жаловаться, что виджет долго отвечает. К ночи стало понятно: сервер ClickHouse на Timeweb взломан через открытый Docker API, и на нём добывают криптовалюту. Злоумышленник создал привилегированный контейнер с монтированием корневой файловой системы хоста, выполнил команды под root, установил скрытый майнер xmrig и подменил системную библиотеку libsystemd-shared версией с сигнатурой HEUR:Rootkit.Linux.Processhider — чтобы майнер не был виден в ps и top.
Что в этом сложного. Для внутренней B2B-платформы самое опасное не отказ, а тихая компрометация. Шифровальщик виден сразу: бизнес встаёт. Майнер с rootkit может месяцами выжирать процессор и маскироваться от стандартных инструментов. Когда его наконец находят, у владельца возникает вопрос «а что ещё могли получить?» — и без подготовленной инфраструктуры ответа на него нет. Удалением файлов тут не отделаешься. Нужен постоянный мониторинг, чтобы следующий инцидент не обнаружился случайно, и нужно видеть, кто и откуда входит. А на случай, когда сервер всё-таки придётся пересоздавать, должна лежать свежая копия данных.
Как мы это сделали
Реагирование на апрельский инцидент. Майнера и rootkit прибили за ночь, работоспособность восстановили к утру следующего дня; на случай скрытых изменений наготове была свежая резервная копия сервера. За выходные провели полное расследование: подменённая системная библиотека, скрытый майнер, больше сотни неиспользуемых слоёв в /var/lib/docker/overlay2 — следы работы атакующего. Удалили, восстановили оригинальную библиотеку, закрыли точку входа, ротировали ключи. Всё зафиксировали во внутреннем отчёте об инциденте и передали клиенту. Месяц по защите вышел дороже планового бюджета, 15 часов вместо 5. Мы предупредили об этом сразу и закрыли остаток из других периодов абонемента: это наши риски, а не сюрприз в счёте.
Что выросло из инцидента. После апреля серверную рутину (мониторинг с алертами, резервные копии, плановые апгрейды серверов) перевели в формат регулярного серверного сопровождения — об этом у нас отдельный кейс. Для сюжета безопасности из неё важен один эффект: с июня 2025 алерты по нагрузке и диску приходят прямо в рабочий чат, и следующую аномалию первой увидит автоматика, а не пользователи, у которых что-то начало тормозить.
ТЗ безопасности: почему мы намеренно его раздробили. В ноябре 2025 заказчик пришёл с запросом по контролю доступов на портал. Мы оформили полное техническое задание с оценкой и сами же честно сказали: объём вышел больше, чем хотелось бы для одного захода. Самый тяжёлый блок — контроль множественных одновременных сессий с привязкой к устройству или городу: в стандартном функционале такого нет, без переписывания авторизации не обойтись. Вместо того чтобы тянуть большой блок целиком, мы предложили вырезать из него то, что нужно закрыть сейчас, и отдельным маленьким срочным ТЗ на 10 часов сделать это немедленно. Срочное и полное развели специально: иначе срочное никогда не доходит до сдачи.
Почему детектор подозрительной активности нельзя строить на IP. В обсуждении ТЗ всплыл нюанс из практики клиента: у большинства пользователей IP динамический, меняется за день-неделю, и в логах это выглядит так, будто человек заходит с сотни адресов. Поэтому эвристику подозрительной активности правильно строить на связке «отпечаток устройства плюс локация (страна, город)», а не на голом IP. И ещё: закрытый браузер не завершает сессию, поэтому лимит одновременных сессий обязан корректно переживать ситуацию «забыл выйти и зашёл с другого устройства» — нужно ждать таймаута. Эти оговорки и есть причина, по которой полноценный контроль сессий стоит дороже и вынесен из срочного среза.
История входов и белый список IP: что они сразу показали. Срочный срез профильный разработчик по правам и ролям сделал за день. Появилось меню «История входов»: каждый вход пользователя пишется в таблицу с IP и виден администратору. В редакторе пользователя появилось поле белого списка IP и галочка «пускать только с разрешённых адресов»; отдельная колонка общих адресов на уровне компании, чтобы не вбивать один и тот же серверный IP каждому; роль суперадмина не ограничивается; для массовой простановки и снятия ограничений добавлены отдельные права доступа. Результат не заставил себя ждать: по истории входов заказчик зафиксировал реальные факты передачи доступов третьим лицам и начал внутреннее расследование. Инструмент окупился в первые же дни — показал то, чего без него вообще не было видно.
Роли и контроль экспортов. Следом доработали систему прав: добавили роли под реальные потребности и закрыли правами доступа экспорт отчётов (общих, отдельных, мультиотчётов и базы новых участников рынка), а заодно копирование данных из таблиц «выделить-скопировать». Мы честно предупредили: защита от копирования поверхностная, кто умеет читать ответ сервера в консоли браузера, всё равно достанет данные. Для отсева очевидных утечек этого достаточно, и клиент сознательно выбрал этот уровень. Для аналитической платформы экспорт и копирование — главный канал возможной утечки, поэтому контроль над ними важнее, чем кажется.
Миграция на новый сервер (январь 2026), с полной документацией. К январю 2026 основной сервер упёрся в лимиты: алерты по диску шли постоянно. Подобрали тариф с запасом (200 ГБ, панель ISPManager) и зафиксировали исходное состояние сервера: версию панели и ядра, набор аддонов (антивирус по расписанию, мониторинг, файловый менеджер, конструктор сайтов), лимиты доменов и срок лицензии. 20 января подготовили документ миграции на сто с лишним страниц и передали в техподдержку хостера: перенос шёл по этому документу и под контролем. 24 января в 9:00 по Москве остановили основной сервер и начали перенос; 25 января закончили, прогнали проверки, заодно ускорили таблицу деклараций в ClickHouse. Старый сервер не удаляли сразу: несколько дней наблюдали, что ошибок нет и парсинг работает штатно, и только 29 января отключили и удалили его. Одна оговорка: сервер с ClickHouse, репликатором и S3-дампером остался независимой машиной, в миграцию он не входил и продолжил работать.
Результаты
| Метрика | Значение |
|---|---|
| Реагирование на инциденты | Два инцидента (январь и апрель 2025) закрыты; майнер и rootkit удалены, отчёт зафиксирован |
| Скорость восстановления | Майнер прибит за ночь, работоспособность восстановлена к утру |
| Контроль доступа | История входов + белый список IP (10 ч, реализован за день); сразу выявлены факты передачи доступов третьим лицам |
| Контроль утечек | Права доступа на экспорт отчётов и базы новых участников рынка, ограничение копирования из таблиц |
| Миграция инфраструктуры | 24–25.01.2026, плановая, по документации на сто с лишним страниц; старый сервер удалён 29.01 |
| Календарь | 28 января 2025 — 29 января 2026 |
После двух инцидентов сервер очищен, точки входа закрыты. Контроль доступа из теоретического стал рабочим: история входов и белый список IP в первые же дни показали реальную утечку доступов. Экспорт и копирование данных закрыты правами доступа. В январе 2026 платформа переехала на сервер с запасом мощности — по подробной документации и без потери данных.
Процесс и хронология
| Этап | Период | Результат |
|---|---|---|
| Инцидент на сервере ClickHouse | 28 января 2025 | Срочный перенос, временный возврат поиска на MySQL, план профилактики |
| Инцидент: компрометация через Docker API | 8 апреля 2025 | Майнер и rootkit найдены и удалены за ночь |
| Отчёт об инциденте | 14 апреля 2025 | Расследование за выходные, документ передан клиенту |
| ТЗ безопасности (полное) | ноябрь 2025 | Оценка показала большой объём → решили раздробить |
| Срочный срез безопасности | 18–19 ноября 2025 | История входов + белый список IP за день; поймали утечку доступов |
| Роли и контроль экспортов | ноябрь 2025 | Пермишны на экспорт и копирование, новые роли |
| Подготовка миграции | 16–20 января 2026 | Аналитика сервера, документ миграции |
| Миграция на новый сервер | 24–29 января 2026 | Перенос, проверки, удаление старого сервера |
Команда
- Антон Херсун, Xaver Pro, руководитель: координация реагирования на инциденты, формализация отчёта, согласование ТЗ безопасности, управление миграцией.
- Инфраструктурное подразделение, отдельная команда по серверной поддержке внутри Xaver Pro. На них очистка сервера после инцидента и миграция на новый сервер. Серверная работа и разработка панели — разные дисциплины, поэтому и команда специализированная.
- Разработчик прав и ролей сделал срочный срез безопасности (история входов, белый список IP, права доступа на экспорт и копирование). Систему доступа на платформе ведёт профильный человек, а не общий пул.
Скриншоты и материалы
Будут добавлены отдельным проходом: нужны скриншоты мониторинга, истории входов и схема «до и после» инфраструктуры, прошедшие обработку приватности.
Если на сервере что-то странное (необъяснимая нагрузка CPU, неизвестные контейнеры, незнакомые процессы), пришлите вывод
ps aux,docker ps -aи логи последней недели. Скажем, искать ли криптомайнер и rootkit или это просто кривой конфиг. Срочный разбор бесплатный.