Выбрать язык


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


Русский | English


четверг, 18 февраля 2016 г.

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 администратор рестартовал необходимые процессы.

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



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

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