Для контроля происходящего в операционной системе не хватит рук и глаз человека, а для целой корпоративной сети, где поток событий может зашкаливать 3000/сек, тем более. Во многих ОС уже предустановлены стандартные утилиты логирования, которые записывают происходящие действия в системе, для Linux – это syslog и любые виды ее реализации, а для Windows – это Windows Event Logs.
Но часто функционала стандартных решений недостаточно, к примеру в syslog Linux нет политик аудита, которые бы определили, что из всего массива информации необходимо собирать, а что игнорировать. Как раз для этого есть альтернативные решения!
Как работает Auditd?
Auditd – это подсистема логирования, которая позволяет, используя политики аудита, модуль ядра и прочее ПО, фиксировать события на ОС в журнал. Состав такой подсистемы представляет собой совокупность:
- клиентской утилиты auditctl, которая передает демону настройки, новые правила;
- демона auditd, который занял файловые сокеты для прослушивания обращений auditctl и логов с ядра;
- ausearch утилиты для поиска логов по параметрам;
- конфигурационных файлов /etc/audit + плагинов + политик аудита или же правил.
Так как выполнение почти любого действия на ОС сопровождается обращением к ядру через системные вызовы, то процесс логирование действия субьектов в ОС происходит следующим образом.
К примеру, процесс с сервером SSH решил занять сетевой сокет, о чем сообщает ядру через системный вызов socket(). Тот в свою очередь обрабатывает его запрос и генерирует запись, в которой указывает все основные параметры вызова, после чего сохраняет его в буфере аудита. От туда логи направляются через IPC или же Inter Process Communication алгоритм на файловый сокет, который занял демон auditd. Внутри него уже происходит процесс фильтрации по правилам и он выбирает, что нужно сохранить из полученных данных.
При необходимости, отфильтрованные пакеты могут быть отправлены на серверы-коллекторы, которые передадут данные SIEM или иным СЗИ. Но в данном материале мы рассмотрим исключительно подсистему на локальном хосте.
Как установить и настроить Auditd?
Для установки достаточно использовать базовый репозиторий, где уже внесен бинарный файл auditd, установка для разных дистрибутивов будет отличаться. Для deb-подобных необходимо использовать команду:
Для rpm-подобных дистрибутивов подойдут уже команды вида:
После чего автоматически будет поднят демон для прослушки логов и их обработки auditd:
Вся подсистема разворачивается автоматизированно и независимо от администратора системы. Когда убедились, что нужная служба успешно запущена – перейдем к настройке политик, которые определят, что будем хранить из массы существующих событий. Для этого откроем директорию правил/политик, в вашем случае вы можете назвать правило любым удобным наименованием, но только с форматом файла .rules:
Рассмотри каждую из строк представленных в конфиге по умолчанию:
- -D опция удаляет ранее добавленные правила в память службы, во избежание конфликтов;
- -b устанавливает размер буфера аудита для событий, перед тем, как записать файл в лог;
- –backlog_wait_time 60000 параметр устанавливает максимальное время (в миллисекундах), в течение которого демон аудита будет ожидать отправки событий, если буфер заполнен. В этом случае он ожидает до 60 секунд, прежде чем принудительно очистить журнал;
- -f 0 — использование минимального уровня сообщений (silent);
- -f 1 — запись только критически важных событий (сжатый вывод);
- -f 2 — более подробные сообщения (по умолчанию).
А так же само правило политики аудита, которое как раз из разнородного массива событий отфильтрует необходимые.
Как писать правила для auditd?
Всего существует два типа написания правила в auditd, первого вида для мониторинга системных вызовов к файлам и директориям:
Данное правило позволяет зарегистрировать запросы на работу с объектом файловой системы в режиме записи и изменения атрибутов. Опция -w указывает путь к отслеживаемому файлу, -p атрибуты файла rwx на мониторинг, а так же доп фильтры -F. Если все эти пункты верны, то событие записывается в log-файл службы!
Или же более расширенный формат второго вида, где будет явно указан системный вызов и фильтр, применяемый к событию:
Где опция -a (append) добавит новое правило в конец списка, always/never действие определяющее логировать событие или нет. -S определяет тип системного вызова, вот основные:
- open – обращение к объекту файловой системы;
- execve – загрузка приложения в память процесса. Можно использовать для отслеживания запуска ПО, так как первый системный вызов fork() создает процесс, а execve загружает файлы в память нового процесса;
- socket – обращение на создание сокета для межсетевого/межпроцессорного общения приложений;
- listen – вызов позволяет начать прослушивание входящих запросов на сокете;
- setreuid/setregid – вызов реализует повышение/понижение привилегий для процесса.
Реальные кейсы применения
Для таких средств, как SIEM/EDR/Zabbix и т.д., которые позволяют проводить мониторинг производительности и безопасности существующей инфраструктуры необходимы логи с машин. Рассмотрим задачу, где необходимо отследить кто запускал зараженный Docker-контейнер, повысив права от обычного пользователя до root.
Отследим системные вызовы на запуск контейнера командой sudo strace -o ss.txt <вредоносная_команда> :
Вывод достаточно большой, с помощью утилиты grep можно отфильтровать по ключевым системным вызовам из файла ss.txt:
Как видим, были запущены два процесса с двумя PID 2545, 2547, в которые загрузили исполняемые файлы из путей /usr/bin/sudo|docker. Напишем правило под найденное событие:
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/sudo -F auid!=0
-a always,exit -F arch=b64 -S execve -F exe=/usr/bin/docker -F auid!=0” | tee -a /etc/audit/rules.d/audit.rules && auditctl -R /etc/audit/rules.d/audit.rules
После выполнения команды загрузки правил в модуль ядра подсистемы логирования, необходимо проверить корректность выполненной операции:
В конце можем увидеть наши загруженные правила, значит операция прошла успешно! Запустим docker от sudo и зафиксируем логи в стандартном файле:
После фильтрации многих зафиксированных событий в папке сохраненных логов, можем увидеть системные вызовы execve с AUID или же реальным UID отличным от root. Данное событие может свидетельствовать о инциденте ИБ, которое нарушило политику, а значит может быть атакой! Логи используются для проактивного детектирования и митигации угроз, а так же мониторинга состояния сервисов и системы в целом.
Обобщая алгоритм работы сервиса уточним, что при работе процесса в ОС генерируется множество запросов к ядру, которые можно отследить. Политика аудита позволяет из миллиона событий выбрать самые необходимые и важные, которые затем можно передать на средства аналитики или использовать для отладки работы системы!