Phishing protection

Exchange довольно мощный и популярный почтовый сервер в мире энтерпрайза. Против угроз малварей и фишинга он имеет как встроенные механизмы защиты, так и возможность использования сторонних продуктов. Но в реальности этих возможностей не всегда достаточно для отлова всех вредоносных писем: малвари проходят к пользователям до того, как их сигнатуры попадут в антивирусные базы, а URL-адреса в репутационные списки. Поэтому мы разработали инструмент, помогающий бороться с различными угрозами, приходящими к нам по почте.

Как известно, в основном атаковать пользователя по почте можно двумя самыми распространенными способами: прицепить в теле письма вредоносные вложения или в тексте письма добавить ссылку, по которой пользователь должен перейти и скачать загрузчик.

Обычно у безопасников считается, что нужно учить пользователей правилам работы с почтой. Типовые корпоративные правила обращения с почтой для пользователей чаще всего сферические в вакууме и не отражают реальность. Например, пользователям советуют не открывать вложения и не переходить по ссылкам от незнакомых отправителей. Но что делать, когда у сотрудников работа заключается в том, чтобы открывать файлы от незнакомых отправителей? Внедренцы и продажники, специалисты по работе с поставщиками/партнерами - для них такие правила трудновыполнимы. Тем более, злоумышленник может подделать отправителя/зарегистрировать похожий на ваш домен и отправить зловреда на ваш почтовый ящик. Или отправить вредоноса со взломанного почтового ящика в старую переписку с сотрудником.

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

Мы в Контуре ежедневно получаем горы вредоносных писем, насмотрелись на разные варианты угроз, и если с вложениями как-то еще было можно бороться, то со ссылками была беда. Поэтому мы решили сделать свой транспортный агент библиотеку для Edge серверов для борьбы с прилетающими по почте вредоносами и фишингом.

История разработки

Сначала мы дописывали StripLinks, который в качестве примера транспортного агента представлен Microsoft, а затем прикрутили к нему функциональность опенсорсного ExchangeAttachmentFilter для фильтрации по имени файлов. Этого нам показалось мало и мы добавили туда анализ контента файлов алгоритмом Ахо-Корасик и регулярками, анализ текста, заголовков и темы письма, а еще обезвреживание автозапуска в pdf.

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

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

Попутно пришлось устранить всякие баги в YARA, из-за которых на сервере через N тысяч операций кончалась память, и служба транспорта падала.

Разработанное мы решили выложить обратно в опенсорс вдруг кому-то послужит с пользой, как нам. Вот ссылка на репозиторий с агентом.

Как это работает

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

• Совпадение отправителя и получателя письма

• Опасные шаблоны в теме письма

• Ссылки в тексте письма

• Опасные шаблоны в тексте письма

• Подделку MessageID

• Потенциально опасные заголовки письма

• SMTP сессию

• Проверку вложения по имени

• Проверку вложения YARA на наличие вредоносных сигнатур

• Проверку содержимого архивов остальными файловыми модулями

Правила для проверки задаются в формате YARA-правил для файлового анализа и в XML для других модулей. В отличие от встроенных механизмов эксченджа, эти правила дают возможность полного контентного анализа, а не только поверхностного принятия решения на основе расширения файла.

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

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

• Пропустить

• Отклонить

• Добавить в тему письма надпись "опасно"

• Добавить в письмо служебный заголовок, на который обратят внимание следующие инструменты защиты

Модули по заданным правилам могут логировать происходящее. Лог сохраняется в локальный файл в формате JSON. Например, полезно собирать инфу об урлах или статистические данные вроде количества похожих писем для разных получателей. У нас лог отправляется в elasticsearch, откуда мы уже забираем данные для дальнейшего анализа. Собранные данные можно отдельно прогонять по репутационным базам или проводить ретроспективный поиск при расследовании инцидентов.

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

Что мы хотим от публикации в опенсурс?

• Идеи, как можно было бы улучшить/поправить инструмент

• Помощь энтузиастов в развитии агента

• Дать коллегам по цеху инструменты и идеи, как можно оградить своих пользователей от почтовых угроз

Если вы видите запись DMARC не найдена, запись DMARC не опубликована илизапись DMARC отсутствует, это означает, что в домене отсутствует самый эффективный и мощный механизм идентификации электронной почты, такой как DMARC.

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

DMARC может защищать от фишинг атак. Фишинг - это мошенническая попытка получить конфиденциальную информацию. Выдавая себя за правомерного индивида, хакеры манипулируют жертвами для выполнения определенных действий. По данным Verizon Data Breach Investigations Report 2018, Фишинг и претекстинг составляют 93% нарушений. 80% всех нарушений связаны с учетными данными DBIR.

Итак, как исправить и добавить отсутствующую запись DMARC?

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

• No DMARC record

• No DMARC record found

• DMARC record is missing

• DMARC record not found

• No DMARC record published

• DMARC policy not enabled

• Unable to find DMARC record

В зависимости от того, чего вы хотите достичь. Есть 2 возможных варианта.

Вариант 1: Просто избавьтесь от раздражающего сообщения No DMARC record, не понимая реальной ценности DMARC и любой защиты от спуфинга электронной почты.

Ответ очень прост. Технически исправление Записи DMARC Не найдено буквально означает добавление записи DNS TXT в субдомен _dmarc.yourdomain.com в соответствии со спецификацией DMARC.

Простую запись DMARC можно рассмотреть на следующем примере:

v=DMARC1; p=none; rua=mailto:whateveryoulike@yourdomain.com

Получилось! Недостающая запись DMARC была успешно добавлена.

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

Вариант 2: Обеспечьте 100% защиту от атак с изменением авторства и спуфинга.

Чтобы добиться 100% защиты, вам нужно понять механизм системы DMARC и то, как она работает. Трудно добиться 100% защиты от спуфинга электронной почты; это требует усердия и некоторого времени (обычно более 2 месяцев и зависит от того, насколько сложна ваша инфраструктура электронной почты).

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

Процесс начинается с простого ввода базовой записи DMARC.

3 шага для устранения проблемы No DMARC record found

1. Опубликуйте запись SPF.

Используйте бесплатный генератор SPF записи EasyDMARC или любой другой, чтобы создать свою запись и опубликовать сгенерированную запись в вашем DNS.

Запись SPF выглядит следующим образом.

v=spf1 include:spf.easydmarc.com include:amazonses.com ip4:198.105.215.71/32 -all

2. Настройте идентификацию DKIM.

Далее вам нужно настроить свой почтовый сервер. Для этого вы можете использовать бесплатный генератор DKIM записи EasyDMARC для идентификации DKIM. Вот автоматический скрипт, который поможет вам настроить почтовый сервер Linux с помощью DKIM.

Для правильного синтаксиса необходимо использовать генераторы записей DKIM.

3. Опубликуйте запись DMARC.

Наконец готовы настроить запись DMARC. Используйте бесплатный генератор DMARC записи EasyDMARC и опубликуйте сгенерированную запись в свой DNS.Во-первых, настоятельно рекомендуется иметь политику мониторинга (p=none). После получения успешных результатов мониторинга система предложит вам изменить опубликованную политику.

Не используйте политику p=reject в самом начале, если вы не уверены, что у вас есть правильная конфигурация и видимость в вашей почтовой инфраструктуре.

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

Имейте в виду, что только запись DMARC с политикой p=reject является самой мощной и стандартной в отрасли системой идентификации электронной почты. Однако добиться p=reject трудно, потому что размещение его в DNS без надлежащего мониторинга может привести к тому, что ваши действительные электронные письма будут отклонены.

Вы можете легко определить и устранить свои проблемы, автоматизировав свои отчеты с помощью EasyDMARC. Вот пример вышеупомянутых агрегированных отчетов DMARC:

Эти статьи помогут вам настроить DMARC-записи от различных провайдеров DNS:

• GoDaddy DNS

• Cloudflare DNS

• AWS DNS

• Azure DNS

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