В первом разделе дана инструкция по настройке сигнализации с нуля. Процедура миграции на новую версию изложена во втором разделе.
Установите пакеты icinga2, icinga2-doc, icingaweb2,
icingaweb2-php-mysql либо icingaweb2-php-pgsql (в зависимости
от используемой СУБД), icingaweb2-nginx, icingaweb2-php-fpm,
icingaweb2-cli, icinga2-ido-mysql либо icinga2-ido-pgsql
(также в зависимости от используемой СУБД). При желании управлять
конфигурацией наблюдений посредством web-интерфейса,
установите также пакет icingaweb2-module-director. Если на
наблюдаемых узлах будет использоваться сценарий пост-обработки
событий 10-push-icinga, то рекомендуется установить и настроить
службу автоматической синхронизации пользователей Icinga 2 REST API
из пакета icinga2-usersyncd.
Включите и запустите СУБД.
Выполните настройку Icinga 2 IDO как написано в разделах
“Set up MySQL database” и “Enable the IDO MySQL feature”
файла /usr/share/doc/icinga2/markdown/14-features.md
(“Set up PostgreSQL database” и “Enable the IDO PostgreSQL”
соответственно, если вы используете СУБД PostgreSQL).
Затем выполните первоначальную настройку зоны мониторинга и её
ведущего узла (master node) как написано в файле
/usr/share/doc/icinga2/markdown/06-distributed-monitoring.md.
Эта процедура также включается в себя настройку Icinga 2 REST API.
Включите и запустите системную службу icinga2.service.
После этого можно переходить к настройке Icinga Web 2 —
web-интерфейса панели наблюдения Icinga 2. Для этого, прежде всего,
настройте и включите соответствующий раздел на веб-сервере Nginx,
конфигурационный файл для которого называется icingaweb2.conf.
Дальнейшие действия по настройке Icinga Web 2 нужно выполнять с
рабочего места администратора безопасности (см. ниже).
Если для настройки наблюдаемых узлов вы планируете использовать
Icinga Director, выполните настройку БД как написано в файле
/usr/share/icingaweb2/modules/director/doc/02-Installation.md.
Под рабочим местом администратора безопасности подразумевается web-интерфейс Icinga Web 2. Мастер первоначальной настройки будет предложен после перехода по адресу http://localhost:81/icingaweb2/ (URL может быть иным в зависимости от тех изменений, которые вы сделали при настройке Nginx). Следуя шагам мастера, введите параметры доступа к Icinga 2 и СУБД.
Для того, чтобы сценарий 10-push-icinga (см. ниже) мог нормально
передавать данные с наблюдаемых узлов, необходимо обеспечить доступ
с соответствующими правами к Icinga 2 REST API. В целях обеспечения
безопасности имеет смысл предоставлять такие права отдельно для
каждого наблюдаемого узла, ограничивая сферу возможных действий
данными, относящимися к этому узлу. Для этой цели удобно изпользовать
службу автоматической синхронизации пользователей Icinga 2 REST API,
которая называется icinga2-usersyncd. Подробнее см. документацию
к этому пакету.
Если для настройки объектов наблюдения используется Icinga Director,
то готовую корзину (basket) шаблонов в формате JSON для наблюдения
за событиями Nagwad можно найти в пакете nagwad-icinga-master.
Шаблон для добавления узла носит название d-nagwad-host.
Вместо того, чтобы добавлять конфигурацию каждого узла вручную,
можно возпользоваться функцией API самообслуживания Icinga Director.
Для этой цели написан скрипт icinga2-register-host
(пакет icinga2).
Также, в этом пакете определены шаблоны конфигурации, пригодные для определения объектов наблюдения в конфигурационных файлах Icinga.
Как один, так и другой вид шаблонов подготовлен для
отслеживания следующих событий, фиксируемых nagwad.service:
/etc/passwd и /etc/group;На основе этих шаблонов в конфигурации наблюдаемой зоны определяются
наблюдаемые узлы. Шаблон для добавления узла носит название
nagwad-host. Например:
# vim /etc/icinga2/zones.d/master/hosts.conf
object Host "comp-21" {
import "generic-host"
import "nagwad-host"
address = "192.168.56.21"
vars.agent_endpoint = name
}
object Host "comp-22" {
import "generic-host"
import "nagwad-host"
address = "192.168.56.22"
vars.agent_endpoint = name
}
Установите пакеты icinga2, nagwad-service, nagwad-audit и
nagwad-icinga-agent. После установки nagwad-service включите и
запустите службу nagwad.service.
Для того, чтобы иметь возможность отслеживать
нарушения целостности системных файлов, также потребуется
пакет integalert. После установки integalert, выполните
настройку наблюдаемых файлов и директорий, проинициализируйте
базу данных командой integalert fix, включите и запустите
службу integalert.service.
В том случае, если на сервере мониторинга установлено и настроено
дополнение Icinga Director, то для автоматической настройки узла
используйте сценарий icinga2-register-host.
Для ручной настройки наблюдаемого узла с агентом
мониторинга (agent/satellite setup), запустите команду
icinga2 node wizard как описано в
/usr/share/doc/icinga2/markdown/06-distributed-monitoring.md.
Поставляемый с пакетом nagwad фильтр событий печати
/etc/nagwad/print.regexp рассчитан на то, что служба печати cupsd
будет а) проверять права доступа при печати и б) записывать в журнал
сообщения об отказе по причине нехватки прав. Для этого cupsd
необходимо настроить следующим образом:
В конфигурационном файле /etc/cups/cups-files.conf установить:
AccessLog syslog
А в главном конфигурационном файле /etc/cups/cupsd.conf повысить
уровень сообщений о нарушении доступа с warn до info:
AccessLogLevel info
Затем в этом же файле лимитировать доступ к операциям печати, например, разрешив их конкретному пользователю:
<Limit Create-Job Print-Job Print-URI Validate-Job>
Require user имя-пользователя
Order deny,allow
</Limit>
Подробнее о написании политик доступа к печати см. https://www.cups.org/doc/policies.html.
Поскольку в новой версии Альт СП вместо Nagios используется система
мониторинга Icinga 2, автоматическая миграция не предусмотрена.
В то же время, Nagios и связанные с ним программы имеют возможность
работать параллельно с новыми средствами, связанными с Icinga.
В частности, сценарий проверки сигнальных файлов Nagwad
check_nagwad совместим как с Nagios, так и с Icinga.
Это позволяет организовать плавный переход с одной системы на другую.
Основные компоненты пакета “Nagwad”:
системная служба nagwad, которая сканирует системный журнал
с помощью набора фильтров /etc/nagwad/*.regexp, *.sed (либо простые
регулярные выражения для grep, либо полнофункциональные скрипты
sed);
сценарии пост-фильтрации событий в /etc/nagwad/filter-event.d;
сценарии пост-обработки событий в /etc/nagwad/process-event.d;
NRPE-скрипт check_nagwad, который проверяет файлы сигналов событий
в /var/log/nagwad/<boot_id>/<filter>/, где boot_id
это текущий системный идентификатор загрузки
(/proc/sys/kernel/random/boot_id);
служебный скрипт nagwad, который предоставляет интерфейс командной
строки для запроса, проверки сигнальных файлов событий и управления
ими (см. nagwad(8)).
Дополнения для различных систем мониторинга включают в себя следующие компоненты:
шаблоны конфигурации для агента мониторинга Icinga 2;
шаблоны конфигурации для агента мониторинга Nagios;
скрипты для интерфейса мониторинга Nagstamon;
оболочка оболочки nsca-shell с ведением журнала, которую
можно использовать для удаленного доступа.
Как только какой-либо из настроенных фильтров определяет сообщение из
системного журнала, “nagwad” генерирует событие, которое затем передается
сценариям в каталоге “filter-event.d”. Сценарии могут 1) дать ответный
сигнал “nagwad” о том, нужно ли пропустить или проигнорировать данное
событие, а так же 2) добавить произвольный текст к сообщению о событии.
Если событие не игнорируется, то соответствующий сигнальный файл
записывается в директорию /var/log/nagwad/<boot_id>/<filter>/.
Имя сигнального файла соответствует шаблону <filter>.<HASH>.<LEVEL>.
NRPE-совместимый агент мониторинга может проверить этот файл
с помощью сценария check_nagwad (шаблоны конфигурации для Icinga и
Nagios можно найти в соответствующих пакетах).
При проверке сигнальных файлов скрипт игнорирует файлы со специальным
суффиксом .FIXED. Это позволяет помечать зарегистрированные события как
разрешенные (либо с помощью команды nagwad fix (см. nagwad(8)),
либо просто переименованием файла).
В дополнение к этому, данные о каждом событии передаются в скрипты
в директории process-event.d.
Если для параметра MAXAGE в файле /etc/nagwad/nagwad.conf
установлено отличное от 0 значение, то при запуске nagwad удаляет
все директории /var/log/nagwad/*, возраст которых превышает
MAXAGE. Однако, в виду того, что интервалы округляются путём
усечения дробной части числа, директория с файлами будет удалена
только в том случае, если она старше MAXAGE + 1 дней.
Параметры конфигурации в файле /etc/nagwad/nagwad.conf предусмотрены
следующие:
PIDFILE — путь к PID-файлу, записываемому при запуске nagwad
запускается (значение по умолчанию — /run/nagwad.pid);
LOG_USER — имя системного пользователя, которому принадлежат
сигнальные файлы (значение по умолчанию — root);
LOG_GROUP — имя системной группы пользователей, имеющей доступ
на чтение для сигнальных файлов (по умолчанию nagwad);
CONFDIR — путь к директории конфигурации (по умолчанию
/etc/nagwad`);
POSTFILTERS — путь к директории для скриптов пост-фильтраци
(по умолчанию $CONFDIR/filter-event.d);
POSTPROCESS — путь к директории для скриптов пост-обработки
(по умолчанию $CONFDIR/process-event.d);
LOGDIR — путь к корневому каталогу журнала (по умолчанию
используется /var/log/nagwad);
MAXAGE — количество дней, по истечении которых старые сигнальные
файлы могут быть удалены (по умолчанию 30);
JOURNAL_TAIL — количество сообщений, которые считываются из
системного журнала при запуске и перезапуске nagwad (значение
по умолчанию равно 5000).
Предварительно настроенный скрипт фильтрации 10-eperm используется
для дополнительной фильтрации событий ошибочного доступа к файлам,
которые записывает в журнал подсистема аудита Linux, на основе фактических
путей к этим файлам. Он использует файлы .regexp из директории
filter-event.d/eperm-skip.d, для определения того, какие события
нужно пропустить. События, которые проходят пост-фильтр 10-eperm,
дополняются текстом: PATH=<путь>, где <путь> — это фактический
путь к файлу, в доступе к которому было отказано.
Специальный скрипт 10-push-icinga предназначен для отправки
зарегистрированных событий на сервер Icinga 2 через REST API. Одним из
преимуществ использования этого скрипта является то, что он может
снимать флаг подтверждения для события каждый раз, когда регистрируется
новое событие того же типа. Скрипт считывает свою конфигурацию из файла
process-event.d/push-icinga.conf и должен работать “из коробки” при
условии, если узел правильно настроен как агент/спутник Icinga 2
(скрипт использует SSL-сертификаты из директории
/var/lib/icinga2/certs). Однако для использования Icinga 2 REST API
на сервере должен быть настроен ApiUser с соответствующим набором
прав. Для этой цели удобно использовать демон icinga2-usersyncd.
Начиная с версии 0.10.0 nagwad автоматически обрабатывает все
*.regexp и *.sed файлы в директории /etc/nagwad.
В файлах формата *.regexp определяются регулярные выражения для
отслеживания сообщений системного журнала. Файл может содержать
сразу несколько регулярных выражений — по одному выражению на
строке. Событие формируется если обнаруживается совпадение с любым
из определённых выражений. Базовое имя записываемого nagwad
сигнального файла определяется базовым именем файла с суффиксом
.regexp. Оно же определяет имя фильтра, которое используется для
проверки сигнального файла из Icinga 2 или Nagios.
Файлы формата *.sed являются полноценными сценариями,
предназначенными для программы sed (см. man sed(1) и info sed).
В отличие от простого набора регулярных выражений, использование
сценариев sed позволяет а) модифицировать сообщения системного
журнала и б) фиксировать различных уровень критичности события для
различных сообщений.
Программа sed запускается из nagwad с аргументом -n, что
позволяет использовать sed прежде всего как фильтр сообщений.
Каждое отфильтрованное сценарием сообщение системного журнала должно
после обработки принимать вид:
<имя_фильтра>:<ВАЖНОСТЬ>:<сообщение>
где имя_фильтра определяет базовое имя записываемого nagwad
сигнального файла. Например, подстановку вида
s//myevent:CRITICAL:&/p удобно использовать после предварительной
фильтрации сообщений системного журнала для того, чтобы транслировать
отфильтрованное сообщение без изменений как критическое событие,
которое будет записано в сигнальный файл в директории
/var/log/nagwad/<boot_id>/<filter>/. В Icinga 2 (а также и в
Nagios) это событие будет отражено как критичное.
При необходимости, вместо уровня CRITICAL можно использовать уровень
WARNING, отображающийся в Icinga и Nagios как предупреждение.
Другие уровни сообщений Icinga и Nagios не поддерживают.
Кроме фильтров для первичной обработки событий (то есть для их
фильтрации из системного журнала), начиная с версии 0.10.1 в nagwad
поддерживает дополнительные фильтры для первично отфильтрованных
событий. Сценарии фильтрации помещаются в директорию
/etc/nagwad/filter-event.d и выполняются для каждого события
в алфавитном порядке.
Каждый сценарий фильтрации запускается с 3 аргументами:
<сценарий> FILTER STATUS MESSAGE
где FILTER — имя фильтра, зафиксировавшего событие, STATUS —
уровень критичности события (CRITICAL или WARNING), MESSAGE —
сообщение. На основе этих данных сценарий должен вынести решение:
пропустить данное событие дальше или же отбросить его. Для этой
цели используется код завершения работы сценария (exit code):
$NAGWAD_SKIP_EVENT — означает, что событие должно быть
отброшено (переменная NAGWAD_SKIP_EVENT передаётся из nagwad
в окружение сценария);Если очередной сценарий из директории /etc/nagwad/filter-event.d
завершается со значением $NAGWAD_SKIP_EVENT, дальнейший вызов
сценариев фильтрации прекращается.
Проверка сигнальных файлов Nagwad производится средствами Icinga и
Nagios с помощью сценария check_nagwad, которому в качестве
аргумента требуется передать имя фильтра:
/usr/lib/nagios/plugins/check_nagwad <имя_фильтра>
Если сигнальный файл отсутствует, сценарий завершается с кодом 0 и
выводит строку "OK: Nothing detected for '<имя_фильтра>'".
Если же сигнальный файл присутствует, выводится содержащаяся в нём
информация (за исключением имени фильтра), а код завершения сценария
соответствует уровню критичности события.
При наличии нескольких сигнальных файлов, связанных с событием одного
и того же типа, сперва обрабатываются сигнальные файлы уровня
CRITICAL.
После того, как событие зафиксировано и обработано, администратор
безопасности может пометить сигнальный файл как разрешённый. Для этого
можно использовать команду nagwad fix (см. nagwad(8)) либо же просто
переименовать файл.