DoS & DDoS

[gul_tech]

Все привыкли к тому, что время от времени случаются DoS и DDoS-атаки. Что с ними делать?
Владельцы ресурсов и админы корпоративных сетей пытаются защитить себя сами. Всякие IDS, IPS, PIX, ASA, Netscreen и много других умных слов. Этот подход логичен, но имеет очевидный недостаток: если атака уложила border router или забила канал к провайдеру, находящиеся внутри средства обнаружения и предотвращения атак бесполезны, нужно содействие ISP.
Что же делать ISP, как защитить клиентов? Ведь его задача - передавать IP-трафик максимально качественно (надёжно, быстро и без потерь), фильтрация в его функции не входит. На объёмах трафика ISP фильтрация (IPS) будет стоить неразумно, клиентам попросту не нужен такой сервис за такие деньги. Да и настройка фильтров - процесс трудоёмкий и индивидуальный, у каждого клиента свои потребности и особенности.
Реакция ISP нужна только тогда, когда атака уложила либо канал, либо border router клиента. Иначе клиент имеет возможность отфильтровать самостоятельно, и перекладывать эту функцию на ISP смысла нет. Автоматическая фильтрация на стороне ISP может быть и вредна. Например, трафик вполне легитимной видеоконференции может быть ошибочно расценен как DoS (большой поток UDP) и отфильтрован, что, очевидно, не вызовет благодарности клиента.

Одно из разумных и распространённых решений - BGP blackhole (rfc3882). Оно позволяет клиенту самостоятельно отфильтровать трафик на атакуемый IP у апстрима, проаннонсировав его как /32 с заранее оговорённым community. Даже если у клиента от атаки упал router, BGP-анонсирование атакуемой сети прекратилось, трафика нет, BGP может опять подниматься, но уже с blackhole-анонсом атакуемого хоста. Если клиент успел определить, какой хост атакуют. Недостатком является то, что это грубая фильтрация, блокируется весь трафик на указанный IP-адрес, независимо от source, protocol и т.п. Атакуемый хост приносится в жертву ради того, чтобы не страдали другие. Достоинством - то, что не нужно содействие персонала апстрима.

В итоге получается, что ISP не должен автоматически фильтровать DoS-атаки на клиентов, но должен иметь информацию об атаках как на своих клиентов, так и от них (ботнеты) с тем, чтобы иметь возможность при необходимости (если атака полностью уложила клиента или по просьбе клиента) быстро отфильтровать атаку, даже если клиент не знает, откуда и куда она идёт. Поскольку атака часто приводит к прерыванию сервиса (собственно, в этом её цель), информацию желательно иметь побыстрее и максимально подробную (какой вид атаки, интенсивность, что за клиент, как себя чувствуют его роутеры и т.п.) с тем, чтобы принимать решение (отфильтровать и сообщить клиенту; не отфильтровывать и сообщить клиенту; игнорировать). При этом для ISP имеют значения только грубые атаки (pps, cps), а контентный анализ (вирусы, хакерская активность, даже syn flood) - это то, с чем клиент может бороться самостоятельно. По этой схеме мы и работаем уже не первый год, нам нравится, клиентам, вроде бы, тоже. :-)

Более подробно о реализации.
На внешних линках снимается sampled netflow. Как показывает практика, rate 8192 вполне достаточно для обнаружения атак. Этот flow сохраняется на некоторое время (пара часов, не больше) через flow-tools, кроме того, идёт на обработку специальному демону dds (самописному), который и занимается обнаружением атак. В случае появления аномальной активности (например, от хоста x.x.x.x на клиентский хост y.y.y.y обнаружен поток udp с 40 Kpps) запускается скрипт, который включает alarm на мониторилке для дежурной смены, а также пишет письмо, в котором:
- информация об атакуемом хосте (какой AS и какому клиенту он относится);
- как в данный момент выглядит mtr на этот хост (насколько живы роутеры по пути и сам атакуемый хост);
- листинг относящегося к этой аномалии трафика за последние 5 минут, из сохранённого в flow-tools.
Этой информации достаточно для того, чтобы человек мог без лишних задержек и исследований принять решение, что делать. Из листинга flow видно, с каких и на какие порты идёт трафик, насколько он похож на легитимный. Из mtr - насколько клиент страдает от этой атаки. Технически можно было бы при некоторых условиях и автоматически фильтровать атаки, но лично мне страшновато автоматизировать подобные действия, к тому же, на стороне ISP.
Демон dds можно получить командой "cvs -d :pserver:cvs@happy.kiev.ua:/cvs co dds". При обработке ~20G трафика с sampled rate 8192 он отжирает ~30M памяти и ~0.2% cpu load.

Btw, мне давно интересно, как люди борятся с DoS-атаками без dds? Если есть атака, роутеру поплохело - как выясняют, какой хост атакуется и с какого источника? Есть какие-то аналогичные утилиты?

Comments

[cae32.livejournal.com]

Применяли arbor+cisco guard. arbor, понятно, следил и слал алармы. Так же, конечно, по sampled. cisco guard по команде принимал поток клиента и фильтровал ddos. Полуавтомат, но можно было довести и до автомата, не знаю доделали ли, я перешёл в другую фирму. Решение, конечно, жутко дорогое, лавка могла себе позволить тогда. Но рабочее вполне, полезный трафик на хост сохранялся, что добавляло бонуса лавке в мозгу клиента.

[gul-kiev.livejournal.com]

"Лавка могла себе позволить" - одно, но вопрос, как это окупалось? То есть, был ли это бесплатный бонус, склоняющий клиентов в вашу сторону и за счёт этого приносящий прибыль путём роста продаж (в ряду с looking glass, системой bgp community, ньюсами и пр.), или это был отдельно продаваемый сервис для клиентов, которые его заказали за дополнительные деньги?

[cae32.livejournal.com]

По факту никак не окупалось.
То есть, конечно, маркетологи расписали бизнес-план с кучей бонусов и ростом продаж, и там даже был выход в ноль. План был, конечно, бесплатного бонуса в Вашей терминологии. Потому что за дополнительные деньги клиент не был готов это покупать. Причины понятны - больше всех при dos/ddos страдает рядовой юзер, сидящий за клиентом-агрегатором, а в больших лавках типа наших МРК или вашего Укртелекома - кто смотрит на его мнение, если честно? ;) Мелкий же клиент и рад бы своему юзеру помочь, потому как бегает за ним, да не может себе позволить заплатить лишний бакс. И так уже маржа выжата досуха. Потому - бесплатный бонус. Но потом начались "пертурбации с собственностями на рынке слияний и поглощений" и всем стало не до окупаемости ;-) Так что по факту внедрили и работает. Окупаемость уже никого не волнует. Вон, в Ростелекоме слили сотни тонн зелени за биллинг, который так и не внедрили (лаба не в счёт) - списали спокойно, даже не сопротивлялся никто. Россия. Нефтяное бабло. Я так думаю ;-)

Так что, на мой скромный взгляд, рынок подобного рода систем в России - почти пуст. Скриптами и своими анализаторами обойтись куда дешевле.

[cdplayer.livejournal.com]

Присоединюсь к рекомендации решения от Arbor. Они решение делают давно, и своё дело знают. Мы предлагаем DDoS protection клиентам, готорвым за него платить - в основном это on-line betting.

[gul-kiev.livejournal.com]

Фильтрация DDoS на клиентов делается автоматически или вручную?
Наверное, в случае, если клиент явно эту услугу, и структура его трафика известна, можно и автоматически фильтровать, да?
Сколько стоит такое решение от Arbor?

[cdplayer.livejournal.com]

Там стоят два продукта - детектор и скраббер (это не мой продукт, поэтому уж извините - я "на пальцах" буду объяснять). Детектор включён перманентно - как я понимаю, он смотрит на flow records (т.е. через него траффик не идёт) и следит за аномалиями поведения траффика. При возникновении аномалии (значительное отклонение от исторического поведения траффика - уровня или его состава) поднимает аларм. По аларму суппорт звонит клиенту, который либо даёт отмашку "зарядить через скраббер", либо говорит "не волнуйтесь, чуваки, всё в порядке". Скраббер, на который "ручками" (policy routing или bgp) перенаправляется весь траффик клиента при необходимости его очистки, пользуется attack fingerprint-ами, которые постоянно обновляются Арбором, для отличения "хорошего" траффика от "плохого", и роняет плохой, но пропускает хороший. Процедура "перенаправления", я так понимаю, полуавтоматическая - т.е. приготовленные куски конфигурации, которые малоквалифицированный чел из суппорта активирует.

Цифры, которые я слышал - в районе 80К USD за решение, способное фильтровать несколько сотен мег (если не ошибаюсь). Это, по-моему, за скраббер. Анализатор ещё какие-то деньги стоит, сколько - сналёту не скажу.

Вообще я про Арбор давно знаю - они ошивались с самого зарождения nsp-sec, но сам лично с их устройствами не работал (и наверное уже и не буду - проехал мимо). :)

[cae32.livejournal.com]

Крайне интересно, есть ли живые клиенты, готовые платить? Размера МРК или похожие. И на какой процент повышается МСС у такого клиента? Или берёте просто по факту использования?

[cdplayer.livejournal.com]

Я не знаю, кто такие МРК. Наше решение было куплено под клиента, которые был готов платить, по-моему ~35-40% premium сверху стандартной цены на интернет. Они реально теряют реальные бабки, если их сайт не виден их клиентам (ставки на скачки или что-то навроде).

[gul-kiev.livejournal.com]

Тут мне немного странно.
Если защита заключается в фильтрации DoS-атак на хост при их обнаружении, то почему бы заранее на стороне провайдера не отфильтровать весь трафик на этот сайт, кроме tcp/80 (ну и что ему ещё надо)?
Если же DDoS идёт не на хост, а на целевой сервис, т.е. на этот самый tcp/80, то как тут анализ sampled netflow может помочь для создания фильтров против такого DDoS? И даже если завернуть такой трафик через скраббер (IPS), который делает сигнатурный анализ всего проходящего трафика - не верится мне, что он на самом деле защитат от DDoS на tcp/80 или tcp/443, отфильтровав вредные пакеты и оставив полезные запросы. В моём представлении IPS полезен для защиты пользователей от вирусов, а не сайтов от DDoS-атак.
Цена у Арбор больше, чем cisco fwsm к 6500 при подобной производительности. Может, он действительно какие-то чудеса делает?..

[cdplayer.livejournal.com]

http://www.arbornetworks.com/en/threat-management-system.html , кусок про Protection. Больше, увы, сказать не могу. Знаю только их репутацию.

Цыцка, как всегда, любой бочке затычка. И, как всегда, half-assed.

[visir.livejournal.com]

Вы про Arbor PeakFlow или Arbor TMS ?

Аналога PeakFlow у циски вроде просто нет.
Как уже сказали, это всего лишь софт. Он анализирует netflow данные и может найти атаки, которые можно выявить по заголовкам пакетов (например syn-флад можно определить по tcp-флагам, которые передаются ему посредством netflow). Для таких атак он может генерировать подходящий access-list, может и сам залить его на раутер (в том числе есть режим с предварительным подтверждением каждого действия человеком).
Еще он находит аномалии - резкие скачки какого-то типа трафика или же превышения заданных вручную порогов.
Все это требует тонкой настройки этой системы. В принципе, на мой взгляд настроить ее не на много проще, чем написать обвязку к flow-tools делающую все что конкретно вам нужно :-) Отличие получится в том, что flow-tools будет все это делать в offline-режиме, а в Арборе все в онлайне - каждая netflow-запись анализируется сразу при поступлении, сырые данные даже не сохраняются на диск. Плюс он обогащает данные netflow информацией из BGP, актуальной именно в момент получения netflow-пакетика. В качестве внутренней базы данных в арборе используется PostgreSQL. Даже просто для анализа структуры трафика, объемов по разным направлениям он не плох, но стоит неадекватно много. Решение ориентировано на тех, кто по каким-то причинам (бюрократическим например, да или просто желает обогатиться на откатах) не может нанять парочку программеров, но при этом готов потратить миллионы на покупку такой системы...

Что касается Arbor TMS - это конкурент Cisco Guard, а не FWSM. Оба продукта (TMS и Guard) схожи, но считается, что Guard - это продукт предыдущего поколения, по моим данным в начале следующего года он будет end-of-sale (это не официальная/точная информация, а всего лишь слухи). А делают они вот что: фильтруют/анализируют трафик на уровне содержимого пакетов, то есть деают все то, что нельзя сделать с помощью access-list-ов. Оба поддерживают всего три протокола: http, dns и... не помню еще какой. Arbor Peakflow может автоматически направлять подозрительный трафик (например резко выросший http-трафик) в эту систему с помощью bgp-анонса с nexthop-ом очищалки (+no-advertise, сам клиент должен быть подключен к другому раутеру) или сгенерировать и залить конфиг для полиси-раутинга. Но делать это автоматически они крайне не рекомендуют - очень высока вероятность ложных срабатываний и фильтрации лигитимного трафика. Они рекомендуют руководствоваться следующим принципом: активировать очищалку только при атаке, которая напрочь кладет http/dns-сервак (с помощью этих самых протоколов), чтоб попытаться очистить трафик так, чтобы хоть какая-то, пусть и небольшая, часть юзеров (но точно не все) попала на сайт.
Для объемов порядка 10G эти решения стоят миллионы долларов... Желающие купить очищенный трафик есть, платить много они тоже готовы, но их очень мало - штучные экземпляры.

PS: в любом случае с DDoS-ами борются люди, а железки им лишь помогают, не более того.

[orao.livejournal.com]

Часто ддосят всяких брокеров биржевой торговли, а эти, полагаю, захотят.

[visir.livejournal.com]

Есть еще обратная проблема, проявляющаяся у операторов ШПД.
Частенько в пятницу вечером существенная часть юзеров начинает слать в сторону определенного IP-а столько трафика, сколько влазит в их каналы. Это может перегружать сами роутеры (если они софтварные), каналы в сети доступа и в сторону аплинка, и даже биллинг, если он обсчитывает нетфлоу... Найти кого именно DDoS-ят в этот раз довольно просто - слишком уж много трафика в его сторону идет. Я обычно всегда блэкхолил жертву как можно ближе к абонентам, ибо всеравно он уже был недоступен из-за трафика со всех концов интернета...

Но по сути блэкхол означает, что атака удалась...

DNS-рекурсор - это тоже очень слабое место сетей ШПД, всего пара юзеров могут его полностью положить.

[gul-kiev.livejournal.com]

IMHO юзеров, замеченных в участии в ботнетах или в рассылке вирусов, надо блокировать, пока не вылечатся. А не жертву блэкхолить. Если не реагировать на ботнеты, вполне может оказаться, что какие-нибудь крупные операторы типа Cogent откажутся принимать анонс блока из-за всяческих blacklists.
Насчёт блэкхола - да, я и написал про него: "Атакуемый хост приносится в жертву ради того, чтобы не страдали другие".

[visir.livejournal.com]

Слишком много разом придется блокировать, руководству это очень не нравится. В саппорт после такой массовой блокировки будет нереально дозвониться в течении нескольких дней. Да и вообще негатива очень много в отношении провайдера будет...
Мы начинали с рассылки на почту замеченным в атаке - процентов 70 юзеров после этого исправлялось.

[dmn42.livejournal.com]

Что-то не едут у меня лыжи.

Настроил на нетфлоу, воткнул заведомо низкий порог срабатывания, а оно не кажет никаких алярмов.
Leafs: 0, nodes: 0, empty leafs: 0, empty nodes: 0, not detailed leafs: 0
Memory usage: 0M
и всё тут.

Нетфлоу при этом сыпется.

[dmn42.livejournal.com]

netflow=188.244.x.y:9992
serv-port=9993
snmp-timeout=10000
router=188.244.x.z
sampled=8192
log=/var/log/dds/dds.log
snap=/var/log/dds/snap
pid=/var/run/dds.pid
user=dds
interval=15
expire=300
noalarm-intervals=1
recheck=yes
inhibit=yes
check syn in 0.0.0.0/0 500 100 bydst
check pps in 0.0.0.0/0 6k 5k
check pps in 0.0.0.0/0 4k 1k bydst
check bps in a.b.c.d 2M 1M bydst
check bps out 0.0.0.0/0 20M 4M bysrc
alarm="echo '%b %p' | mail -s 'DoS %t %d' noc@"
noalarm="echo '%b %p' | mail -s 'DoS %t %d finished' noc@"

[gul-kiev.livejournal.com]

Точно ли пакеты идут на указанный IP и на порт 9992? Если да, должно всё ловить.
И ты в конфиге не указал ни одного аплинк-интерфейса. Весь трафик будет считаться как от клиентов, что не очень хорошо для алгоритма - дело не только в том, что будут срабатывать не те правила, но ещё и будет перерасход памяти. Впрочем, это не относится к имеющейся проблеме.
Можно увеличить уровень вывода отладочной информации - добавить "-vvv" или "-vvvvvv" и посмотреть, будет ли оно что-то говорить в этом случае.

[gul-kiev.livejournal.com]

Думаю, с этим лучше в email, мой адрес указан в "man dds" в конце.
Посмотри tcpdump-ом, действительно ли пакеты идут, ip-адреса и порт правильные.
Проверь, не закрыт ли у тебя этот порт (9992/udp) в firewall.

[dmn42.livejournal.com]

Написал.