Аутентификация и безопасность электронной почты — еще одна сложная тема, которая в прошлом часто неправильно настраивалась. Часто могли рассылаться фишинговые электронные письма от имени клиентов во время оценок. Office 365 несколько усложняет жизнь мошенникам и фишерам. Мы также благодарны за это. В статье рассматривается подмена электронной почты в Office 365.
Проверка подлинности электронной почты используется для проверки того, разрешено ли почтовому серверу отправлять электронные письма от имени отправителя. O365 поддерживает известную триаду SPF, DKIM и DMARC.
SPF позволяет указать, каким серверам разрешено отправлять электронные письма для вашего домена через запись DNS. Это будет проверено принимающим сервером. Он активен по умолчанию, и следующая политика будет настроена (для полностью размещенного O365) автоматически:
$ dig -t txt +short sender.com "v=spf1 include:spf.protection.outlook.com -all"
В свою очередь, благодаря механизму включения будут запрашиваться и учитываться следующие две записи:
$ dig -t txt +short spf.protection.outlook.com "v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/48 include:spfd.protection.outlook.com -all"
$ dig -t txt +short spfd.protection.outlook.com "v=spf1 ip4:51.4.72.0/24 ip4:51.5.72.0/24 ip4:51.5.80.0/27 ip4:20.47.149.138/32 ip4:51.4.80.0/27 ip6:2a01:4180:4051:0800::/64 ip6:2a01:4180:4050:0800::/64 ip6:2a01:4180:4051:0400::/64 ip6:2a01:4180:4050:0400::/64 -all"
Например, сообщение, не соответствующее политике SPF, будет иметь следующие заголовки в O365:
Authentication-Results: spf=fail (sender IP is 1.2.3.4) smtp.mailfrom=sender.com; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=sender.com;compauth=fail reason=001 Received-SPF: Fail (recipient.com: domain of sender.com does not designate 1.2.3.4 as permitted sender) receiver=recipient.com; client-ip=1.2.3.4; helo=mail.sender.com;
Такая почта (без каких-либо других отягчающих обстоятельств) не будет заблокирована О365 без политики DMARC. Сам по себе SPF не защищает от спуфинга электронной почты.
DKIM позволяет добавлять криптографическую подпись к исходящим письмам в заголовке сообщения. Открытый ключ также публикуется в записи DNS. Преимущество DKIM перед SPF заключается в том, что почту можно аутентифицировать, даже если она пересылается сервером ретрансляции.
Это не включено по умолчанию в O365, но поддерживается. Запись DKIM выглядит следующим образом:
$ dig -t txt +short selector1._domainkey.recipient.com selector1-recipient-com01i._domainkey.csnc365.onmicrosoft.com. "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0/Cy8ivpKumzFbBGkAxA2ydbglgrwrBss2FT0UmcsveVcE4xC61zuTmEZEWI2LR5HGLElHlgvv83I3C2YvJmuh4i2e+/TLVpLkFxpwYQTkzQT81MazCShfeUS29Zjwr5nBoGAKdAeuL1OOPwWeXznezFIPQxBhe0oWNyYpslD4bKx1bgO+sjvbPLm61ZzEopX" "8yQzvyU8XNJX9fLlUJbyo10FLeEU0S3Gs9IfIarucc0gktFMcVsEs72XEJoACkKagL0l5UYqN9CgUg+wuIScbJp6TskN8LQqX+CmHgPPJJLLfaYVuBpbo5oC9F1znN7xPliUDuKxznSDn1CQk49HQIDAQAB;"
Сообщение, содержащее подпись DKIM, будет иметь следующие заголовки в O365:
Authentication-Results: spf=pass (sender ip is 1.2.3.4) smtp.rcpttodomain=recipient.com smtp.mailfrom=sender.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=sender.com; dkim=pass (signature was verified) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sender.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yslZcsqEU3doAnzIBv+IiXhdA9VgmTBEY7w17G6s3Ag=; b=cD8dhgH352qUE0HvmLeYaWlC4E7xtUl26Sju41TUTDXIKSB/EUNhiOd2K46Q0VdISshkAFieExTbRfHksyl4hK6Ctuzaeaq5m+cPquzZba4Idt2WSNhwxCZyPsTRf7h7cj++t86lexZDfwrfra+8QJsAwInYAXVmC4tC4/lLGS13+FXWWh8/A/eVu+dGP5iuojZtmSAiKc51sRGya89Oup70MeNIz3NarhMbT/0b0o20XuLGWsdrLykMOhNOSoTRlxALyEEQuR2E7tRIA23OtClZt0i6YqtK1lG+VSs1RwNySGlptNnM+Nnf3NMggGkzCuvU4/FpvZ2yMUcucqe5lw==
DKIM добавляет дополнительный уровень безопасности к вашей электронной почте, вы должны настроить его, если это еще не сделано. Но как получатель узнает, что ему следует ожидать подписи DKIM?
DMARC помогает серверу-получателю решить, что делать в случае сбоя проверки SPF и/или DKIM. Эта функция также не включена по умолчанию для исходящих писем, но поддерживается в O365. Он также состоит из DNS-записи TXT. Например:
$ dig -t txt +short _dmarc.sender.com "v=DMARC1; p=reject; sp=reject; rua=mailto:security@sender.com!10m; ruf=mailto:security@sender.com!10m; rf=afrf; pct=100; ri=86400"
Что это значит? Это можно легко разобрать с помощью mtoolbox:
| Tag | TagValue | Name | Description |
|---|---|---|---|
| v | DMARC1 | Version | Identifies the record retrieved as a DMARC record. |
| p | reject | Policy | Policy to apply to email that fails the DMARC test. |
| sp | reject | Sub-domain Policy | Requested Mail Receiver policy for all subdomains. |
| rua | mailto:security@sender.com!10m | Receivers | Addresses to which aggregate feedback is to be sent. |
| ruf | mailto:security@sender.com!10m | Forensic Receivers | Addresses to which message-specific failure information is to be reported. |
| rf | afrf | Forensic Format | Format to be used for message-specific failure reports. |
| pct | 100 | Percentage | Percentage of messages from the Domain Owner’s mail stream to which the DMARC policy is to be applied. |
| ri | 86400 | Reporting Interval | Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. |
Например, сообщение, передающее SPF, но без DKIM, будет отклонено из-за того, что политика DMARC может иметь следующие заголовки в O365:
Authentication-Results: spf=pass (sender IP is 1.2.3.4) smtp.mailfrom=sender.com; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=sender.com;compauth=fail reason=000
Согласно документации:
oreject или o.reject: означает отклонение переопределения. В этом случае Microsoft 365 использует это действие, когда получает сообщение, не прошедшее проверку DMARC, от домена, запись DMARC TXT которого имеет политику p=reject. Вместо удаления или отклонения сообщения Microsoft 365 помечает его как спам.
Это электронное письмо попадет в папку нежелательной почты в O365, если обход не настроен. Кроме того, это даст компании понять, что кто-то пытается выдать себя за их имя. Например, вот один из таких отзывов:
<?xml version="1.0"?>
<feedback>
<version>0.1</version>
<report_metadata>
<org_name>AMAZON-SES</org_name>
<email>postmaster@amazonses.com</email>
<report_id>670e469b-4307-4c2a-870a-7a07869d7c02</report_id>
<date_range>
<begin>1660953600</begin>
<end>1661040000</end>
</date_range>
</report_metadata>
<policy_published>
<domain>compass-security.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
<fo>0</fo>
</policy_published>
<record>
<row>
<source_ip>52.100.1.208</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from></envelope_from>
<header_from>compass-security.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>compass-security.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>CHE01-GV0-obe.outbound.protection.outlook.com</domain>
<result>none</result>
</spf>
</auth_results>
</record>
</feedback>Спуфинг — это метод, часто используемый злоумышленниками, чтобы сообщение выглядело так, как будто оно исходит от кого-то другого. Приведенные выше методы аутентификации являются контрмерами против спуфинга электронной почты.
O365 по умолчанию включает так называемые политики «защиты от фишинга» (на самом деле это защита от спуфинга). Их нельзя отключить. Любая почта, распознанная как спуфинг (с использованием SPF, DKIM и DMARC), будет автоматически помещена в папку нежелательной почты, как показано в примере ниже:
Хотя отправителем является Дорис МакДжаннет, это письмо было отправлено с другого почтового сервера.
Дополнительные подсказки и индикаторы можно включить с помощью антифишинговой политики:
Настройка политики защиты от фишинга (на странице https://security.microsoft.com/antiphishing)
Это изменит способ отображения почты только в клиенте Outlook, а не в веб-почте следующим образом:
Так называемую функцию «поддельного интеллекта» не удалось протестировать, потому что даже поддельные сообщения, казалось, не запускали ее во время нашего тестирования.
В отличие от спуфинга, фишинг, спам и вредоносное ПО относятся к категориям атак, которые нельзя идентифицировать только по отправителю. В O365 также существуют политики защиты от нежелательной почты и вредоносных программ, которые активны по умолчанию. Их нельзя отключить, однако можно и, возможно, нужно сделать более строгими.
Есть несколько способов создать исключения в O365, чтобы пропускать поддельные письма.
Администраторы могут определять исключения из политик защиты от нежелательной почты. Можно подумать, что это отключает защиту от спама, но не защиту от спуфинга. Тем не менее, документация намекает, что:
Никогда не добавляйте собственные обслуживаемые домены или общие домены (например, microsoft.com или office.com) в список разрешенных доменов. Если этим доменам разрешено обходить фильтрацию нежелательной почты, злоумышленники могут легко отправлять вам сообщения, имитирующие эти доверенные домены.
Действительно, при добавлении домена «insecure.technology» в разрешенный домен любое поддельное письмо попадает в почтовый ящик:
В рекомендуемых настройках от Microsoft даже указано:
Добавлять домены в список разрешенных отправителей — очень плохая идея. Злоумышленники смогут отправить вам электронное письмо, которое в противном случае было бы отфильтровано.
Если это такая плохая идея, то почему это вообще возможно?
Теперь от администраторов O365 можно ожидать, что они читают документацию, но это совсем другая история для пользователей. При получении электронного письма в папку нежелательной почты пользователи могут добавить отправителя в список надежных отправителей.
Мы сталкиваемся с различным поведением в зависимости от того, является ли отправитель частью организации или нет.
Если отправитель является допустимым пользователем в вашей организации, O365 предлагает возможность добавить его в список надежных отправителей:
Опция меню для добавления отправителя в список надежных отправителей
Всплывающее окно с подтверждением действия
Это не имеет никакого эффекта, если это делается через веб-клиент (outlook.office.com), и адрес электронной почты или домен не будут добавлены в список (хотя и без каких-либо ошибок или предупреждений). Это баг или фича?
Однако, когда это делается в Outlook для рабочего стола, этот параметр учитывается:
Опция меню для добавления отправителя в список надежных отправителей
Всплывающее окно с подтверждением действия
Учитывается установка
Можно было бы ожидать, что все политики спуфинга по-прежнему применяются к безопасным отправителям, но это не так. Поддельные письма от надежных отправителей будут поступать во входящие:
Поддельная электронная почта внутри организации, полученная в папке «Входящие»
Недействительные пользователи в организации или действительные пользователи за пределами организации также могут быть добавлены в список надежных отправителей, будь то веб-версия или настольная версия Outlook:
Отправители, добавленные в список надежных отправителей в Outlook Web
То же самое относится к поддельным электронным письмам от надежных отправителей за пределами вашей организации, они будут получены в папке «Входящие»:
Поддельные электронные письма сторонних организаций, полученные в папке «Входящие»
Интересны следующие выводы из документации Microsoft:
В документации указано, что списков безопасных отправителей следует избегать.
Мы видели, что аутентификация по электронной почте эффективно защищает от фишинга, но ее необходимо настроить. Внедрите DKIM и DMARC для своих доменов уже сегодня.
Разрешенные отправители и безопасные отправители вовсе не безопасны. Они будут обходить систему безопасности O365 (за исключением сообщений, идентифицированных как вредоносное ПО или фишинг с высоким уровнем достоверности). списки отправителей.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…