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

Вступление

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

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

Предпосылки

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

CentOS 7 Droplet (работает также с CentOS 6)
Пользователь без полномочий root с привилегиями sudo. Чтобы настроить пользователя этого типа, следуйте учебному руководству Initial Server Setup с 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, измените следующую опцию:

/etc/audit/auditd.conf

num_logs =

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

/etc/audit/auditd.conf

max_log_file =
max_log_file_action =

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

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 +. Файлы журнала аудита содержат много полезной информации, но чтение и понимание файлов журнала может показаться многим пользователям затруднительным из-за большого количества предоставляемой информации, используемых сокращений и кодов и т. Д. В этом разделе мы попытаемся понять некоторые поля типичного сообщения аудита в файлах журнала аудита.

Для этого примера предположим, что на сервере настроено правило аудита с меткой (+ 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 + выглядит следующим образом:

/var/log/audit/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 +) и id (+ 135496 +). Каждая запись состоит из нескольких пар name = value, разделенных пробелом или запятой. Мы подробно рассмотрим, что обозначают некоторые из этих полей.

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

+ Тип = SYSCALL +

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

+ MSG = аудит (1434371271,277: 135496) +

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

+ Арка = c000003e +

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

+ = 2 системного вызова +

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

sudo ausyscall 2

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

open

+ Успех = да +

Поле + 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 = "кошка" +

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

+ Ех = "/ USR / бен / кошка" +

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

+ key =" ssh config change "+

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

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

+ Тип = УХО +

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

+ УХО = "/ дом / Сэмми" +

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

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

+ Тип = ПУТЬ +

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

+ MSG = аудит (1434371271,277: 135496) +

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

+ Имя = "/ и т.д. / 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

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

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

Давайте попробуем пример, скажем, мы хотим отследить процесс + 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 +. Написание пользовательских правил и использование предопределенных наборов правил подробно обсуждается в Writing Пользовательские правила аудита системы на CentOS 7 учебник.

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

TOC