Прокси-серверы
Пример преобразования адресов для служб Meeting Services
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами Meeting Services.
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/MeetingCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:8081/MeetingCBR
Пример преобразования адресов для служб Broadcast Services
Этот пример отображает конфигурацию преобразования адресов, которая позволит клиенту Java-апплета соединяться со службами Broadcast Services.
Если входящим URL-адресом от Java-апплета является
http[s]://proxy.ibm.com/st01/BroadcastCBR/
то правило преобразования адресов на обратном прокси должно преобразовать этот URL-адрес в следующий вид:
http://sametime.ibm.com:554/BroadcastCBR
HTTP-туннелирование, облегчающее преобразование адресов для Java-апплетов
Во время установки сервера Sametime администратор может на свой выбор разрешить или не разрешить HTTP-туннелирование по порту 80.
Если во время установки сервера Sametime администратор не разрешит HTTP-туннелирование по порту 80, то необходимо сконфигурировать отдельные правила преобразования адресов для каждой из трех служб Sametime (Community Services, Meeting Services и Broadcast Services), как было показано выше.
Когда HTTP-туннелирование по порту 80 не разрешено, каждая служба Sametime слушает HTTP-соединения на различных портах и для каждой из служб должны быть установлены отдельные правила преобразования адресов. Правило преобразования адресов должно указывать порт, на котором каждая из служб прослушивает соединения.
Если во время установки сервера Sametime администратор разрешил HTTP-туннелирование по порту 80, клиенты Sametime соединяются со всеми службами по единственному порту.
При этой конфигурации единственное правило преобразования адресов, которое разрешает пользователям осуществлять навигацию по пользовательскому интерфейсу сервера Sametime, разрешит также клиентам Sametime устанавливать соединения с сервисами Sametime.
Когда разрешено HTTP-туннелирование по порту 80, мультиплексор служб Community Services сервера Sametime слушает HTTP-соединения от имени служб HTTP Services, Community Services, Meeting Services и Broadcast Services сервера Sametime. Мультиплексор служб Community Services слушает соединения для всех этих служб на единственном порту (порт 80).
Когда сервер Sametime работает в однопортовом режиме (что означает разрешение HTTP-туннелирования по порту 80), правила преобразования адресов для соединений Java-апплетов более просты. Так как все соединения клиентов Java-апплетов Sametime происходят по одному и тому же порту, нет необходимости указывать в правилах преобразования адресов отдельные порты для каждой из служб.
При таком сценарии администратору необходимо только убедиться в том, что этот входящий URL-адрес от Java-апплетов Sametime:
http[s]://proxy.ibm.com/st01/*
посредством правил преобразования адресов на обратном прокси-сервере изменяется на следующий URL-адрес:
http://sametime.ibm.com/*
Совет. Когда сервер Sametime сконфигурирован на поддержку HTTP-туннелирования по порту 80, производительность сервера не является наиболее эффективной, так как нагрузка от соединений сосредоточена на мультиплексоре служб Community Services.
5.5.6 Конфигурирование Sametime 3.1 для поддержки обратного прокси
Чтобы разрешить серверу Sametime 3.1 понимать и поддерживать запросы обратного прокси, администратор должен использовать на сервере Sametime инструмент Sametime Administration Tool для конфигурирования сервера Sametime на работу с обратным прокси-сервером.
- Убедитесь в том, что Sametime настроен на HTTP-туннелирование.
Требуется HTTP-туннелирование, так как большинство обратных прокси будет поддерживать только протоколы HTTP.
- Разрешите поддержку обратных прокси.
Откройте раздел Configuration (Конфигурация) графического интерфейса пользователя Sametime Web Admin и щелкните мышью на Connectivity (Соединяемость). В нижней части экрана находится раздел "Reverse Proxy Support (Поддержка обратного прокси)".
Разрешите поддержку обратного прокси путем установки кнопки-флажка, после чего введите "имя соединения" ( junction name ) обратного прокси в окне Server Alias (Псевдоним сервера).
- Разрешите обнаружение клиентом обратного прокси.
Выбор параметра Reverse Proxy Discovery (Обнаружение обратного прокси) позволяет администратору разрешить или запретить поддержку обратного прокси.
Этот параметр разрешает применение в клиентах Sametime логики, которая позволяет им соединяться с сервером Sametime через обратный прокси-сервер. Данный параметр по умолчанию запрещен.
Совет. Разрешение этого параметра не требует, чтобы все пользователи вашей корпоративной интранет-сети осуществляли доступ к серверу Sametime через обратный прокси-сервер. Данное разрешение улучшает существующую в клиентах Sametime логику путем добавления к ней логики соединения с обратным прокси. Существующая логика остается и работает внутри клиентов. При такой схеме клиенты, которые не подключаются к серверу Sametime через обратный прокси-сервер, при соединении с сервером Sametime следуют стандартным процессам соединения клиентов Sametime.
5.6 Общие советы по работе с обратными прокси
Этот раздел содержит некоторые общие советы и подсказки по работе с обратными прокси, которые не являются специфичными по отношению к какой-либо технологии или продукту Lotus или IBM.
Рассмотрение воздействия на производительность
При использовании какого-либо обратного прокси необходимо рассматривать потенциальное воздействие на производительность системы. Даже при разрешенном кешировании такие дополнительные шаги, как преобразование URL-адресов, модификация заголовков HTTP, любые требуемые преобразования и т. д., со стороны обратного прокси могут иметь негативное влияние на производительность приложений, которые являются "разговорными".
С примером воздействия на производительность со стороны обратного прокси по отношению к функции Domino Web Access (iNotes) можно ознакомиться в статье "Работа iNotes Web Access с обратными прокси и другими средствами обеспечения безопасности", доступной на Web-сайте Lotus Developer Domain по адресу
Рассмотрение схожести клиентов
Если потенциальным объектом обслуживания запросов может быть более чем один сервер (в случае конфигурации обеспечения высокой доступности, перехвата отказов или распределения нагрузки) и если запросы включают динамический контент, вы должны убедиться в том, что для всех транзакций, проходящих для отдельного клиента за отдельный промежуток времени, используется один и тот же сервер.
Это явление называется схожестью клиентов (client affinity) или "прилипающими" сеансами (sticky sessions). Оно может быть реализовано посредством cookies, правил и т.д., но обычно требует размещения перед группой прокси-серверов компонентов балансировки нагрузки. Примером является модуль Network Dispatcher внутри сервера WebSphere Edge Server компании IBM.
Идея проста: пока сервер доступен, вы обслуживаетесь одним и тем же сервером на протяжении всего вашего сеанса. Если этот сервер становится недоступным, для обхода отказа вы переключаетесь на другой сервер (gracefully transition).
Тестирование всевозможных "дыр"
При создании и построении новой инфраструктуры обратных прокси протестируйте все пути через эту инфраструктуру. Когда введено в действие большинство обратных прокси, то подразумевается, что через брандмауэр разрешено проходить только трафику, пропущенному через обратный прокси и что через обратный прокси разрешено проходить только трафику определенных типов.
В дополнение к проверке того, что все желаемые вами связи работают, убедитесь в том, что все другие связи не работают. Должно работать только то, что разрешено явно, все остальное не должно работать. Общей проблемой развернутых систем являются неудачи в действительном "закрытии" всех альтернативных и прямых маршрутов от запрашивающих объектов до конечных серверов.
Проверка прослушиваемых адресов
Вы можете проконтролировать, работает ли прокси и по каким портам он работает, путем проверки прокси-сервера на предмет наличия процесса, прослушивающего предполагаемые порты. Полезно также проверять, чтобы прокси не был случайно сконфигурирован на прослушивание большего количества IP-адресов, чем планировалось.
Для проверки на наличие прослушивающего процесса для отдельного порта (и для какого удаленного адреса) вы можете использовать команду операционной системы NETSTAT.
netstat –an | find "LISTEN" | find "8080"2В ОС UNIX вместо find используйте команду grep.
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENINGЕсли вы видите 0.0.0.0:8080 (или *.*:8080 ) локальным (первым) адресом, как показано, то это означает, что прокси прослушивает все TCP/IP-адреса, объявленные и разрешенные на локальной машине. Другими словами, в случае наличия компьютера, который имеет более одной сетевой карты и IP-адреса, запрашивающий может соединиться с любым из этих адресов и взаимодействовать через прокси.
Это важно проверять, поскольку иногда чрезвычайно важно прослушивать специфические адреса. К примеру, по причинам безопасности вы можете предпочесть прослушивать 127.0.0.1:xx на предмет наличия трафика в том же самом сервере, доступ к которому должен осуществляться только через локальный обратный прокси, и не прослушивать внешний IP-адрес сервера.
Недопущение переполнения кеша при использовании кеширующего прокси
С точки зрения передового опыта в области обеспечения безопасности единственной наиболее значимой вещью, в которой вы захотите убедиться, будет то, что кеширующий прокси кеширует то, что кешируемо, и не кеширует то, что некешируемо. Результаты игнорирования инструкций насчет невыполнения кеширования со стороны прокси-серверов, сконфигурированных на "сохранение пропускной способности", могут лежать в диапазоне от проблем аутентификации до некорректного функционирования механизма единой авторизации [single sign on (SSO)], до отказа в функционировании ключевых элементов функциональных возможностей, таких, как информированность Sametime.
Продукты Lotus сильно полагаются на то, что прокси не допускают переполнения кеша некешируемым контентом, в противном случае результаты будут действительно непредсказуемыми.
Совет по устранению неполадок. Если в процессе отладки соединения между двумя объектами, скажем Алисой и Бобом, у вас есть хоть малейшее подозрение на то, что кто-то (люди из вашей дружественной сети или даже ваш интернет-провайдер) мог сконфигурировать прозрачный прокси посередине между Алисой и Бобом, то обратитесь к следующему понятию: дополнительные заголовки ответов, которые содержат "путь". Во множестве реальных случаев мы обнаружили (имея анализатор протоколов), что некоторые из этих прозрачных пересылающих прокси допускают переполнение кеша или агрессивно кешируют контент, что означает, что они сконфигурированы на сохранение пропускной способности, причем не важно какой. Соответственно они поступают, как "они считают лучше" или как "более интеллектуальные прокси", игнорируя в действительности инструкции "не кешировать (no-cache)" и "истечение срока (expires)", которые может задавать контенту Web-сервер.
Отслеживание IP-адресов клиентов
По умолчанию многие обратные прокси-серверы будут скрывать подлинный IP-адрес клиента при выполнении запросов конечных серверов. Соответственно, будет казаться, что все запросы идут с одного и того же IP-адреса. Параметры обеспечения конфиденциальности многих образцов прокси разрешают наличие дополнительных заголовков HTTP для передачи их наряду с запросами. Таким образом, существует возможность разрешить пересылку IP-адреса клиента серверу назначения. При этом к запросу добавляется значение дополнительного заголовка HTTP, содержащее действительный IP-адрес запрашивающего клиента. Данное явление имеет большое значение для обеспечения безопасности, так как позволяет вам отслеживать и устранять неполадки в любых клиентских соединениях.
Отключение поиска имени с использованием DNS
Многие прокси-серверы разрешают соединяющимся клиентам осуществлять поиск имени с использованием DNS. Эта опция является причиной того, что прокси-сервер превращает каждый входящий IP-адрес клиента в имя хоста, результатом чего являются непроизводительные издержки в обработке данных на сервере. Если не принимать во внимание причины из области обеспечения безопасности и протоколирования, побуждающие делать это, то данная опция обычно должна быть отключена.
Ведение журналов и мониторинг вашего прокси
Как правило, прокси-серверы размещаются во внешних зонах, которые оставляют их открытыми при наличии повышенного уровня возможности проведения атак со стороны потенциальных хакеров. Поэтому вы должны регулярно осуществлять протоколирование событий и мониторинг ваших прокси-систем.
Поддержка последних системных патчей
В то время как мы постигаем сложности внутреннего размещения и проблемы синхронизации, имея при этом в наличии установленные на что-либо продукты обеспечения безопасности, не располагающие последними доступными патчами/уровнями (обновлениями), существует реальная угроза получения серьезных проблем. Нет смысла тратить деньги на поддержание безопасности ниже стандартного уровня. Несмотря на то что вы можете использовать ее для предотвращения определенных ошибок, такого понятия, как "полубезопасность", не существует. Имеющие злой умысел хакеры располагают той же информацией об известных уязвимостях, которой располагаем и мы, и не замедлят быстро воспользоваться этими уязвимостями.
5.7 Краткие выводы
В этой лекции мы ознакомились с общим представлением о прокси-серверах и описали различные типы прокси, использующиеся в современных инфраструктурах обработки данных. Далее мы сфокусировали внимание на понятии обратного прокси, так как обратные прокси представляют собой ключевые строительные элементы для создания многозональных безопасных сред. После этого были представлены различные рассуждения и советы по введению обратных прокси в эксплуатацию при использовании технологий IBM и Lotus.
Принцип обратного прокси позднее используется в этом курсе в части 4, "Безопасный сценарий", в целях оказания помощи при создании безопасной среды для вымышленной компании.