Сбор статистики по TCP/IP на базе NeTraMetМатыцын Денис ( gdenis@aport.ru )v 1.5, 24 марта 2002 года Данный документ описывает схему сбора статистики по траффику TCP/IP на базе *nix и пакета NeTraMet. Описание весьма поверхностное ибо не призвано заменить документацию, а лишь помочь запустить и оценить комплекс. Я думаю, что мои решения подойдут почти в любом случае с минимальной правкой. На данный момент документ неполон - любые комментарии и дополнения принимаются. ВведениеЯ столкнулся с проблемой подсчета траффика по IP адресам в своей сети. Причем, кроме количества необходимо было иметь статистику по типу траффика: SMTP, ICMP, HTTP, FTP, UDP, TCP... Также должна быть возможность подробного регистрирования траффика для, так сказать, проблемных ситуаций. Инструмент должен был быть универсальным и производительным (расчетная нагрузка 10 Gb в сутки). В результате долгих поисков был найден NeTraMet на котором сейчас все и работает. Проблемы с которыми я столкнулся:
На эти вопросы я и постараюсь ответить в этом HowTo и в следующем посвященном анализу журналов NeTraMet. Преимущества NeTraMet
Недостатки NeTraMetКроме упомянутых проблем хочется отметить:
Описание комплекса NeTraMetКомплекс состоит из:
Структура сетиПояснение к структуре сети
Софт: Я использую на METER FreeBSD 4.5 по, так сказать, субъективным причинам. На нем установлен комплекс NeTraMet и запущен сборщик пакетов NeTraMet, программное обеспечение для удаленного управления OpenSSH и сервер точного времени xntp. Никаких других приложений на нем быть не должно, для исключения атак типа DoS или банального взлома. Сервер должен быть доступен по сети только с MANAGER. Остальные обращения должны блокироваться во избежания опять же взлома. Железо: Зависит от нагрузки на сеть. Обязательно должна быть очень хороший сетевой адаптер - я использую адаптеры фирмы 3com серия 980. Памяти не менее 32 Мбайт, процессор Pentium. Диска может не быть вовсе и загружаться по сети (очень рекомендую - любая механика сильно снижает отказоустойчивость системы). Обязательно должны быть дополнительные вентиляторы. Рекомендации по опциям запуска NeTraMet даны ниже исходя из этих минимальных требований.
Доступ из Интернет к серверу должен быть запрещен.
Сетевые адаптеры одного типа, рекомендую:
Внимание! Чтобы NeTraMet собирал статистику нужно чтоб траффик попадал на его сетевую карту - именно поэтому в сети используется концентратор. Правила NeTraMetИтак, вот и он: # Наши сети define net = (63.43.3.0/27,63.43.4.0/24,10.0.0.0/27); # Интересуемые серверные порты define srv = (53,161,20,21,22,23,69,80,110,25,143,443,119,139,3306,6667,123); # IP по которым ведется полнейшая статистика. Например, проблемные клиенты. define watch=(127.0.0.1/32); # Интересует только IP. Остальное по боку. ══ IF SourcePeerType == IP SAVE ; ══ ELSE IGNORE; # Инициализация служебных значений store DestClass := 0; store SourceClass := 0; store FlowKind := 0; # Сохраняем тип: UDP, TCP, ICMP SAVE SourceTransType; # Если источник наш, то сохраняем IP IF SourcePeerAddress == net { # Источник наш сохраняем SourceClass = 1 store SourceClass := 1; # Если серверный порт у источника, тоже сохраняем IF SourceTransAddress == srv { SAVE SourceTransAddress; } # Cохраняем IP отправителя SAVE SourcePeerAddress; } # Если получатель наш IF DestPeerAddress == net { # Получатель наш сохраняем DestClass = 1 store DestClass := 1; # Если серверный порт у получателя, тоже сохраняем IF DestTransAddress == srv { SAVE DestTransAddress; } # Cохраняем IP получателя SAVE DestPeerAddress; } # Если пакет не наш, то сохраняем все-все-все IF DestClass == 0 && SourceClass == 0 { SAVE SourcePeerAddress; SAVE DestPeerAddress; SAVE SourceTransAddress; SAVE DestTransAddress; # По этому служебному значению потом будем искать непонятный траффик store FlowKind := 9; } # Это случай когда кто-то коннектится к нам IF DestClass == 1 && SourceClass == 0 { IF SourceTransAddress == srv { SAVE SourceTransAddress; } # Наш сервис кому-то понадобился store FlowKind := 1; # А вот здесь мы проверим не надо ли залогить все подряд по IP IF DestPeerAddress == watch { SAVE SourcePeerAddress; # Метка слежки для разбора журналов store FlowKind := 5; } } # Мы забираем у кого-то. Алгоритм аналогичен предыдущему IF DestClass == 0 && SourceClass == 1 { IF DestTransAddress == srv { SAVE DestTransAddress; } store FlowKind := 1; IF SourcePeerAddress == watch { SAVE DestPeerAddress; store FlowKind := 5; } } # Если траффик внутренний IF DestClass == 1 && SourceClass == 1 { # Помечаем как внутренний store FlowKind := 3; } COUNT; # Формат вывода в журнал. Пояснения давать пока лень # Смотрите документацию к NeTraMet FORMAT ═ sourcepeeraddress destpeeraddress tooctets fromoctets topdus frompdus ═ sourcetransaddress desttransaddress sourcetranstype flowkind flowindex ═ firsttime lasttime flowruleset; STATISTICS ; SET 5; Описание атрибутовАтрибуты IP:SourcePeerType - тип траффика: IP или что-либо иное SourcePeerAddress, DestPeerAddress - IP адрес источника сетевого потока. Источником считается тот IP с которого шел первый пакет зарегистрированный сборщиком NeTraMet. Это не всегда клиент :-) SourceTransType - протокол IP: 1 = ICMP, 17 = UDP, 6 = TCP, 18 = OSPF ... SourceTransAddress, DestTransAddress - для TCP и UDP траффика, эти поля содержат порты источника и получателя пакетов: 20 = FTP-DATA, 21 = FTP, 80 = WWW, 23 = TELNET, 119 = NNTP, 25 = SMTP, 123 = NTP, 53 = DOMAIN, 161 = SNMP ... Фрагментированные пакеты обрабатываются несколько иначе, т.к. только первый пакет содержит полноценный заголовок, у остальных фрагментов SourceTransType и DestTransType = 0. Для ICMP пакетов поле SourceTransAddress содержит тип ICMP, а DestTransAddress - код ICMP: 0 = echo reply, 5 = redirect, 3 = destination unreachable, 8 = echo request. Атрибуты предоставляемые NeTraMet:SourceInterface, DestInterface - интерфейсы cборщика NeTraMet. Первый - 1, второй - 2 и тд. SourceClass, DestClass, FlowClass, SourceKind, DestKind, FlowKind - пользовательские атрибуты. В моем случае: SourceClass, DestClass:1 - IP из наших сетей, 0 - IP не входит в наши сети. FlowKind: 1 - траффик из или в Интернет, 3 - внутренний траффик между нашими сетями, 5 - траффик из или в Интернет для отслеживаемых IP адресов или сетей, 9 - неопознанный траффик. FlowIndex - индекс сетевого потока в сборщике пакетов NeTraMet. FlowRuleSet - номер набора правил. ToOctets, FromOctets - количество байт, 'to' - от источника к получателю (source to destination), 'from' - от получателя к источнику. ToPDUs, FromPDUs - количество пакетов, 'to' - от источника к получателю (source to destination), 'from' - от получателя к источнику. FirstTime - время регистрации первого случая сетевой активности в тиках от старта сборщика (тик - 1/1000 секунды). LastTime - время последнего изменения счетчиков сетевого потока. Внимание! Счетчики пакетов и траффика коммулятивные. Каждый раз когда приходит пакет для имеющегося потока счетчик траффика увеличиваются на размер пакета, увеличивается счетчик пакетов и изменяется аттрибут LastTime на текущее время от запуска сборщика. Компиляция правилСохраняем приведенный выше конфиг в файл типа /root/ntm.sh/short.3.srl и компилируем: # cd /root/ntm.sh/ # srl short.3.srl Файл на выходе short.3.rules и есть правила для сборщика пакетов, этот файл указывается в опции ╚-r╩ при запуске NeMaC на MANAGER. # ls short.3.rules short.3.srl Быстрый запуск сборщика NeTraMetДля FreeBSD: Сценарий запуска на METER. # cat /usr/local/etc/rc.d/netramet.sh /usr/local/bin/NeTraMet \ -i network_interface \ -l \ -m 614 \ -r password_for_read \ -w password_for_write_and_read \ -f 60000 \ -D > /dev/null 2>&1 echo " NeTraMet" NeTraMet. Для Linux: Сохраняем приведенную выше команду запуска NeTraMet в файл /root/ntm.sh/netramet.sh. Добавляем вызов этого сценарий в конец /etc/rc.d/rc.local, для автозапуска NeTraMet при старте системы: /root/ntm.sh/netramet.sh Ключи запуска NeTraMet'-i network_interface' - сетевой интерфейс, может быть: eth0,eth2, xl0 или что-нибудь подобное :-) '-l ' - использовать размер пакета из заголовка, а не аппаратный размер, я так понимаю размер на уровне Ethernet. '-m 614' - UDP порт на котором будет общаться NeTraMet c NeMaC. '-r password_for_read' - пароль с правами чтения '-w password_for_write_and_read' - пароль на чтение-запись. '-f 60000' - максимальное количество сетевых потоков в NeTraMet. Чем больше клиентов, траффика и степень детализации статистики тем больше сетевых потоков. Не ставьте слишком много, а то машина помрет от свопа. Быстрый запуск менеджера NeMaCNeMaC. Запускаем на MANAGER. Сценарий запуска: # cat /root/ntm.sh/nemac.short.sh DATER=`date +%Y%m%d%H%M%S` cd /var/ntm.log /usr/bin/NeMaC \ -k 120 \ -F /var/ntm.log/$DATER.flows \ -a 300 \ -b /usr/share/NeTraMet/mibs/mib.txt \ -m 614 \ -c 900 \ -p \ -D \ -L /var/ntm.log/$DATER.nemac \ -r /root/ntm.sh/short.3.rules \ ip_adress_METER password_for_write_and_read Добавляем вызов этого сценарий в конец /etc/rc.d/rc.local, для автозапуска NeMaC при старте системы: /root/ntm.sh/nemac.short.sh Каждую ночь я обнуляю весь комплекс для окончательной обработки журналов сценарием: # cat /etc/cron.daily/ntm_starter.sh /usr/bin/killall NeMaC /bin/mv /var/ntm.log/* /var/ntm.log.toload /root/ntm.sh/nemac.short.sh Внимание! Во время переноса статистики траффик не собирается. Лучше делать в рамках одной файловой системы (пара секунд - ерунда). Ключи запуска NeMaC'-k 120' - каждые 120 секунда NeMaC будет проверять не перезагрузился ли NeTraMet. Загружает правила если NeTraMet перезапускался. '-F /var/ntm.log/$DATER.flows' - суда писать статистику. '-a 300' - непомню что за опция... Наверно зачем-то нужна :-) '-b /usr/share/NeTraMet/mibs/mib.txt' - файл с MIB. Входит в поставку. Может быть /usr/local/usr/share/NeTraMet/mibs/mib.txt '-m 614' - порт для управления сборщиками NeTraMet. '-c 900' - забирать забирать статистику со сборщиков каждые 15 минут. '-p' - после записи в файл статистики очередной порции данных закрывать его. Если файл не найден то начинается новый файл. '-D' - непомню что за опция... Наверно зачем-то нужна :-) '-L /var/ntm.log/$DATER.nemac' - журнал работы NeMaC. '-r /root/ntm.sh/short.3.rules' - файл c правилами. 'ip_adress_METER password_for_write_and_read' - без комментариев :-) Журнал сетевых потоковЧто из себя представлет журнал? Текстовый файл с заголовками и данными по сетевым потокам. Пример: Заголовок журнала ##NeTraMet v4.3: -c900 -r /root/ntm.sh/short.3.rules 63.43.3.2 xl0 60000 flows starting at 04:03:29 Thu 3 Jan 2002 Формат сетевых пакетов. Задается в правилах, директивой FORMAT. Значения этих отрибутов я уже описал в "Описание атрибутов". #Format: sourcepeeraddress destpeeraddress tooctets fromoctets topdus frompdus sourcetransaddress desttransaddress sourcetranstype flowkind flowindex firsttime lasttime flowruleset Время, дата, имя сборщика пакетов NeTraMet, потоки с 0 до 57907002. #Time: 04:03:29 Thu 3 Jan 2002 63.43.3.2 Flows from 0 to 57907002 Еще заголовок :-) #Ruleset: 12 5 /root/ntm.sh/short.3.rules NeMaC Заголовок с статистикой загрузки сборщика пакетов, присутствует если в правилах есть команда STATISTICS. aps = количество пакетов в секунду, среднее #Stats: aps=6 apb=0 mps=280 mpb=0 lsp=0 avi=99.9 mni=0.0 fiu=2 frc=64 gci=10 rpp=18.2 tpp=1.4 cpt=1.0 tts=32749 tsu=0 Метка конца дампа статистики. #EndData: 63.43.3.2 Следующая порция. Время, дата, имя сборщика пакетов NeTraMet, потоки с 57907001 до 58006116. #Time: 04:20:00 Thu 3 Jan 2002 63.43.3.2 Flows from 57907001 to 58006116 Заголовок с статистикой загрузки сборщика пакетов. #Stats: aps=7 apb=0 mps=153 mpb=0 lsp=0 avi=99.9 mni=0.0 fiu=23 frc=0 gci=10 rpp=18.6 tpp=1.4 cpt=1.0 tts=32749 tsu=19 А вот и первый поток :-) Итак, 63.43.3.2 и 63.43.3.1 пообщались по UDP на нестандартных портах. С 63.43.3.2 на 63.43.3.1 отправлено 17401 байт, в 29 пакетах, получено 15680 байт в 28 пакетах. Порт источника не описан в 'srv' в правилах и поэтому не сохранен, 0. Порт получателя тоже не описан в 'srv' и тоже не сохранен, 0. 17 - использован протокол UDP. 3 - траффик внутренний. 4611 - индекс потока, время первой регистрации 57906966, время последнего изменения 58002914. Набор правил номер 12. 63.43.3.2 63.43.3.1 17401 15680 29 28 0 0 17 3 4611 57906966 58002914 12 Так, кому-то из Интернета понадобился наш сервер, по протоколу TCP, порты нестандартные. 0.0.0.0 63.43.4.43 167280 1729290 2788 2931 0 0 6 1 4612 57906977 58005341 12 Хост 63.43.4.34 довольно интенсивно использовал чужой ДНС (порт 53) по UDP. 63.43.4.34 0.0.0.0 33616 7958 491 82 0 53 17 1 4613 57907405 58005279 12 ICMP пакеты из Инетрнета на хост 63.43.4.34 и обратно. Не иначе хацкер :-) 0.0.0.0 63.43.4.34 14140 5430 202 57 0 0 1 1 4614 57907410 58003939
12 Метка конца дампа статистики. #EndData: 63.43.3.2 Еще порция данных. Их я уже объяснил. Посмотрим как изменились наши потоки. #Time: 04:35:00 Thu 3 Jan 2002 63.43.3.2 Flows from 58006115 to
58096066 Обратите внимание что счетчики байт, пакетов изменились. 63.43.3.2 и 63.43.3.1 продолжают общаться :-) 63.43.3.2 63.43.3.1 22904 18554 41 40 0 0 17 3 4611 57906966 58090063
12 Метка конца дампа статистики. #EndData: 63.43.3.2 Журнал работы NeMaC
|
| Previous page: doc.nettools.ru/Unix | Main page: www.nettools.ru |
