- шлюзом выступает устройство провайдера, а в сети есть только файл-сервер;
- данные о трафике нужны не постоянно, а от времени к времени;
- устройство не поддерживает возможность запуска на нем сторонних программ;
- трафика столько, что сервер после запуска tcpdump-а «клеит ласты»;
- или наоборот, настолько мало, что его уровень сравним с долей (хотя и значительной) обычного трафика?
Дополнительную ложку дегтя в эту «бочку меда» задачи добавляет еще и отсутствие как у tcpdump, так и у tshark чудесного ключа «сгруппировать, просуммировать / усреднить и отсортировать».
Так что, при всем нежелании изобретать велосипед, пришлось закатить рукава и написать инструмент, удовлетворяющий следующим требованиям:
- источником данных выступает маршрутизатор или коммутатор, поддерживающий протокол sFlow;
- коллектор (tcpdump, tshark или sflowtool) данные в формате PCAP либо пишет в файл, либо передает на STDOUT;
- соответсвтенно, исходные данные могут быть вычитаны инструментом либо из файла, либо с STDIN-а;
- базовой единицей для анализа является пакет, а не соединение;
- результат должен включать информацию о направлении трафика, количестве прошедших пакетов, объеме трафика и среднем размере пакета;
- должна быть предусмотрена возможность базовой группировки и сортировки результата;
- ну и разные попутные мелочи;
- и при всем этом этот инструмент не должен дублировать функционал существующих общеизвестных инструментов.
Вот исходя из этого и был написан PCAParse — максимально простой инструмент для получения обобощенной информации о проходящем по сети трафике. Для его использования, в простейшем случае, достаточно коммутатора типа D-Link DGS-3XXX или аналога других производителей и запущенного на вышеупомянутом файл-сервере sflowtool либо tcpdump-а на офисном шлюзе. Как показывает практика, эти устройства давным давно утратили статус экзотических и встретить их можно даже в небольших офисах.
Для того, чтобы было понятно, о чем идет речь, приведу небольшой пример:
$ tshark -c 100 -w - | pcaparse
Filename: -
File size: -
Parsed: 100 samples in 4.90 seconds
Matched: 100 samples / 104.21kB
tcp: 20 samples / 2.04kB
udp: 76 samples / 101.79kB
icmp: 4 samples / 392B
other: 0 samples / 0B
Samples Summary Average
Destination count size size
212.XX.XXX.XX 86 102.43kB 1.19kB
tcp: 10 660B 66B
udp: 76 101.79kB 1.34kB
icmp: 0 0B 0B
other: 0 0B 0B
212.XX.XXX.XX 5 550B 110B
212.XX.XXX.XX 5 878B 176B
212.XX.XXX.XXX 4 392B 98B
Разумеется, сразу же бросается в глаза несуразное время работы, но на самом деле это — результат tshark-а, а не скрипта. Реальная его производительность на AMD A8-6600K @ 3,9 ГГц / 8 ГБ RAM составляет 15-25 килопакетов/с в зависимости от источника данных (чтение из файла, sFlow и т. д.).
Более требовательные пользователи могут затребовать более развернутую информацию:
$ tcpdump -w - | pcaparse -f - -d 212.XX.XX.XX
Filename: -
File size: 32.65MB
Parsed: 280692 samples in 27.58 seconds
Matched: 4383 samples / 3.75MB
tcp: 4 samples / 513B
udp: 4378 samples / 3.75MB
icmp: 0 samples / 0B
other: 0 samples / 0B
Samples Summary Average
Destination count size size
212.XX.XX.XX 4.38k 3.75MB 897B
tcp: 4 513B 128B
80 (http) 4 513B 128B
udp: 4378 3.75MB 898B
7 (echo) 2819 2.82MB 1.02kB
3389 (ms-wbt-server) 659 670.15kB 1.02kB
5538 273 86.15kB 323B
9584 87 24.62kB 290B
18002 92 26.55kB 295B
27186 167 55.68kB 341B
32302 279 89.50kB 328B
icmp: 0 0B 0B
other: 0 0B 0B
Если принять во внимание, что дамп для примера взят для обычного web-сервера, эта информация позволяет судить о наличии атаки DoS / DDoS по udp:* на ресурс. Ну, а это знание, позволяет уже принять какие-то адекватные меры. Для удобства дальнейшей обработки данных предусмотрен parser-friendly вывод:
$ pcaparse -f tcpdump-212-XX-XX-XX -d 212.XX.XX.XX -p 212.XX.XX.XX total 4382 3931684 897 212.XX.XX.XX tcp 4 513 128 212.XX.XX.XX tcp:80 4 513 128 212.XX.XX.XX udp 4378 3931171 897 212.XX.XX.XX udp:7 2819 2955528 1048 212.XX.XX.XX udp:3389 659 686237 1041 212.XX.XX.XX udp:5538 273 88222 323 212.XX.XX.XX udp:9584 87 25208 289 212.XX.XX.XX udp:18002 92 27185 295 212.XX.XX.XX udp:27186 167 57019 341 212.XX.XX.XX udp:32302 279 91644 328 212.XX.XX.XX icmp 0 0 0 212.XX.XX.XX other 0 0 0
Скрипт написан на perl-е с использованием модулей Net::PCAP и NetPacket::*, что обеспечивает достаточную производительность и кроссплатформенность. По крайней мере, на свежих linux-ах и FreeBSD проблем с запуском и работой не возникало.
Из известных минусов:
- отсутствие поддержки IPv6 (надеюсь, пока — над этим ведется работа);
- проверка диапазонов IP-адресов с использованием Data::Validate::IP (опять же, надеюсь, временно);
- отсутствие опции «сделать хорошо» у tcpdump или tshark (но, надеюсь, в будущем она может там появиться, если скрипт понравится авторам и контрибьюторам упомянутых инструментов и его функционал будет туда спортирован).
P.S. постфактум оказалось, что существует аналогичный инструмент — Fastnetmon, но он, все-таки, ориентирован под «стационарное» использование, поскольку подразумевает использование коллектора данных, с которым и взаимодействует клиентская часть.
Ссылки:
- PCAParse — github.com/kornix/pcaparse ;
- Fastnetmon — n0where.net/high-performance-dos-analyzer-fastnetmon ;
- DDS — gul-tech.livejournal.com/5959.html ;
- NFDUMP — nfdump.sourceforge.net ;
- NfSen — nfsen.sourceforge.net
Комментарии (21)
Maxim_ka
05.04.2016 18:17+1Давно хожу вокруг, да около fastnetmon, всё руки никак не дойдут потестить плотно. Кто-нибудь может описать опыт работы с ним?
kornix
05.04.2016 18:32+1В общем и целом работает. Из весьма полезных фич — прием данных по NetFlow, с mirror-портов и «родная» сигнализация на тему DoS/DDoS. Поскольку тоже perl-овый и подерживает плагины, весьма просто допилить под свои нужды, хотя, конечно, он потолще одного скрипта получается.
DenIvEvg
05.04.2016 18:49Почему perl-овый? fastnetmon написан на C++. Или я вас неправильно понял?
github.com/pavel-odintsov/fastnetmon/tree/master/srckornix
05.04.2016 18:55Да нет, все правильно. Крутил с пол-года тому, запамятовал. Посыпаю голову пеплом.
pavelodintsov
06.04.2016 06:13Ага, FNM на плюсах писан, полноценные плагины к нему только на С++ получится писать, но есть поддержка lua — для фильтров sflow / netflow (ну, скажем, отсечь заданные интерфейсы или размеры пакетов или что-то более сложное) :)
DenIvEvg
05.04.2016 18:50+1У нас уже больше года отлично работает.
PCAP — далеко не лучший выбор при большом количестве PPS.
Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.kornix
05.04.2016 19:03Большое количество — это сколько? При прочих равных sFlow на несколько порядков менее прожорлив, а потрафиковых тарифов я уже и не упомню, чтобы нужно было туда-сюда с точностью до байта считать.
DenIvEvg
05.04.2016 19:28+1Когда счёт идёт на сотни тысяч PPS.
Вот в чём дело:
«Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»
habrahabr.ru/post/261161
DenIvEvg
05.04.2016 19:31+1Фишка в том, чтобы пакеты обрабатывались еще на уровне ядра, а не в user space, как это происходит в случае с PCAP.
kornix
05.04.2016 19:49IMHO NetFlow обладает слишком большим оверхедом для задач оценки трафика. Для оценки достаточно объема информации, предоставляемой sFlow / jFlow. Количество пакетов, требующих обработки, в этом случае получается кардинально меньшим, нежели в схеме mirror/SPAN + linux box с ipt_netflow + коллектор. Схема сети получается более гибкая, по сравнению с mirror/SPAN, поскольку коллектор никак не привязывается к конкретному коммутатору. Да и в bottleneck SPAN-интерфейса мы никак не упираемся. И в производительность процессора для разбора PCAP.
КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.DenIvEvg
05.04.2016 20:08Если аппаратура сама умеет считать и отправлять куда нужно статистику, то конечно же всё будет хорошо.
Я про подсчёт сырого трафика средствами PCAP.
Вы ведь писали: «или tcpdump-а на офисном шлюзе».
Для малого офиса прокатит, а вот для большой сети вряд ли.
Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.pavelodintsov
06.04.2016 06:17+1Кстати, да, я больше люблю sflow v5 :) Но хорошего агента к нему для линукса нету (бесплатного), только коммерческие реализации. sflow хорош тем, что дает payload пакета и это дает очень большой простой для анализа, что же там внутри. Кроме этого, у него нету задержки (и аггрегации).
Хотя недавно мелькала тема, что можно сделать так, чтобы в NetFlow укладывались сэмплы (куски) пакетов, но как конкретно такое сделать на джуниере / циске — не особо ясно.
Если кто-то исследует вопрос — замутим такое дело в FNM ;)
Yagoda123
06.04.2016 08:05Совсем недавно столкнулись с подобным.
Получили DDOS порядка 1,5Гбит/с (550k pps). Шлюз (Linux) колом становился. Запустить что-то для анализа на нем было нереально.
Пришлось пропустить аплинки через D-Link DGS***, включить на нем sFlow. Сбор и анализ при помощи nfsen (благо уже был развернут).
В результате, при очередной атаке сразу получили все нужные данные. Ну и попросили вышестоящего провайдера заблокировать.
)) Убедились, что анализировать трафик на аплинках необходимо.
ИМХО. Nfsen — вполне достаточный для подобных задач инструмент. Ну и точность sFlow достаточна для оценки трафика. Плюс к этому можно настроить всевозможные алармы на почту. К тому-же самодостаточный — включает в себя и коллектор, и анализатор, и веб-морду.
Думаю, NetFlow для подобного будет сильно избыточный.
RicoX
06.04.2016 08:38А чем не устроил nfsen собранный с поддержкой sflow? Ну в вашем решении не вижу прикручивания к стороннему мониторингу, а nfdump+nfsen уже имеют простенькую морду и просто гору плагинов по анализу проходящего трафика, включая определение простых ДДоС как по конкретным атакующим хостам так и по геораспределенности. Ну и простенький генератор алярм в комплекте, как раз подходит для эпизодического использования.
kornix
06.04.2016 13:35Кто сказал, что не устроил? Просто ниша моего решения несколько другая — хотелось консольное приложение, которое бы позволило быстро получить обощенную информацию либо по уже существующему PCAP-файлу, который собран чем-то другим (типа sflowtools — путем скармливания файла с данными непосредственно приложению), либо аналогично быстро обобщить данные того же tcpdump-а (e. g. tcpdump -n -c 1000 -i eth0 -w — | сумматор). Честно говоря, меня бы гораздо больше устроило, если бы у tcpdump-а появилась фича выдачи обобщенной информации — тогда бы мне не пришлось ничего писать :)
Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.
Впредь буду формулировать мысли аккуратнее.
amarao
Буквально только что думал о том, что хочу sampled pcap, ваш вариант очень близок.
kornix
Ну что ж, могу сделать вывод, что раз хотелось аналогичного, значит какая-то перспектива у проекта светится…