Windows服务器安全进程白名单管控程序运行

Windows服务器上最让人头疼的问题往往不是外部黑客的暴力破解，而是内部一个看似正常的业务程序偷偷调用了PowerShell下载木马，或者一个被篡改的DLL文件在后台静默运行。单纯依赖杀毒软件的特征库已经很难应对无文件攻击和内存注入，而白名单管控的思路恰恰相反：默认拒绝一切未授权的可执行文件、脚本和DLL加载，只允许经过审核的进程运行。这种“零信任”式的进程管控在Windows Server 2016及以上的版本中可以通过AppLocker、WDAC（Windows Defender Application Control）以及软件限制策略来实现，但真正落地时，很多管理员发现配置远比想象中复杂，尤其是对正在承载业务的生产服务器，一旦策略过严会导致服务崩溃，过松又形同虚设。

先说结论：对于大多数Windows服务器，最实用的白名单方案是优先使用WDAC（旧称Device Guard）配合AppLocker做辅助。WDAC工作在Windows内核层面，能够校验可执行文件、脚本、MSI安装包、DLL和驱动程序的数字签名及哈希值，其拦截强度远超用户态的AppLocker。但WDAC的策略编写和部署门槛较高，尤其是在多台服务器、不同业务角色的环境下，需要先进行审计模式运行一段时间，收集实际运行的程序清单，再逐步切换到强制模式。很多管理员直接跳过审计阶段，导致策略启用后IIS工作进程或数据库代理无法启动，最后只能紧急回退。

传统杀毒软件基于特征码、启发式分析和行为监控，本质上是在程序运行后或运行过程中进行判断，存在时间差。而白名单管控是在程序启动前就进行拦截，根本不给未知程序执行的机会。在Windows服务器场景中，攻击者常用的手法是利用PowerShell、wscript、mshta等系统自带工具执行恶意代码，这些工具本身是微软签名的合法程序，杀毒软件很难直接判定为恶意。但白名单策略可以限制这些脚本宿主只能由特定路径或特定用户调用，甚至完全禁止在服务器上运行。比如一台纯Web服务器根本不需要运行PowerShell脚本，直接通过AppLocker的脚本规则禁止powershell.exe和powershell_ise.exe执行任何脚本，攻击者的横向移动空间就被大幅压缩。

WDAC策略文件是XML格式，可以通过PowerShell的ConfigCI模块生成。最稳妥的做法是从“默认Windows模式”开始，这个基础策略允许所有Windows自带的组件和微软签名的程序运行，然后在此基础上叠加自定义规则。对于业务程序，优先使用文件发布者规则，即信任特定软件厂商的代码签名证书，比如只允许“Microsoft Corporation”“Oracle Corporation”“Your Company Name”签名的程序运行。如果某些内部开发的程序没有数字签名，则需要使用哈希规则或路径规则。哈希规则最安全但维护成本高，程序每次更新都要重新计算哈希并更新策略；路径规则维护简单但安全性弱，攻击者只要把恶意文件放到受信任路径下就能绕过。实际生产环境中建议混合使用：对外购商业软件用发布者规则，对内部程序用哈希规则并配合严格的目录权限控制，防止非管理员写入受信任目录。

AppLocker的配置相对直观，在本地安全策略或组策略中即可设置。可执行文件规则、Windows安装程序规则、脚本规则、封装应用规则和DLL规则五类中，DLL规则默认不启用，因为启用后会显著增加系统开销，且需要为每个加载的DLL单独创建允许规则，否则很多程序会无法启动。对于服务器环境，建议至少启用可执行文件规则和脚本规则。一个常见的误区是管理员只配置了“允许”规则而没有设置默认拒绝。AppLocker的默认行为是：如果某类规则中没有任何规则，则允许所有程序运行；一旦创建了任何一条规则，则未匹配的程序会被隐式拒绝。所以正确的做法是先创建一条“允许Everyone运行Program Files和Windows目录下所有程序”的规则，再根据业务需要添加特定路径的允许规则，最后确保没有遗漏。另外，AppLocker的规则匹配是基于用户或用户组，而不是基于进程父子关系，这意味着如果一个被允许的程序（比如浏览器）存在漏洞被利用来启动cmd.exe，而cmd.exe不在允许列表中，则会被拦截。这种基于用户权限的模型在服务器上尤其有效，因为服务器通常只有管理员和服务账户两类身份。

无论是WDAC还是AppLocker，直接切换到强制模式都是高风险操作。正确流程是先在目标服务器上以审计模式运行策略至少一到两周，期间收集事件日志。AppLocker的审计事件记录在“应用程序和服务日志\Microsoft\Windows\AppLocker”下，WDAC的审计事件则在“应用程序和服务日志\Microsoft\Windows\CodeIntegrity\Operational”中。通过分析这些日志，可以找出哪些程序被阻止但实际是业务所需的，然后针对性地补充允许规则。很多管理员忽略审计日志的定期检查，导致策略上线后才发现某些计划任务或服务账户运行的程序被拦截。这里有一个细节：WDAC的审计模式只会记录违规事件，不会阻止程序运行，但某些内核级驱动或反作弊软件在审计模式下也可能出现异常，因此测试阶段要覆盖所有业务功能。

攻击者在获得服务器初始访问权限后，最常见的下一步是使用LOLBin（Living Off the Land Binaries）进行横向移动或持久化。以下是一些针对性的白名单规则建议：

第一，禁止在服务器上运行任何位于用户可写目录下的可执行文件。通过AppLocker的路径规则，只允许Program Files、Program Files (x86)和Windows目录下的程序运行，拒绝Users\Public、Temp、AppData等目录。这条规则能拦截绝大多数通过漏洞上传的恶意文件。

第二，限制脚本宿主。在AppLocker的脚本规则中，默认拒绝所有脚本，然后仅对特定管理脚本存放目录（如C:\AdminScripts）开放powershell.exe和wscript.exe的执行权限。同时通过WDAC禁止从网络路径加载脚本。

第三，对DLL加载进行管控。虽然AppLocker的DLL规则开销较大，但WDAC可以针对特定进程启用DLL验证。例如只对lsass.exe、services.exe等关键系统进程启用DLL签名验证，防止攻击者注入未签名DLL。

第四，阻止从备用数据流（ADS）执行程序。可以通过WDAC的策略规则禁止从带有Zone.Identifier标记的文件运行，这能拦截大量通过浏览器下载或邮件附件传播的恶意文件。

对于超过十台服务器的环境，手动逐台配置AppLocker和WDAC策略显然不现实。建议使用组策略集中管理AppLocker规则，将服务器按角色分组（如Web服务器组、数据库服务器组、域控制器组），每个组对应不同的策略。WDAC策略则可以通过组策略的“计算机配置\管理模板\系统\Device Guard”进行部署，将策略XML文件放在可访问的网络共享上，或者使用Intune进行云端管理。策略更新时务必遵循“先审计、后强制”的流程，尤其是当业务软件升级或新增服务时，要提前收集新程序的签名或哈希信息。一个实用的做法是维护一个内部软件清单，记录每个业务程序的文件路径、数字签名主体和哈希值，当程序更新时由变更管理流程同步更新白名单策略。

白名单管控不是银弹。它无法阻止已经被允许的程序自身存在的漏洞被利用，比如一个已签名的Web服务器组件存在远程代码执行漏洞，攻击者利用该漏洞在Web服务器进程内执行恶意代码，此时进程本身是合法的，白名单无法拦截。因此白名单必须与最小权限原则、及时打补丁、网络分段、日志监控等措施配合使用。另外，白名单策略对系统性能有一定影响，尤其是WDAC的DLL验证和AppLocker的DLL规则，在CPU密集型应用上可能造成1%到5%的性能损耗，需要在安全和性能之间做权衡。对于关键业务服务器，建议先在测试环境模拟生产负载，评估性能影响后再上线。

以下是一个使用PowerShell生成WDAC基础策略并添加自定义发布者规则的示例代码，适用于Windows Server 2019/2022：

# 以管理员身份运行
$PolicyPath = "C:\WDAC\BasePolicy.xml"
$CustomRulePath = "C:\WDAC\CustomRules.xml"

# 生成默认Windows模式的基础策略
New-CIPolicy -Level SignedVersion -Fallback Hash -FilePath $PolicyPath -UserPEs -UserWriteablePaths

# 添加自定义发布者规则（示例：允许某公司签名的程序）
Add-SignerRule -FilePath $PolicyPath -CertificatePath "C:\Certs\YourCompany.cer" -Kernel -User

# 合并规则
Merge-CIPolicy -OutputFilePath $CustomRulePath -PolicyPaths $PolicyPath

# 转换为二进制策略并部署
ConvertFrom-CIPolicy -XmlFilePath $CustomRulePath -BinaryFilePath "C:\WDAC\SiPolicy.p7b"

这段代码首先生成一个基础策略，该策略允许所有Windows签名的系统文件和用户模式程序运行，然后通过Add-SignerRule添加特定公司的代码签名证书作为信任源，最后合并并转换为可部署的二进制策略。实际使用时需要将证书路径替换为自己的代码签名证书，并且建议先在测试服务器上以审计模式部署，确认无误后再切换到强制模式。

对于AppLocker的快速配置，可以通过以下PowerShell命令创建默认规则并启用可执行文件和脚本规则：

# 创建默认AppLocker规则
Set-AppLockerPolicy -XmlPolicy (Get-AppLockerPolicy -Local -Xml) -Merge

# 启用可执行文件规则集合
Set-AppLockerPolicy -Local -XmlPolicy @"
<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePublisherRule Id="..." Name="Allow All Signed by Microsoft" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="Microsoft Corporation" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
</AppLockerPolicy>
"@

上述示例展示了如何通过XML策略启用AppLocker的可执行文件规则，允许所有微软签名的程序运行。实际部署时建议使用组策略管理控制台进行图形化配置，避免手工编写XML出错。

白名单管控的最终效果取决于策略的精细度和维护的持续性。很多组织在初期投入精力部署后，由于业务变更频繁、程序更新不及时更新策略，导致要么出现业务中断，要么被迫放宽规则。建议将白名单策略纳入变更管理流程，任何新程序部署或现有程序升级都必须同步评估白名单影响。同时定期审查策略中是否存在过宽的路径规则或过期的哈希规则，及时清理不再使用的允许条目。只有将白名单管控作为一项持续的安全运营工作，而不是一次性项目，才能真正发挥其在Windows服务器安全防护中的核心价值。