Идентификатор события журнала безопасности 4625 - учетной записи не удалось войти в систему каждые несколько минут - случайные исходные IP-адреса
Достаточно новая установка виртуальной машины MS Windows Server 2019 регистрирует более сотни сбоев аудита журнала безопасности в день с идентификатором события 4625.
RDP для сервера сервер включен только для одного доверенного IP-адреса источника глобальной сети через брандмауэр Draytek.
На сервере размещены 2 локальных приложения и локальный сервер Exchange. PDC - это еще одна виртуальная машина на том же физическом хосте Hyper-V Core.
Имена учетных записей, исходные IP-адреса и имена рабочих станций кажутся случайными, хотя имя рабочей станции «рабочая станция» встречается довольно часто.
Пример записи журнала:
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: Hp
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: workstation
Source Network Address: 40.117.34.82
Source Port: 0
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
Итак, мои непосредственные мысли:
- Я думал, что NTLM отключен по умолчанию, начиная с Win Server 2008?
- Правильно ли я полагаю, что в данном случае это не так?
- Должен ли я отключить это? Если да, то где?
- Может ли что-нибудь сломаться? Если приложения ломаются, ничего страшного, если это делает сервер более безопасным. Я могу заставить разработчиков приложений улучшить приложения. Я боюсь потерять доступ удаленного администратора через TeamViewer и сломать почтовый сервер Exchange.
Я как бы гадю прямо сейчас, потому что мы только что установили этот сервер, чтобы заменить старый Windows Server 2011, который был поражен программой-вымогателем.
Я слышал об использовании таких программ, как IPBan, но это имело бы смысл, только если бы попытки были с одного IP. В данном случае кажется, что они поступают со случайных адресов.
Прав ли я, думая, что открытие необходимых портов для Exchange Server (80 443 587) является единственной причиной, по которой эти попытки с IP-адресов WAN даже достигают сервера? Могу ли я что-нибудь сделать, чтобы предотвратить попытки входа в систему до сервера, или это уровень вторжения, которого следует ожидать при запуске сервера Exchange?
Согласитесь с тем, что joeqwerty сказал выше, и на основании ваших сообщений об ошибках, которые вы предоставили выше, я обнаружил, что эта проблема может быть вызвана входом пользователя в систему с ошибкой или неправильной учетной записью. : 4625 (F): не удалось войти в учетную запись. и Событие безопасности с идентификатором 4625 не содержит имя учетной записи пользователя на компьютере под управлением Windows Vista, Windows Server 2008, Windows 7 или Windows Server 2008 R2
Кроме того, я думаю, вы могли бы разместите свой вопрос на форуме Windows Server, и вы сможете получить более точные ответы.
думал, что NTLM отключен по умолчанию, так как Win Server 2008 г. и далее
Протокол NTLMV1 и хэш LM были отключены.
Могу ли я что-нибудь сделать, чтобы предотвратить попытки входа в систему на сервер?
Вы не хотите, чтобы попытки аутентификации не доходили до сервер.
Прав ли я, думая, что открытие необходимых портов для Exchange Server (80 443 587) является единственной причиной, по которой эти попытки с IP-адресов WAN даже достигают сервера?
Порт 587 используется для такого рода аутентифицированный трафик. (Запрос / ответ - не единственный вид аутентификации, который может обрабатывать сервер Exchange). Если вы не используете POP или IMAP, вы можете закрыть этот порт и получить меньше запросов проверки подлинности NTLMSSP.
Вы также можете отключить службу NTLMV2, если вы не используете ее для чего-то другого. Если у вас правильно настроен Kerebos для внутренней аутентификации, и у вас нет других приложений, использующих аутентификацию по запросу / ответу. Это не остановит TCP-соединения, но, вероятно, предотвратит их распознавание как запросы аутентификации. Есть некоторые различия, поэтому вы можете заметить некоторые вещи, которые не работают одинаково
Отключение SMTP_AUTH теперь рекомендуется для Exchange 365 - используются другие формы аутентификации клиента. Это означает отключение порта 587. На сервере Exchange «Отключение SMTP_AUTH» означает «разрешить неаутентифицированный SMTP-трафик», чего вы не хотите делать, пока не узнаете, что делаете.
Правильно ли я подумал, что необходимо открыть необходимые порты для Exchange Server (80 443 587) - единственная причина, по которой эти попытки IP-адреса в глобальной сети даже доходят до сервера?
Ну да. Если эти порты открыты из Интернета на ваш сервер Exchange, то этого я и ожидал.
Могу ли я что-нибудь сделать, чтобы предотвратить попытки входа в систему? достигая сервера, или это ожидаемый уровень вторжения при запуске сервера Exchange?
Если вы не хотите, чтобы эти попытки входа в систему доходили до сервера, не открывайте эти порты из Интернета на сервер. Конечно, это лишило бы законных пользователей возможности доступа к своим почтовым ящикам на сервере. Если вы хотите, чтобы сервер был доступен из Интернета для законных пользователей, вам придется смириться с этим. IDS / IPS может помочь заблокировать некоторые незаконные попытки, но, вероятно, не устранит все из них.