Введение в безопасность IP… v6

Наталья Мельникова

До недавнего времени мои знания об IPv6 ограничивались безумным адресным пространством и неким смутным ощущением «безопасности», требования которой были учтены при проектировании этого протокола. Однако во время оценки защищенности беспроводной сети использующей IPv6 у меня возникла масса вопросов связанных с его безопасность, ответы на некоторые из которых я попытаюсь изложить в данной статье.

Учитывая распространенность решений, поддерживающих IPv6 в стандартной конфигурации, намеренье Microsoft включить IPv6 в Windows Vista «по умолчанию», вполне вероятно, что администраторам придется столкнуться с этим протоколом задолго до начала его развертывания в сети. В связи с этим хотелось бы обозначить основные проблемы безопасности IPv6 до того, как они станут предметом расследования инцидентов.

Благодаря своему большому адресному пространству, механизмам автоматической настройки, IPv6 расширяет возможности использования сетевых устройств. Однако это же приводит к тому, что он становится менее понятным и прозрачным для человека. Внешний вид записанного в HEX 128-битного [1] IP-адреса на первых порах повергает в шок. В связи с этим, на мой взгляд, широкое внедрение IPv6 приведет к ещё большему возрастанию роли DNS. Если на данный момент в корпоративной сети администратор может воспользоваться «резервным» методом, и продиктовать пользователю IP-адрес вместо имени важного сервера, то довольно трудно представить себе пользователя, вбивающего в строке адреса браузера что-то типа 3ffe:da0c:8b93::da01:1193.

Кроме того, в случае использования DNS для распространения открытых ключей/сертификатов, применяемых для аутентификации в IPSec, возможность установления связи между двумя узлами (даже если IPv6-адреса известны) будет завесить от доступности службы DNS.

Часто IPv6 выпадает из зрения сетевых администраторов. При настройке межсетевых экранов, сканировании устройств на наличие «лишних» открытых портов, обнаружении атак администраторы обычно используют IPv4, но не IPv6. Это позволяет злоумышленнику использовать IPv6 для установки скрытых троянских программ, обхода межсетевых экранов и так далее.

Например, тривиальная задача инвентаризационного сканирования сети в случае с IPv6 будет весьма затруднена, поскольку стандартное количество адресов в одной подсети равняется 2^64. Я думаю, любой согласится, что использование простого перебора здесь не подойдет. Похоже, что сканерам уязвимостей, которые будут поддерживать протокол IPv6, придется реализовывать поиск узлов не на сетевом уровне, как сейчас, а используя широковещательные (точнее multicast, широковещательного трафика в IPv6 нет) запросы для каждого сегмента. Но это потребует либо настройки маршрутизаторов для передачи запросов на широковещательные адреса (что плохо), либо установки агентов в каждом сегменте.

Конечно, можно возразить, что, во-первых – устройство должно поддерживать IPv6, во-вторых, его должна поддерживать сетевая инфраструктура. Дело в том, что многие операционные системы уже сейчас поставляются с IPv6 включенным в стандартной конфигурации. В качестве примеров можно привести Linux RedHat (включая Fedora Core) и даже Windows Mobile 2003. Было весьма удивительно обнаружить, когда КПК на основе Windows Mobile 2003 SE начал непринужденно рассылать ICMPv6 Neighbor Solicitation без какой-либо настройки с моей стороны. Кроме того, существует ряд технологий туннелирования [2], позволяющих передавать трафик IPv6 поверх IPv4 или IPv4 UDP. А как известно, туннели – враг межсетевых экранов.

Дизайн IPv6 предполагает, что у любого интерфейса всегда есть как минимум один адрес IPv6, так называемый Local Link Address, начинающийся с префикса FE80. Этот адрес генерируется на основе идентификатора EUI-64, т.е. по сути – MAC адреса интерфейса, в котором между двумя 24-битными частями вставляется константа FFFE (см. Рисунок 1).

Что самое интересное, в Windows Server 2003 и в Linux Fedora Core 4.0 идентификатор интерфейса генерируется на основе MAC адреса не только при назначении локальных адресов (т.е. действующих в пределах сегмента), но и при конфигурации глобальных адресов через сообщения Routing Advertisement (один из механизмов автоматической конфигурации адресов в IPv6). И если в первом случае это совершенно нормально, то наличие в глобальном адресе идентификатора сетевой карточки наверняка порадует поклонников «1984» и вызовет некоторые вопросы у сторонников «privacy». Представьте, покупаете вы ноутбук с рук, а потом оказывается, что его предыдущий владелец взломал несколько десятков серверов в зоне .gov, или что хуже – загружал нелицензионные mp3 (см. Рисунок 2).

Кроме того, наличие локального адреса, не требующего настройки, дает злоумышленнику ряд дополнительных возможностей. Не так давно в прессе бурно обсуждалась возможность атаковать клиентов беспроводных сетей на базе Windows, автоматически назначающих адрес из диапазона APIPA и через NetBIOS рассказывающих о полученном адресе всем желающим [3].

С IPv6 такие ухищрения не нужны. Дело в том, что клиентский компьютер:

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

Но Windows как обычно идет впереди Linux. Если Linux в настойках «по умолчанию» при включении ограничивается 5ю multicast запросами, то Windows ведет себя как потерявший маму мамонтенок, рассылая Neighbor Solicitation десятками.

Я думаю каждый человек, знакомый с безопасностью IP помнит о неприятных моментах, связанных с протоколом ARP. Широко известна возможность удаленного манипулирования значениями в ARP-таблице другого узла путем отправки ложных сообщений ARP-Response или ARP-Request (ARP-Spoofing, ARP-Poisoning).

В IPv6 протокол ARP отсутствует. Ему на смену пришли сообщения ICMPv6 Neighbor Solicitation и Neighbor Advertisement (запрос и ответ соответственно, см. Рисунки 4,5).

Как и в IPv4 данные сообщения не аутентифицированы [4], что порождает схожие проблемы. Т.е. злоумышленник, посылая ложное сообщение Neighbor Advertisement, может изменить таблицу «соседей» (netsh int ipv6 show neighbors в Windows) на узле и выполнять атаку «человек по середине» в локальном сегменте.

В процессе тестирования оказалось, что реализовать данную атаку с IPv6 несколько сложнее, чем с IPv4. Дело в том, что большинство операционных систем не воспринимали Neighbor Advertisement без отправки Solicitation. Однако практически все удаляли существующую запись из таблицы соседних узлов, и при необходимости отправки пакета снова посылали Solicitation. Таким образом, злоумышленник может просто «бомбить» атакуемые узлы ложными сообщениями Neighbor Advertisement, чтобы его сообщение было принято раньше ответа легитимного узла.

Еще одна проблема, связанная с механизмом поиска соседних узлов заключается в том, что согласно RFC 2462 узел не должен использовать адрес, если он уже используется в сети. Таким образом, находящийся в локальном сегменте злоумышленник вполне может реализовать DoS атаку, отвечая на все Neighbor Solicitation, что данный адрес уже занят.

Протокол IPv6 довольно широко использует ICMPv6. Одна из задач, решаемых этим протоколом, это обмен маршрутной информацией в рамках Neighbor Discovery Protocol.

Данный протокол может также использоваться для автоматического назначения адресов в сети (см. Рисунок 6). Поскольку аутентификация сообщений NDP обычно не используется, злоумышленник имеет возможность подделывать сообщения для выполнения ряда атак [5], таких как:

Приведенный список возможных атак, использующих NDR далеко не полон. Выше описаны те из них, что "лежат на поверхности" и что удивительно - работают.

А как же IPSec?

Действительно, ESP и AH являются частью стандарта IPv6. Однако их использование связанно с рядом трудностей. Первая и основная – необходимость наличия ключевого материала.

В ряде ситуаций использование IKE невозможно (ICMPv6), поскольку работа IKE требует наличия сетевого взаимодействия. И действительно, как клиент будет договариваться об используемых ключах, не выяснив предварительно MAC-адрес второй машины? Использовать статические SA? Одинаковые ключи шифрования и контроля целостности на всех узлах?

Применение IKE-PSK возможно в ограниченном ряде случаев (например, для проверки аутентичности маршрутизаторов). В ситуации, когда все пользователи сети используют один и тот же PSK, злоумышленник путем компрометации рабочей станции может легко получить ключ. Затем, реализовав атаку MITM нарушать целостность и конфиденциальность трафика, либо посылать пакеты от другого узла.

Конечно, применение сертификатов открытых ключей могло бы решить проблему, но развертывание PKI подобных масштабов (минимум – по сертификату на компьютер) вызывает определенные затруднения (по крайней мере, в масштабах всего Internet).

Кроме того, не забывайте, что в случае прохождения трафика ESP через межсетевой экран тот не имеет возможности анализировать содержимое пакета, поскольку пакет просто-напросто зашифрован. Для нормальной обработки AH, межсетевой экран должен уметь разбирать пакеты данного протокола, что приводит к усложнению обработчиков, что в свою очередь повышает требования к аппаратной части и увеличивает вероятность возникновения ошибок в коде [6].

Если IPv6 не используется – отключайте его в настойках ОС. Фильтруйте на межсетевых экранах и граничных маршрутизаторах трафик IPv6 и различные туннели (6to4, 6over4, ISATAP, Teredo). Настройте системы обнаружения атак на распознавание IPv6 в локальной сети [7].

Проверьте, что реализованные в ОС механизмы самонастройки изменяют Interface Identifiers. В обратном случае, используйте механизмы присвоения IPv6 адресов.

Anticap и Antidote ни кто не отменял, так же как и статические записи MAC-IP (…).Не используйте на маршрутизаторах Neighbor Discovery без дополнительной защиты. Или вообще не используйте (sysctl -w net.ipv6.conf.default.accept_ra=0)

И не забывайте – возможность использовать «чистый» IPv6 появится далеко не завтра. Долгое время нам придется жить в сети IPv4+IPv6.

[1] Introduction to IPv6, Microsoft, http://www.microsoft.com/technet/itsolutions/network/ipv6/introipv6.mspx

[2] ABCs of IP Version 6, Cisco http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_ip_version_60900aecd800c112b.html

[3] Attacking Automatic Wireless Network Selection, Dino A. Dai Zovi, Shane A. Macaulay http://www.theta44.org/karma/aawns.pdf

[4] IPv6 Neighbor Discovery trust models and threats, Nikander et. al., RFC 3756 http://www.ietf.org/rfc/rfc3756.txt

[5] Security of the Neighbor Discovery protocol in IPv6, E. Rosti, J.L. Rrushi

[6] Multiple (13) Ethereal remote overflows, Stefan Esser http://www.securityfocus.com/archive/1/358373

[7] Snort6, Charles Tomlin http://www.ecs.soton.ac.uk/~cet/snort6/