Я постоянно получаю сообщения о событии 4625 о том, что учетные записи не могут войти в систему с несуществующими именами пользователей. Такие имена, как: ПРОДАЖИ, ПОЛЬЗОВАТЕЛЬ, ТЕСТ, HELPDESK, ПОДДЕРЖКА, PROGRAMMER не являются нашими пользователями, но мы получаем около 20 сообщений каждую минуту о том, что такие учетные записи, как эти, пытаются войти в систему. Я могу только сделать вывод, что это должна быть атака грубой силой. Я уже убедился, что RDP НЕ общедоступен. Я могу сказать, что они поступают извне домена, потому что NTLM останавливает их, однако я не могу занести IP-адреса в черный список, потому что информация о сети в сообщениях о событиях пуста. Что мне делать в этой ситуации?
Не удалось войти в учетную запись.
Тема: Я могу сказать, что они поступают извне домена, потому что NTLM останавливает их, однако я не могу занести IP-адреса в черный список, потому что информация о сети в сообщениях о событиях пуста. Что мне делать в этой ситуации?
Не удалось войти в учетную запись.
Тема: Я могу сказать, что они поступают извне домена, потому что NTLM останавливает их, однако я не могу занести IP-адреса в черный список, потому что информация о сети в сообщениях о событиях пуста. Что мне делать в этой ситуации?
Не удалось войти в учетную запись.
Тема: Идентификатор безопасности: NULL SID Имя учетной записи: - Домен учетной записи: - Идентификатор входа: 0x0
Тип входа: 3
Учетная запись, для которой не удалось войти в систему: Идентификатор безопасности: NULL SID Имя учетной записи: POSTERMINAL1 Домен учетной записи:
Информация об ошибке: Причина сбоя: неизвестное имя пользователя или неверный пароль. Статус: 0xC000006D Дополнительный статус: 0xC0000064
Информация о процессе: Идентификатор вызывающего процесса: 0x0 Имя вызывающего процесса: -
Сетевая информация:
Имя рабочей станции:
Исходный сетевой адрес: -
Исходный порт: -
Эта информация будет скрыта, пока у вас установлен протокол RDP для согласования безопасности с TLS / SSL и NLA. Если вы снизите уровень безопасности до простого шифрования RDP, вы получите больше информации в этих записях журнала. Очевидно, это не идеальный подход, так как это ослабляет вашу позицию по безопасности.
Попробуйте посмотреть этот журнал: Журналы приложений и служб> Microsoft> Windows>> RemoteDesktopServices-RdpCoreTS> Operational
Посмотрите, есть ли 140 событий (генерируется при использовании поддельного имени) или 131 событие (неудачное, но допустимое имя). В описании к ним должен быть указан исходный IP.
PureRDS хорошо написал об этом ранее в этом году: http://purerds.org/remote-desktop-security/auditing-remote-desktop- services-logon-failures-1 /
Включите аудит проверки подлинности NTLM и проверьте 4776 сбоев в журнале «Журналы приложений и служб \ Microsoft \ Windows \ NTLM \ Operational», чтобы увидеть реальный источник.