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

Веб–интерфейс Admintool

ВНИМАНИЕ!

Admintool не избавляет вас о необходимости начального создания и настройки конфигурационного файла NeTAMS. С его помощью можно лишь управлять параметрами уже существующих юнитов в плане настройки IP–адресов, квот, параметров логинов и прочего.

Admintool тесно связан с существующим сервисом создания статических HTML–страниц так, что в вновь создаваемых страницах появляется ссылка на скрипт:

Допустим, сервис html настроен следующим образом:

service html 0

path /usr/local/www/stat

language en

run hourly

При нормальной работе в этом каталоге находятся следующие файлы:

srv:/usr/local/www/stat#ls–la

drwxr–xr–x 4 root wheel 512 Jul 12 14:31 .

drwxr–xr–x 11 root wheel 1536 Jul 19 11:41 ..

drwxr–xr–x 7 root wheel 512 Jul 12 14:30 2004

drwxr–xr–x 118 root wheel 2048 May 31 14:11 clients

drwxr–xr–x 2 root wheel 512 Jul 21 21:14 images

— rwxr–xr–x 1 root wheel 139 Jul 19 12:59 index.html

Для инсталляции Admintool необходимо скопировать в каталог /usr/local/www/ из дистрибутива NeTAMS подкаталог /cgi–bin/

Необходимо отредактировать верхние строки скрипта admintool.cgi, указав параметры соединения с NeTAMS:

# Data required to do a script login, change this

$sc_host=«localhost»; $sc_port=20001; $sc_user=«anton»; $sc_passwd=«aaa»;

Необходимо настроить веб–сервер (Apache), чтобы он разрешал выполнение CGI–скриптов в каталоге /usr/local/www/stat. Отредактируйте /usr/local/etc/apache/httpd.conf (или где там он у вас есть):

Options FollowSymLinks ExecCGI

Alias /stat/ /usr/local/www/stat/

Убедитесь что скрипт работает, набрав

http://webservername/stat/admintool.cgi

Вы должны увидеть нечто вроде следующего:

В левом верхнем углу указано:

Версия работающей программы NeTAMS

Время выполнения программы NeTAMS (из show version)

Текущее локальное время в системе.

Если вместо пунктов 1 и 2 изображены пустые строки, значит или NeTAMS не запущен в настоящий момент, или скрипту не удалось с ним связаться (не совпадают логин/пароль/номер порта).

Настоятельно рекомендуется:

Запускать NeTAMS, Apache и Admintool на одной машине. Открыть доступ в NeTAMS только с локальной машины (service server … login local).

Средствами Apache разграничить доступ к статистике и к скрипту только для тех, кому это действительно необходимо (и использовать опцию htaccess yes для сервиса html).

Утилита ascii2netflow

Начиная с версии NeTAMS 3.4.0 (build 3018) в дистрибутиве присутствует утилита ascii2netflow, которая предназначена для преобразования входящей статистики в поток данных в формате Cisco NetFlow

Автоматическое создание юнитов

Зачастую бывает проблематично или неудобно вручную создавать весь список юнитов для большой сети. Для решения этой проблемы в netams–3.1(2000.204) была введена функциональность auto–units, или возможность автоматического создания юнитов при появлении IP–трафика на заданные адреса. Для этого необходимо:

Необходимо создать специальную запись в конфигурации сервиса processor, с именем auto–units и уникальным номером, и описать ее поведение

Создать юнит типа сеть (net) и указать параметр «auto–units N» для него.

Опционально создать для каждого использующегося ip–адреса запись в обратной зоне DNS.

Например:

service processor

auto–units 1 type host naming by–dns

auto–units 2 type user naming prefix1 ip–auto–units 3 type user naming prefix2 user_

unit net name OFFICE ip 192.168.0.0 mask 255.255.255.0 auto–units 1

unit net name CLIENTS ip 192.168.100.0 mask 255.255.255.0 auto–units 2

unit net name USERS ip 172.16.0.0 mask 255.255.0.0 auto–units 3

Допустим, что для подсети 192.168.0.0 у вас уже настроена обратная зона DNS (например, для работы DHCP, или через Dynamic DHS от Windows2000). В этом случае возможно обратное преобразование IP–адреса в FQDN, т.е. команда

host 192.168.0.123

выдает что–то вроде

pupkin.office.domain.ru

Допустим также, что у вас настроен и работает сервис data–source, и трафик для подсетей 192.168.0 и 172.16 попадает через этот сервис в NeTAMS.

Что должно происходить, когда пакет с адресом DST=192.168.0.123 попадает на обработку. Если соответствующий сервис имеет тип ip–traffic, то, поскольку юнита для данного IP еще не существует, прохождение или блокировка этого пакета будет определяться значением параметра restrict сервиса processor, наличием no–local–pass, sys–policy, fw–policy на юнит OFFICE. Если сервис data–source не осуществляет фильтрацию, пакет проходит. В любом случае, из–за действия механизма потоков информация о трафике на IP–адрес 192.168.0.123 рано или поздно попадет на обработку s_datasource и связана с юнитом типа «сеть» с именем OFFICE. Если для него установлено значение параметра auto–units, то:

Будет установлено, что адрес 192.168.0.123 принадлежит искомой сети 192.168.0.0/24

Юнита с адресом 192.168.0.123 пока еще не существует, и его надо создать

Поскольку для записи auto–units 1 установлен type==host, будет создан юнит типа host

Для определения имени для этого юнита будет использован DNS (т.к. параметр naming==by–dns), который преобразует IP–адрес 192.168.0.123 в имя pupkin.office.domain.ru. В качестве имени будет выбрано «pupkin». На совести администратора обеспечить уникальность имен в подсети.

Если в качестве типа юнита установлено type==user, будет применен этот тип.

Если в качестве параметра присвоения имени (naming) указано prefix1 или prefix2, то для выбора имени будет использоваться указанная затем подстрока в сочетании с последним (prefix1) или двумя последними (prefix2) октетами рассматриваемого IP–адреса. Таким образом, для проходящих пакетов с адресами 192.168.100.123 и 172.16.0.23 будут созданы юниты:

unit user name ip–123 ip 192.168.100.123

unit user name user_0.23 ip 172.16.0.23

Учтите также, что процесс преобразования IP–адресов в имена хостов может занимать время, и основан на механизме, описанном в man resolver. Это может сказаться на времени реакции системы и производительности NeTAMS.

Автоматически созданные юниты будут расположены в конфигурационном файле «в памяти» и иметь уникальные автоматически присвоенные значения OID. Вы должны время от времени сохранять «растущий» конфигурационный файл на место, чтобы новые юниты и их статистика не потерялась. Эту операцию можно автоматизировать:

schedule time 1hour action save

После того как все IP–адреса «присвоены» новым юнитам, рекомендуется отключить описанный здесь механизм auto–units, путем удаления параметра auto–units с юнита типа «сеть»:

service processor

unit net name OFFICE auto–units 0

Зачем нужен break flag [%] при описании policy

Для версий netams 3.1.xx, 3.2.xx и 3.3.xx до build 2117:

Если вы задаете последовательность из нескольких политик фильтрации трафика подряд, то по умолчанию их действие суммируется, т.е. в случае

service processor

policy name all–ip target proto ip

policy name tcp target proto tcp

unit host name HOST1 ip 192.168.1.5 fw–policy !tcp all–ip

вы все равно не сможете открыть для этой машины ТОЛЬКО TCP–трафик, на следующем совпавшем правиле all–ip пакет зарежется. Для того чтобы после совпадения политики дальнейший поиск прекратился, поставьте

unit host name HOST1 ip 192.168.1.5 fw–policy !%tcp all–ip

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

service processor

policy name ip target proto ip

policy name tcp target proto tcp

policy name udp target proto udp

policy name other target proto ip

unit host name HOST1 ip 192.168.1.5 acct–policy ip tcp udp other

вы все равно не сможете явно посчитать для этой машины весь не udp и не tcp трафик, который назовем other, так как пакет все равно посчитается по политике ip. Чтобы при совпадении политики дальнейший подсчет прекратился, поставьте

unit host name HOST1 ip 192.168.1.5 acct–policy ip %tcp %udp other

Для версий netams 3.3.xx после build 2117, в частности 3.3.0–release и далее:

По многочисленным пожеланиям пользователей и для упрощения конфигурационного файла, действие политики fw–policy было инвертировано. Теперь код вида:

unit host name HOST1 ip 192.168.1.5 fw–policy www icmp

разрешает данному юниту общение по политикам www и icmp, блокируя все остальное. Вам теперь не нужно городить сложные комбинации с участием break flag и инвертирования. Помните, что весь остальной трафик, не описанный в политиках fw–policy, будет блокирован.

Управления карточками экспресс–оплаты

Управление базой данных

Можно настроить автоматическую или ручную очистку быстрорастущих таблиц raw и monitor при помощи этих нехитрых SQL–команд:

delete from raw \

where t_to < unix_timestamp(date_add(now(), interval–6 MONTH));

delete from monitor \

where time < unix_timestamp(date_add(now(), interval–6 MONTH));

При этом удаляются записи, которым более полугода.

Надо отметить, что таблица summary растет достаточно медленно, и при нынешних ценах на дисковую память можно не особо беспокоиться.

Если вы делаете бизнес при помощи NeTAMS и целостность данных критична, рекомендую подумать о резервном копировании. Это можно сделать следующими средствами:

• Поставить в сервер два жестких диска, и организовать аппаратный или программный RAID. Это не спасет, если упадет ОС (придется тратить время на переустановку), разрушится или случайно сотрется содержимое файловой системы или кто–то грохнет базу, или сервер украдут;

• Организовать автоматическое резервное копирование базы через mysqldump/mysqlhotcopy, на соседний сервер или удаленный компьютер;

• Средствами NeTAMS писать одновременно в два хранилища:

service processor

…

storage 1 all

storage 2 summary

В дополнение к этому в дистрибутиве идет скрипт очистки БД: addon/mysql_rotate.pl

Правила для data–source

В случае использование FreeBSD правила должны выглядеть следующим образом:

Случай использования «честных» адресов:

rule number «ip from any to any via ifname»

где:

number — относительно любой номер правила в таблице ipfw, например 100

ifname — название внешнего интерфейса, через который трафик идет к провайдеру

Случай использования «левых» адресов и их трансляции:

rule number1 «ip from any to any via ifname»

rule number2 «ip from any to any via ifname»

где:

number1 и number2 — номера правил в таблице ipfw, так чтобы ваше правило по трансляции адресов (заворот пакетов в divert socket NATD) имело номер МЕЖДУ НИМИ.

ifname — название внешнего интерфейса, через который трафик идет к провайдеру

Это сделано для того, чтобы учитывать трафик на не оттранслированные адреса.

В случае Linux, независимо от наличия трансляции адресов (маскарадинга), правила имеют вид:

rule number1 «INPUT–p all–j QUEUE»

rule number2 «FORWARD–p all–j QUEUE»

rule number3 «OUTPUT–p all–j QUEUE»

причем номера number1, 2 и 3 совершенно произвольные так как никак не используются.

Этими действиями выполняется следующее: вы задаете правила для ipfw/iptables, по которым пакеты ядром направляются пихаются в некую виртуальную трубу (которая называется queue), откуда их потом берет программа, прокачивает через себя (смотря на заголовки и делая подсчет) и отдает обратно в систему, после чего они спокойно идут себе дальше.

ВАЖНО!!!

Если вы остановили программу так что она не смогла после себя убрать эти поставленные правила (через kill–9) или она сама неожиданно померла, то все пакеты по прежнему система будет заворачивать туда откуда их никто не заберет, и они пропадут. С точки зрения системы это будет выглядеть как полная потеря работы с сетью. НИКОГДА не экспериментируйте с этим сидя за удаленной машиной. Тренируйтесь непосредственно за консолью, или в крайнем случае на icmp–трафике. Сделайте для доступа «дырку» перед всеми правилами, пропускающую для вас SSH. Это не касается data–source других (неблокирующих) типов, например libpcap или netflow.

Java API и сервлеты

Для управления системой NeTAMS существует прикладной интерфейс для языка Java. Он повторяет по функциональности интерфейс для Perl, и при этом содержит процедуры разбора конфигурационного файла для получения списка политик и юнитов (с привязанными политиками). На базе этого интерфейса разработано тестовое приложение NetamsView–ShowTable, которое представляет собой веб–интерфейс для доступа к статистике из БД и представления ее в таблично–календарном виде (скриншот 1, скриншот 2).

Если вы хотите разработать свой модуль интерфейса с NeTAMS на языке Java, или просто смотреть таблички как на скриншоте, вам необходимо будет сделать следующее:

Поставить Java SDK

Поставить Apache Tomcat

Поставить драйвер JDBC (MysqlJ)

Поставить сервлет

(опционально) поставить NeTAMS–CURRENT

Теперь по порядку.

1. Java SDK нужно для того, чтобы запускать приложения, написанные на языке Java. Этими приложениями будут сам сервлет, отдающий таблицу, и веб–сервер Tomcat. Установка JDK описана много где, очень рекомендую: http://www.freebsd.org/doc/en_US.ISO8859–1/articles/java–tomcat/. Там написано про версию JDK 1.3, на настоящий момент последняя версия имеет номер 1.4.2 (и 1.5.0 скоро выйдет). После успешной инсталляции вы сможете успешно набрать «java–version» и получить потребный вывод.

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, что существенно сокращает размер базы или лог–файла.

Сбор данных через NETGRAPH

Зачем нужно no–local–pass

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

service processor

policy name all–ip target proto ip

restrict all drop local pass

unit net name LAN ip 192.168.1.0 mask 255.255.255.0 acct–policy all–ip

unit host name USER1 ip 192.168.1.10

unit host name USER2 ip 192.168.1.12

unit host name USER3 ip 192.168.1.13

В таком случае, машина из локальной сети с адресом 192.168.1.20 сможет пройти наружу, так как она попадает в сеть LAN (unit net name LAN) и пакеты маркируются локальными (restrict local pass). Вы можете избежать этого, создав группу и пометив все указанные компьютеры из этой подсети как принадлежащие группе, однако есть более красивое решение:

unit net name LAN ip 192.168.1.0

mask 255.255.255.0 no–local–pass acct–policy all–ip

В этом случае пакеты от 192.168.1.20 не будут считаться за локальные и не пропустятся.

OID, их автоматическая генерация и перезагрузки

При создании конфигурационного файла, и при добавлении юнитов вручную oid можно не указывать. При этом значение oid генерируется автоматически, так что если набрать show config, значения oid выставятся каким–то случайным образом. ГАРАНТИРУЕТСЯ уникальность номеров OID. Чтобы после рестарта NeTAMS oid остались теми же (и старая статистика не потерялась), необходимо после редактирования конфига или любых изменений в нем через интерфейс программы набирать save, тогда конфигурационный файл перезапишется на тот, что выполняется в данный момент, вместе со значениями oid, и после рестарта статистика продолжит собираться и суммироваться правильно.

Причина подобного требования в том, что OID является также уникальным ключом (PRIMARY KEY) в базе данных, и счетчики привязаны к нему. Кстати, из этого следует, что никто не мешает переименовывать юниты по ходу работы.

Perl API

NeTAMS представляет собой достаточно гибкий инструмент учета трафика и установки некоторых ограничений на работу пользователей. Круг задач, которые можно решить с использованием данной программы, чрезвычайно широк, и у каждого администратора есть свои пожелания по организации работы программы и тому, как она взаимодействует с пользователями. Для облегчения задачи настройки и использования NeTAMS под ваши конкретные задачи был создан интерфейс в виде ряда функций, который позволяет управлять программой и получать от нее данные из ваших написанных самостоятельно Perl–скриптов и CGI–программ.

Для применения интерфейса вы должны включить в начало вашей программы строку:

require «netams_api.pl»

Вот список функций, которые определены в этом интерфейсе:

• $result=netams_login($hostname, $port, $username, $password); — осуществляет соединение с программой, используя указанные параметры. Если $result начинается со слов «Welcome», то соединение прошло успешно

• netams_send($command); — отправляет команду $command на исполнение

• $result=netams_read(); — считывает в переменную $result результат выполнения команды

• $result=netams_readline(); — то же самое, но программа ожидает вывода признака конца строки (перевод строки, "\n»). использовать не рекомендуется

• netams_logout(); — осуществляет разрыв соединения.

Вот список идущих с программой скриптов, которые можно применять на практике или рассматривать как примеры программирования общения с NeTAMS:

• netams_example.cgi — выводит результат выполнения команды show version в виде cgi–программы. после небольшой модификации превращается в утилиту командной строки.

• login.cgi — интерфейс к сервису login.

• netams_graph.cgi — программа, динамически создающая картинки в формате PNG с графическим отображением статистики для заданного юнита и всех его политик учета, за последние неделю или месяц. параметры вызова (метод GET):

• unit=UNIT_NAME — обязательный параметр, определяет имя юнита, для которого будет рисоваться картинка

• policy=POLICY_NAME — имя политики, которая будет отображаться. при отсутствии параметра policy будут отрисованы все активные политики.

• prefix=PREFIX — буква, определяющая временной период графика, W (неделя) или M (месяц) соответственно, по умолчанию =W

• nolegend=FLAG — при любом установленном значении запрещает отрисовку легенды с отображением цвета, которым будет отрисовываться данные о политике.

• Данный скрипт использует модули GD.pm и библиотеку libgd. Для FreeBSD вам надо выполнить что–то вроде cd /usr/ports/graphics/p5–GD ; make install. В текущем каталоге необходимо иметь файл lucon.ttf, это TrueType–шрифт Lucida Console из дистрибутива Windows XP.

Место NeTAMS среди других считалок

Вокруг вертится много разных непонятных названий: ipcad, netflow, NetUP, Cisco, netgraph, биллинг и прочее. Что это все значит и с чем это едят?

Если вы попали на этот сайт, значит вам наверняка надо:

а) Учитывать IP–трафик в сети

б) Брать с кого–то за это деньги (опционально)

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

С задачей учета трафика успешно справляется достаточно большое количество программ. Они имеют (или нет) средства, чтобы:

• Собрать циферки

• Суммировать циферки

• Положить сумму в базу или лог

• Отобразить циферки согласно (сложному) запросу

• Скомандовать внешней программе о превышении (редко)

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

• Счетчики пакетов вашей операционной системы

• Можно делать опрос встроенных счетчиков на правилах ipfw/iptables, но сразу возникают вопросы: кто будет эти правила выставлять–убирать, как часто делать такой опрос (скорость vs. точность), насколько это все удобно и гибко

• Анализ потока NetFlow

• Фирма Cisco Systems придумала способ, как отдавать информацию о промаршрутизированном трафике наружу, другим программам. Это делается при помощи протокола NetFlow, который описан тут. Правильным образом настроенный маршрутизатор периодически отсылает на указанный сервер UDP–пакеты, содержащие Flow Records — информацию о прошедшем трафике, суммированную по разным признакам. Принимающей стороне остается лишь разобрать и переварить пакеты.

• Опрос другого сетевого устройства по SNMP

• Нельзя сказать, что это удачный метод, т.к. стандартные счетчики SNMP содержат только информацию по количеству байтов/пакетов, прошедших через интерфейс, без разделения на протоколы–порты–адреса.

• Встроиться вовнутрь ядра операционной системы и получать статистику «из первых рук»

• Очень быстро работает, но фактически приводит к экспорту логов/потока netflow из ядра, не больше.

• Слушать на интерфейсе

• Широко известная библиотека libpcap позволяет посмотреть на каждый пакет (и его заголовки), проходящий через роутер.

Суммировать (агрегировать) статистику просто необходимо, иначе большой объем первичной информации не даст быстро провести нужный запрос. Суммируют обычно по времени, номеру автономной системы, адресу получателя, протоколу, группе протоколов.

Чтобы статистика не потерялась после перезагрузки компьютера, ее надо хранить в базе данных, желательно SQL. При этом упрощается процесс получения выборок по заданному признаку.

Для отображения статистики часто пишется веб–интерфейс, работающий с базой данных, и позволяющий сделать выборку по заданному критерию (время, адреса и прочее).

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

В природе существует большое количество «считалок», в разной степени попадающих под вышеприведенное описание. Их хороший обзор приведен тут: http://www.unixfaq.ru/index.pl?req=qs&id=247.

Дальнейшее развитие систем учета трафика — системы биллинга. Их основные свойства:

• Развитый интерфейс управления, настройки, запросов; клиентская часть

• Перевод счетчиков «считалок» в деньги согласно тарифному плану. Тарифные планы могут быть чрезвычайно хитрыми.

• Ведение счетов клиента (платежи, смена планов, блокировка, …)

• Поддержка бухгалтерии (акты, счета, сводки, …)

• Обязательна возможность отключения клиента (с уведомлением)

• Наличие сертификата Минсвязи

Для получения сертификата Минсвязи, позволяющего легально использовать установленную систему биллинга для обслуживания (читай — отъема денег) клиентов, и официально сдать в эксплуатацию узел связи, нужны большие средства. В природе есть несколько дорогих систем (Абсолют, CBOSS, Атлант, IpSoft Billing), и ряд более дешевых (NetUP, LanBilling). В большинстве случаев стоимость биллинговой системы определяется набором модулей (netflow, выделенные линии, VoIP, …), включенных в поставку.

Система биллинга, не имеющая сертификата Минсвязи, особо никому и не нужна.

Модуль биллинга, поставляемый с NeTAMS бесплатно, позволяет создавать новый тип объектов — аккаунт пользователя, привязывать к нему юниты, вести гибкие тарифные планы, управлять счетом клиента и т.д. Вместе с тем, сертификата Минсвязи на этот модуль НЕТ.

Файл префиксов и учет российского/зарубежного трафика

Для начала необходимо пояснить суть проблемы и рассказать, зачем такой учет вообще необходим.

Зачастую бывает, что ваш провайдер выставляет вам счет за пользование интернетом, состоящий из двух цифр: стоимость российского трафика и стоимость зарубежного, т.е. результат обмена информацией с зарубежными серверами. Дело в том, что сам провайдер каким–либо образом покупает трафик у более крупных, магистральных провайдеров которые не связываются с мелкими клиентами. При этом, обмен данными с российскими серверами ведется по одним каналам связи, а для общения с зарубежными серверами используются немногочисленный зарубежные каналы. Надо сказать, что суммарная полоса пропускания данных всех российских провайдеров «за рубеж» составляет всего несколько сот мегабит на всю страну, и таких каналов не так и много (десяток, наверное). Естественно, аренда этих каналов стоит существенно дороже по сравнению с внутрироссийскими и внутримосковскими каналами. Представьте на секунду, сколько стоит проложить трансатлантический подводный оптоволоконный кабель на несколько тысяч километров? Это вам не витую пару через этаж кинуть! :) Вот почему зарубежный трафик стоит дороже российского. Вообще, процентов 80 российского трафика прокачивается через АТС номер 9, что на ул.Губкина, в Москве.

Теперь надо определить, как отличить «российский» и «зарубежный» трафик, и как это делает ваш провайдер. Все основано на глобальной маршрутизации в Интернете, которая осуществляется по протоколу BGP. Грубо говоря, все сети, подключенные к интернету, принадлежат некоей Автономной Системе (AS), которая представляет собой набор IP–сетей (адресных пространств), находящихся под единым управлением. Владелец и руководитель автономной системы определяет политику маршрутизации своих подсетей через своих соседей–провайдеров или крупных организаций, имеющих свои автономные системы. Все такие системы соединены логическими связями друг с другом так, что любая машина в интернете может быть связана с любой другой машиной посредством нескольких (3–7) автономных систем, каждая из которых образована несколькими маршрутизируемыми сетями. Более того, протокол позволяет выбирать оптимальный путь пользуясь большим количеством передаваемой между автономными системами вспомогательной информации, и т.д. Возвращаясь к нашему случаю, ваш провайдер определил маршрутизацию российского трафика (т.е. сетей, принадлежащих российским AS, их список известен) через один канал, а всего остального — через другой, и за другие деньги. Соответственно, и со своих клиентов взимается разная плата.

Теперь, если вы хотите у себя учитывать разделение трафика так, как это делает у себя ваш провайдер, вам по–хорошему надо бы поднять у себя маршрутизатор (Cisco, FreeBSD/Zebra,…), поднять на нем сессию iBGP с провайдером, получать от него таблицу роутинга (она часто меняется) и импортировать ее в вашу программу учета трафика. Существует возможность пользоваться менее точной, но более короткой базой ru–networks.txt, построенной на основании таблицы выделенных организациям блоков IP–адресов, которую у себя поддерживает RIPE. В настоящий момент она содержит в себе список около 400 сетей, которые можно назвать «Российскими». Никто не гарантирует, что ваш провайдер будет получать трафик от некоторых таких сетей не через зарубежные каналы, однако я надеюсь, что точность такого разделения будет вполне приемлемой.

Файл ru–networks.txt находится в каталоге addon дистрибутива. К сожалению, летом 2004 года RIPE прекратило поддержку файла, используемого скриптом для построения этого списка, так что дальнейшее расширение базы «русских сетей» нетривиально.

NeTAMS поддерживает файл префиксов в форматах:

A.B.C.D /mask

A.B.C.D/mask

A.B.C.D/masklen

A.B.C.D /masklen

(разница — в пробеле перед маской). Где mask это представление в виде X.X.X.X, а masklen — в битовом, например: /24.

Также возможно использование символов ! — исключить сеть из списка, и # - комментарий (работает только в начале строки).

Таким образом один и тот же файл можно использовать и для NeTAMS, и для FreeBSD: ipfw table

Чтобы подсчитать RU трафик необходимо прописать:

policy name russian target file /usr/local/etc/ru–networks.txt

unit host name myhost ip 192.168.1.10 acct–policy russian

Помните, что совпадение пакета с прописанной сетью в файле означает совпадение политики: для подсчета зарубежного трафика используйте флаг инвертирования(!)

Расхождение в статистике с провайдером

Иногда пользователи NeTAMS задают вопрос: «У меня расхождение в статистике с провайдером 3%. А у моего друга вообще 30%. Почему это ваш NeTAMS неправильно считает?»

NeTAMS считает правильно.

Давайте разберемся, как это выглядит на практике и из–за чего возможно расхождение.

В общем случае все выглядит следующим образом: к провайдеру извне (Интернет) на пограничный роутер приходят один или несколько линков, дальше трафик попадает в провайдерскую внутреннюю сеть, после чего перенаправляется на роутер доступа, к которому подключены вы сами. Способ такого подключения может быть очень разным: это или ваш персональный выделенный канал, или разделяемый ресурс (беспроводная сеть или общий ethernet). Далее, трафик попадает на ваш сервер учета (где работает NeTAMS или его flow–коллектор), далее трафик доставляется абонентам вашей сети.

Вы, понятное дело, считаете трафик при помощи NeTAMS. Как это делает провайдер? Вариантов несколько:

• NetFlow (на роутере Cisco)

• SNMP (Cisco или поддерживающее такой механизм устройство)

• ip accounting (на роутере Cisco)

• RADIUS (любое поддерживающее устройство)

По определению, NetFlow учитывает трафик ТОЛЬКО НА ВХОДЕ НА ИНТЕРФЕЙС. Это значит, что посчитанный (читай — добавленный вам в счет) трафик может потом быть отброшенным или модифицированным различными механизмами: access–list, policy routing, NAT, и т.п. С другой стороны, сгенерированный самим роутером или кем–то еще в провайдерской сети трафик в вашу сторону — не посчитается.

Счетчики SNMP, наоборот, снимаются на выходе с интерфейса, однако в них нет разделения по протоколам и портам, зачастую единственно что возможно получить — это количество переданных байт в обе стороны. Если вы связаны с провайдером по ethernet, например, то вам посчитаются все ethernet–броадкасты и IP–броадкасты. Вам зачтутся за полезную нагрузку ethernet–заголовки пакета и ip–заголовки: на маленьких пакетах это до 50%. NeTAMS считает только unicast–пакеты, причем берет за полезную нагрузку длину IP–пакета без layer2–заголовка. ip accounting вроде бы также считает на выходе.

Для учета через RADIUS нужно соединение, поддерживающее aaa accounting, т.е. это применимо только к (псевдо)коммутируемым соединениям вроде dialup или VPN–туннелей, а не к типичному ethernet–подключению.

Итак, то что вас насчитал ваш провайдер — это совсем не то, что оказалось на входе канала в вашу сторону. Далее, при передаче трафика к вам данные имеют большой шанс потеряться. Это касается перегруженных каналов, или таких где ошибок по определению много. Если у вас xDSL–подключение на 2 мегабита, а пользователей ЛВС сотни, это означает что трафик в вашу сторону из интернета к провайдеру может временами превышать эти 2Мбит/с, и он учтётся, но при попадании в низкоскоростной канал к вам — будет неизбежно потерян при переполнении пакетных буферов марштуризатора провайдера. При использовании радиоканала данные могут просто «потеряться» в эфире. Кто говорит вам «мы вас по радио подключили на 11 мегабит, какие там потери?» — смело гоните в шею обманщиков. 11 мегабит — это канальная скорость при максимальном уровне сигнала в режиме точка–точка. На практике получается–50% за счет коррекции ошибок, еще–5%..30% за счет коллизий (вы конечно не одни в сети), еще–5%-30% за счет неустойчивой связи (расстояние, помехи, кривые антенны) и снижении скорости передачи. В итоге вместо «11 мегабит» легко может оказаться 200 килобит и 50% ретрансмитов пакетов.

Наиболее надежным и «безопасным» можно считать подключение к выделенному порту коммутатора провайдера через оптической волокно и пару трансиверов на скорости 100 мегабит или 1 гигабит: в таком канале вряд ли что «пропадет».

Даже если на входящую сетевую плату вашего сервера пришло ровно то, что вам посчитал провайдер, это еще не значит что вы сами все посчитали верно. Сплошь и рядом встречаются ошибки настройки файервола, когда какой–то трафик просто не попадает на учет, какой–то попадает дважды. Ваш сервер тоже генерирует трафик, особенно если у вас там почта или веб. Трансляция адресов также может слегка искажать подсчет. Вывод: нарисуйте схему своей сети и распечатайте таблицы правил firewall, посмотрите что считается, а что летит мимо. Проверьте, что в конфигурационном файле NeTAMS заведены все клиенты. Используйте учет по всей внутренней подсети с параметром no–local–pass.

Наконец, никто не застрахован от влияния «человеческого фактора». Автору известен случай, когда провайдер «случайно» приписал в своем биллинге чужую подсеть, и просил платить за нее.

Подведем итоги. Если расхождения «в вашу пользу», можно, в меру совести, забыть о проблеме. Если вам начисляют «больше», то все зависит от того, «на сколько больше»:

• 0.1% до 1% - вам повезло — это очень хороший показатель точности, можно ничего не делать

• 1% до 10% - ошибки в канале — проверьте загрузку линка в сторону провайдера, ошибки в эфире, «неправильные» правила firewall, неучтенный юнит в конфигурации NeTAMS

• 10% до 30% - возможно это «человеческая» ошибка — неучтенный юнит или недонастроенный firewall

• 100% - трафик посчитан дважды — проверьте правило учета пакетов в NeTAMS

В случае необходимости детального разбирательства можно порекомендовать вести мониторинг юнита типа «сеть» средствами service monitor, запрашивать лог–файлы провайдера и вручную сравнивать цифры, делать выборки из таблиц RAW и SUMMARY вручную и опять же сравнивать с провайдерской детализацией, и думать, думать, думать…

Поддержка RADIUS

Сбор произвольных данных через ds_raw

Начиная с версии NeTAMS 3.4.0 (build 3018) появилась возможность учета произвольных данных с использованием сервиса

service data–source 3

type raw

Команда:

rawdata unit name XXX policy YYY in AAA out BBB {as–is|incremental} [time]

Где XXX и YYY — имена юнита и политики

AAA и BBB — значения в байтах, допускается использование окончаний K, M, G.

As–is означает, что переданные значения напрямую добавятся в поток для данного юнита и присуммируются к статистике.

Incremental означает, что к статистике добавится разница между текущим и предыдущим значением rawdata. При этом первое переданное rawdata не учтется (мало ли, там гигантское число уже накопилось пока netams не работал). Если переданное значение меньше запомненного текущего, оно будет сохранено, а записана будет разница со следующим(большим) значением.

Time — время. Если опущено данные будут учтены с текущим временем.

Вопросы безопасности

Поскольку NeTAMS запускается с правами root, и отвечает за подсчет не бесплатного трафика, безопасность всей системы является очень важным фактором. Существует несколько потенциально небезопасных направлений:

• Взлом всей системы через программу

• Взлом защиты самой программы

• Действия, приводящие к неверному учету трафика

Автор программы не несет никакой ответственности за ее использование и за тот ущерб, который (явно или неявно) может быть нанесен кому–либо в результате работы этой программы или ее компонентов. Если вы несогласны с этим утверждением, деинсталлируйте программу и все ее компоненты немедленно!

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

Несанкционированный доступ к программе может быть получен путем узнавания пароля и присоединения к программе через telnet. Для защиты от этого пароли на доступ шифруются через crypt(); в статических HTML–страницах пароли заменяются звездочками (show config unsecure). Однако рекомендуется выполнить следующие действия:

• Установите права на чтение конфигурационного файла и лог–файлов только для пользователя root

• Отмените права на чтение локальных файлов HTML–статистики тем, кому не нужно

• Установите (средствами http–сервера) права на просмотр статистики «извне» только тем, кому нужно

• Отмените возможность логина в программу не с локальной машины:

• service server 0

• login localhost

• Отрежьте правилами firewall вашей системы нелокальное подключение к программе:

• ipfw add 100 allow ip from any to any via lo0

• ipfw add 110 deny tcp from any to me 20001

Неправильный учет трафика возможен при неверном расположении правил ipfw/iptables и при получении статистики netflow от неизвестного источника. Для избежания этого:

• Подумайте, как данные ходят по вашей сети

• Нарисуйте схему сети с именами интерфейсов

• Выпишите список имеющихся правил ipfw/iptables и придумайте номер (место) вашего правила, через которое будет осуществляться «заворачивание» трафика

• Если вы используете трансляцию адресов или bridging, подумайте еще раз

• Если вы используете прозрачный http–прокси, подумайте снова

• Если вы используете подсчет потока NetFlow, ОБЯЗАТЕЛЬНО укажите ip–адрес присылающего статистику роутера в описании соответствующего сервиса data–source.

Сбор статистики по протоколу SNMP

По 10 правил и юнитов

Здесь собрана «лучшая десятка» наиболее интересных и полезных правил (политик) учета трафика, и 10 описаний различных юнитов. Этот документ поможет вам а) лучше понять механизм работы netams и б) наиболее правильным образом создать ваш конфигурационный файл для ваших задач.

политики учета трафика

Задаются в настройках сервиса processor, формат команды имеет вид:

policy { oid XXX | name NNNNN } target ….

• policy name ip target proto ip

• позволяет выделить весь IP–трафик. простейший случай, т.к. под это правило попадает все, что проходит через netams

• policy name www target proto tcp port 80 81 8080 3128

• определяет TCP–трафик по списку портов, фактически сюда попадет весь WWW–трафик

• policy name t_dns target proto tcp port 53 addr 1.2.3.4

• policy name u_dns target proto udp port 53 addr 1.2.3.4

• policy name extdns target policy–or t_dns u_dns

• если вам вдруг хочется посчитать трафик с/до определенного DNS–сервера, расположенного вне вашей сети и имеющего адрес 1.2.3.4, можно воспользоваться этим примером. для начала определите две политики, отдельно для UDP и TCP (DNS использует оба!), затем скомбинируйте их при помощи правила с логическим ИЛИ

• policy name remote target units oid 0ABCDF

• unit net oid 0ABCDF name remotelan ip 215.236.28.0/24

• если у вас есть удаленный офис, в котором работает подсеть 215.236.28.0/24, можно выделить весь трафик между машинами вашей сети и этой удаленной подсетью. юните назначения target может быть любым — хостом, сетью, кластером. полезно также, если вас интересует трафик до какого–то вашего сервера, расположенного снаружи у провайдера, на collocation.

• policy name anekdotes target addr 217.16.28.51

• аналогичный предыдущему, если вас интересует трафик только до одного определенного ip–адреса, возможно обойтись даже без задания отдельного соответствующего юнита.

• policy name rus target file /etc/ru_networks.txt

• по этой политике подсчитается трафик, предназначенный для сетей, перечисленных в файле префиксов. там может содержаться отображение вашей национальной сети (украинской, русской, молдавской), полученное из базы RIPE или сгенерированное из BGP view

• policy name cust1_in target proto ip ifindex s10

• policy name cust1_out target proto ip ifindex d10

• policy name isp_up_in target proto ip ifindex s8

• policy name isp_up_out target proto ip ifindex d8

• если ваш маршрутизатор Cisco работает с несколькими каналами «наружу», и каждый подключен через свой физический интерфейс, возможно использовать поле номера интерфейса из потока NetFlow.

• policy name worktime target time 9–18 day Mon–Fri

• по этой политике учтётся только трафик, прошедший с 9 до 18 часов в дни с понедельника по пятницу — рабочее время

• policy name sun_night target day Sun time 00:00–06:00

• по этой политике учтётся только трафик, прошедший с 0 до 6 утра воскресенья

• policy name smb target proto tcp port 135 139 445

• policy name day target time 8–20

• policy name daynotsmb target policy–and day !smb

• таким образом можно отделить весь дневной не–SMB трафик. обратите внимание на комбинацию двух ранее определенных политик через логическое И и обращение смысла (!) для учета не–SMB трафика.

создание юнитов

Задаются в настройках сервиса processor ПОСЛЕ политик, формат команды имеет вид:

unit { host | user | cluster | group} { oid XXX | name NNNNN } параметры ….

• unit host name server ip 192.168.0.1 acct–policy ip

• Создается запись о компьютере с IP–адресом 192.168.0.1, ведется учет всего IP–трафика с/на этот адрес

• auto–units 1 type user naming prefix2 «IP — " group CLIENTS

• unit group name CLIENTS acct–policy ip

• unit net name LAN ip 192.168.0.1/24 auto–units 1 acct–policy ip www

• Производится «автодобавление» в конфигурацию всех работающих в сети ip 192.168.0.1/24 юнитов. Юниты получают свои имена на базе двух последних октетов адреса, политики учета ip и www, и помещаются в группу CLIENTS.

• restrict all drop local pass

• unit net name LAN ip 192.168.0.1/24 no–local–pass

• acct–policy ip www

• unit host name pupkin ip 192.168.0.18 acct–policy ip www

• Пользователь Пупкин будет иметь доступ наружу с адреса 192.168.0.18. При этом если юнита с адресом, например, 192.168.0.19, в системе не прописано, этот юнит будет блокирован несмотря на то что адрес проходит по юниту типа «сеть» (192.168.0.1/24). Причина — параметр «no–local–pass».

• unit host name pupkin ip 192.168.0.18 mac 00:03:47:c5:81:33

• acct–policy ip

• Задает MAC–адрес юниту. Если включена проверка соответствия MAC–адресов, то при появлении в сети «вредителя» с другим MAC–адресом, поставившим себе IP–адрес Пупкина, юнит будет блокирован. Также, если пользователи выходят в сеть через PPPoE и RADIUS, то возможно организовать дополнительную проверку на основе этого адреса.

• unit host name pupkin ip 192.168.0.18

• description «Вася Пупкин, д.32 кв.169, тел. 333–22–77»

• email pupkin@gmail.com acct–policy ip

• Значение параметра «description» будут появляться в HTML–страницах со статистикой, что добавляет удобства администратору. Адрес электронной почты юнита используется для сообщения тому о, например, превышении квоты.

• unit host name pupkin ip 192.168.0.18 bw 64K in acct–policy ip

• Пупкин не сможет ничего скачать со скоростью более чем 64 килобита в секунду.

• ВАЖНО! Чтобы ограничение скорости работало, необходимо пересобрать NeTAMS с включенной опцией HAVE_BW. Это делается так: make distclen && FLAGS=-DHAVE_BW make

• unit user name pupkin ip 0.0.0.0 password ABCDEF

• acct–policy ip parent CLIENTS

• Пупкин, имея пустой IP–адрес по умолчанию, может использовать сервис логинов со включенным параметром set–user–ip, для выхода в сеть с любого локального компьютера, используя веб–интерфейс и указанный пароль.

• policy name ip target proto ip

• policy name russian target file /etc/ru–networks.txt

• policy name www target proto tcp port 80 81 8080 3128

• policy name non–www1 target proto ip

• policy name non–www2 target proto tcp port 80 81 8080 3128

• unit host name pupkin ip 192.168.0.18

• acct–policy ip !russian %www non–www1

• Для Пупкина будем считать статистику по IP–трафику, по разубежному трафику, по WWW–трафику, и по всему остальному кроме WWW. Обратите внимание на политику учета non–www1: на самом деле это «весь IP–трафик», однако до учета дойдет только не–WWW–трафик из–за флага "%". Аналогичного эффекта можно добиться, если применить политику «non–www2». Это такая же по сути политика, что и www, однако применена в инвертированном ("!») виде:

• unit host name pupkin ip 192.168.0.18

• acct–policy ip !russian www !non–www2

• Обратите внимание на то что нельзя указывать одно и то же имя политики два раза с разными флагами (например «acct–policy www !www» — неправильно), так как в базе данных статистика сохраняется на основании policy oid, которые должны быть разными

Протоколирование запрошенных ссылок (URL)