Прокси-сервер (известный также как шлюз приложений) представляет собой приложение, которое выступает для трафика в качестве посредника между доверенной сетью и недоверенной сетью. Это не снимает необходимости применения брандмауэра для управления трафиком на IP-уровне, чтобы не предусматривать наличие брандмауэра прикладного уровня.
Слово "proxy", как и множество других ставших популярными компьютерными терминами английских слов, возможно, утратило для некоторых из нас свое оригинальное значение. Согласно словарю, proxy – это кто-то (или что-то), уполномоченный действовать от лица его клиента и "доставляющий" клиенту определенные предметы.
Вы можете представить себе посредника как доверенное лицо или посла, которым предписано находиться где-то, где не может непосредственно находиться их клиент (или предпочитает не находиться) по причинам неудобства или безопасности. Послы обычно знают местный язык и обычаи, могут привести несовершенный запрос клиента в форму, допустимую в местном масштабе другой зоны, и, конечно, могут перевести обратно полученный ответ. В компьютерных понятиях такой "посол" может получать https-запросы по порту 443 и преобразовывать их в http-запросы по порту 80.
Прокси в более повседневных, практических компьютерных терминах являются процессами, запущенными на компьютерах, которым, как правило, предоставлен доступ (в брандмауэре) к более чем одной зоне. Именно эта способность делает их полезными. В типичном случае прокси просто будет работать от имени своего пользователя на месте перекрытия зон (в образе приложения), выполняя и получая нечто из зоны, с которой при других обстоятельствах запрещено устанавливать контакт или запрашивать что-либо со стороны отдельных процессов и пользователей из другой зоны.
С другой стороны, на прокси можно посмотреть с точки зрения "человека посередине". Как мы видели в предыдущих лекциях, одной из фундаментальных концепций всеобщей безопасности (не только в криптографии) является концепция атаки со стороны "(плохого) человека посередине", которая заключается в перехвате и ретрансляции передаваемой между двумя сторонами информации третьей, незваной, "плохой" стороной.
Прокси могут восприниматься как "хорошие" приемники (слушатели) информации или как "люди посередине". Это значит, что они перехватывают информацию, ретранслируют ее далее, но с некоторой предопределенной и полезной для сетевой инфраструктуры целью.
Как правило, компьютерный прокси является базовым bind ), ожидая запросов по определенному протоколу. Когда установлено соединение с клиентом и получен правильный запрос, он "повторит" этот запрос другому серверу от имени клиента, как определено в его правилах для этого типа запросов. Когда от сервера получен ответ, прокси передает этот ответ назад пользователю или процессу клиента, которые ранее осуществили запрос, применяя все необходимые преобразования.
Если смотреть на вещи упрощенно, прокси на самом деле существуют во множестве различных продуктов. К примеру, большинство технологий порталов, которые сегодня легкодоступны, запрашивают контент от лица пользователя и компонуют его в отдельный "вид портала". Другим примером прокси являются "транзитные пересылки" Notes, которые существовали в Lotus Notes определенное количество лет и разрешали удаленный доступ в среды Notes на протяжении всех ранних лет развития Интернета. Тем не менее далее в этом разделе мы сосредоточим внимание на прокси в виде отдельных продуктов, так как наиболее часто используемым сегодня передовым опытом является применение отдельных прокси-сервисов.
В этом разделе определены существующие на рынке различные типы прокси, применяемые в обычных инфраструктурах. Как было установлено ранее, зачастую предоставленное для прокси оборудование будет на самом деле выполнять или поддерживать множество типов прокси-сервисов. К примеру, прокси-сервер может предоставлять возможности
Ключевыми типами прокси, которые мы определяем и рассматриваем в этом разделе, являются:
Пересылающий прокси является прокси-сервером, который помогает пользователям из одной зоны безопасности выполнять запросы контента из "следующей" зоны, следуя направлению, которое обычно (но не обязательно) является исходящим (это значит, что клиент находится внутри, а сервер где-то в открытом Интернете).
С точки зрения безопасности простой прокси имеет целью обеспечение безопасности, состоящее в скрытии наименования (в терминах топологии внутренней сети) рабочей станции или процесса запрашивающего пользователя. Он может также применяться для скрытия некоторых других атрибутов сеанса пользователя.
Типичным примером этого типа являются корпоративные прокси, которые обслуживают внутренних пользователей посредством разрешения им доступа на внешние сайты для Web-браузинга или любого другого вида взаимодействия с Интернетом.
С точки зрения топологии (как в общем смысле, так и относительно ширины полосы пропускания) пересылающие прокси всегда относительно ограничены в терминах сетевой скорости по отношению к своим пользователям из-за более медленного WAN-соединения (соединения с глобальной сетью), которое обычно отделяет пересылающий прокси от реального контента в Интернете.
Прозрачные прокси являются прокси-серверами, которые "находятся здесь", но не осведомляют пользователей в прямой форме о том, что они здесь находятся. В пересылающих прокси обычно существуют Linux/UNIX блоки, которые слушают весь трафик по определенному протоколу для определенного сегмента сети и перехватывают трафик, хотя пользовательский процесс в действительности не знает об их существовании. Фактически пользовательский процесс не общается с прокси, но общается с другим (конечным) сайтом, а прокси, в сущности, становится тем "человеком посередине", который "взламывает" соединение.
Прокси является непрозрачным, или объявленным, когда пользователи знают о том, что они общаются через прокси, потому что они обращаются (на языке прокси: HTTP) к прокси. Другими словами, если я объявил свой прокси как proxy.mydomain.com, то после этого мои процессы будут общаться с proxy.mydomain.com, запрашивая его об установлении контакта с конечным адресом назначения моих запросов. Я полностью осведомлен о существовании прокси, о необходимости общаться с ним на "языке прокси" (HTTP), и о необходимости передать ему куда "идти" и откуда "принести" необходимый контент.
Вы можете иметь объявленные, непрозрачные прокси, которые автоматически объявлены, сконфигурированы или обнаружены. Вне зависимости от того как они были объявлены, эти прокси являются видимыми и известными для запрашивающего пользователя или процесса. Другими словами, неважно, как вы или ваш процесс узнали о существовании прокси, каковы причины того, что вы узнали о существовании прокси и о том, что вы общаетесь с прокси.
Прозрачные прокси сами по себе не являются на самом деле типом прокси, скорее любой прокси является либо прозрачным, либо объявленным по проекту.
Кеширующие прокси, как указано в их названии, являются прокси-серверами, которые сконфигурированы на повторное использование
Наиболее важным аспектом для кеширующих прокси является необходимость обеспечения того, что кеширующие прокси кешируют только то, что на самом деле можно кешировать. Динамический, регулярно изменяющийся контент не лучший выбор для
В большинстве случаев пересылающие прокси конфигурируются также для работы в качестве кеширующих прокси. Это явление используется настолько часто, что компания IBM включила это в название компонента своего Edge Server: IBM Caching Proxy. На рис. 5.1 отображен типичный пересылающий и кеширующий прокси-сервер.
(рис 5.1) Кеширующий прокси, работающий как пересылающий прокси
В качестве высшего проявления необходимой для простых прокси функциональности прокси-серверы могут быть сконфигурированы для приведения в исполнение политик безопасности. Такие прокси обеспечения безопасности могут обрабатывать (либо выступать в качестве посредников при обработке) запросы аутентификации и авторизации. В этих случаях аутентификация пользователя клиента и авторизация клиента для доступа к определенному контенту контролируется самим прокси-сервером. Далее мандат безопасности посылается от прокси к конечным серверам с запросом, а конечный сервер должен быть сконфигурирован на оказание доверия предоставляемому прокси
Существует много различных продуктов и предложений, а также множество топологий на выбор, но с точки зрения выполнения прокси-функций безопасность является дополнительной функцией, которую может выполнять прокси.
В большинстве случаев функциональные возможности по обеспечению безопасности могут быть добавлены стандартному прокси в виде дополнительного программного модуля [plug-in (плагин)] (к примеру, IBM Tivoli WebSeal Plug-In для IBM WebSphere Edge Server). Существуют также и отдельные продукты, такие, как IBM Tivoli
Немного дополнительной информации о таких прокси обеспечения безопасности вы найдете в разделе 4.1.6, "Системы управления подлинностью и управления доступом на предприятии".
Ранее в этой лекции мы установили, что разделение на зоны безопасности является ключевой концепцией при развертывании безопасной топологии. В этом контексте единственным, что позволяет делать обратный прокси, является обеспечение контролируемым и безопасным образом видимости находящегося позади прокси (как правило, во внутренней зоне) более чувствительного контента, без наличия реального необработанного контента, баз данных и т. д., показываемых во внешней зоне.
Обратные прокси имеют много общего кода с пересылающими прокси: фактически одни и те же продукты могут быть сконфигурированы одним или другим образом либо двумя сразу! Однако с функциональной и практической точки зрения в нашем случае мы рассматриваем обратные прокси как полностью другой инструмент.
Обратные прокси прозрачны, отчасти по определению. За обратным прокси пользователь вообще не знает о своем общении с прокси-сервером. Пользователь полагает, что общается с реальным предметом – сервером, на котором находится контент.
Пользователь не только будет думать о том, что он общается с сервером, на котором находится контент, но и может взаимодействовать и проходить аутентификацию на обратном прокси и быть субъектом по отношению к его политикам.
Обратные прокси обычно избраны и реализованы в целях обеспечения изоляции контента и зон. Однако, вы можете также добавить в обратные прокси функциональные возможности по кешированию для обеспечения производительности заодно с преимуществами обеспечения безопасности.
(рис 5.2) Типичный обратный проксиОбратите внимание, что при этом виде сценария выигрыш в производительности за счет
Однако когда на обратном прокси разрешено
Серверы безопасности – обратные прокси [
Зачастую такие продукты RPSS будут иметь в обратном прокси встраиваемый компонент, обрабатывающий запросы управления доступом и авторизации и объединенный с конечной системой управления доступом предприятия, которая фактически проверяет права пользователя или клиента на доступ и авторизацию. Этот встраиваемый компонент иногда называют лезвием (
Большинство технологий на основе Lotus Domino поддерживали сценарии применения обратных прокси на протяжении многих лет. В настоящее время в качестве исключения поддержку обратных прокси получил только продукт Lotus Sametime. Более подробно он описан в следующем разделе.
Последующие требования обратных прокси к Domino должны быть рассмотрены для традиционных технологий на основе Lotus Domino (Notes/Domino, iNotes, QuickPlace и т. д.).
Первым для
Кроме того, основными кешируемыми элементами, которые будут кешироваться обратными прокси с возможностями
?OpenImageResource ?OpenElementFieldElemFormat = gif URL
В IBM WebSphere Edge Server это выполняется посредством параметров настройки фактора последнего модифицирования ("Last Modified Factor").
Поддержка методов HTTP (HTTP Methods) большинством прокси-серверов позволяет вам определить типы запросов, обслуживаемые прокси-сервером. Существует несколько типов, которые включаются по умолчанию в большинстве прокси, но единственными необходимыми Domino для функционирования являются GET, HEAD и POST. Другие являются необязательными и могут представлять собой риск для безопасности.
Существует возможность сконфигурировать правило прокси для типа реализации "передача всего", который будет поддерживать технологии на основе Domino. Фактически это может быть параметром по умолчанию для множества прокси-серверов.
requests for /* go to http://xxx.xxx.xxx.xxx/*
В этом случае правило определяет, что если запросу не соответствует никакое из правил набора по умолчанию, то прокси пересылает запрос запрашиваемому серверу вне зависимости от того, что было на сервере запрошено.
Несмотря на то что подобный шаг может быть достаточно простым, он является рискованным, так как разрешает прямой доступ к какому-либо ресурсу на сервере Domino, доступному посредством HTTP.
В качестве альтернативы для ограничения доступа только до уровня необходимой функциональности может быть определен специфический набор правил. К примеру, правила для обычной инфраструктуры Domino, использующей iNotes, будут выглядеть следующим образом:
requests for /mail* go to http://xxx.xxx.xxx.xxx/mail* requests for /iNotes* go to http://xxx.xxx.xxx.xxx/iNotes* requests for /inotes5* go to http://xxx.xxx.xxx.xxx/inotes5* requests for /icons* go to http://xxx.xxx.xxx.xxx/icons* requests for /domjava* go to http://xxx.xxx.xxx.xxx/domjava* requests for /names.nsf go to http://xxx.xxx.xxx.xxx/names.nsf
При таких правилах обслуживается только контент в подкаталогах /mail*. Правила определены таким образом, что если сайт имеет множество почтовых подкаталогов (к примеру, /mail[1-3] ), то они включены. Если вы хотите ограничить доступ только к подмножеству из почтовых баз данных, переместите их в специальную папку, такую, как /pubmail/*.
Другие правила разрешают доступ для поддержки контента, необходимого для предоставления конечному пользователю практики работы с iNotes Web Access. Еще одним важным правилом, которое необходимо рассмотреть, является правило /names., используемое для аутентификации. Оно разрешает доступ из Интернета к Domino Directory, но не к контенту, который находится вне списка каталогов по умолчанию.
Результат построения URL-адресов со стороны Domino выглядит так. Когда пользователь посредством аутентификации сеанса входит в Domino, экран входа в систему по умолчанию отправляет запрос к /names.. Прокси-сервер согласовывает этот запрос и передает его Domino. Если, к примеру, пользователь пытается открыть вид групп (Groups) с помощью запросов /names. или /names. , то как запрос Domino, так и запрос прокси-сервера потерпят неудачу, потому что они не соответствуют правилу. Пользователь получит сообщение об ошибке 403, гласящее о запрещении доступа.
Большинство прокси-серверов имеет также возможность принятия во внимание ограничителей URL, которые сообщают прокси-серверу, что данное значение должно трактоваться как часть основного URL для преобразования адресов. Ограничители URL (именуемые в IBM WebSphere Edge Server как параметр SignificantUrlTerminator) должны быть созданы для Domino, так как большинство URL-адресов Domino содержат символ "?" и соответственно трактуются прокси-сервером как URL-адреса запросов для возможного
Специфическими ограничителями URL, требуемыми для поддержки Domino, являются:
SignificantUrlTerminator ?OpenImageResource SignificantUrlTerminator ?OpenElement SignificantUrlTerminator /?OpenImageResource SignificantUrlTerminator /?OpenElement
Инструкция ReversePass (обратная пересылка) большинства прокси-серверов перехватывает стандартные перенаправляющие ответы 302 от Domino и переписывает их для нового места назначения. Это новое место назначения должно являться допустимым URL-именем с таким расчетом, что, когда конечный пользователь запросит обновленную страницу после перенаправления, она будет действительной:
ReversePass http://xxx.xxx.xxx.xxx/* http://proxy.formymailserver.web/*
Дополнительную информацию о конфигурировании Domino для использования за обратным прокси-сервером можно найти в статье с домена Lotus Developer Domain (LLD) "Конфигурирование Web-доступа к iNotes при использовании обратного прокси-сервера WebSphere Edge". Эта статья может быть найдена на сайте
В то время как другие технологии Lotus поддерживали использующие обратные прокси-серверы инфраструктуры самостоятельно, поддержка прокси в продукте Lotus
Более детальную информацию о поддержке обратных прокси в Sametime 3.1 можно найти в руководстве администратора Sametime 3.1 Administrators Guide, которое является частью документации на продукт. Данная документация доступна в домене Lotus Developer Domain по адресу:
Когда сервер Sametime 3.1 размещен во внутренней сети за обратным прокси-сервером, то обратный прокси-сервер работает как посредник между сервером Sametime и клиентами Sametime. Все данные Sametime, протекающие между сервером Sametime и его клиентами, проходят через обратный прокси-сервер.
Для выполнения своих целей в области безопасности обратный прокси-сервер обрабатывает проходящие через него данные. Обработка данных Sametime со стороны обратного прокси-сервера накладывает определенные требования и ограничения на использование обратных прокси-серверов вместе с сервером Sametime. Поэтому в данном случае поддерживаются только определенные типы прокси-серверов и могут быть разрешены только определенные типы свойств прокси.
В этом разделе перечислены требования, которым должен соответствовать обратный прокси-сервер для совместного использования с Sametime 3.1.
Совместно с Sametime могут быть использованы только те обратные прокси-серверы, которые поддерживают использование "идентификаторов схожести" (
http[s]://hostname:port/affinity-id/
В этом примере "hostname" представляет собой полное доменное имя машины ( " является псевдонимом внутреннего сервера, который защищен посредством обратного прокси-сервера. Точным примером URL такого формата является
http[s]://reverseproxy.ibm.com/st01/stcenter.nsf
В этом примере текстовая строка "st01" является идентификатором схожести ( id является псевдонимом определенного сервера Sametime (такого, как sametime.ibm.com), который защищен посредством обратного прокси-сервера. Родственный id используется обратным прокси-сервером для направления входящих запросов на определенный внутренний сервер Sametime.
Если вы разместили в вашей сетевой среде множество обратных прокси-серверов и ожидаете, что пользователи будут осуществлять доступ к вашим серверам Sametime через это множество обратных прокси-серверов, то к вашей среде возникают некоторые особые требования:
К примеру, если один из обратных прокси-серверов имеет имя reverseproxy.ibm.com, то и все другие обратные прокси-серверы должны иметь имя reverseproxy.ibm.com. Если обратные прокси-серверы имеют различные DNS-имена, то клиенты Sametime будут неспособны поддерживать связь с сервером Sametime, расположенным за обратными прокси-серверами. Для распределения соединений от Web-браузеров к множеству обратных прокси-серверов должно быть использовано устройство, управляющее распределением соединений (такое, как IBM WebSphere Edge Server).
Каждый обратный прокси-сервер должен использовать идентичные правила и конфигурации преобразования адресов для управления переводом URL-адресов, отправляемых Web-браузерами к обратному прокси-серверу, с целью обеспечения доступа к внутреннему серверу Sametime. Если перевод этих URL-адресов в URL-адреса внутренних серверов Sametime не происходит одинаковым образом на каждом из обратных прокси-серверов, клиенты Sametime будут неспособны поддерживать связь с сервером Sametime, расположенным за обратным прокси-сервером.
Обратные прокси-серверы, которые переписывают URL-адреса в целях аутентификации, не поддерживаются. Некоторые обратные прокси-серверы добавляют информацию об аутентификации и сеансе в конец внедренных в HTML URL-адресов, которые передаются через прокси назад к клиенту. Клиент будет включать эти добавленные данные в последующие запросы к обратному прокси-серверу.
Когда обратный прокси-сервер получает от клиента эти последующие запросы, он отделяет данные аутентификации и переписывает URL-адрес для выполнения внутренней маршрутизации запросов. Сервер Sametime не может работать за обратным прокси-сервером, который обрабатывает данные аутентификации подобным образом.
В связи с этим должны использоваться обратные прокси, которые применяют в информации аутентификации cookies. Кроме того, администратор должен указать значение максимально возможного времени ожидания для cookies аутентификации, сгенерированных обратным прокси-
Несмотря на то что Sametime 3.1 поддерживает среды с обратными прокси-серверами, в связи с этим существуют некоторые ограничения относительно стандартных функциональных возможностей Sametime.
Не все клиенты Sametime могут взаимодействовать с серверами Sametime через обратный прокси-сервер. Поддерживаются следующие клиенты:
Клиент Sametime Meeting Room и клиент Sametime Broadcast могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены следующие Web-браузеры и виртуальные Java-машины [
Клиент Sametime Connect для браузеров и приложения Sametime Links могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены браузеры Explorer 6 или Netscape 7, которые работают с Sun Microsystems JVM 1.4.1.
Клиент Sametime Connect для браузеров и приложения Sametime Links могут не функционировать соответствующим образом с другими виртуальными Java-машинами, включая предусмотренную для Internet Explorer собственную виртуальную машину Microsoft.
Ограничение. Sametime Connect для клиента рабочего стола (Microsoft Windows-версия Sametime Connect) не может использоваться с сервером Sametime, который размещен за обратным прокси-сервером.
Когда сервер Sametime расположен за обратным прокси-сервером, на его возможности накладываются следующие ограничения:
Для шифрования передаваемых между клиентами Sametime и обратным прокси-сервером данных может использоваться протокол защищенных сокетов [Secure Sockets Layer (SSL)]. Однако SSL не может использоваться для шифрования данных, передаваемых между серверами Sametime и обратным прокси-сервером. Соответственно соединение между обратным прокси и сервером Sametime должно быть безопасным.
Совет. Если для шифрования передаваемых между Web-браузерами и обратным прокси-сервером данных используется SSL, на сервере Sametime администратор должен осуществить конфигурацию преобразования адресов, необходимую для преобразования получаемых от Web-браузера данных HTTPS в требуемые сервером Sametime данные HTTP.
Когда SSL используется в среде обратного прокси с Sametime, многие из выполняемых Sametime функций будут запускаться в плагине Java Plug-in Web-браузера (клиент соединения, клиент совещаний и т. д.). Этот Java Plug-in должен распознавать используемые обратным прокси-сертификаты SSL, исходя из чего он сможет взаимодействовать через SSL.
Сертификатами, которые, возможно, потребуется распознавать Java Plug-in, являются следующие.
Когда обратный прокси-сервер сконфигурирован на поддержку SSL, во время подтверждения установления SSL-соединения ("рукопожатия" – handshake) он отправляет Web-браузеру сертификат SSL сервера. Используемый Web-браузером Java 1.4.1 Plug-in должен иметь доступ к сертификату подписчика (Signer certificate), который подписан тем же источником сертификации (Certificate Authority (CA)), что и высланный обратным прокси сертификат сервера.
По умолчанию Java Plug-in имеет доступ к нескольким различным сертификатам подписчика, которые могут быть использованы для этой цели. Для просмотра доступных модулю Java Plug-in 1.4.1 сертификатов подписчика используйте панель управления Java Plug-in следующим образом:
В целях успешного подтверждения связи ("обмена рукопожатиями") для установления SSL-соединения сертификат сервера, отправленный обратным прокси-сервером Web-браузеру клиента, должен быть подписан одним из источников сертификации (CA) из списка источников сертификации подписчика.
Если конфигурация обратного прокси-сервера требует аутентификации сертификата клиента, то этот сертификат для отдельного пользователя должен быть импортирован в панель управления Java Plug-in 1.4.1 на машине данного пользователя. Для импортирования сертификата клиента в хранилище ключей Java Plug-in вы можете использовать закладку Certificates (Сертификаты) панели управления Java Plug-in.
К примеру:
Когда сервер Sametime расположен за обратным прокси-сервером, администратор должен сконфигурировать на обратном прокси-сервере правила преобразования адресов.
Эти правила преобразования адресов позволяют прокси-серверу преобразовывать (или переписывать) URL-адреса, связанные с обратным прокси-сервером, в URL-адреса внутреннего сервера Sametime.
Когда пользователь соединяется с сервером Sametime через обратный прокси-сервер, то последний должен иметь в конфигурации "правила преобразования адресов" для поддержки перечисленных ниже действий, которые дадут возможность пользователям Sametime присутствовать на совещаниях и участвовать в сеансах чатов.
В этом разделе предусмотрены некоторые рекомендации на тему того, как на обратном прокси-сервере сконфигурировать правила преобразования адресов для выполнения преобразования (или переписывания) URL-адресов в случае совместной работы обратного прокси и Sametime.
Любой обратный прокси-сервер, который работает с сервером Sametime, должен поддерживать в URL-адресах идентификатор схожести (
К примеру, если входящим URL-адресом от Web-сервера является
http[s]://reverseproxy.ibm.com/st01/stcenter.nsf
то правила преобразования адресов обратного прокси-сервера преобразуют родственный id "st01" в сервер Sametime, именуемый "sametime.ibm.com", а родственный id обеспечивает переписывание обратным прокси-сервером входящего URL-адреса в адрес следующего вида:
http[s]://sametime.ibm.com/stcenter.nsf
Если вы имеете множество серверов Sametime, размещенных за обратным прокси-сервером, то каждый сервер Sametime должен иметь индивидуальный родственный id, к примеру:
http[s]://sametime2.ibm.com/* /st02/* http[s]://sametime1.ibm.com/* /st01/*
Для преобразования всех URL-адресов, связанных с пользовательским интерфейсом сервера Sametime, может быть применено единственное правило преобразования адресов.
Администратор может создать для обратного прокси-сервера единственное правило преобразования адресов для преобразования всех URL, связанных с интерфейсом сервера Sametime, посредством использования шаблонов. К примеру, администратор может создать правило преобразования, с помощью которого следующий URL-адрес от Web-браузера:
http[s]://reverseproxy.ibm.com/st01/*
будет преобразовываться в такой URL-адрес сервера Sametime:
http[s]://sametime.ibm.com/*
Единственное правило преобразования адресов, которое выполняет этот тип преобразования URL, должно разрешать пользователям доступ ко всем элементам пользовательского интерфейса Sametime через обратный прокси-сервер.
При создании правил преобразования URL-адресов с целью разрешения клиентам Java-апплетов Sametime работать в Web-браузере пользователя должна быть обеспечена поддержка соединения со службами
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами
Если входящими URL-адресами от Java-апплета являются
http[s]://proxy.ibm.com/st01/communityCBR/ http[s]://proxy.ibm.com/st01/CommunityCBR/
то правила преобразования адресов на обратном прокси должны преобразовать эти URL-адреса в следующий вид:
http://sametime.ibm.com:8082/communityCBR http://sametime.ibm.com:8082/CommunityCBR
Совет. Конфигурация преобразования адресов для соединений со службами "с" нижнего регистра, в других фрагментах Java-кода в "CommunityCBR" используется "С" верхнего регистра. Если прокси является чувствительным к регистру, это различие может препятствовать установлению соединений.
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами Meeting Services.
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/MeetingCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:8081/MeetingCBR
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/BroadcastCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:554/BroadcastCBR
Во время установки сервера Sametime администратор может на свой выбор разрешить или не разрешить HTTP-туннелирование по порту 80.
Если во время установки сервера Sametime администратор не разрешит HTTP-туннелирование по порту 80, то необходимо сконфигурировать отдельные правила преобразования адресов для каждой из трех служб Sametime (
Когда HTTP-туннелирование по порту 80 не разрешено, каждая служба Sametime слушает HTTP-соединения на различных портах и для каждой из служб должны быть установлены отдельные правила преобразования адресов. Правило преобразования адресов должно указывать порт, на котором каждая из служб прослушивает соединения.
Если во время установки сервера Sametime администратор разрешил HTTP-туннелирование по порту 80, клиенты Sametime соединяются со всеми службами по единственному порту.
При этой конфигурации единственное правило преобразования адресов, которое разрешает пользователям осуществлять навигацию по пользовательскому интерфейсу сервера Sametime, разрешит также клиентам Sametime устанавливать соединения с сервисами Sametime.
Когда разрешено HTTP-туннелирование по порту 80, мультиплексор служб
Когда сервер Sametime работает в однопортовом режиме (что означает разрешение HTTP-туннелирования по порту 80), правила преобразования адресов для соединений Java-апплетов более просты. Так как все соединения клиентов Java-апплетов Sametime происходят по одному и тому же порту, нет необходимости указывать в правилах преобразования адресов отдельные порты для каждой из служб.
При таком сценарии администратору необходимо только убедиться в том, что этот входящий URL-адрес от Java-апплетов Sametime:
http[s]://proxy.ibm.com/st01/*
посредством правил преобразования адресов на обратном прокси-сервере изменяется на следующий URL-адрес:
http://sametime.ibm.com/*
Совет. Когда сервер Sametime сконфигурирован на поддержку HTTP-туннелирования по порту 80, производительность сервера не является наиболее эффективной, так как нагрузка от соединений сосредоточена на мультиплексоре служб
Чтобы разрешить серверу Sametime 3.1 понимать и поддерживать запросы обратного прокси, администратор должен использовать на сервере Sametime инструмент Sametime Administration Tool для конфигурирования сервера Sametime на работу с обратным прокси-сервером.
Требуется HTTP-туннелирование, так как большинство обратных прокси будет поддерживать только протоколы HTTP.
Откройте раздел Configuration (Конфигурация) графического интерфейса пользователя Sametime Web Admin и щелкните мышью на Connectivity (Соединяемость). В нижней части экрана находится раздел "
Разрешите поддержку обратного прокси путем установки кнопки-флажка, после чего введите "имя соединения" (
Выбор параметра
Этот параметр разрешает применение в клиентах Sametime логики, которая позволяет им соединяться с сервером Sametime через обратный прокси-сервер. Данный параметр по умолчанию запрещен.
Совет. Разрешение этого параметра не требует, чтобы все пользователи вашей корпоративной интранет-сети осуществляли доступ к серверу Sametime через обратный прокси-сервер. Данное разрешение улучшает существующую в клиентах Sametime логику путем добавления к ней логики соединения с обратным прокси. Существующая логика остается и работает внутри клиентов. При такой схеме клиенты, которые не подключаются к серверу Sametime через обратный прокси-сервер, при соединении с сервером Sametime следуют стандартным процессам соединения клиентов Sametime.
Этот раздел содержит некоторые общие советы и подсказки по работе с обратными прокси, которые не являются специфичными по отношению к какой-либо технологии или продукту Lotus или IBM.
При использовании какого-либо обратного прокси необходимо рассматривать потенциальное воздействие на производительность системы. Даже при разрешенном
С примером воздействия на производительность со стороны обратного прокси по отношению к функции Domino Web Access (iNotes) можно ознакомиться в статье "Работа iNotes Web Access с обратными прокси и другими средствами обеспечения безопасности", доступной на Web-сайте Lotus Developer Domain по адресу
Если потенциальным объектом обслуживания запросов может быть более чем один сервер (в случае конфигурации обеспечения высокой доступности, перехвата отказов или распределения нагрузки) и если запросы включают динамический контент, вы должны убедиться в том, что для всех транзакций, проходящих для отдельного клиента за отдельный промежуток времени, используется один и тот же сервер.
Это явление называется схожестью клиентов (client
Идея проста: пока сервер доступен, вы обслуживаетесь одним и тем же сервером на протяжении всего вашего сеанса. Если этот сервер становится недоступным, для обхода отказа вы переключаетесь на другой сервер (gracefully transition).
При создании и построении новой инфраструктуры обратных прокси протестируйте все пути через эту инфраструктуру. Когда введено в действие большинство обратных прокси, то подразумевается, что через брандмауэр разрешено проходить только трафику, пропущенному через обратный прокси и что через обратный прокси разрешено проходить только трафику определенных типов.
В дополнение к проверке того, что все желаемые вами связи работают, убедитесь в том, что все другие связи не работают. Должно работать только то, что разрешено явно, все остальное не должно работать. Общей проблемой развернутых систем являются неудачи в действительном "закрытии" всех альтернативных и прямых маршрутов от запрашивающих объектов до конечных серверов.
Вы можете проконтролировать, работает ли прокси и по каким портам он работает, путем проверки прокси-сервера на предмет наличия процесса, прослушивающего предполагаемые порты. Полезно также проверять, чтобы прокси не был случайно сконфигурирован на прослушивание большего количества IP-адресов, чем планировалось.
Для проверки на наличие прослушивающего процесса для отдельного порта (и для какого удаленного адреса) вы можете использовать команду операционной системы NETSTAT.
netstat –an | find "LISTEN" |TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING find "8080" В ОС UNIX вместо find используйте команду grep.
Если вы видите 0.0.0.0:8080 (или *.*:8080 ) локальным (первым) адресом, как показано, то это означает, что прокси прослушивает все TCP/IP-адреса, объявленные и разрешенные на локальной машине. Другими словами, в случае наличия компьютера, который имеет более одной сетевой карты и IP-адреса, запрашивающий может соединиться с любым из этих адресов и взаимодействовать через прокси.
Это важно проверять, поскольку иногда чрезвычайно важно прослушивать специфические адреса. К примеру, по причинам безопасности вы можете предпочесть прослушивать 127.0.0.1:xx на предмет наличия трафика в том же самом сервере, доступ к которому должен осуществляться только через локальный обратный прокси, и не прослушивать внешний IP-адрес сервера.
С точки зрения передового опыта в области обеспечения безопасности единственной наиболее значимой вещью, в которой вы захотите убедиться, будет то, что кеширующий прокси кеширует то, что кешируемо, и не кеширует то, что некешируемо. Результаты игнорирования инструкций насчет невыполнения
Продукты Lotus сильно полагаются на то, что прокси не допускают переполнения кеша некешируемым контентом, в противном случае результаты будут действительно непредсказуемыми.
Совет по устранению неполадок. Если в процессе отладки соединения между двумя объектами, скажем Алисой и Бобом, у вас есть хоть малейшее подозрение на то, что кто-то (люди из вашей дружественной сети или даже ваш интернет-провайдер) мог сконфигурировать прозрачный прокси посередине между Алисой и Бобом, то обратитесь к следующему понятию: дополнительные заголовки ответов, которые содержат "путь". Во множестве реальных случаев мы обнаружили (имея анализатор протоколов), что некоторые из этих прозрачных пересылающих прокси допускают переполнение кеша или агрессивно кешируют контент, что означает, что они сконфигурированы на сохранение пропускной способности, причем не важно какой. Соответственно они поступают, как "они считают лучше" или как "более интеллектуальные прокси", игнорируя в действительности инструкции "не кешировать (no-cache)" и "истечение срока (expires)", которые может задавать контенту Web-сервер.
По умолчанию многие обратные прокси-серверы будут скрывать подлинный IP-адрес клиента при выполнении запросов конечных серверов. Соответственно, будет казаться, что все запросы идут с одного и того же IP-адреса. Параметры обеспечения конфиденциальности многих образцов прокси разрешают наличие дополнительных заголовков HTTP для передачи их наряду с запросами. Таким образом, существует возможность разрешить пересылку IP-адреса клиента серверу назначения. При этом к запросу добавляется значение дополнительного заголовка HTTP, содержащее действительный IP-адрес запрашивающего клиента. Данное явление имеет большое значение для обеспечения безопасности, так как позволяет вам отслеживать и устранять неполадки в любых клиентских соединениях.
Многие прокси-серверы разрешают соединяющимся клиентам осуществлять поиск имени с использованием DNS. Эта опция является причиной того, что прокси-сервер превращает каждый входящий IP-адрес клиента в имя хоста, результатом чего являются непроизводительные издержки в обработке данных на сервере. Если не принимать во внимание причины из области обеспечения безопасности и протоколирования, побуждающие делать это, то данная опция обычно должна быть отключена.
Как правило, прокси-серверы размещаются во внешних зонах, которые оставляют их открытыми при наличии повышенного уровня возможности проведения атак со стороны потенциальных хакеров. Поэтому вы должны регулярно осуществлять протоколирование событий и мониторинг ваших прокси-систем.
В то время как мы постигаем сложности внутреннего размещения и проблемы синхронизации, имея при этом в наличии установленные на что-либо продукты обеспечения безопасности, не располагающие последними доступными патчами/уровнями (обновлениями), существует реальная угроза получения серьезных проблем. Нет смысла тратить деньги на поддержание безопасности ниже стандартного уровня. Несмотря на то что вы можете использовать ее для предотвращения определенных ошибок, такого понятия, как "полубезопасность", не существует. Имеющие злой умысел хакеры располагают той же информацией об известных уязвимостях, которой располагаем и мы, и не замедлят быстро воспользоваться этими уязвимостями.
В этой лекции мы ознакомились с общим представлением о прокси-серверах и описали различные типы прокси, использующиеся в современных инфраструктурах обработки данных. Далее мы сфокусировали внимание на понятии обратного прокси, так как обратные прокси представляют собой ключевые строительные элементы для создания многозональных безопасных сред. После этого были представлены различные рассуждения и советы по введению обратных прокси в эксплуатацию при использовании технологий IBM и Lotus.
Принцип обратного прокси позднее используется в этом курсе в части 4, "Безопасный сценарий", в целях оказания помощи при создании безопасной среды для вымышленной компании.
Прокси-сервер (известный также как шлюз приложений) представляет собой приложение, которое выступает для трафика в качестве посредника между доверенной сетью и недоверенной сетью. Это не снимает необходимости применения брандмауэра для управления трафиком на IP-уровне, чтобы не предусматривать наличие брандмауэра прикладного уровня.
Слово "proxy", как и множество других ставших популярными компьютерными терминами английских слов, возможно, утратило для некоторых из нас свое оригинальное значение. Согласно словарю, proxy – это кто-то (или что-то), уполномоченный действовать от лица его клиента и "доставляющий" клиенту определенные предметы.
Вы можете представить себе посредника как доверенное лицо или посла, которым предписано находиться где-то, где не может непосредственно находиться их клиент (или предпочитает не находиться) по причинам неудобства или безопасности. Послы обычно знают местный язык и обычаи, могут привести несовершенный запрос клиента в форму, допустимую в местном масштабе другой зоны, и, конечно, могут перевести обратно полученный ответ. В компьютерных понятиях такой "посол" может получать https-запросы по порту 443 и преобразовывать их в http-запросы по порту 80.
Прокси в более повседневных, практических компьютерных терминах являются процессами, запущенными на компьютерах, которым, как правило, предоставлен доступ (в брандмауэре) к более чем одной зоне. Именно эта способность делает их полезными. В типичном случае прокси просто будет работать от имени своего пользователя на месте перекрытия зон (в образе приложения), выполняя и получая нечто из зоны, с которой при других обстоятельствах запрещено устанавливать контакт или запрашивать что-либо со стороны отдельных процессов и пользователей из другой зоны.
С другой стороны, на прокси можно посмотреть с точки зрения "человека посередине". Как мы видели в предыдущих лекциях, одной из фундаментальных концепций всеобщей безопасности (не только в криптографии) является концепция атаки со стороны "(плохого) человека посередине", которая заключается в перехвате и ретрансляции передаваемой между двумя сторонами информации третьей, незваной, "плохой" стороной.
Прокси могут восприниматься как "хорошие" приемники (слушатели) информации или как "люди посередине". Это значит, что они перехватывают информацию, ретранслируют ее далее, но с некоторой предопределенной и полезной для сетевой инфраструктуры целью.
Как правило, компьютерный прокси является базовым bind ), ожидая запросов по определенному протоколу. Когда установлено соединение с клиентом и получен правильный запрос, он "повторит" этот запрос другому серверу от имени клиента, как определено в его правилах для этого типа запросов. Когда от сервера получен ответ, прокси передает этот ответ назад пользователю или процессу клиента, которые ранее осуществили запрос, применяя все необходимые преобразования.
Если смотреть на вещи упрощенно, прокси на самом деле существуют во множестве различных продуктов. К примеру, большинство технологий порталов, которые сегодня легкодоступны, запрашивают контент от лица пользователя и компонуют его в отдельный "вид портала". Другим примером прокси являются "транзитные пересылки" Notes, которые существовали в Lotus Notes определенное количество лет и разрешали удаленный доступ в среды Notes на протяжении всех ранних лет развития Интернета. Тем не менее далее в этом разделе мы сосредоточим внимание на прокси в виде отдельных продуктов, так как наиболее часто используемым сегодня передовым опытом является применение отдельных прокси-сервисов.
В этом разделе определены существующие на рынке различные типы прокси, применяемые в обычных инфраструктурах. Как было установлено ранее, зачастую предоставленное для прокси оборудование будет на самом деле выполнять или поддерживать множество типов прокси-сервисов. К примеру, прокси-сервер может предоставлять возможности
Ключевыми типами прокси, которые мы определяем и рассматриваем в этом разделе, являются:
Пересылающий прокси является прокси-сервером, который помогает пользователям из одной зоны безопасности выполнять запросы контента из "следующей" зоны, следуя направлению, которое обычно (но не обязательно) является исходящим (это значит, что клиент находится внутри, а сервер где-то в открытом Интернете).
С точки зрения безопасности простой прокси имеет целью обеспечение безопасности, состоящее в скрытии наименования (в терминах топологии внутренней сети) рабочей станции или процесса запрашивающего пользователя. Он может также применяться для скрытия некоторых других атрибутов сеанса пользователя.
Типичным примером этого типа являются корпоративные прокси, которые обслуживают внутренних пользователей посредством разрешения им доступа на внешние сайты для Web-браузинга или любого другого вида взаимодействия с Интернетом.
С точки зрения топологии (как в общем смысле, так и относительно ширины полосы пропускания) пересылающие прокси всегда относительно ограничены в терминах сетевой скорости по отношению к своим пользователям из-за более медленного WAN-соединения (соединения с глобальной сетью), которое обычно отделяет пересылающий прокси от реального контента в Интернете.
Прозрачные прокси являются прокси-серверами, которые "находятся здесь", но не осведомляют пользователей в прямой форме о том, что они здесь находятся. В пересылающих прокси обычно существуют Linux/UNIX блоки, которые слушают весь трафик по определенному протоколу для определенного сегмента сети и перехватывают трафик, хотя пользовательский процесс в действительности не знает об их существовании. Фактически пользовательский процесс не общается с прокси, но общается с другим (конечным) сайтом, а прокси, в сущности, становится тем "человеком посередине", который "взламывает" соединение.
Прокси является непрозрачным, или объявленным, когда пользователи знают о том, что они общаются через прокси, потому что они обращаются (на языке прокси: HTTP) к прокси. Другими словами, если я объявил свой прокси как proxy.mydomain.com, то после этого мои процессы будут общаться с proxy.mydomain.com, запрашивая его об установлении контакта с конечным адресом назначения моих запросов. Я полностью осведомлен о существовании прокси, о необходимости общаться с ним на "языке прокси" (HTTP), и о необходимости передать ему куда "идти" и откуда "принести" необходимый контент.
Вы можете иметь объявленные, непрозрачные прокси, которые автоматически объявлены, сконфигурированы или обнаружены. Вне зависимости от того как они были объявлены, эти прокси являются видимыми и известными для запрашивающего пользователя или процесса. Другими словами, неважно, как вы или ваш процесс узнали о существовании прокси, каковы причины того, что вы узнали о существовании прокси и о том, что вы общаетесь с прокси.
Прозрачные прокси сами по себе не являются на самом деле типом прокси, скорее любой прокси является либо прозрачным, либо объявленным по проекту.
Кеширующие прокси, как указано в их названии, являются прокси-серверами, которые сконфигурированы на повторное использование
Наиболее важным аспектом для кеширующих прокси является необходимость обеспечения того, что кеширующие прокси кешируют только то, что на самом деле можно кешировать. Динамический, регулярно изменяющийся контент не лучший выбор для
В большинстве случаев пересылающие прокси конфигурируются также для работы в качестве кеширующих прокси. Это явление используется настолько часто, что компания IBM включила это в название компонента своего Edge Server: IBM Caching Proxy. На рис. 5.1 отображен типичный пересылающий и кеширующий прокси-сервер.
(рис 5.1) Кеширующий прокси, работающий как пересылающий прокси
В качестве высшего проявления необходимой для простых прокси функциональности прокси-серверы могут быть сконфигурированы для приведения в исполнение политик безопасности. Такие прокси обеспечения безопасности могут обрабатывать (либо выступать в качестве посредников при обработке) запросы аутентификации и авторизации. В этих случаях аутентификация пользователя клиента и авторизация клиента для доступа к определенному контенту контролируется самим прокси-сервером. Далее мандат безопасности посылается от прокси к конечным серверам с запросом, а конечный сервер должен быть сконфигурирован на оказание доверия предоставляемому прокси
Существует много различных продуктов и предложений, а также множество топологий на выбор, но с точки зрения выполнения прокси-функций безопасность является дополнительной функцией, которую может выполнять прокси.
В большинстве случаев функциональные возможности по обеспечению безопасности могут быть добавлены стандартному прокси в виде дополнительного программного модуля [plug-in (плагин)] (к примеру, IBM Tivoli WebSeal Plug-In для IBM WebSphere Edge Server). Существуют также и отдельные продукты, такие, как IBM Tivoli
Немного дополнительной информации о таких прокси обеспечения безопасности вы найдете в разделе 4.1.6, "Системы управления подлинностью и управления доступом на предприятии".
Ранее в этой лекции мы установили, что разделение на зоны безопасности является ключевой концепцией при развертывании безопасной топологии. В этом контексте единственным, что позволяет делать обратный прокси, является обеспечение контролируемым и безопасным образом видимости находящегося позади прокси (как правило, во внутренней зоне) более чувствительного контента, без наличия реального необработанного контента, баз данных и т. д., показываемых во внешней зоне.
Обратные прокси имеют много общего кода с пересылающими прокси: фактически одни и те же продукты могут быть сконфигурированы одним или другим образом либо двумя сразу! Однако с функциональной и практической точки зрения в нашем случае мы рассматриваем обратные прокси как полностью другой инструмент.
Обратные прокси прозрачны, отчасти по определению. За обратным прокси пользователь вообще не знает о своем общении с прокси-сервером. Пользователь полагает, что общается с реальным предметом – сервером, на котором находится контент.
Пользователь не только будет думать о том, что он общается с сервером, на котором находится контент, но и может взаимодействовать и проходить аутентификацию на обратном прокси и быть субъектом по отношению к его политикам.
Обратные прокси обычно избраны и реализованы в целях обеспечения изоляции контента и зон. Однако, вы можете также добавить в обратные прокси функциональные возможности по кешированию для обеспечения производительности заодно с преимуществами обеспечения безопасности.
(рис 5.2) Типичный обратный проксиОбратите внимание, что при этом виде сценария выигрыш в производительности за счет
Однако когда на обратном прокси разрешено
Серверы безопасности – обратные прокси [
Зачастую такие продукты RPSS будут иметь в обратном прокси встраиваемый компонент, обрабатывающий запросы управления доступом и авторизации и объединенный с конечной системой управления доступом предприятия, которая фактически проверяет права пользователя или клиента на доступ и авторизацию. Этот встраиваемый компонент иногда называют лезвием (
Большинство технологий на основе Lotus Domino поддерживали сценарии применения обратных прокси на протяжении многих лет. В настоящее время в качестве исключения поддержку обратных прокси получил только продукт Lotus Sametime. Более подробно он описан в следующем разделе.
Последующие требования обратных прокси к Domino должны быть рассмотрены для традиционных технологий на основе Lotus Domino (Notes/Domino, iNotes, QuickPlace и т. д.).
Первым для
Кроме того, основными кешируемыми элементами, которые будут кешироваться обратными прокси с возможностями
?OpenImageResource ?OpenElementFieldElemFormat = gif URL
В IBM WebSphere Edge Server это выполняется посредством параметров настройки фактора последнего модифицирования ("Last Modified Factor").
Поддержка методов HTTP (HTTP Methods) большинством прокси-серверов позволяет вам определить типы запросов, обслуживаемые прокси-сервером. Существует несколько типов, которые включаются по умолчанию в большинстве прокси, но единственными необходимыми Domino для функционирования являются GET, HEAD и POST. Другие являются необязательными и могут представлять собой риск для безопасности.
Существует возможность сконфигурировать правило прокси для типа реализации "передача всего", который будет поддерживать технологии на основе Domino. Фактически это может быть параметром по умолчанию для множества прокси-серверов.
requests for /* go to http://xxx.xxx.xxx.xxx/*
В этом случае правило определяет, что если запросу не соответствует никакое из правил набора по умолчанию, то прокси пересылает запрос запрашиваемому серверу вне зависимости от того, что было на сервере запрошено.
Несмотря на то что подобный шаг может быть достаточно простым, он является рискованным, так как разрешает прямой доступ к какому-либо ресурсу на сервере Domino, доступному посредством HTTP.
В качестве альтернативы для ограничения доступа только до уровня необходимой функциональности может быть определен специфический набор правил. К примеру, правила для обычной инфраструктуры Domino, использующей iNotes, будут выглядеть следующим образом:
requests for /mail* go to http://xxx.xxx.xxx.xxx/mail* requests for /iNotes* go to http://xxx.xxx.xxx.xxx/iNotes* requests for /inotes5* go to http://xxx.xxx.xxx.xxx/inotes5* requests for /icons* go to http://xxx.xxx.xxx.xxx/icons* requests for /domjava* go to http://xxx.xxx.xxx.xxx/domjava* requests for /names.nsf go to http://xxx.xxx.xxx.xxx/names.nsf
При таких правилах обслуживается только контент в подкаталогах /mail*. Правила определены таким образом, что если сайт имеет множество почтовых подкаталогов (к примеру, /mail[1-3] ), то они включены. Если вы хотите ограничить доступ только к подмножеству из почтовых баз данных, переместите их в специальную папку, такую, как /pubmail/*.
Другие правила разрешают доступ для поддержки контента, необходимого для предоставления конечному пользователю практики работы с iNotes Web Access. Еще одним важным правилом, которое необходимо рассмотреть, является правило /names., используемое для аутентификации. Оно разрешает доступ из Интернета к Domino Directory, но не к контенту, который находится вне списка каталогов по умолчанию.
Результат построения URL-адресов со стороны Domino выглядит так. Когда пользователь посредством аутентификации сеанса входит в Domino, экран входа в систему по умолчанию отправляет запрос к /names.. Прокси-сервер согласовывает этот запрос и передает его Domino. Если, к примеру, пользователь пытается открыть вид групп (Groups) с помощью запросов /names. или /names. , то как запрос Domino, так и запрос прокси-сервера потерпят неудачу, потому что они не соответствуют правилу. Пользователь получит сообщение об ошибке 403, гласящее о запрещении доступа.
Большинство прокси-серверов имеет также возможность принятия во внимание ограничителей URL, которые сообщают прокси-серверу, что данное значение должно трактоваться как часть основного URL для преобразования адресов. Ограничители URL (именуемые в IBM WebSphere Edge Server как параметр SignificantUrlTerminator) должны быть созданы для Domino, так как большинство URL-адресов Domino содержат символ "?" и соответственно трактуются прокси-сервером как URL-адреса запросов для возможного
Специфическими ограничителями URL, требуемыми для поддержки Domino, являются:
SignificantUrlTerminator ?OpenImageResource SignificantUrlTerminator ?OpenElement SignificantUrlTerminator /?OpenImageResource SignificantUrlTerminator /?OpenElement
Инструкция ReversePass (обратная пересылка) большинства прокси-серверов перехватывает стандартные перенаправляющие ответы 302 от Domino и переписывает их для нового места назначения. Это новое место назначения должно являться допустимым URL-именем с таким расчетом, что, когда конечный пользователь запросит обновленную страницу после перенаправления, она будет действительной:
ReversePass http://xxx.xxx.xxx.xxx/* http://proxy.formymailserver.web/*
Дополнительную информацию о конфигурировании Domino для использования за обратным прокси-сервером можно найти в статье с домена Lotus Developer Domain (LLD) "Конфигурирование Web-доступа к iNotes при использовании обратного прокси-сервера WebSphere Edge". Эта статья может быть найдена на сайте
В то время как другие технологии Lotus поддерживали использующие обратные прокси-серверы инфраструктуры самостоятельно, поддержка прокси в продукте Lotus
Более детальную информацию о поддержке обратных прокси в Sametime 3.1 можно найти в руководстве администратора Sametime 3.1 Administrators Guide, которое является частью документации на продукт. Данная документация доступна в домене Lotus Developer Domain по адресу:
Когда сервер Sametime 3.1 размещен во внутренней сети за обратным прокси-сервером, то обратный прокси-сервер работает как посредник между сервером Sametime и клиентами Sametime. Все данные Sametime, протекающие между сервером Sametime и его клиентами, проходят через обратный прокси-сервер.
Для выполнения своих целей в области безопасности обратный прокси-сервер обрабатывает проходящие через него данные. Обработка данных Sametime со стороны обратного прокси-сервера накладывает определенные требования и ограничения на использование обратных прокси-серверов вместе с сервером Sametime. Поэтому в данном случае поддерживаются только определенные типы прокси-серверов и могут быть разрешены только определенные типы свойств прокси.
В этом разделе перечислены требования, которым должен соответствовать обратный прокси-сервер для совместного использования с Sametime 3.1.
Совместно с Sametime могут быть использованы только те обратные прокси-серверы, которые поддерживают использование "идентификаторов схожести" (
http[s]://hostname:port/affinity-id/
В этом примере "hostname" представляет собой полное доменное имя машины ( " является псевдонимом внутреннего сервера, который защищен посредством обратного прокси-сервера. Точным примером URL такого формата является
http[s]://reverseproxy.ibm.com/st01/stcenter.nsf
В этом примере текстовая строка "st01" является идентификатором схожести ( id является псевдонимом определенного сервера Sametime (такого, как sametime.ibm.com), который защищен посредством обратного прокси-сервера. Родственный id используется обратным прокси-сервером для направления входящих запросов на определенный внутренний сервер Sametime.
Если вы разместили в вашей сетевой среде множество обратных прокси-серверов и ожидаете, что пользователи будут осуществлять доступ к вашим серверам Sametime через это множество обратных прокси-серверов, то к вашей среде возникают некоторые особые требования:
К примеру, если один из обратных прокси-серверов имеет имя reverseproxy.ibm.com, то и все другие обратные прокси-серверы должны иметь имя reverseproxy.ibm.com. Если обратные прокси-серверы имеют различные DNS-имена, то клиенты Sametime будут неспособны поддерживать связь с сервером Sametime, расположенным за обратными прокси-серверами. Для распределения соединений от Web-браузеров к множеству обратных прокси-серверов должно быть использовано устройство, управляющее распределением соединений (такое, как IBM WebSphere Edge Server).
Каждый обратный прокси-сервер должен использовать идентичные правила и конфигурации преобразования адресов для управления переводом URL-адресов, отправляемых Web-браузерами к обратному прокси-серверу, с целью обеспечения доступа к внутреннему серверу Sametime. Если перевод этих URL-адресов в URL-адреса внутренних серверов Sametime не происходит одинаковым образом на каждом из обратных прокси-серверов, клиенты Sametime будут неспособны поддерживать связь с сервером Sametime, расположенным за обратным прокси-сервером.
Обратные прокси-серверы, которые переписывают URL-адреса в целях аутентификации, не поддерживаются. Некоторые обратные прокси-серверы добавляют информацию об аутентификации и сеансе в конец внедренных в HTML URL-адресов, которые передаются через прокси назад к клиенту. Клиент будет включать эти добавленные данные в последующие запросы к обратному прокси-серверу.
Когда обратный прокси-сервер получает от клиента эти последующие запросы, он отделяет данные аутентификации и переписывает URL-адрес для выполнения внутренней маршрутизации запросов. Сервер Sametime не может работать за обратным прокси-сервером, который обрабатывает данные аутентификации подобным образом.
В связи с этим должны использоваться обратные прокси, которые применяют в информации аутентификации cookies. Кроме того, администратор должен указать значение максимально возможного времени ожидания для cookies аутентификации, сгенерированных обратным прокси-
Несмотря на то что Sametime 3.1 поддерживает среды с обратными прокси-серверами, в связи с этим существуют некоторые ограничения относительно стандартных функциональных возможностей Sametime.
Не все клиенты Sametime могут взаимодействовать с серверами Sametime через обратный прокси-сервер. Поддерживаются следующие клиенты:
Клиент Sametime Meeting Room и клиент Sametime Broadcast могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены следующие Web-браузеры и виртуальные Java-машины [
Клиент Sametime Connect для браузеров и приложения Sametime Links могут взаимодействовать с сервером Sametime через обратный прокси-сервер в том случае, когда запущены браузеры Explorer 6 или Netscape 7, которые работают с Sun Microsystems JVM 1.4.1.
Клиент Sametime Connect для браузеров и приложения Sametime Links могут не функционировать соответствующим образом с другими виртуальными Java-машинами, включая предусмотренную для Internet Explorer собственную виртуальную машину Microsoft.
Ограничение. Sametime Connect для клиента рабочего стола (Microsoft Windows-версия Sametime Connect) не может использоваться с сервером Sametime, который размещен за обратным прокси-сервером.
Когда сервер Sametime расположен за обратным прокси-сервером, на его возможности накладываются следующие ограничения:
Для шифрования передаваемых между клиентами Sametime и обратным прокси-сервером данных может использоваться протокол защищенных сокетов [Secure Sockets Layer (SSL)]. Однако SSL не может использоваться для шифрования данных, передаваемых между серверами Sametime и обратным прокси-сервером. Соответственно соединение между обратным прокси и сервером Sametime должно быть безопасным.
Совет. Если для шифрования передаваемых между Web-браузерами и обратным прокси-сервером данных используется SSL, на сервере Sametime администратор должен осуществить конфигурацию преобразования адресов, необходимую для преобразования получаемых от Web-браузера данных HTTPS в требуемые сервером Sametime данные HTTP.
Когда SSL используется в среде обратного прокси с Sametime, многие из выполняемых Sametime функций будут запускаться в плагине Java Plug-in Web-браузера (клиент соединения, клиент совещаний и т. д.). Этот Java Plug-in должен распознавать используемые обратным прокси-сертификаты SSL, исходя из чего он сможет взаимодействовать через SSL.
Сертификатами, которые, возможно, потребуется распознавать Java Plug-in, являются следующие.
Когда обратный прокси-сервер сконфигурирован на поддержку SSL, во время подтверждения установления SSL-соединения ("рукопожатия" – handshake) он отправляет Web-браузеру сертификат SSL сервера. Используемый Web-браузером Java 1.4.1 Plug-in должен иметь доступ к сертификату подписчика (Signer certificate), который подписан тем же источником сертификации (Certificate Authority (CA)), что и высланный обратным прокси сертификат сервера.
По умолчанию Java Plug-in имеет доступ к нескольким различным сертификатам подписчика, которые могут быть использованы для этой цели. Для просмотра доступных модулю Java Plug-in 1.4.1 сертификатов подписчика используйте панель управления Java Plug-in следующим образом:
В целях успешного подтверждения связи ("обмена рукопожатиями") для установления SSL-соединения сертификат сервера, отправленный обратным прокси-сервером Web-браузеру клиента, должен быть подписан одним из источников сертификации (CA) из списка источников сертификации подписчика.
Если конфигурация обратного прокси-сервера требует аутентификации сертификата клиента, то этот сертификат для отдельного пользователя должен быть импортирован в панель управления Java Plug-in 1.4.1 на машине данного пользователя. Для импортирования сертификата клиента в хранилище ключей Java Plug-in вы можете использовать закладку Certificates (Сертификаты) панели управления Java Plug-in.
К примеру:
Когда сервер Sametime расположен за обратным прокси-сервером, администратор должен сконфигурировать на обратном прокси-сервере правила преобразования адресов.
Эти правила преобразования адресов позволяют прокси-серверу преобразовывать (или переписывать) URL-адреса, связанные с обратным прокси-сервером, в URL-адреса внутреннего сервера Sametime.
Когда пользователь соединяется с сервером Sametime через обратный прокси-сервер, то последний должен иметь в конфигурации "правила преобразования адресов" для поддержки перечисленных ниже действий, которые дадут возможность пользователям Sametime присутствовать на совещаниях и участвовать в сеансах чатов.
В этом разделе предусмотрены некоторые рекомендации на тему того, как на обратном прокси-сервере сконфигурировать правила преобразования адресов для выполнения преобразования (или переписывания) URL-адресов в случае совместной работы обратного прокси и Sametime.
Любой обратный прокси-сервер, который работает с сервером Sametime, должен поддерживать в URL-адресах идентификатор схожести (
К примеру, если входящим URL-адресом от Web-сервера является
http[s]://reverseproxy.ibm.com/st01/stcenter.nsf
то правила преобразования адресов обратного прокси-сервера преобразуют родственный id "st01" в сервер Sametime, именуемый "sametime.ibm.com", а родственный id обеспечивает переписывание обратным прокси-сервером входящего URL-адреса в адрес следующего вида:
http[s]://sametime.ibm.com/stcenter.nsf
Если вы имеете множество серверов Sametime, размещенных за обратным прокси-сервером, то каждый сервер Sametime должен иметь индивидуальный родственный id, к примеру:
http[s]://sametime2.ibm.com/* /st02/* http[s]://sametime1.ibm.com/* /st01/*
Для преобразования всех URL-адресов, связанных с пользовательским интерфейсом сервера Sametime, может быть применено единственное правило преобразования адресов.
Администратор может создать для обратного прокси-сервера единственное правило преобразования адресов для преобразования всех URL, связанных с интерфейсом сервера Sametime, посредством использования шаблонов. К примеру, администратор может создать правило преобразования, с помощью которого следующий URL-адрес от Web-браузера:
http[s]://reverseproxy.ibm.com/st01/*
будет преобразовываться в такой URL-адрес сервера Sametime:
http[s]://sametime.ibm.com/*
Единственное правило преобразования адресов, которое выполняет этот тип преобразования URL, должно разрешать пользователям доступ ко всем элементам пользовательского интерфейса Sametime через обратный прокси-сервер.
При создании правил преобразования URL-адресов с целью разрешения клиентам Java-апплетов Sametime работать в Web-браузере пользователя должна быть обеспечена поддержка соединения со службами
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами
Если входящими URL-адресами от Java-апплета являются
http[s]://proxy.ibm.com/st01/communityCBR/ http[s]://proxy.ibm.com/st01/CommunityCBR/
то правила преобразования адресов на обратном прокси должны преобразовать эти URL-адреса в следующий вид:
http://sametime.ibm.com:8082/communityCBR http://sametime.ibm.com:8082/CommunityCBR
Совет. Конфигурация преобразования адресов для соединений со службами "с" нижнего регистра, в других фрагментах Java-кода в "CommunityCBR" используется "С" верхнего регистра. Если прокси является чувствительным к регистру, это различие может препятствовать установлению соединений.
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами Meeting Services.
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/MeetingCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:8081/MeetingCBR
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/BroadcastCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:554/BroadcastCBR
Во время установки сервера Sametime администратор может на свой выбор разрешить или не разрешить HTTP-туннелирование по порту 80.
Если во время установки сервера Sametime администратор не разрешит HTTP-туннелирование по порту 80, то необходимо сконфигурировать отдельные правила преобразования адресов для каждой из трех служб Sametime (
Когда HTTP-туннелирование по порту 80 не разрешено, каждая служба Sametime слушает HTTP-соединения на различных портах и для каждой из служб должны быть установлены отдельные правила преобразования адресов. Правило преобразования адресов должно указывать порт, на котором каждая из служб прослушивает соединения.
Если во время установки сервера Sametime администратор разрешил HTTP-туннелирование по порту 80, клиенты Sametime соединяются со всеми службами по единственному порту.
При этой конфигурации единственное правило преобразования адресов, которое разрешает пользователям осуществлять навигацию по пользовательскому интерфейсу сервера Sametime, разрешит также клиентам Sametime устанавливать соединения с сервисами Sametime.
Когда разрешено HTTP-туннелирование по порту 80, мультиплексор служб
Когда сервер Sametime работает в однопортовом режиме (что означает разрешение HTTP-туннелирования по порту 80), правила преобразования адресов для соединений Java-апплетов более просты. Так как все соединения клиентов Java-апплетов Sametime происходят по одному и тому же порту, нет необходимости указывать в правилах преобразования адресов отдельные порты для каждой из служб.
При таком сценарии администратору необходимо только убедиться в том, что этот входящий URL-адрес от Java-апплетов Sametime:
http[s]://proxy.ibm.com/st01/*
посредством правил преобразования адресов на обратном прокси-сервере изменяется на следующий URL-адрес:
http://sametime.ibm.com/*
Совет. Когда сервер Sametime сконфигурирован на поддержку HTTP-туннелирования по порту 80, производительность сервера не является наиболее эффективной, так как нагрузка от соединений сосредоточена на мультиплексоре служб
Чтобы разрешить серверу Sametime 3.1 понимать и поддерживать запросы обратного прокси, администратор должен использовать на сервере Sametime инструмент Sametime Administration Tool для конфигурирования сервера Sametime на работу с обратным прокси-сервером.
Требуется HTTP-туннелирование, так как большинство обратных прокси будет поддерживать только протоколы HTTP.
Откройте раздел Configuration (Конфигурация) графического интерфейса пользователя Sametime Web Admin и щелкните мышью на Connectivity (Соединяемость). В нижней части экрана находится раздел "
Разрешите поддержку обратного прокси путем установки кнопки-флажка, после чего введите "имя соединения" (
Выбор параметра
Этот параметр разрешает применение в клиентах Sametime логики, которая позволяет им соединяться с сервером Sametime через обратный прокси-сервер. Данный параметр по умолчанию запрещен.
Совет. Разрешение этого параметра не требует, чтобы все пользователи вашей корпоративной интранет-сети осуществляли доступ к серверу Sametime через обратный прокси-сервер. Данное разрешение улучшает существующую в клиентах Sametime логику путем добавления к ней логики соединения с обратным прокси. Существующая логика остается и работает внутри клиентов. При такой схеме клиенты, которые не подключаются к серверу Sametime через обратный прокси-сервер, при соединении с сервером Sametime следуют стандартным процессам соединения клиентов Sametime.
Этот раздел содержит некоторые общие советы и подсказки по работе с обратными прокси, которые не являются специфичными по отношению к какой-либо технологии или продукту Lotus или IBM.
При использовании какого-либо обратного прокси необходимо рассматривать потенциальное воздействие на производительность системы. Даже при разрешенном
С примером воздействия на производительность со стороны обратного прокси по отношению к функции Domino Web Access (iNotes) можно ознакомиться в статье "Работа iNotes Web Access с обратными прокси и другими средствами обеспечения безопасности", доступной на Web-сайте Lotus Developer Domain по адресу
Если потенциальным объектом обслуживания запросов может быть более чем один сервер (в случае конфигурации обеспечения высокой доступности, перехвата отказов или распределения нагрузки) и если запросы включают динамический контент, вы должны убедиться в том, что для всех транзакций, проходящих для отдельного клиента за отдельный промежуток времени, используется один и тот же сервер.
Это явление называется схожестью клиентов (client
Идея проста: пока сервер доступен, вы обслуживаетесь одним и тем же сервером на протяжении всего вашего сеанса. Если этот сервер становится недоступным, для обхода отказа вы переключаетесь на другой сервер (gracefully transition).
При создании и построении новой инфраструктуры обратных прокси протестируйте все пути через эту инфраструктуру. Когда введено в действие большинство обратных прокси, то подразумевается, что через брандмауэр разрешено проходить только трафику, пропущенному через обратный прокси и что через обратный прокси разрешено проходить только трафику определенных типов.
В дополнение к проверке того, что все желаемые вами связи работают, убедитесь в том, что все другие связи не работают. Должно работать только то, что разрешено явно, все остальное не должно работать. Общей проблемой развернутых систем являются неудачи в действительном "закрытии" всех альтернативных и прямых маршрутов от запрашивающих объектов до конечных серверов.
Вы можете проконтролировать, работает ли прокси и по каким портам он работает, путем проверки прокси-сервера на предмет наличия процесса, прослушивающего предполагаемые порты. Полезно также проверять, чтобы прокси не был случайно сконфигурирован на прослушивание большего количества IP-адресов, чем планировалось.
Для проверки на наличие прослушивающего процесса для отдельного порта (и для какого удаленного адреса) вы можете использовать команду операционной системы NETSTAT.
netstat –an | find "LISTEN" |TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING find "8080" В ОС UNIX вместо find используйте команду grep.
Если вы видите 0.0.0.0:8080 (или *.*:8080 ) локальным (первым) адресом, как показано, то это означает, что прокси прослушивает все TCP/IP-адреса, объявленные и разрешенные на локальной машине. Другими словами, в случае наличия компьютера, который имеет более одной сетевой карты и IP-адреса, запрашивающий может соединиться с любым из этих адресов и взаимодействовать через прокси.
Это важно проверять, поскольку иногда чрезвычайно важно прослушивать специфические адреса. К примеру, по причинам безопасности вы можете предпочесть прослушивать 127.0.0.1:xx на предмет наличия трафика в том же самом сервере, доступ к которому должен осуществляться только через локальный обратный прокси, и не прослушивать внешний IP-адрес сервера.
С точки зрения передового опыта в области обеспечения безопасности единственной наиболее значимой вещью, в которой вы захотите убедиться, будет то, что кеширующий прокси кеширует то, что кешируемо, и не кеширует то, что некешируемо. Результаты игнорирования инструкций насчет невыполнения
Продукты Lotus сильно полагаются на то, что прокси не допускают переполнения кеша некешируемым контентом, в противном случае результаты будут действительно непредсказуемыми.
Совет по устранению неполадок. Если в процессе отладки соединения между двумя объектами, скажем Алисой и Бобом, у вас есть хоть малейшее подозрение на то, что кто-то (люди из вашей дружественной сети или даже ваш интернет-провайдер) мог сконфигурировать прозрачный прокси посередине между Алисой и Бобом, то обратитесь к следующему понятию: дополнительные заголовки ответов, которые содержат "путь". Во множестве реальных случаев мы обнаружили (имея анализатор протоколов), что некоторые из этих прозрачных пересылающих прокси допускают переполнение кеша или агрессивно кешируют контент, что означает, что они сконфигурированы на сохранение пропускной способности, причем не важно какой. Соответственно они поступают, как "они считают лучше" или как "более интеллектуальные прокси", игнорируя в действительности инструкции "не кешировать (no-cache)" и "истечение срока (expires)", которые может задавать контенту Web-сервер.
По умолчанию многие обратные прокси-серверы будут скрывать подлинный IP-адрес клиента при выполнении запросов конечных серверов. Соответственно, будет казаться, что все запросы идут с одного и того же IP-адреса. Параметры обеспечения конфиденциальности многих образцов прокси разрешают наличие дополнительных заголовков HTTP для передачи их наряду с запросами. Таким образом, существует возможность разрешить пересылку IP-адреса клиента серверу назначения. При этом к запросу добавляется значение дополнительного заголовка HTTP, содержащее действительный IP-адрес запрашивающего клиента. Данное явление имеет большое значение для обеспечения безопасности, так как позволяет вам отслеживать и устранять неполадки в любых клиентских соединениях.
Многие прокси-серверы разрешают соединяющимся клиентам осуществлять поиск имени с использованием DNS. Эта опция является причиной того, что прокси-сервер превращает каждый входящий IP-адрес клиента в имя хоста, результатом чего являются непроизводительные издержки в обработке данных на сервере. Если не принимать во внимание причины из области обеспечения безопасности и протоколирования, побуждающие делать это, то данная опция обычно должна быть отключена.
Как правило, прокси-серверы размещаются во внешних зонах, которые оставляют их открытыми при наличии повышенного уровня возможности проведения атак со стороны потенциальных хакеров. Поэтому вы должны регулярно осуществлять протоколирование событий и мониторинг ваших прокси-систем.
В то время как мы постигаем сложности внутреннего размещения и проблемы синхронизации, имея при этом в наличии установленные на что-либо продукты обеспечения безопасности, не располагающие последними доступными патчами/уровнями (обновлениями), существует реальная угроза получения серьезных проблем. Нет смысла тратить деньги на поддержание безопасности ниже стандартного уровня. Несмотря на то что вы можете использовать ее для предотвращения определенных ошибок, такого понятия, как "полубезопасность", не существует. Имеющие злой умысел хакеры располагают той же информацией об известных уязвимостях, которой располагаем и мы, и не замедлят быстро воспользоваться этими уязвимостями.
В этой лекции мы ознакомились с общим представлением о прокси-серверах и описали различные типы прокси, использующиеся в современных инфраструктурах обработки данных. Далее мы сфокусировали внимание на понятии обратного прокси, так как обратные прокси представляют собой ключевые строительные элементы для создания многозональных безопасных сред. После этого были представлены различные рассуждения и советы по введению обратных прокси в эксплуатацию при использовании технологий IBM и Lotus.
Принцип обратного прокси позднее используется в этом курсе в части 4, "Безопасный сценарий", в целях оказания помощи при создании безопасной среды для вымышленной компании.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.