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

Андрей Дугин

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

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

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

Если для мониторинга интерфейсов возможно использование стандартных MIB, то для контроля загрузки процессоров необходимо знать специфические для производителя Cisco OID.

Согласно официальной информации производителя [1], модули IDSM2 поддерживают следующие MIB, доступные на сайте ftp://ftp-sj.cisco.com/pub/mibs/oid:

CISCO-CIDS-MIB;
CISCO-PROCESS-MIB;
CISCO-ENHANCED-MEMPOOL-MIB;
CISCO-ENTITY-ALARM-MIB.

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>

</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 – неизвестные значения отображать как нулевые, вместо повторения предыдущего значения – для более наглядной сигнализации о сбоях.

Настройка

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

# 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 сенсора (см. рис. 1).

Рисунок 1. Сопоставление загрузки процессора и сниффер-порта модуля

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

Рисунок 2. Загрузка интерфейса, принимающего SPAN, того же модуля в то же время

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

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

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

Заключение

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

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