что такое аудит лог

audit log

Audit Record Generation and Utilization System — or Argus is a fixed model Real Time Flow Monitor designed to track and report on the status and performance of all network transactions seenin a data network traffic stream, doing that by that categorizing IP packets which match the boolean… … Wikipedia

Audit trail — An audit trail or audit log is a chronological sequence of audit records, each of which contains evidence directly pertaining to and resulting from the execution of a business process or system function. Audit records typically result from… … Wikipedia

Log analysis — (or system and network log analysis ) is an art and science seeking to make sense out of computer generated records (also called log or audit trail records). The process of creating such records is called data logging.Typical reasons why people… … Wikipedia

Log management and intelligence — Log Management (LM) comprises an approach to dealing with large volumes of computer generated log messages (also known as audit records, audit trails, event logs, etc). LM covers log collection, centralized aggregation, long term retention and… … Wikipedia

Log-Datei — Eine Logdatei (engl. log file) beinhaltet das automatisch erstellte Protokoll aller oder bestimmter Aktionen von Prozessen auf einem Computersystem. Die korrekte Bezeichnung dafür ist deshalb Protokoll Datei. Wichtige Anwendungen finden sich vor… … Deutsch Wikipedia

audit trail — noun A formal record or log of the financial transactions of an organization or system, especially such a computerized record … Wiktionary

audit policy — In Microsoft Windows 2000, the policy that defines the security events to track and report to the network administrator. See also security log … Dictionary of networking

Voter Verified Paper Audit Trail — (VVPAT) or Verified Paper Record (VPR) is intended as an independent verification system for voting machines designed to allow voters to verify that their vote was cast correctly, to detect possible election fraud or malfunction, and to provide a … Wikipedia

Information technology security audit — A computer security audit is a manual or systematic measurable technical assessment of a system or application. Manual assessments include interviewing staff, performing security vulnerability scans, reviewing application and operating system… … Wikipedia

Information audit — An information audit trail or information audit log is a chronological sequence of audit records, each of which contains data about when and by whom was a particular record changed. It can also include information about the actual changes that… … Wikipedia

Источник

Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.

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

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.
Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.
Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора.

Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора.

Эти 2 события генерируются одновременно при удалении файла, но записываются последовательно, сначала 4663, потом 4660. При этом их порядковые номера различаются на один. У 4660 порядковый номер на единицу больше чем у 4663.
Именно по этому свойству и ищется нужное событие.

Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*

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

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

Рекомендации

Вам придется самим определить время в течении которого вы будете искать нужные события. Чем больше период, тем дольше ищет. Все зависит от производительности сервера. Если слабенький — то начните с 10 минут. Посмотрите, как быстро отработает. Если дольше 10 минут, то либо увеличьте еще, вдруг поможет, либо наоборот уменьшите период до 5 минут.

Источник

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

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

Подсистема аудита: архитектура и принцип работы

Подсистема аудита была добавлена в ядро Linux начиная с версии 2.6. Она предназначена для отслеживания критичных с точки зрения безопасности системных событий. В качестве примеров таких событий можно привести следующие (список далеко не полный):

Получив вызов от приложения в пространстве пользователя, подсистема аудита пропускает его через один из следующих фильтров: user, task или exit (более подробно о них речь пойдёт ниже). После этого вызов пропускается через фильтр exclude, который исходя из правил аудита передаёт его демону auditd для дальнейшей обработки.

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

Установка

Чтобы начать работать с подсистемой аудита, нужно установить пакет auditd (здесь и далее приводятся примеры команд для OC Ubuntu 14.04):

В cостав этого пакета входят демон auditd и несколько вспомогательных утилит:

Конфигурирование

Настройки подсистемы аудита хранятся в конфигурационном файле etc/audit/auditd.conf. Он содержит в числе прочих следующие параметры:

Создание правил

Для добавления и настройки правил используется команда auditctl. Вот список её опций:

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

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

Файлы правил

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

Далее следуют пользовательские правила. Их синтаксис предельно прост: достаточно просто перечислить соответствующие опции команды auditctl. Рассмотрим пример типового файла правил:

Изменения конфигурации вступят в силу после перезапуска демона auditd:

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

Все журнальные файлы сохраняются в директории /var/log/audit в машиночитаемом формате. Их можно сделать человекопонятными c помощью утилиты aureport.

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

Она не имеет особой практической ценности. Гораздо больший интерес представляют специализированные отчёты. Вот так, например, можно просмотреть информацию обо всех системных вызовах:

В аureport поддерживается фильтрация по дате и времени:

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

и затем выполнить следующую команду:

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 и его уникальный идентификационный номер.

В поле syscall указан тип системного вызова — в нашем случае это 2, то есть вызов open. Параметр success сообщает, был ли вызов обработан успешно или нет. В нашем примере вызов был обработан неудачно (success = no).

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

Приведённая команда выведет список всех действий, совершённых от имени 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. Мы рассмотрели принцип работы системы аудита, научились формулировать правила, читать логи и пользоваться вспомогательными утилитами.

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

Источник

Основы аудита. Настраиваем журналирование важных событий в Linux

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

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

Под­систе­ма ауди­та в Linux сос­тоит из двух групп ком­понен­тов: в прос­транс­тве ядра это kauditd, а в поль­зователь­ском — auditd.

В общем виде схе­ма работы под­систе­мы ауди­та выг­лядит сле­дующим обра­зом.

Че­рез netlink( 7) сооб­щения отправ­ляют­ся из kauditd в auditd. При получе­нии событий, демон auditd записы­вает их в лог (по умол­чанию / var/ log/ audit/ audit. log ).

Нас­тра­ивая филь­тры с помощью ути­литы auditctl, мы можем управлять потоком событий, который хотим получать. С помощью ути­лит ausearch, aureport, aulast удоб­но прос­матри­вать жур­нал ауди­та.

Да­вай теперь уста­новим и нас­тро­им все под­систе­мы ауди­та. Уста­нов­ка край­не прос­та и не вызыва­ет никаких слож­ностей:

Ста­тус работы под­систе­мы ауди­та мож­но получить так:

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

Раз­берем­ся теперь, как управлять филь­тра­ми kauditd. Все нас­трой­ки филь­тров груп­пиру­ются в фай­лы пра­вил. Фор­мат пра­вил ана­логи­чен син­такси­су кон­соль­ной прог­раммы auditctl. Демон auditd заг­ружа­ет эти пра­вила пос­ледова­тель­но при стар­те сис­темы либо вруч­ную по коман­де пользователя.

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

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

Дей­ствие action может быть always (всег­да соз­давать события) или never (никог­да не соз­давать события).

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

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник

Мониторинг активности базы данных с помощью журналов аудита на гибком сервере базы данных Azure для MySQL

Область применения: База данных Azure для MySQL — гибкий сервер

Гибкий сервер базы данных Azure для MySQL предоставляет пользователям возможность настраивать журналы аудита. Журналы аудита могут использоваться для наблюдения за действиями уровня базы данных, включая события подключения, администрирования, DDL и DML. Эти типы журналов обычно используются для обеспечения соответствия требованиям.

Настройка ведения журналов аудита

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

Другие параметры, которые можно настроить для управления ведением журнала аудита:

Доступ к журналам аудита

Журналы аудита можно интегрировать с настройками диагностики Azure Monitor. Включив ведение журналов аудита на гибком сервере MySQL, вы можете реализовать их отправку этих данных в журналы Azure Monitor, Центры событий или службу хранилища Azure. Дополнительные сведения о настройках диагностики см. в документации к журналам диагностики. Дополнительные сведения о включении настроек диагностики в портале Azure см. в статье о портале журналов аудита.

В следующих разделах описываются выходные данные журналов аудита MySQL на основе типа события. Порядок появления выбранных полей зависит от выбранного метода вывода.

Подключение

Общие сведения

Схема ниже относится к событиям типов GENERAL, DML_SELECT, DML_NONSELECT, DML, DDL, DCL и ADMIN.

Для sql_text_s журнал будет обрезан, если его длина превышает 2048 символов.

Доступ к таблицам

Для sql_text_s журнал будет обрезан, если его длина превышает 2048 символов.

Анализ журналов в журналах Azure Monitor

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

Вывод списка событий GENERAL на конкретном сервере

Вывод списка событий CONNECTION на конкретном сервере

Вывод сводки событий, для которых проводится аудит, на конкретном сервере

Построение диаграммы распределения типов событий, для которых проводится аудит, на конкретном сервере

Вывод списка событий, для которых проводится аудит, на всех серверах MySQL с журналами диагностики, поддерживающих журналы аудита

Источник