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
