X-Forwarded-For и брандмауэр ISA Firewall: отслеживайте своих клиентов с помощью цепи Web-proxy Chain и на своем IIS

Когда был выпущен брандмауэр 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.

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

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

Winfrasoft X-Forwarded-For для сервера ISA Server

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

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS
Прирастить

Набросок 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, я настроил последующую инфраструктуру в собственной испытательной среде.

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS

Набросок 2: Тестовая среда для тестирования прокси ретрансляции

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS
Прирастить

Набросок 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, я настроил последующую инфраструктуру в собственной испытательной лаборатории.

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS

Набросок 4: Ведение логов ISA в случае использования обратимого интернет прокси (Web Proxy)

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS

Набросок 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.

Winfrasoft X-Forwarded-For для IIS

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

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном 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.

X-Forwarded-For и брандмауэр ISA Firewall: выслеживайте собственных клиентов при помощи цепи Web-proxy Chain и на собственном IIS

Набросок 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 Мозилла/
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.

Перечень доверенных IP адресов

Как я уже гласил, 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 адресок первого прокси сервера на базе адреса 4-ого уровня. Если адресок доверенный, процесс верификации длится с IP адресами, перечисленными в X-Forwarded-For заголовке до того времени, пока не будет найден 1-ый ненадежный IP адресок. Потом он употребляется в качестве c-ip в логе интернет сервера, так как это был 1-ый маршрутизируемый адресок веба, попавший в интернет прокси цепь – а это значит, что любые неверные IP адреса, перечисленные ранее, воспрещаются.

Сценарий 2 – Внедрение XFF со перечнем доверия (Trust List)

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 Мозилла/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+2.0.50727) 200 0 0

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

Сценарий 3 – Внедрение XFF без настроенных списков доверия

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 Мозилла/
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 также позволяет вам собирать все нужные данные, которые являются критичными для ваших стратегий аудита и сопоставимости.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.