Comments 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 сохранять научились.
UFO just landed and posted this here
Когда как, на самом деле
Канал забить, особенно хороший, нужен нормальный такой ботнет. Например, серверный :-) Чаще на каком-нибудь хилом хостинге тупо тормозит или падает сервак.
Сейчас пожалуй не сколько канал ( учитывая сейчашнюю их ширину), а подвесить сайт забив всё процессорное время нагрузив по максимуму серверный софт
Бывают и такие атаки, которые именно канал забивают. Например, мощные сервера стоят, балансировка, циски — тут проще нанять большой ботнет и забить канал.
Совершенно верно. При сегодняшних возможностях магистральных каналов, узким местом на мой взгляд является серверный софт, вернее даже не серверный, а клиентский.
Когда нас досили, то до забивки канала было ещё очень далеко, софтом дос распознавался и резался тоже довольно хорошо, а вот всякие буфера ОС и лимиты числа сетевых соединений кончались довольно быстро. И машика падала…
В большинстве 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 сетов и небольшой баш скрипт проверки прежде чем добавлять… и все было ок
интересный топик, причем интересный поднятой темой и обсуждением. + в ..(ну вы поняли куда)… однозначно.
UFO just landed and posted this here
Испорченный IP так же просто определяется как и подделывается, а далее кто мешает запретить принимать пакеты от таких IP ? Antispoof — фильтры есть практически в каждом нормальном фаерволе, я не говорю про серьезные «железные» решения.
Или я ошибаюсь?
Или я ошибаюсь?
Обычно досеры детей не обижают таким флудом
UFO just landed and posted this here
SYN-flood очень легко и непринужденно обрезается включением SYN-cookies.
DDoS атаки режим ооочень просто. Главное выявить ip реального пользователя от бота. Как? очень просто. На примере: висит програмулька, мониторит нагрузку канала. Возрастает до 80% загрузка канала, активируем panicMode, на всех сайтах автоматом догружается скрытый iframe. Боты не используют бровзер, соотвественно этот скрытый iframe не видят, а реальный клиеты грузят. IP реальных клиентов поподают в белый список(через запрос этого iframe, все остальный в бан на iptables.
Нагрузка канала спадает до 70% iptables сбрасывается, panicMode выключается и всё ок.
SYN атаки нормально настроенной системой режутся в разы.
Нагрузка канала спадает до 70% iptables сбрасывается, panicMode выключается и всё ок.
SYN атаки нормально настроенной системой режутся в разы.
UFO just landed and posted this here
Уважаемый, очередь пакетов? или вы о чём? растолкуйте пожалуйста.
Про syncookies вам не рассказали, да ведь?
Про то, что число и периодичность SYN можно лимитировать файрволом, можно блочить тех, кто посылает больше N в T времени, тоже, правда?
Про то, что число и периодичность SYN можно лимитировать файрволом, можно блочить тех, кто посылает больше N в T времени, тоже, правда?
видимо про net.ipv4.tcp_syncookies=1 мало кто знает =:)
UFO just landed and posted this here
Подбираете net.ipv4.tcp_max_syn_backlog, в iptables ограничиваете количество syn пакетов с --limit.
UFO just landed and posted this here
фейковые запросы очень быстро залитают в бан к iptables, собственно да в момент атаки есть небольшие трудности с работой обычных пользователей, но достучавшись впервый раз до ifram´а вы в белом листе и syn лимит вам не страшен =)
UFO just landed and posted this here
такой нагрузки небыло… до 30к пакетов было =) а больше как себя поведет нужно пробывать… у вас есть чем попробывать? с удовольствием =)
200к пакетов в секунду вам уже не backlog, а interrupt queue забьют, там уже не важно какие это будут пакеты, против таких DDoS'ов отбиться простым софтварным способом практически нереально
UFO just landed and posted this here
да кто будет гнать на вас по несколько миллионов пакетов в секунду? никто не спорит для большых проэктов обезательно иметь железку с модными наклейками по 40к. Для пар проэктов на wordpress'e что тоже будете тратить от 40к на защиту от DDoS?
Да с такой нагрузкой первое что сделает датацентр выключит нахрен ваш сервер, нафига ему эти пар миллионов пакетов по роутерам… что нибудь дельное лучше бы предложили, чем с мат частью разглогольствовать.
Да с такой нагрузкой первое что сделает датацентр выключит нахрен ваш сервер, нафига ему эти пар миллионов пакетов по роутерам… что нибудь дельное лучше бы предложили, чем с мат частью разглогольствовать.
хм, инетерсный подход! надо обдумать-попробовать
2 запроса в секунлу — мало, у меня Опера их штук 6 делат параллельно, а если на странице много картинко то запросы авообще дождем будут литься!
Я специально сделал в примере конфигурации пояснение:
По моим тестам и отзывам пользователей, было довольно комфортно и с таким ограничением. По крайней мере, даже если были проблемы, то лучше что бы сайт хоть как то работал, чем не работал вообще.
# Данный случай частный лично для моей
# ситуации и подбирается индивидуально.
По моим тестам и отзывам пользователей, было довольно комфортно и с таким ограничением. По крайней мере, даже если были проблемы, то лучше что бы сайт хоть как то работал, чем не работал вообще.
из практики, для реальных сайов с кучей картинкой — 50-60 запросов в секунду надо ставит порог.
а вот если там нет картинок, то и 20 порог реальен…
а вот если там нет картинок, то и 20 порог реальен…
UFO just landed and posted this here
UFO just landed and posted this here
есть предложение на линуксе плохих дядек отправлять в tarpit
UFO just landed and posted this here
oggy
спасибо
а я то думал почему 503
а я то думал почему 503
Sign up to leave a comment.
Недорогой способ защиты от HTTP-флуда