Aide. Аудит изменений файлов и папок в Linux.

Порой у всех начинает зашкаливать паранойя. Что-то произошло. Сервер взломали? Кто-то неудачно изменил конфиг и теперь непонятно, какой файл изменялся? На эти вопросы нам поможет ответить aide.

Важно! Подобные программы вспоминают чаще всего когда с системой что-то не то. Но в этот момент уже поздно пить боржоми. Если система скомпрометирвоана или просто неудачно что-то изменено, сравнивать текущее состояние просто не с чем. И бекап вам может не помочь, т.к. если система была в продакшене уже 3 года, то откуда вам знать, что и когда было изменено, в т.ч. в важных файлах (/etc/shadow, например). Поэтому важно настроить aide ДО того момента, когда он реально понадобится.

Все действия я проводил в CentOS, сразу после установки и базовых настроек (сеть, nano, mc и др. по вашему вкусу).

В базе файл уже готов к эксплуатации. Обратите внимание на то, где будут логи и база данных aide.

Запоминаем текущее состояние системы:

Сохраняем файлы:
/etc/aide.conf
/usr/sbin/aide
/var/lib/aide/aide.db.new.gz

в безопасном месте (т.е. явно не на этом же хосте), например, на флешке, на центральном сервере или в другом месте. На основании этих файлов вы будете в дальнейшем сравнивать, были ли изменения системных и др. файлов. Т.е. этим файлам вы должны полностью доверять. Как самому себе.

Ну, например, так (из Windows, используя Putty):

# pscp -v -P 22 -l srv-user 192.168.1.12:/var/lib/aide/aide.db.new.gz aide.db.new.gz

или как угодно еще.

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

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

# cd /var/lib/aide
# cp aide.db.new.gz aide.db.gz

Все, мы готовы к проверке.

Изменим какой-либо файл в системе, например, добавим новую строку в файл /etc/resolv.conf. Достаточно добавить пустую строку и сохранить файл.

Ищем, что поменялось:

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

AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2015-12-08 16:06:06

Summary:
Total number of files: 29931
Added files: 0
Removed files: 0
Changed files: 1

File: /etc/resolv.conf
Size : 132 , 133
SHA256 : xOEHDphj3/oSHCPkBuQeNyhZP3k3t/mV , Zd5keHnFCF6HjVdnPuFelZTb7rkgLXfb

Если мы знаем, что изменения легитимны, то мы можем обновить базу данных:

Попробуйте отправить отчет себе на email:

# aide —check | /usr/bin/mail -s «AIDE check on $HOSTNAME at `date +%d-%m-%Y—%H-%M`» your@email.com

Если отчет пришел, можете добавить команду в крон (например, выполнять каждый день):

# crontab -e
0 0 * * * /usr/sbin/aide —check | /usr/bin/mail -s «AIDE check on $HOSTNAME at `date +%d-%m-%Y—%H-%M`» your@email.com

Не факт, что вам не надоест постоянный отчет по электронной почте, но если вы не входили на сервер, а /etc/passwd изменился, это повод для серьезного расследования.

Важно, чтобы вы были уверены, что файл базы данных /var/lib/aide/aide.db.gz именно тот, который вы создавали своими руками.

Aide неплохо дополняется git, но это другая история.

Источник

Настройка и аудит системы Linux с помощью демона Auditd

В инструкции рассмотрена установка, настройка и использование Auditd на серверах под управлением операционной системы Linux.

Что это такое?

Linux Audit Daemon — это среда, позволяющая проводить аудит событий в системе Linux. Используя мощную систему аудита возможно отслеживать многие типы событий для мониторинга и проверки системы, например:

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

Установка и настройка

Для установки используйте ваш пакетный менеджер, например для Debian/Ubuntu:

apt-get install auditd audispd-plugins

На серверах CentOS демон auditd обычно уже предустановлен (пакеты audit and audit-libs).

Конфигурация выполняется с помощью двух файлов: auditd.conf — настройка самого демона, audit.rules — настройка правил, используемых средством auditctl.

Примечание: auditctl — клиентский инструмент для настройки auditd.

Файл auditd.conf настраивает демон аудита Linux (auditd) с акцентом на том, где и как он должен регистрировать события. Он также определяет, как работать с дисками, журналом повторов и количеством хранимых логов. Обычно стандартная конфигурация подходит для большинства систем.

Чтобы настроить, какие именно события подвергать проверке, в структуре аудита используется файл правил с именем audit.rules.

Активные правила можно просмотреть с помощью опции -l:

Сразу после установки набор правил будет пустым.

Удалить правила можно с помощью опции -D:

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

auditctl -a exit,always -F path= -F perm=

auditctl -a exit,always -F path=/etc/passwd -F perm=wa

Ключ -F задет фильтры, определив переменную path, мы задаем, какой каталог или файл следует отслеживать. Переменная path определяет, какой вид доступа вызовет событие. Существует 4 вида доступа и они похожи на разрешения файлов, но обратите внимание, что между ними существует важное различие:

• r = читать
• w = писать
• x = выполнить
• a = изменить атрибут

Ключ -a указывает список и действие. Допустимые списки: task, exit, user, exclude. Допустимые действия: never, always.

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

ausearch -f /etc/passwd

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

• time — время события
• name — имя объекта
• cwd — текущий рабочий путь, из которого происходил доступ к файлу
• syscall — связанный системный вызов
• auid — идентификатор пользователя аудита
• exe — двоичный файл, выполняющий действие над файлом

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

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

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

Например вызов 82 на архитектуре x86_64:

ausyscall x86_64 82

Аудит пользователей

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

auditctl -a exit,always -F arch= -S open -F auid=

auditctl -a exit,always -F arch=x86_64 -S open -F auid=80

• -S open — обращение к системному вызову open
• -F auid=80 указывает идентификатор пользователя

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

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

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

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

aureport —start / / : : —end / / : :

aureport —start 07/15/2018 00:00:00 —end 07/10/2018 00:00:00

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

Для генерации сводки событий используйте ключ —summary:

aureport -x —summary

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

aureport -u —failed —summary -i

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

Источник

Аудит системных событий в Linux

Одним из инструментов, позволяющих повысить уровень безопасности в 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 — используется для исключения событий.

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

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

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

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

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

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

Файлы правил

Правила можно не только задавать через командную строку, но и прописывать в файле etc/audit/audit.rules.
Начинается этот файл с так называемых метаправил, в которых задаются общие настройки журналирования:

Далее следуют пользовательские правила. Их синтаксис предельно прост: достаточно просто перечислить соответствующие опции команды 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=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 нужно прописать следующие параметры:

tcp_listen_port = 60
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535 #optional
tcp_client_max_idle = 0

Заключение

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

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

Источник