Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum





Библиотека сайта rus-linux.net

Мониторинг состояния Linux-системы с помощью демона auditd

Оригинал: Linux System Monitoring and More with Auditd
Автор: Paul Brown
Дата публикации: 25 мая 2016 г.
Перевод: А.Панин
Дата перевода: 12 января 2017 г.

Мониторинг состояния Linux-системы с помощью демона auditd

Узнайте о том, как использовать демон auditd для мониторинга состояния системы.

Одним из ключевых аспектов комплекса мероприятий по защите Linux-системы является своевременное получение информации о происходящих в ней событиях: какие файлы изменились, кто и когда обращался к ним, какие приложения были запущены и так далее. Для получения подобной информации в последние годы использовался инструмент Incrond, но, несмотря на противоречивые слухи, его разработка была приостановлена четыре года назад и до сих пор не была возобновлена. Тем не менее, вы все еще можете загрузить и испытать его в работе, обратившись к примерам, приведенным мною в статье на стороннем ресурсе.

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

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

Инструмент Auditd активно разрабатывается специалистами компании Red Hat и доступен в большинстве, а может и во всех популярных дистрибутивах. Если он не установлен в вашей системе, вы можете найти соответствующий пакет программного обеспечения в одном из ее официальных репозиториев. В системах на основе дистрибутива Debian этот пакет программного обеспечения носит имя audit, в системах, в которых используются пакеты программного обеспечения формата RPM - auditd. В большинстве систем, основанных на наработках компании Red Hat, таких, как Fedora и CentOS, auditd обычно установлен по умолчанию.

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

Установка

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

> systemctl status auditd.service

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

> systemctl start auditd.service

или активировать механизм его автоматического запуска в момент запуска системы с помощью команды

> systemctl enable auditd.service

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

Система генерации отчетов

Сразу же после установки auditd осуществляет журналирование определенных событий, которые считаются критическими, без необходимости выполнения какой-либо конфигурации. Вы можете ознакомиться со списком отслеживаемых событий, выполнив команду aureport без каких-либо аргументов; обратите внимание на то, что вы должны обладать привилегиями пользователя root или получить их на непродолжительное время (например, с помощью команды sudo) для получения доступа к информации, касающейся аудита системы:

> aureport
Summary Report 
====================== 
Range of time in logs: 18/05/16 09:47:34.453 - 22/05/16 11:28:03.168 
Selected time for report: 18/05/16 09:47:34 - 22/05/16 11:28:03.168 
Number of changes in configuration: 195 
Number of changes to accounts, groups, or roles: 30 
Number of logins: 5 
Number of failed logins: 0 
Number of authentications: 136 
Number of failed authentications: 9 
Number of users: 4 
Number of terminals: 12 
Number of host names: 2 
Number of executables: 13 
.
.
.

Так, это уже интересно! Обратите внимание на строку "Number of failed authentications: 9". Если данный параметр имеет большое значение, то можно предположить, что кто-либо мог пытаться получить доступ к вашей системе путем подбора пароля одного из пользователей.

Давайте продвинемся немного дальше:

> aureport -au
Authentication Report 
============================================ 
# date time acct host term exe success event 
============================================ 
1. 18/05/16 09:47:56 sddm ? ? /usr/lib/sddm/sddm-helper yes 187 
2. 18/05/16 09:48:09 paul ? ? /usr/lib/sddm/sddm-helper yes 199 
3. 18/05/16 09:41:29 root ? pts/1 /usr/bin/su yes 227 
4. 18/05/16 09:57:16 root ? pts/2 /usr/bin/su yes 231 
5. 18/05/16 10:01:57 root ? ? /usr/sbin/groupadd yes 235 
.
.
.

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

Если вы отфильтруете вывод рассматриваемой утилиты с помощью утилиты grep, вы получите аналогичный список:

> aureport -au | grep no
37. 18/05/16 12:18:24 root ? pts/0 /usr/bin/su no 217 
38. 18/05/16 12:18:38 root ? pts/0 /usr/bin/su no 218 
47. 18/05/16 12:41:15 root ? pts/1 /usr/bin/su no 262 
66. 18/05/16 14:09:55 root ? pts/4 /usr/bin/su no 220 
67. 18/05/16 14:10:05 root ? pts/4 /usr/bin/su no 221 
102. 20/05/16 12:37:07 root ? pts/5 /usr/bin/su no 191 
117. 21/05/16 12:10:39 root ? pts/0 /usr/bin/su no 229 
129. 21/05/16 17:59:08 root ? pts/1 /usr/bin/su no 208 
134. 21/05/16 18:32:05 root ? pts/0 /usr/bin/su no 248

Он является ничем иным, как журналом неудачных попыток аутентификации. Давайте проведем небольшой эксперимент: запомните, что в последней строке под номером 134 содержится информация о дате 21/05/16 и времени 18:32:05 последней неудачной попытки входа в систему от лица пользователя root.

Теперь давайте рассмотрим информацию об активности пользователей в системе:

> aureport -u -i
User ID Report 
==================================== 
# date time auid term host exe event 
==================================== 
1. 18/05/16 09:47:35 unset ? ? /usr/lib/systemd/systemd 136 
2. 18/05/16 09:47:35 unset ? ? /usr/lib/systemd/systemd-update-utmp 137 
3. 18/05/16 09:47:35 unset ? ? /usr/lib/systemd/systemd 138 
4. 18/05/16 09:47:45 unset ? ? /usr/lib/systemd/systemd 139 
5. 18/05/16 09:47:45 unset ? ? /usr/lib/systemd/systemd 140 
.
.
.

Параметр -u сообщает утилите autoreport о том, что следует выводить информацию об активности пользователей в системе, а параметр -i - отображать имена пользователей вместо их идентификаторов.

И снова утилита aureport выводит большой объем информации. Нам же нужно знать о том, кто в последний раз пытался войти в систему от лица пользователя root, но не смог сделать этого. Если мы скопируем информацию о дате и времени последней попытки аутентификации, а именно, 21/05/16 18:32:05 и используем следующий фильтр grep для того, чтобы отфильтровать ненужные данные, мы получим следующий вывод:

> aureport -u -i|grep "21/05/16 18:32:05"
2324. 21/05/16 18:32:05 paul pts/3 ? /usr/bin/su 201

Упс! Это был я. Вообще, я не собирался оказывать негативного влияния на систему. Просто я постоянно промахиваюсь по клавишам и допускаю ошибки при вводе пароля root на своем компьютере.

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

> accessdate=`aureport -au | grep no | tail -1 | cut -d ' ' -f 2,3`; \
  aureport -u -i | grep "$accessdate"; unset accessdate
2324. 21/05/16 18:32:05 paul pts/3 ? /usr/bin/su 201

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

> aureport -au | grep no | cut -d ' ' -f 2,3 > accessdates.log; \
  aureport -u -i | grep -f accessdates.log; rm accessdates.log
986. 18/05/16 14:09:55 paul pts/4 ? /usr/bin/su 220 
987. 18/05/16 14:10:05 paul pts/4 ? /usr/bin/su 221 
1577. 20/05/16 12:37:07 paul pts/5 ? /usr/bin/su 191 
1785. 21/05/16 12:10:39 paul pts/0 ? /usr/bin/su 229 
2050. 21/05/16 17:59:08 paul pts/1 ? /usr/bin/su 208 
2090. 21/05/16 18:32:05 paul pts/0 ? /usr/bin/su 248

Как я говорил выше, я нередко промахиваюсь по клавишам.

Дальше будет еще интереснее

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


Поделиться: