Настройка syslog astra linux

Обновлено: 03.07.2024

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Файл syslog.conf является главным конфигурационным файлом для демона syslogd. Конфигурационный файл syslog.conf представляет собой набор правил. Каждое правило есть - строка, состоящая из селектора и действия , разделенных пробелом или табуляцией. Селектор представляет собой запись в виде источник . приоритет . (источник иногда именуют - категорией) Селектор может состоять из нескольких записей источник.приоритет, разделенных символом ";" . Можно указывать несколько источников в одном селекторе (через запятую). Поле действие - устанавливает журналируемое действие для селектора.

Источник (он же категория) может быть следующим:

Обычный файл

Задается полным путем, начиная со слеша (/). Поставьте перед ним дефис (-), чтобы отменить синхронизацию файла после каждой записи. Это может привести к потере информации, но повысить производительность.

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Список пользователей

Пример несложного syslog.conf:

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

В синтаксисе конфигурационного файла можно поставить перед приоритетом знак !, чтобы показать, что действие не должно применяться, начиная с этого уровня и выше. Подобным образом, перед приоритетом можно поставить знак =, чтобы показать, что правило применяется только к этому уровню, или !=, чтобы показать, что правило применяется ко всем уровням, кроме этого. Ниже показано несколько примеров (man syslog.conf можно найти множество других примеров):

Я постарался максимально понятно работу syslogd показать на схеме:

Запуск демона syslogd

Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт - начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).

Вот некоторые возможные параметры запуска демона syslogd:

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

можно послать демону syslogd один из следующих сигналов: SIGHUP - перезапуск демона; SIGTERM - завершение работы; SIGUSR1 - включить/выключить режим отладки.

Вообще-то в системе запускаются два демона протоколирования - syslogd и klogd. Оба демона входят в состав пакета sysklogd.

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.

Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:

Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.

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

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

В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.

Параметры, задаваемые в конфигурационном файле logrotate.conf:

Изучение и мониторинг журналов

Далее в файле протокола можно обнаружить версию ядра, параметры его запуска, информацию о типе процессора и объеме ОЗУ:

Иногда может возникать необходимость мониторинга системных журналов с целью поиска текущих событий. Например, можно попробовать поймать редко случающееся событие в тот момент, когда оно произошло. В таком случае можно использовать команду tail с опцией -f для отслеживания содержимого системного журнала. Пример:

Кроме файлов-журналов, указанных в /etc/syslog.conf, существуют так же и другие файлы, например файл /var/log/dmesg, который хранит информацию о процессе загрузки системы до запуска syslogd, а так же файлы /var/log/lastlog, /var/log/wtmp, /var/log/btmp, имеющие двоичный формат и и хранящие информацию о последнем входе пользователя в систему, о всех удачных входах пользователей в систему и о всех неудачных входах пользователей в систему соответственно. Так же в каталоге /var/log/ могут находится лог-файлы таких демонов как веб-сервер или прокси-сервер. Формат данных файлов аналогичен журналам syslogd.

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

Rsyslog – это мощная, безопасная и высокопроизводительная система обработки логов, принимающая данные из различных источников (систем и приложений) и выдающая их в разнообразных форматах. Она представляет собой развитие обычного демона syslog до полнофункциональной системы ведения логов корпоративного уровня. Rsyslog работает по модели «клиент-серевер», поэтому ее можно настроить как клиент и/или сервер для централизованного ведения логов других серверов, сетевых устройств и удаленных приложений.
В данном руководстве мы рассмотрим основы работы с rsyslog. В примерах мы будем использовать следующие узлы:

Сервер: 192.168.241.140
Клиент: 172.31.21.58

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

В большинстве дистрибутивов Linux пакет rsyslog предустановлен. Если у вас его нет, установите его при помощи менеджера пакетов:
Для RHEL/CentOS:

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

Для использования TCP-соединения (медленнее, но надежнее) найдите и раскомментируйте следующие строки:

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

Последняя строка «&

Далее требуется проверить сетевые сокеты rsyslog. Воспользуйтесь netstat

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

При включенном брандмауэре нужно открыть TCP и UDP порты 514, чтобы разрешить подключение к серверу rsyslog по обоим протоколам:

Для CentOS (брандмауэр firewalld):

Для Ubuntu (брандмауэр ufw):

Настройка клиента Rsyslog для отправки логов на сервер

Проверьте, запущена ли служба rsyslog на клиентской машине, при помощи следующей команды:

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

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

Сохраните и закройте файл, а также перезагрузите службу rsyslog чтобы изменения вступили в силу.

Мониторинг логов на сервере

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

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Управление типом и подробностью журналируемой информации

Конфигурационный файл syslog.conf

Источник (он же категория) может быть следующим:

Обычный файл

Терминал и консоль

Терминал, такой как /dev/console.

Удаленная машина

Список пользователей

Пример несложного syslog.conf:

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

Запуск демона syslogd

Вот некоторые возможные параметры запуска демона syslogd:

С помощью команды
kill -SIGNAL `cat /var/run/syslogd.pid`

Автоматическая ротация (обновление заполненных файлов) и архивирование журналов

Параметры, задаваемые в конфигурационном файле logrotate.conf:

Изучение и мониторинг журналов

Подведем небольшой итог:

На сегодня это все. Надеюсь описал все максимально понятно. Со временем буду дополнять статью!

Rsyslog позволяет настроить отправку логов для определенного приложения на централизованный сервер. Это может значительно упростить процесс контроля за событиями на компьютерах в сети. Его настройка на различных системах на базе Linux, практически, не отличается. В данной инструкции мы рассмотрим процесс установки и настройки на примере CentOS и Ubuntu.

Подготовка сервера

На сервере нужно, предварительно, выполнить следующие настройки.

Время

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

Сначала задаем правильный часовой пояс:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере мы использовали московское время.

Затем устанавливаем и запускаем chrony.

а) на системе CentOS / Red Hat:

yum install chrony

systemctl enable chronyd

systemctl start chronyd

б) на системе Ubuntu / Debian:

apt-get install chrony

systemctl enable chrony

systemctl start chrony

Брандмауэр

Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.

а) с помощью firewalld:

firewall-cmd --permanent --add-port=514/

б) с помощью iptables:

iptables -A INPUT -p tcp --dport 514 -j ACCEPT

iptables -A INPUT -p udp --dport 514 -j ACCEPT

в) с помощью ufw:

ufw allow 514/tcp

ufw allow 514/udp

SELinux

Проверяем, работает ли в нашей системе SELinux:

Если мы получаем в ответ:

. необходимо либо настроить SELinux:

semanage port -m -t syslogd_port_t -p tcp 514

semanage port -m -t syslogd_port_t -p udp 514

. либо отключить его командами:

Установка и запуск rsyslog

Установить rsyslog необходимо как на сервер, так и клиентские компьютеры. В зависимости от операционной системы сама установка будет выполняться одной из команд.

а) для систем на базе RPM (Red Hat / CentOS):

yum install rsyslog

б) для систем на базе deb (Debian / Ubuntu):

apt-get install rsyslog

После установки разрешаем автозапуск службы и стартуем ее:

systemctl enable rsyslog

systemctl start rsyslog

Настройка сервера

Открываем конфигурационный файл:

Снимаем комментарии со следующих строк:

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

* в данном примере мы разрешили запуск сервера для соединений TCP и UDP на портах 514. На самом деле, можно оставить только один протокол, например, более безопасный и медленный TCP.

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

$template RemoteLogs,"/var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
&

* в данном примере мы создаем шаблон с названием RemoteLogs, который принимает логи всех категорий, любого уровня (про категории и уровни читайте ниже); логи, полученный по данному шаблону будут сохраняться в каталоге по маске /var/log/rsyslog/<имя компьютера, откуда пришел лог>/<приложение, чей лог пришел>.log; конструкция &

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

Перезапускаем службу логов:

systemctl restart rsyslog

Настройка клиента

Устанавливаем и запускаем rsyslog по инструкции, описанной выше. После приступаем к настройке клиента.

Все логи

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

* где 192.168.0.15 — IP-адрес сервера логов. *.* — перенаправлять любой лог.

systemctl restart rsyslog

Для определенных категорий

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

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные категории для логов (facility):

Для определенного уровня

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные уровни логов:

Возможные категории для логов (severity):

Аудит определенного лог-файла

Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.

Настройка клиента

Создаем новый конфигурационный файл:

$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

* в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.

Перезапускаем сервис на клиенте:

systemctl restart rsyslog

Создаем новый шаблон для захвата логов:

$template HostAudit, "/var/log/rsyslog/%HOSTNAME%/audit.log"
local6.* ?HostAudit

* в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/<имя компьютера, откуда пришел лог>/audit.log.

systemctl restart rsyslog

Лог определенного приложения

Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):

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

.
access_log syslog:server=192.168.0.15:514 info;
error_log syslog:server=192.168.0.15:514 warn;
error_log /var/log/nginx/error.log warn;
.

* в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.

Проверяем корректность конфигурационного файла nginx:

systemctl restart nginx

Чтение логов на сервере

В нашем примере сервер настроен на хранение логов по маске /var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log. Это значит, что в каталоге /var/log/rsyslog должны появляться папки с именами компьютеров, которые отправляют на сервер свои логи. Посмотреть список данных папок можно командой:

Чтение логов выполняется обычной командой cat или tail, например:

* здесь мы прочитаем лог для cron на компьютере comp1.

Читайте также: