CGroups, или официально контрольные группы ( control groups ) относительно новое дополнение к ядру Linux. Изначально появившись в Red Hat Enterprise Linux 6 и Linux 2.6.24, cgroups позволяют пользователю перераспределять такие ресурсы, как процессорное время, пропускную способность сети, или оперативную память между процессами системы. CGroups предоставляют системному администратору возможность детального контроля над системными ресурсами, а также вести учет процессов, что экспоненциально увеличивает эффективность его работы.
В качестве вступления
Процессы в системе Linux порождаются вызовом одной из системных функций: fork() или execve() . Все процессы в системе Linux являются потомками одного инициирующего процесса, запускаемого ядром во время загрузки системы. Следует также отметить, что каждый процесс в системе Linux, за исключением инициирующего, наследует системное окружение своего родителя. Более того, в контексте cgroups, дочерний процесс порожденный с помощью функции fork(), унаследует членство в cgroups от своего родителя. Любой процесс, созданный с помощью функции execve(), тоже будет участвовать в cgroups на правах своего родителя.
Еще ближе к делу
В качестве примера охоты на вредоносное ПО, допустим, что у нас есть ОС Linux с бинарником meterpreter под именем «atd». Как должно быть известно любому пользователю Linux, «atd» является предшественником демона cron, и его до сих пор можно найти в различных системах. Давайте предположим, что некому злоумышленнику удалось получить права root-пользователя на нашей скомпрометированной системе, а злонамеренный бинарный файл «atd» используется им в качестве бэкдора в нашей системе. Вывод команды ps -elf ,в этом случае, может не содержать ничего подозрительного, поскольку бинарный файл atd мог быть запущен без аргументов командной строки. ( На самом деле легитимный бинарный файл atd всегда будет запускаться с аргументом -f, но для нашего примера давайте предположим, что люди, ответственные за безопасность системы, упустили этот факт ). Однако, если кто-нибудь, с помощью метода, показанного ниже, увидит принадлежность этого специфического процесса к контрольной группе user.slice, он поймет, что этот бинарный файл, на самом деле не тот, чем кажется. Системные бинарные файлы, запускаемые ядром, будут всегда отображаться в контрольной группе system.slice, но никак не в user.slice. Для охотника за вредоносными программами - это явный признак того, что в системе происходит нежелательная активность.
Основы CGroups
Давайте теперь чуть углубимся в изучение контрольных групп , и посмотрим их работу на конкретных примерах. Cgroups имеют иерархическую структуру, и дочерняя контрольная группа наследует многочисленные атрибуты родительской. Это позволяет организовать иерархическое представление процессов, что очень удобно, в контексте поиска вредоносных программ. Запуск команды system-cgls -no-pager позволяет охотнику за вредоносными программами просматривать все контрольные группы в системе. Само собой, команду следует запускать с привилегиями суперпользователя!
На изображении выше мы можем видеть иерархическую структуру, корнем которой будет контрольная группа user.slice, а также различные процессы, входящие ее дочерние контрольные группы . Более того, мы видим все аргументы командной строки, которые были использованы для порождения этих подчиненных процессов системными вызовами fork() или execve() . И все это может немедленно указать сообразительному охотнику, что во вверенной ему системе Linux происходит подозрительная активность, которую было бы трудно изобличить другими способами.
Рассмотрим приведенный ниже пример. Мы видим запущенную службу systemd-udev.service, а также ассоциированный с ней бинарный файл( /lib/systemd/systemd-udevd ). Было бы несправедливым считать, что этот путь к бинарному файлу, службы udev.service, выглядит как-то подозрительно. Все выглядит нормально: все там, где надо — в контрольной группе system.slice. Однако, что если бы мы заметили, что “systemd-udevd.service” запущена в контексте контрольной группы user.slice? Тогда это стало бы верным сигналом к тому, что, неплохо бы проверить происхождение бинарного файла этой системной службы. Вся прелесть «охоты» на вредоносное ПО с помощью контрольных групп заключается в том, что активность пользователя, в отличие от активности ядра, легко заметить, поэтому любое несоответствие сразу бросается в глаза.
Чтобы продемонстрировать эту концепцию давайте породим процесс /bin/bash, и назовем его “Nothing_To_See_Here”.
Порождая процесс таким образом, через exec(), мы имитируем запуск бинарного файла без каких-либо аргументов командной строки, и это можно проверить выполнив команду ps -elf
Для того, чтобы установить принадлежность процесса к той, или иной контрольной группе, у нас есть два способа: мы можем использовать, уже описанную выше, команду system-cgls , или получить идентификатор процесса ( PID ) и выполнить команду cat /proc/[PID]/cgroup, как показано на изображении ниже:
Любой из двух методов, продемонстрированный выше, даст информацию, которую вы ищете. Таким образом, ключом к поиску вредоносного ПО с помощью контрольных групп, является выявление в системе подозрительного процесса и проверка его принадлежности к той или иной контрольной группе. А после этого, рассуждая логически, нужно решить должен ли данный процесс принадлежать к этой группе или нет. Если нет - это будет поводом для дальнейшей проверки подозрительного процесса.
Автор: ice-wzl
