Pull to refresh

TCP(syn-flood)-netmap-generator производительностью 1,5 mpps

Reading time 14 min
Views 20K
High performance *
Sandbox
Дано:
# pciconf -lv | grep -i device | grep -i network
    device     = I350 Gigabit Network Connection
# dmesg | grep CPU:
    CPU: Intel(R) Core(TM)2 Duo CPU     E7300  @ 2.66GHz (2666.69-MHz K8-class CPU)
# uname -orp
    FreeBSD 9.1-RELEASE amd64

Задача:
Необходимо на данном оборудовании и ОС создать нагрузочную вилку в виде tcp(syn)-генератора трафика производительностью не менее 500kpps.

Решение:
Читать дальше →
Total votes 34: ↑31 and ↓3 +28
Comments 19

NETMAP (от Luigi Rizzo). Простой и удобный opensource фреймворк для обработки трафика на скоростях 10Gbit/s или 14 Mpps

Reading time 22 min
Views 45K
High performance *
Sandbox
Пропускная способность каналов связи непрерывно возрастает, если ещё пару лет назад сервер с каналом 10Gbit/s был привилегией лишь немногих, то теперь на рынке появились предложения, доступные для маленьких и средних компаний. В то же время, стек протоколов TCP/IP разрабатывался во времена, когда о скоростях порядка 10Gbit/s можно было только мечтать. Вследствие этого, в коде большинства современных операционных систем общего назначения имеется множество оверхедов, впустую съедающих ресурсы. В этих условиях, возрастает важность задач высокопроизводительной обработки сетевых потоков.

Статья сделана на основе моего доклада на Highload++ 2012 и предназначена для быстрого введения в удобный и очень эффективный opensource framework, который включен в HEAD/STABLE FreeBSD, называется NETMAP и позволяет работать с пакетами на скоростях 1-10Gbit/s без использования специализированного железа в обычных *nix операционных системах.
Читать дальше →
Total votes 27: ↑25 and ↓2 +23
Comments 12

SYN-флудим со спуффингом на 14 mpps или нагрузочная вилка V 2.0

Reading time 6 min
Views 19K
High performance *
Что-то меня пробило на написание заметок последнее время, поэтому пока энтузиазм не спал раздаю долги.
Год назад я пришёл на хабр со статьёй "TCP(syn-flood)-netmap-generator производительностью 1,5 mpps", после которой многие писали и даже звонили с просьбой описать создание такой же «вилки» со спуффингом на максимуме возможностей 10GB сети. Я всем обещал, а руки всё не доходили.
Кто-то скажет, что это руководство для хакеров, но ведь свинья грязи найдёт, а те кому нужен этот инструмент в благонадёжных целях могу остаться ни с чем.

image
Читать дальше →
Total votes 39: ↑35 and ↓4 +31
Comments 44

Релиз FastNetMon 1.1.2 открытого решения для мониторинга DoS/DDoS атак

Reading time 3 min
Views 26K
Information Security *
За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы.

Из основных изменений стоит отметить следующие:
  • Возможность выявлять самые популярные виды атак: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood
  • Добавление поддержки протокола Netflow, поддерживаются 5, 9 и 10 (IPFIX) версии
  • Добавление поддержки протокола sFLOW v5, который поддерживается большинством современных сетевых коммутаторов
  • Добавлена поддержка использования netmap (поддерживаются Linux и FreeBSD, для Linux предоставляется специальная версия драйвера ixgbe: github.com/pavel-odintsov/ixgbe-linux-netmap) для захвата пакетов. Данный режим обеспечивает наивысшую производительность захвата трафика наряду с PF_RING ZC.
  • Добавлена поддержка PF_RING ZC (к сожалению, этот режим требует отдельной лицензии на библиотеку PF_RING)


Читать дальше →
Total votes 30: ↑29 and ↓1 +28
Comments 25

Захват пакетов в Linux на скорости десятки миллионов пакетов в секунду без использования сторонних библиотек

Reading time 8 min
Views 83K
Information Security *System Programming *
Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!
Читать дальше →
Total votes 113: ↑112 and ↓1 +111
Comments 77