Библиотека сайта rus-linux.net
Мониторинг файловых операций с помощью демона auditd
Оригинал: Customized File Monitoring with Auditd
Автор: Paul Brown
Дата публикации: 14 июня 2016 г.
Перевод: А.Панин
Дата перевода: 13 января 2017 г.
Узнайте о том, как настроить демон auditd для отслеживания любых системных событий.
В предыдущей статье, посвященной демону auditd, я продемонстрировал методику использования утилиты aureport для получения информации о событиях, отслеживаемых демоном auditd в автоматическом режиме. Также я упомянул о том, что вы можете, к примеру, проверить, не испытывает ли какой-либо из пользователей системы проблем при аутентификации, причем эти проблемы могут быть интерпретированы как попытки получения доступа к системе злоумышленниками.
Как я говорил ранее, утилита aureport является частью большого набора утилит из комплекта поставки auditd. Возможность использования auditd для мониторинга определенных событий сама по себе является довольно полезной, но при этом вы также можете использовать данный демон для отслеживания событий, которые вас действительно интересуют.
Пользовательские правила отслеживания событий
Для передачи пользовательских правил отслеживания событий демону auditd в процессе его работы следует использовать утилиту auditctl. Но перед тем, как создавать свои правила, я предлагаю вам проверить, не используются ли демоном какие-нибудь стандартные правила. Получите привилегии пользователя root (или воспользуйтесь утилитой sudo) и выполните следующую команду:
auditctl -l -a never,task
Параметр -l сообщает утилите о необходимости вывода списка всех активных на данный момент правил и, как несложно заметить, после выполнения данной команды выводится лишь приведенная ниже строка -a never,task, которая обозначает, что ни одно из следующих правил не будет записывать данные в журнал. Это правило, которое обычно используется по умолчанию в новых установках auditd и сообщает демону о необходимости добавления (-a) правила в список задач (аналогичный списку задач, исполняющихся ядром ОС - вам пока не стоит беспокоиться по данному поводу), причем это правило запрещает auditd записывать что-либо в журнал.
Так как в нашем случае не указывается интересующая нас задача, auditd предполагает, что данное правило относится ко всем задачам. По-русски это правило читается так: "Не нужно записывать в журнал информацию о любых задачах, исполняющихся с участием ядра ОС". И, так как демон auditd расставляет приоритет правил сверху вниз (то есть, первое правило имеет преимущество перед последующими правилами в случае возникновения каких-либо конфликтов), данное правило обозначает, что в журнал не будут записываться какие-либо данные вне зависимости от содержания остальных правил.
Вам наверняка не понадобится данное правило, поэтому в первую очередь следует избавиться от него. Для удаления всех правил, используемых демоном auditd, вы можете воспользоваться следующей командой:
auditctl -D
Если вы уже передали демону несколько своих правил и не хотите удалять их, вы можете удалить лишь первое правило с помощью команды:
auditctl -d never,task
Теперь, когда путь свободен, я постараюсь продемонстрировать вам методику создания вашего первого правила. Демон auditd нередко используется для мониторинга операций с файлами и директориями. Например, вы можете создать директорию в своей домашней директории от лица обычного пользователя с помощью аналогичной команды:
mkdir test_dir
Теперь следует получить привилегии пользователя root и добавить правило, предназначенное для наблюдения за созданной директорией:
auditctl -w /home/[ваше_имя_пользователя]/test_dir/ -k test_watch
Параметр -w сообщает демону auditd о необходимости наблюдения за всеми изменениями в рамках директории test_dir/. Параметр -k сообщает auditd о необходимости добавления строки test_watch (называемой ключом) к записям, добавляемым в журнал. В качестве ключа может использоваться любая строка, хотя отличной идеей является использование строки, которая хорошо запоминается и тесно связана с назначением правила. Как вы увидите позднее, данная строка является крайне полезной для отбрасывания не связанных с правилом записей в процессе исследования журналов auditd.
Теперь вы должны будете выполнить какие-либо операции в рамках директории test_dir/ от лица обычного пользователя - создайте несколько поддиректорий, создайте или скопируйте несколько файлов, удалите несколько файлов или получите список ее содержимого.
После выполнения данных операций вы можете обратиться к содержимому журнала демона auditd с помощью команды:
ausearch -k test_watch
Обратили внимание на параметр -k test_watch? Даже в том случае, если вы используете множество других правил для наблюдения за различными параметрами системы, вы можете сообщить утилите ausearch о необходимости вывода лишь тех записей, которые вас действительно интересуют, передав ей соответствующий ключ (Рисунок 1).
Рисунок 1: Вывод утилиты ausearch
Даже при условии использования приведенного ключа утилита ausearch выводит огромный объем информации. Однако, вы также можете заметить, что выводимая информация является достаточно структурированной. По сути, каждому событию соответствуют три записи в выводе.
Каждая запись содержит пары ключ/значение, разделенные с помощью символа "="; некоторые значения являются строками, другие - списками в круглых скобках и так далее. Вы можете узнать о значении каждого из фрагментов записей в , но в данном случае важно понимать, что структурированный формат вывода рассматриваемой утилиты позволяет без каких-либо сложностей осуществлять разбор ее вывода с помощью соответствующих сценариев. Фактически, инструмент aureport, который описывался в предыдущей статье серии, также осуществляет структурированный вывод.
Для того, чтобы доказать данный тезис, предлагаю передать вывод утилиты ausearch на вход утилиты aureport:
ausearch -k test_watch | aureport -f -i File Report =============================================== # date time file syscall success exe auid event =============================================== 1. 05/06/16 13:04:54 sub_dir mkdir yes /usr/bin/mkdir paul 193 2. 05/06/16 13:04:54 /home/paul/test_dir/sub_dir getxattr no /usr/bin/baloo_file paul 194 3. 05/06/16 13:04:54 /home/paul/test_dir/sub_dir getxattr no /usr/bin/baloo_file paul 195 4. 05/06/16 13:04:54 /home/paul/test_dir/sub_dir getxattr no /usr/bin/baloo_file paul 196 5. 05/06/16 13:05:06 /home/paul/test_dir/testfile.txt getxattr no /usr/bin/baloo_file paul 198 . . .
Это уже интересно! Изучив данный вывод, вы можете узнать, кто, что и когда делал с файлами.
Если вы внимательно рассмотрели приведенный листинг, вы наверняка обратили внимание на то, что ввиду использования мною окружения рабочего стола Plasma, индексирующая служба Baloo из состава KDE также осуществляет доступ к исследуемым файлам, наполняя журнал дополнительными записями. Это объясняется тем, что каждый раз при создании или удалении файла Baloo осуществляет фиксацию соответствующего факта. Данное обстоятельство значительно затрудняет разбор вывода рассматриваемой утилиты и наблюдение за процессами, происходящими в системе. Поэтому я предлагаю отфильтровать все записи, относящиеся к действиям Baloo, с помощью утилиты grep:
ausearch -k test_watch | aureport -f -i | grep -v baloo File Report =============================================== # date time file syscall success exe auid event =============================================== 1. 05/06/16 13:04:54 sub_dir mkdir yes /usr/bin/mkdir paul 193 9. 05/06/16 13:05:06 testfile.txt open yes /usr/bin/touch paul 197 17. 05/06/16 13:05:29 ./be03316b71184fefba5cfbf59c21e6d5.jpg open yes /usr/bin/cp paul 210 18. 05/06/16 13:05:29 ./big_city.jpg open yes /usr/bin/cp paul 211 19. 05/06/16 13:05:29 ./blendertracking.jpg open yes /usr/bin/cp paul 212 20. 05/06/16 13:05:29 ./Cover27_Draft01.jpg open yes /usr/bin/cp paul 213 37. 05/06/16 13:05:50 blendertracking.jpg unlinkat yes /usr/bin/rm paul 330 38. 05/06/16 13:05:50 be03316b71184fefba5cfbf59c21e6d5.jpg unlinkat yes /usr/bin/rm paul 328 . . .
Это уже намного лучше. Теперь ясно, чем пользователи занимаются в системе. Вы можете проследить за тем, как они создают и копируют директории и файлы. Также вы можете узнать имена файлов, которые были удалены и так далее.
Если правило более не требуется, вы можете удалить его с помощью команды:
auditctl -W /home/[ваше_имя_пользователя]/test_dir/ -k test_watch
Мониторинг изменений отдельных файлов
Мониторинг изменений содержимого директорий может быть связан с записью огромного объема данных в журнал. По этой причине иногда удобнее осуществлять мониторинг изменений отдельных важных файлов для того, чтобы быть уверенным в том, что никто не подменил их содержимое. Классический пример команды, добавляющей правило для мониторинга изменений отдельного файла:
auditctl -w /etc/passwd -p wa -k passwd_watch
Данное правило позволяет быть уверенным в том, что никто не подменяет содержимое файла passwd.
Параметр -p сообщает демону auditd о типах операций доступа к файлу, которые следует отслеживать. Допустимыми обозначениями типов операций доступа к файлу в данном случае являются:
-
r- операция чтения данных из файла -
w- операция записи данных в файл -
x- операция исполнения файла -
a- операция изменения атрибутов файла или директории
Так как приложения должны иметь возможность читать содержимое файла /etc/passwd, мы не будем отслеживать операции чтения с целью защиты от ложных срабатываний. Также не совсем разумным решением является отслеживание операций исполнения неисполняемого файла; исходя из всего вышесказанного, мы сообщаем демону auditd о необходимости отслеживания изменений содержимого файла /etc/passwd (то есть, операций записи данных в файл), а также его атрибутов.
Если вы явно не укажите атрибуты файла, изменение которых необходимо отслеживать, демон auditd будет отслеживать изменения всех его атрибутов. По этой причине при мониторинге изменений содержимого директории test_dir/ в приведенных выше примерах генерация событий осуществлялась даже в случае использования команды ls.
Правила, используемые на постоянной основе
Для того, чтобы ваши правила работали на постоянной основе, вы можете добавлять их в файл /etc/audit/audit.rules или в новый файл с произвольным именем, который придется создать самостоятельно в директории /etc/audit/rules.d/. Если вы экспериментируете с правилами и используете для этого утилиту auditctl, причем вас вполне устраивает текущий набор правил, вы можете сохранить его с помощью данной последовательности команд:
echo "-D" > /etc/audit/rules.d/my.rules auditctl -l >> /etc/audit/rules.d/my.rules
Данные команды позволяют сохранить текущие правила в файле с именем my.rules без необходимости их ручного ввода. Если вы выполняли все описанные в данной статье действия, файл my.rules должен содержать все приведенные выше правила:
-D -w /home/[ваше_имя_пользователя]/test_dir/ -k test_watch -w /etc/passwd -p wa -k passwd_watch
Для того, чтобы избежать конфликтов правил, следует преобразовать все существующие файлы правил из директорий /etc/audit/ и /etc/audit/rules.d/ в файлы резервных копий путем простого добавления соответствующих расширений:
mv /etc/audit/audit.rules /etc/audit/audit.rules.bak mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.bak
После этого нужно перезапустить рассматриваемый демон с помощью следующей команды:
systemctl restart auditd.service
Это позволит демону обработать все добавленные правила в автоматическом режиме.
Теперь после каждой перезагрузки системы auditd будет осуществлять мониторинг тех файловых операций, которые вас интересуют.
Это еще не все
В рамках нескольких статей мне удалось рассказать лишь о малой части возможностей демона auditd. Но, как несложно заметить, auditd является мощным инструментом, который может использоваться для мониторинга множества других событий, помимо операций с файлами и директориями, со сбором большого объема дополнительной информации. Я планирую описать другие возможности данного инструмента в следующей статье серии.