it-swarm-pt.tech

Como encontrar a fonte do 4625 Event ID no Windows Server 2012

Tenho muitas falhas de auditoria com o ID de evento 4625 e o Tipo de logon 3 no meu log de eventos.

Esse problema está no meu servidor (serviços ou aplicativos internos)? Ou isso é ataque de força bruta? Finalmente, como posso encontrar a origem desses logins e resolver o problema?

Esta é uma informação detalhada na guia Geral:

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 - 

Solução de trabalho que encontrei aqui: https://github.com/DigitalRuby/IPBan

No Windows Server 2008 ou equivalente, você deve desativar os logins NTLM e permitir apenas logons NTLM2. No Windows Server 2008, não há como obter o endereço IP dos logons do NTLM. Use secpol -> diretivas locais -> opções de segurança -> segurança da rede restrinja o tráfego ntlm de entrada ntlm -> negue todas as contas.

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

3
Igor Ostroumov

Eu tive o mesmo tipo de eventos em um servidor. Houve centenas de tentativas de login com nomes de usuário diferentes, mas nenhum ID do processo ou endereço IP visível.

Tenho certeza de que era proveniente de conexões RDP pela Internet sem autenticação no nível da rede.

3
alphanimal

Estes são os ataques de hackers. O objetivo dos atacantes é forçar com força as contas/senhas do servidor.

Eu sugeriria a instalação de um sistema simples de detecção de intrusões (IDS). Você pode considerar RDPGuard (comercial), IPBan, evlWatcher. Eu mesmo uso o Cyberarms IDDS. Essa é simples, possui uma interface amigável (embora seja necessário o .NET Framework 4.0).

A idéia é simples: o IDS monitora o log de segurança do servidor em busca de eventos suspeitos de falha de logon. Em seguida, ele bloqueia os endereços IP de onde vem a tentativa. Você também pode configurar um bloqueio físico quando as tentativas dos IPs com bloqueio automático continuarem.

1
Interface Unknown

Esse evento geralmente é causado por uma credencial oculta antiga. Tente isso no sistema que deu o erro:

Em um prompt de comando, execute: psexec -i -s -d cmd.exe
Na nova janela do cmd, execute: rundll32 keymgr.dll,KRShowKeyMgr

Remova todos os itens que aparecem na lista de nomes de usuário e senhas armazenados. Reinicie o computador.

0
zea62

Havia um Controlador de Domínio sendo desligado quando isso aconteceu? Isso é notavelmente semelhante ao cenário descrito neste artigo:

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

Quando o Windows entra no estado de desligamento, ele deve informar aos novos clientes que tentam se autenticar no DC que precisam entrar em contato com um DC diferente. Em alguns casos, porém, o DC responderá ao cliente que o usuário não existe.Isso causará falhas de autenticação repetidas até que o controlador de domínio termine de desligar e o cliente seja forçado a mudar de controlador de domínio.

A solução proposta neste artigo é interromper o serviço de logon de rede no controlador de domínio antes de desligar o servidor. Isso o torna indisponível para autenticações antes de entrar no estado de desligamento e força o cliente a encontrar um novo controlador de domínio.

0
brassmaster