Comments 44
Что имеется в виду под DDoS с одного компьютера, если первая D означает Distributed?
Можно выжать даже больше, чем 13Mpps… :-)

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
Да, Жень, можно, машинка совсем слабая была, упёрлась в подсчёт контрольной суммы, без него 14,8 без проблем.
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-порт, соответственно можно нагрузить генератор бОльшей логикой и сделать его интересней.
Да, возможно, надо будет попробовать, уже стенд разобрал.
Сколько кстати вам удалось раскачать при защите от чистого syn?
Я где-то на 8 остановился.
Написал бы кстати статью с тестами типов атак. Кроме вас-то нетмап мало кто пользует для защиты.
О статье уже думаем, тем более, что мы только что прошли официальное тестирование в одном крупном телекоме, пока не могу сказать больше, но защита от чистого synflood'а мощностью 14.8 Mpps со скоростью генерации src ip в 1 млн новых ip/sec, на обычном сервере, пройдена без потерь на 10 тыс. автоматизированных JMeter'ом нагрузочных тестах (HTTP/FTP/DNS/SMTP), при задержках в установлении соединения в районе десятка миллисекунд.
А можно узнать ТТХ генерирующей системы?
Как я понял вы генерировали с одного ядра с — SPECIAL OPTIONS: copy, значит происходит копирование в slot->buf_idx предопределенного в initialize_packet() шаблона пакета с последующим апдейтом некоторых полей заголовков. В прошлом году был написан на dpdk для внутреннего тестирования флудер, использующий схожую технику(правда рандомизировались все поля) с одного ядра Е3 1230 выдавало чуть меньше.
генерировали с одного ядра с — SPECIAL OPTIONS: copy

да, именно так
# grep -i cpu: /var/run/dmesg.boot ; grep -i "real memory" /var/run/dmesg.boot ; dmidecode | grep -i "Product Name:"
CPU: AMD FX(tm)-8320 Eight-Core Processor            (3515.62-MHz K8-class CPU)
real memory  = 34359738368 (32768 MB)
        Product Name: GA-78LMT-USB3

Да, рассказывайте о HTTP-DDoS, как говорится — «предупрежден — значит вооружен». Хороший защитник должен знать методы нападения что бы знать как от них защищаться.
М, а чем это отличается от выполнения ридми по запуску pktgen из комплекта нетмап (который, к слову, доступен полтора года без изменений в текущем виде)?
Это не «HTTP» поскольку нет никаких семантически законченых http-конструкций. Это в чистом виде атака на сетевой стэк системы. И, часто, она будет успешной даже если вы льете мусор в TCP порт который никто не слушает.

И личный Вопрос: а вы не боитесь «Синдрома Сахарова»?

Какой смысл публиковать такой пошаговый HOWTO для script kiddies? Все люди «в теме» и так знали. Какую задачу решаем?
В чем повод для беспокойства? Никто из атакующих не будет запускать такую конструкцию, она обрушит ему же канал на стыке с ближайшим сетевым устройством.
Это не «HTTP» поскольку нет никаких семантически законченых http-конструкций. Это в чистом виде атака на сетевой стэк системы. И, часто, она будет успешной даже если вы льете мусор в TCP порт который никто не слушает.

Александр, Вы про эту статью или про ту о которой опрос?
Эту никто и не называл HTTP.

Какой смысл публиковать такой пошаговый HOWTO для script kiddies? Все люди «в теме» и так знали. Какую задачу решаем?

Как я уже говорил, это лишь отдача долгов. Собственно никто же Вам не запрещает написать пошаговое howto для описания защиты от такой атаки, тем более, что Вы располагаете такой информацией :)
Слово HTTP в опросе несколько удивило и вызвало диссонанс этой статьей. Да, не учел что это именно ОПРОС.

Отдача долгов, как минимум, странная — дать людям(и не очень людям) колотушку поувесистей и милостиво забыть вооружить бета-тестеров хотя-бы касками.

Поверьте, и вылетит и долетит до кого надо. И да, мы занимаемся противодействием и нам эти фокусы не страшны. А вот коллеги и индустрия от таких фокусов пострадают.
Вопрос — ЗАЧЕМ и ЗАЧТО?

Какую задачу, кроме субьективного кармического долга, решаем?
UFO landed and left these words here
Александр, если бы я обладал на сегодняшний день полностью законченным решением противодействия этой атаке на базе PC, то опубликовал бы его не задумываясь. Но мне пока не удалось стабильно добиться этого.
А те кому нужна колотушка найдут её, как со мной так и без меня. Вы же сами прекрасно знаете, что купить готовый ботнет со «всё включено» сейчас можно долларов за 300-500. И демпинг на этом рынке продолжается.
А вот что делать владельцам аппаратных фаерволов, которые покупаются по бешеным ценам, но настроить их никто не может, потому что оттестировать нечем? Ждать пока накроет очередная волна ддоса и отлаживать «в мыле»? Ну или бежать под защиту к Вам :)
Так что Ваша точка зрения также понятна — пока люди меньше знают о pfring DNA, netmap и т.п. у них больше шансов стать Вашими клиентами.
Последний пассаж очень в точку. Массовое присутствие курейтора на российском рынке обусловлено скорее отсутствием альтернатив, нежели более глобальными причинами. По сути, хорошее фильтрующее решение на netmap/vyatta dpdk и достаточно большая выкупленная емкость линков для амортизации — залог успеха аналогичного решения в техническом плане, крутить-вертеть там можно только эвристику для шифрованных соединений и то не сильно.
О netmap/dpdk/pfring-dna я говорю чуть-ли не на каждой презентации.

Одно дело — делать фреймворк двойного назначения, и совсем другое дело публикация cookbook по приготовлению штамма холеры.
Дело даже не в «на (работе|свободное время)». Дело в том, что интернет штука крайне хрупкая и еще одной статьи с рецептом как его сломать (но без рецепта как его починить) нам всем и нехватало.

Поверьте, можно сломать интернет и гораздо меньшим количеством пакетов.
Ломать — не строить.

Ну спасибо, конечно, за комплимент в виде «массового присутствия» и «отсутствия альтернатив».
Но, но это совсем не так. Есть Женя Ерхов и его IXI, Женя Касперский и его ЛК, сильная команда Муслима Меджлумова в Ростелекоме, МФИСофт и его Периметр. Альтернативы есть и их много. И они очень разные.

И это главное их свойство.

Задача несколько сложнее, чем вам кажется. Дело не в умении молотить много-много пакетов, и не в полосе чтобы эти пакеты принять. Посмотрите на CloudFlare — у них есть и пакеты и полоса и 120M инвестиций? Казалось бы, что мешает?

Мешает ровно та-же ошибка что допустили вы — «крутить-вертеть там можно только эвристику для шифрованных соединений и то не сильно».

"«Играл — не угадал ни одной буквы».

Засим откланяюсь.
Не берусь судить о деталях непрофильного для меня бизнеса, просто уточню — выше я привел необходимые условия. Безусловно, при погружении в соответствующий рынок выплывут условия желаемые и условия достаточные, вот и все. А упоминание о еще одном инструменте для ломания интернета, оно очень странное. Во-первых, такая атака сложит сетевую инфраструктуру самого атакующего с гораздо большей вероятностью чем что-то еще. Во-вторых, атаковать из одной точки можно гораздо более эффективно, например, с амплификацией. Запуск потока от нетмаповского генератора наружу сродни отрезанию себе репродуктивного органа, никто этим пользоваться не будет. Сущность хороша для проверки хвастливых производителей свичей на соответствие заявлений реальности, не более.
Во-первых, такая атака сложит сетевую инфраструктуру самого атакующего с гораздо большей вероятностью чем что-то еще.

Некоторая доля истины в словах Александра есть. Я приведу историю без упоминания имён и слегка изменив детали.
— Компания А проводила тендер в строго означенное время и для неё невероятно важна была гарантированная доступность. Для этой цели она арендовала сервер в одном румынском ДЦ. Этот датацентр предлагает защиту от атак до ~500 mpps и его защита реальна. Но в означенное время сервер убит. Как же это произошло?
Компания Б выяснив где расположен сервер также арендовала несколько серверов в этом же ДЦ и в час Х начала атаки. Так как вся защита ДЦ расположена на пограничных узлах и не контролирует внутренние сети, то сервер оказался незащищённым в защищённом ДЦ.
— Конечно, это чётко спланированная акция и с учётом денег которые там крутились текущая статья даже не песчинка в пустыне.
Павел, есть такое.
У нас был достаточно бурный и веселый год, правда не только и не столько в «техническом» измерении. Больше про политики и законы.

Пролюлил я Ваше письмо, прошу простить всемилостиво. Отвечу сегодня.
Дело не в умении молотить много-много пакетов, и не в полосе чтобы эти пакеты принять. Посмотрите на CloudFlare — у них есть и пакеты и полоса и 120M инвестиций? Казалось бы, что мешает?


Поддержу, способность справляться с высоким PPS и наличие полосы — это необходимое, но НЕ достаточное условие для эффективной работы. Также, согласен с Сашей, что главное кунгфу находится где-то в области ML.
О netmap/dpdk/pfring-dna я говорю чуть-ли не на каждой презентации.

Александр, а что Вы на них говорите? То что ВАМ удалось сделать решение. Где и когда вы поделились накопленным опытом, хотя бы уже и устаревшим? Где хоть одно готовое решение по защите? Да, понятно, что для Вас это бизнес и Вы не собираетесь делиться своими наработками. Но давайте не будем лукавить — кроме самопиара там ничего нет.
И какая будет польза от «готового решения по защите» если к нему нужно 300Gbps полосы, умение ее балансировать и желание/умение искать ошибке в чемодане кода который отвечает за ML?

Рядовой пользователь из этого точно никакой пользы не извлечет.

не только рядовые пользователи могут и в гости зайти.
Толку от pf_ring как такового для зищат? Ну умею я его, ну умею во всех высокопроизводительных конфигурациях, ну могу обработать пару MPPS, но от DDoS меня это почему-то соверешенно не защищает =) Это инструмент и очень низкоуровнеый. Это равносильно называть карту класса 82599 — средством защиты от DDoS :)
У нас свободная страна :-), поэтому готов поддержать как право публиковать инструментарий по генерации трафика, так и право объединять усилия сообщества по защите. В конечном счёте, мы все от этого выиграем.

IMHO время «security through obscurity» в области DDOS заканчивается.
Женя, раз пошла такая пьянка, hash function вашего балансировщика в студию!
Саш я про то, что это не остановить. Инструментарий уже есть, статьи и howto неизбежно будут появляться, не у нас, так в англоязычном сегменте. Я бы с удовольствием поддержал продолжение твоей борьбы ( tech.yandex.ru/events/yac/2013/talks/1135/ ) по объединению усилий в совместном противодействии DDOS, т.к. абсолютно убеждён, что это и есть решение.
Жень, это или сарказм или «doublethink».

Еще раз, повторюсь: для Тебя, меня, 0din это проблем не доставит. Но вот для любого хостера или бизнеса у которого нет под рукой свободных 10G и железки способной перемолотить 14.88Mpps SYN-flood — это безусловно и однозначно станет проблемой.

С точки зрения бизнеса — это конечно радость-радость. Новые клиенты всем нам.
С точки зрения этики и морали — стандратная притча о продавце ружья.

Нет, не сарказм и не doublethink, просто реально времена меняются и нужно что-то делать. Ты всем доказал, что реальная защита от DDOS — это не многомиллионные вложения в железки и небольшая команда «головой» может сделать больше, чем толстосумы со штатом в сотни программеров и инвестициями в 120М. Думаю, что можно было бы продолжить объединение усилий на круглых столах, а затем перейти и в практическую плоскость.
Александр, меня вот терзают смутные сомнения о необходимости публиковать статью о http-ддосинге, потому что там описан механизм доступный любому школьнику, способный уложить большинство шаред-хостингов и впсок нижнего диапазона. Но о защите от http-ддоса сейчас не знает только ленивый и защита от таких атак меня не интересует.
А вот если не подогревать тему стековых-атак, то и решений найдено не будет. Я долго думал писать ли её, либо просто разослать решение всем кто просил, но сейчас я уже уверен, что решение о написании было верным, хотя бы даже потому, что мне указали на явные косяки (0din отдельное спасибо!).
А как мне простому админу получить нужную мне информацию как не в обсуждении здесь?
Смотрим «качество» принимаемых пакетов:
# tcpdump -vvv -n
11:39:54.349362 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 46)
129.115.75.162.0 > 10.90.90.55.0: Flags [S], cksum 0xcd54 (correct), seq 1091106137:1091106143, win 512, length 6

И в чем заключается качество пакетов?
1. ttl=64 и не изменяется
2. id=0 и не изменяется
3. sport = dport = 0
4. исходя из:
tcp->th_ack = rand(); // Contains the acknowledgement number.

получаем ack != 0, а у SYN сегмента должно быть ack = 0, то на чем палиться старый добрый hping3.
5. win = 512 и не изменяется
6. зачем-то передаете 6 байт в payload?
7. из не существенного, почему-то в pkt-gen.c: ip->ip_tos = IPTOS_LOWDELAY;

tcp->th_seq = ntohl(rand()); // Contains the sequence number.

ntohl — здесь бессмысленен.
0din, огромное спасибо, за комент!
Здесь меня интересовал только подсчёт контрольной суммы.
Эти вопросы я пересмотрю.
s/d порты просто недопечатал (этот функционал есть в pkt-gen)
pkt-gen -f tx -i netmap:ix0 -s 128.0.0.1:1025-223.255.255.254:65535 -d 10.90.90.55:80 -l 60
Тогда можно добавить W-scale, NOP и SACK_PERM в пейлоад и MSS конечно же выставить. Чтобы уж совсем был похож на виндовый пакет.

И кстати можете попробовать пустить на себя SYN Reflection своим методом, это же раза в три больше пакетов будет! Правда не знаю насколько это законно.
Only those users with full accounts are able to leave comments. Log in, please.