Security — Журналирование событий. Часть 2.2 - syslog-ng

В этой части рассматривается настройка демона syslog-ng.

Syslog-ng
Syslog-ng - syslog-сервер нового поколения (-ng = next-generation). Достаточно популярен, по-умолчанию входит во многие дистрибутивы, в том числе в Gentoo и Archlinux. Имеет две версии - opensource и платную - "Premium". Premium, по сравнению с opensource-версией, позволяет осуществлять цифровую подпись передаваемых сообщений, обеспечивать их буферизацию для надёжной доставки, а также работать на неправославных ОС. Само собой, для премиум-версии предлагается поддержка и возможность получить пакет для конкретной ОС, используемой на предприятии заказчика. Мы с вами будем говорить об opensource-версии, а о надёжной доставке и дополнительных возможностях syslog-серверов вообще поговорим в следующих статьях.

Конфигурационный файл вкорне отличается от конфигурационного файла sysklogd. (Ну ещё бы некст-ген всё таки - здесь вам не тут (с)). Конфиг делится на секции, общий вид такой:

<секция> <имя секции> { <параметр>; <<параметр>; ...> };

Здесь <секция> - это одно из указанных ниже значений:
source - источник сообщений
destination - действие для сообщений
filter - критерий сообщений
log - объединение source, destination и filter
options - опции

<имя секции> - это произвольная строка с именем, которое потом используется в других секциях

<параметр> - это специфичная для каждой секии настройка, которая как правило задаётся в виде функции. Набор функций для каждой из секций свой. За полным описанием возможных параметров каждой секции отправляю вас к мануалу (ну или к man syslog-ng.conf).

Исходя из вышесказанного, syslog-ng позволяет вам задавать некие объекты, действия и критерии, а потом применять необходимые действия к этим объектам, исходя из указанных критериев. Возможно, вам будет проще настраивать "с конца", т.е. начинать не с задания source, filter и destination, а с log. Т.е. первым делом вписать в файл директивы log, снабдив названия источников/фильтров/действий (пока не существующих) такими именами, по которым легко определить их назначение. Уже после того, как вы создали log-секции, создать под них недостающие source/filter/destination. Не забудьте про опции.

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


# Зададим несколько источников сообщений
# Классический вариант - устройство, куда собственно и должны записывать сообщения программы
# Собственно, я стянул эту секцию из конфигурации по-умолчанию в Archlinux
source s_syslog {
unix-stream("/dev/log");
internal();
file("/proc/kmsg");
};

# Второй почти классический вариант - демон syslog на удалённом сервере, присылающий сообщения нашему демону.
# Кроме поддержки UDP, syslog-ng позволяет также отправлять собщения по простоколу TCP. Это более надёжно (хотя сообщения всё равно могут быть потеряны - в части 3 объясню, как), но забирает больше ресурсов. Подробнее обсудим это в 3-й части публикаций о syslog, здесь же просто покажем просто наличие такой фичи.

source s_tcp_client { tcp(ip("0.0.0.0") 514); }

#----------------------------------------
# Далее зададим несколько назначений для сообщений
# Разнообразные файлы
destination d_mail_log { file("/var/log/mail.log"); };
destination d_alert_log { file("/var/log/alert.log"); };
destination d_mail_alert_log { file("/var/log/mail_alerts.log"); };
destination d_ssh_debug_log { file("/var/log/ssh_debug.log"); };

# Некий пайп - по сути, файл. Поэтому параметр выглядит также
destination d_some_pipe { file("/var/log/pipe.fifo"); };

# Консоли, где залогинены root и Вася Пупкин
destination d_consoles { usertty root; usertty vpupkin; };

# Удалённый сервер безопасности
destination d_security_srv { udp("security" 514); };

#----------------------------------------
# И, наконец, самое интересное - зададим критерии для фильтрации
# Аналог mail.*
filter f_all_mail { facility("mail"); };

# Аналог auth,authpriv.*
filter f_auth { facility(auth,authpriv)};

# Аналог *.alert
filter f_alerts { level(alert,emerg)};

# Аналог kern,daemon.=debug
# Syslog-ng позволяет также осуществлять фильтрацию по имени пограммы-откравителя. Здесь в качестве примера мы будем получать отладочные сообщения только от демона sshd
# Обратите также внимание, что программа задаётся в фильтрах, а не в источниках!
filter f_ssh_debug { level(kern,daemon) and facility(debug) and program("sshd"); };

#----------------------------------------
# После того, как мы определили все объекты, объединим их правилами, указав, что и куда нужно записывать или отправлять
# Писать любые сообщения почтовой подсистемы в /var/log/mail.log
log {source(s_syslog); filter(f_all_mail); destination(d_mail_log);};

# Писать все критические сообщения (alert и emerg) в файл /var/log/alert.log
log {source(s_syslog); filter(f_alerts); destination(d_alert_log);};

# Писать отладочную информацию ssh в /var/log/ssh_debug.log
log {source(s_syslog); filter(f_ssh_debug); destination(d_ssh_debug_log);};

# Фильтров может быть несколько. В этом случае условия фильтров объединяются по "И"
# Писать все критические сообщения от почтовой подсистемы в файл /var/log/mail_alerts.log
log {source(s_syslog); filter(f_all_mail); filter(f_alerts); destination(d_mail_alerts_log); };

# Отправлять информацию об аутентификации на сервер безопасности
log {source(s_syslog); filter(f_auth); destination(d_security_srv); };
# Отправлять информацию об аутентификации на удалённом сервере на сервер безопасности
log {source(s_tcp_client); filter(f_auth); destination(d_security_srv); };

# Оповещать рута и Васю Пупкина о важных событиях на локальной машине
log { source(s_syslog); filter(f_sys_debug); destination(d_consoles); }

Запись в БД MySQL и шифрование сообщений

Сомневаюсь, что syslog-ng, включённый в ваш дистрибутив, имеет возможность записи в sql-БД или поддерживает SSL. Поэтому для включения этих возможностей придётся или поставить дополнительные пакеты или, скорее всего пересобрать пакет под себя самостоятельно. Для шифрования вам будет нужен пакет openssl (libssl-dev для Debian-like дисрибутивов), для поддержки MySQL - libdbi и mysql-драйвер для этой библиотеки (для Debian это пакеты libdbi0, libdbi0-dev, libdbd-mysql, в Archlinux придётся ставить пакеты из AUR)
Само собой вам будет нужна версия из ветки 3.x, предыдущие ветки не поддерживают sql вообще.
Варнинг: Сам я этого делать не пробовал, но процесс себе представляю. Здесь я больше даю направление, куда копать, нежели пошаговые инструкции. Так что если где немножко ошибся, больно не бейте.

После того, как вам всё таки удалось собрать нужную версию, достаточно только задать соответствующий destination:
Для SSL-шифрования (сертификаты, само собой, придётся предварительно сгенерировать):
destination d_tls_client {
tcp("security" port(10514)
tls( ca_dir("/opt/syslog-ng/etc/syslog-ng/ca.d")) );
};

Совет: Перед тем, как мучить свой сервер шифрованием хорошенько обдумайте, так ли оно вам нужно. Учтите, вероятность отказа с ним только увеличивается.

Для MySQL (спёр отсюда и прокомментировал):

destination d_mysql {
sql(type(mysql)
# Стандартный набор параметров доступа к БД - хост, логин, пароль
host("localhost") username("syslog") password("syslog")
database("syslog")
table("logs")
# Столбцы БД, в которые вы планируете записывать сообщения
columns("host", "facility", "priority", "level", "tag", "datetime", "program", "msg", "seq")
# Какую часть сообщения в какой столбец записывать
values("$HOST_FROM", "$FACILITY", "$PRIORITY", "$LEVEL", "$TAG", "$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC", "$PROGRAM", "$MSG", "$SEQNUM")
# Для каких столбцов создавать индексы для быстрого поиска
indexes("host", "facility", "priority", "datetime", "program", "seq"));
};

Само собой разумеется, что вы создали БД с нужной структурой и дали пользователю права на запись в таблицу. Тем, кто будет делать, советую следовать принципу минимальных привилегий и создать 2 пользователей syslog_logger и syslog_reader. Пользователю syslog_logger вы даёте права только на INSERT, ему этого должно быть достаточно. Пользователя syslog_reader вы можете использовать для чтения сообщений из БД, его права соответственно только на SELECT. Все остальные действия(периодическая чистка, создание индексов) лучше производить от рута(если делаете вручную) или создать третьего пользователя с соответствующими правами(если автоматизируете).
Обратите внимание на очень интересную особенность. Вы можете создать БД с произвольной структурой, прописав в конфиге используемые столбцы и значения для подстановки в эти столбцы.

Достаточно многие вещи, которые умеет делать syslog-ng не упомянуты в этой статье: это макросы, шаблоны сообщений, поддержка RFC5424, изменение сообщений, сравнение с regexp, некоторые другие. Новичкам это всё понадобится врядли, а опытные пользователи вполне могут прочитать документацию, которая очень и очень неплоха.

Следующий претендент на рассмотрение - самый интересный и фичебогатый. Это Rsyslog, но о нём вы узнаете не раньше понедельника.