Впровадження DMARC для захисту корпоративного домену від спуфінга

A Thief on the Run by Manweri
A Thief on the Run by Manweri

Привіт, Хабр! У цьому пості ми знову поговоримо про проблему підробки відправника (або так званому спуфинге). Останнім часом такі випадки почастішали: підробляється все: листи з рахунками за ЖКГ, податкової інспекції, банків і так далі. Вирішити цю проблему допомагає налаштування суворої DMARC-політики. Ми як поштова служба перевіряємо всі приходять до нас листи на DMARC починаючи з лютого 2013 року. Ми були першим в рунеті поштовим сервісом, підтримали стандарти DMARC. Однак, щоб мінімізувати число підроблених листів, цього, на жаль, недостатньо. Головне, щоб строгий DMARC був підтриманий на стороні відправника. Ось чому ми не втомлюємося качати цю тему, ведемо активну роз'яснювальну роботу і закликаємо всіх включати в себе строгий DMARC.

Позитивні зрушення вже є: з кожним місяцем ми спостерігаємо приріст числа корпоративних відправників, прописавшись DMARC, на десятки відсотків. Однак безумовно, ще є над чим працювати. Практика показує, що IT-культура знаходиться на дуже різному рівні. Хтось чув краєм вуха про DMARC, але поки не збирається його впроваджувати. Є й такі, для кого факт, що в транспортних протоколах електронної пошти відсутня яка-небудь перевірка і захист адреси відправника, досі є справжнім одкровенням. Крім того, підтримка DMARC — завдання непросте. Тільки на перший погляд здається, що достатньо опублікувати запис в DNS, і не потрібно ніякого додаткового софта або технічних засобів (докладніше у нашій статті DMARC: захистіть вашу розсилку від підробок). На практиці у великій компанії з численними потоками електронної пошти і розлогою структурою поштових доменів все набагато складніше. І є моменти, які слід передбачити і продумати заздалегідь. Саме для таких складних випадків ми написали цю статтю, намагаючись зібрати в ній всі нюанси.

Ми хочемо поділитися власним досвідом впровадження DMARC і всіма граблями, на які ми наступили (закреслено) тими рекомендаціями, які ми виробили при взаємодії з великими компаніями та державними установами. Ми розглянемо лише впровадження політики DMARC для захисту доменного імені. Впровадження серверної частини DMARC для захисту користувачів корпоративного поштового сервера від підроблених листів — це окремий, абсолютно самостійний і незалежний процес.

DMARC — це політика дій з прийшли листами, у яких в полі From використовується публікує політику домен. DMARC дозволяє не тільки вказати, як чинити з такими листами, але і зібрати статистику від всіх одержувачів, підтримують серверну частину DMARC.

Основною проблемою є те, що DMARC вимагає авторизації всіх легітимних листів. А для цього необхідно не просто впровадити методи авторизації (в якості базових протоколів використовуються і DKIM SPF), але і домогтися того, щоб для всіх без винятку легітимних листів із зворотними адресами домену проходила авторизація. Тому впровадження DMARC варто починати з нижченаведеного пункту.

1. Проведіть ревізію легітимних листів від вашого домену і його піддоменів
Типові упущення в цьому процесі:

  • комерційні листи, що відправляються через зовнішніх постачальників послуг по розсилці;
  • внутрішні списки розсилки;
  • перенаправлення пошти з скриньок користувачів;
  • технологічні листи, що формуються серверами і обладнанням;
  • звіти про доставку (DSN) або про неможливість доставки (NDR) листів.
Для кожної категорії листів необхідно впровадити SPF і з'ясувати можливість або неможливість підпису листів з використанням DKIM.

2. Вбудуйте SPF для основного домену і його піддоменів
Часто можна почути, що SPF захищає адресу відправника від підробки. Це не так. SPF контролює тільки адресу SMTP-конверта, який не бачить користувач. При цьому велику кількість доменів досі не впровадили його, і багато сторони не підтримують переадресацію пошти, сумісну з SPF. З цієї причини найчастіше використовується нейтральна політика SPF (neutral,
?
) або м'яке блокування (soft reject,
~
). Для спільного використання з DMARC не має значення, яка саме дефолтна політика (neutral
?
, soft reject
~
або reject ) SPF буде використана. Ми не рекомендуємо використовувати політику reject (), за винятком особливо вимогливих до безпеки доменів, так як це може негативно позначитися на доставці легітимних листів непрямими способами, наприклад через пересилання або списки розсилки. Хоча більша частина одержувачів не блокує листи з SPF навіть при публікації суворої політики, а використовує SPF в рамках вагових класифікаторів. Всупереч усталеній думці, що саме такий режим SPF найчастіше застосовується на практиці, і він повністю відповідає рекомендаціям стандарту.

Можна дати наступні рекомендації щодо впровадження SPF:

  • Не забувайте, що SPF перевіряється для домену адреси envelope-from (він же MAIL FROM і Return-Path). Для того щоб SPF можна було використовувати для аутентифікації відправника повідомлення, домен в envelope-from повинен збігатися з доменом заголовка From з точністю до організаційного домену (тобто до домену другого рівня .ru або .com). Використання неправильних адрес для envelope-from — одна з найчастіших помилок конфігурації сервера, CMS і серверних скриптів.

  • SMTP деякі категорії листів (NDR DSN) мають порожній адреса envelope-from. Для таких листів аутентифікація виконується по домену, який SMTP-сервер використовує в команді HELO/EHLO і який, як правило, збігається з канонічним ім'ям сервера. Некоректні імена в команді HELO — це ще одна поширена проблема. Переконайтеся, що доменне ім'я в HELO правильне, і пропишіть для нього відповідну SPF політику наприклад,
    mailserver.example.org. TXT "v=spf1 a -all"
    . Перевірте, що в повідомленнях про неможливість доставки не використовується домен або використовується домен, що збігається з доменом HELO з точністю до другого рівня.

  • Не забувайте, що SPF не діє на піддомени. Необхідно впроваджувати його для кожного піддомену або вдаватися до wildcards DNS.

  • SPF має обмеження на 10 дозволів імен для одного запису. Тому слід мінімізувати використання елементів, що призводять до додаткових дозволів, таких як
    mx
    та
    include
    . Наприклад, для елемента
    mx
    потрібно один додатковий запит на отримання самої MX-запису і по одному запиту на кожен сервер в MX-запису для отримання IP-адреси по імені.
3. Опублікуйте DMARC-запис з політикою none для основного домену і піддоменів
Приклад такого запису:

_dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s"

Запис інструктує одержувача надсилати на адресу
rua@example.com
щоденні статистичні звіти. Із звітів будуть видні всі IP-адреси, з яких здійснювалася розсилка листів від імені вашого домену, і статус авторизації SPF, DKIM і DMARC для цих листів. Особливо уважно стежте за листами з ваших IP-адрес. Проконтролюйте за звітами, не упустили ви якісь категорії листів або їх джерела у своїй ревізії. При необхідності скорегуйте SPF. Деякі одержувачі можуть надсилати звіти щодо окремих випадків проблем з SPF (
fo=s
) на адресу
ruf
, ці звіти призначені для ідентифікації проблемних розсилок.

Типові проблеми і рекомендації:

  • Ми не радимо публікувати політику навіть з тегом
    none
    до того, як для основних потоків листів буде впроваджено хоча б один з механізмів аутентифікації DKIM SPF або.
  • Запис повинна починатися саме з v=DMARC1, і регістр букв має значення.
  • Деякі клієнти DNS показують зворотні скісні риски перед крапкою з комою
    v=DMARC1\;p=none
    — але в записах DNS-зони зворотний слеш додавати, як правило, не потрібно.
  • Адреси rua/ruf повинні належати до того ж організаційного домену, для якого публікується політика, або приймає домен повинен опублікувати спеціальну політику, показує згоду на прийом репортов. Не вийде приймати репорти на адреси, наприклад, публічних пошт.
  • Якщо ви ще не закінчили впровадження DKIM, то ви будете отримувати досить багато порушень DMARC з IP-адрес публічних пошт (Mail.Ru, Gmail, Hotmail/Outlook, Yahoo тощо). Це пов'язано з тим, що користувачі даних сервісів часто використовують перенаправлення в інші ящики, і це призводить до порушення аутентифікації SPF. Усувається проблема впровадженням підпису DKIM.
  • Є непогані інструменти для візуалізації звітів DMARC. Dmarcian надає платні і безкоштовні (для невеликих обсягів пошти) сервіси, і зручний зручний безкоштовний інструмент XML-To-Human Converter для перегляду DMARC-звітів. Agari і ReturnPath також пропонують комерційні сервіси для впровадження і підтримки DMARC.
4. Вбудуйте DKIM
Рекомендації:

  • Переконайтеся, що генеруються серверами листи відповідають рекомендаціям, інакше можлива ситуація, що при передачі поштовим релеем лист буде змінено для приведення його у відповідність зі стандартами (найчастіше відбувається розбиття довгих рядків), чого порушиться DKIM-сигнатура.
  • Використовуйте режим канонізації relaxed/relaxed, він рідше призводить до проблем, пов'язаних з нормалізацією листи при передачі.
  • Вбудуйте DKIM на всіх джерелах листів для всіх піддоменів.
  • Використовуйте окремі селектори з окремими ключами для зовнішніх джерел (провайдерів послуг по розсилці пошти), щоб була можливість відкликати ключ при необхідності.
  • Для DMARC необхідно, щоб домен в DKIM-підписи, збігався з точністю до організаційного домену з доменом заголовку From. При цьому можуть бути присутніми і інші DKIM-підписи, але вони будуть ігноруватися.
  • Контролюйте впровадження DKIM за статистичними звітами від зовнішніх сервісів.
  • Використовуйте
    fo=1
    в політиці DMARC, це дозволить отримувати forensic-репорти з усіх проблем з SPF і DKIM, навіть для листів, що проходять авторизацію DMARC.
5. Почніть перемикання на сувору політику
Не використовуйте довго політику quarantine, так як вона може маскувати наявні проблеми. Обов'язково стежте за журналами сервера і звітами про неможливість доставки листів на предмет помилок, пов'язаних з DMARC. Стандарт рекомендує одержувачам, впроваджує серверну частину DMARC, обов'язково вказувати його причину в повідомленні про помилку, тому для ідентифікації проблеми можна використовувати «DMARC» як ключове слово в повідомленні про помилку. По журналам сервера ви побачите проблему значно раніше, ніж за звітами.

Можна почати з включення політики на 10% (
p=reject; pct=10
), щоб відстежити потенційні проблеми з помилок доставки, так як агреговані репорти приходять тільки через деякий час. Але довго тримати таку політику не рекомендується: на решту 90 % спрацьовувань буде застосовуватися політика quarantine, і можна пропустити поодинокі проблеми.

Можна впроваджувати політику, відмінну від політики основного домену, на окремі піддомени, публікуючи для них окремі політики чи вказавши в політиці основного домену (
p=none; sp=reject
): політика sp буде діяти на піддомени, які не публікують власну політику.

Коли всі піддомени будуть переведені на сувору політику, можна прибрати політики піддоменів — або ж залишити, на ваш розсуд. Впливає це тільки на генерацію репортов у відповідності зі сформованою практикою (в стандарті даний момент не обговорений). Якщо він публікує свою політику, на неї стануть приходити окремі репорти; якщо окремої політики немає, то звіти по піддомену будуть включатися у звіт батьківського домену.

6. Тюнінг політики DMARC
Нижче наведено розбір деяких необов'язкових полів DMARC-записи, приклади та рекомендації щодо їх використання.

p (
p=reject
) — політика DMARC. Вказує одержувачу, як поступати з листами, що не проходять аутентифікацію. Може приймати значення
none
(доставляти листи одержувачу),
quarantine
(доставляти листи в папку «Спам») і
reject
(не приймати листи).

sp (
sp=quarantine
) — політика для піддоменів, не публікують самостійної політики. Якщо піддомен має власну політику DMARC, то
sp
на нього не впливає. При відсутності поля
sp
в запису DMARC для піддоменів, не мають власної політики, застосовується політика з поля
p
.

pct (
pct=20
) — відсоток листів, на які діє дана політика. Наприклад, при завданні політики
reject
,
pct=20
до отриманого листа з імовірністю 20 % буде застосована політика
reject
та з ймовірністю 80 % — політика
quarantine
.

rua (
rua=mailto:ruamailbox@example.com
) — адреса, на який одержувачі будуть відправляти аггрегированный (статистичний) звіт. Адреса повинен належати тому ж організаційного домену. Ми рекомендуємо обов'язково публікувати адреса для агрегованих звітів і стежити за ними як мінімум на етапі впровадження політики DMARC.

ruf (
ruf=mailto:rufmailbox@example.com
) — адресу, на яку будуть надсилатися forensic-звіти (тобто дослідні) по окремих листів. За замовчуванням forensic-репорти відправляються тільки щодо порушень DMARC. Можна використовувати опцію fo для регулювання поведінки. В даний час відносно невелика кількість одержувачів відправляє forensic-звіти.

fo (
fo=1
) — за жодних порушень відправляти повідомлення.
fo=0
(за промовчанням) відправляє звіти, тільки коли не пройшли обидві аутентифікації: і DKIM SPF.
fo=1
— коли не проходить будь-яка з аутентифікація, навіть якщо проходить альтернативний метод.
fo=s
шле forensic-репорти на проблеми з SPF-аутентифікації.
fo=d
— на проблеми DKIM.

adkim (
adkim=r
) — режим перевірки відповідності DKIM-домену. За замовчуванням використовується режим
r
(relaxed) і повинен збігатися тільки організаційний домен. У строгому (
s
) режимі вимагається повний збіг домену адреси відправника з доменом з DKIM-сигнатури. Має сенс використовувати суворе відповідність домену, якщо частина ваших піддоменів делегована недоверенным сторонам.

aspf (
aspf=r
) — аналогічно для домену envelope-from, для якого перевіряється SPF і From. При
aspf=s
ці домени повинні повністю збігатися для проходження аутентифікації SPF.

ri (
ri=86400
) — бажаний інтервал отримання агрегованих звітів (в секундах). За замовчуванням звіти відправляються раз на добу, але деякі одержувачі (не все, т. к. підтримка даного параметра сервером не є обов'язковою) підтримують відправку звітів з більш короткими інтервалами. На етапі впровадження політики можна спробувати використовувати менші ri, наприклад
ri=3600
.

Ми дуже раді, що власники доменів почали замислюватися про захист свого доменного імені в електронному листуванні. Якщо у вас є питання або вам потрібні поради або допомоги з налаштуванням SPF, DKIM, DMARC, звертайтеся за адресою dmarc_support@corp.mail.ru або задайте питання тут. Ми сподіваємося, що разом зможемо зробити електронну пошту безпечніше для всіх користувачів.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.