Содержание |
Sendmail — это наиболее распространенный транспортный агент в UNIX системах. Он поставляется почти со всеми дистрибутивами Linux, в том числе и с CentOS. Sendmail был написан Эриком Оллманом в 1983 году и в дальнейшем дорабатывался различными разработчиками.
Нет таких действий, которые бы Sendmail не мог делать с почтовыми сообщениями, за исключением проверки содержимого письма. Но для его проверки он может передать письмо сторонней программе. Например, так включается проверка на вирусы в почтовых сообщениях.
Очень часто возникаю вопросы по поводу безопасности sendmail. Хочу привести цитату из материалов сайта http://www.intuit.ru.
Программа sendmail используется на многих платформах уже на протяжении нескольких десятков лет. В первые годы ее применения были выявлены практически все черные входы и дыры в программе, которые позволяли хакерам проникать в систему. Например, общеизвестна реакция sendmail на SMTP команды debug и wiz. Получив при анонимном SMTP-сеансе посредством этих команд доступ в систему, через другие программы хакер мог получить права пользователя root . Когда программа sendmail стала популярной, то все черные ходы были закрыты и ошибки в программе были исправлены.
К сожалению, многие администраторы почтовых систем отвергают возможность применения sendmail, ссылаясь на старые черные ходы в ней, которые уже давно закрыты. Конечно, время от времени обнаруживаются новые ошибки в программе, которые позволяют получить несанкционированный доступ к системе. Однако это случается не чаще, чем с другими пакетами для работы с почтой. Так как квалификация хакеров в сети Internet с каждым годом повышается, соответствующим образом должна расти сложность программного обеспечения. Единственное, что может противопоставить растущему числу хакеров программа sendmail, это наличие профессиональных программистов, которые работают над ее улучшением. Они достаточно квалифицированы, чтобы постоянно исправлять и улучшать программный код sendmail, сохраняя его стабильность и уровень безопасности. Не так много пакетов для работы с почтой могут похвастаться тем же.
Так что было бы неосмотрительно только из-за слухов о неблагонадежности sendmail отказываться от ее преимуществ.
Основной конфигурационный файл программы — sendmail.cf. Обычно он находится в директории /etc/mail. В файле определяются основные параметры и особенности работы sendmail, в том числе и дополнительные конфигурационные файлы, которые тоже обычно находятся в директории /etc/mail.
Кроме файла sendmail.cf в системе может присутствовать файл submit.cf, являющийся конфигурационным файлом агента подачи сообщений.
Какой из перечисленных файлов будет использоваться в качестве конфигурационного (то есть, в каком режиме будет работать программа) зависит от опций, с которыми sendmail запускается:
Файл submit.cf обычно никогда не редактируется.
Если посмотреть на содержимое файла sendmail.cf, в нем можно найти строки похожие на:
R$* < @ $=w > $* $: $1 < @ $2 . > $3
R$* < @ $=M > $* $: $1 < @ $2 . > $3
R$* < @ $={VirtHost} > $* $: $1 < @ $2 . > $3
Формат файла изначально создавался с учетом облегчения синтаксического анализа файла и поэтому он мало понятен обыкновенным пользователям. Администратору крайне редко приходится редактировать sendmail.cf. Для создания файла используются специальные макросы препроцессора m4, облегчающие задачу его создания и изменения.
Как было сказано в предыдущем разделе, препроцессор m4 облегчает администратору процесс создания и изменения конфигурационных файлов sendmail.cf и submit.cf.
После установки sendmail, конфигурационные макросы будут помещены в директорию /usr/share/sendmail-cf (В разных дистрибутивах эта директория может находиться в различных сетах. Обратитесь к документации к дистрибутиву.). В этой директории вы увидите файл README, где находится полноценная документация по всем макросам. Сами макросы располагаются в поддиректориях
В директории cf находятся шаблоны макросов, которые можно использовать для создания файла sendmail.cf для разных типов UNIX.
Для получения файла sendmail.cf необходимо создать файл, в котором будут описаны используемые макросы. Затем его пропускают через препроцессор и в результате получают конфигурационный файл.
m4 my.mc > /etc/mail/sendmail.cf
В дистрибутиве CentOS файл-шаблон находится в директории /etc/mail.
Препроцессор m4 имеет очень строгий синтаксис. Любой лишний пробел, неправильное указание скобок ведет к появлению сообщения об ошибке или создание неправильного файла.
В качестве начала комментария используется инструкция dnl. Все, что будет написано после этой инструкции до конца строки, считается комментарием. Рекомендуется в конце каждой строки писать dnl для того, чтобы игнорировать случайные пробелы, которые были помещены в конце макроса.
Если необходимо указывать параметры или строки, их берут в кавычки. Следует обратить особое внимание на то, что открывающая кавычка — это обратная одинарная кавычка ` (на клавиатуре расположена там же где и буква ё), а закрывающая — это одинарная прямая кавычка '.
Так же, в файле на языке препроцессора можно использовать инструкцию divert, при помощи которой можно писать комментарии сразу на нескольких строках.
divert(-1) # # Copyright (c) 1998-2002 Sendmail, Inc. # Copyright (c) 1983 Eric P. Allman. # Copyright (c) 1988, 1993 # The Regents of the University of California. divert(0)
divert(-1) — очищает буфер макросов от данных, оставшихся от предыдущих попыток. divert(0) — применяется для обозначения начала макроса.
Для того, чтобы можно было использовать макросы, их необходимо подключить при помощи директивы include.
include(`../m4/cf.m4')dnl
Сейчас мы рассмотрим основные макросы, которые используются при конфигурации sendmail. Остальные макросы будут рассмотрены по мере конфигурации почтового сервера.
Макрос VERSIONID применяется для идентификации версии создаваемого конфигурационного файла. Все, что указывается в качестве параметра, будет без изменений помещено в выходной файл, сразу после символа комментария.
VERSIONID(`My super mail server')dnl
Обратите внимание, на то, что строка помещена в одинарные кавычки. Как уже говорилось ранее, открывающая — это обратная закрывающая кавычка. Закрывающая — прямая одинарная кавычка.
При помощи макроса очень удобно «метить» конфигурационные файлы. Ведь вы можете создать несколько файлов для разных машин. И что бы в дельнейшем не запутаться, в комментарии можно указать машину и свойства конфигурации сервера.
Исторически так сложилось, что в разных версиях UNIX систем принято свое месторасположение и название дополнительных конфигурационных файлов sendmail. Каждый файл можно определить отдельно при помощи директивы define. Но для того, чтобы эти директивы не описывать каждый раз в файле mc, используют макрос OSTYPE.
OSTYPE(linux)dnl
В качестве параметра макроса указывают имя файла без расширения, находящегося в директории /usr/share/sendmail-cf/ostype. В файле определяются параметры по умолчанию для каждого типа UNIX. Ниже показано содержимое файла linux.m4:
VERSIONID(`$Id: linux.m4,v 8.13 2000/09/17 17:30:00 gshapiro Exp $') define(`confEBINDIR', `/usr/sbin') ifdef(`PROCMAIL_MAILER_PATH',, define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')) FEATURE(local_procmail)
Если у Вас есть много почтовых серверов с одинаковыми параметрами, можно создать файл в директории /usr/share/sendmail-cf/domain, в котором эти параметры будут описаны.
Затем при помощи макроса DOMAIN подключить этот файл.
DOMAIN(my-domain)dnl
Например, файл generic.m4 из директории domain:
VERSIONID(`$Id: generic.m4,v 8.15 1999/04/04 00:51:09 ca Exp $') define(`confFORWARD_PATH',`$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl define(`confMAX_HEADERS_LENGTH', `32768')dnl FEATURE(`redirect')dnl FEATURE(`use_cw_file')dnl
Этот макрос применяется для определения того, каким образом sendmail может доставлять почту.
Точно так же, как и в предыдущих макросах, существует специальная директория mailer, в которой описаны агенты доставки почты, которыми может пользоваться sendmail.
Например, если предполагается доставка почты в локальные почтовые ящики и на удаленные транспортные агенты по протоколу smtp, необходимо описать эти возможности:
MAILER(local)dnl MAILER(smtp)dnl
На самом деле mailer smtp включает сразу несколько транспортных агентов: smtp, esmtp, dsmtp, smtp8 и relay.
Если при доставке почты в локальные почтовые ящики требуется ее фильтрация, рекомендуется добавить поддержку программы procmail:
MAILER(procmail)dnl
При помощи мейлера fax можно организовать шлюз почта-fax. Правда, в системе должен быть установлен факс сервер hylafax. Мейлер отсылает письма, отправленные по специальному адресу в качестве fax сообщения.
Макрос применяется для описания различных особенностей почтового сервера. Подавляющее большинство параметров будут определяться при помощи именно этого макроса. Более подробно макрос FEATURE мы будем рассматривать при конфигурации sendmail в других разделах.
Сейчас же мы посмотрим два ключевых макроса FEATURE.
После определения макроса вы можете пользоваться файлом /etc/mail/local-host-names. Это обыкновенный текстовый файл, в котором по одному на строке вы будете вписывать имена доменов, для которых sendmail должен принимать почту. Например:
# Пример файла locak-host-names kryukov.biz test.kryukov.biz # end of file
Обратите внимание на то, что в этом файле последняя строка не читается. Поэтому она должна быть пустой или поместите там, какой либо комментарий.
Макрос позволяет вводить различные ограничения на использование почтового сервера. Определяется он следующим образом:
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
Как видно из примера, определение макроса состоит из двух частей. Первая — имя макроса, вторая — его параметры.
В параметрах говориться, что sendmail в своей работе будет использовать бинарную базу данных, расположенную в файле /etc/mail/access.db. Выполненную в виде hash таблицы.
Для ускорения доступа к данным, хранящимся в базе, sendmail разместит ее в оперативной памяти ( -T<TMPF>).
Файл базы является не обязательным (-o optional). Т.е. если файла не будет, sendmail все равно запуститься. Если же убрать параметр –o, то sendmail не будет стартовать если файл access.db не будет создан или не будет доступен на чтение программе.
Файл access.db — это бинарная база данных, которую нельзя редактировать напрямую. Обычно поступают следующим образом: создают текстовый файл, который затем при помощи программы makemap переделывают в бинарную базу данных.
Что из себя представляет hash таблица? Это уникальный ключ поиска и значение, которое выдается по этому ключу.
KEY VALUE
Обратите внимание на то, что ключ поиска уникальный. Это означает, что нельзя одно и то же значение указывать в качестве ключа несколько раз!
Что можно указывать в качестве ключа? Рассмотрим несколько примеров.
В качестве значения, выдаваемого по ключу можно использовать следующие ключевые слова.
Например, необходимо разрешить пересылать всю почту с машины с IP адресом 192.168.0.2: Connect:192.168.0.2 RELAY. Это далеко не лучший способ разрешения пересылки почты. Используйте аутентификацию.
Cуществуют и другие варианты значений, но мы не будем рассматривать их на этом курсе.
Ниже приводится возможный пример текстового файла /etc/mail/access для машины, принимающей почту для домена kryukov.biz.
Connect:localhost.localdomain RELAY Connect:localhost RELAY Connect:127.0.0.1 RELAY To:artur@kryukov.biz OK To:postmaster@kryukov.biz OK To:postmaster@cosmos.kryukov.biz OK To:root@kryukov.biz OK To:root@cosmos.kryukov.biz OK To:kryukov.biz REJECT
Данный файл помогает ограничить список почтовых ящиков, для которых сервер будет принимать почту. Почему у меня явным образом описаны почтовые ящики? Ведь если почтового ящика нет, сервер не будет принимать для него почту и сразу, на стадии соединения с другим сервером отклонит прием письма.
Это действительно так, при условии, что сервер сам определяет, есть ли в системе такой почтовый ящик. Проблема заключается в том, что у меня сервер настроен таким образом, что за ящики отвечает программа спам фильтр. И именно она выдает информацию о существующих ящиках. Спам фильтр же настроен таким образом, что он принимает почту и для несуществующих (виртуальных) ящиков. Поэтому получается, что MTA принимает письмо от другого сервера, и отдает его спам фильтру. Сообщение об отсутствии почтового ящика может быть сгенерировано уже после закрытия соединения.
И тогда почтовый сервер должен отослать по адресу отправителя сообщение о невозможности доставить письмо. Этим пользуются спамеры, таким образом вы можете стать соучастником в рассылке спама. Что не есть хорошо.
Поэтому при помощи базы доступа, мы можем на стадии соединения отказать в приеме письма. Что и сделано у меня в примере. Конечно, придется повозиться и явно описать все почтовые ящики, для которых вы будете принимать почту. Но овчинка стоит выделки.
Обратите внимание на два обязательных ящика, прием почты, для которых вы должны открыть: root и postmaster. На первый ящик по умолчанию отсылаются служебные письма, от программ, работающих на вашем сервере. Postmaster — это стандартный ящик, куда все почтовые сервера пытаются посылать сообщения об ошибках, возникающих в работе системы электронной почты.
Так же для этих ящиков вы должны явно указать не только имя домена, но имя машины, на которой работает ваш сервер. Программы, отсылающие служебную почту обычно не знают имя вашего домена. Но прекрасно знают имя машины.
После того, как вы создадите текстовый файл, его необходимо превратить в бинарную базу данных. Тут возможны два варианта. Первый — это явный вызов программы makemap:
# makemap hash /etc/mail/access < /etc/mail/access
Мы говорим программе, что бы она создала бинарную базу в виде hash таблицы (параметр hash). Результирующий файл должен находиться в директории /etc/mail и называться access.db. При вызове программы, расширение файла можно не указывать. Данные для преобразования передаются на стандартный вход программы из файла /etc/mail/access.
Второй способ. Необходимо перейти в директорию /etc/mail.
# cd /etc/mail
И запустить в ней программу make
# make
Программа сама преобразует все изменившиеся специальные файлы, находящиеся в этой директории.
После изменения файла, sendmail рекомендуется перезапустить:
# service sendmail restart
Порядок описания файлов имеет значение. Особое внимание необходимо обратить на макросы MAILER. Они должны располагаться в конце файла, но перед описанием различных локальных конфигураций. Ниже показан предпочтительный порядок описания макросов:
Локальные конфигурации, LOCAL_CONFIG и другие, пишутся на языке конфигурационного файла sendmail.cf. Позволяют расширить функционал почтового сервера. Но, к сожалению, этот язык очень сложный и мы его изучать не будем.
Наиболее предпочтительным способом разрешения пересылки почты является аутентификация пользователя.
Для разрешения пересылки аутентифицированным пользователям необходимо определить какие механизмы аутентификации считать доверенным. Добавим в файл my.mc следующую строку:
TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
При помощи макроса TRUST_AUTH_MECH мы определяем доверенные способы аутентификации.
define(`confAUTH_OPTIONS', `A p y')dnl
Оператор define определяет значение переменной confAUTH_OPTIONS. Параметры:
Если эту переменную не определить, механизм аутентификации включаться не будет.
Еще одна переменная — confAUTH_MECHANISMS, определяет какие механизмы аутентификации будут обрабатываться sendmail.
define(`confAUTH_MECHANISMS', `LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
Для нормальной работы почтовых клиентов Windows необходимо определить два механизма аутентификации: login и plain. Карма у нас такая, ничего серьезнее перечисленных механизмов они не поддерживают. Но поскольку они не надежны (в смысле безопасности), обязательно включайте TLS/SSL.
В большинстве дистрибутивов кроме самого почтового сервера, слушающего запросы на 25 порту, запускается дополнительный процесс sendmail — MSA (Агент подачи почты). Он предназначен для предварительной проверки и изменений в заголовках письма. По умолчанию он слушает запросы на 587 порту и, естественно, никакой аутентификации не поддерживает. Поэтому мы сначала запретим значения параметров по умолчанию.
FEATURE(`no_default_msa')dnl
Затем, при помощи макроса DAEMON_OPTIONS, определяем используемые сервером порты и некоторые дополнительные параметры.
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl DAEMON_OPTIONS(`Port=smtps, Name=MSA-SSL, M=E')dnl
Основной процесс sendmail (MTA — Mail Transfer Agent) будет слушать запросы на 25 порту (smtp). А агент подачи почты на 465 порту (smtps). Кроме того, параметр M=E говорит, что не будет использоваться команда ETRN, протокола SMTP.
В результате содержимое файла my.mc станет таким:
include(`../m4/cf.m4') VERSIONID(`My mega server')dnl OSTYPE(linux)dnl FEATURE(`use_cw_file')dnl FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access')dnl FEATURE(`blacklist_recipients')dnl FEATURE(`local_procmail',`',`procmail -t -Y -a $h -d $u')dnl FEATURE(`always_add_domain')dnl define(`confAUTH_OPTIONS', `A p y')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl FEATURE(`no_default_msa')dnl DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl DAEMON_OPTIONS(`Port=smtps, Name=MSA-SSL, M=E')dnl MAILER(local)dnl MAILER(smtp)dnl MAILER(procmail)dnl
Пока все прекрасно, но кроме включения собственно механизма аутентификации, потребуется настроить дополнительную программу, позволяющую sendmail осуществлять аутентификацию, и TLS.
Sendmail сам не производит аутентификацию пользователей, для этого он пользуется SASL механизмом. В системе должна быть установлена библиотека, реализующая этот механизм. В подавляющем большинстве дистрибутивов используется пакет Cyrus-sasl, с которым поставляются необходимые библиотеки.
У этого способа есть один неприятный момент — Вам прийдется заносить всех пользователей, которые должны получать почту, в специальную базу данных. (Поправьте меня, я так и не понял как в Slackware заставить брать информацию о пользователях из /etc/passwd) Делается это следующим образом:
---Поправлено---- Для того что бы в slackware пароли брались из shadow без создания баз :
в каталоге /etc/sasl2 создаем файл Sendmail.conf в него вписываем:
pwcheck_method: saslauthd
mech_list: plain login
создаем два линка (я просто не проверял откуда конкретно читается Sendmail.conf )
ln -sf /etc/sasl2/Sendmail.conf /etc/Sendmail.conf
ln -sf /etc/sasl2/Sendmail.conf /usr/lib/sasl2/Sendmail.conf
пересобираем пакет cyrus-sasl с доп настройками в файле cyrus-sasl.SlackBuild добавляем опции компиляции для того что бы sasl понимал не шифрованые пароли, керберос нам не нужен!
--enable-plain \
--disable-krb4 \
запускать демона /usr/sbin/saslauthd -a shadow
Конец поправки =)
# saslpasswd2 -a sendmail -u kryukov.ru artur #
Программа saslpasswd2 позволяет управлять этой базой. В приведенном примере мы добавили пользователя artur из домена kryukov.ru (-u kryukov.ru). Пользоваться этой информацией сможет программа sendmail (-f sendmail).
Для смены пароля пользователя программа вызывается аналогичным образом. Для удаления пользователя добавьте параметр -d.
Программа sasldblistusers2 позволяет посмотреть какие пользователи находятся в базе данных.
# sasldblistusers2 artur@kryukov.ru: userPassword artur@kryukov.ru: cmusaslsecretOTP #
| Внимание! | При конфигурации почтового клиента в разделе отправление почты в качестве логина пользователя необходимо указывать логин и домен. Для приведенного выше примера это будет выглядеть так: artur@kryukov.ru. |
Последнее, что осталось сделать — включить TLS. Это делается не сложно, достаточно добавить четыре параметра в файл my.mc и создать все необходимые ключи и сертификаты.
Что бы не генерировать все снова, возьмем ключи и сертификаты, которые мы использовали при конфигурации сервера OpenVPN (см. OpenVPN). Или сгенерируйте их самостоятельно, подробности смотрите тут: Создание ключей и сертификатов.
В my.mc добавляем следующие строки:
define(`confCACERT_PATH', `/etc/openvpn/keys/')dnl define(`confCACERT', `/etc/openvpn/keys/ca.crt')dnl define(`confSERVER_CERT', `/etc/openvpn/keys/kryukov.ru.crt')dnl define(`confSERVER_KEY', `/etc/openvpn/keys/kryukov.ru.key')dnl
Все, пересылка почты будет разрешена для пользователей подтвердивших аутентификацию.
Подключение антивируса ClamAV описано на странице, посвященной настройке антивируса.