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

Андрей Дугин

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

Если ваши системы обнаружения вторжения вызывают беспокойство тем фактом, что не сигнализируют своевременно о сбоях в функционировании или реконфигурации сети, не спешите искать дорогостоящие решения. Возможно, бесплатные Open Source-решения после некоторой реконфигурации покажут себя нисколько не хуже.

В крупных компаниях обязанности администраторов сети и сетевой безопасности могут быть распределены между разными подразделениями. Системы IDS/IPS после внедрения выполняют сугубо роль обнаружения атак без активного вмешательства в трафик. Этот этап может длиться несколько лет.

Активная защита периметра выполняется файерволом, доступы к сетевым ресурсам внутри компании реализуются либо с помощью отдельных брандмауэров, либо посредством ACL (Access Control Lists), а обнаружение аномального сетевого трафика производится сенсором, на который направляется копия трафика через «зеркалированный» (SPAN-порт) коммутатор. Если сетевые администраторы и администраторы систем безопасности не извещают друг друга о проводимых работах в сети, вполне может случиться ситуация, при которой разбирается SPAN-сессия, и сенсор перестает отрабатывать события. Также возможен сбой работы как самого сенсора, так и программ мониторинга. В компаниях с большим количеством сенсоров это можно заметить далеко не сразу, и соответственно потерять данные, возможно, необходимые для расследования инцидента.

Исходим из того, что у нас есть 10 сенсоров, дополнительных денег на ПО и железо, кроме лицензий, нет, а задачу выполнить надо. Cisco systems предлагает для мониторинга и управления сенсорами программу IPS Manager Express, которая является бесплатной для скачивания пользователям с сервисным контрактом. Ограничение – максимум 5 устройств. Логично, что можно использовать 2 ПК, в которые завести управление по 5 сенсоров.

Проблемы, с которыми сталкиваешься, но не всегда сразу замечаешь:

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

Настройка

Своевременное реагирование на вышеописанные проблемы можно обеспечить с помощью ПО MRTG. Рассмотрим пример настройки MRTG под Debian Linux.

Устанавливаем MRTG:

#apt-get install mrtg

Для того чтобы было возможно осуществлять мониторинг IPS, необходимо включить на нем управление по SNMP и прописать значения read-only и read-write community. Последний параметр связан исключительно с особенностями сенсора. Тем не менее стоит учесть, что открытое на запись community дает возможность всем, кто имеет доступ по сети к сенсору, изменять его конфигурацию с помощью SNMP. В целях безопасности настоятельно рекомендуется изменить значения по умолчанию public и private на более сложные community.

Через CLI возможность управления по SNMP конфигурируется следующим набором команд:

sensor1#configure terminal

sensor1(config)#service notification

sensor1(config-not)#enable-set-get true

sensor1(config-not)#read-only-community DlY@_$en$ora

sensor1(config-not)#read-write-community Dly@_@dm1n@_$en$ora

sensor1(config-not)#exit

Apply Changes?[yes]:

sensor1(config)#exit

Конфигурация интерфейсов записывается в файл /etc/mrtg.cfg с помощью команды:

# cfgmaker read-only-community@sensor.address > /etc/mrtg.cfg

Но в этом случае затем придется существенно править конфигурационный файл руками. Хоть без этого все равно не обойтись, рекомедую для IDSM2 создавать настройки с параметрами:

# cfgmaker --no-down read-only-community@sensor.address > /etc/mrtg.cfg

В целях безопасности рекомендуется не давать доступ к файлу всем:

# chmod 640 /etc/mrtg.cfg

У модуля IDSM2 определяется 6 интерфейсов:

Interface 1 – loopback (lo);
Interface 2 – GigabitEthernet0/7 (ge0_7);
Interface 3 – GigabitEthernet0/8 (ge0_8);
Interface 4 – sy0_1;
Interface 5 – GigabitEthernet0/2 (ge0_2);
Interface 6 – sy0_0.

Нас интересуют всего 2 из них:

GigabitEthernet0/2, через который происходит управление и сбор событий;
GigabitEthernet0/7 (или 0/8 – в зависимости от настроек) – порт, на который приходит SPAN-сессия.

Если запускать cfgmaker без параметра --no-down – интерфейсы loopback, GigabitEthernet0/7 и GigabitEthernet0/8 будут в конфигурационном файле закомментированы, и придется раскомментировать тот интерфейс, который принимает SPAN.

Интерфейсы sy0_0 и sy0_1, как альтернативные TCP RST-интерфейсы, будут считаться активными.

Адаптация и кастомизация

По умолчанию загрузка интерфейса отображается в байтах/сек, шкала времени идет справа налево. Для того чтобы изменить направление шкалы, необходимо в конфигурационном файле /etc/mrtg.cfg раскомментировать строку:

Options[_]: growright, bits

и оставить те параметры, которые больше по вкусу администратору, либо приняты в компании. Параметр growright направляет шкалу времени вправо, а bits отвечает за отображение загрузки в битах/сек.

С каждого интерфейса IDSM2 в конфигурационный файл MRTG по умолчанию считываются следующие параметры, которые необходимо отредактировать:

MaxBytes[sensor1_5]: 1250000

Title[sensor1_5]: Traffic Analysis for 5 -- sensor1

PageTop[sensor1_5]: <h1>Traffic Analysis for 5 -- sensor1</h1>

---------------output omitted--------------------

<td>Max Speed:</td>

<td>1250.0 kBytes/s</td>

---------------output omitted--------------------

Красным шрифтом показаны несоответствия данных, полученных с помощью SNMP, реальным данным. По умолчанию интерфейсы перечисляются по номерам. Также можно заметить, что гигабитные интерфейсы сенсора MRTG определяет как 10-мегабитные. Cisco в своей документации (http://www.cisco.com/en/US/docs/security/ips/6.2/configuration/guide/ime/ime_troubleshooting.html#wp1020491) указывает, что MIB II поддерживаются сенсорами, однако корректность полученных данных не гарантируется. Соответственно в конфигурационном файле изменяем скорость в местах:

MaxBytes[sensor1_5]: 125000000

<td>Max Speed:</td>

<td>125.0 MBytes/s</td>

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

В итоге конфигурационный файл /etc/mrtg.cfg, полученный для 1-го сенсора, с учетом того, что нам нужен мониторинг только 2 интерфейсов, будет выглядеть приблизительно так:

# Created by

# /usr/bin/cfgmaker DlY@_$en$ora@sensor1

### Global Config Options

# for UNIX

# WorkDir: /home/http/mrtg

# for Debian

WorkDir: /var/www/mrtg

# or for NT

# WorkDir: c:\mrtgdata

### Global Defaults

# to get bits instead of bytes and graphs growing to the right

Options[_]: growright, bits

EnableIPv6: no

#########################################################

# System: sensor1

# Description: Linux sensor1 2.4.30-IDS-smp-bigphys #2 SMP

# Sat Jul 12 04:12:55 UTC 2008 i686

# Contact: dugin

# Location: sensor1

#########################################################

### Interface 2 >> Descr: 'ge0_7' | Name: 'ge0_7' | Ip: | Eth: ###

Target[sensor1_2]: 2:DlY@_$en$ora@sensor1:

SetEnv[sensor1_2]: MRTG_INT_IP="" MRTG_INT_DESCR="ge0_7"

MaxBytes[sensor1_2]: 125000000

Title[sensor1_2]: Traffic Analysis for SPAN -- sensor1

PageTop[sensor1_2]: <h1>Traffic Analysis for SPAN -- sensor1</h1>

<table>

<tr>

<td>System:</td>

<td>sensor1 in sensor1</td>

</tr>

<tr>

<td>Maintainer:</td>

<td>dugin</td>

</tr>

<tr>

<td>Description:</td>

</tr>

<tr>

<td>ifType:</td>

<td>ethernetCsmacd (6)</td>

</tr>

<tr>

<td>ifName:</td>

</tr>

<tr>

<td>Max Speed:</td>

<td>125.0 MBytes/s</td>

</tr>

</table>

</div>

### Interface 5 >> Descr: 'ge0_2' | Name: 'ge0_2' | Ip: | Eth: '00-03-e4-72-38-0c' ###

Target[sensor1_5]: 5:DlY@_$en$ora@sensor1:

SetEnv[sensor1_5]: MRTG_INT_IP="" MRTG_INT_DESCR="ge0_2"

MaxBytes[sensor1_5]: 125000000

Title[sensor1_5]: Traffic Analysis for MGMT -- sensor1

PageTop[sensor1_5]: <h1>Traffic Analysis for MGMT -- sensor1</h1>

<table>

<tr>

<td>System:</td>

<td>sensor1 in sensor1</td>

</tr>

<tr>

<td>Maintainer:</td>

<td>dugin</td>

</tr>

<tr>

<td>Description:</td>

</tr>

<tr>

<td>ifType:</td>

<td>ethernetCsmacd (6)</td>

</tr>

<tr>

<td>ifName:</td>

</tr>

<tr>

<td>Max Speed:</td>

<td>125.0 MBytes/s</td>

</tr>

</table>

</div>

Добавляем новые сенсоры в конец конфигурационного файла:

# cfgmaker --no-down new_sensor_ro_community@new_sensor_address >> /etc/mrtg.cfg

Мониторинг

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

# indexmaker /etc/mrtg.cfg > /var/www/mrtg/index.html

Страница должна находиться в том же каталоге, который указан в конфигурации /etc/mrtg.cfg как:

# for Debian

WorkDir: /var/www/mrtg

Разумеется, также необходим веб-сервер. Особого конфигурирования не нужно, достаточно, чтобы он был запущен. Мониторинг после настройки производится через веб-браузер по адресу http://your.server.addres/mrtg.

Итак, после проведения настройки, каким образом можно узнавать о проблемах?

Приблизительно так выглядит график загрузки SPAN-порта IDSM2 в норме (см. рис. 1). Зеленым показан входящий в интерфейс трафик, синим – исходящий. Логично, что на слушающем порту не будет исходящего трафика.

Рисунок 1. График загрузки SPAN-порта IDSM2 в норме

MRTG по умолчанию снимает показатели с портов 1 раз в 5 минут, что можно заметить в cron. Это минимально возможный интервал опроса. Соответственно, когда график показывает резкий спад и длительное время находится около нуля, как показано на рис. 2, – значит разобрали SPAN-сессию или поменяли идентификаторы VLAN, завернутых в нее.

Рисунок 2. График загрузки SPAN-порта IDSM2 показывает резкий спад

Но возможно, что перенесена нагрузка на другой коммутатор либо произошел сбой в работе модуля IDSM2. Необходимо зайти на интерфейс и послушать некоторое время:

sensor1# packet display gigabitEthernet0/7

чтобы понять, ходит ли вообще какой-либо трафик.

Причины того, что ни один пакет не пришел за определенное время:

Разобрана SPAN-сессия. Однако в этом случае на порт будет приходить широковещательный и служебный трафик.
Сетевики сменили номера VLAN, при этом забыли завернуть их в SPAN.
Сбой в работе модуля IDSM2.

Последняя причина определяется следующим образом: при попытке зайти на веб-консоль управления IDSM2 через https java-апплет запускается, в Dashboard видно, что интерфейсы GigabitEthernet0/7 и 0/8 в состоянии down, затем вылетает ошибка, и веб-консоль закрывается. Поскольку вручную интерфейсами IDSM2 манипулировать не так просто, как с интерфейсами свитчей и роутеров, лучше рестартовать модуль:

sensor1# reset

График загрузки порта управления выглядит приблизительно так (см. рис. 3). В данном случае можно определить по наличию абсолютно ровной прямой, держащейся на определенном уровне, отличном от нуля, что в 11:10-11:20 произошел сбой программы управления, это привело к отсутствию сбора событий, а к 13:00 администратор рестартовал необходимые процессы.

Рисунок 3. График загрузки порта управления

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