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

ВНИМАНИЕ!

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

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

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

© 1998–2005, Антон Л. Винокуров

© 2002–2005, Группа разработчиков NeTAMS

Обработка и исправление документации проведены Владимиром Владимировым

Введение

Программный комплекс NeTAMS предназначен для учета и управления трафиком в вашей IP–сети передачи данных. Он работает на сервере под управлением операционных систем Linux, FreeBSD или Solaris и занимается непрерывным сбором, анализом, фильтрацией и отображением статиски о передаваемой в вашей локальной сети информации. NeTAMS выполнен в виде монолитного процесса–демона и написан на языке C/C++ в виде многопоточного приложения. Он состоит из следующих компонентов (которые здесь будет принято называть сервисами):

processor хранит в себе полные сведения обо всех объектах, подлежащих учету (IP–адреса, подсети), политиках учета, организует передачу сообщений между другими сервисами

data–source поставляет сервису processor данные о прошедшем трафике

storage хранит статистическую информацию, частично конфигурационную информацию

server обеспечивает интерактивное взаимодействие работающей программы с администратором и внешними скриптами через telnet–подобный API

scheduler, html, quota, billing и т.д. обеспечивают вторичные функции обработки статистики, такие как поддержка квот, профилей пользователей биллинга, статических HTML–страниц и прочее.

Поскольку первичным источником информации о трафике является IP–пакет, то основным объектом, статистика по которому учитывается, является IP–адрес. Совместно с адресом хранятся правила (политики) учета и фильтрации, ключ БД и другая информация, совместно образуя единую учетную единицу, или юнит (NetUnit). В настоящий момент поддерживаются следующие типы юнитов:

host — характеризуется единственным IP–адресом

cluster — характеризуется набором (до 12) IP–адресов

net — характеризуется адресом подсети и сетевой маской

user — то же, что и тип host, однако может нести дополнительные параметры, например адрес электронной почты для уведомления или пароль

group — представляет собой логическую группу (объединение) любого количества юнитов любого типа, в том числе и других групп (могут быть вложенными)

Информация о прошедшем трафике может поставляться сервису data–source от операционной системы или от внешнего устройства/приложения. Операционная система может предоставлять механизм перехвата (divert, ipq) и/или копирования (tee, ulog) проходящих через ядро пакетов userland–приложению, каковым является NeTAMS, или отслеживать пакеты, проходящие «мимо» или «через» сетевой интерфейс при помощи библиотеки libpcap. С другой стороны, исходная информация о прошедшем трафике может быть сгенерирована в виде потока сообщений протокола Cisco NetFlow установленным в сети маршрутизатором Cisco или одной из множества свободно доступных программ, снимающих статистику и генерирующих потоки NetFlow. Среди них fprobe (http://www.fprobe.org), ng_netflow (только FreeBSD, /usr/ports/net/ng_netflow), ipfw2netflow и flowprobe (входят в комплект поставки NeTAMS).

Ниже приведен список доступных типов data–source в зависимости от используемой операционной системы

Метода захвата пакетов

Linux

FreeBSD

Solaris

Перехват пакетов у ядра ОС

IPQ

IPFW divert

Копирование пакетов из ядра ОС

IPFW tee

Копирование пакетов, проходящих через сетевой интерфейс

libpcap

libpcap

libpcap

Внешний источник NetFlow

+

+

+

Источник NetFlow на этом же компьютере

flowprobe

flowprobe

flowprobe

ulog2netflow

ipfw2netflow

ng_netflow

Модуль NETGRAPH

+

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

unix hash (Berkley DB)

MySQL (версии 4.0.х и выше)

PostgresSQL

Oracle

Обычно unix hash уже присутствует в операционной системе (его, например, использует sendmail), что упрощает инсталляцию, однако скорость работы, надежность и функциональность оставляет желать лучшего. Рекомендуется использовать SQL–базу данных.

Один экземпляр NeTAMS может иметь несколько настроенных и одновременно работающих сервисов data–source и storage.

Инсталляция

В дистрибутиве есть файл INSTALL, в котором кратко описана процедура инсталляции. Детальное описание следует ниже.

Для ОС Линукс доступна также «сторонняя» инструкция по установке и настройке.

Для успешной работы вашей системы NeTAMS необходимо:

Спланировать архитектуру сети

Установить и настроить операционную систему сервера

Установить и настроить дополнительные приложения

Скачать и установить NeTAMS

Подготовить правильный конфигурационный файл NeTAMS

Для начала, необходимо ответить себе на два вопроса:

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

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

В случае UNIX–маршрутизатора с возможностями ограничения трафика подойдут операционные системы Linux или FreeBSD. Для Linux потребуется модуль IPQ, который есть в большинстве поставок как компонента ядер 2.4.x и 2.6.x и системы iptables. Вы можете проверить его наличие в системе, посмотрев на наличие файла netfilter/ip_queue.o в системе.

Для FreeBSD придется работать через механизм IPFW/divert socket, для чего ядро должно быть скомпилировано с поддержкой «options IPFIREWALL» и «options IPDIVERT». Убедиться в наличии модулей можно, посмотрев в файл /var/log/dmesg.today и поискав там строки «ipfw initialized, divert enabled, …». NeTAMS работает под управлением FreeBSD с версий 4.х вплоть до CURRENT.

Если коллектором трафика будет другое устройство (Cisco или PC–роутер), необходимо отдельно настроить этот коллектор (flowprobe, fprobe, ipfw2netflow под управлением Linux/FreeBSD/Solaris, возможно заработает под OpenBSD/NetBSD) и установить NeTAMS на выделенный сервер. В этом случае требования к производительности аппаратного обеспечения меньше.

На сервер с NeTAMS желательно установить сервер базы данных (MySQL или PostgresSQL) и веб–сервер Apache. Практика показывает, что для нормальной работы сети в 100 узлов потребуется около гигабайта дисковой памяти под базу данных, и порядка 200 мегабайт под статические HTML–страницы с отчетами.

Ниже приведен список пакетов, которые могут потребоваться для установки для ОС Linux (пример взят для системы ALTLinux Master 2.2):

• MySQL–client–4.0.16–alt1.i586.rpm

• MySQL–server–4.0.16–alt1.i586.rpm

• apache–1.3.27rusPL30.16–alt13.i586.rpm

• apache–common–1.3.27rusPL30.16–alt13.i586.rpm

• binutils–2.13.90.0.4–alt2.i586.rpm

• cpp3.2–3.2.1–alt2.i586.rpm

• gcc3.2–3.2.1–alt2.i586.rpm

• gcc3.2–c++-3.2.1–alt2.i586.rpm

• glibc–devel–2.2.6–alt0.6.i586.rpm

• libMySQL–3.23.55–alt1.i586.rpm

• libMySQL–devel–3.23.55–alt1.i586.rpm

• libbfd–2.13.90.0.4–alt2.i586.rpm

• libmm–1.2.2–alt1.i586.rpm

• libpcap–0.7.1–alt3.i586.rpm

• libpcap–devel–0.7.1–alt3.i586.rpm

• libstdc++3.2–devel–3.2.1–alt2.i586.rpm

• make–3.79.1–ipl6mdk.i586.rpm

Если вы хотите использовать сервис html, придется еще ставить

• apache–1.3.27rusPL30.16–alt13.i586.rpm

• apache–common–1.3.27rusPL30.16–alt13.i586.rpm

Если вам надо не только считать трафик, но и фильтровать его (наверняка, в большинстве случаев), надо ставить девелоперский комплект для iptables:

• iptables–devel–1.2.7a–3.1asp.i386.rpm

• kernel–headers–common–1.0–alt2.noarch.rpm

• kernel24–headers–2.4.20–alt13.i586.rpm

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

Для FreeBSD все что нужно (кроме Apache и MySQL) идет в стандартном дистрибутиве.

Вам не надо самостоятельно создавать базы данных и таблицы для NeTAMS — программа сделает это самостоятельно при первом старте.

Теперь необходимо скачать дистрибутив NeTAMS, распаковать, скомпилировать и установить его.

На текущий момент вы можете использовать версию NeTAMS–STABLE, доступную для скачивания тут: http://www.netams.com/download.html, а также NeTAMS–CURRENT (содержащую новые функции и возможно, неустойчиво работающую), которая доступна через anonymous CVS:

cvs–d :pserver:netams@netams.netams.com:/netams/cvs checkout netams

В большинстве случаев вам будет достаточно использовать NeTAMS–STABLE.

Дистрибутивный архив имеет имя вида:

netams–3.2.10.tar.gz

где 3 — номер версии, 2 — номер подверсии и 10 — номер билда.

Распаковываем:

tar zxvf netams–3.2.XXXX.tar.gz

cd netams–3.2.XXXX

Запускаем сборку.

make

Сначала работает конфигурационный скрипт configure.sh. Он создает для вас специальный Makefile, в котором указаны найденные для вашей операционной системы SQL–сервера, пути до конфигурационного и лог–файла по умолчанию, системные библиотеки и прочее. Вы также можете отредактировать этот получившийся файл и изменить некоторые настройки.

Зачастую ошибки компиляции возникают от того, что для каждой версии Линукса пути до заголовочных файлов и библиотек разные. Предлагается дописать необходимые пути в начало скрипта configure.sh и повторить сборку через make distclean && make.

В конечном итоге в каталоге src/ вы должны получить исполняемые файлы netams, netamsctl, flowprobe, ulog2netflow и ipfw2netflow. Запускаем их установку на место: make install

Вот ключи командной строки для запуска netams:

— l создавать и дописывать сообщения о работе в лог–файл (по умолчанию это /var/log/netams.log)

— d не отцепляться от терминала и не уходить в background; лог пишется в терминал

— q не выводить вообще ничего при старте (по умолчанию пишется слово NeTAMS)

— f filename путь до конфигурационного файла, по умолчанию это /etc/netams.cfg для Linux и Solaris и /usr/local/etc/netams.cfg для FreeBSD.

Первоначальная настройка

Скопируйте примерный конфигурационный файл из addon/netams.conf в место, указанное в переменной PATH_TO_CONFIG вашего Makefile, использовавшегося при компиляции. Если вы ставили прогрумму через make install, то файл начальной конфигурации уже на месте. Отредактируйте его.

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

debug none

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

service server 0

login local

listen 20001

max–conn 6

service processor 0

lookup–delay 60

flow–lifetime 300

policy oid 14643C name ip target proto ip

restrict all pass local pass

unit group name ALL

unit user name server ip 192.168.0.1 acct–policy ip

service storage 1

type mysql

service data–source 1

type libpcap

source eth0 # поставьте тут имя вашего сетевого интерфейса!

rule 11 «ip»

service alerter 0

report oid 06100 name rep1 type traffic period day detail simple

smtp–server localhost

service html 0

path /var/html

run hourly

Для FreeBSD добавьте netams_enable=«YES» в /etc/rc.conf

Для Linux убедитесь, что в /etc/rc2.d/ есть правильная ссылка на /etc/ini.d/netams.init.d (хотя во всех линуксах все по–разному)

Запускаем программу:

/usr/local/etc/rc.d/netams–startup.sh start

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

telnet localhost 20001

(укажите логин, «admin»)

(укажите пароль, «aaa»)

в случае успеха вы увидите приглашение к набору команд:

#

Попробуйте выполнить команды «html», «save», «show version», «show config».

Первая команда, html, создаст в каталоге /var/html (указанный в команде path сервиса html) файлы с текущей статистикой и параметрами системы.

Вы должны будете настроить свой веб–сервер, чтобы он отображал эти страницы.

Вторая команда, save, вызывает сохранение текущего выполняемого конфигурационного файла обратно в файл. Это необходимо для сохранения значений ключей БД, присваиваемых объектам автоматически.

Если все четыре команды отработали успешно и вы увидели изменения в конфигурационном файле, вам доступны HTML–страницы и информация о версии показывает пару десятков строк — поздравляем, вы успешно установили NeTAMS.

Внимание!

Начиная я версии 3.4 NETAMS в режиме управления через командную строку работает иначе, чем в версиях 3.3.х. Это связано с переходом на LIBCLI, библиотеку работы с командной строкой. Она позволяет делать такие приятные вещи, как история введенных команд, «стрелочки», редактирование строк и прочее. Более того, интерфейс стал еще ближе к интерфейсу устройств Cisco. Существуют следующие режимы работы:

• непривилегированный

• привилегированный

• привилегированный конфигурационный

В непривилегированном режиме сделать особо ничего нельзя. Он характеризуется приглашением ">" командной строки. Туда можно попасть командой disable из привилегированного режима по умолчанию; это поведение может быть изменено при перекомпиляции (ройтесь в сорцах).

В привилегированный режим вы попадаете после логина в программу. Он характеризуется приглашением "#" командной строки. В этом режиме можно исполнять все команды show, debug и т.д., но нельзя менять поведение (настройку) сервисов и того, что с ними связано. Из непривилегированного режима сюда можно попасть командой enable.

В привилегированный конфигурационный режим можно попасть с помощью команды conf t (сокращенно от configure terminal). Он характеризуется приглашением «(config)#" командной строки.Здесь вы можете запускать и останавливать сервисы, а также настраивать их содержимое. Выход из режима — команда exit.

Эксплуатация

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

• Разобраться с принципами функционирования NeTAMS

• Изучить все сервисы и их команды

• Изучить некоторые специальные моменты и особенности

• Спланировать «как следует» свою концепцию сбора, хранения и отображения информации, список необходимых сервисов

• Составить «полный» конфигурационный файл, донастроить SQL, Apache, почтовую систему, firewall, …

• Научиться вносить изменения в работающую конфигурацию

• Научить пользователей смотреть свою статистику

А вообще, учите матчасть. Читайте документацию по сервисам. Читайте форум. Задавайте там свои вопросы (но сначала попробуйте поискать — может кто–то уже ответил на ваш вопрос). Вы не представляете, как раздражают горе — «администраторы», которые кричат «помогите», не потрудившись открыть и подредактировать Makefile.

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

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

Сервис main представляет собой главный поток, с исполнения которого начинает работу программа. Он определяет основные свойства системы, считывает и разбирает конфигурационный файл, запуская другие сервисы, и впадает в сон до завершения работы NeTAMS. При подаче команд kill, shutdown, reload, возникновении критического сбоя или получении сигнала SIGQUIT сервис main просыпается и пытается остановить все другие сервисы, чтобы корректно закрыть базы данных и убрать перехватчики пакетов.

Сервис processor является ядром NeTAMS, так как именно в нем определяется список объектов, по которым будет произведен учет, и самих правил учета. Все компоненты системы обмениваются между собой сообщениями, например запросами к БД или данными о трафике за некий промежуток времени. Processor обеспечивает диспетчеризацию сообщений. Возможен только один экземпляр сервиса processor программу.

Сервис server обеспечивает возможность присоединяться к работающей программе через tcp–сокет; с помощью команд возможно управление программой и съём статистики.

Сервис data–source обеспечивает поступление данных о трафике вовнутрь программы. В качестве источников данных об IP–трафике могут выступать средства перехвата пакетов систем FreeBSD (divert socket) Linux (модуль ip_queue системы iptables), прослушивания сетевого интерфейса (libpcap), статистика NetFlow версии 5, приходящая от маршрутизаторов Cisco или от любого другого коллектора.

Сервис storage определяет Базу Данных, в которой будет сохраняться статистика и часть конфигурации системы. Это может быть стандартный Berkley DB UNIX hash, который есть в любой системе, или SQL база данных, расположенная на локальной или на соседней машине.

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

Сервис scheduler обеспечивает выполнение заданных команд в запланированное время. Это «виртуальный» сервис, т.к. запускается всегда автоматически и не требует конфигурирования.

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

Сервис monitor организует детальный мониторинг трафика заданных юнитов для последующего «разбора».

Каждый объект в системе (политика, юнит и пр.) имеет свой уникальный номер, так называемый OID, object identificator, который является ключом в базе данных. Он генерируется автоматически случайным образом при создании объекта, так что не забывайте сохранять конфигурационный файл после изменений командой save. Идентификатор представляется в виде шестнадцатеричного числа, записанного шестью символами. Например, запись для юнита типа user выглядит примерно вот так:

unit user oid 02628C name r556–2 ip 10.208.209.40

email anton@localhost parent LAN1 acct–policy ip www rus

Каждый юнит помимо идентификатора OID, и имени, имеет сведения о принадлежности какой–либо группе (он также может не принадлежать никакой группе), о своих параметрах (IP–адрес или, например, маска сети), список политик учета и фильтрации трафика, системную политику, принадлежность к определенному data–source и проч.

В то время как предшественник NeTAMS (aaa+fw) учитывал только ip–only трафик, сейчас есть возможность делить данные по другим признакам. Они определяются при задании политики, policy. Политика может определять правила фильтрации и учета. В любом случае помимо имени и OID, указывается тип политики и target, т.е. принцип по которому будет проведен учет. Например:

policy oid 146633 name all–icmp target proto icmp

policy oid 1574B0 name web target proto tcp ports 80 81 3128

policy oid 153333 name server target units oid 0346E8

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

Если сервис data–source настроен так, что данный пакет «заворачивается» в программу, то анализируется заголовок пакета

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

Для каждого юнита проверяется значение установленной системной политики

Для каждого юнита последовательно перебирается цепочка установленных политик на фильтрацию трафика, проверяется соответствует ли пакет установленной политике. Если после последовательного перебора всего списка пакет «пропущен», аналогично перебирается цепочка установленных правил учета (acct–policy), и если пакет попадает под соответствующее правило, для данного юнита происходит увеличение соответствующего данной политики счетчика, т.е. bytes in/out. Пакет возвращается ядру ОС (data–source ip–traffic) или уничтожается (data–source libpcap или netflow).

Если пакет не пропущен правилом fw–policy или sys–policy, он молча отбрасывается и учет трафика по нему не ведется..

Данные о трафике накапливаются в виде «потоков» (flows), которые периодически (за это отвечает параметр flow–lifetime сервиса processor) сбрасываются в базу данных (таблица raw), дополнительно в системе поддерживаются значения счетчиков о прошедшем трафике с начала текущего часа, дня, недели и месяца для каждой комбинации юнит + политика учета. По истечении соответствующего временного интервала данные о трафике за прошедший интервал все равно остаются в базе (таблица summary), обеспечивая надежность и целостность данных на время случайный или запланированных перезагрузок системы.

Информацию о текущем и прошедшем трафике можно получить, подсоединившись к программе через telnet и набрав команды:

• show list full

• send report to {user_name} on {unit_name} (при настроенном сервисе alerter)

• html (при настроенном сервисе html — и это наилучший вариант)

Сервисы и команды

Информация о командах их параметрах сгруппирована по сервисам. Все команды, описанные в этом разделе, могут использоваться для подготовки конфигурационного файла перед запуском программы. В то же время большинство из них может быть указано при подключении к работающей программе через telnet и вводе соответствующих директив. Некоторые команды требуют рестарта демона (например, изменение пути, где сервис storage хранит свои базы данных). Вы всегда можете получить справку о доступных командах набрав "?» ; для справки о параметрах наберите «имя_команды ?».

Порядок описания сервисов в конфигурационном файле:

• Сервисы main и scheduler (команды debug, user, schedule)

• Сервис processor (таймауты, restrict, policies, units, список БД)

• Сервисы storage (их может быть несколько)

• Сервисы data–source (их может быть несколько)

• Сервис alerter

• Сервис html

• Сервис monitor (их может быть несколько)

• Сервис quota

• Сервис login

• Сервис billing

Каждый сервис стартует командой

service XXX N

где N — номер экземпляра сервиса. Сервисы main и scheduler явно указывать не надо — команды настройки этих сервисов идут в самом начале конфигурационного файла ДО описания остальных сервисов.

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

Сервисы, которые возможны только в единственном варианте, не показывают свой номер.

Для того чтобы отменить введенную команду или удалить объект, необходимо повторить команду и в начале поставить ключевое слово no

Если хочется исполнить последовательность команд, например для настройки каких–нибудь параметров сервиса, команды можно разделять символами "&&" (перед и после — пробелы), например так:

schedule time at–23:30 action «service processor && unit host name pupkin sys–deny && exit»

или так:

send report to admin on LAN+ && html && show perf

[service main]

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

user { oid OID | name user_name }

[real–name user_human_name]

[email email_addr]

[password pass]

[crypted crypted_pass]

[permit permit_state]

Команда, которая задает пользователя системы и его параметры. Только присутствующий в списке user пользователь имеет право управлять программой через TCP–порт, т.е. интерактивно или через API. Таким образом, вы должны создать столько пользователей user, сколько администраторов в вашей сети + отдельный аккаунт, от имени которого будут выполняться веб–скрипты, использующие NeTAMS API.

• oid OID

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

• name user_name

• логин пользователя программы.

• real–name user_human_name

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

• email email_addr

• адрес почты для отправки уведомлений администратору

• password pass

• пароль на вход, не зашифрованный

• crypted crypted_pass

• пароль на вход, зашифрованный. Если в конфигурационном файле был введен не зашифрованный пароль, то он тут же автоматически шифруется, и при выводе show config или save выдается именно шифрованная версия. Команда show config unsecure, которая используется сервисом html для генерации статической страницы с конфигурационным файлом, выводит вместо всех паролей звездочки.

• permit permit_state

• права пользователя в системе, от none до all. Подробнее можно посмотреть в src/security.c

no user { oid OID | name user_name }

Удаляет указанного по имени или OID пользователя из программы.

language { ru | en }

Выбор языка, на котором формируются отчеты сервисами HTML и alerter. Пока действуют только английский и русский.

debug deb_str [deb_str] …

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

deb_str — идентификатор типа отладки:

• none — отсутствие всех видов отладки

• command — введенные пользователем/файлом конфигурации команды

• parse — разбор введенных команд

• sleep — работа механизма синхронизации сервисов

• server — работа сервиса server

• proc_mux — мультиплексор сообщений сервиса processor

• ds_ip — данные ip сервиса data–source

• storage — работа сервиса storage

• alert — работа сервиса alerter

• scheduler — работа сервиса scheduler

• html — работа сервиса html и генерация статических страниц

• monitor — данные по пакетам для указанных units

• login — работа сервиса логинов

• quota — работа сервиса контроля квот quota

• iptree — работа механизма хранения объектов iptree

• flow — работа механизма потоков трафика

• ds_mux — мультиплексор сообщений сервисов data–source

• memory — работа менеджера памяти

• policy — работа по проверке политик для аккаунтов (биллинг)

• billing — работа сервиса биллинга

• aclserver — работа сервиса контроля списков доступа ACL

• bw — работа механизма ограничения скорости передачи данных юнитом

• all — наличие всех видов отладки (включайте осторожно, иначе на экран могут полезть сотни строк в секунду).

no debug deb_str [deb_str] …

Отключает отладку указанного типа. Команда debug none эквивалентна no debug all.

radius auth {nas|web}

login login_str

[password pass_str]

nas–id nas_name

callback–id callback_name

Обеспечивает авторизацию внешнего радиус–сервера (через модуль rlm_netams) согласно внутренней базе паролей netams. См. подробное описание.

mac {control [ alert ] [ block ]} | {fixate}

control выполняет проверку соответствия MAC–и IP–адресов, используя системную таблицу ARP. Проверке будут подвергаться только юниты типа HOST и USER, для которых задан параметр «mac …».

НЕ рекомендуется делать ее очень часто — оптимальным можно считать 1 раз в 5 минут. Задавать такую проверку рекомендуется через service scheduler. Агрументы block и alert задают, что делать при появлении MAC–адреса, отличного от указанного в настройках: отключать юнит через sys–deny–mac и/или отправлять всем администраторам (user XXX … permit all) почтовое сообщение. При «возврате» MAC–адреса обратно заблокированный юнит вновь включается.

fixate производит «дозапись» параметра MAC всем определенным в конфигурационном файле юнитам, которые в данный момент присутствуют в системной таблице ARP. Рекомендуется применять эту команду для создания привязки MAC–IP для работающей системы NeTAMS с уже определенным набором юнитов: через сервис scheduler запланируйте исполнение этой команды раз в 15 минут, а через пару дней отключите задачу и создайте задачу контроля (mac control …)

html

Вызывает создание HTML–страницы сервисом html (если он работает). В большинстве случаев эта команда должна выполняться не вручную, а сервисом scheduler (параметр run XXX сервиса html приводит к созданию соответствующей записи планировшика автоматически)

[service scheduler]

В явном виде описывать этот сервис не нужно: подразумевается, что конфигурационный файл начинается с описания main, после чего идут команды сервиса scheduler.

schedule [oid OID ]

time time_period

action requested_action

Задает расписание, по которому будет исполняться заданная команда.

• oid OID

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

• time time_period

• время или интервал, когда будет выполнена команда:

• <число><указатель_времени>, например schedule time 1min action «show version»

• возможные указатели: sec, min, hour, day, week, month. указанная команда исполнится через соответствующий промежуток времени и будет после исполнения запланирована снова.

• {hourly|daily|weekly|monthly}

• команда будет исполнена в первую секунду начала каждого периода, независимо от времени ее задания. например schedule time weekly action save будет автоматически сохранять конфиг в первую секунду понедельника, т.е. начала недели.

• at–XX:XX

• команда запланируется на заданное время и будет выполняться ежедневно. например schedule time at–22:00 action save

• Если после <time_period> поставить знак '+', то выполнение команды запланируется на 10 секунд позже, чем указано, если знак '-', то на 10 секунд раньше.

• action requested_action

• запланированная команда — любая допустимая. Если в ней несколько слов, заключите ее полностью в кавычки, а если в самой команде нужны кавычки, то используйте апострофы. Если хочется исполнить последовательность команд, например для настройки каких–нибудь параметров сервиса, команды можно разделять символами "&&" (перед и после — пробелы), например так:

• schedule time at–23:30 action «service processor && unit host name pupkin sys–deny && exit»

no schedule oid OID

Отменяет запланированную задачу.

show schedule

Отображает список текущих задач планировщика. Смотри также здесь.

[service server]

listen XXXX

определяет tcp–порт, на котором программа будет ожидать входящих соединений для управления своей работой или сбора статистики. Не поддерживает динамическое изменение!

XXXX — номер порта TCP (1…65535), по умолчанию 20001

max–conn XXXX

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

XXXX — количество одновременных соединений, по умолчанию 6

login { any | localhost }

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

• any

• соединение возможно с любого хоста

• localhost

• соединение возможно только с этой машины (127.0.0.1)

[service processor]

Сервис processor описывает настройки ядра NeTAMS, которое и будет производить учет.

lookup–delay XXXX

определяет периодичность, с которой сервис processor будет просматривать список своих NetUnit, чтобы проверить время существования потоков и сбросить их в базу данных. Чем меньше это время, тем точнее идет «квантование» временных периодов, но тем больше нагрузка на программу. На размер базы данных не влияет.

XXX — время в секундах, по умолчанию 30.

flow–lifetime XXXX

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

XXX — время в секундах, по умолчанию 300.

policy [oid OID] name NAME

[no] target TARGET

[bw { speed in speed out | speed } ]

определяет правило, или политику, по которой для данного объекта (NetUnit) будет производиться фильтрация или подсчет трафика.

oid OID — уникальный идентификатор политики, создается автоматически

name NAME — название политики виде строки (2–8 символов)

hidden — не отображать статистику для этой политики в выводе сервиса HTML (полезно для политики с target layer7–detect)

target TARGET — правило, по которому будет проводиться проверка соответствия политике.

Если перед target стоит флажок no, то указанный TARGET убирается из списка.

• bw { speed in speed out | speed } - позволяет ограничивать входящий и/или исходящий трафик для данной fw политики по отношению к юниту по скорости. Ограничение начинает работать, если по данной fw политике было принято решение DROP. В этом случае пакет НЕ БУДЕТ отброшен, а ВМЕСТО этого он будет пропущен и на него будет проверяться проверка по скорости.

• Параметр speed указывается в битах в секунду; можно применять множители K и M для указания килобит и мегабит. Если не указано направление in или out, подразумевается выставление одинакового лимита скорости на оба направления одновременно. Возможно также задать ограничение скорости напрямую для всего юнита, без политик (см. ниже). ВАЖНО! Чтобы ограничение скорости работало, необходимо пересобрать NeTAMS с включенной опцией HAVE_BW. Это делается так: make distclean && FLAGS=-DHAVE_BW make

•

• Опишем подробнее правила формирования цели (target) политики. Сами политики жестко определены в исходном коде программы и вкомпилированы в обработчик политик трафика. Возможны любые комбинации следующих типов:

• proto XX — номер или имя протокола из файла /etc/protocols

• tos XX — проверка на совпадения с полем TOS IP пакета

• port [s|d|b]num [s|d|b]num … — описывает TCP или UDP трафик на указанные порты. список портов — числа или диапозоны, отделенные пробелом.

• если перед числом стоит буква s(ource) - совпадение происходит только если совпадает порт в поле SRC пакета, d(estination) - в DST пакета, отсутствие буквы или b(oth) - SRC или DST.

• Ограничение на число элементов (отдельных портов или диапозонов) в списке — 10. Диапозоны задаются с помощью двоеточия или тире.

• например: target proto tcp port 25 описывает весь SMTP (почтовый)трафик, target proto tcp port s80:82 s8080 примененная к клиентскому компьютеру (юниту), считает входящий веб–трафик.

• as [s|d|b]num [s|d|b]num … — описывает трафик по указанным AS. список AS — числа или диапозоны, отделенные пробелом.

• если перед числом стоит буква s(ource) - совпадение происходит только если совпадает AS источника пакета, d(estination) - с номером AS получателя пакета, отсутствие буквы или b(oth) - SRC AS или DST AS.

• Ограничение на число элементов AS в списке — 10, диапазоны задаются с помощью двоеточия или тире.

• (Начиная с версии 3.3.0(2266))

• vlan N1 [ N2 ] … совпадает, если пакеты были инкапсулированы с VLAN–тэгом N, применимо к data–source libpcap

• ds N1 [ N2 ] … совпадает, если пакеты пришли от data–source номер N

• units oid XXXX трафик, при том что другая сторона (по IP заголовку) является NetUnit с индексом XXXX

• file YYYY совпадает, если другая сторона (по IP заголовку) совпадает с адресом из файла таблицы префиксов YYYY

• Файл префиксов содержит записи в следующих форматах:

• A.B.C.D /N или A.B.C.D /MASK или A.B.C.D/N или A.B.C.D/MASK

• где:

• A.B.C.D — адрес сети, например 10.1.1.0

• MASK — маска (255.255.255.0)

• N — количество единичных бит в сетевой маске, например 24 (255.255.255.0). Смотрите также подробное описание.

• addr addr … — ip адреса участники соединения.

• ifindex [s|d|b]num [s|d|b]num … — номера (индексы) интерфейсов в таблице роутинга. В настоящее время актуально только для netflow данных.

• ingress|egress — способ сбора netflow информации на роутере. В настоящее время актуально только для netflow v9 данных.

• policy–or [!]{NAME|OID} … [!]{NAME|OID} - политика совпадет, если совпадет проверка ЛЮБОЙ из перечисленных политик. Флажок ! означает инвертирование проверки к которой он относится.

• policy–and [!]{NAME|OID} … [!]{NAME|OID} - политика совпадет, если совпадет проверка ВСЕХ из перечисленных политик. Флажок ! означает инвертирование проверки к которой он относится.

• time timespec — совпадает, если пакет пришел в указанный временной интервал timespec. Это строка, содержащая диапазон времени в часах:минутах (24–часовая схема), при этом нулевые минуты можно пропускать:

• target time 9–18

• target time 00:40–21:30

• day dayspec — совпадает, если пакет пришел в день недели, указанный в dayspec. Это строка, содержащая трехбуквенное название дня недели, или диапазон дней:

• target day Mon–Fri

• target day Sun

default { acct–policy | fw–policy } NAME|OID … NAME|OID

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

restrict all {drop|pass} local {drop|pass}

задает политику фильтрации трафика для случая, когда fw–policy для объекта не определен

all — для всех данных (всех ip–адресов src/dst)

local — для данных, предназначенных объектам, описанным в конфигурационном файле

drop — не пропускать пакеты данного класса

pass — пропускать пакеты

Значение по умолчанию restrict all drop local pass приводит к тому, что для трафика, пакеты которого в заголовке в полях src/dst оба IP–адреса не принадлежат ни одной из описанных в конфигурационном файле машин/кластеров/сетей, этот трафик блокируется. Фактически, это означает что программа будет пропускать только данные с/для зарегистрированных машин «за» маршрутизатор. В случае установления restrict local drop вы обязаны явно для каждого юнита прописать fw–policy. Если для юнита не прописаны никакие политики acct–policy или fw–policy, то это эквивалентно применению к этому юниту параметра no–local–pass, т.е. применение restrict all вместо restrict local.

auto–assign A.B.C.D E.F.G.H

Регистрирует диапазон адресов, начиная с A.B.C.D и заканчивая E.F.G.H в качестве пула для автоматического присваивания IP–адресов вновь создаваемым юнитам. При этом юнит создается при помощи команды:

unit {host|user} name XXX ip auto

В таком случае для всех зарегистрированных диапазонов auto–assign проверяются уже существующие юниты типа user или host, имеющие IP–адреса из заданного диапазона, и назначается следующий незанятый адрес (он выводится в ответ на команду создания). Таким образом, скрипт создания аккаунтов–юнитов может «создавать» новые юниты сам, а адреса присваиваются в автоматическом режиме.

Возможно создание нескольких пулов. В этом случае проверка и выделение IP происходит в порядке следования auto–assign.

auto–units N type {host|user} naming {by–dns| prefix1 PPP |prefix2 QQQ} [group GROUPNAME]

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

• N — номер записи auto–units

• type host или type user — тип создаваемого юнита

• naming — как будет присваиваться имя:

• by–dns — имя будет определяться через DNS, который должен у вас быть уже настроен и обеспечивать обратное преобразование адресов

• Если имя не получено, то в качестве имени будет использоваться IP адрес.

• prefix1 PPP — будет взят последний октет адреса, и спереди перед ним поставлена строчка PPP

• prefix2 QQQ — будут взяты два последних октет адреса, и спереди перед ними поставлена строчка QQQ

• group GROUPNAME — в какую группу помещать созданный юнит (необязательно)(версии начиная с 17 марта 2004).

unit {host|group|cluster|net|user}

[oid OID]

name NAME

parameters

[parent GROUP]

[no–local–pass]

[email addr]

[password passwd]

[description «any describing words»]

[mac «XX:XX:XX:XX:XX:XX»]

[sys–XXXX]

[bw { speed in speed out | speed } ]

[nodefault] [ap–nodefault] [fp–nodefault]

[acct–policy [!][%]p_name [p_name] …]

[fw–policy [!][%]p_name [p_name] … ]

[ds–list 1,2,3…]

[auto–units X]

определение объекта (NetUnit) по которому будет проводиться контроль и учет.

• Тип:

• host — хост, только один IP адрес

• group — группа (возможно пустая)

• cluster — хост с несколькими ip–адресами (кластер)

• net — подсеть, которая определяется сетевым адресом и маской

• user — аналог типа хост, используется для динамического задания ip адресов и привязке к пользователям

• oid OID — уникальный идентификатор сетевой единицы, создается автоматически

• name NAME — название объекта в виде строки (2–8 символов)

• parameters — специфические для данного типа объекта параметры:

• для хоста: ip A.B.C.D — адрес этого хоста

• для группы: нет

• для кластера: ip A.B.C.D [ip A.B.C.E [..]] - список адресов

• для подсети: ip A.B.C.D mask E.F.G.H — сетевой адрес и маска

• для пользователя: ip A.B.C.D — адрес с которого работает пользователь

• parent GROUP [GROUP1 [..]] - название родительских для данного объекта групп

• no–local–pass — при указании этого флага ip–пакет, совпавший с этим юнитом, не будет считаться локальным, к нему применится политика фильтрации restrict all, а не restrict local (полезно для подсетей)

• email addr — адрес электронной почты ответственного за этот юнит человека

• password passwd — пароль для данного юнита. Может использоваться как для авторизации (unit user), так и для просмотра статистики, если включен htaccess yes в сервисе html.

• description «any describing words» — описание юнита, может содержать пробелы и русские буквы (в кавычках).

• mac «XX:XX:XX:XX:XX:XX» — задает аппаратный Ethernet–адрес (MAC–адрес) юнита типа USER или HOST. Используется для проверки соответствия (mac–control …) и RADIUS–авторизации.

• sys-{allow|deny}-XXX — т.н. «системная политика», возможные значения:

• sys–allow — разрешить все, те снять все запреты

• sys–deny — запретить все, остальные запреты тоже остаются

• sys-{deny|allow}-ACTION — запретить|разрешить действие ACTION(auth, block, login, money, quota, mac)

• возможна комбинация нескольких подобных политик.

• sys–deny–OID — запретить работу с юнитом OID вне зависимости от других ограничений

• sys–allow–OID — разрешить работу с юнитом OID вне зависимости от других ограничений

• bw { speed in speed out | speed } - позволяет ограничивать входящий и/или исходящий трафик для данного юнита по скорости. Параметр speed указывается в битах в секунду; можно применять множители K и M для указания килобит и мегабит. Если не указано направление in или out, подразумевается выставление одинакового лимита скорости на оба направления одновременно. Возможно также задать fw–политику ограничения скорости (см. выше). ВАЖНО! Чтобы ограничение скорости работало, необходимо пересобрать NeTAMS с включенной опцией HAVE_BW. Это делается так: make distclen && FLAGS=-DHAVE_BW make

• nodefault, ap–nodefault, fp–nodefault — отменяет, для данного юнита, политики по умолчанию (все, acct–policy или fw–policy, соответственно)

• acct–policy [!][%]p_name — разделенный пробелами список политик учета трафика для данного объекта

! — Если вы ставите восклицательный знак перед именем политики (без пробела), например !all–icmp, то совпадение/несовпадение данной политики применительно к пакету будет ИНВЕРТИРОВАНО, т.е. в данном случае будет учитываться ВЕСЬ НЕ–ICMP трафик.

• % - Если вы ставите знак процента при указании политики acct–policy, это значит, что при совпадении данной политики для пакета, дальнейший просмотр списка политик прекращается и подсчет заканчивается.

• fw–policy [!][%]p_name — разделенный пробелами список политик фильтрации трафика для данного объекта

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

• ! — Если вы ставите восклицательный знак перед именем политики (без пробела), например !all–icmp, то совпадение/несовпадение данной политики применительно к пакету будет ИНВЕРТИРОВАНО, т.е. в данном случае будет пропускаться ВЕСЬ НЕ–ICMP трафик.

• % - Если вы ставите знак процента при указании политики fw–policy, это значит что при совпадении данной политики для пакета дальнейший просмотр списка политик прекращается, и вердикт пропускать/не пропускать пакет будет сделан сразу же.

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

• Перечисляются политики, трафик которых нужно пропускать. Все остальное будет заблокировано. Можно также указать политику ограничения скорости (которая имеет target… bw XX). Флаги [!][%] сохраняют свое действие, но их применение не имеет особого смысла.

• Подробнее про «направление действия» смотрите этот документ.

• ds–list no,[no,no,…] - список источников данных, которые будут связаны с этим сетевым объектом

• auto–units X — номер записи auto–units в сервисе processor, согласно которой будут автоматически создаваться учетные записи для новых хостов в сети. Этот параметр применяется только к юниту типа net. Подробнее об этой функции можно прочитать здесь.

access–script path

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

path — полный путь до скрипта

например:

access–script "/usr/home/anton/script.pl»

при этом скрипт имеет вид:

#!/usr/bin/perl–w

print shift, " ", shift, " ", shift, " ", shift, "\n»;

При наступлении события отключения–включения сервис processor вызывает его с параметрами:

Действие(DENY|ALLOW)

Идентификатор_юнита(OID)

IP(IP)

Причина(QUOTA|LOGIN|…)

[service storage]

type { hash | mysql | postgres | oracle | radius}

Определение типа базы данных:

• hash

• UNIX hash (файлы .db). Есть только учета трафика (нет квот, логинов и биллинга, т.е. только таблицы RAW/SUMMARY). Не рекомендуется для массового применения. Вы должны раскомментировать соответствующую строку–DUSE_HASH в файле addon/Makefile.common и пересобрать программу через make distclean && make

• mysql

• MySQL (www.mysql.com). Поддерживаются версии 4.0.ХХ, 4.1.ХХ и 5.ХХ

• postgres

• PostgreSQL (www.postgresql.com). Поддерживаются версии 7.4.ХХ.

• oracle

• Oracle (www.oracle.com). Работа с базой ведется через OCI (фактически, любые версии базы).

• radius

• Сбрасывание статистики RADIUS–серверу, только на запись, только данные RAW. Для Linux необходимо наличие в системе пакета openssl–devel (или аналогов содержащих md5.h).

path XXX

Определяет каталог в системе, где будут создаваться и храниться файлы базы данных при использовании hash в качестве хранилища данных. при использовании MySQL/PostgreSQL не имеет смысла.

user username

Имя пользователя для подключению к MySQL/PostgreSQL. по умолчанию root

password password

Пароль для подключения к MySQL/PostgreSQL, по умолчанию отсутствует

host hostname

Имя хоста где установлен MySQL/PostgreSQL

dbname database_name

Имя базы данных, по умолчанию «netams»

socket sock_name

Имя UNIX–сокета для общения NeTAMS с SQL–сервером. По умолчанию общение идет через TCP–порт и сокет не используется.

port XXX

Номер TCP–порта, через который идет соединение с MySQL/PostgreSQL. Также номер UDP–порта на котором слушает RADIUS–сервер

retry XXX

Только для RADIUS: Количество повторов посылки accounting–пакета.

timeout XXX

Только для RADIUS: Время ожидания подтверждения получения accounting–пакета.

nas–ip A.B.C.D

Только для RADIUS: IP–адрес (этого) сервера, который подставится в атрибут NAS–IP–Address отсылаемого accounting–пакета. Нужно, если интерфейсов на сервере много, и хочется выбрать один. Без этой команды в качестве адреса подставится то, что первым вернет системная функция gethostbyname(gethostname()).

accept { all | type … } [except type …]

Определяет, какие типы сообщений и какие сервисы будут работать с этим хранилищем. Таким образом, отпадает необходимость указывать тип хранилища в конфигурации каждого сервиса. Возможные типы (type) следующие:

raw summary monitor login quota events oids billing bdata config

Есть специальный тип all, который задан по умолчанию и определяет все типы данных вместе. Можно выборочно исключить один или несколько типов, написав all except type …

[service data–source]

type { ip–traffic | netflow | libpcap | netgraph | raw }

Задает тип источника данных

• ip–traffic

• данные берутся путем перехвата ip–пакетов из ядра через divert socket (FreeBSD) или netfilter (Linux 2.4.x)

• netflow

• данные о прошедшем трафике приходят от маршрутизатора Cisco, отдающего поток информации в пакетах NetFlow, или от любого другого коллектора, поддерживающего NetFlow v.5 (ulog2netflow, ipfw2netfloe, flowprobe)

• libpcap

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

• netgraph

данные передаются от установленного модуля ядра. Только для FreeBSD 5.xx. Смотри этот раздел.

• raw

• данные передаются от произвольного источника (например коммутатор Cisco или сервер Radius) и учитываются через команду rawdata .

source { tee XXX | divert XXX | ipq | ulog NL1 [NL2 … NL32] | A.B.C.D | ifname [promisc] | nodename [divert] }

Задает источник данных:

Для FreeBSD

• tee XXX

• пакеты будут копироваться в программу и параллельно обрабатываться системой, номер divert–порта XXX

• divert XXX

• пакеты будут заворачиваться в программу и она может отдать или не отдать их системе обратно, номер divert–порта XXX

• nodename [divert]

• установится соединение с модулем NETGRAPH ядра nodename. Параметр divert указывает на необходимость проводить авторизацию потока перед его пропусканием. Смотри этот раздел.

Для Linux

Необходимо наличие в системе netfilter.

Подробнее можно прочитать man iptables и на сайте www.netfilter.org

• ipq

• пакеты будут заворачиваться в программу и она может отдать или не отдать их системе обратно. Используется библиотека libipq.

• Для работы должен быть загружен модуль ip_queue (modprobe ip_queue). Чтобы активировать передачу пакетов из ядра, необходимо задать это в firewall, например командой:

• iptables–A FORWARD–j QUEUE …

• ulog NL1 [NL2 … NL32]

• пакеты будут копироваться в программу и параллельно обрабатываться системой, NLx определяет номера мультикаст групп в которых программа будет слушать пакеты отправляемые через ULOG.

• Чтобы активировать передачу пакетов из ядра, необходимо задать это в firewall, например командой:

• iptables–A FORWARD–j ULOG --ulog–nlgroup NLx …

• nlgroup NLx должно быть в границах 1–32

Общие

• A.B.C.D

• поток NetFlow будет идти с хоста (маршрутизатора) с IP–адресом источника A.B.C.D на локальный UDP–порт 20001 или тот, который будет указан в команде listen

• ifname [promisc]

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

• Если указан флаг promisc, то интерфейс будет помещен в promisc mode. По умолчанию — не указан.

listen { 0 | ip } port_number

Задает IP адрес и UDP–порт, на который будут приниматься пакеты NetFlow от источника информации о трафике (коллектора).

clock { remote | local }

Указывает, какое значение текущего времени создания пакета использовать для занесения информации в базу — локальное или указанное в NetFlow–сообщении.

layer7–detect { none | urls }

Включает механизм определения ссылок (URL) в трафике, проходящем через этот сервис data–source. Допустимые значения «none» (выключено) или «urls». Во втором случае, первые несколько пакетов в потоке на порты назначения 80, 81, 8080, 8000, 3128 будут проанализированы на предмет поиска полей Host: и GET. Эта информация может быть учтена через сервис мониторинга (новое поле layer7 в таблице monitor).

rule ID rule_string

Задает системное правило, по которому данные будут попадать в программу:

• ID

• номер правила, для Linux не имеет смысла т.к. правила ставятся в конец цепочки

• rule_string

• правило в виде текстовой строки, которое будет передано системе (Linux или FreeBSD) для установки перехватчика пакетов.

no rule ID

Отменяет правило с номером ID.

[service alerter]

Сервис alerter занимается рассылкой информации о статистике и о работе системы по почте

report [oid 06100] name rep1 type traffic period day detail simple

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

smtp–server smtp_server_name

smtp_server_name задает имя или IP–адрес почтового сервера, через который отправится почта. NeTAMS (сервис alerter) будет устанавливать прямое соединения по TCP–порту 25 на указанный адрес (хост) и использовать протокол SMTP для формирования и отправки письма. Если у вас работает локальный почтовый сервис на той же машине, где и NeTAMS, укажите: smtp–server localhost

[service html]

Сервис html позволяет автоматически создавать статические HTML–страницы с отчетами о трафике и о работе программы

run time_interval

Интервал времени, в формате задачи планировщика, через который будет выполняться генерация страниц. Рекомендуется ставить time_interval равным «hourly — ", т.е. страницы будут создаваться за 10 секунд до окончания каждого часа, и содержать статистику об этом часе.

path /path/to/html/root

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

path /usr/local/www/data/stat/

url url_string

URL (веб–адрес) начальной страницы со статистикой, будет использоваться при построении ссылки на статистику пользователя, присылаемую в ему отчете по электронной почте сервисом quota. Например,

url http://stat.company.ru/traffic/

servlet–url url_string

URL (веб–адрес) сервлета Java, который будет отображать табличное представление статистики для юнита. Например:

servlet–url http://stat.company.ru:8010

htaccess { yes | no }

Включает и выключает механизм автоматической защиты каталогов с помощью файлов .htaccess и .htpassword. При этом используются пароли администратора NeTAMS (те, которые задаются в «user… crypted…» в начале конфигурационного файла и собственно пароли на юниты («unit … password …»). При этом администратору доступны любые подкаталоги веб–дерева, а пользователям — только их собственные.

client–pages { all | groups | none | group GG1 GG2 … }

Показывает, будут ли создаваться клиентские страницы для веб–представления статистики:

• all — будет создаваться все

• groups — только общая статистика и статистика подкаталоги для юнитов типа «группа»

• none — только общая статистика

• group GG1 GG2 … — клиентские статистики только для перечисленных групп и содержащихся в них юнитах (не рекурсивно). Чтобы добавить или удалить группу в списке, необходимо дать команду с новым списком полностью. (версии начиная с 17 марта 2004).

account–pages { all | none }

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

client–pages none

account–pages all

display–top N

Включает механизм генерации статических страниц, показывающих TOP N (N — число, желательно порядка 10) потребителей трафика (юниты типа USER и HOST) для периодов времени с начала часа, дня, недели и месяца.

display–health { yes | no }

Включает и выключает механизм автоматического отображения «здоровья» системы (аналогично show health), т.е. свободного места на жестком диске и загрузки процессора. По умолчанию–выключено.

[service monitor]

Сервис monitor позволяет осуществлять запись данных из заголовков пакетов, относящихся к указанным юнита. При этом в базе данных сохраняется не только информация о локальном источнике–получателе пакета, размере и времени, но и об удаленной стороне. Таким образом, становится возможным узнать не только то, КТО качал, а ОТКУДА качал. Начиная с версии NeTAMS 3.2, информация о трафике поставляется сервисами data–source уже в суммированном, агрегированном по локальному адресу виде (потоки), поэтому ПОПАКЕТНЫЙ мониторинг невозможен. Вместе с тем, такое поведение позволяет СУЩЕСТВЕННО сэкономить место в базе данных.

monitor to { storage N | file XXXX | xmlfile XXXX | netflow IP PORT}

Задает направление вывода информации о мониторинге. Мониторинг позволяет собирать в текстовом файле или базе данных информацию о каждом IP–пакете или NetFlow–записи, обработанной NeTAMS. Эту детальную информацию можно затем отфильтровать для составления специфических отчетов

• storage N

• идентификатор SQL–хранилища, куда пойдет запись

• file XXXX

• имя (путь) до текстового файла с выводом мониторинга

• file XXXX

• имя (путь) до текстового файла с выводом мониторинга в XML формате

• netflow IP PORT

• IP и порт на который будут отслыаться netflow v5 данные

• (начиная с версии 3.4.0)

monitor unit { N | XXXX }

Определяет юнит, который необходимо мониторить

• N идентификатор (OID) юнита

• XXXX — имя юнита

no monitor unit { N | XXXX }

Отменяет мониторинг указанного юнита

no monitor to …

Отменяет мониторинг в указанный получатель

show monitor

Отображает текущее состояние мониторинга, смотри здесь.

Начиная с версии 3.4.0 добавлена возможность мониторить в одном сервисе monitor сразу в несколько получателей. И остутвует ограничение на число сервисов monitor, которые могут мониторить один юнит.

[service quota]

Основные свойства:

Хранение информации о квотах клиентов в базе SQL. В настоящий момент поддерживается MySQL и Postgres.

Возможность задания политики учета (контроля), параметров оповещения по умолчанию.

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

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

Возможность гибкого управления параметрами оповещения при срабатывании и возвращении квоты.

Первоначальную настройку необходимо провести при неработающем демоне NeTAMS.

Допустим, что данные уже хранятся в базе данных MySQL, определенной в сервисе data–source с номером 2:

service data–source 2

type mysql

Для работы сервиса quota необходимо будет указать номер сервиса–хранилища данных:

service quota 0

storage 2

После этих операций запустите NeTAMS. Все остальные настройки можно выполнить при работающей программе. Проверить, работает ли сервис, можно:

Просмотром лог–файла программы

Просмотром списка таблиц SQL–базы NeTAMS: mysqlshow netams (должна появиться таблица «quota»)

Подключившись к программе через telnet–интерфейс и выполнив команду show quota

Для настройки параметров сервиса quota необходимо подключиться к программе через telnet–интерфейс, перейти в режим настройки сервиса командой

service quota 0

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

policy XXX

Задает политику учета (acct–policy), которая будет использоваться при проверке квот. Это политика по умолчанию для всех, существует возможность переопределить ее для конкретного юнита. Если не указано, используется первая политика из определенных policy XXX сервиса processor.

block–policy XXX

Задает политику блокировки (fw–policy), которая будет добавляться к набору политик блокировки юнита при превышении квоты. Это политика по умолчанию действует на все юниты, существует возможность переопределить ее для конкретного юнита. При отсутствии этой команды будет использоваться только механизм sys–deny–quota. Про «направление действия» смотрите этот документ.

ВАЖНО!

Появление этой команды потребовало изменения схемы таблицы QUOTA в базе данных. Если вы проводите «чистую» инсталляцию NeTAMS или можете себе позволить удалить существующую таблицу QUOTA, написанное далее вас не касается. Если вы проводите обновление с версии 3.2.0, 3.2.1 или STABLE до 10.02.2005, необходимо вручную модифицировать схему БД. Для этого достаточно выполнить следующие SQL–команды:

alter table quota add column block_policy INT default 0;

alter table quota add column block_policy_flags INT default 0;

soft–treshold N

Задает порог срабатывания «мягкой квоты» для юнита, в процентах от «жесткой квоты». Ранее размер мягкой квоты можно было указывать независимо для каждого типа квоты (например «входящий в день, исходящий в неделю»), теперь это значение одно. По умолчанию определено в src/netams.h (S_QUOTA_DEF_soft_treshold) и равно 80%. Допустимые значения от 0 до 100, значок "%" ставить не нужно. Значение «0» отключает «мягкие квоты» совсем.

delay N

Интервал времени между периодическими проверками всех юнитов на наступление момента срабатывания квоты. Задается в секундах. По умолчанию значение 10 сек., которое объявлено в в src/netams.h (S_QUOTA_DEF_delay).

storage N

Номер сервиса storage, в котором будет создана и использоваться таблица quota. Этот параметр нельзя указывать (изменять) при работающей программе.

set {name XXX | oid YYY}

[policy XXX]

[block–policy XXX]

[soft–treshold N]

[active|inactive]

[notify [{soft|hard|return} {«{none}»|[«{owner}»] [YYY]}]]

[hour … ]

[day …]

[week …]

[month …]

Задает конкретные настройки для юнита. Параметры policy, soft–treshold и notify переопределяют те, которые заданы глобально для сервиса в целом. Вызов этой команды приводит к изменению записи в таблице quota SQL–сервера, но не отражается в конфигурационном файле.

• name XXX | oid YYY}

• Задает имя или OID юнита, с которым производится работа. Это единственный обязательный параметр.

• policy XXX

• Определяет политику учета (acct–policy), которая будет использоваться при проверке квоты для данного юнита. Задается по имени политики.

• block–policy XXX

• Определяет политику блокировки (fw–policy), которая будет применяться к юниту при превышении квоты. Задается по имени политики.

• soft–treshold N

• Задает конкретное значение порога «мягкой квоты» для данного юнита, в процентах от «жесткой квоты». Значение «0» отключает «мягкую квоту» для данного юнита совсем. Допустимый диапазон значений от 0 до 100.

• active|inactive

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

• notify {при_условии} {кого}

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

• Условие ({при_условии}) - это одно из событий:

• soft — произошло переполнение «мягкой» квоты. Необходимо предупредить пользователя, не отключая его.

• hard — произошло переполнение «жесткой» квоты. Необходимо предупредить пользователя о том, что он отключен, и отключить его.

• return — по прошествии времени (например, начался новый месяц) пользователь должен быть включен и оповещен об этом.

•

• Получатель ({кого}) - персона, которую оповещать. Оповещены о наступлении события могут быть и/или собственно владелец юнита (при условии что юнит имеет тип user и для него установлен параметр email), а также один из заведенных в программе пользователей (user), например сам администратор сети. Возможные значения:

• {owner} - владелец юнита

• username — имя или OID пользователя (администратора).

Примеры (предположим ранее определено user name admin email root@localhost ):

notify soft {owner}

notify hard {owner} admin

notify return admin

• [hour … ], [day …], [week …], [month …]

• Задает значения квот на период времени. Формат:

• time_spec amount {in|out|sum},

• где timespec={hour|day|week|month}, amount — значение квоты (в байтах, но можно использовать модификаторы K, M, G), {in|out} - направление квотируемого трафика, {sum} - суммарный трафик (в обоих направлениях). Если необходимо сбросить значение квоты для определённого направления, то надо задать её равной 0. Например:

set name user1 month 0 in

В этом случае будет сброшена месячная квота на входящий трафик.

Значения параметров по умолчанию можно поменять в соответствующей секции файла src/netams.h и последующей полной пересборкой программы (make clean; make). Ниже приведен их список:

#define S_QUOTA_DEF_soft_treshold 80

#define S_QUOTA_DEF_delay 10

#define S_QUOTA_DEF_notify_soft 1

#define S_QUOTA_DEF_notify_hard 1

#define S_QUOTA_DEF_notify_return 1

Исполнение команд вида set … приводят к модификации внутренних структур программы (точнее, заполнению полей структуры u->quotadata юнита u), а также к модификации таблицы quota текущей указанной SQL–базы данных. Как обычно, если такой таблицы не существует, она создается автоматически при первом запуске. Формат таблицы можно посмотреть через вызов команды mysqlshow netams quota. Не пытайтесь редактировать SQL–таблицу quota извне своими программами. Все записи должны вноситься скриптами или вручную через telnet–интерфейс программы (команда set).

Ниже приведен пример применения сервиса контроля квот для небольшой сети. Постановка задачи следующая:

Сеть построена на маршрутизаторе FreeBSD 4.7 / NeTAMS 3.1(2176)

Локальная сеть объединяет порядка 10 компьютеров с адресами 192.168.0.X

Ряду компьютеров необходимо организовать квоты на выход в Интернет, порядка 3 Мб входящего трафика в день и 100М в месяц.

Необходимо отправлять оповещения о наступлении мягкой квоты (75%), жесткой квоты и возвращения доступа пользователям, жесткой квоты — администратору.

Учитывать необходимо только HTTP–трафик.

Ниже приведен полный конфигурационный файл NeTAMS:

debug none

user oid 01327B name admin real–name Konstantin email AAA@mail.ru permit all

schedule oid 08FFFF time hourly–action html

#services configuration

service server 0

login any

listen 20001

max–conn 6

service processor 0

lookup–delay 20

flow–lifetime 60

policy oid 146633 name all–ip target proto ip

policy oid 147C83 name http target proto tcp ports 80 8080 81 3128 443

restrict all pass local pass

unit group oid 0574B0 name LAN acct–policy all–ip

unit group oid 05431B name WAN acct–policy all–ip

unit host oid 021949 name server ip 192.168.0.1 acct–policy all–ip

unit host oid 02238E name Andrew ip 1.3.168.142 acct–policy all–ip http

unit net oid 0446E8 name local ip 192.168.0/24 acct–policy all–ip

unit net oid 043D1B name all ip 0.0.0.0 mask 0.0.0.0 acct–policy all–ip

unit host oid 02507E name 02 ip 192.168.0.10 acct–policy all–ip http

unit host oid 022EB1 name 03 ip 192.168.0.11 acct–policy all–ip http

unit host oid 0241B7 name 07 ip 192.168.0.12 acct–policy all–ip http

unit host oid 0279E2 name 09 ip 192.168.0.13 acct–policy all–ip http

unit host oid 027545 name 11 ip 192.168.0.14 acct–policy all–ip http

unit host oid 02515F name 12 ip 192.168.0.15 acct–policy all–ip http

unit user oid 025BD0 name 13_1 ip 192.168.0.16

email user08@a.ru acct–policy all–ip http

unit host oid 021220 name 14 ip 192.168.0.17 acct–policy all–ip http

unit user oid 024DB1 name 13_2 ip 192.168.0.18

email user09@a.ru acct–policy all–ip http

unit host oid 020216 name 16 ip 192.168.0.19 acct–policy all–ip http

unit host oid 021F16 name 17 ip 192.168.0.20 acct–policy all–ip http

unit host oid 021190 name 50_1 ip 192.168.0.21 acct–policy all–ip http

unit host oid 0266EF name Localnet ip 192.168.0.22 acct–policy all–ip http

unit host oid 02140E name TPSO–1 ip 192.168.0.23 acct–policy all–ip http

unit host oid 023352 name TPSO–2 ip 192.168.0.24 acct–policy all–ip http

unit host oid 02109C name 07–2 ip 192.168.0.25 acct–policy all–ip http

unit host oid 020DED name 19 ip 192.168.0.26 acct–policy all–ip http

unit user oid 027FDC name 15_1 ip 192.168.0.27

email user05@a.ru acct–policy all–ip http

unit user oid 021BEF name 15_2 ip 192.168.0.28

email user02@a.ru acct–policy all–ip http

unit user oid 0241A7 name 15_3 ip 192.168.0.29

email user04@a.ru acct–policy all–ip http

unit user oid 026B68 name 15_4 ip 192.168.0.30

email user06@a.ru acct–policy all–ip http

unit host oid 024E6A name 08_1 ip 192.168.0.31 acct–policy all–ip http

storage 1 all

service storage 1

type mysql

service quota 0

policy http

soft–treshold 75

notify soft {owner}

notify hard {owner} admin

notify return {owner}

storage 1

service data–source 1

type ip–traffic

source divert 199

rule 5 «ip from any to any via rl0»

service alerter 1

report oid 06100 name rep1 type traffic period day detail simple

smtp–server localhost

service html 1

path /home/www/traffic

language en

run hourly

После установки этого конфигурационного файла необходимо внести в NeTAMS/SQL реальные значения для параметров квот пользователей. Очень подходит для этого утилита netamsctl из дистрибутива :

netamsctl «service quota 0 && set name 12 day 3M in month 150M in && exit»

netamsctl «service quota 0 && set name 13_1 day 3M in month 100M in && exit»

netamsctl «service quota 0 && set name 13_2 day 3M in month 100M in && exit»

netamsctl «service quota 0 && set name 15_1 day 3M in month 100M in && exit»

netamsctl «service quota 0 && set name 15_2 day 3M in month 120M in && exit»

netamsctl «service quota 0 && set name 15_3 day 3M in month 100M in && exit»

netamsctl «service quota 0 && set name 15_4 day 3M in month 100M in && exit»

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

[service login]

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

Основные свойства:

Хранение информации о доступе клиентов в базе SQL.

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

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

Перенос блокировки из сферы системных политик на отдельный уровень, что позволит одновременно использовать сервисы login и quota

Поддержка типа юнита unit user, что дает возможность «роуминга» пользователей, т.е. авторизации с любой машины в сети при привязке статистики не к IP–адресу, а к пользователю.

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

service data–source 2

type mysql

Для старта сервиса login необходимо будет указать номер сервиса–хранилища данных:

service login 0

storage 2

После этих операций запустите NeTAMS. Все остальные настройки можно выполнить при работающей программе. Проверить, работает ли сервис, можно:

Просмотром лог–файла программы

Просмотром списка таблиц SQL–базы NeTAMS: mysqlshow netams (должна появиться таблица `login')

Подключившись к программе через telnet–интерфейс и выполнив команду show config

Команды настройки сервиса login, которые сохраняются в конфигурационном файле, приводят только к установке соответствующих параметров сервиса, но не более. Собственно для обеспечения авторизации отдельных клиентов необходим отдельный набор команд, которые задаются в контексте все в том же сервисе login. Вся информация о паролях пользователей и их правах доступа и значениях таймаутов хранится в SQL–таблице login. Ее формат приведен ниже:

+------------------+------------------+------+-----+---------+-------+

| Field | Type | Null | Key | Default | Extra |

+------------------+------------------+------+-----+---------+-------+

| unit_oid | int(10) unsigned | | PRI | 0 | |

| password | varchar(32) | YES | | NULL | |

| inact | int(10) unsigned | YES | | NULL | |

| abs | int(10) unsigned | YES | | NULL | |

| last_changed | int(10) unsigned | YES | | NULL | |

| last_opened_time | int(10) unsigned | YES | | NULL | |

| last_opened_ip | int(10) unsigned | YES | | NULL | |

| last_opened_mac | varchar(18) | YES | | NULL | |

| def_state | int(11) | YES | | NULL | |

| curr_state | int(11) | YES | | NULL | |

+------------------+------------------+------+-----+---------+-------+

• unit_oid — Идентификатор (OID) юнита, является уникальным ключом к базе данных

• password — Пароль пользователя. Никогда не пытайтесь поменять его извне программы путем прямой записи в SQL.

• inact — Величина таймаута неактивности для данного пользователя

• abs — Величина абсолютного таймаута для данного пользователя

• last_changed — Время (в формате UNIXTIME) последнего изменения записи

• last_opened_time — Время (в формате UNIXTIME), когда был в последний раз предоставлен доступ юниту

• last_opened_ip — IP–адрес, с которого был предоставлен доступ юниту

• last_opened_mac — MAC–адрес, с которого был предоставлен доступ юниту

• def_state — Режим доступа этого юнита по умолчанию (например, сразу после старта программы). 0 означает отсутствие доступа, 1 означает разрешения доступа.

• curr_state — Текущий режим доступа этого юнита. 0 означает отсутствие доступа, 1 означает разрешения доступа. К сожалению, по наступлении таймаута не сбрасывается (баг).

При старте сервиса происходит считывание всех доступных записей о юнитах из базы SQL/таблицы «login» в память программы и заполнение соответствующих полей в структурах, описывающих юниты. Если для какого–то юнита нет информации о таймаутах (т.е. соответствующей по индексу OID строки в таблице), то для данного юнита сервис login не будет работать и вопрос о доступе будет определяться работой других механизмов (fw–policy, sys–policy, quota и пр.). Это обеспечивает «прозрачную» работу уже настроенной системы.

Для случая, когда в базе данных есть запись о юните, информация о таймаутах и пароле копируется в соответствующие поля данных о юните. При этом текущее состояние доступа (u->logindata->c_state) становится равным значению по умолчанию (def_state из таблицы). Каждые delay секунд сервис проверяет возможность доступа, и при необходимости отключает юнит обнулением переменной u->logindata->c_state. Она проверяется при каждом прохождении пакета сервисом data–source.

Не пытайтесь редактировать SQL–таблицу login извне своими программами. Все записи должны вноситься скриптами или вручную через telnet–интерфейс программы. Для этого существует три команды сервиса login: set, login и logout. Их поведение и параметры описаны ниже.

Для полного контроля над процессом логинов и записи всей служебной информации в лог–файл и консоль служит новый параметр встроенного отладчика «debug login»

Для вывода информации о логинах служит команда (глобальная, НЕ сервиса login) «show login {name AAA | oid BBBB}»

Написание администраторского веб–интерфейса по привязке юнитов к сервису логинов и клиентского по управлению паролями и параметрами оставляется на потребителя программы NeTAMS. В настоящий момент реализован только примитивный скрипт веб–авторизации по паролю. Он идет в комплекте поставки NeTAMS в каталоге cgi–bin/ и называется login.cgi. Скрипт требует файлов logo–small.gif и netams_api.pl (последней версии), которые находятся в том же каталоге.

Для работы скрипта нужен веб–сервер, интерпретатор Perl и прямые руки администратора. Рекомендуется:

Использовать протокол HTTPS для доступа к скрипту авторизации

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

Сделать простой URL и раздать его клиентам для выставления иконки на desktop, например https://loginserver/login.cgi

Необходимо исправить несколько первых строчек скрипта с указанием параметров подключения и путей до каталога со статистикой; можно также исправить его HTML–интерфейс.

Написание скрипта автоматического логина пользователя при входе в виндовс, или при авторизации в домене Windows (через скрипт профиля или групповую политику) оставляется на совести заинтересованных лиц.

default–inact N

Устанавливает значение времени неактивности клиента по умолчанию. Применяется, если при настройке параметров сервиса login для заданного юнита не было указано конкретное время неактивности. Задается в секундах. По умолчанию значение 0.

default–abs N

Устанавливает значение времени абсолютного таймаута клиента по умолчанию. Применяется, если при настройке параметров сервиса login для заданного юнита не было указано конкретное время абсолютного таймаута. Задается в секундах. По умолчанию значение 0.

max_inact N

Максимально допустимая величина времени таймаута неактивности, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 43200 сек = 12*60*60.

min_inact N

Минимально допустимая величина времени таймаута неактивности, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 60 сек.

max_abs N

Максимально допустимая величина времени абсолютного таймаута, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 1036800 сек = 24*12*60*60.

min_abs N

Минимально допустимая величина времени абсолютного таймаута, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 60 сек.

min_passwd_length N

Минимально допустимая длина пользовательского пароля. По умолчанию равно 3 символом, однако в настоящий момент проверки не производится.

delay N

Интервал времени между периодическими проверками всех юнитов на наступление таймаута. Задается в секундах. По умолчанию значение 10 сек.

relogin {yes|no}

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

set–user–ip

Указывает на необходимость в случае успешной авторизации перезаписать IP–адрес юнита (если он имеет тип user) на текущий; при наступлении таймаута или останове доступа адрес сбрасывается в 0.0.0.0. Принимает значения yes или 1 (делать перезаписывание) или no или 0 (не делать). По умолчанию равно 0.

set {name AAA | oid BBBB}

[password CCCC]

[inact DDDD]

[abs EEEE]

[mac 0a:0b:0c:0d:0e:0f]

[strict|nostrict]

Записывает в структуру данных юнита в памяти и одновременно в SQL–базу параметры юнита (определяется по имени или номеру OID):

• Пароль (password)

• Таймаут неактивности (inact)

• Абсолютный таймаут (abs)

• Установленный привязанный MAC–адрес юнита (mac)

• Параметр безусловной привязки (strict) или его отмена (nostrict)

Все значения таймаутов задаются в секундах. Они должны быть или равны нулю, или быть в рамках между минимальным и максимальным значением. Если какая–то из величин таймаутов (или обе) равны нулю, то проверка этого типа таймаута для данного юнита не производится. Если какая–то из величин не указана, будет взято значение по умолчанию (определенное соответственно или в заголовочном файле src/netams.h или параметрами управления сервисов default–inact или default–abs).

login {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

Служит для авторизации юнита и открытия к нему доступа. Обязательно указывать имя или OID юнита, а также пароль. Значения IP–и MAC–адреса должны подставляться внешним скриптом авторизации.

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

login:0#login name r546–1a

parse: FAIL: unit with name= r546–1a is not exist

Неправильного пароля:

login:0#login name r546–1 password 123

parse: FAIL: password incorrect

Успешной авторизации:

login:0#login name r546–1 password 123456

parse: OK: login success from ip:0.0.0.0, mac:00:00:00:00:00:00

При этом в лог–файле сервера появится соответствующая запись.

logout {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

Команда отключения пользователя, параметры такие же, как и у login.

[service billing]

NeTAMS разрабатывался изначально не как система биллинга, а как система учета трафика. Вследствие этого основными учетными единицами являются юниты. К сожалению, концепции юнитов, имеющих основным свойством статический IP–адрес, не достаточно для реализации полноценного биллинга. Для решения проблемы был организован новый сервис, service billing, основной целью которого стала «правильная» поддержка других типов учетных единиц — пользовательских аккаунтов.

Как сервис биллинга интегрируется в ядро NeTAMS:

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

а) имя, идентификатор, описание

б) индекс текущего тарифного плана, и того который вступит в действие со след. месяца

в) баланс

г) даты создания, модификации и прочее

д) список ассоциированных юнитов

е) емаил, пароль

ж) статус

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

3. Каждый аккаунт, если не включена его добровольная блокировка, имеет активный тарифный план (и план «на будущее»). Тарифный план характеризуется именем, описанием и списком «подпланов». Этим достигается возможность создания «гибких» планов.

4. Каждый подплан характеризуется:

а) политикой учета трафика. Она автоматически выставится для каждого юнита, который принадлежит соответствию «юнит–аккаунт–план–подплан»

б) количеством включенного в абонентскую плату трафика (раздельно входящий/исходящий, значение в мегабайтах или без лимита)

в) месячная абонентская плата: правило съема этой платы (единовременно/ежедневно и др.)

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

Набор скриншотов с веб–интерфейса управления биллингом:

• Сведения об аккаунте

• Настройки тарифного подплана

• Настройки тарифного плана

• Список юнитов

• Политики учета

• Лог–файл действий с аккаунтом

• Управление отдельным аккаунтом

• Карточка пользовательских сведений об аккаунте; задается шаблоном

subplan N

fee NNN

spread { monthly | daily | hourly }

included { XXX | unlimited } sum |

[ { XXX | unlimited } in ] [ { XXX | unlimited } out ] }

policy MMM

overdraft [ AA in ] [ BB out ] [ CC sum ]

adjust–included {yes|no}

adjust–fee {yes|no}

Команда subplan формирует тарифный подплан, из которого потом можно будет создать сложный тарифный план. Номер подплана N есть короткое число (это НЕ oid).

• fee NNN — определяет количество денег «абонентской платы», снимаемых за месяц, по данному подплану.

• spread { monthly | daily | hourly } - определяет, как будут сниматься эта «абонентская плата» — раз в месяц, раз в неделю или раз в час (в последних двух случаях снимается доля, пропорциональная указанному периоду)

• included { { XXX | unlimited } sum } | [ { XXX | unlimited } in ] [ { XXX | unlimited } out ] } - определяет, сколько (кило-, мега-, гига-)байт трафика включено в абонентскую плату. Величина XXX указывает на точное значение (возможны спецификаторы K, M и G после цифры). unlimited показывает, что включен весь трафик (нет ограничения). Задается ИЛИ раздельно для входящего и выходящего трафика, ИЛИ одно значение для суммы.

• policy MMM — задает заранее описанную политику acct–policy сервиса processor, которая будет применена для учета трафика для юнитов, принадлежащих клиенту.

• overdraft [ AA in ] [ BB out ] - определяет, сколько будет стоить превышение трафика (ИЛИ раздельно входящего и исходящего, ИЛИ суммы) в случае, если скачано больше, чем описано в параметре included

• adjust–included {yes|no} - определяет, будет ли проводиться перерасчет включенного в субплан абонентского трафика, если клиент подключился в середине месяца. Если значение равно «yes» (по умолчанию), то включенный трафик пересчитается пропроционально количеству дней, оставшихся до конца месяца. В противном случае клиент получит возможность бесплатно скачать весь предвключенный трафик.

• adjust–fee {yes|no} - определяет, будет ли проводиться перерасчет масячной абонентской платы, если клиент подключился в середине месяца. Если значение равно «no» (по умолчанию), то абонентская плата спишется полностью независмо от дня подключения, иначе — пропорционально числу оставшихся до конца месяца дней.

Команда subplan не умеет обрабатывать сразу все параметры, поэтому при конфигурировании придётся давать эту команду несколько раз с разными параметрами. Параметры этой команды группируются следующим образом:

subplan N fee NNN spread { monthly | daily | hourly }

subplan N included [ { XXX | unlimited } in ]

[ { XXX | unlimited } out ]

subplan N policy MMM

subplan N overdraft [ AA in ] [ BB out ]

plan N

name AAA

description BBB

[no] subplan N1 N2 N3 …

Команда plan формирует тарифный план, составляя его из подпланов. Номер плана N есть короткое число (это НЕ oid).

• name AAA — задает «короткое» имя для тарифного плана (до 8 символов)

• description BBB — задает «длинное имя», или описание, для плана. Значение BBB можно указывать в кавычках.

• [no] subplan N1 N2 N3 — задает список из ранее определенных тарифных подпланов, формирующих этот план. Каждый тарифный подплан может участвовать одновременно в нескольких тарифных планах. Если указана опция no, то указанный список подпланов будет удален из плана.

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

plan N name AAA

plan N description BBB

plan N subplan N1 N2 N3 …

account NNN

name AAA

[description BBB]

password CCC

plan MM1

nextplan MM2

[beblock | block | unblock]

balance {add|remove|set} ZZ

[credit–limit ZZ]

unit {name AAA | oid NN} {add | delete }

Команда account создает аккаунт, или запись о клиенте, в базе NeTAMS. Эта информация хранится в SQL, не в конфигурационном файле. Число NNN представляет собой объект OID, являющийся ключом в базе данных.

• name AAA — задает короткое имя аккаунту

• description BBB — задает описание аккаунта

• password CCC — задает пароль на доступ аккаунта с своей статистике

• plan MM1 — задает текущий тарифный план (номер MM1 должен соответствовать описанному выше плану)

• nextplan MM2 — задает тарифный план на следующий месяц — таким образом реализуется смена плана клиентом

• [ beblock | block | unblock ] - задает текущее состояние аккаунта: добровольно_блокирован, блокирован_администратором и разблокирован (активен)

• balance { add | remove | set } ZZ — позволяет добавлять, вычитать заданную сумму с баланса (лицевого счета) клиента, или выставлять баланс в указанное значение.

• [credit–limit ZZ] - указывает минимально допустимый баланс клиента, когда он еще не отключается (отрицательное число или 0, т.е. нет кредита).

• unit {name AAA | oid NN} {add | delete } - добавляет или отнимает заранее созданные в service processor юниты, делая их принадлежащими текущему аккаунту.

Подобно командам subplan и plan, команда account конфигурирует параметры аккаунта по одному параметру за команду:

account NNN description BBB

account NNN password CCC

account NNN plan MM1

account NNN nextplan MM2

account NNN [beblock | block | unblock]

account NNN balance {add|remove|set} ZZ

account NNN unit {name AAA | oid NN} {add | delete }

delay NN

Устанавливает интервал времени ( в секундах), который будет использоваться между циклами проверки аккаунтов.

default–credit–limit XX

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

storage MM {all | plans | subplans}

Указывает, в каком хранилище (storage) будет сохраняться биллинговая информация, и какая именно.

show plan [N [account|list]]

Выдает информацию о тарифном плане (планах):

fedora:~#netamsctl show plan

Plan ID 000001 Name «aaa» Desc. «super–puper tarifny plan»

Subplan ID 000001

Fee 10.000000, spread: 'M', policy ip(0B23C6)

Incl. 0 in 0 out, Over. 0.000000/M in 0.000000/M out

Plan ID 000002 Name «bbb» Desc. «plan dlya aktivnyh»

Subplan ID 000001

Fee 10.000000, spread: 'M', policy ip(0B23C6)

Incl. 0 in 0 out, Over. 0.000000/M in 0.000000/M out

Subplan ID 000002

Fee 15.000000, spread: 'M', policy www(0C9869)

Incl. 0 in 0 out, Over. 10.000000/M in 0.000000/M out

show account {XXX [full][bdata] |list}

Выдает информацию о аккаунте (аккаунтах):

fedora:~#netamsctl show account client1 full

Name a1 (01BFEF) BLOCKED SYNC bal: 100.00 cred_lim: — 5.00 plan: aaa

Plan aaa 000001 1107234000 Nextplan aaa 000001 1107234000

Changed 1108397456 Blocked 1108397423 Created 1108397423

Email — Password — Units: client1 08944A

[service acl–server]

Сервис acl–server занимается контролем доступа клиентов через удаленный маршрутизатор. В общем случае для источников данных типов netflow, ulog и libpcap управление трафиком невозможно, т.к. эти источники являются «односторонними», предоставляя данные по трафику безо всякой возможности воздействовать на сам процесс доставки этого трафика. С помощью данного сервиса можно организовать передачу команд вида «открыть–закрыть» на расположенный где–то в сети роутер. Это может быть маршрутизатор Cisco, PC–роутер с генератором потока netflow, или даже локальная машина (роутер/бридж) с настроенным data–source libpcap.

Сервис acl–server появился в NeTAMS начиная с версии 3.3.0 (build 2710). В настоящий момент поддерживается только управление удаленным роутером Cisco по протоколу RSH с набором некоторых стандартных команд. Они передаются на роутер при:

• (пере)запуске NeTAMS

• перезагрузке удаленного роутера

• при изменении системной политики

Эти правила действуют на юниты типа USER и HOST, у которых установлены IP–адреса.

Для начала вам необходимо настроить маршрутизатор Cisco:

no ip rcmd domain–lookup

ip rcmd rsh–enable

ip rcmd remote–host netams 192.168.0.10 root enable

!

ip flow–export source FastEthernet0/1

ip flow–export version 5

ip flow–export destination 192.168.0.10 20001

!

access–list 100 dynamic NETAMS deny ip any any

access–list 100 permit ip any any

!

interface FastEthernet0/1

ip address 192.168.0.1 255.255.255.0

ip access–group 100 in

!

В данном случае внутренний IP–адрес маршрутизатора равен 192.168.0.1, к интерфейсу fa0/1 подключена внутреняя сеть, а в этой сети на адресе 192.168.0.10 висит UNIX–компьюер с запущенным NeTAMS. Поток статистики netflow отправляется роутером туда же.

Хотя и считается, что протокол RSH небезопасный, на самом деле не все так плохо. Если вы явно указали разрешенный IP–адрес, с которого можно принимать команды, и на этом компьютере нет «лишних» клиентов, то все в порядке.

acl–server работает путем установки динамических списком доступа (access–lists) на роутере Cisco, это значит что перезагрузке роутера список потеряется (но будет восстановлен вновь). В данном примере список доступа имеет номер 100, и его динамическая часть имеет имя NETAMS. Обратите внимание на то, что все попадающие в этот список записи будут иметь политику DENY, в то время как сам список будет иметь политику ALLOW. Это значит, что при пустом списке доступа будет разрешен весь трафик, а добавление каких–то новых записей (IP–адресов) будет означать их блокировку. Далее, этот список доступа ставится на «вход» внутреннего интерфейса.

Справочник команд сервиса acl–server:

hostname AAAA [NN]

Задает имя или IP–адрес удаленного маршрутизатора, которым управляем. Опциональный параметр NN — номер TCP–порта, на котором роутер по принимает команды по протоколу RSH (по умолчанию 514).

direction { src|dst }

Определяет, в какое поле (src или dst) записи access–template будет вставлен IP–адрес юнита. Применять совместно направлением access–group на интерфейсе роутера. Например, если у вас записано:

interface FastEthernet0/1

ip access–group 100 in

то для конструкции «direction src» и IP–адреса юнита 192.168.0.10 в случае его блокировки будет исполнена команда:

access–template 100 NETAMS host 192.168.0.10 any

Аналогично, для «direction dst» будет:

access–template 100 NETAMS host any 192.168.0.10

При разблокировании юнита будет послана команда:

clear access–template 100 NETAMS …

dynamic–name AAAA

Задает имя динамической части списка доступа (в данном примере NETAMS)

acl–number NNN [cisco]

Задает номер списка доступа access–list (в данном примере 100), значение по умолчанию: 180. Ключевое слово «cisco» определяет, что удаленная сторона представляет из себя роутер Cisco, а не что–то иное (в данной версии других вариантов нет, так что указывать обязательно).

delay NNN

Задает промежуток времени между периодическими проверками состояния роутера и подачи команд его управления (в секундах). Рекомендуется значение порядка 300 секунд (значение по умолчанию).

set–uptime NNN

Позволяет вручную выставить параметр uptime удаленного роутера, полезно для отладки. NNN — время работы роутера в секундах, с момента последней его перезагрузки.

debug aclserver

Включает отладку сервиса aclserver (это команда сервиса main, НЕ acl–server).

Пример рабочей конфигурации сервиса acl–server, для вышеописанного примера настройки Cisco:

#NeTAMS version 3.3.0 (build 2710) compiled by root@localhost

#configuration built Sun Sep 18 04:15:20 2005

#begin

…

service acl–server 0

hostname 192.168.0.1

direction src

dynamic–name NETAMS

acl–number 100 cisco

delay 100

#end

Пример вывода debug aclserver:

|aclserver: acl server checking every 10 seconds

|aclserver: known: 1, remote uptime: CISCO2 6 5 9 15 4094100

|aclserver: queue u=0F8AEA flag=0 sp_now=0

|aclserver: queue u=03A4C4 flag=0 sp_now=0

|aclserver: message ip=192.168.0.11 action=REMOVE

|aclserver: message ip=192.168.0.12 action=REMOVE

|aclserver: messages processed: 2, failed: 0

|aclserver: acl server checking every 10 seconds

|aclserver: known: 4094102, remote uptime: CISCO26 5 9 15 4094160

|aclserver: messages processed: 0, failed: 0

|aclserver: acl server checking every 10 seconds

|aclserver: known: 4094162, remote uptime: CISCO26 5 9 15 4094160

|aclserver: messages processed: 0, failed: 0

Известные проблемы и направления развития:

• Сделать поддержку нескольких удаленных устройств, различая принадлежность юнитов через ds–list.

• Сделать «обратное» включение, когда политика основного accessl–list по умолчанию — deny, динамического — allow, и добавление записей в список происходит для НЕБЛОКИРОВАННЫХ юнитов.

• Написать клиентские программы для linux, freebsd, solaris, которые работали бы как клиенты сервиса acl–server и делали бы блокировку на удаленной машине.

Команды rotate

rotate log

Перемещает лог–файл в файл с расширением, указывающим на время ротации: "%Y-%m-%d_%H:%M» и открывает новый.

Поддерживается также совместная работа с newsyslog. NeTAMS понимает получение сигнала–1 (SIGHUP) и перезакрывает свой лог.

При старте демона с параметром–l автоматически создается PID–файл /var/run/netams.pid. Необходимо добавить следующую строчку в /etc/newsyslog.conf, чтобы архивировать файл /var/log/netams.log:

/var/log/netams.log 600 7 100 * J /var/run/netams.pid

rotate monitor N

Для сервиса monitor:N, в случае если используется monitor to file, перемещает файл мониторинга в новый с расширением, указывающем на время ротации: "%Y-%m-%d_%H:%M» и открывает новый.

Команды «show XXX»

Различные команды show выдают информацию о состоянии NeTAMS, статистике по трафику, и прочее. Они не сохраняются в конфигурационном файле и предназначены для «разового» исполнения вручную, скриптами или веб–интерфейсом.

show config [unsecure] [oids]

Выдает текущий конфигурационный файл.

Параметр unsecure заставляет заменять в выводимом файле все пароли звездочками, что делает публикацию конфигурационного файла в HTML более безопасной. Сервис html вызывает именно «show config unsecure»

Параметр oids заставляет выводить ID объектов, вместо их имен.

show connections

Выдает список текущих соединений с программой. Пример:

NAME | ID | IDLE | CONNECTED | ADDR | PERMIT

<internal> | 000001 | 6m33s | 17m24s | 0.0.0.0 | all

conn0009 | 000009 | 0s | 1s | 127.0.0.1 | all

show users

Выдает список зарегистрированных пользователей. Пример:

OID | MODE | NAME | REAL NAME | PERMIT

01327B | U | anton | Anton | all

show schedule

Выдает список активных в системе задач. Пример:

OID | INTERVAL | LEFT | ACTION

08FFFF | hourly- | 2564 | html

0841B7 | at–23:15 | 7074 | shutdown

0879E2 | 5min | 294 | show version

show units

[

syspolicy [whereset]

email

hash

name XXX

mac [whereset]

unit_type

]

Выдает список всех юнитов. Пример:

TYPE | OID | NAME | NLP | PARENT | PARAMS

host | 0246E8 | srv | | <> | IP: 195.208.209.5

host | 022EB1 | an | | <> | IP: 195.208.209.20

Если указан параметр name XXX, выводятся данные только для указанного юнита. Если указан параметр syspolicy, выдается таблица текущих системных политик:

OID | NAME | SYSPOLICY

057545 | AA |

0346E8 | vm | sys–deny–money

Если задано show units syspolicy whereset, то в выводимом списке присутствуют только те юниты, у которых что–то установлено (НЕ sys–allow или sys–none).

Для unit_type=user|host|cluster|group|net выводятся только юниты обозначенного типа. Для show units users active будут выводиться только юниты типа user, имеющие ненулевой IP–адрес.

Если указан параметр email, выводятся адреса электронной почты (для тех юнитов, для которых это установлено). Если указан параметр mac выводится таблица заданных IP–и MAC–адресов. Наконец, show units hash выдает состояние хранилища юнитов:

Units HASH: size=4095, 15 units hashed, 15 nodes used, max chain= 1

show processor

Выдает информацию о состоянии очередей внутри сервиса processor

show alerter

Выдает информацию об очереди сообщений к почтовой отправке

show monitor

Выдает информацию о работе сервисов monitor

show version

Информация о выполняемом процессе NeTAMS, его версия и другие системные параметры. Наиболее важная диагностическая команда.

show list [full] [name XXX | OID YY]

Выдает список всех юнитов с указанием политик учета и фильтрации. Если указан юнит (по имени или OID), выдает информацию только для него. Если указан параметр full, выводит также данные о текущем состоянии счетчиков по политикам и flow/hour/day/week/month. Пример:

show list full name linux

OID: 0B23C6 Name: linux Type: user Parent: AA

SYST policy is not set

FW policy list is empty

ACCT policy: OID NAME CHECK MATCH

04643F ssh 90 36

23.07.2004 15:29:10 flow in: 6008 out: 5016

01.07.2004 00:00:00 month in: 796845 out: 1743907

19.07.2004 00:00:00 week in: 734782 out: 1646080

23.07.2004 00:00:00 day in: 99493 out: 134673

23.07.2004 15:00:00 hour in: 36000 out: 42936

04643C ip 90 90

23.07.2004 15:29:10 flow in: 6008 out: 5016

01.07.2004 00:00:00 month in: 912887 out: 5242340

19.07.2004 00:00:00 week in: 912887 out: 5242340

23.07.2004 00:00:00 day in: 608190 out: 3436092

23.07.2004 15:00:00 hour in: 107783 out: 127231

show policy

Выводит список зарегистрированных политик учета и фильтрации трафика. Пример:

TYPE | OID | NAME | PARAMS

acct | 14643C | all–ip | target: proto ip

acct | 14643D | all–icmp | target: proto icmp

acct | 14753D | tcp | target: proto tcp

acct | 14754D | ant | target: units oid 022EB1

acct | 146EFF | russian | target: file /etc/ru–networks.txt

acct | 146EFE | local | target: file /etc/loc–prefix.txt

acct | 146634 | gate | target: units oid 0246E8

show quota [oid ID | name XXX | list]

Выводит текущее состояние системы проверки квот, для указанного по имени или OID юнита или для всех юнитов для которых включена проверка квот. В случае параметра list только перечисляет «включенные» юниты. Пример:

QUOTA: QQQ policy all–ip set sys–deny–quota

UNIT 056255 (AA) SYST: ACCT is NOT present

UNIT 0246E8 (avm) SYST: ACCT is present

HOUR in: 0, quota 300, ratio 0.00% -> [+]

HOUR out: 0, quota 800, ratio 0.00% -> [+]

TOTAL out: 22932, quota 2.00G, ratio 0.00% -> [+]

QUOTA: AAA policy tcp set sys–local–quota

UNIT 0246E8 (avm) SYST: ACCT is NOT present

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

QUOTA: QQQ policy all–ip set sys–deny–quota

UNIT 056255 (AA) SYST: ACCT is NOT present

UNIT 0246E8 (avm) SYST: sys–deny–quota ACCT is present

HOUR in: 420, quota 300, ratio 140.00% -> [-]

HOUR out: 420, quota 800, ratio 52.50% -> [+]

TOTAL out: 23352, quota 2.00G, ratio 0.00% -> [+]

QUOTA: AAA policy tcp set sys–local–quota

UNIT 0246E8 (avm) SYST: sys–deny–quota ACCT is NOT present

В данном состоянии система проверки квот обнаружила превышение и выставила для юнита avm системную политику sys–deny–quota. юнит заблокирован по превышению лимита на входящий за час трафик, о чем свидетельствует знак [-]

show login

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

avm1 (0246E8) opened 14 sec. ago, last used–1 sec. ago

absolute timeout at 106 sec, inactivity at–1 sec.

anb1 (022EB1) opened 6 sec. ago, last used–1 sec. ago

absolute timeout at 114 sec, inactivity at–1 sec.

show stat unit UNIT_NAME PREFIX to now POINTS

Выводит таблицу значений счетчиков для заданного юнита за заданный промежуток времени

• unit UNIT_NAME — имя юнита или его OID

• PREFIX — указатель интервала времени, может быть W или M

• to now — просто слова, пока не используются

• POINTS — сколько строк будет в создаваемой таблице (влияет на точность), пока не используется. В данный момент информация берется из записей «H» таблицы summary БД, поэтому для недельной статистики получается 7*24=168 строк, для месячной 30*24=720 строк.

Формат вывода:

parse: unit avm1 [W] to->now <2>

avm1 0246E8 0 1028781390 2

all–ip all–icmp tcp

0 0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0 0

…

Выводится строка с именем юнита, строка со списком политик (через пробел) и блок из 168 или 720 строк, в каждой из которых 2*число_политик цифр, первая и вторая соответственно значения счетчиков in и out для каждой из политик последовательно, для каждого часа.

show perf filename [header]

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

• filename — имя текстового файла, куда будет записываться информация

• header — ключевое слово, заставляющее программу пересоздать файл статистики и записать в начало его заголовок

Пример работы:

После старта программы набрать

show perf /var/tmp/perflog.txt header

Создастся файл с именем /var/tmp/netams–perflog.txt, содержащий строки вида:

NeTAMS version 3.1(1677) root@srv / Sat Sep 6 13:01:18 MSD 2003

TOD RTM STM LOAD RES LOOP AVG

Задать команду планировщика вида

schedule time 10min action «show perf /var/tmp/perflog.txt»

Каждый час будут добавляться строки вида:

«06.09.2003 13:02:52.9493 50 0.609774 1.20 2896»

show health

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

Current system load: 2%, HTML files folder free disk space: 45%,

Primary storage folder free disk space: 75%

Список всех команд

Информация о командах их параметрах сгруппирована по сервисам.

main

show version

show config [unsecure] [oids]

show connections

show users

show schedule

show units [ syspolicy [whereset] |

email | hash | name XXX |

mac [whereset] | unit_type ]

show processor

show ds

show alerter

show monitor

show list [full] [name XXX | OID YY]

show policy

show quota [oid ID | name XXX | list]

show login

show perf filename [header]

show health

user { oid OID | name user_name }

[real–name user_human_name]

[email email_addr]

[password pass]

[crypted crypted_pass]

[permit permit_state]

no user { oid OID | name user_name }

language { ru | en }

debug deb_str [deb_str] …

no debug deb_str [deb_str] …

radius auth { nas | web }

login login_str

[password pass_str]

nas–id nas_name

callback–id callback_name

mac { control [alert] [block] } | { fixate }

html

save

enable

configure { terminal | … }

rotate log

rotate monitor N

scheduler

schedule [oid OID ]

time time_period

action requested_action

no schedule oid OID

show schedule

server

listen XXXX

max–conn XXXX

login { any | localhost }

processor

lookup–delay XXXX

flow–lifetime XXXX

policy [oid OID] name NAME

[no] target TARGET

[bw { speed in speed out | speed } ]

TARGET=

proto XX

tos XX

port [s|d|b]num [s|d|b]num …

as [s|d|b]num [s|d|b]num …

vlan N1 [ N2 ] …

ds N1 [ N2 ] …

file YYYY

addr addr …

ifindex [s|d|b]num [s|d|b]num …

ingress|egress

policy–or [!]{NAME|OID} … [!]{NAME|OID}

policy–and [!]{NAME|OID} … [!]{NAME|OID}

time timespec

day dayspec

default{ acct–policy | fw–policy } NAME|OID … NAME|OID

restrict all {drop|pass} local {drop|pass}

auto–assign A.B.C.D E.F.G.H

auto–units N

type {host|user}

naming {by–dns| prefix1 PPP |prefix2 QQQ}

[group GROUPNAME]

unit { host | group | cluster | net | user }

[oid OID]

name NAME

parameters

[parent GROUP]

[no–local–pass]

[email addr]

[password passwd]

[description «any describing words»]

[mac «XX:XX:XX:XX:XX:XX»]

[sys–XXXX]

[bw { speed in speed out | speed } ]

[acct–policy [!][%]p_name [p_name] …]

[fw–policy [!][%]p_name [p_name] … ]

[ds–list 1,2,3…]

[auto–units X]

access–script path

storage

type { hash | mysql | postgres | oracle | radius}

path XXX

user username

password password

host hostname

dbname database_name

socket sock_name

port XXX

retry XXX

timeout XXX

nas–ip A.B.C.D

accept { all | type … } [except type …]

data–source

type { ip–traffic | netflow | libpcap | netgraph }

source { tee XXX | divert XXX | ipq | ulog NL1 [NL2 … NL32] |

A.B.C.D | ifname [promisc] | nodename [divert] }

listen { 0 | ip } port_number

clock { remote | local }

layer7–detect { none | urls }

rule ID rule_string

no rule ID

alerter

report [oid 06100] name rep1 type traffic period day detail simple

smtp–server smtp_server_name

html

run time_interval

path /path/to/html/root

url url_string

servlet–url url_string

htaccess { yes | no }

client–pages { all | groups | none | group GG1 GG2 … }

account–pages { all | none }

display–top N

display–health { yes | no }

monitor

monitor to { storage N | file XXXX | netflow IP PORT}

no monitor to …

monitor unit { N | XXXX }

no monitor unit { N | XXXX }

show monitor

quota

policy XXX

block–policy XXX

soft–treshold N

set {name XXX | oid YYY}

[policy XXX]

[block–policy XXX]

[soft–treshold N]

[active|inactive]

[notify [{soft|hard|return} {«{none}»|[«{owner}»] [YYY]}]]

[hour … ]

[day …]

[week …]

[month …]

billing

subplan N

fee NNN

spread { monthly | daily | hourly }

included

{ XXX | unlimited } sum |

[ { XXX | unlimited } in ]

[ { XXX | unlimited } out ]

policy MMM

overdraft [ AA in ] [ BB out ] [ CC sum ]

adjust–included {yes|no}

adjust–fee {yes|no}

plan N

name AAA

description BBB

[no] subplan N1 N2 N3 …

account NNN

name AAA

[description BBB]

password CCC

plan MM1

nextplan MM2

[beblock | block | unblock]

balance {add|remove|set} ZZ

[credit–limit ZZ]

unit {name AAA | oid NN} {add | delete }

default–credit–limit XX

show plan [ N [ account|list] ]

show account { XXX [full] [bdata] |list}

login

default–inact N

default–abs N

max_inact N

min_inact N

max_abs N

min_abs N

min_passwd_length N

relogin {yes|no}

set–user–ip

set {name AAA | oid BBBB}

[password CCCC]

[inact DDDD]

[abs EEEE]

[mac 0a:0b:0c:0d:0e:0f]

[strict|nostrict]

login {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

logout {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

acl–server

hostname AAAA [NN]

direction { src|dst }

dynamic–name AAAA

acl–number NNN [cisco]

delay NNN

set–uptime NNN

debug aclserver

Cisco Netflow

Маршрутизаторы производства Cisco Systems, в современных версиях операционной системы IOS, поддерживают новый метод управления маршрутизацией пакетов, называемый NetFlow. Помимо всего прочего, он дает возможность собирать информацию о статистике и передавать ее внешнему устройству для обсчета. Более подробная информация о NetFlow содержится тут. Маршрутизатор посылает UDP–пакеты со статистикой на некий IP–адрес/порт, где NeTAMS может собрать информацию и обработать ее. Фильтрация трафика в таком случае невозможна, так как пересылку данных осуществляет внешнее устройство. О конкретной настройке netflow export можно почитать тут.

Помимо роутера Cisco, поток данных Netflow может слать один их множества существующих коллекторов: fprobe, ng_netflow, flowprobe, ipfw2netflow, ulog2netflow. Последние три входят в комплект поставки NeTAMS.

Приведем пример команд маршрутизатора:

ip cef

!

ip flow–cache timeout inactive 60

ip flow–cache timeout active 10

!

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

ip route–cache flow

!

ip flow–export version 5

ip flow–export destination 192.168.1.254 20001

Обработчик data–source в конфигурационном файле NeTAMS настраивается следующим образом:

service data–source 1

type netflow

source 192.168.1.1

listen 20001

Полный конфигурационный файл приведен здесь.

Предполагается, что UDP–пакеты NetFlow идут с маршрутизатора, имеющего IP–адрес 192.168.1.1, и поступают на локальный UDP–порт номер 20001 (его и слушает NeTAMS).

ВАЖНО!

По определению, NetFlow учитывает только входящий на роутер трафик. Это вызывает проблемы учета при использовании трансляции адресов. Действительно, пакеты от машин внутренней сети приходят на роутер и учитываются верно, но обратные ответы извне поступают с адресом dst внешнего интерфейса. Поскольку трансляция адресов происходит после учета, то статистика всего входящего трафика будет содержать сумму всего трафика, пришедшего на адрес внешнего интерфейса, и нули для адресов внутренней локальной сети. Для корректного учета, вам необходимо использовать policy routing. Установленная на роутере операционная система должна поддерживать эту функцию. Вот пример конфигурации для Cisco 2514:

ip cef

!

interface Loopback0

ip address 192.168.10.1 255.255.255.0

ip route–cache policy

ip route–cache flow

!

interface Ethernet0

ip address 195.200.200.1 255.255.255.0

ip nat outside

ip route–cache policy

ip route–cache flow

ip policy route–map MAP

!

interface Ethernet1

ip address 192.168.1.1 255.255.255.0

ip nat inside

ip route–cache policy

ip route–cache flow

!

ip nat inside source list 1 interface Ethernet0 overload

ip classless

ip flow–export version 5

ip flow–export destination 192.168.1.254 20001

!

access–list 1 permit 192.168.1.0 0.0.0.255

access–list 101 permit ip any 192.168.1.0 0.0.0.255

route–map MAP permit 10

match ip address 101

set interface Loopback0

При использовании заруливания трафика через раутмап на CPU (loopback) Cisco довольно сильно грузиться CPU, что может существенно занизить производительность устройства начиная с IOS 12.3x в IOS добавились фичи позволяющие избавиться от ненужной нагрузки на CPU маршрутизатора.

Называется фича: Egress NetFlow Accounting

NeTAMS на PC–маршрутизаторе

В большинстве случаев схема подключения PC–роутера к сети следующая: в компьютере имеются две сетевые карты, одна из них ведет в локальную сеть офиса или домашней сети, другая к провайдеру Интернет. Между сетевыми интерфейсами настроена маршрутизация и (возможно) трансляция адресов. Необходимо учитывать трафик пользователей, и при необходимости блокировать некоторым из них доступ во внешнюю сеть.

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

Допустим, что внутренний адрес интерфейса eth1 сервера 192.168.0.1, сетевая маска 255.255.255.0. Компьютеры внутренней сети могут иметь адреса с 192.168.0.2 по 192.168.0.254, в то время как реально пока установлены только три компьютера с адресами .10, .11 и .12.

Необходимо считать общий трафик, трафик только до российских сетей, и весь HTTP–трафик.

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

debug none

user name admin real–name Vasya_Pupkin

password aaa email root permit all

schedule time daily action «send report

to admin on LAN on NETWORK+»

service server 0

login local

listen 20001

max–conn 6

service processor 0

lookup–delay 20

flow–lifetime 120

policy name ip target proto ip

policy name www target proto tcp ports 80

policy name rus target file /etc/ru–networks.txt

restrict all drop local pass

unit group name NETWORK acct–policy ip tcp !rus

unit net name LAN ip 192.168.0.0 mask 255.255.255.0

no–local–pass acct–policy ip tcp !rus

unit host name server ip 192.168.0.1 parent NETWORK

acct–policy ip tcp !rus

unit user name petya ip 192.168.0.10 parent NETWORK password abc

acct–policy ip tcp !rus

unit user name fedya ip 192.168.0.11 parent NETWORK password def

acct–policy ip tcp !rus

unit user name masha ip 192.168.0.12 parent NETWORK password ghi

acct–policy ip tcp !rus

storage 1 all

service storage 1

type mysql

service data–source 1

type libpcap

source eth1

rule 11 «ip»

service alerter 0

report oid 06100 name rep1 type traffic period day detail simple

smtp–server 127.0.0.1

service html 0

path /var/www/traffic

language en

run 5min

htaccess yes

client–pages all

Полезно разобрать весь конфигурационный файл по строчкам.

1 debug none

2 user name admin real–name Vasya_Pupkin password

aaa email root permit all

3 schedule time daily action «send report to admin on LAN on NETWORK+»

Этими командами настраивается сервис main, причем явно писать «service main» не нужно. Вначале отключается вывод всей отладочной информации — это нужно для уменьшения размера лог–файла. Далее, заводится пользователь системы NeTAMS, имеющий в ней административные права (permit all). Указанный пароль «aaa» потом будет храниться в зашифрованном виде. На адрес «root» будут отсылаться уведомления о трафике. Третьей строкой планируется отсылка ежедневных уведомлений о трафике пользователю admin на адрес root@, по юнитам LAN и NETWORK (вместе со всеми входящими в группу юнитами).

Пустая строка за номером 4 отделяет настройки разных сервисов (в данном случае main и server)

5 service server 0

6 login local

7 listen 20001

8 max–conn 6

Этими командами настраивается сервис server, который обеспечивает подключение администратора и скриптов к работающему экземпляру NeTAMS по протоколу telnet. Входящие соединения принимаются только на локальный адрес 127.0.0.1, порт 20001, и возможно не более шести одновременных соединений. Согласно предыдущим строкам, подключиться сможет только один пользователь с логином «admin» и паролем «aaa» — других просто нет.

9

Пустая строка, отделяет команды сервисов server и processor друг от друга.

10 service processor 0

11 lookup–delay 20

12 flow–lifetime 120

13 policy name ip target proto ip

14 policy name www target proto tcp ports 80

15 policy name rus target file /etc/ru–networks.txt

16 restrict all drop local pass

Настраивается главный сервис — processor. В строках 10 и 11 задаются параметры, как часто будет проверяться списки юнитов и откладываться записи в базу данных. Для большинства задач указанные значения параметров оптимальны. Три следующие строки задают политики, по которым будет идти учет трафика. Политика «ip» задает весь IP–трафик, «www» — только тот, который идет по порту TCP 80, «rus» — тот, который получается при совпадении адресов с таблицей русских сетей, содержащейся в файле префиксов /etc/ru–networks.txt. Изначально этот файл идет в дистрибутиве NeTAMS, в каталоге addon/. Последняя, 16–ая строка определяет, как поступать с пакетами, которые прошли через учет по списку юнитов и совпали (или не совпали) с каким–либо юнитом. Указанная конфигурация пропускает пакеты, которые принадлежат имеющимся в конфигурационном файле юнитам, и не пропускает остальные. Полезно использовать именно указанное сочетание, т.к. это поможет не пускать в сеть «незаконные» компьютеры.

17 unit group name NETWORK acct–policy ip tcp !rus

18 unit net name LAN ip 192.168.0.0 mask 255.255.255.0

no–local–pass acct–policy ip tcp !rus

19 unit host name server ip 192.168.0.1 parent NETWORK

acct–policy ip tcp !rus

20 unit user name petya ip 192.168.0.10 parent NETWORK

password abc acct–policy ip tcp !rus

21 unit user name fedya ip 192.168.0.11 parent NETWORK

password def acct–policy ip tcp !rus

22 unit user name masha ip 192.168.0.12 parent NETWORK

password ghi acct–policy ip tcp !rus

Здесь определяются юниты, или учётные объекты. В начале создается группа, которая будет родительской по отношению к включенным в нее юнитам. Затем следует юнит, обозначающий всю подсеть. Далее, идут юниты, представляющие отдельные компьютеры. Для каждого юнита указан одинаковый набор политик учета, обратите внимание на флаг inverse, в виде знака "!», для политики «rus». Для юнита LAN указан также параметр no–local–pass, который заставляет считать не–локальными все пакеты, принадлежащие сети, и не описанные для других юнитов — этим мы отсекаем «неизвестные подключения». Для последних трех юнитов указан также пароль, который может быть использован для доступа к индивидуальной статистике в виде HTML–страниц.

23 storage 1 all

Указывает сервису processor на необходимость сохранять статистику в хранилище, описанном сервисом storage за номером 1. При этом запить будет идти в обе таблицы одновременно — raw и summary.

25 service storage 1

26 type mysql

Определяет хранилище для статистики. Тип хранилища — MySQL, для доступа к базе будут использованы стандартные настройки: имя пользователя root, пустой пароль, работающий на той же машине SQL–сервер (подключение через unix socket). Имя базы данных — netams.

27 service data–source 1

28 type libpcap

29 source eth1

30 rule 11 «ip»

Определяет, каким образом данные о трафике будут попадать в NeTAMS. Для этого будет использован интерфейс eth1 (ОС Линукс), и будет захвачен весь IP–трафик, проходящий через него (механизм libpcap, на базе которого сделан, например, tcpdump). Номер правила, «11», в данном случае смысла не несет.

32 service alerter 0

33 report oid 06100 name rep1 type traffic period day detail simple

34 smtp–server 127.0.0.1

Для того чтобы пользователи и администратор могли получать уведомления о статистике по электронной почте, настраивается сервис alerter и указывается тип отчета, и адрес smtp–сервера (в данном случае это локальный компьютер, где выполняется NeTAMS). Проследите, чтобы на указанной машине был запущен и настроен на прием ваш sendmail/postfix/exim/etc. В настоящий момент тип отчета задать нельзя, и вместо этого придется писать всю 33ю строчку целиком.

36 service html 0

37 path /var/www/traffic

38 language en

39 run 5min

40 htaccess yes

41 client–pages all

Сервис html позволяет автоматически генерировать HTML–страницы с отчетами. Процесс netams будет автоматически создавать эти страницы раз в 5 минут и складывать их в каталог /var/www/traffic. При этом язык страниц – английский (другого пока нет). Будет создаваться как администраторская часть дерева страниц, так и клиентская. Доступ к статистике будет защищен паролем (на администраторскую – admin:aaa, клиентам – их логины–пароли). Если настроить апач так:

ServerName www.company.ru

<Directory /var/www/traffic>

Options FollowSymLinks ExecCGI Indexes

AllowOverride All

</Directory>

Alias /stat/ /var/www/traffic/

то администратор получит доступ по ссылке http://www.company.ru/stat/ , а Федя по ссылке http://www.company.ru/stat/clients/fedya/ (спросится федин логин–пароль)

Простейший файл конфигурации

#NeTAMS version 3.1(1205.408) compiled by root@avm

#configuration built Thu Aug 8 09:03:53 2002

#begin

#global variables configuration

debug none

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

#services configuration

service server 0

login local

listen 20001

max–conn 6

service processor 0

lookup–delay 60

flow–lifetime 180

policy name ip target proto ip

policy name www target proto tcp port 80 81 8080 3128

policy name mail target proto tcp port 25 110

restrict all pass local pass

unit group name CLIENTS acct–policy ip www mail

unit host name server ip 192.168.0.1 acct–policy ip www mail

unit user name client1 ip 192.168.0.10 parent CLIENTS

email client1@domain.ru acct–policy ip www mail

unit net name LAN ip 192.168.0.0/24 acct–policy ip www mail

service storage 1

type mysql

accept all

service data–source 1

type libpcap

source xl1

rule 11 «ip»

service quota 0

policy ip

notify soft <owner>

notify hard <owner> admin

notify return <owner>

service alerter 0

report oid 06100 name rep1 type traffic period day detail simple

smtp–server localhost

service html 0

path /usr/local/www/stat

language en

run 5min

htaccess yes

client–pages all

url http://192.168.0.1/stat/

#end

Startup–скрипт

В дистрибутиве идут два стартап–скрипта, netams–startup.sh и netams–startup–failover.sh. Зачем?

Первый выглядит как обычный стартап–скрипт для процессов–демонов UNIX, и не содержит никаких настроек. Его можно использовать для эпизодических запусков.

Второй, который failover, позволяет:

• Указать пути до исполняемых и конфигурационных файлов

• Указать параметры отладки и имя лог–файла

• Отслеживать момент окончания (смерти/выхода) процесса netams, и в зависимости от причины предпринимать различные действия.

Если процесс закончился аварийно, то будет:

Сохранен старый лог–файл

Если есть core–файл, то сохранится также gdb … bt full для последующего разбирательства

Процесс netams будет запущен снова

Если процесс закончится по команде «reload», он будет перезапущен.

Если процесс закончится по команде «kill» или «shutdown», то перезапуска не произойдет и скрипт закончит работу.

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

Утилита netamsctl

При инсталляции утилита netamsctl переписывается в (обычно) /usr/local/sbin

Что это такое?

netamsctl — примитивный telnet–клиент, позволяющий передать одну или несколько команд для работающего netams. Он работает через обычный TCP–сокет. Открывается соединение, отправляется команда, получается и выводится на экран ответ сервера.

Зачем это нужно, когда все можно сделать и через telnet?

Вам не надо все время вводить логин–пароль для авторизации, указывать имя хоста и порт. Эта информация берется из файла .netamsctl.rc

Вызов netamsctl с нужной командой можно поместить, например, в cron, в вашу любимую самописную программу, в sudo–скрипт для исполнения секретаршей–блондинкой.

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

После сборки, исполняемая программа netamsctl находится в netams/src, пример настроек .netamsctl.rc в netams/addon

make install копирует программу в /usr/local/sbin, однако .netamsctl.rc не трогается

Ваше дело — положить этот файл в один из каталогов:

• ~/.netamsctl.rc (домашний каталог пользователя, который будет запускать)

• .netamsctl.rc (там, где находится исполняемый файл)

• /usr/local/etc/.netamsctl.rc

• /etc/.netamsctl.rc

Отредактируйте этот файл, прописав там верные значения логина, пароля, хоста (по умолчанию — localhost) и TCP–порта (по умолчанию — 20001), словом то же самое, что вы используете для повседневного управления через Telnet

Не забудьте отнять права у этого файла на чтения «кому не надо»:

chmod 600 .netamsctl.rc

Проверяем:

src/netams–l

netamsctl «show version»

Не забывайте, что возможно задать на исполнение сразу несколько команд, если разделить их комбинацией "&&". Это крайне полезно, если необходимо передать команду какому–нибудь сервису:

netamsctl «service processor && unit host name pupkin sys–deny && exit»

Часто задаваемые вопросы

• Какие пакеты мне нужно поставить, чтобы NeTAMS заработал?

• Все зависит от комбинации желаемых data–source и storage. В общем виде список пакетов для Linux приведен тут. Для FreeBSD ничего дополнительного помимо SQL и веб–сервера ставить не надо.

• Как мне создать базу и таблицы SQL?

• Специально создавать базу данных не нужно (MySQL). NeTAMS сам создаст ее при первом старте; таблицы с данными (raw и summary) будут создаваться, когда пойдет реальный трафик и начнется учет. Для Postgres вы можете создать таблицы вручную (они лежат в каталоге addon/), для Oracle вы ДОЛЖНЫ создать схему вручную (addon/oracle/).

• При компиляции не нашелся SQL. Как быть?

• Обычно, при сборке, скрипт configure.sh сканирует набор системных каталогов в поиске клиентских библиотек и заголовочных файлов. При этом на консоль выводится что–то вроде:

freebsd–vm:~/netams#make

/bin/sh configure.sh

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

## Configuring NeTAMS for build targets… ##

FreeBSD operating system…

With FreeBSD 5.XX, will have netgraph module…

Will have MYSQL support

[ /usr/local/lib/mysql /usr/local/include/mysql ]

Will have POSTGRESQL support

[ /usr/local/lib /usr/local/include ]

Will have BILLING service

Will have DEBUG flag set

Will have RADIUS support

Will have private portion of Makefile

## Configuration file was built. ##

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

К сожалению, стандартного места для таких библиотек нет, ваш конкретный дистрибутив может ставить программы куда угодно (особенно славится этим Linux), в связи с чем configure.sh может не найти библиотеки и при старте программа само–выключится с сообщением:

parse: registering storage: 1

parse: using storage:2 as source for READ and STAT requests

parse: creating service storage:1

parse: storage type is unknown

В таком случае вам необходимо вручную добавить соответствующие пути в верхние строки (начало) файла configure.sh, и пересобрать программу через:

make distclean && make

• Как мне блокировать трафик, если я использую libpcap?

• В общем случае — никак. Библиотека libpcap позволяет только слушать проходящий мимо интерфейса трафик. Все возможность блокировки через fw–policy или sys–policy работают ТОЛЬКО при наличии «перехватывающего» сервиса data–source, например IPFW или iptables/IPQ. Вы также можете написать свой скрипт (де)блокировки, который будет вызываться сервисом processor каждый раз, когда изменяется состояние системной политики юнита (см. документацию и пример).

• Почему бы не хранить конфигурацию в SQL?

• По историческим причинам NeTAMS держит ВСЮ свою конфигурацию в текстовом файле. Один и тот же код отвечает за разбор конфигурационного файла при старте, и настройку работающей программы через интерфейс командной строки. Хранение (части) конфига в SQL–базе, вообще–то очень полезная фича, потребует дублирования кода разбора конфига, дублирование кода записи конфига, и нетривиальных механизмов синхронизации SQL и внутренних структур данных работающей программы. К тому же, для управления SQL–конфигом придется писать отдельный веб–интерфейс. Эта задача (пробовали, не получилось) слишком трудоемка, чтобы браться ее реализовать в рамках бесплатного проекта и за разумное время.

• У меня чего–то не компилируется/не настроено/не работает, помогите!

• У вас есть две возможности. Можно обратиться к авторам программы за платной поддержкой по инсталляции и настройке (потребуется доступ по SSH, схема сети, описание задачи и в среднем $200). Можно обратиться за поддержкой в форум, где надо указать: версию ОС, netams, установленного софта; подробное описание проблемы; лог–и конфиг–файл (последний — сделанный через save); ключи запуска netams.

• Программа падает, что делать?

• См. предыдущий вопрос. Попробуйте по очереди отключать неиспользуемые опциональные сервисы (html, quota, ..), и пробовать снова. Для корректного разбирательства надо научиться пользоваться GDB. Получить вывод «gdb /usr/local/sbin/netams netams.core», в котором посмотреть «bt full».

• Делаю как написано в документации, команда не срабатывает.

• Документация относится к версии CURRENT. Возможно ваша (более старая) версия netams просто еще понимает ту команду, которую вы задаете.

• FreeBSD+NAT+SQUID. Конфигурация для подсчета трафика.

• При помощи divert или tee трафик, проходящий через NAT и SQUID, нужно завернуть для подсчета а нетамс.

• Для этого нужно добавить в файервол divert или tee на нетамс трафика по порту 3128(прокси)

• Допустим правило трансляции стоит под номером 800.

• Тогда, один divert или tee на нетамс до NAT–а и один после.

• В этоге в netams.cfg нужно прописать следующее:

service data–source 0

type ip–traffic

source divert/tee 199

rule 400 «tcp from any to any 3128»

rule 500 «tcp from any 3128 to any»

rule 700 «ip from any to any via rl1»

rule 900 «ip from any to any via rl1»

получим в IPFW

• …..

• 00400 divert/tee 199 tcp from any to any 3128

• 00500 divert/tee 199 tcp from any 3128 to any

• ……

• 00700 divert/tee 199 ip from any to any via rl1

• 00800 divert 8668 ip from any to any via rl1

• 00900 divert/tee 199 ip from any to any via rl1

• ……

•

• rl1 — это внешний интерфейс, который смотрит в интернет.

• service scheduler — суммарная информация по группе

• Если

• send report on GROUP

• заменить на

• send report on GROUP+

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

• Ошибки, связанные с работой cgi–скриптов в Admintool

• (http://www.netams.com/ubb/cgi–bin/ultimatebb.cgi?ubb=get_topic&f=2&t=002270) Стандартная ситуация, когда при вызове скрипта из Admintool (типа аccounts.cgi) появляется Internal Server Error.

• Решение:

• Смотрим лог Apache и выясняем на что идет ругань

• [Wed Apr 19 23:22:32 2006] [error] [client 192.168.1.3] Can't locate Crypt/GeneratePassword.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.6/i386

•

• далее идем на http://search.cpan.org/ и устанавливаем недостающей модуль

•

• После сборки NetAms был проинсталлирован без поддержки MySQL.

• (http://www.netams.com/ubb/cgi–bin/ultimatebb.cgi?ubb=get_topic&f=2&t=002301)

• Редактируем PATH в configure.sh указывая путь к MySQL в своей системе, чтобы при сборки NeTAMS включить поддержку MySQL.

#!/bin/sh

# Configuration script for NeTAMS project

# $ Id: configure.sh,v 1.41 2005/07/21 15:48:24 anton Exp $

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

PATH=/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/bin

export PATH

makefile=Makefile.run

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

История проекта NeTAMS

Все началось в 1998, когда была разработана первая «считалка», ipCount. В то время единственной возможностью подсчитать трафик на маршрутизаторе было использовать ipfw count, что и было сделано. Никакого другого софта, который теперь водится в избытке, и в помине не было.

ipCount работал под FreeBSD 3.4. Серверная часть, написанная на Си, периодически опрашивала счетчики ipfw и бросала их содержимое в базу MySQL. Она же воспринимала команды от клиента управления, написанного на Perl; команды через специальную таблицу MySQL и ping–подобный механизм оповещений. Клиент управления занимался созданием–удалением записей о правилах, интерфейсом, выводом статистики и прочее. Подобная технология, характерная и по сей день для «начинающих биллингистов–скриптописателей», не позволяла: а) отключать кого надо, б) требовала профилактики (агрегации) БД, в) плохо масштабировалась и г)… просто Г. Поэтому написали aaa+fw

AAA+FW работало для Linux и FreeBSD, поддерживало несколько потоков (сервисы), однако единственной политикой учета была «IP», и это никак не менялось.

Первая версия NeTAMS вышла в октябре 2001 года. Нумерация версий начинается с 3, по понятным причинам. В течение первых двух лет развивалась ветка 3.1, после чего была освоена система CVS и основные нововведения стали поступать в ветку–CURRENT. Она стала достаточно стабильной и привела в выходу релиза 3.2 в декабре 2004 года. Версия 3.3 вышла в конце сентября 2005 года. Версия 3.4 стала окончательно стабитьной в январе 2009 года.

В настоящий момент NeTAMS включен в дерево портов FreeBSD. Существуют также пакеты RPM/RPMS для вариантов Linux (поддерживаются сторонними разработчиками).

База знаний

Веб–интерфейс 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 (или где там он у вас есть):

<Directory /usr/local/www/stat>

Options FollowSymLinks ExecCGI

</Directory>

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, будет блокирован.

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

Поддержка карточек экспресс–оплаты появилась в NeTAMS 3.3.1 (RELEASE) начиная с номера билда 2811 (25 ноября 2005г.)

Что и зачем

В наборе скриптов управление системой NeTAMS появилось два новых скрипта — управления карточками, и активации карточек пользователем. Владелец (администратор) сети, в которой установлен и работает NeTAMS+модуль биллинга, генерирует базу карточкек эксперсс–оплаты, печатает и реализует их, и использует активацию карточек как средство пополнения баланса абонента в системе биллинга. Активация карточек возможна как оператором системы, так и непосредственно самим абонентом через отдельный скрипт. Возможно также блокировать–разблокировать как отдельные карточки, так и серии карточек, экспортировать номера карточек во внешний файл, проверять годноть и статус карточки, и так далее. Курс преобразования номинала карточки в условные единицы биллинга также управляется из администраторского скрипта.

Каждая карточка имеет десятизначный номер (первые три цифры — номер серии, остальные семь — случайное число), ПИН–код (двадцать случайных чисел в четырех группах по пять чисел, разделенных дефисом), номинал (число от 10 до 10000, задается при создании), время создания, статус (неактивирована, уже активирована, блокирована), время изменения статуса.

Случайные числа, испольованные при генерации номеров — действительно случайные, построенные с использованием системного устройства энтропии вроде /dev/urandom.

Как поставить

Необходимо поставить Netams 3.3.1–release, хотя сам скрипт будет работать и с предыдущими версиями. Необходимо правильно настроить скрипты admintool.cgi, config.cgi из каталога admin/cgi–bin дистрибутива. Фактически, модуль работы с карточками вызывается оттуда и использует чаcть общих функций Admintool и NeTAMS Perl API.

Система управления карточками привязана к MySQL, но легко может быть перенесена на PostgreSQL или Oracle. Она состоит из следующих файлов:

• addon/cardtool_schema.sql — схема базы данных (описание таблицы cards). Вы должны создать эту новую таблицу в вашей базе данных посредством следующей команды:

mysql netams < addon/cardtool_schema.sql

(предполагается, что имя вашей база данных «netams»)

• admin/cardtool.cgi — основной скрипт работы с карточками. В его первых строках указан относительный путь до файла с курсом перерасчета у.е. По умолчанию это «ratefile.txt» в такущем каталоге.

• admin/ratefile.txt — файл содержит одну строку с курсом перерасчета у.е. при пополнении баланса биллинга. Вы ДОЛЖНЫ сами создать этот файл вручную, и присвоить ему права доступа, гарантирующие запись в него из скрипта. Дальнейшие модификации этого файла будут проводиться самим скриптом cardtool.cgi.

• activate.cgi — скрипт активации карточки пользователем. Начало файла содержит ссылку на файл с курсом у.е., а также имя шаблона страницы, которая будет показана пользователью перед активацией (форма с запросом) и после (результат активации).

• activate.tmpl — форма (шаблон) страницы пользователя, проводящего активацию самостоятельно.

В файле config.cgi проверяем наличие:

#enable or disable prepaid card processing services

$have_cards=«yes»;

Все, можно работать. Заходим в Admintool и видим появившийся пункт меню:

Как использовать

Создать новую серию карточек

Необходимо указать номинал карточки, количество карточек, и нажать кнопку «Применить». Номер серии присвоится автоматически (следующий незанятый начиная с 1), и вы увидите что–то вроде:

Просмотреть всю серию

В таблице серий карточек кликнуть на номер серии, появится таблица со сведениями о серии, плюс информация о каждой карточке:

Работа с серией

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

Получить список карточек

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

Курс перерасчета

В основном окне «Prepaid cards» можно выбрать режим изменения курса перерасчета. Карточки выпускаются с номиналом в рублях, а на баланс абонента средства заносятся путем деления номинала карты на этот курс. Величина курса хранится в текстовом файле admin/ratefile.txt

Активация карты

Администратор/оператор системы может сам активировать карту (по звонку абонента), путем ввода всей информации в верхней части основного окна. Необходимо указать номер, ПИН, имя аккаунта абонента, и нажать кнопку «Применить». Будет произведена проверка, и в открывшемся окне можно или подтвердить операцию, или посмотреть сообщение об ошибке:

Кнопка «Применить» (пополнить счет абонента) появится только в случае, если все нормально.

Операции с картой

По номеру карты можно посмотреть ее статус, а также произвести блокировку и разблокировку:

Операция блокировки обратима, операция активации карты — нет.

Активация карты абонентом

Вам бедет необходимо исправить шаблонный файл cgi–bin/activate.tmpl, поместим в него макет страницы, которую должен видеть пользватель. Шаблон состоит из двух половинок (код HTML), разделенных строкой ########. Верхняя часть содержит форму активации, нижняя — информацию об операции.

Пользователью необходимо предоставить ссылку на скрипт cgi–bin/activate.cgi

В шаблоне по умолчанию присутствует следующая таблица:

После выполнения операции абонент получает одно из следующих сообщений:

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

Можно настроить автоматическую или ручную очистку быстрорастущих таблиц 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.

Если у вас что–то не работает — извините. Никакой поддержки по NetamsView не оказывается. Исключение составляют лишь серьезно желающие взяться за доведения этого сервлета до ума!

Мониторинг

Начиная с версии 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

Начиная с версии 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.

• если поток найден, то проверяется его статус:

• QUEUED — рассматриваемый пакет добавляется в конец цепочки пакетов данного потока. при этом делаются проверки на ряд ограничений по количеству потоков/пакетов/байт/очередей, для предотвращения атаки DoS

• PASS — пакет передается дальше

• DROP — пакет уничтожается

Возникает вопрос, что же происходит с пакетами в очереди, и откуда берутся статусы PASS и DROP?

Статус DROP является единственно возможным для режима работы TEE.

Когда демон получает запрос FWREQUEST из модуля ядра, происходит разбор заголовков и полный анализ возможности блокировки пакета с использованием таблиц юнитов, политик, системных политик, словом всего обычного набора действий. По окончании проверки, формируется решение по данному потоку: PASS или DROP, и оно передается обратно в ядро через сообщение FWREPLY. За время такой обработки в ядре уже может накопиться несколько пакетов в очереди для данного потока. По получении ответа от демона, модуль ядра во–первых ставит соответствующий флаг для данного потока, а затем пытается или отправить все пакеты из очереди, или очистить очередь.

Если по каким–то причинам демон недоступен, то по истечении некоторого таймаута (сейчас это NG_NETAMS_DEFAULT_TIMEOUT равный 2 секундам) производится принудительная очистка очереди для потока и принятие «решения по умолчанию» (сейчас: пропускать). Таким образом предотвращается залипание потока и выедание памяти у ядра (что может быть очень опасным!)

В режиме divert, как и в tee, проводится периодическое устаревание потоков и отправка их на учет «наверх», демону.

Рассмотренный механизм работает, по сути, аналогично Multilayer Switching, реализованному в Cisco Catalyst 6000 и подобных ящиках. Там «быстрый» Switch Engine направляет первый пакет потока «медленному» Route Processor, который определяет, куда маршрутизировать пакет, и проводит проверку правил доступа (access lists). Все последующие после ответа пакеты идут через SE напрямую, и только через некоторое время «наверх» передается статистика о прошедшем потоке. В нашем случае решения о маршрутизации принимать не нужно, в роли «быстрого» движка выступает ядро с его механизмом форвардинга пакетов, в роли «медленного» решателя — демон NeTAMS.

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

Для начала, вам надо скомпилировать netams, как обычно. Получившийся модуль src/ng_netams.ko необходимо переписать в /boot/kernel/

В дистрибутиве есть скрипт addon/netams–netgraph.sh, который устанавливает в ядро сам модуль ng_netams.ko, устанавливает его режим работы (TEE или DIVERT), вывод отладочной информации, производит подключения к другим нодам NETGRAPH (интерфейсу и ng_tee, если надо)

Запускается этот скрипт через

./netams–netgraph.sh start

останавливается через

./netams–netgraph.sh stop

Для настройки самого NeTAMS необходимо добавить соответствующий сервис в /usr/local/etc/netams.cfg:

service data–source 1

type netgraph

source netams: divert

При этом 'netams:' - это имя модуля NETGRAPH, совпадающее с тем, что написано в скрипте netams–netgraph.sh. Не забываем про двоеточие!

Модуль ядра должен быть запущен ДО демона. В противном случае демон не заработает, как следует. Однако, в процессе работы допускается останавливать и запускать демон NeTAMS, равно как и выгружать и загружать снова модуль ядра (при этом будет 20–секундная задержка в приеме статистики).

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

Если что–то будет идти совсем не так, упадет ядро :) или блокируется весь трафик!

Работу демона netams можно проверить через просмотр состояния сервиса data–source:

netamsctl show ds

Data–source ID=1 type NETGRAPH source netams::9 loop 0 average 0 mcsec

Perf: average skew delay 0 mcsec, PPS: 0, BPS: 0

IP tree: 7 nodes [12] + 4 dlinks [1024] + 4 unodes [24] = 4276 bytes

Flows: 0/0 act/inact entries (0 bytes), 3 flows sent

HASH: size=65536, 0 flows hashed, 0 nodes used, max chain= 0

FIFO: 0/2 used/ready messages, each 108, total 216 bytes

ds_netgraph data messages: 3

netams: mode=2, pkt_rx=201, pkt_tx=169

flows: active(now)=3, queued(now)=0, blocked(total)=0, total=4

Работа модуля ядра видна через ngctl:

ngctl msg netams: info

Rec'd response «info» (1) from «[3bb]:":

Args: { packets/in=254 packets/out=202 mode=2 debug=1 active_flows=3 total_flows=9 default_policy=2 }

При включенной отладке модуля (через ngctl msg netams: debug 1) на консоли и в dmesg видно много подобных строк:

info/1109893460: sent to daemon [961] with error=0

callout/1109893461+ active 1, checked 1, queued=0, flushed 0

callout/1109893462+ active 1, checked 1, queued=0, flushed 0

callout/1109893463+ active 1, checked 1, queued=0, flushed 0

callout/1109893464+ active 1, checked 1, queued=0, flushed 0

callout/1109893465+ active 1, checked 1, queued=0, flushed 0

callout/1109893466+ active 1, checked 1, queued=0, flushed 0

callout/1109893467+ active 1, checked 1, queued=0, flushed 0

callout/1109893468+ active 1, checked 1, queued=0, flushed 0

callout/1109893469+ active 1, checked 1, queued=0, flushed 0

netams: created flow record id=14, hash=00766, time=1109893469, proto=6

netams: created queue 0xc1a15250 for id=14, hash=00766

netams fwreply for entry id=14, flags=0, queue 1/102

netams: flush queue for entry id=14, hash=766, size=1, action=1

netams: created flow record id=15, hash=00254, time=1109893469, proto=6

netams: created queue 0xc1355240 for id=15, hash=00254

netams fwreply for entry id=15, flags=0, queue 1/102

netams: flush queue for entry id=15, hash=254, size=1, action=1

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

Зачем все это нужно? Чтобы быстрее работало! Ниже приведены результаты небольших стендовых испытаний.

Все работы проводились с ОС FreeBSD 5.3–RELEASE, которая работала внутри виртуальной машины VmWare 4.5.2. Сама виртуальная машина работала на компьютере DUAL P4 Xeon 3.4GHz, 4Gb RAM под управлением Windows Server 2003. Виртуальная машина и хост–машина связаны через виртуальный адаптер vnmat (хотя в тестах трансляции адресов не было).

Скорость передачи данных измерялась при помощи iperf 1.7.0

На самой машине с Windows Server 2003 запущен сервер iperf, там же запускаем клиента:

C:\>iperf.exe–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 8.00 KByte (default)

— -----------------------------------------------------------

[1948] local 192.168.56.1 port 3027 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[1948] 0.0–1.0 sec 97.8 MBytes 821 Mbits/sec

[1948] 1.0–2.0 sec 96.1 MBytes 807 Mbits/sec

[1948] 2.0–3.0 sec 97.7 MBytes 820 Mbits/sec

[1948] 3.0–4.0 sec 93.0 MBytes 780 Mbits/sec

[1948] 4.0–5.0 sec 93.2 MBytes 782 Mbits/sec

[1948] 5.0–6.0 sec 96.9 MBytes 813 Mbits/sec

[1948] 6.0–7.0 sec 98.4 MBytes 825 Mbits/sec

[1948] 7.0–8.0 sec 97.4 MBytes 817 Mbits/sec

[1948] 8.0–9.0 sec 96.0 MBytes 806 Mbits/sec

[1948] 9.0–10.0 sec 98.2 MBytes 824 Mbits/sec

[1948] 0.0–10.0 sec 965 MBytes 808 Mbits/sec

Как видим, скорость передачи данных через локальный виртуальный интерфейс просто гигантская. Пробуем, как передаются данные между Windows и установленной FreeBSD, через VmWare, безо всяких побочных эффектов (NeTAMS и модуль ядра выключены):

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 51925 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 27.6 MBytes 232 Mbits/sec

[ 3] 1.0–2.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 2.0–3.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 3.0–4.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 4.0–5.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 5.0–6.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 6.0–7.0 sec 28.0 MBytes 235 Mbits/sec

[ 3] 7.0–8.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 8.0–9.0 sec 28.7 MBytes 240 Mbits/sec

[ 3] 9.0–10.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 0.0–10.0 sec 282 MBytes 237 Mbits/sec

Естественно, медленнее. Теперь запустим NeTAMS и модуль ядра вместе, в режиме divert и убедимся, что это была не подстава:

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 56639 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 20.9 MBytes 175 Mbits/sec

[ 3] 1.0–2.0 sec 23.4 MBytes 196 Mbits/sec

[ 3] 2.0–3.0 sec 23.5 MBytes 197 Mbits/sec

[ 3] 3.0–4.0 sec 23.5 MBytes 197 Mbits/sec

[ 3] 4.0–5.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 5.0–6.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 6.0–7.0 sec 23.4 MBytes 196 Mbits/sec

[ 3] 7.0–8.0 sec 23.8 MBytes 200 Mbits/sec

[ 3] 8.0–9.0 sec 23.6 MBytes 198 Mbits/sec

[ 3] 9.0–10.0 sec 23.3 MBytes 196 Mbits/sec

[ 3] 0.0–10.0 sec 233 MBytes 195 Mbits/sec

freebsd–vm:~/netams#ngctl msg netams: info

Rec'd response «info» (1) from «[3c5]:":

Args: { packets/in=85515 packets/out=169244 mode=2

debug=1 active_flows=4 total_flows=4 default_policy=2 }

Налицо падение производительности на 100*(237–195)/237=17.7% или в 1.2 раза. Теперь заменим фильтрование через модуль ядра на стандартное, через ipfw divert и data–source ip–traffic:

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 55410 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 2.96 MBytes 24.8 Mbits/sec

[ 3] 1.0–2.0 sec 3.59 MBytes 30.1 Mbits/sec

[ 3] 2.0–3.0 sec 3.73 MBytes 31.3 Mbits/sec

[ 3] 3.0–4.0 sec 3.62 MBytes 30.3 Mbits/sec

[ 3] 4.0–5.0 sec 3.70 MBytes 31.0 Mbits/sec

[ 3] 5.0–6.0 sec 3.69 MBytes 30.9 Mbits/sec

[ 3] 6.0–7.0 sec 3.65 MBytes 30.6 Mbits/sec

[ 3] 7.0–8.0 sec 3.71 MBytes 31.1 Mbits/sec

[ 3] 8.0–9.0 sec 3.71 MBytes 31.1 Mbits/sec

[ 3] 9.0–10.0 sec 3.73 MBytes 31.3 Mbits/sec

[ 3] 0.0–10.0 sec 36.1 MBytes 30.2 Mbits/sec

freebsd–vm:~/netams#ipfw show 10 11

00010 26136 39197956 divert 199 tcp from any to any dst–port 5001

00011 13069 679600 divert 199 tcp from any 5001 to any

В данном случае мы видим потерю производительности на 100*(237–30.2)/237=87.2% или в 8 раз. Выгода налицо!

Заключение

Велосипед мы не изобрели, это понятно. Результаты ожидаемы. Использование модуля ядра более опасно, чем обычного data–source ip–traffic, а уже тем более сбора по libpcap или netflow. В случае ошибок или переполнения буферов зависает ядро вместе со всеми процессами, или блокируются все сокеты. Было проведено тестирование на предмет поддержки «нехороших ситуаций» вроде ping–f или nmap–sS–PS 80–iR 100. Однако стабильность работы не гарантируется, тестируйте модуль со всей осторожностью!

Кто–нибудь особенно умный может спросить: «А собственно зачем вы это делали? Фильтровать можно и в ядре, через тот же ipfw deny, pfctl и прочее. Все будет быстро и надежно.»

Возможно. Однако вам придется как–то синхронизировать таблицу юнитов и политик учета с правилами firewall, фактически городить зоопарк скриптов и дублировать одно и то же дважды. Зачем? Использование NeTAMS позволяет хранить всю информацию о правилах в одном месте, без проблем применяя всякие хитрости вроде break flag, prefix table и срабатывание по времени суток. Совершенно прозрачно работают сервисы квот, системные политики, биллинг, и так далее.

Возможные направления улучшения и развития:

• Создать аналогичный продукт для Linux, видимо на базе ULOG

• Сделать поддержку RAW IP пакетов, PPP и так далее

• Проверить работоспособность в случае нескольких модулей ядра, работающих одновременно

Зачем нужно 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

Поддержка RADIUS появилась в NeTAMS 3.3.0 (CURRENT) начиная с номера билда 2378 (8 апреля 2005г.)

Что именно поддерживается

В NeTAMS реализована поддержка авторизации доступа к ресурсам внешний сервер–доступа и радиус–сервер, когда последний обращается за паролем и атрибутами к внутренним структурам netams через его Telnet API. Также возможно использование RADIUS–сервера для контроля доступа к статическим веб–страницам. Таким образом, с точки зрения организации провайдерства NeTAMS является базой данных для радиус–сервера. Прозрачно поддерживаются любые методы проверки паролей (PAP/CHAP/MS–CHAP/EAP), т.к. это дело FreeRADIUS а не NETAMS; любое число внешних серверов доступа.

Поддерживается отправка аккаунтинга (данных о трафике) в сторону радиус–сервера через новый тип сервиса storage… type radius (документация).

С версии 3.4.0 появилась поддержка получения аккаунтинга радиус–сервером со стороны NAS, с последующей обратоткой через data–source raw.

Что не поддерживается

Не поддерживается контроль доступа и проверка паролей для пользователей NeTAMS посредством радиус–сервера (т.е. функциональность радиус–клиента; по всей видимости этого и не требуется).

Как работает

Новые функции сосредоточены в:

поддержке авторизации через telnet–интерфейс и/или командную строку

модуле rlm_netams, расширяющего сервер FreeRADIUS

поддержке авторизации доступа к HTML–страницам через mod_auth_radius+новая команда сервиса html (опционально)

В качестве сервера доступа, используемого в качестве клиента нового механизма авторизации, проверялись pppoe+ppp (FreeBSD 5.3) и Windows 2003 RRAS. Таким образом, NeTAMS может успешно авторизовывать и контролировать трафик dialup–и pppoe–и прочих коммутируемых соединений, без необходимости дублировать логины/пароли/настройки в текстовых конфигах и базах данных.

Порядок работы с сервером доступа:

При поступлении запроса на соединение сервер доступа осуществляет проверку прав звонящего (логин/пароль) у радиус–сервера.

Радиус–сервер вызывает код модуля rlm_netams, который извлекает требуемые атрибуты из запроса аутентификации, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

На основании полученного запроса демон NeTAMS разрешает или запрещает доступ. Если доступ разрешен, в сторону rlm_netams (т.е. радиус–сервера) передаются ряд атрибутов, в частности IP–адрес клиента и набор фильтров. Если сервер передал параметр «Caller–ID» (для PPPoE это МАС–адрес звонящего), и для юнита установлен параметр «mac …», будет проводиться дополнительный контроль и по этому признаку.

rlm_netams копирует ответ демона, формируя RADIUS–ответ для сервера доступа.

сервер доступа отвергает или принимает клиента, устанавливая необходимые параметры соединения.

Порядок работы при авторизации веб–доступа:

Сервис HTML генерирует статические HTML–страницы с данными о трафике, админскую часть и пользовательскую часть. При этом создаются также файлы .htaccess со списком «правильных» пользователей данного URI, файл паролей .htpasswd не поддерживается — заместо него в глобальном конфигурационном файле apache присутствуют записи о RADIUS–авторизации.

HTTP–клиент (бровзер) пытается обратиться к защищенному при помощи .htaccess ресурсу. Происходит запрос пароля (через код 401)

Apache вызывает модуль mod_auth_radius, сообщая тому логин–пароль клиента. Запрос на авторизацию передается радиус–серверу.

Радиус–сервер вызывает код модуля rlm_netams, который извлекает логин–пароль из запроса аутентификации, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

На основании полученного запроса демон NeTAMS проверяет свою базу пользователей и юнитов, разрешает или запрещает доступ. Ответ пересылается в RADIUS–сервер.

rlm_netams копирует ответ демона, формируя RADIUS–ответ для Apache.

Apache пускает пользователя (бровзер) на страницу, или не пускает его.

Порядок работы при получении accounting пакетов (Start, Stop, Alive) радиус–сервером:

радиус–сервер вызывает код модуля rlm_netams, который извлекает требуемые атрибуты из пакета, формирует сообщение, и передает его работающему демону NeTAMS посредством Telnet API.

Если в пакете Start присутствует In Out, они записываются as–is, если для юнита типа user в пакете присутствует Framed–IP–Address, этот IP–адрес будет установлен данному юниту.

Если в пакете Stop присутствует In Out, они записываются incremental, для юнита типа user IP–адрес обнуляется.

При поступлении пакета Alive, данные In Out записываются incremental.

Если в любом из трех пакетов присутствует Filter–ID=Policy данные будут записаны в эту политику.

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

Настройка PPPoE/PPP

Очень рекомендуем почитать теорию и примеры и настроить доступ безо всякого netams+radius, для начала.

Допустим что NeTAMS, FreeRADIUS, PPP, PPPoE крутятся на одной машине 192.168.0.1, внешний интерфейс fxp0.

### /etc/ppp/ppp.conf #####################################

default:

enable dns # request DNS info (for resolv.conf)

pppoe:

set log Phase Chat LCP IPCP CCP tun command

set radius /etc/ppp/radius.conf

set speed sync

set timeout 240

set ctsrts off

set accmap 000a0000

enable lqr

set cd 5

enable pap chap

set ifaddr HISADDR 192.168.0.253 # .253 is the server's end

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

### /etc/ppp/radius.conf ####################################

auth 192.168.0.1 secretkey 5 3

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

Запуск сервера PPPoE:

/usr/libexec/pppoed–p \* -l pppoe fxp0

Настройка FreeRADIUS

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

cd /usr/ports/net/freeradius/

make && make install

Переходим в дистрибутив NeTAMS и копируем наш модуль rlm_netams куда следует; потом собираем:

cd ~/netams/addon/

cp–rp rlm_netams /usr/ports/net/freeradius/work/freeradius–1.0.1/src/modules/

cd /usr/ports/net/freeradius/work/freeradius–1.0.1/src/modules/rlm_netams

gmake

gmake install

Правим конфигурацию FreeRADIUS, чтобы использовать локальный сервер доступа с правильными паролями:

### /usr/local/etc/raddb/clients.conf #######################

client 192.168.0.1 {

secret = secretkey

shortname = pppoe_server

}

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

И чтобы использовать наш rlm_netams:

### /usr/local/etc/raddb/radius.conf #######################

…

modules {

…

netams {

server = «192.168.0.1» # netams server IP

port = 20001 # netams server port

login = «freeradius» # netams access username

password = «ABCDEF» # netams access password

swap–inout = «yes» # swap IN and OUT counters for accounting

defaultpolicy = «RadAcc»# policy for rawdata

billing–login = «no» # check username from unit or billing

}

}

authorize {

…

netams

}

authenticate {

…

netams

}

accounting {

…

netams

}

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

Настройка NeTAMS

Очень желательно добавить специального пользователя, от имени которого будет идти подключение к NeTAMS:

### /usr/local/etc/netams.cfg ###############################

user oid 0832ED name freeradius password ABCDEF permit radius

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

Если вы хотите использовать авторизацию доступа к веб–страницам со статистикой через mod_auth_radius, измените:

### /usr/local/etc/netams.cfg ###############################

service html

…

htaccess radius

…

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

Настройка Apache (опционально)

Берем mod_auth_radius отсюда: http://www.freeradius.org/mod_auth_radius/

Компилируем, ставим:

apxs–i–a–c mod_auth_radius.c

Настраиваем апач:

…

<IfModule mod_auth_radius.c>

AddRadiusAuth 192.168.0.1:1812 secretkey 5:3

AddRadiusCookieValid 5

</IfModule>

…

<Location /stat>

AllowOverride All

</Location>

…

Запускаем все хозяйство. Допустим, в конфигурационном файле у нас присутствует юнит с именем client1 и паролем abc, у него установлен адрес 192.168.0.111, и есть политика фильтрации с именем filter1 и OID ABCFEF.

Можно проверить работоспособность NeTAMS через утилиту netamsctl:

~#netamsctl radius auth nas login client1 password abc nas–id TEST

1 2

Framed–IP–Address: 192.168.0.111

Filter–ID: ABCFEF filter1

Здесь в первой строке вывода число «1» означает «успешно», далее «2» говорит от том, что последуют две строки параметров.

Первая строка передает IP–адрес этого юнита, Вторая — OID и имя фильтра (может быть затем использовано вашим скриптом if–up). В случае неправильного пароля:

~#netamsctl radius auth nas login client1 password abcef nas–id TEST

0 password incorrect for client1

В обоих случаях информация о событии попадет в лог–файл и таблицу EVENTS базы SQL.

Узнать, как происходит работа RADIUS–сервера, что кому куда передается, можно запустив этот сервер с ключом–X:

/usr/local/sbin/radiusd–X

TODO

• Сделать обработку аккаунтинга, поступающего от NAS–сервера. Видимо, для этого придется сделать новый тип data–source.

• Протестировать работу сервера доступа Cisco (никто не хочет дать тестовый доступ?)

• Сделать более жестким ограничение на тип передаваемого фильтра: сделать новый target radius–filter XXX. Сделать пример скрипта, который этот XXX обрабатывает.

• Сделать аналог rlm_netams для другого RADIUS–сервера? FreeRADIUS считается наиболее распространенным.

Сбор произвольных данных через 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

Начиная с версии NeTAMS 3.4.0 (build 3018) появилась возможность учета трафика путем опроса счетчиков SNMP удаленных устройств. Данная схема работает при наличии:

• Коммутатора или маршрутизатора, имеющего работающий SNMP–агент и поддерживающий MIB–II (фактически, любое устройство поддерживает этот MIB).

• Сервера UNIX, на котором установлены:

• NeTAMS нужной версии

• Пакет net–snmp версии 5

• Perl–модули к net–snmp

• Perl–модуль Net::Telnet

• Настроенного скрипта addon/snmp2netams.pl

• Настроенного data–source … type raw

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

Скрипт addon/snmp2netams.pl опрашивает перечисленные в его заголовке SNMP–устройства, используя заданное значение community. Запрашиваются имена интерфейсов и значения 64–битных счетчиков байт, прошедших через интерфейс:

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifName =

= 1.3.6.1.2.1.31.1.1.1.1

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets =

= 1.3.6.1.2.1.31.1.1.1.6

ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCOutOctets =

= 1.3.6.1.2.1.31.1.1.1.10

Полученная таблица преобразуется в формат, приемлемый для команды rawdata сервиса data–source. При этом имя юнита составляется из имени устройства, дефиса и имени интерфейса:

rawdata unit name catalyst1–fa0/1 policy ip

in 1234567 out 7654321 incremental

Название политики учета также задается в скрипте.

При помощи модуля Net::Telnet осуществляется подключение к демону netams, которому передаются команды rawdata. Использование параметра incremental приводит к корректному увеличению счетчиков учета netams (show lift full name catalyst1–fa0/1) при постоянном росте значений SNMP–счетчиков устройства.

Настройка

В заголовке скрипта addon/snmp2netams.pl необходимо:

@devices=(«catalyst»);

Перечислить через запятую заключенные в кавычки имена (hostname) устройств, откуда вы хотите собирать статистику.

$community=«public»;

Коммьюнити для чтения.

$netams_host=«localhost»;

$netams_port=20001;

$netams_login=«admin»;

$netams_password=«aaa»;

Параметры подключения к демону NeTAMS.

$policy_name=«ip»;

Имя политики учета, которая будет использоваться для счетчиков.

Настроить NeTAMS на новый источник данных:

service data–source 2

type raw

Настроить SNMP–устройство для того, чтобы оно могда отдавать статистику по протоколу SNMP. Допустим, что на сервере с адресом 192.168.0.1 работают snmp2netams.pl и сам демон NeTAMS. Для коммутатора Cisco Catalyst его настройки выглядят так:

access–list 1 permit 192.168.0.1

snmp–server community public RO 1

snmp–server ifindex persist

Протестировать скрипт и прописать его периодический запуск (раз в 5…15) минут в cron.

Вы можете включить режим вывода отладочной информации сервисом data–source…raw этой командой:

debug ds_raw

В ответ можно будет наблюдать следующее:

|ds_raw: unit catalyst–fa0/01(004FE6) policy ip(023CAA)

in=1234567, out 7654321,

time=1147365439, type=2, ds=data–source:3

Подробнее об использовании data–source…raw смотрите тут.

Примечания

Дополнительные сведения о настройке протокола SNMP на коммутаторах Cisco Catalyst можно почитать тут. Часто задаваемые вопросы о поддержке SNMP на Cisco собраны тут.

Значения счетчиков SNMP снимаются по длине пакетов на 2 уровне OSI. Это значит, что в суммарную длину входят заголовки IP пакета, и Ethernet–кадра. Также будут учтены все IP и Ethernet броадкасты и мультикасты, коих может быть много. На практике расхождения показателей IP–счетчиков и SNMP–счетчиков могут достигать 30%.

По 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)

Поддержка этой долгожданной возможности появилась в NeTAMS 3.3.3

Что протоколируется

При работе ряда сервисов data–source (кроме netflow) есть возможность «заглянуть» вовнутрь IP–пакета и проанализировать протоколы «выше» чем TCP/IP. Так, к примеру, пользовательский запрос к веб–сайту происходит согласно спецификации протокола HTTP/1.1. При должном анализе проходящих пакетов средствами NeTAMS стало возможным «запоминать» запрашиваемую ссылку и сохранять ее в таблице monitor. В комплекте поставки NeTAMS идет «недоразвитый» скрипт, позволяющий как–то просматривать собранную информацию.

Как включить

Собрать и поставить новую версию NeTAMS

Скачать, как обычно, дистрибутив, распаковать, скомпилировать, установить. При компиляции по умолчанию сборка будет вестись с ключом–DLAYER7_FILTER. Не забудьте установить новые CGI–скрипты, особенно monitor.cgi.

Настроить сервис data–source

Пропишите в конфигурацию нужного сервиса новый параметр: layer7–detect urls

Создать новую политику учета

В конфигурации сервиса processor добавьте описание новой политики:

policy name urls target layer7–detect

Указать политику учета для тех юнитов, которые надо отслеживать

В конфигурации сервиса processor для нужных юнитов добавьте новую политику учета:

unit host name pupkin ip 172.16.1.3 acct–policy urls

или, для всех юнитов

default acct–policy urls

Настроить сервис мониторинга

Как описано в этом документе. Дополнительных действий не требуется. Специально указывать юниты, которые хочется мониторить на layer7, не требуется. Если же вас интересует полный мониторинг какого–то юнита (по–старому), тогда такой юнит указывать все же необходимо.

(Опционально) обновить SQL–таблицу сервиса monitor

Если вы использовали мониторинг ранее (таблица monitor уже существует), ее необходимо обновить:

mysql netams

alter table monitor add column layer7 varchar(80);

Запустить NeTAMS

Проверка работы

Работоспособность механизма мониторинга ссылок можно проверить командами:

#netamsctl show ds

host: localhost port: 20001 login: anton password: aaa

cmd: show ds

Data–source ID=1 type LIBPCAP source xl1:0 loop 82356480 average 35 mcsec

Perf: average skew delay 2676 mcsec, PPS: 1060, BPS: 904985

IP tree: 258 nodes [12] + 4 dlinks [1024] + 254 unodes [20] = 12272 bytes

Flows: 1644/2507 act/inact entries (796992 bytes), 3332872 flows sent

HASH: size=65536, 1644 flows hashed, 1622 nodes used, max chain= 2

FIFO: 0/1871 used/ready messages, each 152, total 284392 bytes

Libpcap xl1 : EN10MB: 83735013 packets received, 488394 dropped

Эта команда показывает, что data–source действительно получает трафик и выдает сервису processor информацию о прошедших потоках.

#netamsctl show monitor

host: localhost port: 20001 login: anton password: aaa

cmd: show monitor

service monitor 1

Monitoring to storage: 1

Units:

Packets monitored: 1985769

Эта команда показывает, что сервис мониторинга получает информацию о потоках и пишет ее в базу.

debug ds_ip

debug monitor

Покажет, определяются ли ссылки в проходящем трафике и идет ли присвоение атрибута LAYER7 информации о потоках.

mysql netams

select count(*) from monitor where layer7 != NULL;

Показывает, сколько строк собралось в таблице мониторинга с информацией о ссылках.

Проблемы

• Мониторинг в SQL базу активно пожирает дисковое пространство! Например, за неделю работы программы, при общем количестве прошедшего трафика порядка 40 гигабайт (82 миллиона пакетов), в таблице мониторинга образовалось 2 миллиона записей). Размер SQL–таблицы и индекса составляет 240 мегабайт.

• Статистика по трафику для записанных в мониторинге ссылок относится не с скаченной информации, а к запросам на скачивание. Т.е. не надо обращать на цифры большого внимания. К сожалению, это обусловленно нессимитричностью хэш–функции преобразования данных IP–заголовка в индекс потока, т.е. трафик «запроса» и «ответа» попадет в разные потоки и длина «ответа», т.е. фактически скаченной по данному запросу информации, в таблице мониторинга не учтется. Изменить такое поведение технически очень непросто.

Отображение статистики

Отображением статистики занимается скрипт monitor.cgi, входящй с дистрибутив. Как им пользоваться — очевидно из его интерфейса. Пара скриншотов:

Content

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

ВНИМАНИЕ!

Введение

Инсталляция

Первоначальная настройка

Эксплуатация

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

Сервисы и команды

Команды rotate

Команды «show XXX»

Список всех команд

main

scheduler

server

processor

storage

data–source

alerter

html

monitor

quota

billing

login

acl–server

Cisco Netflow

NeTAMS на PC–маршрутизаторе

Простейший файл конфигурации

Startup–скрипт

Утилита netamsctl

Часто задаваемые вопросы

История проекта NeTAMS

База знаний

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

Утилита ascii2netflow

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

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

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

Что и зачем

Как поставить

Как использовать

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

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

Java API и сервлеты

Мониторинг

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

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

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

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

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

Заключение

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

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

Perl API

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

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

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

Поддержка RADIUS

Что именно поддерживается

Что не поддерживается

Как работает

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

TODO

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

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

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

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

Настройка

Примечания

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

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

Что протоколируется

Как включить

Проверка работы

Проблемы

Отображение статистики