Cisco IDSM2 + MRTG. Часть 1

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

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

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

1. Введение.

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

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

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

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

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

II. Настройка

Своевременное реагирование на вышеописанные проблемы можно обеспечить с помощью ПО 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

sensor1#

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

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

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

<div id="sysdetails">

<table>

<tr>

<td>System:</td>

<td>sensor1 in sensor1</td>

</tr>

<tr>

<td>Maintainer:</td>

<td>dugin</td>

</tr>

<tr>

<td>Description:</td>

<td>ge0_7 </td>

</tr>

<tr>

<td>ifType:</td>

<td>ethernetCsmacd (6)</td>

</tr>

<tr>

<td>ifName:</td>

<td>ge0_7</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>

<div id="sysdetails">

<table>

<tr>

<td>System:</td>

<td>sensor1 in sensor1</td>

</tr>

<tr>

<td>Maintainer:</td>

<td>dugin</td>

</tr>

<tr>

<td>Description:</td>

<td>ge0_2 </td>

</tr>

<tr>

<td>ifType:</td>

<td>ethernetCsmacd (6)</td>

</tr>

<tr>

<td>ifName:</td>

<td>ge0_2</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

IV. Мониторинг.

Когда в добавлены все сенсоры, из него можно делать 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 в норме:

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

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

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

sensor1# packet display gigabitEthernet0/7

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

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

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

2. Сетевики сменили номера VLAN'ов, при этом забыли завернуть их в SPAN.

3. Сбой в работе модуля IDSM2.

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

sensor1# reset

График загрузки порта управления выглядит приблизительно так:

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

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