Нет, не сарказм и не doublethink, просто реально времена меняются и нужно что-то делать. Ты всем доказал, что реальная защита от DDOS — это не многомиллионные вложения в железки и небольшая команда «головой» может сделать больше, чем толстосумы со штатом в сотни программеров и инвестициями в 120М. Думаю, что можно было бы продолжить объединение усилий на круглых столах, а затем перейти и в практическую плоскость.
Саш я про то, что это не остановить. Инструментарий уже есть, статьи и howto неизбежно будут появляться, не у нас, так в англоязычном сегменте. Я бы с удовольствием поддержал продолжение твоей борьбы ( tech.yandex.ru/events/yac/2013/talks/1135/ ) по объединению усилий в совместном противодействии DDOS, т.к. абсолютно убеждён, что это и есть решение.
У нас свободная страна :-), поэтому готов поддержать как право публиковать инструментарий по генерации трафика, так и право объединять усилия сообщества по защите. В конечном счёте, мы все от этого выиграем.
IMHO время «security through obscurity» в области DDOS заканчивается.
Дело не в умении молотить много-много пакетов, и не в полосе чтобы эти пакеты принять. Посмотрите на CloudFlare — у них есть и пакеты и полоса и 120M инвестиций? Казалось бы, что мешает?
Поддержу, способность справляться с высоким PPS и наличие полосы — это необходимое, но НЕ достаточное условие для эффективной работы. Также, согласен с Сашей, что главное кунгфу находится где-то в области ML.
О статье уже думаем, тем более, что мы только что прошли официальное тестирование в одном крупном телекоме, пока не могу сказать больше, но защита от чистого synflood'а мощностью 14.8 Mpps со скоростью генерации src ip в 1 млн новых ip/sec, на обычном сервере, пройдена без потерь на 10 тыс. автоматизированных JMeter'ом нагрузочных тестах (HTTP/FTP/DNS/SMTP), при задержках в установлении соединения в районе десятка миллисекунд.
577.636329 main [1807] mapped 334980KB at 0x8019ff000 Receiving from netmap:ix0: 4 queues, 1 threads and 1 cpus.
577.636386 main [1887] Wait 2 secs for phy reset
Попробуй использовать больше очередей и тредов, сейчас у тебя 1 тред работает на 4 очереди, в X520 8 очередей на 1 SFP-порт, соответственно можно нагрузить генератор бОльшей логикой и сделать его интересней.
Есть довольно большие сомнения насчёт всех заявленных характеристик, особенно после внимательного взгляда на представленный график.
Начальные данные
Данных мало, но попробуем сделать апроксимирование линейной функцией. Вряд ли потребление процессорного времени становится более эффективным при увеличении мощности атаки и при сохранении качества работы.
Считаем минимальные значения — поправкой (bias) получаем:
За неимением других данных — результат более-менее :-). Отметим, что при увеличением трафика эффективность его обработки вряд ли будет увеличиваться, скорее наоборот — процессорного времени перестанет хватать и начнутся: либо FP, либо FN.
Дальше считаем загрузку процессора, которая получится при заявленных характеристиках по пропускной способности, возьмём 10-50Gbit/s.
Получаем, что при 10Gbit/s, CPU Load должен быть 550%, а при 50Gbit/s — 2700%.
Собственно, указанные выше соображения и вызывают сомнения в том, что указанное в статье решение «гарантированно выдержит», «без потерь легитимного трафика» 10-50Gbit/s. Думаю, что с таким CPU Load, значения FP и FN будут зашкаливать, что неизбежно приведёт к критической деградации сервиса.
IMHO слова «гарантированно выдержит» и " не теряем легитимный трафик" следует дополнять конкретными числами по мощности/типу атак, TP/TN/FP/FN, Accuracy и Precision.
У меня вопрос / предложение насчёт 50 мегапакетов. Мы предлагаем организовать совместное тестирование заявленных характеристик на Вашей территории с нашим генератором атак.
Будем делать несколько видов атак с пакетрейтом 10-50Mpps, результаты опубликуем на Хабре в рамках отдельной статьи.
Если я правильно помню, размер самого мелкого ethernet-пакета может быть не менее 84 байт.
1. Interframe gap — 12 байт
2. Preamble — 8 байт
3. DST + SRC MAC — 12 байт
4. Ether type — 2 байта
5. Payload — 46 байт минимум
6. CRC — 4 байта
Итого: 84 байта или 672 бита
Получается, если нет коллизий, через 1Gbit/s = 1 073 741 824 bit/s, можно прокачать 1.5 Mpps (1 597 830).
Думаю, что создатель Netmap Luigi Rizzo, просто не стал заморачиваться поддержкой многоядерности, т.к. на одном 900Mhz ядре он поднимает в userspace целых 14Mpps.
По идее e1000 умеет работать на скоростях не больше 1Gbit/s. Если учесть, что, только на одном ядре, netmap поднимает пакеты из кабеля в userspace со скоростью 14Mpps (10Gbp/s), есть ли смысл драйверу поддерживать многоядерность?
Спасибо за интересный материал. Было бы интересно, если бы авторы нашли возможность сделать продолжение статьи с входящим DDOS-трафиком больше 1.5Mpps.
На этот вопрос не ответить в коротко, т.к. слишком много вещей требуется охватить, чтобы ответ не показался кому-либо голословным. Это в первую очередь такие вещи как:
— используемые механизмы фильтрации (syncookie, pps лимиты, другие лимиты, tcpsplicing, др...)
— схема фильтрации, т.е. каков алгоритм прохождения пакета через фильтры
— параметры synflood (кол-во новых ip с которых идёт synflood в сек., количество одновременных реальных сессий в сек, количество
новых реальных сессий в сек. и др.)
— параметры качества фильтрации: для новых сессий, для уже открытых сессий
В лаборатории получатся разогнать фильтрацию synflood на одном 10Gbit/s порту до 12-13Mpps при потоке реальных сессий порядка 500K/s. Стек TCP/IP в процессе не участвует, трафик проходит с одного интерфейса на другой через netmap.
Есть идея подготовить в отдельной статье результаты тестов, в которых показать производительность при изменении количества одновременных сессий, количества новых реальных сессий в секунду и/или изменении параметров synflood. Посмотрим.
Производительность netmap в сравнении c pfring DNA и Intel DPDK мы не сравнивали. Про Intel DPDK, к сожалению, ничего не могу сказать, не работал, судя по описанию — очень круто. Что касается pfring DNA и netmap, они используют похожие, точнее почти одинаковые техники работы с пакетами, соответственно предполагаю, что производительность будет, тоже, одинаковой. Авторы pfring (Luca Deri) и netmap (Luigi Rizzo), кстати, хорошо знают друг друга и вот ниже комментарий Luca Deri относительно производительности pfring и nemap.
Even if DNA and netmap have been developed in totally independent ways, they solve the same problem: how to move packets back/forth a network adapter without using too many CPU cycles. And I believe it’s no surprise that the performance of DNA and netmap is basically the same.
Источник: www.ntop.org/pf_ring/dna-vs-netmap/
По поводу superpages. Netmap, при инициализации, использует свой собственный аллокатор, который выделяет непрерывную область физической памяти для всех необходимых ему для работы структур данных. Ниже фрагмент кода:
В результате такого подхода, для работы с любой структурой данных, включая пакетные буферы, используется указатель на начало выделенной области и смещение (offset). Такая техника показывает очень высокое быстродействие. Соответственно, superpages netmap не использует, т.к. он сам делает один большой superpage для себя.
1. https://www.coursera.org/specializations/jhu-data-science
2. https://www.coursera.org/specializations/executive-data-science
Первое:
Второе:
IMHO время «security through obscurity» в области DDOS заканчивается.
Поддержу, способность справляться с высоким PPS и наличие полосы — это необходимое, но НЕ достаточное условие для эффективной работы. Также, согласен с Сашей, что главное кунгфу находится где-то в области ML.
Попробуй использовать больше очередей и тредов, сейчас у тебя 1 тред работает на 4 очереди, в X520 8 очередей на 1 SFP-порт, соответственно можно нагрузить генератор бОльшей логикой и сделать его интересней.
main [1535] ether_aton(7c:20:64:4a:78:21) gives 0x800fb08d2
main [1651] map size is 334980 Kb
main [1673] mmapping 334980 Kbytes
Sending on ix0: 8 queues, 8 threads and 8 cpus.
(range) -> 10.0.0.6 (90:e2:ba:37:3e:e4 -> 7c:20:64:4a:78:21)
main [1726] Wait 5 secs for phy reset
main [1728] Ready…
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
sender_body [1209] start
main [1841] 14853502 pps
main [1841] 14878679 pps
main [1841] 14878498 pps
main [1841] 14876758 pps
main [1841] 14877630 pps
main [1841] 14879842 pps
main [1841] 14875579 pps
main [1841] 14879976 pps
main [1841] 14879200 pps
main [1841] 14876690 pps
main [1841] 14881448 pps
Начальные данные
Данных мало, но попробуем сделать апроксимирование линейной функцией. Вряд ли потребление процессорного времени становится более эффективным при увеличении мощности атаки и при сохранении качества работы.
Считаем минимальные значения — поправкой (bias) получаем:
CPULoad = CPU_load_min + Theta * (Полоса занимаемая атакой — Throughput_min).
или
CPULoad = 11 + 5.057683e-08 * (Полоса занимаемая атакой — 75Mbit/s). Здесь 75Mbits = 9 834 056 Bytes/s * 8 = 78 672 448 Bits/s.
Считаем ошибку по среднему (Average) значению Throughput, по которому в исходных данных указано значение CPU Load 17.03%
ApproxCPULoad = 11 + 5.057683e-08 * (219234872 — 78672448) = 18.109 %
Error = ( 18.109-17.3 ) / 17.3 * 100 = 4.6763%.
Смотрим график
За неимением других данных — результат более-менее :-). Отметим, что при увеличением трафика эффективность его обработки вряд ли будет увеличиваться, скорее наоборот — процессорного времени перестанет хватать и начнутся: либо FP, либо FN.
Дальше считаем загрузку процессора, которая получится при заявленных характеристиках по пропускной способности, возьмём 10-50Gbit/s.
Получаем, что при 10Gbit/s, CPU Load должен быть 550%, а при 50Gbit/s — 2700%.
Собственно, указанные выше соображения и вызывают сомнения в том, что указанное в статье решение «гарантированно выдержит», «без потерь легитимного трафика» 10-50Gbit/s. Думаю, что с таким CPU Load, значения FP и FN будут зашкаливать, что неизбежно приведёт к критической деградации сервиса.
IMHO слова «гарантированно выдержит» и " не теряем легитимный трафик" следует дополнять конкретными числами по мощности/типу атак, TP/TN/FP/FN, Accuracy и Precision.
Будем делать несколько видов атак с пакетрейтом 10-50Mpps, результаты опубликуем на Хабре в рамках отдельной статьи.
Жду ответа.
1. Interframe gap — 12 байт
2. Preamble — 8 байт
3. DST + SRC MAC — 12 байт
4. Ether type — 2 байта
5. Payload — 46 байт минимум
6. CRC — 4 байта
Итого: 84 байта или 672 бита
Получается, если нет коллизий, через 1Gbit/s = 1 073 741 824 bit/s, можно прокачать 1.5 Mpps (1 597 830).
Думаю, что создатель Netmap Luigi Rizzo, просто не стал заморачиваться поддержкой многоядерности, т.к. на одном 900Mhz ядре он поднимает в userspace целых 14Mpps.
Встроенные фильтры не трогали. Кстати, netmap здорово изменился с декабря 2012 года. В следующий раз, сделаем апдейт по этим изменениям.
На этот вопрос не ответить в коротко, т.к. слишком много вещей требуется охватить, чтобы ответ не показался кому-либо голословным. Это в первую очередь такие вещи как:
— используемые механизмы фильтрации (syncookie, pps лимиты, другие лимиты, tcpsplicing, др...)
— схема фильтрации, т.е. каков алгоритм прохождения пакета через фильтры
— параметры synflood (кол-во новых ip с которых идёт synflood в сек., количество одновременных реальных сессий в сек, количество
новых реальных сессий в сек. и др.)
— параметры качества фильтрации: для новых сессий, для уже открытых сессий
В лаборатории получатся разогнать фильтрацию synflood на одном 10Gbit/s порту до 12-13Mpps при потоке реальных сессий порядка 500K/s. Стек TCP/IP в процессе не участвует, трафик проходит с одного интерфейса на другой через netmap.
Есть идея подготовить в отдельной статье результаты тестов, в которых показать производительность при изменении количества одновременных сессий, количества новых реальных сессий в секунду и/или изменении параметров synflood. Посмотрим.
Производительность netmap в сравнении c pfring DNA и Intel DPDK мы не сравнивали. Про Intel DPDK, к сожалению, ничего не могу сказать, не работал, судя по описанию — очень круто. Что касается pfring DNA и netmap, они используют похожие, точнее почти одинаковые техники работы с пакетами, соответственно предполагаю, что производительность будет, тоже, одинаковой. Авторы pfring (Luca Deri) и netmap (Luigi Rizzo), кстати, хорошо знают друг друга и вот ниже комментарий Luca Deri относительно производительности pfring и nemap.
Even if DNA and netmap have been developed in totally independent ways, they solve the same problem: how to move packets back/forth a network adapter without using too many CPU cycles. And I believe it’s no surprise that the performance of DNA and netmap is basically the same.Источник: www.ntop.org/pf_ring/dna-vs-netmap/
По поводу superpages. Netmap, при инициализации, использует свой собственный аллокатор, который выделяет непрерывную область физической памяти для всех необходимых ему для работы структур данных. Ниже фрагмент кода:
В результате такого подхода, для работы с любой структурой данных, включая пакетные буферы, используется указатель на начало выделенной области и смещение (offset). Такая техника показывает очень высокое быстродействие. Соответственно, superpages netmap не использует, т.к. он сам делает один большой superpage для себя.