 |
|
|
|
Postfix как шлюз для Exchange
Postfix как шлюз для Exchange Предположим, вы системный администратор и вам предстоит организовать функционирование почтовой системы для вашего предприятия. Возможно, это тот случай, когда вашему предприятию нецелесообразно пользоваться почтовыми ящиками, предоставленными провайдером и нужен свой почтовый сервер, более того, вы хотите сами встать у «руля» (ведь есть также возможность организовать свой почтовый сервер, но при этом все равно пользоваться почтовым сервером провайдера, т.е. забирать почту для своего домена из почтовой очереди или pop3 ящика на сервере провайдера) Здесь мы рассмотрим достаточно распространённый случай, когда у вас есть выделенный канал с одним IP-адресом и MX-запись для вашего домена(ов) указывает на этот IP. Для вас выбор программного обеспечения почтового сервера ясен или, может быть, его сделали другие, но это MS Exchange. Вы начинаете думать, и в зависимости от наличия опыта, от того, что посоветовали друзья, и какие данные удалось самому найти в сети, у вас появится несколько вариантов. Итак, наиболее распространенные: Вы ставите Windows-машину в качестве шлюза и на нее нахлобучиваете Exchange. Понятное дело, Exchange на другой ОС не работает, а почту как-то надо получать. Прокопавшись несколько часов, ведь так и будет, потому что настройка Exchange вещь не тривиальная и установка Windows проходит как-то не шустро, закончили первый этап. Почта ходит, да и шлюз вроде справляется с нагрузкой и почти не глючит. Довольные собой идете домой с застывшей улыбкой на губах. На самом деле это не улыбка, просто вы погружены в свои мысли о великих свершениях и не замечаете окружающих, ведь завтра многое предстоит сделать, что-то надо думать с защитой шлюза, да и почту без антивирусной защиты оставлять нельзя, плюс ко всему надо успеть завтра скачать и установить многотонные сервис паки, апдейты, патчи и много всего прочего. Проходит неделя, другая, постепенно налаживается документооборот, совместная работа офиса на базе Exchange, ведь, я надеюсь, Exchange в вашей конторе не только ради почты, впрочем, такой вариант тоже часто встречается. Но что-то все-таки не ладится. То машина в какой-то стопор падает, а то начинаете ковырять настройки, никоим образом не относящиеся к почте, а в результате именно она перестает работать. Да и регулярно обнаруживаемые в Windows критические уязвимости надежд на спокойную жизнь не приносят. В общем, приходится постоянно быть начеку, чтобы вовремя перегрузить сервер и на вопрос: «Вася, а что у нас с почтой?» нетерпеливо глядя то на индикатор hdd led, то на «Windows is now restarting», цедить: «Сейчас всё будет работать.» Пройдёт еще некоторое количество времени, и к вам придёт мысль о том, что надо разделить функции шлюза и Exchange-сервера, тем более что информация на сервере ценная и хочется её сохранить. Уже узнали, что можно спрятать сервер Exchange за шлюзом в приватной сети, но чтобы почта все-таки ходила и c сервером можно было соединиться извне, используя реальный адрес шлюза. Вы опять полны идей и вас слегка лихорадит. Итак, решено, Exchange – внутрь, соединения на 25-й порт с шлюза перенаправляем на внутренний компьютер... а что у нас, пардон, на шлюзе-то осталось? Вот тут наступает момент истины, и от вас зависит, сделаете ли вы правильный выбор или нет. Если до этого вы имели дело с UNIX-подобными ОС, то выбор очевиден – ставите свою любимую ОС в качестве шлюза и все дальше, как в песне. Если вы поклонник Windows или просто не приходилось работать с другими системами, то первым порывом будет взгромоздить на шлюз Windows. Плюсом такого решения является большой выбор программ, как правило, большинство из них коммерческие. Ну а о минусах такого подхода к безопасности, я думаю, вы и сами осведомлены, иначе не стали бы переносить Exchange внутрь защищенной сети. Настало время попробовать UNIX, возможности которого для подобного рода задач скорее всего перекроют ваши потребности, а из преимуществ можно перечислить как минимум следующие:
Меня удивляют некоторые IT-специалисты, которые даже не хотят или боятся делать это, приводя бессмысленные аргументы. Проявив немного терпения и овладев приемами работы в UNIX, в дальнейшем, исходя из ситуации, сможете сделать выбор, которого не будет у них. Ну вот, Exchange убран внутрь, шлюз теперь построен на операционной системе более подходящей для этой цели и кажется, что вы в безопасности. Но не торопитесь так думать, ведь Exchange как был доступен из Интернета, так и остался. И при неправильной конфигурации он может стать сервером для спам-рассылок, источником распространения вирусов и целью для атак. Впрочем, целью для атак он может стать в любом случае, ведь атаковать нельзя только ту систему, которая выключена. Зайдите на любой сайт, который даёт обзоры по найденным уязвимостям и посмотрите статистику. Вы можете возразить, что применяете последние заплаты, но ведь уязвимости всегда на шаг впереди и где гарантия, что вы успеете залатать дыры прежде, чем произойдет неприятность. Вот вывод команд, доступных по умолчанию в Exchange: 250-TURN 250-ATRN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK Сдаётся мне, что для сервера, общающегося с Интернетом, половина этих команд не нужна, а некоторые опасны, например, TURN. Смысл этой команды заключается в том, что клиент и сервер меняются ролями и почта для домена передается на хост клиента. Для идентификации используется доменное имя, полученное от команды HELO. У злоумышленника появляется возможность, подделав имя, заставить сервер отправить почту на свой хост. Отключить же ненужные команды, ползая по меню System Manager, вам вряд ли удастся. Но не все так плохо, как кажется, и мы хотим предложить вам третий вариант. А что если Exchange сделать вообще недоступным из Интернета? А как будет ходить почта, спросите вы. Да очень просто, мы установим на шлюз MTA Postfix и спрячем за ним Exchange, организовав их взаимодействие. Теперь для всего внешнего мира будет доступен Postfix, на котором не будет никаких почтовых учетных записей, никаких почтовых ящиков. Postfix будет принимать почту, обрабатывать ее и передавать дальше Exchange. Естественно, такие вещи как спам, вирусы, попытки переслать почту для чужих доменов (релей) будут отсекаться еще на этапе соединения с Postfix. Исходящая почта также будет проходить через Postfix. Плюс ко всему функции защиты от спама, вирусов и т. д. можно дублировать на Exchange. Таким образом, вы сможете создать достаточно надежную почтовую систему, то есть: а) Нет возможности подобраться к Exchange напрямую извне, а значит провести атаку или получить доступ к вашим данным через дыры в другом ПО, например, через IIS, который требуется для установки Exchange. Атака же на Postfix грозит выходом из строя только Postfix, который не содержит ни пользовательских бюджетов, ни важных данных. К тому же, насколько мне известно, за последние несколько лет в Postfix не обнаружено критических уязвимостей и скорее всего не будет найдено таких дыр, которые могут привести к катастрофе. Учитывая все вышесказанное, можно заключить, что риск потери данных из-за краха Postfix равен нулю. б) Исходя из пункта «а», ясно, что времени на восстановление функционирования почты на шлюзе понадобится меньше, чем системе Exchange, содержащей данные, я бы даже сказал много меньше, если учесть, что в некоторых случаях установка всей системы с нуля, в нашем случае операционной системы и Postfix, единственно приемлемый выход. Все, что вам нужно, это сохранить несколько конфигурационных файлов и при установке новой системы перенести их обратно. А можно поступить еще проще – создать образ жесткого диска. В случае катастрофы нужно будет просто заново записать образ на жесткий диск и обновить конфигурационные файлы. Таким образом, простой системы будет сведен к минимуму. в) Во время восстановления шлюза циркуляция почты внутри предприятия сохраняется. Да и достаточно поменять несколько цифр, чтобы почта стала уходить по другому маршруту. г) Настройка Postfix на порядок проще и даже используя значения по умолчанию, он предлагает достаточный уровень безопасности, чего не скажешь про Exchange. Установите сперва Postfix на шлюз, а потом разбирайтесь с настройками Exchange сколько вам влезет, не опасаясь совершить те или иные ошибки, которые приведут к нежелательным последствиям. д) Наконец, обслуживание UNIX + Postfix требует куда меньше затрат и душевных сил. Это для тех, кто может сказать, что эту схему можно организовать связкой Windows + Exchange, что и рекомендуется некоторыми статьями и книгами про Exchange. Да и злые вирусо-трояно писатели как будто сговорились и пишут в основном для Windows. Я хотел бы ещё вернуться к пункту «а», где говорилось о возможности получить доступ к данным через дыры IIS. При чем тут IIS, скажете вы, когда кроме 25-го порта на Exchange-сервере ничего не открыто. Здесь имелась в виду служба Outlook Web Access, которая входит в состав Exchange и позволяет посредством веб-интерфейса, похожего на Outlook, получить доступ к почтовому ящику, расписаниям, общим документам. Это может быть удобно для мобильных пользователей. Если вам нужна эта служба, то придётся дать доступ к веб-серверу. Это можно сделать опять же средствами NAT, но тогда все усилия, направленные на скрытие Exchange-сервера от внешнего мира, сходят на нет. На помощь может прийти Apache, сконфигурированный в режиме обратного прокси. Он может быть установлен на том же шлюзе или на другом компьютере. Если не хочется ставить Apache, можно попробовать программу Pound (http://www.apsis.ch/pound), которая предназначена как раз для этих целей. Если вам подходит этот вариант, то нужно сделать совсем немного, конечно, за исключением вышеописанного. Установка Exchange, Postfix и операционных систем здесь не описывается. Естественно, для придания Postfix дополнительной функциональности, такой как защита почты от вирусов, smtp-аутентификация, вам потребуется установить дополнительный софт, например: drweb для защиты от вирусов, для smtp-аутентификации postfix использует sasl. Функции защиты от спама и блокировку нежелательной как почты, так и почтальонов, можно осуществить встроенными средствами Postfix. На эти темы есть достаточно документации. Итак, у вас Postfix на шлюзе. Exchange в локальной сети. И хотя в контексте данной статьи слово «шлюз» применяется к компьютеру, одним интерфейсом смотрящим в Интернет, другим в локальную сеть, на практике это может быть специально выделенная машина с одним интерфейсом, например в сети, где все адреса реальные, а функции брандмауэра выполняет другой компьютер или аппаратный брандмауэр, который пропускает почтовый трафик только снаружи к шлюзу и в обратном направлении. Начнем с Postfix. Не забыли, что MX-запись в DNS указывает на него. Повторяю еще раз, что мы описываем взаимодействие Postfix и Exchange, и если вы не видите здесь строчек, касающихся smtp-аутентификации или еще чего-либо, то это не значит, что этого не должно быть в конфигурации вашего сервера. Открываем для редактирования файл main.cf. Имя вашей машины: myhostname = host.domain.ru Имя вашего домена: mydomain = domain.ru Ваши доверенные сети: mynetworks = 127.0.0.0/8, 192.168.100.0/24 или вместо всей сети 192.168.100.0 можно указать только адрес Exchange, к примеру: mynetworks = 127.0.0.0/8, 192.168.100.20 Таким образом, вы запрещаете внутренним клиентам использование Postfix в обход Exchange. Локальные получатели, оставить значение пустым, так как их на этой машине попросту нет: local_recipient_maps = Если мы должны считать своими несколько доменов, то их можно перечислить здесь: mydestination = $myhostname, localhost.$mydomain, $mydomain, domain2.ru, domain3.ru Указываем, в каком файле у нас будет описан маршрут до Exchange: transport_maps = hash:/usr/local/etc/postfix/transport В файле transport мы описываем, на какой компьютер будет пересылаться почта для наших доменов: domain.ru smtp:[192.168.100.20] domain2.ru smtp:[192.168.100.20] domain3.ru smtp:[192.168.100….] Скобки нужны, чтобы Postfix не пытался проверять через DNS соответствие имени IP-адресу Exchange. Впрочем, с таким же успехом вместо адреса можно указать доменное имя Exchange без скобок. После сохранения файлов main.cf и transport даем команду: postmap transport которая при первом вызове создаст файл transport.db, а в дальнейшем будет обновлять этот файл, учитывая изменения в файле transport. Далее даем команду: postfix reload которая перезапустит Postfix с учетом изменений в файле main.cf. С Postfix закончили, переходим к Exchange. Exchange должен быть настроен на обработку почты для наших доменов. Открываем System Manager, переходим к Connectors, и выбираем «New –> SMTP Connector». На вкладке General указываем, что наружу почта должна переправляться через адрес Postfix в квадратных скобках. На вкладке Address Space щелкаем добавить Address type – SMTP. Сохраняем настройки и перегружаем Exchange. Настройка Apache в качестве обратного прокси может быть темой для отдельной статьи. Приведу лишь простейший пример для доступа к OWA на основе Apache 2.x. В файле httpd.conf раскомментируем строчки: LoadModule proxy_module libexec/apache2/mod_proxy.so LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so Далее добавим следующие строчки: ProxyRequests Off ProxyPass /exchange http://192.168.100.20/exchange ProxyPassReverse /exchange http://192.168.100.20/exchan Где 192.168.100.20, как вы наверное уже догадались, наш Exchange-сервер. Теперь удаленный пользователь, набирая в браузере http://адрес_шлюза/exchange, получает доступ к Outlook Web Access. Вот, собственно, и все. И хотя здесь представлена простая схема, она с успехом может применяться в более сложных сетях, когда есть несколько почтовых серверов, которые обслуживают несколько доменов, и не обязательно это должны быть Exchange-сервера. |
ИГОРЬ ПОЛЯНСКИЙ| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
