Вы даже не представляете, какие драмы могут развернуться в такой, казалось бы, мирной отрасли, как торговля пиццей.
Нам, как облачному провайдеру, довелось поучаствовать в одном из них: в декабре 2013 года одним из клиентов была Pizza Empire. Cloud4Y и крупнейшая сеть доставки пиццы в Москве и Московской области начала интенсивную экспансию на новые территории, где уже присутствовали другие игроки.
И у пиццы есть темная сторона
Все бы ничего, но имперская ценовая политика в сфере оказания услуг быстрого питания конкурентам носила демпинговый характер.
Началась война по всем фронтам, вскоре были применены DDoS-атаки.
Начинать
«Империя Пиццы» начала активную рекламную кампанию в крупной сети городов Московской области, начиная от печатной продукции и заканчивая рекламной кампанией в Интернете.Проблемы начались, когда конкуренты – другие сети пиццерий – заметили эту активность и перешли в наступление.
Первое наступление
24 декабря 2013 года война между сетями пиццерий перешла в сферу высоких технологий.
Началась DDoS-атака на все интернет-ресурсы нашего клиента, которые находились у нас.
На первых этапах атаки на Empire мы вывели из-под атаки их интернет-ресурсы, переместив их в другие диапазоны адресов.
Эта политика работала недолго, поскольку злоумышленники отслеживали местонахождение клиента и ботнет быстро перенастраивался.
Через небольшой промежуток времени атака снова переместилась на клиента, заблокировав его сервисы.
Так продолжалось до 31 декабря 2013 года, после чего началась массированная атака на все диапазоны адресов Cloud4Y. 
Начало массированной атаки
1 января 2014 года началась массированная DDoS-атака на весь диапазон адресов Cloud4Y, где находился клиент. Интенсивность атаки превзошла весь внешний пиринг с другими операторами и достигла потолка пропускной способности всех внешних каналов связи.Датчики флуда встроенных технологий защиты от DDoS на группе внешних маршрутизаторов были срочно перенастроены, однако в данной ситуации они не принесли достаточной пользы.
Сами роутеры успешно выдерживали объемы внешней маршрутизации, но начались проблемы и с операторами связи более высокого уровня (периодически выходили из строя некоторые внешние пиры, не справляясь с коммутацией и маршрутизацией таких потоков данных).
В попытке хоть как-то разгрузить внешние каналы связи, мы попросили внешних операторов ограничить UDP-потоки, чтобы выделить свободную полосу пропускания для услуг других наших Клиентов.
Интернет-сервисы нашего клиента, несмотря на все попытки обслуживающих администраторов, не работали.
Серверы потеряли управление через несколько секунд после запуска.
Брандмауэр и правила ограничения не помогли.
Чтобы исключить влияние атаки на работу других клиентов Cloud4Y, виртуальные ресурсы сети пиццерий были вынесены на отдельные гипервизоры.
Однако из-за интенсивности атаки соглашение об уровне обслуживания сервисов, предоставляемых Cloud4Y, сильно пострадало: 
Подробнее о происшествии вы можете прочитать на нашем Веб-сайт (Монитор SLA доступен на главной странице).
Несмотря на столь интенсивную DDoS-атаку, облачные сервисы Cloud4Y были доступны внешним клиентам.
«Гипюр снимается, клиент уходит»
Наш клиент в поисках решения по возобновлению работы своих интернет-ресурсов начал дублировать свои ресурсы на мощностях других облачных операторов.После переноса DNS в новые локации другие облачные операторы (не будем их называть) практически сразу стали недоступны (поскольку мы сами тоже следили за происходящей ситуацией не только из любопытства).
Побродив по просторам Рунета, интернет-ресурсы сети пиццерий постоянно перемещались между дата-центрами Европы, где повторялась картина с последствиями атаки.
Последние дата-центры, на которые перешел наш клиент, находились в Европе (Нидерланды, Германия, Чехия).
На момент написания статьи интернет-ресурсы клиента находились в дата-центре на Виргинских островах.
Думаю, наши менеджеры не сильно расстроились после переезда этого клиента, так как с его переходом в другие дата-центры интенсивность атаки на Cloud4Y упала, однако превентивное «забрасывание говном» в адресную зону бывшего клиента локация продолжалась еще несколько недель.
Заключение
Попав под такую раздачу, было принято решение максимально усилить DDoS-защиту внешнего пиринга Cloud4Y, в результате чего у нас теперь есть прямой выделенный канал к Voxility (ведущему оператору защиты от всех типов атак, включая DDoS)..
Получив максимальную защиту от DDoS в качестве услуги, в течение года после последней атаки Cloud4Y испытывала временные нагрузки из-за активности клиентов, а также небольшие нагрузки из-за возможно небольших и кратковременных DDoS-атак.
Но силовых атак, с которыми они долбили эту самую пиццерию, больше не было.
Что делать?
Тесты
Чтобы проверить защиту Voxility от DDoS-атак в действии, Cloud4Y решил атаковать саму себя, для чего была выделена отдельная подсеть, созданы отдельные инструменты виртуализации, а также созданы отдельные интернет-ресурсы (подопытные кролики), на которых были запланированы самые строгие тесты.будет осуществляться.
Подготовка
Для проведения тестов через Интернет мы нашли по нашему заказу подрядчиков, способных реализовать DDoS-атаку такого уровня, с которой мы столкнулись в конце 2013 – начале 2014 года.Такие исполнители всегда работают анонимно и прямого контакта с ними не было.
телефон, но для реализации своего плана им нужно было быть с нами на постоянной связи, чтобы можно было остановить атаку, если что-то пойдет не так.
Такой исполнитель нашелся.
Группировка внешних маршрутизаторов предварительно была перенастроена и атакованные подсети с короткими префиксами BGP маршрутизировались через Voxility. Технология защиты, реализованная Voxility, имеет следующую архитектуру: 
- Посетитель защищенного ресурса сначала попадает в облако защиты Voxility, где по умолчанию изначально весь трафик передается только в режиме «Анализ».
- При обнаружении угроз облако Voxility переходит в режим защиты и доступ к сервисам пропускается только в том случае, если состав трафика удовлетворяет Правилам чистоты анализатора.
- При необходимости трафик сервиса очищается от вредоносных компонентов и отправляется на обработку защищенным сервисам.
- Трафик, обработанный конечной службой, возвращается потребителю, который его запросил.
- Тестовая атака морских свинок интенсивностью 300 Мбит в секунду в течение 30 минут (для определения реакции Воксилити).
- Основная атака интенсивностью 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 работает и позволяет предоставить заказчику обслуживание даже в самых неблагоприятных условиях.Спасибо за внимание, буду рад ответить на ваши вопросы.
Война войной, а хостинг идет по расписанию! 
Теги: #информационная безопасность #ddos #ddos-атака #ddos-защита #ddos-защита #облачные сервисы #cloud service
-
Защитите Свой Реестр
19 Oct, 24 -
Firefox 3 Альфа 2
19 Oct, 24 -
Свяжитесь С Дизайнером
19 Oct, 24 -
Музыка Является Неотъемлемой Частью Меня
19 Oct, 24 -
Цнии 2007
19 Oct, 24 -
Танцующий Бендер В Css3
19 Oct, 24
