[chocholl]

очень интересен ваш опыт.

а можно позадавать нескромные вопросы по этому вендору. вам в какой форме удобнее?

 

 

DDoS'ы разные бывают. Как и инструменты для защиты.

 

Защищать каналы и HTTP-ресурсы от сетевого флуда (TCP-флуда - SYN, Fin+Ack, Reset, SYN+Ack, Fragmentation, а также флуда по UDP, ICMP и IGMP), защищать Web-сервера от http-флуда - относительно легкая задача.

 

Удел Arbor Peakflow SP - только большие распределенные сети крупного оператора. И то, не всё так просто, как в презентациях вендора.

 

Например, что использовать в качестве флоу-сенсоров в уже построенной реально действующей распределенной сети - получать Netflow без семплирования (1:1) от Cisco 7600 с 10GbE каналов?!

 

Общественность вообще в курсе стоимости коллектора Arbor CP5500-5? Или митигатора Arbor TMS 3050?

 

Из реальных решений по крайней мере для датацентров, а также для корпорэйта рекомендую посмотреть тяжелый Radware DefensePro 8412 - до 8Gbps при небольшом количестве политик, честные 10Mpps для всех типов флуда (сказывается наличие на борту двух EZChip NP3), 4 x 10GbE XFP-порта, аппаратный IPS на контекстном процессоре NETL7 компании Netlogic Microsystem. Работает в режиме INLINE, L2-прозрачен. По функционалу - в хорошем смысле сборная солянка нескольких десятков разноплановых механизмов защиты от DDoS-атак, включая поведенческую защиту с DPI и самообучением, аппаратный IPS, BWM, HTTP Mitigator и пр.

 

Для знакомства рекомендую читать UserGuide - http://www.bifit.com/ru/radware/

 

Но в любом случае защита от DDoS-атак стандартный приложений относительно легкая задача :)

 

Другое дело - проприетарные системы типа Интернет-Банкинга и др.

 

Там уже как минимум HTTPS и заглянуть внутрь HTTPS-запроса оператору не представляется возможным без наличия у оного секретного ключа SSL-сертификата, предварительно полученного от заказчика.

 

Для защиты таких приложений уже требуется плотная интеграция инструмента защиты от DDoS-атак с защищаемой прикладной системой.

 

И что самое плохое - мегакритичность легитимного трафика.

 

Если митигатор убъет легитимный клиентский трафик Интернет-Банкинга, когда клиент уровня Газпрома или РЖД (то есть VIP-юрик) не получит доступ к своим банковским счетам из-за плохой работы DDoS-защиты, вот тогда от банка действительно Цунами подымается. По опыту знаем :)

[Dimitry_Repan]

У f5 есть partitions, которые можно сдать в аренду. Как вариант - банк может разместить свой LTM на площадке.

Для промышленных балансировщиков виртуализация сервиса - стандартная фича. Аналогичный механизм есть в Radware Alteon.

 

Например, тяжелый 20Gb-ый Альтеон можно разбить до 28 партиций по 700Мбит каждая. И по отдельности каждую партицию (эдакий виртуальный балансировщик) сдавать в аренду клиенту-заказчику для балансировки запросов на его ферму серверов с HTTP/HTTPS-ресурсами.

 

Отдельный SSL-акселератор - штука достаточно бесполезная. В load balancer'е от него больше пользы.

Кесарю - кесарево.

 

Если заказчику надо снять нагрузку с HTTPS-ресурса да еще и распределить запросы по ферме серверов, и при этом решение должно быть промышленное, с отсутствием единой точки отказа - то конечно же правильным вариантом будет использование работающих в режиме Active-Active двух балансировщиков с SSL-ускорителями на борту.

 

Если же заказчику нужно обеспечить инспекцию IPS'ом трафика, идущего внутри SSL, да еще и с использованием юзеровских самописных сигнатур, да на скоростях в 5..8Gb и 7..10Mpps, да с хранением секретных ключей SSL-сертификатов в HSM'е, сертифицированном по FIPS-140, то спарка Radware DefensePro 8412 IPS & Behavioral Protection + Radware AppXcel 32000 - одно из промышленных решений сей задачи.

 

На VIPRION'ах те же Nitrox'ы разварены на лезвиях. Можно их игнорировать, можно прикупить лицензию и использовать на всю катушку. Проверяли на практике, ~12k новых SSL коннектов в секунду держит не напрягаясь. Из плюсов - SSL negotiation полностью снимается с http-сервера. У nginx он блокирующий.

Да, да, всё верно. И у Radware'овских балансировщиков тоже показатели аналогичные - ведь одни и те же SSL-чипы юзаются :)

 

В нише балансировщиков F5 и Radware - заклятые коллеги-конкуренты :)

 

Кстати, а не пробовали в качестве эксперимента разгонять SSL на сановских серверах с процессорами Sun SPARC T2? Мы на двухсокетном T5240 до 49k хендшекингов разогнали. Сказывается наличие в Ниагарах аппаратного криптоускорителя (8 ядер для ассиметричной криптографии в хендшекинге, и 8 ядер для потокового шифрования трафика на симметричных криптоалгоритмах). Один недостаток у сановских серверов T5240 - цена :)

 

очень интересен ваш опыт. а можно позадавать нескромные вопросы по этому вендору. вам в какой форме удобнее?

Лучше публично, прям в форуме.

 

Но если для Вас критично - можете мылом на repan@bifit.com

[dvolodin]

Кесарю - кесарево.

 

Если заказчику надо снять нагрузку с HTTPS-ресурса да еще и распределить запросы по ферме серверов, и при этом решение должно быть промышленное, с отсутствием единой точки отказа - то конечно же правильным вариантом будет использование работающих в режиме Active-Active двух балансировщиков с SSL-ускорителями на борту.

Тогда уж правильным решением будет размещение оборудования на двух площадках и комбинирование локальной и глобальной балансировки трафика. У f5 есть отличная связка из LTM+GTM. Сами применяли в нескольких решениях. В одном случае одна площадка была в Европе, другая в штатах. Тут уж реально лучше то решение, с которым умеешь работать ;)

 

Защита от DDoS не бывает идеальной, и класть все яйца в одну корзину весьма опрометчиво. С моей точки зрения - услуга защиты от DDoS, заключающаяся в том, что оборудование надо перенести в ДЦ оператора X, чтобы он имел возможность срезать 1,2,3,4Gbit/s мусора - все это попахивает профанацией вперемешку с самоуспокоением. Успешную защиту можно

выстроить только комбинируя различные методы - разнося оборудования по разным ДЦ, цепляя за сети разных операторов, комбинируя различные методики защиты от DDoS

и держа достаточно свободной полосы.

 

Кстати, а не пробовали в качестве эксперимента разгонять SSL на сановских серверах с процессорами Sun SPARC T2? Мы на двухсокетном T5240 до 49k хендшекингов разогнали. Сказывается наличие в Ниагарах аппаратного криптоускорителя (8 ядер для ассиметричной криптографии в хендшекинге, и 8 ядер для потокового шифрования трафика на симметричных криптоалгоритмах). Один недостаток у сановских серверов T5240 - цена :)

Можно просто сервак платами с nitrox'ами забить :) С другой стороны, можно и вендора по цене просадить так, чтобы не тратить время на изобретение велосипеда :)

[bifit]

Успешную защиту можно выстроить только комбинируя различные методы - разнося оборудования по разным ДЦ, цепляя за сети разных операторов, комбинируя различные методики защиты от DDoS и держа достаточно свободной полосы.

Типично операторский подход, навеянный опытом защиты типовых HTTP-ресурсов, которые действительно можно разносить да хоть по разным континентам :)

 

Но есть еще и жизнь. Есть реальные крупнейшие московские банки, входящие в первую десятку по любым ЦБ-шным показателям, и имеющие при этом суммарную пропускную способность всех своих интернет-каналов менее 100Мбит. И таким банкам "DDoS" в 100Мбит - уже "смерть".

 

И идут такие банки к своим провайдерам и покупают услуги защиты от DDoS-атак.

 

Но оные услуги нихрена не помогают, ибо защищаемые ресурсы - HTTPS-сервера или какой-нибудь проприетарный BS-Defendor, и боты банальным примитивным прикладным HTTPS-флудом убивают и все "каналы" банка, и очень ответственное приложение - сервера Банк-Клиента. И ни Гарды одного оператора, ни Арборы другого, ни Radware'ы третьего оператора ничего полезного сделать не могут :(

 

И нужны мозги разработчика приложения плюс здесь как раз упоминаемые Вами комбинированные методики - требуется интеграция ответственного приложения с операторскими системами защиты от DDoS-атак.

 

И если оператор будет реально очень аккуратно хотя бы "срезать 1, 2 или 4Gb DDoS-мусора", при этом деликатно оставляя ВЕСЬ легитимный трафик нетронутым дабы VIP'ы не взвыли из-за недоступности Банк-Клиента - вот тогда к такому оператору или сервис-провайдеру очередь от банков выстроится.

 

И DDoS на банки идет, кстати, не из-за баловства или попытки шантажа, а для прикрытия реально совершаемого хищения средств со счетов юрика по Банк-Клиенту с использованием злоумышленником ранее похищенных троянами файлов с секретными ключами ЭЦП клиентов и введенных пользователями паролей. И так временами по нескольку яхт у юриков уплывает :(

 

 

 

Изменено 28 июля, 2010 пользователем bifit

[bifit]

Можно просто сервак платами с nitrox'ами забить

А Вы пытались хотя бы раз легитимно по-белому завезти в Россию импортное шифровальное средство?!

 

Ну, например, в виде как раз PCI-плат с SSL-чипами того же Cavium'а или Broadcom'а?

 

Поэтому так с легкой руки рассуждать о забивании сервака платами с nitrox'ами - ну как-то совсем по-простецки. На price.ru таких плат точно не купить :)))

[chocholl]

Дмитрий, написал вам в личку.

 

 

У f5 есть partitions, которые можно сдать в аренду. Как вариант - банк может разместить свой LTM на площадке.

Для промышленных балансировщиков виртуализация сервиса - стандартная фича. Аналогичный механизм есть в Radware Alteon.

 

Например, тяжелый 20Gb-ый Альтеон можно разбить до 28 партиций по 700Мбит каждая. И по отдельности каждую партицию (эдакий виртуальный балансировщик) сдавать в аренду клиенту-заказчику для балансировки запросов на его ферму серверов с HTTP/HTTPS-ресурсами.

 

Отдельный SSL-акселератор - штука достаточно бесполезная. В load balancer'е от него больше пользы.

Кесарю - кесарево.

 

Если заказчику надо снять нагрузку с HTTPS-ресурса да еще и распределить запросы по ферме серверов, и при этом решение должно быть промышленное, с отсутствием единой точки отказа - то конечно же правильным вариантом будет использование работающих в режиме Active-Active двух балансировщиков с SSL-ускорителями на борту.

 

Если же заказчику нужно обеспечить инспекцию IPS'ом трафика, идущего внутри SSL, да еще и с использованием юзеровских самописных сигнатур, да на скоростях в 5..8Gb и 7..10Mpps, да с хранением секретных ключей SSL-сертификатов в HSM'е, сертифицированном по FIPS-140, то спарка Radware DefensePro 8412 IPS & Behavioral Protection + Radware AppXcel 32000 - одно из промышленных решений сей задачи.

 

На VIPRION'ах те же Nitrox'ы разварены на лезвиях. Можно их игнорировать, можно прикупить лицензию и использовать на всю катушку. Проверяли на практике, ~12k новых SSL коннектов в секунду держит не напрягаясь. Из плюсов - SSL negotiation полностью снимается с http-сервера. У nginx он блокирующий.

Да, да, всё верно. И у Radware'овских балансировщиков тоже показатели аналогичные - ведь одни и те же SSL-чипы юзаются :)

 

В нише балансировщиков F5 и Radware - заклятые коллеги-конкуренты :)

 

Кстати, а не пробовали в качестве эксперимента разгонять SSL на сановских серверах с процессорами Sun SPARC T2? Мы на двухсокетном T5240 до 49k хендшекингов разогнали. Сказывается наличие в Ниагарах аппаратного криптоускорителя (8 ядер для ассиметричной криптографии в хендшекинге, и 8 ядер для потокового шифрования трафика на симметричных криптоалгоритмах). Один недостаток у сановских серверов T5240 - цена :)

 

очень интересен ваш опыт. а можно позадавать нескромные вопросы по этому вендору. вам в какой форме удобнее?

Лучше публично, прям в форуме.

 

Но если для Вас критично - можете мылом на repan@bifit.com

[dvolodin]

А Вы пытались хотя бы раз легитимно по-белому завезти в Россию импортное шифровальное средство?!

 

Ну, например, в виде как раз PCI-плат с SSL-чипами того же Cavium'а или Broadcom'а?

 

Поэтому так с легкой руки рассуждать о забивании сервака платами с nitrox'ами - ну как-то совсем по-простецки. На price.ru таких плат точно не купить :)))

Давайте все-таки разделять, для себя привозить, или на продажу. Средства узкоспециальные, на price.ru явно продаваться не будут :)

А для себя десяток-другой плат привезти, проблем не составит :)

[dvolodin]

И если оператор будет реально очень аккуратно хотя бы "срезать 1, 2 или 4Gb DDoS-мусора", при этом деликатно оставляя ВЕСЬ легитимный трафик нетронутым дабы VIP'ы не взвыли из-за недоступности Банк-Клиента - вот тогда к такому оператору или сервис-провайдеру очередь от банков выстроится.

Опять же - не срежут, так как ssl offload'инг на оператора банк делать не будет. Все, что останется делать банку - покупать этот злополучный гиг-два-три-четыре, снимать SSL и дальше чистить

самостоятельно.

 

[bifit]

Опять же - не срежут, так как ssl offload'инг на оператора банк делать не будет. Все, что останется делать банку - покупать этот злополучный гиг-два-три-четыре, снимать SSL и дальше чистить самостоятельно.

Бороться с HTTPS-флудом можно и нужно. Но для этого нужна интеграция прикладного решения с системой DDoS-защиты оператора.

 

SSL со спуффингом не может быть чисто технически :)

 

Поэтому если SSL-сессия открылась - то это либо легитимный клиент, либо бот.

 

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

 

Как выявили бота - направляем в систему DDoS-защиты оператора поручение забанить IP бота на NN-ое время. Всё, естественно, на автомате.

 

Пороги в разрезе запрашиваемых HTTPS-ресурсов устанавливаются либо чисто ручками, либо с самообучением + ручками.

 

Так снимается нагрузка на канал клиента.

[Smersh]

На Radware свет клином не сошелся, к тому же CLI у него хреновенький. Мне понравились балансировщики Brocade ADX, может молоть трафик со скоростью до 70 ГБит/с и SSL трафик до 13 ГБит/с защита от дидос - до 120млн ппс.

З.Ы. И вообще от радваре аппдиреткора у меня субьективно плохие воспоминания, куча глюков, скудная документация, невероятный синтаксис командной строки, и русский саппорт радваре, а также проблемы с настройкой high avaiblity конфигураций.

Изменено 7 сентября, 2010 пользователем Smersh