Документация по ОС FreeBSD Воскресенье, 07.12.2025, 11:52
Главная
Регистрация
Вход
Приветствую Вас Гость | RSS
Меню сайта

Категории каталога
Apache [58]
DNS [25]
FTP [27]
Mail [74]
Samba [24]
Squid [46]
SSH [23]
VPN [35]
РРР [20]
Net [173]

Главная » Статьи » Сеть » Mail
Неприступный почтовик
Чем сложнее система, чем больше в ней компонентов, тем она функциональнее, но в то же время тем сложнее следить за ее безопасностью. Тем не менее, сегодня мы будем строить максимально безопасный почтовый сервер, обслуживающий отдельный домен, и воспользуемся для этого проверенным временем qmail. А так как "просто почта" сегодня уже никому не нужна, будем учить qmail работать вместе с антивирусом ClamAV и лучшим на сегодняшний день убийцей спама SpamAssassin.

Ода DJB

Стопроцентно безопасных программ не бывает. Но есть те, которые приблизились к этому показателю вплотную. Именно такие программы пишет американский профессор-математик Daniel Bernstein (http://cr.yp.to). Как и любой гений, он стоит в оппозиции по отношению ко многим вещам, и ему многое в этом мире не нравится. Например, ему не нравится то, что самый популярный dns-сервер BIND от Internet Systems Consortium, ставший стандартном де-факто для использования на UNIX-серверах, представляет собой весьма жалкое зрелище с точки зрения безопасности и дизайна. То же самое можно сказать о другом неписаном стандарте - почтовом сервере Sendmail. И хотя уже проходят те времена, когда эти ровесники интернета требовали исключительно права суперпользователя для работы, ожидая по свою душу очередного remote root эксплойта, хотя многое изменилось в лучшую сторону, стопроцентного доверия они так и не заслужили (и не заслужат: груз истории уязвимостей давит). Возможно, именно это побудило djb (так в интернете сокращенно зовут Бернштейна) написать свою реализацию dns-сервера под названием djbdns и smtp/pop3-сервера - qmail. Разумеется, qmail - не единственная безопасная альтернатива sendmail. Postfix - не уступающая по функциональности sendmail альтернатива от известного security-эксперта Wietse Venema. Но вот широко распространенных и безопасных, проверенных временем альтернатив BIND, кроме djbdns, похоже, не существует. Кроме того, программы djb многим не нравятся тем, что они разрушают годами складывавшиеся неписаные стандарты. Для чего? Не всегда "как есть" означает "как правильно".

Перед погружением

Было бы странно, если бы реформатор djb ограничился написанием сетевых демонов. Он решил начать с самого начала: с того, как и чем эти сервисы управляются. Представь, что ftp-сервер падает от DDoS-атаки. Пока администратор не придет и руками его не поднимет, сервис будет лежать. Чтобы избежать такой ситуации, было решено придумать "суперсервер", который бы осуществлял мониторинг запущенных подконтрольных ему сервисов и перезапускал их при необходимости. Подобной задачей, впрочем, занимается inetd, но он, как и многие продукты, не устраивал djb кривизной дизайна. Например, если падает сам inetd, то он тянет за собой все запущенные им сервисы. Для управления сервисами Бернштейн написал набор утилит под названием daemontools (http://cr.yp.to/daemontools.html). Если не вдаваться в подробности, то основные составные части daemontools - это монитор supervise, обработчик логов multilog и утилиты контроля сервисов svc/svstat. Помимо daemontools, им же был написан многофункциональный набор утилит ucspi-tcp (как раз прямой функциональный аналог inetd) для точного и детального контроля запускаемых демонов. Ключевая утилита из набора - tcpserver, которая запускает необходимый демон, устанавливает рабочее окружение (переменные среды) и контролирует все подключения к этому серверу, позволяя регулировать нагрузку, использование памяти и, если нужно, осуществлять контроль доступа.

В качестве операционной системы для построения высокопроизводительного надежного почтового сервера выберем FreeBSD 5.3 - лучшую серверную операционную систему на сегодняшний день ;). Детально процесс обновления системы до 5.3-STABLE описан в этом же номере, так что будем считать, что у тебя уже имеется свежая система с актуальным деревом портов. Поехали!

Первым делом ставим daemontools и ucspi-tcp.

# cd /usr/ports/sysutils/daemontools
# make install clean
# echo 'svscan_enable="YES"' >> /etc/rc.conf
# mkdir /var/service

С ucspi-tcp придется немного повозиться. Дело в том, что для доступа к нашему будущему pop3/smtp-серверу с использованием безопасного ssl-соединения нужно пропатчить ucsp-tcp на предмет умения работы с SSL. По каким-то причинам этот патч отсутствует во FreeBSD-порте ucspi-tcp. Так что придется применить его руками.

# cd /usr/ports/sysutils/ucspi-tcp
# make patch
# gunzip ucspi-tcp-ssl-20020705.patch.gz
# cd work/ucspi-tcp-0.88
# patch < ../../ucspi-tcp-ssl-20020705.patch
# cd ../../
# make install clean
# rm ucspi-tcp-ssl-20020705.patch

Ничто не идеально. И софт djb тоже. Его основная проблема в том, что написан он был давно и "на раз". "Чистая" версия qmail обделена многим из той функциональности, которая требуется от современных почтовых серверов. SSL, TLS, SMTP AUTH, Greylisting, поддержка LDAP - все эти и многие другие возможности добавляются в qmail сторонними патчами, за которые автор qmail не отвечает. Так что если окунешься в мир программного обеспечения djb, будь готов запутаться в patch’ах, patchkit’ах, и patch’ах к patchkit’ам ;).

Вам письмо!

Пришло время ставить qmail в качестве pop3/smtp-сервера. Нас интересует порт с поддержкой SMTH-аутентификации и TLS.

# cd /usr/ports/mail/qmail-smtp_auth+tls
# make WITH_QMAILQUEUE_PATCH=yes WITH_BIG_TODO_PATCH=yes install clean

Авторизацию будем выполнять с помощью утилиты checkpassword.

# cd /usr/ports/security/checkpassword && make install clean

Затем сообщим системе, что у нас теперь qmail вместо sendmail:

# vi /etc/mail/mailer.conf
#sendmail /usr/libexec/sendmail/sendmail
#send-mail /usr/libexec/sendmail/sendmail
#mailq /usr/libexec/sendmail/sendmail
#newaliases /usr/libexec/sendmail/sendmail
#hoststat /usr/libexec/sendmail/sendmail
#purgestat /usr/libexec/sendmail/sendmail
sendmail /var/qmail/bin/sendmail
send-mail /var/qmail/bin/sendmail
mailq /var/qmail/bin/qmail-qread
newaliases /var/qmail/bin/newaliases
hoststat /var/qmail/bin/qmail-tcpto
purgestat /var/qmail/bin/qmail-tcpok
# echo 'sendmail_enable="NONE"' >> /etc/rc.conf

Добавляем необходимых пользователей. Почти каждый процесс в qmail работает под отдельной учетной записью.

# pw groupadd nofiles
# pw groupadd qmail
# pw useradd alias -g nofiles -d /var/qmail/alias -s /usr/sbin/nologin
# pw useradd qmaild -g nofiles -d /var/qmail -s /usr/sbin/nologin
# pw useradd qmaill -g nofiles -d /var/qmail -s /usr/sbin/nologin
# pw useradd qmailp -g nofiles -d /var/qmail -s /usr/sbin/nologin
# pw useradd qmailq -g qmail -d /var/qmail -s /usr/sbin/nologin
# pw useradd qmailr -g qmail -d /var/qmail -s /usr/sbin/nologin
# pw useradd qmails -g qmail -d /var/qmail -s /usr/sbin/nologin

Настало время настроить qmail. Делается это, как водится, командой echo ;).

# cd /var/qmail/control
# echo mail.mydomain.ru > me
# echo mydomain.ru > defaultdomain
# echo mydomain.ru > rcpthosts
# echo mail.mydomain.ru >> rcpthosts
# echo mydomain.ru > locals
# echo mail.mydomain.ru >> locals

Мы указали qmail его имя, то, на какие домены принимать почту и какие домены считать локальными. Затем создадим alias’ы на root'а и прочих пользователей, которым могут написать, но которые не смогут ее получить. Вся направляемая им почта будет скидываться пользователю toxa.

# cd /var/qmail/alias
# echo toxa > .qmail-root
# echo toxa > .qmail-postmaster

По умолчанию qmail использует формат почтового ящик Maildir, разработанный все тем же djb. В отличие от традиционного mbox, в котором вся почта складывается в один файл, Maildir хранит каждое письмо в отдельном файле.

По-моему, это вполне удобно, и нет нужды менять принятое по умолчанию поведение qmail. Создадим себе Maildir с помощью утилиты maildirmake:

# maildirmake /home/toxa/Maildir

В появившемся каталоге Maildir увидишь три папки, cur new tmp. Новая почта сваливается в new. Так как сервер у нас будет доступен и по защищенному SSL-протоколу, сгенерируем себе самоподписанный сертификат для почты. Заметь, файл должен содержать как открытый ключ, так и секретный, так что с точки зрения x509 это не совсем сертификат (строго говоря, сертификат = открытый ключ + дополнительная информация):

# cd /tmp
# openssl genrsa -out mail.key 2048
# openssl req -new -key mail.key -out mail.csr
# openssl x509 -req -days 365 -in mail.csr -signkey mail.key -out mail.crt
# cat mail.key >> mail.crt
# rm mail.key mail.csr
# mv mail.crt /etc/ssl/certs/
# chmod 600 /etc/ssl/certs/mail.crt

Запуск qmail будет осуществлять tcpserver из установленного нами набора ucspi-tcp. Мы запустим по два экземпляра pop3- и smtp-сервера, без SSL (на 110 и 25 портах соответственно) и с SSL (на 995 и 465 портах).

На первый взгляд, это выглядит громоздко, зато сразу видно четкое отделение мух от котлет, а защищенных соединений - от незащищенных. При этом не забудем, что smtp должен поддерживать авторизацию. Создаем каталог /var/qmail/runscripts, а в нем - подкаталоги qmail-pop3d, qmail-pop3ds, qmail-send, qmail-smtpd, qmail-smtpds. Если ты заметил, при запуске сервиса supervise'ом выполняется скрипт run в соответствующем каталоге. Здесь мы эти скрипты создадим руками и поправим под наши нужды.
 
# vi qmail-pop3d/run
#!/bin/sh
 
exec 2>&1
exec softlimit -m 5000000000 tcpserver -RHD -x /var/qmail/tcp.smtp.cdb 0 110 \ /var/qmail/bin/qmail-popup mail.myserver.ru /usr/local/bin/checkpassword \
/var/qmail/bin/qmail-pop3d Maildir
 
# vi qmail-pop3ds/run
#!/bin/sh
 
exec 2>&1
exec softlimit -m 5000000000 tcpserver -RHD -s -n /etc/ssl/certs/mail.crt -x \ /var/qmail/tcp.smtp.cdb 0 995 /var/qmail/bin/qmail-popup mail.myserver.ru \ /usr/local/bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir
 
#vi qmail-smtpd/run
#!/bin/sh
 
exec 2>&1
exec envuidgid qmaild softlimit -d 30000000 tcpserver -x /var/qmail/tcp.smtp.cdb \
-p -DRHl mail.myserver.ru 0.0.0.0 25 /var/qmail/bin/qmail-smtpd \
mail.myserver.ru /usr/local/bin/checkpassword /usr/bin/true 2%26gt;%261
 
# vi qmail-smtpds/run
#!/bin/sh
 
exec 2>&1
exec envuidgid qmaild softlimit -m 30000000 tcpserver -n /etc/ssl/certs/mail.crt \
-x /var/qmail/tcp.smtp.cdb -s -p -DRHl mail.myserver.ru 0.0.0.0 465 \
/var/qmail/bin/qmail-smtpd mail.myserver.ru /usr/local/bin/checkpassword /usr/bin/true 2%26gt;%261
 
# vi qmail-send/run
#!/bin/sh

exec /var/qmail/rc

Как видно, цель этих скриптов - установить переменные окружения и запустить tcpserver, который, в свою очередь, запускает соответствующий бинарник qmail-* c аргументами. В случае использования SSL мы указали путь к сертификату, в скриптах запуска smtpd/smtpds прописали checkpassword - это и есть поддержка smth auth в qmail. Заметь, что tcpserver также контролирует доступ согласно /var/qmail/tcp.smtp.cdb. Займемся этим файлом позже.

Спаму и вирусам - бой!

Без антиспам-системы сегодня не обходится ни один приличный почтовик. То же самое можно сказать и об антивирусном контроле проходящей через сервер корреспонденции. Потому мы призовем на помощь лучшие силы OpenSource в этой области - SpamAssassin и ClamAV AntiVirus.

Существует два принципиально разных подхода к фильтрации спама: так называемые server side и client side. Фильтрация на стороне сервера направлена на то, чтобы просто не принимать соединения от машин, которые рассылают спам. Собственно, она и основывается на технологиях определения "доверия" удаленным серверам, таким как Greylisting и RBL Checking (Blacklist checking). Само же письмо при этом, разумеется, никоим образом не затрагивается. Фильтрация на стороне клиента основана на определении вероятности того, что полученное письмо является спамом. Для этого применяются сложные статистические, лингвистические и эмпирические тесты, например, Bayes analysis.

Задача сервера - проанализировать и пометить проверенное письмо как "спам" или "не спам" (например, добавить в заголовок письма слово SPAM). Клиент все равно получит это сообщение, однако он вполне может настроить фильтрацию на своем почтовом клиенте и, например, складывать спам в trash не читая его. Или спам может просто убиваться на сервере по таким же признакам. У обоих методов есть свои преимущества и недостатки. В первом случае можно потерять важные сообщения при ложном срабатывании, во втором - придется принимать спам и хранить его на сервере, что в большой сети (с учетом того, что доля спама в наши дни в интернете достигает 80%) может оказаться критической. Плюс ко всему настойка анализатора на отлов всего спама и отсутствие ложных срабатываний требует времени. Как всегда, выход - золотая середина. Пожалуй, самый эффективный метод на сегодня - комбинация Greylisting и байесовской фильтрации.
 
# cd /usr/ports/mail/p5-Mail-SpamAssassin
# make install clean
# echo 'spamd_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/sa-spamd.sh start

Внесем в конфигурационный файл необходимые изменения:

# vi /usr/local/etc/mail/spamassassin/local.cf
 
# SpamAssassin ставит каждому письму "оценку" - количество баллов по шкале
# "спамовероятности". Например, оценка 50 - однозначно не спам, 0 или 2 - скорее всего не спам, 99
#- однозначно спам. Ограничиваем планку, выше которой все будет считаться спамом,
#шестью баллами. Подбери оптимальное значение для твоей сети на основе
#статистических данных (если есть ложные срабатывания - уменьши значения; если
#наоборот, то есть если спам проскакивает безнаказанно - увеличь).
 
required_hits 6.0
ok_languages en ru uk
ok_locales en ru

# В случае спама будем добавлять в заголовок письма уведомление и количество баллов.

rewrite_header Subject **[SPAM](_SCORE_)**

# Спам будет пересылаться вложением в уведомление почтовой системы.

report_safe 0

# включать статистику в заголовки письма

report_header 1

# Делаем систему самообучаемой

use_bayes 1
auto_learn 1
skip_rbl_checks 0
 
# По умолчанию spamd, обучаясь, складывает токены в $HOME пользователя. Чтобы
# иметь общую базу на всех, будем складывать их в одном месте.

bayes_path /usr/local/etc/mail/spamassassin/

Протестируем работу spamd натравив на него какое-нибудь письмо:

# cat message | spamc

На stdout будет выведено письмо со статистической информацией в заголовках:

X-Spam-Status: No, score=-99.4 required=4.0 tests=AWL,BAYES_50,
RCVD_DOUBLE_IP_LOOSE,SUBJ_ILLEGAL_CHARS,USER_IN_WHITELIST
autolearn=no version=3.0.1
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.myserver.ru

Ставим clamav:

# cd /usr/ports/security/clamav
# make install clean
# echo 'clamav_clamd_enable="YES"' >> /etc/rc.conf
# echo 'clamav_freshclam_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/clamav-clamd.sh start
# /usr/local/etc/rc.d/clamav-freshclam.sh start

Freshclam будет регулярно обновлять базу штаммов вирусов, clamd будет непосредственно отвечать за анализ файлов.

Объединяем все воедино

Итак, у нас стоит qmail (еще не запущенный), clamav и spamassassin. Пока они ничего друг о друге не знают, и чтобы превратить разрозненные компоненты в мощный почтовый монолит, мы воспользуемся маленькой и шустрой программкой simscan. На момент написания статьи ее не было в портах, так что нам придется ставить ее руками, предварительно добавив необходимые программы:
 
# cd /usr/ports/mail/ripmime
# make install clean
# tar xzf simscan-1.0.8.tar.gz && cd simscan-1.0.8
# ./configure --enable-spam=y --enable-received=y --enable-ripmime --enable-spamassassin-path=/usr/local/bin/spamassassin --enable-clamavdb-path=/usr/local/share/clamav --enable-sigtool-path=/usr/local/bin/sigtool --enable-attach=y --enable-spam-passthru=y --enable-quarantinedir=/var/qmail/simscan/quarantined
# make && make install

Подробнее про все опции читай в README. Принцип работы simscan заключается в подмене оригинальной программы процессинга почтовой очереди /var/qmail/bin/qmail-queue на /var/mail/bin/simscan, которая умеет обращаться к spamd/clamd, а в остальном ведет себя так же, как и qmail-queue. Вот тут мы и вернемся к файлу /var/qmail/tcp.smtp.cdb. Создай в /var/qmail файл следующего содержания:

127.0.0.1:allow,RELAYCLIENT=""
192.168.0.:allow,RELAYCLIENT="",QMAILQUEUE="/var/qmail/bin/simscan"
:allow,QMAILQUEUE="/var/qmail/bin/simscan"

Затем преврати его в cdb:

# tcprules tcp.smtp.cdb tcp.smtp.cdb.tmp %26lt; tcp.smtp

В этом файле устанавливаем переменные окружения для хостов. RELAYCLIENT позволяет указанному хосту использовать qmail для пересылки почты хостам, не указанным в rcpthosts, то есть использовать сервер как relay. Мы разрешили это локальному хосту и нашей подсети 192.168.0.0/24. Очевидно, что все остальные будут уметь доставлять почту только тем хостам, которые обслуживает qmail (в нашем случае это mail.mydomain.ru). Таким образом, promisc relay исключен. Как же клиенты будут отправлять почту, например, из дома? Для этого мы и включили smtp-авторизацию, а упомянутый выше checkpassword именно тем и занимается, что после проверки пароля выставляет для сессии переменную RELAYCLIENT, позволяя пересылать почту. Также для всех хостов, кроме локального, мы переписали переменную QMAILQUEUE, чтобы она указывала на simscan. Вот теперь запускаем все четыре экземпляра qmail:

# ln -s /var/qmail/runscripts/qmail-pop3d /var/service
# ln -s /var/qmail/runscripts/qmail-pop3ds /var/service
# ln -s /var/qmail/runscripts/qmail-smtpd /var/service
# ln -s /var/qmail/runscripts/qmail-smtpds /var/service
# ln -s /var/qmail/runscripts/qmail-send /var/service

Проверяем работу системы, посылая почту из локальной сети и из интернета, убеждаемся, что без smth auth снаружи не пускает, смотрим логи clamd/spamd. Если все работает, радуемся и запускаем систему в эксплуатацию. Если нет - идем на www.google.com и учимся пользоваться поиском :).

Мнение эксперта

Андрей Матвеев, редактор рубрик "Юниксоид" журнала "Хакер" (andrushock@real.xakep.ru)

В наши дни все больше внимания уделяют обеспечению комплексной безопасности систем электронной почты. Различные организации создают целые проекты по поддержанию так называемых "черных" списков, в которые занесены адреса отправителей, занимающихся массовой рассылкой информации рекламного характера. Разработчики программного обеспечения постоянно совершенствуют спам-фильтры, выпускают новые версии почтовых пользовательских агентов (MUA) и серверов SMTP/POP3/IMAP4, обладающих встроенной поддержкой аутентификации клиентов и шифрования передаваемых данных. Изо дня в день антивирусные компании трудятся не покладая рук над обновлениями к своим продуктам. Но, как показывает практика, велика вероятность того, что мы можем стать заложниками собственных средств защиты, так как добрый процент корреспонденции будет просто застревать в нашем же каскаде RBL-листов, почтовых фильтров, хэшированных базах доступа и, соответственно, не доходить до получателя. Поэтому тут главное не переборщить с защитой и выработать грамотную политику (к примеру, "что делать со спамом?" - удалять немедленно или доставлять клиенту с модифицированной темой письма).

Источник: http://www.xakep.ru/magazine/xs/051/036/1.asp
Категория: Mail | Добавил: oleg (08.04.2008) | Автор: Антон Карпов
Просмотров: 2190 | Рейтинг: 5.0/1 |
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Форма входа

Beastie

Друзья сайта

Copyright MyCorp © 2025