Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 8:

Идентификаторы интерфейса с особыми свойствами и протоколы на их основе

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >

Безопасность

Протокол ND получился более гибким и универсальным, чем его предшественник ARP, но устойчивость ND к умышленным атакам осталась низкой. Мы не станем разбирать все возможные векторы атаки, а ограничимся самым очевидным из них: узел злоумышленника подключается к каналу и отвечает на вызовы NS касательно чужих адресов. В своих ответах NA узел злоумышленника сообщает, что искомому адресу IPv6 отвечает его собственный канальный адрес. В результате прочие узлы канала сами направляют трафик узлу злоумышленника. К примеру, так узел злоумышленника может прикинуться маршрутизатором по умолчанию и перехватить весь трафик от узлов канала в Internet. Чтобы настоящий владелец адреса не мешал атаке своими ответами NA, можно подвергнуть его параллельной атаке типа "отказ в обслуживании" или выбрать момент, когда он отключен для профилактики.

Этот и прочие векторы атаки на ND разобраны в RFC 3756.

Убедитесь с помощью конечного автомата NUD (рис. 5.9), что злоумышленнику достаточно выслать сообщение NA с установленными флагами S и O, чтобы "исправить" в свою пользу уже существующую запись NC, хотя на пустом месте создать запись NC он таким образом не может.

Предложите способ принудительно создать запись NC в памяти атакуемого хоста. (Подойдут такие сообщения: NS, RS или RA с опцией SLLA; переадресовка с опцией TLLA.)

В отличие от ARP, который стоял в иерархии стека рядом с IP, ND — это подмножество ICMPv6, а значит, в теории его можно защитить на уровне IPv6. Такую защиту обеспечивает протокол IPsec, рассмотренный нами в §3.3.5. Но, увы, на практике это слишком тяжеловесное, хотя и надежное решение. На нижнем уровне работой IPsec управляют связи безопасности — грубо говоря, элементарные правила о том, как именно защищать пакеты из данного источника к данному адресату. Если к каналу подключены N узлов, а у каждого из них M адресов, то для полноценной работы ND надо будет настроить до 2 \cdot (N\cdot M+1) связей на каждом узле [§6 draft-arkko-manual-icmpv6-sas]. Это трудоемкая и неблагодарная по ложности работа. На более высоком уровне связями безопасности управляет удобный протокол IKE, но он требует полноценно работающего сетевого уровня, что неминуемо приводит нас к "проблеме курицы и яйца". В частности, IKE не позволит защитить самый уязвимый элемент ND — разрешение адресов [draft-arkko-icmpv6-ike-effects].

Можно ли защитить ND, обойдясь при этом ручными настройками трудоемкости O(N) ? Давайте рассуждать. Для начала проверим, что нам даст симметричная криптография. Допустим, каждый законный узел хранит общий ключ и пользуется им для подписи сообщений ND (на выходе) и для проверки их подлинности (на входе). Эта схема будет работать до тех пор, пока злоумышленник не похитит ключ. После этого безопасность канала рассыплется, словно карточный домик: злоумышленник сможет прикидываться любым узлом. Восстановление безопасности потребует смены ключа на каждом узле канала. Плохая схема, двигаемся дальше.

Следующий кандидат — асимметричная криптография: каждый законный узел получает свою личную пару ключей, закрытый и открытый. На выходе узел подписывает сообщения ND своим закрытым ключом, на входе он проверяет подпись открытым ключом соседа. Кража закрытого ключа ставит под удар только его владельца, но не весь канал, и это хорошо. Но как узел узнает открытые ключи своих соседей? Если их распространять предварительно, сложность настройки всего канала подскочит до O(N^2). А что будет, если источник сообщения ND сам приложит свой открытый ключ к сообщению? Положим, адресат сообщения ND не располагает никакой априорной информацией о законном соседе. Тогда злоумышленник сгенерирует собственную пару ключей и сможет подписывать сообщения ND как ни в чем не бывало. Такой вариант не годится.

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

Однако мы ошибаемся, говоря, что априорной информации нет. Ведь при розыске соседа узел заранее знает соседский адрес IPv6! На самом деле, это допущение, и допущение очень важное: адрес IPv6 соседа — доверенный. Ведь сейчас мы работаем над защитой протокола ND, и нам нужны определенные "очаги доверия", гарантированные нам другими протоколами и уровнями стека, — иначе нам не на что будет опереться.

Что означает доверенность адреса IPv6? Это значит, что мы узнали его из доверенного источника. Скажем, мы хотим провести ping одного из интерфейсов узла-соседа Б. Как нам достоверно узнать его адрес IPv6? Во-первых, мы можем сами пойти к консоли этого узла, локально войти в систему и прочесть адрес в настройках.

Конечно, возможны атаки и на локальный вход в систему, но сейчас мы их не рассматриваем: это один из наших "очагов доверия".

Во-вторых, если у нас есть основания доверять DNS5Например, благодаря применению DNSSEC. и мы знаем доменное имя узла Б, то программа ping6 сама узнает адрес по имени:

$ ping6 b.example.org

PING6(56=40+8+8 bytes) 2001:db8::2 --> 2001:db8::1

...

В-третьих, адрес Б мы можем узнать от доверенного лица, из рук в руки или в подписанном электронном письме… Читатель может самостоятельно продолжить этот список.

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003