RFC 7288 | Размышления о брандмауэрах хоста

Аннотация

В современном Интернете потребность в брандмауэрах общепризнанна в отрасли, и на самом деле брандмауэры широко применяются на практике. В отличие от традиционных брандмауэров, которые защищают сетевые ссылки, хост-брандмауэры работают в системах конечных пользователей. Часто результатом является то, что программное обеспечение может работать и потенциально потреблять ресурсы, но затем связь блокируется межсетевым экраном хоста. Само собой разумеется, что это конечное состояние является либо желательным, либо наилучшим, которое может быть достигнуто на практике, а не (например) конечным состоянием, когда соответствующее программное обеспечение не работает или работает таким образом, что не приведет к нежелательному обмену данными. В этом документе мы исследуем проблемы, лежащие в основе этих предположений, и даем предложения по улучшению архитектуры в будущем.

Скачать оригинальный документ на английском языке RFC 7288 PDF

 

Оглавление

1. Введение
1.1. Терминология
2. Правила брандмауэра
3. Категория 1. Сокращение поверхности атаки
3.1. Обсуждение подходов
3.1.1. Исправить программное обеспечение
3.1.2. Не используйте программное обеспечение
3.1.3. Запустите программное обеспечение за хост-брандмауэром
4. Категория 2: Политика безопасности
4.1. Обсуждение подходов
4.1.1. Политики безопасности в приложениях
4.1.2. Политики безопасности в хост-брандмауэрах
4.1.3. Политики безопасности в сервисе
5. Режим невидимости
6. Вопросы безопасности
7. Благодарности
8. Члены IAB на момент утверждения
9. Информационные ссылки
Адрес автора

 

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Совета по архитектуре Интернета (IAB) и представляет информацию, которую IAB посчитал ценным для постоянной записи. Он представляет собой консенсус Совета по архитектуре Интернета (IAB). Документы, одобренные для публикации IAB, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7288.

 

Уведомление об авторских правах

Copyright (c) 2014 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

 

1. Введение

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

«Поведение и требования к брандмауэрам Интернета» [RFC2979] содержит введение в брандмауэры и, в частности, требование прозрачности, в котором говорится:

• Введение брандмауэра и любых связанных с ним средств туннелирования или согласования доступа НЕ ДОЛЖНО вызывать непреднамеренные сбои законного и совместимого со стандартами использования, которые могли бы работать, если бы брандмауэр отсутствовал.

Многие брандмауэры сегодня не следуют этому руководству, например, блокируя трафик, содержащий параметры IP или заголовки расширений IPv6 (см. [RFC7045] для получения дополнительной информации).

В разделе 2.1 «Размышления о прозрачности Интернета» [RFC4924] IAB представил дополнительные соображения о брандмауэрах и их влиянии на архитектуру Интернета, включая проблемы, связанные с обязательствами по раскрытию информации и сложностью, по мере того, как приложения развиваются, чтобы обойти брандмауэры. Этот документ расширяет это обсуждение дополнительными соображениями.

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

Хотя глоссарий Internet Security [RFC4949] содержит расширенное определение брандмауэра, неофициально большинство людей склонны считать брандмауэр просто «чем-то, что блокирует нежелательный трафик» (см. [RFC4948] для обсуждения многих типов нежелательного трафика). Фундаментальный вопрос, однако: «нежелателен кем?»

Возможные ответы включают конечных пользователей, разработчиков приложений, сетевых администраторов, администраторов хостов, поставщиков брандмауэров и поставщиков контента. Мы исключим по определению отправителя рассматриваемого трафика, так как отправитель обычно хочет, чтобы такой трафик доставлялся. Тем не менее, другие объекты имеют разные и часто противоречивые желания, что означает, что тип трафика может быть желательным для одного объекта и нежелательным для другого объекта. Таким образом, неудивительно, что существуют различные типы межсетевых экранов и различные типы «гонки вооружений», о которых мы поговорим в разделе 4.1.2.

 

1.1. терминология

В этом документе мы различаем «брандмауэр хоста», который просто предназначен для защиты одного компьютера, на котором он работает, и «сетевой брандмауэр», который расположен в сети и предназначен для защиты сети и любых хостов за ней.

Транслятор сетевых адресов (NAT) также часто рассматривается или даже продается как тип сетевого брандмауэра; Раздел 2.2 [RFC4864] рассматривает это заблуждение, но, тем не менее, некоторые из тех же наблюдений в настоящем документе могут также применяться к NAT.

Среды с песочницей, такие как предоставляемые браузерами, также можно рассматривать как тип брандмауэра хоста в более общем смысле. Например, межсайтовая проверка в браузере может рассматриваться как механизм блокирования нежелательного исходящего трафика в соответствии с «той же политикой происхождения», когда сценарий может взаимодействовать только с «сайтом», с которого был получен сценарий, для некоторых определение сайта, такое как схема и полномочия в URI.

Термин «приложение» используется в этом документе в общем для применения к любому компоненту, который может принимать трафик. В этом смысле он может относиться к процессу, выполняющемуся на компьютере (включая системную службу), или даже к части самого стека TCP / IP, например компоненту, который отвечает на эхо-запросы.

 

2. Правила брандмауэра

Желания для желаемого или нежелательного трафика могут быть выражены в терминах «разрешить» или «заблокировать» правила с некоторым способом разрешения конфликтующих правил. Многие брандмауэры фактически реализованы с точки зрения таких правил. На рисунке 1 показаны некоторые типичные источники таких правил.

На рисунке 1 предполагается, что сетевые брандмауэры (network firewalls) администрируются сетевыми администраторами (network administrators) (если они есть), а хостовые брандмауэры (host firewalls) администрируются хост-администраторами (host administrators) (если таковые имеются). Брандмауэр также может иметь правила, предоставленные самим поставщиком брандмауэра.

Конечные пользователи (End users) обычно не могут напрямую предоставлять правила брандмауэрам, которые влияют на других пользователей, если только конечный пользователь не является администратором хоста или сети. Однако разработчики приложений могут предоставлять такие правила для некоторых межсетевых экранов, например, предоставлять правила во время установки. Они могут сделать это, например, путем вызова API, предоставляемого хост-брандмауэром, включенным в операционную систему, или предоставляя метаданные операционной системе для использования брандмауэрами, или используя протокол, такой как Universal Plug and Play (UPnP). [UPNPWANIP] или протокол управления портами (PCP) [RFC6887] для связи с сетевым межсетевым экраном (более подробное обсуждение см. В разделе 4.1.3).

Правила брандмауэра обычно делятся на две категории:

1. Сокращение поверхности атаки: правила, предназначенные для предотвращения того, чтобы приложение делало то, чего не хочет делать разработчик.
2. Политика безопасности: правила, предназначенные для предотвращения того, чтобы приложение делало то, что разработчик мог бы хотеть, но администратор этого не делает.

Брандмауэр не нужен, если обе категории пусты. Теперь мы рассмотрим каждую категорию по очереди, уделяя особое внимание хост-брандмауэрам (хотя некоторые моменты могут быть в равной степени применимы к сетевым брандмауэрам).

 

3. Категория 1. Сокращение поверхности атаки

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

Кто-то может спросить, является ли эта категория правил, как правило, пустой, и ответ таков: в настоящее время это не так. Одна из причин связана с уменьшением угрозы использования уязвимости путем помещения барьера безопасности в отдельный процесс, изолированный от потенциально скомпрометированного процесса. Кроме того, существует также желание использовать «скрытый режим» (см. Раздел 5 ниже).

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

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

1. Простые политики, которые разработчик хотел бы, но которые трудно реализовать. Одним примером может быть политика, согласно которой приложение должно взаимодействовать только внутри локальной сети (например, дома или на предприятии), но не быть доступным из глобальной сети Интернет или когда устройство перемещено в какую-либо общедоступную сеть, такую ​​как точка доступа. Вторым примером может быть обратный, то есть политика для связи через Интернет, но не с локальными объектами. Потребность в этой категории будет уменьшена за счет лучшей поддержки платформ для таких политик, что облегчит их внедрение и использование разработчиками.
2. Сложные политики, когда разработчик не может знать о специфике. Одним из примеров может быть политика общения только во время или только в нерабочее время, когда точные часы могут отличаться в зависимости от местоположения и времени года. Другим примером может быть политика, позволяющая избежать связи по ссылкам, которые стоят слишком дорого, где определение «слишком много» может варьироваться в зависимости от клиента, и, действительно, конечный хост и приложение могут даже не знать о затратах. Потребность в этой категории будет уменьшена за счет лучшей поддержки платформ для таких политик, что позволит приложению обмениваться данными через какой-то простой API с другой библиотекой или службой, которые могут работать со спецификой.

3.1. Обсуждение подходов

Когда запуск приложения может привести к нежелательному поведению, у клиентов есть три варианта, которые мы обсудим по очереди:

• а. исправить (или заставить разработчика исправить) программное обеспечение,
• б. не использовать программное обеспечение, или
• в. дайте программному обеспечению работать, но затем используйте брандмауэр, чтобы помешать ему и предотвратить его нежелательную работу.

3.1.1. Исправить программное обеспечение

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

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

 

3.1.2. Не используйте программное обеспечение

Ключевой вопрос, который нужно задать, заключается в том, может ли приложение по-прежнему делать что-то полезное, если оно запущено. Если ответ «да», то неиспользование программного обеспечения, вероятно, нереально. Например, игра с однопользовательскими и многопользовательскими возможностями все еще может быть полезна в однопользовательском режиме, когда она находится под огнем. Если вместо этого ответ «нет», лучше сначала не запускать приложение, а некоторые межсетевые экраны хоста действительно могут блокировать запуск приложений.

 

3.1.3. Запустите программное обеспечение за хост-брандмауэром

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

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

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

В качестве другого примера, блокировка ICMP отрицательно влияет на обнаружение MTU пути, что может вызвать проблемы для других объектов (см. [RFC4890] и Раздел 3.1.1 [RFC2979] для дальнейшего обсуждения). Это может произойти из-за непонимания всех деталей поведения приложения или из-за случайной неправильной настройки. Раздел 2.1 [RFC5505] гласит: «Все, что можно настроить, может быть неправильно настроено», и обсуждает это более подробно.

Короче говоря, важно, чтобы приложения лучше осознавали ограничения своей среды и, следовательно, могли лучше вести себя при наличии ограничений.

 

4. Категория 2: Политика безопасности

Как отмечалось в Разделе 2, эта категория правил брандмауэра, как правило, пытается запретить приложению выполнять действия, которые администратор не хочет делать, даже если разработчик приложения это делал.

Кто-то может спросить, является ли эта категория правил, как правило, пустой, и ответ несколько варьируется. Для межсетевых экранов корпоративного сценария он почти никогда не бывает пустым, и, следовательно, проблемы, обсуждаемые в разделе 3.1.3, также могут быть распространены и здесь. Аналогично, для межсетевых экранов потребительского сценария, как правило, они не пусты, но есть некоторые заметные исключения. Например, для брандмауэра хоста в некоторых операционных системах эта категория всегда начинается пустой, и большинство пользователей никогда не изменяют это.

4.1. Обсуждение подходов

Политику безопасности можно реализовать в любом из трех мест, которые мы обсудим по очереди: приложение, брандмауэр или библиотека / служба, которые приложение явно использует.

4.1.1. Политики безопасности в приложениях

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

4.1.2. Политики безопасности в хост-брандмауэрах

Размещение политик безопасности в брандмауэрах без явного взаимодействия с приложениями приводит к проблемам, обсуждаемым в разделе 3.1.3. Кроме того, это приводит к «гонкам вооружений», когда приложения стремятся развиваться, чтобы обойти политики безопасности, поскольку желания конечного пользователя или разработчика могут конфликтовать с желаниями администратора. Как указано в разделе 2.1 [RFC4924]:

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

Хотя такие гонки вооружений часто рассматриваются в контексте сетевых брандмауэров, они также происходят с хост-брандмауэрами. Однако, как правило, брандмауэр хоста легче преодолеть, поскольку для брандмауэра хоста может оказаться более практичным установить некоторую форму доверия между объектами, желающими получить политику, и иметь доверенного арбитра.

4.1.3. Политики безопасности в сервисе

При таком подходе приложения используют библиотеку или другую внешнюю службу, благодаря которой приложения четко знают о влиянии политик безопасности, чтобы избежать проблем, описанных в разделе 3.1.3, и в изолированной среде это может быть единственным способом приложения взаимодействовать с сетью.

Таким образом, в этом подходе согласия приложения предоставляют описание запрошенного доступа к сети, а библиотека / служба может гарантировать, что приложения и / или пользователи информируются таким образом, чтобы они могли их понять, и что администраторы могут создавать политику, которая влияет на приложения.

Этот подход очень трудно реализовать в библиотеке / сервисе, зависящем от поставщика брандмауэра, когда может быть несколько реализаций брандмауэра (в том числе в середине сети), поскольку разработчик приложения обычно не имеет смысла знать и разрабатывать для много разных API брандмауэра. Однако этот подход можно использовать с библиотекой / службой, независимой от поставщика межсетевого экрана, которая может взаимодействовать как с приложениями, так и с межсетевыми экранами. Таким образом, разработчики приложений и разработчики брандмауэров могут использовать общую платформу.

Мы видим, что этот подход сильно отличается от классического подхода брандмауэра. Однако этот подход используется некоторыми брандмауэрами операционной системы, а также подходом, используемым PCP в IETF. Поэтому мы поощряем развертывание и использование этой модели.

Кроме того, хотя такой подход уменьшает стимулы для гонок вооружений, как обсуждалось выше, остается одна важная проблема. А именно, сегодня не существует стандартного механизма для библиотеки / службы по изучению сложных политик из сети. Дальнейшая работа в этой области необходима.

 

5. Режим невидимости

Часто возникает желание скрыться от сканирования адресов и портов в общедоступной сети. Однако соответствие многим RFC требует ответа на различные сообщения. Например, соответствие TCP [RFC0793] требует отправки RST в ответ на SYN, когда нет прослушивателя, а соответствие ICMPv6 [RFC4443] требует отправки эхо-ответа в ответ на эхо-запрос.

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

 

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

Существует распространенное заблуждение о том, что брандмауэры защищают пользователей от вредоносных программ на их компьютере, тогда как на самом деле брандмауэры защищают пользователей от программного обеспечения с ошибками. Существует некоторое беспокойство, что межсетевые экраны дают пользователям ложное чувство безопасности; межсетевые экраны не являются неуязвимыми и не будут препятствовать запуску вредоносных программ, если пользователь это разрешит.

Этот документ был сосредоточен в основном на межсетевых экранах хоста. Для дополнительного обсуждения (больше внимания уделено сетевым брандмауэрам) см. [RFC2979] и [BLOCK-FILTER].

 

7. Благодарности

Стюарт Чешир обеспечил мотивацию для этого документа, задавая наводящий на размышления вопрос о том, почему нужно запускать брандмауэр для приложения, а не просто прекращать его выполнение. Последующее обсуждение и последующий технический чат IAB в ноябре 2011 года привели к этому документу. Дэн Саймон, Стивен Бенсли, Херардо Диас Куэльяр, Брайан Карпентер и Пол Хоффман также предоставили полезные предложения.

8. Члены IAB на момент утверждения

Бернард Абоба (Bernard Aboba)
Яри Аркко (Jari Arkko)
Марк Бланше (Marc Blanchet)
Росс Каллон (Ross Callon)
Алисса Купер (Alissa Cooper)
Джоэл Халперн (Joel Halpern)
Расс Хаусли (Russ Housley)
Элиот Лир (Eliot Lear)
Син Ли (Xing Li)
Эрик Нордмарк (Erik Nordmark)
Эндрю Салливан (Andrew Sullivan)
Дэйв Талер (Dave Thaler)
Ханнес Чофениг (Hannes Tschofenig)

9. Информационные ссылки

[BLOCK-FILTER] Barnes, R., Cooper, A., and O. Kolkman, «Technical Considerations for Internet Service Blocking and Filtering», Work in Progress, January 2014.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC2979] Freed, N., «Behavior of and Requirements for Internet Firewalls», RFC 2979, October 2000.

[RFC4443] Conta, A., Deering, S., and M. Gupta, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006.

[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, «Local Network Protection for IPv6», RFC 4864, May 2007.

[RFC4890] Davies, E. and J. Mohacsi, «Recommendations for Filtering ICMPv6 Messages in Firewalls», RFC 4890, May 2007.

[RFC4924] Aboba, B. and E. Davies, «Reflections on Internet Transparency», RFC 4924, July 2007.

[RFC4948] Andersson, L., Davies, E., and L. Zhang, «Report from the IAB workshop on Unwanted Traffic March 9-10, 2006», RFC 4948, August 2007.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», RFC 4949, August 2007.

[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, «Principles of Internet Host Configuration», RFC 5505, May 2009.

[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, «Port Control Protocol (PCP)», RFC 6887, April 2013.

[RFC7045] Carpenter, B. and S. Jiang, «Transmission and Processing of IPv6 Extension Headers», RFC 7045, December 2013.

[UPNPWANIP] UPnP Forum, «WANIPConnection:2 Service», September 2010, <http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf>.

Адрес автора

Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com