none
Защита почтового сервера от перебора учётных данных RRS feed

  • Вопрос

  • В журнале "Приложения" почтового сервера появляется большое количество предупреждений 1035 вида:

    "Inbound authentication failed with error LogonDenied for Receive connector Default Frontend SRV-MBX1. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [IP-Address]."

    В журнале "Безопасность" почтового сервера при этом каждую минуту появляется несколько событий 4625 вида (с разными именами учётной записи):

    "Учетной записи не удалось выполнить вход в систему.

    Субъект:
    ИД безопасности: СИСТЕМА
    Имя учетной записи: SRV-MBX1$
    Домен учетной записи: MyDomain
    Код входа: 0x3E7
    Тип входа: 8

    Учетная запись, которой не удалось выполнить вход:
    ИД безопасности: NULL SID
    Имя учетной записи: somename@MyDomain.local
    Домен учетной записи
    Сведения об ошибке:
    Причина ошибки: Неизвестное имя пользователя или неверный пароль.
    Состояние: 0xC000006D
    Подсостояние: 0xC0000064

    Сведения о процессе:
    Идентификатор процесса вызывающей стороны: 0x2368
    Имя процесса вызывающей стороны: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeFrontendTransport.exe"

    Что можно предпринять в данной ситуации для обеспечения безопасности и исключения попыток неправомерного использования моего почтового сервера в качестве сервера пересылки?

    25 октября 2018 г. 6:47

Ответы

  • Меня больше интересует не специфичный сценарий с утечкой базы логинов, а вполне распространённый случай, когда злоумышленник узнаёт внешний адрес почтового сервера, а также некоторые адреса почты сотрудников (по сути они не являются тайной - их можно найти, например, в разделе контактов на большинстве сайтов организаций). После этого злоумышленник начинает перебор пароля для известных ему электронных адресов, чем ставит под угрозу безопасность организации и доставляет неудобства пользователю, у которого постоянно блокируется учётная запись - что предпринимать в таком случае?


    вообще-то логин пользователя в АД и адрес его электропочты это две разные вещи. НЕЛЬЗЯ делать их одинаковыми с точки зрения безопасности. разделите мухи и котлеты и проблема блокировки исчезнет

    Не игнорируйте встроенную справку, читайте ее и большинство вопросов будет решено гораздо быстрее.

          А с точки зрения самих сервисов (и их корректной работы) рекомендуют делать UPN = почта.
    2 ноября 2018 г. 9:55
  • Смог решить проблему, благодаря статье:

    https://alanhardisty.wordpress.com/2010/12/01/increase-in-hacker-attempts-on-windows-exchange-servers-one-way-to-slow-them-down/

    Если вкратце, помогло снятие галочки "Обычная проверка подлинности" на соединителе Default Frontend (тот, что работает на 25 порту)

    • Помечено в качестве ответа Alex Nightingale 6 ноября 2018 г. 7:48
    6 ноября 2018 г. 7:48

Все ответы

  • Полагаю единственный разумный вариант защиты от перебора учеток - блокировка после нескольких неудачных попыток. Соответственно это делается уже в AD.
    25 октября 2018 г. 6:53
  • Я, возможно, не совсем корректно описал проблему - абсолютное большинство попыток подключений осуществляется с несуществующими учётными данными, то есть таких учёток нет в AD. Есть ли средства для решения проблемы следующим образом - допустим, если в OWA с одного IP введены несколько раз неверные учётные данные, то происходит блокировка (запрет аутентификации) IP-адреса сроком на 24 часа?

    Это могло бы решить и ещё одну проблему - допустим, у злоумышленника есть адрес почты действующего сотрудника организации и он пытается подобрать пароль. Я совсем недавно столкнулся с похожей проблемой - в AD с определённой периодичностью блокируется учётная запись пользователя - в логах КД вызывающим компьютером (источником блокировки) числится почтовый сервер, пароль данного сотрудника бессрочный (блокировка не может возникать из-за, например, старого пароля в мобильном приложении почты). Как мне выяснить, что именно является источником блокировки - действия злоумышленника или же что-то ещё?

    25 октября 2018 г. 7:30
  • При включенной блокировке УЗ и при утечке базы логинов - может быт реализован сценарий полной блокировки всех УЗ, кроме административных (которые без почтовых ящиков), элементарным скриптом с любой внешней машины.
    25 октября 2018 г. 12:38
  • При включенной блокировке УЗ и при утечке базы логинов - может быт реализован сценарий полной блокировки всех УЗ, кроме административных (которые без почтовых ящиков), элементарным скриптом с любой внешней машины.
    Хорошо подмечено!
    26 октября 2018 г. 6:49
  • Меня больше интересует не специфичный сценарий с утечкой базы логинов, а вполне распространённый случай, когда злоумышленник узнаёт внешний адрес почтового сервера, а также некоторые адреса почты сотрудников (по сути они не являются тайной - их можно найти, например, в разделе контактов на большинстве сайтов организаций). После этого злоумышленник начинает перебор пароля для известных ему электронных адресов, чем ставит под угрозу безопасность организации и доставляет неудобства пользователю, у которого постоянно блокируется учётная запись - что предпринимать в таком случае?
    26 октября 2018 г. 12:46
  • День добрый.

    Вариант очень простой. Внедрить MFA for Exchange 2016.

    Multi-Factor Authentication Adoption: Are You One of the 55%?

    Can Exchange Web Services be Accessed by Bypassing Multi-Factor Authentication?

    Office 2013 modern authentication public preview announced

    MFA например с использованием SMS.

    Exchange OWA and Multi-Factor Authentication

    Возможно использовать Hybrid Modern Authentication for Exchange On-Premises


    MCITP, MCSE. Regards, Oleg

    31 октября 2018 г. 16:55
    Модератор
  • Спасибо, решение интересное, хотя 2FA скорее дополнительная мера безопасности и не решает проблему в корне - журнал безопасности так и будет пестрить событиями о неудачных попытках входа в систему. А слышали что-нибудь про wail2ban (аналог линуксоидного fail2ban)?
    1 ноября 2018 г. 12:04
  • Меня больше интересует не специфичный сценарий с утечкой базы логинов, а вполне распространённый случай, когда злоумышленник узнаёт внешний адрес почтового сервера, а также некоторые адреса почты сотрудников (по сути они не являются тайной - их можно найти, например, в разделе контактов на большинстве сайтов организаций). После этого злоумышленник начинает перебор пароля для известных ему электронных адресов, чем ставит под угрозу безопасность организации и доставляет неудобства пользователю, у которого постоянно блокируется учётная запись - что предпринимать в таком случае?

    вообще-то логин пользователя в АД и адрес его электропочты это две разные вещи. НЕЛЬЗЯ делать их одинаковыми с точки зрения безопасности. разделите мухи и котлеты и проблема блокировки исчезнет

    ЗЫ Раскрою тему глубже. Я, например, Мих Михеевич Михеев, мой адрес Mih.Miheev@microsoft.com (ну предположим :) В этом случае нормальный хакер должен перепробовать логины на подключение к почте: mih, Mih.Miheev, Miheev, MiheevMM, MMMiheev, mmm, mm, m. Соответственно в домене у меня логин Ivan - пусть подбирают логин :)


    Не игнорируйте встроенную справку, читайте ее и большинство вопросов будет решено гораздо быстрее.


    • Изменено Mih Miheev 2 ноября 2018 г. 10:35 ЗЫ
    2 ноября 2018 г. 9:52
  • Меня больше интересует не специфичный сценарий с утечкой базы логинов, а вполне распространённый случай, когда злоумышленник узнаёт внешний адрес почтового сервера, а также некоторые адреса почты сотрудников (по сути они не являются тайной - их можно найти, например, в разделе контактов на большинстве сайтов организаций). После этого злоумышленник начинает перебор пароля для известных ему электронных адресов, чем ставит под угрозу безопасность организации и доставляет неудобства пользователю, у которого постоянно блокируется учётная запись - что предпринимать в таком случае?


    вообще-то логин пользователя в АД и адрес его электропочты это две разные вещи. НЕЛЬЗЯ делать их одинаковыми с точки зрения безопасности. разделите мухи и котлеты и проблема блокировки исчезнет

    Не игнорируйте встроенную справку, читайте ее и большинство вопросов будет решено гораздо быстрее.

          А с точки зрения самих сервисов (и их корректной работы) рекомендуют делать UPN = почта.
    2 ноября 2018 г. 9:55
  • Смог решить проблему, благодаря статье:

    https://alanhardisty.wordpress.com/2010/12/01/increase-in-hacker-attempts-on-windows-exchange-servers-one-way-to-slow-them-down/

    Если вкратце, помогло снятие галочки "Обычная проверка подлинности" на соединителе Default Frontend (тот, что работает на 25 порту)

    • Помечено в качестве ответа Alex Nightingale 6 ноября 2018 г. 7:48
    6 ноября 2018 г. 7:48