Служба веб-прокси предоставляет несколько функций, повышающих производительность веб-запросов. Служба веб-прокси обеспечивает:

Как клиенты брандмауэра и SecureNAT используют службу веб-прокси

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

То, как обрабатываются HTTP-запросы от клиентов SecureNAT и брандмауэра, зависит от того, как вы настроили фильтр перенаправления HTTP. Вы можете найти этот фильтр, развернув свой сервер или массив, разверните узел «Расширения» на левой панели, а затем щелкните узел «Фильтры приложений». Дважды щелкните фильтр перенаправителя HTTP на правой панели, а затем перейдите на вкладку «Параметры». Вы увидите, что появится ниже.

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

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

Отклонить HTTP-запросы от клиентов брандмауэра и SecureNAT позволяет блокировать HTTP-запросы от клиентов SecureNAT и брандмауэра. Этот параметр заставляет вас настраивать клиентов, которым требуется доступ к HTTP, в качестве клиентов веб-прокси. Если клиент, не являющийся веб-прокси, попытается получить доступ к HTTP, запрос будет отклонен.

Аутентификация и фильтр перенаправления HTTP

У фильтра перенаправления HTTP в безопасной среде есть некоторые недостатки:

Когда HTTP-запрос от SecureNAT или клиента брандмауэра передается из службы брандмауэра в службу веб-прокси, информация аутентификации из клиента брандмауэра удаляется. Конечно, клиент SecureNAT никогда не предоставляет информацию для аутентификации, поэтому вопрос об ее удалении является спорным.

Это делает все HTTP-запросы от клиентов SecureNAT и брандмауэра анонимными. Если у вас нет высоких требований к безопасности или мониторингу, отсутствие аутентификации не проблема. Однако, если вам нужна информация о том, кто получает доступ к какому контенту, или если вам нужно контролировать доступ к веб-контенту на основе учетных данных пользователя, вам не повезло.

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

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

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

Например, даже если вы создаете правило протокола, которое запрещает доступ к HTTP пользователю/группе или набору адресов клиента, правило разрешения анонимного сайта и содержимого может переопределить настройку правила протокола. Все HTTP-запросы всегда изначально отправляются как анонимные запросы. Если существует правило разрешения сайта и контента, которое можно применить к анонимному пользователю, это правило будет применяться всегда. И это правило всегда будет применяться перед любыми правилами DENY.

Однако, если вы создадите анонимное правило протокола DENY (тип клиента установлен на Any request ), всем пользователям будет отказано в доступе к HTTP, независимо от их типа клиента ISA Server или наличия неанонимных разрешающих правил.

ПРИМЕЧАНИЕ. Если правила разрешения анонимных сайтов и контента отсутствуют, служба веб-прокси отправит обратно запрос на аутентификацию. Когда браузер получит запрос, он попытается отправить информацию для аутентификации. Компьютер, сконфигурированный только для клиентов SecureNAT или брандмауэра, не сможет отправлять эту информацию для аутентификации, и доступ будет запрещен.

Примеры

Рассмотрим следующие комбинации правил:

Обратите внимание, что при использовании HTTP правила сайта и контента имеют приоритет над правилом протокола.

Решите свои проблемы с помощью клиента веб-прокси

Вся проблема HTTP Redirector и анонимного доступа вызывает у меня головную боль. Было бы неплохо просто настроить фильтр перенаправления HTTP, чтобы заблокировать доступ от клиентов SecureNAT и брандмауэра и удалить все правила анонимного доступа. Но если мы заблокируем доступ клиентов SecureNAT и брандмауэра к HTTP, как они получат доступ в Интернет?

Ответ заключается в настройке всех браузеров для отправки запросов в службу веб-прокси. Это делает машину клиентом веб-прокси. Клиент веб-прокси может отправлять данные проверки подлинности в службу веб-прокси, поэтому данные проверки подлинности не теряются, как при использовании фильтра перенаправления HTTP для передачи запросов в службу веб-прокси.

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

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

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

Берегись

Помните, что настройка браузера и других приложений в качестве клиентов веб-прокси не приводит к тому, что они отправляют учетные данные с каждым запросом. Они будут отправлять учетные данные только тогда, когда их запрашивает служба веб-прокси. Если существует анонимное правило Site and Content Allow, то ISA Server не будет отправлять запрос на учетные данные и применит анонимное правило. ПРЕДУПРЕЖДЕНИЕ. Никогда не создавайте анонимное правило DENY; в этом случае анонимное правило DENY обрабатывается ДО анонимного правила Allow, и все сайты и контент будут запрещены.

Головы и пальцы вверх!

Как насчет не-HTTP-запросов? Что происходит, когда включено правило сайта и контента по умолчанию (которое разрешает анонимный доступ ко всему) и вы создаете правило DENY Site and Content Rule? Например, мы создаем правило Site and Content, которое ЗАПРЕЩАЕТ доступ к ftp.microsoft.com определенной учетной записи пользователя. Когда этот пользователь попытается получить доступ к сайту, запрос будет заблокирован, поскольку анонимное правило сайта и содержимого не обрабатывается первым для FTP-запросов; правило DENY обрабатывается первым. Помните, что анонимные правила применяются и принимаются перед всеми другими правилами ТОЛЬКО для HTTP-запросов.

Головы, большие пальцы и что случилось?!!

Что произойдет, если мы отправим этот FTP-запрос из браузера, настроенного как клиент веб-прокси? На этот раз запрос будет РАЗРЕШЕН, потому что клиент веб-прокси отправляет FTP-запросы как туннелированные FTP-запросы. Эти FTP-запросы фактически туннелируются к службе веб-прокси внутри HTTP-сообщения. Таким образом, запрос разрешен, поскольку правило сайта и контента по умолчанию разрешает все анонимные запросы и игнорирует правило DENY Site and Content, которое блокирует пользователя, поскольку браузер не будет запрашивать аутентификацию.

Заключительный комментарий относительно аутентификации службы веб-прокси

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

Примечание:
Если вы выберете принудительную аутентификацию в прослушивателе исходящих веб-запросов, вы НЕ сможете использовать Outlook Express для доступа к своим учетным записям Hotmail. В Outlook Express 5.x есть ошибка, из-за которой ваши учетные данные Hotmail отправляются в службу веб-прокси, а не учетные данные вашего домена. Ошибка была исправлена в Outlook Express 6.0, входящем в состав Windows XP.

Резюме
Фильтр перенаправителя HTTP позволяет клиентам SecureNAT и брандмауэра получать доступ к некоторым функциям службы веб-прокси. Однако одним из ограничений фильтра перенаправления HTTP является то, что он удаляет информацию аутентификации перед пересылкой запросов в службу веб-прокси. В результате для того, чтобы запросы обрабатывались ISA Server, должны быть анонимные правила Site and Content Allow для поддержки запросов. Анонимные правила сайта и контента всегда оцениваются в первую очередь. Это отличается от того факта, что правила DENY всегда оцениваются перед правилами разрешения. Чтобы решить эту проблему, настройте фильтр перенаправления HTTP для запросов на удаление от клиентов SecureNAT и брандмауэра и настройте все веб-приложения как клиенты веб-прокси.