Настройка DKIM-SPF-DMARC записей или защищаемся от спуфинга

в 13:44, , рубрики: DNS, Администрирование доменных имен, защита, инструкция, настройка, спуфинг

Приветствую! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.

1. DKIM

DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.

Принцип работы DKIM (взято с Wikipedia)

Зачем же он нужен?

DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).

Настройка DKIM подписи и DNS записей

Для это нам необходимо создать пару ключей:

openssl genrsa -out private.pem 1024 //генерируем секретный ключ длинной 1024

openssl rsa -pubout -in private.pem -out public.pem //получаем публичный ключ из секретного

Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.

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

Примером записей является
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>"

где
mail — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется тогда, когда задействовано несколько серверов. (на каждый сервер свой ключ)
v — версия DKIM, всегда принимает значение v=DKIM1. (обязательный аргумент)
k — тип ключа, всегда k=rsa. (по крайней мере, на текущий момент)
p — публичный ключ, кодированный в base64. (обязательный аргумент)
t — Флаги:
t=y — режим тестирования. Такие отличают отличаются от неподписанных и нужны лишь для отслеживания результатов.
t=s — означает, что запись будет использована только для домена, к которому относится запись, не рекомендуется, если используются субдомены.
возможные:
h — предпочитаемый hash-алгоритм, может принимать значения h=sha1 и h=sha256
s — Тип сервиса, использующего DKIM. Принимает значения s=email (электронная почта) и s=* (все сервисы) По-умолчанию "*".
; — разделитель.

Так же стоит прописать ADSP запись, которая позволяет понять, обязательно должно быть письмо подписано или нет.
_adsp._domainkey.example.com. TXT "dkim=all"

Значений может быть три:
all — Все письма должны быть подписаны
discardable — Не принимать письма без подписи
unknown — Неизвестно (что, по сути, аналогично отсутствию записи)

2. SPF

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208 (Wiki). Если простым языком, то SPF — механизм для проверки подлинности сообщением, путем проверки сервера отправителя. Как по мне, данная технология полезна в связке в другими (DKIM и DMARC)

Принцип работы SPF (взято с просторов интернета)

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

Примером обычной SPF записи является your.tld. TXT "v=spf1 a mx ~all"
Здесь:
v=spf1 является версией, всегда spf1
a — разрешает отправляет письма с адреса, который указан в A иили AAAA записи домена отправителя
mx — разрешает отправлять письма c адреса, который указан в mx записи домена
(для a и mx можно указать и другой домен, например, при значении a:example.com, будет разрешена а запись не домена отправителя, а example.com)
Так же можно добавлять и отдельные ip адреса, используя ip4: и ip6:. Например, ip4:1.1.1.1 ip6: 2001:0DB8:AA10:0001:0000:0000:0000:00FB. Еще есть include: (include:spf.example.com), позволяющий дополнительно подключать spf записи другого домена. Это все можно комбинировать через пробел. Если же нужно просто использовать запись с другого домена, не дополняя её, то лучше всего использовать redirect: (redirect:spf.example.com)
-all — означает то, что будет происходить с письмами, которые не соответствуют политике: "-" — отклонять, "+" — пропускать, "~" — дополнительные проверки, "?" — нейтрально.

3.DMARC

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

Принцип работы DMARC (взято с просторов интернета)

Настройка DMARC записей

Типичная запись выглядит так: _dmarc.your.tld TXT "v=DMARC1; p=none; rua=mailto:postmaster@your.tld"
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.

Теперь подробнее о тегах:
v — версия, принимает значение v=DMARC1 (обязательный параметр)
p — правило для домена. (Обязательный параметр) Может принимать значения none, quarantine и reject, где
p=none не делает ничего, кроме подготовки отчетов
p=quarantine добавляет письмо в СПАМ
p=reject отклоняет письмо
Тэг sp отвечает за субдомены и принимает такие же значения, как и p
aspf и adkim позволяют проверять соответствиям записям и могут принимать значения r и s, где r — relaxed более мягкая проверка, чем s — strict.
pct отвечает за кол-во писем, подлежащих фильтрации, указывается в процентах, например, pct=20 будет фильтровать 20% писем.
rua — позволяет отправлять ежедневные отчеты на email, пример: rua=mailto:postmaster@your.tld, так же можно указать несколько email через пробел (rua=mailto:postmaster@your.tld mailto:dmarc@your.tld)

Пример отчета

<record>
 <row>
 <source_ip>1.1.1.1</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>your.tld</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>your.tld</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>your.tld</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>1.1.1.1</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>your.tld</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>your.tld</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>your.tld</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 

ruf — отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.

Эпилог

Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).

Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.

Буду рад конструктивной критике и правкам.

Автор: tech42

Источник

Поделиться

* - обязательные к заполнению поля