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

Комментарии 32

Было на прошлогоднем HL++. И ещё ранее было где-то у Сысоева.
Veriora veris! Тут вообще нет по сути ничего нового — вопрос в том, что никто не использует и старого, а тем временем ребята из Китая выдувают по 80 кппс со своих тазиков, и даже на такой «атаке» проекты массово мрут.
НЛО прилетело и опубликовало эту надпись здесь
Кому что ближе. Так получилось, что в основном работаем с фряхой, поэтому тут обстановкой владею больше. Да и настроек здесь фактически никаких, будем откровенны — с ними приведенных тут результатов не добиться. Разбор по настройкам хочу написать в топике о самой атаке, что бы не мешать в одну кучу сало и мед.
НЛО прилетело и опубликовало эту надпись здесь
На деле, на одном тюнинге стека много не вырубишь — да вы, наверно, и сами знаете. Поэтому хотелось бы комплексно рассмотреть проблему на основе одной атаки — от и до, где описать и железо, и софт, и взаимодействие с аплинками и панику, которая разразилась в начале :) Этот топик прошу считать введением в проблему.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Так и есть. Думал, что творческое осмысление RFC в примерах основной массе аудитории будет не интересно. Наверное, ошибся, впредь буду больше времени уделять описанию общей части. Но тут и цель ставилась — дать общую стратегию, исправлюсь в описании атаки :)
Все хорошо, но если вы уж предлогаете тюнинговать систему через systcl, то хотя бы разжевать для чего это делается (почему именно эти параметры) — это куда интресенее.
Считаете? Отлично, буду действовать в направлении, описанном в предыдущем комментарии. Но вообще детальный разбор запланирован на следующую статью.
Ну если все будет в слд части, то будем только ждать. Вообще тема оптимизация очень интересна и тонкая, так как универсального метода нет, и надо донести понимание как делать хорошо в сложившийся ситуации.
Очень постараюсь оправдать ожидания :)
Интересно, какие хостеры согласятся вам резать трафик с определенных ip адресов/ по регионам? Как правило у них на одном ип адресе висит целая туча сайтов, как они им объяснят что вдруг для определенных регионов ваш сайт стал недоступен? В 99,9% они отключат сайт на который идет аттака (если конечно определят кто под ударом).

Даже в случае своего сервера, в ДЦ врядли будет этим заморачиваться, по той же самой причине. Просто недавно довелось с подобным столкнутся, оббегал несколько дц, везде делали большие глаза при просьбе порезать мусорные трафик с определенных ип. Предложили ASA киски по 400 евро в мес, но, судя по характеристикам, они бы легли раньше сервера, ибо аттака была около 1млн ппс.

Проблема решилась грамотным тюнингом сервера, однако хороший ДЦ под фильтры все еще в поиске.
Если кто-то посоветует такой, который бы мог по просьбе на аплинках резать трафик с определенных ипов или по числу коннектов, буду очень признателен.

Кстати частично свинью ботнетчикам удалось подложить в виде скрипта, анализирующего логи аттак и рассылающего автоматом абузы с вырезками логов на спарсенные из вхуизной информации мыльники. Как-нибудь напишу об этом статейку.
>>Интересно, какие хостеры согласятся вам резать трафик с определенных ip адресов/ по регионам? Как правило у них на одном ип адресе висит целая туча сайтов, как они им объяснят что вдруг для определенных регионов ваш сайт стал недоступен? В 99,9% они отключат сайт на который идет аттака (если конечно определят кто под ударом).

ну резать не обязательно по айпи можно. в iptables есть модуль string. им можно вытащить host из заголовка пакета и резать для этого хоста китай и т.д. работает довольно быстро. а вообще это так, размышления вслух — будет ли хостер так делать или нет не в курсе.
Попробую ответить максимально подробно:
— далеко не каждый, но ищите и обрящите — мы работаем с дата-центрами, в которых такие вопросы давно решены. Если действительно есть необходимость в такого рода сервисе — с радостью дам вам координаты. Хотелось бы заметить, что в нашем случае выкупается серьезная полоса транзита и у нас есть свои AS вкупе с full-view bgp. Но начинали мы с пяти серверов и 300 мбит канала — и даже в то время проблем с блокированием мусора в разумных приделах не было, правда мы оплачивали аренду полной цешки. На всякий случай скажу, что «разумный придел» был около 8 гбпс.
— в дисклеймере я упомянул, что реализация какой бы то ни было стратегии защиты на базе шаред-хостинга — запредельно ужасное дело. Пожалуйста, читайте внимательнее. По поводу 99.9% — добавляйте еще десятую долю смело — сайт под SYN-атакой в условиях шаред-хостинга будет заблокирован мгновенно. Разблокировать его будет той еще задачей по боксу по переписке.
— с недоумением прочитал о «Проблема решилась грамотным тюнингом сервера» — но потом увидел, что вы просили заблокировать мусорный трафик с определенных адресов. Честно скажу, при условии знания адресов, с которых идет трафик — не понимаю, почему ДЦ не пошел вам навстречу.
— по поводу последнего — в ситуации, описанной в топике — это очевидно бесполезное занятие, да и в целом — мм, как бы сказать, дц будут просить данных по атаке как минимум. В прочем, была бы охота заниматься.
С уважением.
>> с недоумением прочитал о «Проблема решилась грамотным тюнингом сервера»
Как ни странно, но все было именно так. Пришлось обновить ядро на дебиане, в новой версии появилась возможность более грамотно раскидывать прерывания сетевой по ядрам, это в купе с еще некоторыми шаманствами и рассылкой абуз, решило проблему и позволило без потерь свободно держать млн ппс и 700 гбит поток без каких-либо потерь.
>> по поводу ДЦ не пошедшего навстречу, это называется не сыпьте соль на рану. ДЦ проще скинуть проблемного клиента, чем искать какие-то нестандартные решения. По поводу блоков на аплинках однозначно ответили что нет технической возможности. Данные по аттаке их также не интересовали.

В общем за контакты адекватных ДЦ или ресселлеров буду очень благодарен.
Отлично, отписываюсь в личку :)
Поток 700 мегабит, отпечатался, сори)))
Тоже неплохой результат, даже и с неспуфленными синами — за такое провайдеры защиты, которые считают объем атаки, содрали бы дополнительных пару тысяч евро — так что неплохая экономия :) Все-таки обзор таких провайдеров так и просится в топик, однако, заодно и с реакцией различных ДЦ на атаки.
>>> Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
Но если вам посчастливилось работать с серьезной компанией — попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона.

я вот про это писал. Мне реально очень интересно, какой ДЦ согласится на блекхол целого региона или хотя бы конкретных айпишников.

>>Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой. На эти действия способен фактически любая хостниг-компания.
Про это я вообще молчу и очень интересно посмотреть на хостинг-компанию, с радостью режущую вам UDP трафик на аплинках.

iptables это конечно хорошо, но бывают случаи, когда сервер становится раком даже при полном блоке всех коннектов, не говоря уже о анализе через string.
> я вот про это писал. Мне реально очень интересно, какой ДЦ согласится на блекхол целого региона или хотя бы конкретных айпишников

Года четыре назад работал в NOC одного киевского провайдера. Клиенты — региональные провайдеры или крупные предприятия. Помимо наших и клиентских коммутаторов, стоек десять занимали колокаторы. Раза два в месяц кого-то из колокаторов DDoSили, и так качественно, что это на себе ощущал весь бекбон.

Был скрипт, который определял айпишки источников атаки, и заворачивал их /24 сети в BGP Blackhole. Лучше через 2-3 недели кто-то напишет письмо с жалобой: «у меня не работает zhazha.com и последний хоп ваш пограничный роутер, прошу разобраться» чем от атаки будут страдать смежные с атакуемым сегменты сети.

А что за провайдер, если не секрет?
Плюс к этому — вас поливали с реальных адресов, я правильно понимаю? Или вы просто блокировали цешки в нейбор, из которого льют?
Digital Generation, в то время уже часть Ucomline или Фарлеп-инвест, они сами не могли разобраться кто кем владеет.

Как правило атака шла с 3-5 реальных адресов, иногда они были в одной /24, но чаще в разных странах.
Извиняюсь, если не правильно понял «цешки в нейбор», два года как не админ, а когда был BGP знал поверхностно. Вы имеете в виду что мы /24 сети блокировали в роут-мапах того аплинка от которого пришел DDoS трафик?
Просто ваш подход мне напомнил UTEL, мы как раз с ними работали в то время, и подумалось — не о нас ли речь :)
Я имел ввиду, что вы отдавали нульраут вашим аплинкам для своих /24 по destination ip
Наверное я неправильно выразился, употребив «BGP Blackhole» к той ситуации, скрипт заворачивал маршруты в null интерфейс. Хотя может это одно и то же.
Тут просто возможны два варианта как минимум, зависит от условий атаки и от того, что готов терпеть владелец атакуемого ресурса :)
Насколько я помню, владелец атакуемого ресурса мог даже не заметить атаки. Скрипт крутился в кроне наверное ежеминутно, и заворачивал трафик с сети атакующего в null интерфейс. Атаку мог заметить дежурный, увидев письмо которое слал скрипт, да и то постфактум.
Тогда точно не мы :) Атаки на наши проекты аукались даже пользователям DSL'а, к сожалению
Мне кажется, вот этот фрагмент поймут исключительно те, кто у же и так в теме:
В первом приближении на уровне «клиент-сервер» выглядит это вот так:
клиент отправляет серверу SYN-пакет, на который отвечает SYN+ACK.Клиент отправляет в ответ ACK на SYN сервера и соединение переходит в состояние установленного.

(из такой формулировки не очевидно, что syn и ack — это флаги в заголовке tcp, а «syn+ack» это не два разных пакета. кроме того, пропущено слово «сервер» и синтаксически получается, что клиент отправляет syn и самже отвечает двумя пакетами syn и ack.)

Гораздо доходчивее была бы просто картика:
upload.wikimedia.org/wikipedia/commons/c/c7/300px-Tcp-handshake.png
Из которой, кроме прочего, видно, как связаны SYN и ответный ACK, и почему это трудоёмко для сервера.
Что бы было очевидно, что такое SYN/AСK — пришлось бы рассказать о структуре пакета полностью, объяснить, что такое битовые флаги, и — наверное — что такое бит? Это кому-то нужно? Видите, даже вы смогли это увидеть в википедии, не понадобилось творчески переосмысливать ее текст.
А вот описка в
(из такой формулировки не очевидно, что syn и ack — это флаги в заголовке tcp, а «syn+ack» это не два разных пакета. кроме того, пропущено слово «сервер» и синтаксически получается, что клиент отправляет syn и самже отвечает двумя пакетами syn и ack.)

очень досадная, спасибо, что поправили.
О том, почему это трудоемко для сервера — пришлось бы рассказать о том, какие сущности создает ОС в процессе коннекта, что в общем-то, для первого приближения — сильно лишняя информация. На примере используемой нами ОС я опишу чуть позже, тут такой объем просто не нужен.
Открытое решение по защите от DDOS атак — в частности synflood
https://github.com/LTD-Beget/syncookied
https://beget.com/ru/articles/syncookied
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории