事件ID 4625和logintypes3在我的事件日志中有很多审核失败。
这个问题是否构成我的服务器（内部服务或应用程序）？ 或者这是蛮力攻击？ 最后，我怎样才能find这个login的来源，并解决问题？
这是“常规”选项卡中的详细信息：
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 - 我在服务器上有相同types的事件。 有数百次不同用户名的login尝试，但没有可见的进程ID或IP地址。
我很确定它来自RDP连接通过互联网没有networking级authentication。
这些是黑客攻击。 攻击者的目标是蛮横暴力您的服务器的帐户/密码。
我build议安装一个简单的入侵检测系统（IDS）。 你可能要考虑RDPGuard（商业），IPBan，evlWatcher。 我自己我使用Cyberarms IDDS。 这个很简单，有一个友好的界面（不过需要.NET Framework 4.0）。
这个想法很简单：IDS监视您的服务器的安全日志中的可疑login失败事件。 然后它软锁IP地址（es），尝试来自。 您也可以在来自软锁IP的尝试继续时configuration硬锁。
发生这种情况时，有没有碰巧有一个域控制器被closures？ 这看起来非常类似于本文中描述的情况：
https://support.microsoft.com/en-us/kb/2683606
当Windows进入closures状态时，它应该告诉新客户端尝试对DC进行身份validation，以便他们需要联系不同的DC。 但是，在某些情况下，DC会回复用户不存在的客户端。 这将导致重复的身份validation失败，直到域控制器最终完成closures并且客户端被迫切换DC。
本文中提出的解决scheme是在closures服务器之前停止域控制器上的netlogon服务。 这使得身份validation在进入closures状态之前不可用，并强制客户端find新的DC。
这个事件通常是由一个陈旧的隐藏证书造成的。 尝试从系统给出这个错误：
从命令提示符处运行： psexec -i -s -d cmd.exe
从新的cmd窗口运行： rundll32 keymgr.dll,KRShowKeyMgr
删除存储的用户名和密码列表中出现的任何项目。 重新启动计算机。