Выбрать язык


Выбрать язык | Show only


Русский | English


понедельник, 22 февраля 2016 г.

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 – неизвестные значения отображать как нулевые, вместо повторения предыдущего значения – для более наглядной сигнализации о сбоях;
  1. Настройка.
Конфигурационный файл создается командой:
# 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, того же модуля в то же время. Сенсором контролируется пользовательский сегмент, можно заметить резкий рост трафика, а также соответствующей нагрузки на процессоры, в понедельник после выходных:


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

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


Комментариев нет:

Отправить комментарий