из ваших-же статей и описании услуги на предыдущей итерации ddosinsurance я это взял. очевидно?
если это не так, то хотя-бы надо было сделать часть «Как это работает» в текущей статье. Логично?
Расскажите «как это работает». Можно без той части как работают фильтры и то что является реальным «know how», достаточно способ обнаружения атаки и перенаправления трафика и какие действия должен сделать клиент для подключения.
Ну и раз мы уже до этого добрались — ответьте пожалуйста на моих 3 вопроса. Это-же не сложно…
Клиент фактически переводит свой домен в ваше управление, на ваши DNS-сервера.
Очень странно от вас слышать — «При чем тут DNS?».
Он как-бы… при всем?
Начиная от способов обнаружения атаки, заканчивая единой точкой отказа и потенциальными рисками для всех ваших клиентов, которые будут так-же лежать навзничь всем колхозом «потому что 2.5mpps, работаем над этим».
вопросов несколько:
— что будет, если боты не будут спрашивать dns много и вы не заметите атаки?
— что будет если боты не будут спрашивать dns вообще, и вы не заметите атаки а роботы не заметят ваших попытко перевести ее на фильтр?
— что будет если боты заметят dns и убьют его (это не сложно учитывая вашу архитектуру)?
у меня напрашиваются неприятные ответы на эти «если», но давайте заслушаем зачинщиков…
Коллеги, спасибо за интересный сравнительный обзор. Можно было. конечно, и подробнее, и насыщеннее технически. Однако, учитывая что в публичном доступе подобных материалов практически нет — статья бесценна ;)
Вы взяли текст годичной давности ориентированный на аудиторию журнала Хакер, и делаете какие-то выводы даже не посмотрев на предмет который обсуждаете.
Ваш-же очевидный уже сейчас недостаток — theorycraft. Вы безусловно имеете представление о предмете, но оно явно поверхностно.
Вообще дискуссия явно вышла за рамки пикировки в комментах, вы приходите лучше в гости на чай — расскажете о своей системе, а мы укажем вам на очевидные ее недостатки и покажем пару новых модных трюков ;)
P.S. У RAD лучший из апплайансов L7, но его всеравно недостаточно, что мы наблюдали не далее как в это воскресенье ;)
И уж тем-более сомнительна история с «анализом чего-то там администратором» потому что люди — это явная точка отказа, имея по 10-100 инцидентов в день — администраторов не напасешься.
Да могла. Единственное что нам нужно от хостера — получить работающее приложение заказчика любом доступном IP адресе, и желательно оперативно. Все остальное мы оставляем на усмотрение самого хостинга, мы не эксперты в этом бизнесе и не считаем себя вправе давать рекомендации.
В ваших рассуждениях Все бы хорошо но есть несколько но:
>1. Это перенаправление через ДНС, примерно от 30 минут на распространение новых записей. (DNS провайдеры пишут вообще про >24 часа). Под атакой может быть критично.
Перенаправление DNS это в чистом виде SOA TTL value, держите его на уровне 5-30 минут, но вообще если у Вас есть риски получить атаку и 30 минут для Вас критично — ВЫ ОБЯЗАНЫ ПОДУМАТЬ ОБ ЭТОМ ЗАРАНЕЕ.
Все наши тарифные планы и логика работы фильтров намекают что мы не скорая помощь. В случае если вы уже подключены к фильтрам — велика вероятность что о факте атаки вы узнаете только из репортов Qrator.
>2. Трафик идет через «левый» ресурс неизвестно где, если задержки сервиса критичны, решение не подходит.
Cпасибо за лестное прилагательное. Вы обратите внимание на топологию «левого» ресурса. Там вы не найдете «левых» хостингов с «левыми» каналами или «левых» эксченджей без SLA на трафик.
Только крупные магистральные сети. Как вы думаете, почему?
Потому что топологию у нас считает 2 человека. Это раз.
Два — у нас уже открыты соединения к защищенным ресурсам, а RTT на открытие новых соединений от клиента к периметру нашей сети будет ниже, потому что мы расположены на магистралях. Эти меры более чем компенсируют возникающую задержку на обработку трафика, в чем вы можете убедиться посетив любой из «левых» ресурсов из нашего портфолио.
>3. Есть кучи других протоколов на которые сейчас направлен вектор атаки. (VOIP, DNS, SMTP).
Все TCP протоколы (включая SMTP) мы успешно кроем вплоть до L5, если есть спрос — готовы свять классификатор.
С DNS все сложнее, поскольку он UDP. К сожалению ответить в комментарии не нахожу возможным, но эту задачу мы успешно решили.
>4. Есть кучи других атак на ресурс, ряд из которых в том числе служит для усиления DoS/DDoS атак. (SQL-Injection, XSS и т.п.), >т.е. по хорошему нужен хороший IPS.
Можно чуть подробнее здесь разьяснить? И как IPS может быть вообще хорошим если он не понимает семантику приложения.
>5. Описанный вариант аналитики имеет право на жизнь, однако по факту в любом случае должен иметь фидбэк от оператора, т.к. >есть куча пограничных операций, например промо-сайты, где есть только заглавная страница, т.е. никакой матрицы переходов нет >в принципе. Новостные сайты, где контент постоянно обновляется и пользователи могут так-же не ходить дальше первой >страницы, что делать в таком случае? Резать легитимных вместе с ботами? Я конечно догадываюсь, что есть еще варианты и >методики работы )
Вы абсолютно правильно догадываетесь. Есть и другие варианты, например анализ частотности запросов или старые-добрые сигнатуры.
>6. Борьба с флудом. 2 проблемы: а) доставка трафика до системы очистки и кто за этот трафик будет платить, как я понимаю в >предложенном решении платит пользователь, и поверьте, удовольствие небольшое внезапно получить счет на оплату 10Гб/с >атаки длительностью хотя бы в сутки. Я уже не говорю про наличие толстых каналов оператора защиты. б) Нужны достаточно >мощные железки, либо серверная ферма чтобы эффективно чистить к примеру UDP флуд. К примеру у нас только одним из 3 >систем компонент защиты стоит Radware, 10MPPS. Второй компонент 14 MPPS + внешние методы BGP FlowSpec, BGP Blackhole.
Вот здесь вы вообще не угадали ниодной буквы. Какой-то адов theorycraft. Эффективно чистить ЛЮБОЙ трафик который можно описать битмаской требует сравнительно мало ресурсов — кластер Ломоносов тут совершенно непричем. Толстые каналы — да это MUST HAVE, поэтому в наших тарифах фигурирует ценник за легитимную полосу.
Очень рад за обилие ваших «игрушек». Наши платформы умеют 8Mpps в текущей версии, но они стоят в стэке и финальные цифры получаются гораздо веселей, правда корпуса не такие нарядно-цветастые и лампочек меньше.
>7. Что делать если нужно поставить под защиту целую сеть?
Капитан подсказывает — «Проанонсировать ее по BGP?»
>На самом деле вопросов больше чем ответов, да, для ОБЫЧНОГО конечного пользователя с небольшим сайтом и средними >атаками «по больнице» решение имеет право на жизнь. Как только что-то нестандартное, большое, ресурсом начинают заниматься >всерьез…
Ваше утверждение верно с точностью до наооборот. Весь стэк технологий — это наша собственная разработка, отсюда невероятные возможности по интеграции с приложениями и сервисами заказчика, особенно когда это что-то нестандартное, большое и ресурсом занимаются всерьез.
Ни один вендор или набор вендоров вам этого не обеспечит.
Большие деньги — большие риски.
Больше больших денег только политика — которая, как подсказывают классики, есть концентрированное выражение экономики.
Мы занимались и оппозицей и госами, а так-же торговыми площадками и банками, СМИ и крупным e-commerce.
Вот prooflink: online.wsj.com/article/SB10001424052970204707104578090793159318064.html
А чем можете порадовать вы?
Политика — это концентрированное выражение экономики.
У меня к Вам встречный вопрос, что вы будете делать с атакой которую RADWARE пропустил? ;)
если это не так, то хотя-бы надо было сделать часть «Как это работает» в текущей статье. Логично?
Расскажите «как это работает». Можно без той части как работают фильтры и то что является реальным «know how», достаточно способ обнаружения атаки и перенаправления трафика и какие действия должен сделать клиент для подключения.
Ну и раз мы уже до этого добрались — ответьте пожалуйста на моих 3 вопроса. Это-же не сложно…
Клиент фактически переводит свой домен в ваше управление, на ваши DNS-сервера.
Очень странно от вас слышать — «При чем тут DNS?».
Он как-бы… при всем?
Начиная от способов обнаружения атаки, заканчивая единой точкой отказа и потенциальными рисками для всех ваших клиентов, которые будут так-же лежать навзничь всем колхозом «потому что 2.5mpps, работаем над этим».
нет?
— что будет, если боты не будут спрашивать dns много и вы не заметите атаки?
— что будет если боты не будут спрашивать dns вообще, и вы не заметите атаки а роботы не заметят ваших попытко перевести ее на фильтр?
— что будет если боты заметят dns и убьют его (это не сложно учитывая вашу архитектуру)?
у меня напрашиваются неприятные ответы на эти «если», но давайте заслушаем зачинщиков…
"Все будет, но позже."Утром деньги — вечером стулья? ;)
Неплохие у HP сервачки…
Спасибо.
Тем-более заходите в гости! ;)
Ваш-же очевидный уже сейчас недостаток — theorycraft. Вы безусловно имеете представление о предмете, но оно явно поверхностно.
Вообще дискуссия явно вышла за рамки пикировки в комментах, вы приходите лучше в гости на чай — расскажете о своей системе, а мы укажем вам на очевидные ее недостатки и покажем пару новых модных трюков ;)
P.S. У RAD лучший из апплайансов L7, но его всеравно недостаточно, что мы наблюдали не далее как в это воскресенье ;)
И уж тем-более сомнительна история с «анализом чего-то там администратором» потому что люди — это явная точка отказа, имея по 10-100 инцидентов в день — администраторов не напасешься.
В ваших рассуждениях Все бы хорошо но есть несколько но:
>1. Это перенаправление через ДНС, примерно от 30 минут на распространение новых записей. (DNS провайдеры пишут вообще про >24 часа). Под атакой может быть критично.
Перенаправление DNS это в чистом виде SOA TTL value, держите его на уровне 5-30 минут, но вообще если у Вас есть риски получить атаку и 30 минут для Вас критично — ВЫ ОБЯЗАНЫ ПОДУМАТЬ ОБ ЭТОМ ЗАРАНЕЕ.
Все наши тарифные планы и логика работы фильтров намекают что мы не скорая помощь. В случае если вы уже подключены к фильтрам — велика вероятность что о факте атаки вы узнаете только из репортов Qrator.
>2. Трафик идет через «левый» ресурс неизвестно где, если задержки сервиса критичны, решение не подходит.
Cпасибо за лестное прилагательное. Вы обратите внимание на топологию «левого» ресурса. Там вы не найдете «левых» хостингов с «левыми» каналами или «левых» эксченджей без SLA на трафик.
Только крупные магистральные сети. Как вы думаете, почему?
Потому что топологию у нас считает 2 человека. Это раз.
Два — у нас уже открыты соединения к защищенным ресурсам, а RTT на открытие новых соединений от клиента к периметру нашей сети будет ниже, потому что мы расположены на магистралях. Эти меры более чем компенсируют возникающую задержку на обработку трафика, в чем вы можете убедиться посетив любой из «левых» ресурсов из нашего портфолио.
>3. Есть кучи других протоколов на которые сейчас направлен вектор атаки. (VOIP, DNS, SMTP).
Все TCP протоколы (включая SMTP) мы успешно кроем вплоть до L5, если есть спрос — готовы свять классификатор.
С DNS все сложнее, поскольку он UDP. К сожалению ответить в комментарии не нахожу возможным, но эту задачу мы успешно решили.
>4. Есть кучи других атак на ресурс, ряд из которых в том числе служит для усиления DoS/DDoS атак. (SQL-Injection, XSS и т.п.), >т.е. по хорошему нужен хороший IPS.
Можно чуть подробнее здесь разьяснить? И как IPS может быть вообще хорошим если он не понимает семантику приложения.
>5. Описанный вариант аналитики имеет право на жизнь, однако по факту в любом случае должен иметь фидбэк от оператора, т.к. >есть куча пограничных операций, например промо-сайты, где есть только заглавная страница, т.е. никакой матрицы переходов нет >в принципе. Новостные сайты, где контент постоянно обновляется и пользователи могут так-же не ходить дальше первой >страницы, что делать в таком случае? Резать легитимных вместе с ботами? Я конечно догадываюсь, что есть еще варианты и >методики работы )
Вы абсолютно правильно догадываетесь. Есть и другие варианты, например анализ частотности запросов или старые-добрые сигнатуры.
>6. Борьба с флудом. 2 проблемы: а) доставка трафика до системы очистки и кто за этот трафик будет платить, как я понимаю в >предложенном решении платит пользователь, и поверьте, удовольствие небольшое внезапно получить счет на оплату 10Гб/с >атаки длительностью хотя бы в сутки. Я уже не говорю про наличие толстых каналов оператора защиты. б) Нужны достаточно >мощные железки, либо серверная ферма чтобы эффективно чистить к примеру UDP флуд. К примеру у нас только одним из 3 >систем компонент защиты стоит Radware, 10MPPS. Второй компонент 14 MPPS + внешние методы BGP FlowSpec, BGP Blackhole.
Вот здесь вы вообще не угадали ниодной буквы. Какой-то адов theorycraft. Эффективно чистить ЛЮБОЙ трафик который можно описать битмаской требует сравнительно мало ресурсов — кластер Ломоносов тут совершенно непричем. Толстые каналы — да это MUST HAVE, поэтому в наших тарифах фигурирует ценник за легитимную полосу.
Очень рад за обилие ваших «игрушек». Наши платформы умеют 8Mpps в текущей версии, но они стоят в стэке и финальные цифры получаются гораздо веселей, правда корпуса не такие нарядно-цветастые и лампочек меньше.
>7. Что делать если нужно поставить под защиту целую сеть?
Капитан подсказывает — «Проанонсировать ее по BGP?»
>На самом деле вопросов больше чем ответов, да, для ОБЫЧНОГО конечного пользователя с небольшим сайтом и средними >атаками «по больнице» решение имеет право на жизнь. Как только что-то нестандартное, большое, ресурсом начинают заниматься >всерьез…
Ваше утверждение верно с точностью до наооборот. Весь стэк технологий — это наша собственная разработка, отсюда невероятные возможности по интеграции с приложениями и сервисами заказчика, особенно когда это что-то нестандартное, большое и ресурсом занимаются всерьез.
Ни один вендор или набор вендоров вам этого не обеспечит.
Большие деньги — большие риски.
Больше больших денег только политика — которая, как подсказывают классики, есть концентрированное выражение экономики.
Мы занимались и оппозицей и госами, а так-же торговыми площадками и банками, СМИ и крупным e-commerce.
Вот prooflink: online.wsj.com/article/SB10001424052970204707104578090793159318064.html
А чем можете порадовать вы?
Политика — это концентрированное выражение экономики.
У меня к Вам встречный вопрос, что вы будете делать с атакой которую RADWARE пропустил? ;)