Назад | Перейти на главную страницу

Как найти источник идентификатора события 4625 в 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 - 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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