Сотрудник запустил майнинг на корпоративных серверах: как обнаружить и пресечь

Криптоджекинг, или скрытый майнинг криптовалюты, — это распространённая киберугроза, в рамках данного вида атаки целью злоумышленников становятся вычислительные мощности компаний и физических лиц, на которых путём установки вредоносного программного обеспечения осуществляется добыча (майнинг) криптовалюты.

В случае если в компании был выявлен несанкционированный майнинг на внутренних ресурсах, в первую очередь следует сузить область действия майнингового ПО и выявить конкретные ресурсы, задействованные в данной деятельности. Следующий шаг — сбор необходимой информации о процессах, снятие дампов памяти и системной информации, забор логов аудита для последующего выявления сотрудника, запустившего процесс. Далее ресурс стоит изолировать или провести нейтрализацию ВПО, после чего следует определить сотрудников, имеющих доступ к указанным ресурсам и провести внутреннее расследование. Данный алгоритм рекомендуется регламентировать и оформить в плейбук для ускорения действий со стороны команд производства и ИБ при расследовании инцидента и нейтрализации последствий.

Теперь рассмотрим, как бороться с криптоджекингом и как его предотвращать. Предположим, что мы защищаем компанию-разработчика ПО, в данной компании штат насчитывает 2000 сотрудников, есть отделы разработки, DevOps, DevSecOps, SOC, свои кластеры Kubernetes, локальные вычислительные мощности, а также облачные ресурсы. Составим список активов, которые нам нужно защитить:

— Железные серверы, находящиеся в офисе компании;

— Облачные аккаунты и привязанные к ним ресурсы;

— Кластеры Kubernetes;

— Хранилища артефактов;

— Пайплайны CI/CD.

Теперь, когда мы знаем, что хотим защитить, нам нужно разобраться с тем, как мы будем защищаться. Для этого рассмотрим каждый из активов детальнее и посмотрим на средства защиты информации, которые могут нам пригодиться.

Сперва займёмся железными серверами: предположим, что в нашей компании есть отдельная серверная, где находятся 2 серверные стойки — классическая стойка с мощным железом под кластер виртуализации на основе Proxmox и модная GPU-стойка под обучение больших языковых моделей и их развёртывание. Для защиты вычислительных мощностей в первую очередь стоит обеспечить качественный мониторинг, в случае железа лучше для этого подойдёт отдельный контроллер на материнской плате сервера, который обеспечит доступ к метрикам железа через IPMI (смотрим за температурами, оборотами вентиляторов, напряжением на компоненты и так далее), обращаться к IPMI можно как через консоль ОС, так и по сети, также можно использовать вендорские BMC-решения, если таковые имеются, но самое главное — обеспечить единообразность получения информации, то есть в случае с вендорскими решениями все наши серверы должны относиться к одному вендору, или хотя бы группироваться.

Помимо BMC-решений мы можем получать информацию с помощью утилит lm-sensors и hwmon, но уже на уровне ОС, в таком случае мы можем получить меньше информации, но сможем обеспечить большее покрытие серверов мониторингом с меньшими затратами на настройку. Для GPU-стойки лучше всего подойдут утилиты nvidia-smi или amd-smi, они позволят мониторить нагрузку и прочие параметры графических процессоров. После того как мы разобрались с тем, как мониторить каждый из серверов по отдельности, нам стоит централизовать мониторинг. Для этого подойдут такие системы, как Zabbix или VictoriaMetrics в связке с Grafana.

После настройки мониторинга мы должны настроить оповещение об аномальной активности, например, резко возросла нагрузка и наши процессоры работают на максимальных мощностях, при этом никакой бизнес-нагрузки на данный момент нет, также стоит обращать внимание не только на резкие скачки нагрузки, но и на небольшое возрастание, которое держится статично, чаще всего это будет плановый рост, например, добавление новых виртуальных машин, но также подобное поведение может указывать на более скрытый формат криптоджекинга. Помимо нагрузки стоит следить за состоянием накопителей, если их SMART и прочие показатели начали стабильно ухудшаться и это происходит быстрее, чем планировалось — стоит изучить причину подобной аномалии.

В заключение разбора защиты железных серверов добавлю, что помимо вышеупомянутых способов защиты не стоит пренебрегать установкой SIEM-агентов и антивирусного ПО для возможности раннего выявления вредоносной активности, а также следить за тем, кто и зачем заходит на данные серверы через удалённый доступ, например, по SSH и тщательно следить за прямым доступом к серверному оборудованию, как через СКУД на входе в серверную, так и через регламентацию доступа к ней.

Следующим пунктом на рассмотрение являются облачные аккаунты. Когда речь заходит об облаках, в голове невольно всплывают счета за вычислительные мощности, которые были арендованы и забыты из-за некорректного мониторинга и отсутствия выверенных процессов работы с ними, поэтому, как и с железом, мы начнём с мониторинга. Чаще всего в облачных сервисах уже есть встроенный мониторинг трат, который покажет детализированную информацию о том, за что и сколько компания платит, но по умолчанию эти данные спрятаны в недрах аккаунта, а вечно обновлять страницу в поисках аномалии идея сомнительная, поэтому имеет смысл создать отдельный сервисный аккаунт и через API забирать данную информацию, а после выводить её в ранее развёрнутой Grafana с настроенным алертингом при превышении квот по деньгам и резком росте трат, примером подобных утилит для забора информации является проект opencost, у него также есть собственная панель с информацией по тратам. В продолжение работы с аккаунтами добавлю, что стандартный аккаунт администратора должен быть защищён двухфакторной аутентификацией, желательно с использованием физических ключей аутентификации, а администраторы облака должны пользоваться личными аккаунтами с минимально необходимыми правами, а все создаваемые ресурсы должны автоматически поставляться на мониторинг, как и факт их создания, в случае с виртуальными машинами и кластерами Kubernetes мы также должны обеспечить безопасность данных ресурсов и запускаемого на них ПО, всё также с помощью SIEM-агентов и мониторинга.

Далее подробнее разберём способы защиты Kubernetes кластеров от запуска на них майнеров. В данном случае мы должны защитить как сами ноды кластера, так и сам кластер. В случае нод пользуемся сформированным ранее набором — антивирус, который настраиваем с учётом особенностей работы с Kubernetes, чтобы антивирус не мешал работе кластера, SIEM-агент для слежки за происходящим на сервере, мониторинг можно поставить внутрь кластера, поэтому на ноды ставим только ту часть, которую не сможем достать из кластера, например, мониторинг с помощью BMC-решений, если ноды железные. Далее в сам кластер ставим агентов мониторинга для получения информации по нагрузке, активным подам и существующим ресурсам, выдаём им минимально необходимые права, а также настраиваем политики безопасности для наших пространств имён (namespace), отключаем возможность запуска привилегированных подов, запрещаем запускать поды от root, выставляем лимиты на ресурсы на уровне namespace и подов, защищаем доступ к кластеру через IAM-решение и чётко разграничиваем, что пользователи кластера могут делать, а что нет, вдобавок это поможет нам понять кто из пользователей выполнил конкретное действие, здесь подойдёт как нативный RBAC Kubernetes, так и OIDC провайдеры, такие как Keycloak, Dex или Цифровой Купол. Помимо вышеперечисленных действий можно также определить белый список образов для подов, но данное действие может сильно замедлить рабочие процессы, если не налажен общий процесс между производством и ИБ, для выполнения данного пункта можно использовать Kyverno или OPA Gatekeeper. Также в кластер стоит поставить Falco или Tetragon, эти инструменты помогут защитить рантайм кластера и упростят выполнение вышеописанных шагов.

Следующие пункты — хранилище артефактов и пайплайны CI/CD мы объединим, так как они напрямую связаны друг с другом. Оба пункта включают в себя работу с различными пакетами, такими как зависимости для различных языков программирования (пакеты npm/nuget/pip/maven/apt) и Docker-образы, для обеспечения безопасной работы с данными сущностями есть 2 подхода:

— Белый список из пакетов, который содержит список разрешённых зависимостей с указанием конкретных версий и их хэш-сумм, список пополняется через запрос от производства и для упрощения общего процесса проверка безопасности конкретного пакета/образа должна осуществляться автоматически, в противном случае это замедлит производство, данный подход является наиболее оптимальным за счёт полного контроля за зависимостями, попадающими во внутренний контур компании

— Активный мониторинг и сканирование устанавливаемых зависимостей, а также их блокировка в случае обнаружения вредоносной нагрузки.

Оба подхода включают в себя полный запрет исходящего трафика к публичным хранилищам артефактов и централизованную настройку конечных систем на работу с внутренним хранилищем, например, Nora или KKRepo. Внутреннее хранилище имеет доступ к публичным хранилищам, в случае работы с белым списком артефактов чаще всего требуется дополнительная оснастка для предотвращения скачивания запрещённых пакетов, в случае с активным мониторингом существующих пакетов также требуется использовать дополнительное ПО, при этом хранилища enterprise уровня чаще всего поставляются со встроенным компонентным файрволом и позволяют обеспечить защиту нативно, но требуют дополнительных финансовых вложений.

Перейдём к CI/CD. Здесь, в первую очередь, стоит озаботиться разграничением прав доступа к группам, репозиториям, веткам, переменным окружения, раннерам и прочим сущностям нашей git-платформы, внедрить IAM-решение и регламентировать выдачу доступов на уровне компании. Огромным преимуществом для обеспечения защиты CI/CD будет грамотно выстроенный процесс DevOps и DevSecOps, которые при этом будут работать сообща, а не противостоять друг другу, как это часто бывает. В рамках DevOps-процесса мы должны выполнять харденинг и мониторинг активных раннеров, например, в GitLab, а ещё лучше — отключить возможность их создания, чтобы все непрерывные процессы могли выполняться исключительно на централизованных ресурсах, которые уже поставлены на мониторинг, здесь отлично подойдёт вариант gitlab-runner в Kubernetes, эфемерные раннеры с ограничением по привилегиям и ресурсам — отличный способ снизить поверхность атаки, а мониторим мы пайплайны, работающие подозрительно долго, или те, что тратят много ресурсов на выполнение. Перейдём к DevSecOps — здесь нам нужно собрать и внедрить наш собственный appsec-pipeline, добавить туда сканеры SAST (Semgrep), Bandit, Gitleaks, TruffleHog) и SCA (Trivy, Grype), собирать SBOM (Cdxgen) и проверять полученные зависимости на наличие уязвимостей, например, с помощью платформы Dependency-Track. Замечу, что все процессы CI/CD должны использовать внутреннее хранилище артефактов как источник зависимостей, пакетов и образов, всё это должно быть настроено по умолчанию на уровне систем автоматизации.

Резюмируя, отмечу, что криптоджекинг, несмотря на кажущуюся безобидность на фоне таких атак, как шифрование инфраструктуры, всё же требует проработки на уровне стратегии ИБ. Он предполагает построение мониторинга активов компании наравне с установкой средств защиты информации и принятием мер по укреплению вычислительных мощностей.

Автор: Аверин Андрей Александрович, старший инженер по ИБ, компания Digital Design