Тонкости настройки syslog в Citrix ADC

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

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

Можно разделить требования к syslog Citrix ADC на две части: функциональные возможности Citrix ADC и операционная система Citrix ADC. Рассмотрим обе стороны этого вопроса.

Syslog для функциональных возможностей Citrix ADC.

Документация по syslog для Citrix ADC рекомендует использовать выражения продвинутых политик (Advanced Policy Expression) при настройке Citrix ADC, так как выражения классических политик (Classical Policy) устарели и не будут поддерживаться в будущих релизах.

Процесс настройки сообщений syslog для отправки на удаленный сервер в общем виде состоит из 3 шагов:

1. Создание сервера syslog для определения назначения и способа отправки сообщений.
2. Создание политик syslog для определения момента отправки сообщений.
3. Привязка политик syslog для определения сообщений, которые должны быть отправлены.

Если нет особых требований, то абсолютно нормально отправлять все уровни журнала, за исключением уровня отладки (Debug). Уровень отладки может быть включен, в крайнем случае, для устранения неисправностей. Необходимо осторожно подходить к уровню отладки (Debug), так как на этом уровне генерируется значительный объем данных, который быстро заполняет доступное хранилище.

Если существуют требования учёта срабатываний списков контроля доступа (ACL), ведение журнала ACL должно быть включено и для сервера syslog, куда будут отправляться журналы, а также отдельные правила ACL для записи в журнал.

Также не лишним будет включить отправку пользовательских сообщений syslog. В противном случае в журнале не отобразятся настраиваемые действия (Actions).

Пример команд для настройки отправки сообщений syslog для хранения на сервер syslog и Citrix Application Delivery Management (ADM):

add audit syslogAction retention-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -acl ENABLED -userDefinedAuditlog YES

add audit syslogAction CitrixADM-syslog-SRV -logLevel EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFORMATIONAL -userDefinedAuditlog YES

add audit syslogPolicy retention-syslog-POL true retention-syslog-SRV

add audit syslogPolicy CitrixADM-syslog-POL true CitrixADM-syslog-SRV

bind audit syslogGlobal -policyName retention-syslog-POL -priority 100

bind audit syslogGlobal -policyName CitrixADM-syslog-POL -priority 110

Syslog для операционной системы Citrix ADC.

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

Некоторые конфигурационные файлы, хранящихся в /etc, могут быть скопированы в /nsconfig, для большей устойчивости в процессе перезагрузки. /etc/syslog.conf – один из примеров таких файлов.

Выбор syslog local, зависит от конфигурации сервера syslog, на который будут отправляться сообщения. Для Citrix ADM можно использовать все доступные уровни local от 0 до 7. Звёздочка (*) после local7, определяет все сообщения для отправки на сервер syslog.

Также необходимо отредактировать /nsconfig/rc.netscaler для перезапуска демона syslog после загрузки, чтобы убедиться в использовании корректного конфигурационного файла. Если Citrix ADC сконфигурирован в высоко доступной паре, NSIP не может быть указан в явном виде, вместо этого, он может быть извлечен из файла na.conf, как показано в примере ниже.

Одна последняя вещь, которую нужно учесть – все команды, которые выполняются в оболочке, выполняются от имени пользователя root, который и будет указан в поле имени пользователя (username) в сообщениях syslog.

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

1. Скопируйте /etc/syslog.conf в /nsconfig/syslog.conf.

2. Добавьте следующие строки в /nsconfig/syslog.conf.

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

local7.*                 @<IP-АДРЕС СЕРВЕРА SYSLOG>

3. Добавьте следующие строки в /nsconfig/rc.netscaler:

pkill syslogd

nsip=$(grep -i ‘set ns config -IPAddress’ /nsconfig/ns.conf | cut -d ‘ ’ -f 5)

/usr/sbin/syslogd -b $nsip -n -v -v -8 -C &

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

Надёжный внешний репозиторий для хранения журналов syslog – это критически важный аспект при устранении неисправностей, проведении расследований и прочих задачах. Надеюсь, информация из данного блога окажется для вас полезной и пригодится в дальнейшем. За основу данного материала я хотел бы поблагодарить Magnus Esse, а дополнительную информацию по ведению журнала событий аудита можно получить в документации.