Перейти к содержимому
Калькуляторы

"Акадо-Телеком": "В начале года мы обучались на «живых» клиентах"

Материал:

Защита от DDoS - явный тренд сезона, причем не в теоретическом, а уже в практическом плане. С запросами о такой услуге к сервис-провайдерам обращаются не только крупные корпоративные клиенты - это интересует компании любого уровня, которые зарабатывают деньги в Сети. Одной из компаний, которая об этом подумала является "Акадо-Телеком" - в коммерческий режиме услуга "Защита от DDoS" будет представлена в конце августа, но нам удалось побеседовать об этом с первым заместителем генерального директора, техническим директором компании Юрием Скобелевым.

 

Полный текст

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какая-то рекламная байда. Уж извините.
Вы настоящей рекламной байды не видели. :-)

Любой "саморасказчик" будет выставлять себя в позитивном свете, это нормальная объективная реальность.

Т.е. для этого жанра статья, на мой взгляд, хороша - много реальных цифр, да и вполне объективно все...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость nerik

Согласен с nag'ом. Статья неплохая, хоть и присутствует в ней скрытая реклама. Мне понравилось)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость Василий

Ну цифра тут только одна - сколько готовы брать с клиента. Все остальные цифры по скоростям не информативные. Ну и единственное что интересно - на базе чего это сделано "Arbor Networks" И скорость порта 1Gb/s

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость doctorsoul (автор материала)

В материала отражена ситуация по конкретному оператору с максимально возможной детализацией. По крайней мере это дает возможность сделать выбор - идти к ним или к другим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

атака:

ботнет в 50к зомби, начинает обращаться к web-магазину и шарить по каталогу товаров, маскируясь под обычные запросы браузера. Траф подскакивает в 10 раз апач и база падает, загрузка проца 100%

 

пожалуйста опишите способ очистки трафа

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну цифра тут только одна - сколько готовы брать с клиента. Все остальные цифры по скоростям не информативные. Ну и единственное что интересно - на базе чего это сделано "Arbor Networks" И скорость порта 1Gb/s

Вот тут коренной вопрос - если порты (много:)) по 10 GE и фикисированный платеж , хоть по несколько Кило-уе, это хорошо и это для операторов. Если 1GE и стоимость защиты +50-100% от рыночной стоимости полосы, это для банков и т.п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость bifit

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-защиты, вот тогда от банка действительно Цунами подымается. По опыту знаем :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

клиент уровня Газпрома или РЖД (то есть VIP-юрик)

Таких в белые списки не сложно затолкать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Гость bifit

Так ведь Газпром - это же Холдинг, то есть большое множество юриков - дочки, внучки , правнучки и праправнучки. Вплоть до газораспределительной станции в Урюпинске.

 

И опять же, куда прикажите IP-адреса этих юриков заносить?

 

А если TCP SYN flood со спуфингом, и при этом в качестве IP-адреса отправителя злоумышленник указывает IP-адреса этих всех легитимных юриков?

 

Многие и как часто сталкиваются с боевым SYN-флудом со спуфингом в ~7Gbps и ~10Mpps ? Кто, чем и как борется?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Таких в белые списки не сложно затолкать.
На счет несложно - http://www.vedomosti.ru/newspaper/opinions/2010/07/26/241578

 

Хакеры увели клиента

Владелец процессинговой системы Assist лишился одного из основных клиентов - «Аэрофлота» из-за хакерской атаки, на борьбу с последствиями которой ушла неделя. Авиакомпания перейдет на аналогичную систему Альфа-банка

Аэрофлот» был вынужден приостановить онлайн-продажу билетов на неделю с 16 по 22 июля, а в пятницу возобновил прием платежей в интернете

Персональные данные клиентов не пострадали, но оплачивать билеты через интернет было невозможно, говорит представитель «Аэрофлота» Ирина Данненберг.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сначала заходите люди добрые, берите что хотите!

А потом - спасите от супостата проклятого с его распределенной атакой!

Последствия экономики Интернета - нате вам пацаны по сто мегабит на халяву. Вот и зарабатывают как могут - организуют распределенные атаки за деньги с халявных полос.

Клиент должен платить за исходящий с него трафик, а не за безлимитную двухстороннюю полосу. Тогда будет и с вирусами, спамом, ботнетами бороться. Вплоть до физического отключения от сети в нерабочее время.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Клиент должен платить за исходящий с него трафик, а не за безлимитную двухстороннюю полосу. Тогда будет и с вирусами, спамом, ботнетами бороться. Вплоть до физического отключения от сети в нерабочее время.

Вы бы весь список привели, что Клиент должен. А то так то недосказанно получаеться

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Это где это у вас реально действующая сеть с netflow без сэмплирования на 10ж скоростях с 76?!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И я об этом же.

 

То есть далеко не у каждого оператора стоит в ядре железка, способная без особого напряга выполнять еще и функцию флоусенсора, выдавая netflow с потока в 10Gb и более.

 

76-я при netflow с потока 1Gb почти умирает :)

 

В идеале увидеть бы в форуме реальные, а не лабораторные схемы внедрения Arbor Peakflow SP.

 

Такой-то оператор, собираем с таких-то железок информацию о проходящем XX Gb трафике по netflow/сflow/jflow/sflow. Направляем информацию о трафике в такой-то коллектор (например, CP5500-5), обслуживающий реально такое-то количество флоусенсоров. Суммарный flow-трафик на коллектор - столько-то Mb или Gb.

 

Или же кто-то из операторов в продакшене использует софтверный арборовский флоусенсор на базе обычного интеловского сервера с обычной сетевой картой?!

 

Далее. Для предотвращения DDoS-атак используем такой-то митигатор (например, TMS-3110), подключенный такими-то линками к ядру. Или же митигатор не используем, а коллектор банально управляет ACL на роутере.

 

Вот такая история была бы интересна многим :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот такая история была бы интересна многим :)
Пока есть только забавная антиистория. Через несколько дней опубликуем - будет понятнее.

А пот по позитиву - может поделитесь данными и опытом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы бы весь список привели, что Клиент должен. А то так то недосказанно получаеться
А зачем? Практика говорит о том, что однократное попадание клиентом на бабки делает его супер предприимчивым по части экономии средств на связи. Клавишу выкл. находит быстро...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Могу поделиться своими личными субъективными выводами:

 

1. Тема защиты от DDoS-атак - топиковая.

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

 

2. Идеального решения для защиты от DDoS-атак, так чтобы поставил и забыл - не существует.

 

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

 

4. К решениям стартапов надо подходить очень аккуратно и всё щупать лично в боевых условиях как минимум месяц.

 

5. При знакомстве с решением обязательным является "засовывать пятак" во все внутренности решения - софтверная или хардварная реализация.

Если хардварная, то какая конкретно - на универсальных сетевых процессорах типа EZChip NP3 или на топовых FPGA типа Xilinx Virtex-6 HXT.

Какие конкретно механизмы для защиты от каких конкретно DDoS-атак реализованы хардварно. Какие ТТХ в итоге - Gbps, Mpps, cps и пр.

 

6. Чистый IPS типа Cisco 4270, и даже хардварно прокаченный IPS с использованием конктекстных процессоров и/или FPGA (Force10Network P10) не спасает от всего разнообразия DDoS-атак.

 

7. Для централизованных внедрений - то есть для корпорэйта и датацентров/хостеров - могу рекомендовать только одно решение - Radware DefensePro на платформе ODS 3S2 с EZChip NP3 на борту и firmware 5.x.

 

Соответственно для старта можно взять решение на 4Gb - Radware DefensePro 4412 IPS & Behavioral Protection (GPL 132k$).

 

При необходимости можно оперативно (софтверно) раскрыть железку до 8Gb (GPL +64k$).

 

Решение не идеальное, но своих денег точно стоит. При вдумчивой настройке в разрезе защищаемых приложений чистит довольно тонко. Затраты отрабатывает сполна. Из плюсов - есть API для интеграции с проприетарными приложениями типа Интернет-Банкинга и подобных систем. Из минусов - ИМХО, не годится для ЦЕНТРАЛИЗОВАННОЙ защиты географически распределенной операторской сети, IPv6 не везде поддерживает хардварно, весь функционал доступен только при включении "inline". Хотя в начале 2010 года Франстелеком взял около 150 самых тяжелых DefensePro-8412.

 

 

8. Для ЦЕНТРАЛИЗОВАННОЙ защиты от DDoS-атак географически распределенных операторских сетей ничего кроме Arbor Peakflow SP рекомендовать не буду.

Решение универсально, исключительно операторского класса и ориентировано на оказание клиентам услуг по очистке трафика.

Масштабируется горизонтально и вертикально. Самое то для операторов уровня Ростелеком с его бюджетами.

 

Из минусов:

 

- чистит грубо, реагирует с задержками, временами требует "пинка" админа; для оператора всплеск 50 Мбит что слону булочка, а для корпорэйта с каналом в десяток мегабит - смерть.

 

- требует соответствующей инфраструктуры от оператора - надо как-то собирать информацию о трафике; чем с меньшим прореживанием (с большей точностью) собираем инфу о трафике - тем больше нагрузка на маршрутизаторы (уже упоминалось, что Cisco 7600 не может без надрыва отдавать Netflow с трафика даже в 1Gb)

 

- бесполезен при защите Web-серверов от HTTPS-флуда, а также проприетарных Internet-приложений

 

- стоит как самолет (подержанный); в прямом смысле слова :)

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Сухой остаток: и в Акаде появились (или выросли) специалисты... Мы тут вобщем все, во внутримкадье не лаптем щи хлебаем =)

Изменено пользователем homeless

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для HTTP и HTTPS интересное решение есть у f5 (VIPRION). Помимо SSL-offloading'а есть еще обучаемые application profiles. В качестве бонуса и основного назначения - load balancer.

Ну и в целом не мешает припереть чем-то вроде Juniper SRX.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Практика говорит о том, что однократное попадание клиентом на бабки делает его супер предприимчивым по части экономии средств на связи. Клавишу "выкл. дурн. пров." находит быстро...

Именно на этом и появились, и внедрились анлимиты. Обычный человек не хочет, чтобы его за его же деньги заставляли думать. Поэтому проще чуть переплатить, но не думать о том, что тебе неинтересно. Что, в общем-то, логично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вариант с SSL-offloading требует передачи секретного ключа SSL-сертификата от клиента-заказчика к оператору дабы оператор загрузил секретный ключ в своё решение для защиты HTTPS-ресурса клиента от прикладных DDoS-атак.

 

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

 

На то банк и применяет SSL, чтобы никто, в том числе и операторы, не мог посмотреть информацию интернет-банкинга.

 

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

 

Кстати, такие механизмы балансировки и просмотра SSL-трафика есть не только у F5 :)

 

У Radware также есть несколько линеек балансировщиков AppDirector XL с набортными аппаратными криптоускорителями для SSL-offloading'а на базе Cavium'овских чипов Nitrox XL, и даже есть (вернее была) отдельная линейка чисто SSL-ускорителей Radware AppXcel, которые могли подключаться к Radware DefensePro и при наличие секретных ключей SSL-сертификатов защищаемых от DDoS-атак HTTPS-ресурсов, позволяли делать HTTPS Mitigation.

 

Но рынок такого сервиса еще более узок, чем просто защита от DDoS-атак обычного Web-сайта, и если заказчик решает серьезно защищать свой HTTPS-сервис от всего спектра DDoS-атак, тогда предполагается наличие соответствующего бюджета у банка-заказчика на покупку нужного решения и размещение оного у оператора в дата-центре (желательно подключаться в ядро по 10GbE).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Именно на этом и появились, и внедрились анлимиты. Обычный человек не хочет, чтобы его за его же деньги заставляли думать. Поэтому проще чуть переплатить, но не думать о том, что тебе неинтересно. Что, в общем-то, логично.
Алогично.

Думать не надо при любом тарифном плане, если план честный, условия прочитаны и осознаны, приняты и подписаны.

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

 

Анлимиты появились как результат жадности помноженной на глупость. Обезьянья потребность провайдера находиться в полосе сбыта и роста абонентской базы.

Но практика говорит, что эти безлимиты с душком. Потому что либо с оговоркой до, либо с прямым указанием - 10 ГБайт, а потом до 64Кбит до конца месяца.

В общем - всем надо жить, изготовителям, разработчикам, поставщикам услуг. А по известной пословице: "Не наипешь - не проживешь!" Вот и следуют заветам. А фигли мол делать - капитализм, дикий и подлый... Вот и рассуждаем с умным видом - куда нам бедным без Арбора с портами на 10ГЕ.

А зачем думать и напрягаться - деньги заплачены и "... человек не хочет, чтобы его за его же деньги заставляли думать. Поэтому проще чуть переплатить, но не думать о том, что тебе неинтересно. Что, в общем-то, логично..."

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На то банк и применяет SSL, чтобы никто, в том числе и операторы, не мог посмотреть информацию интернет-банкинга.

 

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

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

 

У Radware также есть несколько линеек балансировщиков AppDirector XL с набортными аппаратными криптоускорителями для SSL-offloading'а на базе Cavium'овских чипов Nitrox XL, и даже есть (вернее была) отдельная линейка чисто SSL-ускорителей Radware AppXcel, которые могли подключаться к Radware DefensePro и при наличие секретных ключей SSL-сертификатов защищаемых от DDoS-атак HTTPS-ресурсов, позволяли делать HTTPS Mitigation.
Отдельный SSL-акселератор - штука достаточно бесполезная. В load balancer'е от него больше пользы.

 

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

 

Сайты, работающие под нагрузкой - это отдельная тема. От ДЦ требуется только размещение оборудования. Остальная мишура, как правило, неинтересна.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.