Записная книжка сисадмина Вопросы безопасности при развертывании IPv6

    В этой статье речь пойдет о моментах, которые необходимо учитывать при обеспечении безопасности IPv6. Прежде чем углубиться в статью, следует знать, что IPv6 может иметь проблемы безопасности, отличные от IPv4, и совершенно необязательно, что технология IPv6 более безопасна. Кроме того, статья фокусируется на аспектах, присущих не только IPv6, поскольку многие «best practices», применяемые для сетей IPv4, применимы и для сетей IPv6. Первоисточник статьи здесь blogs.cisco.com/security/securing-ipv6/.
    Проблемы двойного стека.
    Прежде всего, для поддержки перехода от IPv4 к IPv6 многие системы поддерживают оба протокола, и такая конфигурация называется конфигурацией с двойным стеком. Важно понимать, что в такой конфигурации IPv6 и IPv4 используют различные стеки, что означает, что если у вас имеется список управления доступом (ACL) для IPv4 трафика, он неприменим для IPv6 трафика.
    Это может быть проблемой на таких устройствах, как персональные компьютеры, на которых IPv6 разрешен по умолчанию (поскольку пользователи и не думают о применении IPv6 списков доступа, т.к. они не используют IPv6). Поскольку IPv6 поддерживает автоматическое обнаружение соседей и создание адресов, интерфейсы могут автоматически генерировать как локальные, так и глобальные адреса, без участия пользователя. Кроме того, даже если локальная сеть не поддерживает трафик IPv6, атакующий может направить IPv6 трафик на ваш компьютер, используя иные механизмы. Например, можно отправить IPv6 трафик на систему поверх IPv4 SSH соединения, поддерживающего порт форвардинг. Таким образом, жизненно важной является настройка правил для трафика IPv6 на файрволле.
    Настройка списков доступа.
    Использование списков доступа для IPv6 в IOS изменилось незначительно. Традиционные списки доступа применяются к IPv4. Для ограничения IPv6 трафика необходимо настроить списки доступа с использованием ключевого слова ipv6. В их настройке, однако, есть некоторые тонкости. Например, в списке доступа для IPv4 в конце всегда присутствует неявный «deny ip any any». В IPv6 вместе с неявным запретом присутствуют два неявных разрешения, как показано ниже:
    •permit icmp any any nd-na
    •permit icmp any any nd-ns
    •deny ipv6 any any
    Разрешения добавлены для того, чтобы обеспечить работоспособность Neighbor Discovery, выполняющего такую же роль, как и ARP в IPv4. Это может привести к проблемам, если вы используете опцию log в ACL, например таким образом: «deny ipv6 any any log», потому что теперь запрещающее правило перекроет неявные разрешения, и обнаружение соседей перестанет работать. Так что эту опцию следует использовать с особой осторожностью.
    Фильтрация транспортных протоколов
    В IPv4 использовались расширенные списки доступа для фильтрации большого количества TCP и UDP трафика, основанной на портах источника и назначения. Такую же фильтрацию можно осуществлять и для IPv6 трафика, хотя для фильтрующего устройства обнаружить транспортный протокол в IPv6 трафике сложнее. В IPv4 несложно идентифицировать транспортный протокол. В IPv6 для идентификации нужно просмотреть всю цепочку расширенных заголовков, т.к. информация о транспортном протоколе находится в самом конце этой цепочки. В случае фрагментации, информации о транспортном протоколе может и не быть в первом фрагменте. Это способствует появлению новых фильтрующих ключевых слов, таких как undetermined-transport, которое указывает, что либо не идентифицирован транспортный протокол для пакета, либо либо пакет содержит неопределенный расширенный заголовок. Это также меняет способ, с помощью которого интерпретируется ключевое слово «fragment», в зависимости от места расположения заголовка транспортного протокола.
    Фильтрация расширенных заголовков.
    В IPv4 обычно основной задачей является ограничение IP-трафика, такого как TCP или UDP. В IPv6 по-прежнему важно уметь ограничивать трафик на основе типа IP протокола, но также вы должны уметь фильтровать расширенные заголовки. Например, одним из расширенных заголовков, который вы обязательно должны запретить, является Routing Header (RH) Type 0, который является тем же самым, что и source routing для IPv4. К счастью, расширенный заголовок RH Type 0, согласно RFC 5095, устарел, так что по умолчанию он должен быть запрещен на многих устройствах (начиная с версии IOS 12.4(15)T). Вы можете также захотеть запретить трафик RH Type 2.
    Фильтрация туннелей.
    Кроме двойных стеков, для взаимодействия IPv4 и IPv6 сетей на время перехода были разработаны различные технологии туннелирования. Эти туннели могут обеспечить пути прохождения трафика, которые не контролируются либо не фильтруются текущей политикой безопасности IPv4. Без надлежащей фильтрации пользователи могут сконфигурировать эти туннели для связывания сетей IPv4 и IPv6. Некоторые туннели даже могут сконфигурироваться автоматически без участия пользователей. Таким образом трафик, запрещенный вашей IPv4 политикой безопасности, может пройти через эти огранчения. Например, туннель teredo позволяет пользователям инкапсулировать IPv6 пакеты в IPv4 UDP пакеты. Через такой туннель пользователь либо атакующий может установить соединения, блокируемые политикой IPv4.
    Проблемы ICMP
    При работе с IPv4 ICMP сообщения от других сетей обычно не влияют на работу вашей сети. Во многих случаях вы можете заблокировать весь ICMP трафик на периметре (что обычно и делается). Поскольку в IPv6 роль ICMP возросла, просто заблокировать все пакеты нельзя. Например, если не разрешить прохождение пакетов ICMP Type 2 (Packet Too Big), нарушится механизм фрагментации. Также вы должны решить, стоит ли разрешить на периметре neighbor discovery, так как он также использует ICMP. По факту RFC 4890 объясняет все моменты при применении правил ограничения ICMP.
    Ликвидация NAT
    В IPv4 на большинстве домашних брандмауэров применена конфигурация по умолчанию, которая применяет динамический NAT, позволяя нескольким внутренним системам выходить во внешний мир с одного адреса. По умолчанию такая конфигурация обычно разрешает только исходящие соединения из внутренней сети и запрещает любые соединения, инициируемые из сети Интернет к вашим внутренним системам. Такая конфигурация обеспечивает безопасность внутренних систем. В IPv6 количество адресов практически не ограничено и в NAT нет необходимости. Недостатком является то, что настройки по умолчанию для домашних IPv6 брандмауэров, вероятно, будут гораздо более открыты. С точки зрения безопасности, это будет выглядеть как если бы вы подключили кабель напрямую в компьютер. Таким образом, вы должны быть уверены, что применили ACL в вашей IPv6 сети.
    Это был всего лишь краткий обзор вещей, которые нужно учесть при обеспечении безопасности IPv6 сети. Он призван подтолкнуть вас к поиску «best practices», например таких www.cisco.com/web/SG/learning/ipv6_seminar/files/02Eric_Vyncke_Security_Best_Practices.pdf. Вы должны осознавать все риски перед развертыванием сети IPv6, т.к. многие механизмы настраиваются автоматически.

    0 комментариев

    Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.