Как использовать систему аудита Linux в CentOS 7

Введение

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

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

Предпосылки

Для этого урока вам понадобится следующее:

Дроплет CentOS 7 (также работает с CentOS 6)
Пользователь без полномочий root с привилегиями sudo. Чтобы настроить пользователя этого типа, следуйте руководству по начальной настройке сервера с CentOS 7. Все команды будут выполняться от имени этого пользователя.

Проверка установки аудита

Система аудита состоит из двух основных частей:

Компонент ядра аудита перехватывает системные вызовы пользовательских приложений, записывает события и отправляет эти сообщения аудита демону аудита.
Демон auditd собирает информацию из ядра и создает записи в файле журнала

Система аудита использует следующие пакеты: audit и audit-libs. Эти пакеты устанавливаются по умолчанию в новой капле CentOS 7 (и новой капле CentOS 6). Хорошо убедиться, что они установлены на вашем сервере, используя:

sudo yum list audit audit-libs

Вы должны увидеть оба пакета в разделе Installed Packages в выводе:

Installed Packages
audit.x86_64
audit-libs.x86_64

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

Основным файлом конфигурации для auditd является /etc/audit/auditd.conf. Этот файл состоит из параметров конфигурации, которые включают в себя, где регистрировать события, что делать с полными дисками и ротацию журналов. Чтобы отредактировать этот файл, вам нужно использовать sudo:

sudo nano /etc/audit/auditd.conf

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

num_logs = 10

Вы также можете настроить максимальный размер файла журнала в МБ и действия, предпринимаемые после достижения размера:

max_log_file = 30
max_log_file_action = ROTATE

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

sudo service auditd restart

чтобы изменения вступили в силу.

Другой файл конфигурации — /etc/audit/rules.d/audit.rules. (Если вы используете CentOS 6, вместо этого используйте файл /etc/audit/audit.rules.) Он используется для постоянного добавления правил аудита.

Когда запущен auditd, сообщения аудита будут записываться в файл /var/log/audit/audit.log.

Общие сведения о файлах журнала аудита

По умолчанию система аудита записывает сообщения аудита в файл /var/log/audit/audit.log. Файлы журналов аудита содержат много полезной информации, но чтение и понимание файлов журналов может показаться трудным для многих пользователей из-за огромного количества предоставленной информации, используемых сокращений и кодов и т. д. В этом разделе мы попытаемся понять некоторые полей в типичном сообщении аудита в файлах журнала аудита.

Примечание. Если auditd по какой-либо причине не запущен, сообщения аудита будут отправляться в rsyslog.

Для этого примера предположим, что на сервере настроено правило аудита с меткой (key) sshconfigchange для регистрации каждого доступа или модификации к файлу / etc/ssh/sshd_config. При желании вы можете временно добавить это правило, используя:

sudo auditctl -w /etc/ssh/sshd_config -p rwxa -k sshconfigchange

Выполнение следующей команды для просмотра файла sshd_config создает новое событие в файле журнала аудита:

sudo cat /etc/ssh/sshd_config

Это событие в файле audit.log выглядит следующим образом:


type=SYSCALL msg=audit(1434371271.277:135496): arch=c000003e syscall=2 success=yes exit=3 a0=7fff0054e929 a1=0 a2=1fffffffffff0000 a3=7fff0054c390 items=1 ppid=6265 pid=6266 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=113 comm="cat" exe="/usr/bin/cat" key="sshconfigchange"

type=CWD msg=audit(1434371271.277:135496):  cwd="/home/sammy"

type=PATH msg=audit(1434371271.277:135496): item=0 name="/etc/ssh/sshd_config" inode=392210 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 objtype=NORMAL

Вышеприведенное событие состоит из трех записей (каждая начинается с ключевого слова type=), которые имеют одну и ту же метку времени (1434371271.277) и идентификатор (135496). ). Каждая запись состоит из нескольких пар имя=значение, разделенных пробелом или запятой. Мы подробно рассмотрим, что означают некоторые из этих полей.

В первой записи:

type=SYSCALL

Поле type содержит тип контрольного сообщения. В этом случае значение SYSCALL показывает, что это сообщение было вызвано системным вызовом ядра.

msg=audit(1434371271.277:135496):

Отметка времени и идентификатор сообщения аудита в форме audit(time_stamp:ID). Несколько сообщений/записей аудита могут иметь одну и ту же отметку времени и идентификатор, если они были созданы как часть одного и того же события аудита. В нашем примере мы видим одинаковую метку времени (1434371271.277) и идентификатор (135496) во всех трех сообщениях, сгенерированных событием аудита.

arch=c000003e

Поле arch содержит информацию об архитектуре процессора системы. Значение c000003e представлено в шестнадцатеричном формате и означает x86_64.

системный вызов=2

Поле syscall обозначает тип системного вызова, отправленного ядру. В данном случае 2 — это системный вызов open. Утилита ausyscall позволяет преобразовывать номера системных вызовов в их удобочитаемые эквиваленты. Например, выполните следующую команду, чтобы преобразовать значение 2 в его удобочитаемый эквивалент:

sudo ausyscall 2

Вывод показывает:

open

Примечание. Вы можете использовать команду sudo ausyscall --dump для просмотра списка всех системных вызовов вместе с их номерами.

успешно=да

Поле success показывает, был ли системный вызов в этом конкретном событии успешным или неудачным. В этом случае звонок удался. Пользователь sammy смог открыть и прочитать файл sshd_config при выполнении команды sudo cat /etc/ssh/sshd_config.

ppid=6265

Поле ppid записывает идентификатор родительского процесса (PPID). В данном случае 6265 был PPID процесса bash.

pid=6266

Поле pid записывает идентификатор процесса (PID). В данном случае 6266 был PID процесса cat.

auid=1000

auid — это UID аудита или исходный UID пользователя, инициировавшего это контрольное сообщение. Система аудита запомнит ваш исходный UID, даже если вы повысите привилегии с помощью su или sudo после первоначального входа в систему.

uid=0

Поле uid записывает идентификатор пользователя, запустившего анализируемый процесс. В данном случае команда cat была запущена пользователем root с uid 0.

comm=cat

comm записывает имя команды, вызвавшей это контрольное сообщение.

exe=/usr/bin/cat

Поле exe записывает путь к команде, которая использовалась для запуска этого контрольного сообщения.

key=sshconfigchange

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

Для второй записи:

type=CWD

Во второй записи тип CWD — текущий рабочий каталог. Этот тип используется для записи рабочего каталога, из которого был выполнен процесс, вызвавший системный вызов, указанный в первой записи.

cwd=/home/sammy

Поле cwd содержит путь к каталогу, из которого был вызван системный вызов. В нашем случае команда cat, вызвавшая системный вызов open в первой записи, была выполнена из каталога /home/sammy.

Для третьей записи:

type=ПУТЬ

В третьей записи используется тип PATH. Событие аудита содержит запись PATH для каждого пути, который передается системному вызову в качестве аргумента. В нашем событии аудита в качестве аргумента использовался только один путь (/etc/ssh/sshd_config).

msg=audit(1434371271.277:135496):

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

name=/etc/ssh/sshd_config

Поле name записывает полный путь к файлу или каталогу, который был передан системному вызову (open) в качестве аргумента. В данном случае это был файл /etc/ssh/sshd_config.

ouid=0

Поле ouid записывает идентификатор пользователя владельца объекта. Здесь объектом является файл /etc/ssh/sshd_config.

Примечание. Дополнительные сведения о типах записей аудита доступны по ссылкам в конце этого руководства.

Поиск событий в журналах аудита

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

Давайте рассмотрим несколько примеров.

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

sudo ausearch -m LOGIN --start today -i

Приведенная ниже команда будет искать все события с идентификатором события 27020 (при условии, что событие с таким идентификатором существует).

sudo ausearch -a 27020

Эта команда будет искать все события (если они есть), касающиеся файла /etc/ssh/sshd_config, и интерпретировать их:

sudo ausearch -f /etc/ssh/sshd_config -i

Создание аудиторских отчетов

Вместо того, чтобы читать необработанные журналы аудита, вы можете получить сводку сообщений аудита с помощью инструмента aureport. Предоставляет отчеты в удобочитаемом формате. Эти отчеты можно использовать в качестве строительных блоков для более сложного анализа. Когда aureport запускается без каких-либо параметров, он покажет сводку различных типов событий, присутствующих в журналах аудита. При использовании с параметрами поиска он покажет список событий, соответствующих критериям поиска.

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

sudo aureport -x --summary

Вывод будет выглядеть примерно так с разными значениями:

Executable Summary Report
=================================
total  file
=================================
117795  /usr/sbin/sshd
1776  /usr/sbin/crond
210  /usr/bin/sudo
141  /usr/bin/date
24  /usr/sbin/autrace
18  /usr/bin/su

В первом столбце показано, сколько раз выполнялась команда, а во втором — количество выполненных команд. Обратите внимание, что не все команды записываются по умолчанию. Регистрируются только те, которые связаны с безопасностью.

Следующая команда даст вам статистику всех неудачных событий:

sudo aureport --failed

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

Failed Summary Report
======================
Number of failed logins: 11783
Number of failed authentications: 41679
Number of users: 3
Number of terminals: 4
Number of host names: 203
Number of executables: 3
Number of files: 4
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 9

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

sudo aureport -f -i

Пример вывода:

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Monday 15 June 2015 08:27:51 /etc/ssh/sshd_config open yes /usr/bin/cat sammy 135496
2. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147481
3. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config lgetxattr yes /usr/bin/ls root 147482
4. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147483
5. Tuesday 16 June 2015 00:40:15 /etc/ssh/sshd_config getxattr no /usr/bin/ls root 147484
6. Tuesday 16 June 2015 05:40:08 /bin/date execve yes /usr/bin/date root 148617

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

sudo aureport -f -i --summary

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

Анализ процесса с использованием autrace

Для аудита отдельного процесса мы можем использовать инструмент autrace. Этот инструмент отслеживает системные вызовы, выполняемые процессом. Это может быть полезно при расследовании подозреваемого трояна или проблемного процесса. Вывод autrace записывается в /var/log/audit/audit.log и выглядит аналогично стандартным записям журнала аудита. После выполнения autrace предоставит вам пример команды ausearch для исследования журналов. Всегда используйте полный путь к двоичному файлу для отслеживания с помощью autrace, например, sudo autrace /bin/ls /tmp.

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

Возьмем пример, скажем, мы хотим проследить процесс date и просмотреть используемые им файлы и системные вызовы. Запустите следующее:

sudo autrace /bin/date

Вы должны увидеть что-то похожее на следующее:

Waiting to execute: /bin/date
Wed Jun 17 07:22:03 EDT 2015
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 27020'

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

sudo ausearch -p 27020 --raw | aureport -f -i

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

Вы должны увидеть вывод, подобный следующему:

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. Wednesday 17 June 2015 07:22:03 /bin/date execve yes /usr/bin/date sammy 169660
2. Wednesday 17 June 2015 07:22:03 /etc/ld.so.preload access no /usr/bin/date sammy 169663
3. Wednesday 17 June 2015 07:22:03 /etc/ld.so.cache open yes /usr/bin/date sammy 169664
4. Wednesday 17 June 2015 07:22:03 /lib64/libc.so.6 open yes /usr/bin/date sammy 169668
5. Wednesday 17 June 2015 07:22:03 /usr/lib/locale/locale-archive open yes /usr/bin/date sammy 169683
6. Wednesday 17 June 2015 07:22:03 /etc/localtime open yes /usr/bin/date sammy 169691

Заключение

В этом руководстве мы рассмотрели основы системы аудита Linux. Теперь у вас должно быть хорошее представление о том, как работает система аудита, как читать журналы аудита, а также о различных доступных инструментах, облегчающих вам аудит вашего сервера.

По умолчанию система аудита записывает в журналы только несколько событий, таких как вход пользователей в систему и использование sudo. Сообщения, связанные с SELinux, также регистрируются. Демон аудита использует правила для отслеживания определенных событий и создания соответствующих записей в журнале. Можно создавать настраиваемые правила аудита для мониторинга и записи в журналы всего, что мы хотим. Именно здесь система аудита становится мощной для системного администратора. Мы можем добавлять правила либо с помощью инструмента командной строки auditctl, либо постоянно в файле /etc/audit/rules.d/audit.rules. Написание пользовательских правил и использование предопределенных наборов правил подробно обсуждаются в руководстве по написанию пользовательских правил системного аудита в CentOS 7.

Вы также можете ознакомиться со следующими ресурсами для получения дополнительной информации о системе аудита:

Типы аудиторских записей
Настройка аудита для среды CAPP
Поля событий аудита и их определения