Для публикации Web-сервисов Exchange использует IIS, который вполне может подойти для работы в локальной сети или через VPN-подключение, но никак не для открытого доступа через интернет. В данном случае намного более защищенным является web-сервер apache.
В этой статье речь пойдет о подключении мобильных ActiveSync устройств в серверу Microsoft Exchange 2007 используя реверс-прокси на Apache 2.2. Как показано на рисунке ниже у нас имеется установленный в локальной сети Exchange 2007 Server, в DMZ установлен сервер на базе CentOS 5.5.
1. Создание сертификатов.
Для настройки apache с поддержкой SSL/TLS нам понадобится сертификат сервера и закрытый ключ, здесь может быть множество различных вариантов начиная от импорта сетификата из ActiveDirectory и кончая сертификатами подписанными в VeriSign. В статье я рассмотрю только базовый случай с самоподписанным сертификатом.
Генерируем закрытый ключ:
[root@localhost ~]# openssl genrsa -out ca.key 1024 Generating RSA private key, 1024 bit long modulus .............++++++ .........++++++ e is 65537 (0x10001)
Создаем запрос на сертификат:
[root@localhost etc]# openssl req -new -key ca.key -out ca.csr ...................... Country Name (2 letter code) [GB]:RU State or Province Name (full name) [Berkshire]:Russia Federation Locality Name (eg, city) [Newbury]:Moscow Organization Name (eg, company) [My Company Ltd]:MyCompany Organizational Unit Name (eg, section) []:Office Common Name (eg, your name or your server's hostname) []:activesync.mydomain.global Email Address []:support@mydomain.global Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Генерируем самоподписанный сертификат:
[root@localhost ~]# openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt Signature ok subject=/C=RU/ST=Russia Federation/L=Moscow/O=MyCompany/OU=Office/CN=activesync.mydomain.global/emailAddress=support@mydomain.global Getting Private key
Переносим файлы ca.crt и ca.key в соответствующие директории:
[root@localhost ~]# mv ca.key /etc/pki/tls/private [root@localhost ~]# mv ca.crt /etc/pki/tls/certs
2. Настройка apache
Устанавливаем apache и mod_ssl
[root@localhost etc]# yum install httpd mod_ssl
Удаляем файл /etc/httpd/conf.d/ssl.conf и создаем файл /etc/httpd/conf.d/activesync.conf следующего содержания:
LoadModule ssl_module modules/mod_ssl.so Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl # Включаем поддержку SSL/TLS SSLEngine On # Указываем файлы сертификата сервера и секретного ключа SSLCertificateFile /etc/pki/tls/certs/ca.crt SSLCertificateKeyFile /etc/pki/tls/private/ca.key # Для подключений использовать только протоколы SSLv3 и TLSv1 SSLProtocol -All +SSLv3 +TLSv1 # создаем именованный виртуальный хост на порту 443 NameVirtualHost *:443 # описание виртуального хоста по умолчанию, сюда будут попадать все запросы # пришедшие не на доменное имя activesync.mydomain.global <VirtualHost *:443> ServerAdmin support@mydomain.global DocumentRoot /var/www/html ServerName Default <LocationMatch "^/+$"> SSLRequireSSL </LocationMatch> </VirtualHost> # описание виртуального хоста для доменного имени activesync.domain.com <VirtualHost *:443> ServerName activesync.mydomain.global ServerAdmin support@mydomain.global ProxyRequests Off ProxyPreserveHost On SSLProxyEngine On # Разрешаем использовать SSL/TLS прокси ProxyVia On RequestHeader set Front-End-Https on ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log LogLevel info CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" <Location /Microsoft-Server-ActiveSync> ProxyPass https://mail.mydomain.local/Microsoft-Server-ActiveSync ProxyPassReverse https://mail.mydomain.local/Microsoft-Server-ActiveSync SSLRequireSSL </Location> </VirtualHost>
Добавляем в автозагрузку и запускаем сервис.
[root@localhost ~]# chkconfig httpd on [root@localhost ~]# service httpd start Starting httpd: [ OK ]
Настройка коммуникаторов
Для коммуникаторов HTC на базе android в настроке электоронной почты выбираем ActiveSync, потом выбираем расширенные настройки, и заполняем по образу и подобию с рисунком ниже.
Для использования коммуникаторов со стандартными настройками, когда для подключения нужно указать только адрес электронной почты и пароль пользователя, придется настраивать АutoDiscover. Но об этом немножко позже, как только наткнусь на коммуникатор в котором нельзя указать адрес сервера.
15 Коммент. : “Настройка Exchange ActiveSync через Apache”
А почему нестабильный и уязвимый апач, к которому постоянно выходят патчи и эксплойты, называется более надёжным, чем удобный и безопасный iis 7.5, который сейчас является основным веб-сервером для enterprise-решений? ну понятно, что на уровне хостинга narod.ru апач ещё кое-как тянет, но не в серьёзных же фирмах. про сертификат вообще неправильно написано. а autodicover называется AutoDiscover, слова «dicover» нет.
@vlad
Все чаще наталкиваюсь на холивары на тему MS против Linux, apache против iis. В последнем сложно сказать кто выигрывает, пока apache установлен на более чем 60% web-серверов.
1. В apache найдено больше дыр – это истинная правда обусловленная открытым исходным кодом и распространенностью. Если можешь приведи пример уязвимости, которую нельзя закрыть парой легких движений.
2. Apache нестабильный
– чистой воды домысел.
3. IIS 7.5 является основным веб-сервером для enterprise-решений – А что конкретно ты подразумеваешь под словом enterprise-решения? Как не странно крупные интернет порталы используют не apache и не iis, а некоторый гибрид nginx (например яндекс или vkontakte) или как google используют свое ПО для web-сервера.
4. Как пишется AutoDiscover я знаю, наверное торопился
5. По поводу SSL/TLS сертификатов с радостью послушаю правильный рассказ, как и что нужно делать. Но слова «вообще не правильно» мне не говорят ни о чем – нужна конкретика.
PS: Желаю успехов с продуктами MS.
1. от того, что код открытый, больше дыр не находят. от того, что школьник Вася может в принципе просмотреть миллионы строк кода, реализующего неизвестные ему протоколы, он в их реализации баги не увидит. плюс в спо отсутствует процедура тестирования – кое-как вроде заработало – сразу выпускают. в профессиональном ПО такого нет – и тестируют профи, и тестируют по науке. поэтому большое количество багов в спо – от некачественного кода.
2. время наработки на отказ у апача ниже, чем у IIS, патчи выходят чаще, downtime больше.
3. intel.com, ferrari.com, microsoft.com – это enterprise-решения. sharepoint, project server – это enterprise-решения. хостинг бесплатных страничек – это не enterprise-решения. во всех фирмах в Fortune 500 используются решения на IIS, а nginx – крайне узкофункциональное решение для ряда специфичных провайдеров.
5. про TLS материалов в сети много. кстати, как будешь смотреть, задайся вопросом – почему в СПО стандарты RFC реализовывают годами и неудачно, а в коммерческих продуктах – сразу. и почему Microsoft, Cisco, Juniper стандарты RFC разрабатывают, а вот некое полупрозрачное всемогущее СПО-коммунити – ни одного.
// Для публикации Web-сервисов Exchange использует IIS
IIS используется не для публикации, а для исполнения веб-служб клиентского доступа. Для публикации обычно используют обратный прокси (ISA Server, например, а в Вашем случае – это Apache).
Apache в качестве обратного прокси не представляет никакой защищенности, т.к. перенаправляет запросы на IIS без их инспекции, так что Вы всего лишь представляете злоумышленнику еще одну потенциально уязвимую службу. Логичнее и практичнее «публиковать» веб-службы CA без посредничества, чем «огораживать» бесполезной прокладкой.
Привет, @vlad
1. Открытое программное обеспечение как правило существует под каким-то учебным заведением или коммерческой организацией, кроме того имеет достаточно широкую распространенность, поэтому утверждать что его никто не тестирует и не тестируют профессионалы никак нельзя. Открытый код не поможет школьнику Васе, зато будет очень полезен профессионалу Пете
2. Время наработки на отказ есть у жестких дисков и другого оборудования, о том что оно стало актуальным и для софта слышу впервые
Я не вижу связи между временем простоя и частотой выхода патчей, а downtime скорее больше зависит от реализации балансировки нагрузки, наличия резервирования и опыта обслуживающего персонала. Давай попробуем посчитать предположим к apache вышло 20 пачей за год, на установку одного пача мне понадобится ровно 6 секунд, итого время простоя будет равно 2 минутам. Скажи сколько у тебя будет перезапускаться сервер с Win2k8 и IIS 7.5 после одной установки обновлений?
3. Microsoft естественно использует свой продукт, хотя было время когда для балансировки нагрузки на Windows Update использовался AkamaiGHost. Intel и ferrari – не показатель использования IIS, кроме них есть и другие не менее крупные организации – например HP, AMD, Redhat, Adobe используют apache для хостинга своих сайтов. Даже Cisco – один из крупнейший производителей сетевого оборудования использует Apache/2.0.
5. «про TLS материалов в сети много», «вообще не правильно», «а в яндексе набрать не пробовал» и тд… Но пока ничего конкретного. Я знаю, но никому ничего не скажу
На мой взгляд такая позиция является крайне на тактичной.
Добрый день, @Дмитрий Пономарев
Достаточно интересные исправления. Но мне все-таки хотелось бы разобраться в этом до конца, поэтому к тебе два вопроса:
1. В чем заключается потенциальная уязвимость?
2. По какому алгоритму проводит инспекцию трафика ISA Server при публикации ActiveSync?
А вот вопрос: на картинке 3-leg perimeter network, что за роутер и на кой он нужен? Судя по всему он выполняет функцию файервола, или это два раза NAT в периметр и во внутреннюю сеть?
Привет, @Lebedev Yuriy
3-leg perimeter network – есть такой шаблон в ISA-сервере, и предназначен он исключительно для тех кому не хватило денег на 2 сервака + 2 Windows Server + 2 ISA Server. Что-то вроде 3-leg perimeter network я и хотел изобразить, правда сейчас хочется заметить что получилось у меня немого хуже чем у Microsoft.
Про NAT совершенно верно угадал. Если есть желание помочь в улучшении качества восприятия предложенной информации – предложи правильную картинку. Заранее спасибо
Автор может пояснить в чем безопасность данной схемы? Или это интуитивные суждения?)
@Alsigned
// В чем заключается потенциальная уязвимость?
Уязвимости в Apache встречаются? Ок. Так зачем увеличивать площадь атаки для злоумышленника, если Apache является лишь обратным прокси?.. Еще раз повторюсь, в таком сценарии «безопаснее» будет транслировать порт на сервер CAS.
// По какому алгоритму проводит инспекцию трафика ISA Server…
Во-первых, ISA производит т.н. «statefull-инспекцию» на сетевом уровне. На уровне приложений ISA производит инспекцию HTTP. Если не использовать дополнения к ISA или кое-какой функционал TMG (наследник ISA), то ISA «из коробки» как минимум, проверяет нормализацию запросов, фильтрацию методов и заголовков, а также может подавлять флад GET-запросов.
Почитайте: http://blogs.technet.com/b/isablog/archive/2010/11/01/outlook-anywhere-and-activesync-http-filter-configuration.aspx.
В предыдущем посте не дописал предложение: проводит инспекцию на стевом уровне и и выполняет т.н. «statefull-инспекцию» на _транспортном_ ровне.
@Дмитрий Пономарев
Идея предложенная в статье на мой взгляд очень даже не плохая, и так просто отказываться от нее я не хочу. Но как видно из всего написанного выше в ней есть много недостатков, которые нужно исправить и дописать.
Флад GET-запросов можно подавить и средсвами apache, со statefull-фильтрацией на траспортном и сетевом уровнях вполне справятся iptables.
Единственный сложный вопрос как выглядит алгоритм фильтрации методов и заголовков, которым польузуется ISA. Из предложенной таблицы на technet видна только конфигурация фильтра. Проще говоря, если есть более подробная информация по проводимой ISA сервером фильтрации методов и заголовков, буду всем примного благодарен.
@Alsigned
Вы не понимаете, или, вернее всего, не хотите принять мои доводы. Я не вижу никакого «профита» от реализации Вашей идеи.
ISA Server выполняет фильтрацию HTTP с помощью фильтра для протокола HTTP и, в «коробочной конфигурации», никак более. У фильтра есть базовые (эталонные) настройки, как, например, MaxRequestLength, CharacterNormalization и т.п., а уж прочие настройки производятся согласно рекомендациям по т.н. «hardering» для конкретной web-службы. Статья, приведенная мной, на мой взгляд, наиболее понлно отражает вопрос превентивной защиты веб-служб клиентского досотупа Exсhange с помощью HTTP-фильра ISA Server. А Вы в своей статье лишь кичитесь тем, что Apache, выступая в роли revrse-webproxy перед CAS, положительным образом сказывается «на безопасности» при публикации CAS в сети Интернет. Это профанская позиция, глупо так утверждать, не имея убедительных доводов, тем более, что Вам в сравнение приводят доводы вполне пристойные, как мне кажется…
@Дмитрий Пономарев
Нормальная позиция ИТ-специалиста (да в принципе и любого рода специалиста) – это размышлять, разбираться и ставить под сомнение, а не просто напрямую верить всему что говорят. Не ошибается лишь тот кто ничего не делает.
Профанская позиция в данном случае была бы сказать «Да, есть Microsoft ISA сделанный по рекомендациям MS, поэтому моя статья плохая, я ее удаляю, а сам ухожу в забвение и больше никогда не буду ничего написать.
»
А моя позиция выглядит по другому: «Да, доводов мне предостаточно, но я хочу разобраться и исправить ситуацию. Весь перечисленный Дмитрием функционал ISA, необходимый для публикации ActiveSync, можно реализовать за счет apache + mod_security + mod_proxy и iptables. Я проанализирую вопрос и напишу новую статью
»
Дмитрий, Вам огромное спасибо – наиболее адекватная критика была именно с Вашей стороны.
PS: Теперь я возьму небольшой таймаут и погружусь в чтение мануалов по реализации атак на веб-сервера и функционированию ISA сервера.