Анастасия Кузнецова, Security Vision

Данное исследование было проведено в рамках проработки агентской истории для целой группы продуктов.

И снова здравствуйте! Продолжаем наш цикл статей о методах сбора данных (Прошлые статьи здесь и здесь). В данной (третьей) статье опубликована сжатая аналитика по двум технологиям сбора на Linux Endpoint на основе проработки наших продуктов по лог-менеджменту и сбору событий.

Начнем, пожалуй, с самой распространенной и, с позволения сказать, даже legacy-технологии auditd или Linux Audit Daemon. Это компонент пользовательского пространства Linux Auditing System, отвечающий за сбор и сохранение записей журнала аудита на диск.

Чтобы понять, как auditd работает, сначала нужно понять, как в целом работает демон Linux.

Демон — это фоновый процесс, который не зависит от взаимодействия активного пользователя, т. е. обычный пользователь не может контролировать периодическое выполнение демона. Он запускается при загрузке Linux, а процесс init выступает в качестве его родительского процесса. Для запуска и остановки демона необходимо изначально получить доступ к скриптам /etc/init.d в ОС.

В Linux процесс-демон имеет суффикс d. Наличие этого суффикса означает, что процесс является системным (aka демоном), отсутствие – что процесс пользовательский.

Подсистема аудита в Linux состоит из двух групп компонентов - в пространстве ядра это kauditd, а в пользовательском — auditd.

Система аудита является важной частью операционной системы, поскольку она ведет журнал событий, происходящих в системе. Эти журналы могут иметь решающее значение для мониторинга нарушений безопасности или инцидентов безопасности. Однако, auditd не отвечает за просмотр журналов — это можно сделать с помощью ausearch или aureport.

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

Журналы системных событий (/var/log/syslog, /var/log/kern.log, /var/log/messages)
Эти журналы создаются операционной системой и содержат информацию о системных событиях, таких как запуск и завершение работы, системные ошибки и предупреждения.

Журналы событий безопасности (/var/log/secure, /var/log/auth.log)
Эти журналы отслеживают события, связанные с безопасностью, такие как входы пользователей, неудачные попытки входа и другие действия, связанные с безопасностью. Вы можете использовать их для выявления потенциальных нарушений безопасности или несанкционированного доступа к вашей системе.

Журналы событий приложений
Они генерируются программными приложениями и содержат информацию о событиях приложения, таких как ошибки, предупреждения и другие важные события.

Журналы событий сервера (/var/log/access.log)
Генерируются веб-серверами, серверами приложений или базами данных. Эти журналы содержат информацию об активности сервера, например, об ошибках сервера, времени безотказной работы и простоя, производительности и проблемах безопасности. Эта информация полезна системным администраторам для выявления и решения проблем, связанных с сервером.

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

Журналы событий облачного сервиса
Это журналы, которые генерируются облачными сервисами, такими как поставщики Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) и Software-as-a-Service (SaaS). Эти журналы предоставляют информацию о работоспособности, производительности и безопасности облачных сервисов, а также помогают администраторам выявлять проблемы и устранять их.

Журнал событий должен содержать достаточно информации, чтобы помочь в устранении неполадок или анализе проблемы или инцидента.

С помощью аудита можно реализовать журналирование для следующих событий:

доступ к объектам файловой системы (ANOM_MK_EXEC; ANOM_EXEC; PATH);
выполнение системных вызовов (EXECVE; MMAP; MQ_OPEN; SYSCALL);
запуск пользовательских команд (USER_CMD; SOCKADDR);
логины пользователей (USER_LOGIN; ANOM_LOGIN_FAILURES);
действия с учетными записями и привилегиями (ADD_USER; ANOM_LOGIN_ACCT; ANOM_MOD_ACCT).

Полный список типов событий можно посмотреть здесь.

Хотя приложения и базы данных, связанные с продуктом, могут реализовывать различные меры предосторожности для предотвращения этих инцидентов, эти меры могут быть недостаточными даже при таких типовых атаках, как чтение и изменение системных файлов (/etc/sudoers, /etc/passwd, /etc/shadow, /etc/crontab), запуск системных команд/bash, запуск reverse shell, создание/удаление пользователей, добавление процессов в автозагрузку через init/cron/system, удаленная оболочка, запущенная на машине, или другие угрозы, исходящие от злоумышленников, имеющих доступ к машине. Для решения этой проблемы и был создан auditd.

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

Правила для auditd добавляются в файл /etc/audit/rules.d/audit.rules по умолчанию. При запуске системы эти правила считываются утилитой auditctl. Рекомендуется использовать тот же путь для сохранения правил для auditd, чтобы обеспечить бесперебойный доступ к правилам при перезагрузках.

Auditd.conf находится в каталоге /etc/audit/ и является файлом конфигурации для auditd. Он содержит конкретную информацию о конфигурации демона аудита и включает несколько строк конфигурации, где каждая строка имеет ключевое слово, знак равенства и соответствующее значение конфигурации. Некоторые ключевые слова, доступные в файле:

log_file
log_format
flush
freq
num_logs
max_ log_file
max_log_ file_action

Как упоминалось выше, auditd не позволяет просматривать журналы. Для просмотра журналов необходимо использовать утилиту ausearch. Она используется для запроса журналов демона аудита на наличие событий на основе различных критериев поиска.

Вот некоторые из наиболее распространенных вариантов, используемых для запроса журналов.

· -p - поиск событий с указанным идентификатором процесса.

· -m - поиск событий с указанным типом сообщения.

· -sv - поиск событий с заданным значением успешности.

· -ua - поиск события с использованием идентификатора пользователя, эффективного идентификатора пользователя или идентификатора пользователя для входа или auid.

· -ts - поиск событий с временными отметками, равными или более поздними, чем указанное время окончания.

Не существует единого мнения о том, как долго следует хранить журнал. Длительность хранения зависит от требований соответствия, политики информационной безопасности компании, емкости хранилища или внешних требований, таких как GDPR, стандарт Банка России и приказы ФСТЭК.

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

Там, где нет возможности использовать auditd (например, ввиду его низкой производительности), целесообразно применять eBPF. За последние несколько лет eBPF приобрел большую популярность в сообществе Linux и за его пределами.

Классический BPF позволяет пользовательской программе (например, tcpdump) получать определенные сетевые пакеты на основе некоторого фильтра. Фактически фильтрация выполняется внутри ядра Linux. Это значительно повышает производительность, т.к. в пространство пользователя необходимо копировать только пакеты, которые прошли фильтрацию. eBPF – это, в свою очередь, эволюционное развитие BPF, которое используется для безопасного и эффективного расширения возможностей ядра без необходимости изменения исходного кода ядра или загрузки его модулей. Для упрощения можно провести аналогию со своеобразной виртуальной машиной, которая определяет среду, в которой выполняются программы.

eBPF можно использовать где угодно в пространстве ядра или в пространстве пользователя и даже непосредственно на сетевых картах. Возможность выгружать eBPF программы на сетевую карту особенно интересны с точки зрения безопасности. Это означает, что ядро может обрабатывать пакеты только после программы eBPF. Главные варианты использования — это инструменты отслеживания, наблюдения, измерения производительности и безопасности. Многие новейшие инструменты обнаружения, мониторинга и отслеживания производительности написаны с использованием eBPF и получают широкое распространение в облачных средах.

eBPF-программы интересны с точки зрения безопасности, т.к. обладают сверхспособностями. И вот что они могут:

1. Подключаться к системным вызовам и вызовам функций пользовательского пространства, например, манипулировать структурами данных пользовательского пространства;

2. Перезаписывать возвращаемые значения системного вызова;

3. Вызывать системный вызов system(), чтобы создать новый процесс;

4. Некоторые eBPF программы можно запускать на аппаратных устройствах (например, сетевых картах);

5. Атакующая программа eBPF может устанавливаться в качестве rootkit;

6. Использоваться для побега из контейнера.

Вот некоторые из основных областей применения eBPF:

Безопасность

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

Мониторинг и наблюдаемость

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

Сеть

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

Профилирование и трассировка производительности

eBPF позволяет организациям профилировать и отслеживать поведение систем и приложений во время выполнения, позволяя создавать пользовательские инструменты трассировки, которые могут захватывать и анализировать широкий спектр системных событий. Программы eBPF могут использоваться для отслеживания вызовов функций и создания комплексных структур данных на основе статистики, не требуя экспорта больших объемов данных.

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

eBPF позволяет создавать небольшие программы, которые запускаются ядром в ответ на событие (триггер), когда оно проходит определенную точку перехвата (точки трассировки ядра, точки входа/выхода функции, системные вызовы и др.).

Каждая такая программа состоит из двух файлов: для выполнения в ядре (…_kern.c) и из пользовательского пространства (…_user.c). Программа eBPF определяет map (key-value хранилище/мап) и функции, привязанные к разделу (секции). Когда ядро выдает событие определенного типа (например, tracepoint), привязанные функции выполняются. Мапы обеспечивают обмен данными между программой ядра и программой пользовательского пространства. Если есть желание глубоко погрузиться в эту технологию и ее возможности очень советую к изучению следующую книгу, стоит только заполнить форму и скачать.

Благодаря своей архитектуре и модели работы eBPF имеет очевидные преимущества:

eBPF-программа никогда не зациклится и не заблокируется. Сами программы проходят встроенные проверки на то, что они будут выполнены до конца. Процесс верификации отслеживает такие проблемы как: доступ к памяти за пределами выделенного буфера, неавторизованный доступ к функциям ядра и др.

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

eBPF-программа работает в «песочнице» внутри ядра, тем самым обеспечивается необходимая изоляция и снижаются риски.

Итак, мы взглянули на основные технологии мониторинга событий на ОС Linux. Ситуация такова, что, хоть обе технологии все еще встречаются на практике сбора событий, рынок постепенно перетягивает одеяло на eBPF из-за его простоты и гибкости при настройке мониторинга.

За другими полезными и интересными статьями — к нам на Хабр и на наш блог на сайте.

Два столпа Linux мониторинга