Comments 21
Буквально только что думал о том, что хочу sampled pcap, ваш вариант очень близок.
Давно хожу вокруг, да около fastnetmon, всё руки никак не дойдут потестить плотно. Кто-нибудь может описать опыт работы с ним?
В общем и целом работает. Из весьма полезных фич — прием данных по NetFlow, с mirror-портов и «родная» сигнализация на тему DoS/DDoS. Поскольку тоже perl-овый и подерживает плагины, весьма просто допилить под свои нужды, хотя, конечно, он потолще одного скрипта получается.
У нас уже больше года отлично работает.
PCAP — далеко не лучший выбор при большом количестве PPS.
Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.
PCAP — далеко не лучший выбор при большом количестве PPS.
Мы зеркалируем трафик на машину с Linux, на которой модуль ядра ipt_netflow считает трафик, и передаёт статистику для fastnetmon в формате NetFlow.
Большое количество — это сколько? При прочих равных sFlow на несколько порядков менее прожорлив, а потрафиковых тарифов я уже и не упомню, чтобы нужно было туда-сюда с точностью до байта считать.
Когда счёт идёт на сотни тысяч PPS.
Вот в чём дело:
«Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»
habrahabr.ru/post/261161
Вот в чём дело:
«Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.
Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.
Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.»
habrahabr.ru/post/261161
Фишка в том, чтобы пакеты обрабатывались еще на уровне ядра, а не в user space, как это происходит в случае с PCAP.
IMHO NetFlow обладает слишком большим оверхедом для задач оценки трафика. Для оценки достаточно объема информации, предоставляемой sFlow / jFlow. Количество пакетов, требующих обработки, в этом случае получается кардинально меньшим, нежели в схеме mirror/SPAN + linux box с ipt_netflow + коллектор. Схема сети получается более гибкая, по сравнению с mirror/SPAN, поскольку коллектор никак не привязывается к конкретному коммутатору. Да и в bottleneck SPAN-интерфейса мы никак не упираемся. И в производительность процессора для разбора PCAP.
КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.
КМК, для каждой задачи — свой инструмент. И, опять же, КМК, для оценки профиля трафика, NetFlow — не лучший выбор.
Если аппаратура сама умеет считать и отправлять куда нужно статистику, то конечно же всё будет хорошо.
Я про подсчёт сырого трафика средствами PCAP.
Вы ведь писали: «или tcpdump-а на офисном шлюзе».
Для малого офиса прокатит, а вот для большой сети вряд ли.
Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.
Я про подсчёт сырого трафика средствами PCAP.
Вы ведь писали: «или tcpdump-а на офисном шлюзе».
Для малого офиса прокатит, а вот для большой сети вряд ли.
Также вангую, что если малый офис подвергнется DDoS атаке типа NTP amplification, то шлюз с запущенным tcpdump сразу склеит ласты.
Также, при определённых условиях любой из сотрудников малого офиса может положить торрентом шлюз с запущенным tcpdump.
Кстати, да, я больше люблю sflow v5 :) Но хорошего агента к нему для линукса нету (бесплатного), только коммерческие реализации. sflow хорош тем, что дает payload пакета и это дает очень большой простой для анализа, что же там внутри. Кроме этого, у него нету задержки (и аггрегации).
Хотя недавно мелькала тема, что можно сделать так, чтобы в NetFlow укладывались сэмплы (куски) пакетов, но как конкретно такое сделать на джуниере / циске — не особо ясно.
Если кто-то исследует вопрос — замутим такое дело в FNM ;)
Хотя недавно мелькала тема, что можно сделать так, чтобы в NetFlow укладывались сэмплы (куски) пакетов, но как конкретно такое сделать на джуниере / циске — не особо ясно.
Если кто-то исследует вопрос — замутим такое дело в FNM ;)
Есть еще один прекрасный проект на эту тему: http://gul-tech.livejournal.com/5959.html
Совсем недавно столкнулись с подобным.
Получили DDOS порядка 1,5Гбит/с (550k pps). Шлюз (Linux) колом становился. Запустить что-то для анализа на нем было нереально.
Пришлось пропустить аплинки через D-Link DGS***, включить на нем sFlow. Сбор и анализ при помощи nfsen (благо уже был развернут).
В результате, при очередной атаке сразу получили все нужные данные. Ну и попросили вышестоящего провайдера заблокировать.
)) Убедились, что анализировать трафик на аплинках необходимо.
ИМХО. Nfsen — вполне достаточный для подобных задач инструмент. Ну и точность sFlow достаточна для оценки трафика. Плюс к этому можно настроить всевозможные алармы на почту. К тому-же самодостаточный — включает в себя и коллектор, и анализатор, и веб-морду.
Думаю, NetFlow для подобного будет сильно избыточный.
Получили DDOS порядка 1,5Гбит/с (550k pps). Шлюз (Linux) колом становился. Запустить что-то для анализа на нем было нереально.
Пришлось пропустить аплинки через D-Link DGS***, включить на нем sFlow. Сбор и анализ при помощи nfsen (благо уже был развернут).
В результате, при очередной атаке сразу получили все нужные данные. Ну и попросили вышестоящего провайдера заблокировать.
)) Убедились, что анализировать трафик на аплинках необходимо.
ИМХО. Nfsen — вполне достаточный для подобных задач инструмент. Ну и точность sFlow достаточна для оценки трафика. Плюс к этому можно настроить всевозможные алармы на почту. К тому-же самодостаточный — включает в себя и коллектор, и анализатор, и веб-морду.
Думаю, NetFlow для подобного будет сильно избыточный.
А чем не устроил nfsen собранный с поддержкой sflow? Ну в вашем решении не вижу прикручивания к стороннему мониторингу, а nfdump+nfsen уже имеют простенькую морду и просто гору плагинов по анализу проходящего трафика, включая определение простых ДДоС как по конкретным атакующим хостам так и по геораспределенности. Ну и простенький генератор алярм в комплекте, как раз подходит для эпизодического использования.
Кто сказал, что не устроил? Просто ниша моего решения несколько другая — хотелось консольное приложение, которое бы позволило быстро получить обощенную информацию либо по уже существующему PCAP-файлу, который собран чем-то другим (типа sflowtools — путем скармливания файла с данными непосредственно приложению), либо аналогично быстро обобщить данные того же tcpdump-а (e. g. tcpdump -n -c 1000 -i eth0 -w — | сумматор). Честно говоря, меня бы гораздо больше устроило, если бы у tcpdump-а появилась фича выдачи обобщенной информации — тогда бы мне не пришлось ничего писать :)
Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.
Впредь буду формулировать мысли аккуратнее.
Я в самой статье этот момент, к сожалению, упустил — хотелось именно а) консольное, б) заточенное под максимально распространенный и поддерживаемый коллекторами формат данных и в) без лишних свистелок. Так, чтобы можно было зайти на сервер с мобильного устройства в консоль 80x25 и получить необходимые данные.
Впредь буду формулировать мысли аккуратнее.
Sign up to leave a comment.
Быстрый анализ транзитного трафика