Cisco IDSM2 + MRTG. Часть 2

  Статья 2009 года, опубликована в журнале "Системный администратор"

Мониторинг Cisco IDS/IPS на примере модуля IDSM2 c помощью MRTG. Часть 2.

Рано или поздно перед администратором систем обнаружения вторжений возникают вопросы:

- рациональности использования ресурсов,

- соответствия официально заявленных производителем параметров реальным данным,

- возможности распределения сенсоров различной мощности по разным участкам сети.

В этом случае также может пригодиться MRTG.

1. Особенности создания конфигурационного файла.

Если для мониторинга интерфейсов возможно использование стандартных MIB-ов, то для контроля загрузки процессоров необходимо знать специфические для производителя Cisco OID.
Согласно официальной информации производителя [1], модули IDSM2 поддерживают следующие MIB:

•CISCO-CIDS-MIB

•CISCO-PROCESS-MIB

•CISCO-ENHANCED-MEMPOOL-MIB

•CISCO-ENTITY-ALARM-MIB

доступные на сайте ftp://ftp-sj.cisco.com/pub/mibs/oid/ .

Cisco IDSM2 модуль является двухпроцессорным. Загрузка процессора напрямую зависит от количества и характера инспектируемого трафика. Показатели среднего значения загрузки за 5 минут CPU1 и CPU2 дают OID'ы 1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 и 1.3.6.1.4.1.9.9.109.1.1.1.1.8.2 соответственно, относящиеся к CISCO-PROCESS-MIB. Конфигурационный файл в данном случае лучше создать на основе файла-шаблона. Пример можно найти в страницах инструкций man cfgmaker и отредактировать под свои нужды.

Мой файл-шаблон после редактирования изначального варианта выглядит следующим образом:

$head_lines .= <<ECHO;

#---------------------------------------------------------------------

ECHO

my $target_name = $router_name . ".cpu";

$target_lines .= <<ECHO;

YLegend[$target_name]: CPU load, %

ShortLegend[$target_name]: %

Legend1[$target_name]: CPU1 load in %

Legend2[$target_name]: CPU2 load in %

Legend3[$target_name]: Max Observed CPU1 load

Legend4[$target_name]: Max Observed CPU2 load

LegendI[$target_name]:  CPU1 Load:

LegendO[$target_name]:  CPU2 Load:

WithPeak[$target_name]: ywm

MaxBytes[$target_name]: 100

Options[$target_name]: growright, gauge, nobanner,

Title[$target_name]: $router_name CPU load

Target[$target_name]: 1.3.6.1.4.1.9.9.109.1.1.1.1.8.1&1.3.6.1.4.1.9.9.109.1.1.1.1.8.2:$router_connect

PageTop[$target_name]: <h1>$router_name CPU load</h1>

<div>

<table>

<tr>

<td>System:</td>

<td>$router_name in $html_syslocation</td>

</tr>

<tr>

<td>Maintainer:</td>

<td>$html_syscontact</td>

</tr>

<tr>

<td>Description:</td>

<td>$html_sysdescr</td>

</tr>

<tr>

<td>Resource:</td>

<td>CPU.</td>

</tr>

</table>

</div>

ECHO

Вкратце о параметрах в файле, которые пришлось отредактировать:

YLegend – легенда оси Y графика;

ShortLegend – единица измерения оси Y;

Legend1 – легенда графика зеленого цвета, в данном случае средней загрузки CPU1;

Legend2 - легенда графика синего цвета, в данном случае средней загрузки CPU2;

Legend3 – легенда дополнительного графика темно-зеленого цвета, в данном случае пиковой загрузки CPU1 за единицу времени;

Legend4 - легенда дополнительного графика фиолетового цвета, в данном случае пиковой загрузки CPU2 за единицу времени;

LegendI – интерпретация параметра Legend1 на странице дополнительных графиков;

LegendO – интерпретация параметра Legend2 на странице дополнительных графиков;

WithPeak – использование пиковых значений в дополнительных графиках за неделю (w), месяц (m), год (y);

MaxBytes – максимальное значение оси Y;

growright – указывает направление оси X вправо;

gauge – обработка параметров, значения которых не возрастают постоянно;

nobanner – не добавлять баннер MRTG к страницам с дополнительными графиками;

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

2. Настройка.

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

# cfgmaker --nointerfaces \

--host-template=/etc/mrtg/templates/cpu-idsm \

--global "WorkDir: /var/www/mrtg/idsm" \

community_name@sensor1 \

community_name@sensor2 \

community_name@sensor3 \

community_name@sensor4 \

community_name@sensor5 > /etc/mrtg/idsm.cfg

В данном случае рассматривается автономный от интерфейсов вариант мониторинга загрузки CPU. Соответственно, кроме конфигурационного файла создается отдельная веб-директория:

# mkdir /var/www/mrtg/idsm

и, соответственно, index.html в ней:

# indexmaker --nolegend \

--title="IDSM CPU" \

/etc/mrtg/idsm.cfg > /var/www/mrtg/idsm/index.html

Создаем в /etc/cron.d/ отдельный файл, в котором указываем новые параметры конфигурации для запуска MRTG 1 раз в 5 минут, а также путь для записи ошибок в отдельный лог-файл:

# vim /etc/cron.d/idsm-mrtg

и записываем:

*/5 * * * * root if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg/idsm.cfg ]; then env LANG=C /usr/bin/mrtg /etc/mrtg/idsm.cfg 2>&1 | tee -a /var/log/mrtg/idsm-mrtg.log ; fi

Веб-интерфейс мониторинга CPU будет находиться по адресу http://yourserver/mrtg/idsm/

Сопоставить загрузку процессора и сниффер-порта модуля можно на следующем примере. Зеленым цветом показана загрузка CPU1, синим - CPU2 сенсора:

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

3. Практическое применение.

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

- необходимости снятия части нагрузки с модуля путем исключения из SPAN-сессии некоторых интерфейсов либо VLAN'ов в случае высокой загрузки модуля;

- возможности наращивания инспектируемого трафика в случае низкой нагрузки;

- целесообразности добавления дополнительного модуля в коммутатор – в случае перегрузок;

- целесообразности замены модуля в коммутаторе на более соответствующий поставленным задачам для данного участка сети сенсор другого производителя - как в случае чрезмерно высокой, так и низкой загрузки;

- возможности агрегации SPAN-сессий из разных коммутаторов для инспектирования на одном сенсоре любого производителя – при наличии такой необходимости.

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

Итого, сопоставляя полученные данные мониторинга систем, имеем, как минимум, дополнительный факт для принятия решения в зависимости от поставленной задачи. В ряде случаев показатели загрузки могут косвенно свидетельствовать о наличии аномалий сетевой активности, что ускорит процесс реагирования на инцидент информационной безопасности. Соответственно, в некоторых ситуациях MRTG еще и помогает системам IDS выполнять свои основные функции.

1. http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_snmp.html#wp1042408