Игра по осведомлённости о фишинге

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

← Назад к портфолио
Лучший счёт: 0Лучшая серия: 0Запуски: 0

Обучение безопасности email

Короткие понятные заметки про SPF, DKIM, DMARC, CompAuth, ARC, DNSSEC, MX, порты SMTP, STARTTLS, EHLO, SEG и базовую аутентификацию почты.

Аутентификация и доверие

SPF (Sender Policy Framework)

SPF - это DNS-список серверов, которым разрешено отправлять почту за домен.

  1. Получатель сверяет IP отправителя со списком и получает результат вроде pass или fail.
  2. SPF не защищает имя From, которое видят люди. Используйте его вместе с DMARC.
  3. Держите запись простой. Слишком много DNS-запросов может сломать проверку.

DKIM (DomainKeys Identified Mail)

DKIM - цифровая подпись: домен подписал письмо, и по пути его не меняли.

  1. Отправитель подписывает части письма. Получатель проверяет открытый ключ в DNS.
  2. Валидная подпись повышает доверие к подписывающему домену. Она сама по себе не доказывает честность видимого From.
  3. Ротируйте ключи и подписывайте важные заголовки вроде From и Subject.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC проверяет, что SPF или DKIM совпадают с доменом From, и говорит, что делать при сбое.

  1. Политика может только наблюдать (none), карантинировать или отклонять.
  2. Отчёты помогают находить спуфинг и ошибки настройки.
  3. Именно DMARC останавливает прямой спуфинг домена в фишинге и BEC.

BIMI (Brand Indicators for Message Identification)

BIMI может показать логотип бренда в поддерживающих ящиках при сильном DMARC.

  1. Нужен enforced DMARC и DNS-запись BIMI со ссылкой на логотип.
  2. Некоторые провайдеры также требуют verified mark certificate.
  3. BIMI - значок доверия. Он не заменяет SPF, DKIM или DMARC.

CompAuth (Microsoft composite authentication)

CompAuth - сводная оценка подлинности письма в Exchange Online от Microsoft.

  1. Его видно в Authentication-Results вместе с SPF, DKIM и DMARC.
  2. Учитывается больше одного сигнала, включая репутацию и alignment.
  3. При разборе фишинга в Microsoft 365 читайте CompAuth вместе с остальными auth-результатами.

ARC (Authenticated Received Chain)

ARC сохраняет прошлые auth-результаты, когда письмо пересылают или переписывают по пути.

  1. Списки и шлюзы часто ломают DKIM, меняя сообщение.
  2. ARC фиксирует то, что уже проверил предыдущий hop.
  3. Это помогает легитимной пересылке. Это не бесплатный пропуск для спуфинга.

DNSSEC (DNS Security Extensions)

DNSSEC подписывает ответы DNS, чтобы поддельные записи было сложнее подсунуть.

  1. Поддельный DNS может увести почту или подменить SPF и DKIM.
  2. Email auth зависит от честного DNS. DNSSEC усиливает эту основу.
  3. Записи нужно опубликовать, а резолверы должны реально валидировать.

MTA-STS (SMTP MTA Strict Transport Security)

MTA-STS требует TLS для входящей почты и запрещает откат к открытому тексту.

  1. Публикуют DNS-маркер и короткий HTTPS policy-файл.
  2. Поддерживающие отправители включают TLS до ваших MX.
  3. Следите за сертификатами MX, чтобы enforcement не стал аварией.

DANE / TLSA

DANE привязывает ожидаемый TLS-сертификат SMTP к DNS через TLSA.

  1. Нужен DNSSEC. Без валидации DNSSEC TLSA нельзя доверять.
  2. Где поддерживается, это усиливает SMTP TLS сильнее обычных web-сертификатов.
  3. Многие команды выбирают MTA-STS как более простой путь.

SMTP и транспорт

SMTP (Simple Mail Transfer Protocol)

SMTP - протокол, которым серверы передают почту по интернету.

  1. Обычно путь: клиент → submission → hop за hop → ящик.
  2. Сегодня путь фильтруют и чаще всего шифруют TLS.
  3. Понимание hop помогает читать Received при разборе фишинга.

Порты SMTP (25, 465, 587, 2525)

Разные порты SMTP для разных задач: relay между серверами и отправка пользователем.

  1. Порт 25 - доставка между серверами.
  2. Порт 587 - обычная authenticated submission. Порт 465 шифрует с первого байта.
  3. Порт 2525 - частый запасной вариант, если 587 закрыт. Следуйте гайду провайдера.

STARTTLS и implicit TLS

STARTTLS поднимает шифрование в уже открытой SMTP-сессии. Implicit TLS шифрует сразу при подключении.

  1. STARTTLS начинается открыто, затем переключается после EHLO.
  2. Без политики вроде MTA-STS или DANE атакующий может попытаться снять STARTTLS.
  3. Всегда проверяйте сертификаты. Шифрование само по себе не доказывает, что вы на нужном сервере.

EHLO и HELO

EHLO и HELO - приветствия SMTP. EHLO ещё показывает, что умеет сервер.

  1. Современные клиенты должны использовать EHLO.
  2. После STARTTLS клиенты обычно шлют EHLO снова.
  3. Странное приветствие - слабый сигнал. Его легко подделать, не верьте ему одному.

MAIL FROM и заголовок From

MAIL FROM - envelope-отправитель для bounce и SPF. From - то, что видит пользователь.

  1. Они могут отличаться и в легитимных системах, и в фишинге.
  2. SPF проверяет envelope. DMARC сверяет alignment с видимым доменом From.
  3. Учите смотреть мимо display name на реальный адрес.

VRFY и EXPN

VRFY спрашивает, существует ли ящик. EXPN раскрывает список рассылки. Оба помогают собирать адреса.

  1. Отключайте их на SMTP, доступном из интернета.
  2. Открытый VRFY наружу - находка по hardening.

Bounce и NDR

Bounce или NDR говорит, что доставка не удалась. Атакующие также подделывают такие письма ради кликов.

  1. Поддельный envelope может засыпать чужие домены bounce-спамом.
  2. SPF и DMARC уменьшают этот шум.
  3. Неожиданные письма "delivery failed" со ссылками считайте подозрительными.

DNS и маршрутизация

MX (Mail Exchanger)

MX-записи говорят, какие серверы принимают почту домена и в каком порядке.

  1. Отправители ищут MX, затем подключаются к этим хостам.
  2. Backup MX тоже нужно фильтровать, иначе он станет магнитом для спама.
  3. Свежий домен со слабым MX и без auth - подсказка для triage, не доказательство само по себе.

Записи A и AAAA

A и AAAA сопоставляют имена хостов с адресами IPv4 и IPv6.

  1. Имена MX должны резолвиться в адреса, иначе подключение не выйдет.
  2. Смена адреса требует обновления firewall, сертификата и SPF.
  3. Подозрительные IP в Received стоит сверить с репутацией.

PTR / обратный DNS (rDNS)

PTR отображает IP обратно в hostname. Многие получатели ждут чистый rDNS для SMTP.

  1. Плохой или отсутствующий rDNS бьёт по репутации доставки.
  2. Это гигиена, а не криптоконтроль вроде DKIM.

TXT-записи для email auth

DNS TXT хранят SPF, DMARC, ключи DKIM, BIMI, маркеры MTA-STS и похожие политики.

  1. DMARC живёт на _dmarc.example.com. Ключи DKIM - под selector._domainkey.
  2. Защищайте DNS-аккаунт. Устаревшие SPF include часто дают внезапные auth-сбои.

Стек безопасности email

SEG (Secure Email Gateway)

SEG фильтрует спам, фишинг, malware и утечки данных до попадания в ящик.

  1. Может стоять на MX или как облачный фильтр перед Microsoft 365 / Google Workspace.
  2. Частые функции: перепись URL, песочница вложений, AI-модели фишинга.
  3. Обучение плюс SEG сильнее, чем каждый по отдельности.

MTA (Mail Transfer Agent)

MTA - ПО, которое ретранслирует почту между серверами.

  1. Примеры: Postfix, Exim, Exchange Transport и облачные relay.
  2. Интернет-facing MTA должны закрывать open relay и защищать submission-логины.

MSA (Mail Submission Agent)

MSA принимает почту от приложений пользователя после логина, обычно на порту 587.

  1. Нужны сильная auth, TLS и rate limits, чтобы украденные аккаунты не спамили свободно.
  2. По возможности отделяйте submission от inbound MX.

MDA (Mail Delivery Agent)

MDA кладёт принятое письмо в итоговый ящик.

  1. Это последний hop в inbox, quarantine или archive.
  2. В инцидентах сопоставляйте delivery-логи с вердиктами SEG и auth-результатами.

Journaling и архивирование

Journaling копирует почту в compliance-архив для хранения и юридического поиска.

  1. Пользователи часто не видят journal-копию.
  2. Жёстко защищайте архивы: там чувствительная переписка и доказательства фишинга.

Фишинг, спуфинг и BEC

Фишинг обманывает людей. Спуфинг подделывает личность. BEC крадёт деньги через бизнес-процессы.

  1. Фишинг использует обманные ссылки, файлы или экраны входа.
  2. Спуфинг подделывает From или display name. DMARC блокирует много прямых domain spoof.
  3. BEC часто идёт из реально взломанного ящика, поэтому auth может пройти.

Заголовки и форензика

Authentication-Results

Authentication-Results записывает SPF, DKIM, DMARC, ARC и иногда CompAuth на границе приёма.

  1. Доверяйте результатам только своему mail edge или hop под вашим контролем.
  2. Атакующие могут вставить фальшивые auth-заголовки раньше по цепочке.
  3. Смотрите authserv-id: кто именно выставил результат.

Цепочка Received

Каждый hop добавляет строку Received. Обычно сверху самая новая.

  1. Начинайте со своего доверенного края. Нижние строки могут быть подделкой.
  2. Смотрите IP, hostname, TLS-заметки и странные задержки.
  3. Сверяйте подозрительные IP с SPF и репутацией.

Reply-To и From

Reply-To задаёт, куда уйдут ответы. From - личность в inbox.

  1. Фишеры часто маскируются под бренд в From и собирают ответы в другом месте.
  2. Доверенный From с чужим Reply-To доменом стоит перепроверить.
  3. Настоящие тикет-системы тоже используют Reply-To. Важен контекст.

Message-ID

Message-ID - уникальный ID одного письма. По нему склеивают логи разных систем.

  1. Фиксируйте его рано в инциденте.
  2. Странный или отсутствующий ID - слабый сигнал, не доказательство само по себе.