DDoS + IT

Вы соскучились по новостям? Так вот же они.

Инженер-программист Дэнни Го рассказ, что его кошка вовремя разбудила спящего хозяина, тем самым предупредив о DDoS.

Несколько лет назад Го работал в стартапе, в нем не было дежурства за работой сайта. Это было осознанное решение компании, тк быть на дежурстве сложно, а команда и так справлялась, следя за срочными сообщениями.

Только работает схема днем, а ночью никто за сайтом никто не следит, по причине сна.. (вспоминается советский анекдот про полет на солнце ночью)

Около трёх часов ночи я проснулся от того, что моя кошка вылизывала мне волосы. Само это действие не было чем-то необычным. Время от времени она делала это, и я оптимистично воспринимаю это как знак того, что я ей действительно нравлюсь, а не того, что она просто меня терпит. Но за 9 лет это был единственный раз, когда она сделала это, пока я спал. Я проверил свой смартфон, чтобы узнать, который час, и заметил, что пару минут назад сработало предупреждение AWS CloudWatch из-за неработоспособных сервисов нашего балансировщика нагрузки.

Я пытался зайти на наш сайт со смартфона, но он не загружался. Я начал проверять логи на рабочем ноутбуке. Наша панель мониторинга показала огромное количество запросов, поступающих со многих IP-адресов, связанных с разными странами. Да и международный трафик для нас не был типичен, поскольку наши сервисы были доступны только жителям США. Это была распределённая атака типа «отказ в обслуживании» (DDoS).

Моей первой и не самой удачной мыслью было заблокировать IP-адреса на уровне сервера, что было бы утомительно и, возможно, неэффективно, если бы у злоумышленника было значительно больше исходных IP-адресов. Но потом я вспомнил, что мы уже настроили брандмауэр веб-приложений AWS. Чтобы справиться с немедленным сбоем, я установил правило блокировки запросов из других стран. Оно вступило в силу и в течение следующего часа заблокировало сотни тысяч запросов. Наш сайт снова заработал, поток запросов прекратился.

Позже тем же утром в команде заметили, что получили электронное письмо в нашу службу поддержки примерно в то время, когда началась атака. Отправитель, используя ужасную грамматику, заявил, что нашёл уязвимость на нашем веб-сайте, приводившую к сбою Apache, которую мы не устранили. Злоумышленник угрожал, что заблокирует наш сайт и сможет сохранять его в таком состоянии в течение нескольких месяцев. Он великодушно предложил нам «файл с решением», если мы отправим ему $5000 в биткойнах. Мы не ответили, хотя, оглядываясь назад, можно сказать, что было бы забавно попытаться его троллить.

«Мне до сих пор трудно поверить, что моя кошка разбудила меня в идеальное время. Вы можете предположить, что предупреждение AWS заставило мой телефон вибрировать или издать звук, разбудив первым мою кошку. Но ночью я держу телефон в режиме «Не беспокоить». Так что мне просто нравится думать, что каким-то образом она почувствовала, что что-то не так, и это не могло подождать до утра. Это был, конечно, более приятный способ проснуться, чем рёв будильника», — подытожил Го.

Отсюда вывод, что кошки чувствуют электромагнитные волны, исходящие от телефона)

И когда у нас будет сайт заведем дежурную кошка, сэкономив на дежурстве.

Дисклеймер ↓

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

Но в итоге сегодня наша статья наконец-то выходит в свет. Из цензуры — только внимательная рука корректора. Передаем слово Максу Яковлеву.

Привет, Пикабу. Меня зовут Максим, я руковожу отделом сетевых инженеров в Таймвебе. Как вы уже поняли из заголовка, речь пойдет про наш прошлогодний DDoS. Это не стандартный постмортем, а скорее история от первого лица. Расскажу и покажу, каково это было изнутри — жить на энергетиках и пересобрать ядро сети всего за пару месяцев.

❯ Некоторое время до

Про Таймвеб вы, скорее всего, знаете. И скорее всего — как про хостинг, работающий по модели shared, с саб-сервисами вроде регистрации доменов, конструктора сайтов и пр. Еще есть облако, выросшее из хостинга, — о нем и пойдет речь.

В 2023 мы начали потихонечку распиливать легаси-сеть хостинга и делать ее похожей на сеть IaaS-провайдера. Но в целом архитектура на момент дня Х была довольно типичной для хостинга: несколько маршрутизаторов, стопка растянутых VLAN, три транзита и пара обменников.

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

Важно понимать, что любой типичный хостинг находится под DDoS-атакой практически 24/7: хоть одного клиента в каждый момент времени да атакуют. Поэтому DDoS для нас — это даже несколько банально. За 17 лет мы повидали много чего и в принципе знаем ключевые (и не только) паттерны, откуда, что, куда и как.

❯ Добрый вечер

14 сентября, ближе к 18:00, в нас влетел очередной DDoS, с которым известно что делать. Отбили — пошли отдыхать. И не успел я допить чай, как атака повторилась, потом опять, а потом еще раз. Каждый раз интервал уменьшался, а объем нарастал.

Далее для любителей краткого изложения перечислю возникшую причинно-следственную связь по инфраструктуре.

В площадку наливается больше, чем та способна переварить → роутеры перегружаются вплоть до потери сигнализации → мы через OOB блокируем атаку через RTBH/FS или переключаем сеть на сторонний центр очистки трафика → цель атаки меняется в течение пяти минут.

Из дополнительных проблем в СПб: аплинки подключены через свитчи с переподпиской, QOS или не работает, или не хватает буфера → разваливается сигнализация. Дополнительно существуют громадные растянутые VLAN, из-за чего атака на одну подсеть затрагивает огромное количество клиентов. Мониторинг и контрмеры работают слишком медленно.

И в остальных локациях: нет своей сети, а ЦОДы нас блочат, защищая свою инфраструктуру. Когда сеть отдается напрямую с железок дата-центра, нет не то что возможности заблокировать атаку, затруднена даже идентификация паттерна: раз — и ноды отвалились. Из доступной информации только триггер в Заббиксе. Самые печальные моменты — когда у нас сутками лежало несколько локаций целиком и наглухо. Даже аплинки наших провайдеров в дата-центрах просто говорили, что мы не готовы это фильтровать, поэтому мы вас отключаем. Как атаки прекратятся, подключим обратно.

❯ Мы накидываем план

Первое: научиться блокировать хотя бы часть атаки на уровне маршрутизаторов провайдеров. Цель — снизить воздействие на клиентов, защитить инфраструктуру. Второе: научить нашу сеть переваривать всю аплинковую емкость без спецэффектов, параллельно ее расширяя.

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

И стратегически: построить свои сети во всех локациях. И собственную защиту.

В первую очередь отказываемся от существующей системы подавления DDoS, потому что она приносит больше вреда, чем пользы. Сетевики начинают спать по очереди, текущий flow-мониторинг меняем на семплированный Inline IPFIX с payload-ом. Таким образом не ждем, пока соберется поток, и принимаем решения за секунды. Этот шаг помог уменьшить среднее время обнаружения каждой атаки: чтобы понять, что она началась и как нужно действовать, нам сначала нужна была пара минут, чуть позже — 15 секунд, а сейчас автоматика реагирует почти мгновенно.

Изначально управление было ручным, чуть позже принятие решений стало автоматизированным: мониторинг научился блокировать DDoS сразу же после обнаружения. В итоге за период с 14 по 20 сентября мы заблокировали более 20 тысяч отдельных паттернов.

В это время по всем каналам — в телеге, в соцсетях, в тикетах — клиенты переживали, ругались и задавали вопросы. И я их прекрасно понимаю. Кстати, о прекрасном:

Дорабатываем защиту: делаем ее быстрее, технологичнее, чтобы принимала максимально правильные решения. Разбираем всю старую архитектуру и избыточные куски сети — все под нагрузкой и идущими атаками и так, чтобы воздействие на клиентов было минимальным.
Примерно в это же время атакующие понимают, что мы что-то сделали, поэтому меняют паттерны. Мы стали получать мощные краткосрочные волны трафика, на которые не успевала реагировать ни наша программа, ни большинство предлагаемых на рынке защит: заливало настолько разнообразно и быстро, что наши стыки и некоторые обменники начали складывать в нас сессии по prefix-limit. В эти периоды бывало и такое:

❯ Строим свою сеть

Начинаем с Питера. План включал в себя апгрейд маршрутизатора с установкой дополнительных плат и подключение к различным каналам и точкам обмена трафиком. Цель — увеличить пропускную способность: нам нужно было научиться принимать трафик атак и блокировать более точечно, а не просто кидаться блекхолами и снимать префиксы. Кроме того, стало понятно, что объемы атак могут расти и нам нужно будет научиться расширять емкость более оперативно, не проходя весь цикл «найти железо → найти емкость → собрать».

Обычные маршрутизаторы не всегда эффективны для такой деятельности: они обладают слишком сложным и дорогим конвейером обработки трафика, предназначенным для других задач. Исходя из этого мы решили действовать комплексно: помимо расширения каналов и увеличения портовой емкости сервисных и пограничных маршрутизаторов начали внедрять пакетные платформы на базе Juniper PTX. Они хоть и попроще, но в них много дешевых 100G/400G-портов, как раз то, что нам нужно.

Благодаря хорошим отношениям с поставщиками мы смогли быстро найти сетевое оборудование: поставка заняла всего полтора месяца. Для техники такого класса это очень быстро.

В итоге в Питере мы добили емкость по основным направлениям до 500+ гбит, а по автономке у нас сейчас суммарно около терабита. Уже через две недели после этого ситуация в СПб стабилизировалась: емкости хватало, фильтры отрабатывали оперативно. В остальных локациях сеть была арендованная: и в Казахстане, и в Европе. По этой причине параллельно с выравниванием ситуации в Питере у нас появилась новая приоритетная задача: поставить в заграничные локации собственные маршрутизаторы и дотянуться до них из Питера — тянуться решили через M9.

Девятка до сих пор крупнейшая пиринговая точка и сосредоточение телеком-инфраструктуры РФ и СНГ. Кроме основных трасс для всей России, туда же заходят каналы от СНГ — зачастую единственные.

Магистральные каналы между площадками дают несколько преимуществ:

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

2. Возможность предоставлять клиентам дополнительные сервисы в виде каналов связи.

3. Наше управление не развалится никогда, даже если внешние стыки в локации будут забиты под полку.

Собственно, начинаем с Казахстана. Протянули канал до девятки и пустили трафик уже через свою сеть.

Кстати, с доставкой в Казахстан повезло не с первого раза. На казахской таможне менялся состав — и все встало мертвым грузом. Ситуацию решили творчески: отправили одного из наших сотрудников везти 204. Забавно, что изначально мы собирались отправлять MX104 — довольно старую и давно снятую с поддержки платформу, которой, впрочем, с запасом хватает на нужды этой площадки.

Но из-за ее громоздкости отправили 204 — и теперь в казахстанском ЦОДе у нас стоит платформа, которой хватит на целый машинный зал облака, а не на наши несколько стоек. На память осталась только фотка со стикером из аэропорта Екб:

К декабрю дотянулись и в Европу: теперь у нас есть узлы во Франкфурте и Амстердаме с арендованной магистральной емкостью. Там появились выходы и в интернет — через Tier-1 операторов, и на европейские обменники.

Следующий логичный шаг — перевели площадки в Амстердаме и Польше на свою сеть. Теперь нас никто не отключит в случае атак, как бонус — интернета стало больше и появились выделенные каналы для клиентских выделенных серверов, скоро будут и во всем Клауде. В итоге вы сможете не только заказать себе сервер с 10G-интернетом, но и расширить локальную сеть до любой нашей точки присутствия — с гарантированной полосой и любыми удобными вам настройками.

Раз уж пошли по локациям, то добавлю, что в этом году запустились и в Москве, в IXcellerate. Это Tier-3 с уникальной системой охлаждения по типу «холодная стена». Я там был на экскурсии — наверное, самое интересное, что я видел в России и СНГ, а поездил я немало. Пиво еще вкусное у них было — тоже плюс 🙂

Москва, кстати, у нас сразу же запустилась с нормальной архитектурой: широкие линки на стойку, 200G до девятки, масштабируемый слой агрегации. По умолчанию даем на все виртуальные серверы по гигабиту в секунду вместо 200 мегабит, на всех дедиках доступно 10G/40G по запросу. В результате, если клиентам это необходимо, мы можем дать гораздо больше емкости, чем могли бы в Петербурге еще полгода назад.

❯ Почему мы не спрятались за подрядчиками

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

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

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

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

Такое положение дел было связано с характером самого трафика и с тем, что атаки были короткими и частыми: классифицировать «чистый» трафик в подсети, состав серверов которой меняется от недели к неделе, если не чаще, — малореально. А переключить маршрутизацию за время между атаками часто и вовсе не получается: цели меняются быстрее, чем BGP-апдейты распространяются по интернету.

❯ Что сейчас

Подобные атаки прилетают, но в целом мы научились их фильтровать: чистить на уровне сетевого оборудования или деприоритизировать/блокировать клиента, если объем превышает пороги.

Работы еще много: всю эту новообразовавшуюся сеть нужно резервировать и расширять. На М9 мы взяли целую стойку и собираемся ставить шасси MX960 — с большим запасом на будущее. Оно будет выполнять роль магистральной развязки, принимать внешние стыки и выступать ядром сети дата-центров по Москве, у нас там большие планы. Не забываем и про Северную столицу: платформа PTX10003 станет ядром нового узла на Кантемировской («Радуга»), где будет перемыкать магистрали и стыки с внешними сетями, выступая частью инфраструктуры очистки трафика в Санкт-Петербурге.

Находимся на этапе тестирования с Servicepipe: будем пробовать систему уже тонкой очистки трафика — если атака на клиента не угрожает инфраструктуре, не полностью все блокировать, а принимать трафик атак на себя и отдавать клиенту уже очищенный, вплоть до L7.

Много работы будет по пирингам: думаем, что скоро мы сделаем прямые подключения к Google, AWS, Azure и другим гиперскейлерам. Хотим организовывать серьезные продуктовые преимущества для наших клиентов: если ваш продукт требует очень хорошей связности с мировыми облаками или у вас мультиклауд — мы сможем обеспечить как хорошую связность по интернету, так и выделенные линии, если потребуется.

Для выделенных серверов по части сети у нас получилось очень интересное предложение. По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет. Кроме простого интернета — широкий набор сетевых решений: тут и более-менее стандартные L2/L3 VPN на MPLS, и любые манипуляции с внешней маршрутизацией. Для владельцев своих AS соберем транзит, притянем любую популярную точку обмена трафиком. Для тех, кто хочет ими стать, — поможем выпустить ASN, арендовать или купить сети, анонсировать их в мир.

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

❯ И напоследок — неудобный вопрос от маркетинга

— Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?

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

А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.

Присоединяйтесь к нашему комьюнити в Телеграме — здесь можно общаться с сообществом, задавать вопросы руководителям, гендиректорам и фаундерам, и предлагать идеи ↩

Одна из разновидностей UDP Flood, которая направлена на DNS сервис.

В время атаки DNS Flood  направляется огромное количество DNS запросов с очень широким диапазона IP-адресов.

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

В результате чего, DNS Flood занимает все сетевые ресурсы и полосу пропускания DNS-сервера, вызывая его отказ.

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

Информация предоставлена в ознакомительных целях!
Мы в телеграме!

T50-более быстрый инструмент напряжения сети.

UFONet-злоупотребляет OSI layer 7 HTTP для создания / управления «зомби» и проведения различных атак с использованием; GET/ POST, многопоточность, прокси, методы подмены происхождения, методы уклонения от кэша и т. д.

Мы в телеграме!