Електронна пошта: фішинг із вашого домену — робочий план реагування на інцидент

Швидкий план діагностики

Ви шукаєте вузьке місце: чи листи надсилаються вашою інфраструктурою, чи хтось просто підроблює заголовки й користується публічним інтернетом? Не «перевіряйте все». Перевірте три речі, що відокремлюють ці світи.

По‑перше: чи якийсь лист пройшов через ваші вихідні системи?

• Перевірте логи MTA (Postfix/Exim/Exchange відстеження повідомлень). Якщо немає доказів, що спам виходив із ваших систем, швидше за все це підробка заголовків і політика, а не скомпрометований відправник.
• Перевірте трасування повідомлень провайдера (Microsoft 365 / Google Workspace). Якщо там є успішні вихідні надсилання, ймовірно відбулося крадіжка облікових даних або зловживання токеном API.

По‑друге: чи заголовки в одержувачів показують проходження аутентифікації?

• Якщо SPF=pass для вашого домену і DKIM=pass з вашим селектором, відправник, ймовірно, використав вашу реальну інфраструктуру або облікові дані.
• Якщо SPF/DKIM не проходять, але лист все одно доставляється, ваша політика DMARC занадто слабка (або відсутня), і отримувачі приймають власні рішення.

По‑третє: чи ваша доменна політика щось примушує виконувати?

• Перевірте запис DMARC: якщо це p=none, ви спостерігаєте, але не захищаєтеся.
• Перевірте вирівнювання (alignment): SPF/DKIM можуть «pass», але все одно провалити DMARC, якщо не вирівнюються з видимим From: доменом.

Правило швидкості: у перші 30 хвилин оптимізуйте дії на припинення додаткових надсилань і збереження доказів. Відновлення репутації може почекати, поки пожежу загасите.

Що насправді означає «фішинг із вашого домену»

Є три поширені реальності за тим самим страшним скриншотом.

1) Чиста підробка (ваш домен підроблено, не зламано)

Електронна пошта була створена в еру, коли модель безпеки була «бути чемним». Будь-хто може написати From: ceo@yourdomain.com у повідомленні. Якщо у вас немає суворої політики DMARC, багато систем-одержувачів все одно доставлять його — особливо людям, які навчені в корпоративному житті клікати на термінові повідомлення.

2) Компрометація облікового запису (хтось надсилає від вашого імені)

Ящик пошти був фішинґований, екран згоди OAuth підтверджено, витік токена API або обхід MFA із викраденням сесії. Атакуант надсилає з вашого реального тенанта, тому SPF і DKIM часто проходять. Це болісний сценарій, бо спам «автентичний».

3) Зловживання інфраструктурою (відкритий ретранслятор, відкритий SMTP submission, зловживання маркетинговим інструментом)

Менш поширено, але катастрофічно при підтвердженні: ваш MTA релеїть для всіх, забутий SMTP-логін усе ще валідний або третя сторона, дозволена в SPF, зловживається. Різниця тут у тому, що ви побачите це в логах.

Добра інцидент-реагування — це здебільшого класифікація. Як тільки ви знаєте, з якої з трьох категорій ситуація, виправлення стає нудним. Нудне — добре.

Цікаві факти й історичний контекст

• SMTP поставлявся без аутентифікації на початку 1980‑х; ідентичність вважалися такою, що не потребує перевірки. Підробка не була «помилкою», вона була поза оригінальною моделлю загроз.
• SPF виник як ідея авторизації відправника через DNS на початку 2000‑х, головно щоб зменшити спам із підроблених конвертів.
• DKIM походить із DomainKeys і Identified Internet Mail; він криптографічно підписує вміст листа, щоб отримувачі могли перевірити контроль над доменом.
• DMARC (приблизно 2012) зв’язав SPF і DKIM правила вирівнювання та додав регулятор політики (none/quarantine/reject) і звітування.
• DMARC-звітність створила нову галузь телеметрії: раптом можна було бачити, хто «надсилає від вашого імені», включно з давно забутими постачальниками.
• «Вирівнювання» — це підводний камінь: SPF може проходити для одного домену, тоді як видимий From: — інший; DMARC саме це й перевіряє.
• ARC (Authenticated Received Chain) існує тому, що пересилання й розсилки ламають аутентифікацію; ARC дозволяє посередникам засвідчувати те, що вони бачили.
• Крупні поштові провайдери поступово посилювали вимоги: з часом масові відправники були спрямовані на дотримання SPF/DKIM/DMARC і очікування простого відписатися одним кліком.
• Команди безпеки вчилися на гіркому досвіді: «ми маємо SPF» — це не захист. SPF — одна двері. Нападники обходять двері.

Дерево рішень: підробка заголовків vs компрометація vs реле

If outbound logs show the messages leaving your systems

• Ймовірно: скомпрометований поштовий ящик, скомпрометований SMTP-обліковий запис, зловживання інтеграцією постачальника.
• Робіть зараз: заблокуйте відправника, скасуйте токени, скиньте облікові дані, примусово вийміть сесії, дослідіть логи доступу, збережіть зразки.

If outbound logs show nothing, but recipients see your From:

• Ймовірно: підробка заголовків.
• Робіть зараз: посиліть DMARC, переконайтеся, що DKIM увімкнено для всіх легітимних джерел, і перевірте, що SPF включає тільки контрольовані вами відправники.

If logs show your MTA relayed to many domains you don’t do business with

• Ймовірно: відкритий реле або відкритий submission/auth.
• Робіть зараз: заблокуйте правила релею, обмежте порти submission, обертайте облікові дані, заблокуйте шкідливі IP і перевірте на наявність шкідливого ПЗ на хості.

Цитата, що варта розміщення на стіні (перефразована ідея): John Allspaw: надійність приходить від того, як системи поводяться під навантаженням, а не від того, наскільки приємно виглядають ваші діаграми.

Практичні завдання з командами (і як вирішувати)

Це реальні завдання, які можна виконати на Linux MTA-хості або джамп‑боксі з DNS‑інструментами. Кожне включає: команду, що означає її вивід, і рішення. Налаштуйте домени й імена хостів відповідно.

Завдання 1 — витягнути SPF-запис і перевірити його

cr0x@server:~$ dig +short TXT yourdomain.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all"

Що це означає: SPF авторизує 203.0.113.10 плюс Google і SendGrid. ~all — це «softfail», фактично ввічливе рекомендовання.

Рішення: перелікуйте всі include. Якщо не можете пояснити, навіщо він там, це не «тимчасово», це «невідомий ризик». Рухайтеся до -all тільки коли впевнені, що всі легітимні відправники покриті.

Завдання 2 — перевірити запис DMARC і рівень політики

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; adkim=r; aspf=r; pct=100"

Що це означає: Ви збираєте звіти, але не застосовуєте політику. Встановлено relaxed alignment.

Рішення: якщо вас активно підроблюють, p=none — це не план реагування. Швидко переходьте на p=quarantine, потім на p=reject після валідації легітимних джерел.

Завдання 3 — перевірити наявність DKIM селектора (поширена помилка: відсутній запис)

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: DKIM-публічний ключ існує для селектора s1.

Рішення: якщо відсутній, DKIM не пройде для пошти, підписаної цим селектором. Виправте DNS, потім перевірте підписування на стороні відправника.

Завдання 4 — подивитися Authentication-Results у зразку фішингу

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:|Received-SPF|DKIM-Signature" -n sample.eml | sed -n '1,120p'
12:From: "Accounts Payable" <ap@yourdomain.com>
18:Return-Path: <bounce@evil-example.net>
31:Authentication-Results: mx.example.net;
32: spf=fail (mx.example.net: domain of bounce@evil-example.net does not designate 198.51.100.77 as permitted sender) smtp.mailfrom=evil-example.net;
33: dkim=none (message not signed);
34: dmarc=fail (p=none) header.from=yourdomain.com

Що це означає: Не підписано, SPF не проходить для envelope-домену, DMARC не проходить, але політика — p=none, тож лист може потрапити до поштових скриньок.

Рішення: розцінюйте як підробку. Ваше завдання — зробити так, щоб провалений DMARC означав «не доставляти». Посиліть DMARC і переконайтеся, що легітимні відправники вирівнюються.

Завдання 5 — перевірити репутацію вихідних IP (швидко: чи є в списках)

cr0x@server:~$ dig +short 10.113.0.203.zen.spamhaus.org A
127.0.0.2

Що це означає: 203.0.113.10 виглядає як занесений у список (приклад відповіді). Деякі списки повертають різні loopback-коди з різних причин.

Рішення: якщо ви в списку й дійсно надсилали листи, локалізація й очищення важливіші за сперечання з списком. Якщо ви не надсилали, все одно потрібна DMARC‑енфорсмент і докази для запиту на вилучення.

Завдання 6 — пошук піків обсягу в логах Postfix

cr0x@server:~$ sudo zgrep -h "postfix/smtp" /var/log/mail.log* | awk '{print $6}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  4821 status=sent
   118 status=deferred
    22 status=bounced

Що це означає: Багато успішних відправлень. Це відповідає реальній вихідній активності, а не простій підробці.

Рішення: переключіться на «хто це надсилав» (аутентифікований користувач, IP джерела, логи submission). Якщо обсяг нульовий, перестаньте шукати MTA-привидів і виправляйте DMARC.

Завдання 7 — ідентифікувати аутентифікованих SMTP-користувачів (зловживання submission)

cr0x@server:~$ sudo zgrep -h "sasl_username=" /var/log/mail.log* | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  913 payroll@yourdomain.com
  112 notifications@yourdomain.com
   10 helpdesk@yourdomain.com

Що це означає: Конкретна поштова скринька домінує в надсиланнях через аутентифікований SMTP.

Рішення: негайно відключіть цей акаунт, обертайте пароль, відкличте сесії і перегляньте історію входів. Потім перевірте, чи це дійсний бізнес‑відправник (наприклад, payroll часто легітимний), чи атакувальник.

Завдання 8 — простежити один ID черги повідомлень, щоб побачити призначення й час

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*     2048 Mon Jan  4 08:55:12  ap@yourdomain.com
                                         user1@example.net
                                         user2@example.org

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            2048
sender: ap@yourdomain.com
*** MESSAGE CONTENTS ***
From: "Accounts Payable" <ap@yourdomain.com>
Subject: Updated remittance advice
Date: Mon, 04 Jan 2026 08:55:11 +0000

Що це означає: Це дійсно в вашій черзі. Це не підробка; ваша система надсилає це.

Рішення: локалізуйте, призупинивши вихід або утримуючи чергу за потреби, потім ізолюйте джерело акаунту або додатка.

Завдання 9 — тимчасово зупинити Postfix на вихід (важіль локалізації)

cr0x@server:~$ sudo postfix stop
postfix/postfix-script: stopping the Postfix mail system

Що це означає: Ви зупинили MTA. Це грубий, але ефективний підхід, якщо ваш сервер — джерело проблем.

Рішення: використовуйте тільки якщо підтверджено, що хост відправляє зловмисну пошту і ви можете допустити перебої. Інакше обмежте на краю (фаєрвол, ліміти, відключення акаунтів), щоб уникнути колатеральних збитків.

Завдання 10 — перевірити реле (класична «ні»)

cr0x@server:~$ swaks --to victim@example.net --from spoof@yourdomain.com --server mail.yourdomain.com
=== Trying mail.yourdomain.com:25...
=== Connected to mail.yourdomain.com.
<= 220 mail.yourdomain.com ESMTP Postfix
=> EHLO server
<= 250-mail.yourdomain.com
=> MAIL FROM:<spoof@yourdomain.com>
<= 250 2.1.0 Ok
=> RCPT TO:<victim@example.net>
<= 554 5.7.1 Relay access denied
=> QUIT
<= 221 2.0.0 Bye

Що це означає: Реле заборонено. Добре. Якби ви бачили 250 2.1.5 Ok для RCPT до зовнішнього домену без автентифікації, у вас був би відкритий реле.

Рішення: якщо воно відкрите, виправте обмеження реле негайно. Якщо закрите, перестаньте звинувачувати MTA за підроблені листи, які ви не надсилали.

Завдання 11 — перевірити експозицію TLS і портів submission

cr0x@server:~$ sudo ss -lntp | grep -E ":(25|465|587)\s"
LISTEN 0 100 0.0.0.0:25   0.0.0.0:* users:(("master",pid=1123,fd=13))
LISTEN 0 100 0.0.0.0:587  0.0.0.0:* users:(("master",pid=1123,fd=15))

Що це означає: SMTP і submission слухають на всіх інтерфейсах. Це може бути правильно, або може бути питанням: «навіщо ми так робимо?»

Рішення: якщо submission (587/465) доступний з інтернету, забезпечте сильну автентифікацію, ліміти й MFA для акаунтів. Якщо зовнішня подача не потрібна, обмежте через фаєрвол/VPN.

Завдання 12 — витягнути останні успішні логіни для підозрюваної скриньки (загальні логи IMAP)

cr0x@server:~$ sudo zgrep -h "imap-login: Login:" /var/log/mail.log* | grep "payroll@yourdomain.com" | tail -5
Jan  4 08:41:02 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22101, TLS
Jan  4 08:43:19 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22144, TLS

Що це означає: Повторювані входи з одного віддаленого IP. Може бути користувач або атакувальник.

Рішення: корелюйте з відомими місцями користувача/виходами VPN. Якщо підозріло, відкличте сесії й скиньте облікові дані. Не чекайте, поки HR «підтвердить, чи це був вони», поки спам продовжується.

Завдання 13 — підтвердити надходження агрегованих DMARC-звітів (здоров’я поштової скриньки)

cr0x@server:~$ sudo mailq | head
Mail queue is empty

Що це означає: Ваша локальна черга не заблокована, але це не доводить, що DMARC-звіти обробляються. Це «перевірка здоров’я», не переможний вигук.

Рішення: якщо ви залежите від звітів для видимості, переконайтеся, що поштовий ящик отримувача моніториться й має достатньо квоти. DMARC‑телеметрія, що тихо повертається, — це як пожежний сигнал із сівшими батарейками.

Завдання 14 — швидка перевірка розповсюдження DNS з різних резольверів

cr0x@server:~$ dig @1.1.1.1 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"
cr0x@server:~$ dig @8.8.8.8 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100"

Що це означає: Різні резольвери бачать різні записи — пропагація або split‑brain DNS. Поки це не зійдеться, ваше примусове застосування політики буде непослідовним.

Рішення: не оголошуйте «виправлено», поки інтернет все ще бачить стару політику. Дослідіть хостинг DNS, TTL і чи існують дублікати TXT‑записів.

Завдання 15 — перевірити на наявність кількох DMARC TXT записів (ламає оцінювання)

cr0x@server:~$ dig TXT _dmarc.yourdomain.com +noall +answer
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:old@yourdomain.com"

Що це означає: Два DMARC-записи. Багато отримувачів трактують це як permerror і можуть ігнорувати DMARC повністю.

Рішення: видаліть зайвий запис. Один DMARC‑запис на домен. Завжди.

Жарт №1: Аутентифікація електронної пошти — єдина система безпеки, де «pass» може все ще означати «fail», і всі кивнуть, ніби це нормально.

Три корпоративні міні-історії з війни

Міні‑історія 1: інцидент через хибне припущення

Середня фінансова компанія почала отримувати скарги: постачальники отримували листи «оновлені банківські реквізити» від домену компанії. IT‑команда зробила логічний перший крок: шукали в логах виходу. Нічого. Вони впевнено оголосили: «нас не зламали».

Вони були наполовину праві й повністю неправі. Зловмисники підроблювали видимий From: домен і використовували одноразову інфраструктуру відправлення. Компанія мала SPF і DKIM «налаштовані», але DMARC був p=none. Системи отримувачів мали вирішувати, чи доставляти, і багато хто вирішував «так», бо лист виглядав як бізнес‑повідомлення і не тригерив фільтри контенту.

Хибне припущення було тонким: «якщо ми не надсилали, ми не можемо зупинити це». Ви не можете заборонити підробляти ваше ім’я в SMTP‑заголовках, але ви можете зробити доставку таких підробок дорогою. DMARC існує саме для цього.

Після переходу на p=quarantine, а потім на p=reject, скарги різко впали. Декілька легітимних систем зламалися — старий постачальник інвойсінгу не підписував DKIM і надсилав з IP, відсутнього в SPF. Це прибирання було давно затребуване.

Постмортем був чесним: інцидент — не «компрометація пошти», а «слабкість політики». Виправлення не було дивом SOC; це був DNS TXT запис і тиждень інвентаризації постачальників.

Міні‑історія 2: оптимізація, що обернулася проти

SaaS‑компанія вирішила «спростити» пошту, направивши весь вихід через одну третю платформу. Один include в SPF, один DKIM селектор, одне місце для шаблонів. Міграція спрацювала, доставляння покращилося і всі заспокоїлися.

За шість місяців хвиля фішингу вдарила по їхнім клієнтам з ідеальною аутентифікацією. SPF пройшов. DKIM пройшов. DMARC пройшов. Повідомлення були відправлені через ту платформу, використовуючи валідні API‑ключі, що витекли з артефакту CI‑логів. Це не зовсім вина постачальника. Компанія ставилася до API‑ключів як до конфігурації, а не як до виробничих облікових даних.

Помилка оптимізації — централізація без обмежень. Вони зменшили різноманітність (кілька відправників), але також прибрали контроль радіусу ураження. Кожна пошта — скидання пароля, рахунок, маркетинг, підтримка — ділили один «бог‑ключ». Коли він витік, нападники отримали довіру їхнього найсильнішого відправника.

Відновлення зайняло дні: обертання ключів, поліпшення гігієни CI, розділення транзакційних і маркетингових потоків, впровадження ключів з обмеженою дією для кожної служби і додавання обмежень швидкості і виявлення аномалій. Іронія: «спрощення» перетворило неприємний інцидент на репутаційну подію.

Міні‑історія 3: нудна, але правильна практика, що врятувала день

Організація охорони здоров’я мала рутину, яку ніхто не любив: щомісячний перегляд DMARC‑звітів і реєстр авторизацій постачальників. Це було нудно. Це виробляло таблиці. Люди зітхали на нарадах.

Потім атакувальник спробував підробити їх під час регіонального збою, використавши «допоміжний» лист з проханням пацієнтам підтвердити персональні дані. DMARC організації вже був встановлений на p=reject зі строгим вирівнюванням для організаційного домену. Підроблені повідомлення провалили DMARC і були відхилені багатьма великими провайдерами до того, як потрапили в скриньки.

Вони все ж отримали кілька повідомлень — скриншотів із крайових поштових систем і декілька переадресувань — але масштабу інциденту не стало. Те, що вони зробили, перевірили DMARC‑агрегати і підтвердили шаблон атаки: багато провалів з нових діапазонів IP, нуль відповідної вихідної активності.

Нудна практика окупилася двічі: суворе застосування зменшило доставляння, а базова телеметрія дозволила швидко класифікувати подію як підробку, а не компрометацію. Це означало, що вони не витратили день на обертання кожного пароля «на авось».

Локалізація: припиніть «кровотечу» перш за все

Локалізація залежить від класифікації, але ментальність однакова: швидко зменшити пропускну здатність нападника, не знищивши докази, які знадобляться, щоб довести, що трапилось.

Якщо це компрометація скриньки (найтерміновіше)

• Відключіть акаунт або заблокуйте вхід. Не починайте з «запитайте користувача». Користувачі сплять або обороняються; нападники — ні.
• Відкличте сесії та токени. Скидання пароля без відкликання токенів — це театр.
• Видаліть шкідливі правила в поштовій скриньці (класика: автопереадресація, видалення при отриманні, «позначати як прочитане»).
• Зупиніть вихід від імені цієї ідентичності через транспортні правила/політику або тимчасово блокуйте зовнішніх отримувачів.
• Збережіть зразки: повні заголовки, raw MIME, часові мітки і ID повідомлень.

Якщо це зловживання стороннім відправником

• Обертайте API‑ключі, потім інвалідуйте старі. Якщо не можете інвалідувати старі ключі, вважайте, що не можете локалізувати проблему.
• Обмежуйте права (окремі ключі для транзакційної пошти, маркетингу, підтримки; обмеження для кожного додатка).
• Впровадьте ліміти швидкості на вихід за ключем і за IP, і налаштуйте оповіщення про аномалії.

Якщо це підробка заголовків

• Переведіть DMARC з none → quarantine швидко, якщо можете дозволити деякі помилкові спрацьовування. Використовуйте pct=25 для поступового нарощування якщо потрібно, але обмежте це по часу.
• Переконайтеся, що DKIM увімкнено для кожного легітимного джерела, особливо CRM/маркетингових систем.
• Очистьте include в SPF. Видаліть застарілих постачальників. SPF — це allowlist; ставтесь до нього як до правил фаєрвола.

Жарт №2: Якщо ваш SPF містить п’ять постачальників, про яких ви ніколи не чули, вітаємо — ви винайшли «аутсорсований відкритий реле».

Усунення й посилення: зробіть виправлення постійними

Локалізація купує час. Посилення запобігає повторенню того самого класу інцидентів наступного кварталу з іншим ім’ям відправника.

Закрийте доступи й шляхи аутентифікації

• MFA скрізь, але також: блокуйте застарілі протоколи автентифікації й паролі додатків якщо можете. Нападники люблять старі двері.
• Умовний доступ для ризикових входів: неможливі подорожі, новий пристрій, підозрілі діапазони IP.
• Керування OAuth‑додатками: обмежуйте згоду, переглядайте корпоративні додатки і моніторте нові гранти.

Зробіть політику аутентифікації такою, що виконується

• DMARC на p=reject для вашого організаційного домену, коли будете готові. Якщо не можете дійти до reject, ви не знаєте всіх своїх відправників.
• Використовуйте строгий alignment де можливо (adkim=s, aspf=s), щоб зменшити зловживання пірнувшими доменами. Relaxed — це етап, а не мета.
• Розділяйте домени: використовуйте субдомен для масового маркетингу і тримайте основний домен під суворим контролем. Маркетингові платформи можуть бути скомпрометовані; це не передбачення, це фізика.

Умисно вирішіть кейси з пересиланням і розсилками

Форвардери часто ламають SPF (бо IP форвардера не авторизований) і розсилки часто ламають DKIM (бо змінюють повідомлення). ARC допомагає, але не припускайте, що кожен отримувач його використовує однаково.

• Для критичних робочих процесів (рахунки, скидання пароля) уникайте відправлення тільки на списки/форвардери як єдиний канал доставки.
• Якщо ви керуєте серверами розсилок, налаштуйте їх так, щоб максимально зберігати аутентифікацію і використайте ARC де потрібно.

Побудуйте виявлення, що не залежить від удачі

• Оповіщайте про стрибки вхідного обсягу по користувачу/додатку/API‑ключу.
• Відстежуйте нові правила пересилання та нові правила вхідної пошти, що видаляють або перенаправляють.
• Збереження логів: переконайтеся, що маєте достатній історичний період, щоб відповісти на питання «коли це почалося?» без здогадок.

Відновлення репутації та доставляння

Після того як ви зупинили поточне зловживання, постає друга проблема: інтернет вважає вас “брудними”. Вийти з «кабінету покарань» здебільшого означає довести, що ви стабільні.

Стабілізуйте шаблони відправлення

• Тимчасово зменшіть обсяги, якщо можете (особливо маркетинг). Перші 48 годин після інциденту — час, коли фільтри менш поблажливі.
• Надсилайте чистий, очікуваний трафік: транзакційні повідомлення за участю зацікавлених одержувачів — ваш «здоровий пульс».
• Видаліть мертві адреси і припиніть повторні bounce’и; вони отруюють репутацію.

Виправте джерело, потім вирішуйте блок‑лісти

Запит на вилучення без виправлення причини — як витерти підлогу, поки труба продовжує фонтанувати. Деякі списки швидко повторно занесуть, і вдруге це вирішується повільніше.

Комунікуйте по‑дорослому

• Повідомте внутрішні команди, що сталося і що змінилося: DMARC політика, блокування акаунтів, обмеження постачальників.
• Надайте клієнтам коротку інструкцію: «Ми не запитуємо скидання пароля через посилання в листі; перевіряйте домен і індикатори автентичності.» Тримайте повідомлення фактичним.
• Не обіцяйте надто багато. Якщо скажете «нас не зламали», не перевіривши, ви ризикуєте довірою на припущеннях.

Чеклісти / покроковий план

0–30 хвилин: класифікація й локалізація

1. Зберіть щонайменше один повний зразок (raw .eml з заголовками). Скриншот — це не доказ.
2. Перевірте сліди/логи виходу: чи ваша система це надсилала?
3. Якщо так: відключіть підозрілі акаунти і відкличте токени; призупиніть вихід за потреби.
4. Якщо ні: підтвердіть DMARC‑політику; готуйтеся перейти на quarantine/reject.
5. Оголосіть канал інциденту з одним власником і одним приймаючим рішення. Хаос — справжній шкідник.

Того ж дня: виправіть умови, що дозволили інцидент

1. Перелічіть відправників: M365/GWS, маркетингова платформа, система квитків, моніторингові алерти, інвойсинг, HR.
2. Увімкніть DKIM‑підписування для кожного джерела де можливо.
3. Звужте SPF: видаліть застарілі include; переконайтеся, що ви не перевищуєте ліміт DNS‑запитів.
4. Встановіть DMARC на quarantine (за потреби рамуйте з pct). Почніть збирати звіти, якщо ще не робили.
5. Аудитуйте OAuth‑додатки і гранти згод; видаліть невідомі або ризикові інтеграції.
6. Пошукайте правила пересилання і підозрілі правила в скриньках.

Протягом тижня: зробіть це довготривалим

1. Переведіть DMARC на reject для організаційного домену, коли вирівнювання чисте.
2. Розділіть домени: транзакційні на суворо контрольованому домені; маркетинг на субдомені з чіткою політикою.
3. Впровадьте ліміти швидкості і оповіщення про аномалії на вихідні надсилання.
4. Напишіть runbook, який вам хотілося б мати. Потім проведіть tabletop‑вправу і подивіться, де він ламається (доброзичливо).

Поширені помилки: симптом → корінна причина → виправлення

«Ми маємо SPF, тож чому підробки все ще відбуваються?»

Симптом: отримувачі бачать ваш домен у From:, але Authentication-Results показують SPF fail і DKIM none/fail, однак повідомлення доставляються.

Корінна причина: SPF перевіряє лише envelope‑домен, і без примусового DMARC отримувачі можуть все ще доставляти підроблені From: листи.

Виправлення: впровадьте DMARC з quarantine/reject, забезпечте DKIM‑підписування і вирівняйте SPF/DKIM з видимим From: доменом.

«DMARC встановлено, але отримувачі кажуть permerror»

Симптом: DMARC у звітах показує permerror; підробка триває.

Корінна причина: кілька DMARC TXT записів, помилкові теги або надто великий запис.

Виправлення: забезпечте рівно один DMARC‑запис, перевірте синтаксис і тримайте його в межах DNS‑лімітів.

«DKIM проходить інколи, інколи ні»

Симптом: неконсистентна DKIM‑валідація залежно від отримувача або шляху.

Корінна причина: кілька систем відправлення з різними селекторами/ключами, проблеми пропагації DNS або посередники, що змінюють вміст (списки/футери).

Виправлення: стандартизуйте DKIM для кожного відправника, перевірте DNS для селекторів, припиніть модифікації тіла повідомлення і розгляньте ARC для відомих посередників.

«Ми встановили DMARC на reject і тепер легітимна пошта зникає»

Симптом: рахунки або відповіді служби підтримки зникають; користувачі скаржаться.

Корінна причина: легітимний сторонній відправник не включений у SPF і не підписує DKIM з вирівняним доменом.

Виправлення: правильно підключіть постачальника: авторизуйте IP або include, забезпечте DKIM‑підписування з вашим доменом (або використайте субдомен), потім повторно протестуйте перед підвищенням політики.

«Наш домен використовується, але наш поштовий сервер чистий»

Симптом: немає логів виходу; все одно багато скарг.

Корінна причина: чиста підробка у поєднанні зі слабким DMARC (p=none) і/або слабкими евристиками отримувачів.

Виправлення: переведіть DMARC на quarantine/reject, опублікуйте чітку політику і моніторте звіти щодо несанкціонованих джерел.

«Ми поміняли паролі, але спам продовжується»

Симптом: вихідний спам триває після скидання пароля.

Корінна причина: нападник використовує існуючі сесії, OAuth‑рефреш‑токени або API‑ключі, а не пароль.

Виправлення: відкличте сесії/токени, обертайте API‑ключі і відключіть підозрілі корпоративні додатки або гранти згоди.

«Ми заблокували порт 25 і проблема зупинилася… і наш бізнес‑емейл теж»

Симптом: дія локалізації спричинила масові відмови виходу.

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

Виправлення: надавайте перевагу цілеспрямованій локалізації: блокуйте конкретні акаунти/ключі, обмежуйте швидкість, звужуйте правила релею; зберігайте критичні шляхи доставки.

ЧаПи

1) Як нападники можуть надсилати «від мого домену», якщо нас не зламали?

Тому що заголовок From: — це просто текст, якщо отримувачі не примушують аутентифікацію. Підробка — проста; зупинити доставлення можна тільки через DMARC‑енфорсмент плюс правильне вирівнювання DKIM/SPF.

2) Чи слід одразу ставити DMARC на p=reject?

Якщо ви впевнені, що знаєте всіх легітимних відправників і вони вирівнюються — так. Якщо ні, спочатку переходьте на p=quarantine і використовуйте DMARC‑звіти, щоб знайти «страглерів». Обмежте фазу quarantine по часу.

3) У чому різниця між SPF «pass» і DMARC «pass»?

SPF «pass» означає, що IP відправника авторизований для envelope‑домену. DMARC «pass» означає, що SPF або DKIM пройшли і вирівнюються з видимим From: доменом. Вирівнювання — це ключ.

4) Чому переслані листи ламають SPF/DKIM?

SPF ламається, бо IP форвардера не авторизований для початкового домену. DKIM може ламається, якщо форвардер змінює повідомлення. Саме через це DMARC може створювати проблеми для розсилок і чому існує ARC.

5) Ми використовуємо кількох постачальників. Як уникнути монстра із SPF?

Надавайте перевагу DKIM‑підписуванню для кожного постачальника і тримайте SPF тісним. Кожен include: — це відносини довіри. Слідкуйте також за лімітом DNS‑запитів SPF; багато include може спричинити permerror SPF, що є самоіндукованим збоям.

6) Як визначити компрометацію OAuth‑токена?

Шукайте нові або незвичні згоди додатків, входи без відповідного скидання пароля і продовження надсилання після зміни пароля. Відклик токенів і видалення додатків — ключові дії локалізації.

7) Чи можна зупинити підробку без DMARC?

Ви не зупините підробку; ви можете лише впливати на поведінку отримувачів. Без DMARC‑енфорсменту ви сподіваєтесь, що евристики кожного провайдера врятують вас. Надія — не контроль.

8) Що слід надсилати клієнтам під час інциденту?

Коротко, фактологічно й дійсно: що ігнорувати, як перевіряти легітимні повідомлення, що ви ніколи не просите, і канал підтримки. Не спекулюйте щодо кореневої причини, поки її не перевірили.

9) Чому фішинг все одно потрапляв у деякі скриньки після встановлення p=reject?

Затримки пропагації, кешований DNS, отримувачі, що не виконують DMARC послідовно, або листи, що пересилаються так, що змінюють оцінку. Також перевірте на наявність кількох DMARC‑записів і налаштувань вирівнювання.

Висновок: наступні кроки, які ви реально можете зробити

Якщо ваш домен використовується для фішингу, не починайте з масштабної зміни паролів і молитви. Почніть із класифікації: чи пройшло це через ваші системи чи ні? Потім локалізуйте на потрібному шарі: ідентичність, ключ постачальника, правила реле MTA або політика.

Практичні наступні кроки на сьогодні:

1. Отримайте один raw‑зразок повідомлення з повними заголовками і збережіть його в надійному місці.
2. Перевірте докази виходу (трасування провайдера + логи MTA). Вирішіть: підробка vs компрометація vs реле.
3. Якщо підробка: перемістіть DMARC на quarantine зараз і плануйте reject після інвентаризації відправників.
4. Якщо компрометація: відключіть акаунт, відкличте токени/сесії, видаліть шкідливі правила, обертайте ключі.
5. Протягом тижня: очистьте SPF, забезпечте DKIM скрізь і підніміть DMARC до reject для організаційного домену.
6. Протягом місяця: розділіть домени, впровадьте оповіщення про аномалії виходу і відрепетируйте цей runbook хоч раз.

Мета не в досконалості. Мета — щоб наступного разу ваша інцидент‑бригада витримала 30 хвилин, а не 30 годин — і щоб ваш домен перестав бути костюмом, який може носити будь-хто.