Тайна перенаправителя HTTP и правил Site&Content

Тайна перенаправителя HTTP и правил Site&Content

Стефан Пуселе
ноябрь 2002 г.

Последнее обновление: 17.11.2002

1. Резюме

Вы думали, что полностью поняли, как ISA-сервер применяет правила Site&Content и в каком порядке, а теперь вы обнаружили, что клиенты брандмауэра и SecureNAT по-прежнему имеют доступ к заблокированным сайтам, несмотря на то, что существует правильное правило Site&Content. Как это возможно? В этой статье мы рассмотрим, при каких условиях это может произойти и что вы можете с этим поделать.

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

• Настройка перенаправителя HTTP, Курт Симмонс
• Предотвращение обхода службы веб-прокси клиентами SecureNAT и брандмауэра и как доставить себе головную боль с помощью фильтра перенаправления HTTP и анонимного доступа, Томас Шиндер

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

• Запретить правила, применимые к любому запросу (анонимно).
• Разрешить применение правил к любому запросу (анонимно).
• Запретить применение правил к клиентским наборам адресов или пользователям и группам (прошедшим проверку подлинности).
• Разрешить применение правил к клиентским наборам адресов или пользователям и группам (прошедшим проверку подлинности).

Конечно, требуется хорошее знание различных клиентов ISA. Если у вас есть какие-либо вопросы по ним, сначала ознакомьтесь с отличными статьями в разделе Джима Харрисона.

2. HTTP-перенаправитель

Чтобы упростить понимание и тестирование проблемы, мы создадим простую конфигурацию со следующими правилами:

• Правило протокола, разрешающее доступ ко всему IP-трафику для любого запроса.
• Правило Site&Content, разрешающее доступ ко всем местам назначения и всему содержимому для набора клиентских адресов. Набор адресов клиента содержит всю таблицу локальных адресов.
• Правило Site&Content, запрещающее доступ к целевому набору и всему контенту для любого запроса. Целевой набор содержит записи *.playboy.com, *.penthouse.com, *.netscape.com и www.pouseele.be.

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

Если клиент настроен как клиент веб-прокси, HTTP-запрос отправляется службе веб-прокси на ISA. Как и ожидалось, клиент будет иметь доступ ко всем адресатам, кроме тех, которые перечислены в наборе адресатов, используемом правилом deny Site&Content. Что произойдет, если веб-браузер не настроен в качестве клиента веб-прокси? В этом случае веб-браузер является клиентом брандмауэра или SecureNAT, а HTTP-запрос отправляется службе брандмауэра на ISA. Там запрос HTTP перехватывается перенаправителем HTTP и отправляется в запрошенное место назначения, минуя службу веб-прокси на ISA.

Как и большинство из нас, вы, вероятно, предполагаете, что служба брандмауэра возьмет на себя управление и применит к этому трафику настроенные правила Site&Content, как и к любому другому трафику. Однако это неправда! Клиенты брандмауэра и SecureNAT будут иметь HTTP-доступ к любому сайту и контенту, независимо от того, какие правила Site&Content определены. В журнале брандмауэра вы могли четко видеть, что для этих HTTP-запросов поле s-operation = Connect и что поле sc-status = 0, что означает успех. В поле Rule#1 будет указано правило протокола, разрешающее доступ, а поле Rule#2 будет пустым.

3. Правила сайта и контента

Когда перенаправитель HTTP настроен на отправку на запрошенный веб-сервер, запрос не только обходит службу веб-прокси, но и все правила Site&Content и перенаправляется непосредственно на веб-сервер. На мой взгляд, это делает HTTP Redirector бесполезным в такой конфигурации. Итак, давайте просто отключим HTTP Redirector и посмотрим, что произойдет. Обратите внимание, что мы по-прежнему используем те же правила протокола и сайта и контента, и что клиент не настроен как клиент веб-прокси.

Мы проверили все четыре запрещенных направления, и вот результат:

• Адреса www.playboy.com и www.penthouse.com всегда заблокированы.
• Адрес www.netscape.com иногда блокируется.
• Адрес www.pouseele.be никогда не блокируется.

Вы, вероятно, спросите себя, почему служба брандмауэра на ISA не блокирует все места назначения, перечисленные в наборе мест назначения, используемом правилом deny Site&Content. Это кажется нелогичным. Однако такому поведению есть хорошее объяснение.

Вы должны иметь в виду, что клиент брандмауэра и SecureNAT всегда отправляет запросы по IP-адресу службе брандмауэра на ISA. Прямой DNS-поиск полного доменного имени выполняется клиентом (SecureNAT и, возможно, клиентом брандмауэра) или сервером ISA от имени клиента (клиентом брандмауэра). Когда запрос достигает службы брандмауэра на ISA, могут произойти две вещи. Если набор назначения заполнен IP-адресами, служба брандмауэра может сравнить запрошенное назначение (IP-адрес) с IP-адресами, указанными в наборе назначения, и немедленно решить, что делать с этим запросом. Однако, если набор назначения заполнен полными доменными именами, служба брандмауэра должна сначала выполнить обратный поиск запрошенного IP-адреса в DNS. После этого он может сравнить запрошенный пункт назначения (преобразованный в полное доменное имя) с полным доменным именем, указанным в наборе пунктов назначения, и решить, что делать с этим запросом.

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

Назначения	Переадресация DNS	Обратный DNS
www. playboy.com	209.247.228.201	свободный чи. playboy.com
www. пентхаус.com	209.10.26.51	penthouse.co.uk. пентхаус.com
www. netscape.com	64.12.180.19 64.12.180.22 64.12.151.211 64.12.151.215	основной v3. netscape.com основной-v4.netscape. aol.com основной-v1.netscape. aol.com основной-v2. netscape.com
www.pouseele.be	212.35.122.33	walz.hospitable.be

Если вы теперь сравните полные доменные имена, полученные в результате обратного поиска DNS, с содержимым набора запрещенных адресатов, вы можете ясно увидеть, что служба брандмауэра найдет совпадения для www.playboy.com и www.penthouse.com. Однако для адресата www.pouseele.be служба брандмауэра никогда не найдет соответствия. Для адресата www.netscape.com это зависит от того, какой IP-адрес будет использоваться. Это точно объясняет поведение, которое мы видели.

Вам, наверное, интересно, почему служба Web Proxy на ISA ведет себя по-другому? Когда запрос отправляется службе веб-прокси, она полностью знает URL-адрес, к которому вы хотите получить доступ. Таким образом, служба веб-прокси может очень легко сопоставить URL-адрес с целевым набором, указанным в правилах Site&Content. Обычно вы вводите полное доменное имя в качестве URL-адреса. В этом случае поиск DNS не требуется. Однако если вы введете IP-адрес в качестве URL-адреса, поведение службы веб-прокси будет определяться разделом реестра SkipNameResolutionForAccessAndRoutingRules, который можно найти в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3ProxyParameters. Если этот раздел реестра отсутствует (конфигурация по умолчанию) или имеет значение 0 (DWORD), тогда служба веб-прокси выполнит обратный поиск DNS, и будет применяться та же логика, что и для службы брандмауэра. Однако если раздел реестра имеет значение 1 (DWORD), обратный поиск в DNS не выполняется. В последнем случае только правила Site&Content с целевыми наборами, заполненными IP-адресами, могут дать совпадение.

4. Вывод

Когда HTTP Redirector настроен на отправку на запрошенный веб-сервер, это действительно важно! Запрос обходит все правила Site&Content и перенаправляется непосредственно на веб-сервер. Если вам не нравится такое поведение, вам следует отключить HTTP Redirector. Однако помните о возможных проблемах с прямым и обратным поиском в DNS при создании целевых наборов для правил Site&Content.

Надеюсь, вам понравилась эта статья, и вы нашли в ней что-то, что вы можете применить к своей сети. Если у вас есть какие-либо вопросы по поводу того, что я обсуждал в этой статье, зайдите на http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=3;t=002291 и разместите сообщение. Я буду проинформирован о вашем сообщении и отвечу на ваши вопросы как можно скорее. Спасибо! – Стефан.