Конференция BLACK HAT. Уроки выживания при DDOS-атаке 300 Гбит / с. Часть 1
Интересным в этой атаке было то, что нас не решились атаковать прямо, а пошли по цепочке наших провайдеров. Они принялись атаковать upstream-провайдеров, расположенных выше CloudFlare, и источник атаки действительно находился в Лондоне. Сначала я не был в этом уверен, но поскольку Spamhaus тоже находился в Лондоне, возможно, хакер тем самым хотел поставить их в постыдное положение. Как я говорил, техническим вдохновителем атаки вроде бы был подросток из Лондона, возможно, таким образом он мог более эффективно отследить эффект своей атаки. На этом слайде показан маршрут BGP трафика, который включал в себя максимум 30 транзитных узлов next-hop.
Я скрыл расширения адресов лондонского провайдера широкополосной связи, последний hop – это один из IP-адресов Spamhaus, их было несколько в нашей сети. Вы видите, как маршрутизировался трафик, по приведенным данным сложно определить точный путь, однако он был направлен к нашему оборудованию в Лондоне, куда попал спустя 17 миллисекунд после прохождения пограничного IP-адреса нашей сети, которая работала в Лондоне.
Сначала злоумышленник атаковал этот адрес, отмеченный стрелкой, и поскольку здесь используется распределенный DNS, то он слегка ударил по Лондону, немного по Амстердаму и Франкфурту, по США, Азии и немного по Австралии. Затем хакер понял, что атака получилась рассеянной и не эффективной, и решил подняться вверх по цепочке маршрутизации над дополнительными частями инфраструктуры. Поэтому после последнего IP-адреса он перешел к предпоследнему IP-адресу. Опять же, если вы не знаете, как работает интернет-маршрутизация и соединения, скажу, что частично трафик обменивается прямо между сетями, когда я подсоединяю свою сеть непосредственно к другой сети. В данном конкретном случае трафик поступает в нашу сеть из сети Sky, проходя через то, что известно как Лондонская интернет-биржа, или LINX.
Атакующие принялись пропускать тонны трафика через LINX как порт. У нас в LINX имеется порт с относительно скромными возможностями, поэтому если вы посылаете 300 гигов трафика в порт LINX, вы перегружаете наш порт и другие порты этой биржи. Так что самым разумным решением для нас было сбрасывать соединение через этот порт, как только мы видели, что его атакуют, и трафик «обтекал» его другими путями.
Проблема была в том, что существовал сопутствующий ущерб, который затронул остальные порты LINX, так, что другие провайдеры крупных интернет-сетей также испытывали проблемы из-за того, что мы отбрасывали трафик. Это было довольно неприятно, и впоследствии мы работали с ними, чтобы помочь им защитить свои сети.
Атака вызвала временные региональные нарушения, но у нас была хорошая возможность перенаправлять трафик на другие узлы, чтобы создать возможность оставаться в режиме онлайн для Spamhaus и всех остальных наши клиентов. Злоумышленники также затронули наших транзитных провайдеров более высокого уровня, посылая целую кучу трафика людям, с которыми у нас были заключены контракты на услуги сети. Их целью было причинить как можно больше неудобств нашим клиентам, так, что были затронуты части сетевой инфраструктуры, которые не относились непосредственно к нашей сети.
Возможно, что атаки достигали более высокого уровня, однако у меня нет данных, которые бы это подтвердили, но они атаковали базовые маршрутизаторы, работающие в ядре различных сетей. Фактически эта атака послужила гигантским пентестом не только нашей сети, но и сетей, которые нас окружали, провайдеров, которых мы использовали и провайдеров, которых использовали эти провайдеры. Получилось, что благодаря этой атаке мы провели аудит своих уязвимостей. Позже мы прошлись по разным интернет-биржам типа лондонской и реализовали лучшие решения в отношении настройки их сетей, чтобы повысить эффективность противостояния подобным атакам. Мы выяснили, что весь внутренний трафик организации не должен направляться через пограничные маршрутизаторы сети. Таким образом, если вы не хотите нанести удар по одной из таких бирж внутри сети интернет-бирж, её IP-адрес не должен маршрутизироваться через эти биржи. В идеале вы должны использовать 192.168, один из неразрешимых адресов RFC 1918, которые не могут быть маршрутизированы и пропускать через себя трафик, то есть сеть, для работы которой не требуется внешний доступ. Это лучшее, что можно сделать для противодействия такой атаке.
Есть и другие вещи, которые вы можете сделать, например, внутреннюю маршрутизацию Next Hop Self, чтобы убедиться, что трафик, который предназначен для передачи внутри сети, не будет использовать пакеты, поступающие извне. Вы должны не только проделать это для своей собственной сети, но и убедить upstream-провайдеров проделать то же самое.
Есть еще одна полезная вещь — граничная фильтрация для конкретного IP-адреса, основанная на понимании работы нашего приложения. Например, наше приложение работает с разными протоколами, и если мы видим UDP-пакет, не предназначенный для нашего DNS-сервера, значит, что-то пошло не так.
С тех пор мы сегментировали наши сети таким образом, что IP-адреса для веб-серверов отличаются от IP-адресов для DNS-серверов, и мы можем попросить наших upstream-провайдеров просто заблокировать весь UDP-трафик, поступающий к этому конкретному IP-адресу, чтобы обеспечить безопасность нашего сегмента сети. Подобное разделение адресов позволило нам проводить более агрессивную фильтрацию трафика высокого уровня.
Фильтр BGP Flowspec – наш настоящий друг, это протокол, который был предложен Cisco. Несмотря на то, что в нем имеются баги, мы используем этот протокол и предпочитаем, чтобы транзитные провайдеры его тоже использовали, потому что это позволяет передавать наши правила на удаленные узлы сетей, влияющих на наши маршруты. Это позволяет очень быстро ответить на подобную атаку.
Особенного упоминания заслуживает трехуровневая архитектура nLayer, и я хочу выразить огромную благодарность её создателям из GTT, которые провели колоссальную работу, чтобы их сеть была особо устойчива к атакам. Как только они видели пики этой атаки, то быстро отбивали трафик даже от границ своей сети. Вы когда-нибудь задумывались, насколько круто быть провайдером Tier-1, Layer3 или NTT? Вся их работа – это сплошные выходные, потому что провайдеры первого уровня никому не платят за соединения, и это также означает, что они не могут никому перекидывать транзит. Поскольку мы начали блокировать атаку, отключая сегменты нашей сети, воздействие сконцентрировалось на небольшом числе провайдеров Tier-1, оказавшихся в центре атаки, и внутри их сети образовалась «черная дыра», в которую и устремился весь трафик, потому что ему больше некуда было деваться. Так что это было сложное испытание для многих провайдеров первого уровня.
Это одна из причин, по которой вы увидели Open Resolver Project созданный в первый понедельник после атаки. Ребята из nLayer действительно технически подкованная команда и они оказали нам большую помощь. Они с пониманием отнеслись к нам, а не просто сказали: «Иди отсюда, ты создаешь нам слишком много проблем». Итак, мы разработали практические шаги, которые вы можете осуществить, чтобы убедиться в безопасности своих сетей.
Это четыре рекомендации, первая из которых звучит глупо, но очевидно: сначала убедитесь, что вы не являетесь частью проблемы! Думаю, многие люди за последние годы это вам говорили. Просто остановитесь хоть на секунду и проверьте, что в вашей сети не запущены эти два компонента.
Первый – это открытые резолверы. Если они имеются в IP-адресном пространстве компании, если ваши клиенты их используют, вам необходимо их заблокировать или ограничить скорость трафика. Еще лучше настроить резолверы так, чтобы они принимали только тот трафик, который поступает напрямую из вашей сети.
На этом слайде вы видите мою любимую статью на сайте The Register, которую написал Тревор Потт. Она называется «Признание IT-профессионала: как я помог самой большой DDoS атаке».
Тревор пишет: «Я думал, что все делаю правильно. Но оказалось, что у меня был открытый резолвер, и я видел по журналам трафика, как запросы ударяли по Spamhаus». Я знаю, что здесь присутствуют люди, ответственные за работу очень больших сетей, в которых имеются открытые DNS-резолверы. Этим вы вносите свой вклад в создание вышеуказанной проблемы, поэтому прошу вас – потратьте буквально секунду времени и избавьтесь от них.
Второе — убедитесь, что вы используете BCP38. Ребята из iBall network проделали большую работу, но многие из присутствующих здесь людей, обеспечивающих работу больших сетей считают, что сеть закрыта, если они не разрешают внешний доступ.
Однако предположим, что у вас в сети оказывается один скомпрометированный сервер WordPress, который может начать спуфинг исходных пакетов, не предназначенных для вашей сети, и это вызовет большую проблему для остальных участников интернета.
Проблема – это открытые резолверы, это 28 миллионов резолверов, число которых увеличивается каждую неделю. Мы сможем победить эту проблему только совместными усилиями. Вы должны установить на своих пограничных роутерах флаги, которые давали бы уверенность, что они принимают пакеты только из доверенных источников внутри вашей сети. Если вы сделаете это, то лишите атакующих возможности использовать эту уязвимость. Трудность состоит в том, чтобы обнаружить большие скомпрометированные машины, которые работают в сетях и которые позволяют спуфинг.
Если рассмотреть атаки brute-force на WordPress, а там есть и другие атаки, например, с использованием сети ботнет, то вам будет трудно догадаться, что причина заключается именно в возможности использовать спуфинг.
Ещё одна рекомендация – используйте действительно надежные протоколы. Вы можете сказать: «Эй, я получил этот IP-адрес и запускаю службу по протоколу UDP, и сервис по протоколу TCP и ещё трафик по ICMP, и все эти протоколы я подвяжу к тому же IP». Хочу предупредить вас, что при возникнет проблема, ограничивающая вашу возможность гибко реагировать на такой тип атак, тем более, что вы спокойно можете сегментировать сеть таким образом, чтобы каждый протокол работал на своём собственном IP-адресе. Лучше всего, если вы сможете фильтровать upstream-трафик. Целью любой из этих атак является не остановка трафика внутри вашей сети, а блокировка его как можно ближе к источнику трафика, поэтому предоставляя кому-то возможность блокировать весь UDP-трафик, направленный к каждому IP, кроме выбранного адреса, вы значительно уменьшите поверхность атаки, которой может быть использована злоумышленником.
Таким образом, отдельные протоколы для отдельных IP эффективно работают при взаимодействии с upstream-провайдерами. Вы просто задаете им вопрос: «Эй, вы можете реализовать эти типы фильтрации?». Кстати, одна из причин того, что мы, как поставщики, поддерживаем Flowspec – это то, что мы с полным правом можем спросить их: «Парни, а вы поддерживаете Flowspec?», и если они отвечают «Да», разговор закончен, и мы можем развернуть наши собственные фильтры на границе сети так быстро, как только захотим.
Третья рекомендация – это реализация ACL-инфраструктуры, то есть использование списков контроля доступа. Я имею ввиду, что пакет не может предназначаться для вашей внутренней сети, если его источник не принадлежит к этой внутренней сети. Если пакет исходит из вашей сети или входит в вашу сеть с пограничного роутера, он не должен «путешествовать» по инфраструктуре вашей внутренней сети. Существует множество способов реализации этого положения. Вы можете применить фильтрацию для того, чтобы позволить некоторым IP-адресам не достигать границ сети, можете использовать маршрутизацию типа Next Hop Self, чтобы запретить обращение к некоторым внутренним адресам, можете использовать внутри сети протоколы RFC 1918, чтобы удостовериться, что ваши внутренние IP не используются для адресации из внешнего мира.
Это действительно способно принести дополнительную головную боль, так как вынуждает проверить настройки маршрутизатора, реально использовать сеть VPN, вместо того, чтобы претворяться, что вы её используете, и так далее. Это не самые популярные решения, но если их не осуществить, то атакующий может заглянуть в вашу сеть и нацелиться на её отдельные сегменты, чтобы нанести ещё больший вред.
Четвертая рекомендация – вы должны хорошо знать свой исходящий upstream-трафик. Хочу еще раз подчеркнуть, что при этой атаке не использовались сложные приложения или syn-пакеты, это был просто пещерный человек с увесистой дубинкой. В некотором смысле, у вас должно быть больше транзита, чем у плохого парня. Он может генерировать 300 Гбит / с трафика, и я уверен, что мало кто из присутствующих может похвастаться сетями с таким объемом трафика. Это означает, что у вас должен быть друг, у которого есть много исходящего трафика, и, привлекая его к сотрудничеству, вы прикрываете свою спину от подобного нападения. Мы очень избирательно относимся к исходящему трафику, с которым работаем, чтобы иметь возможность вовремя заметить атаку подобного рода.
На днях я беседовал с главным техническим директором крупного транзитного провайдера и спросил его, не собирается ли он продать мне транзит, на что он ответил – нет, ребята, от этого вы бы как клиенты получили только лишнюю головную боль.
Однако мы ищем такой трафик и даже выплачиваем провайдерам премии за транзит, который мы используем, потому что когда происходят атаки подобного рода, мы хотим иметь возможность позвонить им и попросить помочь смягчить последствия нападения. Вам не понадобится строить сети пропускной способностью 3-4-5 терабит, если вы сможете распределить пиковый трафик по партнерским сетям.
Это не обязательно должны быть компании с мощной DDoS-защитой, просто они должны использовать архитектуру nLayer для того, чтобы действительно хорошо делать свою работу и помогать вам, когда возникают проблемы. Работайте с ними в тесном контакте для того, чтобы расширить границы вашей сети. Используйте такую политику настройки сети, которая позволит вам примкнуть к границе их сетей, и поставщики готовы пойти на это, если у вас есть грамотные сетевые провайдеры. Вот и вся история об атаке интенсивностью 300 гигабит, у нас остаётся ещё около 10 минут для ответов на ваши вопросы.
Я прошу вас пользоваться микрофоном, если вы согласны стоять в очереди, чтобы задать вопрос. Ещё одно нововведение, о котором я забыл сказать: организаторы Blackhat хотят иметь обратную связь со спикером, и если вы «засветите» свой бейдж снаружи, они передадут вашу информацию в АНБ и тоже получат обратную связь. Я пошутил относительно первой части, но относительной второй всё справедливо – вы сможете воспользоваться обратной связью, так что можете обзывать меня идиотом и вообще задавать любые вопросы.
Вопрос: какие протоколы усиления, помимо UDP и 53, встречались вам при работе CloudFlare?
Ответ: вы спрашиваете, были ли другие протоколы усиления, кроме упомянутых? Мы до сих пор наблюдаем использование ICMP при выполнении старой доброй Smurf-атаки, однако ничто не сопоставимо с масштабами атаки, о которой я вам рассказал. Так что в следующем году мы будем категорически настаивать на том, чтобы люди не использовали открытые резолверы, а применяли законный, авторизированный DNS-сервер. Используйте CloudFlare, Bind или UltraDNS для запуска своих сетей, и если вы можете перечислить все домены, за которые ответственен авторизированный сервер, найти домены, которые имеют очень большие списки имен, то сможете защитить свою сеть, потому что такой сервер обладает возможностью при необходимости ограничить скорость трафика. Мы посвятили реализации этого решения кучу времени, и я с удовольствием расскажу об этом тому, кому это действительно интересно.
Вопрос: в данной атаке ботнет не использовался, но вы можете порекомендовать ресурсы, которые дадут возможность обнаружить, не используют ли большие сети, которыми вы управляете, ботнет для осуществления DDoS-атаки?
Ответ: это зависит от того, где вы находитесь — например, вы можете поискать такие инструменты в организациях, отслеживающих поведение ботнета, и найти то, что соответствует вашим потребностям. Если вам нужен проект с открытым исходным кодом, я рекомендую появившийся несколько лет назад Honeypot. С помощью него мы эффективно отслеживаем значительную часть мировых ботнет-сетей, вы можете задать диапазон ваших IP-адресов и он покажет, есть ли там вредоносные сети. Это только один из многих подобных проектов. Можно просто искать шаблоны аномального трафика, которые встречаются в вашей сети, так что если вы видите гигабит трафика, который направляется на один IP-адрес, и не существует никакой разумной причины, почему это происходит в данный момент времени, то вероятно, это трафик исходит не от веб-сервера, а от сети ботнет. Это должно вызывать у вас подозрения.
Вопрос: Google имеет один из самых популярных открытых DNS-резолверов, вы не считаете, что это может вызвать проблемы?
Ответ: они провели большую работу по ограничению трафика, и лучший способ в этом убедиться – это использовать такой же запрос digANY, какой я вам приводил в пример, и заменить IP-адрес сети PCCW адресом 888. Любой из присутствующих сможет отослать этот запрос только один раз, повторить его не получится. Так что они очень хорошо реализовали ограничение запросов. Еще одна разумная вещь, которой вы можете воспользоваться – это не требующий флагов UDP, который решает множество проблем, вы можете ограничить размер ответов, которые получите обратно, тем самым ограничив усиление.
Вопрос: встречали ли вы такое, чтобы провайдеры транзита внедряли BGP Flowspec, потому что вы, ребята, широко его используете, или же, если их сеть не имеет возможности поглощать много трафика, то они отказываются использовать BGP Flowspec?
Ответ: мы стараемся работать с клиентами, которые используют BGP Flowspec, но если вы видите здесь кого-то со значком Cisco, то к ним это не относится. Они придумали протокол, который никогда не реализовывали, но мы подняли достаточно шума, чтобы они учли наши пожелания при составлении плана развития сетей. Существуют сети, которые не поддерживают Flowspec на всем своем протяжении, и время от времени мы имеем с ними дело. Но мы всё же предпочитаем иметь дело с провайдерами, которые в качестве основы сети используют Juniper, потому что там можно реализовать Flowspec. Я надеюсь, что в ближайшие 12 месяцев Cisco также начнёт его поддерживать.
Вопрос: могли бы вы немного рассказать об опыте использования Flowspec в вашем сервисе CloudFlare?
Ответ: скажу, что это сильно забагованная штука. В конечном итоге мы оказываемся между молотом и наковальней, потому что нужно использовать в своих маршрутизаторах самую стабильную версию ПО, но даже самая стабильная версия выдает кучу ошибок при совместной работе с Flowspec. Так что мы создали целый промежуточный слой инфраструктуры, который выявляет возникающие баги и старается их обойти. Я не особо разбираюсь в этом, но если вы интересуетесь работой Flowspec, то я был бы счастлив связать вас с более знающими сетевиками из нашей команды, которые обладают опытом в этой области. Еще раз подчеркну, что очень важно, чтобы ваши правила сети можно было распространить на примыкающие сети upstream-провайдеров.
Вопрос: я использую CloudFlare, мне нравится этот сервис и я слежу за вашим блогом. Я боюсь, что вы затеяли что-то вроде гонки вооружений, соревнуясь с атакующим в пропускной способности. Может ли случиться, что вы скажет: «Всё, мы больше не можем этого делать»?
Ответ: думаю, что в этой гонке вооружений мы занимаем хорошую позицию, так как можем довольно быстро нарастить мощность своей сети. Я думаю, что суть этой гонки не в дизайне инфраструктуры, а в числе сетей, которые вы можете привлечь на свою сторону, чтобы быстро нарастить пропускную способность. Конечно, устройства для защиты от DDoS-атак тоже играют свою роль, но в случае подобной атаки у вас просто нет никакого оборудования с портом, способным пропустить 300 Гбит / с. Так что это подталкивает людей к созданию таких огромных сетей, как Akamai, которые могут смягчить действие подобных атак. Как конечный сетевой сервис, мы представляем мир в виде кучи вещей, для который покупаются «коробки», способные обеспечить производительность, безопасность и балансировку нагрузки. Мы думаем о себе как о строителе края платформы, в любой слот которой можно вставить приложение и таким образом обеспечить бесконечную масштабируемость, бесконечную надёжность и бесконечную доступность.
Вероятно, это можно расценивать как гонку вооружений, довольно болезненный процесс, который всё же больше нам помогает, чем вредит. И я знаю, вызов, брошенный хакерами крупным сетям, способствует консолидации провайдеров и дальнейшему укрупнению сетей. Я думаю, что глобальная сеть сконцентрируется вокруг ограниченного количества технически продвинутых провайдеров, таких как Akamai, Amazon, CloudFlare, и даже Google, который, отбрыкиваясь изо всех сил, всё же вынужден будет войти в этом бизнес. Вопрос состоит в том, кто же ещё способен обеспечить функционирование таких сетей, если не они?
Вопрос: я благодарен вам за то, что вы привлекли внимание к проблеме открытых резолверов и BCР38, однако создается впечатление, что вы умалчиваете о проблеме с набором расширений для протокола DNSSec…
Мэттью Принс: в этом заключается причина, по которой мы не используем DNSSec!
Продолжение вопроса: так вот, хотелось бы знать, собираетесь ли вы участвовать в исправлении DNSSec, прежде чем они получат широкое распространение, или же вы будете поддерживать альтернативные технологии?
Ответ: это достаточно сложный вопрос. На мой взгляд, DNSSec не решает проблем, для которых был создан. Можно ли его исправить? Это находится за пределами нашего бюджета. Я думаю, мы все хотели бы сделать так, чтобы просто повернуть выключатель – и DNSSec заработал как надо, при этом не делая мир хуже. Я боюсь, что если мы дадим толчок внедрению DNSSec, не позаботившись о том, чтобы минимизировать вред, который он может причинить DNS-серверам, это создаст очень большую проблему.
Вы можете осуществить подобное усиление и без DNSSec, вы можете вставить целую кучу текстовых записей, но, конечно, намного проще находить такие большие записи с помощью DNSSec. Иногда мы видим, что люди подписываются на услуги Cloudflare, создают эти гигантские записи зоны DNS, а затем используют нас как усилитель, и мы очень хорошо научились это обнаруживать. Так что креативный подход атакующих к использованию DNS-серверов никогда не перестанет меня удивлять.
Вопрос: нужно ли вам платить upstream-провайдеру за атакованный трафик? Это можно расценивать как продолжение предыдущего вопроса.
Ответ: да, если вследствие атаки наш трафик настолько увеличился, что превышает объемы, оговоренные в контракте с нашим upstream-провайдером. Однако мы используем кэширование прокси, поэтому подобные случаи происходят очень редко. С точки зрения пропускной способности преимуществом CloudFlare является то, что обычно мы сами эффективно справляемся с такими атаками, поэтому их последствия не вызывают необходимости платить провайдерам высшего уровня за превышение объемов исходящего от нас трафика.
Конечно, такая исключительная атака, о которой мы говорили, чего-то нам стоила. Но мы стараемся подходить к этому не так, как подходят традиционные провайдеры во время DNS DDoS: мы включаемся в это дело, решаем проблемы, вызванные атакой, а потом уже говорим о деньгах.
Вопрос: не может ли произойти так, что вы переложите свои расходы на оплату сверхнормативного трафика вследствие DDoS-атаки на своих клиентов, мотивируя это решение тем, что от вас требуют слишком много денег?
Ответ: вы недооцениваете, сколько денег у нас имеется в банке!
Благодарю всех, буду рад поговорить с вами, ребята, в другом месте, а сейчас пришло время уступить эту трибуну следующему оратору.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
(KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до весны бесплатно при оплате на срок от полугода, заказать можно тут.
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Автор: ua-hosting
