- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
qrator по факту лучше, чем ddos-guard, но совсем не на много.
qrator при udp-флуде блокирует весь udp и icmp трафик к серверу. ИМХО это не очень хорошо.
---------- Добавлено 21.04.2016 в 09:50 ----------
На самом деле, ситуация с анти-ддосом в России весьма печальная. Мы за этот месяц перепробовали кучу вариантов, провели массу переговоров с различными компаниями. В итоге, ни одна из компаний в России оказалась не способна взять целый ДЦ под полную защиту. Большинство отечественных решений рассчитаны на защиту сайтов или других конкретных ресурсов (как правило TCP, UDP гораздо реже). Но это не совсем то, что мы хотели бы получить для нашего ДЦ, по этому приходится работать над собственным решением.
servicepipe.ru пробовали? Что скажете?
К сожалению, при асимметричной передаче трафика, возникает куча проблем с анти-ддосами, у нас такое было, когда входящий шел через анти-ддос, а исходящий на прямую.
В этом случае, антиддос не видит сессии, на основе которой как правило принимается решение о легитимности пакета.
В схеме ASN1 + ASN2 + AntiDDOS ASN ассиметричная схема работает хорошо.
Возможно у вас есть какие-то нюансы, из-за бОльшего числа аплинков или пиров на IX.
Представляете, как обрадуются соседи по сети атакуемого сервера, особенно если это будут геймеры, у которых вдруг пинг побежит через заграницу. По нормальному, переключение айпишника под защиту должно происходить по маске /32. Мало кто из операторов готов принимать префиксами /32 (точнее, вообще никто).
В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.
На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.
nullroute, это ведь тоже по сути будет защита от DDoS для вас.
У retn есть готовое решение, по сути ip transit, но более дорогой, и он чиститься.
Все что надо в таком сценарии, это нужный префикс анонсить только через них, что вобщем не так плохо, роуты не меняются.
По вариантам сторонних чисток, типовый вариант - поднятие gre тунеля, в обе стороны. Это правда, что для корректной чистки, особенно все что касается днс и вообще L7, трафик должен в обе стороны ходить через железку.
В схеме ASN1 + ASN2 + AntiDDOS ASN ассиметричная схема работает хорошо.
Возможно у вас есть какие-то нюансы, из-за бОльшего числа аплинков или пиров на IX.
В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.
На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.
nullroute, это ведь тоже по сути будет защита от DDoS для вас.
РТК сейчас по префиксу /32 отлично фильтруют. Единственное, что не всегда автоматически срабатывает и приходится их пинать письмами при обнаружении атаки.
servicepipe.ru пробовали? Что скажете?
Нет, не пробовали. Свяжусь с ними, узнаю, что предлагают.
---------- Добавлено 21.04.2016 в 15:06 ----------
В случае нахождения центра очистки в Амстердаме, пинг увеличится на 20-40 мс. Это конечно, вызовет недовольство у какой-то части геймеров, но в большинстве своем вполне приемлемое увеличение.
На счет принимать /32 , то это возможно даже у Ростелекома, но смысл в этом есть только для remotely triggered black hole , т.е null-route. С ними надо только предварительно договориться, чтобы они сняли фильтры. Так же , я знаю, что подобное можно организовать у Мегафона.
nullroute, это ведь тоже по сути будет защита от DDoS для вас.
РТК сейчас по префиксу /32 отлично фильтруют. Единственное, что не всегда автоматически срабатывает и приходится их пинать письмами при обнаружении атаки.
Но только в данном случае, не мы им анонсируем, а они сами заворачивают атакуемый IP через Arbor. А блекхол, у нас давно совсем апстримами настроен, правда это становится малоэффективным когда ддосят подрять все твои айпи. В итоде, можно так все свои подсети убрать в бекхол ). Но в этом случае гораздо эффективнее просто оптику выдернуть и маршрутизатора ).
А на счет увеличения пинга на 20-40 мс, это как повезет. У кого-то на 40 мс поднимется, а у кого то и на все 100. Надо учитывать отдаленные регионы России, от них до Москвы получается 40-60 мс, А если завернуть траф на Амстердам, то и получаются все 100-120.
---------- Добавлено 21.04.2016 в 15:09 ----------
У retn есть готовое решение, по сути ip transit, но более дорогой, и он чиститься.
Все что надо в таком сценарии, это нужный префикс анонсить только через них, что вобщем не так плохо, роуты не меняются.
С Ретном мы уже ведем настройку. Посмотрим как хорошо у них будет работать. Правда, на счет готовности они сами не до конца уверены, насколько я понял, они сейчас предлагают нам выступить в роли бета-тестеров.
---------- Добавлено 21.04.2016 в 15:15 ----------
По вариантам сторонних чисток, типовый вариант - поднятие gre тунеля, в обе стороны. Это правда, что для корректной чистки, особенно все что касается днс и вообще L7, трафик должен в обе стороны ходить через железку.
Вот мы и подняли в марте GRE с ддос-гвардом... Сейчас, правда уже с ними поднят прямой стык на М9, но трафика по нему не гоняем пока, т.к. не до конца отработали с ними схему взаимодействия. Пока, идея такая, что поднимаем 2 канала protected и unprotected. По умолчанию, весь траф идет через unprotected, в случае детектирования ими атаки, они по API, сообщают нам атакуемый IP, и мы должны его анонсировать (как раз по /32) в protected-канал, тогда он начинает чистится. Переключать трафик самостоятельно на своей стороне они не готовы.
Вот мы и подняли в марте GRE с ддос-гвардом... Сейчас, правда уже с ними поднят прямой стык на М9, но трафика по нему не гоняем пока, т.к. не до конца отработали с ними схему взаимодействия. Пока, идея такая, что поднимаем 2 канала protected и unprotected. По умолчанию, весь траф идет через unprotected, в случае детектирования ими атаки, они по API, сообщают нам атакуемый IP, и мы должны его анонсировать (как раз по /32) в protected-канал, тогда он начинает чистится. Переключать трафик самостоятельно на своей стороне они не готовы.
На самом деле оно и правильно. Это Ваш трафик, ваши анонсы, Вы должны это регулировать. Они дают сервис очистки. В смысле, не только они, а вообще кто угодно, схема правильная.
Не так уж сложно, на основе top talkers, при превышении лимита, автоматически начинать анонсить /32 куда надо.