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 из модуля ядра, происходит разбор заголовков и полный
