Вы даже не представляете, какие драмы могут разворачиваться в такой мирной, казалось бы, отрасли, как торговля пиццей. В одной из них довелось поучаствовать и нам, как облачному провайдеру: в декабре 2013 года «Империя пиццы» — один из клиентов Cloud4Y и крупнейшая сеть доставки пиццы в Москве и Московской области, начала интенсивную экспансию на новые территории, на которых уже присутствовали другие игроки.
И у пиццы есть тёмная сторона
Все бы ничего, но имперская ценовая политика в сфере предоставления услуг быстрого питания для его конкурентов имела демпинговый характер. Началась война на всех фронтах, и вскоре в ход пошли DDoS-атаки.
Начало
«Империя пиццы» начала активную рекламную компанию в большой сети городов Подмосковья, начиная от печатной продукции и заканчивая рекламной интернет-кампанией. Проблемы начались, когда эту активность заметили конкуренты – другие сети пиццерий — и перешли к наступлению.
Первое наступление
24 декабря 2013 года война сетей пиццерий перешла на поля высоких технологий. Началась DDoS-атака всех интернет ресурсов нашего клиента, которые располагались у нас.
В первые этапы начала атаки на «Империю», мы выводили их интернет-ресурсы из-под действия атаки перемещением на другие адресные диапазоны. Подобная политика работала совсем недолго, поскольку атакующими отслеживалось расположение клиента и бот-сеть достаточно быстро перенастраивалась. Атака через непродолжительный промежуток времени перемещалась опять в сторону клиента, блокируя его сервисы. Это продолжалось до 31 декабря 2013 года, после чего началась массивная атака всех адресных диапазонов компании Cloud4Y.
Начало массовой атаки
1 января 2014 года началась массовая DDoS-атака всего адресного диапазона Cloud4Y, где располагался клиент. Интенсивность атаки забивала весь внешний пиринг с другими операторами и ударила в потолок пропускной способности всех внешних каналов связи.
В срочном порядке были перенастроены флуд-сенсоры встроенных технологий DDoS защиты на группировке внешних маршрутизаторов, однако, пользы в данной ситуации они приносили недостаточно. Сами маршрутизаторы успешно выдерживали внешние объемы маршрутизации, однако проблемы начались также у вышестоящих операторов связи (часть внешних пиров периодически уходила в даун, не справляясь с коммутацией и маршрутизацией таких потоков данных).
В попытках как-то разгрузить внешние каналы связи мы просили внешних операторов ограничить UDP потоки, чтобы выделить свободные полосы пропускной способности для работы сервисов других наших Клиентов.
Интернет-сервисы нашего клиента, несмотря на любые попытки обслуживающих администраторов, были неработоспособны. Сервера теряли контроль после нескольких секунд после запуска. Правила фаирволинга и ограничений не помогали. Для того, чтобы исключить влияние атаки на работу других клиентов Cloud4Y, виртуальные ресурсы сети пиццерии были перемещены на отдельные гипервизоры. Однако из-за интенсивности атаки SLA предоставляемых Cloud4Y услуг достаточно пострадал:
Подробнее об инциденте можно прочитать на нашем сайте (SLA-монитор доступен на главной странице). Несмотря на столь интенсивную DDoS-атаку, облачные сервисы Cloud4Y были доступны внешним клиентам.
«Гипс снимают, клиент уезжает»
Наш клиент в поисках решения для возобновления работы своих интернет-ресурсов начал дублировать свои ресурсы на мощностях других облачных операторов. После переброски DNS на новые месторасположения, другие облачные операторы (не будем их называть), практически сразу становились недоступными (поскольку мы сами также мониторили происходящую ситуацию не только из интересов любопытства).
Поблуждав по просторам рунета, интернет-ресурсы сети пиццерий постоянно переезжали между дата-центрами Европы, где картина с последствиями атаки повторялась. Последние дата-центры, куда переключался наш клиент, были в Европе (Нидерланды, Германия, Чехословакия). На момент написания данной статьи, интернет-ресурсы клиента находились в дата-центре на островах Вирджинии.
Думаю, наши менеджеры не сильно расстроились после переезда этого клиента, поскольку с его переключением в другие дата-центры интенсивность атаки на Cloud4Y упала, однако профилактическое «поливание дерьмом» в область адресации уже бывшего расположения клиента длилось еще несколько недель.
Вывод
Попав под такую раздачу, было принято решение максимально усилить DDoS-защиту внешнего пиринга Cloud4Y, в результате чего у нас появился прямой выделенный канал до Voxility (лидирующий оператор защиты от любых видов атак, в том числе и DDoS).
Получив максимальную защиту от DDoS как услугу, в течение года после прошлой атаки у Cloud4Y были временные нагрузки, связанные с активностью работы клиентов, а также небольшие нагрузки из-за возможно небольших и непродолжительных DDoS-атак. Но атак мощности, с которой долбили по этой самой пиццерии, больше не случалось. Что делать?
Испытания
Для того, чтобы испытать защиту от DDoS-атак Voxility в действии, Cloud4Y решил сам себя атаковать, для чего была выделена отдельная подсеть, отдельные средства виртуализации и созданы отдельные интернет-ресурсы (подопытные кролики), на которых планировалось провести самые жесткие испытания.
Подготовка
Для проведения испытаний через просторы интернета были найдены исполнители нашего заказа, которые смогли бы реализовать DDoS-атаку такого уровня, и которую мы пережили в конце 2013 – начале 2014 года. Такие исполнители работают всегда анонимно и прямого контакта по телефону с ними не было, однако для реализации задуманного они должны были быть с нами на постоянной связи, чтобы была возможность остановить атаку, если что-то пойдет не так. Такой исполнитель был найден.
Предварительно была перенастроена группировка внешних маршрутизаторов и атакуемые подсети короткими префиксами BGP были смаршрутизированы через Voxility. Технология защиты, реализуемая Voxility имеет следующую архитектуру:
- Посетитель защищенного ресурса прежде всего попадает в облако защиты Voxility, где по умолчанию весь трафик изначально пропускается только в режиме «Анализ».
- В случае обнаружения опасностей, облако Voxility переключается в режим защиты и обращение к сервисам пропускается только в том случае, если состав трафика удовлетворяет Правилам чистоты анализаторов.
- При необходимости, трафик к сервису очищается от вредоносных составляющих и поступает на защищаемые сервисы для обработки.
- Обработанные оконечным сервисом трафик возвращается к запросившему его потребителю.
Испытания планировалось провести в два этапа:
- Пробная атака подопытных кроликов с интенсивностью в 300 Мбит в секунду в течении 30 минут (для того чтобы определить реакцию Voxility).
- Основная атака интенсивностью в 15 Гбит.в секунду в течении 2 часов.
В процессе тестирования этот план мы дополнили третьим этапом, о котором расскажу далее. Перед началом тестирования, мы произвели самостоятельное тестирование, т.е. инициировали DDoS-атаку своих ресурсов своими средствами. Атакуемые кролики располагались в нашем дата-центре в Москве, в то время как свою атаку мы инициировали из нашего ДатаЦентра в Нидерландах. Технологию атаки мы разглашать не будем, однако можем сказать что нам удалось успешно завалить своих кроликов через Voxility, при чем наша атака осталась даже незамеченной облаком Voxility и технологической атакой кролик был успешно завален. Оговоримся сразу – это не была флуд-атака, целью которой была забить все внешние каналы. Таким образом мы только испытали технологические преимущества Voxility при обнаружении сложных типов атак. Сложную атаку Voxility к сожалению не обнаружил, подопытные кролики вооруженные системами кеширования на базе NGINX были успешно завалены в течение продолжительного времени, а сенсоры Voxility так наше вторжение не обнаружили и не обезвредили.
Тестирование
Начиная самотестирование, мы достаточно сильно рисковали тем, что:
1. Защита Voxility могла не справиться;
2. Мы могли потерять связь с атакующими и не могли бы остановить атаку (связь с атакующими велась исключительно по ICQ);
3. В случае падения пиринга с Voxility, мы могли бы получить настоящую DDoS атаку по всем нашим ресурсам, последствия от которой могли бы быть аналогичными предновогодней-новогодней атаке 2013-2014 года.
Первый этап
Атака небольшой мощностью (порядка 300 Мбит) вначале была пропущена Voxility и в течение первых 10 минут наш подопытный кролик выдал ошибку 502. Через 10 минут Voxility обнаружил нашу пробную атаку и перешел в режим защиты нашего канала связи. Подопытные кролики ожили, работа сервисов восстановилась. Voxility отрапортовал нам о прошедшей DDoS-атаке и ее отражении:
Второй этап
По истечению 20 минут пробной атаки, мы попросили атакующих поднять интенсивность атаки до 15 гигабит. Реакция нашего канала связи с Voxility при первом и втором этапе отражены на графике ниже:
Voxility успешно отразил и вторую волну атаки, несмотря на то, что она превышала первую пробную в 45 раз. Интенсивность второй волны атаки соответствовала интенсивности атаки, которую мы выгребли на новогодние праздники по интернет-ресурсам Московской сети пиццерий.
Сервисы на подопытных кроликах оставались работоспособными, Voxility полностью закрыл некоторые сервисы на атакуемой подсети (ICMP).
Третий этап
Удостоверившись, что защита Voxility работает, а также отсутствие проблем с нашим внешним пирингом, мы попросили атакующих показать все что они могут, а могут они как оказалось достаточно много (третья волна видна на графике):
Интенсивность атаки была поднята с 15 гигабит до 50-120 гигабит и как мы видим часть SYN-трафика облако Voxility некоторое время не успевало изучать, и часть вредоносного трафика все-таки стала попадать к нам в канал, однако в любом случае половина тестируемого канала по-прежнему оставалась доступна для прохождения полезного Клиентского трафика. На системах мониторинга с нашей стороны атака выглядела следующим образом:
Итог
По результатам испытания, мы пришли к выводу, что универсальной и идеальной защиты от DDoS и других видов атак не существует, однако примененная нами защита от DDoS-атак «как услуга» от Voxility работает, и позволяет обеспечивать клиентский сервис даже в максимально неблагоприятных условиях.
Спасибо за внимание, с удовольствием отвечу на ваши вопросы.
Война войной, а
Автор: Cloud4Y