Привет! Меня зовут Павел Маслов, я архитектор дирекции инфраструктурных проектов 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:
Запустите Microsoft IIS Manager и откройте параметры сервера (Configuration Editor).
Выберите секцию system.web/httpRuntime.
Найдите поле enableVersionHeader и смените True на False.
Заголовок X-Powered-By можно заменить на любое содержимое вместо номера версии:
Откройте параметры Microsoft IIS Manager.
Выберите HTTP Response Header.
Выберите 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 и миграции на новую версию.
Внедрите строгую аутентификацию для сотрудников с правами администратора
Учетные записи сотрудников с правами администратора должны использовать строгую аутентификацию — на основе криптографии и смарт-карт. Смарт-карта — это специальное устройство, которое хранит закрытый ключ для входа в аккаунт.
Чтобы внедрить ее:
Настройте внутреннюю инфраструктуру открытых ключей (public key infrastructure, PKI). Сделать это можно с помощью документации Microsoft.
Создайте отдельные учетные записи для администрирования Exchange.
Выпишите для этих учетных записей сертификаты аутентификации, которые будут соответствовать следующим требованиям.
Разрешите сотрудникам с правами администратора аутентификацию только с использованием смарт-карт.
Настройте для доступа к 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 необходимо ввести еще ряд ограничений:
Заблокируйте доступ по протоколу MAPI over HTTP на внешнем периметре. Порт по умолчанию — 443 (TCP). Почтовые клиенты должны подключаться только из локальной проводной сети или через VPN.
Запретите подключение мобильных клиентов по протоколу ActiveSync без VPN или используйте аутентификацию по сертификатам.
Сделайте Outlook on the web доступным только через VPN и запретите доступ через интернет. При необходимости разместить его на внешнем периметре и разрешить доступ опубликуйте OWA через Web Application Proxy и используйте многофакторную аутентификацию. Если вы заметите несколько неудачных попыток входа, скорее всего, вас пытаются взломать. В этом случае нужно временно заблокировать IP-адрес атакующего.
Выключите на серверах протоколы 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
Комментарии (13)
falcon4fun
31.10.2024 10:45Если релизовать пункты 1, 2, 3, 4, то компания остается без доступа к почте на внешке, что фактически является бредом, как таковым.
Второй пункт: аутентификация по сертификатам не является какой-то убер защитой и зачастую является еще большим дном. Там, где я видел реализацию сертов, пароли на токены и сертификаты были уровня "говнобомжа123" и все одинаковые еще зачастую. Это раз.
Два: ActiveSync умеет только в ИЛИ-ИЛИ: или пароли, или certificate-based. Не завидую тем, кто видел инфру с certificate-based и потом решил однажды, что ему надо назад. Ах да, это я, который столкнулся с этой проблемой. Нет, можно пойти методом колхоза: сделать еще один бэкэнд. Но для этого нужен еще один хостнейм и еще один IP. И опять же: сильная модификация Exchange сервера, которая добавит лучей поноса от того, кто однажды накатит новую CU и потеряет подобные все изменения.
Впрочем, чем больше изменений в IIS и конфигах, тем больше лучей поноса будет при обновлении CU. Ведь никто, как обычно, ничего не задокументировал, что наделал за 5-10 лет на Exchange сервере, да?
Три: Certificate-Based auth ломает встроенные пробы Exchange по мониторингу ActiveSync. Добро пожаловать в мир ошибок по ActiveSync-у в ивентлоге, HealthReport статусе и ServerHealth статусе.
Четыре: Токены (Smart card is required for interactive logon) ломает еще кучу всякого. Например, многие SSO интеграции не сделать, если у юзера зафорсена авторизация через токен. И еще куча нюансов вылезает, что в большой инфре приводит к инфракту жопы: "сколько мне теперь всего нужно сделать и сколько потратить времени, чтобы избавиться от этого бредового решения: токены и сертификаты с паролем жопа123 жи бизапасна"..Третий пункт, как и первый: Если в компании более 300-500 человек, не реализуемо практически от слова совсем. Бизнес пошлет далеко и надолго с такими желаниями. В большинстве компаний никому не интересно, что кого-то там взломают сегодня или завтра. "Ну взломают? Ну утащат весь адресбук? Ну фишинг разошлют внутри компании? Ничего же не случится. А вот я не смогу письмо важное после работы увидеть с телефона". Это должна быть идеальная компания в сферическом вакууме, построенная на ИТ с нормальными людьми в хай-менеджменте, чтобы такие хотелки работали.
И да. Почему-то все забыли, что /ecp открыт для всего мира в дефольных настройках и стоит хотя бы накатить модули IP whitelist-а на IIS.
И еще. Не заворачивать Exchange через WAF в 2к24 - считаю глупостью вселенского маштаба. Как минимум проблему балансинга DAG-а никто не отменял и ДНС балансер вообще не то, на что можно расчитывать.
Всегда есть тот же Sophos UTM, нынче XG - бесплатный для "home use only". Настроить и потестить хватить. Или если уж очень хочется: выбрать любой другой балансер под DAG.Ну и в дополнение. Всё еще не понимаю, почему почтовые клиенты используют древний ActiveSync вместо EWS.
Shaman_RSHU
31.10.2024 10:45В 2023 году я волевым решением оставил сотрудников компании без почты извне. Совсем всех. И ТОПов тоже. Это около 1000 сотрудников. И ничего, процессы были перестроены буквально за 3 недели. Если риски КБ велики, то нужно действовать.
sneakerclouder
31.10.2024 10:45Процессы перестраиваются на личную почту на яндексе и прочих, админ то конечно теперь может спать спокойно, но тогда зачем вообще свой почтовый сервер?
Shaman_RSHU
31.10.2024 10:45Поверьте, не во всех компаниях админ занимается и кибербезопасностью и почтой и антивирусы устанавливает. Если до Генерального донести недопустимые события, то он и за запрет использования личной почты в рабочих процессах и много чего еще.
Но можно как на подводной лодке, появилась дырка - латай, потом беги к другой. Но это немного не к тегу "Информационная безопасность".
falcon4fun
31.10.2024 10:45Большинству генеральных плевать на недопустимые события. Как и исполнительным директорам. Как и ИТ лидам. Все работают, как последний день. Получают ЗП, а дальше что будет - никого не колышет. И таких компаний больше, чем тех, где вам повезло это реализовать.
Ну либо вторая сторона ада: огромные корпорации, вроде банков, на 10-50к людей. Где список ченджей исчисляется очередью в тысячу, а список апеляций еще в 500. В итоге: "приходите через полгода"
Я, например, не имею не малейшего желания биться о стену, когда это еще и не моя работа: не хотите делать, как я говорю? - ок. Вот примерные риски, о которых я прокричал на каждом углу и сохранил их в папочку. На выходных и после работы не звоните, ваши проблемы. В иных случаях: нанимайте ит лида, СТО, охапку секьюритистов и прочих. Мне, как архитектору инфры - глубоко и далеко: хотели сэкономить - поздравляю, ваши проблемы теперь, я не собираюсь быть затычкой в каждой проблеме фирмы, которая происходит не по моей вине.
Shaman_RSHU
31.10.2024 10:45Прямо в точку! Поэтому давно для себя решил, что зеленые, синие, желтые банки обхожу стороной (РЖД и им подобные Газпромы).
А у мелких фирм-торгашей попросту на меня нет денег, поэтому не сталкивался, но верю, что там так все так, как описано:)
navion
31.10.2024 10:45Пара дополнений:
Сохранение конфигурации большинства сервисов при обновлениях появилось полтора года назад в CU13.
Для ограничения доступа к ECP есть Client Access Rules.
Сам ещё не проверял, но в Office 2024 должна появиться аутентификация через ADFS для MAPI.
Ну и в целом лучше один раз пройти EXRAP, чем десять аудитов от ИБшников.
falcon4fun
31.10.2024 10:45Насколько хорошо работает это в 2019ом? Стандартные изменения под Apple девайсы в активСинке, изменения под сертификаты и прочее как успешно сохраняется при накатывании нового CU?
Это есть только в 2019 Эксчендже. В 2016, если мне не изменяет память, такого добра нет и не будет. Поэтому только доп. модуль IIS
navion
31.10.2024 10:45У меня почти нет модификаций, но конфигурация OWA сохраняется при обновлениях.
bazanovv
31.10.2024 10:45Как вариант на Exchange 2016 ещё можно вынести административную ECP на отдельный сайт и порт в IIS, скопировав всё содержимое исходного каталога (и копируя потом файлы руками после установки CU) или вынести администрирование на отдельный небольшой сервер (на отдельном сайте местами кривовато работает), а потом запретить интерфейс администрирования на основном ECP совсем на всех доступных публично серверах при помощи Set-ECPVirtualDirectory -Identity "<server_name>\ecp (default web site)" -AdminEnabled $False
DikSoft
31.10.2024 10:45Если релизовать пункты 1, 2, 3, 4, то компания остается без доступа к почте на внешке, что фактически является бредом, как таковым.
Это не бред, а нормальная практика.
Если у вас только наземный Exchange - VPN на разрешённых устройствах.
Если гибрид - Outlook Services + MAM / MDM прекрасно справляются с задачей. Публикация сервисов Exchange on-prem не на весь Интернет, а только на скоп адресов M365 работает и работает уже не первый год.
Использование почты на яндексах / гуглах в корп целях пресекается 1) административно (политика) 2) технически (DLP + SIEM)
что /ecp открыт для всего мира в дефольных настройках
Нормально настройте internal / external Virtual Directory URL + балансеры/firewall перед CAS и будет всё хорошо.
grumbler70
Советы очевидные и много раз озвученные, но спасибо за хорошую подачу и не далеко лишнее напоминание!
Жду продолжения про Exchange hybrid )