Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 100
Конфиг уже был использован в бою, я так понял? Какие результаты по сравнению с железкой? Железку примерно какого уровня стоимости он может заменить?
Да, он уже более двух недель помогает мне бороться с флудом суммарной мощностью ~ 34 Mb/s. Сравнивать с железками трудно — так как задачи у них немного, но все же разные. На уровне атакуемого сервера не совсем верно решать вопросы с атаками, но когда другого выбора нет — то очень даже вполне. Касаемо ценового вопроса, то 34 — 40 Mb/s. способны «переживать» железки стоимостью не более 400 — 500$ + цена за размещение этой железки в дата-центре.
Но я так понимаю, что в железных решениях тоже крутится какая-то специализированная ось и какие-то конфиги, так? В тех же цисках?
Само собой, любая железка, будь то решение от Cisco, D-link и т.п. — это всего лишь куча микросхем в красивой обертке. Без грамотной конфигурации сего железа это и дальше будет грудой «железа».
Ага, в линейке cisco это cisco guard xt, плюс к ней нужно cisco PIX firewall…
первая весь трафик смотрит и в случае аномалии отправляет сигнал PIX и тот блокирует траф…
цены конечно кусаются от 30к зеленых =)
первая весь трафик смотрит и в случае аномалии отправляет сигнал PIX и тот блокирует траф…
цены конечно кусаются от 30к зеленых =)
При обычном флуде — до уровня мгновенной заливки канала. А дальше в любом случае конец. :)
Если прикрутить еще и проверку по cookie + кэширование + грамотно настроенный firewall, то продавить «это» обычным HTTP-flood/SYN-flood практически невозможно, за исключением опять-таки заливки каналов десятками\сотнями\гигабитами, в зависимости от ширины канала и железа. При условии, что железо — не celeron/512RAM/IDE HDD и не VDSка.
Другое дело, что боты сейчас стали умными, и в тупую долбят «HTTP 1.1 /» уже единицы. Нормальные боты и страницы меняют, и user agent, и referrer. А самые умные уже даже cookie сохранять научились.
Если прикрутить еще и проверку по cookie + кэширование + грамотно настроенный firewall, то продавить «это» обычным HTTP-flood/SYN-flood практически невозможно, за исключением опять-таки заливки каналов десятками\сотнями\гигабитами, в зависимости от ширины канала и железа. При условии, что железо — не celeron/512RAM/IDE HDD и не VDSка.
Другое дело, что боты сейчас стали умными, и в тупую долбят «HTTP 1.1 /» уже единицы. Нормальные боты и страницы меняют, и user agent, и referrer. А самые умные уже даже cookie сохранять научились.
Когда как, на самом деле
Канал забить, особенно хороший, нужен нормальный такой ботнет. Например, серверный :-) Чаще на каком-нибудь хилом хостинге тупо тормозит или падает сервак.
Сейчас пожалуй не сколько канал ( учитывая сейчашнюю их ширину), а подвесить сайт забив всё процессорное время нагрузив по максимуму серверный софт
Бывают и такие атаки, которые именно канал забивают. Например, мощные сервера стоят, балансировка, циски — тут проще нанять большой ботнет и забить канал.
Совершенно верно. При сегодняшних возможностях магистральных каналов, узким местом на мой взгляд является серверный софт, вернее даже не серверный, а клиентский.
Когда нас досили, то до забивки канала было ещё очень далеко, софтом дос распознавался и резался тоже довольно хорошо, а вот всякие буфера ОС и лимиты числа сетевых соединений кончались довольно быстро. И машика падала…
В большинстве OS все буферы и тайминги довольно хорошо поддаются подкрутке. У меня была атака на один из наших DNS серверов — просто шли «кривые» запросы которые вводили bind и вместе с ним сервер в дикий ступор, долго ничего не мог поделать пока не разобрался в том, что все сокеты заняты — подкрутил на горячую через sysctl и смог нормально разобраться с вредоносным трафиком.
У нас «труба» 1 Gbit/s. Забить её простыми http — запросами…. это какой же ботнет надо содержать… У меня не размещено проектов, на которые экономически целесообразно было бы проводить атаки такого уровня.
А сколько, кстати, стоит атака, забивающая 100 мегабит и 1 гигабит?
Тут я Вам, Алексей, не помощник — цен не знаю. Тут простая математика — один запрос в моем случае «весит» 62 байта, вот и подсчитайте сколько надо таких запросов отправить в единицу времени что бы суммарный поток трафика достиг предела моего канала, разделите к примеру на 7 (число запросов с одного зомби в момент времени) и получится приблизительное количество зомби в ботнете. Вряд ли содержание такого ботнета стоит дешево.
Хм, интересно, а какие расходы на содержание ботнета? Какие составляющие там в расходах?
Могу ответить основываясь лишь на предположениях и логике — для того, что бы все это функционировало, нужно «доставить» вирус или что там, на уязвимую машину, связать все воедино с центром управления, и следить за работоспособностью этого хозяйства, и это параллельно постоянному процессу детектирования и распознаванию антивирусами этих программ. Исходя из того, что написание программы которая и реализует функционал ботнета вряд ли занятие для энтузиастов, то это скорее всего так же несет некие затраты.
Была ведь ссылка на статью Экономика ботнетов…
>> средняя цена составляет $0,5 за один бот
Конечно цены варьируются сильно от задач и т.д.
Вот и считайте.
>> средняя цена составляет $0,5 за один бот
Конечно цены варьируются сильно от задач и т.д.
Вот и считайте.
Если верить людям, которые нас досили, то 100Мбит стоит около $350-400/сутки (цены 2007 года).
Это если пингуют. Сейчас в моде TCP SYN-Flood атаки, когда веб-серверу отсылается большое количество запросов, а ответ никто на забирает уже. В результате веб-сервер жрет процессорное время и память, как безумный, плюс ядро тоже начинает откушивать ресурсы на поддержание толпы коннектов.
нжинкс фронтендом в общемто решает эту проблему. даже без файрвольных хитростей
Use syncookies, Luke ;)
У Сысоева на highload был хороший доклад о настройке FreeBSD на обработку большого числа соединений — вполне применимо к ДДОСу.
У Сысоева на highload был хороший доклад о настройке FreeBSD на обработку большого числа соединений — вполне применимо к ДДОСу.
accept() срабатывает только после завершения tcp-handshake, так что флуд SYN-пакетами до прикладных программ не доходит
Можно еще добавить автоматическое разбанивание по прошествии определенного срока — недели, например, или месяца, если атака затяжная. Ведь среди атакующих большинство компьютеров — ваши потенциальные пользователи.
Плюс туда могли попасть и случайные пользователи, которые, например, пытались стянуть сайт телепортом, или еще каким пауком. И, самое интересное, что туда же могли попасть и админы сайта, которые с постороннего ip, например, сливают файлы по FTP. (меня так мой хостер регулярно банит, я знаю о чем говорю :)
Плюс туда могли попасть и случайные пользователи, которые, например, пытались стянуть сайт телепортом, или еще каким пауком. И, самое интересное, что туда же могли попасть и админы сайта, которые с постороннего ip, например, сливают файлы по FTP. (меня так мой хостер регулярно банит, я знаю о чем говорю :)
Можно еще добавить автоматическое разбанивание по прошествии определенного срока — недели, например, или месяца, если атака затяжная. Ведь среди атакующих большинство компьютеров — ваши потенциальные пользователи.
Конечно можно, даже более того, нужно. Но это уже явно не задача nginx, как минимум тех скриптов, которые парсят логи, в моем случае это 5 скриптов на perl.
И, самое интересное, что туда же могли попасть и админы сайта, которые с постороннего ip, например, сливают файлы по FTP.
Для этого существует «белые списки» адресов, которые каждый администратор имеет возможность дополнить через web- морду.
Белые списки… так у вас же админы попадают в блеки :) нафиг таких админов, они по белому задосят :D
Сегодня только модератор жаловался что не может из дома попасть на сайт, из под 1 IP выходят 4000 пользователей, какая то машина из числа этих 4000 пользователей была заражена и скрипты забанили на фаерволе этот грешный 1 IP… Вот свежайший пример из жизни.
В итоге сам модератор решал вопрос со своим провайдером в части поиска того, кто флудит наш сайт. Так как открывать этот IP пока с него идет флуд я отказался.
В итоге сам модератор решал вопрос со своим провайдером в части поиска того, кто флудит наш сайт. Так как открывать этот IP пока с него идет флуд я отказался.
Разбанить можно будет всех как атака прекратится. Обычно это не особо затяжное действо.
Я думаю, все китайские и индийские айпи, а также подсетки абузоустойчивых хостингов можно нафиг и не разбанивать.
Метод действенный для небольших атак, но увы часть запросов всё-равно сначала поступит к серверу, прежде чем начнут блокироваться, а если ставить слишком маленький лимит то это начнёт доставлять неудобства пользователям. У себя например мы фильтруем запросы по определённым параметрам — в данный момент это user-agent'ы браузеров атакующих компьютеров. Конечно, это не всегда эффективно но спасает от большинства атак из-за бугра. Сначала nginx отдаёт ботам код 444, затем по крону IP достаются из лога и отправляются в фаерволл. В итоге 99% недействительных запросов фильтруются и не достигают бекэнда. Правда, для начала необходимо достать эти самые user-agent'ы, их может быть до 20-40. На практике удавалось смягчать атаки до 15к запросов/сек при 10-15к ботнете. Замечу, что боты часто и не делают больше нескольких запросов в секунду — и остановить такие атаки описанным выше методом невозможно. Экспериментируйте :) нет одного простого решения которое остановит любую атаку.
Абсолютно согласен с Вами — универсального способа не существует. Для каждой новой атаки я вот и «сочиняю» новые софтовые решения, не по тому что нет аппаратных возможностей для фильтрации вредоносного трафика, а потому что интересно побороть атаку не стандартным методом.
Особенностью же этой атаки были вполне легитимные рандомные запросы и user-agent`ы — никаких отличий от действий нормального пользователя за исключением частоты запросов. Как вариант пробовал анализировать состояния соединений с помощью netstat, смотрел трафик на предмет выделения одной сигнатуры, но ничего более эффективного, чем описанное мною решение из софтовых вариантов у меня не вышло.
Особенностью же этой атаки были вполне легитимные рандомные запросы и user-agent`ы — никаких отличий от действий нормального пользователя за исключением частоты запросов. Как вариант пробовал анализировать состояния соединений с помощью netstat, смотрел трафик на предмет выделения одной сигнатуры, но ничего более эффективного, чем описанное мною решение из софтовых вариантов у меня не вышло.
Нечто подобно пару лет уже использую (ранее только с limit_conn в nginx) + более сложный перловый скрипт, анализирующий с какого ип пришло более чем разрешено одинаковых запросов в еденицу времени.
Отбивал атаки порядка 15к ботов в час. на core2duo 2.4
но, на линухе. там есть особенно полезный патч ядра (оформляется модулем без пересборки ядра) — ipset
удобство в возможности задания времени жизни включения в сет
и в том что сет имея до 65к /32 включений ни разу не тормозит.
Кстати, както было особенно настырная атака, держали адреса по неделе в сете, так 65к исчерпали,
ничего, завели 10 сетов и небольшой баш скрипт проверки прежде чем добавлять… и все было ок
Отбивал атаки порядка 15к ботов в час. на core2duo 2.4
но, на линухе. там есть особенно полезный патч ядра (оформляется модулем без пересборки ядра) — ipset
удобство в возможности задания времени жизни включения в сет
и в том что сет имея до 65к /32 включений ни разу не тормозит.
Кстати, както было особенно настырная атака, держали адреса по неделе в сете, так 65к исчерпали,
ничего, завели 10 сетов и небольшой баш скрипт проверки прежде чем добавлять… и все было ок
интересный топик, причем интересный поднятой темой и обсуждением. + в ..(ну вы поняли куда)… однозначно.
Испорченный IP так же просто определяется как и подделывается, а далее кто мешает запретить принимать пакеты от таких IP ? Antispoof — фильтры есть практически в каждом нормальном фаерволе, я не говорю про серьезные «железные» решения.
Или я ошибаюсь?
Или я ошибаюсь?
Обычно досеры детей не обижают таким флудом
SYN-flood очень легко и непринужденно обрезается включением SYN-cookies.
DDoS атаки режим ооочень просто. Главное выявить ip реального пользователя от бота. Как? очень просто. На примере: висит програмулька, мониторит нагрузку канала. Возрастает до 80% загрузка канала, активируем panicMode, на всех сайтах автоматом догружается скрытый iframe. Боты не используют бровзер, соотвественно этот скрытый iframe не видят, а реальный клиеты грузят. IP реальных клиентов поподают в белый список(через запрос этого iframe, все остальный в бан на iptables.
Нагрузка канала спадает до 70% iptables сбрасывается, panicMode выключается и всё ок.
SYN атаки нормально настроенной системой режутся в разы.
Нагрузка канала спадает до 70% iptables сбрасывается, panicMode выключается и всё ок.
SYN атаки нормально настроенной системой режутся в разы.
Уважаемый, очередь пакетов? или вы о чём? растолкуйте пожалуйста.
Про syncookies вам не рассказали, да ведь?
Про то, что число и периодичность SYN можно лимитировать файрволом, можно блочить тех, кто посылает больше N в T времени, тоже, правда?
Про то, что число и периодичность SYN можно лимитировать файрволом, можно блочить тех, кто посылает больше N в T времени, тоже, правда?
видимо про net.ipv4.tcp_syncookies=1 мало кто знает =:)
Подбираете net.ipv4.tcp_max_syn_backlog, в iptables ограничиваете количество syn пакетов с --limit.
фейковые запросы очень быстро залитают в бан к iptables, собственно да в момент атаки есть небольшие трудности с работой обычных пользователей, но достучавшись впервый раз до ifram´а вы в белом листе и syn лимит вам не страшен =)
такой нагрузки небыло… до 30к пакетов было =) а больше как себя поведет нужно пробывать… у вас есть чем попробывать? с удовольствием =)
200к пакетов в секунду вам уже не backlog, а interrupt queue забьют, там уже не важно какие это будут пакеты, против таких DDoS'ов отбиться простым софтварным способом практически нереально
да кто будет гнать на вас по несколько миллионов пакетов в секунду? никто не спорит для большых проэктов обезательно иметь железку с модными наклейками по 40к. Для пар проэктов на wordpress'e что тоже будете тратить от 40к на защиту от DDoS?
Да с такой нагрузкой первое что сделает датацентр выключит нахрен ваш сервер, нафига ему эти пар миллионов пакетов по роутерам… что нибудь дельное лучше бы предложили, чем с мат частью разглогольствовать.
Да с такой нагрузкой первое что сделает датацентр выключит нахрен ваш сервер, нафига ему эти пар миллионов пакетов по роутерам… что нибудь дельное лучше бы предложили, чем с мат частью разглогольствовать.
хм, инетерсный подход! надо обдумать-попробовать
2 запроса в секунлу — мало, у меня Опера их штук 6 делат параллельно, а если на странице много картинко то запросы авообще дождем будут литься!
Я специально сделал в примере конфигурации пояснение:
По моим тестам и отзывам пользователей, было довольно комфортно и с таким ограничением. По крайней мере, даже если были проблемы, то лучше что бы сайт хоть как то работал, чем не работал вообще.
# Данный случай частный лично для моей
# ситуации и подбирается индивидуально.
По моим тестам и отзывам пользователей, было довольно комфортно и с таким ограничением. По крайней мере, даже если были проблемы, то лучше что бы сайт хоть как то работал, чем не работал вообще.
из практики, для реальных сайов с кучей картинкой — 50-60 запросов в секунду надо ставит порог.
а вот если там нет картинок, то и 20 порог реальен…
а вот если там нет картинок, то и 20 порог реальен…
есть предложение на линуксе плохих дядек отправлять в tarpit
oggy
спасибо
а я то думал почему 503
а я то думал почему 503
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Недорогой способ защиты от HTTP-флуда