发布于11小时前11小时 背景内网授权测试中,扫描器经常把“SMB 签名未强制”直接标成高危,但这不等于目标一定能够被中继利用。实际风险取决于客户端是否会发起 NTLM 认证、服务端是否拒绝未签名会话、是否存在 EPA 或通道绑定,以及攻击路径能否跨越当前权限边界。下面按问答中心常见排障方式,给出一套低影响复核流程。测试前应明确目标 IP、允许的认证方式和时间窗口;不要在未授权网段诱导认证,也不要采集或离线破解口令材料。问题一:扫描结果中的 enabled 与 required 有什么区别?SMB 支持签名和强制签名是两个不同状态。服务端支持签名但不强制时,客户端可能建立未签名会话,这才形成典型 NTLM 中继的必要条件之一。反过来,即使服务端强制签名,如果同一主机上的 LDAP、HTTP 或 AD CS Web Enrollment 存在弱绑定,仍需分别检查,不能用 SMB 的结论覆盖其他协议。状态含义处置判断EnableSecuritySignature=True服务端支持 SMB 签名不能单独证明安全RequireSecuritySignature=True服务端拒绝未签名会话可阻断典型 SMB 中继落点客户端 RequireSecuritySignature=False客户端可能接受或发起未强制签名的连接需结合认证流向评估问题定位:先确认协议、角色和配置来源建议先区分域控、成员服务器、工作站和 NAS。Windows 本机值还可能被域组策略覆盖,因此既要看运行时配置,也要看策略结果。以下命令均为只读检查,适合在已授权的管理员会话中执行。Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature,EnableSMB1Protocol,EnableSMB2Protocol Get-SmbClientConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature gpresult /scope computer /h C:\\Windows\\Temp\\computer-gpo.html reg query HKLM\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters /v RequireSecuritySignature reg query HKLM\\SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters /v RequireSecuritySignature # 从测试机做非认证、低影响枚举;只验证方言与签名状态 nmap -Pn -p445 --script smb-protocols,smb2-security-mode 10.20.30.15读取 nmap 结果时,重点看 SMB 2/3 是否启用,以及消息签名是否为 required。不要因为发现 SMBv1 关闭就结束检查:SMBv2/3 在未强制签名时同样可能成为中继落点。技术分析:如何确认它是可利用路径,而不是孤立配置项?建议用“认证来源、传输路径、目标落点、权限结果”四段式建模:认证来源:是否确有服务器账户、管理员账户或普通用户会向测试节点发起 NTLM,而不是仅凭理论推断。传输路径:445/TCP 是否双向可达,主机防火墙、VLAN ACL 与终端隔离是否允许该流量。目标落点:目标是否不强制签名;若检查 LDAP 或 IIS,还要单独核对 LDAP signing、channel binding 和 EPA。权限结果:被中继身份在目标上是否具备管理、写目录对象或访问敏感共享的权限。配置弱点不应自动等同于域管权限。在生产环境中,优先采用“配置证据加日志关联”完成验证。若合同确实要求概念验证,应使用专门测试账户和隔离目标,只证明会话被拒绝或接受,不执行服务创建、计划任务、凭据转储等后续动作。操作步骤:从端口证据关联到主机日志第一步,在扫描端保存 UTC 时间、源地址、目标地址和命令输出。第二步,在目标侧检查 SMB Server 审计日志及安全日志。第三步,用防火墙或流量日志确认连接实际到达,避免把 ACL 阻断误判为协议安全。# 查看 SMB 服务端相关日志通道 wevtutil gl Microsoft-Windows-SMBServer/Audit wevtutil qe Microsoft-Windows-SMBServer/Audit /rd:true /c:30 /f:text # 查询最近 30 分钟的网络登录事件;生产环境建议追加目标 IP、账户等过滤条件 $start = (Get-Date).AddMinutes(-30) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625; StartTime=$start} | Select-Object TimeCreated,Id,MachineName,Message # 检查 Windows 防火墙是否存在放宽的 SMB 入站规则 Get-NetFirewallRule -Enabled True -Direction Inbound | Where-Object DisplayGroup -eq 'File and Printer Sharing' | Get-NetFirewallPortFilter事件 4624 中需要关注 Logon Type 3、Authentication Package、源工作站和源地址。仅看到 NTLM 不代表发生中继;还需要与同一时间窗内的 445 连接、目标账户权限和 SMB 审计记录对应。4625 则可辅助判断失败原因,例如账户限制、错误凭据或策略拒绝。排障经验:扫描器与 PowerShell 结果不一致时,先确认是否扫到了负载均衡后的另一节点、NAS 虚拟 IP 或旧系统;再检查 GPO 是否刚更新但服务尚未重新读取配置。保留每台节点的独立证据,不要只记录 VIP。问题二:怎样做最小影响的验证?推荐分三级控制验证强度:一级:仅用 smb2-security-mode 和本机配置确认签名要求,适合生产首轮复核。二级:使用无特权测试账户访问专门共享,确认正常业务在启用签名后不受影响,并采集客户端与服务端日志。三级:仅在隔离演练环境复现认证转发,使用无业务权限账户和空白目标;成功标准止于会话建立,不做持久化、执行命令或读取业务数据。如果一级证据已经显示未强制签名,且资产存在明确的 NTLM 认证来源和管理权限关系,通常无需在生产环境继续实施主动中继。报告中把“必要条件已满足”和“完整攻击链已验证”分开表述即可。修复建议与回归验证Windows 服务端可通过域组策略启用“Microsoft 网络服务器:对通信进行数字签名(始终)”,客户端对应启用“Microsoft 网络客户端:对通信进行数字签名(始终)”。不要只改注册表后就结束,应让策略集中下发,并检查例外资产。# 示例:本机临时整改验证。域环境最终应由 GPO 统一管理。 Set-SmbServerConfiguration -RequireSecuritySignature $true -Force Set-SmbClientConfiguration -RequireSecuritySignature $true -Force # 刷新策略并复核实际状态 gpupdate /force Get-SmbServerConfiguration | Select-Object RequireSecuritySignature Get-SmbClientConfiguration | Select-Object RequireSecuritySignature整改前要盘点老旧 NAS、打印设备、非 Windows SMB 客户端和高吞吐文件服务。SMB 3.x 的签名性能通常可接受,但旧设备可能直接连接失败。建议先在测试 OU 灰度,下发后监控 4625、SMBClient/Connectivity 和业务告警,再逐步扩大范围。关闭 SMBv1,但不要把它当作签名整改的替代项。限制工作站之间的 445 横向访问,仅保留到文件服务器、管理节点的必要路径。减少 NTLM 使用,审计 NTLM 事件后再分阶段限制,避免直接“一刀切”造成业务中断。对高权限账户设置登录边界,避免其在普通终端和低信任服务器上产生可转发认证。若环境包含 LDAP、AD CS 或 IIS,分别落实 LDAP signing、channel binding、HTTPS 与 EPA,防止风险迁移到其他落点。总结“SMB 签名未强制”应作为攻击链条件而非孤立结论。可靠复核至少包含:运行时配置、策略来源、网络可达性、认证来源、目标权限和日志时间线。生产验证以只读枚举和日志关联为主;修复则应同时覆盖签名、网络分段、NTLM 收敛和高权限账户登录边界。这样既能给出可复现证据,也能避免为了证明漏洞而扩大测试影响。 服务器、云资产与权限边界梳理示意 网络请求、日志与边界流量分析示意
10小时前10小时 这类告警先别直接等同于“可中继”。很多扫描器报的是目标支持 SMB 签名,但没有强制要求(enabled / not required)。复核时建议把目标端配置、协议协商结果、可获得的 NTLM 认证来源分开确认。 1. 先核对服务端是否真正要求签名 # 在目标 Windows 主机本地执行 Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature,EnableSMB1Protocol,EnableSMB2Protocol # 同时检查策略落到注册表后的结果 Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' | Select-Object EnableSecuritySignature,RequireSecuritySignature 远程侧可用协议协商交叉验证: nmap -Pn -p445 --script smb2-security-mode,smb2-time <target-ip> 重点看 Message signing enabled but not required 还是 required。如果本地配置显示已要求,而扫描仍告警,优先排查扫描器是否命中了负载均衡后的其他节点、旧资产地址,或结果缓存;不要只看主机名。 2. 抓一次协商包,排除工具误判 # 在已授权测试流量中提取 SMB2 协商及签名状态 tshark -r test.pcapng \ -Y 'smb2.cmd == 0 || smb2.flags.signed == 1' \ -T fields -e ip.src -e ip.dst -e smb2.cmd -e smb2.flags.signed 要区分两个概念:协商响应中的“服务端要求签名”决定未签名会话能否建立;会话建立后的 signed 标志只能证明该次连接用了签名,不能反推服务端会拒绝所有未签名客户端。因此,单看一次正常域客户端访问产生的签名流量不够。 3. 中继风险不能只由 445 端口结论化 目标 SMB 不强制签名,只说明它具备成为 SMB 中继落点 的必要条件之一。 还要确认测试范围内是否存在可被诱导或强制发起 NTLM 认证的主体,以及网络路径是否允许该主体访问目标 445。 认证身份在目标上的权限决定影响:普通域用户通常对应文件读取、写入或特定共享权限;本地管理员或对目标有管理权的域主体才可能扩大到远程管理级影响。 同一账号向同一主机进行反射通常受现有防护限制,不能把“存在 NTLM”直接写成“可接管主机”。 如果告警目标其实是 HTTP、LDAP 或 AD CS,SMB 签名不是核心控制项,应分别检查 EPA、LDAP 签名与通道绑定、证书服务 Web 端点的 EPA,避免修复边界写错。 报告里可以按下面方式定级,证据会更扎实: 仅配置缺口:签名未强制,但未验证到可用认证来源或有效权限,记录为潜在中继面。 链路成立:在授权窗口内证明可获得 NTLM 认证、目标接受未签名会话,并以测试账号验证了明确的共享访问权限。 高影响:只有在测试账号确实对目标具备高权限,且影响经过最小化验证后再提高等级。不要用“可能获得管理员认证”替代证据。 4. 修复边界要同时考虑服务端和客户端 对于被中继的 SMB 服务端,核心策略是: 计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 安全选项 Microsoft 网络服务器: 对通信进行数字签名(始终) = 已启用 对应注册表值为: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters RequireSecuritySignature = 1 (DWORD) 客户端侧也建议评估: Microsoft 网络客户端: 对通信进行数字签名(始终) = 已启用 HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters RequireSecuritySignature = 1 (DWORD) 前者防止本机 SMB 服务成为未签名中继落点,后者约束本机向不支持签名的 SMB 服务发起连接,两者控制的方向不同。不要只修改 EnableSecuritySignature;它通常表示“支持或协商签名”,真正决定强制要求的是 RequireSecuritySignature。 落地前建议先盘点 NAS、老旧打印设备、嵌入式设备和 SMB1 依赖。可以先对域控、文件服务器和高价值管理服务器分批强制,再观察 SMB 客户端连接失败、服务器审计和设备兼容性。域控还应单独核对 LDAP 签名、LDAP channel binding,以及 NTLM 使用情况;只修 445 不能覆盖跨协议中继。 复测时至少保留三组证据:策略或注册表截图、远程协商结果、业务账号访问回归结果。这样能明确证明告警关闭,同时避免把“强制签名后旧设备断连”留到生产变更后才发现。
创建帐户或登录后发表意见