Здравствуйте, меня зовут Евгений Усков, я представляю Qrator Labs. Сегодня мы с вами затронем тему ещё одной уязвимости, потенциально приводящей к отказу в обслуживании. Вам эта проблема может показаться очевидной, однако, мы нашли более миллиона уязвимых устройств.
Для начала, давайте представим себе типичный роутер. Он выполняет различные задачи, например: построение таблицы маршрутизации, он коммуницирует с другими устройствами с помощью разнообразных протоколов, и, наконец, он занимается непосредственным форвардингом сетевых пакетов. Существует известная абстракция, согласно которой все эти задачи могут быть разделены на два уровня с разными свойствами: передающий уровень и управляющий уровень.
На управляющем уровне принимаются решения о том, куда направить трафик. Он использует для этого различные протоколы, такие как протокол остовного дерева (STP), OSPF или BGP. Пакеты достигают передающего уровня, если роутер является назначением или источником пакета. Тем не менее, здесь важно отметить, что управляющий уровень обрабатывает всё центральным процессором и, более того, так как эти операции, в общем случае, производятся для сравнительно малой части пакетов — нет жесткого временного ограничения на их обработку.
Передающий уровень также известен как уровень форвардинга и, как следует из его названия, он обеспечивает в первую очередь форвардинг.
Важная разница между данными уровнями заключается в том, что пакеты передающего уровня обрабатываются аппаратно, в то время как на управляющем уровне пакеты обрабатываются силами центрального процессора. Оставлять управляющий уровень открытым всему интернету, традиционно, плохая идея — он может быть использован злоумышленником для атаки по CPU.
Типичный сценарий получения доступа к управляющему уровню строится на утилизации открытого TCP-порта. Какой TCP порт типично открыт на сетевом устройстве? Это, конечно, порт какой-то сетевой службы или протокола. Так что мы решили взять порт BGP (179) и проверить, насколько опасна данная проблема.
Сначала мы провели простой эксперимент для того, чтобы проверить, является ли такой открытый порт настоящей уязвимостью и может ли быть использован для атаки на отказ в обслуживании. Жертвой выступил обыкновенный роутер Cisco, на который мы совершили SYN flood атаку, намеренно достаточно простую.
Мы запустили 32 процесса hping syn-flood, что позволило нам генерировать среднюю по трафику нагрузку около 720 000 пакетов в секунду на примерно 0,5 Гбит/с.
Даже этого объёма оказалось достаточно для того, чтобы вызвать серьёзные последствия. Перед вами график загрузки центрального процессора на устройстве. По оси Х у нас время, на оси Y загрузка CPU. Мы видим, что первые 45 минут, пока атаки не происходило, процессор практически бездействовал, но в последние 15 минут — под атакой, был загружен почти на 100%. Но, глядя на этот график, вы всё равно можете спросить — ну и что? Что такого в загрузке центрального процессора?
На деле, сам уровень загруженности процессора был не единственным последствием атаки и далеко не самым опасным.
Во-первых, мы наблюдали несколько рестартов BGP-сессии. Скриншот лога на экране. Помимо этого, мы увидели несколько сбоев в работе протокола динамической маршрутизации OSPF, что вылилось в нестабильные трейсы до устройства. Помимо всего этого, до перегруженного устройства просто сложно достучаться.
Этот эксперимент показывает, что уязвимость открытого сетевого порта может быть использована для атак на отказ в обслуживании. Я хочу подчеркнуть тот факт, что это значит отказ в обслуживании не одного отдельно взятого хоста — так как речь идёт о сетевом устройстве, его нестабильная работа может приводить к большему сопутствующему урону, как например недоступность всей сети.
Решение этой проблемы простое, как всегда. Просто не оставляйте открытыми порты управляющего уровня всему интернету. Используйте список контроля доступа (ACL) либо, по меньшей мере, приватные адреса. Вроде бы — ничего сложного.
Тем не менее, мы обнаружили, что в большинстве ситуаций управляющий уровень роутера выглядит примерно так. Предлагает обнимашки любому желающему.
Давайте взглянем на некоторую статистику по уязвимым хостам. Эти данные мы собирали следующей методологией: просканировав доступное IPv4 пространство на предмет открытых портов BGP, мы отфильтровали те порты, которые отвечали по всем открытым портам, проверим затем, похоже ли их поведение на BGP — например, мгновенный сброс сессии.
Итак, вот цифры. Существует более миллиона уязвимых хостов. Около десятой части всех префиксов и примерно треть всех автономных систем находятся в зоне риска. Более того — порядка 5000 из этих автономных систем являются поставщиками IP-транзита, поэтому проблемы у них будут наследоваться клиентами. Мы также провели проверку поведения данных портов и обнаружили, что большинство из них закрывает соединение. Но существуют и особенные случаи — например, порядка 60 000 хостов прислало уведомление. А около 70 000 хостов перед завершением соединения присылает open message, что уже точно является предложением обнимашки любому встречному.
radar.qrator.net
Вывод прост — несмотря на то, что проблема открытых всему свету портов известна как минимум несколько лет — она до сих пор остаётся актуальной и может привести к плохим последствиям. Я ещё раз повторю, что речь идёт о возможной недоступности сетевого устройства.
У нас есть инструмент проверки автономных систем на предмет таких уязвимостей. Инструмент бесплатный, доступен любому желающему. Вам нужно только зарегистрировать собственную автономную систему и подтвердить право владения, чтобы исключить использование данной информации злоумышленником. Если у вас есть фидбэк, любое мнение или предложение, пожалуйста, напишите его.
Большое спасибо, если возникнут вопросы — с радостью на них отвечу.
P.S. Коллеги, внимание! Вот уже вторую неделю по нашей инициативе о внедрении механизма автоматической защиты от возникновения «утечек маршрутов» (route leaks) в протоколе BGP идёт adoption call.
Это значит, что начиная с 21 мая 2017 года, в течение двух недель в списке рассылки IETF (подписаться на неё можно здесь) обсуждаются все «за» и «против» принятия предлагаемых авторами черновика предложений в рабочую группу. В зависимости от результатов голосования, работа над этим документом будет продолжена до получения статуса стандарта (RFC) или заморожена.
Мы просим всех, кому небезразлично состояние BGP-проблематики, выразить собственные аргументы на английском языке, в треде писем под заголовком «draft-ymbk-idr-bgp-open-policy-03». Помните, что, выражая мнение, вы должны выражать именно свое мнение как инженера, а не мнение вашего работодателя. Крайне желательно, чтобы ваше мнение было аргументировано — для этого мы рекомендуем ещё раз ознакомиться с нашими предложениями (ссылка на черновик: раз, два).
Напоминаем, что любой может выразить своё мнение в списке рассылки IETF — ценз отсутствует.
Мы заранее признательны каждому техническому специалисту, системному администратору, разработчику и просто заинтересованному человеку, готовому вслух поддержать нашу инициативу по модернизации одного из ключевых протоколов, обеспечивающих эффективную работу современных сетей.
Спасибо.
