Отражая DDoS

Представьте ситуацию — вы идете домой с работы по знакомой улице, слушаете музыку и готовитесь достать ключи, но из-за угла выходит пара здоровых ребят, которые выше, сильнее, быстрее (на первый взгляд) и бьют вас прямым в челюсть. Вот так выглядит DDoS атака для 99% компаний. Это неожиданно и неприятно для владельца бизнеса, но очень интересно для разработчиков и системных администраторов.

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

За последние 4 месяца напали на 2 наших издания. В первый раз вымогали 1 BTC, второй раз ничего не просили, просто били.

DDoS атака это внештатная ситуация и закладываться под 2000% нагрузки при построении инфраструктуры нет смысла.

Почему? — Потому что атака может быть такой, что Akamai и Yandex не отобьются. И возможность держать 2000% будет каплей в море, но за время простоя оборудования компания сожжет вагон денег, и все равно ресурс ляжет.

Нужно ли готовиться, если все так плохо? — Однозначно. Но как обычно с умом.

Как это выглядит в кино?

Куча открытых терминалов, что-то куда-то летит, шифруется-криптуется-пингуется.

[Загорается красная лампочка].

— Сэр, на нас напали

–– Покажи им, Джон.

[Тут обязательно ломается спутник, детектится плохой парень и вот уже бравые ребята выносят дверь какого-нибудь бункера и всех ластают].

Как это выглядит в реальности?

Едешь ночью из бара на такси. Звонит мониторинг и электронный голос надиктовывает сообщение — <sitename> unreachable. С телефона 504 и спиннер браузера нарезает бесконечные круги пока ты судорожно пытаешься вспомнить пароль от Zabbix… А там лавина 500-х и в 1000 раз больше запросов. И тебе надо что-то делать. Все спутники до тебя уже сломали при запуске или при сборке, так что выбор невелик, надо как-то отбиваться. Как в кино бывает только в кино.

Нормальная нагрузка в это время 600–800rpm на 1 app машину.

Как идет атака?

Нас атаковали двумя самыми простыми и действенными способами:

1. Атака на уровне приложения (L7). GET/POST запросы в разные location (/, /login, /wp-login) с рандомизацией User-Agent и cookie.
2. Атака на транспортном уровне (L4). SYN flood, UDP flood.

Если от первого реально отбиться, настроив фильтры или WAF, то от второго не всегда. UDP flood крайне эффективен. Запретить UDP пакеты можно только с помощью хостера.

Флоу обычно такой — бьют в приложение (L7), если отбились, то бьют в (L4), если и тут отбились, то увеличивают размер. Дальше бьют и в L7 и в L4.

Как отбивались?

1. Нашли в логах сервера паттерны в запросах к приложению. Вытащили IP адреса и зафильтровали трафик на балансере.
2. Запретили POST там, где он не нужен.
3. Начали снимать дамп TCP и UDP пакетов. Обнаружили UDP flood.
4. Созвонились с хостером и попросили отключить UDP трафик к нашему IP. Но наш прекрасный хостер не сделал этого, а отправил в Null route. Проще говоря, заблокировал весь трафик к нашему IP, чтобы защитить свою инфраструктуру, и выключил нас.
5. Переключили на новый IP и подали заявки в CloudFlare Project Galileo и Google Shield.
6. Завели аккаунт и оплатили тариф professional в CloudFlare.
7. Перенесли зону в CloudFlare. Это была самая длительная операция. Зона переносилась 1,5 часа, это время сайт работал с сильными перебоями. (Вот тут можно ускорить обновление публичных DNS).
8. Включили магическую кнопку Under Attack. Это javascript challenge и агрессивная фильтрация запросов. До входа на сайт показывается страница, на которой должен отработать js скрипт и средиректить пользователя через 5 секунд.
9. Включили rate limit на количество запросов с одного IP и отключили такую же настройку на nginx.
10. Включили WAF (Web Application Firewall) от CloudFlare. Последующая настройка WAF для издания заняла примерно 3 дня. Это отслеживание запросов и работы редакции, отключение части фильтров и адаптация под нашу систему.
11. Настроили nginx, чтобы не блокировать запросы от подсети CloudFlare и прокидывать реальные IP пользователей в систему.

Как итог, издание было недоступно в сумме около 2х часов — что укладывается в SLA.

Тайминги

В среднем ботнет живет 1,5–2 недели. Хостеры заблокируют взломанные машины, с которых идет подозрительный трафик, или атакующим просто надоест.

Вымогатели атаковали неделю, били по 2–3 часа в пиковое по трафику время, а также ночью и рано утром. На другом издании включили в 12:00 и держали до 16:30 следующего дня. Причины и цели остались неизвестными.

CloudFlare включил в программу Galileo в течение двух дней. Защита на тарифе professional была сразу, но бесплатной её сделали спустя два дня.

Google Shield дал доступ к своему сервису спустя три дня. К тому времени мы уже уехали за щит CloudFlare.

Что сделать сразу после прочтения этого текста?

1. Проверить TTL в критичных DNS записях (сделайте хотя бы 900-1800). Это 15–30 мин. Сторонний DNS хостинг не умрет от такого TTL, self-hosted надо смотреть и помнить о резервировании сервиса. Низкий TTL позволит быстро менять IP и быстрее встать после переноса зоны.
2. Купите IP подсеть. Стоит копейки, если уходить за внешний щит, то нужно менять IP и выключать старый. Будете отбиваться сами, возможность менять IP даст время для маневров.
3. Подайте заявки в CloudFlare и GoogleShield. Это сервисы по защите медиа. Плюсы и минусы каждого распишу в отдельной статье. В кратце, у Shield быстрее сетап, но хуже защита.

Не нужно бросаться переписывать приложение или наращивать мощность машин. Приложение быстро не перепишите, а машины не помогут.

Какие сервисы можно использовать?

Бесплатные

1. CloudFlare Project Gallileo
2. Google Shield

Платные

1. Qrator
2. Kona Site Defender от Akamai

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

Хостинг

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

Мы использовали Softlayer (IBM), всё что сделали эти ребята, так это отправили в null route без разговоров. Даже простая просьба отключить весь UDP трафик до наших машин была проигнорирована. Хоть Softlayer предоставляет самый большой функционал по работе с сетью, все же отсутствие защиты от DDoS атак и нежелания помогать заставили нас искать другие варианты.

Советую посмотреть в сторону Hetzner, Online.net и OVH. Это крупные компании, которые предоставляют защиту от DDoS. Российских хостеров не смотрел, но думаю там тоже есть игроки с нужными опциями. Hetzner предоставляет условно бесплатно. Качество и границы не проверял.

Что делать если вы сейчас под атакой?

Во-первых, выдохнуть. На вас уже напали и если подготовки было 0, то рвать волосы на голове или жопе уже бесполезно.

Во-вторых, понять проблему:

1. Вектор атаки.
2. Масштаб трагедии.

L7 — смотрите логи, вытаскивайте IP и фильтруйте.

L4 — tcpdump на балансировщике (машине где у вас висит основной IP) и составляйте список IP и подсетей. Можно фильтровать или отправить хостеру/сервис по защите.

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

Можете написать в FB, чем смогу помогу.

Если вы смелый, ловкий, умелый…

Ботнет это куча зараженных машин (камеры, роутеры, виртуальные машины с WP, etc). У него есть 1-N управляющих центров. За центрами могут быть еще центры и уже за ними человек (группа людей).

Чтобы отбить ботнет нужно сломать одну из зараженных машин, определить откуда идут команды, сломать одну из машин управляющего центра, посмотреть нет ли там еще одного слоя и так вглубь. Контрол центры можно пролечить и остановить DDoS. TL; DR; статья от Wired о том, как отбивали один из самых больших ботнетов.

Весь предыдущий абзац это нарушение законодательства, как минимум в РФ, поэтому прежде чем так делать, даже если вы сможете, подумайте.

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