Как King Servers DDoS-атаку на своих клиентов отражал
Итак, несколько недель назад нашими клиентами стали несколько крупных новостных сайтов из ближнего зарубежья. Прежде, чем подписать договор, мы были предупреждены о том, что на эти ресурсы может быть совершена мощная DDoS-атака, хотя конкретики не было - кто будет атаковать, почему и с какой мощностью.
Опыт отражения DDoS-атак у нас есть, поэтому мы согласились работать вместе. Сайты перебрались к нам и несколько дней после этого работали в штатном режиме. Но через 4 дня мы поняли, что "не все так хорошо в королевстве Датском". На сайты обрушилась DDoS-атака, причем весьма мощная.
Совокупная мощность потока достигала 300 Гбит/с, злоумышленники использовали для атаки на ресурсы http-протокол. У нашей компании есть собственная система защиты от атак подобного рода, которая и отфильтровала большую часть пакетов от атакующих адресов. Клиенты оказались тоже опытными, представители партнерской компании оптимизировали свои веб-сервера самостоятельно. Тем не менее, часть запросов все же прошла через заслоны. И хотя это были отголоски основной атаки (мощность запросов, которые дошли до серверов, не превышала 400 Мбит/с и 20000 pps), этого хватило, чтобы сервер "лег".
С этим всем можно было бы справиться при помощи системы автоматического обучения фильтров, но для этого нужно время - анализ трафика в нашем случае занял бы не менее 6 часов. Ждать было некогда, поскольку сайты уже не работали, и клиент по понятным причинам был не слишком доволен.
Решение проблемы
Для того, чтобы избавиться от атаки, мы решили выполнить настройку системы фильтрации самостоятельно, отсеяв вредоносные запросы. В качестве подходящего варианта мы выбрали стандартную настройку, которая ранее использовалась у некоторых других наших клиентов. Этот вариант сработал, сервер поднялся и сайты стали доступны для посетителей.
Вероятно, вы уже догадались, что это еще не все, правильно? И действительно, злоумышленники оказались тоже не лыком шиты. Изменился характер атаки, пакеты стали приходить с более обширного спектра IP-адресов, причем с меньшим количеством запросов за секунду с одного адреса. Это позволило атакующим обмануть систему фильтрации, которая была настроена на несколько иные паттерны атаки. Трафик в итоге попал на сервер. Дальнейшая настройка потребовала времени и человеческих ресурсов, причем работать пришлось быстро.
Специалисты определили основные локации, откуда шел мусорный трафик (это Восточная Азия и Ближний Восток) и настроили фильтры по-новому. Как итог - трафик с этих локаций был полностью отфильтрован. Примерно час ушел на то, чтобы установить минимально возможный treshold на количество одновременных запросов. Это было сделано для того, чтобы система фильтрации получила возможность убирать такие запросы, не влияя на реальных пользователей сайтов клиента. При этом настройка для каждого конкретного ресурса была индивидуальна, и поначалу работа фильтров тщательно проверялась. Проблема в том, что чем большее количество одновременных соединений требуется для нормальной работы ресурса, тем сложнее отсеять вредоносный трафик. Если выставить слишком низкий лимит на одновременные соединения, то на стороне клиента могут возникнуть такие проблемы, как не до конца погружающаяся страница или же полная недоступность ресурса.
Конечно, блокировка сегмента IP Восточной Азии и Среднего Востока - не лучший вариант, но все же отсюда не так много реального трафика для украинских СМИ, поэтому в качестве временного решения этот вариант подошел.
Ну а дальше уже дело техники. После того, как нагрузка на сервер вернулась к нормальным значениям, мы решили вернуть трафик из заблокированных сегментов. Все заработало, проблемы исчезли.
Правда, и после этого случилась небольшая неприятность. А именно - клиент принял решение синхронизировать время для одного из своих серверов и поднял NTP-сервер, открыв его для внешнего мира. Те, кто стоял за атакой, видимо, следили за действиями администратора и сразу же воспользовались оплошностью. На сервер пошла атака мощностью в 1558933.5Mbps/420473216PPS (по протоколу NTP, само собой). Наша система фильтрации рассчитана на атаки вплоть до уровня 1,2 Тбит в секунду, но пришлось все равно туговато. В течение 3 минут был заблокирован весь NTP-трафик в дата-центре компании, после чего работать стало легче. Спустя некоторое время мы запретили NTP-трафик лишь для конкретного клиента, чьи сервера находились под атакой, и разрешили это тип трафика для всех остальных клиентов.
Действия привели к успеху - вредоносный трафик стали отлавливать на 99,999%, и проблема была решена. Спустя неделю атаки прекратились, сервер клиента и его ресурсы были спасены.
В качестве вывода хотелось бы сказать, что кейс, возможно, не уникальный, но некоторые его особенности привели к выводу, что о нем стоит рассказать. Главное, что требуется от команды ДЦ - слаженная работа во время атаки. Не должно быть паники или разброда и шатания. Каждый сотрудник должен знать, что ему делать и знать хорошо. А чтобы не растеряться, стоит иметь под рукой план "судного дня", то есть список действий (которые отрабатываются в ходе учебных тревог!) сотрудников на случай атак и неполадок разного рода. Еще - обязательно нужно следить за тем, что делают ваши клиенты во время того, как вы сражаетесь с DDoS или атаками иного рода. Небольшая неосторожность и все действия могут просто пойти прахом.
