Что бы было очевидно, что такое SYN/AСK — пришлось бы рассказать о структуре пакета полностью, объяснить, что такое битовые флаги, и — наверное — что такое бит? Это кому-то нужно? Видите, даже вы смогли это увидеть в википедии, не понадобилось творчески переосмысливать ее текст.
А вот описка в
(из такой формулировки не очевидно, что syn и ack — это флаги в заголовке tcp, а «syn+ack» это не два разных пакета. кроме того, пропущено слово «сервер» и синтаксически получается, что клиент отправляет syn и самже отвечает двумя пакетами syn и ack.)
очень досадная, спасибо, что поправили.
О том, почему это трудоемко для сервера — пришлось бы рассказать о том, какие сущности создает ОС в процессе коннекта, что в общем-то, для первого приближения — сильно лишняя информация. На примере используемой нами ОС я опишу чуть позже, тут такой объем просто не нужен.
Тоже неплохой результат, даже и с неспуфленными синами — за такое провайдеры защиты, которые считают объем атаки, содрали бы дополнительных пару тысяч евро — так что неплохая экономия :) Все-таки обзор таких провайдеров так и просится в топик, однако, заодно и с реакцией различных ДЦ на атаки.
Просто ваш подход мне напомнил UTEL, мы как раз с ними работали в то время, и подумалось — не о нас ли речь :)
Я имел ввиду, что вы отдавали нульраут вашим аплинкам для своих /24 по destination ip
А что за провайдер, если не секрет?
Плюс к этому — вас поливали с реальных адресов, я правильно понимаю? Или вы просто блокировали цешки в нейбор, из которого льют?
Попробую ответить максимально подробно:
— далеко не каждый, но ищите и обрящите — мы работаем с дата-центрами, в которых такие вопросы давно решены. Если действительно есть необходимость в такого рода сервисе — с радостью дам вам координаты. Хотелось бы заметить, что в нашем случае выкупается серьезная полоса транзита и у нас есть свои AS вкупе с full-view bgp. Но начинали мы с пяти серверов и 300 мбит канала — и даже в то время проблем с блокированием мусора в разумных приделах не было, правда мы оплачивали аренду полной цешки. На всякий случай скажу, что «разумный придел» был около 8 гбпс.
— в дисклеймере я упомянул, что реализация какой бы то ни было стратегии защиты на базе шаред-хостинга — запредельно ужасное дело. Пожалуйста, читайте внимательнее. По поводу 99.9% — добавляйте еще десятую долю смело — сайт под SYN-атакой в условиях шаред-хостинга будет заблокирован мгновенно. Разблокировать его будет той еще задачей по боксу по переписке.
— с недоумением прочитал о «Проблема решилась грамотным тюнингом сервера» — но потом увидел, что вы просили заблокировать мусорный трафик с определенных адресов. Честно скажу, при условии знания адресов, с которых идет трафик — не понимаю, почему ДЦ не пошел вам навстречу.
— по поводу последнего — в ситуации, описанной в топике — это очевидно бесполезное занятие, да и в целом — мм, как бы сказать, дц будут просить данных по атаке как минимум. В прочем, была бы охота заниматься.
С уважением.
На деле, на одном тюнинге стека много не вырубишь — да вы, наверно, и сами знаете. Поэтому хотелось бы комплексно рассмотреть проблему на основе одной атаки — от и до, где описать и железо, и софт, и взаимодействие с аплинками и панику, которая разразилась в начале :) Этот топик прошу считать введением в проблему.
Так и есть. Думал, что творческое осмысление RFC в примерах основной массе аудитории будет не интересно. Наверное, ошибся, впредь буду больше времени уделять описанию общей части. Но тут и цель ставилась — дать общую стратегию, исправлюсь в описании атаки :)
Кому что ближе. Так получилось, что в основном работаем с фряхой, поэтому тут обстановкой владею больше. Да и настроек здесь фактически никаких, будем откровенны — с ними приведенных тут результатов не добиться. Разбор по настройкам хочу написать в топике о самой атаке, что бы не мешать в одну кучу сало и мед.
Veriora veris! Тут вообще нет по сути ничего нового — вопрос в том, что никто не использует и старого, а тем временем ребята из Китая выдувают по 80 кппс со своих тазиков, и даже на такой «атаке» проекты массово мрут.
А вот описка в
очень досадная, спасибо, что поправили.
О том, почему это трудоемко для сервера — пришлось бы рассказать о том, какие сущности создает ОС в процессе коннекта, что в общем-то, для первого приближения — сильно лишняя информация. На примере используемой нами ОС я опишу чуть позже, тут такой объем просто не нужен.
Я имел ввиду, что вы отдавали нульраут вашим аплинкам для своих /24 по destination ip
Плюс к этому — вас поливали с реальных адресов, я правильно понимаю? Или вы просто блокировали цешки в нейбор, из которого льют?
— далеко не каждый, но ищите и обрящите — мы работаем с дата-центрами, в которых такие вопросы давно решены. Если действительно есть необходимость в такого рода сервисе — с радостью дам вам координаты. Хотелось бы заметить, что в нашем случае выкупается серьезная полоса транзита и у нас есть свои AS вкупе с full-view bgp. Но начинали мы с пяти серверов и 300 мбит канала — и даже в то время проблем с блокированием мусора в разумных приделах не было, правда мы оплачивали аренду полной цешки. На всякий случай скажу, что «разумный придел» был около 8 гбпс.
— в дисклеймере я упомянул, что реализация какой бы то ни было стратегии защиты на базе шаред-хостинга — запредельно ужасное дело. Пожалуйста, читайте внимательнее. По поводу 99.9% — добавляйте еще десятую долю смело — сайт под SYN-атакой в условиях шаред-хостинга будет заблокирован мгновенно. Разблокировать его будет той еще задачей по боксу по переписке.
— с недоумением прочитал о «Проблема решилась грамотным тюнингом сервера» — но потом увидел, что вы просили заблокировать мусорный трафик с определенных адресов. Честно скажу, при условии знания адресов, с которых идет трафик — не понимаю, почему ДЦ не пошел вам навстречу.
— по поводу последнего — в ситуации, описанной в топике — это очевидно бесполезное занятие, да и в целом — мм, как бы сказать, дц будут просить данных по атаке как минимум. В прочем, была бы охота заниматься.
С уважением.