SMB签名漏洞深度解析：从原理到实战修复指南-Seo优化-塔城地区网站建设公司

1. 项目概述：从一条Nessus告警说起

如果你负责过企业内网的安全运维或渗透测试，大概率在Nessus的扫描报告里见过这个熟悉的“中等风险”告警：SMB Signing not required，对应的插件ID是57608。第一次看到时，你可能会疑惑，这既不是远程代码执行，也不是权限提升，怎么就成漏洞了？这个“签名”到底是什么，不开启又会怎样？我最初也有同样的疑问，直到在一次真实的内网横向移动演练中，攻击者利用这个“不起眼”的配置弱点，像逛自家后院一样，悄无声息地窃取了大量敏感文件，我才真正意识到它的严重性。这绝不是一个可以忽略的低危项，而是通往核心数据的一道敞开的侧门。

简单来说，SMB（Server Message Block）协议是Windows网络中文件和打印机共享的基石。而SMB签名（SMB Signing）是一项安全特性，它确保在网络上传输的SMB数据包确实来自它所声称的客户端，并且在传输过程中没有被篡改。当这项特性被设置为“非必需”（Not required）时，就意味着服务器虽然支持签名，但不会强制要求客户端使用。攻击者就可以利用中间人攻击（如ARP欺骗、LLMNR/NBT-NS投毒）等手段，劫持或伪造SMB会话，进行数据窃取甚至远程命令执行。Nessus插件57608正是在检测网络中是否存在这类配置不安全的SMB服务器（通常是域控制器或文件服务器）。

本文将从一个实战运维和渗透测试双重视角，彻底拆解SMB签名漏洞的原理、危害、检测方法，并提供从单机到域环境的完整修复指南。无论你是安全工程师、系统管理员，还是对内网安全感兴趣的爱好者，都能从中获得可直接落地的操作步骤和避坑经验。

2. SMB签名漏洞深度解析：不只是“一个开关”

2.1 SMB协议与签名机制的工作原理

要理解漏洞，得先明白SMB协议是如何工作的。你可以把SMB会话想象成两个人（客户端和服务器）通过一条不安全的公共电话线通话。他们需要交换文件（通话内容）。在没有签名的情况下，对话可能是这样的：

客户端：“我是Alice，请把‘财务报告.docx’发给我。”
服务器：“好的，给你。”

这里存在两个致命问题：1. 你怎么证明打电话的真是Alice？2. 传输过程中的“财务报告”内容有没有被窃听者掉包？

SMB签名就是为了解决这两个问题而生的“数字指纹”机制。它的核心原理基于会话密钥（Session Key）。在SMB会话建立的身份验证阶段（比如使用NTLM或Kerberos），客户端和服务器会协商出一个只有双方知道的共享密钥。此后，对于每个SMB数据包，发送方都会用这个会话密钥，通过HMAC（哈希消息认证码，通常是HMAC-SHA256）算法，计算出一个唯一的“签名”（Signature），并将这个签名附加在数据包中。

接收方在拿到数据包后，会用相同的密钥重新计算一次签名，并与数据包中的签名进行比对。如果一致，则证明：1.数据完整性：数据在传输过程中未被篡改；2.消息真实性：数据确实来自拥有会话密钥的合法对方（因为密钥是在安全身份验证后产生的）。

在Windows系统中，SMB签名有三个可能的状态：

启用并必需（Enabled and required）：服务器只接受带有效签名的SMB数据包。这是最安全的状态。
启用但不必需（Enabled but not required）：服务器支持并可以处理签名，但如果客户端不支持或不使用签名，它也会接受未签名的连接。这就是Nessus报告漏洞的状态。
禁用（Disabled）：服务器根本不支持签名。这是最不安全的状态，但有趣的是，Nessus的57608插件主要针对的是第二种状态，因为“不要求”在混合环境中最常见，也最容易被利用。

2.2 漏洞利用场景与真实危害

“不就是可能被篡改数据吗？”——如果这么想，就低估了它的危害。在实际攻击链中，SMB签名缺失是内网横向移动的“黄金跳板”之一。结合其他攻击手法，它能产生毁灭性的效果。

场景一：中间人攻击与凭据窃取攻击者通过ARP欺骗或利用有缺陷的协议（如LLMNR、NBT-NS），将自己伪装成网关或目标服务器。当域内用户尝试访问一个不存在的共享路径（如误输入\\filesrv\share）时，其计算机会通过LLMNR广播询问“filesrv在哪？”。攻击者响应这个广播，声称自己就是“filesrv”。用户的SMB客户端随后会向攻击者发起连接并进行身份验证（发送NTLM Hash）。由于攻击者伪装的“服务器”不要求SMB签名，它可以完全接收并转发这些认证流量，从而轻松截获用户的NTLM Hash。这个Hash可以被用于“传递哈希”攻击，直接登录其他同样不要求签名的服务器。

场景二：SMB Relay（中继）攻击这是比单纯窃取更高级的攻击。攻击者同样通过中间人位置截获一个客户端的SMB认证请求（NTLM Challenge/Response）。但这次，攻击者不破解这个Hash，而是将它“原封不动地”中继（Relay）到网络中的另一台服务器（Target）上，并试图访问Target的资源。如果Target服务器也不要求SMB签名，它就会接受这个被中继的认证，认为攻击者就是最初的合法客户端。攻击者从而获得在Target服务器上的访问权限，可能是执行命令、写入文件，甚至直接获取Shell。整个过程中，攻击者无需知道用户的明文密码或破解Hash，利用的就是签名缺失导致的身份验证机制缺陷。

实操心得：在一次红队评估中，我们发现在一个大型办公网段，超过80%的服务器和所有工作站都未强制要求SMB签名。利用Responder工具进行LLMNR投毒，在15分钟内就捕获了数十个域用户的NTLMv2 Hash。更危险的是，其中一台用于软件分发的服务器（不要求签名）存在弱口令，我们成功将捕获的一个高权限用户Hash中继到这台服务器，获得了系统权限并部署了后门。这一切的起点，就是那条“SMB Signing not required”的告警。

场景三：数据篡改与注入在文件传输过程中，攻击者可以修改SMB数据包的内容。例如，将用户下载的软件安装包替换为捆绑了恶意软件的版本，或者在上传的文档中注入恶意代码。由于没有签名验证，客户端和服务器都无法察觉数据已被篡改。

2.3 Nessus插件#57608的检测逻辑

了解漏洞原理后，再看Nessus的检测就一目了然了。插件57608的执行流程非常直接：

连接探测：Nessus尝试通过445端口与目标建立SMB连接。
协议协商：在SMB协议协商阶段（Negotiate Protocol Request/Response），客户端会告知服务器自己支持的能力列表。Nessus会模拟一个声明自己支持SMB签名的客户端。
响应分析：服务器在协商响应中，会返回其自身的能力标志位。其中一个关键标志位是Security Signatures Required。如果服务器返回的标志表明它支持签名（Security Signatures Enabled为True），但不要求签名（Security Signatures Required为False），那么插件就会触发告警，判定为“SMB Signing not required”。
信息收集：插件通常还会收集目标机器的NetBIOS名称、操作系统版本等信息，辅助判断其重要性（如是否为域控制器）。

这个检测是非侵入性的，它只是进行了一次正常的协议协商，不会对目标系统造成任何破坏或更改。

3. 漏洞检测与影响范围评估

3.1 手动检测与验证方法

除了依赖Nessus，掌握手动检测方法能让你在应急响应或快速排查时更得心应手。这里推荐几个实用工具。

使用nmap脚本检测nmap的smb-security-mode脚本是快速扫描网段的利器。

nmap -p 445 --script smb-security-mode <目标IP或网段>

执行后，重点关注输出中的两行：

| smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled but supported

如果message_signing显示为disabled but supported或enabled but not required，则说明存在漏洞。如果显示required，则是安全的。

使用PowerShell（适用于本地或已有权限的远程主机）在Windows主机上，你可以使用PowerShell快速检查本地或远程服务器的SMB签名要求状态。

# 检查本地机器的SMB服务器签名配置 Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RequireSecuritySignature" -ErrorAction SilentlyContinue # 检查本地机器的SMB客户端签名配置（这影响它作为客户端时是否使用签名） Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" -Name "EnableSecuritySignature" -ErrorAction SilentlyContinue # 更全面的方法是使用Get-SmbServerConfiguration cmdlet (Windows Server 2012+ / Win8+) Get-SmbServerConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature

对于远程检测，如果没有现成工具，可以尝试通过WMI查询（需要相应权限）：

Get-WmiObject -Class Win32_ComputerSystem -ComputerName <远程主机名> | Select-Object Name # 注意：直接查询签名注册表项需要远程注册表访问权限，通常较难。

使用Impacket套件中的smbclient.py对于渗透测试人员，Impacket工具包提供了更底层的交互方式。

python3 /usr/share/doc/python3-impacket/examples/smbclient.py <域名>/<用户>:<密码>@<目标IP>

连接后，在SMB shell中，服务器的能力会在初始协商时显示，但不如nmap脚本直观。更专业的做法是使用ntlmrelayx.py等工具直接进行中继测试，但这属于攻击模拟范畴，需在授权环境下进行。

3.2 确定影响范围与风险定级

拿到扫描报告后，不能一概而论，需要评估风险。

资产重要性排序：
- 域控制器（Domain Controllers）：最高风险。攻击者一旦通过中继攻击获得域控权限，意味着整个域沦陷。必须立即修复。
- 文件服务器、数据库服务器、应用服务器：高风险。存储和处理关键业务数据。优先修复。
- 成员服务器：中风险。可能作为横向移动的跳板。计划内修复。
- 普通办公电脑（工作站）：风险相对较低，但数量庞大。如果攻击者已进入内网，工作站同样是中继攻击的良好目标。可以通过组策略统一修复。
网络位置考量：
- 核心业务网段：风险高，需优先处理。
- 隔离的测试/开发网段：可根据安全策略放宽，但仍建议修复。
- DMZ区：通常不应开放SMB（445端口）到互联网，如果存在，风险极高。
业务影响评估：开启强制签名可能会影响与一些老旧设备或特定嵌入式系统的兼容性。在修复前，需要识别网络中是否存在这类设备。一个实用的方法是，在修复策略中先设置为“启用但不要求”，观察一段时间，看是否有业务报错，日志中是否有签名失败记录，然后再推进到“强制要求”。

注意事项：不要只盯着服务器。在一个现代攻击链中，攻击者往往先攻陷一台工作站，然后以此为起点，利用工作站（作为客户端）向其他服务器发起的、未签名的SMB会话进行中继攻击。因此，客户端的签名配置同样重要。服务器要求签名，但客户端不启用签名，会话依然无法建立。必须两端配合。

4. 修复指南：从单机到域环境的完整方案

修复的核心目标是将SMB签名策略从“不要求”改为“要求”。这需要在SMB服务器和SMB客户端两端进行配置。

4.1 单机手动修复（Windows Server 2012 R2 / Windows 8 及以上）

对于少量服务器或无法加入域的设备，可以采用手动修改注册表或PowerShell命令的方式。

方法一：通过PowerShell（推荐）这是最清晰、最不容易出错的方式。

# 以管理员身份运行PowerShell # 1. 配置SMB服务器端（本机作为文件共享服务器时） # 查看当前配置 Get-SmbServerConfiguration # 启用服务器签名并要求它 Set-SmbServerConfiguration -RequireSecuritySignature $true -Force # -Force 参数避免交互式确认 # 同时，也建议启用服务器端的签名支持（通常默认已启用） Set-SmbServerConfiguration -EnableSecuritySignature $true -Force # 2. 配置SMB客户端（本机作为访问其他共享的客户端时） # 查看当前配置 Get-SmbClientConfiguration # 启用客户端签名并要求它 Set-SmbClientConfiguration -RequireSecuritySignature $true -Force # 启用客户端的签名支持 Set-SmbClientConfiguration -EnableSecuritySignature $true -Force

执行后，可能需要重启服务器服务或重新启动计算机才能使更改完全生效。可以重启Server服务：

Restart-Service LanmanServer -Force

方法二：通过注册表编辑器（适用于所有Windows版本）注册表是底层配置，但操作需谨慎。

打开regedit。
导航到服务器端配置：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
- 新建或修改DWORD (32位)值：RequireSecuritySignature，设置值为1。
- 确保EnableSecuritySignature值为1（通常默认是）。
导航到客户端配置：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
- 新建或修改DWORD (32位)值：RequireSecuritySignature，设置值为1。
- 确保EnableSecuritySignature值为1。
重启计算机。

实操心得：在手动修改注册表时，我曾遇到过因拼写错误（如RequireSecuritySignatures多了个‘s’）导致配置不生效的情况。强烈建议使用PowerShell的Set-Smb*Configuration命令，它更直观且不易出错。修改后，务必使用Get-Smb*Configuration命令验证，并用nmap或Test-NetConnection从另一台机器扫描445端口验证策略是否已生效。

4.2 使用组策略进行域级统一修复（最佳实践）

对于域环境，使用组策略对象（GPO）是高效、统一的管理方式。可以针对不同的OU（组织单位）设置不同的策略。

创建并链接GPO：

打开组策略管理控制台（GPMC）。
在需要应用的OU（例如“服务器OU”或“工作站OU”）上右键，选择“在这个域中创建GPO并在此处链接”。
为GPO命名，如“强制启用SMB签名 - 服务器”。

配置SMB服务器签名策略（针对服务器OU）：

右键新建的GPO，选择“编辑”。
导航到：计算机配置->策略->Windows 设置->安全设置->本地策略->安全选项。
在右侧找到策略：
- Microsoft 网络服务器: 对通信进行数字签名(如果客户端允许)
  - 解释：此策略对应EnableSecuritySignature。设置为“已启用”，表示服务器支持签名。
- Microsoft 网络服务器: 对通信进行数字签名(始终)
  - 解释：此策略对应RequireSecuritySignature。设置为“已启用”，表示服务器要求所有传入的SMB会话都必须签名。这是修复漏洞的关键设置。

配置SMB客户端签名策略（针对所有计算机OU，或单独为工作站创建）：

在同一GPO或为工作站新建的GPO中，编辑。
导航到相同路径：安全选项。
找到策略：
- Microsoft 网络客户端: 对通信进行数字签名(如果服务器同意)
  - 解释：对应客户端的EnableSecuritySignature。设置为“已启用”。
- Microsoft 网络客户端: 对通信进行数字签名(始终)
  - 解释：对应客户端的RequireSecuritySignature。设置为“已启用”。这意味着客户端将只与要求签名的服务器通信，并对自己发起的会话进行签名。

策略应用与验证：

将包含服务器的GPO链接到服务器OU，将包含客户端的GPO链接到工作站OU。
在域控制器上运行gpupdate /force，或在目标客户端/服务器上运行，强制刷新组策略。
等待策略生效（通常下一个组策略刷新周期，约90分钟）或重启计算机。
使用gpresult /h report.html生成策略结果报告，确认策略已成功应用。
再次使用nmap或Nessus进行扫描验证，告警应已消除。

4.3 修复后的兼容性测试与回滚方案

兼容性测试：强制启用签名后，最大的风险是与旧设备或不支持签名的设备（如某些网络存储设备NAS、老式打印机服务器、特定工业控制设备）的连接中断。

监控事件日志：重点查看Windows日志->系统和Microsoft-Windows-SMBServer/Operational中的警告或错误事件。寻找事件ID为3019、3020等与SMB签名失败相关的事件。
分段实施：不要在全网同时强制启用。可以先在一个非关键的、具有代表性的测试OU中实施，观察1-2周。
使用“审核”模式：对于无法确定影响的场景，可以先将组策略中的“始终”签名设置为“已禁用”，但启用“审核”模式（如果系统支持）。这样可以在事件日志中记录哪些连接尝试了未签名的会话，而不实际阻止它们。

回滚方案：如果出现严重兼容性问题，需要快速回滚。

组策略回滚：在GPMC中，直接将该GPO链接设置为“已禁用”，然后在受影响计算机上运行gpupdate /force。或者，修改GPO中的策略设置回“未配置”或“已禁用”。
手动回滚：对于个别关键服务器，如果等不及组策略刷新，可以按照4.1节的方法，使用PowerShell将-RequireSecuritySignature设置为$false，并重启Server服务。
制定例外策略：对于极少数确实无法支持签名的关键业务设备，可以考虑将其隔离到独立的VLAN中，并在网络边界（防火墙/ACL）上严格限制其SMB访问范围，作为风险缓释措施，而不是简单地全局关闭签名。

5. 进阶加固与持续性监控

修复漏洞只是第一步，建立持续的监控和防御体系才能长治久安。

5.1 网络层加固措施

禁用过时且不安全的协议：
- SMBv1：这是永恒之蓝（EternalBlue）利用的协议版本，本身存在严重漏洞且性能差。应在所有系统上彻底禁用。可以通过组策略（计算机配置->策略->管理模板->网络->Lanman工作站->启用不安全的来宾登录）或PowerShell (Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol) 禁用。
- LLMNR和NetBIOS-NS：这些是用于本地名称解析的协议，正是它们的不安全性被Responder等工具利用来进行投毒攻击。在纯域环境（有DNS）中，可以考虑在网络层面或主机层面禁用它们。
  - 组策略路径：计算机配置->策略->管理模板->网络->DNS客户端->关闭多播名称解析（禁用LLMNR）。
  - 禁用NetBIOS over TCP/IP：在网络适配器属性中，TCP/IPv4高级设置 -> WINS标签 -> 选择“禁用NetBIOS over TCP/IP”。
网络分段与微隔离：将不同安全等级的设备划分到不同的VLAN中，并在核心交换机或防火墙上配置访问控制列表（ACL），严格限制SMB（445端口）的访问流量。例如，只允许管理网段访问服务器区的SMB端口，工作站之间禁止互相访问445端口。这能极大限制攻击者在攻陷一台主机后的横向移动能力。

5.2 安全监控与日志审计

配置集中日志收集（如SIEM系统），并监控以下关键事件，以便及时发现异常SMB活动。

事件ID 3019 (SMB签名错误)：记录在Microsoft-Windows-SMBServer/Operational日志中。当服务器配置为要求签名，但收到未签名的请求时，会生成此事件。偶尔出现可能是兼容性问题，大量出现则可能预示攻击探测。
事件ID 4625 (登录失败)：在安全日志中。关注登录类型为“3”（网络登录）的大量失败，尤其是来自非常用IP或用户名的失败，可能伴随中继攻击。
事件ID 4648 (使用显式凭据登录)：在安全日志中。如果攻击者通过中继攻击成功，可能会产生此类日志，显示一个账户从某台计算机（攻击者机器）登录到另一台计算机（目标机器）。
网络流量监控：使用IDS/IPS或网络流量分析工具，检测异常的SMB连接模式，例如同一源IP在短时间内向大量不同目标发起SMB连接尝试。

5.3 构建主动防御体系

启用Windows Defender Credential Guard：对于Windows 10/11和Server 2016+，启用Credential Guard可以基于虚拟化安全（VBS）隔离和保护NTLM哈希、Kerberos票证等秘密，使得即使攻击者窃取了内存，也难以提取出可用于传递哈希攻击的凭据。
实施LAPS（本地管理员密码解决方案）：确保每台计算机的本地管理员账户密码是随机、唯一且定期更改的。这能有效阻止攻击者利用中继攻击获取一台机器的本地管理员权限后，使用相同密码横向移动。
强制使用Kerberos认证：在域环境中，Kerberos认证比NTLM更安全，且天然抗中继攻击（因为票据是针对特定服务主体的）。通过组策略限制使用NTLM（计算机配置->策略->Windows 设置->安全设置->本地策略->安全选项->网络安全: 限制 NTLM: ...），但需谨慎评估对旧应用的兼容性影响。
定期漏洞扫描与渗透测试：将SMB签名检查作为常规漏洞扫描的必选项。定期授权进行内部渗透测试，模拟攻击者视角，验证包括SMB中继在内的横向移动手段是否依然有效。

修复“SMB Signing not required”漏洞，远不止是在扫描报告上打一个勾。它要求我们从协议原理理解风险，在业务兼容性中寻找平衡，并通过技术配置、网络架构和监控响应构建一个立体的防御层。从一条Nessus告警开始，深入下去，你会发现这其实是夯实内网安全基础的一块关键基石。每次策略变更后，别忘了亲自用工具扫一下，亲眼看到那个红色的“Medium”变成“None”或“Info”，才是对安全工作最好的回报。