Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:
В первых двух частях статьи о публикации web-сайтов без SSL мы рассмотрели работу мастера создания нового правила web-публикации и настройку web-приемника. В данной, последней, части мы закончим работу с мастером создания нового правила web-публикации, а затем рассмотрим свойства правила. К окончанию статьи у вас будут все средства, необходимые для публикации web-сайтов без SSL.
На странице User Sets (Пользователи) вы настраиваете необходимость использования аутентификации для доступа к web-серверу, опубликованному с помощью правила web-публикации. Установка по умолчанию — All Users (Все пользователи), что значит, что для доступа к web-серверу аутентификация не требуется. Нажмите Add (Добавить), если вы хотите использовать аутентификацию. Откроется диалоговое окно Add Users (Добавить пользователей), где вы можете выбрать тех, пользователей, к которым будет применяться правило.
Рисунок 1: Окно настройки пользователей
На странице User Sets (Пользователи) нажмите Next (Далее), а затем нажмите Finish (Завершить) на странице Completing the New Web Publishing Rule Wizard (Завершение работы мастера создания нового правила web-публикации).
Новое правило web-публикации появится в списке Firewall Policy (Политики сервера). Щелкните по правилу правой кнопкой и выберите из контекстного меню пункт Properties (Свойства). Диалоговое окно Properties (Свойства) правила web-публикации состоит из 12 вкладок:
Рассмотрим параметры каждой из вкладок. Вы увидите, что здесь есть множество опций, не задействованных в мастере.
Здесь вы можете изменить наименование правила, введя новое имя в поле Name (Имя). Также вы можете ввести описание правила в поле Description (optional) (Описание (не обязательно)). Вы можете включить или выключить правило с помощью переключатели Enable (Включить).
3940Рисунок 2: Вкладка General (Общие)
Здесь вы можете разрешить (Allow) или запретить (Deny) доступ к сайту, настроенному в правиле. Также есть параметр Log requests matching this rule (Записывать в журнал запросы, удовлетворяющие правилу). Если вы обнаружите, что файлы журналов стали слишком большими, а сайт, доступ к которому осуществляется по данному правилу, не представляет для вас серьезного интереса, вы можете отключить запись запросов, обрабатываемых данным правилом, в журнал. Однако, мы не рекомендуем отключать журналирование у всех правил, поскольку большинство из них обрабатывают соединения из недоверительных сетей.
Нажмите Apply (Применить) для сохранения изменений.
Рисунок 3: Вкладка Action (Действие)
Здесь вы настраиваете, откуда правилом будут приниматься соединения к опубликованным сайтам. Значение по умолчанию – Anywhere (Отовсюду), что значит, что любой узел имеет доступ к IP-адресу или адресам web-приемника, использующегося в правиле публикации.
Можно ограничить доступ к правилу, выделив запись Anywhere (Отовсюду), а затем нажав Remove (Удалить). После удаления нажмите Add (Добавить). В диалоговом окне Add Network Entities (Добавить сетевые элементы) щелкните по папке с теми сетевыми объектами, которым вы хотите разрешить доступ к правилу.
Здесь же вы можете подстроить доступ, установив исключения в разделе Exceptions (Исключения). Например, вы захотите разрешить доступ к правилу всем сетям, за исключением узлов, расположенные в одной сети с опубликованным сервером. В целом, это весьма правильная мысль, поскольку таким образом узлы корпоративной сети не будут использовать замыкание через ISA-сервер при доступе к ресурсам корпоративной сети.
После изменений нажмите Apply (Применить).
Рисунок 2: Вкладка From (От)
Это одна из самых важных вкладок диалогового окна Properties (Свойства). Дело в том, что запись в поле Server (Сервер) определяет имя узла в адресе URL, который правило отсылает на опубликованный web-сайт. Значение поля Server (Сервер) заменяет заголовок узла, включенный в первоначальный запрос клиента, отсылаемый на ISA-сервер. Если вы не хотите, чтобы ISA-сервер заменял запись в заголовке узла значением поля Server (Сервер), отметьте параметр Forward the original host header instead of the actual one (specified above) (Передавать оригинальный заголовок узла вместо актуального (указан выше)).
Важно отметить, что в сервере ISA 2006 присутствуют значительные улучшения, уменьшающие сложность настройки вкладки To (К).
Еще одним важным параметром этой вкладки является возможность указания того, как ISA-сервер переводит запросы на сервер, обозначенный в поле Server (Сервер). Есть два варианта:
Вариант Requests appear to come from the ISA Server computer (Запросы считаются приходящими от ISA-сервера) полезен при нежелании сделать опубликованный web-сервер клиентом SecureNAT. Одним из главных недостатков использования клиента SecureNAT является то, что вся инфраструктура маршрутизации должна знать, что ISA-сервер является шлюзом для выхода в Интернет. Во многих организациях установлены инфраструктура маршрутизации, и они не хотят сделать ISA-сервер единственным маршрутом для всех узлов сети. Можно решить эту проблему, разрешив ISA-серверу заменять IP-адреса удаленных узлов своим собственным. Если опубликованный сервер возвращает ответ на запрос, единственное, что нужно, это знать маршрут к локальному интерфейсу ISA-сервера. Не нужен маршрут в Интернет, а ISA-сервер можно не делать собственным шлюзом по умолчанию.
Вариант Request appear to come from the original client (Запросы считаются приходящими от изначального клиента) позволяет ISA-серверу сохранять IP-адрес удаленного узла, отправляющего запросы к ресурсам опубликованного web-сайта. Преимуществом такого подхода является, в случае наличия программы для ведения журналов на самом web-сервере, возможность получения актуальных IP-адресов узлов, соединяющихся с web-сайтом. Если вы не выберите этот вариант, то в журнале web-сайта все соединения будут обозначены, как приходящие с IP-адреса ISA-сервера.
Однако, при таком подходе возникает проблема. Если вы включите обратный прокси для опубликованного web-сайте, вы заметите несколько запросов, идущих от самого ISA-сервера и можете неправильно подумать, что ISA-сервер не может сохранить IP-адрес узла, инициировавшего запрос. Это не так, и в данном случае это не является недоработкой или ошибкой ISA-сервера. Дело в том, что при использовании обратного прокси ISA-сервер обрабатывает запросы с помощью собственного кэша. Однако, ISA-сервер, в роли обратного прокси-сервера, должен проверять статус объектов, расположенных на web-сайте, и именно эти проверки статусов создают запросы с адреса ISA-сервера к опубликованному сайту, что, в свою очередь, и отображается в журналах.
По этой и другим причинам мы всегда предпочитаем, чтобы анализ активности web-сайта отражался в журналах службы web-прокси ISA-сервера, а не в журналах самого сайта. Из данного правила есть исключения, однако, в том, что касается открытых сайтов, к которым у внутренних пользователей нет доступа, журналы web-прокси ISA-сервера предоставляют более подробную и более точную информацию.
Рисунок 5: Вкладка To (К)
Здесь вы видите список протоколов, разрешенных данных правилом web-публикации. Протоколы на данной вкладке не настраиваются. Разрешенные протоколы определяются поддержкой протоколов, установленной на web-приемнике данного правила.
В данном примере опция Notify HTTP users to use HTTPS instead (Сообщить HTTP-пользователям об использовании HTTPS) недоступна, поскольку мы не используем SSL-приемник. Когда эта опция доступна, мы может разрешить ISA-серверу возвращать пользователю окно с ошибкой о необходимости использования протокола HTTPS вместо HTTP при попытке пользователя получить доступ к web-сайту через правило web-публикации. Это обычная ошибка пользователей, которые вводят HTTP вместо HTTPS при доступе к защищенным web-сайтам. По счастью, добавление буквы «s» в протокол занимает не слишком много времени. Необходимость использования пользователями правильных протоколов повысит Интернет-гигиену пользователей.
Опция Require 128-bit encryption for HTTPS traffic (Необходимо 128-битное шифрование для HTTPS-трафика) также недоступна, поскольку правило не применяется для SSL-публикации. Данная опция позволяет вам контролировать уровень шифрования SSL-соединений с опубликованным web-сайтом. Все современные клиенты Windows поддерживают 128-битное шифрование по умолчанию, однако старые клиенты Windows и не-Windows клиенты могут не поддерживать 128-битное шифрование, и, возможно, вы захотите блокировать соединения этих незащищенных клиентов.
Важно отметить, что работа данных опций немного отличается в сервере ISA 2006. Обратитесь к блогу Стефана Посееле по адресу http://blogs.isaserver.org/ для получения дополнительной информации по данной проблеме.
Нажмите Apply (Применить) для сохранения изменений на данной вкладке.
Рисунок 6: Вкладка Traffic (Трафик)
Здесь вы можете просмотреть настройки приемника, использующегося в правиле web-публикации. Здесь же вы можете изменить настройки приемника, нажав на кнопку Properties (Свойства). Нажав на кнопку New (Новый) вы можете создать новый приемник и применить его в данном правиле.
Если вы уже создали несколько web-приемников на ISA-сервере, вы можете изменить приемник, использующийся в данном правиле, выбрав необходимый из выпадающего списка This rule applies to requests received on the following listener (Данное правило применяется к запросам, полученным на следующий приемник).
Нажмите Apply (Применить) для сохранения изменений на вкладке Listener (Приемник).
Рисунок 7: Вкладка Listener (Приемник)
Здесь вы можете просмотреть и настроить общие имена, использующиеся для доступа к web-серверу через правило web-публикации. В созданном нами правиле для доступа к web-серверу с помощью используется имя www.msfirewall.org. Если запрос, приходящий на web-приемник данного правила, содержит имя FQDN отличное от этого, правило проигнорирует этот запрос на соединение.
Обратите внимание, что если web-приемник используется другим правилом, входящие запросы будут сравниваться с записями поля Public Name (Общее имя) во всех этих правилах. Если запись поля Public Name (Общее имя) ни в одном из правил не совпадает с заголовком узла входящего web-запроса, соединение обрывается.
Одно правило web-публикации можно использовать для нескольких имен узлов. Главное правило – убедиться, что каждое из этих имен разрешается в IP-адрес или адреса web-приемника, привязанного к этому правилу.
Например, web-приемник правила прослушивает IP-адрес, в который разрешаются имена www.msfirewall.org и www.tacteam.net. В этом случае мы можем добавить имя www.tacteam.net в список Public Name (Общее имя). Однако, это значит, что настройки Paths (Пути), Bridging (Сопряжение), Users (Пользователи), Schedule (Расписание) и другие будут применяться к соединениям к сайтом www.tacteam.net. Это не всегда нужно, поэтому мы рекомендуем создавать отдельное правило для каждого публикуемого сайта.
Вы можете добавить новое имя в список с помощью кнопки Add (Добавить), а также удалить или редактировать выбранное имя с помощью кнопок Remove (Удалить) и Edit (Редактировать) соответственно.
Нажмите Apply (Применить) для сохранения изменений.
Рисунок 8: Вкладка Public Name (Общее имя)
Здесь вы указываете, как запросы к разным путям, включенным в запрос, управляются правилом. В списке путей вы увидите две колонки: External Path (Внешний путь) и Internal Path (Внутренний путь).
Внешний путь – это путь в запросе, сделанном пользователем, соединяющимся с сайтом через данное правило web-публикации. Например, если пользователь вводит в браузер путь http://www.msfirewall.org/docs, то внешним путем будет /docs. Если пользователь вводит путь http://www.tacteam.net/graphics, внешним путем будет /graphics.
Внутренний путь – это путь, на который ISA-сервер переадресует запрос, основываясь на записи External path (Внешний путь). Например, предположим, что мы установили внешним путем /docs, а внутренним /publicdocuments. Когда пользователь вводит адрес http://www.msfirewall.org/docs, web-приемник ISA-сервера для данного правила принимает соединение по данному запросу, а ISA-сервер переадресует запрос на сайт, указанный на вкладке To (К) с путем /publicdocuments. Если запись на вкладке To (К) – 10.0.0.2, то ISA-сервер будет переадресовывать запросы на опубликованный web-сервер на http://10.0.0.2/publicdocuments.
Переадресация путей дает вам достаточную гибкость правил web-публикации и позволяет вам упростить пути, которые используют внешние пользователи для доступа к опубликованным ресурсам без необходимости изменения имен каталогов опубликованного web-сервера.
Если вы хотите получить доступ ко всем файлам и папкам отдельной директории, введите путь в формате /path/*. Если вы хотите разрешить доступ к единственному файлу, введите путь к формате /path. Например, если вы хотите разрешить доступ ко всем файлам в папке documents web-севера, введите в качестве внутреннего пути /documents/*. Если вы хотите разрешить доступ только к файлу names.htm в папке documents, введите /documents/names.htm.
Рисунок 9: Вкладка Paths (Пути)
Нажмите Add (Добавить) для добавления нового пути. В диалоговом окне Path mapping (Сопоставление путей), введите внутренний путь в поле Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank (Укажите папку web-сайта, которую вы ходите опубликовать. Для публикации всего сайта оставьте это поле пустым). Теперь, выберите либо Same as published folder (Такой же, как опубликованная папка) или The following folder (Следующая папка). Если внешними пользователями будет использоваться тот же самый путь, выберите первый вариант. Если пользователи будут вводить другой путь, выберите второй вариант и введите альтернативный путь.
Рисунок 10: Сопоставление путей
совет по использавнию ISA-сервера:
Многие администраторы ISA-сервера хотят сделать переадресацию в корень web-сайта для путей, введенных пользователями. Например, если пользователь вводит адрес http://www.msfirewall.org/firewalldocs, переадресация будет осуществлена в корень внутреннего web-сервера 10.0.0.2. Сделать это можно, введя внешним путем /firewalldocs/*, а внутренним — / (Рисунок 11). Все соединения с каталогом firewalldocs будут переадресованы в корень сервера, указанного на вкладке To (К), т.е. в нашем случае это 10.0.0.2.
Рисунок 11: Переадресация в корень web-сайта
Обычно администраторы хотят использовать переадресацию соединений с корнем сайта для доступа к папке /Exchange сайта Outlook Web Access (OWA). Это легко сделать с помощью переадресации путей на вкладке Paths (Пути). В этом случае внешним путем будет /*, а внутренним — /Exchange\. Обратите внимание, что вы должны использовать обратный слэш в конце пути, поскольку уже существует запись /Exchange/, которая создалась после запуска мастера публикации почтового сервера. Настройки путей для OWA в этом случае будут выглядеть, как на Рисунке 12.
ВНИМАНИЕ: Этот способ не работает в сервере ISA 2006. Для правильной работы такой конфигурации OWA вы должны использовать запрещающее правило web-публикации с переадресацией.
Причина работы таких установок в том, что сайт OWA любезно помогает невезучим пользователям, которые не понимают разницы между путями UNC и HTTP. Сайт OWA принимает обратный слэш за правильный запрос и конвертирует его в прямой слэш. Таким образом, в колонке Internal Path (Внутренний путь) вы можете использовать пути /Exchange\ и /exchange/*, что было бы невозможно, если бы в обоих случаях использовался прямой слэш, поскольку ISA-сервер не разрешает создавать несколько привязок путей с одинаковым префиксом пути.
Рисунок 12: Связь корневой папки сайта OWA и папки Exchange
Помимо всего этого вы можете осуществлять переадресацию на другие серверы. Для примера возьмем следующие адреса:
Все три URL указывают на одно и то же имя FQDN и различаются только путем. Вы можете создать три правила web-публикации, каждое из которых будет использовать одно и то же открытое имя, и каждое будет использовать разные пути и различные серверы на вкладке To (К). Когда пользователь будет запрашивать один из этих URL, запрос будет переадресовываться на правильный сервер на основе установок вкладок Public Name (Общее имя), Paths (Пути) и To (К).
На этой вкладке вы можете настроить переадресацию порта или протокола для правила web-публикации. Здесь есть следующие опции:
Опция Web Server (Web-сервер) позволяет вам настраивать правило на переадресацию HTTP или HTTPS запросов как HTTP или HTTPS запросы. Переадресация протоколов не используется.
Опция Redirect requests to HTTP port (Переадресовывать запросы на HTTP-порт) позволяет вам переадресовывать входящие HTTP-запросы для данного правила и web-приемника на опубликованный web-сервер с помощью порта, указанного справа от опции. По умолчанию это 80 порт. Вы может выбрать любой другой порт. Таким образом, вы можете использовать любые номера портов на опубликованном web-сайте, хотя приниматься соединения будут на порту по умолчанию, указанному в настройках web-приемника (хотя вам необязательно использовать на web-приемнике порт по умолчанию, если вы настроили приемник на использование альтернативного порта).
Опция Redirect requests to SSL port (Переадресовывать запросы на SSL-порт) позволяет вам переадресовывать запросы на указанный SSL-порт. Обратите внимание, что вы можете выбрать и HTTP, и SSL порты одновременно. В этом случае входящий трафик будет маршрутизироваться через соответствующий протокол и порт. Например, если входящий запрос является HTTP-запросом, он будет переадресовываться на HTTP-порт. Если входящий запрос является SSL-запросом, он будет переадресовываться на SSL-порт. Вы можете изменить SSL-порт, на который переадресуется запрос, что позволит вам использовать SSL-публикацию на альтернативных портах.
Одной из неправильно интерпретируемых опций настроек ISA-сервера является опция Use a certificate to authenticate to the SSL Web server (Использовать пользовательский сертификат для аутентификации на SSL web-сервере). Данная опция не используется ISA-сервером для приема входящих SSL-соединений пользователей, соединяющихся с опубликованным web-сервером. Данная опция позволяет настроить ISA-сервер для предоставления пользовательского сертификата опубликованному web-сайту, если сайт требует аутентификацию с помощью пользовательского сертификата. Пользовательский сертификат привязан к службе брандмауэра ISA-сервера и позволяет ISA-серверу предоставлять сертификат web-сайту.
Опция FTP server (FTP-сервер) позволяет правилу производить переадресацию протокола. Входящий запрос может быть либо HTTP, либо HTTPS, а соединение переадресуется как FTP GET–запрос на опубликованный FTP-сайт. Использование SSL- FTP сопряжения полезно при предоставлении удаленного доступа к FTP-сайтам, требующим аутентификации. Поскольку FTP-сайты поддерживают только базовую аутентификацию, вы можете защитить пользовательские учетные данные с помощью SSL-канала с внешним интерфейсом ISA-сервера.
Рисунок 13: Вкладка Bridging (Сопряжение)
Здесь вы можете настроить, какие пользователи могут получать доступ к опубликованному web-сайту через данное правило. При установке All Users (Все пользователи) любой пользователь может получить доступ к сайту через ISA-сервер. Однако, это означает, что все пользователи могут пройти через ISA-сервер и их неаутентифицированный запрос переадресован на опубликованный сайт. Сам сайт может требовать аутентификацию. Пользователю в этом случае придется аутентифицировать себя на сайте.
Вы можете потребовать аутентификацию на ISA-сервере, удалив группу All Users (Все пользователи) и добавив необходимых пользователей с помощью кнопки Add (Добавить). По умолчанию на ISA-сервере используются группы All Users (Все пользователи), All Authenticated Users (Все аутентифицированные пользователи) и System and Network Service (Системные и сетевые службы). Вы можете добавить собственную группу отстроить схему аутентификации.
Рисунок 14: Вкладка Users (Пользователи)
Возможность аутентификации пользователей на ISA-сервер дает значительное преимущество в вопросах безопасности. Аутентификация на ISA-сервере защищает опубликованный web-сервер от неаутентифицированных соединений. Злоумышленники и вредоносное программное обеспечение потенциально могут использовать неаутентифицируемое соединение для атаки опубликованного сервера. Аутентификация на ISA-сервер уничтожает связанные с этим риски.
Обратите внимание, что вы можете также потребовать аутентификацию и на web-сайте, и пользователи должны будут проходить аутентификацию и на ISA-сервере, и на сайте. В некоторых случаях пользователь увидит два окна для регистрации: первое – запрос аутентификации на ISA-сервере, второе – на опубликованном web-сайте.
Вы можете исключить двойную регистрацию, воспользовавшись преимуществом одной подписи, предлагаемым функцией делегирования базовой аутентификации ISA-сервера. Данная функция включается при выборе параметра Forward Basic authentication credentials (Basic delegation) (Переадресовывать учетные данные базовой аутентификации (Базовое делегирование)).
Делегирование базовой аутентификации позволяет пользователям проходить регистрироваться на ISA-сервере с помощью базовой аутентификации. ISA-сервер аутентифицирует пользователя. Если попытка аутентификации успешна, запрос переадресуется на опубликованный web-сайт. Если сайт запрашивает учетные данные, ISA-сервер переадресует учетные данные, предоставленные пользователем при успешной аутентификации на ISA-сервере.
Вам необходимо включить базовую аутентификацию на web-приемнике правила, и web-сайт также будет требовать использования базовую аутентификацию
ВНИМАНИЕ: Для правильной работы делегирования базовой аутентификации ISA-сервер должен быть членом домена. В большинстве случаев самой безопасной и самой гибкой конфигурацией является та, где ISA-сервер является членом домена. Существует немного вариантов, в которых ISA-сервер не должен быть членом домена. Хотя это может показаться некоторым читателям вызовом «здравому смыслу», помните, что в свое время «здравым смыслом» считалось утверждение, что Земля — плоская.
Здесь вы можете настроить расписание, по которому пользователи могут соединяться с опубликованным web-сайтом. По умолчанию есть три расписания:
Также вы можете создать собственное расписание.
Рисунок 15: Вкладка Schedule (Расписание)
Возможность перевода ссылок позволяет вам переписывать URL, возвращаемые опубликованными web-серверами. Переписывание URL полезно при публикации web-сайтов, в чьем коде указаны ссылки, недоступные внешним пользователям.
Для примера предположим, что пользователь зашел на сайт с помощью адреса www.msfirewall.org. На начальной странице сайта есть ссылки на адреса http://server1/users и http://server1/computers. Если Интернет-пользователь нажмет на одну из этих ссылок, соединение не установится, поскольку Интернет-пользователь не сможет правильно разрешить имя server1 в IP-адрес внешнего интерфейс ISA-сервера.
Функция перевода ссылок позволяет вам переписать ссылки и заменить имя server1 на www.msfirewall.org. Когда web-сервер возвращает домашнюю страницу сайта www.msfirewall.org, внешний пользователь больше не увидит URL с записью server1, поскольку ISA-сервер переписал эти URL на использование www.msfirewall.org вместо server1. Внешний пользователь теперь может щелкнуть по ссылке и получить доступ к содержимому web-сервера.
Рисунок 16: Вкладка Link Translation (Перевод ссылок)
В данной, последней, части статьи о создании правил web-публикации без использования SSL мы закончили работу с мастером создания нового правила web-публикации и рассмотрели свойства созданного правила. Теперь, пользуясь полученной информацией, вы можете создавать почти любые правила web-публикации без SSL. Если что-то осталось непонятным, задайте мне вопрос в web-форуме. Я попытаюсь ответить на ваш вопрос так быстро, как только смогу. Спасибо!
www.isaserver.org
Tags: Exchange, forward, ftp, ISA Server, nat, redirect, traffic