Поздним вечером к нам обратился системный администратор постоянного клиента и попросил поговорить с другим администратором. После того, как мы связались друг с другом напрямую, началась наша история, которая не завершилась и на момент написания этой статьи, но уже сейчас есть о чём рассказать и чем поделиться.
Проблема
Проблемой стали постоянные непрекращающиеся DDoS-атаки на web-сервер. Загрузка процессора от apache + mysql уходили стабильно в 100%. После перезагрузки сервер работал несколько минут и снова уходил в максимум, и не мог обрабатывать соединения. Изменения внешнего адреса спасали на короткие промежутки времени, пока DDoS-атака не резолвила новый IP-адрес по доменному имени.
Анализ
Сначала решили подтвердить, что это DDoS. Получили логи запросов и состояний с маршрутизаторов и сервера. Выяснили, что маршрутизаторы тоже благополучно уходят в значения нагрузки близкие к 100%, так как не рассчитаны на подобное количество соединений.
Случайным образом выбрав с десяток IP-адресов источников запросов получили ясную картину, что они не имеют никакого отношения к людям и порождаются ботнетом (тысячами ботов, на момент написания статьи больше 200 тысяч адресов — источников запросов полностью или временно попадали в правила блокировки). Такое количество для нас было впервые и откровенно пугало. Суточные посещения наших проектов в 60000 — 80000 мы легко переносим, но это проекты, где мы могли что-то менять налету, включать и отключать, если возникает такая необходимость. Здесь чужой проект, на известной CMS, на языке и инфраструктуре компетенций в котором у нас на уровне недостаточном для предоставления платных услуг, как нам тогда казалось.
Поэтому, мы предложили обратиться в профильную организацию, которая занимается отражением DDoS-атак с “историей”. Выяснилось, что они берут за мощность атаки в мегабитах, а также дополнительно за анализ специфических правил, если они есть. Нашему потенциальному клиенту уже называли сумму 35 тысяч. Сказать что мы были удивлены — ничего не сказать. Решили попробовать справиться своими силами, объяснив возможные риски, вплоть до того, что возможно ничего не получится.
Решение
Первое, что было замечено в логах Web-сервера — это единственная страница, куда шли все запросы ботнета. Открыв страницу в изолированном окружении, отключенном от сети, всё стало на свои места. Страница была значительно большего размера, чем остальные и содержала ссылки на внутренние мультимедиа элементы. Цель стала ясна.
Структура (человек или группа лиц), начавшая атаку, проанализировала сайт, нашла страницу максимального размера и нацелила на неё свой ботнет. В попытках задавить канал исходящим трафиком, диски сервера чтениями, а процессор обработкой запросов к серверу и базе. В первые дни атака проходила с десятков тысяч IP-адресов одновременно. Была запрошена дополнительная информация про серверное кэширование nginx или apache. Кэш был выключен, но включение не сняло проблемы с исходящим трафиком. Однако, нагрузка на процессор изменилась незначительно, позже мы смогли понять почему и найти решение этого вопроса используя уже свою инфраструктуру как промежуточную.
Дополнительной проблемой был устаревший софт, администратору клиента пришлось его обновлять по ходу движения, начиная от операционной системы, заканчивая CMS, установкой nginx, настройкой на нём кэша и так далее. Но на всё это нужно время, плюс добавление и настройка таких элементов не дает возможности блокировать или хотя бы анализировать входящие запросы. Если попробовать заставить оборудование клиента анализировать тысячи запросов, то про работу сайта можно забыть точно.
Было принято решение: реверс-прокси. Оно заключается в том, что клиент получает внешний адрес и скрывает его от всех, кроме администраторов реверс-прокси. Следующим шагом, администратор ресурса вносит все адреса, которые сообщили ему администраторы реверс-прокси в белый список, остальные — блокирует. В свою очередь администраторы реверс-прокси настраивают так, чтобы она могла забирать информацию с сервера (серверов) клиента и отправлять во внешнюю сеть интернет. Логично что оборудование на котором размещены реверс-прокси должно быть иного класса, гарантирующего резервные каналы, round robin dns, failover и так далее. Развернув и настроив прокси началось добавление правил анализа входящего трафика.
Правила анализа
Правила могут быть различными, составлять их может человек, анализируя трафик глазами, какие-то статичные алгоритмы, нейронные сети. Первые алгоритмы мы добавляли руками, заблокировав явных ботов, с пустыми UserAgent и другими странными заголовками. Обратили внимание, что достаточно большая часть ботов, по непонятной нам причине, обращаются по адресам с указанием порта, например https://example.com:443/example. Проверив десяток таких адресов, все они были инициированы ботами.
На основании первых правил, мы создали алгоритмы, которые автоматически добавляли данные адреса в чёрный список фаервола и запросы не доходили до прокси.
Нагрузка упала, но структура начавшая атаку обнаружила это и сменила вектор атаки, теперь ботнет обращался к главной странице, но менял как частоту обращений, так и UserAgent, нагрузка на прокси и клиента поползла снова вверх. Это способ замаскироваться под NAT посетителей сайта. Ведь если кто-то из посетителей сайта находится за NAT и обращается к сайту с разных браузеров, то смешивается с ботнетом. Эмпирически было получены несколько чисел, которые отражали частоту смены UserAgent в единицу времени, количество обращений от одного адреса и так далее, мы проверяли что отсеянные этим алгоритмом адреса не представляют интереса и являются ботнетом.
Прошла примерно неделя, были настроен кэш на реверс-прокси, но вектор атаки был снова изменён, за ресурсом следили, ко всем старым способам добавился ещё один. К адресу главной страницы произвольным образом добавлялось число в надежде, что полученный уникальный адрес приведёт к выборке не из кэша, а полному исполнению запроса. Атака была быстро обнаружена и добавлено автоматическое правило, а построение кэша было строго ограничено через семафор до одного потока, другими словами данные с клиента забирались в один поток, остальные ожидают, в момент когда кэш нужно было перестроить (выходило время жизни кэша). Иначе сотни запросов пытались через прокси перестроить кэш, что приводило к повышенной нагрузке на инфраструктуру клиента.
Дальше была обнаружена новая атака, HEAD запросами. Смысл этой атаки, кроме количества запросов, мы не поняли, но добавили правило и начали блокировать.
Параллельно просматривая логи получившегося сервиса по анализу DDoS, мы обнаружили точки входа, где собиралась структура — инициатор DDoS, их сайты, где к ним можно было присоединиться, давался полный список программ, руководств по эксплуатации, где и как запускать, для совсем простого входа — достаточно было открыть несколько вкладок в браузере и ты уже участвуешь в атаке на десятки разных ресурсов.
Были добавлены белые списки для сервисов, которые не всегда корректно указывают свои заголовки, что немаловажно ведь они потенциально могли быть автоматически заблокированы алгоритмами.
Одним из интересных и одновременно странным решением - это оповещать о возросшем потреблении мощности ИБП, что тоже является 100% маркером нехарактерной нагрузки и скорее всего добавления нового, ранее неизвестного вектора атаки. Ждём.
По вопросам обращайтесь на почту: contacts@thisislogic.ru