X-Forwarded-For и брандмауэр ISA: отслеживайте вашего исходного клиента через цепочку веб-прокси и на вашем IIS

Когда был выпущен брандмауэр ISA 2000, сообщество брандмауэров восприняло его как обновленную версию Microsoft Proxy Server 2.0, и впоследствии его авторитет в области брандмауэра и безопасности постоянно подвергался сомнению администраторами «аппаратного» брандмауэра старого мира. «Динозавры» по-прежнему рассматривают брандмауэр ISA как веб-прокси и устройство кэширования с некоторыми возможностями брандмауэра, добавленными для эффекта. Большое количество этой дезинформации было распространено конкурирующими поставщиками брандмауэров и обычной бригадой воинствующих противников Microsoft (ABMer's), которым не особенно мешали тривиальные вещи (например, факты).

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

Это неверное представление о том, что брандмауэр ISA является своего рода устройством, предназначенным только для веб-прокси, тем не менее, привело к одной вещи: брандмауэр стал наиболее широко используемым в мире решением для веб-прокси и кэширования. Нет никаких сомнений в том, что брандмауэр ISA работает исключительно хорошо в качестве веб-прокси и кэширующего сервера. Однако, как и во всех решениях, в технологиях конкурентов есть некоторые особенности, которых нет у брандмауэра ISA. Функция, отсутствующая в брандмауэре, а также в других продуктах Microsoft, таких как IIS, — это поддержка поля заголовка X-Forwarded-For: HTTP и HTTPS.

И что?

HTTP-заголовок X-Forwarded-For ( XFF ) является отраслевым стандартом де-факто для определения исходного IP-адреса клиента, подключающегося к веб-серверу через HTTP-прокси. Без этого поля любое подключение через прокси-сервер раскрывало бы только исходный IP-адрес прокси-сервера, фактически превращая прокси-сервер в службу анонимизации. Это делает очень трудным, если не невозможным, надежное определение IP-адреса клиента, отправляющего запросы, когда они проходят через цепочку веб-прокси. Чтобы ответить на вопрос «Ну и что?» вопрос, так как Microsoft ISA Server изначально не поддерживает поле X-Forwarded-For, становится очень сложно регистрировать и обнаруживать неправомерные обращения, которые прошли через цепочку прокси-сервера ISA Server.

Есть причины, по которым эта функция изначально не поддерживается продуктами Microsoft, такими как брандмауэр ISA и IIS.

• Во-первых, использование X-Forwarded-For является отраслевым стандартом де-факто, а НЕ официальным стандартом RFC.
  
• Во-вторых, исторически было много недостатков безопасности, связанных с поддержкой заголовков HTTP X-Forwarded-For. Многие реализации стали жертвами поддельных атак, когда системам предоставлялась поддельная информация X-Forwarded-For, и они непреднамеренно обрабатывали правило или действие на основе этой информации.
  
• Информация X-Forwarded-For IP представляет собой открытый текст внутри заголовка HTTP; он НЕ подписан и НЕ аутентифицирован. Это может представлять огромную угрозу безопасности, если решения о разрешении и отказе принимаются на основе данных, хранящихся в заголовке X-Forwarded-For, особенно если данные исходят из Интернета.
  
• Еще одна историческая проблема безопасности с этой технологией заключается в том, что информация о внутреннем IP-адресе может быть раскрыта в Интернете, что может привести к непреднамеренному раскрытию информации о внутренней инфраструктуре.

Ребята из Winfrasoft выпустили 2 продукта, которые позволяют вашей инфраструктуре Microsoft распознавать и использовать поле X-Forwarded-For, в то же время устраняя проблемы безопасности, связанные с этой технологией. Один продукт предназначен для брандмауэров ISA, а другой — для IIS. Нечасто я оцениваю продукты, разработанные для других технологий, кроме брандмауэра ISA. Однако существует значительная синергия между развертыванием брандмауэра ISA и IIS, поскольку многие веб-серверы IIS публикуют веб-сайты за брандмауэром.

Winfrasoft X-Forwarded-For для брандмауэров ISA позволяет администраторам брандмауэра ISA отслеживать и регистрировать веб-трафик HTTP и HTTPS из исходного источника через несколько прямых и обратных прокси-серверов и анализировать информацию с помощью ведения журнала ISA Server. Этот продукт предоставляет брандмауэру 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) и обычными подозреваемыми, перечисленными выше.

Winfrasoft X-Forwarded-For для ISA Server

Установка — это простой процесс, который требует ограниченного участия пользователя, поэтому я не буду вдаваться в подробности этой операции. После установки X-Forwarded-For для ISA Server появляется в разделе Web Filters узла Add-ins на левой панели консоли брандмауэра ISA. Через консоль брандмауэра ISA можно включить или отключить веб-фильтр, а также перемещать его вверх и вниз по списку приоритетов.

Рисунок 1: Раздел Web Filters в узле Add-ins на левой панели консоли брандмауэра ISA.

Как только X-Forwarded-For для ISA Server установлен на всех брандмауэрах ISA в вашей цепочке веб-прокси, происходит волшебство. Когда клиентский запрос проходит через вашу цепочку веб-прокси, HTTP-заголовок X-Forwarded-For добавляется (если поле XFF не существует) или модифицируется (если XFF существует), а брандмауэр ISA включает реальный IP-адрес клиента в заголовок X. -Forwarded-For заголовок HTTP.

Чтобы протестировать X-Forwarded-For для ISA в Forward Proxy, я настроил следующую инфраструктуру в своей тестовой среде.

Рисунок 2: Лабораторная установка для прямого прокси-теста

Рисунок 3: Ведение журнала ISA — веб-прокси (вперед)

Это журнал с сервера Upstream Proxy (192.168.0.254), показывающий HTTP-запрос к лучшему в мире веб-сайту:-). IP-адрес исходного клиента можно увидеть в поле Источник. В разделе Информация о фильтре было создано поле заголовка HTTP X-Forwarded-For и записаны IP-адреса веб-прокси-серверов, обработавших запрос.

Существует потенциальная проблема с безопасностью, поскольку HTTP-пакет, отправляемый в Интернет, может содержать список ваших внутренних IP-адресов, однако поведение по умолчанию X-Forwarded-For для ISA Server заключается в удалении данных поля X-Forwarded-For. когда пакет покидает последний веб-прокси в цепочке веб-прокси, как это делает вышестоящий прокси в этом сценарии. Это можно проверить с помощью сетевого анализатора, такого как NetMon 3.2 (Microsoft Network Monitor 3.2).

Если у вас есть прозрачный восходящий анализатор пакетов, то поведение X-Forwarded-For для ISA Server можно настроить так, чтобы информация X-Forwarded-For оставалась в HTTP-пакете, поскольку он покидает последний веб-прокси-сервер в веб-цепочке. Очевидно, я бы порекомендовал это только в том случае, если сниффер восходящего потока имеет возможность удалить заголовок X-Forwarded-For до того, как запрос попадет в Интернет.

Чтобы протестировать X-Forwarded-For для ISA в обратном прокси-сервере, я настроил следующую инфраструктуру в своей тестовой среде.

Рисунок 4: Ведение журнала ISA в сценарии с обратным веб-прокси

Рисунок 5: Регистрация информации в сценарии с обратным веб-прокси

Это журнал с сервера Downstream2 Proxy (192.168.0.200), показывающий HTTP-запрос от интернет-клиента к веб-странице, опубликованной в IIS, которая находится за моей цепочкой обратного веб-прокси. IP-адрес исходного клиента можно увидеть в поле Источник. В разделе Информация о фильтре было создано поле заголовка HTTP X-Forwarded-For и записаны IP-адреса веб-прокси-серверов, обработавших запрос.

В отличие от сценария прямого прокси-сервера, поскольку HTTP-запрос остается внутри, нет проблем с безопасностью при сохранении внутренних адресов в заголовке HTTP-пакета, поэтому последний веб-прокси-сервер не удаляет поле X-Forwarded-For.

Это также хорошо, потому что если у вас есть веб-сервер Apache (черт возьми!), настроенный за вашей цепочкой веб-прокси, то журналы могут быть проверены на этом сервере и определен маршрут для запроса. Это плавно подводит меня ко второму продукту пакета Winfrasoft X-Forwarded-For, X-Forwarded-For для IIS.

Winfrasoft X-Forwarded-For для IIS

Как и в случае с X-Forwarded-For для ISA Server, процесс установки очень прост, и, опять же, требуемый пользовательский ввод очень ограничен. X-Forwarded-For для IIS — это фильтр ISAPI, который после установки внедряется на страницу свойств фильтров ISAPI для всех веб-сайтов на вашем сервере IIS.

Рис. 6. Диалоговое окно «Свойства веб-сайтов»

Ниже показана моя лабораторная среда, используемая для тестирования X-Forwarded-For для IIS. В приведенных ниже примерах с моего клиентского ПК (192.168.10.76) я запрашиваю веб-страницу, размещенную на моем веб-сервере IIS (192.168.0.1). Мой сервер IIS — это IIS версии 6.0, работающий на сервере Windows 2003, но для всех первых пользователей X-Forwarded-For для IIS также поддерживает IIS 7.0 в Windows 2008.

Рис. 7. Сценарий 1. Интернет-информационный сервер без X-Forwarded-For для IIS

Как упоминалось ранее, Internet Information Server изначально не поддерживает X-Forwarded-For, поэтому изучение журналов стандартной установки IIS покажет, что все запросы исходили от Downstream2 (192.168.0.200).

Это запись журнала в формате W3C с веб-сервера (192.168.0.1). В поле c-ip хранится исходный IP-адрес клиента.

#Программное обеспечение: Microsoft Internet Information Services 6.0
#Версия: 1.0
#Дата: 2008-09-09 16:37:24
#Поля: дата и время 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+ (совместимый;+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.

Список надежных IP-адресов

Как упоминалось выше, X-Forwarded-For для IIS можно настроить для отображения первого недоверенного IP-адреса. Чтобы понять эту концепцию, нам нужно установить различия между доверенными и недоверенными IP-адресами. В моей тестовой среде я знаю IP-адреса всех своих прокси-серверов, поэтому это доверенные адреса, которые я добавлю в список доверенных. Мой список доверия в этом примере будет таким:

TrustList = 192.168.0.254, 192.168.0.200, 192.168.0.100

Любой IP-адрес, не найденный в моем списке доверенных лиц, будет рассматриваться как недоверенный IP-адрес.

Списки доверия смягчают проблемы безопасности, возникающие при использовании прокси-серверов, поддерживающих заголовки X-Forwarded-For. Прокси-серверы, которые поддерживают X-Forwarded-For, просто добавляют IP-адрес, с которого они получают запрос, к заголовку и пересылают его. Поскольку в этом поле нет подписи данных, любой IP-адрес может быть подменен в заголовок. Это может сделать недействительными любые отчеты, созданные на основе заголовков X-Forwarded-For.

Когда фильтр IIS обрабатывает заголовок X-Forwarded-For, он проверяет IP-адрес первого прокси-сервера на основе его адреса уровня 4. Если ему доверяют, процесс проверки продолжается с IP-адресами, перечисленными в заголовке X-Forwarded-For, пока не будет найден первый ненадежный IP-адрес. Затем он используется в качестве c-ip в журнале веб-сервера, поскольку это был первый интернет-маршрутизируемый адрес, который вошел в цепочку доверенных прокси-серверов, а это означает, что любые поддельные IP-адреса, перечисленные ранее, отбрасываются.

Сценарий 2 — Использование XFF со списком доверия

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-адрес клиента.

#Программное обеспечение: Microsoft Internet Information Services 6.0
#Версия: 1.0
#Дата: 2008-09-09 16:44:12
#Поля: дата и время 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+ (совместимый;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET +CLR+2.0.50727) 200 0 0

Из этого эксперимента видно, что первый ненадежный IP-адрес клиента регистрируется как исходный IP-адрес клиента.

Сценарий 3. Использование XFF без настроенного списка доверия

X-Forwarded-для: 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.

#Программное обеспечение: Microsoft Internet Information Services 6.0
#Версия: 1.0
#Дата: 2008-09-09 16:46:54
#Поля: дата и время 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+(совместимо;+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 также позволяют собирать необходимые данные, критически важные для ваших стратегий аудита и соответствия требованиям.