Софт уже продаем, в том числе и со срочной лицензией от месяца (можно считать как аренду). Удаленную поддержку в настройке и отражении атаки окажем. А сервер, в большинстве случаев, клиент может найти по своим каналам дешевле.
Была гипотеза развития в направление подобной связки, но cusdev показал ряд проблем и пока отложили. Зато есть смежное развитие продукта за счет интеграции с внешними системами мониторинга, детектирования, защиты и "облачными" сервисами.
Если есть незакрытая "боль" или потребность в каком-то сценарии защиты от DDoS, то можно обсудить.
С экономическим обоснования атаки согласен, вот только прикол в том, что организовать атаку в десятки гигабит просто и почти бесплатно. Различные UDP-Based Amplification Attacks в помощь юному атакующему.
Такие атаки фильтровать легко, но к ним нужно быть готовым.
Не все "проекты" можно вынести в публичное облако. По причинам техническим, экономическим, регулятивным.
Алексей писал про случай, когда AWS используется для защиты сервера стоящего в каком-то внешнем ДЦ и наличия риска атаки мимо AWS. Поэтому комментарий про облака и Яндекс нерелевантны.
Но для полноты картины и развенчание мифа об 100% защите в облаках почитайте историю о том, как и почему Akamai отказался защищать Браина Кребса (Brain Krebs).
Я мыслю в парадигме сетей и защиты от DDoS-атак, которыми занимаюсь больше 10 лет. И основная задача стоит не в том, что просто быстро дропнуть пакеты, а в том чтобы дропнуть нужные пакеты атаки. И в рамках FPGA эту задачу полностью не решить.
На рынке много решений, которые на аппаратном уровне (как на FPGA, так на ASIC'ах стандартных network processor, так и специализированных network security processors, кnowledge-based processor, content processors) делают часть защиты, но современные решения защиты переходят в софтверные реализации, т.к. это более эффективно сразу по многим критериям.
Ну, и для информации. Для работы на wirespeed 10 GbE нужно успевать за 67,2 ns обработать "пакет", мы на обычном CPU обрабатываем на wirespeed 40 GbE.
Резюмируя. В современных реалиях вера в защиту в "облаках" и в аппаратных реализациях необоснованна. Нужен комплексный подход с учетом требований и особенностей объекта защиты.
И от каких атак и какие сервисы такая железка защитит? А какая у нее будет производительность? А хватит ли каналов у хостинг провайдера? А готов ли будет хостинг переплачивать за трафик атаки своим аплинкам из-за проблемного клиента?
DDoS-атаки это общее название большого количества видов атак, которые нацелены на исчерпания ресурсов, в том числе и финансовых.
Поэтому для какого-то сервиса подойдет защита за 300$ и возможные риски простоя не столь критичны. А для другого сервиса многомиллионные вливания в защиту будут недостаточны.
Поддерживаю. Для напоминания оставлю несколько определении:
«Стартап — это компания или временная организация, созданная для поиска повторяемой и масштабируемой бизнес-модели» Стив Бланк (Steve Blank)
«Стартап — это организация, целью которой является создание продуктов и услуг в условиях экстремальной неопределенности» Эрик Рис (Eric Ries)
Ну, и мне особо нравится определение близкое к венчурным инвестициям:
«Стартап — это временная организация, созданная для поиска масштабируемой, повторяемой и прибыльной бизнес-модели в условиях экстремальной неопределенности, с целью быстрого роста» Илья Королев
Если известен реальный IP-адрес ресурса, то можно организовать атаку мимо сервиса защиты.
Даже если на вышестоящем роутере ACL'ем закрыть все адреса, кроме источников туннеля, то все равно можно забить входящие каналы, вплоть до отключения ДЦ или оператора связи.
DDoS устойчивость одной площадки явно меньше, чем у территориально распределенного сервиса по защите от DDoS-атак. Но при использовании сервиса остается риск атаки на "последнюю милю", поэтому нужно выстраивать эшелонированную оборону. Каждый из эшелонов будет лучше подходить для определенных типов DDoS-атак, а количество эшелонов и состав нужно строить исходя из защищаемых ресурсов и сервисов, задач, денег.
Спасибо за пожелание.
Только я не из Qrator Labs. :-)
Я PdM в MITIGATOR (http://mitigator.ru)
Софт уже продаем, в том числе и со срочной лицензией от месяца (можно считать как аренду).
Удаленную поддержку в настройке и отражении атаки окажем.
А сервер, в большинстве случаев, клиент может найти по своим каналам дешевле.
Была гипотеза развития в направление подобной связки, но cusdev показал ряд проблем и пока отложили.
Зато есть смежное развитие продукта за счет интеграции с внешними системами мониторинга, детектирования, защиты и "облачными" сервисами.
Если есть незакрытая "боль" или потребность в каком-то сценарии защиты от DDoS, то можно обсудить.
Они и не возьмут.
С экономическим обоснования атаки согласен, вот только прикол в том, что организовать атаку в десятки гигабит просто и почти бесплатно. Различные UDP-Based Amplification Attacks в помощь юному атакующему.
Такие атаки фильтровать легко, но к ним нужно быть готовым.
Не все "проекты" можно вынести в публичное облако. По причинам техническим, экономическим, регулятивным.
Алексей писал про случай, когда AWS используется для защиты сервера стоящего в каком-то внешнем ДЦ и наличия риска атаки мимо AWS. Поэтому комментарий про облака и Яндекс нерелевантны.
Но для полноты картины и развенчание мифа об 100% защите в облаках почитайте историю о том, как и почему Akamai отказался защищать Браина Кребса (Brain Krebs).
Я мыслю в парадигме сетей и защиты от DDoS-атак, которыми занимаюсь больше 10 лет. И основная задача стоит не в том, что просто быстро дропнуть пакеты, а в том чтобы дропнуть нужные пакеты атаки. И в рамках FPGA эту задачу полностью не решить.
На рынке много решений, которые на аппаратном уровне (как на FPGA, так на ASIC'ах стандартных network processor, так и специализированных network security processors, кnowledge-based processor, content processors) делают часть защиты, но современные решения защиты переходят в софтверные реализации, т.к. это более эффективно сразу по многим критериям.
Ну, и для информации. Для работы на wirespeed 10 GbE нужно успевать за 67,2 ns обработать "пакет", мы на обычном CPU обрабатываем на wirespeed 40 GbE.
Резюмируя. В современных реалиях вера в защиту в "облаках" и в аппаратных реализациях необоснованна. Нужен комплексный подход с учетом требований и особенностей объекта защиты.
Обычное серверное железо. Процессоры Intel x86 последних поколений и сетевые контроллеры 82599 и X710.
Если в таких формулировках, то защита на уровне CPU и мимо ядра.
Наш софт для быстрой обработки пакетов использует Intel DPDK.
И от каких атак и какие сервисы такая железка защитит? А какая у нее будет производительность? А хватит ли каналов у хостинг провайдера? А готов ли будет хостинг переплачивать за трафик атаки своим аплинкам из-за проблемного клиента?
DDoS-атаки это общее название большого количества видов атак, которые нацелены на исчерпания ресурсов, в том числе и финансовых.
Поэтому для какого-то сервиса подойдет защита за 300$ и возможные риски простоя не столь критичны. А для другого сервиса многомиллионные вливания в защиту будут недостаточны.
Потому что сервисом и устройством на площадке закрывают разные вектора атак и прикладные задачи.
Ну, если «стартап» ниасилит, то и без него банку плохо будет =) А так, я думаю, у банка есть резервные сценарии работы.
Поддерживаю. Для напоминания оставлю несколько определении:
«Стартап — это компания или временная организация, созданная для поиска повторяемой и масштабируемой бизнес-модели» Стив Бланк (Steve Blank)
«Стартап — это организация, целью которой является создание продуктов и услуг в условиях экстремальной неопределенности» Эрик Рис (Eric Ries)
Ну, и мне особо нравится определение близкое к венчурным инвестициям:
«Стартап — это временная организация, созданная для поиска масштабируемой, повторяемой и прибыльной бизнес-модели в условиях экстремальной неопределенности, с целью быстрого роста» Илья Королев
Если известен реальный IP-адрес ресурса, то можно организовать атаку мимо сервиса защиты.
Даже если на вышестоящем роутере ACL'ем закрыть все адреса, кроме источников туннеля, то все равно можно забить входящие каналы, вплоть до отключения ДЦ или оператора связи.
DDoS устойчивость одной площадки явно меньше, чем у территориально распределенного сервиса по защите от DDoS-атак. Но при использовании сервиса остается риск атаки на "последнюю милю", поэтому нужно выстраивать эшелонированную оборону. Каждый из эшелонов будет лучше подходить для определенных типов DDoS-атак, а количество эшелонов и состав нужно строить исходя из защищаемых ресурсов и сервисов, задач, денег.
Cisco аппаратные железки antiDDoS очень давно не делает. Есть версии софта от Arbor и Radware, которые можно запустить на платформах от Cisco.
Программно можно больше 10 Gbps отражать. Например, наш софт на одном сервере защищает от 40 Gbps и 59 Mpps различных L3-L4 атак.