Почту на прокачку: повышаем защиту MS Exchange

от автора

Привет! Меня зовут Павел Маслов, я архитектор дирекции инфраструктурных проектов Positive Technologies. Не так давно мой коллега Артем Мелехин уже рассказывал на Хабре о сути нашего подхода к харденингу ИТ-инфраструктуры. Сегодня же мы поговорим об укреплении киберустойчивости программных средств на конкретном примере — параметрах почтовой системы Microsoft Exchange (MS Exchange).

Начать хочется с небольшой истории, которая и подтолкнула меня к написанию этой статьи. Недавно к нам за консультацией обратились ИТ-специалисты одной крупной компании с государственным участием, назовем ее N. Вопрос касался работы их корпоративной почты на базе MS Exchange, а точнее конкретного письма. Дело в том, что генеральный директор их контрагента получил e-mail от имени руководителя N с просьбой поделиться конфиденциальной информацией. Как вы уже догадались, никакого сообщения с подобным запросом он не отправлял. Чем закончилась эта история и как не повторить судьбу наших героев, читайте под катом.


Сначала ИТ-специалисты компании N заподозрили банальный фишинг, ведь в папке «Исходящие» этого письма не было. Мы тоже подключились к расследованию, результаты которого оказались совсем небанальными. Как оказалось, злоумышленники получили доступ к почтовому серверу и уже некоторое время читали всю переписку сотрудников организации, а еще могли отправлять письма от их имени. Давайте разберемся, как так получилось.

MS Exchange: популярность среди компаний и… хакеров

Если обратиться к статистике, сам по себе этот случай не кажется таким уж удивительным. Согласно исследованию Positive Technologies, почти половина успешных кибератак на бизнес происходят с помощью социальной инженерии. Основным каналом ее распространения является электронная почта — 85% всех случаев. Добавим сюда данные о том, что не менее 70% компаний со штатом от 2000 сотрудников пользуются Microsoft Exchange, и наш «коктейль» готов.

Сервис Microsoft Exchange находится на сетевом периметре организации и предназначен как для отправки сообщений внутри компании, так и для связи с внешним миром. При этом у него большое число уязвимостей, многие из которых имеет оценку 7 и более баллов по шкале CVSS v3. С точки зрения архитектуры все тоже довольно заманчиво: Microsoft Exchange 2019 по умолчанию интегрирован с Active Directory, а значит, его взлом может дать атакующим права администратора этого домена. Расположение и проблемы с безопасностью делают Microsoft Exchange привлекательной и легкой целью для хакеров.

Одно из решений — постараться закрыть все уязвимости средствами защиты и «навесить» на систему всевозможные сканеры. Однако это очень дорого и займет немало времени, да и все дыры заткнуть наверняка не получится. Поэтому предлагаю рассмотреть другой сценарий: что, если попробовать найти выход не в сфере ИБ, а через более грамотную настройку Exchange? Для начала разберемся, что не так с типовой инсталляцией.

Как выглядит типовая инсталляция и почему это плохо

Ниже вы можете увидеть, как выглядит архитектурная схема типовой инсталляции почты на базе Microsoft Exchange Server 2019.

Архитектурная схема типовой инсталляции почтовой системы

Архитектурная схема типовой инсталляции почтовой системы

Большинство компаний выбирают именно такой способ установки, поскольку хотят сэкономить время и ресурсы своих ИТ-подразделений. Однако у всего есть обратная сторона, и расплачиваться приходится безопасностью.

При таком способе установки нет регулярного тестирования и инсталляции обновлений, а серверы почтовой системы разглашают версии ее компонентов. Трафик из интернета проходит напрямую к серверам почтовой системы внутри периметра организации, при этом используются устаревшие алгоритмы шифрования (DES, RC4), протоколы сетевого доступа (TLS 1.0 и SMB v1) и аутентификации (NTLM v1). Кроме того, служебным учетным записям обычно оставляют права на подключение по любым протоколам. Вдобавок к этому учетная запись для инсталляции Exchange остается в группах с повышенными привилегиями домена Active Directory, а у административных учеток нет строгой аутентификации.

Если мы обратимся к матрице MITRE ATT&CK, то увидим, что злоумышленники могут использовать против такой почтовой системы 14 тактик и более 160 техник. Причем для их применения не нужно быть гением взлома — достаточно уровня «Киберхулиган» или «Энтузиаст-одиночка».

Прокачиваем нашу почту

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

  • Обновление и архитектура

  • Безопасность учетных записей

  • Устранение проблем с протоколами

  • Настройка работы с внешними клиентами

  • Использование расширенной защиты Windows

Подробные описания рекомендаций приведены в подразделах ниже.

Обновление и архитектура

Следите за актуальностью ПО

Как бы банально это ни звучало, чаще всего источник проблем — устаревшее ПО. Пользуйтесь только поддерживаемым вендорами софтом и следите за выходом накопительных обновлений (Cumulative Updates, CU) и обновлений безопасности (Security Updates, SU). Эти апдейты не только исправляют ошибки и добавляют новые функции, но и закрывают известные уязвимости.

Прячьте заголовки ответа сервера Microsoft IIS

После того как вы выстроили процесс обновления, не спешите всем об этом рассказывать. Чем больше злоумышленники знают о вашей системе, тем легче им подобрать способ ее взлома. Поэтому нужно скрыть заголовки ответов X-AspNet-Version, X-Powered-By и Server, которые содержат номера версий веб-приложений и сервера Microsoft IIS (Internet Information Services).

Чтобы отключить отображение заголовка X-AspNet-Version:

  1. Запустите Microsoft IIS Manager и откройте параметры сервера (Configuration Editor).

  2. Выберите секцию system.web/httpRuntime.

  3. Найдите поле enableVersionHeader и смените True на False.

Заголовок X-Powered-By можно заменить на любое содержимое вместо номера версии:

  1. Откройте параметры Microsoft IIS Manager.

  2. Выберите HTTP Response Header.

  3. Выберите X-Powered-By и замените содержимое поля Value на произвольное.

Скрыть заголовок Server можно с помощью компонента модуля перезаписи URL Rewrite. Для этого создаем правило Outbound и заполняем чем угодно поля NAME, VARIABLE NAME и VALUE ANY.

Используйте серверы с ролью Edge Transport

Если раньше вы не сталкивались с серверами Edge Transport aka пограничными транспортными серверами, подробнее о них можно почитать в статье Microsoft. Они используются для защиты от нежелательной почты и будут нужны вам в двух случаях:

  • Вы не используете сторонние средства защиты от спама и фишинга и полагаетесь только на встроенные инструменты Exchange.

  • Ваши сторонние средства защиты от нежелательной почты требуют установки серверов Edge Transport.

Если ни одно из условий вас не касается, для «общения» с внешним миром достаточно настроить агент передачи почты — Postfix.

Учетные записи

Отключите OWA и ActiveSync для служебных учетных записей

Служебными в Exchange называют все учетные записи, которые не принадлежат физическим лицам — сотрудникам или подрядчикам компании. Они используются для отправки и (или) получения сообщений от систем мониторинга или для запуска служб с ограниченными правами.

Нередко для них оставляют включенными сервисы Outlook Web App (OWA) и Exchange ActiveSync. Первый предоставляет доступ к почте через браузер, а второй отвечает за синхронизацию между рабочим компьютером и мобильным устройством сотрудника. Служебным учетным записям эти сервисы ни к чему, однако через них атакующие могут попытаться скомпрометировать систему.

Чтобы отключить OWA и ActiveSync для учетной записи, можно использовать центр администрирования Exchange или консольные команды:

Set-CasMailbox -Identity <MailboxIdentity> -ActiveSyncEnabled $false

Set-CasMailbox -Identity <MailboxIdentity> -OWAEnabled $false

Вместо MailboxIdentity нужно указать имя учетной записи.

Настройте ограничения административной учетной записи

Убедитесь, что административная учетная запись Microsoft Exchange не входит в следующие группы:

  • Администратор домена (Domain Admin).

  • Администратор предприятия (Enterprise Admin).

  • Администратор схемы (Schema Admin).

Из этого правила существует лишь два исключения: временно включать административную учетную запись в эти группы можно во время первоначальной установки Microsoft Exchange и миграции на новую версию.

Внедрите строгую аутентификацию для сотрудников с правами администратора

Учетные записи сотрудников с правами администратора должны использовать строгую аутентификацию — на основе криптографии и смарт-карт. Смарт-карта — это специальное устройство, которое хранит закрытый ключ для входа в аккаунт.

Чтобы внедрить ее:

  1. Настройте внутреннюю инфраструктуру открытых ключей (public key infrastructure, PKI). Сделать это можно с помощью документации Microsoft.

  2. Создайте отдельные учетные записи для администрирования Exchange.

  3. Выпишите для этих учетных записей сертификаты аутентификации, которые будут соответствовать следующим требованиям.

  4. Разрешите сотрудникам с правами администратора аутентификацию только с использованием смарт-карт.

  5. Настройте для доступа к Exchange Admin Center проверку подлинности по сертификатам согласно инструкции Microsoft.

Кроме того, не забывайте про парольные политики, чтобы задавать требования к сложности и периодичность смены пароля.

Протоколы

Проверьте конфигурацию протоколов SSL и TLS

Устаревшим протоколам шифрования сетевого доступа тоже не место в вашей почтовой системе. Убедитесь, что параметры SSL и TLS в вашей организации соответствуют требованиям Microsoft.

Используйте надежные алгоритмы шифрования:

  • RSA-2048 — для создания новых ключей сертификатов.

  • SHA-256 или более безопасный — при обновлении или создании новых запросов на подпись сертификатов.

Если вам нужно создать самоподписанный (его еще называют самозаверенным) SSL-сертификат, опирайтесь на рекомендации Microsoft.

Отключите SMB v1

Еще один устаревший протокол, который встречается на почтовых серверах, — SMB v1. Microsoft уже несколько лет настоятельно просят администраторов отключить его из-за проблем с безопасностью. В частности, его применяют в эксплойтах EternalBlue и EternalRomanc.

Проверить его статус можно с помощью следующих команд PowerShell:

(Get-WindowsFeature FS-SMB1).Installed

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Если в результате вы видите True, значит, в вашей системе используется SMB v1. Убедитесь, что ваши серверы группы доступности баз данных (database availability group, DAG) поддерживают SMB v2 или более новой версии. Для этого проверьте, правильно ли настроены DAG.

Теперь можно переходить к отключению SMB v1. Сделать это можно с помощью групповых политик по инструкции Microsoft или команд:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Клиенты

Настройте службу Kerberos и ограничения для почтовых клиентов

Используйте протокол Kerberos для аутентификации клиентов Outlook и OWA в локальной сети. Нужные параметры можно найти опять же в инструкции Microsoft.

Для почтовых клиентов Outlook необходимо ввести еще ряд ограничений:

  1. Заблокируйте доступ по протоколу MAPI over HTTP на внешнем периметре. Порт по умолчанию — 443 (TCP). Почтовые клиенты должны подключаться только из локальной проводной сети или через VPN.

  2. Запретите подключение мобильных клиентов по протоколу ActiveSync без VPN или используйте аутентификацию по сертификатам.

  3. Сделайте Outlook on the web доступным только через VPN и запретите доступ через интернет. При необходимости разместить его на внешнем периметре и разрешить доступ опубликуйте OWA через Web Application Proxy и используйте многофакторную аутентификацию. Если вы заметите несколько неудачных попыток входа, скорее всего, вас пытаются взломать. В этом случае нужно временно заблокировать IP-адрес атакующего.

  4. Выключите на серверах протоколы IMAP4 и POP3. По умолчанию они и так должны быть отключены, но лучше все же проверить и при необходимости принять меры. Если вам очень нужно их использовать, заблокируйте доступ через интернет по этим протоколам и разрешите подключение только из локальной проводной сети или через VPN.

Включаем расширенную защиту Windows

Расширенная защита Windows включает дополнительные меры безопасности, чтобы предотвратить атаки типа «обход проверки подлинности» (authentication relay) и «человек посередине» (man-in-the-middle, MITM). Она доступна в Microsoft Exchange Server 2013, 2016 и 2019, а также если вы установили обновление безопасности Exchange Server (SU) за август 2022 года или версию SU выше.

Однако у расширенной защиты Windows есть ряд ограничений. Например, она не будет работать:

  • Если в Microsoft Exchange 2013 есть общедоступные папки в среде сосуществования.

  • Если в Microsoft Exchange Server 2016 CU22, Microsoft Exchange Server 2019 CU11 или в версии ниже размещена иерархия общих папок.

  • Сервер использует метод управления идентификацией пользователей Hybrid Modern Authentication.

Кроме того, стоит учитывать, что перед включением расширенной защиты конфигурация TLS-сертификата должна быть согласована на всех серверах MS Exchange, а клиенты не должны использовать протокол NTLM v1.

Подведем итоги

Типовая настройка MS Exchange значительно упрощает злоумышленнику задачу. Такая конфигурация задействует только 2 из более чем 40 мер защиты. Если мы попытаемся рассчитать время на атаку исходя из данных MITRE ATT&CK, то на взлом такой системы хакеру потребуется около 6,5 часов. А вот как может выглядеть его путь в системе.

Моделирование путей злоумышленника в типовой инсталляции почтовой системы

Моделирование путей злоумышленника в типовой инсталляции почтовой системы

Теперь взглянем на то, как изменилась ситуацию после «тюнинга» нашей почты.

Моделирование путей злоумышленника в «тюнингованной» инсталляции почтовой системы

Моделирование путей злоумышленника в «тюнингованной» инсталляции почтовой системы

Путь хакера стал длиннее, нам удалось замедлить каждый его шаг в системе, и время атаки увеличилось до 64,5 часов. Причем мы смогли добиться такого прогресса без трат на новые средства защиты информации, а реализация большинства мер заняла всего пару часов.

Выполнение этих простых шагов даст команде реагирования почти в 10 раз больше времени на обнаружение и нейтрализацию угрозы. Будем рады, если вы тоже решите воспользоваться этими рекомендациями и поделитесь своим результатом!

А что же с нашими героями, спросите вы? Теми, кто обратился к нам за помощью?

ИТ-специалисты компании N «выгнали» злоумышленников с почтового сервера, провели «тюнинг» почтовой системы и подготовили коммуникацию для контрагентов об инциденте (включая принятые меры).

Павел Маслов

Архитектор, дирекция инфраструктурных проектов Positive Technologies


ссылка на оригинал статьи https://habr.com/ru/articles/854924/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *