Как найти источник 4625 Event ID в Windows Server 2012

У меня много ошибок аудита с идентификатором 4625 и типом входа 3 в моем журнале событий.

Эта проблема с моего сервера (внутренние службы или приложения)? Или это атака грубой силой? Наконец, как я могу найти источник этих логинов и решить проблему?

Это подробная информация на вкладке Общие:

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:       aaman
    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:   test2
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

**And this is detailed information in Detail Tab:**

+ System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 

   EventID 4625 

   Version 0 

   Level 0 

   Task 12544 

   Opcode 0 

   Keywords 0x8010000000000000 

  - TimeCreated 

   [ SystemTime]  2015-05-09T06:57:00.043746400Z 

   EventRecordID 2366430 

   Correlation 

  - Execution 

   [ ProcessID]  696 
   [ ThreadID]  716 

   Channel Security 

   Computer WIN-24E2M40BR7H 

   Security 


- EventData 

  SubjectUserSid S-1-0-0 
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName aaman 
  TargetDomainName  
  Status 0xc000006d 
  FailureReason %%2313 
  SubStatus 0xc0000064 
  LogonType 3 
  LogonProcessName NtLmSsp  
  AuthenticationPackageName NTLM 
  WorkstationName test2 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress - 
  IpPort - 

У меня был такой же тип событий на сервере. Были сотни попыток входа в систему с разными именами пользователей, но не было видно ни идентификатора процесса, ни IP-адреса.

Я почти уверен, что он исходил от RDP-соединений через Интернет без аутентификации на уровне сети.

Рабочее решение я нашел здесь: https://github.com/DigitalRuby/IPBan

В Windows Server 2008 или аналогичной версии следует отключить входы NTLM и разрешить только входы NTLM2. В Windows Server 2008 нет способа получить IP-адрес для входа в систему NTLM. Используйте secpol -> локальные политики -> параметры безопасности -> сетевая безопасность, чтобы ограничить входящий ntlm-трафик ntlm -> запретить все учетные записи.

В RU версии: Локальная политика безопасности -> Локальные политики -> Параметры безопасности -> Сетевая безопасность: ограничение NTLM: входящий трафик NTLM -> Запретить все учетные записи

Это хакерские атаки. Цель злоумышленников - взломать учетные записи / пароли вашего сервера.

Я бы предложил установить простую систему обнаружения вторжений (IDS). Вы можете рассмотреть RDPGuard (коммерческий), IPBan, evlWatcher. Я сам использую Cyberrarms IDDS. Это простой, дружественный интерфейс (хотя требуется .NET Framework 4.0).

Идея проста: IDS отслеживает журнал безопасности вашего сервера на наличие подозрительных событий сбоя входа в систему. Затем он мягко блокирует IP-адрес (а), с которого была получена попытка. Вы также можете настроить жесткую блокировку, когда попытки с IP-адресов с программной блокировкой продолжатся.

Случалось ли, что Контроллер домена был закрыт, когда это произошло? Это выглядит очень похоже на сценарий, описанный в этой статье:

https://support.microsoft.com/en-us/kb/2683606

Когда Windows входит в состояние выключения, она должна сообщить новым клиентам, пытающимся пройти аутентификацию на контроллере домена, о том, что им нужно связаться с другим контроллером домена. Однако в некоторых случаях контроллер домена отвечает клиенту, что пользователь не существует. Это приведет к повторным ошибкам аутентификации, пока контроллер домена не завершит работу и клиент не будет вынужден переключать контроллеры домена.

Решение, предложенное в этой статье, заключается в остановке службы netlogon на контроллере домена перед выключением сервера. Это делает его недоступным для аутентификаций до его перехода в состояние завершения работы и вынуждает клиента находить новый DC.

Это событие обычно вызывается устаревшими скрытыми учетными данными. Попробуйте это из системы, выдавшей ошибку:

Из командной строки запустите: psexec -i -s -d cmd.exe
Из нового окна cmd запустите: rundll32 keymgr.dll,KRShowKeyMgr

Удалите все элементы, которые появляются в списке сохраненных имен пользователей и паролей. Перезагрузите компьютер.