Настройка аудита астра линукс

Обновлено: 06.07.2024

Расскажем о том, как использовать auditd. В качестве примера используется сервер с ОС Ubuntu Server 18.04.

Установка

По умолчанию auditd не интегрирован в операционную систему. Установим его штатными средствами:

sudo apt-get install auditd audispd-plugins

Важно! Если серверная платформа находится под управлением CentOS, устанавливать ничего не нужно — демон интегрирован в ОС.

Конфигурирование

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

Если настройки не выполнялись, то таблица будет пустой.

Важно! Удаление правил производится через ключ D.

Для активации мониторинга за конкретным файлом прописываем следующий синтаксис в терминале:

auditctl -a command,action -F path=name_file -F perm=permission

name_file — имя файла, за которым ведется наблюдение со стороны сервиса auditd;
permission — права на доступ.

Поле принимает четыре значения:

R — права на чтение;
W — разрешается изменять;
X — используется для исполняемых файлов, сервис запускает его от своего имени;
A — изменить атрибуты объекта.

Дополнительные ключи, которые идут совместно с командой, расшифровываются следующим образом:

–a: обозначает для демона auditctl список (task, exit, user или exclude) и действие (never или always). Пара перечисляется через запятую.
–F: задает путь к файлу и предоставляет права на поиск.

Если требуется найти определенное событие или объект, используем команду ausearch с ключом –f. Допустим, необходимо просмотреть информацию о том, кто и когда использовал объект /etc/passwd. Прописываем:

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

ausyscall arch number

arch — архитектура операционной системы;
number — числовое значение, полученное через команду uname.

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

Просмотр логов

Условия заданы, аудит проведен, а как же просмотреть результат? Для этого доступна команда aureport. Собранная информация хранится в директории /var/log/audit/, а файлы имеют расширение .log. Общий вид:

aureport option -if filename

option задает ключи, по которым происходит выборка информации;
–if указывает на файл, по которому работает фильтр.

Наиболее часто встречается фильтр по датам. За это отвечают опции --start и --end, после которых следует указание даты и точного времени. К примеру:

aureport --start 07/15/2008 00:00:00 --end 07/19/2018 00:00:00

Другой пример — просмотр всех отчетов, которые хранятся в каталоге:

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

Последний востребованный вариант — просмотр «неудачных» операций. К таким относятся неудачный вход в ОС, блокировки и т.д. Посмотреть их можно следующим образом:

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

Подсистема аудита: архитектура и принцип работы

Подсистема аудита была добавлена в ядро Linux начиная с версии 2.6. Она предназначена для отслеживания критичных с точки зрения безопасности системных событий. В качестве примеров таких событий можно привести следующие (список далеко не полный):

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

Получив вызов от приложения в пространстве пользователя, подсистема аудита пропускает его через один из следующих фильтров: user, task или exit (более подробно о них речь пойдёт ниже). После этого вызов пропускается через фильтр exclude, который исходя из правил аудита передаёт его демону auditd для дальнейшей обработки.

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

Установка

Чтобы начать работать с подсистемой аудита, нужно установить пакет auditd (здесь и далее приводятся примеры команд для OC Ubuntu 14.04):

В cостав этого пакета входят демон auditd и несколько вспомогательных утилит:

auditctl — утилита для управления демоном auditd; позволяет получать информацию о текущем состоянии подсистемы аудита, а также добавлять и удалять правила;
autrace — утилита для аудита событий, порождаемых процессами (работает по тому же принципу, что и strace);
ausearch — утилита для поиска событий в журнальных файлах;
aureport — утилита для генерации отчётов о работе системы аудита.

Конфигурирование

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

log_file — файл, в котором будут храниться логи подсистемы аудита;
log_format — формат, в котором будет сохранены логи;
freq — максимальное число записей протокола, которые могут храниться в буфере;
flush — режим синхронизации буфера с диском (none — ничего не делать, incremental — переносить данные из буфера на диск с частотой, указанной в значении параметра freq; data — синхронизировать немедленно, sync — синхронизировать как данные, так и метаданные файла при записи на диск);
max_log_file — максимальный размер файла лога в мегабайтах;
max_log_file_action — действие при превышении максимального размера файла лога;
space_left — минимум свободного пространства в мегабайтах, по достижении которого должно быть осуществлено действие, указанное в следующем параметре;
space_left_admin — указывает, что делать, когда на диске недостаточно свободного места (ignore — ничего не делать; syslog — отправлять в syslog, email — отправлять уведомление по почте; suspend — прекратить запись логов на диск; single — перейти в однопользовательский режим; halt — выключить машину)
disk_full_action — действие, которое нужно осуществить при переполнении диска (этот параметр может принимать те же значения, что и space_left_admin).

Создание правил

Для добавления и настройки правил используется команда auditctl. Вот список её опций:

-l — вывести список имеющихся правил;
-а — добавить новое правило;
-d — удалить правило из списка;
-D — удалить все имеющиеся правила.

Сначала после опции -а указывается список, в который нужно добавить правило. Всего существует 5 таких списков:

task — события, связанные с созданием новых процессов;
entry — события, которые имеют место при входе в системный вызов;
exit — события, которые имеют место при выходе из системного вызова;
user — события, использующие параметры пользовательского пространства;
exclude — используется для исключения событий.

После опции -S идёт имя системного вызова, при котором событие нужно перехватить (open, close и т.п.).

После опции -F указываются дополнительные параметры фильтрации. Например, если нам требуется вести аудит обращений к файлам из каталога /etc, правило будет выглядеть так:

Можно установить и дополнительный фильтр:

Аббревиатура aw означает следующее: а — изменение атрибута (attribute change), w — запись (write). Формулировка perm = aw указывает, что для директории /etc нужно отслеживать все факты изменения атрибутов (а — attribute change) и w (w — write).

При настройке слежения за отдельными файлами можно опустить опцию -S, например:

Файлы правил

Далее следуют пользовательские правила. Их синтаксис предельно прост: достаточно просто перечислить соответствующие опции команды auditctl. Рассмотрим пример типового файла правил:

Изменения конфигурации вступят в силу после перезапуска демона auditd:

Анализ журнальных файлов: утилита aureport

Все журнальные файлы сохраняются в директории /var/log/audit в машиночитаемом формате. Их можно сделать человекопонятными c помощью утилиты aureport.

Если ввести команду aureport без аргументов, мы увидим общую системную статистику (количество пользователей системы, общее количество системных вызовов, число открытых терминалов и т.п.):

Она не имеет особой практической ценности. Гораздо больший интерес представляют специализированные отчёты. Вот так, например, можно просмотреть информацию обо всех системных вызовах:

Воспользовавшись опцией -au (или −−auth), можно просмотреть информацию обо всех попытках входа в систему:

В аureport поддерживается фильтрация по дате и времени:

Можно указывать как конкретные время и дату, так и специальные человекопонятные конструкции:

now — текущий момент;
yesterday — вчерашнее сутки;
recent — 10 минут назад;
this-week (или this-month, this-year) — текущая неделя (месяц, год).

и затем выполнить следующую команду:

Ausearch: поиск и анализ событий

Для просмотра детальной информации о событии используется утилита ausearch:

Вывод приведённой выше команды выглядит так:

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"

Рассмотрим его структуру более подробно. В поле type указывается тип записи; type = syscall означает, что запись была сделана после выполнения системного вызова. В поле msg указано время события в формате Unix Timestamp и его уникальный идентификационный номер.

В поле arch содержится информация об используемой архитектуре системы (c000003e означает x86_84), представленная в закодированном шестнадцатеричном формате. Чтобы она выводилась в человекочитаемом виде, можно воспользоваться опцией -i или −−interpret.

В поле syscall указан тип системного вызова — в нашем случае это 2, то есть вызов open. Параметр success сообщает, был ли вызов обработан успешно или нет. В нашем примере вызов был обработан неудачно (success = no).

Для каждого вызова в отчёте также перечисляются индивидуальные параметры; более подробно о них можно почитать в официальном руководстве. Вывести на консоль информацию о любом параметре в человекочитаемой форме можно получить при помощи упомянутой выше опции -i или −−interpret, например:

Опция -sc позволяет включать в список события, относящиеся к указанному системному вызову, например:

Опция -ui служит для поиска событий по идентификатору пользователя:

Поиск по именам демонов осуществляется с помощью опции -tm:

Для поиска нужных событий можно также использовать ключи, например:

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

Анализ процессов с помощью утилиты autrace

В некоторых случаях бывает полезным получить информацию о событиях, связанных с одним конкретным процессом. Для этой цели можно воспользоваться утилитой autrace. Предположим, нам нужно отследить процесс date и узнать, какие системные вызовы и файлы он использует. Выполним команду:

На консоли появится следующий текст:

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

В результате мы получим вот такой отчёт:

Централизованное хранение логов

Для отправки логов подсистемы аудита в централизованное хранилище используется плагин audisp-remote. Он входит в пакет audisp-plugins, который нужно устанавливать дополнительно:

Конфигурационные файлы всех плагинов хранятся в директории /etc/audisp/plugins.d.

Настройки удалённого логгирования прописываются в конфигурационном файле /etc/audisp/plugins.d/audisp-remote.conf. По умолчанию этот файл выглядит так:

Чтобы активировать отправку логов в удалённое хранилище, заменим значение параметра active на yes. Затем откроем файл etc/audisp/audisp-remote.conf и в качестве значения параметра remote_server укажем буквенный или IP-адрес cервера, на котором будут храниться логи.

Чтобы принимать логи с удалённых хостов и сохранять их на сервере, в файле /etc/audit/auditd.conf нужно прописать следующие параметры:

Заключение

В этой статье мы изложили основы работы с подсистемой аудита Linux. Мы рассмотрели принцип работы системы аудита, научились формулировать правила, читать логи и пользоваться вспомогательными утилитами.

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

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

доступ к объектам файловой системы;
выполнение системных вызовов;
запуск пользовательских команд;
логины пользователей;
действия с учетными записями и привилегиями.

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

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

В общем виде схема работы подсистемы аудита выглядит следующим образом.

Ядро, принимая системные вызовы из user space, пропускает их через фильтры user , task , filesystem , exclude и exit .

Фильтр user используется для фильтрации (исключения) событий, происходящих в пользовательском пространстве до отправки в auditd. Практически никогда не используется.
Фильтр task применяется для системных вызовов fork( ) и clone( ) .
Фильтр filesystem используется для исключения событий для конкретной файловой системы.
Фильтр exclude задает исключения для событий.
Фильтр exit проходят все системные вызовы. Обычно настраивают именно этот фильтр.

Через netlink( 7) сообщения отправляются из kauditd в auditd. При получении событий, демон auditd записывает их в лог (по умолчанию / var/ log/ audit/ audit. log ).

Настраивая фильтры с помощью утилиты auditctl, мы можем управлять потоком событий, который хотим получать. С помощью утилит ausearch, aureport, aulast удобно просматривать журнал аудита.

Давай теперь установим и настроим все подсистемы аудита. Установка крайне проста и не вызывает никаких сложностей:

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

$ sudo auditctl -s
enabled 1
failure 1
pid 885
rate_limit 0
backlog_limit 8192
lost 0
backlog 0
backlog_wait_time 60000
loginuid_immutable 0 unlocked

Для теста есть возможность отправить текстовое сообщение в подсистему аудита и убедиться, что соответствующее событие попало в журнал аудита.

$ sudo auditctl -m helloaudit
$ sudo ausearch -m USER
----
type=USER msg=audit(08/31/2021 19:20:11.160:330699) : pid=305708 uid=root auid=andrey ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='text=helloaudit exe=/usr/sbin/auditctl hostname=rhel.ipa.localdomain addr=? terminal=pts/0 res=success'

Настройки демона auditd представлены в файле / etc/ audit/ auditd. conf . Конфиг по умолчанию рабочий и не требует изменений, оставляем его как есть.

Разберемся теперь, как управлять фильтрами kauditd. Все настройки фильтров группируются в файлы правил. Формат правил аналогичен синтаксису консольной программы auditctl. Демон auditd загружает эти правила последовательно при старте системы либо вручную по команде пользователя.

Важный момент: чтобы наши правила применялись после перезагрузки, необходимо записать их в файл, в каталог / etc/ audit/ rules. d/ .

Примеры правил ты можешь найти в каталоге / usr/ share/ audit/ sample-rules/ . Правила аудита бывают следующих типов:

Управляющие правила настраивают систему аудита и поведение агента. Все возможные опции перечислены в мане auditctl( 8) .

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

Ключ -w указывает на то, что это правило файловой системы. Далее следует путь к файлу или каталогу.

Ключ -p может содержать любые комбинации прав доступа r (чтение), w (запись), x (выполнение) и a (изменение атрибута).

Ключ -k задает имя правила, по которому впоследствии можно фильтровать логи.

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

Ключ -a означает append (добавление) правила в фильтр.

Действие action может быть always (всегда создавать события) или never (никогда не создавать события).

Фильтр list содержит один из возможных вариантов: task , exit , user , filesystem или exclude .

-S указывает конкретный syscall (имя или номер); можно в одном правиле указывать сразу несколько syscall, каждый после своего ключа -S .

-F задает фильтр по полям. Рекомендуется всегда указывать разрядность, добавляя в правила фильтр -F arch=b64 .

Ключ -k — имя правила. Как и в правиле файловой системы, используется для маркировки событий для последующей фильтрации лога.

Важно отметить, что правила системных вызовов значительно влияют на производительность системы в целом. Старайся сократить их количество и объединяй правила, где это возможно.

В качестве тренировки создадим правило аудита для регистрации изменения файла / etc/ passwd .

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Подсистема аудита: архитектура и принцип работы

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

Ни одно из названных событий не может произойти без использования системных вызовов ядра. Чтобы их отслеживать, достаточно просто перехватывать соответствующие системные вызовы. Именно это и делает подсистема аудита:

Установка

В cостав этого пакета входят демон auditd и несколько вспомогательных утилит:

auditctl — утилита для управления демоном auditd; позволяет получать информацию о текущем состоянии подсистемы аудита, а также добавлять и удалять правила;
autrace — утилита для аудита событий, порождаемых процессами (работает по тому же принципу, что и strace);
ausearch — утилита для поиска событий в журнальных файлах;
aureport — утилита для генерации отчётов о работе системы аудита.

Конфигурирование

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

log_file — файл, в котором будут храниться логи подсистемы аудита;
log_format — формат, в котором будет сохранены логи;
freq — максимальное число записей протокола, которые могут храниться в буфере;
flush — режим синхронизации буфера с диском (none — ничего не делать, incremental — переносить данные из буфера на диск с частотой, указанной в значении параметра freq; data — синхронизировать немедленно, sync — синхронизировать как данные, так и метаданные файла при записи на диск);
max_log_file — максимальный размер файла лога в мегабайтах;
max_log_file_action — действие при превышении максимального размера файла лога;
space_left — минимум свободного пространства в мегабайтах, по достижении которого должно быть осуществлено действие, указанное в следующем параметре;
space_left_admin — указывает, что делать, когда на диске недостаточно свободного места (ignore — ничего не делать; syslog — отправлять в syslog, email — отправлять уведомление по почте; suspend — прекратить запись логов на диск; single — перейти в однопользовательский режим; halt — выключить машину);
disk_full_action — действие, которое нужно осуществить при переполнении диска (этот параметр может принимать те же значения, что и space_left_admin).

Создание правил

Для добавления и настройки правил используется команда auditctl. Вот список её опций:

-l — вывести список имеющихся правил;
-а — добавить новое правило;
-d — удалить правило из списка;
-D — удалить все имеющиеся правила.

Чтобы создать новое правило, нужно выполнить команду вида:

task — события, связанные с созданием новых процессов;
entry — события, которые имеют место при входе в системный вызов;
exit — события, которые имеют место при выходе из системного вызова;
user — события, использующие параметры пользовательского пространства;
exclude — используется для исключения событий.

Затем указывается, что нужно делать после наступления события. Здесь возможны два варианта: always (события будут записываться в журнал) и never (не будут).

После опции -S идёт имя системного вызова, при котором событие нужно перехватить (open, close и т.п.).

Можно установить и дополнительный фильтр:

При настройке слежения за отдельными файлами можно опустить опцию -S, например:

Файлы правил

Далее следуют пользовательские правила. Их синтаксис предельно прост: достаточно просто перечислить соответствующие опции команды auditctl. Рассмотрим пример типового конфигурационного файла:

Изменения конфигурации вступят в силу после перезапуска демона auditd:

Анализ журнальных файлов: утилита aureport

Все журнальные файлы сохраняются в директории /var/log/audit в машиночитаемом формате. Их можно сделать человекопонятными c помощью утилиты aureport.
Если ввести команду aureport без аргументов, мы увидим общую системную статистику (количество пользователей системы, общее количество системных вызовов, число открытых терминалов и т.п.):

Воспользовавшись опцией -au (или −−auth), можно просмотреть информацию обо всех попытках входа в систему:

В аureport поддерживается фильтрация по дате и времени:

Можно указывать как конкретные время и дату, так и специальные человекопонятные конструкции:

now — текущий момент;
yesterday — вчерашнее сутки;
recent — 10 минут назад;
this-week (или this-month, this-year) — текущая неделя (месяц, год).

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

и затем выполнить следующую команду:

Ausearch: поиск и анализ событий

Для просмотра детальной информации о событии используется утилита ausearch:

Вывод приведённой выше команды выглядит так:

Рассмотрим его структуру более подробно. В поле type указывается тип записи; type = syscall означает, что запись была сделана после выполнения системного вызова. В поле msg указано время события в формате Unix Timestamp и его уникальный идентификационный номер.

Для каждого вызова в отчёте также перечисляются индивидуальные параметры; более подробно о них можно почитать в официальном руководстве . Вывести на консоль информацию о любом параметре в человекочитаемой форме можно получить при помощи упомянутой выше опции -i или −−interpret, например:

Опция -sc позволяет включать в список события, относящиеся к указанному системному вызову, например:

Опция -ui служит для поиска событий по идентификатору пользователя:

Поиск по именам демонов осуществляется с помощью опции -tm:

Для поиска нужных событий можно также использовать ключи, например:

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

Анализ процессов с помощью утилиты autrace

На консоли появится следующий текст:

В результате мы получим вот такой отчёт:

Централизованное хранение логов

Конфигурационные файлы всех плагинов хранятся в директории /etc/audisp/plugins.d.

Заключение

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

Читайте также: