На сегодняшний день существует множество способов борьбы со спамом. Одному из них, достаточно эффективному против фишинговых атак, мы решили посвятить отдельную статью. Речь идёт о технической спецификации DMARC (Domain-based Message Authentication, Reporting and Conformance).
Зачем это нужно?
Мошенники отправляют сообщения от имени какой-либо надежной компании с хорошей репутацией. Эти письма содержат ссылки на подставные сайты, где пользователя обманным путем вынуждают оставить свою конфиденциальную информацию, например, доступы к личным аккаунтам, номерам банковских карт и другие подобные вещи.
Чтобы защититься от этого, необходимо отличать оригинальные емейлы от поддельных.
Одним из способов борьбы с фишинговыми атаками является размещение ссылок, найденных в фишинговых письмах, в глобальных черных списках. Например, в листах Google safe browsing или SURBL.
Но у этого способа есть свои недостатки. Во-первых, факт наличия атаки должен быть известен, во-вторых, нельзя получить никакой информации об объёме фишинговой кампании, а также предупредить само попадание подобных писем в почтовые ящики.
Второй способ борьбы включает в себя использование различных механизмов аутентификации отправителя. К ним относятся, например, DKIM (Domain Keys Identified Mail), SPF(Sender Policy Framework) и ADSP (Author Domain Signing Practices). Каждый из этих механизмов имеет свои недостатки, среди которых можно выделить три основных: плохая обработка оригинальных перенаправленных сообщений, неправильное применение политики идентификации к отправителю и невозможность оповещения получателя о том, что письмо было отклонено.
Ещё один вариант предотвращения фишинговой атаки — использование технической спецификации DMARC.
LinkedIn совместно с Gmail, Bank of America, Yahoo! Mail, Return Path, а также многими другими известными компаниями, разработали открытую публичную спецификацию использования DMARC. Впервые DMARC был применен в качестве фильтра входящей почты в Gmail. В данный момент работает в Yahoo, AOL, Facebook, LinkedIn, Mail.ru и некоторых других почтовых сервисах.
Как это работает?
Суть технологии заключается в идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя. DMARC устанавливает стандарт для идентификации электронных сообщений принимающими узлами с использованием механизмов Sender Policy Framework (структуры политики отправителя, SPF) и DomainKeys Identified Mail (почты, идентифицируемой при помощи доменных ключей, DKIM).

Защита в этом случае начинается с подписания всех ваших писем DKIM-ключом и обновления записи SPF. Однако опыт показывает, что проверка по SPF работает некорректно, когда емейл пересылается с одного адреса на другой, а DKIM, хотя и лучше с этим справляется, не является полностью надежным из-за сложного алгоритма подписания. Объединяя эти 2 технологии, мы можем избавиться от их недостатков.
После подписания сообщения, DMARC задает концепцию идентификации. Наиболее значимый идентификатор на стороне получателя — это адрес отправителя в поле From в заголовке емейла. Фильтр DMARC проверяет, соответствует ли домен в заголовке идентификаторам проверки SPF и подписи DKIM.
Для прохождение проверки DMARC любой из этих идентификаторов должен соответствовать домену из поля From, т.е. либо быть полностью идентичным, либо в заголовке должен быть найден поддомен в домене организаций. Это довольно сильно упрощенное описание работы алгоритма DMARC.
Как использовать DMARС?
Чтобы начать использование DMARС, необходимо добавить в DNS-настройки доменную запись. На стороне получателя будет производиться проверка, соответствует ли домен в заголовке From тому, что указан в доменной записи DMARC. Если да, то проверка на стороне получателя завершается успешно.
Например, если мы хотим защитить емейл с заголовком:
From: joe@mail.example.com
Мы можем добавить следующую запись в DNS:
_dmarc.example.com IN TXT “v=DMARC1; p=none”
Здесь основной домен для mail.example.com — example.com.
Это простейшая DMARC запись, которая включает только режим мониторинга. Она дает получателю команду выполнить DMARC-тест и сохранить его результат.
Более продвинутая версия аналогичной записи может выглядеть следующим образом:
_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com”
На этот раз мы инициируем отправку ежедневного сводного отчета для всех проверок DMARC в домене всем получателям DMARC-жалоб. Доставка сообщений в данном случае не затронута, это означает, что все емейлы будут доставлены, как если бы этой записи не было.
Что такое сводные отчеты и зачем их использовать?
Для того, чтобы пользователь мог видеть статистику работы с письмами, используются сводные отчеты.
Сводный отчет показывает, сколько емейлов было получено, с каких IP они отправлены и как много DMARC-тестов было пройдено успешно или провалено и по каким причинам. Это дает нам информацию о том, какие емейлы отправлены с серверов в домене example.com, т.е. являются оригинальными, а какие нет. Более того, мы можем посмотреть, по каким причинам были отклонены письма, отправленные не из домена example.com.
Подобный отчет также является хорошим способом протестировать инфраструктуру отправки емейлов и отследить возможные ошибки, например, отсутствие на сервере SPF или DKIM-подписи писем.
С помощью сводного отчета можно оценить масштабы фишинговой кампании, определить серверы, с которых ведется атака, и получить ссылки, которые можно добавить в черные списки.
Ниже вы можете увидеть пример отчета из DMARC FAQ:
<feedback> <report_metadata> <org_name>acme.com</org_name> <email>noreply-dmarc-support@acme.com</email> <extra_contact_info>http://acme.com/dmarc/support</extra_contact_info> <report_id>9391651994964116463</report_id> <date_range> <begin>1335571200</begin> <end>1335657599</end> </date_range> </report_metadata> <policy_published> <domain>example.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>none</p> <sp>none</sp> <pct>100</pct> </policy_published> <record> <row> <source_ip>72.150.241.94</source_ip> <count>2</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <result>fail</result> <human_result></human_result> </dkim> <dkim> <domain>example.net</domain> <result>pass</result> <human_result></human_result> </dkim> <spf> <domain>example.com</domain> <result>pass</result> </spf> </auth_results> </record> </feedback>
В заключение
DMARC не решает все проблемы фишинга, но заставляет использовать в заголовке поддельного письма домен, отличный от оригинального, а это, в свою очередь, позволяет почтовым провайдерам, производителям антиспам-решений и конечным пользователям с легкостью определять поддельные письма. Борьба со спамом — это гонка вооружений, но, используя инструменты, облегчающие распознавание подобных писем, мы можем быть уверены, что получим ожидаемое качество и безопасность сообщений.