Защищаем почтовый сервер от спама, вирусов и фишинга с помощью DKIM, SPF и DMARC-записей|Информационная безопасность

Электронная почта является одним из старейших и ключевых элементов корпоратвиного ИТ-ландшафта абсолютно любой компании. Не смотря на растущие альтернативы в виде систем электронного документооборота, межведомственной связи и других share-площадок, до сих огромное количество данных, в том числе и конфиденциального характера пересылаются с помощью обычных электронных писем. Хотя, конечно, значимость e-mail серверов сегодня уже не та, что, к примеру, еще лет так 10 или 15 назад. Вспомним хотя бы эпидемию vbs-вируса Love Letter (I love you) или червя Melissa, распространявшихся в основном посредством рассылки вредоносных писем с зараженных машин. Да, и что говорить, почта до сих пор является одним и векторов для реализации таргетированных APT-атак у "плохих парней" и одним из пунктов чек-листа при проведении расширенного пен-теста у легитимного заказчика.

Сегодня в материалы мы рассматриваем вопросы усиление безопасности корпоративных почтовых серверов с помощью доступных подручных средств, т.к. DKIM, SPF, DMARC-записи, не требующих использования сторонних дорогостоящих коммерческих продуктов ИБ.

Что такое DKIM?

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

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

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

Поддержка DKIM почтовым сервером
Создание приватного и публичного ключа шифрования
Занесение в DNS домена записей связанных с DKIM

Что такое SPF?

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

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

Что такое DMARC?

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

Ограничения

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

Полезные сервисы

SPF Policy Tester - онлайн-сервис проверки корректности spf-записи. Указываете почтовый адрес с которого хотите отправлять и ip-адрес почтового сервера. Если все хорошо, то внизу теста должна быть зеленная надпись PASS

Dkimvalidator.com - вам дают адрес почты на который нужно выслать письмо, после этого можно просмотреть отчет об валидности dkim. Все просто!

Mail-tester.com - аналогичный сервис, где вам дается адрес почты на который нужно выслать письмо, а после этого можно посмотреть отчет

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

Постмастера Mail и Yandex и Gmail

Практика

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

1. Конфигурируем SPF,DKIM и DMARC на Postfix (Debian)

Общий принцип работы нашего почтового сервера будет таков:
Сервер получателя получает письмо с адреса info@example.com, с сервера mx.example.com;
Сервер получателя делает запрос к DNS для домена example.com и ищет записи SPF и DKIM;
В случае если записей нет, письму проставляется статус neutral (конкретно по этим проверкам) и письмо проверяется дополнительными фильтрами;
В случае если записи обнаружены, проверяется, разрешено ли серверу mx.example.com отправлять почту домена example.com;
Если mx.example.com не найден в списке разрешенных, то письмо или отбрасывается, или проставляется статус neutral;
Если mx.example.com найден в списке разрешенных, письму проставляется статус pass и повышается рейтинг письма при прохождении других фильтров.

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

Если вы отправляете сообщения только с одного сервера (почтовые клиенты не считаются), то в SPF-записи будет достаточно указать IP-адрес этого сервера:example.com. IN TXT "v=spf1 +a +mx ip4:12.34.56.78 -all"

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

"v=spf1" - используемая версия SPF.

"+" - принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. То есть, если никаких параметров не установлено, то это "Pass"; "-" - Отклонить (Fail);

"?" - нейтральное отношение; "~" - "мягкое" отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ; "mx" - включает в себя все адреса серверов, указанные в MX-записях домена;

"include" - включает в себя хосты, разрешенные SPF-записью указанного домена; "ip4" - опция позволяет указать конкретный IP-адрес или сеть адресов; "a" - указываем поведение в случае получения письма от конкретного домена;

"all" - все остальные сервера, не перечисленные в SPF-записи.

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

"+a" - разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для mydomen.ru; "+mx" - разрешает прием писем, если отправляющий хост указан в одной из MX-записей для mydomen.ru;

"-all" - все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

"ip4:" - тут мы указали ip адрес нашего почтового

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

1.2 Проверка корректности внесенных SPF

Обновление DNS записей обычно занимает некоторое время, в зависимости от вашего региона и загруженности серверов занимает это от 30 минут до 12 часов.

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

1.3 Настройка DKIM

Для начала на почтовом сервере нам необходимо установить пакет opendkim:

# apt-get update

# apt-get install opendkim opendkim-tools

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

# mkdir /etc/opendkim/keys/

# mkdir /etc/opendkim/keys/example.com/

# mkdir /etc/opendkim/keys/example.org/

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

# opendkim-genkey -D /etc/opendkim/keys/example.com/ -d example.com -s mail

# opendkim-genkey -D /etc/opendkim/keys/example.org/ -d example.org -s mail

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

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

Пример данной записи:mail._domainkey IN TXT "v=DKIM1;k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAdfmWEGERbLGARxEFI9Ibwx79tk1kMi36rFeAT4aLu4iI3ctPUWa7y0WcuMZGCBQMMutolT8IM9EGEHYT/rbKlhoeiA0r8qJZiIX/NkjkLIXzR+9h1i47dD5zCu4uEFWRHETJAERWGQaC9hSHCcCwzosSRwBpaxIMZuRGQIDAQAB"

Владельцем ключей обязательно! делаем opendkim (потому что иногда из-за этого бывают ошибки):chown opendkim:opendkim -R /etc/opendkim/keys

После этого создадим 3 необходимых файла конфигурации:

# touch /etc/opendkim/KeyTable

# touch /etc/opendkim/SigningTable

# touch /etc/opendkim/TrustedHosts

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

mail._domainkey.example.com example.com:mail:/etc/opendkim/keys/example.com/mail.private

mail._domainkey.example.org example.org:mail:/etc/opendkim/keys/example.org/mail.private

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

*@example.com mail._domainkey.example.com

*@example.org mail._domainkey.example.org

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

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

Пример файла /etc/opendkim/TrustedHosts (у вас будет свой!)

127.0.0.1 localhost

192.168.0.1/24 ::1

*.example.org

*.example.com

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

Syslog yes UMask 002

OversignHeaders From Mode s LogWhy yes

Canonicalization relaxed/simple SyslogSuccess yes KeyTable /etc/opendkim/KeyTable

Socket inet:8891@localhost SigningTable refile:/etc/opendkim/SigningTable ReportAddress root AutoRestart Yes

InternalHosts refile:/etc/opendkim/TrustedHosts AutoRestartRate 10/1h ExternalIgnoreList refile:/etc/opendkim/TrustedHosts PidFile /var/run/opendkim/opendkim.pid

UserID opendkim:opendkim

SignatureAlgorithm rsa-sha256

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

AutoRestart: автоматический перезапуск в случае ошибки;

AutoRestartRate: определяет максимальное количество перезапусков в единицу времени, после чего фильтр останавливается. Например, значение 10/1h означает, что разрешено не более 10 автоматических перезапусков за 1 час, если значение будет превышено - автоперезапуск в случае ошибки будет отключен. UMask: предоставляет все права доступа группе пользователей, указанной в UserID и позволяет другим пользователям читать и выполнять файлы. В данном случае это позволяет создавать и изменять pid-файл. Syslog, SyslogSuccess, *LogWhy: эти параметры настраивают ведение логов с помощью syslog.

Метод simple не позволяет практически никаких изменений, в то время как метод relaxed допускает незначительные изменения (например замена пробела и т.д.). Значение relaxed/simple указывает, что заголовок сообщения будет обрабатываться методом relaxed, а тело сообщения - методом simple. Canonicalization: определяет методы преобразования, используемые при подписании сообщения. ExternalIgnoreList: определяет внешние хосты, которые могут отправлять почту через сервер в качестве одного из подписанных доменов без учетных данных. InternalHosts: определяет список внутренних хостов, почтовые сообщения от которых не должны быть проверены, но должны быть подписаны.

Mode: режимы работы; в данном случае выступает в качестве milter (фильтрация писем до попадания в очередь сообщений, прописывается в postfix в main.cf, см. ниже) подписывающего (s) и верификатора (v). В нашем случае мы будем только подписывать. KeyTable: файл-карта названий и путей к секретным ключам. SigningTable: список подписей, которые будут применяться на основании заголовка письма, указанного в "From:". PidFile: путь к файлу Pid, который содержит идентификационный номер процесса. SignatureAlgorithm: алгоритм подписи. UserID: указывает под каким пользователем и группой должен работать процесс opendkim.

и 8891 порт (8891@localhost).

Socket: milter будет слушать на сокете указанном здесь, Posfix будет отправлять сообщения opendkim для подписи и проверки через этот сокет. В нашем случае будет использоваться localhost

После этого запускаем\перезапускаем демон opendkim:# /etc/init.d/opendkim start

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

smtpd_milters = inet:localhost:8891

non_smtpd_milters = inet:localhost:8891 milter_default_action = accept

milter_protocol = 2

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

smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:8891

non_smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:8891 milter_default_action = accept

milter_protocol = 2

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

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

Для этого надо разместить на DNS-сервере в TXT записи для каждого домена для которого используется DKIM следующую строчку:_adsp._domainkey IN TXT "dkim=unknown"

Значения могут быть следующими:

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

discardable: говорит, что все письма будут подписаны, а если письмо не подписано или подпись не верна - то его следует удалить.

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

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

И вот, пример ответа, что DKIM настроен корректно:

The results are as follows:

DKIM Signature validation: pass

DKIM Author Domain Signing Practices: (

Ура! У нас получилось! ̶З̶а̶е̶б̶и̶с̶ь̶,̶ ̶в̶с̶е̶ ̶р̶а̶б̶о̶т̶а̶е̶т̶!̶

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

Authentication-Results: mxfront1g.mail.yandex.net; spf=pass (mxfront1g.mail.yandex.net:

domain of example.com designates 12.34.56.78 as permitted sender) smtp.mail=tester@example.com; dkim=pass header.i=@example.com

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

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=mail; t=1484724874; bh=LGgFxMGKg3waFbi+enIwqHYdnPLt2IsuxgR6s1EEHvg=;

b=fvFO2qXwC3VRfbUVaG4SW3vtmBJbW8+1kKbKuP25/w/UZ7TLq1TruOYhgoCPpk6B/ h=From:To:Subject:Date:From;

5g+xUYyz7/a3oy0MstIFJnhjpJlRwgeS/JPjPfuQ=tz93DY5/1mzbPDTiBuEJoh371t34yJDTWUGqMucoOhXXhHBdtCfns+L6lW5oI+stM

1.6 Настройка DMARC

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

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

хост: _dmarc

значение: v=DMARC1; p=none

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

Ну вот и все на этом! Настройка завершена для open sources MTA завершена!

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

За предоставленные материалов по конфигурированию агента Exchange DKIM Signer большое спасибо все команде блога IT-KB

2.1 Установка агента Exchange DKIM Signer

1) Открываем репо на GitHub и скачиваем файл с названием Source Code

2) Распаковываем ZIP архив во временную директорию на диске С.

3) Открываем от имени администратора power shell-скрипт Exchange Management Shell и переходим в распакованную папку.

4) Перед тем, как запустить установочный скрипт .\install.ps1, зададим политику выполнения PowerShell скриптов:Set-ExecutionPolicy Unrestricted

5) И наконец-то запускаем сам скрипт установки .\install.ps1

Setup нам предлагает запустить Configuration.DkimSigner.exe, чтобы сконфигурировать агента, но мы не будем этого делать сейчас, нажимаем Enter.

6) Теперь можно убедиться в том, что агент удачно установился в системе:

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

1) Идем в папку “C:\Program Files\Exchange DkimSigner\” и запускаем там файл Configuration.DkimSigner.exe после чего видим вот такое окно:

На скриншоте выше видно, что я использую не самую последнюю версию программы, произведем обновление после конфигурирования и проверки работоспособности агента.

2) Нажимаем кнопку Configure:

Выбираем Exchange DkimSigner и понижаем приоритет до самого низкого. Это значит, что почтовое сообщение будет обрабатываться в последнюю очередь этим агентом, когда у письма будут окончательно сформированы все заголовки почтового сообщения, из документации:Make sure that the priority of the DkimSigner Agent is quite low so that no other agent messes around with the headers. Best set it to lowest priority

3) Переходим на вкладку DKIM Settings и переключаем алгоритм хеширования на RsaSha256, Body Canonicalization, Header Canonicalization выставляем в Simple, из документации:Possible values for HeaderCanonicalization and BodyCanonicalization are Simple (recommended) and Relaxed

На вкладке DKIM Settings так же можно настроить заголовки почтового сообщения, которые будут подписываться. Оставим все по умолчанию.

Не забываем нажать кнопку Save configuration.

4) Переходим на вкладку 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 сервере нужно проверять.

Следующим шагом генерируем ключевую пару (public key и private key). Private key будет храниться строго на сервере, и с его помощью будет подписываться вся исходящая почта. Нажимаем кнопку Generate Key и Exchange DKIM Signer предлагает нам сохранить *.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 сервере который обслуживает наш почтовый домен:

В панели хостинг провайдера вашего DNS сервера создаем TXT запись:

После создания TXT-записи в DNS желательно подождать некоторое и уже потом проверять работоспособность.

2.3 Проверка работоспособсти агента Exchange DKIM Signer

Отправим тестовые письма на известные почтовые домены, к примеру такие как gmail.com и yandex.ru:

На скриншоте выше видно, что отработала только SPF запись.

А теперь посмотрим, как будет выглядеть скриншот после включения агента:

Получающий сервер, в данном случае gmail.com, определил, что почтовое сообщение было отправлено через действительный почтовый домен (SPF) и им же подписано (DKIM).

Посмотрим, как yandex.ru определяет, что сообщение имеет достоверную цифровую подпись: