Протокол автоматического обнаружения веб-прокси

Протокол автоматического обнаружения веб-прокси (WPAD) — это метод, используемый клиентами для определения URL-адреса файла конфигурации с использованием методов обнаружения DHCP и/или DNS . После завершения обнаружения и загрузки файла конфигурации его можно выполнить для определения прокси-сервера для указанного URL-адреса.

История

Протокол WPAD лишь описывает механизм определения местоположения этого файла, но наиболее часто используемым форматом файла конфигурации является формат автоматической настройки прокси-сервера, первоначально разработанный Netscape в 1996 году для Netscape Navigator 2.0 . ^{[ 1 ]} Протокол WPAD был разработан консорциумом компаний, включающим Inktomi Corporation , Microsoft Corporation , RealNetworks, Inc. и Sun Microsystems, Inc. (теперь Oracle Corp. ). WPAD задокументирован в ИНТЕРНЕТ-ПРОЕКТЕ, срок действия которого истек в декабре 1999 года. ^{[ 2 ]} Однако WPAD по-прежнему поддерживается всеми основными браузерами. ^{[ 3 ]}^{[ 4 ]} WPAD впервые был включен в Internet Explorer 5.0 .

Контекст

Чтобы всем браузерам в организации была предоставлена одна и та же политика прокси-сервера без настройки каждого браузера вручную, необходимы обе следующие технологии:

Стандарт автоматической настройки прокси-сервера (PAC): создайте и опубликуйте один центральный файл конфигурации прокси-сервера. Подробности обсуждаются в отдельной статье.
Стандарт протокола автоматического обнаружения веб-прокси (WPAD): убедитесь, что браузеры организации найдут этот файл без ручной настройки. Это тема данной статьи.

Стандарт WPAD определяет два альтернативных метода, которые системный администратор может использовать для публикации местоположения файла конфигурации прокси-сервера, используя протокол динамической конфигурации хоста (DHCP) или систему доменных имен (DNS):

Прежде чем получить свою первую страницу, веб-браузер, реализующий этот метод, отправляет запрос DHCPINFORM на локальный DHCP-сервер и использует URL-адрес из параметра WPAD в ответе сервера. Если DHCP-сервер не предоставляет нужную информацию, используется DNS. Если, например, сетевое имя компьютера пользователя — pc.department.branch.example.com , браузер будет по очереди пробовать следующие URL-адреса, пока не найдет файл конфигурации прокси-сервера в домене клиента:

http://wpad.department.branch.example.com/wpad.dat
http://wpad.branch.example.com/wpad.dat
http://wpad.example.com/wpad.dat
http://wpad.com/wpad.dat (в неправильных реализациях см. примечание в разделе «Безопасность» ниже)

(Примечание. Это примеры, а не «действующие» URL-адреса, поскольку в них используется зарезервированное доменное имя « example.com ».)

Кроме того, в Windows, если запрос DNS не удался, разрешение многоадресных имен локального канала (LLMNR) и/или NetBIOS . будет использоваться ^{[ 5 ]}^{[ 6 ]}

Примечания

DHCP имеет более высокий приоритет, чем DNS: если DHCP предоставляет URL-адрес WPAD, поиск DNS не выполняется. Это работает только с DHCPv4. В DHCPv6 опция WPAD не определена.

При создании пакета запроса поиск DNS удаляет первую часть имени домена (имя хоста клиента) и заменяет ее на wpad . Затем он «перемещается вверх» по иерархии, удаляя дополнительные части доменного имени, пока не найдет файл WPAD PAC или не покинет текущую организацию.

Браузер догадывается, где проходят границы организации. Это предположение часто верно для таких доменов, как «company.com» или «university.edu», но неверно для «company.co.uk» (см. безопасность ниже).

Для поиска DNS путь к файлу конфигурации всегда — wpad.dat . Для протокола DHCP можно использовать любой URL-адрес. По традиционным причинам файлы PAC часто называются proxy.pac (конечно, файлы с таким именем будут игнорироваться DNS-поиском WPAD).

MIME -тип файла конфигурации должен быть «application/x-ns-proxy-autoconfig». см . в разделе «Автонастройка прокси» Дополнительную информацию .

Internet Explorer и Konqueror в настоящее время являются единственными браузерами, поддерживающими методы DHCP и DNS; метод DNS поддерживается большинством основных браузеров. ^{[ 7 ]}

Требования

Для работы WPAD необходимо выполнить несколько требований:

Чтобы использовать DHCP, сервер должен быть настроен для обслуживания опции 252 «local site» («auto-proxy-config») со строковым значением, например, http://example.com/wpad.dat, где « example.com» — адрес веб-сервера.
Чтобы использовать метод только DNS, необходима запись DNS для хоста с именем WPAD.
Хост по адресу WPAD должен иметь возможность обслуживать веб-страницу .
В обоих случаях веб-сервер должен быть настроен для обслуживания файла WPAD с типом MIME : application/x-ns-proxy-autoconfig.
Если используется метод DNS, файл с именем wpad.dat веб-сайта WPAD должен находиться в корневом каталоге .
Файлы PAC обсуждаются в статье об автоматической настройке прокси-сервера .
Будьте осторожны при настройке сервера WPAD в среде виртуального хостинга . При использовании автоматического обнаружения прокси-сервера WinHTTP и WinINET в Internet Explorer 6 и более ранних версиях отправляют заголовок «Host: <IP-адрес>», а IE7+ и Firefox отправляют заголовок «Host: wpad». Поэтому рекомендуется размещать файл wpad.dat на виртуальном хосте по умолчанию, а не на собственном.
Internet Explorer версии 6.0.2900.2180.xpsp_sp2_rtm запрашивает с веб-сервера «wpad.da» вместо «wpad.dat».
Если в качестве DNS-сервера используется Windows Server 2003 (или более поздней версии), глобальный черный список запросов DNS-сервера или изменить реестр для редактирования списка заблокированных запросов. возможно, придется отключить ^{[ 8 ]}^{[ 9 ]}

Безопасность

Несмотря на то, что протокол WPAD значительно упрощает настройку веб-браузеров одной организации, его следует использовать с осторожностью: простые ошибки могут открыть злоумышленникам возможность изменить то, что отображается в браузере пользователя:

Злоумышленник внутри сети может настроить DHCP-сервер, который передает URL-адрес вредоносного сценария PAC.
Если сеть — «company.co.uk», а файл http://wpad.company.co.uk/wpad.dat не обслуживается, браузеры продолжат запрашивать http://wpad.co.uk. /wpad.dat. До введения списка общедоступных суффиксов в 2010-х годах некоторые браузеры не могли определить, что wpad.co.uk больше не принадлежит организации.
Тот же метод использовался с http://wpad.org.uk. Раньше он служил файлу wpad.dat, который перенаправлял весь трафик пользователя на сайт интернет-аукциона.
Интернет-провайдеры, реализовавшие перехват DNS, могут нарушить поиск DNS протокола WPAD, перенаправив пользователей на хост, который не является прокси-сервером.
Утечка запросов WPAD может привести к конфликтам доменных имен со схемами именования внутренней сети. Если злоумышленник зарегистрирует домен для ответа на просочившиеся запросы WPAD и настроит действительный прокси-сервер, существует вероятность проведения атак «человек посередине» (MitM) через Интернет. ^{[ 10 ]}

С помощью файла WPAD злоумышленник может указать браузерам пользователей их собственные прокси-серверы, а также перехватить и изменить WWW-трафик всех, кто подключен к сети. Хотя в 2005 году было применено упрощенное исправление для обработки WPAD в Windows, оно устранило проблему только для домена .com. Презентация на Kiwicon показала, что остальной мир по-прежнему критически уязвим для этой дыры в безопасности: образец домена, зарегистрированный в Новой Зеландии в целях тестирования, получает прокси-запросы со всей страны со скоростью несколько раз в секунду. Некоторые доменные имена wpad.tld (включая COM, NET, ORG и US) теперь указывают на адрес обратной связи клиента, чтобы защититься от этой уязвимости, хотя некоторые имена все еще зарегистрированы (wpad.co.uk).

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

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

Ссылки

^ «Формат файла автоматической настройки прокси-сервера Navigator» . Netscape Navigator Документация . Март 1996 г. Архивировано из оригинала 7 марта 2007 г. Проверено 10 февраля 2015 г.
^ Готье, Поль; Джош Коэн; Мартин Дансмюр; Чарльз Перкинс (28 июля 1999 г.). «Протокол автоматического обнаружения веб-прокси (ИНТЕРНЕТ-ПРОЕКТ)» . IETF . Проверено 10 февраля 2015 г.
^ «Chromium #18575: Платформы, отличные от Windows: WPAD (автоопределение прокси-сервера) не проверяет DHCP» . 05.08.2009 . Проверено 10 февраля 2015 г.
^ «Firefox #356831 — Автообнаружение прокси-сервера не проверяет DHCP (опция 252)» . 16 октября 2006 г. Проверено 10 февраля 2015 г.
^ «Устранение неполадок автоматического обнаружения веб-прокси (WPAD)» . Программное обеспечение GFI. Архивировано из оригинала 14 апреля 2021 г. Проверено 10 февраля 2015 г.
^ Хельмвик, Эрик (17 июля 2012 г.). «Человек WPAD посередине» . Проверено 10 февраля 2015 г.
^ «Konqueror: автоматическое обнаружение прокси» . КДЕ . 20 мая 2013 г. Архивировано из оригинала 11 февраля 2015 г. Проверено 10 февраля 2015 г.
^ Кинг, Майкл (17 февраля 2010 г.). «WPAD не разрешается в DNS» . Проверено 10 февраля 2015 г.
^ «Удаление WPAD из черного списка DNS» . Microsoft TechNet . 26 сентября 2008 года . Проверено 10 февраля 2015 г.
^ «Оповещение (TA16-144A) об уязвимости WPAD, связанной с конфликтом имен» . США-СЕРТ . 06.10.2016 . Проверено 2 мая 2017 г.

Дальнейшее чтение

де Бойн Поллард, Джонатан (2004). «Автоматическая настройка прокси-сервера HTTP в веб-браузерах» . Часто встречающиеся ответы .

Джим Гроувс (ноябрь 2007 г.). «Глобальный черный список запросов DNS-сервера» . Майкрософт .

«Примеры файлов PAC и WPAD» . 18 сентября 2015 г.

[1] «Формат файла автоматической настройки прокси-сервера Navigator» . Netscape Navigator Документация . Март 1996 г. Архивировано из оригинала 7 марта 2007 г. Проверено 10 февраля 2015 г.

[2] Готье, Поль; Джош Коэн; Мартин Дансмюр; Чарльз Перкинс (28 июля 1999 г.). «Протокол автоматического обнаружения веб-прокси (ИНТЕРНЕТ-ПРОЕКТ)» . IETF . Проверено 10 февраля 2015 г.

[chrome-3] «Chromium #18575: Платформы, отличные от Windows: WPAD (автоопределение прокси-сервера) не проверяет DHCP» . 05.08.2009 . Проверено 10 февраля 2015 г.

[firefox-4] «Firefox #356831 — Автообнаружение прокси-сервера не проверяет DHCP (опция 252)» . 16 октября 2006 г. Проверено 10 февраля 2015 г.

[5] «Устранение неполадок автоматического обнаружения веб-прокси (WPAD)» . Программное обеспечение GFI. Архивировано из оригинала 14 апреля 2021 г. Проверено 10 февраля 2015 г.

[6] Хельмвик, Эрик (17 июля 2012 г.). «Человек WPAD посередине» . Проверено 10 февраля 2015 г.

[7] «Konqueror: автоматическое обнаружение прокси» . КДЕ . 20 мая 2013 г. Архивировано из оригинала 11 февраля 2015 г. Проверено 10 февраля 2015 г.

[8] Кинг, Майкл (17 февраля 2010 г.). «WPAD не разрешается в DNS» . Проверено 10 февраля 2015 г.

[9] «Удаление WPAD из черного списка DNS» . Microsoft TechNet . 26 сентября 2008 года . Проверено 10 февраля 2015 г.

[10] «Оповещение (TA16-144A) об уязвимости WPAD, связанной с конфликтом имен» . США-СЕРТ . 06.10.2016 . Проверено 2 мая 2017 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]