[pavel.odintsov]

Добрый день, уважаемое сообщество!

 

Хочу поделиться своей наработкой, актуальный список фич на 21е ноября 2015го года выглядит вот так:

 

• Complete BGP Flow Spec support, RFC 5575
• Can process incoming and outgoing traffic
• Can trigger block script if certain IP loads network with a large amount of packets/bytes/flows per second
• Thresholds could be configured in per subnet basis with hostgroups feature
• Could announce blocked IPs to BGP router with ExaBGP
• GoBGP integration for unicast IPv4 announces
• Full integration with Graphite and InfluxDB
• API
• Redis integration
• MongoDB integration
• Deep packet inspection for attack traffic
• netmap support (open source; wire speed processing; only Intel hardware NICs or any hypervisor VM type)
• SnabbSwitch support (open source, very flexible, LUA driven, very-very-very fast)
• Could filter out NetFLOW v5 flows or sFLOW packets with script implemented in LUA (useful for port exclude)
• Supports L2TP decapsulation, VLAN untagging and MPLS processing in mirror mode
• Can work on server/soft-router
• Can detect DoS/DDoS in 1-2 seconds
• Tested up to 10GE with 12 Mpps on Intel i7 3820 with Intel NIC 82599
• Complete plugin support
• Could capture attack fingerprint in pcap format
• Have complete support for most popular attack types

Изменено 20 января, 2018 пользователем pavel.odintsov

[photon]

Это хорошо, но если вы рассчитываете на широкое распространение, то нужно писать на простом C без всяких плюсов и 11. Комментарии в коде нужно делать на английском языке. Не помешает также нормальный Makefile вместо какого-то shell-скрипта.

[Ivan_83]

iftop чем то хуже?)

[Lynx10]

но на скоростях в районе 100 мегабит должно нормально

интересно но нужно для больших скоростей.... особенно если с инета атаки....

[pavel.odintsov]

iftop чем то хуже?)

 

День добрый!

 

Много чем хорош, но под наши задачи совершенно не подходит.

 

Если предметно:

• pcap на скоростях более 100 мегабит и при большом числе сессий/pps теряет более половины пакетов и потребляет огромное число ресурсов
  
• iftop не отображает нагрузку в pps, а она важнее, чем мегабиты по крайне мере в нашем случае
  
• У iftop очень перегруженный интерфейс
  
• iftop не может работать в режиме слежения и его выдача очень сложна для анализа скриптами
  

 

но на скоростях в районе 100 мегабит должно нормально

интересно но нужно для больших скоростей.... особенно если с инета атаки....

 

Программа поддерживает работу как по pcap, так и по ULOG2. По нашим тестам pcap - это очень и очень странная и тормозная штука. На скоростях выше 100 мегабит (а тем более на 4-5 сотнях мегабит) он теряет больше половины пакетов.

 

Может быть мы не умеем готовить pcap, но:

• Сами raw сокеты на Linux никогда не отличались скоростью
  
• Вариация с буферами pcap никак не решила проблему
  
• Потери пакетов имеются также и у самого tcpdump, так что вряд ли это наш косяк
  
• ULOG2 изумительно работает на скорости в несколько гигабит, но требует дополнительной настройки - создания iptables target'а
  
• Но при этом ULOG2 потребляет в разы меньше ресурсов, чем PCAP и меньше грузит процессор
  

 

Так что на больших скоростях я рекомендую ULOG2 режим.

 

Во время тестов скрипт отлично ловил атаки в 150-300kpps.

 

Вот текущие показатели с одного из серверов, где работает анализатор, это даже не средняя нагрузка, намного меньше:

Outgoing traffic 89409 pps 696 mbps

Incoming Traffic 71423 pps 160 mbps

[pavel.odintsov]

Это хорошо, но если вы рассчитываете на широкое распространение, то нужно писать на простом C без всяких плюсов и 11. Комментарии в коде нужно делать на английском языке. Не помешает также нормальный Makefile вместо какого-то shell-скрипта.

 

Да, тут согласен build.sh/C++11 можно привести в вид Makefile/С++ 03, но отказываться от С++, увы, дорого выйдет, я не готов заменить map/pair/vector. В ближайшие дни постараюсь внести все эти пожелания и выкатить новую ветку.

[ichthyandr]

Программа поддерживает работу как по pcap, так и по ULOG2. По нашим тестам pcap - это очень и очень странная и тормозная штука. На скоростях выше 100 мегабит (а тем более на 4-5 сотнях мегабит) он теряет больше половины пакетов.

Могу выразить несогласие. PCAP отлично работает, правда, проект который делал с его использованием был под винду. Суть проекта была - принять видеопоток в YUV формате с камеры и отобразить, поток > 400мбит/сек. Почему не на сокетах делал? Потому что так же товарищ, который занимался проектом сказал - сокеты тормозят, однако причина тормозов была в отображении. Поэтому как-то сразу начал использовать PCAP. Скорее всего потеря пакетов на PCAP у вас связана с активным использованием malloc/free. Попробуйте обращаться к памяти по другому.

[pavel.odintsov]

ichthyandr, поток в 400 мегабит с каким числом числом pps? 200 000 pps и типовое для такого потока как у Вас 500-1000 - это две больших разницы, ибо вызов колбэка равен pps. Кроме того, под Windows, насколько я знаю, pcap работает сильно иначе. Я уже говорил, что после почти недели попыток приручения pcap повторил точь-в-точь ту же проблему на обычном tcpdump, который пакеты также теряет, вне зависимости от объема буферов и длины захвата (snaplen).

 

По поводу аллокации памяти - вопрос открытый, тут я, честно говоря, вполне ожидаю подставы от std::map и попробую сейчас это проверить.

[ichthyandr]

ichthyandr, поток в 400 мегабит с каким числом числом pps? 200 000 pps и типовое для такого потока как у Вас 500-1000 - это две больших разницы, ибо вызов колбэка равен pps. Кроме того, под Windows, насколько я знаю, pcap работает сильно иначе. Я уже говорил, что после почти недели попыток приручения pcap повторил точь-в-точь ту же проблему на обычном tcpdump, который пакеты также теряет, вне зависимости от объема буферов и длины захвата (snaplen).

 

По поводу аллокации памяти - вопрос открытый, тут я, честно говоря, вполне ожидаю подставы от std::map и попробую сейчас это проверить.

не в pps-ах дело, а дело в обращениях к менеджеру памяти и как вы это реализуете. Если на каждый пакет вы выделяете память (это я Вам уже прямым текстом подсказываю), то чем больше поток и пакетов в секунду - тем больше тормоза. И не надо тем более связываться с выделением памяти через контейнеры STL. Почитайте чтоли electronix.ru - как народ вылизывает код, чтобы тот шустро работал на слабеньких процессорах. В качестве вариантов:

1) выделяете один раз столько буферов в памяти сколько нужно, чтобы не было на каждый пакет malloc/free (если работаете через STL - этих операций не избежать)

2) выделяете один большой буфер, сажаете на него свой менеджер памяти и вместо использования системных malloc/free - используете свои, работающие с этим менеджером.

 

Операции выделения-освобождения памяти очень затратны

 

PS применительно к моей задаче - в начале программы я выделял всего два буфера (под два кадра, так как так был организован поток с камеры) и все. Посчитайте такты процессора в конце концов - спрофилируйте код. И на винде libpcap внутренне ничем не отличается от линуксового

Изменено 14 ноября, 2013 пользователем ichthyandr

[pavel.odintsov]

photon, bash скрипт сборки выкинут, сделан Makefile. Продолжаем работу)

 

ichthyandr, спасибо за критику, пока не могу подтвердить, что pcap начал работать нормально, но вот то, что SLT map ведет себя страшно (ну ведет-то он себя ожидаемо, просто в данном случае это получается очень медленно) - подтвердилось в gprof.

[pavel.odintsov]

ichthyandr, а не подскажете, может ли pcap слушать определенные интерфейсы - 4 штуки или только либо один либо все?

[ichthyandr]

ichthyandr, а не подскажете, может ли pcap слушать определенные интерфейсы - 4 штуки или только либо один либо все?

привет, не могу сказать, сам не делал, libpcap вроде слушает только один интерфейс. Программно можно попробовать запускать отдельные процессы, каждый из которых слушает свой интерфейс

[wtyd]

Добрый день, уважаемое сообщество!

 

Хотел бы поделиться своей программой для анализа проходящего через миррор порты/роутеры трафика: https://github.com/FastVPSEestiOu/fastnetmon

 

• 
   
  
• Для чего она писалась? Чтобы фиксировать серьезные всплески по полосе/pps как со стороны клиентов, так и со стороны интернета в сторону клиентов.
  
• Что выдает? Выдает топ 10 самых активных потребителей ресурсов сети, выборки топ 10 можно делать как по pps так и по трафику
  
• Что умеет? Умеет передавать управление внешнему скрипту, который забанит пользователя либо передаст его на анализ группе администраторов
  
• На чем работает? Поддерживает pcap (очень медленно, но на скоростях в районе 100 мегабит должно нормально) и ulog2 (на порядки быстрее и надежнее)
  
• Что еще умеет? Умеет считать трафик по заданным диапазонам, решение базируется на redis и используется в исключительно внутренних целях
  
• На каком канале работает? Приложение сейчас в продакшене (на миррор портах, с отдельной машины) с нагрузкой в несколько гигабит входящего+исходящего трафика с примерно 250kpps и более в среднем. Ресурсы жрет довольно хорошо :)
  
• На какой платформе точно работает? Debian 7 Wheezy, с остальными надо заниматься отдельно, так как используется C++11
  
• На чем написано? C++
  

 

Предвосхищая обвинения в том, что это костыль или "не нужно" хочу сказать, что в связи с врожденной ленью перебрал очень много решений до начала реализации своего и все они просто не работали на наших потоках трафика. Силами свичей/роутеров невозможно создавать число рейт лимитеров/анализаторов для нашего числа с IP (сильно больше 10000).

 

Есть проект http://www.ntop.org/products/pf_ring/ с аццкем libpcap. Не совсем тривиально ставить, т.к. там ограничения в версиях ядра есть. Потом можно пересобрать нужный софт и слинковать его с этим аццке быстрым lipbcap. Пробовал, tcpdump в некоторых случаях захватывал/дропал не совсем то количество пакетов, которое указывал, а вот с pf_ring всегда именно указанное количество и ноль дропов. Т.е. профит вроде бы есть :-).

 

Ещё была такая программка как rate. Надо попробовать её слинковать с pf_ring'овским libpcap. rate показывает хитпарад качков тоже поразным параметрам, но вот только home page я найти не могу с таким названием, увы :-).

[icegloom]

в фряшных портах есть net-mgmt/rate адрес домашней странички http://s-tech.elsat.net.pl/

[wtyd]

в фряшных портах есть net-mgmt/rate адрес домашней странички http://s-tech.elsat.net.pl/

 

Спасибо за ссылку. Там кроме rate есть ещё комплект софта stak, там тоже есть полезные программки, но некоторые у меня работать не стали (ничего не выводят).

 

Ещё сегодня пришло сообщение, что pf_ring из svn теперь должен собираться на ядрах моложе 3.3.8, но я не проверял. Так же у меня не получилось слинковать rate и stak с libpcap-pf_ring, но я пытался ровно 1 раз :-), наверное я просто не разбираюсь в Makefile или либу криво поставил.

 

UPD: Попробовал ещё раз и получилось. При этом stak софтинки заработали (не все проверил, но нужная заработала). Вроде бы юзают именно libpcap от pf_ring. Заметил профит в снижении загрузки ЦПУ на 5-7 процентов, но у меня и pps не для соревнований и проц 7-и летней давности, так что надо тестировать на другом трафике и на другом железе.

 

Если кому интересно, то вот пример:

 

Зеркалим нужный трафик в зеркало, на зеркале компилим pf_ring с блек джеком и ***ми с компанией, ставим, потом собираем stak подсправив Makefile, потом запускаем примерно так:

 

stakhosts -i lan1 -p18 -r 10 -a 30 -n 10.0.0.0/20 192.168.0.0/19 -b -P -O

 

покажет хитпарад из 30-ти генераторов трафика по pps и по TX. -p18 это офсет чтобы 802.1ку нормально отработать (по-моему 18 надо :-), по умолчанию 14 для нетегированного езернета).

Изменено 22 ноября, 2013 пользователем wtyd

[photon]

Предлагаю не ограничиваться только Линуксом. Во FreeBSD есть альтернатива PF_RING, которая называется netmap: http://info.iet.unipi.it/~luigi/netmap/ . Он также доступен и в Linux на некоторых драйверах: https://github.com/aarrpp/netmap На мой взгляд, нужно использовать libpcap поверх netmap.

Изменено 22 ноября, 2013 пользователем photon

[pavel.odintsov]

Добрый день, уважаемое сообщество!

 

Хотел бы поделиться своей программой для анализа проходящего через миррор порты/роутеры трафика: https://github.com/FastVPSEestiOu/fastnetmon

 

• 
   
  
• Для чего она писалась? Чтобы фиксировать серьезные всплески по полосе/pps как со стороны клиентов, так и со стороны интернета в сторону клиентов.
  
• Что выдает? Выдает топ 10 самых активных потребителей ресурсов сети, выборки топ 10 можно делать как по pps так и по трафику
  
• Что умеет? Умеет передавать управление внешнему скрипту, который забанит пользователя либо передаст его на анализ группе администраторов
  
• На чем работает? Поддерживает pcap (очень медленно, но на скоростях в районе 100 мегабит должно нормально) и ulog2 (на порядки быстрее и надежнее)
  
• Что еще умеет? Умеет считать трафик по заданным диапазонам, решение базируется на redis и используется в исключительно внутренних целях
  
• На каком канале работает? Приложение сейчас в продакшене (на миррор портах, с отдельной машины) с нагрузкой в несколько гигабит входящего+исходящего трафика с примерно 250kpps и более в среднем. Ресурсы жрет довольно хорошо :)
  
• На какой платформе точно работает? Debian 7 Wheezy, с остальными надо заниматься отдельно, так как используется C++11
  
• На чем написано? C++
  

 

Предвосхищая обвинения в том, что это костыль или "не нужно" хочу сказать, что в связи с врожденной ленью перебрал очень много решений до начала реализации своего и все они просто не работали на наших потоках трафика. Силами свичей/роутеров невозможно создавать число рейт лимитеров/анализаторов для нашего числа с IP (сильно больше 10000).

 

Есть проект http://www.ntop.org/products/pf_ring/ с аццкем libpcap. Не совсем тривиально ставить, т.к. там ограничения в версиях ядра есть. Потом можно пересобрать нужный софт и слинковать его с этим аццке быстрым lipbcap. Пробовал, tcpdump в некоторых случаях захватывал/дропал не совсем то количество пакетов, которое указывал, а вот с pf_ring всегда именно указанное количество и ноль дропов. Т.е. профит вроде бы есть :-).

 

Ещё была такая программка как rate. Надо попробовать её слинковать с pf_ring'овским libpcap. rate показывает хитпарад качков тоже поразным параметрам, но вот только home page я найти не могу с таким названием, увы :-).

 

День добрый!

 

Мне на скоростях в районе 2-3 гигабит удалось почти полностью победить потери силами ULOG2. Но PF_RING штука занятна, попробую прикрутить.

[wtyd]

День добрый!

 

Мне на скоростях в районе 2-3 гигабит удалось почти полностью победить потери силами ULOG2. Но PF_RING штука занятна, попробую прикрутить.

 

Судя по описанию netmap более перспективный и совсем не проприетарный. Лучше его пробуйте. Я только отсюда узнал про его существование. Там в pf_ring за ДНК надо платить, а в нетмапе всё свободно. ДНК бесплатно только 5 минут работает, ну и ещё другие проблемы у меня с ним были. Ну и конечно же все эти ДНК-кольца и нетмапы эффективнее всего на зеркале запускать (я не знаю, как вы ULOG2 используете, на зеркале или прям на роутере).

 

В любом случае, пожалуйста, отпишитесь тут по результатам -- интересно :-).

Изменено 23 ноября, 2013 пользователем wtyd

[pavel.odintsov]

Обязательно отпишусь) Сейчас ждем новые карточки x540 и проведу тесты на 10Ge канале.

[pavel.odintsov]

ichthyandr, Вы были совершенно не правы. Для теста я вообще отключил STL структуры и вообще убрал всю обработку пакета кроме обычного парсинга пакета. То есть анализатор работал в режиме "ничего не делаю, просто смотрю пакеты".

 

Итог такой - PCAP неприемлем ни для какого серьезного (от 50kpps и выше) трафика.

 

Тестовый стенд - i7 2600, NIC Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection, драйвер igb c sourceforge, ОС - Debian Wheezy/3.2 kernel.

 

При потоке в 100 pps:

PCAP statistics
Received packets: 6353168
Dropped packets: 848902 (13%)
Dropped by driver or interface: 1

 

В то же время ULOG выдает на порядки более приятные цифры, теряется меньше 1% трафика (но, к сожалению, я так и не разобрался, как победить потери вообще):

ULOG buffer errors: 2904 (0%)
ULOG packets received: 210776

 

То есть погрешность около 13%. Если кажется, что это мало, то хотелось бы обратить внимание, что на это почти 100-200 kpps при нагрузке канала в ~1 mpps, а это почти гарантированная смерть либо абонента либо сервера, куда это вливается :)

 

Итог простой - не юзайте PCAP.

 

Приступаю к тестам AF_PACKET в mmap режиме, PF_RING и правда какой-то мутно-лицензированыный, не хочется тратить время на технологию, которая никогда не станет мейнстримом.

Изменено 28 ноября, 2013 пользователем pavel.odintsov

[pavel.odintsov]

Кстати, немного тестов tcpdump и netsniff-ng, платформа как и была прежде. Трафик около 80-100 kpps. Дабы избежать влияния файловой системы, даныне пишутся в tmpfs.

 

Tcpdump, потери аж 30-40%:

tcpdump -i br0 -w /run/shm/tcpdump
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
1672931 packets captured
2352767 packets received by filter
679743 packets dropped by kernel

 

Теперь тоже самое, но с netsniff-ng, потери менее 0.1% (!!!):

netsniff-ng -i br0 --out /run/shm/suxx -s
netsniff-ng 0.5.7
BPF JIT
RX: 64.00 MiB, 32768 Frames, each 2048 Byte allocated
PROMISC
BPF:
L0: ret #0xffffffff
MD: RX scatter-gather lf64 realtime: prio 4

    2405016  frames incoming
    2400257  frames passed filter
       4759  frames failed filter (out of space)
     0.1979% frame droprate
         25  sec, 983493 usec in total

 

Так что рекомендую! :) Осталось портировать код из netsilter-ng

[pavel.odintsov]

Друзья, добавил еще одну фишку, не знаю уж кому пригодится, но нам очень помогает при трафик инжиниринге - отображение топ10 ASN, в/из которых принимается максимальный трафик.

 

Выглядит это дело примерно так:

Incoming channel: ASN traffic
11222           5271 pps 446 mbps
24940           6180 pps 344 mbps
11222           675 pps 72 mbps
11222          653 pps 70 mbps
11222           1488 pps 59 mbps
11222           551 pps 52 mbps
11222           791 pps 44 mbps
11222           2404 pps 34 mbps
11222           189 pps 23 mbps
11222           97 pps 17 mbps
11222           1579 pps 17 mbps
11222            1872 pps 15 mbps

Outgoing channel: ASN traffic
11222            2548 pps 225 mbps
11222           2506 pps 206 mbps
11222            2191 pps 202 mbps
11222            2236 pps 199 mbps
11222            1912 pps 189 mbps
11222           1537 pps 155 mbps
11222            1922 pps 130 mbps
4134            1836 pps 129 mbps
11222           1248 pps 124 mbps
11222           1539 pps 109 mbps
11222            1189 pps 104 mbps
13238           1480 pps 97 mbps

 

Работает это дело на открытых ASN базах от MaxMind. Также есть возможность сделать аналогичый отчет по странам (+- 3 строки кода), если кому-то требуется - могу дописать.

[Susanin]

Друзья, добавил еще одну фишку, не знаю уж кому пригодится, но нам очень помогает при трафик инжиниринге - отображение топ10 ASN, в/из которых принимается максимальный трафик.

И как получить подобную стату ?

[pavel.odintsov]

Друзья, добавил еще одну фишку, не знаю уж кому пригодится, но нам очень помогает при трафик инжиниринге - отображение топ10 ASN, в/из которых принимается максимальный трафик.

И как получить подобную стату ?

 

Да довольно просто, собрать по гайду https://github.com/FastVPSEestiOu/fastnetmon, найти внутри fastnetmon.cpp блок:

  // TODO: ВРЕМЕННО ДЕАКТИВИРОВАНО
       if (false) {

 

И заменить его на true и скомпилировать. После этого под топом потребителей трафика будет список топ ASN потребителей входящего-исходящего трафика. Ну и да - собирать на Дебияне 7, ни подо что другое готовый ман по сборке дать не смогу.

[pavel.odintsov]

Сейчас смотрю в сторону dpdk.org, возможно, удастся добавить его поддержку.