Astra linux журналы аудита

Журналы работы системных служб

В Astra Linux Special Edition очередное обновление x.7 рекомендована к применению служба ведения журналов syslog-ng. В более ранних очередных обновлениях Astra Linux по умолчанию используется служба rsyslog. Служба syslog-ng:

• устанавливается по умолчанию при установке оперативных обновлений Astra Linux x.7;
• при установке замещает собой службу rsyslog. Служба rsyslog при этом полностью удаляется.

Дальнейшее использование службы rsyslog не соответствует поддерживаемым сценариям эксплуатации. Служба rsyslog более не поддерживается в составе основного репозитория Astra Linux Special Edition (доступна в составе расширенного репозитория). В находящихся в эксплуатации системах службу rsyslog необходимо заменить на службу syslog-ng.

Службы управления журналами

• syslog-ng — служба управления журналами syslog-ng по умолчанию используется в Astra Linux Special Edition x.7, доступна в репозиториях более ранних очередных обновлений;
• rsyslog — служба управления журналами rsyslog по умолчанию используется в Astra Linux Common Edition и Astra Linux Special Edition ранее очередного обновления x.7, доступна в основном репозитории Astra Linux Special Edition x.7 ;
• syslog (sysklogd) — служба управления журналами syslog в настоящее время в Astra Linux не используется;
• logrotate — служба архивирования и очистки (ротации) журналов.

Основные возможности служб:

• Получение и передача сообщение по сетевым протоколам TCP/UDP/. с возможностью настройки IP-портов и IP-адресов;
• Загрузка внешних модулей;
• Фильтрация и перенаправление сообщений по имени программы, источнику, номеру процесса и т.д.;
• Удаление ненужных сообщений;

Служба syslog-ng

Расположение файлов конфигурации

• основной файл: /etc/syslog-ng/syslog-ng.conf;
• дополнительные файлы .conf в каталоге /etc/syslog-ng/conf.d.

Базовые принципы функционирования

Служба syslog-ng получает системные сообщения из указанных источников и перенаправляет их в указанные приемники. Источниками могут быть файлы, удаленные хосты, системные сокеты и другие источники. Источники и приемники являются независимыми объектами и соединяются путями передачи (далее — путь). Путь состоит из одного или нескольких источников и одного или нескольких приемников. Дополнительно определение пути может содержать:

• фильтры — правила, применяемые для селекции сообщений;
• анализаторы (parsers) — правила для анализа и разбора сообщений;
• модификаторы ( rewriting rules) — правила для модификации сообщений.

Базовые принципы конфигурации

Конфигурационный файл состоит из определений объектов. Базовый синтаксис определения объекта:

• тип объекта — один из типов:
  • source — источник;
  • destination — приемник;
  • log — путь;
  • filter — фильтр;
  • parser — анализатор;
  • rewrite rule — модификатор;
  • template — шаблон;
  • option — глобальные опции.

  Пример: определение объекта типа источник и именем s_internal:

  Пример: определение объекта типа приемник:

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

  Параметры объектов могут иметь обязательные и необязательные опции. Обязательные опции являются позиционными и должны быть указаны в заданном порядке. Необязательные опции имеют формат
  () и могут указываться в любом порядке.

  Пример: Источник s_demo_stream имеет один параметр — драйвер источника unix-stream(), который имеет одну обязательную опцию — имя сокета, и необязательные опции — max_connection и group:

  source s_demo_stream1 < unix-stream("" max-connections(10) group(log)); >;

  • Объекты могут использоваться до их определения;
  • Объекты могут определяться при их использовании (inline), что полезно при однократном применении, например, фильтров;
  • Строки, начинающиеся с символа «#» считаются комментариями и игнорируются;

  Синтаксис определения пути:

  Пример определения источника, приемника и простого пути:

  source s_localhost < network(ip(127.0.0.1) port(1999)); >; destination d_tcp < network("10.1.2.3" port(1999) localport(999)); >; log < source(s_localhost); destination(d_tcp); >;

  Тот же пример определения простого пути с использованием inline-определений источника и приемника:

  В конфигурации syslog-ng поддерживаются глобальные опции для управления использование DNS, форматами временных отметок и других общих параметров. Синтаксис определения опций:

  Пример применения глобальных опций:

  Отключения разрешения имен через DNS:

  Перечень основных источников, приемников и фильтров:

  Таблица 1. Драйверы источников

  Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS..

  Таблица 2. Драйверы приемников

  Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версия 2 и новее.

  Таблица 3. Доступные фильтры.

  Название	Описание	Комментарий
  facility()	Фильтрация сообщений по указанному объекту (facility).
  filter()	Вызов другого фильтра.
  host()	Фильтрация сообщений по имени хоста-отправителя.
  inlist()	Фильтрация сообщений по черным и белым спискам в файлах.
  level() priority()	Фильтрация сообщений по приоритету.
  match()	Фильтрация по регулярным выражениям, применяемым к заголовку и содержимому сообщения.
  message()	Фильтрация по регулярным выражениям, применяемым к содержимому сообщения.
  netmask()	Фильтрация сообщений по IP-адресу хоста-отправителя.
  program()	Фильтрация сообщений по названию приложения.
  source()	Фильтрация сообщений по указанному источнику.
  tags()	Фильтрация сообщений по наличию указанных тегов.

  Служба rsyslog

  Расположение файлов конфигурации

  Служба logrotate

  Расположение файлов конфигурации

  Настройки по умолчанию (основной файл конфигурации /etc/logrotate.conf):

  • weekly — файлы журналов подвергаются ротации, если текущий день недели меньше дня недели последней ротации или если со времени последней ротации прошло больше недели;
  • rotate— файлы журнала ротируются указанное количество раз перед тем, как будут удалены или отправлены на адрес, указанный в директиве mail. Если количество равно нулю, прежние версии удаляются, а не ротируются. Количество по умолчанию — 4;
  • create — сразу после ротации (до запуска сценария postrotate) создать файл журнала (с таким же именем, как у только что ротированного файл журнала). Поле режим определяет режим для файла журнала в восьмеричном представлении (как в chmod(2)), поле владелец определяет имя пользователя который является владельцем этого файла журнала, и поле группа определяет группу, которой принадлежит файл журнала. Любой из этих атрибутов может быть пропущен, в таком случае для пропущенных атрибутов будут использоваться атрибуты исходного файла журнала. Эта опция может быть отключена с помощью опции nocreate;

  Подробное описание см. man logrotate.

  Взаимная замена служб rsyslog/syslog-ng

  Замена пакетов

  B Astra Linux Special Edition x.7 служба rsyslog не поддерживается. Если служба rsyslog была установлена ранее, то для замены службы rsyslog на службу syslog-ng выполнить команду:

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

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

  Миграция конфигурационных файлов

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

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

  Далее в качестве примера приведено соответствие конфигураций rsyslog и syslog-ng некоторых пакетов. :

  # Log cloudinit generated log messages to file :syslogtag, isequal, "[CLOUDINIT]" /var/log/cloud-init.log # comment out the following line to allow CLOUDINIT messages through. # Doing so means you'll also get CLOUDINIT messages in /var/log/syslog & stop

  log < source(s_src); filter < message("^.*CLOUDINIT.*$"); >; destination < file("/var/log/cloud-init.log"); >; flags( final); >;

  # Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile :programname, startswith, "haproxy" < /var/log/haproxy.log stop >

  log < source < unix-dgram("/var/lib/haproxy/dev/log"); >; filter < program("haproxy"); >; destination < file("/var/log/haproxy.log"); >; flags( final); >;

  # Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& stop

  log < source(s_src); filter < message("^.*UFW.*$"); >; destination < file("/var/log/ufw.log"); >; # flags( final); >;

  # Send Jetty messages to jetty.out when using systemd :programname, startswith, "jetty9" < /var/log/jetty9/jetty-console.log stop >

  log < source(s_src); filter < program("jetty9"); >; destination < file("/var/log/jetty9/jetty-console.log"); >; flags( final); >;

  # Create an additional socket in postfix's chroot in order not to break # mail logging when rsyslog is restarted. If the directory is missing, # rsyslog will silently skip creating the socket. $AddUnixListenSocket /var/spool/postfix/dev/log

  log < source < unix-stream("/var/spool/postfix/dev/log" keep-alive(yes)); >; filter < program("postfix"); >; destination(d_syslog); >;

  # Send Tomcat messages to catalina.out when using systemd $template TomcatFormat, "[%timegenerated. date-year%- %timegenerated. date-month%- %timegenerated. date-day% %timegenerated. date-hour%: %timegenerated. date-minute%: %timegenerated. date-second%] [%syslogseverity-text%]%msg%\n" :programname, startswith, "tomcat9" < /var/log/tomcat9/catalina.out;TomcatFormat stop >

  log < source(s_src); filter < program("tomcat9"); >; destination < file("/var/log/tomcat9/catalina.out", template("[$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC] [$PRIORITY]$MSG\n")); >; flags( final); >;

  Инструмент сбора журналов astra-create-debug-logs

  В состав дистрибутивов ОС Astra Linux входит инструмент командной строки astra-create-debug-logs, предназначенный для автоматического сбора архива журналов системных служб.
  Для создания архива журналов инструмент должен быть запущен от имени суперпользователя:

  Расположение файлов журналов основных системных служб

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

  Необходимо включить запись в журнал в конфигурационном файле /etc/dovecot/conf.d/10-logging.conf в параметре log_path.
  Например, указать: /var/log/dovecot.log

  Источник

  Настройка аудита

  Все факты начала и окончания работы пользователя фиксируется в журнале /var/log/auth.log на клиентской машине. Например:

  Feb 19 12:32:48 nd-nout fly-dm: :0[3421]: pam_unix(fly-dm:session): session opened for user ivanov by (uid=0)

  Указанная запись содержит информацию о начале сессии для пользователя с учетной записью « ivanov ».

  Указанная запись содержит информацию о завершении сессии для пользователя с учетной записью « petrovich ».

  Кроме того, информация о начале и завершении работы пользователя попадает в журнал подсистемы безопасности parsec: /var/log/parsec/user.mlog , доступный для просмотра при помощи утилиты « userlog ». В журнале регистрируются события с типами « auth » (вход), « exit » (выход).

  [u] ‘Tue Feb 19 12:50:00 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 12:57:59 2013’ ‘/usr/bin/fly-dm’ [s] exit(«fly-dm»,»root»)

  [u] ‘Tue Feb 19 13:14:52 2013’ ‘/bin/login’ [s] auth(«login»,»root»)

  [u] ‘Tue Feb 19 13:15:33 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:15:39 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:19:53 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:20:13 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:20:23 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:20:31 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:27:48 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:27:54 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:33:51 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:33:55 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:39:49 2013’ ‘/bin/login’ [s] auth(«login»,»petrovich»)

  [u] ‘Tue Feb 19 13:39:53 2013’ ‘/bin/login’ [s] exit(«login»,»petrovich»)

  Описание системы регистрации событий приведено в разделе 10 документа «Операционная система специального назначения «Astra Linux Special Edition». Руководство по КСЗ. Часть 1». Дополнительная информация приведена на страницах справочного руководства « man » для расширенной системы протоколирования, доступной по команде « man parselog ». В операционной системе специального назначения «Astra Linux Special Edition» обеспечивается регистрация всех событий в соответствии с требованиями документа «Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» ФСТЭК России, предъявляемых к средствам вычислительной техники третьего класса защищенности. Регистрация событий может быть проверена следующим образом: устанавливаем для пользователя (доменного) все возможные флаги аудита:

  Audit policy user:petrovich

  Audit success rules: ocxudntligarmphew

  Источник

  Читайте также:  Сколько места занимает linux ubuntu