Comments
Все прекрасно!, но вы лечите симптомы! а не саму проблему — т.е. очистив трафик для нужного клиента вы не находите все хосты и виновника «торжества» (голову). И не содествуете (например оказываете юридическую поддержку пострадавшему с целью допилить управление К заняться реальной работой и найти и наказать виновника).
А так спасибо… каспер вот тоже недавно выстрелил со своим АнтиДосом с антигуманными ценами — только мниторинг 50К рублей в месяц — без очистки трафа
Всё правильно. Задача сервис-провайдера, собственно, предоставить услугу надлежащего качества, т.е. «ваш сайт будет доступен не смотря на атаку». А уж искать или не искать «голову» — это личное дело непосредственно жертвы атаки, провайдер может лишь посодействовать информацией, логами.
Моё мнение (возможно не совпадающее с другими) сервис провайдер должен сам пресекать ДДОС атаки и сам разбираться «кто?» «что?» и «кому?» должен. А клиент даже и не знал что его атаковали или знал в уведомительном порядке типа: «мы тут ддос на ваш сайт отловили вот логи, а вот это зказчик… вы его случаем не знаете? мало ли вдруг вы сами заказали себе ддос.» — вот это реально прекрасная жизнь.
Если копнуть глубже, то существующая схема привлекательнее чем ваша. Поясню мысль — методы противодействия, описанные в статье, требуют вычислительных ресурсов и грамотной поддержки, то есть затратны для клиента при постоянной оплате. Естественно, если за время, когда сервер клиента не доступен из-за DDOS, клиент теряет сравнимое с оплатой анти-DDOS услуг кол-во денег, то выгоднее бороться с проблемой уже после возникновения. Иначе это не рентабельно. В принципе то же самое касается и поиска заказчика атаки — это время и деньги, которые кто-то должен тратить.
Пресекать ДДоС — это ж запросто! Если есть возможность пресечь — какой провайдер откажется? Никто ж специально не будет пропускать ДДоС мимо пальцев.

Администраторы сами забанят пару десятков обнаглевших ip, с которых идёт больше всего запросов. Если уровень атаки выше, чем «навались ребята всем раёном!», то можно забацать банилку по обращениям с таких-то ip средствами htaccess. Можно даже парсить логи и банить ip-адреса, с которых идёт больше всего запросов. Впрочем, этих методов клиент обычно просто не замечает, т.к. они бесплатные.

Ещё можно поставить или пiднастроить дорогую спец.железку. Но серьёзные пацаны нанимают других серьёзных пацанов для предоставления вип-сервиса — «Реальная защита от ДДоС!». Можно даже нанять вместо Апача девушку на телефон, с томным голосом: «индекс точка пэхапэ не найден… перевожу Вас на страницу 404 точка пэхапэ ...»

Но, увы, для организации более-менее масштабного ддоса, когда счёт идёт на тысячи ip-адресов, не нужно ни много знаний, ни много денег. Оборудование для защиты даже от средней силы ддос-атаки будет стоить на 4-5 порядков дороже, чем организация такой атаки. При том 99% клиентов провайдера не подвергнутся такой атаке никогда. Они с радостью заплатят за защиту от возможной ДДоС-атаки?

По поводу «должен разбираться». Провайдеры в РФ не выступают в качестве органов, уполномоченных проводить оперативно-розыскную деятельность. То есть, сам по себе провайдер не может кого-то преследовать и подвергать санкциям, или заниматься расследованием ддос-атаки (за пределами своей компетенции); тем более — не может заниматься установлением заказчика ддос-атаки.

Да, прекрасно было бы, если б всё, что нам хочется, происходило бы само собой. В Вашем случае — всегда можно вписаться в тот самый 1%, которым реально нужна защита от ддос. Вы платите деньги и получаете защиту; в большинстве случаев Вы эту защиту действительно даже не заметите.
>Пресекать ДДоС — это ж запросто! Если есть возможность пресечь — какой >провайдер откажется? Никто ж специально не будет пропускать ДДоС мимо >пальцев.

С точки зрения carrier — DDoS трафик это трафик, который можно побиллить.
Приятный бонус. Бороться? Пчелы против меда!

ну до тех пор пока инфраструктура держит по крайней мере…
Проблема владельца сайта с точки зрения провайдера заключается не в том, что владелец кого-то обидел и его сайт атакуют, а в том, что владелец расстроен плохой работой сайта. Решение проблемы — провайдер делает хоть что-то для того, чтобы владелец не расстраивался — например, лечит симптомы; владелец, как пострадавшая сторона, делает хоть что-то для легитимного преследования виновника. Например, обращается в милицию. Милиция дальше разбирается сама, и нередко вполне успешно, какие такие данные может дать провайдер, чтобы наказать виновника.

Провайдер не может обращаться в правоохранительные органы с заявлением «моего клиента ддос-атакуют! примите меры!». Провайдер по Закону о связи либо предоставляет милиции сведения (какие есть) о нарушении, либо приостанавливает работу ресурса (разумеется, если к тому есть предписание от той же милиции). Какую ещё юридическую поддержку Вы бы хотели от провайдера? Вызов спортсменов на IP-адрес виновника?
а как бороться с http-ddos типа хабраэффекта, а не просто с мусором по сети, забивающим канал?
UFO landed and left these words here
Никогда:
— не плодить лишних сущностей.
— не делать запросов к базе с титульной страницы
— не хранить картинки и другие блобы в MySQL/Postgres
— не держать в качестве фронтенда Apache
— не хранить несколько абсолютно идентичных экземпляров одних и тех-же данных в памяти.
— не получать результаты работы лежащего в соседней директории куска кода запросом по http по loopback через установленый на марсе relay.
… да много чего НЕ_
ибо глупость человеческая поистине бесконечна.

Проще сказать что делать:

1. ЛЕНИТЬСЯ по максимуму (ибо только лень более бесконечна чем глупость)
2. ну и ДУМАТЬ, чтобы лениться было комфортно ;)
я имею ввиду, когда DDOS начинается правильными HTTP запросами — несколько тысяч в минуту… купить сервера — это для сайта со средней посещаемостью в 500 человек в сутки — это, конечно, решение, да…
а вообще заминусовали так, как будто глупость сказал… именно DDOS, а «типа хабраэффекта» — потому что эмулируется нормальное поведение пользователя, причем с тысяч IP — т.е. действовал ботнет.
Берете VDS, сисадмин Вам настраивает сверху nginx, снизу апач. И «несколько тысяч» в минуту совершенно спокойно перевариваются
достаточно подробно и познавательно. по каким критериям идет распознавание трафика DDoS-атаки? какие алгоритмы лежат в основе фильтрации? думаю умную атаку, которая бегает по страницам сайта как пользователь, вычислить проблематично.

также, ждем описание методики автомасштабирования приложений. Спасибо.
Мощность атаки еще и PPS описывается.
К тому же Вы написали о защите от мусорного траффика, на сегодняшний день любая хорошо оттюненная система справиться с 10 гбит поносного траффика.
А вот что делаете с «хитрыми» ботами, которые подставляют браузеры, реферралы, куки принимают и еще и POST дают?
У нас стоит самописная защита от них, но даже в процессе написания системы понимаешь, что кол-во false positive будет высоким.
А такая «хитрая» атака в 20 тыс. IP в несколько потоков разных браузеров уложит множество систем…
Надеюсь Вы понимаете (да вы и сами написали), что для борьбы с «хитрыми ботами» нужно задействовать не только типовые системы защиты от DDoS, но и другие системы, в том числе и самописанные и разной направленности. Как говорится, наличие IPS в сетке, не отменяет необходимости пользоваться антивирусом и устанавливать заплатки. Если вы пользуетесь защитой от DDoS, но у вас на сервере нет соответствующих патчей, то сервер может упасть исключительно из-за уязвимости в системе, на использование которой Anti-DDoS не среагирует.

В Оверсан-Меркурий применяются типовые решения от Cisco, которые поддерживают «допиливание» защиты под конкретную атаку (если система способна бороться с подобной атакой), а при необходимости можем предоставить и многоступенчатую защиту «Passive Defense---Anti-DDoS---Firewall--IPS».
Вот это меня и удивляло в Cisco Guard.
Что делать, если на пакетном уровне все впорядке и легитимно?
Если атака идет по приложению, то можно сниффером попытаться выявить нелегитимные обращения и либо создать Flexible-Filter либо направить трафик на IPS (смотря что будет эффективнее)…
Если же Zombie перезапрашивает разные страницы с веб-сайта (Victim) полностью легитимными запросами (по ХХХ запросов в секунду), то таких Zombie система AGM и сама выявит.
ng_bpf? :D
А вот если 20000 тыс. зомби, с легитимными запросами раз в минуту? :|
Как отличить от проксей?
Как отличить от легитимных юзеров долбящих, например, статистику?
Если ботнет будет в 20000 зомбей, которые будут «пульсировать», то облегчит участь сервера rate-limeter, однако почти за год испытаний системы такие пульсации не проходили через AGM (про технологии различия легитимного и нелегитимного трафика официальный ответ от Cisco TAC был такой, что данная информация из разряда «Confidential»).

Да и это же не секрет, что сервер и сам должен быть готов справляться с повышенными нагрузками? Если у вас проект работает как Интернет-магазин подарков, а сервер расчитан на среднюю нагрузку в 500 пользователей, то 7 марта сервер ляжет безо всякого DDoS-а :)
Для таких случаев предусмотрены всякие виртуализации серверов с Auto-Scaling-ом, которые тоже помогают бороться с повышенными нагрузками в real-time.
Не проще ли дружить с провайдерами, что у вас в аплинках, и бороться их силами — не допускать до себя весь этот мусор?
Вряд ли им будет проще, да и размещать надо, как уже сказано в статье, максимально близко к защищаемым серверам. А на уровне провайдера разгребать много мегабит траффика-задачка та еще, вряд ли пров согласиться такую затею оплачивать.
Упор был на слово дружить :)
Видимо это зависит от мощности атаки… Когда на тебя льются десятки гигабит, играть в неприступный бастиончик — не разумно. Хотя, конечно, бывают разные ситуации…
Аплинки сами останавливают «десятки» гигабит обычно, т.к. это им не выгодно.
Аплинки, обычно, предоставляют полосу, без обрезания, и им это выгодно — больше полоса=больше денег.
Видимо нам повезло с аплинками :D
Но в принципе, когда их железо начинает плавиться от предельных скоростей передач данных на «границах», а циска за пару лимонов баксов нагружается на 5 процентов, аплинки задумываются :)
Дать такой «промышленный» ДДОС (больше 10 гбит) может либо очень крутая частная структура, либо гос. органы, имхо.
Чтобы у нормального провайдера начало «плавиться» железо от нагрузки, нужно купить не один и даже не 2*10Г порта ;)
А с учетом того, что за пару лимонов баксов железо может пропустить через себя сильно больше чем 20Г full duplex, с аплинком вам скорее не повезло.
Чтобы представить DDos больше 10Gb/s, и что для этого нужно — достаточно взглянуть на средний тариф провайдеров домашнего интернета и становится понятно, что это как минимум не очень сложно.
Это все верно только при условии отсутствия на железках таких вещей как QoS, acl и прочий шейпинг.
Иначе железо плавится под гораздо меньшей нагрузкой.
Впрочем, за пару лимонов… Хм… Назовите модель :)
QOS, ACL не сказываются на производительности нормального железа(не говоря уже о железе за пару лимонов баксов).
Что касается шейпинга и прочего обрезания, то во первых тут вопрос как раз стоит в том, что провайдер сам начинает обрезать, а как вы понимаете это доп. нагрузка, при плавящемся то железе — как минимум не очень верный способ его охладить.
И во вторых, для обрезания циска давно уже пропагандирует отдельную железяку под MSE у которой априори с этим проблем нет.
> QOS, ACL не сказываются на производительности нормального железа
Это маркетинговые бредни. Сказывается, да еще как.

> как минимум не очень верный способ его охладить.
Зато это способ охладить атакуемую железку.

А модельку за $2m все-таки любопытно узнать :)
Вы хотите сказать, что «самолет» типа CRS-а, нагружается на 5% когда маршрутизирует DDos(хотя ему безусловно плевать, на DDos это или нет) менее 10Gb/s?
Я же уже писал, ддос менее 10 гбит/с заметить разве что кор2дуо с линуксом в качестве рутера :), а не циска, циска пока на нее ACL не вешаешь будет отрабатывать свой bandwidth ресурс по полной до заявленного.
То есть вы утверждаете, что циска, в нашем примере CRS, когда на него вешаешь ACL, теряет в производительности и «плавиться» при нагрузке более 10Gb/s?
Вы неверно читаете, циска в моем пример будет «плавиться» при нагрузке в 500 терабит и стоит она соответствующе — порядка 50 млн. в полный фарш и врядли потеряет в производительности много от ACL. А вот какая-нибудь непрокачанная 65хх, что стоит на бордергейтах — скорее всего да.
«Cisco claims the CRS-3, which will be available in a few months for prices beginning at $90,000»
имхо, до $2m далековато.
>Это маркетинговые бредни. Сказывается, да еще как.
будет очень любопытно узнать как? например на 65** той же?
>Зато это способ охладить атакуемую железку.
Безусловно, TeliaSonera спит и видит, как бы ей при DDos-e охладить железо клиента Оверсан-Меркурия, нагрузив при этом свое.

> будет очень любопытно узнать как? например на 65** той же?
Про 65xx врать не буду, а вот хваленый Quantum Flow на ASR в разы проседает от ACL, QoS и NAT (пруф.).

> Безусловно, TeliaSonera спит и видит, как бы ей при DDos-e охладить железо клиента Оверсан-Меркурия, нагрузив при этом свое.
Не в курсе взаимоотношений Телии и Оверсана. Но насколько могу судить по своему опыту — аплинки в таких случаях всегда идут навстречу.
Вы действительно наивно-таки полагаете, что домашние провайдеры выдают Вам полностью все мегабиты?
У них выход в мир максимум 10 гбит будет, ну только если это не корбина какая-нибудь, там может быть 1х40 гбит/с или 2х40, врядли больше.
Аплинки в Европе повсеместно имеют довольно узкие каналы, например GlobalCrossing до недавнего времени имел сеть всего в 10 гбит/с по Европе.
Да что уж там говорить, всего каналов между США и остальными континентами по-моему на 400 гигабит.
И Вы хотите сказать, что кто-то позволит вот так вот 10 процентов сетевого траффика хапнуть на 0ки? :)
Ээээ, пардон:
а) это обменник
б) собранные данные со всех свитчей, то есть эта производительность считается примерно как если я на каждом свитче в дц поставлю по ррд и соберу в сумме данные, — это не мера пропускных способностей каналов конкретного оператора, среднего.
У моего провайдера тоже есть доступ в DE-CIX, однако проводок то 10 гбит/с и никак не получиться с него протянут терабиты :).
Я-ж не опровергаю :)
Соски наружу там, действительно, по 10g max. И это крупнейший IX по данным вики.
«Я вам не скажу за всю Одессу», но у КТ проблем не возникало(по поводу скорости).
Посмотрите хотя бы кол-во участников MSK-IX и кол-во трафика продуваемого через него. По прежнему думаете 10Гб/с = 10% сетевого трафика?

При локальном обмене Ваша правда, могут долбануть и завалить бордерный рутер с большей сети, но вопрос решится по телефону и в противном случае законодательство в практически любой стране готово на эти вопросы дать ответы.
А вот когда атака из-за рубежа будет.
Собственно последнее время наблюдаю картину увеличения подключений с обменниками других стран и пропускную способность увеличивают (мой дц очень хорошо расширился, правда защиту поставил хорошую тоже), так что когда 100 гбит/с будут доступны, за 3-5 лет уже будут такие каналы везде — вот тогда начнутся проблемы, хотя возможно к тому времени железо будет способно и 1 тбит/с обработать :) как сейчас способно 10 гбит/с в легкую.
Почему только при локальном, представьте себе, что есть провайдер Х, у которого есть подключение к ОПГ, какова возможность вдуть в него 10GB/s из всего ОПГ в 18:00? 100%. А в 6:00? 1000%!
Из-за рубежа скорость безусловно поменьше, но имея распределенную сеть ботов, это тоже, не проблема.
Я не представляю себе, каким образом DDos на Ваш бордер можно прекратить позвонив аплинку во вменяемые временные рамки? Вы думаете он будет отключать всех пользователей, адреса которых вы ему предоставите в ту же минуту? (если вообще будет отключать)
Заворачивать будете по /32? ;)
Или все префиксы той же КТ? после чего конечно стоит подумать, для какого кол-ва нормальных пользователей стал не доступен ресурс.
Ну простите Вы уже придираетесь, тут вопрос доступен ли вообще ресурс будет :) если атака зальет бордер, то Ваш ресурс будет недоступен.
Вывод — вычленить и завернуть траффик, можно даже по /8.
А дальше уже разбираться, открывать потихоньку, собирать базу «плохих» и писать/звонить.
А как Вы еще хотели?
>Ну простите Вы уже придираетесь, тут вопрос доступен ли вообще ресурс будет :)
Безусловно, можно даже всю динамику порубить, а клиенту отвечать что его ресурс вообще то доступен, НО только с гейтвея и может даже из любой точки AS дата центра. ;)
>если атака зальет бордер, то Ваш >ресурс будет недоступен.
>Вывод — вычленить и завернуть траффик, можно даже по /8.
Простите, но каким образом блэкхол на вашем бордере спасет его от заливания или вернее сказать его линк от переполнения в случае однонаправленного трафика?
>А дальше уже разбираться, открывать потихоньку, собирать базу «плохих» и писать/звонить.
Мне кажется клиент будет не в восторге когда ему тех. сап. ответит на вопрос о недоступности его ресурса(при заворачивании даже одной /8) словами:
«Собираем, пишем, звоним»
Блекхол не только на бордере, но и у апстрима — подобное нужно оговаривать заранее и делать либо как по статье outoforder, либо вручную.
Можно ответит: «на Вас ведется расширенная атака, (защита от подобных атак не входит в условия нашего договора,: прим. это вписать если клиент неадекват, жмот, злобный бегемот) однако наши администраторы сделают все возможное для предотвращение этой атаки. Ждите, пожалуйста»

Хотя в итоге все равно, чем шире у Вас канал тем лучше, даешь 100 гбит, 40 гбит была самой большой атакой по статистике Arbour
Размещать близко к серверам нужно детекторы. А Guard должен стоять, по возможности, как можно дальше, чтоб фильтрануть уж точно до последней мили к клиенту.
>чтоб фильтрануть уж точно до последней мили к клиенту.
скорее чтобы не нагружать каналы внутри сети паразитным трафиком.
Спасибо за статью!
Очень интересно было почитать как это все таки устроено для такого большого потока трафика, все таки такие нагрузки нам в провинции и не снились.
И идея удаленной защиты понравилась. А есть ли какие то ограничения по нагруженности защищаемого сервиса для этой услуги?
«Мы работаем с DDoS-атаками несколькими способами и предоставляем их в качестве услуг собственным клиентам.»

У меня закрадываются подозрения.
Мы работаем с DDoS-атаками несколькими способами и предоставляем их в качестве услуг собственным клиентам.

Вы уверены что сказали именно то, что хотели сказать? :-)
меня тоже поразила эта фраза, вероятно кто-то имел ввиду защиты от ддос
А зачем именно ipsec? Мало того что железка дорого стоить будет, жрать ресурсы, так еще не очень понятно — зачем там шифрование? Запросы от пользователей до вашего оборудования явно без криптографии добрались.
UFO landed and left these words here
Иногда GRE съедает гораздо больше ресурсов, чем IPSec. Вы не пробовали гонять 10 гигабит по 10 GRE — туннелям между 65хх? Железо проседает очень неплохо, несмотря на наличие DFC и MPLS…
А вы пробовали гонять 10G IPSEC? -))
И что значит «несмотря на наличие DFC и MPLS… »?
Какая связь между GRE и MPLS?
>Какая связь между GRE и MPLS?
имелось ввиду, что маршрутизация не дергает лишний раз RP, а «все» ресурсы направлены на GRE.
а почему никто не вспоминает про L7? есть же и железки и тот же Netfilter поддерживает L7-filtration.
да навалом таких железок. Только это уже мало имеет отношения к DDoS, L7 фильтрами массированную атаку не остановить, быстро сдуется фильтр (если вообще заметит тупой syn-flood). Эти штуки рассчитаны на хитрые, точечные атаки, всяческие инъекции, эксплойты, XSS и т.п. Ставят их вторым эшелоном после системы защиты от DDoS.
В Оверсан-Меркурий L7-защита выполняется на IPS, который стоит действительно третьим (!) эшелоном.
первым гард/детектор, третьим IPS, а вторым файервол? Или что выступает в роли второго?
схемку набросайте, если не трудно, интересно посмотреть. Типа
   аплинк
     |
   граничные шлюзы
     |
   FW1
     |
   детектор/гард
     |
   FW2
     |
   IPS
     |
   Server Farm
Passive Defense это всевозможные превентивные меры по отбрасыванию заведомо-ложных пакетов (Anti-Spoofing и т.п.)
L2 Security позволяет локализовать успешную атаку и не дать ей распространиться(как минимум затруднить распространение) по всем серверам сегмента, если клиент размещает в ДЦ целую подсеть с серверами. Это технологии защиты от всевозможных подмен (spoofing), переполнений (overflow) и разграничение доступа (access control) внутри сегмента клиента.
ммм, циско гард замечательно распознает спуфинг. Так что именно (железки/технологии/протоколы/политики/etc.) стоит за Passive Defence и L2 Security?
Или это просто маркетинговые слова для клиентов?
И, кстати, уже внутри серверного сегмента зачем применять антиспуфинг? От нехороших соседей? По мне так виланами проще уж тогда разделять клиентов, нет?
да… не замечательно, но распознает… но зачем тянуть проспуфленный пакет до гарда, если я могу его отбросить на бордере?

Это не маркетинговые слова… Здесь и списки доступа, и проверка на правильность маршрутизации (ip verify) и виртуальные маршрутизаторы…

Что касается L2 и защиты в сегменте, то спуфинг бывает не только по IP, но и по MAC и по ARP…
По VLAN мы обязательно разделяем клиентов, но иногда этого не достаточно… применяются Port-Security, MAC — фильтры, ARP-фильтры, приватные VLAN и многое другое… В сегменте достаточно начать дергать STP и сегмент ляжет — от этого тоже надо защищаться… Средств много и всего не расскажешь :)
могу его отбросить на бордере
можно и на бордере, действительно, если железка позволяет.
Что касается L2 и защиты в сегменте, то спуфинг бывает не только по IP, но и по MAC и по ARP…
Разорвало. На L2 не бывает ip. Ну и ARP и MAC — это, вообще-то, одно и то же. Как раз таки единственно возможный спуфинг на L2 — это arp-спуфинг.
В сегменте достаточно начать дергать STP
Бесстрашные вы ребята. Мы от STP отказались много лет назад, всё на 3-м уровне.
Ага… на L2 не бывает IP… Но я вам не OSI модель рассказываю, а про L2 сегмент, где спуфить можно и по IP и по ARP и по МАС… А вот путать ARP и МАС лучше не нужно… Это и слова разные и спуфинги… Если вам на access — коммутаторе забьют САМ таблицу нелегитимными МАС — адресами с хакнутого сервера, то весь остальной трафик сегмента будет доступен атакующему…

А насчет бесстрашности, то при правильном использовании STP совсем не страшен :) Как альтернативу сквозному VLAN (который обуславливает использование STP) можно использовать L2VPN или VPLS, но нам это бенефитов на данный момент не дает.
«L2 сегмент», я так понимаю, это ваша внутренняя терминология, название конкретного сегмента, под L2 в целом принято понимать «канальный уровень», что в случае с ethernet обозначает сопоставление MAC-IP, чем и занимается протокол ARP.
ОК, просветите, чем arp-спуфинг от mac-спуфинга отличается? ARP — это протокол, который оперирует MAC-адресами (таблицами соответствия MAC-IP), термин mac-спуфинг я слышу впервые. )
Ладно, уже оффтоп.
А STP не страшен, он, ммм, ущербен. Как говорится, L3 рулит.
Ну если вы раньше никогда не слышали выражение L2-сегмент, то извините, что я так выразился… видимо это совершенно непонятная фраза для настоящих ITшников и обещаю, что впредь буду выражаться предельно ясно…

Про МАС-спуфинг надо было читать в предыдущем посте… или снова непонятно?

А про ущербность STP: Я прошу у вас совета как при помощи L3 топологии мне соединить единым бродкастовым (если непонятно — «широковещательным») доменом две стойки в разных рядах ДЦ, если требование клиента, занимающего эти две стойки звучит как «сервера должны быть в одной подсети»?
Буду очень признателен, если расскажете как это сделать максимально просто и надежно.
Коллега, я слышу звуки капающего яда с ваших уст. Ни к чему это, спокойнее.
Про мак непонятно, да. Где, собственно, различие?
Теперь по broadcast. Если таких клиентов у вас действительно много, то stp вам подходит, да. Если это полторы штуки в год таких, то можно и vlan протянуть в качестве исключения.
Яд слизнул :)
Про МАС. ARP — спуфинг отравляет кэш соседей по VLAN-у, за счет ответов своим МАС-ом на запросы вышеуказанных соседей. В результате все в сегменте начинают общаться через хакнутый сервер и возникает обычный man-in-the-middle, не говоря уже про проседание производительности в сегменте. Защититься от этого можно обычными статик-ARP-ами или ARP-ACL и атака не пройдет. Спуфинг по МАС-ам нацелен на отравление САМ-таблицы коммутатора ( иногда с переполнением). Это делается при помощи:
1. Создания тысяч фреймов с разными (например рандомными) МАС-адресами, которые исчерпывают емкость САМ — таблицы коммутатора и тот начинает рассылать Unicast — фреймы на все порты (и атакующий слышит весь сегмент)
2. Постоянная отправка фреймов с МАС-адресом жертвы с целью создать привязку в данного МАС (в САМ коммутатора) со своим портом. Результат — все фреймы жертвы поступают на хакнутый сервер.

По stp. Даже если клиент такой один, то пробрасывать VLAN между стойками все равно придется, а поскольку требуется отказоустойчивость, то тянем бэкап-каналы, получаем петли и разрываем при помощи stp.
Под ARP-спуфингом обычно имеют в виду ARP-poisoning, который вы и описали двумя способами (нулевым и вторым). Первым пунктом вы описали частный случай дос-атаки с применением ARP.
А вот MAC-спуфинг, это ничто иное, как простая смена собственного мак-адреса на чужой. Ладно, это всё проблемы терминологии.
А по поводу stp — как правило, стараются построить сеть так, чтобы минимизировать количество деревьев, а лучше и вовсе без них обойтись. Нам проще, у нас между нашими ДЦ собственные оптические каналы, непосредственно в шеститонники транком и идут, любые виланы пихай — не хочу.
Описанная первым пунктом атака выполняется любыми фреймами, и ARP тут совсем не обязателен.
Вторая описанная атака тоже не требует использования ARP.
Насчет ARP-poisoning согласен… так чаще всего и называют… Просто poisoning — следствие spoofing-а.
Коллеги, я тут в ваш спор встряну чутка-)
Кроме l2vpn и vpls, с которыми все понятно (l2 поверх l3), у той же циски есть еще VSS, который решает ту же проблему спанинга L2-доменов еще более простым способом. О его реализации не задумывались? Выгоды по сравнению с STP вполне очевидные.
Для создания связки VSS необходимо железо, которое на момент создания ДЦ еще не продавалось.
Но решение действительно интересное и возможно в дальнейшем оно будет реализовано.
Три момента:
1. У Cisco на данный момент просто НЕТ Адекватного продукта по данной тематике. Как-следствие Guard как appliance снята с производства и существует только модулем к 65xx. Сама Cisco инвестирует в Arbor.

2. Нарисованый на картинке IPS это вообще про другое. (http://cisco.com) и сам будет СЛАБЫМ звеном при грамотно раскрученной атаке.

3. Терминация IPSEC сказачно красиво расписанная на практике заканчивается: разглашением банковской тайны и всеми мыслимыми и немыслимыми чекистскими лицензиями на шифрование и защиту данных. А ну как Вы узнаете что Ваш банк разглашает ваши транзакции Третьей Стороне? Все-же доверяют Компании Оверсан — Империи Света? %)

N.B. Не анонс, но приглашение: Четверг, 24 Июля 2010. 18:00 ВМиК МГУ состоиться небольшой открытый семинарчик по теме «Уязвимости в TCP/IP: обнаружение и противодействие»
Желающие присоединиться — пишите в личку. К сожалению не могу гарантировать участие всем, но приложу максимум усилий.
> 2. Нарисованый на картинке IPS это вообще про другое. (http://cisco.com) и сам будет СЛАБЫМ звеном при грамотно раскрученной атаке.

Да он вообще не включен ;)
UFO landed and left these words here
UFO landed and left these words here
Сама Cisco закончила инвестировать в Arbor года 4 назад, после того как они поссорились. Хотя в некоторых старых материалах Cisco еще можно найти схемы с оборудованием Arbor.
посмотрите Cisco Clean pipes версии 1 и 2

во второй версии от Cisco там только протокол NetFlow
устройство обнаружения — Arbor Peakflow CP, устройство очистки трафика — Arbor Peakflow TMS

Cisco Guard ушел в end of sale
Никогда не имел дела с dDOS, однако есть некоторый опыт оптимизации производительности…
Есть мысль по поводу зараженных компьютеров (членов ботнета):
Важно понять действительно ли это браузер или какая-то программа, которая выдает себя за браузер. Софт находящийся на зараженном компьютере вполне может себя вести примерно как живой человек…
Вкидываем в страничку нетривиальный js и ожидает, что клиент вернет результат в очередном GET или POST или ajax запросом… Помещаем на страничку flash, который что-то там высчитывает и возвращает нам результат.
Если что-то идет не так, то ip хулигана передается наружу и в течении минут 20-ти он вообще не принимается к рассмотрению.
Реализация исполнения js или flash — слишком серьезная задача для дДОСеров (я как бы понимаю, что все можно написать если задаться целью).
хе, надо обрубать такие запросы вообще через ядро (iptables т.е.) — чтобы они вообще не доходили до http сервера. Самый популярный ddos — «тупой» — просто тупо по http ломятся и тыкают на линки. Причём часто лезут на главную и тянут ответ, а потом уже все линки тычят в разнобой но не сливают результат. DDOS же «заказной» — когда пишутся специальные сценарии имитирующие пользователей на таком-то конкретном сайте — редкость, но и уж куда сложнее их отсекать.

Но все равно можно траф анализировать. Если «вдруг» куча «пользователей» из Китая появилась — отрубить весь Китай к чертям) И тп
Тоже способ, а за Китаем, еще полмира, чем окажете неимоверную помощь атакующему, который добился, что ваш ресурс не доступен.
Ну по вашей методике:
Началась атака с Китая — отрубили Китай, с Японии — отрубили Японию и т.д. Через сутки, например, сервис доступен только из России = для неудачников из Китая, ddos удался — ресурс для них не доступен. Это одна сторона вопроса, вторая:
Думаю все понимают трудоемкость фильтрации хотя бы 5к ботов из разных сетей методом написания правил для iptables по /32 ручками.
Вы сами придумали мою «методику», я вообще ничего не сказал)

1) лучше дать доступ к сайту 50% пользователям, чем закрыть всем (ну или обречь на тонну False Positive)
2) руками в iptables засовывать — ну что за глупости, блин
3) iptables в любом случае должен учавствовать в процессе — это гораздо эффективнее пресловутого htaccess

Вообще в ситуации когда траф вроде нормальный, ресурсов не хватает, сервер почти стоит — что делать? Если при этом видно что 90% трафа идёт с Китая — отрубить его целиком, временно — пожалуй, лучший вариант. Понятно что лучше до такого не доводить, но теоретически любой анализатор трафика можно обмануть.
>Вы сами придумали мою «методику», я вообще ничего не сказал)
ну как же: «хе, надо обрубать такие запросы вообще через ядро (iptables т.е.) — чтобы они вообще не доходили до http сервера». Прям руководство к действию.
>2) руками в iptables засовывать — ну что за глупости, блин
безусловно — глупости! но надеюсь вы расскажите, каким автоматизированным способом можно это сделать не подготовленному к DDos админу, администрирующему сайт скорее всего удаленно, и не обладающему хорошими навыками в написании всевозможных скриптов, за вменяемое время.
>Если при этом видно что 90% трафа идёт с Китая — отрубить его целиком, временно — пожалуй, лучший вариант.
Расскажите, пожалуйста, методику определения границ IP сети Китая, так чтобы его можно было отключить целиком? ;)
да я что какую то статью что ли писал? Я написал своё мнение — не умеешь писать скрипты — это твоя личная проблема. Да и не в скриптах дело

> Расскажите, пожалуйста, методику определения границ IP сети Китая, так чтобы его можно было отключить целиком? ;)
ну здрассьте, приехали. GeoIP базы для кого?
Я понял что вы предлагаете, прописал правило:
deny made in china
чувствую как поперла защита :)

>ну здрассьте, приехали. GeoIP базы для кого?
пробовали по подобным базам отключить весь Китай? результат удовлетворил?
JS уже научились.
В наше время боты не пишутся, под линуксовыми впсками пускаются браузеры с флешом и чем угодно, и бродят туда-сюда через автоматизацию в shell скриптах.
ДДоС-боты больно умные нынче, браузерами ходят. Вот недавно один из серваков, которые я админю, валили нехило, rl сразу загнулся :) В стаминусе, куда быстренько свалил, за пару попыток порезали в принципе неплохо, но смотреть на постоянную полочку в сотку мне за пару дней надело. Поставил на главную ссылочку вида <noindex><a rel=noindex,nofollow href=please-block-me-with-pf style=display:none&gt… — оказалось эффективнее всего. ;)
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.