我有一个Windows 2008 R2系统,它每天在Windows日志的安全部分显示数千个带有登录类型8 (NetworkCleartext)的4625个登录失败错误。没有试图获得源网络地址中列出的访问权限的系统的IP地址,所以我为阻止经常失败的IP而构建的脚本无法找到它们。
这些登录尝试可能来自哪些服务?
下面是其中一个例子:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: server-name$
Account Domain: example
Logon ID: 0x3e7
Logon Type: 8
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: Administrator
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x4d0
Caller Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name: system-name
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
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.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
发布于 2014-01-30 03:59:57
有多个登录源可能会生成这些错误:
数字2和3在WindowsSecurity.com中提到:
此登录类型表示类似于登录类型3的网络登录,但密码是在明文中通过网络发送的。Windows服务器不允许连接到具有明文身份验证的共享文件或打印机。我知道的唯一情况是使用ADVAPI从ASP脚本中登录,或者当用户使用IIS的基本身份验证模式登录到IIS时。在这两种情况下,事件描述中的登录过程都会列出advapi。只有在SSL会话(即https)中没有包装时,基本身份验证才是危险的。至于ASP生成的登录,脚本请记住,在源代码中嵌入密码是维护目的的错误做法,也是恶意查看源代码从而获得密码的风险。
发布于 2014-01-29 20:50:39
我会运行一个netstat -a -n | find "1232"
来查看进程ID (PID) 1232正在侦听的端口。这就是导致身份验证失败的PID。您可以在这些端口上嗅探传入的通信量,以跟踪源。
(我很难想出运行进程内w/ svchost.exe
并侦听身份验证的服务。我几乎感觉到第三方.)
发布于 2014-12-13 17:46:24
登录类型8发生时,密码是通过网络发送的明文。IIS中的基本身份验证是这种登录失败的最可能原因。据我所知,有五种常用的基于Microsoft的服务,通过终端用户通过桌面或移动设备进行基本身份验证,即OWA客户端、MS Exchange ActiveSync、Outlook、FTP客户端和SharePoint服务器。
当终端用户将启用基本身份验证的OWA客户端与错误密码的桌面-pc/移动设备连接时,登录类型为8的事件4625将登录在承载OWA的Exchange中。
查看本文:http://www.morgantechspace.com/2014/12/Find-Account-Lockout-Source-for-Logon-Type-8.html
https://serverfault.com/questions/570842
复制相似问题