Как защитить почтовый сервер от спама Clamav + Amavisd

Как защитить почтовый сервер от спама Clamav + Amavisd

 

Установка и настройка Clamav + Amavisd

Устанавливаем необходимые для работы антивируса и антиспама компоненты:

dnf —enablerepo=epel,powertools install amavisd-new clamd perl-Digest-SHA1 perl-IO-stringy

Открываем конфигурационный файл amavis:

vi /etc/amavisd/amavisd.conf

Редактируем следующие параметры:

$mydomain = ‘infoit.com.ua’;

$myhostname = ‘relay.infoit.com.ua’;

* данные опции не обязательны, но они определяют сообщения в заголовках. $mydomain — домен, в котором находится сервер; $myhostname — имя сервера.

… а также добавим:

$allowed_header_tests{‘multiple’} = 0;
$allowed_header_tests{‘missing’} = 0;

* данные опции позволят программе Outlook без ошибок отправлять тестовое сообщение.

Открываем конфигурационный файл clamd:

vi /etc/clamd.d/scan.conf

Снимаем комментарий для опции TCPSocket:

TCPSocket 3310

Теперь разрешаем запуск антивируса и amavis:

systemctl enable clamd@scan —now

systemctl enable amavisd —now

Настройка Postfix

Добавляем в postfix:

vi /etc/postfix/main.cf

content_filter = scan:[127.0.0.1]:10024
receive_override_options = no_address_mappings

* где content_filter указывает на приложение, которое будет сканировать сообщения; receive_override_options позволяет увидеть оригинальные email адреса писем с вирусами.

Теперь редактируем master.cf:

vi /etc/postfix/master.cf

Дописываем следующее:

scan   unix  —  —  n  —  16  smtp
-o smtp_send_xforward_command=yes
-o smtp_enforce_tls=no

127.0.0.1:10025   inet  n  —  n  —  16  smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

* итак, данной настройкой мы создадим два вспомогательных сервиса scan и 127.0.0.1:10025 (сервис без имени, он просто будет слушать на порту 10025 — это порт по умолчанию, на который отправляет сообщение amavis после выполнения проверки). Также, мы используем следующие опции:

  • smtp_send_xforward_command — передавать ли в сканирование сообщение с исходными именем клиента и IP-адресом. В данном примере, да.
  • smtp_enforce_tls — требовать ли TLS.
  • content_filter — приложение для сканирования. В данном примере сканирование отключено.
  • receive_override_options переопределяет опции в main.cf. В нашем случае, no_unknown_recipient_checks отключает попытки выяснить, является ли получатель неизвестным; no_header_body_checks отключает проверки заголовков и тала писем.
  • пустые значения для smtpd_helo_restrictionssmtpd_client_restrictionssmtpd_sender_restrictions отключают ограничения для данных опций.
  • smtpd_recipient_restrictions — контролирует ответ Postfix на SMTP-команду RCPT TO. Здесь мы разрешаем только соединения от узлов, перечисленных в mynetworks.
  • mynetworks_style=host указывает postfix, что он должен пересылать почту только с локального компьютера.
  • smtpd_authorized_xforward_hosts укажет, какие удаленные клиенты могут использовать XFORWARD. В данном случае локальный компьютер.

Перезапускаем postfix:

systemctl restart postfix

Настройка обновлений антивируса и amavis

Устанавливаем clamav-update:

dnf install clamav-update

Обновляем антивирусную базу командой:

freshclam

Для обновления базы антиспама:

sa-update —nogpg —verbose

Для настройки автоматического обновления, редактируем cron:

crontab -e

15 3 * * * /bin/freshclam
30 3 * * * /bin/sa-update

* в данном примере, каждый день в 03:15 будет запускаться процесс обновления clamav, а в 03:30 — антиспама.

Проверка

Для проверки антивируса отправляем сообщение со следующим содержимым:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Письмо не должно дойти, а в логе (/var/log/maillog) мы увидим строку:

… amavis[17688]: (17688-04) Blocked INFECTED (Eicar-Signature) {DiscardedOutbound,Quarantined}, MYNETS LOCAL …
… relay=127.0.0.1[127.0.0.1]:10024, delay=0.25, delays=0.19/0/0/0.06, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=17688-04 — INFECTED: Eicar-Signature)

Для проверки работы контентного антиспама, отправляем письмо со следующим содержимым:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

В итоге, письмо не должно прийти, а в логах мы увидим:

… amavis[17689]: (17689-04) Blocked SPAM {DiscardedOutbound,Quarantined}, MYNETS LOCAL …
… status=sent (250 2.7.0 Ok, discarded, id=17689-04 — spam)

Пересылка СПАМа и вирусов на другой ящик

Все письма со спамом и вирусами будут перемещаться в карантин. Если мы хотим перенаправлять все подобные сообщения на специальный ящик, то необходимо настроить amavis.

Открываем конфигурационный файл:

vi /etc/amavisd/amavisd.conf

Добавляем такие опции:

$spam_quarantine_to = «spam\@infoit.com.ua»;

$virus_quarantine_to = «virus\@infoit.com.ua»;

* где $spam_quarantine_to указываем на адрес для перенаправления СПАМ-писем; $virus_quarantine_to — почта для писем с обнаруженными вирусами.

После перезагрузим amavisd:

systemctl restart amavisd

Пробуем отправить сообщения с тестовыми сигнатурами на СПАМ и вирус — письма должны быть перенаправлены на указанные адреса.

Сохранения СПАМа в папку SPAM пользователя

Выше мы рассмотрели возможность перенаправления всех нежелательных писем на другой почтовый ящик. Данный способ удобен, что пользователи не видят ненужные сообщения, но накладывает дополнительную обязанность на администратора по поиску писем, которые ложно были определены как СПАМ. В данном подразделе мы рассмотрим альтернативу — сохранение нежелательных сообщений в специальной папке.

Устанавливаем пакет dovecot-pigeonhole:

dnf install dovecot-pigeonhole

Открываем на редактирование файл:

vi /etc/dovecot/conf.d/90-sieve.conf

Комментируем и добавляем строки:

#sieve = file:~/sieve;active=~/.dovecot.sieve
sieve = /etc/dovecot/sieve/default.sieve

* закомментированная строка указывала, что файл с настройками находится в домашней директории каждого пользователя. Мы же будем делать централизованный конфиг в файле /etc/dovecot/sieve/default.sieve.

Открываем файл /etc/dovecot/conf.d/15-lda.conf и редактируем:

vi /etc/dovecot/conf.d/15-lda.conf

protocol lda {

mail_plugins = $mail_plugins sieve
}

* в данном примере мы добавили плагин sieve. Также необходимо со строки снять комментарий, если он был.

Открываем файл /etc/dovecot/conf.d/15-lda.conf и редактируем:

vi /etc/dovecot/conf.d/20-lmtp.conf

protocol lmtp {

mail_plugins = $mail_plugins sieve
}

* также мы добавили плагин sieve + необходимо со строки снять комментарий, если он есть.

Создаем каталог и файл с настройками sieve:

mkdir /etc/dovecot/sieve

vi /etc/dovecot/sieve/default.sieve

require «fileinto»;
if header :contains «X-Spam-Flag» «YES» {
fileinto «Junk»;
}

* в данном примере мы ищем в заголовках X-Spam-Flag и отправляем такие письма в папку Junk.

Задаем владельца для созданных каталога и файла:

chown -R vmail:vmail /etc/dovecot/sieve

Перезапускаем dovecot:

systemctl restart dovecot

Открываем конфиг amavis:

vi /etc/amavisd/amavisd.conf

Редактируем строку:

$final_spam_destiny = D_PASS;

* по умолчанию стоит значение D_DISCARD, что означает, что сообщения будут отклонятся. Нам же нужно D_PASS — пропускать.

Перезапускаем amavisd:

systemctl restart amavisd

Антиспам средствами Postfix

В MTA Postfix встроен свой механизм проверки заголовков входящих сообщений. Правила размещаются в 7 секций, обработка которых выполняется в следующем порядке:

client -> helo -> sender -> relay -> recipient -> data -> end_of_data

Чтобы лучше понять принцип, мы должны знать SMTP-команды при выполнении отправки почты. И так, порядок, следующий:

  1. Соединение с сервером.
  2. Команда HELO. Приветствие, в котором отправитель называет свое имя, по которому можно проверить, соответствует ли оно правилам именования и своему IP-адресу.
  3. MAIL FROM — указывает адрес отправителя. Выполняется для sender и relay.
  4. RCPT TO — кому отправляем письмо.
  5. DATA — команда сообщает о готовности отправить письмо с заголовками и текстом.
  6. END-OF-DATA — отправка письма.

И так, для настройки антиспама в конфигурационный файл main.cf добавляем:

vi /etc/postfix/main.cf

smtpd_client_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_pipelining
permit

smtpd_helo_restrictions =
permit

smtpd_sender_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_sender
reject_unknown_sender_domain
permit

smtpd_relay_restrictions =
permit

smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_recipient_domain
reject_unverified_recipient
permit

smtpd_data_restrictions =
permit

smtpd_end_of_data_restrictions =
permit

* где параметры:

  1. smtpd_client_restrictions — настройки ограничений при осуществлении клиентских соединений с почтовым сервером.
  2. smtpd_helo_restrictions — ограничения в контексте клиентской команды HELO.
  3. smtpd_sender_restrictions — ограничения будут применяться во время выполнения клиентской команды MAIL FROM.
  4. smtpd_relay_restrictions — ограничения пересылки почты в контексте клиентской команды RCPT TO.
  5. smtpd_recipient_restrictions — ограничения в контексте клиентской команды RCPT TO после пересылки (smtpd_relay_restrictions).
  6. smtpd_data_restrictions — ограничения будут применяться во время выполнения команды DATA.
  7. smtpd_end_of_data_restrictions — ограничения во вреся выполнения команды END-OF-DATA.

… и значения для них:

  • permit_mynetworks — разрешает все адреса, перечисленные в настройке mynetworks.
  • permit_sasl_authenticated — разрешает запросы всех успешно авторизованных клиентов.
  • reject_unauth_pipelining — запрещает отправку писем, которые отправляются заранее (пропуская правильную цепочку сессии SMTP).
  • reject_non_fqdn_sender — отклонить соединение, если адрес отправителя указан неправильно (согласно RFC).
  • reject_unknown_sender_domain — запрещает запрос, если Postfix не является конечным пунктом назначения для адреса отправителя, а домен MAIL FROM не имеет 1) DNS-записи MX и DNS-записи A или 2) искаженной MX-записи, такой как запись с MX-именем хоста нулевой длины.
  • reject_non_fqdn_recipient — запретить соединение, если адрес получателя указан неправильно (согласно RFC).
  • reject_unauth_destination — отклонить соединение, если письмо не пересылается согласно правилу relay_domains или сервер не является адресом назначения. Другими словами, запрещает использование нашего сервера в качестве open relay.
  • reject_unknown_recipient_domain — отклонить запрос, если Postfix не является конечным пунктом назначения для домена получателя, а домен RCPT TO не имеет 1) DNS-записи MX и DNS-записи A или 2) неверно сформированной MX-записи, такой как запись с именем хоста MX нулевой длины.
  • reject_unverified_recipient — отклонить запрос, если известно, что почта на адрес RCPT TO отклоняется или когда адрес получателя не доступен. 
  • permit — разрешает соединение. Ставим в конец каждого блока ограничений (если ограничения не сработали, то разрешаем).

* это более или менее мягкие правила. Их можно использовать первое время, пока тестируем сервер.

Для усиления защиты добавляем:

smtpd_recipient_restrictions =

reject_unknown_client_hostname
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
reject_rbl_client bl.spamcop.net
reject_rbl_client cbl.abuseat.org
reject_rbl_client dul.ru
reject_rbl_client dnsbl.abuse.ch
permit

* где:

  • reject_unknown_client_hostname — проверяет наличие PRT-записи отправителя и наличие рабочей А-записи в соответствие PTR.
  • reject_invalid_helo_hostname — проверяет синтаксис HELO-приветствия.
  • reject_non_fqdn_helo_hostname — требует правильного FQDN-имени во время HELO-приветствия.
  • reject_unknown_helo_hostname — запрещает представляться именами, для которых нет А-записи или MX.
  • reject_rbl_client — проверяет наличие отправителя в черных списках.

* более подробное описание опций для защиты можно найти на странице postfix.org/postconf.5.html.

После внесения всех правок, необходима перезагрузка Postfix:

systemctl restart postfix

Обучение антиспама

Мы установили amavis, который проверяет почту на СПАМ средствами spamassassin. Последний без обучения, практически, бесполезен. Синтаксис команды для обучения следующий:

sa-learn —spam <папка с нежелательными письмами>

sa-learn —ham <папка письмами, которые ошибочно определены как СПАМ>

Таким образом, первая команда укажет spamassassin какие письма являются нежелательными, а вторая — не несущими рекламный характер.

Хорошей практикой будет договориться с пользователями о ручном помещении нежелательной почты из входящих в папку СПАМ. Тогда мы сможем пройтись скриптом по всем ящиками на сервере и обучать антиспам. Например, такой командой:

sa-learn —spam /home/mail/dmosk.local/*/{.\&BCEEPwQwBDw-,.Spam,.Junk\ E-mail,.Junk}/cur

* в данном примере мы сказали spamassassin найти в каталогах пользователей папки Спам, Spam, Junk, Junk E-mail (данные каталоги являются типичными для помещения СПАМа) и провести обучение.

Чтобы минимизировать количество ложных срабатываний, необходимо проводить обучение с ключом —ham. В нашем примере мы отправляем все нежелательные письма на ящик spam. В таком случае, необходимо вручную находить ложные срабатывания и переносить их в специальную папку, например Ham. Тогда команда для обучения будет такой:

sa-learn —ham /home/mail/dmosk.local/spam\@dmosk.local/.Ham/cur

Статистику обучения можно посмотреть командой:

sa-learn —dump magic

Черные и белые списки

В настройках amavis мы можем переопределять СПАМ-бал для конкретного отправителя или всего домена. Для этого открываем файл:

vi /etc/amavisd/amavisd.conf

Находим строки:

#  read_hash(«/var/amavis/sender_scores_sitewide»),

{

}

Внутри фигурных скобок можно создавать новые строки с описанием поведения антиспама.

а) для добавления в белый список.

Присваиваем минусовое значение для бала, например:

{

‘example@mail.ru’                      =>  -10.0,
‘infoit.com.ua’                             =>  -5.0,
}

* в данном примере все письма от домена infoit.com.ua будут получать минус 5 баллов. Таким образом, шансов попасть в СПАМ будет меньше. У всех писем от email example@mail.ru будет отниматься 10 баллов.

б) для добавления в черный список.

В данном случае, мы задаем положительное значение для балла:

{

‘infoit.com.ua’                             =>  5.0,
}

После того, как мы внесли правки в наш файл, перезапускаем amavis:

systemctl restart amavisd

9. Отправка почты наружу

Для отправки почты на другие почтовые серверы необходимо правильно сконфигурировать сервер, чтобы письма не попадали в СПАМ. Чтобы это сделать, выполняем инструкции ниже.

Настройки DNS для сервера

Многие почтовые серверы делают запросы в систему доменных имен для проверки легитимности почтового сервера, отправляющего почту. При настройке MTA очень важно правильно добавить необходимые записи в DNS.

1. rDNS. Обратная зона используется для проверки соответствия имени сервера в приветствии с именем, которое возвращает NS сервер при запросе по PTR-записи.

И так, для создания записи в обратной зоне, необходимо написать письмо Интернет провайдеру, к сети которого подключен сервер или хостеру, если почтовый сервер настроен на VPS. IP-адрес нашего сервера должен вести на имя, которым приветствуется наш postfix — можно посмотреть командой:

postconf -n smtpd_banner

Если мы получим пустой ответ, то вводим:

postconf -n myhostname

Если и в этот вариант не вернет ответ, вводим:

hostname

2. А-запись. Также необходимо, чтобы имя сервера, которым представляется почтовый сервер разрешалось в IP-адрес.

Для этого заходим в консоль управления зоной нашего домена и создаем запись типа А для сопоставления имени сервера с IP-адресом, на котором слушает запросы данный сервер.

Настройки DNS для домена

Для каждого домена, для которого будем отправлять почту создаем записи:

  1. SPF.
  2. DMARC.
  3. DKIM

Для проверки корректности настройки сервера, воспользуемся ресурсами:

Инфа с :  БАЦ