Электронная почта является одним из самых часто используемых векторов проникновения злоумышленников в инфраструктуру компании. В 2024 только на заражение ВПО пришлось 29% всех инцидентов, где основным каналом доставки был фишинг. Одним из звеньев в данной цепочке являются почтовые сервера. При этом проникновение в инфраструктуру компании может происходить не только через фишинг, но и через компрометацию почтовых серверов. Логично отнести почтовые сервера к критичным хостам, поскольку они являются одним из основных каналов коммуникации как внутри компании, так и с внешним миром, а также содержат конфиденциальную и критичную для бизнеса информацию. Кроме того, их простой хотя бы на час может привести к большим убыткам практически в любой компании.
В данной статье приведены основные рекомендации по повышению безопасности почтовых серверов и корпоративной почты.
Безопасность почтовых серверов
Антивирусное ПО
Должно быть обязательно установлено (в т.ч. на почтовые сервера на ОС семейства Linux), антивирусные базы должны постоянно поддерживаться в актуальном состоянии.
Казалось бы, банальная рекомендация, однако в своей практике встречались разные кейсы. Например, почтовый сервер на ОС семейства Linux, АВПО не стоит. Или стоит, но антивирусные базы никогда не обновлялись (иногда по несколько лет). И все это обнаруживалось в ходе расследований инцидентов, связанных с установкой вредоносного ПО на почтовые сервера.
Мониторинг журналов ОС
Антивирус никогда не являлся абсолютным средством защиты от всех угроз. Важно отслеживать такие события, как: старты процессов, входы на хост, операции с реестром и файловой системой и пр.
Одним из примеров отслеживаемой активности может быть запуск процессов от имени процесса почтового сервера, при этом особо критично в данном случае выглядит запуск командных оболочек cmd, powershell, bash, sh. Подобная активность должна централизованно собираться на уровне SIEM-системы и обрабатываться как алерты высокой степени критичности. В идеале совместно с антивирусным ПО на хосте должно быть установлено решение класса Endpoint Detection and Response (EDR). Это позволит не только выявлять более продвинутые атаки, но и оперативно реагировать на инциденты на конечной точке. В случае невозможности можно воспользоваться бесплатными альтернативами. Например, Sysmon для расширения собираемой телеметрии и Velociraptor для оперативного реагирования.
Мониторинг журналов приложений и средств защиты
Не стоит забывать, что в журналах приложений почтового сервера можно найти много полезной информации для выявления потенциальных атак. Сюда можно отнести:
Собранную информацию по IP и email-адресам отправителей можно сопоставить с базой фидов провайдеров данных Threat Intelligence (TI) и таким образом выявлять попытки проникновения известных хакерских группировок.
Входы пользователей на почтовый сервер можно проверять по GEO базам и TI-фидам. Входы из других стран, ранее неизвестных локаций или из VPN подсетей (например, proton VPN) могут указывать на компрометацию учетной записи. Для более детального анализа поведений пользователей можно воспользоваться решениями класса Behavior Analytics, например User and Entity Behavior Analytics (UEBA).
Реагирование на алерты средств защиты обязательно. Любой детект антивирусного ПО и EDR на почтовом сервере должен быть обработан, и необходимо проводить детальное расследование. Даже если средство защиты заблокировало угрозу, это не значит, что на хосте все в порядке. Злоумышленник может быть уже на хосте или попытаться на него проникнуть. При этом попытка загрузки ВПО на хост (которая также могла быть обнаружена средствами защиты) может указывать на наличие незакрытой уязвимости. Этому моменту также следует уделить особое внимание.
Должно быть обязательно установлено (в т.ч. на почтовые сервера на ОС семейства Linux), антивирусные базы должны постоянно поддерживаться в актуальном состоянии.
Казалось бы, банальная рекомендация, однако в своей практике встречались разные кейсы. Например, почтовый сервер на ОС семейства Linux, АВПО не стоит. Или стоит, но антивирусные базы никогда не обновлялись (иногда по несколько лет). И все это обнаруживалось в ходе расследований инцидентов, связанных с установкой вредоносного ПО на почтовые сервера.
Мониторинг журналов ОС
Антивирус никогда не являлся абсолютным средством защиты от всех угроз. Важно отслеживать такие события, как: старты процессов, входы на хост, операции с реестром и файловой системой и пр.
Одним из примеров отслеживаемой активности может быть запуск процессов от имени процесса почтового сервера, при этом особо критично в данном случае выглядит запуск командных оболочек cmd, powershell, bash, sh. Подобная активность должна централизованно собираться на уровне SIEM-системы и обрабатываться как алерты высокой степени критичности. В идеале совместно с антивирусным ПО на хосте должно быть установлено решение класса Endpoint Detection and Response (EDR). Это позволит не только выявлять более продвинутые атаки, но и оперативно реагировать на инциденты на конечной точке. В случае невозможности можно воспользоваться бесплатными альтернативами. Например, Sysmon для расширения собираемой телеметрии и Velociraptor для оперативного реагирования.
Мониторинг журналов приложений и средств защиты
Не стоит забывать, что в журналах приложений почтового сервера можно найти много полезной информации для выявления потенциальных атак. Сюда можно отнести:
- входы пользователей в приложение почтового сервера (IP-адреса, учетные записи),
- информацию о доставке или блокировке писем (IP и email-адреса отправителей, названия вложений),
- алерты средств защиты (сработки антивирусного ПО, EDR, WAF),
- и пр.
Собранную информацию по IP и email-адресам отправителей можно сопоставить с базой фидов провайдеров данных Threat Intelligence (TI) и таким образом выявлять попытки проникновения известных хакерских группировок.
Входы пользователей на почтовый сервер можно проверять по GEO базам и TI-фидам. Входы из других стран, ранее неизвестных локаций или из VPN подсетей (например, proton VPN) могут указывать на компрометацию учетной записи. Для более детального анализа поведений пользователей можно воспользоваться решениями класса Behavior Analytics, например User and Entity Behavior Analytics (UEBA).
Реагирование на алерты средств защиты обязательно. Любой детект антивирусного ПО и EDR на почтовом сервере должен быть обработан, и необходимо проводить детальное расследование. Даже если средство защиты заблокировало угрозу, это не значит, что на хосте все в порядке. Злоумышленник может быть уже на хосте или попытаться на него проникнуть. При этом попытка загрузки ВПО на хост (которая также могла быть обнаружена средствами защиты) может указывать на наличие незакрытой уязвимости. Этому моменту также следует уделить особое внимание.
Контроль доступа администраторов к почтовым серверам
В идеале обеспечить доступ к почтовому серверу только через решение класса Privilege Access Management (PAM). В случае его отсутствия можно воспользоваться best practice по организации доступа к серверной инфраструктуре. Например, трёхуровневая tier-модель доступа от Microsoft. Несмотря на то, что модель вышла довольно давно, она не потеряла свою актуальность.
Патч-менеджмент
Достаточно вспомнить историю про ProxyLogon (CVE-2021-26855) и ProxyShell (CVE-2021-34473, CVE-2021-34523), чтобы понять, к каким последствиям могут привести непропатченные почтовые сервера. Важно также понимать, что установка только что вышедших обновлений безопасности также может привести к негативным последствиям (например, аварийное завершение работы приложения или ОС). Поэтому, перед установкой обновления на «боевые» почтовые сервера их необходимо хотя бы какое-то время проверять в тестовом контуре. При этом важно не сильно затягивать с установкой обновлений. Чтобы уменьшить риски в период тестирования или при невозможности установки обновления можно воспользоваться компенсационными мерами. Например, ограничить доступ к web-интерфейсу корпоративной почты из внешней сети или закрыть за WAF.
Ограничение доступа в web-интерфейсы почты из сети интернет
Открытый во внешнюю сеть доступ к web-интерфейсу корпоративной почты (например, Outlook Web Access (OWA)) означает, что абсолютно любой пользователь сети интернет имеет возможность перейти на страницу с входом в web-интерфейс, зная её адрес. Это имеет определенные риски:
Для того, чтобы избежать данных рисков, имеет смысл ограничить доступ к web-интерфейсу почты из сети интернет. Например, закрыть за корпоративным VPN.
В идеале обеспечить доступ к почтовому серверу только через решение класса Privilege Access Management (PAM). В случае его отсутствия можно воспользоваться best practice по организации доступа к серверной инфраструктуре. Например, трёхуровневая tier-модель доступа от Microsoft. Несмотря на то, что модель вышла довольно давно, она не потеряла свою актуальность.
Патч-менеджмент
Достаточно вспомнить историю про ProxyLogon (CVE-2021-26855) и ProxyShell (CVE-2021-34473, CVE-2021-34523), чтобы понять, к каким последствиям могут привести непропатченные почтовые сервера. Важно также понимать, что установка только что вышедших обновлений безопасности также может привести к негативным последствиям (например, аварийное завершение работы приложения или ОС). Поэтому, перед установкой обновления на «боевые» почтовые сервера их необходимо хотя бы какое-то время проверять в тестовом контуре. При этом важно не сильно затягивать с установкой обновлений. Чтобы уменьшить риски в период тестирования или при невозможности установки обновления можно воспользоваться компенсационными мерами. Например, ограничить доступ к web-интерфейсу корпоративной почты из внешней сети или закрыть за WAF.
Ограничение доступа в web-интерфейсы почты из сети интернет
Открытый во внешнюю сеть доступ к web-интерфейсу корпоративной почты (например, Outlook Web Access (OWA)) означает, что абсолютно любой пользователь сети интернет имеет возможность перейти на страницу с входом в web-интерфейс, зная её адрес. Это имеет определенные риски:
- возможные атаки перебора паролей и подбора пользователей. В случае, если злоумышленнику удалось узнать адрес электронной почты, при наличии доменной аутентификации, атака перебора паролей может привести к блокировке доменной учетной записи;
- эксплуатация уязвимостей из сети интернет, в т.ч. zeroday, в web-интерфейсах;
- использование адреса веб-интерфейса почты в фишинговых атаках;
- несанкционированный доступ к почтовой переписке
Для того, чтобы избежать данных рисков, имеет смысл ограничить доступ к web-интерфейсу почты из сети интернет. Например, закрыть за корпоративным VPN.
Безопасность корпоративной почты
Настройка DKIM, SPF, DMARC
Про данные технологии уже было много раз сказано. Если кратко:
Их настройка – первое, что должен сделать владелец корпоративной почты. Они напрямую связаны с безопасностью и репутацией почтовых доменов и позволяют уменьшить риски использования ваших почтовых доменов в спам и фишинговых рассылках. При этом важно понимать, что некорректная настройка данных механизмов может привести к попаданию всей вашей исходящей почты в спам или блокировке на стороне получателя.
Маркировка входящей почты от внешних отправителей
Пометив письма, которые приходят от внешних отправителей, в теме или в содержимом, можно существенно повысить защиту организации от фишинговых атак (в т.ч. атак с применением техники typosquatting, когда используется похожее (look-a-like) написание домена отправителя).
Проверка контента и почтовых вложений
Имеет смысл проводить как для внешней, так и для внутренней почты. Для проверки на наличие конфиденциальной информации, отправляемой из организации вовне, можно воспользоваться решениями класса Data Loss Prevention (DLP). В редких случаях применение DLP оправдано для контроля внутренней почты, чтобы не допустить пересылку конфиденциальной информации сотрудникам, которые не должны иметь к ней доступ.
Стандартными средствами для контроля вложений и проверки писем на вредоносные вложения и ссылки являются почтовые шлюзы и системы защиты электронной почты, которые включают в себя проверку писем антивирусными движками. Важно проверять не только письма, которые приходят извне, но и внутренние рассылки, поскольку злоумышленники могут скомпрометировать почту одного из пользователей и воспользоваться ей для продвижения по инфраструктуре организации.
Для более глубокого анализа писем можно воспользоваться решениями класса Sandbox, однако данные решения дорогие и требуют времени на проверку письма. В организациях с большим потоком электронной почты это может привести к существенным задержкам в доставке электронных писем конечным адресатам.
Обучение пользователей работе с почтой
Одних технических мер по защите почты никогда не будет достаточно. Конечный пользователь всегда будет играть решающую роль в успешности атаки. Поэтому важно обучить пользователей правильно работать с почтой. Примеры мер безопасного обращения с корпоративной электронной почтой:
Про данные технологии уже было много раз сказано. Если кратко:
- SPF, или Sender Policy Framework, указывает, какие серверы имеют право отправлять почту от имени домена.
- DKIM, или Domain Keys Identified Mail, добавляет цифровую подпись к письмам, чтобы подтвердить их происхождение.
- DMARC, или Domain-based Message Authentication, Reporting and Conformance, определяет, как поступать с письмами, не прошедшими проверку SPF / DKIM.
Их настройка – первое, что должен сделать владелец корпоративной почты. Они напрямую связаны с безопасностью и репутацией почтовых доменов и позволяют уменьшить риски использования ваших почтовых доменов в спам и фишинговых рассылках. При этом важно понимать, что некорректная настройка данных механизмов может привести к попаданию всей вашей исходящей почты в спам или блокировке на стороне получателя.
Маркировка входящей почты от внешних отправителей
Пометив письма, которые приходят от внешних отправителей, в теме или в содержимом, можно существенно повысить защиту организации от фишинговых атак (в т.ч. атак с применением техники typosquatting, когда используется похожее (look-a-like) написание домена отправителя).
Проверка контента и почтовых вложений
Имеет смысл проводить как для внешней, так и для внутренней почты. Для проверки на наличие конфиденциальной информации, отправляемой из организации вовне, можно воспользоваться решениями класса Data Loss Prevention (DLP). В редких случаях применение DLP оправдано для контроля внутренней почты, чтобы не допустить пересылку конфиденциальной информации сотрудникам, которые не должны иметь к ней доступ.
Стандартными средствами для контроля вложений и проверки писем на вредоносные вложения и ссылки являются почтовые шлюзы и системы защиты электронной почты, которые включают в себя проверку писем антивирусными движками. Важно проверять не только письма, которые приходят извне, но и внутренние рассылки, поскольку злоумышленники могут скомпрометировать почту одного из пользователей и воспользоваться ей для продвижения по инфраструктуре организации.
Для более глубокого анализа писем можно воспользоваться решениями класса Sandbox, однако данные решения дорогие и требуют времени на проверку письма. В организациях с большим потоком электронной почты это может привести к существенным задержкам в доставке электронных писем конечным адресатам.
Обучение пользователей работе с почтой
Одних технических мер по защите почты никогда не будет достаточно. Конечный пользователь всегда будет играть решающую роль в успешности атаки. Поэтому важно обучить пользователей правильно работать с почтой. Примеры мер безопасного обращения с корпоративной электронной почтой:
- Перед открытием письма проверять отправителя на предмет подделки контента или попытки выдать себя за кого-то другого.
- Обращать внимание на тему письма. Например, получение писем на корпоративную почту якобы от налоговой, силовых ведомств и пр. должно насторожить.
- Не переходить по ссылкам, которые вызывают сомнения.
- Не кликать по «размытым» картинкам.
- Не открывать почтовые вложения, если есть сомнения. Особенно если вложения требуют пароль для открытия или просмотра содержимого.
- В случае получения подозрительного письма переслать его как вложение (с сохранением оригинального контента и заголовков) в отдел ИБ на детальный анализ.
- Не пересылать подозрительные письма коллегам или вовне. При этом можно предупредить коллег, если получили такое письмо. Рассылка может оказаться массовой.
- и пр.
Рассмотренные в статье меры не являются универсальным «рецептом». Каждый владелец почтовых серверов и корпоративной почты выбирает только то, что может себе позволить. Важно помнить, что одних технических мер никогда недостаточно для обеспечения защищенности. Налаженные процессы, связанные с ИБ, адаптация к меняющемуся ландшафту угроз в совокупности с техническими и организационными мерами позволят обеспечить должный уровень защищенности не только корпоративной почты и почтовых серверов, но и инфраструктуры в целом.
Автор: Алексей Егоров, руководитель отдела анализа данных NGR Softlab
Источник: CISOCLUB