Если отправитель пренебрег шифрованием и послал сообщение в открытом виде то

Обновлено: 05.07.2024

Outlook поддерживает два варианта шифрования:

Шифрование S/MIME. Чтобы использовать шифрование S/MIME, отправитель и получатель должны иметь почтовое приложение, поддерживаю которое поддерживает стандарт S/MIME. Outlook поддерживает стандарт S/MIME.

Шифрование с помощью S/MIME

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

Если получатель указан в службе LDAP, например в глобальном списке адресов (GAL), используемом Microsoft Exchange Server, сертификат получателя публикуется в службе каталогов и доступен вам вместе с другими контактными данными.

Если получатель указан в LDAP службе каталогов, сертификат получателя публикуется в службе каталогов и доступен вам вместе с другими контактными данными.

В меню Сервис выберите пункт Учетные записи.

В области "Сертификат"выберите сертификат, который вы хотите использовать. Вы увидите только те сертификаты, которые вы добавили вchain для своей учетной записи пользователя Mac OSX, и сертификаты, которые действительны для цифровой подписи или шифрования. Дополнительные информацию о том, как добавлять сертификаты в keychain, см. в справке Mac.

Если вы подписаны на Microsoft 365, а также в сборке 16.19.18110915 и более новых,

Outlook для Mac 2019, 2016 и 2011

Если вы подписаны наMicrosoft 365, а также в сборке 16.19.18110915 и болееновых,

Outlook для Mac 2019, 2016 и 2011

Примечание: Функция Encrypt-Only не включена в этих версиях Outlook для Mac.

Прежде чем начать эту процедуру, необходимо добавить сертификат вchain-ключ на компьютере. Сведения о том, как запросить цифровой сертификат в сертификации, см. в справке Mac.

В меню Сервис выберите пункт Учетные записи.

Выполните любое из описанных ниже действий.

Если вы подписаны наMicrosoft 365, а также в сборке 16.19.18110402 и более новых,

В Outlook для Mac 2019, 2016 и 2011,

Gmail автоматически шифрует письма всегда, когда это возможно. Чтобы злоумышленники не смогли прочитать ваши письма, мы применяем протокол защиты транспортного уровня (TLS).

Чтобы эффективнее использовать сервисы Google на работе или в учебном заведении, оформите подписку Google Workspace на бесплатный пробный период.

Как проверить, защищено ли письмо

Как проверить письмо перед отправкой

Откройте Gmail на компьютере.
В левом верхнем углу экрана нажмите на значок "Написать письмо" .
Введите адреса получателей в поля "Кому", "Копия" и "Скрытая копия".
Посмотрите, нет ли значка "Без TLS" справа от адреса получателя.

Как проверить полученное письмо

Почему некоторые письма не шифруются

Чтобы шифрование TLS применялось, оно должно поддерживаться почтовым сервисом как отправителя, так и получателя. Подробнее о шифровании…

Some email providers send messages to Gmail addresses using TLS but can't receive encrypted messages.

If you reply to these messages, this icon could show up even though you're sending from Gmail.

ОБЩАЯ ДИСПОЗИЦИЯ

Злоумышленник находится в одном сегменте локальной сети Ethernet либо с Отправителем, либо с Получателем, либо с их почтовым сервером.
Отправитель и Получатель находятся в одной локальной сети, к которой злоумышленник имеет доступ через Internet.
Отправитель, Получатель и Злоумышленник находятся в различных подсетях, подключенных к Internet.

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ ШИРОКОВЕЩАТЕЛЬНОЙ ПРИРОДЫ ETHERNET

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

Единственная проблема, стоящая перед Злоумышленником, - как проникнуть в локальную сеть, да еще и оказаться в одном сегменте с жертвой? Чаще всего атакующий находится вне локальной сети, в лучшем случае имеет к ней доступ через Internet.

ПЕРЕХВАТ ПОЧТЫ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ ПОЧТОВОГО СЕРВЕРА

Многие расшифровщики помещают раскодированный текст в файл, указанный в заголовке UUE, допуская его перезапись без запроса подтверждения от пользователя. Если, как часто и бывает, почтовый сервер обладает наивысшими привилегиями, программа uudecode унаследует их при запуске, а Злоумышленник получает возможность перезаписи любого файла в системе.

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

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

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ СЕРВЕРОВ DNS

Не все адресаты находятся в рамках одной локальной сети, и в некоторых случаях с ними приходится связываться через Internet. Для установления соединения с удаленным узлом необходимо знать его IP-адрес, но в адресах электронной почты обычно используются не IP-адреса, а доменные имена почтовых серверов абонентов. Для того чтобы узнать адрес узла по его доменному имени, обычно программа и пользователи обращаются к службе DNS - распределенной базе данных, чаще всего функционирующей на базе протокола UDP.

Такой выбор объясняется тем, что протокол UDP работает без установления соединения и поэтому имеет лучшую производительность по сравнению с TCP. Расплатой за скорость становятся отсутствие контроля доставки пакетов, невозможность определения подлинности отправителя, неспособность противостоять сбоям и выявлять повторяющиеся пакеты.

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

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

Таким образом, Злоумышленник должен знать не только адреса Отправителя и Получателя, но и адрес сервера DNS Отправителя. А вот это уже представляет определенную проблему! В простейшем случае, когда при отправке используется предоставленный провайдером сервер DNS, выяснить его адрес можно без труда: достаточно осведомиться об этом у провайдера, а его, в свою очередь, можно определить по IP-адресу Отправителя.

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

Даже если Злоумышленник каким-то образом обойдет межсетевой экран, ему неизвестно точное время отправки письма — ведь не может же он бесконечно долго забрасывать Отправителя пакетами: такое поведение быстро обратит на себя внимание и демаскирует атакующего. Если Отправитель отвечает Получателю в абсолютно непредсказуемое время, и у Злоумышленника нет никаких, даже косвенных зацепок, позволяющих хотя бы приблизительно определить время пересылки письма, то ему придется изменить свою тактику и атаковать сам сервер DNS.

Такая возможность базируется на незащищенности взаимодействия серверов DNS друг с другом. Для этой цели используется все тот же уязвимый протокол UDP, не позволяющий установить подлинность отправителя. В общих чертах работа типичного сервера DNS выглядит так: получив запрос клиента, сервер просматривает содержимое своего локального кэша, и в случае отрицательного результата перенаправляет запрос на сервер DNS более высокого уровня. Для ускорения работы его ответ помещается в кэш, и в дальнейшем необходимость прибегать к посторонней помощи отпадает.

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

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

Во-вторых, популярные операционные системы содержат одну малоизвестную тонкость (о том, что не все из них умеют формировать запросы TCP к DNS, приходится вообще молчать): посылая запрос DNS, они не знают, по какому именно протоколу работает сервер, и предполагают, что по умолчанию выбран UDP (во всяком случае так настроены LINUX и Windows). Поэтому в названных случаях сеанс обмена начинается с посылки пакета UDP. При нормальном ходе вещей сервер может дать клиенту указание перейти на протокол TCP, но если Злоумышленник сумеет послать жертве подложный ответ раньше, чем это успеет сделать настоящий сервер, то клиент окажется введенным в заблуждение со всеми вытекающими отсюда последствиями.

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

Однако такой подход не лишен недостатков. Во-первых, Отправитель скорее всего не знает IP-адреса узла Получателя и будет вынужден обратиться за ним к DNS. А как было показано выше, сервер DNS мог быть атакован Злоумышленником, навязавшим ему ложный IP-адрес доменного имени почтового сервера Получателя.

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

Таким образом, лучшее, что можно предпринять, - это установить межсетевой экран, при необходимости перевести сервер DNS на протокол TCP, запретить клиенту DNS принимать пакеты UDP, установить максимально возможный размер кэша DNS для предотвращения его переполнения, не использовать генерирующих предсказуемые идентификаторы реализаций протокола TCP/IP и, по возможности, попросить выполнить эти требования администратора сервера DNS более высокого уровня.

НАРУШЕНИЕ РАБОТОСПОСОБНОСТИ РАБОЧЕЙ СТАНЦИИ ПОЛУЧАТЕЛЯ

Подобные шутки неприятны, но не более того. Куда большую опасность представляют сценарии для кражи секретных файлов с локального диска пользователя. Такие атаки становятся возможны благодаря многочисленным ошибкам в браузерах и виртуальных машинах Java. Даже пятая версия браузера Internet Explorer, последняя на момент написания статьи, запущенная под управлением Windows 2000, остается небезопасной. Вызов windows.open() в сочетании с функцией location() позволяет выполнить апплет Java в контексте локального документа, вследствие чего сценарий Злоумышленника получает доступ к содержимому файла.

Но на этом поток ошибок не заканчивается. Злоумышленник может вставить в письмо HTML файл подсказки Windows в формате chm с командами вызова исполняемых файлов, причем последние не обязательно должны находиться на локальном диске жертвы и вполне могут располагаться на компьютере взломщика - ведь благодаря встроенной в Windows поддержке общей межсетевой файловой системы (Common Internet File System, CIFS) различия между локальными и удаленными файлами нивелируются!

Опасность такой атаки заключается в том, что от Отправителя не требуется выполнения никаких дополнительных действий - Получателю достаточно просмотреть содержимое письма, и код Злоумышленника тут же получит управление. На фоне этой угрозы, нашумевший вирус I LOVE YOUR и все прочие насекомые, требующие для своего запуска открытия прикрепленного к письму вложения, выглядят детской игрушкой.

Недавно в Outlook Express 5.х была обнаружена серьезная ошибка, состоящая в том, что слишком длинное поле заголовка письма может переполнить буфер и передать управление коду злоумышленника еще на стадии получения письма с сервера, т. е. задолго до того, как его успеют проверить все существующие антивирусы! Нетрудно вообразить себе, как это могло бы быть использовано расторопными злоумышленниками (окажись они не такими ленивыми)! Впрочем, такая возможность у них еще есть - ведь не все пользователи заботятся об обновлении своих приложений, и уязвимый Outlook Express 5.x до сих пор широко распространен.

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

ПРОНИКНОВЕНИЕ В ПОЧТОВЫЙ ЯЩИК ПОЛУЧАТЕЛЯ

Предположим, Получатель правильно отнесся к выбору пароля и контрольной информации. Может ли он теперь чувствовать себя в безопасности? Если используемая почтовая служба не содержит ошибок реализации, позволяющих Злоумышленнику получить доступ к содержимому чужих ящиков (вообще-то системы без ошибок сегодня большая редкость), то на первый взгляд ему ничто не угрожает.

Между тем протокол POP3, используемый для доставки почты с сервера на компьютер клиента, передает имя пользователя и пароль в открытом, незашифрованном виде. Злоумышленнику достаточно перехватить сетевой трафик и извлечь соответствующие пакеты. Широковещательная среда локальных сетей Ethernet позволит осуществить эту операцию без труда, а межсегментная атака может быть реализована компрометацией DNS.

ВЫВОДЫ

Проанализировав сложившуюся ситуацию, приходится констатировать: конфиденциальность электронной переписки на сегодняшний день не гарантируется. Угроза исходит не только от спецслужб, наподобие СОРМ, но и от обычных подростков, вооруженных одним лишь модемом, простеньким персональным компьютером и базовыми техническими знаниями. Все атаки, описанные выше, не представляют никакого секрета и хорошо известны как специалистам по безопасности, так и злоумышленникам. Отсутствие громких прецедентов, связанных с хищением почты, не дает повода надевать розовые очки. В отличие от украшения страничек Web своим графити, перехват корреспонденции происходит незаметно, а жертвам невыгодно разглашать факт свершившейся атаки, особенно если злоумышленникам удалось похитить действительно ценную информацию.

В идеальном случае следовало бы посоветовать отказаться от пересылки почты на удаленные узлы Internet, а если такая операция неизбежна, - обязательно шифровать содержимое послания с помощью таких утилит, как PGP.

Строго говоря, любой протокол Internet, основанный на TCP/IP, принципиально уязвим для взлома, а переход на новые защищенные протоколы по некоторым причинам затягивается и происходит не так быстро, как хотелось бы.

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

ПЕРЕХВАТ С ИСПОЛЬЗОВАНИЕМ УЯЗВИМОСТИ ТРАНЗИТНЫХ УЗЛОВ

Выяснить маршрут письма можно несколькими способами. Если сервер Отправителя допускает отправку корреспонденции без аутентификации клиента (такие серверы, хотя и редко, но все же встречаются), то Злоумышленник сможет соединиться с ним и послать письмо самому себе. Все промежуточные узлы оставят свои адреса в его заголовке. Не факт, что к Получателю корреспонденция пересылаться тем же самым путем, но адреса первых одного-двух узлов обычно идентичны независимо от конечного получателя.

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

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

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

Привет habr! В данной заметке решил затронуть тему защиты от поддельных писем (Email spoofing, Forged email). Речь пойдёт о письмах, в которых так или иначе подделывается информация об отправителях. Получатель видит письмо, отправленное якобы доверенным лицом, но на самом деле, письмо отправлено злоумышленником.

В последнее время всё чаще слышим о проблеме поддельных писем от наших заказчиков, да и просто от знакомых. Эта проблема не только актуальна, но, похоже, набирает обороты. Вот реальная история от знакомого, который был близок к тому, чтобы потерять сумму с четырьмя нулями в долларовом эквиваленте. В компании велась переписка на английском языке с зарубежной компанией о приобретении дорогостоящего специализированного оборудования. Сперва нюансы возникли на стороне нашего знакомого – потребовалось изменить реквизиты счёта отправителя (компанию-покупателя). Через некоторое время, после успешного согласования новых реквизитов, поставщик оборудования также сообщил о необходимости изменения реквизитов счёта получателя (компанию-продавца). Вот только письма об изменении данных получателя шли уже от злоумышленников, удачно подменявших адрес отправителя. На фоне некоторой общей суматохи, усугубляющейся ещё и тем, что обе стороны не являлись носителями языка переписки, заметить подмену писем было практически невозможно. Нельзя не отметить и тот факт, что злоумышленники старательно копировали стили, шрифты, подписи и фотографии в письмах. Как именно утекла информация о сделке – скорее всего была скомпрометирована почтовая переписка. За неделю до финального согласования сделки, о которой идет речь в этой статье, на почту знакомого пришло письмо с трояном, в виде счета-фактуры в *.exe архиве. На момент прихода письма антивирус не отловил зловреда, и тот, некоторое время успел “поработать” на компьютере, и даже подтянуть на подмогу пару своих собратьев.

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

В Outlook письмо от злоумышленника тоже выглядело достаточно похоже на оригинал, если внимательно не всматриваться, то тоже можно и не заметить подделку.

Компании по всему миру терпят существенные убытки из-за Email-атак (источник). Так с октября 2013 по август 2015 совокупный убыток от компрометаций корпоративной электронной почты компаний по всему миру составил 1,2 миллиарда долларов США. А атаки с поддельными письмами находятся среди самых распространённых видов атак на корпоративные почтовые системы.

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

Рассмотрим пример SMTP-команд для отправки письма с поддельными заголовками “From:” и “Reply-To:”. Подключаемся к почтовому серверу Exchange с помощью telnet:

Не существует единого метода борьбы с подменёнными письмами. Защита от данного вида атак требует комплексного и многоуровневого подхода. Попробую выделить основные подходы борьбы с поддельными письмами:

Методы 4-6 помогают бороться с точными подменами отправителей, то есть ситуациями, когда в заголовках письма злоумышленник указывает с точностью до знака подменяемый отправитель.
К методу 7 предстоит прибегать в случаях как в примере про переписку с зарубежной компанией в начале статьи, когда заголовок письма модифицируется таким образом, чтобы стать похожим на реального отправителя. Но при этом, заголовок в подменённом письме всё же отличается от заголовка реального отправителя, что позволяет обойти проверки методами 4-6.

Рассмотрим перечисленные методы более подробно.

1. Фильтрация на основе репутации сервера-отправителя. Если система защиты корпоративной почты обеспечивает качественную базу репутаций отправителей, мы можем фильтровать значительный процент распространителей спама и вредоносной корреспонденции любого вида уже на этапе установления TCP-сессии, не заглядывая ни в тело, ни в конверт письма. Такой подход существенно экономит ресурсы системы. Как только отправитель пытается установить TCP-сессию на порт 25, система защиты определяет репутацию для IP-адреса отправителя, и принимает решение.

Немного конкретики на примере Cisco ESA. Решение использует репутационную базу Sender Base. Мы видим, что репутационная фильтрация помогает останавливать в районе 80% вредоносных писем. Причём по многолетнему опыту внедрения и сопровождения данного решения могу сказать, что количество ложных срабатываний репутационной фильтрации Cisco ESA стремится к нулю.

Ниже сводка по нашей организации:

В зависимости от репутации отправителя Cisco ESA не только принимает решение отбросить письмо или пропустить далее, но и определяет дальнейший сценарий обработки письма. Для различных значений репутации мы можем применять различные политики:

Рассмотрим DNS-проверки на примере Cisco ESA. При установлении TCP-сессии выполняются следующие проверки отправителя по DNS:

Проверка наличия PTR-записи. PTR запись должна быть единственной и возвращать корректное каноническое имя хоста отправителя.
Проверка наличия А-записи для имени хоста, найденного на первом шаге (по PTR-записи).
Проверка совпадения forward DNS lookup для А-записи из предыдущего шага с IP-адресом отправителя.

3. Фильтрация на основе проверок DNS-записей домена отправителя из конверта письма. Информация в mail from также подлежит проверке по DNS. На примере Cisco ESA письмо может быть отброшено если:

Информация о домене отправителя отсутствует в конверте.
Имя домена не разрешается в DNS.
Имя домена не существует в DNS.

Задача решается опять же с помощью DNS. Для домена отправителя публикуется TXT-запись специального формата. В данной TXT-записи перечисляются IP-адреса, подсети или А-записи серверов, которые могут отправлять корреспонденцию, серверы, которые не являются легитимными отправителями. Благодаря системе SPF получатель может обратиться к DNS и уточнить, можно ли доверять серверу отправителю письма, или же сервер отправитель пытается выдать себя за кого-то другого.

На данный момент SPF-записи формируют далеко не все компании.

Мы более ориентированы на 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 для борьбы с атакой.

Бороться с данной ситуацией можем, проверяя равенство значений в mail from и заголовке From. Сразу стоит оговориться, в общем случае RFC совершенно не требует, чтобы mail from равнялся From. Поэтому применять такой фильтр нужно только к некоторым отправителям.

Forged Email Detection настраивается через Content Filters или Message Filters. Ниже скриншот настройки Content Filter:

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

Читайте также: