Когда мы говорим об атаках через цепочку поставок, обычно всплывает в голове что-то монументальное - SolarWinds, взлом инфраструктуры гигантов. Но правда в том, что сегодня любой бизнес, который нанимает внешних админов или DevOps-инженеров, рискует заполучить зловреда, способного годами сидеть в периметре и сливать базы данных(БД). И вы об этом даже не узнаете…

В этой статье - хочу поделиться реальным случаем из практики. Как взлом ноутбука подрядчика привел к внедрению eBPF-руткита в Linux. Раскрыть атаку помогла… ну, скажем так, случайная оплошность самих злоумышленников.

Симптомы: ничего не падает, но что-то не так

Клиент - крупная компания с десятками сервисов на Ubuntu 2x.xx (версии Ubuntuы не играют роли), развернутых на «железе» в дата-центре. Доступ к серверам есть у нескольких команд подрядчиков: DBA, DevOps, техподдержка. В общем, классическая история для среднего и большого бизнеса.

В компании настроен минимальный SOC, сотрудник SOC заметил странную аномалию: в течение месяца объем трафика, который уходит с сервера БД, стабильно на 5–10% превышал входящий. Вроде бы мелочь, но настораживало.

Провайдер прислал стандартный отчет: «железо и сеть работают идеально». Логи на серверах - тишина, никаких падений процессов. Задача перед нами формально звучала так «Провести аудит и найти причину небольшого расхождения в сетевой статистике». Но при первом же погружении стало понятно, что это не типовой случай, а с “остринкой”. Это целенаправленное и очень хорошо скрытое проникновение, которое случайно «засветилось».

Следствие ведут знатоки!

Следствие ведут знатоки!
Следствие ведут знатоки!

1. Аномалия трафика и след в iptables

Аналитики SOC уже несколько недель мониторили эту странную аномалию: сервер БД стабильно отдавал на 5–10% больше трафика, чем получал. Не похоже на обычную работу приложений. Когда мы начали расследование, первым делом полезли в историю изменений межсетевого экрана. И тут же нашли зацепку.

Примерно месяц назад - как раз когда аномалия только началась - в /etc/iptables/rules.v4 появилось новое правило:

-A OUTPUT -d xxx.xxx.xxx.xxx -p tcp --dport YYYY -j ACCEPT

Правило разрешало исходящие соединения на IP-адрес из пула IP VPN для выделенного подрядчика . Хотя в изначальной конфигурации такого правила не было и недолжно было быть.

2. Несоответствие в /proc: признак руткита

Подключаемся к серверу, начинаем искать следы присутствия. ps auxf показывает только стандартные демоны. Но если сравнить количество директорий в /proc с количеством строк в ps — обнаруживается расхождение: в /proc на одну папку больше. Это классический признак, что руткит перехватывает системные вызовы (getdents, getdents64) и скрывает свои процессы от стандартных утилит. Ну, думаем, нашли - сейчас вытащим модуль. Но .. нет.

3. Тихий убийца: eBPF вместо модуля ядра

Первое подозрение пало на скрытый LKM-модуль. Однако работа с образом VM, загрузка с LiveCD и проверка /proc/modules не выявила ничего подозрительного - список модулей полностью совпадал с эталонным. Это нас озадачило: как тогда скрываются процессы?

Дальнейший анализ показал, что злоумышленники использовали технику, которая набирает обороты - eBPF. С помощью утилиты bpftool мы обнаружили несколько загруженных eBPF-программ и карт, прикрепленных к kprobe-точкам входа системных вызовов __x64_sys_getdents и __x64_sys_kill. Одна из программ была привязана к сокету и занималась копированием трафика, перенаправляя пакеты с данными на ноут подрядчика (С2 -сервер).

Хитрость в том, что eBPF-код живет в ядре, но не отображается в списке модулей. Он загружается через специальный системный вызов и может быть скрыт из пользовательского пространства. Для обнаружения такого руткита требуется либо запуск bpftool с привилегиями root, либо анализ памяти ядра. В нашем случае руткит не скрывал свои eBPF-объекты.

В директории /usr/share/man/man3/ нашелся бинарник systemd-snoop. Он использовал libbpf для загрузки eBPF-программ в ядро. Задача вредоноса - каждую ночь делать дамп таблиц с PII-данными (персональные данные), сжимать их и отправлять на C2-сервер.

4. Цепочка поставок: украденный ключ подрядчика

Смотрим /var/log/auth.log. Вход был выполнен по SSH-ключу, принадлежащему сотруднику компании-подрядчика, обслуживающей базы данных. IP-адрес, с которого пришло соединение (XX.XX.XX.XX), совпадал с IP VPN пулом подрядчика. После выполненных работ c БД, доступ к северу для сотрудника компании-подрядчика был отозван . Но не был отозван доступ к VPN.

Выяснилось: у подрядчика скомпрометировали рабочий ноутбук. Во время плановых работ по настройки сервера с БД, злоумышленники параллельно зашли на сервер, изменили правила в iptables и установили eBPF-руткит для скрытого сбора данных и передачи на С2 сервер.

Как защититься от кражи данных через подрядчиков

Этот инцидент лишний раз показал, что доверие к внешним специалистам должно быть подтверждено техническими средствами тотального контроля.

Обязательная двухфакторная аутентификация для SSH

Даже если ключ украдут, второй фактор остановит злоумышленника. Это единственный способ гарантировать, что за ключом стоит живой человек.

Принцип минимальных привилегий и сегментация доступа

Никакого root по умолчанию. Подрядчику из команды БД не нужен доступ к веб-серверу, и наоборот. Категорически нельзя давать доступ к продакшену напрямую — только через прыжковый хост (bastion host) с полным логированием сессий.

Регулярная ротация ключей и немедленный аудит доступа

Ключи подрядчиков должны перевыпускаться не реже раза в полгода. А если сотрудник увольняется из компании-подрядчика — доступы отзываются в течение 24 часов. Пропишите это в SLA!

Временные сессии VPN
Подрядчику не нужен круглосуточный доступ. VPN-сессии должны выдаваться на время работ, с автоматическим отключением.

Контроль целостности системы (AIDE, Osquery, Falco, Tracee)

Классический контроль целостности файлов (AIDE) против eBPF-руткитов не поможет - они же не создают файлов в lib/modules. Необходимо внедрить мониторинг загрузки eBPF-программ:

  • Используйте bpftool prog list и bpftool map list для периодического сбора информации о загруженных объектах и отправки ее в SIEM.

  • Внедрите аудит системного вызова bpf() через auditd или ebpf_exporter, чтобы отслеживать, кто и когда загружает программы.

  • Возможно использование инструментов вроде Falco или Tracee - они специально созданы для обнаружения аномальной активности eBPF и подозрительных системных вызовов.

Централизованный сбор логов, ELK + NetFlow и SIEM с корреляцией

Логи должны стекаться в защищенное хранилище (ELK, Graylog), куда у злоумышленника нет доступа. Если бы правило iptables с «подозрительным» IP сразу ушло в SIEM и сработала корреляция по GeoIP, атаку обнаружили бы раньше. Плюс — анализ NetFlow: если база данных вдруг начала отдавать трафик на IP незарегистрированный как нормальный трафик, это должно вызывать автоматический алерт. Кореляция событий в момент проведения плановых работ с работой сегмента сети к которому сотруднику компании-подрядчика имет доступ.

GitOps для файрвола

Все правки iptables - только через Ansible (или аналоги) с контролем версий в Git. Ручные изменения запретить. Тогда любое «левое» правило сразу будет видно.

Вывод

Этот случай — наглядный пример того, как аномалия сетевого трафика помогла обнаружить долговременную утечку баз данных. Безопасность цепочки поставок начинается с простого требования к подрядчику: «Предъяви второй фактор и работай только под нашей записью, временной VPN-сессией ». Внедряйте 2FA, контроль целостности и проактивный анализ трафика - и тогда даже самый талантливый злоумышленник не сможет остаться незамеченным.