Довольно новая установка виртуальной машины MS Windows Server 2019 регистрирует более сотни сбоев аудита журнала безопасности в день с идентификатором события 4625.
RDP для сервера включен только для одного доверенного IP-адреса источника WAN через межсетевой экран 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.
Итак, мои непосредственные мысли:
Я как бы обосрался прямо сейчас, потому что мы только что установили этот сервер, чтобы заменить старый Windows Server 2011, который был поражен программой-вымогателем.
Я слышал об использовании таких программ, как IPBan, но это имело бы смысл, только если бы попытки были с одного IP. В этом случае они кажутся со случайных адресов.
Прав ли я, думая, что открытие необходимых портов для Exchange Server (80 443 587) является единственной причиной, по которой эти попытки с IP-адресов WAN даже достигают сервера? Могу ли я что-нибудь сделать, чтобы эти попытки входа в систему не достигли сервера, или это ожидаемый уровень вторжения при запуске сервера Exchange?
Прав ли я, думая, что открытие необходимых портов для Exchange Server (80 443 587) является единственной причиной, по которой эти попытки с IP-адресов WAN даже достигают сервера?
Ну да. Если у вас есть открытые порты из Интернета на ваш сервер Exchange, то этого я и ожидал.
Могу ли я что-нибудь сделать, чтобы предотвратить попытки входа в систему до сервера, или это уровень вторжения, которого следует ожидать при запуске сервера Exchange?
Если вы не хотите, чтобы эти попытки входа в систему доходили до сервера, не открывайте эти порты из Интернета на сервер. Конечно, это лишило бы законных пользователей возможности доступа к своим почтовым ящикам на сервере. Если вы хотите, чтобы сервер был доступен из Интернета для законных пользователей, вам придется смириться с этим. IDS / IPS может помочь заблокировать некоторые незаконные попытки, но, вероятно, не устранит все из них.
Согласитесь с тем, что joeqwerty сказал выше, и на основе ваших сообщений об ошибках, которые вы предоставили выше, я обнаружил, что эта проблема может быть вызвана входом пользователя в систему с ошибкой или неправильной учетной записью. Для получения более подробной информации: 4625 (F): не удалось войти в учетную запись. и Событие безопасности, имеющее идентификатор события 4625, не содержит имя учетной записи пользователя на компьютере под управлением Windows Vista, Windows Server 2008, Windows 7 или Windows Server 2008 R2.
Кроме того, я думаю, что вы могли бы разместить свой вопрос на форуме сервера Windows, это будет лучшим выбором, и вы сможете получить более точные ответы.
думал, что 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-трафик», чего вы не хотите делать, пока не узнаете, что делаете.