Thursday, October 18th, 2018

Понимание Обработки Права Доступа ISA 2004

Published on Февраль 6, 2009 by   ·   Комментариев нет

В противоположность простой сетевой модели «верю — не верю» ISA Server 2000, ISA Server 2004 использует намного более сложную и гибкую сетевую модель. Как результат этого способа, вы определяете вашу сеть и политику брандмауэра в ISA Server 2004 полностью различно, и, поэтому, логика позади обработки прав доступа выполняется ISA Server 2004. Из-за того, что результат не всегда соответствует вашим ожиданиям, мы покажем в этой статье, как ISA Server 2004 обрабатывает списки различных правил и как отдельное правило выбирается для подтверждения отдельного исходящего запроса.

1. Резюме

В противоположность простой сетевой модели «верю — не верю» ISA Server 2000, ISA Server 2004 использует намного более сложную и гибкую сетевую модель. Как результат этого способа, вы определяете вашу сеть и политику брандмауэра в ISA Server 2004 полностью различно, и, поэтому, логика позади обработки прав доступа выполняется ISA Server 2004. Из-за того, что результат не всегда соответствует вашим ожиданиям, мы покажем в этой статье, как ISA Server 2004 обрабатывает списки различных правил и как отдельное правило выбирается для подтверждения отдельного исходящего запроса.

Если вы новичок в ISA Server 2004, я советую вам вначале посетить web-сайт Microsoft ISA Server 2004. Другие очень хорошие ресурсы — это, конечно, web-сайт ISAserver.org и прекрасная книга Тома Configuring ISA Server 2004 (Конфигурирование ISA Server 2004). Также, я подразумеваю здесь, что вы уже имеете хорошее понимание сетевой модели ISA Server 2004, то, как вы определяете сети, сетевые правила и политику брандмауэра.

2. Введение

Для того, чтобы описать с точки зрения функциональности, какие связи допустимы между описанными сетями, ISA Server 2004 использует набор из трех списков правил:

  • Сетевые правила: Этот список определяет и описывает сетевую топологию. Эти правила определяют, есть ли отношение между двумя сетевыми объектами и какого типа это отношение (Маршрут или NAT). Когда нет настроенного отношения между сетями, ISA Server выкидывает весь трафик между этими двумя сетями. Должно быть понятно, что корректное описание сетевых объектов и их отношений предельно важно для полной работы ISA 2004.
  • Правила Системной Политики: Этот список содержит 30 встроенных правил доступа, которые применяются на сети Local Host (Локального Хоста). Поэтому они управляют обменом от/к ISA Server и нужны для разрешения необходимых вспомогательных функций, таких как авторизация, сетевая диагностика, вход пользователей и удаленное управление. Помните, что эти правила являются разрешительными и что вы можете только включить или выключить их и применить только небольшие изменения некоторых их свойств.
  • Правила Политики Брандмауэра: Этот список содержит правила, определенными вами, как администратором брандмауэра. Это список одного порядка из правил трех возможных типов: правило доступа, правило web-публикации и правило серверной публикации. Этот список включает, так же, специальное предопределенное правило по умолчанию Last (Последнее), которое отклоняет весь доступ к и из всех сетей. Это правило по умолчанию Last не может быть изменено или удалено. Поэтому, любой трафик, разрешенный или блокированный ISA Server 2004, делается явно заданным по правилу.

Примечание: Комбинация правил системной политики и правил политики брандмауэра определяет и описывает введенную политику брандмауэра.

Как ISA Server 2004 применяет описанные выше три списка правил к любому исходящему запросу, показано на рисунке ниже:

В каком порядке располагать правила isa

Примечание: соединители 1, 2 и 3 будут использованы в другой потоковой диаграмме, приведенной в разделе 6. Обобщение.

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

Далее ISA Server проверяет по порядку вначале правила системной политики, а затем — правила политики брандмауэра. Если правило системной политики или политики брандмауэра разрешает запрос, то ISA Server идет далее, обрабатывая исходящий запрос. Иначе, трафик отклоняется.

Наконец, ISA Server проверяет снова сетевые правила для определения того, должен ли быть трафик маршрутным или NAT. Также, ISA Server проверяет правила web цепочки (если клиент Web Proxy запросил этот объект) или цепочечную конфигурацию брандмауэра (если клиент SecureNET или Брандмауэра запросил этот объект) для определения способа обслуживания запроса.

Должно быть ясно, что логика позади обработки сетевых правил откровенная и прямая. Или есть отношение, или его нет. Однако, то, как ISA server определяет, когда правило системной или брандмауэрной политики должно разрешить или запретить трафик, не так хорошо определено в этом месте. Причина этой неопределенности в том, что нет простого ответа на этот вопрос. Мы только уверенно знаем одну вещь — что правила системной политики применяются перед правилами политики брандмауэра, и что ISA Server оценивает правила системной и брандмауэрной политик одинаковым способом.

3. Политика брандмауэра

Основная работа ISA Server это контроль трафика между сетями источника и приемника. Это является ключевой концепцией и результат этого — что хосты отправителя и получателя должны быть в разных сетях. Другими словами, вы никогда не должны возвращаться назад через ISA Server для доступа к ресурсу в этой же сети. Другая ключевая концепция — что ISA Server оценивает политику брандмауэра строго по порядку. Когда правило доступа совпадает с параметрами запроса, это правило применяется и ISA Server не проверяет запрос по другим правилам.

Также помните, что правила системной политики обрабатываются до правил политики брандмауэра, и что ISA Server оценивает правила системной и брандмауэрной политик абсолютно одинаковым способом. Другими словами, политика брандмауэра должна бы быть представлена, как одиночный упорядоченный список правил, в котором правила 1-30 содержат правила системной политики, а правило 31 и далее содержат правила политики брандмауэра, и всегда последним правилом является правило по умолчанию Last. Поэтому, если правило системной политики и правило политики брандмауэра оба применяются к определенному запросу, то правило системной политики всегда будет выигрывать у правила политики брандмауэра.

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

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

ISA клиент Запрос послан Возможность авторизации
Web Proxy По IP-адресу или FQDN в зависимости от ввода пользователя Да (HTTP/HTTPS и тоннельный FTP)
Firewall Всегда по IP-адресу (*) Да (все протоколы на основе TCP/UDP)
SecureNET Всегда по IP-адресу (*) Нет

(*) Это относится ко всем не-HTTP(S) запросам. Однако, для HTTP(S) запросов ISA будет всегда проверять поле Host в заголовке HTTP вместо запрашиваемой оконечной точки назначения (адрес уровня 3). Как и для клиента Web Proxy, значение Host заголовка зависит от пользовательского ввода.

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

4. Совпадение Критерия

Теперь вопрос, когда правило доступа совпадает с параметрами запроса? ISA Server применяет правило, если запрос соответствует следующим требованиям правила, проверяя элементы правила в этом порядке:

  1. Protocol (Протокол): один или несколько протокольных описаний с исходящим направлением для основного соединения.
  2. From (source) (От (источник)): один или более сетевых объектов, которые могут включать Сети, Множества Сетей, Компьютеры, Множества Компьютеров, Адресные диапазоны и Подсети.
  3. Schedule (Расписание): любые определения расписания.
  4. To (destination) (К (получатель)): один или более сетевых объектов, которые могут включать Сети, Множества Сетей, Компьютеры, Множества Компьютеров, Адресные диапазоны, Подсети, Множества Доменных Имен и Множество URL.
  5. Users (Пользователи): один или несколько пользовательских объектов, которые могут включать Все Пользователи, Все Авторизованные пользователи, Системные и Сетевые сервисы и любые определенные пользователем Пользовательские Множества.
  6. Content groups (Группы содержимого): любой описанный тип содержимого.

Некоторые из описанных вверху условий ясны для понимания. В особенности, критерии Protocol, From и Schedule. Они либо совпадают, либо не совпадают. Однако, для условий To, Users и Content group это не всегда легко для понимания. Например, какая методология используется, если авторизация запрошена по правилу, а запрос не может быть авторизованный? Как ISA будет обрабатывать правило с указанными Множеством URL или Группой Содержимого, а разрешенные протоколы содержат HTTP и не-HTTP протокольные описания? Давайте рассмотрим все эти особые ситуации более детально.

4.1. To (destination) (К (назначение))

Если вы проверите свойства этого элемента, вы можете получить значения трех возможных типов: IP-адрес, Fully Qualified Domain Name (FQDN) (Полностью Уточненное Доменное Имя) или Uniform Resource Locator (URL) (Унифицированный Локатор Ресурса). Давайте вначале расследуем, что произойдет, когда указаны IP-адреса или FQDN, а затем, что случиться, если определить URL.

Domain Name Sets (Множества Доменных Имен) и Computer Sets (Множества Компьютеров)

В целях этого исследования мы некоторым способом ограничим доступ по адресам назначения www.cevi.be и www.pouseele.be. Если мы взглянем вначале на DNS-преобразование для этих получателей, мы получим следующие результаты:

Destination (Назначение) Forward DNS (Прямой DNS) Reverse DNS (Обратный DNS)
www.cevi.be 193.75.143.142 www.cevi.be cesar.cevi.be
www.pouseele.be 194.150.224.42 comsec17.win2k.combell.com

Теперь примем взамен следующие правила политики брандмауэра:

Rule Protocol From Schedule To Users Content Action
1 FTP HTTP Internal (внутреннее) Always (всегда) FQDNs All Users (все пользователи) All (все) Allow (позволить)
2 FTP HTTP Internal (внутреннее) Always (всегда) IPs All Users (все пользователи) All (все) Allow (позволить)
Last All (все) All (все) Always (всегда) All (все) All Users (все пользователи) All (все) Deny (отклонить)

Примечание: Множество Доменных Имен FQDN наполнено значениями www.cevi.be и www.pouseele.be, а Множество Компьютеров IP — значениями 193.75.143.142 и 194.150.224.42. Также, мы протестируем FTP доступ из FTP клиента (не тоннельный FTP) командной строки Microsoft и HTTP доступ из Internet Explorer.

Для FTP доступа результат будет следующий, независимо от того, сконфигурирован ли клиент как клиент Firewall или как клиент SecureNET:

  • FTP доступ на назначение www.cevi.be будет разрешен по правилу #1.
    Когда ISA начинает оценку правила #1, ISA обнаруживает, что элементы Protocol, From и Schedule совпали. Для возможности совпадения элемента To, ISA производит обратный DNS поиск запрошенного назначения 193.75.143.142 (помним, что запрос послан по IP-адресу). Возвращаемым значением является www.cevi.be, поэтому мы имеем совпадение для элемента To. Затем проверяются элементы Users и Content, и они тоже совпадают. Поэтому мы поучаем полное совпадение, никакие правила больше не оцениваются, а выполняется указанное действие Allow.
  • FTP доступ на назначение www.pouseele.be будет разрешен по правилу #2.
    Когда ISA начинает оценивать правило #1, ISA обнаруживает, что элементы Protocol, From и Schedule совпадают. Для возможности совпадения элемента To, ISA производит обратный DNS поиск запрошенного назначения 194.150.224.42 (помним, что запрос послан по IP-адресу). Возвращаемым значением является comsec17.win2k.combell.com, поэтому мы не получаем совпадение по элементу To. Следовательно, ISA пропускает дальнейший анализ правила #1 и начинает оценивать следующее правило по порядку.
    Когда ISA начинает оценивать правило #2, ISA обнаруживает, что элементы Protocol, From и Schedule совпадают. Далее проверяется элемент To и теперь без необходимости выполнять DNS поиск ISA может получить совпадение запрашиваемого назначения 194.150.224.42 с IP-адресами Множества Компьютеров. Затем проверяются элементы Users и Content, которые также совпадают. Поэтому мы имеем полное совпадение, никакие правила больше не оцениваются, а выполняется указанное действие Allow.

Для HTTP доступа будет точно такая же логика с одним большим отличием в том, что ISA пытается поставить в соответствие поле заголовка HTTP Host вместо точки назначения уровня-3. Заметьте, что значение поля заголовка HTTP Host заполнено тем, что пользователь ввел в адресной панели Internet Explorer. Результат будет следующий, вне зависимости от того, сконфигурирован ли клиент как клиент Web Proxy, Firewall или SecureNET:

  • HTTP доступ по адресу http://www.cevi.be и http://www.pouseele.be будет разрешен по правилу #1. Поле заголовка HTTP Host может прямо совпасть с Множеством Доменных Имен FQDN, указанным в элементе To правила #1.
  • HTTP доступ по адресу http://193.75.143.142 будет разрешен по правилу #1. Поле заголовка HTTP Host может после обратного DNS поиска совпасть с Множеством Доменных Имен FQDN, указанным в элементе To.
  • HTTP доступ по адресу http://194.150.224.42 будет разрешен по правилу #2. Поле заголовка HTTP Host может после обратного DNS поиска не совпасть с Множеством Доменных Имен FQDN, указанных в элементе To правила #1. Поэтому ISA пропускает дальнейший анализ правила #1 и начинает оценку правила #2. Здесь поле заголовка HTTP Host может напрямую совпасть с Множеством Компьютеров IP, указанным в элементе To правила #2.

Мы можем сделать важный вывод о том, что DNS преобразование крайне важно для ISA Server. Также, если вы хотите разрешить или запретить отдельные назначения, и они дают различный результат, когда выполняется прямой и обратный DNS поиск, вы должны быть очень внимательны с типами сетевых объектов (FQDN или IP-адрес), которые вы используете в элементе To правила доступа.

В качестве упражнения, давайте построим простую политику брандмауэра, которая запрещает доступ к www.cevi.be и www.pouseele.be, и разрешает доступ ко всем остальным адресатам. Мы будем использовать такие же протоколы, Множество Доменных Имен и Множества Компьютеров, как и в предыдущем примере. Мы имеем два пути достижения этой цели:

  • Ваша первая возможность — это создать запретительное правило для назначений www.cevi.be и www.pouseele.be (правило #1), а затем — разрешительное правило для всех других назначений (правило #2). Не требуются никакие другие правила, за исключением правила по умолчанию Last. Вопрос в том, что следует включить в элемент To правила #1? Ответ: оба — Множество Доменных Имен FQDN и Множество Компьютеров IP — должны быть включены. Иначе, доступ на назначение www.pouseele.be будет не всегда блокироваться по правилу #1, а будет зависеть от того, посылается ли запрос по IP-адресу или FQDN.
  • Ваша вторая возможность — создать одиночное правило доступа для всех назначений, кроме двух: www.cevi.be и www.pouseele.be (правило #1). Больше не нужны ни какие правила, за исключением правила по умолчанию Last. Снова, вопрос: что же следует включить в исключение элемента To правила #1? Ответ опять такой же: оба — Множество Доменных Имен FQDN и Множество Компьютеров IP — должны быть включены. Иначе доступ на назначение www.pouseele.be будет иногда разрешен правилом #1, в зависимости от того, посылается ли запрос по IP-адресу или FQDN.
    Знайте, что в последнем случае правило по умолчанию Last блокирует трафик, потому что элемент To в правиле #1 не совпадает и поэтому правило #1 не применяется.

Множества URL

Последний вопрос, который мы должны обсудить в этом разделе — это что случится, когда мы укажем Множество URL в элементе To и не-Web протоколы будут затронуты в подобном правиле. Когда ISA Server 2004 обрабатывает правило, которое применяется ко Множеству URL, элемент Множества URL этого правила обрабатывается только для запросов Web-трафика, т.е. для протоколов HTTP, HTTPS и тоннельного FTP. Однако, для HTTPS трафика, множества URL обрабатываются только, если URL не имеет описанного пути. Наконец, если клиентский запрос использует другой протокол, ISA Server всегда игнорирует Множество URL, когда обрабатывает правило.

Для проверки такого поведения давайте немного изменим нашу политику брандмауэра, заменив Множество Доменных Имен FQDN в правиле #1 на Множество URL URLs, наполненных значениями http://www.cevi.be и http://www.pouseele.be. Оставим правило #2 таким же. Полученная политика брандмауэра будет, как описано ниже:

Rule Protocol From Schedule To Users Content Action
1 FTP HTTP Internal Always URLs All Users All Allow
2 FTP HTTP Internal Always IPs All Users All Allow
Last All All Always All All Users All Deny

Когда теперь мы тестируем FTP доступ (не тоннельный FTP) на назначения www.cevi.be и www.pouseele.be, мы увидим, что оба назначения всегда разрешены по правилу #2. Это означает, что ISA Server не может найти подходящий элемент To в правиле #1. Другими словами, если ISA игнорирует Множество URL для не-Web протоколов, а больше ничего не указано, то ISA никогда не найдет соответствие и это правило никогда не применится, не зависимо от того, разрешающее это правило или запрещающее. Если мы добавим опять Множество Доменных Имен FQDN в элемент To правила #1 и повторим наш тест FTP доступа, то мы получим наш начальный результат: FTP доступ на назначение www.cevi.be будет разрешен по правилу #1, а FTP доступ на назначение www.pouseele.be будет разрешен по правилу #2.

4.2. Пользователи

Когда вы создаете правила политики брандмауэра, вы можете применить их к определенным IP-адресам или пользователям. Когда вы применяете правило к пользователю, пользователь должен быть авторизован, представив идентификационные данные, как это требуется для определенного правила. Вы можете группировать пользователей вместе в Множества Пользователей. Множества пользователей могут включать одного или более пользователей из любой схемы авторизации. Например, множество пользователей может включать пользователя Windows, пользователя из пространства имен RADIUS и другого пользователя из пространства имен SecurID. ISA Server поставляется предварительно настроенным со следующими множествами пользователей:

  • All Authenticated Users (Все авторизованные пользователи): предопределенное множество пользователей, представляющее всех авторизованных пользователей. Правило, определенное на использование этого множества, применяется только к авторизованным пользователям.
    Заметьте, что SecureNET клиенты никогда не могут авторизоваться, если они не являются также и VPN клиентами. В этом случае, удостоверения о входе VPN пользователя будут использоваться для авторизации.
  • All Users (Все пользователи): предопределенное множество пользователей, представляющее всех пользователей. Правило, определенное на использование этого множества, будет применяться ко всем пользователям, как авторизованным, так и не авторизованным или анонимным.
  • System and Network Service (Системные и Сетевые Сервисы): предопределенное множество пользователей, представляющее Local System (Локальный Системный) сервис и Network (Сетевой) сервис на компьютере ISA Server. Это множество пользователей в некоторых правилах системной политики.

Как клиенты авторизуются в ISA server, зависит от типа ISA клиента, обрабатывающего запрос:

  • Клиент Firewall (Брандмауэра): ISA Server запрашивает удостоверения, когда устанавливается сессия. Затем, когда клиент Firewall запрашивает объект, ISA Server не требует, чтобы клиент прошел авторизацию заново, потому что сессия уже имеет идентификатор. Помните, что клиент Firewall авторизует пользователя в ISA Server от имени приложения, запросившего доступ.
  • Клиент Web Proxy: после разрешения доступа Web Proxy клиенту для определенной сети на которой расположен пользователь, вы можете сконфигурировать механизмы авторизации, которые будут использоваться для авторизации клиентов Web Proxy. Когда выбрана установка Require all users to authenticate (Требуется авторизация всех пользователей) в приемнике Web Proxy, ISA Server будет всегда запрашивать пользовательские удостоверения до проверки политики брандмауэра. Иначе ISA Server будет запрашивать авторизацию клиента только, если правило требует авторизации клиента для проверки совпадения.

Более того, вы должны знать о двух интересных ситуациях, касающихся авторизации пользователей:

  • Если правило применяется ко множеству пользователей All Users (Все пользователи), ISA Server не будет требовать пользовательские удостоверения. Однако клиент Firewall будет всегда посылать удостоверения на ISA Server. Вы это увидите на самом деле в MMC в этой сессии и вкладке регистрации, когда имя пользователя имеет вопросительный знак (?) следом за этим. Это означает в действительности, что пользовательские удостоверения представляются, но они не проверяются.
  • Когда вы конфигурируете правила доступа, которые применяются к пользователям и пользователь не может авторизоваться самостоятельно для любых случаев, то запрос будет отклонен по правилу, требующему авторизацию, даже если это разрешающее правило. Эта ситуация может возникнуть, если вы забыли включить, по крайней мере, один механизм авторизации в приемнике Web Proxy. Например, ISA сервер будет отклонять любые запросы от клиента SecureNET, который не является одновременно VPN клиентом, когда попадает на правило, требующее пользовательской авторизации.

Для проверки описанного выше поведения авторизации пользователя, давайте создадим правило #1 политики брандмауэра, позволяющее пользователю Tom доступ для FTP и HTTP ко всем внешним назначениям, и правило #2, позволяющее всем авторизованным пользователям доступ для FTP и HTTP ко всем внешним назначениям. Полученная в результате политика брандмауэра показана в таблице внизу:

Rule Protocol From Schedule To Users Content Action
1 FTP HTTP Internal Always External Tom All Allow
2 FTP HTTP Internal Always External All Auth All Allow
Last All All Always All All Users All Deny

Для клиента Web Proxy и клиента Firewall результирующий доступ будет, как описано ниже:

  • Пользователю Tom будет разрешен доступ по HTTP и FTP к любому назначению по правилу #1.
    Когда ISA начинает оценку правила #1, ISA обнаружит, что элементы Protocol, From, Schedule и To совпали. Для способности проверить на совпадение элемент Users, ISA должен подтвердить пользователя и сравнить с пользователем Tom. Или ISA Server будет запрашивать авторизацию у клиента Web Proxy, или использовать удостоверения, предоставленные клиентом Firewall. Потому, что удостоверения пользователя Tom действительны и этот пользователь соответствует описанному пользователю Tom, мы получаем совпадение для элемента User. Затем проверяется элемент Content и он соответствует тоже. Поэтому мы получаем полное совпадение, никакие другие правила не проверяются, а применяется описанное действие Allow.
  • Любому другому авторизованному пользователю будет разрешен доступ по HTTP и FTP на любое назначение по правилу #2.
    Когда ISA начинает оценивать правило #1, ISA обнаруживает, что элементы Protocol, From, Schedule и To совпали. Для способности проверки элемента Users, ISA должен подтвердить пользователя и сравнить его с пользователем Tom. Или ISA Сервер будет запрашивать авторизацию у клиента Web Proxy, или использовать удостоверения, предоставленные клиентом Firewall. Из-за того, что удостоверения пользователя X действительны, но не совпадают с определенным пользователем Tom, ISA пропускает дальнейший анализ правила #1 и начинает оценку следующего правила по порядку.
    Когда ISA начинает оценку правила #2, ISA обнаруживает, что элементы Protocol, From, Schedule и To совпали. Далее, проверяется элемент User и теперь удостоверения пользователя X действительны и совпадают с предопределенным множеством пользователей All Authenticated Users. Затем проверяется элемент Content, и он совпадает тоже. Поэтому, мы имеем полное совпадение, никакие другие правила не проверяются, а применяется описанное действие Allow.

Для клиента SecureNET (не являющегося VPN клиентом) результат описан ниже:

  • Для любого анонимного пользователя будет запрещен HTTP и FTP доступ по правилу #1. Когда ISA начинает оценку правила #1, ISA обнаруживает совпадение элементов Protocol, From, Schedule и To. Для способности проверки элемента Users, ISA должен подтвердить пользователя и сравнить его с пользователем Tom. Однако клиент SecureNET неспособен авторизоваться для ISA Server и поэтому никакие пользовательские удостоверения не могут быть переданы в механизм правила. Поэтому ISA никогда не может утвердить пользователя и запрос будет немедленно отклонен. Это также означает, что никакие другие правила уже не применяются.

Очень важный вывод из этого раздела — это, если ISA Server не способен авторизовать пользователя по каким-либо причинам, что означает, что никакие удостоверения не предъявлены ISA Server, то любой запрос от этого пользователя будет отклонен по первому же правилу, требующему авторизации пользователя, вне зависимости от того, разрешающее это правило или запрещающее. В действительности, эта ситуация является первым случаем, когда разрешающее правило реально запрещает запрос. Без надобности говорить, что такое поведение может вызвать небольшое замешательство, на первый взгляд.

4.3. Группы Content (Содержимого)

Когда вы создаете правило доступа. Вы можете ограничить типы содержимого, к которым применяется правило доступа. Группы Content определяются при конфигурировании типов содержимого Multipurpose Internet Mail Extensions (MIME) (Многоцелевые Интернет Почтовые Расширения) и расширения имен файлов. Тип содержимого контролирует применение правил только для протоколов HTTP и тоннельного FTP трафика. Для других протоколов, включая HTTPS, ISA Server всегда игнорирует описанные группы Content, когда обрабатывает правила.

Когда клиент запрашивает FTP содержимое, ISA Server проверяет расширение имени файла запрашиваемого объекта. Однако когда клиент запрашивает HTTP содержимое, ISA Server посылает запрос на Web сервер. Когда Web сервер возвращает этот объект, ISA Server проверяет MIME тип объекта или расширение его имени файла, в зависимости от информации заголовка, возвращаемого Web сервером.

Для проверки такого поведения давайте создадим следующую политику брандмауэра:

Rule Protocol From Schedule To Users Content Action
1 FTP HTTP Internal Always External All Users HTML Allow
2 FTP HTTP Internal Always External All Users All Allow
Last All All Always All All Users All Deny

Примечание: мы используем предопределенную группу Content HTML Documents (Документы HTML). Также мы будем тестировать FTP доступ с помощью FTP клиента командной строки Microsoft (не тоннельный FTP) и HTTP доступ с помощью Internet Explorer.

Когда мы тестируем HTTP доступ к web-сайту, вы увидите, что возвращаемые объекты, являющиеся членами группы содержимого HTML Documents, разрешены по правилу #1, а все остальные объекты разрешены по правилу #2. Это означает, что ISA Server не может найти совпадение для элемента Content в правиле #1. Поэтому ISA пропускает дальнейший анализ правила #1 и начинает оценку следующего правила по порядку. В правиле #2 все содержимое разрешено. Поэтому мы теперь получаем полное совпадение, никакие другие правила не проверяются, а применяется описанное действие Allow.

Для FTP доступа, ISA игнорирует определенные группы содержимого в правиле #1. Из-за того, что вы не сконфигурировали All content types (Все типы содержимого) и Selected content types (Выбранные типы содержимого) в этом правиле, ISA Server никогда не найдет совпадение для элемента Content в правиле #1. Поэтому ISA пропускает дальнейший анализ правила #1 и начинает оценку следующего правила по порядку. В правиле #2 разрешено все содержимое. Поэтому мы теперь получаем полное совпадение, никакие другие правила не проверяются, а применяется описанное действие Allow. Это означает, что если вы определили управление типом содержимого в правиле, другими словами, если вы разрешили Selected content types (Выбранные типы содержимого), то правило никогда не применится к протоколам, отличным от HTTP и тоннельного FTP, вне зависимости от того, является ли это правило разрешающим или запрещающим.

5. Критерии Фильтрации

Кроме совпадения критериев, описанном довольно подробно в предыдущем разделе, разрешающее правило может также иметь некоторые критерии фильтрации, ограничивающие его. Заметьте, что критерии фильтрации могут быть определены только для разрешающих правил, не для запрещающих правил. Прямо из коробки, ISA Server поддерживает критерии фильтрации для протоколов HTTP, FTP и RPC. Если разрешающее правило применяется к одному или более из этих протоколов, то вы можете добраться до критерия фильтрации правым щелчком мыши на соответствующем правиле, как показано на рисунке внизу:

Правило isa server на другой прокси

Configure HTTP (Конфигурирование HTTP): эта опция позволяет вам настроить HTTP Security Filter (Фильтр Безопасности HTTP) для приведения в действие управления доступом над соединениями HTTP, используя расширенные механизмы инспекции приложения ISA Server.

  • Configure FTP (конфигурирование FTP): эта опция позволяет вам разрешать или запрещать FTP закачку.
  • Configure RPC protocol (Конфигурирование протокола RPC): эта опция позволяет вам разрешать или запрещать строгое RPC соответствие, которое имеет эффектом разрешение или запрещение DCOM соединений.

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

Для проверки этого поведения, давайте создадим следующую очень простую политику брандмауэра:

Rule Protocol From Schedule To Users Content Action
1 FTP HTTP Internal Always External All Users All Allow
2 FTP HTTP Internal Always External All Users All Allow
Last All All Always All All Users All Deny

Далее мы настроим следующий критерий фильтрации HTTP только по правилу #1:

Системные правила в isa

Наконец, убедимся, что мы разрешили регистрацию работы Фильтра Безопасности HTTP добавлением поля Filter Information (Информация Фильтра) в список отображаемых колонок встроенного просмотрщика логов. Это поле включает информацию, которую может регистрировать Web-фильтр. Например, когда Фильтр Безопасности HTTP отклоняет запрос, причина такого отклонения фиксируется здесь.

Теперь перейдем на www.microsoft.com и вы увидите, что картинки с расширением gif, jpg или png блокированы. Для подтверждения этого, проверьте ISA log и вы должны обнаружить некоторое количество запросов, разрешенных по правилу #1, но также и много запросов, отклоненных по правилу #1. Если будете далее изучать log, вы должны обнаружить информацию Blocked by the HTTP Security filter: URL contains an extension which is disallowed (Блокировано фильтром Безопасности HTTP: URL содержит расширение, которое запрещено) в колонке Filter Information (Информация Фильтра) для отклоненных запросов. Итак, эти запросы реально блокированы правилом #1.

6. Обобщение

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

Не все пользователи авторизуются на шыф

Примечание: соединители 1, 2 и 3 те же, что и показаны на потоковой диаграмме в разделе 2. Введение.

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

  • Поместите Web and Server Publishing rules (Правила Web и Серверной Публикации) на самый верх списка. В соответствие с файлом справки ISA, правила доступа, которые запрещают трафик обрабатываются перед правилами публикации. Поэтому, если запрос соответствует правилу доступа, запрос будет отклонен, даже если правило публикации разрешило бы этот запрос.
  • Далее разместите ваши anonymous access rules (правила анонимного доступа) в следующем порядке: вначале запрещающие, а затем разрешающие правила. Эти правила не требуют авторизации.
  • В конце расположите ваши authenticated access rules (правила авторизованного доступа) в следующем порядке: вначале запрещающие, а затем разрешающие правила. Эти правила требуют авторизации.

Последнее замечание: убедитесь, что более специфичные правила всегда расположены перед более общими правилами и что вы никогда не используете законченного подмножество в элементе from, подобного элементу предыдущего правила.

7. Заключение

В этой статье мы изучили то, как ISA Server 2004 использует три списка правил: Сетевые правила, правила Системной Политики и правила Политики Брандмауэра, которые описывают от функциональной точки зрения реализованной сетевой топологии и политики брандмауэра до определения того, должен ли быть трафик разрешен или запрещен. Вы должны помнить, что ISA Server очень зависим от устойчивой сплошной инфраструктуры DNS для возможности корректно оценивать сконфигурированную политику брандмауэра. Также, знайте, что порядок расположения правил очень важен и что есть два случая, в который разрешающее правило может, в действительности, запретить трафик.

Источник www.isaserver.org










Смотрите также:

Tags: , , , , , , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]