Как стать автором
Обновить

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

Высокая производительность *
Из песочницы
Дано:
# 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.

Решение:
Читать дальше →
Всего голосов 34: ↑31 и ↓3 +28
Просмотры 20K
Комментарии 19

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

Высокая производительность *
Из песочницы
Пропускная способность каналов связи непрерывно возрастает, если ещё пару лет назад сервер с каналом 10Gbit/s был привилегией лишь немногих, то теперь на рынке появились предложения, доступные для маленьких и средних компаний. В то же время, стек протоколов TCP/IP разрабатывался во времена, когда о скоростях порядка 10Gbit/s можно было только мечтать. Вследствие этого, в коде большинства современных операционных систем общего назначения имеется множество оверхедов, впустую съедающих ресурсы. В этих условиях, возрастает важность задач высокопроизводительной обработки сетевых потоков.

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

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

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

image
Читать дальше →
Всего голосов 39: ↑35 и ↓4 +31
Просмотры 18K
Комментарии 44

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

Информационная безопасность *
За прошедшие почти 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)


Читать дальше →
Всего голосов 30: ↑29 и ↓1 +28
Просмотры 26K
Комментарии 25

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

Информационная безопасность *Системное программирование *
Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



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

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

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

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

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!
Читать дальше →
Всего голосов 113: ↑112 и ↓1 +111
Просмотры 81K
Комментарии 77