20. Служба journal

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

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

Настройка данной службы осуществляется на следующем уровне конфигурации:

[edit service journal]

20.2. Настройка размера системного журнала на диске

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

# set limits max-disk-usage <max-disk-usage-value>

где <max-disk-usage-value> – число Мбайт, по умолчанию – 10% от размера диска, но не более 4G.

Для определения максимального размера каждого файла журнала по отдельности применяется команда:

# set limits max-file-size <max-file-size-value>

где <max-file-size-value> – число МБайт, по умолчанию – 1/8 от значения настройки max-disk-usage.

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

# set limits max-journal-files <max-journal-files-value>

где <max-journal-files-value> – число, по умолчанию – 100.

Пример настройки размера системного журнала на диске:

# edit service journal limits
# set max-disk-usage 4096
# set max-file-size 1
# set max-journal-files 50

В данном примере максимальное количество файлов журналов – 100, каждый из которых не превышает по размеру 1 МБ (т.е., если текущий журнал заполняется до 1 MБ, он ротируется; если общее количество файлов журналов превышает 100, самый старый файл журнала удаляется).

20.3. Уведомления о критичных событиях в интерфейсе командной строки

При возникновении событий уровня CRIT и выше в интерфейсе командной строки выводится уведомление в виде:

>

[CRIT] Lorem ipsum dolor sit amet
>

Для отключения данных уведомлений применяется команда:

# del service journal console-log-level

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

# set service journal console-log-level [emerg|alert|crit|err|warning|notice|info|debug]

где emerg|alert|crit|err|warning|notice|info|debug – уровень событий.

Примечание

Рекомендуется использовать уровень событий не ниже crit.

Для уведомлений о событиях уровня ALERT и выше:

• включается звуковой сигнал;

• в режиме конфигурации вместо знака # в командной строке отображается знак !;

• в режиме администрирования вместо знака > – >!.

Для выключения звукового сигнала применяется команда:

# del service journal alert-beep

По умолчанию настройка включена.

Для включения звукового сигнала применяется команда:

# set service journal alert-beep

Для просмотра уведомлений о событиях уровня ALERT и выше применяется команда:

> show alert

Для удаления уведомлений о событиях уровня ALERT и выше применяется команда:

> clear alert

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

20.4. События в журнале и их обработка

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

Предусмотрены действия трёх типов:

• пересылка сообщения на удалённый сервер (syslog-server <syslog-server-name>);

• вызов скрипта (script <script-name>);

• дублирование сообщения в журнал событий СКЗИ (crypto-log).

Настройка событий осуществляется на следующем уровне конфигурации

[edit service journal event <event-name>]

где <event-name> – строка длиной от 1 до 128 символов.

На данном уровне конфигурации доступны следующие настройки:

• facility <facility-name> – указать категорию журнала, сообщения которого отслеживаются, где <facility-name> – имя syslog facility;

• max-priority <max-priority-name> – указать максимальный уровень приоритета журнала, сообщения которого отслеживаются, где <max-priority-name> – имя syslog priority;

• min-priority <min-priority-name> – указать минимальный уровень приоритета журнала, сообщения которого отслеживаются, где <min-priority-name> – имя syslog priority;

• message-regex <regex-value> – указать регулярное выражение для отслеживаемых сообщений, где<regex-value> – строка длиной от 1 до 128 символов по стандарту POSIX ERE;

• syslogtag <syslogtag-name> – указать тэг журнала, сообщения от которого отслеживаются, где <syslogtag-name> – значение поля syslog tag;

• action <action-name> – указать действие(я), которое(ые) предпринимаются при возникновении события, где <action-name> – syslog-server <syslog-server-name>, script <script-name> или crypto-log.

При отслеживании сообщений применяется следующее правило: между различными настройками (критериями отбора) событий действует логическое ‘И’, для настроек событий одного типа действует логическое ‘ИЛИ’.

При указании настройки syslogtag <syslogtag-name> отслеживаются все сообщения, начинающиеся указанного в аргументе настройки значения. Например, при указании systemd в качестве тэга журнала в настройке syslogtag <syslogtag-name> отслеживаются все systemd* сервисы.

Пример настройки события (без настройки action):

# edit service journal
# edit event alert_fortun
# set syslogtag fxconf
# set min-priority 5
# set regex test regex "fortun"
# exit
# diff
service {
  journal {
+    event alert_fortun {
+      min-priority 5
+      syslogtag fxconfd
+      message-regex test {
+        regex fortun
+      }
+    }
  }
}

20.4.1. Правила написания регулярных выражений для фильтра message-regex

При написании регулярных выражений для фильтра message-regex необходимо соблюдать следующие правила:

1. Все сообщения начинаются с пробела.

2. Символ « следует дополнительно экранировать символом \ (в этом случае при установке (set) настройки regex в регулятронном выражении перед символом « указываются три символа \).

3. Если с помощью регулярного выражения фильтруются сообщения со спецсимволами |.()[]+*$^, их следует экранировать с помощью символов \ (в этом случае при выставлении (set) regex перед спецсимволами |.()[]+*$^ указываются четыре символа \).

Примеры команд с экранированием:

# set message-regex test regex "^ found \\\" at the start of message"
# set message-regex test2 regex "\\\\(in brackets\\\\) i want to find (this|or_this)"

20.4.2. Пересылка сообщения на удалённый сервер

Настройка удалённых серверов, на которые пересылаются сообщения по настройке action syslog-server, осуществляется на следующем уровне конфигурации:

[edit service journal syslog-server <syslog-server-name>]

где <syslog-server-name> – строка длиной от 1 до 128 символов.

На данном уровне конфигурации доступны следующие настройки:

• address ip <ip>|<host> – указать IP-адрес удалённого сервера, где <ip>|<host> – IP-адрес или имя хоста;

• address port <port-number> – указать порт удалённого сервера, где <port-number> – число от 1 до 65535;

• address protocol udp|tcp – указать протокол передачи, где udp|tcp – протокол, по умолчанию – udp.

• prefix <prefix-value> – указать префикс для сообщения при пересылке, где <prefix-value> – строка;

• source ip <ip-address>|<host> – указать IP-адрес, с которого отправляются сообщения при пересылке, где <ip>|<host> – IPv4/IPv6-адрес или имя хоста;

• source interface <interface-name> – указать имя интерфейса, с которого отправляются сообщения при пересылке, где <interface-name> – имя существующего интерфейса.

Настройка source ip может быть определена только при указании настройки address protocol udp.

Настройка prefix не является обязательной. Если данная настройка не указана, сообщения пересылаются на удалённый syslog-сервер без изменений. Если данная настройка указана, записи пересылаются в следующем виде:

<prefix-str>: <orig-message>

После настройки удалённого сервера, его имя можно указывать в качестве действия action при настройке события event.

Пример настройки события (продолжение примера настройки события):

# edit service journal
# set syslog-server server1 address ip 192.168.56.101
# set syslog-server server1 address port 1234
# set event alert_fortun action syslog-server server 1
# diff
service {
  journal {
+    syslog-server server1 {
+      address {
+        ip 192.168.56.101
+        port 1234
+      }
+    }
+    event alert_fortun {
+      min-priority 5
+      syslogtag fxconfd
+      message-regex test {
+        regex fortun
+      }
+      action {
+        syslog-server server1
+      }
+    }
  }
}

20.4.3. Выполнение скрипта

Настройка скриптов, вызываемых по настройке action script, осуществляется на следующем уровне конфигурации:

[edit service journal event <event-name> action script <script-name>]

где

• <event-name> – имя существующего события event;

• <script-name> – строка длиной от 1 до 128 символов.

На данном уровне конфигурации доступны следующие настройки:

• path <path-to-script> – указать выполняемый скрипт, где <path-to-script> – полное имя файла;

• args <args> – аргументы скрипта, где <args> – слова, указанные через пробел.

Экранирование пробелов при указании аргументов осуществляется с помощью символа \ (при этом символ \ внутри yang также подлежит экранированию).

В скрипт в качестве переменной окружения передаются следующие параметры:

• JOURNAL_EVENT_COUNT – число запусков события с момента его появления после последнего выполнения скрипта и до текущего вызова;

• JOURNAL_EVENT_MESSAGE – сообщение, вызвавшее событие.

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

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

[edit service journal]
# set script-user <account>

где <account> – имя существующей учетной записи.

Пример настройки скриптов (при условии существования интерфейса типа fortun):

# edit service journal
# set script-user admin
# set event key_exp message-regex catch regex "ifaces: Warning: private key"
# edit event key_exp
# set action script job path /system/scripts/snmp_send.lua
# set action script job args "one two three\\ four"
# commit
# show
event key_exp {
  message-regex catch regex "ifaces: Warning: private key"
  action script job path /system/scripts/snmp_send.lua
  action script job args "one two three\\ four"
}
script-user admin
# exit
# exit
# edit interface fortun test
# show
ipv4 {
  local 192.168.66.123
  remote 192.168.66.125
}
id 5
forsec-keypair {
  local-key pair1
  remote-key pair2
}
encryption

Содержимое скрипта, находящегося в /system/scripts/snmp_send.lua:

local conf1 = {
  snmptype = "trap",
  version = "3",
  addr = "192.168.56.1:12345",
  sec_engine_id = "0x8000123acd1ab43abbfff000fa",
  user = "test",
  auth_alg = "MD5",
  auth_key = "testsnmp",
  privacy_alg = "DES",
  privacy_key = "testSNMP",
}
local message = getenv("JOURNAL_EVENT_MESSAGE")
local key_name = string.match(message,"'%b'")
if ARGS[1] then
  journal("info", ARGS[1]) -- напишется только one
end
if ARGS[3] then
  journal("info", ARGS[3]) -- напишется three four
end
send_snmp(conf1, {"1.1.1.1.1.2.2.3.4.5"}, {"iso.3.6.1.6.3.1.1.6.2", key_name})

Пример события в журнале, подходящего под критерии отбора из примера выше:

апр 19 10:53:45 Fortics fxconf[3544]: ifaces: Warning: private key 'pair1' is expired!

После выполнения указанного скрипта на сервер поступает следующий сигнал SNMP-trap (ниже указан вывод snmptrapd):

2024-04-19 13:53:47 <UNKNOWN> [UDP: [192.168.56.101]:35686->[192.168.56.1]:12345]:
iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.1.1.1.1.2.2.3.4.5    iso.3.6.1.6.3.1.1.6.2 = STRING: "'pair1'"

20.4.4. Дублирование сообщения в журнал событий СКЗИ

Настройка дублирования осуществляется на следующем уровне конфигурации:

[edit service journal event <name-event> action crypto-log]

где <name-event> – имя существующего события event.

На данном уровне конфигурации доступна следующая настройка:

• prefix <prefix-value> – указать префикс для сообщения при дублировании в журнал событий СКЗИ, где <prefix-value> – строка.

Настройка не является обязательной. Если данная настройка не указана, сообщения дублируются в журнал событий СКЗИ без изменений. Если данная настройка указана, записи дублируются в виде:

<prefix-str>: <orig-message>

где

• <prefix-str> – префикс длч сообщения;

• <orig-message> – дублируемое сообщение.

Для сообщений из категории журнала local7 дублирование сообщений в журнал СКЗИ неприменимо.

Пример настройки дублирования:

# edit service journal event test
# set message-regex catch regex ".*"
# set facility authpriv
# set action crypto-log prefix "Prefix"
# commit
# show
facility authpriv
message-regex catch regex .*
action crypto-log prefix Prefix

Пример события в журнале, подходящего под критерии отбора из примера выше:

фев 07 13:53:15 Fortics sshd-session[5581]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)

Пример дублированного сообщения в журнале событий СКЗИ по указанным выше настройкам:

root@Fortics> show crypto log
2025-02-07 13:53:15 : Prefix:  pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)

Пример удаления настройки prefix:

# edit service journal event test
# del action crypto-log prefix
# commit
# show
facility authpriv
message-regex catch regex .*
action crypto-log

Пример события в журнале, подходящего под критерии отбора из примера выше:

фев 07 13:58:48 Fortics sshd-session[5581]: pam_unix(sshd:session): session closed for user root

Пример дублированного сообщения в журнале событий СКЗИ при удалённой настройке prefix:

root@Fortics> show crypto log
2025-02-07 13:58:48 :  pam_unix(sshd:session): session closed for user root

20.5. Просмотр журнала

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

> show journal

Для фильтрации вывода указываются следующие опции:

• boot 0|<negative-number>|<positive-number> – вывести указанную загрузку, где 0 – текущая загрузка, <negative-number> – отрицательное число (прошлые загрузки, например -1 – предыдущая), где <positive-number> – положительное число (начальные загрузки, присутствующие в журнале, например 1 – самая первая загрузка);

• service <service-name> – вывести сообщения указанной службы, где <service-name> – имя службы;

• facility <facility-name> – вывести сообщения указанной категории журнала, где <facility> – имя syslog facility;

• priority <priority-name> – вывести сообщения указанной уровня приоритета, где <priority> – имя syslog priority;

• format <format-name> – указать формат вывода журнала, где <format-name> – json, plain, режим выводимого времени;

• lines <lines-number> – вывести указанное количество последних строк журнала, где <lines-number> – число;

• search <search-string> – выделить в выводе команды сообщения, содержащие указанную строку, где <search-string> – строка;

• list-boots – вывести информацию о загрузках устройства;

• kernel – вывести сообщения ядра;

• reverse – вывести сообщения в обратном порядке (сверху – новые, снизу – старые);

• since <yyyy-mm-dd hh:mm:ss> – вывести сообщения начиная с указанной даты;

• until <yyyy-mm-dd hh:mm:ss> – вывести сообщения до указанной даты;

• size – вывести размер журнала (текущего и архивированных);

• utc – вывести время в формате UTC;

• follow – вывести журнал в интерактивном режиме.

Доступно единовременное использование нескольких опций из вышеуказанных.

Пример вывода команды для просмотра журнала:

> show journal service wcf lines 10
Jun 19 07:15:35 Fortics e2guardian[907]: Check the group that e2guardian runs as (wcf)
Jun 19 07:15:35 Fortics systemd[1]: Started WCF service.
Jun 19 07:15:35 Fortics e2guardian[914]: master: Started successfully.
Jun 20 08:29:17 Fortics systemd[1]: Starting WCF service...
Jun 20 08:29:17 Fortics e2guardian[909]: Unable to getgrnam(): Success
Jun 20 08:29:17 Fortics e2guardian[909]: Unable to getgrnam(): Success
Jun 20 08:29:17 Fortics e2guardian[909]: Check the group that e2guardian runs as (wcf)
Jun 20 08:29:17 Fortics e2guardian[909]: Check the group that e2guardian runs as (wcf)
Jun 20 08:29:17 Fortics systemd[1]: Started WCF service.
Jun 20 08:29:17 Fortics e2guardian[919]: master: Started successfully.

20.6. Очистка журнала

Для очистки журнала в режиме администрирования применяется команда:

> service journal clear

Для данной команды возможно указание следующих опций:

• time <time-value> – удаление событий, произошедших ранее указанного периода, где <time-value> – строка в формате n(s|m|h|days|weeks|years|months), где n – число, s – секунды, m – минуты, h – часы, days – дни, weeks – недели, years – годы, months – месяцы;

• size <size-value> – очистка журнала до указанного размера, где <size-value> – строка в формате n(K|M|G), где n – число, K – Кбайты, M – Мбайты, G – Гбайты.

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

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

> service journal clear time 2days

> service journal clear size 100M

20.7. Проверка целостности журнала

В ПАК “Фортикс” реализована возможность проверки целостности журнала за счёт проверки корректности структуры двоичных файлов журнала и свёрки хэшей. В случае, если в журналах обнаружены ошибки, администратор может игнорировать их или очистить данные журналы.

Для проверки целостности файлов журнала применяется команда:

> service journal verify

Перед файлами журнала, успешно прошедшими проверку, выводится PASS:.

Пример вывода команды для проверки целостности файлов журнала в случае успешного прохождения проверки всеми файлами:

> service journal verify
PASS: /log/journal/8768c0a72e9b479ba5beb45880f8e9f3/system@d1b49a459bfb4a8da0721025bcc44ca7-000000000000075c-00062c491ba6919e.journal
PASS: /log/journal/8768c0a72e9b479ba5beb45880f8e9f3/system@d1b49a459bfb4a8da0721025bcc44ca7-0000000000000001-00062c49195cb2ec.journal
PASS: /log/journal/8768c0a72e9b479ba5beb45880f8e9f3/system@00062bee841167e0-3832fd4329d459c9.journal~
PASS: /log/journal/8768c0a72e9b479ba5beb45880f8e9f3/system.journal
PASS: /log/journal/8768c0a72e9b479ba5beb45880f8e9f3/system@00062c4919679642-f6fba473abdc3043.journal~

В случае неуспешного прохождения проверки выводится причина ошибки и перед повреждённым файлом выводится FAIL:.

Пример вывода команды для проверки целостности файлов журнала в случае неуспешного прохождения проверки:

> service journal verify
0015e0: Invalid data hash table hash table item (49369/178318): head_hash_offset=000000 tail_hash_offset=220000
0015e0: Invalid object contents: Bad message
File corruption detected at /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-0000000000006ffa-00062c4903c8d5ec.journal:0015e0 (of 5175480 bytes, 0%).
FAIL: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-0000000000006ffa-00062c4903c8d5ec.journal (Bad message)
PASS: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-0000000000006a39-00062c48ea69c34f.journal
PASS: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-00000000000003a6-00062be3a82af550.journal
PASS: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-0000000000000001-00062be3a7c77551.journal
PASS: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system.journal
PASS: /log/journal/ea96a9058961432fab9c25ae20da5e6a/system@f3fa1fe5da904a39b55e64da94b7d5f2-0000000000000abb-00062be4c96dfdd4.journal