📋 Оглавление
1. Введение: почему корпоративная почта остаётся главным вектором атак
2. Анатомия фишинговой атаки: как работает угроза изнутри
3. Базовые протоколы аутентификации: SPF, DKIM и DMARC как первый рубеж
4. Почтовые шлюзы и антиспам-фильтры: выбор и настройка
5. Анализ заголовков письма: как читать служебные метаданные
6. Продвинутые техники: sandbox, URL-деторонация и поведенческий анализ
7. Защита от целевого фишинга (BEC и spear phishing)
8. Настройка Microsoft 365 Defender: пошаговое руководство
9. Настройка Яндекс 360 и отечественных почтовых серверов
10. Обучение сотрудников: человеческий фактор и фишинг-симуляции
11. Реагирование на инцидент: что делать, если фишинг прошёл фильтр
12. Мониторинг и метрики: как измерить эффективность защиты
13. Типичные ошибки при настройке защиты от фишинга
14. FAQ: 12 горячих вопросов о фильтрации фишинга
15. Чек-лист: полная настройка защиты корпоративной почты от фишинга
16. Заключение и теги
1. Введение: почему корпоративная почта остаётся главным вектором атак
Корпоративная электронная почта — это не просто инструмент коммуникации. Для злоумышленников это самый результативный способ проникнуть в организацию. По данным отчёта Verizon DBIR 2024, более 94% вредоносного программного обеспечения доставляется именно через электронную почту. Фишинг занимает первое место среди методов первоначального проникновения в корпоративные сети уже восемь лет подряд.
Проблема не в том, что технологии защиты слабые. Проблема в том, что большинство компаний либо не настраивают их вовсе, либо настраивают по минимуму — и называют это «защитой от фишинга». Установить антивирус на почтовом сервере и считать задачу решённой — это примерно как закрыть входную дверь и оставить открытым окно на первом этаже.
В 2026 году ситуация стала сложнее. Генеративный ИИ позволяет злоумышленникам писать фишинговые письма без грамматических ошибок, на любом языке, с правильно оформленными реквизитами — те письма, которые раньше легко опознавались по корявому тексту, теперь неотличимы от легитимной корреспонденции. Атаки BEC (Business Email Compromise — компрометация деловой переписки) приносят злоумышленникам миллиарды рублей ежегодно, причём большинство жертв — средний и малый бизнес, не располагающий выделенными командами безопасности.
Что вы получите по итогам этого руководства: понимание полного цикла фишинговой атаки; практические настройки SPF, DKIM и DMARC для любого домена; алгоритм выбора и настройки почтового шлюза; пошаговые инструкции для Microsoft 365 и Яндекс 360; методологию обучения сотрудников с фишинг-симуляциями; алгоритм реагирования на инциденты; готовый чек-лист для проверки защищённости корпоративной почты.
Руководство рассчитано на IT-администраторов, специалистов по информационной безопасности и руководителей IT-подразделений. Все описанные инструменты — реально существующие, широко документированные. Никаких теоретических конструкций без практического применения.
> *💡 Руководство носит образовательный характер. Все описанные настройки применяются к почтовым системам, которыми вы владеете или за администрирование которых несёте ответственность.*
2. Анатомия фишинговой атаки: как работает угроза изнутри
Прежде чем строить защиту, необходимо понять, против чего именно вы защищаетесь. Фишинг — не монолитная угроза. Это семейство техник с различными механизмами доставки, целями и векторами обхода защиты. Настройка фильтрации фишинга в корпоративной почте без понимания этих механизмов похожа на установку сигнализации, не зная, какими путями проникают в дом.
Классификация фишинговых атак по типу
Массовый фишинг (phishing) — рассылка одинаковых или слегка персонализированных писем по максимально широкой базе адресов. Цель — получить учётные данные хотя бы от небольшого процента получателей. Характеристики: большой объём, слабая персонализация, стандартные приманки (банк, налоговая, доставка, техподдержка).
Целевой фишинг (spear phishing) — атака на конкретного человека или группу людей в организации. Злоумышленник заранее изучает цель: должность, имена коллег, текущие проекты, стиль переписки. Письмо содержит убедительные детали, которые сложно отличить от реальных рабочих коммуникаций. Эффективность в разы выше массового фишинга при значительно меньших затратах на масштаб.
Компрометация деловой переписки (BEC — Business Email Compromise) — высокоуровневая атака, при которой злоумышленник имитирует руководителя организации, финансового директора или ключевого контрагента с целью инициировать несанкционированный платёж или передачу конфиденциальных данных. BEC не требует вредоносных вложений или ссылок — достаточно убедительного текста.
Вишинг и смишинг — голосовой и SMS-фишинг, которые часто используются в связке с почтовыми атаками для повышения доверия («мы отправили вам письмо, сейчас позвоним для подтверждения»).
Жизненный цикл фишинговой атаки
Понимание жизненного цикла атаки позволяет выстраивать защиту на каждом этапе, а не только на уровне входящего письма.
| Этап | Что происходит | Точка защиты |
|---|---|---|
| 1. Разведка | Сбор email-адресов сотрудников, изучение структуры организации | Ограничение публичности корпоративных адресов |
| 2. Подготовка | Регистрация похожего домена, создание поддельной страницы | Мониторинг похожих доменов (typosquatting) |
| 3. Доставка | Отправка письма с вредоносной ссылкой или вложением | Почтовый шлюз, SPF/DKIM/DMARC |
| 4. Эксплуатация | Пользователь кликает ссылку или открывает вложение | Sandbox, URL-деторонация, антивирус |
| 5. Закрепление | Установка вредоносного ПО или кража учётных данных | EDR, мониторинг аномалий |
| 6. Монетизация | Кража данных, шифрование, несанкционированный платёж | SIEM, DLP, поведенческий анализ |
Новые техники фишинга в 2026 году
Атаки через QR-коды (QRishing) — вместо текстовых ссылок злоумышленники вставляют QR-код, который обходит большинство URL-фильтров почтовых шлюзов, так как фильтр видит только изображение, а не ссылку.
Фишинг через легитимные сервисы — письмо отправляется с реального аккаунта Google Docs, SharePoint или OneDrive. Домен отправителя легитимный, SPF проходит — фильтры не блокируют.
HTML-смаглинг — вредоносная нагрузка закодирована непосредственно в HTML-теле письма и собирается в вредоносный файл уже в браузере пользователя, минуя сканирование вложений.
> *⚠️ Атаки типа BEC не содержат вредоносного кода и не нарушают технические протоколы. Их нельзя заблокировать только техническими средствами — необходимо сочетание технической защиты и обучения сотрудников.*
3. Базовые протоколы аутентификации: SPF, DKIM и DMARC как первый рубеж
SPF, DKIM и DMARC — фундамент технической защиты корпоративной почты от фишинга. Без их правильной настройки все остальные меры будут значительно менее эффективными: злоумышленник сможет отправлять письма от имени вашего домена, а получатели не смогут отличить их от легитимных. Настройка этих трёх протоколов — обязательный первый шаг для любого IT-администратора.
SPF (Sender Policy Framework): кто имеет право отправлять почту от вашего имени
SPF — DNS-запись, которая указывает, какие IP-адреса и почтовые серверы имеют право отправлять письма от имени вашего домена. Получающий почтовый сервер сверяет IP отправителя с записью SPF: если совпадает — письмо прошло проверку, если нет — маркируется как подозрительное.
Пример SPF-записи для компании, использующей только Google Workspace для отправки почты:
dns
v=spf1 include:_spf.google.com ~all
Пример для компании с собственным почтовым сервером, Microsoft 365 и сервисом рассылок SendPulse:
dns
v=spf1 ip4:203.0.113.50 include:spf.protection.outlook.com include:sendpulse.ru ~all
Расшифровка механизмов SPF:
- `ip4:203.0.113.50` — разрешить отправку с конкретного IPv4-адреса
- `include:domain.com` — включить SPF-запись стороннего домена
- `~all` — «мягкий отказ»: письма с неавторизованных серверов маркировать, но не блокировать (SoftFail)
- `-all` — «жёсткий отказ»: письма с неавторизованных серверов блокировать (HardFail)
Важные ограничения: SPF не должен содержать более 10 DNS-запросов (lookup limit). Превышение этого лимита приводит к тому, что SPF-проверка завершается ошибкой и письма перестают проходить проверку. При сложной инфраструктуре используйте инструмент dmarcanalyzer.com для оптимизации записи.
DKIM (DomainKeys Identified Mail): криптографическая подпись каждого письма
DKIM добавляет к каждому исходящему письму цифровую подпись, созданную с помощью закрытого ключа вашего сервера. Получающий сервер проверяет подпись через открытый ключ в DNS — если совпадает, письмо не было изменено в транзите. Это защищает от атак «человек посередине» и подделки содержимого.
Проверка существующей DKIM-записи вашего домена:
bash
<h2 id="proverka-dkim-zapisi-cherez-komandnuyu-stroku">Проверка DKIM-записи через командную строку</h2>
<h2 id="selector-imya-vashego-klyucha-obychno-default-google-mail-selector1">selector — имя вашего ключа (обычно default, google, mail, selector1)</h2>
dig TXT selector._domainkey.yourdomain.com
<h2 id="ili-cherez-nslookup-na-windows">Или через nslookup на Windows</h2>
nslookup -type=TXT selector._domainkey.yourdomain.com
Онлайн-проверка: mxtoolbox.com/dkim — введите домен и селектор.
DMARC (Domain-based Message Authentication, Reporting & Conformance): политика и отчётность
DMARC — надстройка над SPF и DKIM, которая определяет, что делать с письмами, не прошедшими проверку. Именно DMARC замыкает цепочку аутентификации и даёт реальную защиту от спуфинга домена.
Базовая DMARC-запись для начала внедрения (режим мониторинга без блокировки):
dns
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1"
DMARC-запись с политикой карантина (письма, не прошедшие проверку, попадают в спам):
dns
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com"
DMARC-запись с политикой отклонения (самый жёсткий режим — блокировать):
dns
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com"
Рекомендуемая последовательность внедрения DMARC: начать с `p=none` для сбора данных → проанализировать отчёты в течение 2–4 недель → устранить легитимные источники, не прошедшие проверку → переключиться на `p=quarantine` с `pct=10` (10% писем) → постепенно поднимать до 100% → перейти на `p=reject`.
Инструменты проверки и анализа
| Инструмент | URL | Назначение |
|---|---|---|
| MXToolbox | mxtoolbox.com | Комплексная проверка SPF, DKIM, DMARC |
| Google Admin Toolbox | toolbox.googleapps.com | Анализ заголовков и MX-записей |
| DMARC Analyzer | dmarcanalyzer.com | Чтение и анализ DMARC-отчётов |
| Mail Tester | mail-tester.com | Полный тест письма на спам-оценку |
| Dmarcian | dmarcian.com | Визуализация DMARC-отчётов (есть бесплатный план) |
> *✅ Корректно настроенные SPF + DKIM + DMARC с политикой reject полностью блокируют спуфинг вашего домена — злоумышленник не сможет отправить письмо «от вас» так, чтобы оно прошло проверку у получателя. Это фундамент фильтрации фишинга в корпоративной почте.*
4. Почтовые шлюзы и антиспам-фильтры: выбор и настройка
Почтовый шлюз (email gateway) — это специализированное решение, которое встаёт перед вашим почтовым сервером и фильтрует весь входящий и исходящий трафик до того, как письма попадут в ящики пользователей. Это второй рубеж защиты от фишинга — после аутентификации отправителя и перед почтовым клиентом пользователя.
Ключевые функции почтового шлюза при фильтрации фишинга
Антиспам-движок анализирует содержимое письма, метаданные, репутацию отправителя и домена, соответствие шаблонам известных фишинговых кампаний. Современные решения используют машинное обучение для выявления аномалий в тексте и структуре письма.
Проверка URL-адресов во всех письмах происходит в режиме реального времени через репутационные базы данных (Google Safe Browsing, Symantec, Cisco Talos). Ссылки, ведущие на известные фишинговые сайты, блокируются до того, как пользователь их видит.
Сканирование вложений через антивирусные движки и подозрительные файлы открываются в изолированной среде (sandbox) для анализа поведения. Это перехватывает вредоносные документы с макросами, зашифрованные архивы с нагрузкой и эксплойты.
Фильтрация по репутации домена учитывает возраст домена (только что зарегистрированный домен подозрителен), историю отправки спама, геолокацию серверов и другие сигналы угрозы.
Сравнение популярных решений для корпоративной почты
| Решение | Тип | Для кого | Стоимость | Особенности |
|---|---|---|---|---|
| Microsoft Defender for Office 365 | Облако | Пользователи M365 | От $2/польз./мес. | Нативная интеграция, Safe Links, Safe Attachments |
| Kaspersky Security for Mail | On-premise / облако | Любой сервер | Лицензия | Высокий уровень обнаружения для RU-рынка |
| Positive Technologies PT Sandbox | On-premise | Крупный бизнес | Лицензия | Sandbox, поведенческий анализ, без передачи данных за рубеж |
| SpamAssassin | On-premise | Linux-серверы | Бесплатно (open source) | Гибкая настройка через правила, требует экспертизы |
| Rspamd | On-premise | Linux-серверы | Бесплатно (open source) | Высокая производительность, нейросетевой движок |
| Proofpoint Essentials | Облако | СМБ | От $2/польз./мес. | Продвинутая защита от BEC и spear phishing |
Настройка SpamAssassin: базовая конфигурация
SpamAssassin — классическое открытое решение для Linux-серверов. Используется как самостоятельно, так и в связке с Postfix или Exim.
bash
<h2 id="ustanovka-na-debian-ubuntu">Установка на Debian/Ubuntu</h2>
sudo apt install spamassassin spamc
<h2 id="vklyuchenie-sluzhby">Включение службы</h2>
sudo systemctl enable spamassassin
sudo systemctl start spamassassin
<h2 id="osnovnoy-fayl-konfiguratsii">Основной файл конфигурации</h2>
sudo nano /etc/spamassassin/local.cf
Ключевые параметры в `/etc/spamassassin/local.cf` для защиты от фишинга:
bash
<h2 id="porog-dlya-markirovki-pisma-kak-spam-po-umolchaniyu-5-0">Порог для маркировки письма как спам (по умолчанию 5.0)</h2>
required_score 5.0
<h2 id="dobavlyat-x-spam-status-zagolovok">Добавлять X-Spam-Status заголовок</h2>
report_safe 0
<h2 id="vklyuchit-proverku-reputatsii-cherez-dns-bloklisty">Включить проверку репутации через DNS-блоклисты</h2>
use_bayes 1
bayes_auto_learn 1
<h2 id="obnovlenie-pravil-zapuskat-cron-ezhednevno">Обновление правил (запускать cron ежедневно)</h2>
<h2 id="sa-update-no-gpg">sa-update --no-gpg</h2>Интеграция SpamAssassin с Postfix через spamd:
bash
<h2 id="v-etc-postfix-master-cf-dobavit-filtr">В /etc/postfix/master.cf добавить фильтр</h2>
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
<h2 id="v-etc-postfix-main-cf">В /etc/postfix/main.cf</h2>
content_filter = smtp-amavis:[127.0.0.1]:10024
Настройка Rspamd: современная альтернатива
Rspamd — более современное решение с нейросетевым движком, значительно быстрее SpamAssassin на больших объёмах почты:
bash
<h2 id="ustanovka-rspamd-na-debian-ubuntu">Установка Rspamd на Debian/Ubuntu</h2>
sudo apt install rspamd
<h2 id="veb-interfeys-dostupen-na-portu-11334-posle-zapuska">Веб-интерфейс доступен на порту 11334 после запуска</h2>
sudo systemctl start rspamd
<h2 id="generatsiya-parolya-dlya-veb-interfeysa">Генерация пароля для веб-интерфейса</h2>
rspamadm pw
<h2 id="dobavit-v-etc-rspamd-local-d-worker-controller-inc">Добавить в /etc/rspamd/local.d/worker-controller.inc</h2>
password = "$GENERATED_HASH";
> *⚠️ Слишком агрессивные настройки антиспам-фильтра приводят к ложным срабатываниям — блокировке легитимных писем. Начинайте с режима «только метка» (маркировать, не блокировать) и наблюдайте за результатами 1–2 недели перед переходом к автоматическому отклонению.*
5. Анализ заголовков письма: как читать служебные метаданные
Заголовки электронного письма — это служебная информация, которую большинство пользователей никогда не видит. Для IT-администратора умение читать заголовки — базовый навык расследования фишинговых инцидентов и диагностики проблем с доставкой. Именно заголовки позволяют восстановить полный путь письма от отправителя до получателя и выявить попытку подмены.
Как получить полные заголовки письма
В разных почтовых клиентах и сервисах путь к заголовкам различается:
- Gmail: открыть письмо → три точки (⋮) → «Показать оригинал»
- Outlook: открыть письмо → Файл → Свойства → «Заголовки Интернета»
- Яндекс.Почта: открыть письмо → «Ещё» → «Свойства письма»
- Roundcube: открыть письмо → «Дополнительно» → «Заголовки»
- Thunderbird: открыть письмо → Вид → Заголовки → Все
Ключевые заголовки при анализе фишингового письма
return
-Path: <bounce@suspicious-domain.com>
Received: from mail.suspicious-domain.com (203.0.113.100)
by mx.yourcompany.com with ESMTP
id ABC123; Mon, 15 Feb 2026 10:30:00 +0300
From: "CEO Иванов" <ceo@yourcompany.com>
Reply-To: real-attacker@gmail.com
Authentication-Results: mx.yourcompany.com;
spf=fail smtp.mailfrom=suspicious-domain.com;
dkim=none;
dmarc=fail
X-Spam-Score: 8.5
В этом примере сразу несколько красных флагов: `Return-Path` указывает на чужой домен; `Reply-To` ведёт на Gmail вместо корпоративного адреса; `spf=fail` — письмо отправлено с неавторизованного сервера; `dmarc=fail` — проверка не пройдена.
Инструменты анализа заголовков
| Инструмент | URL | Что делает |
|---|---|---|
| Google Admin Toolbox | toolbox.googleapps.com/apps/messageheader | Визуальный анализ пути письма, задержки |
| MXToolbox Email Header Analyzer | mxtoolbox.com/emailheaders | Детальный разбор с пояснениями |
| Mail Header Analyzer | mailheader.org | Простой парсер с визуализацией |
| Microsoft Remote Connectivity Analyzer | testconnectivity.microsoft.com | Тестирование и анализ для M365 |
Что искать при подозрении на фишинг
1. Расхождение From и Return-Path — адрес в поле «От» не совпадает с Return-Path. Это классический признак спуфинга отображаемого имени.
2. Поле Reply-To отличается от From — при ответе письмо уйдёт злоумышленнику, а не реальному отправителю. Чаще всего используется в атаках BEC.
3. SPF/DKIM/DMARC в Authentication-Results — проверьте статус. `fail` или `none` для известного домена — подозрительный сигнал.
4. Цепочка Received — читается снизу вверх. Первый Received — это сервер отправителя. Проверьте, соответствует ли IP домену отправителя.
5. Слишком короткая цепочка Received — письмо якобы пришло «напрямую» без промежуточных серверов, хотя должно было пройти через несколько хопов.
> *💡 Google Admin Toolbox Message Header Analyzer — самый удобный инструмент для быстрого анализа: покажите заголовки, и он визуально отобразит весь путь письма со временными метками на каждом этапе.*
6. Продвинутые техники: sandbox, URL-деторонация и поведенческий анализ
После базовой фильтрации остаются атаки, которые специально разработаны для обхода стандартных защитных механизмов. Продвинутые техники защиты от фишинга работают на уровне поведения, а не только сигнатур.
Sandbox: изолированное выполнение подозрительных вложений
Sandbox (изолированная среда) — это виртуальная машина, в которой вложение автоматически открывается и выполняется под наблюдением. Система фиксирует все действия файла: создание и удаление процессов, обращения к реестру Windows, сетевые подключения, изменения файловой системы. Если поведение соответствует вредоносному — файл блокируется и аналитик получает оповещение.
Открытые и бесплатные sandbox-решения:
bash
<h2 id="any-run-interaktivnyy-onlayn-sandbox">ANY.RUN — интерактивный онлайн-sandbox</h2>
<h2 id="url-app-any-run-zagruzit-podozritelnyy-fayl-ili-url">URL: app.any.run — загрузить подозрительный файл или URL</h2>
<h2 id="cuckoo-sandbox-open-source-reshenie-dlya-razvyortyvaniya-na-servere">Cuckoo Sandbox — open source решение для развёртывания на сервере</h2>
<h2 id="repozitoriy-github-com-cuckoosandbox-cuckoo">Репозиторий: github.com/cuckoosandbox/cuckoo</h2>
pip install cuckoo
cuckoo init
cuckoo web
<h2 id="virustotal-onlayn-analiz-cherez-70-antivirusnyh-dvizhkov-povedencheskiy-analiz">VirusTotal — онлайн-анализ через 70+ антивирусных движков + поведенческий анализ</h2>
<h2 id="url-virustotal-com-zagruzit-fayl-ili-vvesti-url-hesh">URL: virustotal.com — загрузить файл или ввести URL/хеш</h2>Коммерческие sandbox для корпоративной почты: Check Point SandBlast, Cisco Secure Email (ранее IronPort), Kaspersky Anti Targeted Attack, PT Sandbox (Positive Technologies).
URL-деторонация (URL Detonation): проверка ссылок перед кликом
URL-деторонация — механизм, при котором ссылки в письмах перезаписываются через прокси-сервис безопасности. Когда пользователь кликает по ссылке, прокси сначала проверяет URL в режиме реального времени (открывает страницу в sandbox, анализирует содержимое, проверяет репутацию), и только если URL безопасен — перенаправляет пользователя.
Эта технология защищает от «отложенного фишинга»: вредоносный сайт в момент получения письма может быть безопасным (и пройти статическую проверку), а через 2 часа — превратиться в фишинговую страницу.
В Microsoft 365 эта технология называется Safe Links и входит в Defender for Office 365 Plan 1:
microsoft
365 Admin Center →
Security → Policies & rules → Threat policies → Safe Links → Create policy
Поведенческий анализ и защита от BEC
Поведенческий анализ (Behavioral Analysis) выявляет аномалии в паттернах отправки и получения почты, которые невозможно обнаружить по сигнатурам или репутации домена. Система обучается на истории переписки и поднимает флаг при отклонениях.
Признаки BEC, которые должен выявлять поведенческий анализ:
- Письмо имитирует руководителя, но отправлено с другого домена (даже визуально похожего)
- Первый контакт от «знакомого» контрагента, который раньше никогда не писал с этого адреса
- Письмо с просьбой срочного платежа или нестандартного запроса информации
- Отправитель использует внешний адрес для имитации внутреннего сотрудника
Решения с поведенческим анализом: Microsoft Defender for Office 365 (встроен), Proofpoint Advanced Threat Protection, Abnormal Security (специализируется именно на BEC-защите).
Защита от QR-фишинга
QR-фишинг стал массовым явлением в 2024–2025 годах, поскольку большинство почтовых шлюзов не анализировали ссылки внутри изображений. Современные решения начали добавлять распознавание QR-кодов:
- Microsoft Defender for Office 365 с 2024 года умеет декодировать QR-коды в письмах
- Проверяйте, поддерживает ли ваш шлюз сканирование изображений на наличие QR-кодов
- Как временная мера: политика блокировки писем с QR-изображениями от внешних отправителей в высокорисковых подразделениях (бухгалтерия, финансы)
> *⚠️ Sandbox замедляет доставку письма — вложение должно быть проверено перед тем, как пользователь получит доступ. Предупредите сотрудников, что небольшая задержка доставки писем с вложениями является нормой, а не сбоем.*
7. Защита от целевого фишинга (BEC и spear phishing)
Целевой фишинг и BEC — наиболее опасные формы атак на корпоративную почту, поскольку они обходят большинство технических фильтров. Письмо технически корректно, домен отправителя легитимен, вредоносных вложений нет. Единственный способ защититься — сочетание продвинутых технических мер и хорошо обученных сотрудников.
Технические меры против BEC
Защита от спуфинга отображаемого имени — самая распространённая техника в BEC: адрес электронной почты чужой, но «имя» отправителя — это имя директора или финансиста компании. Большинство почтовых клиентов показывают только имя, не адрес.
Правило для Microsoft Exchange / M365, блокирующее письма, где «имя» отправителя совпадает с именем сотрудника из каталога, но адрес внешний:
powershell
<h2 id="powershell-dlya-exchange-online">PowerShell для Exchange Online</h2>
<h2 id="sozdanie-pravila-transporta-protiv-display-name-spoof">Создание правила транспорта против display name spoof</h2>
New-TransportRule -Name "Block Display Name Spoof - CEO" `
-FromScope NotInOrganization `
-SenderAddressLocation Header `
-HeaderMatchesPatterns "From","Иванов Иван" `
-RejectMessageEnhancedStatusCode "5.7.500" `
-RejectMessageReasonText "Suspicious display name from external sender"
Защита от typosquatting-доменов — злоумышленники регистрируют домены, похожие на ваш (yourcompany.com → yourcompanny.com, your-company.com). Мониторинг похожих доменов:
bash
<h2 id="urlcrazy-generator-variantov-typosquatting-domenov">URLCrazy — генератор вариантов typosquatting-доменов</h2>
<h2 id="ustanovka-na-kali-ubuntu">Установка на Kali / Ubuntu</h2>
sudo apt install urlcrazy
urlcrazy yourcompany.com | grep -i "Registered"
<h2 id="dnstwist-poisk-pohozhih-zaregistrirovannyh-domenov">dnstwist — поиск похожих зарегистрированных доменов</h2>
pip install dnstwist
dnstwist yourcompany.com --registered
Внешняя метка для писем — во всех входящих письмах от внешних отправителей автоматически добавляется баннер. Это один из самых эффективных механизмов предупреждения пользователей:
text
[⚠️ ВНЕШНЕЕ ПИСЬМО] Это письмо получено из-за пределов организации.
Будьте осторожны с вложениями и ссылками.
В Microsoft 365 настройка через транспортное правило: Add disclaimer → выбрать HTML-шаблон с предупреждением → применить к письмам, где Scope = «NotInOrganization».
Организационные меры против BEC
Верификация финансовых запросов — обязательное правило: любой запрос на изменение реквизитов оплаты или внеплановый перевод верифицируется по телефону с известным контактом, а не по данным из того же письма. Это правило должно быть зафиксировано в регламенте и донесено до всех сотрудников, имеющих доступ к платёжным системам.
Разделение полномочий — для проведения платежей выше определённой суммы требуется подтверждение от двух независимых авторизованных лиц. Даже если один сотрудник стал жертвой BEC, транзакция не пройдёт без второго одобрения.
Политика «паузы» — ввести правило: срочные запросы на финансовые операции от высокого руководства, полученные по почте в нерабочее время или с просьбой «никому не говорить», автоматически проходят дополнительную верификацию.
> *✅ По данным ФБР, в большинстве случаев успешных BEC-атак была проигнорирована хотя бы одна из этих организационных мер. Технические средства не могут остановить атаку, которая эксплуатирует бизнес-процессы, а не технические уязвимости.*
8. Настройка Microsoft 365 Defender: пошаговое руководство
Microsoft 365 — наиболее распространённая корпоративная почтовая платформа в мире. Встроенные инструменты безопасности при правильной настройке обеспечивают многоуровневую защиту от фишинга. По умолчанию многие функции либо отключены, либо настроены на минимальную агрессивность — их нужно активировать вручную.
Включение защиты Safe Links и Safe Attachments
Safe Links — перезапись всех URL через прокси Microsoft для проверки в реальном времени. Safe Attachments — открытие вложений в изолированной среде Microsoft до доставки пользователю.
Настройка через Microsoft 365 Defender Portal (security.microsoft.com):
1
. Перейти: security.microsoft.com
2. Policies & rules → Threat policies → Safe Attachments
3. Нажать + Create
4. Имя политики: "All Users - Safe Attachments"
5. Users and domains: применить ко всем доменам организации
6. Safe attachments unknown malware response: Block
7. Redirect: включить, указать почту администратора безопасности
8. Сохранить
9. Перейти: Threat policies → Safe Links
10. Нажать + Create
11. Имя: "All Users - Safe Links"
12. URL & click protection settings:
- On: URLs will be rewritten... ✅
- Do not track when users click... ❌ (отключить — нужна статистика)
- Let users click through... ❌ (запретить переход на заблокированные URL)
13. Сохранить
Настройка антифишинговой политики
security
.microsoft.com → Threat policies → Anti-phishing → + Create
Impersonation protection:
- Enable users to protect: добавить ФИО и адреса топ-менеджмента
- Enable domains to protect: ✅ Include domains I own, ✅ Include custom domains
Advanced phishing thresholds:
- Phishing email threshold: выбрать "3 - More aggressive"
Actions:
- If email is detected as impersonated user: Quarantine the message
- If domain is detected as impersonated: Quarantine the message
- If mailbox intelligence detects impersonated user: Move to Junk
- Show first contact safety tip: ✅ On
- Show (?) for unauthenticated senders for phishing: ✅ On
Настройка политики Anti-spam для дополнительной защиты
powershell
<h2 id="cherez-exchange-online-powershell">Через Exchange Online PowerShell</h2>
<h2 id="podklyuchenie-k-exchange-online">Подключение к Exchange Online</h2>
Install-Module ExchangeOnlineManagement
Connect-ExchangeOnline
<h2 id="prosmotr-tekuschih-politik-spama">Просмотр текущих политик спама</h2>
Get-HostedContentFilterPolicy | Format-List Name, SpamAction, HighConfidenceSpamAction
<h2 id="uzhestochenie-politiki-po-umolchaniyu">Ужесточение политики по умолчанию</h2>
Set-HostedContentFilterPolicy Default `
-SpamAction Quarantine `
-HighConfidenceSpamAction Quarantine `
-PhishSpamAction Quarantine `
-HighConfidencePhishAction Quarantine `
-BulkThreshold 4
Включение отчётности и мониторинга
security
.microsoft.com → Reports → Email & collaboration → Threat protection status
Настройка еженедельного отчёта по электронной почте: Reports → Email & Collaboration Reports → Schedule report → выбрать «Threat protection status» → указать email получателя → Weekly.
> *💡 После изменения настроек Safe Attachments задержка доставки писем с вложениями может составить до 5 минут. Проинформируйте об этом пользователей заранее, чтобы избежать обращений в поддержку.*
9. Настройка Яндекс 360 и отечественных почтовых серверов
С 2022 года многие российские компании перешли на отечественные почтовые платформы. Яндекс 360 for Business — наиболее распространённое решение. Принципы настройки SPF/DKIM/DMARC универсальны, но настройка шлюзов и специфических правил имеет свои особенности для каждой платформы.
Настройка SPF, DKIM и DMARC для домена на Яндекс 360
Добавление DNS-записей для домена, подключённого к Яндекс 360 for Business:
SPF-запись — добавить через панель управления DNS-регистратора или хостинга:
dns
Тип: TXT
Имя: @
Значение: v=spf1 include:_spf.yandex.net ~all
TTL: 3600
DKIM-запись — получить через Яндекс 360 Admin Console:
admin
.yandex.ru → Домены → [ваш домен] → Настройки почты → DKIM
Скопировать готовую TXT-запись и добавить в DNS
Обычный вид: mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
Проверка через Яндекс Postmaster:
postmaster
.yandex.ru → Добавить домен → пройти верификацию →
в разделе «Аутентификация» проверить статус SPF, DKIM, DMARC
Настройка Postfix + Rspamd для собственного почтового сервера
Для компаний, использующих собственный почтовый сервер на базе Linux (Postfix + Dovecot):
bash
<h2 id="bazovaya-nastroyka-rspamd-dlya-zaschity-ot-fishinga">Базовая настройка Rspamd для защиты от фишинга</h2>
<h2 id="fayl-etc-rspamd-local-d-phishing-conf">Файл: /etc/rspamd/local.d/phishing.conf</h2>
enabled = true;
<h2 id="blokirovka-pisem-gde-from-domen-otlichaetsya-ot-dkim-domena">Блокировка писем, где From-домен отличается от DKIM-домена</h2>
check_from_domain = true;
<h2 id="minimalnyy-ball-dlya-blokirovki-15-uverennyy-spam">Минимальный балл для блокировки (15 = уверенный спам)</h2>
<h2 id="nastraivaetsya-v-etc-rspamd-local-d-actions-conf">Настраивается в /etc/rspamd/local.d/actions.conf</h2>
<h2 id="etc-rspamd-local-d-actions-conf">/etc/rspamd/local.d/actions.conf</h2>
reject = 15;
add_header = 6;
greylist = 4;
Настройка интеграции Rspamd с Postfix:
bash
<h2 id="etc-postfix-main-cf-dobavit-filtratsiyu-cherez-rspamd">/etc/postfix/main.cf — добавить фильтрацию через Rspamd</h2>
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_default_action = accept
milter_protocol = 6
Защита от фишинга в корпоративных системах на базе RuPost и VK WorkMail
Для RuPost (Релap Group) и других отечественных решений принципы те же, но настройка производится через собственный веб-интерфейс администратора. Обязательные шаги для любой платформы:
1. Включить проверку SPF для входящих писем и маркировать/блокировать при провале
2. Включить проверку DKIM для входящих писем
3. Добавить заголовок предупреждения для всех внешних писем
4. Настроить блокировку исполняемых вложений (.exe, .js, .vbs, .bat, .cmd, .ps1)
5. Включить сканирование ссылок через интегрированный или внешний антивирусный движок
Бесплатные DNS-блок-листы для подключения к почтовому серверу
Списки заблокированных IP (DNSBL/RBL) — бесплатный способ отклонять почту от известных источников спама и фишинга на уровне SMTP-соединения, до получения тела письма:
bash
<h2 id="podklyuchenie-dnsbl-v-postfix">Подключение DNSBL в Postfix</h2>
<h2 id="etc-postfix-main-cf">/etc/postfix/main.cf</h2>
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
permit
> *⚠️ Перед включением DNSBL в режиме «reject» проверьте, не попал ли IP вашего исходящего почтового сервера в какой-либо из этих списков. Используйте mxtoolbox.com/blacklists для проверки.*
10. Обучение сотрудников: человеческий фактор и фишинг-симуляции
Технические средства фильтрации фишинга в корпоративной почте задерживают большинство атак — но не все. Атаки, прошедшие технические фильтры, встречаются с последней линией защиты: сотрудником. По данным исследований, 85% инцидентов информационной безопасности связаны с человеческим фактором. Необученный сотрудник сводит на нет даже самую продвинутую техническую защиту.
Что должен знать каждый сотрудник о фишинге
Минимальный набор знаний, который должен быть у каждого, кто использует корпоративную почту:
Признаки фишингового письма: несоответствие адреса отправителя и имени; орфографические ошибки в доменном имени; срочный тон с требованием немедленных действий; просьба авторизоваться или ввести данные; вложения от незнакомых отправителей.
Правила безопасной работы с почтой: не открывать вложения от неизвестных отправителей; не переходить по ссылкам в письмах, не проверив URL; при сомнении — позвонить отправителю по известному номеру, не используя контакты из подозрительного письма; сообщать о подозрительных письмах в IT-отдел.
Как проверить ссылку перед переходом: навести мышь на ссылку — в строке статуса браузера или почтового клиента отобразится реальный URL; скопировать URL и проверить на virustotal.com; обратить внимание на доменное имя — yourbank.com и yourbank.secure-login.com — разные домены.
Организация фишинг-симуляций
Фишинг-симуляция — контролируемая отправка учебных фишинговых писем собственным сотрудникам без их предупреждения. Цель — не наказать «попавшихся», а выявить уязвимые группы и провести целевое обучение.
Платформы для проведения фишинг-симуляций:
| Платформа | URL | Стоимость | Особенности |
|---|---|---|---|
| GoPhish | github.com/gophish/gophish | Бесплатно (open source) | Гибкая настройка, самостоятельный хостинг |
| KnowBe4 | knowbe4.com | Платно (от $18/польз./год) | Крупнейшая библиотека шаблонов, аналитика |
| Phishsim by Cybereason | cybereason.com | Платно | Интеграция с SIEM |
| Microsoft Attack Simulator | security.microsoft.com | Включён в M365 E5 / Plan 2 | Нативная интеграция с M365 |
Настройка GoPhish для запуска первой симуляции:
bash
<h2 id="skachat-gophish">Скачать GoPhish</h2>
wget https://github.com/gophish/gophish/releases/latest/download/gophish-linux-64bit.zip
unzip gophish-linux-64bit.zip
chmod +x gophish
<h2 id="zapustit-po-umolchaniyu-veb-interfeys-na-https-localhost-3333">Запустить (по умолчанию веб-интерфейс на https://localhost:3333)</h2>
./gophish
<h2 id="voyti-admin-parol-iz-konsoli-pri-pervom-zapuske">Войти: admin / пароль из консоли при первом запуске</h2>
<h2 id="sozdat-kampaniyu">Создать кампанию:</h2>
<h2 id="sending-profile-dobavit-smtp-server-dlya-rassylki">Sending Profile → добавить SMTP-сервер для рассылки</h2>
<h2 id="landing-pages-sozdat-poddelnuyu-stranitsu-vhoda">Landing Pages → создать поддельную страницу входа</h2>
<h2 id="email-templates-zagruzit-shablon-pisma">Email Templates → загрузить шаблон письма</h2>
<h2 id="users-groups-importirovat-spisok-sotrudnikov">Users & Groups → импортировать список сотрудников</h2>
<h2 id="campaigns-zapustit-kampaniyu">Campaigns → запустить кампанию</h2>Метрики фишинг-симуляций и целевые показатели
| Метрика | Значение | Комментарий |
|---|---|---|
| Open Rate (процент открытий) | >70% — нормально | Большинство сотрудников открывают почту |
| Click Rate (переходы по ссылке) | <10% — хороший результат | Цель программы — снизить ниже 5% |
| Credential Submission | <3% — приемлемо | Самый критичный показатель |
| Report Rate (сообщений в ИБ) | >20% — хороший результат | Чем выше, тем активнее культура безопасности |
> *⚠️ Обязательно согласуйте проведение фишинг-симуляций с HR и юридическим отделом до запуска. В ряде компаний и юрисдикций требуется уведомление сотрудников о возможности проверок в общем формате (без раскрытия конкретных дат).*
11. Реагирование на инцидент: что делать, если фишинг прошёл фильтр
Никакая система защиты не даёт стопроцентной гарантии. Фишинговое письмо может пройти все фильтры — особенно если атака целевая и тщательно подготовленная. Алгоритм реагирования на такой инцидент должен быть продуман и закреплён в документации заранее, а не выстраиваться в момент паники после атаки.
Немедленные действия при обнаружении фишингового письма
1. Не кликать — если письмо ещё не открыто или ссылка не нажата: сообщить в IT/ИБ, не открывать, не пересылать коллегам «для ознакомления».
2. Изолировать — если ссылка уже нажата или вложение открыто: немедленно отключить компьютер от сети (вытащить кабель или отключить Wi-Fi), НЕ выключать компьютер (данные в оперативной памяти важны для расследования).
3. Сообщить — немедленно уведомить ответственного за информационную безопасность, зафиксировать время и обстоятельства инцидента.
4. Сохранить письмо — не удалять письмо до завершения расследования. Попросить пользователя не предпринимать никаких действий с компьютером.
Алгоритм расследования инцидента
1
. Получить полные заголовки письма
└─ Определить реальный IP отправителя
└─ Проверить IP на mxtoolbox.com/blacklists
└─ Проверить домен отправителя через virustotal.com
2. Проверить, кто ещё получил это письмо
└─ Exchange: Get-MessageTrace -SenderAddress [адрес] -StartDate [дата]
└─ Google Workspace: Admin Console → Reports → Email Log Search
3. Отозвать письмо у всех получателей
└─ Exchange Online: New-ComplianceSearch → New-ComplianceSearchAction -Purge
└─ Google Workspace: Admin Console → Reports → Email Log Search → Delete
4. Проверить, не прошли ли учётные данные
└─ Проверить Active Directory: Get-ADUser -Filter * -Properties LastLogonDate
└─ Проверить Azure AD Sign-In Logs на аномальные входы
└─ Если пароль введён: немедленная смена пароля + проверка активных сессий
5. Занести домен/IP в блок-лист
└─ Exchange: New-TenantAllowBlockListItems -ListType Sender -Block
└─ Postfix: добавить в /etc/postfix/sender_access → postmap
Команды PowerShell для быстрого реагирования в M365
powershell
<h2 id="poisk-vseh-poluchateley-podozritelnogo-pisma">Поиск всех получателей подозрительного письма</h2>
Get-MessageTrace -SenderAddress "attacker@phishing-domain.com" `
-StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
| Select RecipientAddress, Received, Subject
<h2 id="udalenie-fishingovogo-pisma-iz-vseh-yaschikov">Удаление фишингового письма из всех ящиков</h2>
$Search = New-ComplianceSearch -Name "Remove Phishing" `
-ExchangeLocation All `
-ContentMatchQuery "Subject:'Срочно: смените пароль' AND Sent:2026-02-15"
Start-ComplianceSearch -Identity $Search.Identity
New-ComplianceSearchAction -SearchName "Remove Phishing" `
-Purge -PurgeType SoftDelete
<h2 id="blokirovka-domena-otpravitelya">Блокировка домена отправителя</h2>
New-TenantAllowBlockListItems `
-ListType Sender `
-Block `
-Entries "phishing-domain.com" `
-NoExpiration
> *⚠️ Не переустанавливайте операционную систему скомпрометированного компьютера до завершения криминалистического анализа. Переустановка уничтожает доказательства и усложняет понимание масштаба атаки.*
12. Мониторинг и метрики: как измерить эффективность защиты
Защита от фишинга — не состояние, а непрерывный процесс. Без мониторинга и измерения эффективности невозможно понять, работает ли система защиты и где остаются уязвимости. Следующие метрики позволяют объективно оценить текущий уровень защиты корпоративной почты.
Ключевые метрики защиты от фишинга
| Метрика | Что измеряет | Целевое значение | Инструмент |
|---|---|---|---|
| Phishing Catch Rate | % фишинговых писем, заблокированных системой | >99% | Отчёты почтового шлюза |
| False Positive Rate | % легитимных писем, ошибочно заблокированных | <0.1% | Жалобы пользователей + логи |
| DMARC Pass Rate | % входящих писем, прошедших DMARC | >95% для известных отправителей | DMARC-отчёты |
| Time to Detect | Время от получения письма до выявления угрозы | <1 час | SIEM |
| Employee Click Rate | % сотрудников, кликнувших фишинг-симуляцию | <5% | GoPhish / KnowBe4 |
| Incident Report Rate | % сотрудников, сообщивших о подозрительном письме | >20% | Форма репортинга |
Настройка еженедельного отчёта по безопасности почты
Для Microsoft 365 — автоматический отчёт через Defender Portal:
security
.microsoft.com → Reports → Email & collaboration →
Threat protection status → Export → Schedule weekly report
Для собственного сервера с Rspamd — экспорт статистики:
bash
<h2 id="rspamd-statistika-za-poslednie-sutki">Rspamd статистика за последние сутки</h2>
rspamc stat
<h2 id="eksport-v-json-dlya-posleduyuschey-obrabotki">Экспорт в JSON для последующей обработки</h2>
curl http://localhost:11334/stat -H "Password: YOUR_PASSWORD" | python3 -m json.tool
<h2 id="logi-v-realnom-vremeni">Логи в реальном времени</h2>
journalctl -u rspamd -f
Анализ DMARC-отчётов для выявления спуфинга
DMARC-отчёты (RUA — aggregate reports) приходят ежедневно или еженедельно от всех крупных почтовых провайдеров: Google, Yandex, Mail.ru, Microsoft. Они содержат информацию о том, кто отправлял письма от имени вашего домена и прошли ли они проверку.
Инструменты для чтения DMARC-отчётов (XML-формат, не читается вручную):
- Dmarcian — бесплатный план до 5 доменов
- Google Postmaster Tools — для доменов с большим объёмом отправки в Gmail
- Yandex Postmaster — обязательно для доменов, отправляющих на Яндекс
Красные флаги в DMARC-отчётах: появление незнакомых IP-адресов, отправляющих почту от имени вашего домена; резкий рост объёма писем от вашего домена; высокий процент `spf=fail` или `dkim=fail`.
> *💡 Настройте мониторинг DMARC-отчётов как обязательный еженедельный процесс — это бесплатный ранний индикатор того, что ваш домен используется в фишинговых кампаниях против ваших клиентов или партнёров.*
13. Типичные ошибки при настройке защиты от фишинга
Большинство компаний делают одни и те же ошибки при построении защиты корпоративной почты от фишинга. Знание этих ошибок позволяет не повторять их — и не тратить бюджет на решения, которые создают иллюзию безопасности, не обеспечивая её реально.
Ошибка 1: Только антивирус без аутентификации отправителя
Антивирус на почтовом сервере без настроенных SPF, DKIM и DMARC — это защита от вредоносных вложений, но не от фишинга. Письмо с поддельным «From: ceo@yourcompany.com» без вложений пройдёт антивирус без проблем. SPF, DKIM и DMARC — это фундамент, без которого всё остальное неполноценно.
Ошибка 2: DMARC в режиме «none» годами
DMARC с политикой `p=none` ничего не блокирует — только собирает данные. Это правильный первый шаг на срок 2–4 недели, но не постоянная конфигурация. Компании, которые «настроили DMARC» годы назад и оставили `p=none` — имеют видимость защиты без реального эффекта.
Ошибка 3: SPF с `?all` вместо `~all` или `-all`
`?all` означает «нейтрально» — проверка SPF фактически не даёт никакого результата для получающих серверов. Минимальная рабочая конфигурация: `~all` (softfail) для начала, затем `-all` (hardfail) после проверки всех легитимных источников.
Ошибка 4: Блокировка только исполняемых файлов
Многие политики блокируют `.exe`, `.bat`, `.cmd` — и считают задачу решённой. Но современные фишинговые атаки используют: документы Office с макросами (.doc, .xls), зашифрованные ZIP-архивы с нагрузкой, файлы `.iso` и `.img` (монтируются как диски в Windows 10/11), OneNote-файлы `.one` (активно использовались в 2023 году).
Ошибка 5: Игнорирование исходящего трафика
Большинство компаний настраивают фильтрацию только входящей почты. Исходящая фильтрация решает другие задачи: предотвращение утечки данных через почту; обнаружение компрометированных аккаунтов (если ящик сотрудника взломан и рассылает спам); контроль соответствия корпоративным стандартам коммуникации.
Ошибка 6: Отсутствие процедуры репортинга для сотрудников
Если сотрудник не знает, как и куда сообщить о подозрительном письме — он либо молча удалит его (потенциально ценный сигнал для команды ИБ) либо спросит коллегу (возможное распространение). Кнопка «Сообщить о фишинге» в почтовом клиенте или чёткая инструкция с email службы ИБ должны быть у каждого сотрудника.
> *⚠️ Самая дорогостоящая ошибка — экономия на обучении сотрудников при больших затратах на технические средства. Один необученный сотрудник с доступом к финансовым системам стоит дороже годовой лицензии на любой антифишинговый шлюз.*
14. FAQ: 12 горячих вопросов о фильтрации фишинга
Q 01 Достаточно ли настроить SPF, DKIM и DMARC для полной защиты?
A Нет. SPF, DKIM и DMARC защищают от спуфинга вашего домена — то есть от писем, притворяющихся отправленными от вас. Они не защищают от фишинговых писем, отправленных с легитимных, но чужих доменов. Для полной защиты нужны: почтовый шлюз с антиспам-анализом, сканирование вложений, проверка URL и обучение сотрудников.
Q 02 Можно ли заблокировать 100% фишинговых писем техническими средствами?
A Нет, 100% недостижимо. Целевые атаки с использованием легитимных почтовых сервисов (Google Docs, SharePoint), письма с QR-кодами вместо ссылок, атаки через взломанные аккаунты реальных партнёров — всё это обходит даже самые современные технические фильтры. Конечная защита — обученный и внимательный сотрудник.
Q 03 Как часто нужно обновлять правила антиспам-фильтра?
A Облачные решения (Microsoft 365 Defender, Kaspersky Security Cloud) обновляются автоматически. Для on-premise SpamAssassin: запускайте `sa-update` ежедневно через cron. Для Rspamd: обновления правил происходят автоматически через rspamd.com/rules. Репутационные базы доменов и IP обновляются несколько раз в день.
Q 04 Наш домен попал в чёрный список. Что делать?
A Шаги: проверить факт попадания через mxtoolbox.com/blacklists; устранить причину (найти и удалить источник спама или вредоносного ПО в сети); подать заявку на делистинг на сайте конкретного блок-листа (у каждого свой процесс); проверить настройки SPF/DKIM/DMARC; подождать 24–72 часа. Самые важные списки для репутации: Spamhaus ZEN, Barracuda BRBL, SpamCop.
Q 05 Нужно ли шифровать корпоративную почту?
A Для большинства компаний — нет необходимости шифровать всю почту. Но S/MIME или PGP стоит рассмотреть для: переписки с конфиденциальными финансовыми данными; коммуникации с юристами; обмена персональными данными сотрудников или клиентов (требование 152-ФЗ). Шифрование также является дополнительной защитой от MITM-атак на почтовый трафик.
Q 06 Что такое «серая зона» в антиспам-фильтре и нужна ли она?
A Greylisting (серая зона) — техника, при которой неизвестный отправитель временно отклоняется с кодом «попробуйте позже». Легитимные почтовые серверы повторяют отправку автоматически, спам-боты — обычно нет. Эффективно снижает объём спама с минимальными настройками, но добавляет задержку 5–15 минут для писем от новых отправителей. Включена по умолчанию в Rspamd.
Q 07 Как защитить почту руководства от целевого фишинга?
A Специальные меры для топ-менеджмента: внести адреса в «Impersonation Protection» в M365 Defender; включить дополнительную верификацию входа (MFA) обязательно; настроить отдельное правило безопасности с более агрессивными порогами фильтрации; провести персональное обучение — руководители часто наиболее уязвимы из-за высокой загрузки и привычки к авторитарным запросам.
Q 08 Как отличить легитимное письмо от сервиса (банк, налоговая) от фишинга?
A Признаки легитимности: письмо прошло SPF и DKIM от правильного домена сервиса; ссылки в письме ведут на официальный домен сервиса (проверить до клика); письмо не требует ввода полного пароля или SMS-кода; у вас есть предшествующий контекст (вы сами совершали операцию, которая могла вызвать уведомление). При малейшем сомнении — войдите в личный кабинет вручную, не через ссылку из письма.
Q 09 Нужно ли блокировать письма с внешних адресов gmail.com и mail.ru?
A Полная блокировка приведёт к пропуску легитимных писем от контрагентов и клиентов. Рекомендуется: маркировать такие письма как «внешние»; устанавливать более высокий порог подозрительности; отдельно проверять письма с gmail/mail.ru, претендующие быть от внутренних сотрудников. Полную блокировку можно применить только к конкретным ящикам с высоким риском (бухгалтерия, финансовый директор).
Q 10 Как понять, что защита работает? Каков нормальный уровень блокировки?
A Типичный объём отфильтрованной почты для корпоративного домена: 40–80% всей входящей почты — спам и фишинг. Если шлюз блокирует менее 10% — скорее всего, настройки слишком мягкие или объём легитимной почты аномально высок. Если блокирует более 95% — возможно, слишком агрессивные настройки с ложными срабатываниями.
Q 11 Обязательна ли многофакторная аутентификация (MFA) для почты?
A Да, MFA — обязательная мера для всех корпоративных почтовых ящиков без исключений. Даже если фишинговое письмо прошло все фильтры и пользователь ввёл пароль на фишинговой странице — без второго фактора злоумышленник не получит доступ к ящику. MFA нейтрализует самый распространённый результат успешной фишинговой атаки — кражу пароля.
Q 12 Как часто проводить аудит настроек защиты почты?
A Минимальная частота: полный аудит раз в год; проверка актуальности SPF/DKIM/DMARC при любых изменениях инфраструктуры (новый сервис рассылок, переезд на другой хостинг); просмотр DMARC-отчётов еженедельно; фишинг-симуляция раз в квартал.
15. Чек-лист: полная настройка защиты корпоративной почты от фишинга
Структурированный алгоритм внедрения защиты от фишинга. Выполнение всех блоков займёт 4–8 часов рабочего времени IT-администратора при наличии доступа к DNS и почтовой платформе.
Блок A: Аутентификация отправителя (1–2 часа)
- [ ] Проверить текущий SPF-записи домена через mxtoolbox.com/spf
- [ ] Добавить или обновить SPF-запись: включить все легитимные источники отправки
- [ ] Убедиться, что SPF не превышает 10 DNS-запросов (lookup limit)
- [ ] Получить и добавить DKIM-запись от почтовой платформы
- [ ] Проверить DKIM через mxtoolbox.com/dkim
- [ ] Добавить DMARC-запись с `p=none` и адресом для получения RUA-отчётов
- [ ] Проверить DMARC через mxtoolbox.com/dmarc
- [ ] Подписаться на бесплатный DMARC-мониторинг (dmarcian.com или dmarcanalyzer.com)
Блок B: Настройка почтового шлюза (1–2 часа)
- [ ] Включить проверку SPF для входящих: маркировать при SoftFail, блокировать при HardFail
- [ ] Включить проверку DKIM для входящих: маркировать при несоответствии
- [ ] Включить DNS-блоклисты (Spamhaus ZEN минимум)
- [ ] Настроить сканирование вложений: включить антивирусный движок
- [ ] Заблокировать опасные типы вложений: .exe, .js, .vbs, .bat, .cmd, .ps1, .iso
- [ ] Включить проверку URL через репутационные базы
- [ ] Настроить метку «ВНЕШНЕЕ ПИСЬМО» для всей входящей почты от внешних отправителей
- [ ] Включить greylisting или настроить паузу для новых отправителей
Блок C: Защита от BEC и spear phishing (1 час)
- [ ] Создать правила транспорта против display name spoofing для топ-менеджмента
- [ ] Добавить адреса руководства в Impersonation Protection (для M365)
- [ ] Запустить dnstwist для мониторинга typosquatting-доменов
- [ ] Задокументировать регламент верификации финансовых запросов по почте
Блок D: Аутентификация пользователей (30 минут)
- [ ] Включить MFA для всех пользователей корпоративной почты без исключений
- [ ] Настроить условный доступ: блокировать вход из неизвестных стран (если применимо)
- [ ] Включить мониторинг аномальных входов (уведомления при входе из нового устройства/локации)
Блок E: Обучение и процедуры (1 час настройки + регулярные активности)
- [ ] Создать и разослать инструкцию по распознаванию фишинга всем сотрудникам
- [ ] Добавить кнопку «Сообщить о фишинге» в почтовый клиент или создать ящик security@yourcompany.com
- [ ] Запланировать первую фишинг-симуляцию (GoPhish или встроенный инструмент платформы)
- [ ] Закрепить регламент реагирования на инциденты с почтой
- [ ] Ввести обязательный инструктаж по почтовой безопасности для новых сотрудников
Блок F: Мониторинг и поддержание (постоянный процесс)
- [ ] Настроить еженедельный отчёт по почтовой безопасности
- [ ] Проверять DMARC-отчёты еженедельно
- [ ] Плановый аудит SPF/DKIM/DMARC при любых изменениях инфраструктуры
- [ ] Ежеквартальная фишинг-симуляция для сотрудников
- [ ] Обновление правил SpamAssassin/Rspamd (ежедневно через cron)
- [ ] Ежегодный полный аудит всех настроек защиты от фишинга
> *✅ Компании, полностью выполнившие блоки A–D, снижают успешность массовых фишинговых атак на 95–99%. Блок E (обучение) — это страховка от оставшихся 1–5%, которые технические средства не могут перехватить.*
16. Заключение
Фильтрация фишинга в корпоративной почте — не разовый проект, а непрерывный процесс. Злоумышленники адаптируются к защитным мерам быстро: техники, работавшие год назад, сегодня уже блокируются шлюзами — и появляются новые. QR-коды вместо ссылок, HTML-смаглинг, фишинг через легитимные облачные сервисы — всё это появилось именно как ответ на улучшение технических фильтров.
Единственная устойчивая стратегия — многоуровневая защита без ставки на одно «серебряное решение». SPF, DKIM и DMARC создают фундамент аутентификации. Почтовый шлюз блокирует массовые атаки. Sandbox и поведенческий анализ перехватывают сложные угрозы. Обученные сотрудники являются последней, но часто самой важной линией защиты.
Главные принципы, которые нужно вынести из этого руководства: аутентификация отправителя через DMARC с политикой reject — обязательный стандарт, не рекомендация; MFA — без него всё остальное условно; BEC нельзя остановить только техническими средствами; обучение сотрудников — это инвестиция с наибольшей отдачей на рубль затрат; мониторинг и DMARC-отчёты дают ранние сигналы атак задолго до инцидента.
Следите за актуальными угрозами через профессиональные ресурсы: Kaspersky Securelist (securelist.ru), BI.ZONE Blog (bi.zone/blog), Positive Technologies (ptsecurity.com), Anti-Phishing Working Group (apwg.org).
Пять правил администратора почтовой безопасности
1. Аутентифицируй — SPF + DKIM + DMARC c `p=reject` — это не «хорошо бы», это обязательный стандарт 2026 года
2. Слои важнее одного щита — ни один продукт не обеспечивает полную защиту; строй защиту в глубину
3. Обучай регулярно — фишинг-симуляция раз в год бесполезна; ежеквартально — минимум
4. Мониторь постоянно — еженедельные DMARC-отчёты и метрики шлюза покажут атаку раньше, чем пользователь
5. Планируй реагирование заранее — алгоритм ответа на инцидент, написанный в момент паники, будет плохим алгоритмом
