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

Поскольку 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, проводится периодическое устаревание потоков и отправка их на учет «наверх», демону.