Pull to refresh

Атака на IPv6: NDP Table Exhaustion

Reading time 5 min
Views 17K
IPv6 уверенно шагает рано или поздно войдёт в нашу жизнь в той же степени, что и IPv4. Интересная особенность — долгий период разработки и внедрения привёл к тому, что некоторые первоначальные идеи были списаны в утиль, а сама конструкция постепенно обросла костылями. И, что обидно, к решению некоторых серьёзных проблем приступили только недавно.

Под катом — как положить IPv6 и даже IPv4 сеть DoS-атакой NDP Table Exhaustion, а также варианты полумер и мер защиты.

image



Справка по теме


Протокол NDP (Neighbor Discovery Protocol) играет ключевую роль в работе IPv6. По сути это замена ARP с рядом новых возможностей и рядом новых проблем.

Сферический обмен пакетами в вакууме согласно RFC выглядит так: узел А без нужной записи в таблице соседств ищет по IPv6-адресу физический адрес узла Б. Для этого он создаёт запись в таблице с пометкой «INCOMPLETE», отсылает Neighbor Solicitation (NS) на специальный адрес (solicited-node multicast) и ждёт. Узел Б получает сообщение и отвечает на него сообщением Neighbor Advertisement (NA). Узел А записывает адрес в таблицу, начинается обмен информацией, все счастливы.

Также полезно будет вспомнить про две важные особенности адресации в IPv6. Первая — глобальных уникальных адресов на интерфейсе может быть много, даже с одинаковым префиксом. При этом они в некотором смысле равноценны, а логика использования этих адресов зачастую зависит от реализации. К примеру, вместо EUI-64 идентификатор интерфейса может генерироваться случайным образом во имя приватности.

Вторая особенность — рекомендуемый (изначально) размер сети равен /64. Даже на соединениях «точка-точка». Лично меня это всегда коробило — как можно распределять на такую сеть столько глобально уникальных (=публичных) адресов?! Но, по версии авторов IPv6, «голодные годы» и дефицит IPv4 в прошлом, поэтому так эффективнее. По этой причине некоторые разработчики оборудования и ПО ориентируются на правило «подсеть — только /64»

Суть проблемы


Сколько адресов в подсети IPv4? Зависит от размера, но скорее всего мало. Любимый размер — /24 — предполагает не более 254, крупные сети встречаются редко из-за плохой масштабируемости.

Сколько адресов в подсети IPv6? 2 в степени 64. Даже если в ней один узел, он может использовать случайные адреса из всего диапазона. Чтобы найти устройство (или установить факт его отсутствия), используется механизм обнаружения соседей.

Сколько записей NDP может помнить устройство? Для «средних» L3-коммутаторов цифра будет где-то в районе нескольких тысяч, для более мощных устройств — десятки или сотни тысяч записей. В любом случае, это капля в море по сравнению с количеством возможных адресов.

Каждый запрос создаёт запись в этой таблице. В результате даже простой ping sweep может её легко переполнить. Учитывая глобальность адресов, это можно сделать не только изнутри, но и снаружи отправкой абсолютно любого пакета на адреса из этой сети.

Последствия


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

Сценарий 0. Наблюдается на некоторых устройствах. Корректная реализация ND ограничивает количество записей INCOMPLETE и при необходимости чистит очередь. Атака не проходит.

Сценарий 1 — Плохой. На устройстве есть только ограничение по количеству пакетов в секунду для Neighbor Discovery (Control Plane policer).
  • В этом случае атака возможна, но будет более медленной.
  • Во время атаки разрешение IPv6 в MAC будет затруднено для всех узлов.
  • Вполне возможно, что рано или поздно переполнение таблицы всё же наступит. В этом случае события пойдут по сценарию 2.
  • Жёсткое ограничение помешает нормальной работе сети (например, в случае перезапуска большого числа машин)


Сценарий 2 — Ещё хуже. Ограничений нет, на подверженном интерфейсе таблица переполнилась
  • Туда уже не смогут попадать новые записи. То есть, часть устройств будет «невидима».
  • Некоторые реализации удаляют старые записи из таблицы, даже если записи активно используются. Теперь отпали и работающие устройства


Сценарий 3 — Приехали. Происходит, если ресурсы общие.
  • На некоторых платформах перестают нормально работать все IPv6-интерфейсы
  • Отдельные реализации имеют общую память для ND в IPv6 и ARP в IPv4. Сломанный IPv6 тянет за собой и IPv4 тоже.


Что делать


По сути основа этой проблемы — не баг, а фича. Просто сегодня у устройств нет столько ресурсов, чтобы вместить достаточное для /64 сети количество записей. Помимо этого устройство не может отличить легитимные запросы от «просто спросил». Но главный усугубляющий фактор — алгоритм работы с сообщениями ND.

Разработчикам «железа» и ПО теоретически надо пересмотреть реализацию этого алгоритма. К примеру, запросы на неизвестные адреса должны иметь минимальный приоритет, и при достижении определённого процента заполнения таблицы записи INCOMPLETE должны забываться в первую очередь. Некоторые устройства уже так работают, однако далеко не на всех платформах это сделано надлежащим образом.

Что делать сейчас:

  • Ограничить политикой количество пакетов в секунду до control plane. Не решает проблему, поскольку при малом объёме таблицы и большом сроке хранения записей даже очень небольшой поток рано или поздно её заполнит. Однако замедляет процесс и в ряде ситуаций может помочь. Плохо работает, если возможны пики ND-трафика
  • Использовать подсети меньшего размера, например /127 для соединений «точка-точка». К сожалению, попытка уйти от «слишком больших» /64 сетей далеко не всегда работает. При этом теряется SLAAC, и ряд других технологий, о чём говорит RFC 5375 (секция 3). Хотя /127 разрешается RFC 6164, инженеры при разработке также закладывают сети /64, поэтому на ряде платформ трафик для нестандартных сетей может обрабатываться только полностью программно. В общем, много побочных эффектов.
  • Использовать везде статические записи ND. В отдельных случаях может выручить, но даже на среднем масштабе больше похоже на мазохизм.
  • Использовать маршрут в никуда для сети /64 и отдельные маршруты /128 до узлов. В этом случае для масштабируемости узлам потребуется участвовать в маршрутизации.
  • Ограничить на граничном устройстве с помощью ACL/фаерволла диапазон адресов, на которые можно инициировать соединения. Этот метод защищает от атак из внешней сети.
  • Включить Neighbor Discovery Inspection с Destination Inspection. Эта технология входит в набор технологий IPv6 First Hop Security от Cisco. Аналоги есть или, вероятно, появятся и у других вендоров. По своей сути подобна IP DHCP Snooping + ARP Inspection для IPv4: устройство слушает все сообщения ND и поддерживает таблицу соответствий (Binding Table). Опция Destination Inspection запрещает узнавать адреса, которые не содержатся в таблице, а значит, отсутствуют в сети. Руководство по настройке First Hop Security можно найти здесь.


Заключение


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

Неплохо список для проверки типичных уязвимостей есть вот здесь. Помните, что по умолчанию на многих современных ОС IPv6 уже включен и работает.
Tags:
Hubs:
+20
Comments 23
Comments Comments 23

Articles