 |
|
|
|
Почтовый сервер на базе Postfix. Защита от вирусов и нежелательной почты минимальными средствами
Почтовый сервер на базе Postfix Защита от вирусов и нежелательной почты минимальными средствами В январском номере журнала за прошлый год вышла моя статья [1], посвященная настройке почтовых фильтров на базе MTA Sendmail. Тогда я не предполагал, что она может вызвать такой широкий интерес и привести к целому ряду публикаций на совершенно разные темы. Очень большое количество откликов со стороны читателей натолкнуло меня на мысль поделиться своими новыми изысканиями в области системного администрирования. Немного теории Среди многочисленных систем передачи информации в глобальной сети Интернет немаловажную роль играет система передачи электронных сообщений от одного респондента к другому. Она включает в себя клиентов доставки, протоколы передачи данных и процедуры согласования между агентами. Один из основных агентов, отвечающий за доставку сообщения от одного клиента к другому, получил название MTA (Mail Transfer Agent). На сегодняшний день этих агентов насчитывается уже более десяти. В данной статье речь пойдет об MTA Postfix. Некоторое время назад я сменил работу, перейдя в одну из лучших фирм Петербурга на должность ведущего инженера. Системный администратор, занимавшийся управлением сетевой инфраструктурой фирмы, был очень занят серьезным проектом и меня попросили помочь в решении небольшой проблемы, связанной с постоянным падением почтового сервера. Таким образом я получил в свои руки связку из Red Hat Enterprise Linux (RHEL) 3.0 и как-то настроенного Postfix. При всем моем скептическом отношении к Linux меня в данной ситуации подогревал жуткий интерес, какими минимальными средствами можно заставить корректно работать данную систему. При этом требовалось, чтобы она выполняла функции фильтрации почты как на вирусы, так и на нежелательную корреспонденцию. В этой статье я не буду подробно описывать всю систему целиком, материалов на похожие темы предостаточно. Я лишь укажу на некоторые интересные моменты в данной связке и покажу, какими минимальными средствами можно получить вполне рабочую систему. Итак, начнем. Kaspersky Со времен выхода первой статьи [1], где я рассказывал о связке Sendmail и Kaspersky Antivirus for FreeBSD, ничего не изменилось. Однако для привязки Kaspersky Antivirus в RHEL 3.0 нужно будет использовать отдельную утилиту, обеспечивающую шлюз для обмена данными между Postfix и антивирусной программой. Но все по порядку. Первое, с чего мы начнем – это создадим отдельную группу и пользователей, от имени которых будут работать наши демоны. Они пригодятся нам в дальнейшем, когда мы будем устанавливать и настраивать спам-фильтры. # groupadd filter –g 551 # mkdir /var/spool/filter /var/spool/filter/spamd # useradd -u 542 -g 551 -d /var/spool/filter/spamd -s /sbin/nologin avpclient # useradd -u 543 -g 551 -d /nonexistent -s /nonexistent avpdaemon # chown avpclient:filter /var/spool/filter/spamd # cd /var/spool/filter/avp # mkdir Bases ctl dev etc proc tmp tst usr var var/log # chown –R avpdaemon:filter Bases ctl tmp tst var # cd dev # mknod console c 0 0 # mknod null c 2 2 Последние две команды необходимы, так как антивирусный демон будет запускаться в chroot-окружении. Покончив с деревом каталогов, берем дистрибутив Kaspersky Antivirus for Linux Server (kavwslinux-4.0.3.1.tgz), распаковываем: # tar xzvf kavwslinux-4.0.3.1.tgz # cd kavwslinux Из всего списка получившихся файлов нам понадобится: AvpUnix.ini, kavdaemon, kavscanner, kavupdater, а также файл /etc/defUnix.prf. Перейдем к установке и настройке антивируса. Скопируем в каталог /var/spool/filter/avp перечисленные выше файлы. В результате должно получиться следующее (обратите внимание на имя владельца подкаталогов): # ls –all
Перейдем к конфигурационным файлам. Ниже будут приведены лишь параметры, значения которых отличаются от принятых по умолчанию. AvpUnix.ini [AVP32] # Меняем путь к основному конфигурационному файлу DefaultProfile=defUnix.prf [Configuration] KeysPath=. # Прописываем путь к вирусным базам от корневого каталога BasePath=/Bases Конфигурационный файл defUnix.prf описывает действия антивирусного сканера при обнаружении вирусов в теле сканируемого файла. defUnix.prf # same section with parameters for objects [Object] # Указываем каталог, в котором будем проводить сканирование файла на вирусы Names=*/tst # Отключаем сканирование памяти и секторов логических томов Memory=No Sectors=No # Указываем параметры сканирования упакованных файлов, архивов, саморазворачивающихся архивов и так далее Packed=Yes Archives=Yes SelfExtArchives=Yes MailBases=Yes MailPlain=Yes Embedded=Yes # Устанавливаем реакцию на обнаружение вируса в теле письма «3» означает удаление тела вируса без попыток его лечения InfectedAction=3 # Требуем не архивировать письмо в случае обнаружения вируса BackupInfected=No IfDisinfImpossible=1 [Report] # Требуем вести файл журнала Report=Yes UseSysLog=No # Прописываем путь к файлу журнала ReportFileName=/var/log/kavscan.log # Отключаем расширенные формы записи в журнале ExtReport=No RepForEachDisk=No LongStrings=Yes # Отключаем пользовательский файл журнала UserReport=No # Устанавливаем реакцию на обнаружение вируса: не делать копии писем [ActionWithInfected] InfectedCopy=No # Устанавливаем порядок действий при подозрении на вирус: не делать копии писем [ActionWithSuspicion] SuspiciousCopy=No # Устанавливаем порядок действий в случае, если не удалось распаковать файл (считаем его поврежденным): # не делать копии писем [ActionWithCorrupted] CorruptedCopy=No [TempFiles] # Устанавливаем предельный размер сканируемых файлов и определяем каталог для временных файлов UseMemoryFiles=Yes LimitForMemFiles=6000 MemFilesMaxSize=20000 TempPath=/tmp [Customize] # Отключаем проверку необходимости обновления вирусных баз. Данная опция необходима для работы антивирусной программы # без вмешательства администратора. В противном случае она будет просить обновить базы каждый раз при загрузке UpdateCheck=No # Отключаем все лишние предупреждения на консоли сервера OtherMessages=No RedundantMessage=No DeleteAllMessage=No Основная идея состоит в том, чтобы максимально упростить ведение файлов журнала, и хранить в них только самое главное: проверен такой-то файл, инфицирован или нет. К тем параметрам, которые я менял в этом файле, написаны комментарии. Остальные параметры не менялись. Как можно заметить, все каталоги прописаны от корневого, в котором, собственно, и находится антивирусная программа. Все дело в том, что дальше мы будем запускать антивирус в chroot-окружении (зачем это нужно, будет объяснено чуть позже). Приведу сценарий для запуска процедуры обновления вирусных баз. Он достаточно маленький и состоит из двух строчек. Этот скрипт следует прописать в crontab для ежедневного выполнения, скажем, в час ночи. updater.sh #!/bin/sh /var/spool/filter/avp/kavupdater -y -kb -ui=http://downloads2.kaspersky-labs.com/updates/ -b=/var/spool/filter/avp/Bases /etc/init.d/kavd restart Сценарий для запуска/остановки демона антивирусной программы (/etc/init.d/kavd) также необходимо несколько модифицировать. Здесь приведены лишь его части, подвергшиеся изменению. Остальное можно найти в дистрибутиве AVP. /etc/init.d/kavd # Указываем каталог, в который установлен антивирусный фильтр INSTPATH=/var/spool/filter/avp # Указываем каталог, в котором будем тестировать файлы AVPDIR="/tst" # Указываем каталог для хранения сокета AVPPIPE="/ctl" # Указываем параметры запуска демона DPARMS="-Y -MP -f=$AVPPIPE -dl -MD -I0 -o{$AVPDIR} $AVPDIR" # Строки, проверяющие наличие конфигурационных и ключевых файлов, можно исключить. В случае корректной настройки # системы они не нужны. Далее в секции запуска демона убираем проверку демонстрационной версии, наличия вирусных # баз и корректируем строку запуска самого демона. Почему она выглядит именно так, будет объяснено чуть позже start () { if [ -r "$PIDFILE" ]; then echo "$NAME is running" exit 1 fi cd $INSTPATH echo -n "Starting $DESC: " daemon "/bin/env - HOME=/ /bin/nice/ var/spool/filter/avp/uchroot -u avpdaemon $INSTPATH /kavdaemon $DPARMS" RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$NAME cd $WD } Обратите внимание на строку запуска антивирусного демона: daemon "/bin/env - HOME=/ /bin/nice /var/spool/filter/avp/uchroot -u avpdaemon $INSTPATH /kavdaemon $DPARMS" Как легко видеть, мы пытаемся запустить демона в chroot-окружение с использованием неких утилит. Дело в том, что входящий в комплект AVP шлюз kavkeeper, обеспечивающий связь между почтовым сервером и антивирусным демоном, корректно работает лишь в случае, когда в качестве фильтров используется только антивирус. При попытке привязать к системе дополнительные фильтры вроде Spamassassin образовывается некая внутренняя петля, и почтовое сообщение постоянно крутится по кругу внутри почтового сервера. Переписка с технической поддержкой лаборатории Касперского по этому поводу, к сожалению, ничего не дала. Поэтому вместо kavkeeper мы будем использовать avcheck (http://www.corpit.ru/avcheck), написанный Михаилом Токаревым. # cd /home/gennadiy # tar xzvf avcheck-0.8.tar.gz # cd avcheck-0.8 # make # cp avcheck /var/spool/filter/avp/ # cp uchroot /var/spool/filter/avp/ # mkdir /var/spool/filter/avp/infected # cp infected.ex2.ru /var/spool/filter/avp/infected Вот вроде бы и все. Единственный момент связан с тем, что я откорректировал конфигурационный файл infected. ex2.ru таким образом, чтобы в случае обнаружения вируса администратору высылалось лишь предупреждение без оригинального вложения. infected.ex2.ru # Оставляем данную строчку пустой, чтобы не посылать лишних сообщений отправителю и получателю вирусного сообщения VIRUS_ALERT= # Отключаем информативные сообщения отправителю и получателю INFORM_SENDER=n # no send alert INFORM_RCPT=n # send alert to recipients # Удаляем функции attach_message() и attach_message_headers() # В секции генерации предупреждения администратору убираем вызов функции attach_message(). Также в случае, если мы # не используем информативные сообщения отправителю и получателю вирусного письма, можно удалить секции # «send alert to sender» # «alert to recipients» С настройкой антивирусного демона закончили. Перейдем к установке SpamAssassin. SpamAssassin С фильтром на нежелательную почту все немного проще. Находим дистрибутив, скачиваем, распаковываем, устанавливаем: # tar xzvf Mail-SpamAssassin-3.0.2.tar.gz # cd Mail-SpamAssassin-3.0.2 # make # make install Инсталляцию можно произвести и из RPM-пакета, если таковой имеется у вас под рукой. Обратите внимание, в 3-й версии SpamAssassin некоторые параметры конфигурационных файлов сильно отличаются. Ниже будут приведены тексты именно для 3-й версии и выше. Файл конфигурации SpamAssassin, приведенный целиком и созданный мною практически с нуля, а также стартовый сценарий (/etc/init.d/spamd), который пришлось слегка модифицировать для запуска демона от имени другого пользователя. Все необходимые каталоги были созданы нами ранее. Конфигурационный файл SpamAssassin: local.cf # don't use agent use_razor2 0 use_dcc 0 use_pyzor 0 # check rbl skip_rbl_checks 0 # autowhitelist use_auto_whitelist 1 auto_whitelist_path /var/spool/filter/spamd/auto_whitelist # bayes use_bayes 1 bayes_auto_learn 0 bayes_path /var/spool/filter/spamd/bayes bayes_expiry_max_db_size 1500000 bayes_auto_learn_threshold_nonspam 0.1 bayes_auto_learn_threshold_spam 10.0 bayes_min_ham_num 100 bayes_min_spam_num 200 auto_learn 0 ok_languages en ru ok_locales en ru # Spam header rewriting – clear_headers rewrite_header subject ****SPAM (_SCORE_)**** required_hits 3.5 # user rules allow_user_rules 0 # report options always_add_report 1 report_safe 0 report_charset koi8-r # dns testing dns_available no # score options score FROM_ILLEGAL_CHARS 1.5 score HEAD_ILLEGAL_CHARS 1.5 score SUBJ_ILLEGAL_CHARS 1.5 score SUBJ_HAS_SPACES 2.5 score NO_REAL_NAME 1.0 score PENIS_ENLARGE 3.5 score PENIS_ENLARGE2 3.5 score FROM_HAS_MIXED_NUMS 1.0 score FORGED_IMS_TAGS 0.5 score FORGED_MUA_OUTLOOK 0.5 score FORGED_OUTLOOK_TAGS 0.5 score BAYES_80 3.5 score BAYES_90 4.0 score BAYES_99 10.0 # network whitelist whitelist_from localhost В скрипте запуска демона SpamAssassin меняем одну строку, относящуюся к стартовым параметрам демона. /etc/init.d/spamd # Set default spamd configuration. SPAMDOPTIONS="-d -m 5 -u avpclient -x -r /var/run/spamd/spamd.pid" Особых изменений по сравнению с настройками для FreeBSD здесь не наблюдается (см. [1]), поэтому подробно останавливаться на данном вопросе мы не будем. Нам осталось лишь настроить фильтры на нашем почтовом сервере. Postfix Каких-то особых хитростей в конфигурации данного почтового сервера я описывать не буду. Статей на эти темы предостаточно и в журнале, и в глобальной Сети. Нам интересны лишь моменты, связанные с использованием настроенных нами почтовых фильтров. Для этого в файле main.cf необходимо включить фильтр avcheck: main.cf content_filter=avcheck И добавить фильтры в файл master.cf: master.cf # check mail with spamd and kaspersky avcheck unix - n n - 5 pipe flags=q user=avpclient argv=/usr/bin/spamc -u avpclient -e /var/spool/filter/avp/avcheck -i /var/spool/filter/avp/infected/infected.ex2.ru -h Ok -d /var/spool/filter/avp/./tst -s AVP:/var/spool/filter/avp/ctl/AvpCtl -f ${sender} -S :1025 -- ${recipient} localhost:1025 inet n - n - - smtpd -o content_filter= Теперь следует перезапустить Postfix и проверить работоспособность почтового сервера. Если он не функционирует, проверьте права доступа к каталогам, скрипты запуска, конфигурационные файлы. Приведенные мною примеры взяты с реального сервера. Последние штрихи Кажется, все хорошо. Почта работает, вирусы отлавливает, спам идентифицируется. Но, как всегда, хочется большего. В связке Sendmail + SpamAssassin в milter (это программа, предоставляющая транспорт между MTA и почтовым фильтром) можно было указать, на какой адрес пересылать всю нежелательную корреспонденцию. В Postfix мы воспользуемся стандартными средствами фильтрации по заголовкам письма. Однако прежде чем это делать, нам необходимо проверить, чтобы наш MTA был не ниже версии 2.1. Ранние версии не поддерживают инструкцию REDIRECT. Находим дистрибутив для RHEL 3.0, устанавливаем: # rpm –Uvh postfix-2.1.5-4.rhel3.i386.rpm В файле main.cf добавляем строки, осуществляющие поиск в заголовках письма по регулярному выражению, сохраненному в /etc/postfix/header.regexp: main.cf header_checks=regexp:/etc/postfix/header.regexp Затем создаем файл /etc/postfix/header.regexp следующего содержания: header.regexp /^X-Spam-Flag: YES/ REDIRECT spam@company.ru т.е. требуем, чтобы все письма, в заголовке которых стоит флаг «X-Spam-Flag», перенаправлялись по адресу spam@company.ru. Соответственно стоит позаботиться, чтобы у нас в системе присутствовал пользователь с именем «spam» или на существующего пользователя была сделана ссылка (alias). Таким образом, весь почтовый трафик, идентифицированный как потенциальный спам, будет перенаправлен на определенный адрес. Вот вроде бы и все. Итоги В этой статье я попытался поделиться секретами настройки почтовых фильтров на базе MTA Postfix. Статей на подобные темы достаточно, однако некоторые из них слишком громоздки и используют очень большое количество связок. Другие же слишком неполны. Я попытался обойтись минимальными средствами, чтобы получить максимальный уровень защиты. Ведь чем проще система, тем легче за ней следить. Тексты конфигурационных файлов будут опубликованы на сайте журнала и на техническом форуме «Тринити». Хочется выразить огромную благодарность Сергею Тараненко, системному администратору фирмы «Тринити», за интеллектуальную поддержку. Ссылки и литература:
|
ГЕННАДИЙ ДМИТРИЕВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
