Вы можете настроить дополнительные параметры DKIM-проверки подлинности отправителей сообщений для одного или нескольких правил.
Перед тем как настроить дополнительные параметры DKIM-проверки сообщений для правила, убедитесь, что DKIM-проверка подлинности отправителей сообщений включена в параметрах Kaspersky Secure Mail Gateway.
Чтобы настроить дополнительные параметры DKIM-проверки для правила, выполните следующие действия:
В главном окне веб-интерфейса программы в дереве консоли управления выберите раздел Правила .
В списке правил по ссылке с названием правила откройте правило, для которого вы хотите настроить дополнительные параметры DKIM-проверки.
Выберите блок Проверка подлинности отправителей сообщений .
Включите переключатель рядом с названием блока параметров Проверка подлинности отправителей сообщений , если он выключен.
В блоке параметров DKIM-проверка подлинности отправителей выполните одно из следующих действий:
Установите флажок рядом с названием параметра Считать отсутствие DKIM-подписи нарушением подлинности отправителя , если вы хотите, чтобы Kaspersky Secure Mail Gateway считал отсутствие DKIM-подписи к сообщению, обнаруженное при DKIM-проверке, нарушением подлинности отправителя сообщения.
Снимите флажок рядом с названием параметра Считать отсутствие DKIM-подписи нарушением подлинности отправителя , если вы не хотите, чтобы Kaspersky Secure Mail Gateway считал отсутствие DKIM-подписи к сообщению, обнаруженное при DKIM-проверке, нарушением подлинности отправителя сообщения.
В нижней части рабочей области нажмите на кнопку Применить .
Источник
Подделка письма электронной почты почти от любого человека менее чем за 5 минут и способы защиты
Что такое аутентификация электронной почты?
На протяжении большей части последних 40 лет пользователям приходилось совершать прыжок веры каждый раз, когда они открывали электронную почту. Считаете ли вы, что письмо действительно приходит от того, кто указан в графе отправителя? Большинство легко ответит «да» и на самом деле очень удивится, узнав как легко подделать электронную почту почти от любого отправителя.
При создании Интернета изначально не было разработано никакой возможности проверить личность отправителя. Во время разработки основных протоколов электронной почты, затраты на вычислительную мощность, реализацию и простоту использования были уравновешены с риском мошенничества. Тяжело было предположить, что 84% всей электронной почты в будущем будут иметь вредоносную нагрузку и являться фишингом или спамом.
Результатом является то, что заголовки писем, включая поля «From: » и «Reply-to: », очень легко подделать. В некоторых случаях это так же просто, как набрать «john@company.com» в поле «From: ». Объединив это с неподозрительным содержанием, убедительной графикой и форматированием, вполне возможно обмануть людей, подумавших, что сообщение в их почтовом ящике действительно пришло от банка, ФНС, руководителя или президента США.
Приняв во внимание повсеместное распространение электронной почты, вы осознаете основу нашего нынешнего кризиса информационной безопасности. Слабость в электронной почте привела к массе фишинговых атак, направленных на то, чтобы заставить людей нажимать на вредоносные ссылки, загружать и открывать вредоносные файлы, отправлять форму W-2 (аналог 2-НДФЛ в США) или переводить средства на счета преступников.
Совсем недавно Coupa, компания из Кремниевой долины, была в центре внимания после отправки данных о заработной плате всех 625 сотрудников мошеннику. В прошлом году одна из крупнейших компаний Европы Leoni AG потеряла 45 миллионов долларов, когда сотрудник ошибочно перечислил деньги на учетную запись мошенника по причине фальшивой электронной почты. По оценкам ФБР, фишинговые атаки типа «компрометация деловой переписки» (BEC — Business Email Compromise), обходятся компаниям США в 3 миллиарда долларов в год.
На databreaches.net был составлен список фактов фишинга формы W-2. Работа над списком в этом году указывает на то, что количество случаев с 2016 года растет и на данный момент он состоит из 204 отчетов. По списку можно понять, что известны случаи кражи данных тысяч сотрудников и такой вид мошенничества является очень распространенным.
Как злоумышленник может подделать незащищенную электронную почту от почти любого человека менее чем за 5 минут
На самом деле, поддельный адрес в поле «от» — это основа и начальная стадия большинства атак. Почему стоит беспокоиться о фальсификации электронной почты с условного «company.com», когда возможно просто зарегистрировать похожий поддельный домен (например, c0mpany.com) и использовать его? Или создать учетную запись Gmail (randomaddress1347356@gmail.com), присвоить ей дружеское имя, которое выглядит как имя генерального директора компании? Потому что, на самом деле, подделать отправку письма с адреса реального человека даже проще, чем регистрировать поддельный домен или создать учетную запись Gmail.
Три простых способа
В интернете без труда можно найдите сайты, которые позволяют отправлять фейковые письма. Их десятки, вот лишь пара примеров: spoofbox.com и anonymailer.net. Многие из них бесплатны, некоторые стоят денег, позиционируются эти сервисы как законные, а основной целью использования предполагается розыгрыш друзей.
Алгоритм использования прост. Требуется лишь ввести адрес электронной почты получателя в поле «Кому:», поместить любой желаемый адрес электронной почты в поле «От:» и после создания сообщения подтвердить отправку. По условия пользовательского соглашения ответственность за ущерб полностью лежит на клиентах сервиса.
Следующий способ — это отправка с помощью командной строки UNIX. Если у вас есть компьютер с настроенной почтовой службой, достаточно ввести эту команду:
В итоге получается сообщение, в котором в поле «От» будет содержаться «any@anydomain.com». Введя строку темы и остальную часть сообщения, после нажатия Ctrl+D сообщение отправится получателю. Работостпособность этой идеи зависит от того, как настроена ваша система. Тем не менее, она работает во многих случаях.
Используя PHP, вы можете создать электронное письмо с помощью нескольких строчек очень простого кода:
Фактически, это строки кода, используемые в качестве примера в онлайн-руководстве для функции отправки почты mail() с дополнительными шапками/header.
Эти инструменты спуфинга сильно упрощены. Чтобы сделать сообщения более реалистичными, потребуется немного больше работы и, конечно, навыки социальной инженерии. Но основная техническая составляющая очень проста. Единственное, что действительно предотвращает спуфинг — аутентификация электронной почты с помощью совместного использования SPF-записи, DKIM-подписи и DMARC. Далее мы расскажем, как работают и чем отличаются эти технологии. Они не являются чем-то новым, однако, к счастью для мошенников, большинство доменов в Интернете еще не защищены. Например, только около 4% доменов .gov используют аутентификацию. Что касательно других 96%? Злоумышленники могут отправлять электронные письма под видом исходящих с почтовых ящиков этих доменов в любой момент.
Согласно источнику, одно из четырех писем с доменов .gov является мошенническим. Домены justice.gov, House.gov, Senate.gov, Whitehouse.gov, а также democrats.org, dnc.org, gop.com, rnc.org. и DonaldJTrump.com — все они могут быть легко использованы для спуфинга почтовыми мошенниками.
Способы защиты от спуфинга
Описанная выше простота использования уязвимости электронной почты без аутентификации и широкое использование этих методов как начальная стадия для крупнейших кибер-атак, акцентирует внимание IT-сообщества на необходимости использования технологий проверки подлинности почты. Внедряя аутентификацию электронной почты, вы можете гарантировать, что любой пользователь — сотрудник, клиент или партнер, получающий электронное письмо, сможет определить отправлено ли электронное письмо легитимным представителем компании. Кроме того, вы можете получить прозрачность и контроль того, кто отправляет электронную почту от вашего имени.
Важность этого резко возросла благодаря быстрому росту облачных сервисов (SaaS), более 10 000 из которых отправляют электронную почту от имени своих клиентов по теме продаж, маркетинга, поддержки клиентов, HR, бухгалтерского учета, юридических и прочих услуг. Благодаря принудительной аутентификации, вы можете заблокировать всех, кто пытается отправить письмо от вашего имени, — спамеров, фишеров и даже «серых» отправителей, которые могут быть легитимными, но не указаны вами в списке разрешенных.
Стандарты аутентефикации электронной почты позволяют почтовому серверу проверять, что электронное письмо с вашим доменом в поле «От:» было разрешено отправлять от вашего имени. До попадания сообщения в папку «Входящие» получателя, почтовый сервер может проверить:
Используя SPF-запись, имеет ли отправляющий сервер право использовать доменное имя (или имена), указанное в заголовках сообщения?
Если к сообщению прикреплена криптографическая DKIM-подпись, с помощью открытой версии ключа в записи DNS домена можно расшифровать заголовки входящих сообщений и узнать, действительно ли сообщение исходит от заявленного отправителя.
Благодаря настройке DMARC владельцы доменов могут создавать правила обработки писем, которые поступили с доменов, не прошедших авторизацию и проверять совпадают ли заголовки друг с другом (например, поля From: и Reply-to:). Правила включают инструкции о том, что должен сделать принимающий сервер с сообщениями, не прошедшими проверку подлинности, например, не пропускать их, помещать в папку со спамом или помечать их как потенциально опасные. Проверка подлинности по электронной почте дает владельцу домена глобальный контроль над тем, что происходит с сообщениями, отправленными от их имени кем угодно и кому угодно. Например, если вы представляете домен-отправитель почты и публикуете DMARC-запись с запросом информации, то вы будете получать от всех доменов-получателей, которые тоже поддерживают DMARC, статистику обо всех почтовых письмах, которые приходят с обратным адресом от вашего домена. Статистика приходит в XML и содержит IP-адрес каждого отправителя, который подписывается вашим доменом, количество сообщений с каждого IP-адреса, результат обработки этих сообщений в соответствии с правилами DMARC, результаты SPF и результаты DKIM
Почему необходимо совместное использование этих технологий?
В упрощенном смысле SPF позволяет создавать белый список для IP-адресов. Если почтовый сервер с IP-адресом, который отсутствует в вашем списке, пытается отправить электронное письмо с использованием вашего домена, тест проверки подлинности SPF не будет пройден. Однако, большая проблема с SPF заключается в том, что используется домен, указанный в поле Return-Path для проверки подлинности, а не поле From, который люди действительно читают.
Хуже того, злоумышленники, занимающиеся фишингом, могут настроить SPF-запись для своих собственных доменов. Затем они могут отправлять электронные письма, которые, как будет казаться, поступают от компании или бренда, которым доверяют, но домен этой компании будет отображаться в поле «От», а домен мошенника в Return-Path. Такие письма пройдут проверку подлинности SPF. Дополнительное использование DMARC, решает эту проблему, позволяя владельцу домена требовать «выравнивания», что означает, что обратные и исходящие адреса должны быть одинаковыми.
SPF-записи представляют собой текст, но синтаксис довольно сложный. Легко можно сделать опечатки, которые трудно обнаружить. При этом, они сделают SPF-запись бесполезной. Анализ SPF-записей всех 62 спонсоров конференции RSA 2017 года показал, что только 58 опубликовали SPF, при этом у 17 спонсоров конференции по кибербезопасности были ошибки в записи. Компании, которые не имеют большого опыта в IT-области, часто находят SPF еще более сложным.
Также и DKIM не особенно эффективен против мошенничества без использования DMARC. Чтобы остановить фишинг, самым важным адресом является домен в поле «От». Однако, проверка только DKIM-подписи нечего не говорит по поводу домена в этом поле. Используемый для подписи сообщения домен может полностью отличаться от домена, указанного в поле «От». Другими словами, хакеры могут создавать сообщения, которые подписываются через DKIM, используя контролируемый ими домен, но в поле «От» будет находится email вашего банка. Большинство людей не собираются копаться в заголовках всех входящих сообщений, чтобы убедиться, что данные DKIM-подписи являются легитимными. Также стоит учитывать большое количество законных почтовых служб, которые могут делать рассылки от имени отправителя и проблему сохранения секретности закрытого ключа, используемого для подписи сообщений.
Эти два ранних стандарта, хотя и важны, содержат важные пробелы. DMARC основывается на них и дополняет. DMARC значительно увеличивает доверие к электронной почте, которую вы отправляете, независимо от того, поступают ли письма от ваших собственных почтовых серверов или облачных сервисов, которым вы разрешаете отправлять электронную почту.
Основными вкладами DMARC являются:
настройка политики, которая сообщает получающим серверам электронной почты, что делать с электронными сообщениями, которые не аутентифицируются (ничего, карантин или отказ),
предоставление механизма отчетности.
Наличие политики и механизма обратной связи — вот что заставляет всё это работать.
Источник
Подделка писем. Как защищаться
Привет habr! В данной заметке решил затронуть тему защиты от поддельных писем (Email spoofing, Forged email). Речь пойдёт о письмах, в которых так или иначе подделывается информация об отправителях. Получатель видит письмо, отправленное якобы доверенным лицом, но на самом деле, письмо отправлено злоумышленником.
В последнее время всё чаще слышим о проблеме поддельных писем от наших заказчиков, да и просто от знакомых. Эта проблема не только актуальна, но, похоже, набирает обороты. Вот реальная история от знакомого, который был близок к тому, чтобы потерять сумму с четырьмя нулями в долларовом эквиваленте. В компании велась переписка на английском языке с зарубежной компанией о приобретении дорогостоящего специализированного оборудования. Сперва нюансы возникли на стороне нашего знакомого – потребовалось изменить реквизиты счёта отправителя (компанию-покупателя). Через некоторое время, после успешного согласования новых реквизитов, поставщик оборудования также сообщил о необходимости изменения реквизитов счёта получателя (компанию-продавца). Вот только письма об изменении данных получателя шли уже от злоумышленников, удачно подменявших адрес отправителя. На фоне некоторой общей суматохи, усугубляющейся ещё и тем, что обе стороны не являлись носителями языка переписки, заметить подмену писем было практически невозможно. Нельзя не отметить и тот факт, что злоумышленники старательно копировали стили, шрифты, подписи и фотографии в письмах. Как именно утекла информация о сделке – скорее всего была скомпрометирована почтовая переписка. За неделю до финального согласования сделки, о которой идет речь в этой статье, на почту знакомого пришло письмо с трояном, в виде счета-фактуры в *.exe архиве. На момент прихода письма антивирус не отловил зловреда, и тот, некоторое время успел “поработать” на компьютере, и даже подтянуть на подмогу пару своих собратьев.
Через несколько дней сигнатуры антивируса обновились и зловред с собратьями был удален, но к тому моменту в переписку уже вклинились, отправителя подделали, деньги ушли на чужой счёт. В данном примере подмена адреса отправителя была сделана крайне незамысловато. Реальные адреса мы не опубликуем, но приведём аналогичный пример.
Правильный адрес отправителя: best@bestofall.com Поддельный адрес отправителя: bestbestofall.com@spoofed.ru.
Почтовая учётная запись злоумышленника включала имя “best@bestofall” и фамилию “.com”. Часть переписки знакомый вел с мобильного устройства, почтовый клиент которого отображал в поле отправителя только имя и фамилию отправителя. А так делают все мобильные почтовые клиенты. Поэтому, входящее письмо в этом почтовом клиенте виделось как от best@bestofall «пробел» .com. Что очень похоже на оригинал. Ниже письмо от злоумышленника и под ним легитимное письмо в интерфейсе Яндекс.Почты:
В Outlook письмо от злоумышленника тоже выглядело достаточно похоже на оригинал, если внимательно не всматриваться, то тоже можно и не заметить подделку.
Всё всплыло, когда позвонил поставщик и спросил: «Веэр из май мани?». К счастью знакомого, из-за двойной смены реквизитов (получателя и отправителя) относительно изначального подписанного соглашения $$$$$ не были окончательно зачислены на счет злоумышленников, а зависли на транзитном счете банка-получателя, и их удалось вернуть.
Компании по всему миру терпят существенные убытки из-за Email-атак (источник). Так с октября 2013 по август 2015 совокупный убыток от компрометаций корпоративной электронной почты компаний по всему миру составил 1,2 миллиарда долларов США. А атаки с поддельными письмами находятся среди самых распространённых видов атак на корпоративные почтовые системы.
Особое внимание уделяется атакам, при которых злоумышленник отправляет поддельное письмо от имени высокопоставленного руководителя компании. В тексте письма злоумышленник требует незамедлительного ответа, или какой-либо срочной реакции от сотрудника или группы сотрудников компании. Например, может потребовать ответить на письмо отправкой какой-либо конфиденциальной информации. Это может привести к утечке данных. Или злоумышленник может потребовать срочный банковский перевод какой-либо крупной суммы. В описанных сценариях сотрудник ощущает давление: высокопоставленный руководитель требует безотлагательных действий. Этот факт повышает вероятность успеха атаки. Кроме того, атаке может предшествовать рекогносцировка методами социальной инженерии, чтобы наиболее эффективно сформировать текст письма и наиболее точно выявить целевую группу сотрудников, которые получат поддельное письмо. Данный подход также благотворно влияет на успех атаки.
Для того, чтобы разобраться с механизмом подделки адреса отправителя, вспомним структуру электронного письма, передаваемого по протоколу SMTP. Электронное письмо состоит из конверта (envelope), заголовков (headers) и тела письма (message body). Информация об отправителе содержится в конверте. Эта информация формируется SMTP-командой mail from и оказывает непосредственное влияние на процесс пересылки сообщения по мере прохождения почтовых cерверов Mail Transfer Agent (MTA). Однако, информация об отправителе также содержится в некоторых заголовках письма, таких как “From:”, “Return-Path:”, возможно “Reply-To:”. Заголовок “From:” не обязательно должен совпадать с тем, что написано в конверте письма и может представлять некоторое «дружеское имя» (friendly name, friendly from). Заголовок “Return-Path:” копирует отправителя из конверта. Заголовок “Reply-To:” содержит адрес для ответа. Заголовки значимы для почтового клиента (например, MS Outlook), по заголовкам заполняются соответствующие поля.
Рассмотрим пример SMTP-команд для отправки письма с поддельными заголовками “From:” и “Reply-To:”. Подключаемся к почтовому серверу Exchange с помощью telnet:
В данном примере мы отправляем с реального адреса attacker@spoofed.ru письмо, но в заголовке “From:” указываем имя и адрес руководителя компании, а в заголовке “Reply-to” адрес на mail.yandex, куда невнимательный сотрудник отправит конфиденциальную информацию. В итоге письмо в почтовом клиенте Outlook будет выглядеть следующим образом:
А если нажать «Ответить» автозаполнится адрес получателя:
Как видно из предыдущего примера, отправить поддельное письмо не составляет большого труда, если почтовый сервер не защищён. В худшем случае, значение в конверте письма mail from также может быть подменено на легитимное. Если тело письма составлено аккуратно и с применением результатов социальной инженерии, выявить поддельное письмо становится всё сложнее для конечного пользователя. Ситуация ещё более усугубляется для пользователей мобильных устройств. Концепция мобильности предполагает, что все действия выполняем быстро, «на ходу», да ещё и на небольшом экране, не обращая внимание на мелочи/несоответствия. Кстати говоря, в примере про сделку с зарубежной компанией у знакомого тоже не обошлось без фактора «мобильности». Часть переписки проходила с мобильного устройства, почтовый клиент в поле отправителя отображал только имя/фамилию отправителя, но скрывал полный почтовый адрес.
Не существует единого метода борьбы с подменёнными письмами. Защита от данного вида атак требует комплексного и многоуровневого подхода. Попробую выделить основные подходы борьбы с поддельными письмами:
Фильтрация на основе репутации сервера-отправителя.
Фильтрация на основе проверок DNS-записей сервера отправителя.
Фильтрация на основе проверок DNS-записей домена отправителя из конверта письма.
Фильтрация на основе проверок SPF-записей.
Фильтрация на основе DKIM.
Фильтрация на основе DMARC.
Создание гранулярных фильтров «вручную».
Из перечисленных методов первые три являются фильтрами грубой очистки, позволяющими бороться с массовыми рассылками спама, вредоносной почты, в том числе с подменённым отправителем. В данном случае злоумышленники используют эффект массовости, не осуществляя до атаки какой-либо специальной рекогносцировки и не стараясь точно подобрать контент под получателя. Например, письма от лица Сбербанка с просьбой сообщить какую-либо конфиденциальную информацию (логин/пароль от личного кабинета, номера карт, PIN-коды), рассылаемые на огромное число получателей. По принципу, кто-нибудь да клюнет.
Методы 4-6 помогают бороться с точными подменами отправителей, то есть ситуациями, когда в заголовках письма злоумышленник указывает с точностью до знака подменяемый отправитель. К методу 7 предстоит прибегать в случаях как в примере про переписку с зарубежной компанией в начале статьи, когда заголовок письма модифицируется таким образом, чтобы стать похожим на реального отправителя. Но при этом, заголовок в подменённом письме всё же отличается от заголовка реального отправителя, что позволяет обойти проверки методами 4-6.
Рассмотрим перечисленные методы более подробно.
1. Фильтрация на основе репутации сервера-отправителя. Если система защиты корпоративной почты обеспечивает качественную базу репутаций отправителей, мы можем фильтровать значительный процент распространителей спама и вредоносной корреспонденции любого вида уже на этапе установления TCP-сессии, не заглядывая ни в тело, ни в конверт письма. Такой подход существенно экономит ресурсы системы. Как только отправитель пытается установить TCP-сессию на порт 25, система защиты определяет репутацию для IP-адреса отправителя, и принимает решение.
Немного конкретики на примере Cisco ESA. Решение использует репутационную базу Sender Base. Мы видим, что репутационная фильтрация помогает останавливать в районе 80% вредоносных писем. Причём по многолетнему опыту внедрения и сопровождения данного решения могу сказать, что количество ложных срабатываний репутационной фильтрации Cisco ESA стремится к нулю.
Ниже сводка по нашей организации:
В зависимости от репутации отправителя Cisco ESA не только принимает решение отбросить письмо или пропустить далее, но и определяет дальнейший сценарий обработки письма. Для различных значений репутации мы можем применять различные политики:
2. Фильтрация на основе проверок DNS-записей сервера отправителя. Отправитель почтовых сообщений должен быть корректно зарегистрирован в DNS. Для отправителя должны существовать корректные PTR запись, А-запись. Отправитель должен корректно представляться в SMTP-команде HELO. При массовых рассылках спама и вредоносов злоумышленники постоянно меняют IP-адреса рассылающих серверов. Адреса меняются каждый день и даже чаще. Регистрировать необходимые записи в DNS сложно и даже невозможно. Поэтому, многие распространители спама и вредоносных сообщений пренебрегают данными требованиями, соответственно, появляется возможность их фильтровать по признакам DNS.
Рассмотрим DNS-проверки на примере Cisco ESA. При установлении TCP-сессии выполняются следующие проверки отправителя по DNS:
Проверка наличия PTR-записи. PTR запись должна быть единственной и возвращать корректное каноническое имя хоста отправителя.
Проверка наличия А-записи для имени хоста, найденного на первом шаге (по PTR-записи).
Проверка совпадения forward DNS lookup для А-записи из предыдущего шага с IP-адресом отправителя.
Если PTR-запись не существует, или найденная A-запись указывает на сторонний IP-адрес, с наибольшей долей вероятности мы принимаем сессию от нелегитимного отправителя. Для таких отправителей на Cisco ESA мы можем применять ограничивающие политики (отбрасываем письмо, отправляем в карантин, модифицируем заголовок, ограничиваем количество сессий и т.д.), в зависимости от поставленных требований.
Хочу обратить внимание, на данном этапе проверок ESA не контролирует легитимность отправителя, то есть не проверяет, имеет ли право отправитель слать письма от указанного домена. Более того, на данном этапе ни конверт письма, ни заголовки не просматриваются. Отрабатывает только проверка по IP-адресу. Например, если письма от домена mycompany.ru будут идти с «левого» IP-адреса с корректными A- и PTR-записями в DNS, например, «smtp.spamer.ru», проверка пройдёт успешно и письмо будет пропущено для дальнейшей обработки. Проверка легитимности отправителей осуществляется другими методами (см. далее SPF-записи, DKIM, DMARC).
3. Фильтрация на основе проверок DNS-записей домена отправителя из конверта письма. Информация в mail from также подлежит проверке по DNS. На примере Cisco ESA письмо может быть отброшено если:
Информация о домене отправителя отсутствует в конверте.
Имя домена не разрешается в DNS.
Имя домена не существует в DNS.
Данный тип проверок не особенно эффективен, отбрасываются письма с заведомо неверно сформированными конвертами.
4. Фильтрация на основе проверок SPF-записей. SPF – Sender Policy Framework – система проверки отправителей электронных сообщений. Проверка методом 2 «DNS-записи сервера отправителя» говорит только о том, что для IP-адреса отправителя существуют необходимые записи в DNS (PTR- и A-записи). Однако данные проверки не помогают определить, имеет ли право сервер отправитель слать письма от указанного домена. Стоит заметить, часто A-записи почтовых серверов содержат в себе имя домена компании, например, smtp01.mycompany.ru. Если этот же сервер используется для приёма почты, то эта же A-запись будет входить и в MX-запись. Можно предположить, что если письмо от mycompany.ru отправлено с сервера smtp01.mycompany.ru, то это письмо не поддельное, в противном случае, если письмо отправлено с smtp01.anythingelse.ru, письмо поддельно. Но на самом деле часто компании отправляют электронную корреспонденцию не напрямую со своих почтовых серверов, а через какие-либо дополнительные серверы MTA, например, через сервера своих провайдеров. В этом случае получаем, что письмо от домена mycompany.ru отправляется через серверы, к примеру, smtp01.provider.com, smtp02.provider.com и т.д. Канонические имена серверов отправителей не принадлежат домену компании mycompany.ru. Как на стороне получателя в данном случае понять, являются ли серверы-отправители легитимными или нет? Эту задачу решает система проверок SPF.
Задача решается опять же с помощью DNS. Для домена отправителя публикуется TXT-запись специального формата. В данной TXT-записи перечисляются IP-адреса, подсети или А-записи серверов, которые могут отправлять корреспонденцию, серверы, которые не являются легитимными отправителями. Благодаря системе SPF получатель может обратиться к DNS и уточнить, можно ли доверять серверу отправителю письма, или же сервер отправитель пытается выдать себя за кого-то другого.
На данный момент SPF-записи формируют далеко не все компании.
5. Фильтрация на основе DKIM. DKIM — DomainKeys Identified Mail – технология аутентификации электронных сообщений. Вернёмся к примеру из рассмотрения SPF-записей, когда компания mycompany.ru отправляет корреспонденцию наружу через провайдерские MTA smtp01.mycompany.ru и smtp02.provider.com. Для MTA существуют SPF-записи, поэтому письма от mycompany.ru, отправленные через эти серверы, успешно проходят проверку. Но что если данные MTA окажутся скомпрометированными, и злоумышленник также получит возможность отправлять поддельные письма через эти серверы? Как установить подлинность отправителя в этом случае? На помощь приходит аутентификация писем.
Для аутентификации используется ассиметричная криптография и хеш-функции. Закрытый ключ известен исключительно серверу отправителю. Открытый ключ публикуется опять же с помощью DNS в специальной TXT-записи. Сервер отправитель формирует отпечаток заголовков письма с помощью хэш-функции и подписывает его, используя закрытый ключ. Подписанный отпечаток вставляется в заголовок письма “DKIM-Signature:”. Теперь получатель письма с помощью открытого ключа может получить расшифрованный отпечаток и сравнить его с отпечатком полей полученного письма (хеш-функция известна). Если отпечатки совпадают, подписанные заголовки не были изменены при передаче, а отправитель письма, сформировавший заголовок “DKIM-Signature:”, является легитимным.
6. Фильтрация на основе DMARC. DMARC — Domain-based Message Authentication, Reporting and Conformance — техническая спецификация, описывающая как именно следует использовать результаты проверок SPF и DKIM. Политики DMARC публикуются как обычно с помощью DNS в TXT-записи. Политики DMARC указывают, что именно нужно делать с письмом на стороне получателя (доставить, отбросить, отправить в карантин), в зависимости от результатов проверок SPF и DKIM. Кроме того, DMARC обеспечивает обратную связь отправителя с его получателями. Отправитель может получать отчёты о всех электронных письмах, имеющих домен отправителя. Информация включает IP-адреса серверов-отправителей, количество сообщений, результат в соответствии с политиками DMARC, результаты проверок SPF и DKIM.
7. Создание гранулярных фильтров «вручную». К сожалению, далеко не все организации используют SPF, DKIM, DMARC при отправке электронной почты. Кроме того, в некоторых случаях проверки SPF, DKIM и DMARC могут пройти успешно, но письма оказываются всё равно подделанными (Cousin domain, Free Email Accounts). Для таких случаев помогают настройки фильтров. Возможности различных систем по созданию правил фильтрации разнятся. Фильтры настраиваются под различные сценарии проведения атаки и зависят от особенностей организации почтовых систем в компаниях. Например, в каких-то компаниях могут приходит из вне письма с доменом-отправителем этой же компании. Хотя в большинстве случаев такие письма должны пересылаться только в пределах периметра организации.
Мы более ориентированы на Cisco ESA, поэтому в заключении рассмотрим несколько примеров настройки фильтров на этом решении, а также интересную функциональность, появившуюся в релизе 10.0 (от июня 2016) программного обеспечения для Cisco ESA — Forged Email Detection. Данная функциональность как раз позволяет бороться с неточной подделкой отправителей, как в примере из начала статьи. Если заинтересовало, велкам в подкат.
Cisco ESA предлагает два типа фильтров: Content Filters и Message Filters. Первые настраиваются с помощью GUI и предлагают конечный (хотя и достаточно обширный) список условий и действий. Пример из GUI:
Если Content Filters не достаточны, чтобы описать условия попадания письма под действие фильтра, можно использовать Message Filters. Message Filters настраиваются из командной строки, используют регулярные выражения для описания условий и позволяют создавать сложные условия (например, If ( ( (A and B) and not C ) or D ) ). Message Filters обрабатывают письмо до Content Filters и позволяют создавать более гранулярные правила.
Рассмотрим несколько сценариев подделки отправителя и соответствующие фильтры Cisco ESA для борьбы с атакой.
Пример 1. Письма с доменом организации в отправителе не должны приходить из вне. Пример взят из с cisco.com: ссылка. Пример актуален в том случае, когда организация не готова публиковать свои SPF и Domain Keys в DNS. В данном примере используется следующий Message Filter:
В качестве действия могут быть выбраны и другие варианты: отправить в карантин, отбросить письмо и т.д.
Пример 2. В начале статьи мы рассматривали пример, когда mail from из конверта письма был не поддельный (attacker@spoofed.ru, то есть атакующий пишет свой верный адрес), однако в заголовке From указывался поддельный адрес (uskov@cbs.ru). При этом, ничто не мешает атакующему завести SPF и Domain Keys в DNS для домена spoofed.ru. Получаем, что поддельное письмо пройдёт проверки SPF и DKIM. Также, проверки SPF и DKIM будут успешно пройдены, если злоумышленник использует бесплатную почту (free mail accounts – gmail.com, mail.ru и т.д.).
Бороться с данной ситуацией можем, проверяя равенство значений в mail from и заголовке From. Сразу стоит оговориться, в общем случае RFC совершенно не требует, чтобы mail from равнялся From. Поэтому применять такой фильтр нужно только к некоторым отправителям.
У Cisco ESA на данный момент (ноябрь 2016) есть ограничение: нельзя сравнивать значения полей между собой, то есть нельзя просто написать if mail from != header (From). Задачу можно решить другим способом. Создаём словарь имён отправителей Spoofed_senders, в который будем заносить отправителей, подверженных подмене. В фильтре ставим условие: если mail from не содержит отправителя из словаря, а заголовок From содержит отправителя из словаря, выполнять действие. Можно отправить письмо в карантин или отбросить, но cisco рекомендует записать подделанное значение заголовка From в новый заголовок X-Original-From, а поле From вообще удалить. В этом случае Cisco ESA автоматически сформирует заголовок From из значения mail from. Пример такого фильтра:
Пример 3. Злоумышленники используют адреса, похожие на адреса отправителей, так называемые “Cousin domains” и “Cousin addresses”. Например, адрес uskov@cbs.ru заменяется на usk0v@cbc.ru. Для домена cbc.ru формируются SPF и Domain Keys в DNS, поэтому письма проходят соответствующие проверки SPF и DKIM успешно, а получатель письма видит знакомого отправителя. Бороться с такой подменой сложнее. Придётся заносить в словарь Spoofed_senders из предыдущего примера все похожие варианты имён отправителей и названий домена, что едва-ли возможно.
Для борьбы с данным видом подмены отправителей у Cisco ESA, начиная с релиза AsyncOS 10.0 (от июня 2016 года), появилась интересная функциональность “Forged Email Detection”. Сперва создаётся словарь имён отправителей (в примерах используется имя словаря FED), как и в предыдущем примере, в который будем заносить отправителей, подверженных подмене. Этот словарь формируется из имён отправителей, а не из имён почтовых ящиков. То есть нужно писать Olivia Smith вместо olivia.smith@example.com. Система Forged Email Detection будет сверять заголовок From с именами из словаря FED и выдавать вероятность (от 1 до 100), с которой отправителя можно считать подделанным.
Например, если в словаре есть “John Simons”, а в заголовке From фигурирует j0hn.sim0ns@example.com, система выдаст вероятность подделки 82. Если в заголовке From фигурирует john.simons@diff-example.com (то есть то же имя, но другой домен), система выдаст вероятность подделки 100.
Forged Email Detection настраивается через Content Filters или Message Filters. Ниже скриншот настройки Content Filter:
Необходимо указать имя словаря, и пороговое значение вероятности, после которого считаем отправителя подделанным. Для данного условия можно выбрать любое из доступных действий (отбросить, отправить в карантин, модифицировать тему письма и т.д.). Кроме того, появилось новое дополнительное действие для Forged Email Detection: заменить значение заголовка From на значение из mail from. Данное действие не предлагает каких-либо опций:
Атаки на электронную почту с подделкой отправителя, к сожалению, повседневная реальность. А последствия успешного проведения такого рода атаки могут быть крайне плачевными как для каждого человека в отдельности, так и для атакуемой организации в целом. Возможны существенные материальные потери и утечки конфиденциальной информации. Надеюсь, статья поможет разобраться как с анатомией атак поддельными письмами, так и со способами защиты. В примерах я оперировал решением Cisco ESA, однако, инструменты защиты, упомянутые в статье, реализуемы и на других системах защиты корпоративной электронной корреспонденции.
