Как стать автором
Обновить

Комментарии 65

«Защита от атаки любой мощности»
«Мощная атака грозит „залить“ линк»
«Клиентское оборудование отражает атаку»

Маркетологи такие маркетологи…
По графикам видно что Defense Pro «выпилил» лишнего ~20% — CPU есть функция от Request Rate, жалко сам Request Rate не показываете.
И пропустил лишнего Connections раза в 2 выше нормы до инцидента.

А вы его настраивать пробовали? Вроде-же хорошая железка Defense Pro.
Если посмотреть на время, то начало атаки примерно соответствует началу рабочего дня, а вы за бейслайн принимаете значение в пять часов ночи.
Это все хорошо, но почему тогда CPU usage (который вроде функция от Request Rate) упал в 2 раза ниже ночного бейслайна? Это FP?
Да вообще странная какая-то атака.
Как раз обычная достаточно для формата «ручного отражения». Качество — абсолютно непредсказуемо и зависит от радиуса кривизны рук. Тут TimeWeb с Pravail в прошлом году отметился. И ровно такая-же история — пропустили/фильтранули лишнего…

Ну это ладно, бывает. Но не увидеть это в картинках своей «победной реляции» на хабре.....image
К вопросу. Несколько часов у меня не открывался хабр (иногда стили не загружались, иногда SYN ACK не было). Проблема совершенно точно не на моей стороне. www.downforeveryoneorjustme.com/ говорил, что с его точки зрения проблем с ресурсом не было. Уважаемый сотрудник highloadlab — чозанах? Это вы так качественно не теряете полезный трафик? :)
Дим, это было непосредственно с habrahabr.ru (178.248.233.33)?
SYN ACK не отвечал именно этот IP?
image

Как видите Down For Everyone прав — все работает и «ни единого разрыва». Черный список так-же пуст.
Думаю SYN ACK и стили, сьедал кто-то по дороге — например ближайший к вам NAT.
За ближайший ко мне NAT я ручаюсь :)

Сообщение, где черными буквами на белом фоне было что-то вроде «Qrator 400» после минутного (или около того) ожидания, тоже генерирует наше железо? Было несколько раз.

Адрес точно 178.248.233.33. Логи файрвола говорят о куче SYN timeout'ов, закрытий по RST изнутри (браузеру надоело ждать), редко по FINам. Задница продолжалась где-то с 09:43 до 12:41 (самый вал ошибок).

А о чем говорит этот график? Атаки нет что ли, просто так теряете трафик? :)

За магистрали тоже ручаюсь, связность в интернете у нас хорошо мониторится. Впрочем, трассировку не делал.
Там помимо Qrator 400 еще совершенно точно была строчка GURU MEDITATION. Можно вот ее тоже сюда :)

график говорит говорит о том что все гладко и ровно, а вот tcpdump с вашего файрвола или полный текст ошибки Qrator сделал-бы ваш пост менее похожим на попытку обычного интернет-троллинга ;)
Скажу по секрету — если у кого-то работает, а у кого-то нет, то это все-таки говорит о проблемах с сервисом… Какой смысл пользоваться еще одной сторонней пингалкой, когда первая говорит «всё ок», а страница у меня все равно не грузится?
Пингалка хороша распределенностью и хорошим покрытием российского сегмента. И дает некоторое, приближенное к реальности, представление о наличии/отсутствии связности.
Допустим, там всё зелено (вы наверняка сами отслеживаете такое). А у меня страшные ошибки вылезают, страницы грузятся по несколько минут без стилей, генерируемые куратором сообщения показываются. О чем это говорит? :)
По таким вопросам я всегда предельно серьезен. Проблема была, и однозначно на вашей стороне. Дамп не предоставлю — какой смысл сниффить, когда telnet на 80-й порт не проходит и появляются генерируемые вашей стороной ошибки?
Вот про «однозначность стороны» учитывая то что это интернет и активного оборудования (в том числе и DPI ) по дороге может быть понатыкано уйма — это достаточно смелое программное заявление.

Какие-то предположения о просихождении проблем можно делать только имея tcpdump с двух сторон, да и то не всегда…

edit: чтобы не быть голословным roem.ru/2014/05/12/mega99078/
Кто-то кроме вас может генерировать страницу «qrator 400»?
я не уверен о какой Qrator 400 идет речь.

Наша 400я содержит еще несколко строчек текста который позволяет понять что и где именно случилось, вплоть до ядра…
Ещё раз отметим, какой-то целенаправленной атаки на ресурсы не было. Было большое количество «мусора», которое нагружало IPS на FW
На графике, где отмечен момент включения DefensePro, никаких инцидентов, связанных с недоступностью публичных ресурсов или их аномальной загрузкой, не было, поэтому было не очевидно, на сколько нужно «закручивать гайки» по количеству connections. Никто и не ожидал резкого снижения нагрузки на Firewall.
В данном случае показан момент включения в режим блокировки после обучения. Настройки Request Rate – по умолчанию.
Вообще-то когда на тендер приходит только одна заявка, тендер обычно считается неудачным. Минимум две а то и три надо.

Это по ФЗ если что.
Дык, шлём две и дальше блокируем проведение тендера. Видел я пару контор, котоыре так работали — всегда на тендеры ходили вместе. Одни ставили цену на 20% выше.
Коммерсы не закупаются по ФЗ 44 или 223, только госы.
В открытом аукционе в электронной форме процедура с одной заявкой считается несостоявшейся и контракт заключается по этой заявке по МАКСИМАЛЬНОЙ цене лота.
Процедура аукциона и правда не проводится.

*Это относительно гос.контрактов проводимых через ОАЭФ
И, кстати, по ФЗ, если что, такого понятия, как «тендер» вообще не существует.

Тендер, относится исключительно к коммерческим торговым площадкам.
Всё что описано в статье можно решить за бесплатно — cloudflare
Нельзя.
Хотя бы тот же httpS в cloudflare за денюшку.
Да и DefensePro железка не только для защиты сайта.
ок, но цена cloudflare будет сильно ниже.
За какой период?
И да. Мы вроде как не увидели цены на услуги ВымпелКом-а.
ну да, только он не в России
Ну так одни плюсы же!
В России давно есть qrator.net, который доказал свою профпригодность временем и делом. Чем вы лучше? Если, как я понял, всё что вы делаете, это покупаете чужое antiDDoS оборудование и позиционируете его как панацею?
QRator, при всем уважении к тому, что они сделали — допиленный нжинкс и пачка каналов для амортизации бэндвиз-ориентированных атак. И тут, и там некоторая доля ракетной науки присутствует, но в случае билайна, пусть они выступают перепродавцами с маржой, эффективность будет выше. Еесли бы реселлеры озвучили ценники прямо в посте, можно было бы предметно сравнивать. Ну и да, сравнивать потребности озвученных клиентов со среднестатистической айти-компанией нельзя из-за специфичной оптимизации расходов на айти у первых.
Ну нас часто упрекают, про то что мы «на коленке сделаны».
Мы не только HTTP умеем, но и любой другой протокол — это с вашим «nginx на коленке» никак не бьется.
DNS умеем вообще достаточно элегантно, отдельная песня и предмет для гордости.

И packetrate держим в десятки мегапакетов, и SSL умеем без раскрытия сертификатов — чем ни Radware, ни CloudFlare похвастаться не могут.

Мы не обижаемся. Коленки у всех разные.

Боюсь вступить в длинную и не очень продуктивную (по причине NDA) дискуссию — почему десятки mpps при фильтрации считаете достижением? Это достижимо, в общем, на опенсоурсных технологиях и на очень небольших мощностях. SSL тоже можно довольно лихо фильтровать эвристикой в зависимости от поведения отдельного флоу, но при этом неизбежны фолспозитивы.
Что касается SSL, то мы его тоже умеем без раскрытия сертификатов, также мы умеем внутри SSL отражать атаки на уровне приложения.
PacketRate — сейчас гарантированно держим 50 мегапакетов, предусмотрено расширение до 100. Но это все сугубо технические характеристики. Самое главное то, что мы под атакой не теряем легитимный трафик (подтверждено как независимыми тестами, тот же NSS Labs, так и тестами, которые проводили наши клиенты)
Без раскрытия сертификатов L7 атаки?
Да, на 7 уровне сертификаты также не раскрываем.
Да вы волшебник ;)
Не видя семантики приложения делать разгадывать робот/человек — это сильно.
Да, мы волшебники, и нашли способ это делать. Рассказать, увы, не можем. Но то, что проверка делается — факт. Догоняйте.
Ох уж эти сказочки, ох уж эти сказочники… ;)
Как вам тут уже написали, Radware DefensePro, на основе которого вы построены, таких чудес не умеет и требует раскрыть ключи шифрования.

Что ещё важнее: если вы утверждаете, что умеете:
  • анализировать поведение пользователя в шифрованном трафике
  • подставлять в этот трафик JS и редиректы

и всё это без расшифровки трафика, то это означает одно из двух:
  • либо вы тем самым заявляете, что скомпрометировали алгоритмы шифрования, которые используются HTTPS (причём все: от RSA до ГОСТ). Это достаточно громкое заявление, которое заслуживает отдельного поста, поскольку у сообщества автоматически возникает целый ряд вопросов, в т. ч. о безопасности финансовых операций, проводимых через HTTPS сквозь вашу систему защиты.
  • либо такой анализ требует дополнительного содействия от вашего клиента. Какого содействия? Что дополнительно должен сделать клиент, чтобы быть защищённым?
DefensePro не участвует в распознавании атаки внутри SSL, поскольку, как правильно было замечено, не умеет этого делать без раскрытия ключа.
Для этого используются дополнительные методы анализа, которые не требуют передачи нам клиентского ключа шифрования, в связи с чем нет рисков его компрометации.
Но как эти методы работают? Ведь вы не видите запросов в трафике! Или алгоритм RSA всё же скомпрометирован? :-)

Или вы полагаете, что для анализа L7 достаточно таймингов и информации об объёмах передаваемых данных? :-)
НЛО прилетело и опубликовало эту надпись здесь
Не похоже. Модели поведения могут быть только у пользователя, у шифрованного трафика могут быть только косвенные показатели.

Полноценный поведенческий анализ на основе таймингов и размеров передаваемых данных — это утопия. Для того, чтобы обмануть такой «анализ», достаточно последовательно отправлять заранее определённые запросы по кольцевому списку, что ботнеты умеют делать уже достаточно давно :-)
У меня вопрос / предложение насчёт 50 мегапакетов. Мы предлагаем организовать совместное тестирование заявленных характеристик на Вашей территории с нашим генератором атак.

Будем делать несколько видов атак с пакетрейтом 10-50Mpps, результаты опубликуем на Хабре в рамках отдельной статьи.

Жду ответа.
Тогда уж лучше нашу команду во главе с BeLove позовите вас потестить, чтобы все честно было.
да и мы тоже с удовольствием потестим контр-меры ;)
давайте устроим Pchelki-CUP?
В документине, описывающей механизм radware «securing-online-businesses-from-ssl-ddos-attacks-wp» есть фраза:

The SSL engine terminates the client connection, performs the SSL handshake, decrypts the traffic, and returns it to the application layers of defense in a clear text (marked as dashed blue lines).
The SSL termination requires that certificate will be installed on the SSL engine.
Абсолютно верно — именно так всё и работает, но нигде не написано что ставится боевой сертификат. Фишка заключается как раз во втором, не боевом сертификате — его компрометация ничего не даст, а железки, куда ставится этот сертификат, еще и под контролем клиента.
Есть довольно большие сомнения насчёт всех заявленных характеристик, особенно после внимательного взгляда на представленный график.

Начальные данные


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

Считаем минимальные значения — поправкой (bias) получаем:

CPULoad = CPU_load_min + Theta * (Полоса занимаемая атакой — Throughput_min).
или
CPULoad = 11 + 5.057683e-08 * (Полоса занимаемая атакой — 75Mbit/s). Здесь 75Mbits = 9 834 056 Bytes/s * 8 = 78 672 448 Bits/s.

Считаем ошибку по среднему (Average) значению Throughput, по которому в исходных данных указано значение CPU Load 17.03%

ApproxCPULoad = 11 + 5.057683e-08 * (219234872 — 78672448) = 18.109 %
Error = ( 18.109-17.3 ) / 17.3 * 100 = 4.6763%.

Смотрим график



За неимением других данных — результат более-менее :-). Отметим, что при увеличением трафика эффективность его обработки вряд ли будет увеличиваться, скорее наоборот — процессорного времени перестанет хватать и начнутся: либо FP, либо FN.

Дальше считаем загрузку процессора, которая получится при заявленных характеристиках по пропускной способности, возьмём 10-50Gbit/s.



Получаем, что при 10Gbit/s, CPU Load должен быть 550%, а при 50Gbit/s — 2700%.

Собственно, указанные выше соображения и вызывают сомнения в том, что указанное в статье решение «гарантированно выдержит», «без потерь легитимного трафика» 10-50Gbit/s. Думаю, что с таким CPU Load, значения FP и FN будут зашкаливать, что неизбежно приведёт к критической деградации сервиса.

IMHO слова «гарантированно выдержит» и " не теряем легитимный трафик" следует дополнять конкретными числами по мощности/типу атак, TP/TN/FP/FN, Accuracy и Precision.

В отличие от простой продажи оборудования мы предлагаем защиту от мощных DDoS атак как сервис. Редкая компания станет сама себе покупать оборудование, способное защитить от атак в 80 Гбит/с, и нанимать штат специалистов, умеющих с этим оборудованием работать – это слишком дорого. У нас есть поддержка 24*7, которая контролирует работу всех систем и при необходимости отражает атаки вручную.

В рамках услуги происходит защита не только web ресурсов заказчика, а также на 7 уровне анализируется SMTP, POP3, DNS, FTP, MySQL, MSSQL, SIP.

Защита от атак в полосе канала осуществляется на оборудовании, размещённом у заказчика. При этом заказчик может использовать DefensePro, приобретённый ранее и интегрированный с нашим центром очистки.

Трафик переводится на центр очистки средствами BGP внутри нашей магистральной сети только при превышении полосы атаки установленного с клиентом значения.
«вручную» — самое печальное слово в этой песне.
Отражение атак и на клиентском оборудовании, и в центре очистки происходит в автоматическом режиме. Но за любой автоматизацией всегда должны стоять реальные люди.
В исключительных ситуациях их необходимо подключать. Например, если оборудование не прошло период обучения до конца, либо подключение идет под атакой.
Даже в таких ситуациях железо, конечно, проведет очистку, но более тонкую фильтрацию в соответствии с профилем трафика конкретного клиента можно сделать только вручную.
1. Как давно внедрили защиту по этой технологии?

2. В презентации написано «Защита от атаки любой мощности» (я так понимаю это с оговоркой на «более мощные тоже фильтруются, но уже без гарантий по отсутствию потерь легитимного трафика») — прокомментируйте, плиз.

3. Далее указана «Максимальная мощность атаки — 80 Гб/с», в спеке DefensePro 40420 указана максимальная пропускная (я так понял фильтрующая) способность — 40Gbps. Где ошибка? Или они могут стэкироваться каким то образом? 40Gbps это физическое ограничение платформы или какое-то лицензионное?
Сервис был запущен в конце прошлого года.

Всё верно – атаки свыше 80 Гбит/с фильтруются, но с возможными потерями легитимного трафика.

Один DefensePro максимально несет на борту один 40g-сегмент и 4 сегмента по 10G, а в стандартную 42-юнитовую стойку можно установить 21 модуль. Дальше, извините, по соображениям безопасности не могу детализировать.
Прошу прощения, я видимо неправильно вас понял, ведь стекирование и установка в одну стойку — это немного разные вещи. При чем тут стойка? На сайте DP нет информации о том, что несколько DP могут стекироваться и увеличивать таим образом пропускную (фильтрующую?) способность.

P.S.: Да и потом, поставив 21 DP в одну стойку, вы её расплавите при первой серьезной атаке. Не говоря уж о том, что это все добро питать надо чем-то.
и стянуть столько полосы в один узел…
Архитектура центра очистки позволяет распределить трафик.
Один DP x420 потребляет 650 Вт. 13650 Вт на стойку – это нормально.

А по тупому — переход на HTTPS разве не уберет 99% подобных атак?
К примеру, для детектирования атак внутри SSL у нас на уровне железа делается следующее:
  1. ...302-й редирект..
  2. каждый отдельный клиент получает Javascript буквально на 3 строки


Внутри SSL то? Без сертификата? А если с ним, в чем был смысл указывать, что это все внутри SSL?
> Если ботнет отрабатывает редирект, каждый отдельный
> клиент получает Javascript буквально на 3 строки.
> Современные ботнеты этот скрипт не проходят.

Это не так. Мы (Qrator) впервые зарегистрировали деятельность JS-enabled-ботов, ЕМНИП, в 2011 году; Incapsula сообщила о крупной атаке с использованием PhantomJS в октябре 2013 г.
Гораздо интереснее было бы решение, позволяющее без предварительного обучения и наличия в «предоплаченной» сети максимально быстро отражать атаки.
В принципе, решается только если хотя бы DNS-сервера размещены у защитного сервиса (даже без предварительной фильтрации трафика) и доступна предварительная статистика по другим клиентам. А то все эти «режимы обучения» стоимостью дороже, чем отражение атаки.

Одной из метрик эффективности защиты является время подключения отражения хотя бы 80% атаки «с нуля». Кто готов дать статистику с SLA?
Вы совсем недавно анонсировали свою услугу и на рынке не так много отзывов о качестве предоставляемого вами сервиса, поэтому хотелось бы понять проводилось ли сравнение antiddos услуг от других операторов/cloud-сервисов? Было бы очень интересно услышать чем вы лучше или хуже? А также в чем отличие услуги построенной на базе решения Radware?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий