Как настроить rsyslog

Настройка rsyslog для хранения логов на удаленном сервере

Опубликовано: 19.07.2019

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

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

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

Установка и запуск 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):

№	Категория	Описание
0	kern	Сообщения, отправляемые ядром
1	user	Пользовательские программы
2	mail	Почта
3	daemon	Сервисы (демоны)
4	auth	Безопасность/вход в систему/аутентификация
5	syslog	Сообщения от syslog
6	lpr	Логи печати
7	news	Новостные группы (usenet)
8	uucp	Unix-to-Unix CoPy (копирование файлов между компьютерами)
9	cron	Планировщик заданий
10	authpriv	Безопасность/вход в систему/аутентификация — защищенный режим
11	ftp	Логи при передачи данных по FTP
12	ntp	Лог службы синхронизации времени (существует не везде)
13	security, log audit	Журнал аудита (существует не везде)
14	console, log alert	Сообщения, отправляемые в консоль (существует не везде)
15	solaris-cron, clock daemon	Cron в solaris (существует не везде)
16-23	local0 — local7	Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7.

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

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

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

systemctl restart rsyslog

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

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

№	Уровень	Расшифровка
0	emerg	Система не работает (PANIC)
1	alert	Серьезная проблема, требующая внимания
2	crit	Критическая ошибка
3	err	Ошибка (ERROR)
4	warning	Предупреждение (WARN)
5	notice	Важное информационное сообщение
6	info	Информационное сообщение
7	debug	Отладочная информация

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

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

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

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

$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

Настройка сервера (фильтрация сообщений)

На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл 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.

Rsyslog — сервис управления логами

Rsyslog — это очень быстрый, расширяемый сервис для управления логами с огромным количеством возможностей. Среди его возможностей можно отметить поддержку фильтрации контента, а также передачу логов по сетям. Основные возможности:

• Многопоточность;
• TCP, SSL, TLS, RELP;
• Поддержка MySQL, PostgreSQL, Oracle;
• Фильтрация журналов;
• Полностью настраиваемый формат вывода.

На нашем Youtube-канале вы можете подробнее ознакомиться с работой сервиса управления логами Rsyslog, просмотрев видео Rsyslog — сервис управления логами, а также найти много другой полезной информации.

Каталогом по умолчанию для хранения логов является каталог /var/log, в файлы которого записывается вся информация о состоянии системы и используемых программ, а также информация об ошибках. Лог-файлы можно просмотреть, выполнив команду:

ls -l /var/log/

Содержимое конфигурационного файла rsyslog.conf

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

nano /etc/rsyslog.conf

Файл разделен на 3 основных секции:

• Modules — содержит параметры, предназначенные для настройки методов работы сервиса с лог-сообщениями;
• Global derectives — содержит глобальные параметры работы службы rsyslog;
• Rules — содержит правила сортировки логов.

Секция Modules

В секции Modules загружаются все необходимые модули программы. Секция имеет следующим вид:

module(load=»imuxsock» # provides support for local system logging (e.g. via logger command)
SysSock.Use=»off») # Turn off message reception via local log socket;
# local messages are retrieved through imjournal now.
module(load=»imjournal» # provides access to the systemd journal
StateFile=»imjournal.state») # File to store the position in the journal
#module(load=»imklog») # reads kernel messages (the same are read from journald)
#module(load»immark») # provides —MARK— message capability

# Provides UDP syslog reception
# for parameters see http://www.rsyslog.com/doc/imudp.html
#module(load=»imudp») # needs to be done just once
#input(type=»imudp» port=»514″)

# Provides TCP syslog reception
# for parameters see http://www.rsyslog.com/doc/imtcp.html
#module(load=»imtcp») # needs to be done just once
#input(type=»imtcp» port=»514″)

Существует четыре типа модулей:

• Модули ввода — можно рассматривать, как способ сбора информации из различных источников, начинаются с im;
• Модули вывода — позволяют отправлять сообщения в файлы, по сети или в базу данных, начинаются с om;
• Модули фильтрации — позволяют отфильтровывать сообщения по разным параметрам, начинаются с fm;
• Модули парсинга — предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Модуль imuxsock позволяет сервису получать сообщения от приложений, работающих в локальной системе. По умолчанию отключено прослушивание сокета /dev/log из-за параметра SysSock.Use=»off» .

Модуль imjournal предоставляет возможность импорта сообщений структурированного журнала из журнала systemd в системный журнал. Обратите внимание, что этот модуль читает базу данных журнала, что считается относительно интенсивной операцией. Таким образом, производительность конфигурации с использованием этого модуля может быть заметно ниже, чем при использовании imuxsock. По умолчанию ограничение скорости активировано и позволяет обрабатывать 20 000 сообщений в течение 10 минут, чего должно быть достаточно для большинства случаев использования. Если импорт структурированных данных необходим, используйте imjournal, в противном случае следует задействовать модуль imuxsock.

Модуль imklog предназначен для получения сообщений ядра.

Модуль mark позволяет маркировать соединения или выводить сообщения о том, что syslog все еще работает.

Секция Global directives

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

Секция Global directives имеет следующий вид:

# Where to place auxiliary files
global(workDirectory=»/var/lib/rsyslog»)

# Use default timestamp format
module(load=»builtin:omfile» Template=»RSYSLOG_TraditionalFileFormat»)

# Include all config files in /etc/rsyslog.d/
include(file=»/etc/rsyslog.d/*.conf» mode=»optional»)

• global(workDirectory=»/var/lib/rsyslog») — задает директорию, которая будет использоваться для рабочих файлов службы rsyslog;
• module(load=»builtin:omfile» Template=»RSYSLOG_TraditionalFileFormat») — задает стандартный формат хранения времени, в секундах с 1970 года;
• include(file=»/etc/rsyslog.d/*.conf» mode=»optional») — задает директорию, которая будет использоваться для дополнительных файлов конфигурации.

Секция Rules

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

Содержимое секции имеет следующий вид:

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* -/var/log/maillog

# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg :omusrmsg:*
# Save news errors of level crit and higher in a special file.

# Save boot messages also to boot.log
local7.* /var/log/boot.log

Источниками являются места, откуда поступают сообщения.

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

• auth — все, что связано с авторизацией пользователей, например, login и su (безопасность/права доступа);
• authpriv — то же самое, что и auth, однако сообщения этой категории записываются в файл, который могут читать лишь некоторые пользователи (категория выделена, потому что принадлежащие ей сообщения могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и, следовательно, файлы протоколов должны иметь соответствующие права доступа);
• cron — сообщения от системного планировщика;
• daemon — сообщения от системных служб, которые в отличие от FTP или LPR не имеют специально-выделенных категорий;
• kern — сообщения ядра;
• lpr — сообщения от системы печати;
• mail — сообщения от почтовой системы;
• mark — присваивается отдельным сообщениям, формируемым службой syslog;
• security — эквивалентно auth;
• syslog — система протоколирования может протоколировать сообщения от самой себя;
• uucp — копирование файлов между компьютерами (Unix-to-Unix CoPy);
• user — сообщения пользовательских программ;
• local0 … local7 — зарезервированные категории для использования администратором системы. Категория local7 обычно используется для сообщений, генерируемых на этапе загрузки системы;
• * — Выбор всех источников.

Приоритетом является степень важности сообщения.

Приоритеты могут принимать следующие значения:

• emerg (раньше panic) — чрезвычайная ситуация, система неработоспособна;
• alert — тревога, требуется немедленное вмешательство;
• crit — критическая ошибка (критическое состояние);
• error (раньше err) — сообщение об ошибке;
• warn (раньше warning) — предупреждение;
• notice — информация о каком-либо нормальном, но важном событии;
• info — информационное сообщение;
• debug — сообщения, формируемые в процессе отладки;
• * — выбор всех приоритетов;
• none — сообщения от источника с любым приоритетом будут исключены для действия.

Действием является отправка сообщений, которые подходят под заданные ранее параметры в заданное место.

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

• /путь/к/файлу — отправка сообщений в обычный файл;
• /dev/console — отправка сообщений в терминал или консоль;
• @xx.xx.xx.xx:514 — отправка сообщений на удаленную машину с помощью UDP;
• @@xx.xx.xx.xx:514 — отправка сообщений на удаленную машину с помощью TCP;
• user,user2,root — отправка сообщений пользователям на терминал (разделенный запятыми список пользователей, получающих сообщения).

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

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

В качестве примера разберем правило:

Первым источником событий являются все сообщения с приоритетом info. Также к источникам добавляются и другие сообщения, разделенные между собой точкой с запятой. Из правил следует, что источники mail, authpriv, cron будут исключены, так как имеют приоритет none. Действием для данного правила является отправка сообщений в файл /var/log/messages.

Другие варианты написания правил

Фильтрация на основе свойств сообщения

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

Переменные могут принимать значение:

• msg — тело сообщения;
• hostname — имя хоста/IP-адреса из сообщения;
• fromhost — имя хоста, от которого пришло сообщение;
• fromhost-ip — адрес хоста, от которого пришло сообщение (127.0.0.1 для локальных сообщений);
• syslogtag — имя и номер процесса ( «rsyslogd[12125]:» ), который выдал сообщение (извлекается из сообщения);
• programname — имя процесса, который выдал сообщение (извлекается из сообщения);
• pri — источник и приоритет, в виде числа;
• pri-text — декодированные источник и приоритет ( facility.priority , например syslog.emer );
• syslogfacility — только источник в виде числа;
• syslogfacility-text — только декодированный источник (» local0 «);
• syslogseverity — только приоритет в виде числа;
• syslogseverity-text — только декодированный уровень (» debug «);
• timegenerated — время получения (с высоким разрешением);
• timereported — время, извлечённое из сообщения;
• inputname — имя входного модуля;
• $hour, $minute — текущее время;
• $myhostname — имя хоста обработки.

Операция сравнения может принимать значение:

• contains — проверяет соответствие с любой частью строки в переменная;
• isequal — проверяет, совпадает (целиком) ли с переменной;
• isempty — проверяет, является ли переменная пустой;
• startswith — проверяет, начинается ли переменная с ;
• regex — сравнивает поле с регулярным выражением.

Искомое значение может принимать значение имени программы, службы или источника (источники были рассмотрены ранее в данной статье).

Действие принимает значения, рассмотренные ранее в статье.

Теперь можно составить правило для логирования приложения. Пример составления правила:

:syslogtag, isequal, «wireguard:» /var/log/wireguard.log
&stop

& stop необходим для того, чтобы остановить регистрацию сообщения после его совпадения.

Фильтрация RainerScript

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

Операция сравнения может принимать значения:

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

if $syslogtag == «wireguard» then /var/log/wireguard.log

Отправка лог-сообщений на удаленный сервер

Настройка сервера, который будет принимать лог-сообщения

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

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

Затем настройте SELinux, если он используется:

semanage port -m -t syslogd_port_t -p tcp 514 semanage port -m -t syslogd_port_t -p udp 514

Для разрешения серверу принимать соединение по TCP и UDP в конфигурационном файле /etc/rsyslog.conf раскомментируйте строки в секции Modules:

module(load=»imudp») # needs to be done just once
input(type=»imudp» port=»514″)

module(load=»imtcp») # needs to be done just once
input(type=»imtcp» port=»514″)

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

В эту же секцию после модулей для TCP- и UDP-соединения необходимо добавить следующее:

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

Таким образом создается шаблон, по которому лог-сообщения от любого источника с любым уровнем будут сохраняться в каталог сервера /var/log/rsyslog//.log.

После проделанных настроек необходимо перезагрузить службу rsyslog командой:

systemctl restart rsyslog.service

Настройка сервера на этом закончена. Для проверки открытия порта выполните команду:

netstat -pnltu

Настройка клиента, который будет отправлять лог-сообщения

Для создания правила на клиенте воспользуйтесь директорией rsyslog.d, которая является дополнительной для конфигурационных файлов.

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

nano /etc/rsyslog.d/auth.conf

И добавьте правило:

где @@xx.xx.xx.xx:514 — адрес сервера и его порт для протокола TCP. Для протокола UDP нужно указывать действие в виде @xx.xx.xx.xx:514.

Сохраните изменения и перезагрузите службу rsyslog командой:

systemctl restart rsyslog.service

При корректной настройке на сервере в каталоге /var/log/rsyslog должна появиться директория с именем (hostname) ПК, который отправляет лог-файлы, и, непосредственно, лог-файлы.

Дата последнего изменения: 19.06.2023

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

Настройка rsyslog для сбора логов по сети через шифрованное соединение

На Хабре есть несколько статей по rsyslog, но не нашлось ни одной, описывающей, как настроить взаимодействие клиента и сервера через защищенное соединение. Попробую исправить этот момент.

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

В качестве подопытных у нас выступают машинки с CentOS 6.7, тренироваться мы будем с rsyslog 7.x. rsyslog server (rslserver) у нас будет называться server.com, а rsyslog client (rslclient) — example.com.

Установка

Ставить rsyslog будем с их оффициального репозитория (http://www.rsyslog.com/rhelcentos-rpms/).

Сервер

wget http://rpms.adiscon.com/v7-stable/rsyslog.repo -O /etc/yum.repos.d/rsyslog.repo yum install gnutls-utils rsyslog rsyslog-gnutls mv /etc/rsyslog.conf.rpmnew /etc/rsyslog.conf #в случае если что-то правили до этого, надо будет перенести изменения service rsyslog restart less /var/log/messages #проверяем что rsyslog запустился без ошибок 

Клиент

wget http://rpms.adiscon.com/v7-stable/rsyslog.repo -O /etc/yum.repos.d/rsyslog.repo yum install rsyslog rsyslog-gnutls #gnutls-utils на клиенте не нужен mv /etc/rsyslog.conf.rpmnew /etc/rsyslog.conf #в случае если что-то правили до этого, надо будет перенести изменения service rsyslog restart less /var/log/messages #проверяем что rsyslog запустился без ошибок 

Настройка

Генерация сертификатов

Самая муторная часть. Нам необходимо сгенерировать пару ключей CA и по запросу+паре ключей для сервера и для каждого клиента. Все секьюрно. Для безопасности генерацию стоит делать не на сервере/клиенте, а на отдельной машине.

CA

Сердце нашей безопасности. Генерируем private key:

[root@sysadmin ~]# certtool --generate-privkey --outfile ca-key.pem Generating a 2048 bit RSA private key. 

Генерируем самоподписанный сертификат:

[root@sysadmin ~]# certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem Generating a self signed certificate. Please enter the details of the certificate's distinguished name. Just press enter to ignore a field. Country name (2 chars): RU Organization name: myorg Organizational unit name: Locality name: State or province name: Common name: cacert UID: This field should not be used in new certificates. E-mail: Enter the certificate's serial number in decimal (default: 1395159808): Activation/Expiration time. The certificate will expire in (days): 3650 Extensions. Does the certificate belong to an authority? (y/N): y Path length constraint (decimal, -1 for no constraint): Is this a TLS web client certificate? (y/N): Is this also a TLS web server certificate? (y/N): Enter the e-mail of the subject of the certificate: email@admin.com Will the certificate be used to sign other certificates? (y/N): y Will the certificate be used to sign CRLs? (y/N): Will the certificate be used to sign code? (y/N): Will the certificate be used to sign OCSP requests? (y/N): Will the certificate be used for time stamping? (y/N): Enter the URI of the CRL distribution point: X.509 Certificate Information: [. ] Is the above information ok? (Y/N): y Signing certificate. [root@sysadmin ~]# ls -l total 136 -rw------- 1 root root 1675 Mar 18 11:12 ca-key.pem -rw-r--r-- 1 root root 1318 Mar 18 12:24 ca.pem [root@sysadmin ~]# 

Не забываем что с помощью ca-key.pem злоумышленник может запросто подменить сертификат на свой, поэтому хранить его нужно в безопасном месте.

Сервер

Генерируем private key для rsyslog сервера:

[root@sysadmin ~]# certtool --generate-privkey --outfile rslserver-key.pem --bits 2048 Generating a 2048 bit RSA private key. 

Генерируем certificate request. Rsyslog проверяет авторизацию по полю сертификата X509/name, так что в сommon name лучше указывать FQDN хоста.

[root@sysadmin ~]# certtool --generate-request --load-privkey rslserver-key.pem --outfile request.pem Generating a PKCS #10 certificate request. Country name (2 chars): RU Organization name: myorg Organizational unit name: Locality name: State or province name: Common name: server.com UID: Enter a dnsName of the subject of the certificate: server.com Enter a dnsName of the subject of the certificate: Enter the IP address of the subject of the certificate: Enter the e-mail of the subject of the certificate: Enter a challenge password: Does the certificate belong to an authority? (y/N): n Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): Will the certificate be used for encryption (RSA ciphersuites)? (y/N): Is this a TLS web client certificate? (y/N): y Is this also a TLS web server certificate? (y/N): y 

Генерируем сертификат из request’а.

[root@sysadmin ~]# certtool --generate-certificate --load-request request.pem --outfile rslserver-cert.pem --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem Generating a signed certificate. Enter the certificate's serial number in decimal (default: 1395162401): Activation/Expiration time. The certificate will expire in (days): 3650 Extensions. Do you want to honour the extensions from the request? (y/N): Does the certificate belong to an authority? (y/N): n Is this a TLS web client certificate? (y/N): y Is this also a TLS web server certificate? (y/N): y Enter a dnsName of the subject of the certificate: server.com Enter a dnsName of the subject of the certificate: Enter the IP address of the subject of the certificate: Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (y/N): Will the certificate be used for encryption (RSA ciphersuites)? (y/N): X.509 Certificate Information: [. ] Is the above information ok? (Y/N): y Signing certificate. [root@sysadmin ~]# rm -f request.pem 

Теоретически, можно использовать wildcards в common name и dns name, генерируя один сертификат сразу для нескольких хостов, но лучше этого не делать. После генерации сертификата request можно удалить.

Клиент

Для клиента все шаги те же, что и для сервера: генерируем ключ, затем запрос, затем сертификат. Естественно, имена файлов нужно заменить с rslserver на rslclient, а common name/dns name — с server.com на example.com.

Копируем файлы

Пакет для CentOS создает директорию /etc/pki/rsyslog/, которой грех не воспользоваться. Копируем на сервер файлы ca.pem, rslserver-cert.pem, rslserver-key.pem, а на клиента файлы ca.pem, rslclient-cert.pem, rslclient-key.pem.

Получаем что-то вроде:

[root@server.com]# ls -l1 /etc/pki/rsyslog/ -rw-r--r-- 1 root root 1172 Feb 8 20:19 ca.pem -rw-r--r-- 1 root root 1294 Feb 8 21:13 rslserver-cert.pem -rw-r--r-- 1 root root 1675 Feb 8 21:11 rslserver-key.pem [root@example.com]# ls -l1 /etc/pki/rsyslog/ -rw-r--r-- 1 root root 1172 Feb 8 20:21 ca.pem -rw-r--r-- 1 root root 1273 Feb 8 20:21 rslclient-cert.pem -rw------- 1 root root 1675 Feb 8 20:21 rslclient-key.pem 

Конфиги

Сервер

Добавляем в начало /etc/rsyslog.conf, сразу после загрузки модулей imuxsock и imklog:

################### REMOTE LOGGING BEGIN ######################### # Increase the amount of open files rsyslog is allowed, which includes open tcp sockets # This is important if there are many clients. # http://www.rsyslog.com/doc/rsconf1_maxopenfiles.html $MaxOpenFiles 2048 # make gtls driver the default $DefaultNetstreamDriver gtls # certificate files generated on RHEL6 and stored in /root $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslserver-cert.pem $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslserver-key.pem # Provides TCP syslog reception # for parameters see http://www.rsyslog.com/doc/imtcp.html module(load="imtcp" MaxSessions="2000" StreamDriver.mode="1" StreamDriver.authmode="x509/name" PermittedPeer="example.com" ) input(type="imtcp" port="10514" name="tcp-tls") ################### REMOTE LOGGING END ######################### 

Из названий директив вроде все понятно: увеличиваем лимит открытых файлов, указываем что поток идет через TLS, показываем на ключи для его расшифровки, а затем передаем поток в модуль imtcp, который проверяет авторизацию по полю x509/name, сравнивая с разрешенным пиром.

Если мы хотим складывать логи с каждого клиента в отдельный файл, то в конце /etc/rsyslog.conf (или в каком-то из файлов в /etc/rsyslog.d) нам надо указать rsyslog соответствующие параметры:

# This one is the template to generate the log filename dynamically, depending on the client's hostname. $template FileForRemote,"/var/log/remote/%fromhost%/syslog.log" if ($inputname contains "tcp-tls") then

Тут все просто. Сначала мы задаем динамический шаблон имени файла, и затем записываем в эти файлы все, что приходит из «tcp-tls» (имя задано выше в input). После того как мы создали запись, мы прекращаем обработку данного сообщения (директива stop), чтобы она не попала в «общий котел».

Клиент

На клиенте все еще проще. В файле /etc/rsyslog.d/tls.conf указываем, что сетевой поток надо гнать через TLS с такими-то сертификатами, проверяя x509/name на соответствие заданному. Последняя строчка указывает, что по сети, через протокол TCP (@@) на адрес server.com мы шлем только записи от ядра (kern).

# make gtls driver the default $DefaultNetstreamDriver gtls # certificate files $DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem $DefaultNetstreamDriverCertFile /etc/pki/rsyslog/rslreverb-cert.pem $DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/rslreverb-key.pem #### GLOBAL DIRECTIVES #### # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # gtls Network Stream Driver # x509/name - certificate validation and subject name authentication # http://www.rsyslog.com/doc/ns_gtls.html $ActionSendStreamDriverAuthMode x509/name $ActionSendStreamDriverPermittedPeer server.com $ActionSendStreamDriverMode 1 # run driver in TLS-only mode kern.* @@server.com:10514 

Собственно и все. Не забудьте открыть порты на фаерволе и перезапустить rsyslog на сервере и клиенте. В подготовке руководства использовалась официальная документация rsyslog и запись из блога Kristian Reese.

• Системное администрирование
• *nix

Настройка Rsyslog в Linux

Когда в системе происходит та или иная ошибка, нужно выяснить почему она произошла, исправить её и попытаться сделать так, чтобы такой ошибки больше не было. В этом системным администраторам очень сильно помогает логирование всех ошибок. Например, общие сообщения ядра и программ сохраняются в /var/log/messages.

Но рано или поздно файлы логов становятся слишком большими, они занимают все место на диске и это приводит к новым ошибкам. Поэтому важно контролировать, как и куда сохраняются файлы журналов. На протяжении многих лет в операционной системе Linux используется сервис Syslog для управления логами. В современных версиях применяется его модификация — rsyslog.

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

Что такое Rsyslog?

Развитие rsyslog началось в 2004 году, в качестве форка используемого тогда сервиса Syslog. Программа очень быстро набрала популярность среди пользователей и сейчас она поставляется по умолчанию во многих дистрибутивах Linux.

Rsyslog — это очень быстрый, расширяемый сервис для управления логами с огромным количеством возможностей. Среди его возможностей можно отметить поддержку фильтрации контента, а также передачу логов по сетям. Разработчики утверждают, что система очень быстрая, программа может обрабатывать до миллиона сообщений в секунду.

Вот основные возможности:

• Многопоточность;
• TCP, SSL, TLS, RELP;
• Поддержка MySQL, PostgreSQL, Oracle;
• Фильтрация журналов;
• Полностью настраиваемый формат вывода.

Как происходит логирование?

Все программы Linux ведут лог путем отправки сообщений об ошибках или своем состоянии с помощью сокета syslog или просто записывая все сообщения в файл, который будет находиться в каталоге /var/log/.

Но важное значение имеет уровень подробности логирования. Вы можете настраивать подробность в каждой отдельной программе, или же с помощью syslog. Это поможет уменьшить использование дискового пространства, на хранение логов. Но тут нужно найти компромисс между количеством информации и использованием диска.

Например, ядро Linux определяет такие уровни логов, или как мы будем называть их ниже — приоритеты:

• KERN_EMERG — система неработоспособна;
• KERN_ALERT — нужно немедленно принять меры;
• KERN_CRIT — критическая ошибка;
• KERN_ERR — обычная ошибка;
• KERN_WARNING — предупреждение;
• KERN_NOTICE — замечание;
• KERN_INFO — информационное сообщение;
• KERN_DEBUG — сообщения отладки.

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

Настройка Rsyslog в Linux

Все настройки Rsyslog находятся в файле /etc/rsyslog.conf и других конфигурационных файлах из /etc/rsyslog.d/. Вы можете посмотреть существуют ли у вас эти файлы выполнив:

Основной конфигурационный файл — /etc/rsyslog.conf, в нем подключены все файлы из папки /etc/rsyslog.d/ с помощью директивы IncludeConfig в самом начале файла:

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

Синтаксис конфигурационного файла очень прост:

$ переменная значение

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

ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support
#$ModLoad immark # provides —MARK— message capability

# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514

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

• Модули ввода — можно рассматривать, как способ сбора информации из различных источников, начинаются с im.
• Модули вывода — позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;
• Модули фильтрации — позволяют фильтровать сообщения по разным параметрам, начинаются с fm;
• Модули парсинга — предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокетов, а второй imklog получает сообщения ядра. Следующим загружается модуль mark, который позволяет маркировать соединения, или же выводить сообщения о том, что syslog все еще работает. Например, вы можете попросить rsyslog выводить сообщения каждые 20 минут:

Дальше идут глобальные директивы:

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

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

FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

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

Выше была более общая настройка syslog, ну а теперь самое интересное — правила сортировки логов. Вот набор правил по умолчанию:

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, мы можем отправить больше сообщений в лог системы linux /var/messages:

В этой строке мы выбираем все сообщения уровня info, кроме mail,authpriv и cron. Шаблон mail.none будет означать, что не нужно логировать ни один уровень сообщений. Соответственно конструкция *.info — значит логировать сообщения от всех источников, но только с уровнем info, *.* — это вообще все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также заметьте, что приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими. В целом, в качестве источников вы можете использовать:

• auth;
• authpriv;
• cron;
• daemon;
• kern;
• lpr;
• mail;
• mark;
• news;
• security (эквивалентно auth);
• syslog;
• user;
• uucp;
• local0 . local7;

А в качестве приоритетов вы можете применить:

• emerg (раньше panic);
• alert;
• crit;
• error (раньше err);
• warn (раньше warning);
• notice;
• info;
• debug;

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

Вы можете выполнять фильтрацию сообщений с помощью такого синтаксиса:

: поле, сравнение, «значение» путь_к_файлу

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

• contains — поле содержит указанное значение;
• isequal — поле должно быть идентичным значению;
• startswith — поле должно начинаться со значения;
• regex — сравнивает поле с регулярным выражением.

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

:syslogtag, isequal, «giomanager:» /var/log/giomanager.log
& stop

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

if $поле сравнение ‘значение’ then файл

Здесь используются те же самые компоненты, только выглядит немного проще. Например:

if $syslogtag == ‘giomanager’ then /var/log/giomanager.log

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

Было бы очень удобно, если бы логи со всех серверов сети собирались на одной машине. Здесь бы были все важные сообщения об ошибках и неполадках. Вы могли бы все это очень быстро проанализировать. Отправить лог на удаленный сервер достаточно просто, для этого достаточно указать @ и ip адрес удаленной машины, на которой запущен rsyslog:

Здесь 514 — это порт, на котором слушает rsyslog. Настройка rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp. Далее, все что нужно для того чтобы получить логи с определенной машины, отфильтровать их из общего потока с помощью фильтров:

if $fromhost-ip contains ‘192.168.1.10’ then /var/log/proxyserver.log

Без фильтров, сообщения с разных машин будут писаться в один общий лог системы linux в зависимости от того как вы их распределите.

Выводы

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

Обратите внимание, что при использовании rsyslog в качестве сетевого сервера для хранения логов место на диске будет очень быстро уменьшаться. Поэтому лучше применять в дополнение к программе такую утилиту, как Logrotate.

На завершение видео на английском про настройку Logrotate: