Когда был выпущен брандмауэр 2000 ISA, он воспринимался сообществом пользователей файерволов, как обновленная версия Microsoft Proxy Server 2.0 и, соответственно, его надежность в области безопасности и файерволов постоянно ставилась под сомнение администраторами брандмауэров аппаратного уровня. Представители «старой школы» все еще воспринимают брандмауэр ISA, как веб прокси сервер и устройство кэширования с небольшими возможностями файервола, встроенными для отвода глаз. Большое количество этой ложной информации распространялось производителями других брандмауэров и обычными противниками продукции Microsoft (ABMer’s), которые не придавали особого значения обычным вещам (таким, как, например, факты).
Для тех, кто ‘в курсе’, это очевидно неправильная и некорректная оценка брандмауэра. Брандмауэр ISA был создан на пустом месте, чтобы стать полноценным брандмауэром сетевого и прикладного уровня. Функции web proxy и кэширования были составляющими технологии брандмауэров, а не наоборот.
Неправильное представление о том, что брандмауэр ISA является своего рода только устройством Web proxy, однако, позволило достичь одной вещи, а именно того, что брандмауэр стал самым популярным в мире решением кэширования и веб прокси. Есть небольшие сомнения на счет того, что брандмауэр ISA работает исключительно хорошо в качестве сервера веб доступа и кэширования. Однако, как и у всех решений, у брандмауэра ISA отсутствуют некоторые функции, которыми оснащены брандмауэры прочих производителей. Функция, которая отсутствует в брандмауэре, а также в таких продуктах компании Microsoft, как IIS, это поддержка X-Forwarded-For: поле заголовков HTTP и HTTPS.
X-Forwarded-For (XFF) HTTP заголовок, по сути, представляет собой стандарт отрасли для идентификации создаваемого IP адреса клиента, подключаемого к веб серверу через HTTP proxy. Без этого поля любое подключение через прокси будет показывать только IP адрес прокси сервера, что в свою очередь преобразовывает прокси сервер в службу анонимности. Это значительно усложняет, или вообще делает невозможным, надежное определение запросов создаваемого IP адреса клиента, когда они проходят по цепи веб прокси. Чтобы ответить на вопрос ‘Так что же?’, поскольку сервер Microsoft ISA Server изначально не поддерживает X-Forwarded-For поле, очень сложно войти и определить злоумышленный доступ, который прошел через вашу прокси цепь ISA Server.
Есть причина, по которой данная функция изначально не поддерживается такой продукцией компании Microsoft, как брандмауэр ISA и IIS.
Разработчики компании Winfrasoft создали два продукта, которые позволяют инфраструктуре Microsoft распознавать и использовать поле X-Forwarded-For, в то же время предотвращая все проблемы безопасности, связанные с этой технологией. Один продукт разработан для брандмауэров ISA, а второй – для IIS. Я не часто оцениваю продукты, созданные для других технологий, а не для брандмауэров ISA. Однако существует значительная синергетика между брандмауэром ISA и IIS, поскольку многие серверы IIS Web публикуют веб сайты за брандмауэром.
Winfrasoft X-Forwarded-For для брандмауэров ISA позволяет администраторам ISA отслеживать и регистрировать HTTP и HTTPS веб трафик из оригинального источника посредством многоуровневой ретрансляции и обратимых прокси, а также анализировать информацию с помощью ведения логов ISA Server Logging. Этот продукт обеспечивает брандмауэр ISA той же функциональностью, которой обладают другие устройства веб прокси и компенсаторы нагрузки (Squid, Apache, F5 Big-IP, Blue Coat, Cisco Cache Engine и Netcache).
Winfrasoft X-Forwarded-For для IIS позволяет администраторам IIS регистрировать HTTP и HTTPS веб трафик из оригинального источника посредством многоуровневых прокси, а также анализировать данные с помощью стандартных инструментов для отчетов веб сайтов. Это позволяет безопасно публиковать веб серверы IIS за брандмауэрами 7 уровня и компенсаторами нагрузки, такими как брандмауэр ISA (с помощью X-Forwarded-For для брандмауэров ISA) и обычными продуктами, перечисленными выше.
Установка представляет собой простой процесс, требующий минимальных действий пользователя, поэтому я не буду вдаваться в подробности этой операции. После установки, X-Forwarded-For для ISA Server появляется в разделе Web Filters вкладки программных модулей Add-ins левой панели консоли брандмауэра ISA. В консоли брандмауэра ISA веб фильтр можно включить или выключить, а также перемещать вниз или вверх в списке приоритетности.
Рисунок 1: Раздел Веб фильтров во вкладке программных модулей Add-ins левой панели консоли брандмауэра ISA
Когда X-Forwarded-For для ISA Server установлен на всех брандмауэрах ISA вашей веб прокси цепи, происходит чудо. Когда клиентские запросы проходят через веб прокси цепь, X-Forwarded-For HTTP заголовок добавляется (если поле XFF не существовало) или изменяется (если поле XFF существовало) и брандмауэр ISA включает действительный IP адрес клиента в заголовок X-Forwarded-For HTTP.
Для тестирования X-Forwarded-For для ISA в Forward Proxy, я настроил следующую инфраструктуру в своей тестовой среде.
Рисунок 2: Тестовая среда для тестирования прокси ретрансляции
Рисунок 3: Логи ISA — Web Proxy (Forward)
Этот журнал регистрации событий с Upstream Proxy (192.168.0.254) сервера показывает HTTP запрос лучшего в мире сайта :-). IP адрес клиента можно посмотреть в поле Источник. В окне Информация фильтра было создано поле заголовка X-Forwarded-For HTTP и IP адреса веб прокси серверов, обрабатывающих запрос, тоже записаны.
Существуют потенциальные проблемы безопасности, поскольку пакеты HTTP, исходящие в веб, могут перечислять ваши внутренние IP адреса, хотя стандартным поведением X-Forwarded-For для ISA Server является удаление данных поля X-Forwarded-For, когда пакет покидает последний веб прокси сервер в веб прокси цепи, как делает Upstream Proxy в этом сценарии. Это можно проверить с помощью сетевого анализатора, например NetMon 3.2 (Microsoft Network Monitor 3.2)
Если у вас установлен сниффер входящих пакетов (transparent upstream packet sniffer), то поведение X-Forwarded-For для ISA Server может быть настроено на оставление информации X-Forwarded-For в пакете HTTP, когда он покидает последний веб прокси сервер в веб цепи. Конечно, я могу порекомендовать его только в том случае, если сниффер входящих пакетов имеет возможность удалять X-Forwarded-For до того, как запрос попадает в интернет.
Чтобы проверить X-Forwarded-For для ISA в Reverse Proxy, я настроил следующую инфраструктуру в своей тестовой лаборатории.
Рисунок 4: Ведение логов ISA в случае использования обратимого веб прокси (Web Proxy)
Рисунок 5: Информация логов в случае использования обратимого веб прокси
Этот лог с Downstream2 Proxy (192.168.0.200) сервера показывает HTTP запрос с интернет клиента на веб страницу, опубликованную на IIS, расположенном за моей обратимой веб прокси цепью. IP адрес оригинального клиента показан в поле Источник. В окне Информация фильтра было создано поле заголовка X-Forwarded-For HTTP, а IP адреса веб прокси серверов, обрабатывавших запросы, записаны.
В отличие от сценария с веб прокси, поскольку HTTP запрос остается внутренним, отсутствует проблема безопасности, связанная с сохранением внутренних адресов в заголовке HTTP пакета, поэтому последних веб прокси сервер не отображает поле X-Forwarded-For.
Это тоже очень хорошо, так как если у вас есть веб сервер Apache, настроенный за вашей веб прокси цепью, то можно просматривать логи на этом сервере и определять маршрут запроса. Это плавно ведет нас ко второму продукту пакета Winfrasoft X-Forwarded-For, X-Forwarded-For для IIS.
Как и в случае с фильтром X-Forwarded-For для ISA Server, здесь процесс установки тоже очень простой и требует минимальных действий со стороны пользователя. X-Forwarded-For для IIS является фильтром ISAPI, который после установки интегрируется в страницу свойств ISAPI Filters для всех веб сайтов на вашем сервере IIS.
Рисунок 6: Диалоговое окно Свойства веб сайтов
Ниже приведена схема моей тестовой среды, используемой для тестирования X-Forwarded-For для IIS. В нижеприведенном примере с клиентского ПК (192.168.10.76) я запрашиваю веб страницу, расположенную на моем сервере IIS Web Server (192.168.0.1). Мой сервер IIS представляет собой IIS версии 6.0, запущенный на сервере Windows 2003, однако следует отметить, что X-Forwarded-For для IIS также поддерживает IIS 7.0 на Windows 2008.
Рисунок 7: Сценарий 1 – Сервер Internet Information Server без X-Forwarded-For для IIS
Как уже говорилось, сервер Internet Information Server изначально не поддерживает X-Forwarded-For, поэтому в логах на стандартной установке IIS будет записано, что все запросы исходят с сервера Downstream2 (192.168.0.200).
Это запись лога в формате W3C с Веб сервера (192.168.0.1). Поле c-ip содержит IP адрес клиента, выполняющего запрос.
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2008-09-09 16:37:24
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-
username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2008-09-07 16:37:24 W3SVC1 192.168.0.1 GET /Default.htm - 80 - 192.168.0.200 Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) 200 0 0
В этом примере видно, что IP адрес клиента, выполняющего запрос, потерян, что делает ведение логов на веб сервере бесполезным.
X-Forwarded-For для IIS можно настроить с помощью списков доверия на отображение всего поля заголовка X-Forwarded-For или первого ненадежного IP адреса в логах IIS.
Как я уже говорил, X-Forwarded-For для IIS можно настроить на отображение первого ненадежного IP адреса. Чтобы понять эту концепцию, нам нужно разобрать различия между надежными и ненадежными IP адресами. В своей тестовой среде я знаю IP адреса всех своих прокси серверов, поэтому данные адреса будут надежными, и я добавлю их в список доверенных адресов. Мой список доверенных адресов в этом примере будет следующим:
TrustList= 192.168.0.254, 192.168.0.200, 192.168.0.100
Любой IP адрес, который не входит в этот список, будет считаться недоверенным.
Списки доверенных адресов снижают уровень риска для безопасности, который встречается на прокси серверах с поддержкой заголовков X-Forwarded-For. Прокси серверы, поддерживающие X-Forwarded-For, просто добавляют IP адрес, получаемый ими с запроса, к заголовку и передают его. Поскольку в этом поле нет подписи данных, любой IP адрес может быть подменен ложным адресом в этом заголовке. Это может сделать недействительными все отчеты, созданные на основе заголовков X-Forwarded-For.
Когда IIS фильтр обрабатывает заголовок X-Forwarded-For, он проверяет IP адрес первого прокси сервера на основе адреса четвертого уровня. Если адрес доверенный, процесс верификации продолжается с IP адресами, перечисленными в X-Forwarded-For заголовке до тех пор, пока не будет обнаружен первый ненадежный IP адрес. Затем он используется в качестве c-ip в логе веб сервера, поскольку это был первый маршрутизируемый адрес интернета, попавший в веб прокси цепь – а это означает, что любые ложные IP адреса, перечисленные ранее, запрещаются.
TrustList= 192.168.0.254, 192.168.0.200, 192.168.0.100
X-Forwarded-For: 192.168.0.254, 192.168.0.200, 192.168.0.100
Это запись журнала регистрации событий в формате W3C с Веб сервера (192.168.0.1), использующего вышеупомянутый список доверия. И снова, поле c-ip содержит IP адрес клиента, выполняющего запрос.
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2008-09-09 16:44:12
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-
username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2008-09-07 16:37:24 W3SVC1 192.168.0.1 GET /Default.htm - 80 - 192.168.10.76 Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) 200 0 0
Из этого примера видно, что первый ненадежный клиентский IP адрес записан, как IP адрес клиента, выполняющего запрос.
X-Forwarded-For: 192.168.0.254, 192.168.0.200, 192.168.0.100
В этом примере я удалил свой список доверия и снова запросил веб страницу, расположенную на веб сервере. Поскольку список доверия отсутствует, X-Forwarded-For для IIS работает по-другому и теперь вставляет весь заголовок X-Forwarded-For в поле c-ip лога W3C, а также IP адрес сервера, прошедший HTTP запрос на сервер IIS Web Server.
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2008-09-09 16:46:54
#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-
username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2008-09-07 16:37:24 W3SVC1 192.168.0.1 GET /Default.htm - 80 -
192.168.10.76,+192.168.0.254,+192.168.0.100,+192.168.0.200 Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) 200 0 0
Пакет продуктов X-Forwarded-For предоставляет вашему брандмауэру ISA и инфраструктуре IIS те же возможности применения X-Forwarded-For и функции ведения логов, какими обладают продукты других производителей. Компания Winfrasoft сделала шаг вперед для устранения рисков безопасности, связанных с этой технологией.
Эти два программных продукта, которые можно устанавливать независимо друг от друга, значительно улучшат ваши возможности отслеживания HTTP и HTTPS запросов, а их удобство становится очевидным, когда вы анализируете или определяете атаку вредоносного кода. X-Forwarded-For для ISA Server и X-Forwarded-For для IIS также позволяет вам собирать все необходимые данные, которые являются критическими для ваших стратегий аудита и совместимости.
www.isaserver.org
Tags: apache, cache, forward, ISA Server, Microsoft ISA Server, proxy, squid, transparent, Windows 2008