Особенности безопасности IPv6, которые нельзя игнорировать

Соблазнительно считать IPv6 прямой заменой IPv4, у которой просто больше адресное пространство. Но с точки зрения безопасности есть несколько реальных отличий, которые стоит понимать, а не предполагать, что всё из IPv4 переносится без изменений.

Список блокировки нужно строить отдельно, а не просто делать длиннее

В IPv6 есть собственные приватные, loopback- и link-local-диапазоны, устроенные иначе, чем их аналоги в IPv4. Проверка безопасности, которая умеет разбирать и фильтровать только диапазоны IPv4, молча пропустит всё это со стороны IPv6. Дело не в том, что IPv6 менее безопасен, а в том, что равноценные защитные меры для него просто никогда не создавались.

IPv4-mapped-адреса: простое слепое пятно

В IPv6 есть способ встроить адрес IPv4 внутрь адреса IPv6, например ::ffff:127.0.0.1: он указывает на тот же loopback-адрес, что и обычный 127.0.0.1, только записанный в форме IPv6. Проверка, которая корректно отсеивает IPv4 loopback, но не «распаковывает» такую встроенную форму, пропустит адрес, функционально идентичный тому, который иначе был бы заблокирован сразу.

• Любой системе, которая сверяет разрешённые адреса со списком блокировки, нужна по-настоящему отдельная и полная логика для IPv6, а не предположение, что правила IPv4 автоматически распространяются и на него.
• IPv4-mapped-адреса IPv6 нужно «распаковывать» и проверять именно по правилам IPv4, а не оценивать как непрозрачные адреса IPv6.
• Dual-stack-системам (большинству современных) нужно последовательно применять обе проверки, потому что злоумышленник просто воспользуется тем семейством адресов, на котором стоит более слабая проверка.

Ничто из этого не причина избегать IPv6: более широкое внедрение в целом полезно, а специфичная для IPv6 поверхность атаки не обязательно больше, чем у IPv4. Это причина убедиться, что вся логика безопасности, работающая с адресами, действительно была построена и протестирована для обоих семейств адресов, а не для одного, к которому второе прикручено задним числом.

NAT64 добавляет второй уровень трансляции, о котором стоит знать

Некоторые сети только с IPv6 используют NAT64 и DNS64, чтобы их клиенты всё же могли обращаться к интернету только с IPv4: DNS64 на лету синтезирует запись AAAA для домена, у которого есть только запись A, встраивая адрес IPv4 в специальный префикс (общеизвестный вариант по умолчанию — 64:ff9b::/96), а NAT64 на границе сети транслирует трафик на этот синтетический адрес обратно в настоящий IPv4. Это законный и полезный механизм, но он означает, что адрес из этого диапазона — не «сырой» адрес IPv6, который нужно оценивать сам по себе, а IPv4 в костюме IPv6, и его нужно «распаковывать» и проверять по правилам IPv4 так же, как IPv4-mapped-адрес.

Тестирование логики безопасности на деле означает тестирование обоих семейств

Автоматические тесты легко незаметно смещаются в сторону IPv4: большинство примеров доменов, большинство тестовых данных и большинство быстрых ручных проверок по умолчанию используют именно его, и никто не принимает такого решения сознательно. Набор тестов для всего, что разрешает и фильтрует адреса, заслуживает доверия лишь настолько, насколько полно он покрывает IPv6: случаи для приватных, loopback- и link-local-диапазонов выше, для IPv4-mapped-адреса и для адреса, синтезированного в стиле NAT64, требуют собственных явных проверок, а не формулы «наверное, работает так же». Код безопасности, обрабатывающий адреса, — это как раз та логика, где непротестированный и сломанный путь неразличимы, пока злоумышленник не найдёт разницу первым.