Статья и комменты сочатся желчью. Почему-то сразу вспомнили за распил. Возможно конечно сами виноваты, ибо в народе был создан такой образ, но постойте, вроде на хабре мы тут обсуждаем технику, не так ли?
Первое, компания умолчала об интенсивности атаки. Цифра в 3,2 миллиона пакетов из «Пятерочки» выглядит внушительно, тем более, SYN-flood атаки на самом деле измеряются в количестве пакетов.
Не пойму, так умолчала или нет? Вроде нет, зачем тогда писать обратное?
При этом в пресс-релизе «Ростелекома» открыто нагнетается ситуация с атаками на европейские структуры и организации мощностью до 1 Тбит/c (125 Гбайт/c).
Ткните пожалуйста меня носом в то место, где нагнетается.
Исходя из вышесказанного можно прийти к выводу, что «Ростелеком» пытается выдать победу надуманную за победу реальную и заработать «очков» в глазах корпоративных клиентов как надежный провайдер.
Так, вообще-то вы притащили на хабр это. Ростелек написал у себя в блоге (и да, журналисты конечно охотно растащили, но что поделать?)
которое без ответа с запрашиваемой стороны снимается только через 75 секунд.
Время жизни полуоткрытых соединений варьируется. FreeBSD это net.inet.tcp.keepinit, который да, по умолчанию 75 секунд. В Линуксе несколько по другому, там зависит от initial RTO и количества syn_ack ретрансмитов. По дефолту все это выливается в 31 секунду.
При этом максимальный размер пакета SYN составляет 64 Кб, но стандартом является его меньшая версия на 16 Кб.
максимальный размер IP да — 64Кб, но что за стандарт, говорящий о 16Кб syn пакетах я даже близко не могу предположить. По этому
Путем нехитрых подсчетов получаем наиболее вероятную интенсивность атаки в 51,2 Гбайт/с.
вы не правильно посчитали канальную составляющую атаки, к слову которая мерится далеко не в bps.
Атака типа SYN Flood известна давно (еще с начала 2000-х) и используется злоумышленниками с переменным успехом. При этом эффективность подобных методов спустя полтора десятилетия вызывает сомнения.
Использовались, используются и будут использоваться. Более того — они все еще довольно эффективны, если не подумать о защите заранее. И тут имеет место быть ряд векторов.
Во-первых, наличие достаточной канальной емкости. Для получения 3.2 Мппс син флуда нужно чуть больше 2Гб/с (1 Гб/с это 1,488 Мппс, если syn пакеты без опций). Не каждая компания, нуждающаяся в услуге фильтрации, имеет в распоряжении такой объем свободной канальной полосы.
Во-вторых, раз уж тут предложили фильтровать на линуксе, то современный ТСП стек линукса может обработать порядка пары мппс на нормальных камнях. Но нужно же еще и полезную работу выполнять.
Известный ботнет Mirai, который положил DNS-провайдера Dyn в октябре этого года (и которому приписываются упомянутые «Ростелекомом» атаки в Европе), использовал UDP-атаку, также известную как DNS retry.
Mirai умеет много разных типов атак, в том числе и упомянутый в статье synflood.
З.Ы. Хочу посмотреть как умники тут будут фильтровать своими силами 3.2Гб/с честного синфлуда своими силами без наличия специализированных решений.
На систар не смотрел, он на плюсах, по мне так низкоуровневые сетевые вещи должны быть на чистом С (это не предмет для спора, считайте это предубеждениями).
На прошлой неделе в Дублине на dpdksummit в кулуарах общался на тему юзерспейс тсп стеков, узнал много ньюансов из первых рук. Попробую собрать тут по крупицам инфу. На данный момент дела обстоят так:
https://github.com/rumpkernel/drv-netif-dpdk — стек netbsd, как есть, не быстрый, проект не развивается
https://github.com/eunyoung14/mtcp — проект автора packetshader (KyoungSoo Park), так же не блещет скоростью. По словам KyoungSoo их главная цель не скорость, а стройный код и модульность.
https://github.com/scylladb/seastar — C++, больше о нем ничего не знаю
https://github.com/OpenFastPath/ofp — со слов коллег, вроде бы достаточно быстр (локи вычищены), опирается на ODP — абстракцию над DPDK (и не только), имеются проблемы со стабильностью.
https://github.com/opendp/dpdk-ans — закрытые исходники
https://wiki.fd.io/view/Project_Proposals/TLDK — проект, развиваемый в рамках VPP, интел ставит пока на него, правда нет публичной реализации ТСП (есть на данный момент внутри интела)
http://www.6wind.com/solutions/tcp/ — закрытый, коммерческий, но вроде как быстрый
Ну, я бы не сказал что достаточно хорошо знаю DPDK, не смотря на то, что работаю с ним начиная с версии 1.2.3 и порой комичу. И да, использую его для решения своих практических задач.
День добрый! Пожалуй поворчу немного, вы уж сильно не обижайтесь =)
Intel DPDK
Уже без Intel, просто DPDK
Они позволяют полностью исключить сетевой стек Linux из процесса обработки пакетов и сделать так, чтобы приложение, работающее в пользовательском пространстве, взаимодействовало с сетевым устройством напрямую
Необходимо понимать, что
DPDK is not a networking stack
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
когда пакет поступает на сетевую карту, он сначала попадает в специальную кольцевую структуру, — приёмную очередь (receive queue или просто RX). Оттуда он копируется в основную память с помощью механизма DMA — Direct Memory Access.
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
прерывание генерируется всякий раз, когда новый пакет поступает в систему
Современные сетевые умеют в interrupt moderation
Что касается sk_buff, да структура очень разрослась, к тому же поля расположены не лучшим образом.
входящий в DPDK драйвер PMD
На самом деле на данный момент в библиотеке целый скоп различных PMD для большинства современных сетевых карт + PMD виртуальных устройств + misc (af_packet, pcap, null etc...)
Для работы с DPDK необходимо также настроить большие страницы памяти (hugepages). Это нужно, чтобы выделять большие регионы памяти и записывать в них данные.
Это нужно для того, чтобы не вымывать дичайше TLB
Можно сказать, что hugepages в DPDK выполняют ту же роль, что механизм DMA в традиционной обработке пакетов.
Што?
заключается в том, чтобы поменять голову и хвост местами
Нет. Во-первых, то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Во-вторых, в случае enqueue CAS'ом апдейтится prod.head (увеличивается на кол-во вставляемых объектов) __rte_ring_mp_do_enqueue()
, а в случае dequeue — cons.head. __rte_ring_mc_do_dequeue()
во многом напоминает тот, что используется в FreeBSD: вместо одной большой структуры sk_buff — много буферов rte_mbuf небольшого размера.
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD. Более того, во Фре есть сами mbuf, которые могут нести короткие пакеты (если я не ошибаюсь до 128 байт) и mbuf_cluster — соответственно для больших.
Что же касается причин столь высокой производительности библиотек — их пишут довольно квалифицированные люди. На вскидку для ускорения обработки используются техники: выравнивание, батч обработка пакетов (+ векторизация), префетчинг (особенно полезен при пайплайнинге), поллинг (отказ от прерываний), использование hugepages (меньше трешим TLB), lockless fastpath (должны отсутствать блокировки в коде обработки пакетов), тред аффинити (меньше трешит кеши), итд.
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
testpmd — это не утилита, это sample application из фреймворка intel dpdk, в котором показано, как программисту работать с pmd (poll mode driver). К ядерному драйверу (например ixgbe) не имеет отношения. Для ядерных драйверов есть ethtool.
Может содержать не более 8 000 правил.
зависит от регистра PBALLOC. Максимальное значение для perfect — 8k — 2, при этом из 512 кбайт пакетного буфера на порт будет заимствовано 256кбайт. Чем это чревато — потерей пакетов в определенных ситуациях (например сильные всплески мелкопакетного трафика, при нехватке dma).
Может содержать не более 32 000 правил.
Не более 32k — 2 при максимальном PBALLOC
ATR запоминает, в какую очередь (и на каком процессоре) _ушёл_ SYN пакет и направляет приходящие пакеты этого потока через ту же очередь.
ATR — это видимо какая-то софтовая часть. Signature filter работает не так. Он просто роутит по очередям по 13-15 (в зависимости от PBALLOC) least significant bits от хеша по packet tuple. Сам fpga чипа не может следить за проходящими syn и создавать динамически фильтры.
И да, в вышей ситуации, когда у вас 16+ ядер при 4-х 10G портах, почему бы не полагаться на RSS, ведь можно балансить по 4*16 очередям.
а) Услугу получать от IX? Простите, а если трафик полетит не с IX? Неужели вы довольствуетесь только IX связностью?
б) В данном случае cloudflare все равно видит не шифрованный трафик, хоть и не имеет сертификата. В некоторых случаях это недопустимо.
Ошибаетесь. В тыкву никто не превратится, потому как арбор (как в прочем и остальные, например периметр от мфи софт) это прежде всего инструмент. И это инструмент умеет определенные контрмеры, эффективные при определенных атаках. Опять таки не нужно воспринимать ни арбор, ни железо других вендоров в качестве серебряной пули.
Можно узнать в чем заключается неадекват относительно предоставляемой услуги защиты от DDoS? У вас реальный практический опыт использования услуги или просто слышали?
провайдер может захотеть бесконечных денег
тарифы фиксированы как у Телии, так и у Ростелека.
А можно узнать ТТХ генерирующей системы?
Как я понял вы генерировали с одного ядра с — SPECIAL OPTIONS: copy, значит происходит копирование в slot->buf_idx предопределенного в initialize_packet() шаблона пакета с последующим апдейтом некоторых полей заголовков. В прошлом году был написан на dpdk для внутреннего тестирования флудер, использующий схожую технику(правда рандомизировались все поля) с одного ядра Е3 1230 выдавало чуть меньше.
Архипов Илья, Системный администратор Rambler, 2013-2018
Да, я в курсе, выше я говорил о
А так, есть вот например purifier, который будет на порядок быстрее упомянутого выше решения.
Не пойму, так умолчала или нет? Вроде нет, зачем тогда писать обратное?
Ткните пожалуйста меня носом в то место, где нагнетается.
Так, вообще-то вы притащили на хабр это. Ростелек написал у себя в блоге (и да, журналисты конечно охотно растащили, но что поделать?)
Время жизни полуоткрытых соединений варьируется. FreeBSD это net.inet.tcp.keepinit, который да, по умолчанию 75 секунд. В Линуксе несколько по другому, там зависит от initial RTO и количества syn_ack ретрансмитов. По дефолту все это выливается в 31 секунду.
максимальный размер IP да — 64Кб, но что за стандарт, говорящий о 16Кб syn пакетах я даже близко не могу предположить. По этому
вы не правильно посчитали канальную составляющую атаки, к слову которая мерится далеко не в bps.
Использовались, используются и будут использоваться. Более того — они все еще довольно эффективны, если не подумать о защите заранее. И тут имеет место быть ряд векторов.
Во-первых, наличие достаточной канальной емкости. Для получения 3.2 Мппс син флуда нужно чуть больше 2Гб/с (1 Гб/с это 1,488 Мппс, если syn пакеты без опций). Не каждая компания, нуждающаяся в услуге фильтрации, имеет в распоряжении такой объем свободной канальной полосы.
Во-вторых, раз уж тут предложили фильтровать на линуксе, то современный ТСП стек линукса может обработать порядка пары мппс на нормальных камнях. Но нужно же еще и полезную работу выполнять.
Mirai умеет много разных типов атак, в том числе и упомянутый в статье synflood.
З.Ы. Хочу посмотреть как умники тут будут фильтровать своими силами 3.2Гб/с честного синфлуда своими силами без наличия специализированных решений.
На прошлой неделе в Дублине на dpdksummit в кулуарах общался на тему юзерспейс тсп стеков, узнал много ньюансов из первых рук. Попробую собрать тут по крупицам инфу. На данный момент дела обстоят так:
https://github.com/rumpkernel/drv-netif-dpdk — стек netbsd, как есть, не быстрый, проект не развивается
https://github.com/eunyoung14/mtcp — проект автора packetshader (KyoungSoo Park), так же не блещет скоростью. По словам KyoungSoo их главная цель не скорость, а стройный код и модульность.
https://github.com/scylladb/seastar — C++, больше о нем ничего не знаю
https://github.com/OpenFastPath/ofp — со слов коллег, вроде бы достаточно быстр (локи вычищены), опирается на ODP — абстракцию над DPDK (и не только), имеются проблемы со стабильностью.
https://github.com/opendp/dpdk-ans — закрытые исходники
https://wiki.fd.io/view/Project_Proposals/TLDK — проект, развиваемый в рамках VPP, интел ставит пока на него, правда нет публичной реализации ТСП (есть на данный момент внутри интела)
http://www.6wind.com/solutions/tcp/ — закрытый, коммерческий, но вроде как быстрый
А кто отказался то? Если говорить про dpdk — там в основном все приложения крутятся в busy loop.
Нет, это абсолютно не так.
man netmap
…
netmap supports the following interfaces: em(4), ixgbe(4), re(4)
…
А про dpdk можно почитать прям на главной
Список поддерживаемых сетевых карт
Уже без Intel, просто DPDK
Необходимо понимать, что
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
Современные сетевые умеют в interrupt moderation
Что касается sk_buff, да структура очень разрослась, к тому же поля расположены не лучшим образом.
На самом деле на данный момент в библиотеке целый скоп различных PMD для большинства современных сетевых карт + PMD виртуальных устройств + misc (af_packet, pcap, null etc...)
Это нужно для того, чтобы не вымывать дичайше TLB
Што?
Нет. Во-первых, то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Во-вторых, в случае enqueue CAS'ом апдейтится prod.head (увеличивается на кол-во вставляемых объектов)
__rte_ring_mp_do_enqueue()
, а в случае dequeue — cons.head.
__rte_ring_mc_do_dequeue()
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD. Более того, во Фре есть сами mbuf, которые могут нести короткие пакеты (если я не ошибаюсь до 128 байт) и mbuf_cluster — соответственно для больших.
Что же касается причин столь высокой производительности библиотек — их пишут довольно квалифицированные люди. На вскидку для ускорения обработки используются техники: выравнивание, батч обработка пакетов (+ векторизация), префетчинг (особенно полезен при пайплайнинге), поллинг (отказ от прерываний), использование hugepages (меньше трешим TLB), lockless fastpath (должны отсутствать блокировки в коде обработки пакетов), тред аффинити (меньше трешит кеши), итд.
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
В любом случае — спасибо за популяризацию DPDK.
testpmd — это не утилита, это sample application из фреймворка intel dpdk, в котором показано, как программисту работать с pmd (poll mode driver). К ядерному драйверу (например ixgbe) не имеет отношения. Для ядерных драйверов есть ethtool.
зависит от регистра PBALLOC. Максимальное значение для perfect — 8k — 2, при этом из 512 кбайт пакетного буфера на порт будет заимствовано 256кбайт. Чем это чревато — потерей пакетов в определенных ситуациях (например сильные всплески мелкопакетного трафика, при нехватке dma).
Не более 32k — 2 при максимальном PBALLOC
ATR — это видимо какая-то софтовая часть. Signature filter работает не так. Он просто роутит по очередям по 13-15 (в зависимости от PBALLOC) least significant bits от хеша по packet tuple. Сам fpga чипа не может следить за проходящими syn и создавать динамически фильтры.
И да, в вышей ситуации, когда у вас 16+ ядер при 4-х 10G портах, почему бы не полагаться на RSS, ведь можно балансить по 4*16 очередям.
Соглашусь. Для всего есть свой покупатель. Порой часовой простой может стоить на порядок больше годового контракта.
б) В данном случае cloudflare все равно видит не шифрованный трафик, хоть и не имеет сертификата. В некоторых случаях это недопустимо.
Можно узнать в чем заключается неадекват относительно предоставляемой услуги защиты от DDoS? У вас реальный практический опыт использования услуги или просто слышали?
тарифы фиксированы как у Телии, так и у Ростелека.
Как я понял вы генерировали с одного ядра с — SPECIAL OPTIONS: copy, значит происходит копирование в slot->buf_idx предопределенного в initialize_packet() шаблона пакета с последующим апдейтом некоторых полей заголовков. В прошлом году был написан на dpdk для внутреннего тестирования флудер, использующий схожую технику(правда рандомизировались все поля) с одного ядра Е3 1230 выдавало чуть меньше.