Библиотека knigago >> Компьютеры и Интернет >> Сети >> Документация NetAMS


СЛУЧАЙНЫЙ КОММЕНТАРИЙ

# 1429, книга: Наследник Бури 2
автор: Алекс Гастов

"Наследник Бури 2" Алексея Гастова на первый взгляд может показаться типичным попаданческим романом, но за этим обманчивым фасадом скрывается нечто гораздо большее. Глубоко проработанный мир книги поражает своим размахом и продуманностью. Автор создал уникальную смесь славянской мифологии, аристократических интриг и элементов бояръаниме. Результат - захватывающий и свежий сеттинг, который удерживает читателя в напряжении от первой до последней страницы. Главный герой, сильный и...

Автор неизвестен - Документация NetAMS

Документация NetAMS
Книга - Документация NetAMS.  Автор неизвестен  - прочитать полностью в библиотеке КнигаГо
Название:
Документация NetAMS
Автор неизвестен

Жанр:

Сети

Изадано в серии:

неизвестно

Издательство:

netams.com

Год издания:

-

ISBN:

неизвестно

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "Документация NetAMS"

Аннотация к этой книге отсутствует.

Читаем онлайн "Документация NetAMS". [Страница - 5]

учета и фильтрации трафика, системную политику, принадлежность к определенному 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]

Напоминаем, --">

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.