обеспечение безопасности Exchange с помощью ISA Server 2004
Вас привлекает возможность работы Exchange Server 2003 через Интернет? Отличный выбор, однако вам следует знать о проблемах с безопасностью такой работы. В руках хакеров множество методов и программ, представляющих собой реальную угрозу вашему Exchange Server. Ситуацию мог бы спасти Outlook Web Access, если бы он не имел подобных проблем с безопасностью. Также не стоит забывать тот факт, что иногда требуется дать полный доступ клиентам Microsoft Outlook, а Web Access не может этого позволить.
Эта статья расскажет о проблемах безопасности, связанных с Outlook Web Access или полной версией Outlook, а затем обсудит, как настроить ISA Server 2004 чтобы минимизировать угрозу. Мы начнем с Outlook Web Access (OWA), как самого простого решения.
Но до того, как мы начнем, имейте ввиду, что эта статья не обсуждает безопасность агента передачи сообщений (MTA) сервера Exchange. Вместо этого мы рассмотрим, как обезопасить удаленные соединения пользователей с сервером.
безопасность Outlook Web Access с помощью ISA 2004
Некоторые пользователи могут обходиться только Outlook Web Access, достойным инструментом, имитирующим интерфейс Outlook в браузере. Однако существует много претензий к Outlook Web Access в плане безопасности.
Как можно улучшить ситуацию с безопасностью? OWA может использовать HTTPS – безопасную, туннелированную версию HTTP – но в ней отсутствует способность обнаружения вторжения. Более проблематично то, что все версии OWA, кроме последних, не имеют свойства блокировки по времени (timeout), так что ваши пользователи будут оставаться зарегистрированными в системе, пока не нажмут на “Выход”. Представьте себе Интернет-кафе и вашего финансового директора, проверяющего почту через OWA. Он просто закрывает браузер после прочтения почты, но человек, охотящийся за информацией, откроет браузер и зайдет на последнюю посещенную страницу и получит доступ к важному почтовому ящику. Это скверная ситуация, и она уже случалась прежде.
потребность в ISA 2004
Чтобы обезопасить OWA, администратору нужно проделать следующие шаги:
- Проверять весь SSL-трафик на уровне приложений, чтобы отличить настоящий трафик от постороннего. Это предотвратит значительную часть современных атак.
- Соблюдать конфиденциальность передаваемых данных – важная информация часто передается по электронной почте.
- Блокировать атаки, связанные с URL, пропуская только известные URL. Это обезопасит вас от атак, выполняющих различные действия со скриптами, посылающих большое количество символов и использующих другую кодировку.
Если соблюдать эти правила, то в целом можно быть уверенным, что информация, проходящая через OWA, будет в безопасности.
ISA Server 2004 поможет вам осуществить вышеизложенное. Когда вы поставите ISA Server перед сервером/серверами OWA, ISA станет бастионом на пути в глобальную сеть, обрезая все соединения с помощью Web Proxy, расшифровывая весь HTTPS-трафик, чтобы исследовать содержимое пакетов, проверяя URL с помощью URLScan и окончательно шифруя весь трафик, отсылая его на сервер OWA.
упреждающее опознание соединений
ISA 2004 предоставляет еще одну выгоду: упреждающее опознание соединений. Вот как оно работает: сервер ISA сам предоставляет формы пользователю для заполнения – например, окно входа в систему. Форма получает информацию от пользователя, и сервер ISA проверяет ее через Active Directory. Заметим, что серверы RADIUS также поддерживаются, так что ISA-системы, которые не доверяют или не являются членами домена, все равно могут производить аутентификацию. Затем ISA берет информацию и вставляет ее в хедеры обычных HTTP-пакетов, которые он отправляет серверу OWA, так что пользователь не должен повторно вводить информацию. В итоге, ISA проверяет ваших пользователей формой OWA, опознавая их в пределах вашей внутренней сети до того, как пакеты достигнут настоящего сервера OWA.
Рис. 1.
Подробная информация по реализации подобной системы доступна в пошаговой инструкции компании Microsoft. Называется эта инструкция так: How to publish an SSL Web site by using SSL tunneling in ISA Server 2004.
проблемы с клиентами Outlook и VPN
Виртуальная частная сеть (VPN), клиенты которой присутствуют во всех версиях Windows, - обычный выбор тех, кто нуждается в предоставлении полной функциональности Outlook в сети Интернет. Однако безопасность VPN также оставляет желать лучшего: хотя PPTP можно сделать безопасным, для этого потребуется хорошее знание методов шифрования данных. Конечно, есть и чисто логические препятствия для использования сетей VPN – они просто не будут работать в некоторых общественных местах из-за правил сетевых фильтров, блокирующих нужные порты, проблемы с использованием IPSec и L2TP из-за фрагментации пакетов. Возможны и другие проблемы. Так что, на мой взгляд, лучшим решением по безопасности будет все таки установка Microsoft ISA Server 2004.
особенности безопасности Exchange 2003
Exchange 2003 позволяет расширить функциональность почтовой системы с помощью RPC-over-HTTP. RPC-over-HTTP является выгодным дополнением к продукту, поскольку позволяет помещать RPC-запросы в протокол HTTP, под который настроены большинство сетевых фильтров. RPC-over-HTTP полагается на элемент Server 2003, называемый RPC Proxy, ISAPI-расширение, работающее под IIS, которое устанавливает RPC-сессию после аутентификации. Изначально клиент Outlook соединяется с фильтром при помощи RPC-over-HTTP, а затем обрезает “over-HTTP”, выдирает RPC-запросы и отсылает их серверу Exchange.
Однако, RPC-over-HTTP не является панацеей. Он поддерживает лишь обычную HTTP-аутентификацию (basic HTTP-authentication), так что вам придется проверить, использует ли HTTP-соединение SSL. Также здесь нет поддержки SecurID. Аутентификация с помощью RADIUS также невозможна по RPC-over- HTTP, равно как и использование сертификатов. Так что, в то время как RPC-over-HTTP решает некоторые проблемы с функциональностью и безопасностью, у этой технологии имеется и некоторое количество недостатков.
ISA 2004 и RPC-фильтр Exchange
В стандартную поставку ISA 2004 входит RPC-фильтр для Exchange, который включает в себя лучшее от RPC Proxy. RPC-фильтр создан со знанием способов установления соединения Exchange RPC и правильного формата для этого протокола. Также он позволяет только передачу Exchange RPC UUID. Вот как все работает:
- Клиент соединяется с portmapper RPC-фильтра. Вообще-то это не настоящий portmapper, он всего лишь ведет себя подобным образом, отвечая только на RPC-запросы сервера Exchange, что позволяет сократить количество атак.
- Как только соединение установлено, сервер ISA возвращает номера портов RPC-фильтра.
- Клиент, располагая информацией о портах, авторизуется на сервере. В ходе этого процесса Exchange передает информацию Active Directory, которая решает – пустить пользователя или нет.
- RPC-фильтр на сервере ISA все это время наблюдает за процессом, ожидая подтверждения от Active Directory. Получив положительный ответ, фильтр удостоверяется, что соединение шифруется, и затем клиент, наконец, увидит свой почтовый ящик :).
Следует заметить, что весь процесс скрыт от клиента. Он увидит форму, запрашивающую имя и пароль, когда откроет Outlook. После того, как он введет свои имя и пароль, пройдет буквально пять секунд, и он сможет смотреть свою почту. Так что одно из основных достоинств этого метода – прозрачность для пользователя, упрощение работы.
Этот вариант заодно защитит вас от различных атак, основанных на использовании уязвимостей RPC. Например, ISA RPC-фильтр устойчив против разведывательных атак и атак отказа в обслуживании в отношении сервиса portmapper. Все известные атаки проваливаются, но даже если атака успешно проникла через RPC-фильтр, имейте ввиду, что Exchange все равно защищен, так как ISA стоит на входе, проверяя все соединения к серверу Exchange. Этот вариант также непроницаем для атак на сервисы, в основном потому, что такие атаки требуют разведанную информацию, которую они получить не могут. И наконец, часть соединения, связывающая ISA с Exchange, просто умирает, если первая часть соединения (клиент к ISA) неправильного формата.
Как бы вы осуществили подобный вариант? На рисунке 2 показан пример сети, с сервером ISA в демилитаризованной зоне, защищающим серверы Exchange и Active Directory.
Рис. 2.
Jonathan Hassell.
Эта статья расскажет о проблемах безопасности, связанных с Outlook Web Access или полной версией Outlook, а затем обсудит, как настроить ISA Server 2004 чтобы минимизировать угрозу. Мы начнем с Outlook Web Access (OWA), как самого простого решения.
Но до того, как мы начнем, имейте ввиду, что эта статья не обсуждает безопасность агента передачи сообщений (MTA) сервера Exchange. Вместо этого мы рассмотрим, как обезопасить удаленные соединения пользователей с сервером.
безопасность Outlook Web Access с помощью ISA 2004
Некоторые пользователи могут обходиться только Outlook Web Access, достойным инструментом, имитирующим интерфейс Outlook в браузере. Однако существует много претензий к Outlook Web Access в плане безопасности.
Как можно улучшить ситуацию с безопасностью? OWA может использовать HTTPS – безопасную, туннелированную версию HTTP – но в ней отсутствует способность обнаружения вторжения. Более проблематично то, что все версии OWA, кроме последних, не имеют свойства блокировки по времени (timeout), так что ваши пользователи будут оставаться зарегистрированными в системе, пока не нажмут на “Выход”. Представьте себе Интернет-кафе и вашего финансового директора, проверяющего почту через OWA. Он просто закрывает браузер после прочтения почты, но человек, охотящийся за информацией, откроет браузер и зайдет на последнюю посещенную страницу и получит доступ к важному почтовому ящику. Это скверная ситуация, и она уже случалась прежде.
потребность в ISA 2004
Чтобы обезопасить OWA, администратору нужно проделать следующие шаги:
- Проверять весь SSL-трафик на уровне приложений, чтобы отличить настоящий трафик от постороннего. Это предотвратит значительную часть современных атак.
- Соблюдать конфиденциальность передаваемых данных – важная информация часто передается по электронной почте.
- Блокировать атаки, связанные с URL, пропуская только известные URL. Это обезопасит вас от атак, выполняющих различные действия со скриптами, посылающих большое количество символов и использующих другую кодировку.
Если соблюдать эти правила, то в целом можно быть уверенным, что информация, проходящая через OWA, будет в безопасности.
ISA Server 2004 поможет вам осуществить вышеизложенное. Когда вы поставите ISA Server перед сервером/серверами OWA, ISA станет бастионом на пути в глобальную сеть, обрезая все соединения с помощью Web Proxy, расшифровывая весь HTTPS-трафик, чтобы исследовать содержимое пакетов, проверяя URL с помощью URLScan и окончательно шифруя весь трафик, отсылая его на сервер OWA.
упреждающее опознание соединений
ISA 2004 предоставляет еще одну выгоду: упреждающее опознание соединений. Вот как оно работает: сервер ISA сам предоставляет формы пользователю для заполнения – например, окно входа в систему. Форма получает информацию от пользователя, и сервер ISA проверяет ее через Active Directory. Заметим, что серверы RADIUS также поддерживаются, так что ISA-системы, которые не доверяют или не являются членами домена, все равно могут производить аутентификацию. Затем ISA берет информацию и вставляет ее в хедеры обычных HTTP-пакетов, которые он отправляет серверу OWA, так что пользователь не должен повторно вводить информацию. В итоге, ISA проверяет ваших пользователей формой OWA, опознавая их в пределах вашей внутренней сети до того, как пакеты достигнут настоящего сервера OWA.
Рис. 1.
Подробная информация по реализации подобной системы доступна в пошаговой инструкции компании Microsoft. Называется эта инструкция так: How to publish an SSL Web site by using SSL tunneling in ISA Server 2004.
проблемы с клиентами Outlook и VPN
Виртуальная частная сеть (VPN), клиенты которой присутствуют во всех версиях Windows, - обычный выбор тех, кто нуждается в предоставлении полной функциональности Outlook в сети Интернет. Однако безопасность VPN также оставляет желать лучшего: хотя PPTP можно сделать безопасным, для этого потребуется хорошее знание методов шифрования данных. Конечно, есть и чисто логические препятствия для использования сетей VPN – они просто не будут работать в некоторых общественных местах из-за правил сетевых фильтров, блокирующих нужные порты, проблемы с использованием IPSec и L2TP из-за фрагментации пакетов. Возможны и другие проблемы. Так что, на мой взгляд, лучшим решением по безопасности будет все таки установка Microsoft ISA Server 2004.
особенности безопасности Exchange 2003
Exchange 2003 позволяет расширить функциональность почтовой системы с помощью RPC-over-HTTP. RPC-over-HTTP является выгодным дополнением к продукту, поскольку позволяет помещать RPC-запросы в протокол HTTP, под который настроены большинство сетевых фильтров. RPC-over-HTTP полагается на элемент Server 2003, называемый RPC Proxy, ISAPI-расширение, работающее под IIS, которое устанавливает RPC-сессию после аутентификации. Изначально клиент Outlook соединяется с фильтром при помощи RPC-over-HTTP, а затем обрезает “over-HTTP”, выдирает RPC-запросы и отсылает их серверу Exchange.
Однако, RPC-over-HTTP не является панацеей. Он поддерживает лишь обычную HTTP-аутентификацию (basic HTTP-authentication), так что вам придется проверить, использует ли HTTP-соединение SSL. Также здесь нет поддержки SecurID. Аутентификация с помощью RADIUS также невозможна по RPC-over- HTTP, равно как и использование сертификатов. Так что, в то время как RPC-over-HTTP решает некоторые проблемы с функциональностью и безопасностью, у этой технологии имеется и некоторое количество недостатков.
ISA 2004 и RPC-фильтр Exchange
В стандартную поставку ISA 2004 входит RPC-фильтр для Exchange, который включает в себя лучшее от RPC Proxy. RPC-фильтр создан со знанием способов установления соединения Exchange RPC и правильного формата для этого протокола. Также он позволяет только передачу Exchange RPC UUID. Вот как все работает:
- Клиент соединяется с portmapper RPC-фильтра. Вообще-то это не настоящий portmapper, он всего лишь ведет себя подобным образом, отвечая только на RPC-запросы сервера Exchange, что позволяет сократить количество атак.
- Как только соединение установлено, сервер ISA возвращает номера портов RPC-фильтра.
- Клиент, располагая информацией о портах, авторизуется на сервере. В ходе этого процесса Exchange передает информацию Active Directory, которая решает – пустить пользователя или нет.
- RPC-фильтр на сервере ISA все это время наблюдает за процессом, ожидая подтверждения от Active Directory. Получив положительный ответ, фильтр удостоверяется, что соединение шифруется, и затем клиент, наконец, увидит свой почтовый ящик :).
Следует заметить, что весь процесс скрыт от клиента. Он увидит форму, запрашивающую имя и пароль, когда откроет Outlook. После того, как он введет свои имя и пароль, пройдет буквально пять секунд, и он сможет смотреть свою почту. Так что одно из основных достоинств этого метода – прозрачность для пользователя, упрощение работы.
Этот вариант заодно защитит вас от различных атак, основанных на использовании уязвимостей RPC. Например, ISA RPC-фильтр устойчив против разведывательных атак и атак отказа в обслуживании в отношении сервиса portmapper. Все известные атаки проваливаются, но даже если атака успешно проникла через RPC-фильтр, имейте ввиду, что Exchange все равно защищен, так как ISA стоит на входе, проверяя все соединения к серверу Exchange. Этот вариант также непроницаем для атак на сервисы, в основном потому, что такие атаки требуют разведанную информацию, которую они получить не могут. И наконец, часть соединения, связывающая ISA с Exchange, просто умирает, если первая часть соединения (клиент к ISA) неправильного формата.
Как бы вы осуществили подобный вариант? На рисунке 2 показан пример сети, с сервером ISA в демилитаризованной зоне, защищающим серверы Exchange и Active Directory.
Рис. 2.
Jonathan Hassell.
Сетевые решения. Статья была опубликована в номере 05 за 2005 год в рубрике save ass…
