Защита почтового сервера без антивируса

Электронная почта — один из самых популярных каналов распространения спама, малвари и фишинговых ссылок. Существует куча софта, который защищает почтовые серверы от этих напастей, да вот незадача: большинство таких программ стоит денег, и порой немалых. В этой статье я расскажу, как усилить безопасность корпоративных почтовых серверов (MS Exchange и Postfix) с помощью доступных штатных средств — DKIM-, SPF- и DMARC-записей, не требующих использования дорогостоящих коммерческих продуктов.

Защита почтового сервера без использования антивируса

Итак, прежде чем мы приступим непосредственно к изменению настроек безопасности нашего почтового сервера, нужно разобраться с тем, что именно мы собираемся настраивать. Если тебя не пугают страшные на вид аббревиатуры, состоящие из трех и более заглавных букв латинского алфавита, ты можешь пропустить этот раздел. Остальных приглашаю освежить свои знания, ибо повторение, как гласит народная мудрость, мать учения.

Важно помнить, что, к сожалению, настройка DKIM-, SPF- и DMARC-записей не панацея от всех бед. Если почтовый сервер был взломан, эти функции безопасности не смогут защитить от нелегитимного трафика. Поэтому важно заранее продумать эшелонированную защиту системы, включая антиспам-фильтры, антивирусное детектирование и прочее.

Что такое DKIM?

DKIM (Domain Keys Identified Mail) — это, условно говоря, цифровая подпись, которая подтверждает подлинность отправителя и гарантирует целостность доставленного письма. Подпись добавляется в служебные заголовки сообщения и остается незаметной для самого пользователя. Поскольку в DKIM используется асимметричная система шифрования, репозиторий сервера всегда хранит два ключа шифрования — открытый (сертификат) и закрытый. С помощью закрытого ключа формируются заголовки для всей исходящей почты, а открытый ключ как раз добавляется в DNS-записи в виде TXT-файла.

Статус DKIM проверяется автоматически на стороне получателя при сохранении письма в контейнер (именной почтовый ящик). И если домен в письме не авторизован для отправки сообщений, то письмо может быть помечено подозрительным или же сразу помещено в папку «Спам», в зависимости от настроенной политики безопасности. Кстати, это одна из ключевых причин, почему письма определенных отправителей постоянно попадают в спам, даже несмотря на валидность домена отправителя.

Для работы с DKIM требуется выполнение следующих условий:

• поддержка DKIM почтовым сервером (а она есть у всех современных почтовиков);
• создание приватного и публичного ключа шифрования (это нужно сделать ручками);
• занесение в DNS домена записей, связанных с DKIM (и это тоже ручками).

Что такое SPF?

SPF (Sender Policy Framework) — это еще одна специальная подпись, содержащая информацию о серверах, которые могут отправлять почту с твоего домена. То есть SPF позволяет владельцу домена указать в TXT-записи для DNS-домена специальным образом сформированную строку, содержащую весь список серверов, которые имеют право отправлять email-сообщения с обратными адресами в этом домене. А если сказать то же самое понятными словами, то в этой записи мы сообщаем, с каких почтовых серверов можно посылать письма от имени сотрудников нашей компании. Воу! Вот так просто! В общем, наличие SPF снижает вероятность, что твое письмо попадет в спам.

РЕКОМЕНДУЕМ:
Как написать веб-приложение устойчивое к ботнетам

Важно помнить, что SPF-запись должна быть только одна для одного домена, хотя уже в рамках одной SPF может содержаться несколько записей. И нужно сказать, что для поддоменов будут нужны свои записи. И никак иначе! Безопасность требует времени и усердия.

Что такое DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это еще одна подпись, которая позволяет серверу получателя принять решение, что делать с пришедшим письмом. Важно заметить, что DMARC — это скорее дополнительная фича к уже используемым DKIM и SPF. Например, если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Все логично. А вот если письмо успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC оно тоже преодолеет. Также при помощи DMARC можно получать репорты от почтовых систем с информацией, сколько через них пыталось пройти или прошло поддельных сообщений на ваш домен. Из сказанного становится понятно, что DMARC добавляется только после того, как уже настроены записи SPF и DKIM.

От чего нельзя защититься с помощью DKIM, SPF и DMARC

С использованием DKIM, SPF и DMARC можно противостоять email-спуфингу и распространению малвари. Однако важно понимать, что это не гарантирует безопасности в случае взлома сервера, например путем компрометации админки или применения эксплоита, а также если письма форвардятся через иные почтовые сервисы с сомнительной репутацией или с полностью отсутствующими записями DKIM, SPF и DMARC.

Некоторые полезные ссылки для проверки корректности настройки DKIM- и SPF-записей, а также репутации домена:

• SPF Policy Tester — онлайн-сервис проверки корректности SPF-записи. Для проведения теста на сайте указываешь почтовый адрес, с которого хочешь отправлять письма, и IP-адрес почтового сервера. Если все хорошо, то после нескольких секунд ожидания внизу страницы должна появиться зеленая надпись PASS.
• Dkimvalidator.com — разработчики этого сервиса дают тебе адрес почты, на который нужно выслать письмо. После этого можно просмотреть отчет о валидности DKIM. Все просто!
• Mail-tester.com — еще один вариант аналогичного сервиса, где тебе предоставляется адрес почты для отправки тестового сообщения, а после этого можно посмотреть отчет о доставке. Если возникли проблемы, из представленного репорта можно понять, в чем именно заключаются косяки.

Также не стоит забывать о регистрации своего сервера в службах постмастера для публичных почтовых серверов (если ты, конечно, администрируешь такой сервер). Это позволит тебе не только получать статистику по рассылкам, но и заработать чуть больше доверия от этого почтового сервиса. Вот самые известные и часто используемые постмастеры: Mail.RU, Yandex и Gmail.

Практика и еще раз практика

В практической части мы рассмотрим конфигурирование описанных выше настроек безопасности на примере двух наиболее популярных почтовых серверов — опенсорсного Postfix на Debian (ну, или Ubuntu Server) и проприетарного Microsoft Exchange Server 2013+. Предполагается, что почтовые серверы у тебя уже установлены и настроены под твой домен, поэтому рассматривать будем только само конфигурирование фич на обезличенных данных.

Настраиваем SPF, DKIM и DMARC на Postfix (Debian)

Общий принцип работы нашего почтового сервера будет таков:

1. Принимающий сервер получает письмо с адреса [email protected], отправленное с сервера mx.example.com.
2. Сервер получателя делает запрос к DNS для домена example.com и ищет записи SPF и DKIM.
3. В случае если записей нет, письму проставляется статус neutral (конкретно по этим проверкам) и письмо проверяется дополнительными фильтрами.
4. В случае если записи обнаружены, проверяется, разрешено ли серверу mx.example.com отправлять почту домена example.com.
5. Если домен mx.example.com не найден в списке разрешенных, то или письмо отбрасывается, или ему устанавливается статус neutral.
6. Если домен mx.example.com таки найден в списке разрешенных, письму устанавливается статус Pass и повышается его рейтинг при прохождении других фильтров.

Ну что, погнали!

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

Настройка SPF-записи

Если ты отправляешь все сообщения только с одного сервера (почтовые клиенты не считаются), то в SPF-записи будет достаточно указать IP-адрес этого сервера:

Описание опций:

• v=spf1 — используемая версия SPF;
• + — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. То есть, если никаких параметров не установлено, это автоматически Pass;
• - — отклонить (Fail);
• ~ — мягкое отклонение (SoftFail). Письмо будет принято, но будет помечено как спам;
• ? — нейтральное отношение, то есть никаких действий не предпринимать;
• mx — включает в себя все адреса серверов, указанные в MX-записях домена;
• ip4 — опция позволяет указать конкретный IP-адрес или подсеть IP-адресов;
• a — указываем поведение в случае получения письма от конкретного домена;
• include — включает в себя хосты, разрешенные SPF-записью указанного домена;
• all — все остальные серверы, не перечисленные в SPF-записи.

А теперь, используя эту шпаргалку, расшифруем то, что указано в нашей записи:

• +a — разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для mydomen.ru;
• +mx — разрешает прием писем, если отправляющий хост указан в одной из MX-записей для mydomen.ru;
• ip4: — это не что иное, как IP-адрес нашего собственного почтового сервера;
• -all — все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, будут отброшены.

Вот, в принципе, и все! Никаких плясок с бубном и сотен строк скриптового кода, нужно только прописать правильно указанную строку и радоваться жизни ленивого сисадмина.

Проверка корректности внесенных SPF-записей

Обновление DNS-записей обычно занимает некоторое время. В зависимости от твоей локации и загруженности серверов может пройти от 30 минут до одних суток.

Итак, чтобы проверить корректность нашей записи, идем на ресурс MxToolBox и вбиваем доменное имя, для которого только что прописали SPF. Жмем кнопку SPF Record Lookup и смотрим на результат.

Настройка DKIM-записи

Для начала на нашем почтовом сервере необходимо установить пакет opendkim, поскольку именно он отвечает за возможность конфигурирования DKIM. Для этого от имени суперпользователя отдадим в терминале следующие команды:

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

Потом в обязательном порядке создаем ключи для наших доменов и селектор (в нашем примере используется домен example.com и example.org, а селектор mail. Селектор может быть любой. По сути, это всего лишь название для ссылки на ключ):

Приведенная выше команда создаст файлы /etc/opendkim/example.com/mail.private и /etc/opendkim/example.com/mail.txt (и аналогично для каждого домена), с секретным и публичными ключами соответственно.

Файл mail.txt (для соответствующего домена) содержит публичный ключ (сертификат), который надо разместить на DNS-сервере в TXT-записи для того домена, для которого он был создан.

Пример данной записи:

Владельцем ключей обязательно указываем opendkim: если этого не сделать, иногда в работе сервера возникают ошибки. Для этого пишем в консоли от рута:

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

Содержимое файла /etc/opendkim/KeyTable (здесь все слова mail меняем на наш селектор, в данном файле прописываются домены и пути к секретным ключам):

Смотрим содержимое файла /etc/opendkim/SigningTable:

В файле /etc/opendkim/TrustedHosts определяем так называемые ExternalIgnoreList и InternalHosts, то есть хосты, домены и IP-адреса, сообщения от которых будут считаться доверенными и будут подписываться.

Так как в основном конфигурационном файле мы укажем, что файл TrustedHosts имеет тип refile (файл с регулярными выражениями), мы можем использовать в нем регулярные выражения. Например, *.example.com означает, что сообщения, поступающие от поддоменов example.com, тоже будут доверенными.

Пример файла /etc/opendkim/TrustedHosts (у тебя он будет свой, поэтому слепо не копируй):

Ну и конечно же, настроим сам пакет opendkim. Для этого внесем следующие настройки в конфигурационный файл /etc/opendkim.conf:

А вот расшифровка этих магических слов:

• AutoRestart — автоматический перезапуск демона в случае ошибки;
• AutoRestartRate — определяет максимальное количество перезапусков в единицу времени, после чего фильтр останавливается. Например, значение 10/1h говорит о том, что разрешено не более десяти автоматических перезапусков за час, если значение будет превышено — автоперезапуск в случае ошибки будет отключен;
• UMask — предоставляет все права доступа группе пользователей, указанной в UserID, и позволяет другим пользователям читать и выполнять файлы;
• Syslog, SyslogSuccess, LogWhy — эти параметры настраивают ведение логов с помощью системного демона журналирования syslog;
• Canonicalization — определяет методы преобразования, используемые при подписании сообщения;
• метод simple не позволяет практически никаких изменений, в то время как метод relaxed допускает незначительные изменения (например, замена пробела). Значение relaxed/simple указывает, что заголовок сообщения будет обрабатываться методом relaxed, а тело сообщения — методом simple;
• ExternalIgnoreList — определяет внешние хосты, которые могут отправлять почту через сервер в качестве одного из подписанных доменов без учетных данных;
• InternalHosts — определяет список внутренних хостов, почтовые сообщения от которых не должны проверяться, но должны быть подписаны;
• KeyTable — файл-карта названий и путей к секретным ключам;
• SigningTable — список подписей, которые будут применяться на основании заголовка письма, указанного в поле «From:»;
• Mode — режимы работы; в данном случае выступает в качестве milter (фильтрация писем до попадания в очередь сообщений, прописывается в Postfix в main.cf, см. ниже), подписывающего (s) и верификатора (v). В нашем случае мы будем только подписывать;
• PidFile — путь к файлу Pid, который содержит идентификационный номер процесса;
• SignatureAlgorithm — указывает используемый алгоритм электронной подписи;
• UserID — указывает, под каким пользователем и группой должен работать процесс opendkim;
• Socket — milter будет слушать на указанном здесь сокете, Postfix будет отправлять сообщения opendkim для подписи и проверки через этот сокет. В нашем случае будет использоваться localhost и 8891-й порт (8891@localhost).

После всех проделанных изменений обязательно перезапускаем демон opendkim:

Также обязательно прописываем для Postfix в файле main.cf вот эти строчки:

Если у тебя уже используется milter (например, для SpamAssasin), тогда эти же строчки будут выглядеть так:

После внесения всех изменений в конфигурационный файл Postfix мы снова его перезапустим:

Определим политику ADSP (Author Domain Signing Practices)

ADSP — дополнительное расширение DKIM, предназначенное для проверки подлинности email через DKIM. С помощью этого механизма домен может публиковать методы подписи, которые он принимает при передаче почты от имени ассоциированных авторов.

Чтобы настроить политику ADSP, нужно разместить на DNS-сервере в TXT-записи для каждого домена, для которого используется DKIM, следующую строчку:

Значения могут быть такими:

• unknown — значение по умолчанию (аналогично тому, что указанной DNS-записи вообще нет). Данное значение говорит почтовым серверам (на которые ты будешь отправлять письма) о том, что письма могут быть как с подписью DKIM, так и без нее;
• all — говорит, что все письма будут подписаны;
• discardable — говорит, что все письма будут подписаны, а если письмо не подписано или подпись неверна, то его следует удалить.

Проверка корректности внесенной DKIM-записи

Для проверки настроенного DKIM уже ничего не нужно ждать, как это было в предыдущем случае. Можно просто отправить письмо на адрес check-auth@verifier.port25.com и получить ответ.

Вот пример такого ответа, сообщающий, что DKIM настроен корректно:

Ура! Все получилось! Открывай бутылку пива!

Также для проверки можно отправить письмо (например, себе же на какой-нибудь из общедоступных почтовых серверов вроде mail.yandex.ru или mail.ru), открыть его исходник и найти в теле такие строчки:

и еще вот такие:

Настройка DMARC

Последний штрих нашего мануала — это настройка DMARC. Как мы уже выяснили, DMARC — это опциональная вещь, которая позволяет нам определить порядок работы с письмами, не прошедшими проверку фильтров SPF или DKIM.

Все делаем точно так же через DNS-запись типа TXT:

Здесь мы устанавливаем, что, если письма не прошли SPF или DKIM, ничего делать не нужно. Но можно поставить маркер p=reject, тогда такие письма будут сразу же дропаться.

Ну вот и все на этом! Настройка DKIM, SPF и DMARC-записей для open sources MTA завершена! А впереди нас ждет настройка аналогичных опций, но уже на почтовике от Microsoft.

Конфигурируем SPF и DKIM на MS Exchange Server

Безусловно, мы не можем обойти стороной огромную аудиторию сисадминов, по своей или не своей воле выстроивших корпоративный ИТ-ландшафт на базе продуктов всем известной корпорации Microsoft. Поэтому ниже мы рассмотрим настройку SPF- и DKIM-записей для почтового сервера MS Exchange Server. Должен сказать, что все приведенные здесь настройки были мною протестированы на версии MS Exchange Server начиная с 2013, хотя и не исключены какие-нибудь приколы с наиболее актуальным сегодня билдом MS Exchange Server 2019 (версия 15.2). Так что внимательно читай changelog’и и документацию ко всем используемым утилитам.

Установка Exchange DKIM Signer

Перед началом всех действий нам понадобится установить специальную утилиту Exchange DKIM Signer.

Для этого мы идем на страничку GitHub тулзы DKIM Signer и скачиваем оттуда файл с названием Source Code. Далее распаковываем загруженный ZIP-архив в любую временную директорию на диске С:\. Обязательно от имени администратора запускаем PowerShell-скрипт Exchange Management Shell и переходим в распакованную папку.

Если возникнут ошибки, перед тем как запустить установочный скрипт .\install.ps1, зададим политику выполнения PowerShell-скриптов следующей командой:

Или еще вариант:

Теперь наконец-то запускаем сам скрипт установки .\install.ps1 и ждем завершения операции.

Для тех, кто не очень любит работать с консолью, есть вариант графической установки Exchange DKIM Signer. Для этого идем в репозиторий на GitHub и скачиваем там файл с именем Configuration.DkimSigner.zip. Распаковываем содержимое архива в произвольную папку на C:\ и запускаем из нее исполняемый файл Configuration.DkimSigner.exe, в открывшемся окне выбираем, какую версию будем устанавливать, жмем Install и ждем несколько секунд до завершения операции.

Конфигурирование агента Exchange DKIM Signer

Не закрывая предыдущее окно Exchange DKIM Signer, на вкладке Information нажимаем кнопку Configure.

В открывшемся окне выбираем Exchange DkimSigner и понижаем приоритет до самого низкого, в моем случае это значение 7. Такой приоритет означает, что почтовое сообщение будет обрабатываться этим агентом в последнюю очередь.

Далее переходим на вкладку DKIM Settings и переключаем алгоритм хеширования на RsaSha256. Активируем опции Body Canonicalization, а Header Canonicalization выставляем в значение Simple. Тут же, не закрывая окно, можно настроить заголовки почтовых сообщений, которые будут подписываться. Однако эта настройка для работы не критична, поэтому оставим все как есть по умолчанию.

После всех правок не забываем нажать кнопку Save configuration.

Переходим на вкладку Domain Settings, где удаляем предустановленные домены по умолчанию — example.com и example.org. Нажимаем на кнопку Add, вводим свои значения и заполняем основные поля. Поле Domain Name — это имя нашего почтового домена; например, для адресов типа UserName@company.com это поле примет значение company.com.

Поле Selector — это произвольная строка, которая добавляется к имени домена. С помощью поля Selector правильно идентифицируется public key в TXT-записи на DNS-сервере.

Если взять установленное нами значение из поля Selector и посмотреть на Email Headers отправляемых с сервера писем, то мы увидим тег s=, который имеет значение из поля Selector. Тег d= имеет значение, указывающее на наш почтовый домен. Таким образом сервер получателя понимает, какой именно public key на нашем DNS-сервере нужно проверять.

РЕКОМЕНДУЕМ:
Настройка система обнаружения вторжений Snort

На следующем шаге генерируем ключевую пару «открытый — закрытый ключ» (public key и private key). Private key будет храниться строго на сервере, и с его помощью будет подписываться вся исходящая почта. Нажимаем кнопку Generate Key и сохраняем *.xml-файл в папку keys.

После всех этих действий на выходе должно получиться три файла в папке keys:

• MailDomain.ru.xml;
• MailDomain.ru.xml.pub — файл содержит public key, в будущем мы разместим его в TXT-записи на нашем внешнем DNS-сервере;
• MailDomain.ru.xml.pem — файл содержит private key.

После сохранения всех XML-файлов не забываем нажать Save Domain, иначе изменения не сохранятся.

Далее Exchange DKIM Signer предлагает нам создать TXT-запись на внешнем DNS-сервере, который обслуживает наш почтовый домен.

Проверка работоспособности почтового сервера после конфигурирования Exchange DKIM Signer

Теперь мы отправим тестовые письма на известные почтовые домены, такие, к примеру, как gmail.com и yandex.ru, и посмотрим, как они доходят. Можно воспользоваться сервисом MxToolBox, введя IP-адрес нашего почтовика и проверив таким образом корректность DKIM- и SPF-записей.

Заключение

Сегодня мы рассмотрели доступный каждому админу простой и не требующий заморочек набор штатных средств, помогающих усилить безопасность почтовых серверов под *NIX и серверы Microsoft. Грамотно сконфигурированные DKIM-, SPF- и DMARC-записи позволят по максимуму снизить поток спама, фейковых рассылок, писем с малварью и в целом хоть как-то сократить нелегитимный трафик между почтовыми серверами в интернете. Конечно, предложенное решение — это не панацея от всех бед, но это еще один дополнительный барьер на пути злоумышленников, притом еще и бесплатный.