Аутентификация исходящего веб-трафика из сетей, защищенных брандмауэром TMG

Введение

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

Методы аутентификации

Брандмауэр TMG предоставляет два метода аутентификации исходящих веб-запросов:

• Через глобальный параметр конфигурации прослушивателя исходящего веб-прокси.
  
• На основе правил брандмауэра

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

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

1. На брандмауэре TMG откройте консоль брандмауэра Forefront TMG.
   
2. Щелкните Forefront TMG (имя сервера) на левой панели консоли.
   
3. Щелкните узел Networking на левой панели консоли, а затем щелкните вкладку Internal на средней панели.
   
4. Нажмите «Изменить выбранную сеть» на правой панели.
   
5. Перейдите на вкладку «Веб-прокси», а затем нажмите кнопку «Аутентификация». Вы должны увидеть диалоговое окно, подобное показанному на рисунке ниже.

фигура 1

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

Дайджест

Дайджест-аутентификация требует использования протокола HTTP 1.1. Это означает, что веб-браузер должен поддерживать HTTP 1.1. Любые запросы, отправленные браузерами, не поддерживающими HTTP 1.1, не будут выполнены.

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

фигура 2

WDigest

WDigest впервые появился в Windows XP (Wdigest.dll), а затем стал поддерживаться в доменах Windows Server 2003. Метод WDigest обладает следующими уникальными характеристиками:

• Имя пользователя и доменное имя чувствительны к регистру при проверке подлинности WDigest. В этом отношении он отличается от Digest, Basic и Integrated аутентификации. Это означает, что имя пользователя должно быть введено точно так же, как оно было введено администратором при создании учетной записи пользователя в Active Directory.
  
• WDigest требует, чтобы значение в ресурсной части пути URL-адреса было указано явно. Например, предположим, что пользователь отправляет запрос HTTP GET для http://host.contoso.com. Этот запрос завершится ошибкой, так как ресурс URL ( /index.htm в этом примере) отсутствует.

Если брандмауэр TMG является членом домена Windows Server 2003 или более поздней версии с включенной дайджест-аутентификацией, брандмауэр TMG будет использовать WDigest по умолчанию. Преимущество использования WDigest вместо Digest заключается в том, что WDigest не требует, чтобы в Active Directory хранилась обратимо зашифрованная копия пароля пользователя, и это обеспечивает преимущество в плане безопасности. Дополнительные сведения о том, как работает проверка подлинности Digest и WDigest на уровне операционной системы Windows, см. в статье здесь.

Интегрированная аутентификация

Встроенная проверка подлинности позволяет брандмауэру TMG использовать поставщика поддержки безопасности Windows (SSP) для проверки учетных данных пользователя. Этот метод проверки подлинности поддерживает использование проверки подлинности Negotiate, NTLM или Kerberos. Преимущество этих методов аутентификации заключается в том, что имена пользователей и пароли никогда не передаются по сети в удобочитаемой форме, если вообще пересылаются.

Базовый

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

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

Когда вы выбираете Обычную аутентификацию в диалоговом окне аутентификации, вы увидите сообщение, показанное на рисунке ниже.

Рисунок 3

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

Например, когда пользователь ( Tom ) отправляет запрос на доступ к ресурсу, брандмауэр TMG добавляет к запросу свой собственный домен ( MSFIREWALL ) и перенаправляет запрос аутентификации как MSFIREWALLTOM. Если кнопка «Выбор домена» доступна, вы можете нажать ее и добавить домен, который вы хотите, чтобы брандмауэр TMG использовал для аутентификации, как показано на рисунке ниже.

Рисунок 4

SSL-сертификат

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

Если вы включите эту опцию без установленного на TMG сертификата SSL, появится сообщение, показанное на рис. 11-35.

Рисунок 5

РАДИУС

Протокол Remote Authentication Dial-In User Service (RADIUS) указан в RFC 2865 для использования в качестве централизованного репозитория аутентификации. Брандмауэр TMG может действовать как клиент RADIUS и отправлять учетные данные пользователя и информацию о параметрах соединения на сервер RADIUS. Сервер RADIUS оценивает запрос и аутентифицирует запрос клиента RADIUS (брандмауэра TMG в данном примере) и отправляет ответное сообщение RADIUS.

Когда RADIUS используется в качестве репозитория аутентификации, трафик между клиентским приложением (например, Internet Explorer) и брандмауэром TMG будет аутентифицироваться с использованием базовой HTTP-аутентификации. Напомним, что базовая аутентификация HTTP передает имя пользователя и пароль без шифрования. При использовании RADIUS в качестве поставщика проверки подлинности для сценария веб-публикации можно повысить безопасность с помощью HTTPS. Таким образом, весь трафик от TMG к клиенту будет зашифрован. К сожалению, защита SSL недоступна для исходящих запросов на подключение, поскольку веб-браузер нельзя настроить для установления безопасного канала для прослушивателя веб-прокси.

Когда вы включаете эту опцию, вы должны указать имя или IP-адрес сервера RADIUS, который будет использоваться брандмауэром TMG. На рисунке ниже показано, куда вы добавляете информацию о новом сервере RADIUS. Нажмите кнопку «Добавить», чтобы добавить новый сервер RADIUS.

Рисунок 6

На рисунке ниже показано диалоговое окно, в котором вы добавляете информацию о новом сервере RADIUS.

Рисунок 7

Здесь вы указываете информацию о RADIUS-сервере, такую как имя сервера (или IP-адрес), общий секрет, который будет использоваться между RADIUS-сервером и RADIUS-клиентом (в данном случае брандмауэром TMG), порт аутентификации, который будет использоваться (1812 по по умолчанию) и каков будет период ожидания (по умолчанию 5 секунд).

Вы можете создать несколько серверов RADIUS, и TMG будет использовать их по порядку, проверяя список сверху вниз, для аутентификации запроса.

Требовать аутентификацию всех пользователей

Параметр Require All Users To Authenticate в прошлом немного сбивал с толку администраторов брандмауэра ISA. Многие считали, что если вы отключите эту опцию, пользователи не смогут аутентифицироваться. Дело в том, что это не так, и этот параметр не имеет ничего общего с отключением возможности прослушивателя веб-прокси аутентифицировать запросы. Запросы аутентификации по-прежнему будут оцениваться в соответствии с методом аутентификации, используемым сетью, и правилом брандмауэра, которое применяется к запросу.

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

Кроме того, при использовании этой опции могут возникнуть некоторые другие проблемы:

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

Резюме

В этой статье мы рассмотрели доступные вам протоколы аутентификации для аутентификации исходящих соединений веб-прокси через брандмауэр TMG. Мы также рассмотрели различные репозитории аутентификации, такие как Active Directory и RADIUS. Наконец, мы рассмотрели проблемы, связанные с требованием аутентификации на уровне прослушивателя исходящего веб-прокси.