{"id":13653,"url":"\/distributions\/13653\/click?bit=1&hash=fee89fe6174decc3f9a9e1cefc15dbde7d85d27279acdc112d63d4da4d5a0e3c","title":"\u0427\u0435\u043c\u043f\u0438\u043e\u043d\u0430\u0442 \u0434\u043b\u044f \u0438\u043d\u0432\u0435\u0441\u0442\u043e\u0440\u043e\u0432: \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0438\u0433\u0440\u0430\u0442\u044c \u0434\u043e 100 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e!","imageUuid":"8c1166aa-ed4d-5964-8fea-818410a466e6","isPaidAndBannersEnabled":false}
Марк Дерманов

Как победить DDoS-атаку на коленке или технические подробности одной битвы НаПоправку за честные отзывы

Не было печали, но были негативные отзывы

Подразумевается, что читатель знаком с понятием DDoS-атаки.

Началось всё с того, что 25 ноября нам пришло сообщение от адвоката Бенхина А.Я. Адвокат представлял интересы пластического хирурга из Москвы — Михайлова А.А. и предлагал деньги за удаление негативных отзывов пользователей нашего сервиса. Мы его проигнорировали.

На следующий день с другого номера телефона мы получили новое сообщение, уже с угрозой блокировки нашего сайта:

Мы его тоже проигнорировали.

26 ноября

Шел обычный рабочий день. Первыми вестниками проблемы стали жалобы от наших пользователей, что сайт тормозит. Начали сыпаться алерты от системы мониторинга про высокий RPS, нагрузку на сервер, и высокое время ответа.

В этот момент наш сервер находился на пиковом уровне нагрузки. Бекенд у нас на PHP. Хотя ресурсов сейчас с запасом, но к такой нагрузке мы не были готовы.

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

Стоит сказать, что у нас был подключен сетевой фильтр для защиты от DDoS-атак, который предоставляет Selectel “базовая защита от DDoS”. Поэтому на счет атаки мы не спешили делать выводы, раз есть фильтр. Но толи он не счел это атакой, толи он на какие-то другие атаки рассчитан, толи он реально что-то фильтровал - но нашу проблему он не решал, сайт не работал.

Фильтр заметил что-то неладное Сетевой фильтр для защиты от DDoS-атак от Selectel
Трафик на сайт в обычное время и в период атаки Сетевой фильтр для защиты от DDoS-атак от Selectel

Идеи приходили в голову медленнее, чем наш сайт переставал работать окончательно. Тем временем, мы двинулись по стандартному пути и начали вычислять хацкеров по айпи и блокировать их руками. Разумеется, это нам не помогло.

Мы используем DNS-хостинг от CloudFlare. Поэтому решили попробовать воспользоваться их услугой защиты от DDoS-атак. По описанию, она включается в пару кликов. Запросы начинают проксироваться через их сервера и выводить подозрительным пользователям и роботам js-капчу вместо целевого сайта. Это даже заработало. Но внешний вид капчи - страшный, как атомная война. Очень не хотелось видеть это у себя на сайте. Кроме этого, у CF нету точек присутствия в РФ, а это значит что трафик будет ходить через полмира, что ухудшает скорость работы сайта. Ранее мы уже это исследовали и отказались функции проксирования, которая обещала много других полезных опций. Однако, это тоже не решило проблему в один момент, и сайт продолжал лежать. Отключили их услугу и продолжили думать.

Внешний вид js-капчи от CloudFlare, пример из интернета так себе)

Так как по логам было видно, что запросы идут со всего мира, один из разработчиков предложил закрыть доступ к сайту для иностранных ip-адресов. Ключевые наши пользователи находятся в РФ. Поэтому вариант выглядел перспективно. Для этого пришлось повозиться с модулем ngx_http_geoip_module для Nginx, который у нас ранее не использовался. Где-то через пару часов сайт снова заработал. Далее до конца дня уже было тихо. Однако, включенное ограничение по РФ может помешать поисковым роботам индексировать сайт, поэтому мы отключили его в конце дня.

Позже, анализируя логи, мы обнаружили, что атака в этот день велась на две страницы: выборку врачей по услуге “нитевой лифтинг”. 4 млн запросов было сделано за несколько часов. На главную страницу на этом фоне была совсем небольшая атака, где-то 0.3 млн.

Распределение запросов 26 ноября 2020 с 12 до 18 часов Kibana

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

27 ноября

Под конец дня, а это была пятница, снова началась атака. Но мы быстро включили ограничение по РФ и на этом проблема была решена. В этот раз ограничение оставили включенным на выходные.

28 ноября

В субботу я проснулся в 10 утра от звонка генерального директора - сайт не работал. А в эту ночь нашим основателям безостановочно сыпались спамные смс и емейл сообщения. По ньюрелику было видно, что все запросы идут на главную страницу. Ограничение по РФ не спасло, тк трафик шел в пределах РФ.

Рост запросов на главную страницу Newrelic

Еще было видно, что сервер балансировщик нагрузки просто не справляется с таким количеством запросов - кончился CPU, там было всего 8 ядер. Так что запросы до бекенда даже не доходили. Это повлияло на все наши сервисы. Поэтому нам пришлось пойти на экстренные меры.

Вид главной страницы сайта napopravku.ru в период атаки

Мы решили вывести вместо главной страницы скрины с перепиской с мошенниками. Под рукой был только старенький домашний ноутбук, пришлось верстать их на коленке и заливать напрямую на сервер. Плюс перенастроить nginx, чтобы за главной страницей ходил в другой document_root. Само по себе, это не помогло решить проблемы, процессор по прежнему был перегружен и сайт лежал. Однако, меньше чем через полчаса атака остановилась, а мошенники прислали новое сообщение, в котором были недовольны нашей новой главной страницей.

Реакция хацкеров на временную главную страницу совпадение))

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

Ночь 27-28 ноября

Пока был еще день субботы и было спокойно, мы думали что делать дальше. Подключились наши инвесторы, посоветовали компанию, а та посоветовала сервис по защите от DDoS - Qrator. Поначалу я скептически к этому отнесся, тк у нас уже был один фильтр, а сайт лежал.

Ночью я занялся его подключением и настройкой. В целом, там все просто и быстро подключается, не буду углубляться. Пока настраивал, успела случиться небольшая атака, которую мы успешно пережили. Выглядело это так, что начали сыпаться алерты о проблемах, а следом, что проблем больше нет. Буквально в течение нескольких минут.

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

Первая отраженная атака DDoS фильтр от Qrator

С этого момента у нас больше не было проблем с работой сайта. Система успешно все фильтровала.

Кстати, по графикам видно, что 28 ноября была атака на две страницы: услуга блефаропластика и профиль врача Михайлова Андрея Анатольевича.

Распределение запросов 30 ноября 2020 с 12:40 до 12:50 Kibana

Однако, после подключения системы фильтрации трафика, мы заметили, что скорость сайта просела, особенно фронтенд. Главным образом из-за того, что статика начала прокачиваться через фильтр, а ранее раздавалась через CDN.

Время загрузки страницы после подключения куратора GTmetrix

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

26 декабря

Днем в субботу начали сыпаться алерты, стали писать коллеги, позвонил генеральный директор - сайту было плохо. Пришлось приехать в офис и решать проблему. Сначала нужно было убедиться, что это DDoS, а не локальные проблемы у нас. По характерному росту RPS на главную - быстро стало понятно, что это атака. Далее план был понятный - подключить фильтр.

Еще нужно было вывести скрины с перепиской на главной странице сайта - мы решили, что так будет при каждой атаке.

Вот так выглядела нагрузка на CPU на балансировщике во время атаки.

Нагрузка на сервер балансировщик в начале атаки Netdata

Пока я занимался подключением фильтра, наблюдал за характером атаки. Заметил, что запросы идут на наши технические поддомены, которые не были подключены к фильтру. То есть хацкеры догадались подсмотреть их в DNS. Из чего следует, что заводить технические поддомены нужно не на продуктовом домене, а на техническом.

Подключение фильтра сводится к перенаправлению трафика на другой прокси-сервер, то есть нужно настроить DNS записи. Однако, остается возможность делать запросы напрямую на оригинальный сервер. Поэтому на оригинальном сервере нужно настроить фаервол (например, iptables), чтобы принимать запросы только от доверенного прокси-сервера. В ноябре атака была “глупая” и не использовала эту лазейку, а в этот раз догадались. Поэтому пришлось закрыть прямой доступ. После этого у хацкеров не осталось шансов как-то навредить своей DDoS-атакой, тк она просто отсекалась фильтром.

Нагрузка на балансировщике прекратилась после включения фаервола.

Нагрузка на сервер балансировщик в конце атаки Netdata

Еще несколько интересных графиков с мощностью атаки

Сравнение мощности атаки в ноябре и декабре

Сравнение мощности атаки в ноябре и декабре DDoS фильтр от Qrator

Атака 26 декабря крупным планом - в пике до 7 Гб/с

Атака 26 декабря крупным планом - в пике до 7 Гб/с DDoS фильтр от Qrator

Чтобы статика не тормозила - вернули CDN, но за оригинальным контентом запрос идет через прокси-сервер. Получилось оптимально по скорости и защищенности.

Фильтр оставили включенным на новогодние выходные, и по сей день.

Выводы

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

Есть несколько вариантов, что можно сделать при атаке:

  1. вручную заблокировать атакующего по Ip
  2. заблокировать какие-то регионы из которых идет атака или наоборот
  3. разрешить доступ только из определенных регионов
  4. отключить конкретную страницу на сайте
  5. подключить систему фильтрации трафика

Инструменты, которые мы использовали и польза от них:

Здесь перечень инструментов, которые мы использовали в рамках борьбы с DDoS-атакой. Мы поделились своим опытом работы с ними. Как-либо рекламировать их у нас нет цели, но скрывать названия инструментов кажется странным.

  1. система фильтрации Qrator - реально помогла решить проблему
  2. фаервол iptables - железно блокирует трафик, полезен в паре с фильтром от DDoS
  3. базовая защита от DDoS от Selectel - не помогла, или мы этого не заметили
  4. защитой от DDoS от Cloudflare - вроде работает, но не подошла нам. Полезный эффект не оценить.
  5. модуль ngx_http_geoip_module - полезен при удачной локации атакующих

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

Полезные ссылки

Использованные инструменты

Другие статьи об этой истории

0
1 комментарий
Dmitry Popov

Хороший кейс. А Пластическому Хирургу Михайлову Андрею Анатольевичу большой привет, поздравление с цитированием на сайте с высоким ранжированием и предложение попробовать удалить упоминание и отсюда...

Ответить
Развернуть ветку
Читать все 1 комментарий
null