Главное Свежее   Проекты
Рекомендуем
Хотите больше продаж
по всей России?
Подключите красивый номер 8-800 за 1 рубль
Перейти
Продвинуть свой проект
42 2 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как King Servers DDoS-атаку на своих клиентов отражал

У нас, как у хостинг-компании, есть много интересных кейсов о решении тех либо иных проблем. Сегодня как раз покажем один из кейсов, который касается отражения DDoS-атаки.

b_5afdde696ccf6.jpgИтак, несколько недель назад нашими клиентами стали несколько крупных новостных сайтов из ближнего зарубежья. Прежде, чем подписать договор, мы были предупреждены о том, что на эти ресурсы может быть совершена мощная 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 или атаками иного рода. Небольшая неосторожность и все действия могут просто пойти прахом.

-1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
VoiceTal.ru
Сервис обработки звонков с элементами ИИ
Левин Антон
"мощность запросов, которые дошли до серверов, не превышала 400 Мбит/с и 2000 pps"
http -атака, 2000 pps и 400 мбит что то вообще не вяжутся. 2000 http-запросов вряд ли создадут нагрузку даже в пару мегабит. или вы исходящий трафик считаете?
что за атака такая на 300 гбит по http? совсем не стыкуется. 300 гбит запросов уровня L7 OSI? вы ничего не перепутали?
хотя, если проводить параллель с "http -атака, 2000 pps и 400 мбит" и "300 гбит", то получается атака на 300 гбит это всего 1 500 000 pps.
вы действительно считаете, что тут есть чем похвастаться? mikrotik ccr1032 за 1000 долларов переваривает 3 000 000 pps и 25 правилах фаервола.
Ответить
King Servers
Хостинг-провайдер
Tatiana
Спасибо за то, что указали на нашу ошибку. На самом деле было около 400мбит/с и 20000pps. Мы поправили информацию в статье.
Ответить
Выбрать файл
Не пропустите публикацию!
King Servers
Хостинг-провайдер
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать