В каких юнитах можно померить DDOS атаку? Биты в секунду, запросы, пакеты, время даунтайма, количество машинок в ботнете — все эти ответы верные. Потому что DDoS-атаки бывают разных категорий и для каждой есть свои ключевые метрики. Их рост и является движущей силой для эволюции DDoS атак. Посмотрим, как это происходит.
Поможет нам в этом Георгий Тарасов, владелец продукта Bot Protection в Qrator Labs. Ранее он занимался разработкой, проектным менеджментом и pre-sales. Вместе с ним мы полетим в 1994 год и обратно, в настоящее время. Посмотрим, как развивались распределённые атаки на отказ в обслуживании за эти годы, к чему они пришли сейчас, и на что есть смысл обратить внимание.
Движущие силы эволюции атак
Если вспомнить эволюцию в природе, там работают такие движущие силы, как борьба за ресурсы, наследование, мутации и естественный отбор. У DDoS атак своя эволюция и силы, которые ими движут:
Канальная емкость
Для широкополосных атак, которые генерируют очень много трафика, ключевая движущая сила — увеличение канальной ёмкости у интернет-провайдеров. Она определяет, сколько полос мусорного трафика можно доставить до своей жертвы.
Скорость обработки
Для атак, генерирующих большое количество пакетов в секунду — это, в первую очередь, флуды на транспортном уровне: TCP SYN Flood, SYN+ACK Flood, TAC Flood, SYN+ACK амплификация – ключом является то, сколько пакетов может обработать устройство маршрутизации по дороге.
Для прикладных атак, в которых стоимость генерации единиц атаки довольно дорогая, этой силой являются запросы в секунду. Они определяют, сколько запросов в секунду сгенерирует одна машинка в ботнете, и сколько одновременно открытых соединений она способна поддерживать в течение выбранного времени.
Возможности генерации и амплификации
Количество серверов в интернете, которые могут усиливать DDoS-трафик, служит движущей силой для развития атак типа Amplification. Большинство из них использует прикладные протоколы поверх UDP.
Возможности защиты
Средства защиты от DDoS атак тоже развиваются и участвуют в гонке вооружений. Таким образом, они являются движущей силой для атакующих, которым приходится их превозмогать.
RFC (новые протоколы, механизмы реализации)
Новые протоколы и сетевые механизмы порождают новые типы атак, которые эксплуатируют дизайн или конкретную реализацию нового протокола. Например, на роутерах конкретного вендора и/или массового пользователя. Помимо этого, старые методы атак также адаптируются под новые протоколы.
Динамика движущих факторов
Чтобы понять, к чему эти движущие силы приводят, посмотрим на порядки их развития с 90-х годов до нашего времени.
Данные субъективные, сугубо выборочные. Георгий выбрал их, потому что они ему понравились:
Канальная ёмкость на границах крупных провайдеров увеличилась примерно в 106 раз: (сравним Pacific Bell AN в 1996 и Hurricane Electric в 2020);
Скорость обработки пакетов в секунду на роутерах увеличилась примерно в 104 раз (Cisco 2500 в 1996 против Cisco ASR 1000 в 2022);
Количество хостов в Сети, по данным Internet Systems Consortium, выросло примерно в 100 раз к 2019, а домашний Интернет переехал с килобитных диалап-модемов на гигабитные подключения;
Также изменились средства защиты от DDOS. Специализированные коробки, которые фильтруют DDoS трафик, увеличили производительность в 100 раз по полосе (сравним Arbor TMS 2006 и нынешний Arbor Peakflow SP), а облака за счёт распределённости, масштабируемости и увеличения количества подключений — почти в 1000 раз (Qrator Labs).
В таких условиях говорить о конкуренции за питательную среду не приходится – все прекрасно уживаются. Царит любовь и сосуществование новых методов с самыми старыми.
1994: Митник, SYN Flood DoS
Поговорим сначала про самые старые методы.
Рассмотрим эпизод из карьеры знаменитого хакера Кевина Митника.
Он пытался получить доступ (разумеется, несанкционированный) к машине своего давнего оппонента Цутому Шимомуры. Для этого хакнул машинку в лабораторной сети и постарался представиться логин-сервером, с которого был доверенный логин на искомый терминал.
Проблема в том, что если спуфить подключение, представляясь чужой машиной, нужно как-то вывести настоящую машину из обращения, чтобы она не смогла ничего сказать. Для этого Митник использовал генерацию большого количества SYN-пакетов со взломанной машинки, отправил их с указанием чужого валидного, но не используемого спуфленного IP-адреса из этой локалки.
Server.login честно принял все пакеты в очередь полуоткрытых соединений, забил очередь до потолка и отослал все SYN-ACK несуществующей машине. Так что, когда Митник успешно спуфил соединение, представляясь логин-сервером, тот не мог ничего сказать терминалу, который слал SYN-ACK пакет, так как логин-сервер был уже плотно занят. В итоге Митник установил TCP-соединение, получил shell, посадил туда бэкдор, закрыл соединение и отправил reset на логин-сервер. Вся атака, если верить логам, длилась 16 секунд.
Атака Митника — это правильный пример SYN Flood — одного из самых старых, по крайней мере, описанных в летописной истории, вариантов DoS-атаки. Тогда это была ещё не распределённая атака, а Denial of Service с одной машины. Но после этого появился подробный разбор этой ситуации с логами и прочим в mailing-листах: сначала вышла книжка Шимомуры, потом — Митника. Таким образом, люди, которые интересуются интернетом и технологиями, узнали, что так, оказывается, было можно.
1996–2010: возникновение и развитие основных методов
Начало основного периода — это годы, когда DDoS-атаки, с которыми мы сейчас умеем и привыкли жить, появились, развились и успели наделать довольно много шума.
1996: PANIX SYN Flood
Буквально через 2 года после SYN Flood пользователи одного из старейших мировых провайдеров, Нью-Йоркского PANIX, обнаружили, что их mail-сервера не работают. Спамеры разослали через них тысячи писем, использовав SYN Flood с нескольких взломанных машин. Дежурный администратор PANIX отреагировал примерно как в меме: «Очень страшно, мы не знаем, что это такое».
Однако, по итогам полутора суток даунтайма они поняли, что они имеют дело с Distributed Denial of Service (распределённой атакой на отказ в обслуживании) с использованием SYN пакетов, генерируемых со взломанных машинок.
Реакция масс-медиа на эту историю была сдержанной. Написали только в профильных колонках технологических изданий. Однако это был чуть ли не первый случай, когда об этом вообще кто-то написал за пределами тематической mail-рассылки.
Реакция профессионального сообщества была немножко интересней. Спустя два года исследователи проводили research и выяснили, что для среднестатистического сервера достаточно 20 пакетов в секунду, чтобы держать очередь полуоткрытых соединений (SYN queue) полностью забитой. После чего сервер не сможет принять TCP-коннект ни от кого больше.
Internet Protocols for Network-Attached Peripherals Steve Hotz, Rodney Van Meter, and Gregory Finn, Information Sciences Institute University of Southern California, 1998
20 пакетов в секунду — не очень много даже по меркам того периода, тем более, если их гонят несколько машинок. Таким образом, мы не знаем, сколько трафика было сгенерировано в первой исторической DDoS-атаке на PANIX, но, очевидно, много пакетов не потребовалось.
Экспертное сообщество (Центр реагирования CERT) внимательно рассмотрело причины и симптомы возникновения проблемы и выпустило очень общие экспертные рекомендации: «за всё хорошее, против всего плохого».
«Провайдеры: фильтруйте трафик с поддельных IP-адресов, идущий через ваши сети»
CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks
То есть, провайдеры, не пускайте спуфленный входящий и исходящий IP-трафик через свои сети. Если он спуфлен, значит, это атака. Идея — замечательная! А как её реализовать?
Есть набор советов. Но если забегать вперёд, станет понятно, что никакие из рекомендаций CERT (полно и в частичной мере) не были исполнены. Борьба с DDoS-атаками путём массовых внушений интернет-провайдерам, хостерам и транзитным сетям себя не зарекомендовала.
Практические подходы к решению вопроса оказались более успешными. Так, например, через 7 дней после атаки на PANIX, Дэниел Бернштейн и Эрик Шенк обсудили и сгенерировали новый способ борьбы с флудом на открытие TCP соединений. Механизм назвали SYN cookies. Уже через месяц появились первые реализации этого механизма для тогдашних популярных серверных ОС. Для понимания того, насколько технология оказалась удачной — возьмите любое средство защиты от DDoS (коробку, операторскую защиту, облачных провайдеров или софт, который ставится на балансировщики). Почти везде реализован механизм SYN cookies, чтобы фильтровать невалидные входящие SYN пакеты от несуществующих или не принадлежащих абонентам IP-адресов. Вот такой метод-долгожитель.
2000: MafiaBoy гасит топ-сайты
Атака на PANIX больших кругов на воде в мировом сообществе не создала. Зато через 4 года это сделал молодой 15-летний хакер с ником MafiaBoy. Он с помощью того же, уже «хорошо» зарекомендовавшего себя метода атаки, обронил все крупные .com, существовавшие на тот момент:
Технических подробностей история сохранила мало:
В течение 8 дней он их кошмарил, делая по несколько — от 1 до 2 — атак в день. Пока они отколупывались после очередной атаки и поднимали сервера, он валил их обратно;
Полоса атаки составляла примерно 800 Mbps. По тем меркам это были астрономические цифры;
Источниками трафика были хосты в университетах. Хакер взломал некоторое количество машин в университетах Калифорнии, Санта-Барбары и Массачусетса и использовал их для генерации трафика.
Хакера звали Майкл Кальче. Он особо не шифровался, наследил везде, где только можно, и хвастался своими успехами. За это и сел в тюрьму. Но сел MafiaBoy в тюрьму не просто так, а потому что спустя несколько часов после первой атаки тогдашний президент США, Клинтон, собрал саммит.
Он был посвящён кибербезопасности, на нём было постановлено, что с DDoS’ерами надо что-то делать — искать, предъявлять обвинение и сажать в тюрьму. Это и случилось.
Поэтому данный эпизод можно считать точкой отсчёта преследования силовыми органами тех, кто организует DDoS-атаки.
2004: DDoS в РФ
Про DDoS в РФ тоже известно очень давно: примерно с тех пор, когда случился PANIX и .com. В журнале Хакер вышли статьи в 2000-2002 годах по тому, как устроить DDoS-атаку:
Тогда это можно было спокойно обсуждать. Первый эпизод случился в 2004 году. Это произошло потому, что многие сайты рунета размещались на хостинг-провайдере masterhost и вложенным в него peterhost. Когда же они и их провайдер (РТКомм) были атакованы и не справились с входящим мусорным трафиком, все эти сайты легли.
Атакующий использовал уязвимость в популярной утилите Remote Admin (radmin) в основном для виндовых машин. Она позволяла получить управление над машиной и посадить туда скриптик, который генерирует трафик. Этот скриптик умел гонять SYN Flood, ACK Flood, UDP Flood — в общем, полную палитру популярных методов DDoS-атак на тот момент.
Технических подробностей по тому, сколько там было битов в секунду или пакетов, история не сохранила. Но об этом (и ещё много интересного про тогдашний Рунет) можно узнать из разбора Фила Кулина на OpenNET.
2006: Amplification-атаки
Совершенно новым способом эксплуатации машин в интернете для организации DDoS-атак стала амплификация.
Про этот способ экспертное сообщество, успев подготовиться и изучить возможные векторы такой деятельности, узнало раньше, чем он был использован. Уже упомянутый американский CERT ещё в 2005 году выпустил бюллетень «The Continuing DoS Threat Posed by DNS Recursion». В ней говорилось, что большое количество появившихся в интернете рекурсивных DNS-резолверов, которые отвечают каждому встречному и поперечному на DNS-запросы, может привести к проблемам. Кто-то может захотеть отправить много-много маленьких DNS query на рекурсивные резолверы, и исходящий трафик может стать таким большим, что забьёт каналы этих серверов. А это угроза инфраструктуре DNS.
Меньше чем через год после выхода этого бюллетеня, случилась крупнейшая на тот момент (и, возможно, во всей истории) атака на корневую DNS-инфраструктуру, Top Level Domains (.com, .uk и прочих) и на .ru DNS-сервера. Последних на тот момент было около 10 (сейчас их 13). Так или иначе, инфраструктура в одном случае полностью вышла из строя и частично — в остальных. Сгенерированный таким образом трафик, достигал уже гигабитных значений, перевалив психологический порог (2,4 Gbps в пике, 14 минут атаки на TLD).
Но интересно здесь не только это, а то, что атакеры пошли немножко дальше, чем исследователи из CERT. Они подумали: зачем набивать name-сервера исходящим трафиком, когда реальный прикол в том, что можно подставить в DNS query IP того, кто им не нравится? Тогда все эти DNS ответы полетят к нему на хост-машину. Даже если каждый сервер сгенерирует не много, то жертве всё равно не выжить в таких условиях. Потому что количество ответов будет помножено на трафик, который они генерируют, и на фактор амплификации. Амплификация определяет во сколько раз то, что отправит атакующий, по размеру отличается от того, что ответит DNS-сервер.
С этого момента атаки типа DNS Amplification, а также все их весёлые собратья, прочно вошли в нашу жизнь. Буквально любой прикладной протокол, который основан на UDP, будь то LDAP, SSDP, NTP, RIPv1, MOTD (Message of the Day), является вектором DDoS не только потенциально, но и действительно – есть немало примеров реальных атак для каждого из них.
2007–2010: Расцвет DDoS-хактивизма
Как обычно набирались ботнеты в те времена? Помимо традиционных троянов, которые воруют данные или шифруют машину, оказалось возможным подсаживать DDoS-ботов на машинки тех, кто кликнул на вложение в почте. Таким образом домашние и офисные Windows-машины стали очень популярными участниками ботнетов в те времена. Но ботнеты формировались не только так, но и с согласия самих пользователей.
Хактивизм — это попытка заявить свои политические требования и протесты с помощью методов киберпреступности, то есть в частности и DDoS. DDoS-хактивизм выражался в том, что пользователи добровольно устанавливали себе утилиты на свои персональные машины. Эти утилиты занимались генерацией трафика по кнопке. Нужно было лишь сообщить destination-адрес, выбрать тип атаки и нажать “старт”. К таким утилитам относятся Low Orbit Ion Cannon, High Orbit Ion Cannon (HOIC).
К ним добавилась замечательная утилита Slowloris, которая реализовывала невиданный ранее тип атак — медленные атаки с использованием HTTP. Они открывают соединения, которые никогда не закрываются. В соединения шлются, например, заголовки по несколько байт раз в минуту. Этих соединений становится много, и сервер обрабатывает их до тех пор, пока не исчерпает свои вычислительные ресурсы и не встанет колом. Такие медленные атаки продолжаются до сих пор в видоизмененных вариантах.
DDoS-хактивизм активно использовался для того, чтобы атаковать основных рупоров борьбы с пиратством: ассоциации правообладателей, музыки, киноконтента, тех, кто гнобил WikiLeaks, и многих других.
2010–2016: эволюция методов защиты
Следующий исторический период — это эволюция и активное видоизменение методов защиты.
2011–2014: Несчастья Sony
Начнём с замечательной компании Sony, для которой период с 2011 по 2014 годы был не самым лучшим. Наложилось много факторов: землетрясение в Японии, которое уничтожило часть производства, утечки информации, уходы ключевых сотрудников и судебные скандалы. Но немаловажным фактором во всей этой несчастной истории был именно DDoS.
Атаки на Sony привели к осознанию того, что DDoS можно использовать не только, чтобы положить ресурс, но и для того, чтобы замести следы или скрыть факт взлома. Например, мы начинаем DDoS атаку, ложится Firewall или экран веб-приложения, которое не в состоянии обработать такую нагрузку. Его приходится выключить из обращения, вывести в параллель или вообще погасить. В этот момент можно организовать попытку взлома, получить shell, посадить нужный backdoor. Потом провести ещё одну DDoS-атаку для того, чтобы снова всё легло, и инженеры занимались отскребанием DDoS, а не поиском того, где внезапно появился несанкционированный доступ.
Первый такой инцидент случился в 2011. Sony сначала заDDoS’сили, потом взломали сервера PlayStation Network, вынудив этим взломом выключить Sony сервера более, чем на 3 недели. По подсчётам компании это им стоило более 150 миллионов недополученной прибыли.
Атаки на сеть Sony PlayStation продолжались каждое Рождество с 2011 по 2014 год. Последний год — вишенка на торте. Тогда произошла крупнейшая DDoS атака на все основные сайты Sony, в результате которой утекло всё, что только можно (киноконтент, сценарии, ранние версии игрушек и прочее).
Группировка, которая кошмарила Sony большую часть времени, называлась Lizard Squad. Она интересна тем, что использовала нафармленный ботнет в основном из commodity роутеров в подъездах (в домашнем интернете). Причём она не только использовала их для своих атак, но ещё и сдавала его в аренду всем желающим. Она заявляла мощность своего ботнета в более чем 100 ГБит/с. По тем времена это был рекорд, но, тем не менее, психологическая планка, к которой приближались, но ещё не переваливали.
2011: А что у нас?
Вот, что происходило в российском интернете примерно в тот же период. Интересные цифры, которые занятно выглядят в исторической перспективе:
Это связано с ограниченными возможностями интернета тех, кто генерирует, и особенно тех, кто принимает. В бизнес-инфраструктуре каналы больше гигабита ещё тогда были невиданным делом. Поэтому гнать атаки большей полосы на чьи-то сервера не было особого смысла.
Трудно себе представить, но уже тогда были атаки длительностью 1228 часов. Это означает, что такой вариант борьбы с DDoS как блэкхолинг, когда весь трафик из сетей, откуда идет DDoS, сливается в black hole, и соединения оттуда вообще не принимаются, с такими атаками больше не работает. Потому что в это время в этих сетях, через которые передаётся трафик, найдётся достаточное количество настоящих хороших юзеров, а их надо бы пропустить. Если просто выключить для них доступ, можно очень многое потерять.
Наибольший размер обнаруженного ботнета составил примерно 200 тысяч активных IP-адресов. Как складывается эта цифра? Подавляющее большинство хостов — зараженные домашние и офисные Windows-машины. Одна часть задействуется под атаку, а другая находится в резерве, потому что светить всеми IP-адресами против сервиса защиты не очень правильно: сервис может перебанить адреса, и следующей атаки уже не получится. Помимо этого, ночью пользователи выключают Windows-машины, утром уходят на работу, вечером возвращаются – какая-то часть еще и выключена вовсе. Существует некоторый пик присутствия участников ботнета, который можно задействовать. Поэтому когда мы говорим об увиденных 200 тысячах адресов в одной атаке с ботнета, в реальности там может быть и миллион IP.
2013: Атаки на Spamhaus
Организация Spamhaus, которая борется в интернете со спамерами и прочими неблаговидными личностями, внесла в черный список адреса печально тогда известного хостинг-провайдера CyberBunker. Владельцы и пользователи CyberBunker оказались этим недовольны и, как ранее спамеры в случае с PANIX, начали DDoS’сить хосты Spamhaus.
После первой атаки около сотни гигабит в секунду Spamhaus понял, что сам это не вывезет и обратился к начинающей тогда фирме Cloudflare с её облаком. Cloudflare ответил: «Не проблема!». Отфильтровал 70-80-100 Гбит/с, написал отчёт и прислал графики. Тогда CyberBunker налил втрое больше, и плохо стало уже Cloudflare. Таким образом в 2013 году впервые был преодолен порог в 100 ГБит/с.
Такой лёгкий переход от (70 к 300Гбит/с) означал, что возможности по генерации атак типа DNS Amplification у хакеров ограничены только магистральными каналами в интернете. Сколько можно прогнать трафика через backbone – такая и будет наибольшая атака. Проблем же с самой генерацией, с задействованием публичных DNS-резолверов для устраивания амплификаций не было и нет.
Радует только то, что с тех времен количество DNS-серверов, которые можно задействовать для Amplification, неуклонно снижается. На это есть ряд причин: одни закрывают порты, другие мигрируют на облачные DNS-сервисы и уже не нуждаются в персональных резолверах.
Возможно, в какой-то момент график достигнет тех значений, когда гонять DNS Amplification будет совсем невыгодно. Но он ещё не наступил.
2010–2016: Развитие сервисов защиты
Когда мы говорим про атаку, нельзя забывать про защиту от DDoS. Что происходило с ней в тот период?
Всё началось с коробок под названием Customer On-Premises Equipment. Это оборудование, которое ставится в инфраструктуру заказчика. Это сервера, специализированные юниты, которые умеют быстро отфутболивать плохой трафик: пропускать только то, что разрешается, и имеют гибкую систему настройки правил. Но очень быстро стало понятно, что с атаками в сотни гигабит и десятки мегапакетов в секунду справляться могут только батареи таких коробок. Их нужно ставить в инфраструктуру по 5, 10, 20 штук, а это капитальные расходы, лицензии и непрогнозируемые затраты со временем.
Поэтому для ряда крупных игроков стало естественным перемещение коробок в сеть оператора связи. У него связность выше, трубы толще, он может себе позволить держать специализированный центр очистки трафика. Направленный на такой центр трафик будет фильтроваться, и к нему можно подключать n-ое количество клиентов, которым нужна защита от DDoS. Так появилась операторская защита. Начало 2010 года стало тем самым моментом, когда выделенные коробки от вендоров Arbor, Radware и Cisco, стали переезжать к крупным интернет-провайдерам.
Но возникла новая проблема — атаки вышли далеко за пределы 100Гбит/с, и не каждый оператор мог вывезти их на своей магистрали. К тому же у оператора ограниченное количество точек подключения, своя география. Даже если это провайдер Tier-1, то он обычно захватывает n-ое количество регионов. В зависимости от локации атаки, пропустить ее трафик на очистку через эти ограниченные стыки может быть трудно.
Так возникли распределённые сети фильтрации. Многие их называют облаками, хотя это не совсем облака с точки зрения организации. Эти сети используют подключение к разным провайдерам, имеют большое количество центров очистки в разных регионах, умеют за счёт увеличения площади своей поверхности принимать на неё большое количество DDoS-трафика – и честно обрабатывать каждый прилетевший в эту сеть пакетик, битик, чтобы до клиентов, которые у них защищаются, долетел только чистый трафик.
Этот путь был проделан примерно за 5-6 лет. Как и в случае с атаками, все эти варианты прекрасно сосуществуют, имеют свою целевую аудиторию и свои специфические задачи. Самые крупные бизнес-игроки обычно комбинируют у себя все три описанных типа защиты.
2016–2018: терабитные атаки; бутер-сервисы
В этом эпизоде истории атаки продолжают поднимать планку в цифрах и в массовом сознании, затрагивая все большее и большее количество людей.
2016: Mirai и «DDoS из чайника»
В 2016 году стало ясно, что участниками ботнета могут быть не только взломанные машинки или сетевые устройства, но и любая IPTV камера, домашний смарт-ТВ и даже чайник с выходом в интернет. Шутка про “DDoS из каждого чайника” имеет куда большие связи с реальностью, чем можно предположить.
Реальная такая DDoS-атака случилась в 2016 году. Первая волна пришлась на сайт KrebsOnSecurity исследователя Брайана Кребса, который исследовал действия хакеров на протяжении многих лет. Она произошла с использованием ботнета, названного Mirai — замечательный кусок кода, написанный на С. В его арсенале огромное количество разных методов атак, всевозможные флуды на транспортном и прикладном уровне с хитрой инкапсуляцией, чтобы обманывать коробки, фильтрующие DDoS. Например, используются заголовки GRE (туннелирование). Многие коробки, которые тогда видели трафик Mirai, распознавали его как что-то важное для серверов в инфраструктуре, поэтому не фильтровали, а пропускали. За счет этого многие атаки достигли цели.
Такая атака внезапно выстрелила на 600 ГБ. Количество ботов, которые засветились в этой истории, составляет почти 150 тысяч. И это был не предел. Очень скоро случилась атака на французский хостер OVH, где цифры достигли терабита в секунду! С условностями, но всё же это произошло.
Атаки продолжались некоторое время, не снижая своей интенсивности. OVH справился за счёт гигантской канальной ёмкости и быстрого реагирования. А вот атака на DNS-провайдер Dyn вывела его из строя очень надолго, а вместе с ним и примерно 14 тысяч популярных сайтов, которые у него резолвились. Почти у всего восточного побережья США всё перестало работать. Именно атака на Dyn запустила расследование, судебное разбирательство, в рамках которого нашли авторов Mirai и привлекли к порядку.
Как победили ботнет Mirai? Казалось бы, IT-устройства уязвимы, их прибавляется каждый год, остаётся лишь их заражать – ботнет будет только расти. Но кто-то очень умный и дальновидный слил исходники Mirai на GitHub. Таким образом на месте Mirai, который мог собрать сотни тысяч ботов в одну атаку, возникло больше сотни аналогичных ботнетов, которые боролись за один и тот же пул взломанных устройств (уязвимых роутеров, камер, чайников и скороварок). Один большой ботнет развалился на кучу маленьких, а каждый из них по отдельности не смог оказать большого эффекта. Так угроза Mirai была уничтожена по принципу «разделяй и властвуй».
2016: Как давно существует DDoS как сервис?
DDoS as a Service использовался ещё атакующими Sony — Lizard squad, но только после атак Mirai о нём стали публично разговаривать. Эти атаки показали, что сдача ботнета в аренду для проведения DDoS на определенное время – популярный метод заработка среди киберпреступников. При этом не нужно нанимать самого хакера и договариваться с ним, чтобы он кого-то взломал. Достаточно лишь взять в аренду ботнет из 50 тысяч устройств за скромную сумму, и можно в течение часа поливать огромным мусорным трафиком заданный хост жертвы. Очень просто!
Два израильских подростка организовали самый крупный из DDoS-сервисов под названием vDos. Он был выведен на чистую воду в 2016 году. Но, естественно, как и с любым cобытием, которое попадает в массовое сознание, это не послужило предостережением, а, наоборот, призывом к действию. Поэтому на месте vDos появились сотни других бутеров – сервисов по аренде DDoS-ботнетов, которые переехали в даркнет и принимают заказы там.
2018– н.в.: Memcached, гибриды, Mēris, новые протоколы
Этот период характерен появлением новых типов атак. До этого было лишь количественное наращивание методов DDoS, с которыми все уже знакомы.
2018: Memcached amplification
Первое, что удивляет — это появление атак с амплификацией, но не NTP или LDAP, а Memcached. Казалось бы, это инструмент, с помощью которого кэшируется контент. Куча очень крупных ресурсов с большим количеством серверов на Edge используют Memcached, но оказывается, что его можно эксплойтить. Если мы обратимся к нему, запросив достаточно большой кэш и указав адрес жертвы в качестве получателя, они будут слать мусорный трафик, повинуясь действиям DDoS’ера.
Атака сходу пробила все возможные потолки, разогнавшись до 1,35 ТБ. Такого ещё никто не видел!
Угроза не в том, что метод слишком сложный или отличается от того, что мы уже видели. А в том, что по цифрам из Shodan в 2018 году количество серверов, которые могут быть задействованы по открытым портам, составляло примерно 90 тысяч – у ничего не подозревающих организаций в интернете.
Естественно, началась массовая работа, чтобы убрать их из доступа и снизить количество амплификаторов. Наш любимый CERT вместе с GitHub, который писали постмортем по атаке, выпустили ряд рекомендаций. Вот самая ключевая из них:
Но как тогда работать? Далеко не везде для кэширования можно использовать TCP, и при этом сохранять те метрики производительности, которые вы имеете на продакшене. К счастью, нашлись другие пути для улучшения ситуации. Выяснилось, что CentOS, например, в определённой версии сразу открывает UDP-порт наружу, когда вы ставите Memcached. Это можно пропатчить, провести небольшую ревизию в хозяйстве и таким образом закрыть дырку.
В общем, с Memcached худо-бедно, но справились, а буквально через год случился новый прикол, которого никто не ожидал.
2019: TCP SYN-ACK Amplification
Мы говорили про амплификацию на базе UDP-протоколов: очень просто спуфить, так как никто не проверяет source-адрес, то есть того, кто шлёт трафик. Факторы амплификации тоже довольно большие — умножение полосы и пакетов в десятки и сотни раз. Делать то же самое с помощью TCP, казалось бы, бессмысленно – фактор амплификации несравнимо меньше.
И вот результат:
Защищая своих коллег из Servers.com, Qrator Labs выдержал атаку, которая продолжалась больше половины суток. С помощью амплификации пакетов SYN-ACK на транспортном уровне атакующие сумели пробить планку в 200 мегапакетов в секунду. Это — очень много. Тогдашние SYN-флуды составляли всего лишь десятки мегапакетов (30-60 Mpps) в секунду.
Фактор амплификации такой атаки реально низкий. Он работает за счёт перепосылки одинаковых сегментов при их неполучении, а не за счёт увеличения payload у отправляемого сегмента. Поэтому до поры до времени использовать его для широкополосных DDoS-атак было не очень выгодно.
Вот данные из отчёта Qrator Labs о том, сколько амплификаторов и с какими факторами появились в 2019 году на базе UDP:
Видно, что факторы амплификации — единицы, десятки, сотни — вполне себе достижимы. Но количество таких машин снижается, и разогнать мега-мощную полосу с помощью них к 2019 году стало намного сложнее. Приходится конкурировать за эти ресурсы. На фоне этого атаки с использованием TCP SYN-ACK Amplification внезапно стали более выгодными. Теперь они появляются достаточно часто. Особенно, если учесть, что число потенциальных хостов, которые могут быть использованы в этой амплификации, сравнимо с общим количеством UDP-based амплификаторов по всем протоколам.
2021: Mēris на роутерах MikroTik
Буквально следующим случаем стало то, что было сложно ожидать. Кто-то заразил сотни тысяч MikroTik одинаковым ботом и устроил ими прикладную атаку на десятки миллионов запросов в секунду.
Это серьёзнейшая нагрузка на любой балансировщик, тем более, что она использует HTTPS — соответственно, дополнительные затраты на TLS-шифрование. Такую атаку пережить, пожалуй, никто не в состоянии, кроме очень крупных сетей и специализированных провайдеров.
Яндекс с честью справился с атакой и поделился с Qrator Labs данными. По итогам исследования в Qrator Labs назвали этот ботнет Mēris (с латышского — чума), потому что эффект от попадания такой атаки для любой инфраструктуры сравним с эпидемией чумы.
Cloudflare сумел выдержать похожую атаку. Сразу же началась общественно-административная работа по донесению сведений до владельцев MikroTik о том, что им срочно надо патчить устаревшие RouterOS — уязвимость уже несколько лет как была известна. В Qrator Labs выпустили плашку на своих ресурсах для проверки: «Не являетесь ли вы членом ботнета Mēris, не фигурировал ли ваш IP в его DDoS-атаках?».
Однако, оказалось, что возможности Mēris в 2021 году лишь частично были засвечены, потому что уже в следующем году Google получил вдвое большую атаку такого же типа. Поэтому Mēris, как чума, продолжает шагать по мировому интернету и набирать себе преданных поклонников.
Итоги
Что мы узнали и чему научились?
→ Новые методы появляются, старые не уходят.
DDoS-атаки работают по накопительному принципу. Например, SYN Flood ежегодно входит в ТОП-5 атак.
→ Рекомендации экспертного сообщества помогают только на бумаге, в отличие от проактивных мер.
Только реальные практические рекомендации защищают от DDoS-атак.
→ Большинство методов DDoS не «фиксятся» без изменений протоколов, а это занимает десятилетия.
Пофиксить протокол, чтобы через него нельзя было DDoS’сить, — невозможно, потому что смена протоколов длится десятилетиями. За это время можно положить всех, кого только можно.
→ Повышение качества жизни, которое несут новые протоколы, и в принципе, развитие интернета — это одновременно повышение возможностей для атакующих.
Поэтому вперёд в новое светлое будущее с новыми протоколами, с новыми DDoS атаками и, надеюсь, с новой защитой!
