chocholl Опубликовано 28 июля, 2010 · Жалоба очень интересен ваш опыт. а можно позадавать нескромные вопросы по этому вендору. вам в какой форме удобнее? 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-защиты, вот тогда от банка действительно Цунами подымается. По опыту знаем :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimitry_Repan Опубликовано 28 июля, 2010 · Жалоба У 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 28 июля, 2010 · Жалоба Кесарю - кесарево. Если заказчику надо снять нагрузку с 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'ами забить :) С другой стороны, можно и вендора по цене просадить так, чтобы не тратить время на изобретение велосипеда :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bifit Опубликовано 28 июля, 2010 (изменено) · Жалоба Успешную защиту можно выстроить только комбинируя различные методы - разнося оборудования по разным ДЦ, цепляя за сети разных операторов, комбинируя различные методики защиты от DDoS и держа достаточно свободной полосы. Типично операторский подход, навеянный опытом защиты типовых HTTP-ресурсов, которые действительно можно разносить да хоть по разным континентам :) Но есть еще и жизнь. Есть реальные крупнейшие московские банки, входящие в первую десятку по любым ЦБ-шным показателям, и имеющие при этом суммарную пропускную способность всех своих интернет-каналов менее 100Мбит. И таким банкам "DDoS" в 100Мбит - уже "смерть". И идут такие банки к своим провайдерам и покупают услуги защиты от DDoS-атак. Но оные услуги нихрена не помогают, ибо защищаемые ресурсы - HTTPS-сервера или какой-нибудь проприетарный BS-Defendor, и боты банальным примитивным прикладным HTTPS-флудом убивают и все "каналы" банка, и очень ответственное приложение - сервера Банк-Клиента. И ни Гарды одного оператора, ни Арборы другого, ни Radware'ы третьего оператора ничего полезного сделать не могут :( И нужны мозги разработчика приложения плюс здесь как раз упоминаемые Вами комбинированные методики - требуется интеграция ответственного приложения с операторскими системами защиты от DDoS-атак. И если оператор будет реально очень аккуратно хотя бы "срезать 1, 2 или 4Gb DDoS-мусора", при этом деликатно оставляя ВЕСЬ легитимный трафик нетронутым дабы VIP'ы не взвыли из-за недоступности Банк-Клиента - вот тогда к такому оператору или сервис-провайдеру очередь от банков выстроится. И DDoS на банки идет, кстати, не из-за баловства или попытки шантажа, а для прикрытия реально совершаемого хищения средств со счетов юрика по Банк-Клиенту с использованием злоумышленником ранее похищенных троянами файлов с секретными ключами ЭЦП клиентов и введенных пользователями паролей. И так временами по нескольку яхт у юриков уплывает :( Изменено 28 июля, 2010 пользователем bifit Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bifit Опубликовано 28 июля, 2010 · Жалоба Можно просто сервак платами с nitrox'ами забитьА Вы пытались хотя бы раз легитимно по-белому завезти в Россию импортное шифровальное средство?! Ну, например, в виде как раз PCI-плат с SSL-чипами того же Cavium'а или Broadcom'а? Поэтому так с легкой руки рассуждать о забивании сервака платами с nitrox'ами - ну как-то совсем по-простецки. На price.ru таких плат точно не купить :))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 29 июля, 2010 · Жалоба Дмитрий, написал вам в личку. У 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 29 июля, 2010 · Жалоба А Вы пытались хотя бы раз легитимно по-белому завезти в Россию импортное шифровальное средство?! Ну, например, в виде как раз PCI-плат с SSL-чипами того же Cavium'а или Broadcom'а? Поэтому так с легкой руки рассуждать о забивании сервака платами с nitrox'ами - ну как-то совсем по-простецки. На price.ru таких плат точно не купить :))) Давайте все-таки разделять, для себя привозить, или на продажу. Средства узкоспециальные, на price.ru явно продаваться не будут :)А для себя десяток-другой плат привезти, проблем не составит :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 29 июля, 2010 · Жалоба И если оператор будет реально очень аккуратно хотя бы "срезать 1, 2 или 4Gb DDoS-мусора", при этом деликатно оставляя ВЕСЬ легитимный трафик нетронутым дабы VIP'ы не взвыли из-за недоступности Банк-Клиента - вот тогда к такому оператору или сервис-провайдеру очередь от банков выстроится.Опять же - не срежут, так как ssl offload'инг на оператора банк делать не будет. Все, что останется делать банку - покупать этот злополучный гиг-два-три-четыре, снимать SSL и дальше чиститьсамостоятельно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bifit Опубликовано 29 июля, 2010 · Жалоба Опять же - не срежут, так как ssl offload'инг на оператора банк делать не будет. Все, что останется делать банку - покупать этот злополучный гиг-два-три-четыре, снимать SSL и дальше чистить самостоятельно. Бороться с HTTPS-флудом можно и нужно. Но для этого нужна интеграция прикладного решения с системой DDoS-защиты оператора. SSL со спуффингом не может быть чисто технически :) Поэтому если SSL-сессия открылась - то это либо легитимный клиент, либо бот. Далее приложение своими средствами должно выявлять чрезмерно активные хосты, запрашивающие слишком много информации да еще и по шаблону/сигнатуре. Или же сливать эту информацию в отдельно стоящий коллектор, который выполняет аналитику. Как выявили бота - направляем в систему DDoS-защиты оператора поручение забанить IP бота на NN-ое время. Всё, естественно, на автомате. Пороги в разрезе запрашиваемых HTTPS-ресурсов устанавливаются либо чисто ручками, либо с самообучением + ручками. Так снимается нагрузка на канал клиента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smersh Опубликовано 7 сентября, 2010 (изменено) · Жалоба На Radware свет клином не сошелся, к тому же CLI у него хреновенький. Мне понравились балансировщики Brocade ADX, может молоть трафик со скоростью до 70 ГБит/с и SSL трафик до 13 ГБит/с защита от дидос - до 120млн ппс. З.Ы. И вообще от радваре аппдиреткора у меня субьективно плохие воспоминания, куча глюков, скудная документация, невероятный синтаксис командной строки, и русский саппорт радваре, а также проблемы с настройкой high avaiblity конфигураций. Изменено 7 сентября, 2010 пользователем Smersh Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...