Оглавление:
[Done] Приведение FreeBSD к состоянию, когда в ней можно работать.
[Done] Построение почтового сервера с антивирусом на базе штатного MTA FreeBSD 6.2 (sendmail)*.
[TODO] Изменение конфигурации системы для сопряжения с установленным на рабочей станции MTA postfix.
[TODO] Фильтрация спама**.
[TODO] Изменение конфигурации системы для возможности оперативного перехода с проприетарного антивируса (работоспособность которого ограничена) на Open Source.
[TODO] И сюда можно отнести кусок из прорабатываемой мной темы о построении для всего домена системы авторизации на базе OpenLDAP. В том числе, обязательную авторизацию при отправлении почты.
* Обсуждается в форуме nixp.ru.
** Обсуждалось в форуме nixp.ru.
Исходные данные:
Имеем две сети класса «С», некоторое количество зон (primary.zone, sub1.primary.zone, sub2.primary.zone, secondary.zone);
сервер должен выполнять функции почтового антивируса (клиенты-то преимущественно — под Windows), доступ к почтовым ящикам по протоколу POP3; сервер рассчитывается на 100—200 почтовых ящиков (большая часть пользователей, за исключением «мёртвых душ», переходит с используемых почтовых серверов), списки рассылки, обработка ответов на рассылки рассылаемые роботами, спам-фильтр.
Смежные вопросы (а именно: конфигурация свичей и внесение записей в DNS) будут упоминаться, но без детального рассмотрения выполняемых действий.
Первый этап: приведение FreeBSD к состоянию, когда в ней можно работать
Как уже упоминалось в моей предыдущей статье, FreeBSD last stable release, ныне — 6.2 (политика партии такая). Некоторое количество достоинств у данного решения есть, но без серьёзной доработки напильником работать с ним невозможно.
а) Сцена первая: подготовка к установке
И здесь первым же моментом — удобство: для установки полностью работоспособной системы достаточно скачать первый из двух образов дисков (забегая вперёд: качать второй — никакого смысла).
б) Сцена вторая: собственно установка
Ничего особенно выдающегося. Единственное — мягко говоря, непривычная для человека, ранее имевшего дело только с Linux, логика разбиения диска (надо всё сделать правильно на этапе установки — в уже установленной системе в конфигурации по умолчанию структуру разделов не изменить). Главное здесь — не забыть поставить исходники всего необходимого (в первую очередь, ядра) и коллекцию портов.
И сразу — подарочный набор граблей от FreeBSD Team: после установки система нормально загружается, ТОЛЬКО если корневой раздел был указан первым. Если же, как в моём случае, после привычки к Linux первым разделом на автопилоте указывается SWAP, то — добро пожаловать к танцам с бубном (дилемма: переустанавливать или искать LiveCD с поддержкой UFS2).
Также в процессе установки указывается имя хоста, основной IP-адрес и основной маршрутизатор (DNS — после установки). Доменное имя и используемые DNS-серверы прописываются в файле /etc/resolv.conf. Формат файла:
domain MYDOMAIN
nameserver NAMESERVER1
nameserver NAMESERVER2
Но в целом в процессе установки (в отличие от Linux) выполнение большей части действий по первичной настройке не предусмотрено.
в) Сцена третья: берём в руки напильник
Необходимые действия следующие:
Задать пароль суперпользователя root (задание которого в стандартную процедуру установки не входит; зато есть возможность сброса оного с помощью установочного диска).
Добавить своего рабочего пользователя (с заданием пароля).
Войти под root, в профиль (для FreeBSD — ~/.profile; ну, ни парадоксально ли? В домашней директории пользователя — файл конфигурации shell'а, отсутствующего в стандартной установке) прописать промежуточное значение переменной EDITOR (которой должно быть присвоено значение vi).
export EDITOR=vi
Также следует заменить значение переменной PAGER с дремуче-традиционного more на less.
Только в подобной установке представлен весьма скромный выбор shell'ов (я бы даже сказал, выбор оных отсутствует). В качестве оболочки по умолчанию дают csh, настройки которого, соответственно, хранятся в ~/.cshrc.
Блок, который надо вставить в этот файл (и который после установки и настройки bash'а можно с чистой совестью удалить), прилагается:
setenv PAGER less
setenv BLOCKSIZE K
setenv HTTP_PROXY PROTOCOL://ADRESS:PORT
setenv FTP_PROXY PROTOCOL://ADRESS:PORT
setenv http_proxy PROTOCOL://ADRESS:PORT
setenv ftp_proxy PROTOCOL://ADRESS:PORT
Обращаю внимание на тот факт, что здесь используются совершенно другие команды и синтаксис.
Ещё на начальном этапе скорее всего придётся наступить на грабли отсутствия в стандартном перечне путей csh /usr/local/bin.
Этот момент можно исправить на этапе правки ~/.cshrc, а можно просто проигнорировать.
Для обеспечения установки дополнительного (необходимого) ПО в большинстве реальных случаев (когда сервер не имеет прямого доступа в Сеть и выходит через proxy-сервер) необходимо указать адрес proxy-сервера (почтовый сервер — внутренний, и, соответственно, всё общение с внешним миром — через proxy).
Там же (т.е. в ~/.profile, потому что не знаю кто как, а лично я работать буду с bash) прописывается:
export HTTP_PROXY="PROTOCOL://ADRESS:PORT"
export FTP_PROXY="PROTOCOL://ADRESS:PORT"
export http_proxy="PROTOCOL://ADRESS:PORT"
export ftp_proxy="PROTOCOL://ADRESS:PORT"
Теперь надо перезайти в систему, после чего можно переходить к установке необходимого для жизни софта.
Первым этапом — обеспечение безопасности (правда, статья не вполне соответствует действительности), в смысле проверки устанавливаемого ПО на известные уязвимости.
Сначала — установка утилиты, осуществляющей проверку:
# cd /ust/ports/ports-mgmt/portaudit/
# make
# make install
Далее нужно привести в порядок конфиг в /usr/local/etc/.
To check your installed ports for known vulnerabilities now, do:
#/usr/local/sbin/portaudit -Fda
Опция -F указывает на необходимость загрузки базы, -d — печатает дату, -a — задаёт проверку всех установленных пакетов.
И в дальнейшем для поддержания базы в актуальном состоянии рекомендуется в crontab добавить следующую команду с правами суперпользователя:
/usr/local/sbin/portaudit -F
С запуском каждый день (например, в 3:40).
И, собственно, установка. Первым делом — shell, в котором можно работать:
# cd /usr/ports/shells/bash2/
# make
# make install
# make clean
Пока любимый шелл ставится/компилируется, можно заняться указанием русской локализации (koi8-r):
# vi /etc/rc.conf
Туда вставляется следующий блок:
# System console options:
keymap="ru.koi8-r"
scrnmap="koi8-r2cp866"
font8x16="cp866b-8x16"
font8x14="cp866-8x14"
font8x8="cp866-8x8"
Переключение кодировок производится клавишей <CapsLock>.
Далее:
# vi /etc/ttys
Где для всех терминалов тип cons25 меняется на cons25r, а первый выключается (on -> off) для того, чтобы в случае возникновения необходимости было удобнее читать системные сообщения.
Необходимо и достаточно для работы за физическим терминалом. Для корректной локализации при работе с виртуальным (через ssh) нужно задать тип терминала в профиле (что в некоторой степени дублирует изменения, внесённые в /etc/ttys).
$ cat ~/.profile | grep TERM
export TERM=${TERM:-cons25r}
Далее (предполагая, что shell уже установлен): редактирование профиля пользователя (команда chpass).
Необходимо прописать login class «russian» и указать shell «/usr/local/bin/bash». Остаётся установить и прописать в профиле редактор:
# cd /usr/ports/editors/vim
# make
# make install
# make clean
(В FreeBSD-интерпретации файл .vimrc не прилагается. Впрочем, мои предпочтения несколько отличаются от стандартных. Мой ~/.vimrc: vimrc. ~/.profile тоже приходится сочинять свой: profile).
После установки любимого редактора надо не забыть прописать его в качестве редактора по умолчанию в профиль.
И совершенно забыт такой архинужный файл, как ~/.bash_logout, в котором для нулевого приближения достаточно прописать всего одну команду: clear.
Если предполагается добавление заметного количества пользователей, для которых желательно сразу получить указанные настройки, вероятно, имеет смысл скопировать эти файлы (~/.profile, ~/.bash_logout и ~/.vimrc) в /etc/skel/, который в FreeBSD пустой.
После очередного перезахода в систему можно начинать настройку запуска сервисов, прописав доменное имя и используемые серверы DNS: # vim /etc/rc.conf /etc/defaults/rc.conf.
Из второго файла в первый переносится секция, посвящённая настройке ssh; демон ssh разрешается, в конфиге демона (/etc/ssh/sshd_config) прописывается запрет регистрации пользователя root, но мы этим не ограничиваемся и прописываем директиву AllowUsers (пользователи, которым разрешено заходить в систему по ssh, — с пробелом в качестве разделителя).
Теперь можно запустить демона ssh и продолжать танцы с бубном уже из тёплого помещения.
Что делает настоящий линуксоид перед настройкой боевого сервера?
Правильно: проверяет конфигурацию ядра (точнее, пересобирает его). FreeBSD также предоставляет такую возможность. Процедура компиляции достаточно хорошо (если быть честным) описана в Handbook.
Тем не менее, опишу ее кратко по шагам:
Конфигурация ядра размещается в простом текстовом файле, прозрачном для чтения и редактирования, да ещё и снабжённого практически самодостаточными комментариями.
Я бы даже сказал, что процедура конфигурации ядра в FreeBSD удобнее и понятнее, чем в Linux. Если бы не одно «но»: в стандартном конфигурационном файле присутствуют далеко не все возможные опции. О многом, пока не упрёшься, и не догадываешься.
# cp /usr/src/sys/i386/conf/GENERIC ~/MY_KERNEL
# ln -s /root/MY_KERNEL /usr/src/sys/i386/conf/MY_KERNEL
# vim /root/MY_KERNEL
В правке конфига ядра (точнее, в выяснении используемых модулей) незаменимым подспорьем является файл /var/run/dmesg.boot. Особо оговариваю тот момент, что в данном случае (да и наверное, в принципе) отключать бинарную совместимость с предыдущими версиями FreeBSD категорически НЕ рекомендуется.
После приведения файла конфигурации в соответствие со своими представлениями о том, что должно работать на сервере (с учётом реально используемых модулей), сборка ядра завершается:
# cd /usr/src/sys/i386/conf/
# /usr/sbin/config MY_KERNEL_CONFIG
# cd ../compile/MY_KERNEL_CONFIG
# make clean
(Последнее — архиполезно при пересборке.)
# make cleandepend
# make depend
# make
# make install
(По этой команде загрузчик переписывается автоматически.)
Для перехода на новое ядро:
# shutdown -r now
И ещё один момент в плане комментария: в ядро зашивается текущее значение hostname!
Для анализа поведения системы обычно бывает полезно раскомментировать в файле /etc/syslog.conf строку, содержащую описание all.log (при этом в /etc/newsyslog.conf соответствующая запись вносится автоматически).
И ещё по настройке логирования: в строке, содержащей объявление /var/log/messages рекомендуется убрать упоминание размера лога (т.е. ротировать по времени независимо от объёма записанной информации).
В качестве завершающего штриха — настроить обновление системы.
Для чего необходимо установить пару портов:
net/cvsup-without-gui — для обновления дерева портов (примеры команд и управляющих файлов размещаются в /usr/share/examples/cvsup/; особо выделю тот момент, что для рассматриваемого случая [доступ в Сеть через proxy] в файле обновления (для дерева портов — это ports-supfile) в качестве источника обновлений по умолчанию надо указывать имя хоста того proxy-сервера, который был прописан в профиле на этапе подготовки к установке);
ports-mgmt/portupgrade — один из инструментов для обновления ПО, установленного из портов.
Также в качестве подспорья в поиске сервера (особенность администрирования Unix: достаточно быстро забывается, где стоит сервер и как он выглядит) полезно установить любимую утилитку: sysutils/eject.
Кроме того, даже для случая внутреннего сервера необходимо поднять и сконфигурировать firewall (в моём случае — для FreeBSD это традиционно ipfw), но описание безопасных и в то же время обеспечивающих всю необходимую функциональность принципов настройки firewall'а выходит за рамки данной статьи. Информацию об этом можно найти в другой моей статье — «Стартовый минигид по пакетному фильтру FreeBSD ipfw».
Остался последний момент: добавить системного пользователя, под которым будешь работать и не забыть прописать его в /etc/group в группу wheel (чтобы разрешить этому пользователю выполнение команды su -).
Таким образом, Свободная Бздя приводится к состоянию, когда в ней более не менее можно работать. Но ты никогда не будешь знать, когда и на какие именно грабли ты наступишь в следующий раз.
После обновления XOrg из портов до версии 7.2 может возникнуть проблема с работой X11 Forwarding sshd (если оный XForwarding используется). Причина в изменении стандартных путей к командам на несовпадающие с использованными при компиляции значения.
В данном конкретном случае решается следующим образом:
# cd /usr/X11R6/bin/
# ln -s /usr/local/bin/xauth xauth
(Обсуждение этой проблемы в форуме nixp.ru, ее решение — в архиве рассылки freebsd-ports.)
Второй (главный) этап: конфигурация почтовой системы
В качестве платформы была выбрана Свободная Бздя с жёстко встроенным в корпус sendmail (рассмотрением которого в общем случае я бы не хотел ограничиваться, хотя, возможно, это буду уже не я).
Соответственно, необходимость выбора платформы устранена: MTA (Mail Transfer Agent) уже имеется, причём интегрированный (в чём не только удобства).
Осталось активировать MTA, определиться с необходимой функциональностью и задействовать оную, поставить антивирус и обеспечить возможность пользователям со своих клиентских машин забирать почту. Всего — ничего…
По условиям задачи большая часть пользователей (вместе с почтовыми ящиками) переносится с двух других серверов (с попутным удалением мёртвых душ). Итак, поехали.
Рассмотрим, что в нулевом приближении представляет из себя электронная почта в UNIX.
ОС UNIX изначально разрабатывалась как сетевая многопользовательская операционная система. И в ней изначально были предусмотрены механизмы как для обмена сообщениями между пользователями одной системы, так и между пользователями разных систем.
Качественная связь == эффективность работы и, соответственно, деньги.
Со временем система обмена сообщениями вышла за рамки рабочих групп на просторы большой Сети.
Концепция почты UNIX проста:
У каждого пользователя есть свой ящик (специальный файл), в котором хранятся поступающие на его адрес сообщения
Отправляемые сообщения в соответствии с информацией, содержащейся в поле адреса, пересылаются к следующему узлу сети и так до достижения адресата (или выполнения условий останова).
Система стара как мир, следствием чего является конструктивно заложенная головная боль администратора сетевой безопасности.
С наступлением эры персональных компьютеров (и сопутствующим падением грамотности пользователей) необходимость давать shell и домашнюю директорию для каждого пользователя, которому нужна лишь электронная почта, (и учить этим пользоваться) пропала.
Но главное: «почтовый ящик — это реальный системный пользователь» — осталось неизменным.
Хотя в процессе разработки темы я встречал упоминания о возможности ситуации, когда почтовый ящик оторван от сущности системного пользователя, никакой конкретики не нашёл. Т.е. хотя целесообразность такой возможности для систем с большим количеством пользователей очевидна, большого распространения она не имеет.
А тенденция к построению в рамках домена единой системы авторизации на базе LDAP — возвращение к старым проверенным решениям, только на новом уровне.
Для начала было бы очень неплохо определиться с версией sendmail.
И тут — «приятный» сюрприз: в отличие от того же Gentoo Linux, pkg_info информации о версиях встроенного ПО не выводит. Приходится прибегать к разного рода ухищрениям. telnet на 25-й порт — не спортивно. Используем другой метод:
# echo \$Z | /usr/sbin/sendmail -bt -d0
Выводится до фига разного интересного, в том числе желаемое:
Version 8.13.8
Перенос для пользователей должен быть произведён незаметно, отсюда — и перенос почтовых ящиков, и перенос паролей.
Добавление ПОЧТОВЫХ пользователей в систему осуществляется следующим образом:
# pw useradd $MAIL_ADRESS -c $REAL_USER_NAME -d /nonexistent -g $MAIL_GROUP -s /sbin/nologin
Перенос — несколько сложнее:
Сначала на одном, а потом — и на втором из существующих почтовых серверов (исходим из того, что на них разные модные возможности типа хранения учётных записей пользователей в базе с доступом через LDAP не реализованы) выполняется команда vipw. В окне редактора отделяются учётные записи почтовых пользователей от системных и сохраняются в отдельных файлах, которые переносятся на новую машину. В /etc/group надо завести специальную группу (например, pop3user).
Далее — информация переносится в базу пользователей нового сервера. При этом придётся редактировать UID'ы (на предмет устранения нарушений уникальности), приводить к актуальному виду комментарии и указывать правильные домашние каталоги, группы и shell.
При редактировании пользователей, которым на этой машине будет предоставляться только сервис электронной почты, считаю правильным задание UID'ов в диапазоне от 20000 (будет полезно на этапе организации резервного почтового сервера домена).
При необходимости — внести дополнительные учётные записи (можно особо не напрягаясь — ручками в редакторе, вызываемом командой vipw).
Следующим этапом — установка антивируса. В наличном случае это Касперский. Версия под FreeBSD заявлена. Только проблема: у них много разной продукции, и определение нужного — нетривиальная задача.
Стандартный антивирус от Касперского слишком требователен к ресурсам. И работает по неправильному алгоритму. Но у них есть и почтовый фильтр (Milter) для sendmail.
Скачать его можно, например, здесь: ftp://dnl-ru2.kaspersky-labs.com/produc … avmilter/.
Пакет: в моём случае (и на момент установки) — kav4milter-freebsd5.4-5.6.20_2.
Как видно из названия, пакет собран для FreeBSD 5.4. Для ветки 6.X версии не предусмотрено. И тут нам пригодится оставленная на этапе сборки ядра бинарная совместимость с FreeBSD 5.X.
Документацию брать здесь: http://dnl-ru1.kaspersky-labs.com/docs/ … ailru.pdf.
Установка — почти как обычно:
# pkg_add $PATH_TO/kav4milter-freebsd5.4-5.6.20_2
Ключ (без которого не работает) в процессе установки не спросили, настройки сети (proxy) также не были даже упомянуты (установка антивируса Касперского — это такой увлекательные квест для админов: догадайся, что ещё нужно сделать, чтобы оно заработало).
Под конфигом подразумевается следующий файл: /usr/local/etc/kav/5.6/kavmilter/kavmilter.conf.
Пакет собран совершенно невнятно. Создаётся ощущение, что люди, занимавшиеся генерацией пакетов, are far from being familiar with FreeBSD package system. Пути — совершенно невменяемые; например, основные файлы хранятся в /usr/local/share/kav/5.6/kavmilter/, настройки — в /usr/local/etc/kav/5.6/kavmilter/, почтовые базы и логи — в /var/db/kav/5.6/kavmilter/.
Кое-что из настроек по умолчанию (что совсем уж напрягало) я поправил. Но править всё — увольте.
Регистрация ключа:
# /usr/local/share/kav/5.5/kav4mailservers/bin/licensemanager -a $PATH_TO_KEY/$KEYNAME.key
И попытка запуска:
# /usr/local/etc/kav/5.6/kavmilter/rc.d/kavmilterd start
И, естественно, облом. Наши друзья — разработчики проприетарного ПО — накосячили не только со структурой каталогов в пакете. Ругань на библиотеки. В Сети нашёл подсказку.
Полностью вылечилось (для моего случая две первые ссылки, ВОЗМОЖНО, лишние) следующим шаманским заклинанием:
# cd /lib
# ln -s libm.so.4 libm.so.3
# ln -s libc.so.6 libc.so.5
# ln -s /usr/lib/libkvm.so /usr/lib/libkvm.so.2
В процессе установки антивируса в основной конфигурационный файл почтового агента (/etc/mail/sendmail.cf) Касперский добавляет две секции (существующий /etc/mail/sendmail.cf перед этим копируется в /etc/mail/sendmail.cf.bak). О правке исходников речи не идёт. Этот момент существенен, его должно запомнить.
Дальше нужно установить антивирусные базы и настроить их обновление. В общем-то, для решения этой задачи достаточно воспользоваться скриптом: /usr/local/share/kav/5.6/kavmilter/bin/keepup2date.sh, запуская его с ключиком -install.
Насколько я помню, обещание добавлять задачу в crontab текущего пользователя не вполне соответствует действительности. Задача установки и обновления баз прописывается в crontab пользователя kav, что есть правильно. Прописывается задача с рекомендованным разработчиком антивируса периодом обновления 1 час. ИМХО, имеет смысл поставить что-нибудь поменьше: минут 20…30.
В правке чистоты запуска отдельных служб остаётся исправить только один момент:
В наличной Сети IPv6 не используется, и при пересборке ядра поддержка IPv6 была отключена. Но sendmail — штатный, и собирался с поддержкой IPv6. Соответственно, ему не нравится отсутствие поддержки IPv6 в ядре, на что он и ругается.
Пересобирать sendmail лениво, и, забегая вперёд, скажу, что в исходных файлах конфига отключения IPv6 не нашёл, поэтому правка свелась к комментированию в /etc/mail/sendmail.cf двух строчек, в которых фигурирует IPv6.
Осталось настроить правильный порядок старта сервисов, ибо антивирус Касперского по умолчанию ставится в /usr/local/, а sendmail пускается из /etc/rc.d/sendmail. Соответственно, при сохранении стандартной конфигурации сначала стартует sendmail, потом — Касперский. При этом письма, полученные во временном интервале между стартом sendmail и Antivirus Milter, теряются. Ни эти потери, ни лишние сообщения об ошибках в логах мне не нужны.
Согласно здравому смыслу СНАЧАЛА должен стартовать Antivirus Milter, и только после него — MTA (хотя, на самом деле, заметной практической разницы здесь нет: всё равно, если в /etc/mail/sendmail.cf прописан Milter, до запуска его демона sendmail письма не принимает).
И здесь во всей красе предстаёт «интуитивная понятность» BSD style init для случая, когда необходимо явно задать определённый порядок старта сервисов.
Разбираться с тем, как должна решаться эта задача, было некогда (преимущественно потому, что путей решения, не противоречащих логике построения системы, не просматривалось). Тем более, что и Касперский с зашитой в пакет структурой каталогов без дополнительных костылей системными средствами самостоятельно автоматически не запускался (почему запуск sendmail'ом меня не устраивает, я объяснил).
Посему проблема была решена грубо и неизящно:
В стартовом скрипте sendmail (/etc/rc.d/sendmail) в секции sendmail_precmd() было добавлено дополнительное условие проверки состояния антивируса:
# check antivirus state
if [ -f "/var/db/kav/5.6/kavmilter/run/kavmilter.pid" ]; then
echo "KAVMilter already started"
else
/usr/local/etc/kav/5.6/kavmilter/rc.d/kavmilterd start
fi
После перезагрузки и анализа логов/сообщений на консоли было получено подтверждение тому, что все сервисы стартуют, причём стартуют в правильном порядке.
Теперь можно приступать к собственно вопросу настройки sendmail:
Порядок рассмотрения:
Какие возможности нужны и зачем (и как их можно активировать при необходимости).
Обновление конфигурации sendmail в FreeBSD 6.X.
Конфигурационные файлы антивируса. Формат и назначение.
Начнём с первого пункта.
Необходимо обеспечить приём почты на адреса, доменные имена которых далеко не всегда совпадают с доменным именем машины — сервера электронной почты. Это реализуется в два этапа:
Все домены, для которых принимается почта, прописываются в качестве точек останова в /etc/mail/local-host-names.
Активируется база пользователей /etc/mail/virtusertable.
В штатном sendmail FreeBSD 6.X последняя функция активирована, и в /etc/mail/ даже лежит файл с примерами. Формат файла следующий:
mail-user1@rootdomain.zone system-user1
mail-user2@subdomain1.rootdomain.zone system-user2
mail-user1@subdomain2.rootdomain.zone system-user3
mail-user1@otherdomain.zone system-user4
И т.д.
Списки рассылки в этом файле указываются аналогично:
list@rootdomain.zone maillist_file
В данном файле разрешаются дубли, т.е. произвольное количество почтовых адресов для одного почтового ящика (или системного пользователя). Но пустые строки категорически не приветствуются. Лишние столбцы — так просто запрещены. При этом необходимо помнить, что:
system-user1@rootdomain.zone
system-user1@subdomain1.rootdomain.zone
system-user1@subdomain2.rootdomain.zone
system-user1@otherdomain.zone
— вполне работоспособные почтовые адреса (независимо от содержимого файла /etc/mail/virtusertable).
И если вы не хотите, чтобы пользователь, приписанный к одному домену. получал почту, адресованную тому же пользователю из другого домена, то необходимо закрыть все объявленные домены. Делается это подстановкой в конце файла /etc/mail/virtusertable следующих строк:
#Close all listed domains
#All valid users must be described above!!!
@rootdomain.zone error:nouser No such user here
@subdomain1.rootdomain.zone error:nouser No such user here
@subdomain2.rootdomain.zone error:nouser No such user here
@otherdomain.zone error:nouser No such user here
При этом надо отдавать себе отчёт в том, что при использовании такой конфигурации файл /etc/mail/aliases, содержащий почтовые псевдонимы и адреса для перенаправления почты, фактически используется только для перенаправления почты системных пользователей и объявления списков рассылки. Все дополнительные почтовые адреса пользователей электронной почты должны быть перечислены в /etc/mail/virtusertable.
И ещё один момент: по условиям задачи почтовый сервер должен «приземлять» на конкретный, прописанный в /etc/mail/aliases, список рассылки письма, приходящие в ответ на рассылки с адресов robot1@host1.rootdomain.zone и robot1@host2.subdomain1.rootdomain.zone.
Прописывать указанные машины в /etc/mail/local-host-names (что равноценно «приземлению» всего почтового трафика для пользователей этих серверов) на почтовый сервер — некрасиво и неправильно. Для того, чтобы сказать sendmail'у искать соответствие пользователей, приписанных к другим хостам в базе /etc/mail/virtusertable, необходимо задействовать другую возможность, которая в стандартных настройках FreeBSD sendmail уже отсутствует.
Для её активации в исходники конфига sendmail (собственно, процедура получения этого файла и обновления конфигурации sendmail будет рассмотрена ниже) необходимо добавить следующие строки:
VIRTUSER_DOMAIN_FILE(`-o MAIL_SETTINGS_DIR`'virtual-domains')
FEATURE(`virtuser_entire_domain')
И создать файл /etc/mail/virtual-domains следующего содержания:
host2.subdomain1.rootdomain.zone
host1.rootdomain.zone
Теперь (в смысле, после пересборки файла конфигурации и рестарта) почтовый сервер при получении почты в адрес host2.subdomain1.rootdomain.zone или host1.rootdomain.zone перед перенаправлением адресату будет просматривать базу /etc/mail/virtusertable на предмет необходимости «приземления» сообщений, направленных пользователям этих серверов в локальный почтовый ящик.
В одной из итераций (за Web-программистов я не отвечаю) стараниями наших заклятых «друзей»-спамеров возникла необходимость решить эту же задачу другим способом. А именно: вместо адреса робота. осуществляющего рассылку, в поле «From» подставить адрес списка рассылки. на который нужно приземлять ответы.
Решать эту задачу корректно для общего случая мне было лениво. Всё равно с указанных двух хостов кроме отмеченных выше роботов никто почту не рассылает. Поэтому я пошёл совершенно ленивым путём: в описанном ниже файле /etc/mail/generics-domains прописал указанные хосты, с которых осуществляется рассылка (особо отмечу тот факт, что рассылка осуществляется через построенный почтовый сервер), а в /etc/mail/genericstable добавил две строчки:
robot1@host1.rootdomain.zone list@rootdomain.zone
robot1@host2.subdomain1.rootdomain.zone list@rootdomain.zone
Теперь исходящий трафик. Рассматриваемый почтовый сервер является оконечным для львиной доли принимаемого трафика. Однако, будучи Primary MX (Mail Exchanger) своего домена, производит трансляцию почтового трафика на ряд хостов своего домена. При этом должен быть реализован контроль со стороны сервера за правильностью указания пользователями адресов (либо сервер выдаёт ошибку при попытке отправления письма, либо правильно прописывает доменное имя независимо от настроек почтового клиента).
Реализуется это внесением в исходный файл конфигурации sendmail, например, следующих строк:
FEATURE(`genericstable')
FEATURE(generics_entire_domain)
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')
Файл — /etc/mail/genericstable. Формат файла — обратный /etc/mail/virtusertable, т.е. в первом столбце — системные пользователи (реальные владельцы файлов почтовых ящиков), а во втором — адреса электронной почты, которые подставляются sendmail в поле FROM при отправлении этими пользователями письма. Разделителем, как и в случае /etc/mail/virtusertable, является <TAB>.
Единственное (правда, вполне радикальное) отличие от /etc/mail/virtusertable — то, что дубли не допускаются. Для каждого системного пользователя — не больше одной записи.
Домены, на которые распространяются правила замены, заданные в /etc/mail/genericstable перечислены в файле /etc/mail/generics-domains. Формат файла следующий:
rootdomain.zone
subdomain1.rootdomain.zone
subdomain2.rootdomain.zone
otherdomain.zone
Пользователи, не перечисленные в файле /etc/mail/genericstable, могут отправлять письма с любых доменов, прописанных на данный почтовый сервер.
Но данная возможность при использовании совместно с широко известным и много где описанным способом «приземления» почтового трафика на одинаковые адреса в разных доменах (физически расположенных на одном сервере) имеет нежелательный побочный эффект. Для случая двух адресов:
mail-user1@rootdomain.zone
mail-user1@subdomain1.rootdomain.zone
Независимо от указанного в настройках клиента в поле FROM пишется первая строка, встречающаяся в базе /etc/mail/genericstable. Есть решение этой проблемы.
Аналогично тому, как в случае организации «приземления» почтового трафика, я посчитал логичным и правильным применить следующую стратегию именования системных пользователей: для корневого домена — собственно, mail-user1, а для домена, занимающего нижнюю ступеньку иерархии, — subdomain1mail-user1. Также и для организации правильного указания адресов в исходящих письмах я посчитал правильным создать виртуальный почтовый ящик subdomain1mail-user1@subdomain1.rootdomain.zone (если получение почты на него нежелательно, можно перенаправить в /dev/null). Для этого ящика в /etc/mail/genericstable прописал подстановку правильного почтового адреса (mail-user1@subdomain1.rootdomain.zone), а пользователю в настройках клиента прописал созданный виртуальный почтовый адрес.
Других проблем с адресацией не возникло.
Осталось задать маршруты, по которым будет направляться почта, адресованная вовне. Маршруты прописываются в файле, который так и называется: /etc/mail/mailertable.
Мета-символы: в случае sendmail «.» означает то же самое, что «*» в shell (т.е. произвольную последовательность символов).
Формат файла:
домен протокол и направление маршрутизации
. smtp:mailgateway.zone
# И заворот почты на хосты, где запущен свой MTA и присутствуют
# пользователи, получающие почту извне:
host1.rootdomain.zone smtp:host1.rootdomain.zone
host2.subdomain1.rootdomain.zone smtp:host2.subdomain1.rootdomainzone
В процессе эксплуатации выяснился ещё один момент:
В реальном рабочем режиме с настройками антивируса по умолчанию производительности сервера оказалось недостаточно. На проверке архива RAR размером 1,46 МБ антивирус отбивал письмо по таймауту.
Проблема была решено заменой в конфиге (/usr/local/etc/kav/5.6/kavmilter/kavmilter.conf) значения параметра MaxScanTime с 60 с на 120.
После обновления файлов конфигурации sendmail и рестарта изменения вступят в силу.
Осталось произвести настройки, относящиеся к последней миле. Сначала — приём и трансляция почты от клиентов.
В файле /etc/mail/relay-domains прописываются домены, с которых sendmail разрешено принимать почту для дальнейшей передачи.
Раздача почты клиентам осуществляется по протоколу POP3. Стандартным почему-то считается qpopper (/usr/ports/mail/qpopper/). Пусть будет.
Относительно make config скажу лишь, что в силу отсутствия внятного описания (и непонятных результатов сборки) standalone-версии, желания выёживаться и пускать его таким образом не возникло. Пускаем по старинке через inetd. Так что после установки (cd /usr/ports/mail/qpopper && make && make install && make clean), необходимо внести соответствующие изменения в /etc/inetd.conf и /etc/rc.conf.
В /etc/inetd.conf добавляется следующая строка:
pop3 stream tcp nowait root /usr/local/libexec/qpopper qpopper -f /usr/local/etc/qpopper.conf
Сразу говорю: не совсем то, что рекомендовано при установке. Зачем/почему — поясню ниже.
В /etc/rc.conf добавляется следующий блок (берётся из /etc/defaults/rc.conf, с заменой s:/NO/YES/ в строке inetd_enable):
# Entry to enable POP3 server, which starts from inetd
inetd_enable="YES" # Run the network daemon dispatcher (YES/NO).
inetd_program="/usr/sbin/inetd" # path to inetd, if you want a different one.
inetd_flags="-wW -C 60" # Optional flags to inetd
#
После чего — правка конфигурационного файла /usr/local/etc/qpopper.conf. Реально в этом файле необходимо только раскомментировать строку относительно ведения логов:
set statistics = true
Изначально логирование обращений предлагается задавать опцией командной строки. И задать источник, куда будут писаться логи. В моём случае — это:
set log-facility = local6
По умолчанию qpopper работает с таймаутом 120 секунд. Казалось бы, куда больше? Однако в процессе эксплуатации пришлось столкнуться с ситуацией, когда стараниями антивируса (клиенты-то в большинстве на Windows, и им без дяди касперского никуда; следовательно, включение в рассмотрение помимо скорости передачи данных по сети параметра быстродействия клиента) на размере ящика всего-то 73 мегабайта этого оказалось недостаточно. Поставил значение 600 секунд.
(Проблема обсуждалась в форуме nixp.ru.)
Это было бы неплохо задать на системном уровне, т.е. в /etc/syslog.conf и в /etc/newsyslog.conf (и здесь — очередной «приятный» сюрприз от FreeBSD Team: syslogd вносит записи в журнал, только когда файл определён в обоих конфигах, но во второй, в /etc/newsyslog.conf, объявление большинства интересующих меня журналов приходится добавлять вручную. При этом, если у администратора возникает желание воспользоваться функциональностью syslogd только для ротации логов, подобных проблем не возникает).
В /etc/syslog.conf добавляется следующая строка:
local6.* /var/log/qpopper.log
Но этим правка /etc/syslog.conf не ограничивается, потому что в такой конфигурации qpopper своим весьма обильным потоком сообщений доводит до практически не читаемого состояния журнал /var/log/messages. Для исправления этого в конфигурационном файле /etc/syslog.conf в строку, определяющую /var/log/messages, вносится параметр, запрещающий запись туда вывода qpopper (в рассмотренной конфигурации):
local6.none
(Разделителем параметров является «;».)
Для настройки ротации в /etc/newsyslog.conf добавляется следующая строка:
/var/log/qpopper.log 640 7 * @T00 JC
(На самом деле, это не единственный способ задания логирования сообщений qpopper в отдельный файл.)
(Ещё есть возможность контроля за списком пользователей, которым открыт доступ к POP3, но здесь я соглашаюсь с разработчиками qpopper).
Теперь можно запускать сервис inetd:
# /etc/rc.d/inetd start
Рассмотрим вопрос обновления конфигурации sendmail в FreeBSD 6.X. Теперь это делается не просто, а очень просто.
Для обновления информации о пользователях в операционных базах:
# cd /etc/mail
# make
# make restart
(По команде make обновляются все файлы, исходники которых изменялись с даты последней генерации.)
Обновление главного конфигурационного файла (с учётом моего конкретного случая, т.е. внесения ряда правок напрямую в /etc/mail/sendmail.cf и желания сохранить эти изменения в обновлённой версии) является несколько менее простой и очевидной задачей.
По команде:
# cd /etc/mail && make
Производится не только обновление операционных баз, но и генерация как исходного файла конфигурации senmail (с именем формата /etc/mail/$HOSTNAME.mc), так и создаваемого на его базе файла конфигурации, который должен совпадать с /etc/mail/sendmail.cf (с именем /etc/mail/$HOSTNAME.cf) и которым следующей командой из инструкции переписывается действующий файл конфигурации (/etc/mail/sendmail.cf), что в моём случае является лишним.
Соответственно, исходный файл получен. Самое время сделать резервную копию рабочего файла конфигурации:
# cd /etc/mail/sendmail.cf /etc/mail/sendmail.cf.kav
Теперь нужно внести уже описанные изменения в исходный файл конфигурации /etc/mail/$HOSTNAME.mc и скомпилировать конфигурационный файл, элементарно сказав make в /etc/mail/. Далее надо ручками перенести внесённые в /etc/mail/sendmail.cf изменения в новый конфигурационный файл, переписать /etc/mail/sendmail.cf файлом /etc/mail/$HOSTNAME.cf и перезапустить sendmail (после замены конфига лучше всё-таки через /etc/rc.d/sendmail).
В случае правки операционных баз sendmail достаточно в каталоге /etc/mail выполнить:
# make
# make restart
Вроде бы всё сделано? Да как бы не так!
Конфигурация антивируса Касперского по умолчанию от вирусов не лечит — она их просто транслирует адресатам. Поэтому необходимо доработать антивирус напильником (особенно, если учесть тот факт, что он ни самостоятельно ротировать свои логи не может, хоть эта возможность и заявлена, ни с syslogd корректно взаимодействовать не умеет.).
Сначала: настройка проверки на вирусы.
Профили лежат в каталоге (по умолчанию при установке пакета) /usr/local/etc/kav/5.6/kavmilter/groups.d/. Оттуда читаются файлы с расширением *.conf. Файлы снабжены достаточно хорошими комментариями. Также есть какое-никакое описание в формате PDF. Стандартные профили разработчика можно взять в каталоге /usr/local/etc/kav/5.6/kavmilter/profiles/ (туда же желательно положить резервную копию того, что есть по умолчанию).
Правильнее же — хотя бы ознакомиться с тем, что будет делать программа. Поэтому мой путь — правка установленного по умолчанию (естественно, предварительно сделав резервную копию).
Поправил в соответствии со своими представлениями о здравом смысле, перезапустил — и (о чудо!) антивирус Касперского начал лечить jn вирусов.
Правда, в процессе эксплуатации выяснился другой неприятный момент (связанный с наличной технологической цепочкой). А именно: то, что Касперский не умеет читать архивы в формате .arj (возможность рассылки которых является необходимым требованием). Соответственно, в качестве действия выполняемого при ошибке чтения (в принципе) пришлось прописать «Skip».После чего осталось исправить правила рассылки уведомлений:
Значения по умолчанию для NotifySender=none и NotifyAdmin=none были оставлены без изменений, а вот для получателя — маразматическая строка NotifyRecipients=all была заменена на блок:
NotifyRecipients=infected
NotifyRecipients=suspicious
NotifyRecipients=filtered
Ибо ну зачем получателю письма уведомление антивируса в письме с архивом, который антивирус читать не умеет или который элементарно защищён паролем?
Последний штрих — настройка логирования.
В основном конфигурационном файле Касперского (/usr/local/etc/kav/5.6/kavmilter/kavmilter.conf) прописывается запрет на самостоятельные попытки ротации логов, которые он пишет всё же самостоятельно.
Соответственно, достаточно добавить следующую строчку в /etc/newsyslog.conf:
/var/log/kavmilter.log kav:kav 640 7 * @T00 JC
И здесь мы упираемся в ублюдочность Касперского, усугубляемую ограниченностью штатного механизма ротации логов FreeBSD. Указания PID'а в строке для корректного перехода к записи в новый файл недостаточно. А механизм ротации логов в отличие от банального logrotate (который, конечно, в потрах есть, но вот полная замена им встроенного механизма ротации логов требует слишком больших трудозатрат — это не Gentoo, где даже для куцего стандартного набора ПО можно сказать emerge --unmerge $PACKAGE_NAME) не предусматривает возможности указания postcmd. Соответственно, пришлось тупо прописывать перезапуск антивируса в crontab пользователя kav в качестве ежедневно выполняемой в 00:01 задачи.
Осталось лишь указать время хранения логов (ограничением здесь является свободное место на жёстком диске):
Для логов sendmail посчитано достаточным 64 дня.
Для логов qpopper — 32.
Логи антивируса хранятся в течение недели (потому как слишком обильный поток сознания записывается Касперским).
На этом настройку в том, что касалось почтовика можно считать завершённой. Но с точки зрения сервера необходимо сделать ещё несколько штрихов.
По условиям задачи, обслуживаемая данным почтовым сервером зона разделена на несколько участков, и по крайней мере один из них не должен иметь связи с внешним миром иначе чем через электронную почту. Соответственно, почтовый сервер должен присутствовать в нескольких сетях, и на нём необходимо поднять как минимум два сетевых интерфейса.
В принципе, типовой современный сервер (железяка) снабжается 2—4 сетевыми картами. Но эти карты — всегда ограниченный ресурс. Причём близкий к исчерпанию. К тому же, использование этого способа — лишние провода, и необходимость задействовать (а для того, чтобы задействовать необходимо иметь) дополнительные порты свича.
Проще (не нужно провода тянуть и вообще не нужно никуда ходить) использовать виртуальные интерфейсы (особенно с учётом того факта, что пропускной способности одной сетевой карты, с учётом назначения, достаточно).
Активация ручками:
Создать виртуальный интерфейс:
# ifconfig <vlan_name> create
«Поднять» его:
# ifconfig <vlan_name> <ip_address> netmask <subnet_mask> vlan <vlan_id> vlandev <physical_interface>
Для автоматического выполнения этих действий в /etc/rc.conf необходимо добавить две строки:
cloned_interfaces="vlan0" # List of cloned network interfaces to create.
ifconfig_vlan0="inet 192.168.1.1 netmask 255.255.255.0 vlan 101 vlandev em0"
На самом деле, в стандартном ядре функциональность обеспечивается модулем и (если ничего не менять) можно создать много виртуальных интерфейсов. Также можно задать их жёстко в ядре (вот она, замечательно «полная» документация FreeBSD: в страничке Handbook, посвящённой сборке ядра, об этом не говорится).
Осталось немного: проверить, как ведёт себя построенная система под нагрузкой. Главный упор — на минимизацию потерь.
Система тестировалась на прохождение писем с прикреплёнными файлами размером до 4 мегабайт. При этом наличествовал файл с вирусами, так что работа антивируса тоже проверялась.
Итак, сначала нужно создать файлы:
$ dd if=/dev/random of=/PATH/TO/TARGET/FILE bs=1024k count=1
$ dd if=/dev/random of=/PATH/TO/TARGET/FILE bs=1024k count=2
$ dd if=/dev/random of=/PATH/TO/TARGET/FILE bs=1024k count=3
$ dd if=/dev/random of=/PATH/TO/TARGET/FILE bs=1024k count=4
Потом — организовать рассылку. Здесь я считаю правильным рассылать письма с 2—3 узлов сети на один тестовый адрес с указанием в заголовке отправителя и типа письма и записью информации об отправленных письмах в лог.
В предположении, что на всех узлах, с которых предполагается осуществлять тестовую рассылку, часы синхронизированы с одной точки, предлагается запустить по cron следующий скрипт, который при наличии необходимости/желания легко модифицируется под индивидуальные пожелания (в данном варианте — с каждого узла посылается от 1024 до 4096 писем):
#!/bin/sh
#
#
LETTERS=4048 # | 1024 | 4096
SENDER=$HOSTNAME
LETTER=0
BLANK=0
1M_ATTACH=0
1M_FILE=/PATH/TO/FILE
2M_ATTACH=0
2M_FILE=/PATH/TO/FILE
3M_ATTACH=0
3M_FILE=/PATH/TO/FILE
4M_ATTACH=0
4M_FILE=/PATH/TO/FILE
INFECTED_ATTACH=0
INFECTED_FILE=/PATH/TO/FILE
RANGE=6
while [ "$LETTER" -lt "$LETTERS" ]
do
number=$RANDOM
let "number %= $RANGE"
case "$number" in
[[:0:]] ) set FILE=blank;;
[[:1:]] ) set FILE=1M_FILE;;
[[:2:]] ) set FILE=2M_FILE;;
[[:3:]] ) set FILE=3M_FILE;;
[[:4:]] ) set FILE=4M_FILE;;
[[:5:]] ) set FILE=INFECTED_FILE;;
esac
if [ "$number" -eq "0" ]
then
mutt -s "Mail No_$LETTER from $SENDER without\
attach" test@rootdomain.zone < mail.message
else
mutt -s "Mail No_$LETTER from $SENDER with\
file $FILE" -a $FILE test@rootdomain.zone < mail.message
fi
# Подготовка данных для записи в лог:
case "$number" in
[[:0:]] ) BLANK=`expr $BLANK + 1`;;
[[:1:]] ) 1M_ATTACH=`expr 1M_ATTACH + 1`;;
[[:2:]] ) 2M_ATTACH=`expr 2M_ATTACH + 1`;;
[[:3:]] ) 3M_ATTACH=`expr 3M_ATTACH + 1`;;
[[:4:]] ) 4M_ATTACH=`expr 4M_ATTACH + 1`;;
[[:5:]] ) INFECTED_ATTACH=`expr INFECTED_ATTACH + 1`;;
esac
# Сохранение текущего номера письма в файле счётчика
LETTER=`expr $LETTER + 1`
# И запись строки в подробный лог:
echo "`date +%H:%M:%S` отправлено тестовое письмо\
номер $LETTER (attach: $FILE)" | tee -a detailed_mailtest.log
done
# Собственно запись общий в лог:
echo "`date +%H:%M` from $SENDER на адрес\
test@rootdomain.zone было отправлено" > sendmail_test.log
echo "$BLANK - пустых писем" >> sendmail_test.log
echo "$1M_ATTACH - писем\
с прикреплённым файлом в 1 Мб" >> sendmail_test.log
echo "$2M_ATTACH - писем \
с прикреплённым файлом в 2 Мб" >> sendmail_test.log
echo "$3M_ATTACH - писем \
с прикреплённым файлом в 3 Мб" >> sendmail_test.log
echo "$4M_ATTACH - писем \
с прикреплённым файлом в 4 Мб" >> sendmail_test.log
echo "$INFECTED_ATTACH - писем\
с прикреплённым инфицированным файлом" >> sendmail_test.log
exit 0
Завершающий штрих — прописать построенный почтовый server в DNS в качестве Primary MX для всех обслуживаемых им зон (и перезапустить демона named). И закончить настройку системы логирования: для Primary MX-домена запись сообщения mail.crit в /var/log/messages может привести этот журнал к нечитаемому виду. Поэтому рекомендуется в /etc/syslog.conf добавить следующую строку:
mail.* /var/log/mail-error.log
А в /etc/newsyslog.conf — следующую:
/var/log/mail-error.log 640 16 * @T00 JC
И в /etc/syslog.conf, где содержится определение журнала /var/log/messages, добавить mail.none.
В дальнейшем категорически рекомендуется озаботиться настройкой резервного MX для обслуживаемого домена.
Этапы начиная с третьего являются опциональными (с большим или меньшим приоритетом).
Третий этап: установка спам-фильтра
Потому как есть такое подозрение, что я являюсь единственным желающим настроить у себя на рабочей станции MTA, третий этап в настоящий момент будет опущен.
Четвёрый этап: установка спам-фильтра
Таблица приоритета: не по степени фильтрации спама, а по минимизации доли отсеиваемых спам-фильтром валидных писем (которая в идеале должна быть равной нулю). И при этом исходить из ситуации, когда для значительной части корреспондентов электронная почта — единственный канал связи.
Задача усугубляется тем, что через данный mail-сервер осуществляется массовая рассылка писем и необходимо обеспечить прохождение через спам-фильтр некоторого количества списков рассылки.
И при этом он ещё не должен препятствовать функционированию антивируса.
Пятый этап: переход на антивирус с открытым кодом
Данный этап — установка всего необходимого программного обеспечения, подготовка рабочего и актуального /etc/mail/sendmail.cf с выполнением функций антивирусной проверки и фильтрации спама с использование Open Source-антивируса (ибо работоспособность Касперского зависит от степени актуальности ключа и не является константой равно единице) и отработка процедуры перехода.
Рекомендуемые (и местами используемые) ссылки по теме
http://www.technoids.org/freebsdsendmailfaqs.html
http://www.fima.net/sendmail.html
http://www.opennet.ru/base/net/virtual_ … l.txt.html
Ну, и хватит пока.
Дополнение в виде некоторого количества общетеоретических ссылок (которые тоже изрядно помогли):
http://www.sendmail.org/faq/
http://home.leo.org/~barner/freebsd/art … ticle.html