Настройка связки postfix exchange

 Устанавливаем связку Postfix + Exchange

Рубрика:

Администрирование / 
Электронная почта

 ВЛАДИМИР АГАПОВ

Устанавливаем связку Postfix + Exchange

Перед нами нетривиальная задача. Требуется организовать внутрикорпоративный документооборот на базе MS Exchange, оставив пользователям возможность общаться по электронной почте с внешним миром. И при этом не уменьшить уровень внутренней безопасности. Предлагаем вам быстрое и эффективное решение данной задачи

Итак, вы – системный администратор. Большой конторы или маленькой, принципиального значения не имеет. Равно как и то, настроена ли у вас почтовая система или это только предстоит сделать в ближайшее время. Главное другое: однажды вас вызывает к себе начальник и говорит: «хочу». Хочу, чтобы у нас все было как у людей: и книга адресная единая, корпоративная, и планировщик задач, и календарь событий на месяцы и годы, ну, в общем, все, что только он где-то слышал или, не дай бог, видел. Озадаченные этим вопросом, вы возвращаетесь к себе, попутно думая, а что же проще: настроить The Bat на работу с LDAP и найти какие-нибудь утилиты, позволяющие получить данный функционал, или снести The Bat со всех машин, и поставить туда Outlook, закрыв глаза на резко упавшую в этом случае безопасность? Подумав с полчасика, приходим к выводу: придется ставить Outlook, и не только его, что было бы только половиной беды, но и Exchange в качестве почтового сервера. Поскольку начальнику может прийти в голову и еще что-нибудь неприличное, типа внутрикорпоративного документооборота. Вместо MS Exchange можно, конечно, использовать и OpenXchange, Hula, Opengroupware и пр. Но мы остановимся на первом варианте.

Скорее всего, у вас совершенно нет желания вывешивать наружу машину с установленной на ней ОС Windows и Exchange в придачу. Значит, придется разделить функции внешнего и внутреннего почтовых серверов. На внутреннем пусть себе крутится Exchange, а на внешнем поставим UNIX-подобную операционную систему и, например, Postfix в качестве почтового сервера. Вот из этих предпосылок и будем исходить.

Поставить и запустить эти два сервера – задача сама по себе для новичка нетривиальная, но такой вариант нас не устраивает, в нашем случае необходимо, чтобы эти сервера взаимодействовали между собой и прозрачно пропускали почту в мир и обратно.

В результате всех размышлений получается примерно следующий список задач:

  1. Установка на все рабочие машины Microsoft Office Outlook в качестве почтового клиента.
  2. Установка на первый сервер (exchange) ОС Windows и Microsoft Exchange (в данном документе будет подразумеваться версия 2003).
  3. Установка на второй сервер (gate) ОС из семейства UNIX и Postfix (FreeBSD 5.3 и postfix 2.2 соответственно).
  4. Настройка Exchange для работы с Postfix
  5. Настройка Postfix для работы с Exchange
  6. Дополнительное конфигурирование для поддержки alias и прочего.

Пункты с 1-го по 3-й выходят за рамки обсуждения данной статьи, поэтому детально описывать их я не буду, а более подробно остановлюсь на пунктах 4, 5 и 6.

Одно из решений задачи уже было предложено в журнале [1]. Мы же в отличие от него будем использовать вариант проверки Postfix наличия почтового аккаунта в Windows-домене перед приемом почты.

Настраиваем Exchange для работы совместно с Postfix

Для начала определимся, что именно мы хотим получить от Exchange в данной конфигурации:

  • Он должен получать почту, которую будет перенаправлять ему Postfix и доставлять ее в соответствующие почтовые ящики пользователей.
  • Почта пользователей, отправляемая за пределы домена, должна попадать в Exchange и пересылаться им для дальнейшей обработки на внутренний интерфейс gate для дальнейшей отсылки ее в мир уже Postfix.
  • В связи с тем, что название Windows-домена в AD часто не совпадает с почтовым доменом, необходимо включить маскарадинг.
  • Во избежание локальных эпидемий внутреннюю почту также необходимо проверять на вирусы.

Приступим к настройке Exchange

Запускаем Exchange System Manager:

  • Разворачиваем «Administrative Group  company  Servers  Exchange  protocols SMTP». Открываем свойства default. На закладке «Access» выбираем «Relay Restrictions» и записываем туда IP-адрес нашего Postfix-сервера. В некоторых случаях может потребоваться указать подсети целиком. Например, в случае использования приложений, напрямую общающихся с SMTP-сервером.
  • Там же, на закладке «Delivery», выбираем «Advanced» и указываем в поле «Smart Host» IP-адрес Postfix-сервера в квадратных скобках.
  • Здесь же, в поле «masquerade domain», указываем наш почтовый домен, для того чтобы Exchange отправлял всю почту от имени этого домена.
  • Выбор антивирусного сканера под Exchange я оставляю за вами, поскольку почти все крупные производители антивирусных продуктов имеют в своих линейках такие решения.

Этих настроек на данный момент достаточно. Более детальную настройку и конфигурирование оставляю на ваше усмотрение.

Настраиваем Postfix для работы с Exchange

Определимся, что мы ожидаем от Postfix:

  • Принимать почту, пересылаемую ему Exchange и отправлять ее дальше в мир.
  • Проверять всю входящую и исходящую почту на вирусы.
  • Проверять всю входящую почту на наличие спама и выставлять ей соответствующие балы.
  • Для экономии трафика необходимо проверять, есть ли получатель входящего письма в нашем домене, и в зависимости от результата либо принимать, либо отвергать письмо.
  • Пересылать все прошедшие проверку входящие письма на Exchange.

Прежде всего нам потребуется установить Postfix. Об этом достаточно много имеется информации в Интернете, поэтому остановлюсь лишь на главных моментах. У нас есть два варианта установки:

  • просто пересылать всю входящую почту внутрь сети, не задумываясь, есть ли такой почтовый пользователь;
  • предварительно проверять наличие пользователя в AD и в случае его отсутствия не принимать почтовое сообщение.

По первому варианту вы можете посмотреть уже упоминавшуюся здесь статью [1]. Однако я предпочел остановиться на втором варианте. Это позволит нам существенно сэкономить трафик и поможет уменьшить количество приходящего спама.

Для начала установим LDAP-client.

# cd /usr/ports/net/openldap22-client/
# make install clean

Далее устанавливаем Postfix с поддержкой LDAP. Если вы собираете его из портов, отметьте соответствующий пункт, в другом случае вам потребуется указать это явно:

# gmake tidy
# gmake makefiles CCARGS=»-I/usr/local/include -DHAS_LDAP» AUXLIBS=»-L/usr/local/lib
-R/usr/local/lib -lldap -L/usr/local/lib -R/usr/local/lib -llber»
# gmake install

Приступаем к конфигурированию Postfix

Для начала установите все минимально необходимые значения. Что именно, можно узнать в документации на Postfix и в Интернете.

  • Добавим в значение переменной «mynetworks» IP-адрес Exchange-сервера (например, 192.168.1.2/32).
  • В качестве антивирусного сканера я использую ClamAV. Как его подключить к Postfix, можно прочитать в статье [2].
  • Как подключить SpamAssassin, можно прочитать там же.
  • Для проверки наличия учетной записи будем использовать LDAP-запросы к AD. Именно для этого мы и собирали Postfix с поддержкой LDAP. Внесем следующие записи в main.conf:

# Имя Windows-домена
ldapmap_search_base = dc=office, dc=company, dc=ru

 # IP-адрес PDC
ldapmap_server_host = 192.168.16.1

# LDAP-порт
ldapmap_server_port = 3268
ldap_timeout = 60
ldapmap_query_filter = (&(proxyAddresses=smtp:%s)(|(objectClass=user)(objectClass=group)(objectClass=contact)))
ldapmap_result_filter = %s
ldapmap_result_attribute = canonicalName
ldapmap_special_result_attribute =
ldapmap_scope = sub
ldapmap_bind = yes
ldapmap_bind_dn = ldapquery@office.company.ru
ldapmap_bind_pw = LdaPassworD
ldapmap_cache = no
ldapmap_dereference = 0
ldapmap_domain = office.company.ru
ldapmap_debuglevel = 0
virtual_mailbox_maps = ldap:ldapmap
virtual_mailbox_domains = company.ru

Для того чтобы у Postfix были права на выборку информации о пользователях домена, заведем в домене нового пользователя ldapquery с паролем LdaPassworD.

В результате данной процедуры Postfix будет опрашивать домен на наличие пользователя с заведенным почтовым ящиком типа user@company.ru. В случае положительного ответа письмо будет приниматься для дальнейшей доставки, в случае отрицательного – отвергаться с кодом, указанным в переменной unknown_local_recipient_reject_code.

Чтобы Postfix после всех проверок отправлял письмо Exchange, добавим в main.conf:

virtual_transport = hash:/etc/postfix/virtual_transport
transport_maps = hash:/etc/postfix/virtual_transport

и создадим файл /etc/postfix/virtual_transport:

company.ru               smtp:[192.168.16.5]

где 192.168.16.5 – IP-адрес Exchange-сервера, а company.ru – домен, всю приходящую для которого почту следует пересылать на другой сервер. Не забываем после создания или редактирования этого файла делать:

postmap /etc/postfix/virtual_transport

Дополнительное конфигурирование

Для полноценной работы нам, возможно, потребуется еще несколько штрихов, а именно:

  • Создать группы рассылок на Exchange. Для этого необходимо сделать следующее:
  • Создать группу распределения.
  • Создать почтовый аккаунт для этой группы.
  • Добавить в эту группу всех, кто должен быть подписан на эту рассылку.
  • Разобраться, как можно сделать алиасы в Exchange. Для этого можно использовать два варианта:
  • Создать в Active Directory дополнительные SMTP-записи для каждого пользователя, которому необходимо прописать alias. Этот вариант проще и предпочтительнее.
  • Там же можно создать запись типа CC для тех же целей.

На этом можно считать минимально необходимую настройку для работы данной связки законченной. Все возможные ошибки и проблемы всегда возможно отследить в логах postfix, где все достаточно информативно пишется. Так же для обсуждения этой статьи и всех дополнительных вопросов существует специально созданный топик на форуме [3].

Данный вариант является рабочим, проверен на офисе компании. Но у него есть как минимум один недостаток – он потенциально не защищен от атак типа DoS на AD, в случае большого количества одновременных внешних SMTP-сессий. Чтобы этого избежать, можно либо настроить в Postfix ограничения на количество одновременных сессий, либо скриптом по cron забирать информацию из AD и складывать ее на машине с Postfix. Но это тема уже совсем другой статьи.

  1. Полянский И. Postfix как шлюз для Exchange. – Журнал «Системный администратор», №5, 2004  г. – 34-37 с (https://samag.ru/archive/article/280).
  2. Почтовая система на базе Postfix, PostgreSQL, с фильтрацией вирусов и спама на FreeBSD 5.3 – www.deepnet.ru, раздел «Статьи».
  3. https://forum.deepnet.ru.

Источник

Blog of Khlebalin Dmitriy

Postfix как шлюз для Exchange (часть 1).

Мои изыскания в области freebsd продолжаются. Книга прочитана, сервер настраивается.

Пришло время перейти к почтовому серваку.

Здесь мы рассмотрим достаточно распространённый случай, когда у вас есть выделенный канал с одним IP-адресом и MX-запись для вашего домена(ов) указывает на этот IP.

Итак, в моем случае почтовиком на данный момент является  MS Exchange 2003. На нем в качестве спам-фильтра сейчас прикручен GFI Mail Essentials 14 (видел еще несколько спам фильтров эксченджа в работе: Cisco Ironport-прекрасен, но очень дорог, ORF-тоже достаточно не плох, Kaspersky Antispam-столкнулся достаточно вскользь, быстро пристрелил, по этому многое сказать не могу и TrendMicro-мне не понрафился, вроде бы все ничего, но постоянно приходилось что-то донастраивать, докручивать, а самое главное все вышеперечисленное стоит не мало денег), все бы не плохо, но есть несколько минусов в такой схеме, я про то, когда спамфильтр и эксчендж (как в нынешнем моем случае) стоят на одном серваке:

— Сервак с эксченджем практически мертв (1 гиг оперативки) + спам фильтр нагибают его до земли, при увеличении глубины фильтрации встает просто «колом».

— Сам спам-фильтр не так хорош, как бы нам хотелось (как ни странно пропускает спам в казахских доменов).

Так как в данный момент мое изучение направлено на изучение freebsd, то соответственно и почтовый шлюз будет на нем. Sendmail мне показался достаточно замороченным (наверно это для фанатов больше), я решил остановиться на Postfix.

Ну вот, 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 (https://www.apsis.ch/pound), которая предназначена как раз для этих целей.

Если вам подходит этот вариант, то нужно сделать совсем немного, конечно, за исключением вышеописанного. Установка Exchange и операционных систем здесь не описывается.

Postfix устанавливаем вот так.

Ставить будем конечно из портов:

  # cd /usr/ports/mail/postfix-current/
  # make all install  clean

нам будет предоставлен выбор

в данном случае нам понадобится только SASL.

по умолчанию варианты: 
        You need user «postfix» added to group «mail».
        Would you like me to add it? — [y]? y
        Would you like to activate Postfix in /etc/mail/mailer.conf [n]? n

После окончания сборки вся документация в /usr/local/share/doc/postfix/, файлы конфигурации в /usr/local/etc/postfix/
В FreeBSD информация о почтовых программах находится в /etc/mail/mailer.conf
В нашем случае он должен выглядеть так

  # more  /etc/mail/mailer.conf
  #
  # Execute the Postfix sendmail program, named  /usr/local/sbin/sendmail
 #
  sendmail /usr/local/sbin/sendmail
  send-mail  /usr/local/sbin/sendmail
  mailq /usr/local/sbin/sendmail
  newaliases  /usr/local/sbin/sendmail

Кроме того, так как sendmail, как таковой, нам больше не понадобится, добавим в /etc/make.conf строку

  NO_SENDMAIL=true

При пересборке и установке мира sendmail больше не участвует.
Укажем в /etc/rc.conf, что sendmail мы больше не импользуем

  sendmail_enable=»NONE».
 Проверим, что Postfix установился:

Естественно, для придания Postfix дополнительной функциональности, такой как защита почты от вирусов, smtp-аутентификация, вам потребуется установить дополнительный софт, например: drweb для защиты от вирусов, для smtp-аутентификации postfix использует sasl. Функции защиты от спама и блокировку нежелательной как почты, так и почтальонов, можно осуществить встроенными средствами Postfix. На эти темы есть достаточно документации.

Итак, у вас Postfix на шлюзе. Exchange в локальной сети. И хотя в контексте данной статьи слово «шлюз» применяется к компьютеру, одним интерфейсом смотрящим в Интернет, другим в локальную сеть, на практике это может быть специально выделенная машина с одним интерфейсом, например в сети, где все адреса реальные, а функции брандмауэра выполняет другой компьютер или аппаратный брандмауэр, который пропускает почтовый трафик только снаружи к шлюзу и в обратном направлении.

Начнем с Postfix. Не забыли, что MX-запись в DNS указывает на него (не забудьте ее изменить или менить айпишники на серверах). Повторяю еще раз, что мы описываем взаимодействие Postfix и Exchange, и если вы не видите здесь строчек, касающихся smtp-аутентификации или еще чего-либо, то это не значит, что этого не должно быть в конфигурации вашего сервера.

Открываем для редактирования файл main.cf.

Имя вашей машины:

myhostname = bsd.seq.loc

Имя вашего домена:

mydomain = seq.ru

Ваши доверенные сети:

mynetworks = 127.0.0.0/8, 192.168.44.0/24

или вместо всей сети 192.168.100.0 можно указать только адрес Exchange, к примеру:

mynetworks = 127.0.0.0/8, 192.168.44.20

Таким образом, вы запрещаете внутренним клиентам использование Postfix в обход Exchange.

Локальные получатели, оставить значение пустым, так как их на этой машине попросту нет:

local_recipient_maps =

Если мы должны считать своими несколько доменов, то их можно перечислить здесь:

mydestination = $myhostname, localhost.$mydomain, $mydomain, seq.ru, seq1.ru

Указываем, в каком файле у нас будет описан маршрут до Exchange:

transport_maps = hash:/usr/local/etc/postfix/transport

В файле transport мы описываем, на какой компьютер будет пересылаться почта для наших доменов:

seq.ru        smtp:[192.168.44.20]

seq1.ru       smtp:[192.168.44.20]

Скобки нужны, чтобы Postfix не пытался проверять через DNS соответствие имени IP-адресу Exchange. Впрочем, с таким же успехом вместо адреса можно указать доменное имя Exchange без скобок.

После сохранения файлов main.cf и transport даем команду:

postmap transport

которая при первом вызове создаст файл transport.db, а в дальнейшем будет обновлять этот файл, учитывая изменения в файле transport.

Далее даем команду:

postfix reload

которая перезапустит Postfix с учетом изменений в файле main.cf.

Вернулась команда, что Postfix не стартован.

С Postfix закончили, переходим к Exchange. Exchange должен быть настроен на обработку почты для наших доменов. Открываем System Manager,переходим к Connectors, и выбираем «New –> SMTP Connector».

На вкладке General указываем, что наружу почта должна переправляться через адрес Postfix в квадратных скобках. На вкладке Address Space щелкаем добавить Address type – SMTP. Сохраняем настройки и перегружаем Exchange.

Установим Apache из портов:

Затем добавим в /etc/rc.conf строку для того что бы можно было запускать демона apache

apache22_enable=»YES»

Теперь отредактируйте конфигурационный файл apache /usr/local/etc/apache22/httpd.conf командой

ee /usr/local/etc/apache22/httpd.conf

Настройка 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 https://192.168.44.20/exchange

ProxyPassReverse /exchange https://192.168.44.20/exchan

Где 192.168.44.20, как вы наверное уже догадались, наш Exchange-сервер. Теперь удаленный пользователь, набирая в браузере https://адрес_шлюза/exchange, получает доступ к Outlook Web Access.

Вот, собственно, и все. И хотя здесь представлена простая схема, она с успехом может применяться в более сложных сетях, когда есть несколько почтовых серверов, которые обслуживают несколько доменов, и не обязательно это должны быть Exchange-сервера.

Продолжение следует …

Всем удачи !!!

26.04.2011 —

Posted by khlebalin |
linux and unix

Sorry, the comment form is closed at this time.

Источник

Читайте также:  Растяжение связок пятки лечение в домашних условиях