Документация NetAMS - [4]

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