WindowsServer安全之启用安全审计策略记录失败登录

Windows Server 默认的登录失败记录往往只停留在事件查看器里几条零散的日志，等你发现服务器被暴力破解时，攻击者可能已经尝试了数千个密码。启用高级安全审计策略并精确配置失败登录的记录，是发现这类攻击最直接的手段。这不是简单的开启开关，而是需要针对“登录事件”和“账户登录事件”进行精细化配置，才能准确捕获是哪个源IP、通过什么协议、在什么时间发起的失败尝试。

很多人配置失败的原因在于没搞懂这两个类别的区别。登录事件（Logon/Logoff）记录的是在“本机”上发生的登录活动，比如你通过远程桌面直接登录到这台服务器，或者本地控制台登录。账户登录事件（Account Logon）记录的是域控制器对账户进行身份验证的活动。如果你的服务器是域成员，那么域登录的验证发生在域控制器上，成员服务器上只会记录账户登录事件，而不是登录事件。因此，要捕获针对域账户的暴力破解，必须在域控制器上启用账户登录事件的审核；要捕获针对本地账户或直接RDP登录成员服务器的失败尝试，则需要在目标服务器上启用登录事件审核。配置错误会导致日志一片空白，让你误以为服务器很安全。

不要再去用本地安全策略里的传统审核策略了，那个颗粒度太粗，会产生海量无用日志。必须使用高级审核策略配置。在域环境中，打开组策略管理控制台，找到Default Domain Controllers Policy或新建一个专门的安全审核GPO。导航到计算机配置 - 策略 - Windows 设置 - 安全设置 - 高级审核策略配置 - 审核策略。这里才是真正的控制台。

首先展开“账户登录”，双击“审核凭据验证”，勾选“配置以下审核事件”，然后只勾选“失败”。这个设置会在域控制器上记录所有使用密码凭据验证失败的请求，无论是Kerberos还是NTLM。接着在同一类别下，找到“审核Kerberos身份验证服务”，同样只勾选“失败”。这能捕获Kerberos预身份验证失败，也就是攻击者用错误密码请求TGT票据的行为。

然后展开“登录/注销”，双击“审核登录”，同样只勾选“失败”。这会在目标服务器上记录登录失败事件，比如RDP连接输入错误密码。再双击“审核特殊登录”，这个很多人会忽略，但它能记录管理员使用runas或通过计划任务触发的登录失败，也勾选“失败”。最后，如果你的服务器面向互联网开放了RDP端口，强烈建议在“对象访问”中启用“审核文件共享”和“审核详细文件共享”的失败记录，因为攻击者在获得立足点后往往会尝试访问共享文件夹，这些失败记录是横向移动的早期预警。

如果你管理的是独立服务器或工作组环境，或者需要批量部署，用auditpol命令行工具更高效。以管理员身份打开命令提示符，执行以下命令来启用账户登录失败审核：

auditpol /set /subcategory:"Credential Validation" /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /failure:enable

启用登录失败审核：

auditpol /set /subcategory:"Logon" /failure:enable
auditpol /set /subcategory:"Special Logon" /failure:enable

执行完毕后，用以下命令检查当前生效的策略：

auditpol /get /category:*

输出结果会列出每个子类别的启用状态，确保上述四项显示为“失败”。这个命令也可以写成脚本，通过组策略启动脚本或配置管理工具推送到所有服务器。

策略生效后，安全日志里会出现特定事件ID。对于账户登录失败，最核心的是事件ID 4771（Kerberos预身份验证失败）和4776（NTLM凭据验证失败）。4771事件会明确显示失败代码，0x18表示密码错误，0x12表示账户被禁用或过期，0x6表示用户名不存在。仔细看事件详情里的“客户端地址”字段，那就是攻击源IP。4776事件则记录工作站名称和错误代码，错误代码0xC000006A表示用户名正确但密码错误，0xC0000064表示用户名不存在。

对于登录失败，核心事件ID是4625。这个事件信息量极大。打开一条4625事件，重点看“账户名”和“域”字段，确认是哪个账户在遭受攻击。“失败原因”字段是百分比符号包裹的状态码，比如%%2313表示未知用户名或密码错误，%%2304表示账户被锁定。“进程ID”和“进程名”能告诉你攻击是通过哪个服务进来的，如果是RDP，进程名通常是C:\Windows\System32\svchost.exe，但更准确的判断方法是看“登录类型”。类型3是网络登录，比如访问共享文件夹；类型10是远程交互登录，也就是RDP；类型2是控制台登录。如果看到大量类型10的4625事件，而且源IP来自外部，基本可以确定RDP端口正在被扫描爆破。

4625事件里的“源网络地址”字段记录了发起登录请求的客户端IP。这是封堵攻击源的直接依据。但要注意，如果服务器前面有反向代理或负载均衡器，这个字段可能显示的是代理设备的IP。此时需要结合应用层日志或代理设备的X-Forwarded-For头来获取真实IP。对于RDP爆破，源网络地址就是攻击者IP，可以直接拿来用。对于SMB协议的攻击，4625事件同样会记录源IP。如果攻击者使用NTLM中继攻击，4776事件里的工作站名称可能会被伪造，但源IP通常无法伪造，所以IP是相对可靠的溯源依据。

安全日志默认大小只有20MB，在遭受暴力破解时几分钟就会被填满，导致早期关键日志被覆盖。必须增大日志容量。在事件查看器中，右键“安全”日志，选择属性，将最大日志大小设置为至少1GB，并选择“按需要覆盖事件”或“不覆盖事件”。更稳妥的做法是部署Windows事件转发或使用SIEM工具集中收集日志。攻击者拿到管理员权限后第一件事往往是清除安全日志，所以日志一旦写入本地，就面临被篡改的风险。通过配置事件订阅，将日志实时转发到专用的日志服务器，源服务器上只保留短期缓存，这样即使服务器被攻陷，攻击记录依然保留在远端。

配置事件转发需要在日志服务器上启用Windows事件收集器服务，并在源服务器上通过winrm quickconfig启用WinRM。然后在日志服务器上创建订阅，选择“源计算机已启动”类型，指定要收集的事件ID，比如4625和4771。订阅配置完成后，源服务器产生的每一条失败登录记录都会近乎实时地发送到日志服务器。

光记录不响应等于没记录。一旦安全日志里出现连续失败登录，应该触发自动封禁。这可以通过计划任务配合事件触发器来实现。在事件查看器中，右键一条4625事件，选择“将任务附加到此事件”，触发条件设置为“当记录的事件符合特定条件时”，筛选事件ID 4625，并可以进一步限定登录类型为10。操作部分启动一个PowerShell脚本，脚本内容从事件中提取源IP，然后创建一条Windows防火墙入站规则阻止该IP访问特定端口。

以下是一个精简版的自动封禁脚本示例，用于提取事件ID 4625中的源IP并添加防火墙规则：

$Event = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4625} -MaxEvents 1
$XML = [xml]$Event.ToXml()
$IP = ($XML.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'}).'#text'
if ($IP -and $IP -ne '-') {
    $ExistingRule = Get-NetFirewallRule -DisplayName "Block-$IP" -ErrorAction SilentlyContinue
    if (-not $ExistingRule) {
        New-NetFirewallRule -DisplayName "Block-$IP" -Direction Inbound -Action Block -RemoteAddress $IP -Protocol TCP -LocalPort 3389
    }
}

这个脚本取最新一条4625事件的源IP，检查是否已有同名防火墙规则，如果没有就创建一条阻止该IP访问3389端口的规则。将脚本保存为.ps1文件，在计划任务的操作里调用powershell.exe -File执行。更稳健的做法是设置一个阈值，比如5分钟内同一IP出现10次4625事件才触发封禁，避免误伤正常用户输错密码的情况。这可以通过在脚本里增加计数器逻辑来实现，或者使用第三方工具如RDPGuard，但内置功能已经足够应对大多数场景。

除了失败登录，还应该开启“审核账户管理”类别下的“审核用户账户管理”失败和成功事件。这能记录谁创建了用户、谁修改了组成员关系。攻击者提权后往往会创建后门账户或将自己加入管理员组，这些操作会触发事件ID 4720（用户创建）、4728（成员添加到全局安全组）、4732（成员添加到本地安全组）。开启这些审核，结合失败登录记录，可以形成完整的攻击链还原。

另外，在“审核策略更改”类别下启用“审核审核策略更改”的成功和失败事件，可以防止攻击者关闭审核策略。事件ID 4719记录审核策略被修改，一旦出现非预期的4719事件，说明有人试图关闭你的安全监控。

配置完成后务必进行测试。用一台测试机，故意输入错误密码尝试RDP登录目标服务器，然后在目标服务器上打开事件查看器，筛选事件ID 4625，确认能看到失败记录，并且源IP正确显示。再到域控制器上，用错误密码尝试登录域账户，筛选事件ID 4771或4776，确认记录生成。如果看不到日志，检查高级审核策略是否被传统审核策略覆盖。组策略里有一个强制设置：“强制审核策略子类别设置覆盖审核策略类别设置”，这个必须启用，否则传统审核策略会优先于高级审核策略，导致你的精细配置不生效。

整个配置过程的核心在于理解不同事件ID的产生场景和位置，将日志集中存储并关联分析，最后配合自动化脚本实现从检测到响应的闭环。这样一套组合拳下来，任何针对Windows服务器的登录爆破行为都会在第一时间被记录、告警和封禁，而不是等到服务器失陷后才去翻找早已被覆盖的日志。