Опыт работы с ddos-guard

1 234
P
На сайте с 21.04.2008
Offline
251
#31
lsw_fan:
qrator по факту лучше, чем ddos-guard, но совсем не на много.

qrator при udp-флуде блокирует весь udp и icmp трафик к серверу. ИМХО это не очень хорошо.

---------- Добавлено 21.04.2016 в 09:50 ----------

Ivan Lungov:
На самом деле, ситуация с анти-ддосом в России весьма печальная. Мы за этот месяц перепробовали кучу вариантов, провели массу переговоров с различными компаниями. В итоге, ни одна из компаний в России оказалась не способна взять целый ДЦ под полную защиту. Большинство отечественных решений рассчитаны на защиту сайтов или других конкретных ресурсов (как правило TCP, UDP гораздо реже). Но это не совсем то, что мы хотели бы получить для нашего ДЦ, по этому приходится работать над собственным решением.

servicepipe.ru пробовали? Что скажете?

Интернет Хостинг Центр IHC.RU - Хостинг, KVM VPS на SSD, аренда серверов.
LF
На сайте с 13.08.2015
Offline
65
#32
Ivan Lungov:
К сожалению, при асимметричной передаче трафика, возникает куча проблем с анти-ддосами, у нас такое было, когда входящий шел через анти-ддос, а исходящий на прямую.
В этом случае, антиддос не видит сессии, на основе которой как правило принимается решение о легитимности пакета.

В схеме ASN1 + ASN2 + AntiDDOS ASN ассиметричная схема работает хорошо.

Возможно у вас есть какие-то нюансы, из-за бОльшего числа аплинков или пиров на IX.

Ivan Lungov:

Представляете, как обрадуются соседи по сети атакуемого сервера, особенно если это будут геймеры, у которых вдруг пинг побежит через заграницу. По нормальному, переключение айпишника под защиту должно происходить по маске /32. Мало кто из операторов готов принимать префиксами /32 (точнее, вообще никто).

В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.

На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.

nullroute, это ведь тоже по сути будет защита от DDoS для вас.

MIRhosting.com
На сайте с 18.10.2006
Offline
203
#33

У retn есть готовое решение, по сути ip transit, но более дорогой, и он чиститься.

Все что надо в таком сценарии, это нужный префикс анонсить только через них, что вобщем не так плохо, роуты не меняются.

По вариантам сторонних чисток, типовый вариант - поднятие gre тунеля, в обе стороны. Это правда, что для корректной чистки, особенно все что касается днс и вообще L7, трафик должен в обе стороны ходить через железку.

Андрей Нестеренко, MIRhosting Облачная платформа для DevOps (https://mirhosting.com/paas)
S2
На сайте с 30.12.2015
Offline
307
#34
lsw_fan:
В схеме ASN1 + ASN2 + AntiDDOS ASN ассиметричная схема работает хорошо.
Возможно у вас есть какие-то нюансы, из-за бОльшего числа аплинков или пиров на IX.



В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.
На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.
nullroute, это ведь тоже по сути будет защита от DDoS для вас.

РТК сейчас по префиксу /32 отлично фильтруют. Единственное, что не всегда автоматически срабатывает и приходится их пинать письмами при обнаружении атаки.

Ivan Lungov
На сайте с 24.04.2013
Offline
222
#35
porutchik:
servicepipe.ru пробовали? Что скажете?

Нет, не пробовали. Свяжусь с ними, узнаю, что предлагают.

---------- Добавлено 21.04.2016 в 15:06 ----------

lsw_fan:
В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.
На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.
nullroute, это ведь тоже по сути будет защита от DDoS для вас.
smart2web:
РТК сейчас по префиксу /32 отлично фильтруют. Единственное, что не всегда автоматически срабатывает и приходится их пинать письмами при обнаружении атаки.

Но только в данном случае, не мы им анонсируем, а они сами заворачивают атакуемый IP через Arbor. А блекхол, у нас давно совсем апстримами настроен, правда это становится малоэффективным когда ддосят подрять все твои айпи. В итоде, можно так все свои подсети убрать в бекхол ). Но в этом случае гораздо эффективнее просто оптику выдернуть и маршрутизатора ).

А на счет увеличения пинга на 20-40 мс, это как повезет. У кого-то на 40 мс поднимется, а у кого то и на все 100. Надо учитывать отдаленные регионы России, от них до Москвы получается 40-60 мс, А если завернуть траф на Амстердам, то и получаются все 100-120.

---------- Добавлено 21.04.2016 в 15:09 ----------

MIRhosting.com:
У retn есть готовое решение, по сути ip transit, но более дорогой, и он чиститься.
Все что надо в таком сценарии, это нужный префикс анонсить только через них, что вобщем не так плохо, роуты не меняются.

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

---------- Добавлено 21.04.2016 в 15:15 ----------

MIRhosting.com:
По вариантам сторонних чисток, типовый вариант - поднятие gre тунеля, в обе стороны. Это правда, что для корректной чистки, особенно все что касается днс и вообще L7, трафик должен в обе стороны ходить через железку.

Вот мы и подняли в марте GRE с ддос-гвардом... Сейчас, правда уже с ними поднят прямой стык на М9, но трафика по нему не гоняем пока, т.к. не до конца отработали с ними схему взаимодействия. Пока, идея такая, что поднимаем 2 канала protected и unprotected. По умолчанию, весь траф идет через unprotected, в случае детектирования ими атаки, они по API, сообщают нам атакуемый IP, и мы должны его анонсировать (как раз по /32) в protected-канал, тогда он начинает чистится. Переключать трафик самостоятельно на своей стороне они не готовы.

IHOR Хостинг (https://www.ihor.hosting/) Наша ветка на серчах (/ru/forum/1015084)
MIRhosting.com
На сайте с 18.10.2006
Offline
203
#36
Ivan Lungov:

Вот мы и подняли в марте GRE с ддос-гвардом... Сейчас, правда уже с ними поднят прямой стык на М9, но трафика по нему не гоняем пока, т.к. не до конца отработали с ними схему взаимодействия. Пока, идея такая, что поднимаем 2 канала protected и unprotected. По умолчанию, весь траф идет через unprotected, в случае детектирования ими атаки, они по API, сообщают нам атакуемый IP, и мы должны его анонсировать (как раз по /32) в protected-канал, тогда он начинает чистится. Переключать трафик самостоятельно на своей стороне они не готовы.

На самом деле оно и правильно. Это Ваш трафик, ваши анонсы, Вы должны это регулировать. Они дают сервис очистки. В смысле, не только они, а вообще кто угодно, схема правильная.

Не так уж сложно, на основе top talkers, при превышении лимита, автоматически начинать анонсить /32 куда надо.

1 234

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий