RFC: 3715
Оригинал: IPsec-Network Address Translation (NAT) Compatibility Requirements
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

RFC 3715, Страница 15 из 16

5. Вопросы безопасности

По определению, IPsec/NAT-совместимость требует, чтобы IP-узлы и маршрутизаторы, использующие IPsec-протоколы, были способны надежно обрабатывать IP-пакеты, у которых IP-заголовки не защищены с помощью криптографических методов защиты информации.

Так как IPsec/АН-пакеты не могут транспортироваться через NA(P)T-модуль, то тогда одним из побочных эффектов внедрения решения, обеспечивающего IPsec/NAT-совместимость, может быть использование ESP-протокола в режиме «холостого» шифрования (отсутствие шифрования — «null encryption») вместо АН-протокола в тех сетевых сегментах, где между отправителем и получателем IP-пакетов имеет место NA(P)T-модуль. Однако, необходимо указать, что ESP-протокол в режиме «холостого» шифрования не обеспечивает такую же защищенность как АН-протокол. Например, наличие рисков безопасности, связанных с маршрутизацией IPv6-пакетов источника, которые устраняются при использовании АН-протокола и не устраняются при использовании ESP-протокола в режиме «холостого» шифрования.

Кроме этого, так как ESP-протокол, в любом режиме шифрования, не защищает IP-адрес источника от атак типа «маскарад», некоторые типы IP-адресов должны проходить соответствующую проверку. Важность этой проверки не всегда понятна. Обычно, эта проверка относится к IP-адресу источника сообщения, как часть проверки «IPsec_{esp,ah}_input(_)». Она гарантирует, что IP-адрес отправителя совпадает с IP-адресом, который указывался в период проведения первой и второй фаз IKE-протокола, то есть установления SA-соединения. Когда принимающий IP-узел обслуживается NA(P)T-модулем, то тогда такая проверка может быть полностью бессмысленна для одноадресных сеансов связи, поскольку в глобальной Internet-сети такая проверка имеет смысл только для одноадресных сеансов связи в РТУ, так как она позволяет предотвращать атаки типа «маскарад». В последнем случае эта проверка может осуществляться тогда, когда доступ к приемнику контролируется на основе верификации ESP-пакетов после их разобрамления и проверки IP-адрес отправителя. Решения, обеспечивающие IPsec/NAT-совместимость, должны включать средство защиты от атак типа «маскарад», если эти решения используют систему управления доступом на основе проверки IP-адреса отправителя.

Положим, что имеют место два IP-узла «А» и «С», которые обслуживаются разными NA(P)T-модулям, и желают согласовать IPsec/SA-соединения в РТУ с марщрутизатором «В». IP-узлы «А» и «С» могут иметь различные привилегии, например, IP-узел «А» может принадлежать штатному сотруднику компании, который авторизован для доступа ко всем информационным подсистемам корпоративной Intranet-сети, а IP-узел «С» может принадлежать временному сотруднику компании, который авторизован для доступа только к конкретному WWW-серверу.

Если IP-узел «С» передает IP-пакет в РТУ, указывая ложный IP-адрес источника (IP-адрес IP-узла «А», атака «маскарад»), то тогда очнь важно, чтобы этот IP-пакет «не пользовался привилегиями», которые принадлежат IP-узлу «А». Если проводится процедура аутентификации и защиты целостности, но при этом не проводится проверка с целью защиты от атак типа «маскарад» (проверка того, что IP-адрес источника сообщения соответствует IP-адресу, уазанному в SPI-индексе), то тогда IP-узел «С» может проникнуть в те сегменты и подсистемы корпоративной сети, в которые доступ для него запрещен. Следовательно, Решения, обеспечивающие IPsec/NAT-совместимость, должны обеспечивать определенной аровнь защищенности от атак типа «маскарад».

Страница 15 из 16

2007 - 2022 © Русские переводы RFC, IETF, ISOC.