Защита Exchange от брутфорса: SMTP AUTH, OWA и ActiveSync

Exchange Server публикует в интернет сразу несколько точек, где принимается пароль: OWA, ActiveSync, EWS, Autodiscover и SMTP AUTH. Каждую перебирают боты. Поэтому защита Exchange от брутфорса сложнее, чем защита одного RDP: у каждой службы свой лог и свой признак неудачного входа. Разберём, где искать перебор, как находить IP атакующих и где подвох с reverse proxy.

Почему перебор паролей к Exchange опаснее, чем кажется

Кроме очевидного риска подбора пароля, у перебора есть побочный эффект. Если в домене включена политика блокировки учётных записей, бот, подбирающий пароль к ящику сотрудника, блокирует его учётную запись в Active Directory. Сотрудник теряет доступ не только к почте, но и ко всему остальному. Блокировка атакующего IP решает эту проблему, блокировка учётной записи нет.

Базовые меры защиты Exchange

• Не публикуйте лишнее. Центр администрирования (/ecp) снаружи обычно не нужен. Закройте его на reverse proxy или ограничьте доступ по IP.
• Уходите от базовой проверки подлинности. Basic auth для ActiveSync, EWS и SMTP проще всего перебирать. В свежих версиях Exchange 2019 доступна современная проверка подлинности через AD FS.
• Отключите SMTP AUTH там, где он не нужен. На соединителе для приёма почты из интернета (порт 25) он, как правило, не нужен. Клиентам хватает соединителя на порту 587.
• Следите за обновлениями. Критичные уязвимости Exchange опаснее любого перебора.

Перебор SMTP AUTH: логи протокола

Попытки входа по SMTP видны в логах протокола соединителей получения. По умолчанию подробное логирование выключено, включите его для клиентского соединителя:

Set-ReceiveConnector "EX01\Client Frontend EX01" -ProtocolLoggingLevel Verbose

Логи пишутся в %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive. Неудачный вход выглядит как ответ 535 5.7.3 Authentication unsuccessful, а попытка использовать неподдерживаемый способ входа как 504 5.7.4 Unrecognized authentication type. Кроме того, Exchange пишет в журнал Windows событие MSExchangeTransport с ошибкой LogonDenied.

Сводка по адресам за последние 2 часа:

$dir = Join-Path $env:ExchangeInstallPath 'TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive'
Get-ChildItem $dir -Filter *.log | Where-Object LastWriteTime -gt (Get-Date).AddHours(-2) |
  ForEach-Object { Get-Content $_.FullName } |
  Where-Object { $_ -match '535 5\.7\.3|504 5\.7\.4' } |
  ForEach-Object { ($_ -split ',')[5] -replace ':\d+$', '' } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name -First 20

Шестое поле строки лога (remote-endpoint) содержит IP и порт клиента, порт скрипт отрезает.

Перебор ActiveSync, EWS и Autodiscover: логи IIS

ActiveSync, EWS, Autodiscover и другие веб-службы Exchange работают через IIS. Внешние клиенты подключаются к сайту Default Web Site, его логи лежат в C:\inetpub\logs\LogFiles\W3SVC1.

Главная ловушка здесь в коде 401. При проверке подлинности NTLM и Kerberos сервер сначала всегда отвечает 401, это нормальная часть рукопожатия. Считать все 401 нельзя, иначе заблокируете собственных пользователей. Неверный пароль отличается подстатусом и кодом ошибки Windows:

Скрипт разбирает логи с учётом заголовка #Fields, поэтому не зависит от набора полей в вашем IIS:

$Since = (Get-Date).ToUniversalTime().AddHours(-2)   # IIS пишет время в UTC
$Fail  = @('1326', '2148074252')
$hits = foreach ($f in Get-ChildItem 'C:\inetpub\logs\LogFiles\W3SVC1' -Filter *.log |
                  Where-Object LastWriteTime -gt (Get-Date).AddHours(-2)) {
  $fields = $null
  foreach ($line in Get-Content $f.FullName) {
    if ($line.StartsWith('#Fields:')) { $fields = $line.Substring(9).Split(' '); continue }
    if ($line.StartsWith('#') -or -not $fields) { continue }
    $v = $line.Split(' '); $r = @{}
    for ($i = 0; $i -lt $fields.Count; $i++) { $r[$fields[$i]] = $v[$i] }
    if ($r['sc-status'] -eq '401' -and $r['sc-substatus'] -eq '1' -and $r['sc-win32-status'] -in $Fail -and
        [datetime]"$($r['date']) $($r['time'])" -ge $Since) { $r['c-ip'] }
  }
}
$hits | Group-Object | Where-Object Count -ge 10 | Sort-Object Count -Descending | Select-Object Count, Name

Найденные адреса блокируются так же, как в статье о защите RDP: правилом брандмауэра Windows, только на портах 443 и 587 или на всех.

А что с OWA?

Вход в OWA через форму отправляется запросом POST /owa/auth.owa, и IIS отвечает перенаправлением 302 и при верном, и при неверном пароле. По логу IIS неудачный вход в OWA не отличить от удачного. Неудачная попытка оставляет событие 4625 в журнале безопасности сервера Exchange. Есть ли в нём IP клиента, зависит от схемы публикации, проверьте это на своём сервере, прежде чем строить на нём блокировку.

Reverse proxy и балансировщик: чей IP вы видите

Если Exchange опубликован через reverse proxy или балансировщик, в логах IIS и SMTP вместо адреса атакующего будет адрес прокси. Заблокировав его, вы отключите почту всем. Варианты:

• блокировать атакующих на самом прокси, где виден настоящий IP клиента;
• передавать настоящий адрес в заголовке X-Forwarded-For и добавить это поле в логи IIS;
• в любом случае внести адрес прокси в исключения всех скриптов и программ, которые блокируют IP.

Защита Exchange от брутфорса в KIPBan

Агент KIPBan на Windows ловит перебор SMTP AUTH: читает логи протокола в папке установки Exchange по умолчанию и события LogonDenied транспортной службы. Логи протокола на соединителе должны быть включены, как описано выше. Отдельного правила для OWA, ActiveSync и EWS в KIPBan пока нет, для них используйте разбор логов IIS из этой статьи.

Заголовок X-Forwarded-For агент не читает. Если перед Exchange стоит прокси с публичным адресом, внесите этот адрес в whitelist KIPBan, иначе агент может заблокировать сам прокси. Адреса локальной сети агент не блокирует никогда.

Зато всё, что агент поймал, уходит в общий бан-лист: IP, перебиравший SMTP на почтовом сервере, в течение 5 минут блокируется и на ваших RDP-, SQL- и Linux-серверах. Как это работает, читайте в статье «Fail2ban для Windows». Официальные рекомендации по соединителям получения есть в документации Microsoft.

Вопросы про защиту Exchange