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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы статика не тормозила - вернули 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 - полезен при удачной локации атакующих

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

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

• Qrator - Защита от DDoS-атак
  
• Selectel - Защита от DDoS‑атак
• Cloudflare - Enterprise DDoS Attack Protection
• Nginx - Модуль ngx_http_geoip_module
• Фаервол iptables
• DDoS атака в обход Qrator. Как защититься?
• DDoS в обход Куратора: простые действия для спокойной жизни

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

• Сервис «НаПоправку» подвергся хакерской атаке после отказа удалить негативные отзывы о пластическом хирурге
  
• DDoS-вендетта: как НаПоправку отказались удалить отзыв и месяц отражали атаки. Сначала на сайте, потом — в жизни