Документация NetAMS

2. Apache Tomcat — это такой веб–сервер, написанный целиком на языке Java, и позволяющий исполнять сервлеты (приложения Java для серверной стороны). Скачать можно тут: http://jakarta.apache.org/tomcat/index.html. Проверялось на версии 5.0.26

3. Для «прямого» доступа к базе данных вашему сервлету понадобится механизм взаимодействия с MySQL, при помощи «родного» JDBC–драйвера по имени Mysql Connector/J. Берется тут: http://dev.mysql.com/downloads/connector/j/3.0.html

4. Необходимо скачать и настроить наш сервлет NetamsView. Дистрибутив в виде WAR файла находится тут: NetamsView.war. Скачайте его. Для установки сервлета в систему необходимо зайти в интерфейс Manager управления Tomcat, выбрать там «Select WAR file to upload», указать на файл и нажать кнопку «Deploy». После этого необходимо поправить параметры доступа сервлета к NeTAMS и базе, которые находятся в файле netams.properties. У меня этот файл установлен в каталоге /usr/local/jakarta–tomcat5.0/webapps/NetamsView/WEB–INF/

Внутри этого файла находятся строки вида:

netams–hostname router

netams–port 20001

netams–login admin

netams–password abc

mysql–hostname router

mysql–login netams

mysql–password secretpass

5. После этого должен заработать доступ к сервлету. Наберите в бровсезе:

http://www.myserver.ru:8180/NetamsView/netams

и попробуйте посмотреть что получилось. внимание! отображение таблиц отдельно по политикам не работает, используйте табличное представление по всем политикам сразу!

6. Если вы хотите получать «нормальные» ссылки на таблицы из статических страниц, генерируемых сервисом html, вам надо будет поставить и настроить NeTAMS–CURRNET, и прописать в параметрах сервиса html строку

servlet–url http://www.myserver.ru:8180

Не забудьте положить картинку showtable–logo.gif в каталог images.

Начиная с версии 1120.5 NeTAMS поддерживает мониторинг заданных юнитов для сбора информации по относящемуся к ним трафику. Для включения этой функции необходимо задать сервис monitor и направление вывода статистики. Она может сохраняться как в текстовом файле, так и в базе данных, определенной одним из сервисов storage. Для включения мониторинга необходимо задать команду

service monitor NN

monitor to file /path/to/output/file

или

service monitor NN

monitor to storage N

где N — номер соответствующего сервиса storage

После этого задайте список юнитов, трафик которых вы хотите записывать. Можно указывать как имя юнита, так и его номер (OID), каждый юнит определяется отдельной командой на своей строке. Например:

monitor unit server_1

monitor unit net_real

monitor unit 02ffad

В результате мониторинга с выводом в текстовый файл создаются записи вида:

29.04.2002 22:27:27.4898 user_1 041BEF

06 s:172.16.0.1:2174 d:172.16.13.1:23 60

29.04.2002 22:27:30.4800 user_1 041BEF

06 s:172.16.0.1:2174 d:172.16.13.1:23 60

30.04.2002 10:37:55.9553 user_1 041BEF

01 s:172.16.13.2 d:172.16.0.1 84

30.04.2002 10:39:43.4137 user_1 041BEF

17 s:172.16.13.2:1031 d:212.69.119.4:53 59

30.04.2002 10:39:43.4146 user_1 041BEF

17 s:212.69.119.4:53 d:172.16.13.2:1031 145

30.04.2002 10:39:43.4424 user_1 041BEF

06 s:172.16.13.2:1032 d:213.180.194.129:80 48

30.04.2002 10:39:43.4512 user_1 041BEF

06 s:213.180.194.129:80 d:172.16.13.2:1032 44

Первое — второе поля: дата и время, после точки — доли секунды

Третье — четвертое поля: имя юнита и его OID

Пятое поле — номер протокола (01–icmp, 06 — tcp, 17 — udp)

Шестое — седьмое поля: IP–адрес и номер порта src и dst полей пакета

Восьмое поле: длина пакета (или потока) в байтах

Вы можете использовать NeTAMS как сборщик детальной информации о трафике или записей NetFlow, применив упрощенную для этого случая конфигурацию:

# configuration file example 3 begin

debug none

user name admin real–name Admin email root@localhost password aaa permit all

service server 0

login any

listen 20001

max–conn 6

service processor 0

lookup–delay 20

flow–lifetime 120

policy name ip target proto ip

unit net name u_all ip 0.0.0.0 mask 0.0.0.0 acct–policy ip

service data–source 1

type netflow

source 192.168.0.254

listen 20001

service monitor 1

monitor to file /var/netflow.log

monitor unit u_all

# configuration file example 3 end

Поскольку NeTAMS 3.2 получает внутри себя уже агрегированную по потокам статистику, то попакетной детализации получить нельзя. Вместо этого будет сохранена информация о каждом потоке, прошедшем через data–source, что существенно сокращает размер базы или лог–файла.

Начиная с версии NETAMS–CURRENT build 2340 (03 марта 2005 г.) работает метод сбора статистики и фильтрация трафика через модуль NETGRAPH.

Технология NETGRAPH доступна для операционной системы FreeBSD версий 4.хх и 5.хх. Входящий в поставку модуль совместим с веткой 5.хх. NETGRAPH представляет собой механизм объединения различных сетевых модулей ядра FreeBSD в произвольные структуры (образующие граф), для последовательной обработки пакетов данных. Таким образом, представляется возможным написать и использовать достаточно произвольную схему обработки данных в ядре ОС, пользуясь стандартным интерфейсом программирования. Более того, легко осуществить связь модуля ядра с user–level программой. Через NETGRAPH работают, например, ng_netflow, user–level ppp, различные механизмы инкапсуляции пакетов, и многое другое. Для более глубокого ознакомления можно порекомендовать следующие источники:

http://www.daemonnews.org/200003/netgraph.html и man 4 netgraph

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

Принципы работы

Как настроить

Как проверить

Результаты испытаний

Заключение

Работа netams в случае использования модуля NETGRAPH (далее–модуль) заключается в установке модуля в ядро (и подключения его к интерфейсу, через который идет трафик), и настройке программы netams (далее–демона) для корректного соединения с модулем.

Модуль и демон могут работать в двух режимах (они должны быть одинаковы в настройках!): tee и divert.

В режиме tee модуль ядра получает пакеты с использованием «дубликатора» ng_tee, который отсылает на обработку «копию» проходящего через интерфейс пакета. Понятное дело, в таком случае фильтрация трафика невозможна. Проходящие через модуль пакеты подвергаются анализу заголовков, формируются записи в хэш–таблице, которые периодически «устаревают» и отправляются на обработку демону. Он получает пакеты с данными о трафике и обрабатывает их примерно так же, как происходит с потоками netflow (работают учет и мониторинг).

В режиме divert модуль ядра подключается непосредственно к ethernet–интерфейсу. Весь трафик проходит через обработку, однако НЕ IP трафик пропускается прозрачно без учета. Каждый пакет также проходит проверку на соответствие с уже имеющимся в системе потоком данных, и:

• если соответствующего потока не найдено, т.е. рассматриваемый пакет–первый в потоке данных (начало соединения), то для данного потока создается очередь. пакет помещается в конец очереди. создается запрос вида FWREQUEST, содержащий заголовки пакета, и передается через контрольный сокет демону netams. заметим, что в этот момент оригинальный IP пакет никуда не передается, он «застревает» в модуле. потоку присваивается статус QUEUED.