Как закрыть CVE-2024-21410 и проверить защиту Exchange

Чтобы защитить Exchange от CVE-2024-21410, я проверяю обновления и фактическую настройку Extended Protection. Одного номера CU недостаточно: атака связана с ретрансляцией NTLM-аутентификации. Ниже — проверка сборки, ограничения защиты и порядок работ для небольшого офиса. Для Exchange 2016/2019 отдельно учитываю завершение поддержки.

Что позволяет CVE-2024-21410 и где проходит граница риска

Начну с механизма. CVE-2024-21410 — уязвимость повышения привилегий в Exchange Server, связанная с NTLM relay. Злоумышленник ретранслирует аутентификацию пользователя на уязвимый сервер и получает возможность действовать от его имени. Для этой цепочки нужен источник NTLM-аутентификации и доступ к подходящей службе Exchange. Поэтому при проверке безопасности почты я смотрю одновременно на сервер, способы входа и доступные маршруты. Само наличие старой машины ещё не описывает условия атаки.

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

Открытый порт показывает доступность службы. Он не доказывает CVE-2024-21410: нужно установить, какой протокол за ним работает, принимает ли он соответствующую аутентификацию и настроена ли защита. Обратное тоже неверно: отсутствие публикации в интернете не исключает доступ из внутренней сети. Я проверяю оба направления и записываю разрешённые подключения. Табличка «только для своих» пакеты не фильтрует. Приоритет получает доступный извне неподтверждённый узел, но внутренние серверы остаются в плане проверки.

Ключевая мера против ретрансляции — Extended Protection for Authentication, сокращённо EPA или EP. Она связывает аутентификацию с защищённым соединением. Установка Exchange Server 2019 CU14 и более поздних CU включает её по умолчанию, однако фактические настройки нужно проверить. Для Exchange Server 2016 предусмотрен отдельный сценарий настройки средствами Microsoft. Я считаю работу выполненной, когда есть подтверждение конфигурации защиты, подходящего уровня обновлений и работоспособности почты. Формула «скачали свежий пакет — закрыли вопрос» таких доказательств не даёт.

• Определить источник и маршрут NTLM-аутентификации.
• Проверить доступность нужных служб извне и внутри сети.
• Подтвердить сборку Exchange и состояние Extended Protection.

Как узнать сборку Exchange и не пропустить обновления

Я начинаю с перечня установленных серверов и их назначения. В нём нужны владелец узла, версия Exchange, ОС, накопительное обновление CU, обновление безопасности SU, опубликованные службы и зависимости. Отдельно отмечаю устройства и приложения, отправляющие через этот сервер письма. Часть сведений уже должна быть в паспорте ИТ-инфраструктуры. Остальное сверяю с работающей системой. Старый файл инвентаризации полезен как отправная точка, но статус обновления из него я не переношу без проверки.

Для первичного списка в Exchange Management Shell подходит команда ниже. Она показывает серверы и уровень CU через AdminDisplayVersion. В документации Microsoft прямо оговорено: этот способ не показывает установленные SU и HU, то есть исправления безопасности и отдельные исправления. Поэтому такой вывод нельзя прикладывать как единственное подтверждение закрытия уязвимости. Я сохраняю его для инвентаризации, а фактическую сборку проверяю следующим шагом. Это небольшое различие регулярно превращает уверенный отчёт в недостоверный.

Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

Для подробной проверки Microsoft рекомендует HealthChecker. Я загружаю актуальный HealthChecker.ps1 из официального проекта CSS-Exchange и запускаю на проверяемом сервере в Exchange Management Shell от имени администратора. Нужны права, перечисленные в документации сценария. В отчёте смотрю Build Number и сведения об обнаруженных исправлениях, затем сопоставляю их с официальной таблицей сборок. Вывод храню с датой и именем узла: после работ он понадобится для сравнения. Сам сценарий собирает диагностику, установку обновлений я планирую отдельно.

.\HealthChecker.ps1

Гибридную среду разбираю по ролям. Локальный Exchange может обеспечивать почтовый транспорт, управление получателями или гибридные функции. Синхронизация каталогов — отдельная задача соответствующего средства синхронизации; наличие Exchange само по себе не означает, что он её выполняет. Я выясняю, какие операции действительно проходят через узел, и отдельно отмечаю Hybrid Agent, если он используется. Это влияет и на настройки защиты, и на допустимость отключения сервера. Отсутствие локальных пользовательских ящиков не даёт основания вычеркнуть машину из обслуживания.

• Сохранить список серверов и назначение каждого узла.
• Получить отчёт HealthChecker для каждого проверяемого сервера.
• Сопоставить сборки с таблицей Microsoft, включая SU/HU.
• Записать гибридные зависимости и отправителей через SMTP.

Что проверить перед включением Extended Protection

Перед изменениями я снимаю состояние EP официальным сценарием ExchangeExtendedProtectionManagement.ps1. Его загружают из CSS-Exchange и запускают в повышенной Exchange Management Shell с необходимыми правами Organization Management. Параметр ниже выводит конфигурацию защиты на доступных серверах; это диагностический режим. Результат надо прочитать, сопоставить с назначением виртуальных каталогов и сохранить. Один успешный запуск без разбора вывода ничего не говорит о полноте проверки: недоступный узел всё ещё требует внимания.

.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

Затем выясняю, где заканчивается TLS-соединение. Microsoft не поддерживает EP при SSL offloading, когда устройство перед Exchange завершает шифрование и дальше передаёт трафик без него. Для SSL bridging предусмотрены условия, включая одинаковый сертификат на промежуточном устройстве и Exchange. Такая проверка нужна до окна работ. Иначе установка может закончиться успешно, а клиенты получат проблемы со входом. Схему соединений я рисую по фактическим настройкам устройств, потому что подпись «балансировщик» не объясняет, что происходит с трафиком.

У Modern Hybrid с Hybrid Agent есть отдельное ограничение: EP нельзя включать на Front-End EWS опубликованных через этот агент серверов. Я открываю соответствующий сценарий Microsoft и проверяю предусмотренные ограничения доступа. Для остальных каталогов действуют свои рекомендации. Поэтому универсальное указание выставить одинаковый режим повсюду опасно. Аналогично проверяю совместимость клиентов и общие требования к TLS. Защита должна соответствовать конкретной схеме подключения, иначе исправление одной проблемы создаст сбой почтовых функций.

Включённая многофакторная аутентификация полезна, но я не принимаю её наличие на одной странице входа за подтверждение защиты всех служб от NTLM relay. Проверяю, какие способы входа доступны по каждому маршруту и где применяется EP. Изменения защиты выполняю по подходящему сценарию производителя после проверки требований. При ошибках входа сначала выясняю, какой клиент и какой маршрут сломались. Массово выключить защиту ради исчезновения жалоб — удобный способ вернуть исходную проблему вместе с привычной работой почты.

• Сохранить текущие настройки Extended Protection.
• Проверить TLS, промежуточные устройства и сертификаты.
• Учесть исключения для Modern Hybrid с Hybrid Agent.
• Проверить совместимость реально используемых клиентов.

Как обновить Exchange с подготовленным окном работ

Сначала определяю, какую систему вообще имеет смысл обновлять. Поддержка Exchange Server 2016 и 2019 завершилась 14 октября 2025 года. На дату проверки статьи, 25 октября 2026 года, закрытие старой CVE не возвращает этим выпускам обычную поддержку. Программа ESU имеет отдельные условия и право получения обновлений. Я проверяю участие в ней, если организация на неё рассчитывает, и составляю план перехода на поддерживаемую платформу. Исторический CU14 объясняет появление защиты по умолчанию; выбирать его конечной целью обслуживания сегодня неправильно.

Перед установкой нужна проверенная резервная копия Exchange и Active Directory, а также сохранённые настройки, которые придётся восстановить. Я проверяю не только отчёт задания, но и доступность копии, порядок восстановления и необходимые учётные данные. Обычный снимок виртуальной машины с возможностью возврата состояния Microsoft для Exchange не поддерживает. Поэтому обещание «сделаем snapshot, потом разберёмся» я из плана убираю. Копия без понятного восстановления выглядит убедительно ровно до момента, когда её попросят использовать.

Пакеты и порядок работ выбираю по текущей и целевой версии, требованиям к ОС и компонентам, а также замечаниям к выпуску. Проверку совместимости провожу до обслуживания рабочей системы. Для установленного CU нельзя обещать простой возврат удалением обновления: Microsoft предупреждает, что удаление новой версии полностью удаляет Exchange с сервера. Поэтому заранее согласую действия при неудачной установке и момент, когда нужно остановиться. Здесь полезнее прочитанный план восстановления, чем уверенность в кнопке отмены, которой может не быть.

На одиночном сервере я закладываю остановку обслуживаемых им функций и перезагрузки. В среде с DAG перед обновлением участника требуется предусмотренное обслуживание; сохранение доступности зависит от исправности остальных узлов и всей схемы подключений. Само слово «кластер» непрерывную работу не гарантирует. Для малого офиса фиксирую начало окна, критерии завершения и порядок уведомления сотрудников. Точную длительность определяю после диагностики и проверки выбранного пути обновления. Обещание уложиться в несколько часов без этих данных в договорённости не включаю.

• Уточнить поддержку продукта и доступность нужных обновлений.
• Проверить копии Exchange и AD, сохранить настройки.
• Проверить требования целевого выпуска и порядок восстановления.
• Согласовать окно, установить обновления и выполнить перезагрузки.

Условный разбор: «Слой и крем», 26 рабочих мест

Разберу учебную ситуацию для кондитерской «Слой и крем» в Москве, где 26 рабочих мест. Версию и настройки ниже задаю как условия примера. После переноса пользовательских ящиков в облако локальный Exchange Server 2019 CU13 оставили для пересылки писем. EP не настроена, внешняя публикация веб-служб сохранилась. Такой сценарий помогает увидеть ошибку: объём локальной почты приняли за показатель безопасности. По одним этим условиям я не объявляю произошедший взлом; сначала требуются диагностика и проверка доступных способов аутентификации.

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

Дальше в примере идут отчёты о сборке и EP, проверка резервного копирования, затем согласованное окно обслуживания. Для оставляемой системы выбираю актуальный допустимый путь обновления с учётом завершённой поддержки старой ветки; при выводе из эксплуатации составляю отдельный план. Историческая отметка CU13 здесь нужна, чтобы показать исходное состояние. Она не превращает переход на ближайший CU в универсальное решение. Если выясняется, что схема несовместима с включением EP, сначала исправляю схему и документирую временные ограничения доступа.

Результат учебного разбора принимаю по понятным признакам: подтверждена настройка защиты, пересылка дошла до контрольного получателя, ненужный веб-доступ закрыт, отчёты сохранены, дальнейшая судьба сервера определена. На следующий рабочий день в плане предусмотрен повторный контроль очередей и обращений пользователей. Длительность ремонта в часах из такого примера вывести нельзя. Отчёт «обновили успешно» слишком короток для приёмки. В нём должны быть исходное состояние, выполненные изменения, результаты проверок и оставшиеся задачи с ответственными.

Как подтвердить результат и сохранить его после обновления

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

Правила доступа пересматриваю по назначению служб. Если сервер принимает письма извне или участвует в гибридной работе, совет закрыть вообще все внешние подключения может оборвать нужный процесс. Я удаляю лишние публикации и ограничиваю остальные по согласованной схеме, затем повторяю функциональные проверки. Для внутренних отправителей тоже нужен явный перечень разрешённых подключений. Такая запись помогает при последующих изменениях: следующий специалист сможет объяснить назначение правила, а не оставит его навсегда из опасения что-нибудь сломать.

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

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

• Сравнить сборку и настройки EP до и после работ.
• Проверить доставку и все используемые почтовые функции.
• Зафиксировать ограничения доступа и результаты приёмки.
• Назначить ответственного и следующую проверку.

Частые вопросы