КабельщикМодели сильного и слабого узлов

Джозеф Дэвис (Joseph Davies)

Все большее распространение получают многосетевые узлы с несколькими сетевыми интерфейсами. Многосетевой узел обеспечивает дополнительные возможности подключения благодаря возможности одновременного подключения к нескольким сетям, таким как интрасеть или Интернет. Однако из-за возможности одновременного подключения к интрасети и

Интернету службы, выполняемые на многосетевых узлах, могут быть подвержены атакам. Чтобы помочь предотвратить атаки и получить представление о том, как обрабатывается трафик IP на многосетевом узле, я собираюсь рассмотреть модели слабого и сильного многосетевого узла, а также их поддержку в Windows®.

RFC 1122 — это спецификация, описывающая две модели многосетевых узлов, выступающих не в качестве маршрутизаторов, а только в качестве узлов, отправляющих и получающих одноадресный трафик IP. Эти модели, известные как сильный и слабый узлы, устанавливают, должен ли отправленный или полученный одноадресный трафик быть связан с сетевым интерфейсом, по которому он проходит. Эти модели определяют отправку и получение узлом пакетов, а также влияние на уязвимость выполняемых на узле служб.

Хотя спецификация RFC 1122 определяет эти модели для IPv4, они также применяются к IPv6. Примером многосетевого узла для IPv6 является компьютер, использующий протоколы IPv4 и IPv6, с сетевым адаптером, подключенным к интрасети и интерфейсу туннелирования IPv6.

Модель слабого узла

В модели слабого узла узел IP (IPv4 или IPv6) может отправлять пакеты через интерфейс, для которого не назначен IP-адрес отправителя отправляемого пакета. Это называется поведением отправки слабого узла. Узел IP также может получать пакеты на интерфейсе, для которого не назначен конечный IP-адрес получаемого пакета. Это называется поведением получения слабого узла.

При наличии многосетевого узла IP с несколькими интерфейсами разрешение поведения получения слабого узла на интерфейсах иногда может привести к тому, что узел станет уязвимым для многосетевых атак. Например, на рис. 1 показан узел A, подключенный к Интернету и интрасети. Узел A имеет общий IPv4-адрес 131.107.89.211, назначенный интерфейсу Интернета, и частный IPv4-адрес 192.168.17.48, назначенный интерфейсу интрасети.

Рис. 1** Пример многосетевого компьютера **

При включенном поведении отправки слабого узла на интерфейсах Интернета и интрасети узел A может отправлять пакеты с адреса 131.107.89.211 с интерфейса Интернета, пакеты с адреса 192.168.17.48 с интерфейса Интернета, пакеты с адреса 131.107.89.211 с интерфейса интрасети и пакеты с адреса 192.168.17.48 с интерфейса интрасети.

При включенном поведении получения слабого узла узел A может получать следующие типы пакетов (предполагается, что правила брандмауэра узла разрешают входящий трафик): пакеты на адрес 131.107.89.211 на интерфейс Интернета, пакеты на адрес 192.168.17.48 на интерфейс Интернета, пакеты на адрес 131.107.89.211 на интерфейс интрасети, пакеты на адрес 192.168.17.48 на интерфейс интрасети.

При включенном поведении получения слабого узла злоумышленник в Интернете может отправлять пакеты интерфейсу Интернета узла A для атаки служб, выполняемых на узле A и доступных только узлам в интрасети. Это тип атаки становится доступным, если инфраструктура Интернета поддерживает пересылку пакетов, предназначенных для 192.168.17.48, интерфейсу Интернета узла A. Этот тип атаки можно предотвратить, настроив соответствующие правила брандмауэра на интерфейсе Интернета узла A. Однако даже в этом случае службы, выполняемые на узле A, доступном для клиентов интрасети, могут находиться в опасности.

Модель сильного узла

В модели сильного узла поведения отправки и получения отличаются. При отправках сильного узла узел может отправлять пакеты через интерфейс, только если для него назначен IP-адрес отправителя отправляемого пакета. При получениях сильного узла узел также может получать пакеты на интерфейсе, только если для него назначен IP-адрес назначения получаемого пакета.

При включенном на интерфейсах Интернета и интрасети поведением отправки сильного узла узел A, показанный на рис. 1, может отправлять пакеты только с адреса 131.107.89.211 через интерфейс Интернета, а также пакеты с адреса 192.168.17.48 через интерфейс интрасети.

При включенном поведении получения сильного узла узел A может получать только пакеты на адрес 131.107.89.211 интерфейса Интернета и пакеты на адрес 192.168.17.48 интерфейса интрасети.

Показанная на рис. 1 модель сильного узла для узла A отбрасывает все входящие пакеты на интерфейсе Интернета, адресованные 192.168.17.48, эффективно изолируя интерфейс интрасети узла A от Интернета — брандмауэр при этом настраивать не приходится.

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

Получение и отправка сильного узла

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

Для отправляемых пакетов протокол IP сначала проверяет указание адреса отправителя. Если адрес отправителя не указан, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. При неограниченном поиске выполняется поиск по всем маршрутам таблицы маршрутизации. На основе выбранного для назначения маршрута протокол IP определяет интерфейс следующего прыжка (интерфейс для размещения пакета на канальном уровне) и адрес следующего прыжка. На основе интерфейса следующего прыжка протокол IP использует процесс выбора адреса, определенный в спецификации RFC 3484, что необходимо для определения наилучшего адреса отправителя. В этот момент у протокола IP есть все необходимое для отправки пакета: адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка.

Если указан адрес отправителя, известен интерфейс отправителя. Интерфейсу отправителя присваивается адрес отправителя. Затем протокол IP определяет, разрешены ли отправки сильного узла на интерфейсе отправителя.

Если отправки отключены, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. На основе наилучшего подходящего маршрута для назначения протокол IP определяет интерфейс и адрес следующего прыжка. Протокол IP имеет адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка. Обратите внимание, что если на интерфейсе отправителя отключено поведение отправки сильного узла, интерфейс следующего прыжка может не совпадать с интерфейсом отправителя.

Если на интерфейсе отправителя разрешены отправки сильного узла, протокол IP выполняет неограниченный поиск адреса назначения пакета в таблице маршрутизации. При неограниченном поиске выполняется поиск только в маршрутах с интерфейсом следующего прыжка интерфейса отправителя. На основе выбранного для назначения маршрута протокол IP определяет адрес следующего прыжка. Протокол IP имеет адрес отправителя и адрес назначения, интерфейс и адрес следующего прыжка. Обратите внимание, что если на интерфейсе отправителя разрешено поведение отправки сильного узла, интерфейс следующего прыжка всегда совпадает с интерфейсом отправителя. На рис. 2 показан общий процесс на узле отправки IP.

Рис. 2** Общий процесс на узле отправки IP **(Щелкните изображение, чтобы увеличить его)

Если указан адрес отправителя, неограниченный поиск маршрута может выбрать в таблице маршрутизации среди маршрутов с ближайшим соответствием назначению маршрут с более высокой метрикой. Например, узел A, показанный на рис. 1, имеет два маршрута по умолчанию; маршрут с метрикой 10 указывает на Интернет, а маршрут с метрикой 20 указывает на интрасеть.

Если отправляющее приложение на узле A не указывает адрес отправителя, результатом поиска маршрута будет являться маршрут по умолчанию с наименьшей метрикой; узел A всегда отправляет трафик с интерфейса Интернета с адресом отправителя 131.107.89.211. Однако если отправляющее приложение на узле A указывает адрес отправителя 131.107.89.211, результатом поиска будет являться маршрут по умолчанию для интерфейса Интернета; узел A отправляет трафик с интерфейса Интернета. Если отправляющее приложение на узле A указывает адрес отправителя 192.168.17.48, при поиске будет выбран маршрут по умолчанию для интерфейса Интернета; узел A отправляет трафик с интерфейса Интернета. После выполнения неограниченного поиска маршрута протокол IP отправляет трафик с адресом отправителя 192.168.17.48, используя маршрут по умолчанию с наибольшей метрикой.

Для принятого трафика протокол IP сначала определяет, предназначен ли трафик для узла. Если трафик не предназначен для узла, протокол IP сбрасывает пакет без уведомления, поскольку узел не выступает в качестве маршрутизатора. Затем протокол IP определяет разрешение служб сильного узла на входящем интерфейсе (интерфейс получения пакета). Если службы отключены, протокол IP обрабатывает пакет. Если службы включены, протокол IP определяет, назначен ли адрес назначения в пакете входящему интерфейсу. Если адрес назначен входящему интерфейсу, протокол IP обрабатывает пакет. В противном случае протокол IP сбрасывает пакет без уведомления. На рис. 3 показан общий процесс на узле получения.

Рис. 3** Процесс на узле получения **

Поведение слабого и сильного узлов в Windows

Windows XP и Windows Server® 2003 используют модель слабого узла для отправки и получения для всех интерфейсов IPv4 и модель сильного узла для отправки и получения для всех интерфейсов IPv6. Это поведение нельзя настроить. Набор протоколов TCP/IP нового поколения в Windows Vista и Windows Server 2008 поддерживает отправку и получение сильного узла для IPv4 и IPv6 по умолчанию для всех интерфейсов, кроме интерфейса туннелирования Teredo для связанной с узлом передачи Teredo. На рис. 4 перечислены команды, которые можно использовать для настройки поведения получения и отправки для IPv4 и IPv6 для отдельных интерфейсов. Обратите внимание, что InterfaceNameOrIndex является или именем интерфейса в папке «Сетевые подключения», или индексом интерфейса. Индекс интерфейса можно получить с помощью команды:

Figure 4 Команды для настройки поведения получения и отправки сильного и слабого узлов

netsh interface ipv6 show interface

Поведение слабого и сильного узлов и спецификация RFC 3484

Для предоставления стандартизированного способа выбора адресов отправителя и адресов назначения IPv6 и IPv4 для выполнения подключений спецификация RFC 3484 определяет два алгоритма. Первым является алгоритм выбора адреса отправителя, позволяющий выбрать наилучший адрес отправителя для использования с адресом назначения. Вторым является алгоритм выбора адреса назначения для упорядочения списка возможных адресов назначения в предпочитаемом порядке.

Поведение сильного и слабого узлов активируется после определения списка потенциальных адресов отправителя для определенного адреса назначения; это также влияет на окончательный упорядоченный список адресов назначения. Для поведения отправки сильного узла список потенциальных адресов отправителя состоит из адресов одноадресной рассылки, назначенных отправляющему интерфейсу для назначения. Для поведения отправки слабого узла список кандидатов может включать адреса, назначенные любому интерфейсу со включенной отправкой слабого узла. Дополнительные сведения о выборе адреса отправителя и адреса назначения приведены в статье на веб-узле microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

По умолчанию отправка и получение слабого узла отключены для IPv4 и IPv6 для всех интерфейсов, кроме интерфейса туннелирования Teredo для связанной с узлом передачи Teredo.

Дополнительные сведения о спецификации RFC 3484 приведены на врезке «Поведение слабого и сильного узлов и спецификация RFC 3484».

Отключение ролей по умолчанию для подключений VPN удаленного доступа

Клиент виртуальной частной сети (VPN) удаленного доступа является другим примером многосетевого узла. Даже если узел имеет один интерфейс локальной сети, подключенный к Интернету, когда клиент VPN удаленного доступа выполняет подключение к VPN, он является многосетевым. Он имеет два интерфейса: интерфейс локальной сети и интерфейс на основе протокола PPP для подключения VPN. Он также имеет два IPv4-адреса: назначенный поставщиком услуг Интернета IPv4-адрес для интерфейса локальной сети и назначенный сервером VPN IPv4-адрес для интерфейса на основе протокола PPP.

Для обеспечения отправки VPN-клиентом трафика маршрута по умолчанию интрасети через VPN-подключение Windows XP и Windows Server 2003 изменяют таблицу маршрутизации IPv4, повышая метрику существующего маршрута по умолчанию и добавляя новый маршрут по умолчанию с более низкой метрикой, использующий интерфейс PPP. Это поведение по умолчанию на время подключения к VPN делает расположения в интрасети доступными и почти все расположения в Интернете недоступными. Можно настроить VPN-клиент для разделения туннелирования, чтобы можно было одновременно иметь доступ к расположениям интрасети и Интернета, не добавляя маршрут по умолчанию для подключения VPN и добавляя определенные маршруты для назначений интрасети. Однако существует опасность маршрутизации VPN-клиентами с разделенным туннелированием пакетов между Интернетом и интрасетью. Дополнительные сведения приведены на веб-узле microsoft.com/technet/community/columns/cableguy/cg1003.mspx.

Поведение клиента VPN по умолчанию в Windows XP и Windows Server 2003 было разработано для поведения отправки слабого клиента. При поиске маршрута всегда используется маршрут по умолчанию для подключения VPN, поскольку он имеет наименьшую метрику. Однако при использовании поведения отправки сильного узла маршрут по умолчанию для отправки трафика зависит от IP-адреса отправителя, указанного в пакете. При поиске маршрута для трафика с IPv4-адреса, назначенного поставщиком услуг Интернета, будет использоваться маршрут по умолчанию, использующий интерфейс локальной сети, делающий все расположения Интернета доступными. При поиске маршрута для трафика с IPv4-адреса, назначенного сервером VPN, будет использоваться маршрут по умолчанию, использующий интерфейс протокола PPP, делающий все расположения интрасети доступными, поэтому при использовании поведения отправки сильного узла клиент VPN имеет настройку разделенного туннелирования и одновременный доступ к Интернету и интрасети, даже для приложений без прав администратора на непосредственное изменение таблицы маршрутизации IPv4.

Для предотвращения создания поведением отправки сильного узла настройки разделенного туннелирования по умолчанию клиент VPN в Windows Vista® и Windows Server 2008 автоматически отключает маршруты по умолчанию интерфейсов локальной сети после завершения подключения VPN. Это поведение обеспечивает наличие только одного активного маршрута по умолчанию в таблице маршрутизации, использующей интерфейс протокола PPP. Это поведение также предотвращает выполнение разделенного туннелирования приложениями без прав администратора.

Поскольку источником трафика от компьютера VPN-клиента должен являться IPv4-адрес, назначенный сервером VPN, такое поведение обеспечивает лучшую изоляцию интрасети от Интернета. После завершения подключения VPN происходит включение отключенных маршрутов по умолчанию.

Этим поведением можно управлять с помощью параметра:

netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Джозеф Дэвис (Joseph Davies) работает составителем технической документации в корпорации Майкрософт. С 1992 года занимается преподаванием и пишет о сетях Windows. Он автор пяти книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику «Кабельщик» в журнале TechNet.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.