ИТ-портал компании «Инфосистемы Джет»

Эволюция DDoS-атак: от первых инцидентов до терабитных атак

Эволюция DDoS-атак: от первых инцидентов до терабитных атак

Первая в мире DDoS-атака — SYN flood — была зафиксирована в 1994 г. А рекомендации по противодействию атакам такого рода были опубликованы лишь в 1996 г. Эти материалы подготовил Координационный центр CERT (Computer Emergency Response Team) Университета Карнеги — Меллона, официально признав таким образом наличие проблемы. Поводом для подготовки рекомендаций стало первое масштабное нападение — на крупнейшего интернет-провайдера Нью-Йорка Panix Networks. Это была коммерческая атака, организованная спамерами, которые решили отомстить компании за то, что она не позволила им рассылать рекламные сообщения пользователям.

В том же 1996 г. впервые был опубликован набор публичных инструментов с исходным кодом для осуществления DDoS-нападений. Спустя два года этот инструментарий был задействован против Мичиганского университета — состоялась вторая крупная DDoS-атака.

В 2000 г. проведены атаки RiverHead & MafiaBoy (последнюю провел 15-летний канадец, из-за действий которого почти неделю лежали такие ресурсы, как Yahoo!, Fifa.com, Amazon.com, eBay, CNN, Dell и др.).

Здесь заканчивается эра blackhole/sinkhole — то есть полного сброса трафика, этот метод уже не может нейтрализовать наиболее крупные атаки. Наступает следующий этап — применение Customer Premises Equipment от поставщиков оборудования для защиты от DDoS на стороне заказчика.

В 2001 г. появляются атаки HTTP flood (в этот момент оформляется индустрия кибербезопасности).

В 2003 г. DDoS докатился и до России: был атакован MasterHost — самый крупный хостинг нашей страны на тот момент.

В 2004 г. Cisco Systems поглотила израильского разработчика средств предотвращения атак Riverhead Networks. Благодаря этой покупке ей удалось создать первый успешный коммерческий продукт для борьбы с DDoS — Cisco Guard.

В 2005 г. Arbor Networks на ежегодном мероприятии World-Wide Infrastructure Security Survey сообщила о мощной атаке 8 Гбит/с.

В 2007 г. серьезным распределенным атакам на отказ в обслуживании подверглась Эстония. Впервые всю силу DDoS-атак ощутило на себе государство, до этого считалось, что такими инструментами пользуются пранкеры/вымогатели.

В 2008 г. появляется хакерская группа Anonymous, которая занимается дефейсами сайтов и DDoS-атаками.

В 2011 г. реализована DDoS-атака на компанию Sony, комбинированная с проникновением. Результатом стала компрометация данных учетных записей Playstation Network.

Начинается эра глобальных облачных сервисов защиты от DDoS.

В 2013 г. из мести атакована организация Spamhaus, 300 Гбит/с — новый рекорд мощности атаки.

В 2014 г. хакерская группировка Lizard Squad на рождественские каникулы устраивает атаку на Xbox Live и Playstation Network.

В августе 2016 г. — во время Олимпийских игр — происходят атаки мощностью до 500 Гбит/с.

В сентябре 2016 г. реализована атака ботнета Mirai в 620 Гбит/с на сайт журналиста-расследователя Брайана Кребса. Провайдер Akamai отключает сайт Кребса от защиты (которую предоставлял pro bono).

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

В 2016 г. с использованием ботнета Mirai проводятся мощные атаки 620 Гбит/с — 1,2 Тбит/с на провайдера DNS-сервиса Dyn, в США наблюдаются перебои с доступом к сайтам.

В 2018 г. реализуются атаки на GitHub с использованием найденной в популярной библиотеке memcached уязвимости (500 Гбит/с — 1,7 Тбит/с).

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

В начале 2018 г. было установлено сразу несколько рекордов. В конце февраля компания Qrator Labs, специализирующаяся на противодействии DDoS-атакам и обеспечении доступности интернет-ресурсов, зафиксировала атаку полосой 500 Гбит/с на платежную систему Qiwi. Всего за несколько дней пиковая скорость атаки выросла до глобальных масштабов — 1,7 Тбит/с, о чем рапортовал Arbor Netscout, нейтрализовавший данную атаку, направленную на самый популярный репозиторий кода — GitHub.

На сегодняшний день, на пороге 2019 г., ландшафт DDoS-атак представлен частыми атаками в первую очередь прикладного уровня (L7 по модели OSI). После истории с ботнетом Mirai, создатель которого по приговору суда получил два года тюрьмы и штраф 8 млн долл., очень немногие случайные люди атакуют крупные цели. И дело не в страхе наказания, а в увеличившемся «входном пороге» для осуществления серьезных атак, способных нанести повреждения достаточно масштабным интернет-ресурсам так, чтобы это стало заметно.

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

В 2019–2020 гг. DDoS-атаки имеют все шансы выйти на уровень более 10 Тбит/с. Этому будут способствовать экспоненциальный рост количества подключенных к сети устройств (развитие IoT) и линейный рост числа уязвимостей, к чему приводят отсутствие общепринятых практик безопасности при разработке, а также по-прежнему низкая грамотность пользователей. Такие необходимые действия, как обновление прошивок и изоляция сетевых устройств от внешнего доступа, выполняются не везде. Мощные атаки опасны в первую очередь тем, что такой объем трафика способен исчерпать доступную полосу среднего регионального провайдера. Невозможность фильтровать трафик на уровне ключевых узлов сети — это очень опасный фактор. Поэтому появление волны недоступности интернет-ресурсов, потенциально влияющей на несколько крупных стран и регионов, — это лишь вопрос времени.

Сочетание сложности и объема трафика уже приводит к тому, что наиболее целенаправленные атаки на специфические болевые точки приложения очень сложно нейтрализовать эффективно и быстро — без простоя.

Но растет не только количество устройств. Ключевой единицей взаимодействия в сети является не отдельное устройство, а сущность — автономная система (AS). На сегодняшний день в мире зарегистрировано более 60 000 автономных систем. Вот здесь и начинается будущее безопасности объединенных сетей. Насколько успешно удастся противодействовать манипуляциям с маршрутизацией? Ведь злоумышленники обязательно будут эксплуатировать уязвимости протоколов ядра интернета: DNS и, в первую очередь, BGP.

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

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

1. Все больше трафика в интернете шифруется. По данным Let’s Encrypt к моменту написания данной статьи, в браузере Firefox 76,5% страниц загружалось с использованием защищенного соединения. Это не значит, что три четверти интернета «зашифровано», но динамика данного показателя, составлявшего 25% в начале 2014 г., однозначно свидетельствует об успешном принятии SSL-сертификатов в вебе. Зашифрованный трафик, казалось бы, бессмысленно перехватывать.

2. Человечество начало подключать к сети абсолютно всё. И то, что в свое время произошло с электричеством, мы наблюдаем в настоящее время с интернетом в еще больших масштабах. Каждая камера, трекер, мобильный телефон и бесчисленное множество других мелких и крупных гаджетов сегодня отправляют стабильный поток информации в лучшем случае на сервер производителя.

3. Сеть построена фактически на основе одного протокола — BGP. Border Gateway Protocol, или протокол граничного шлюза, — это краеугольный камень архитектуры современного интернета. Как бы странно это ни звучало, но протокол слабо защищен от атак злоумышленников, так как представляет собой протокол «доверия». При этом операторы AS не сдают никаких экзаменов, не получают сертификаты и т. д., находясь в равных возможностях со всеми другими AS.

Сценарии получения сертификата безопасности злоумышленником

Процедура получения TLS-сертификата для домена от сертификационного центра TLS (CA — Certificate Authority) обычно проходит в следующей последовательности:

1. Создается аккаунт на веб-сайте центра сертификации.

2. CSR (certificate signing request — запрос подписи сертификата) создается и загружается на сайт центра сертификации.

3. Центр сертификации предлагает опции подтверждения владения доменом: WHOIS-запись — загрузка специальной HTML-странички по требуемому URL — создание уникального токена в записи DNS TXT (а также иногда другие способы).

4. После подтверждения владения требуется оплатить (некоторые сертификаты бесплатные) услуги центра сертификации — и всё: вы получаете TLS сертификат!

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

Злоумышленник может легко мимикрировать под владельца сайта, совершая атаки перехвата трафика.

К чему же всех нас приводит эта архитектурная диспозиция?

Во-первых, мы уже видели, как некорректная конфигурация автономных систем и анонсов сетевых префиксов наносит урон, несовместимый с нормальной работой сетевых ресурсов, поскольку единовременное перенаправление трафика крупного ресурса может вывести из строя неподготовленную транзитную точку — то есть потенциально любую AS. В этом году в результате подобной «утечки маршрута» ресурсы Google были недоступны в Японии.

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

Злонамеренность или случайность подобных сетевых инцидентов оценить тяжело, но общее число ликов/хайджеков — достаточно легко. По методологии Qrator.Radar, «хайджек» (hijack), или перехват трафика, отличается от «рут лика» (route leak), или утечки маршрута, отсутствием корректных регистрационных данных при создании маршрута.

На момент написания публикации:

1) утекших префиксов — 92 585 от 544 операторов, из них хорошо распространившихся — 2195 префиксов от 322 операторов;

2) хайджеков/перехватов — 102 602 префикса от 8589 операторов, из них хорошо распространившихся — 54 564 от 7665.

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





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

Негативные сценарии

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

Ведь если можно перехватить и перенаправить для обработки запросы пользователей на заранее выбранные поддельные серверы, то ни пользователь, ни владелец ресурса сразу же не идентифицирует подмену. Как мы уже упоминали, даже установленный сертификат не гарантирует безопасности пользователей или вашего бизнеса, ведь злоумышленники могут выпустить вполне легальный сертификат, легитимный для браузера пользователя, при помощи все того же перехвата. Также они могут самостоятельно подписать фальшивый сайт, на который пользователи попадут в результате перехвата трафика. Итогом такой атаки могут стать колоссальные убытки для бизнеса, при том что пользователь ничего не заподозрит. Подобная атака была проведена в недавнем прошлом на одно из крупнейших облаков в мире — Amazon EC2, когда на фишинговом сайте использовался самоподписанный сертификат. По идее, у пользователей должны были возникнуть подозрения, но так как далеко не все смотрят на значки «замка», означающего корректный сертификат для запрашиваемой страницы, то за 2 часа атаки из одного популярного криптокошелька было выведено активов на сумму около 150 000 долларов. Издание The Register, специализирующееся на инфобезопасности, подробно описало инцидент в конце апреля 2018 г.

Добавим лишь, что этой возможности эксплуатации протокола BGP уже более 10 лет.

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

Нет. В мире перехватов трафика удар может быть нанесен (и будет нанесен!) в первую очередь по вашей репутации, и есть проверенный способ сделать это — дефейс (deface). Именно так называется изменение внешнего вида страницы, отображаемой через браузер пользователя. И хорошо еще, если это будет «безобидная» детская проделка с кучей рекламы, угроз или прочего непотребства на главной странице вашего ресурса. Но подумайте о том, к каким последствиям может привести спланированная атака. Пользователи в течение дня или нескольких часов будут видеть фальшивую резонансную новость, опровергать которую впоследствии вы будете долго и мучительно (и с финансовыми потерями). Не будем забывать и о том, что в каждой стране есть законы, за нарушение которых любой информационный ресурс закроют в два счета из-за угрозы национальной безопасности.

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

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

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

Возьмем для примера любую сеть доставки контента (CDN). Сегодня без таких сетей невозможно существование крупных, глобально распределенных ресурсов, предоставляющих контент в точке, наиболее близкой к пользователю, его запрашивающему.

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

В результате перехвата трафик такой сети может начать двигаться по произвольному маршруту — например, через другой континент. Как вам задержка в 100–200 миллисекунд для каждого из пакетов по направлению к CDN? Подобный рост сетевой задержки сильно повлияет на скорость реакции сервера на запросы.

И это проблема не столько сетей доставки контента, сколько классических операторов связи — в первую очередь предоставляющих широкополосное подключение к сети. Вы гарантируете своим клиентам набор параметров в виде SLA? А что будет, если ваш бизнес не сможет выполнить обещания? Мы все знаем, что происходит на конкурентном рынке: потребитель выбирает альтернативного поставщика. Гонка за временем в процессе майнинга криптовалют (вознаграждение достанется только той группе майнеров, которая первой нашла «правильный» хэш для нового блока) — еще один интересный пример того, как сетевая задержка может перевернуть парадигму сервиса или процесса, в котором задействовано множество людей.

Основное, что нужно запомнить из всего рассказанного нами о вероятных последствиях утечки или перехвата трафика, — это то, что атакующему не требуется слишком много «телодвижений» для достижения своей цели. Помимо вышеупомянутых способов нанести вред, злоумышленник всегда имеет абсолютно реальную возможность вывести ваш ресурс из строя, просто направив перехваченный трафик в пустоту. В реальности все даже чуть хуже, чем рисует воображение, так как подобный вариант развития событий может произойти и по причине чужой ошибки. Бритва Хэнлона идеально работает в мире современных сетей, ежедневно подтверждая известную фразу: «Никогда не приписывайте злому умыслу то, что вполне возможно объяснить глупостью». Такой постулат постоянно доказывают разнообразные инциденты маршрутизации, часть из которых мы освещаем в блоге сервиса Radar. Крупные компании, впервые сталкивающиеся с подобной проблемой, обычно тратят больше часа только на установление причин, а для применения контрмер могут потребоваться дни. И все это время бизнес простаивает, терпя соответствующие убытки.

Как оценить ущерб от подобного инцидента? Как установить, был ли инцидент локальным? Насколько серьезными могут быть последствия? Для этого необходимо получить ответ на ключевой вопрос: чей трафик был перехвачен?

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

Можно ли защититься от атак на маршрутизацию? К сожалению, нельзя. Существуют определенные способы противодействия, так как приоритет на пути движения трафика всегда отдается более специфичным (more specific в терминологии BGP) путям. Но, для того чтобы начать анонсировать такие пути от вашей автономной системы, как минимум нужно вовремя узнать о том, что произошло что-то плохое. Как?

Мониторинг и только мониторинг

Более того, на сегодняшний день эта услуга бесплатна при условии обновления данных раз в 24 часа. И именно созданием такого продукта занимается команда Radar внутри Qrator Labs. По состоянию на конец 2018 г., Radar — это крупнейший в мире коллектор путей, собирающий данные от более чем 500 сессий по всему миру и имеющий возможность отслеживать даже локальные изменения. Открытыми данными бесплатного онлайнового сервиса Radar уже сегодня пользуются более 3500 операторов уникальных автономных систем.

На данный момент Radar реализует мониторинг в режиме реального времени (платная услуга для крупных заказчиков), что означает время реакции не более двух минут после интеграции с нашей системой на начало инцидента. Помимо прочего, наш сервис старается не только отслеживать сами случаи перехвата, по возможности предлагая контрмеры, но и пытается предотвратить саму принципиальную возможность использования данного вектора атаки. Для этого мы активно сотрудничаем с сообществом и предлагаем собственные решения, начиная от закрытия уязвимостей в популярных продуктах (таких как Quagga, Bird) и заканчивая полным искоренением глобальных инцидентов подобного плана с помощью расширения, позволяющего регистрировать отношения между обладателями автономных систем, что лишает злоумышленника возможности нарушить установленные участниками транзита связи.

Краткий обзор эволюции и развития DDoS-атак.

Для людей, знакомых с процессом создания и внедрения обновлений протоколов ядра интернета, уточним: сетевые инженеры Qrator Labs совместно с зарубежными специалистами, в рамках Инженерного совета интернета (IETF), разрабатывают расширение протокола BGP под названием AS Provider Authorization, направленное именно на борьбу с утечками маршрутов и перехватом трафика (черновик расширения доступен в IETF Datatracker по адресу https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/).

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su