Windows服务器安全之配置AppLocker禁止未知脚本运行

AppLocker是Windows Server内置的应用程序白名单控制工具，通过配置AppLocker规则可以从根本上禁止服务器上运行任何未经授权的脚本和可执行文件。具体做法是：打开"本地安全策略"或使用组策略编辑器，找到"应用程序控制策略"下的AppLocker节点，分别为可执行文件、脚本、安装程序和DLL创建默认拒绝规则，然后针对合法程序添加允许规则。这样一来，任何不在白名单内的.exe、.ps1、.bat、.vbs等脚本都将被系统拦截，无法执行。这是Windows服务器防勒索、防挖矿、防恶意脚本最有效的手段之一。

很多运维人员在管理Windows Server时，最头疼的就是服务器被植入未知脚本。攻击者一旦获得了一个低权限账户，就可能通过PowerShell、CMD批处理、VBS脚本等方式下载并执行恶意代码。传统的杀毒软件往往滞后于新型攻击手法，而AppLocker从"允许什么运行"的角度出发，直接从源头卡死未知程序的执行权限。下面我会从原理、配置步骤、规则策略、常见问题和最佳实践几个维度，把这件事讲透。

AppLocker本质上是一个应用程序白名单机制。它不依赖签名识别或行为分析，而是通过管理员预先定义的规则来判断一个程序是否允许运行。判断依据包括：发布者信息（数字签名）、文件路径、文件哈希值三种方式。只要程序不满足任何一条允许规则，就会被拒绝执行，用户会收到"此应用已被组策略阻止"的提示。

相比传统的软件限制策略（Software Restriction Policies），AppLocker有几个明显优势。第一，规则粒度更细，可以分别针对可执行文件、脚本、安装程序、DLL进行独立控制。第二，支持基于发布者的规则，只要程序有有效的数字签名就能放行，维护成本低。第三，支持审核模式，可以先观察哪些程序会被拦截，再正式启用强制模式，避免误杀正常业务。

需要注意的是，AppLocker仅在Windows Server 2008 R2及以上版本、Windows 7企业版/旗舰版及以上版本中可用。Windows Server 2012及以后版本还增加了对Packaged App（UWP应用）的支持。家庭版和普通版Windows不支持AppLocker，这一点在部署前务必确认。

在正式配置之前，有几项准备工作必须完成。首先，确保"Application Identity"服务正在运行。这个服务是AppLocker的依赖项，如果没有启动，所有规则都不会生效。检查方法是打开services.msc，找到"Application Identity"，将启动类型设为"自动"并启动服务。

其次，建议在测试环境中先跑一遍完整流程。AppLocker一旦配置了默认拒绝规则，如果没有提前添加足够的允许规则，可能导致系统本身的正常程序也无法运行，严重时会影响远程桌面连接甚至服务器管理。所以，先用审核模式跑两周，收集被拦截的程序列表，再逐步添加允许规则，最后切换到强制模式，这是最稳妥的路径。

另外，如果服务器上运行了SQL Server、IIS等关键服务，需要提前梳理这些服务会调用哪些可执行文件和脚本。可以使用PowerShell命令导出当前运行的程序列表作为参考：

Get-AppLockerPolicy -Effective | Export-Clixml -Path "C:\AppLockerPolicy.xml"

这条命令可以导出当前生效的AppLocker策略，方便备份和迁移。在大规模部署时，建议通过组策略统一下发，而不是在每台服务器上手动配置。

配置AppLocker有两种入口：本地安全策略（secpol.msc）和组策略编辑器（gpedit.msc）。对于单台服务器，用本地安全策略即可；对于域环境中的多台服务器，强烈建议用组策略统一管理。以下以本地安全策略为例，逐步说明。

第一步，打开secpol.msc，导航到"应用程序控制策略" → "AppLocker"。你会看到四个节点：可执行规则、脚本规则、安装程序规则、DLL规则。每个节点下有三个子项：默认规则、允许规则、拒绝规则。

第二步，右键点击每个节点下的"默认规则"，选择"创建默认规则"。系统会自动生成一组基础规则：允许管理员组运行所有程序、允许Program Files和Windows目录下的程序运行、允许Publisher规则等。这一步是基础，但远远不够。

第三步，针对每个节点创建额外的允许规则。比如对于脚本规则，你需要明确允许哪些脚本路径。典型的做法是：

允许 %OSDRIVE%\Windows\*.ps1
允许 %OSDRIVE%\Windows\System32\*.bat
允许 C:\Program Files\*\*.vbs

这里的%OSDRIVE%是系统变量，会自动解析为C:或其他盘符。对于PowerShell脚本，建议只允许System32和特定业务目录下的脚本，不要开放整个C盘的ps1权限。

第四步，创建发布者规则。这是最推荐的规则类型。比如你要允许Microsoft签名的所有程序运行，可以创建如下规则：

发布者：O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US
操作：允许
用户：Everyone

通过这种方式，所有带有微软有效签名的程序都会自动放行，包括Windows Update组件、.NET Framework程序等。对于第三方软件，也可以用同样的方式添加发布者规则，只要软件有正规的数字签名。

第五步，切换到强制模式。在每个规则节点上右键选择"属性"，将"强制规则"或"已配置"设为启用状态。如果之前一直用审核模式，先确认所有必要的允许规则都已添加，再统一切换。

脚本是服务器被攻击的重灾区。PowerShell、CMD、WSH脚本（.vbs、.js）都可能被利用来执行恶意代码。AppLocker对脚本的控制非常精细，可以分别对.ps1、.bat、.cmd、.vbs、.js等扩展名进行规则设置。

最佳实践是采用"默认拒绝 + 白名单"策略。具体来说：在脚本规则节点下创建一条默认拒绝规则，拒绝所有用户运行所有脚本，然后针对合法的脚本路径和发布者添加允许规则。这样即使攻击者上传了一个恶意的.ps1文件到Web目录，也无法执行。

特别要注意PowerShell的执行策略和AppLocker是两层不同的防护。PowerShell的Set-ExecutionPolicy只是限制脚本的加载方式，并不能阻止脚本运行。而AppLocker是从系统层面阻止程序启动，两者配合使用效果最佳。建议同时将PowerShell执行策略设为AllSigned或RemoteSigned：

Set-ExecutionPolicy -ExecutionPolicy AllSigned -Scope LocalMachine

另外，对于IIS服务器，要特别关注Web应用程序可能调用的脚本。如果Web应用需要执行某些脚本，必须把这些脚本放在专门的目录下，并为该目录创建明确的允许规则，而不是开放整个网站目录。

第一个常见问题：配置AppLocker后远程桌面连不上了。这通常是因为没有为mstsc.exe添加允许规则。解决方法是在可执行规则中添加一条路径规则，允许%SystemRoot%\system32\mstsc.exe运行。类似地，如果用PowerShell远程管理，也要确保powershell.exe和pwsh.exe在白名单中。

第二个问题：规则冲突导致某些程序时能运行时不能。这往往是因为同时存在允许规则和拒绝规则，且拒绝规则优先级更高。AppLocker的规则优先级是：拒绝规则 > 允许规则 > 默认规则。如果你发现某个程序被拦截，检查是否有一条拒绝规则覆盖了它。

第三个问题：更新Windows后AppLocker规则失效。某些Windows大版本更新可能会重置本地安全策略。建议通过组策略下发AppLocker配置，这样即使本地被重置，重启后组策略会重新应用。同时定期使用导出命令备份策略文件。

第四个问题：攻击者绕过AppLocker。虽然AppLocker很强，但不是万能的。如果攻击者以SYSTEM权限运行，或者利用LOLBins（Living Off the Land Binaries，如certutil、mshta、regsvr32等系统自带工具），可能绕过AppLocker。因此，AppLocker必须配合最小权限原则、禁用不必要的服务、限制管理员账户数量等措施一起使用。

对于有几十台甚至上百台Windows Server的企业环境，AppLocker的部署应该遵循"集中管理、分阶段推进、持续审计"的原则。首先通过域组策略创建一个统一的AppLocker策略模板，包含基础的默认规则和常见的允许规则。然后按服务器角色分组：Web服务器、数据库服务器、文件服务器、域控制器，每组根据业务需求微调规则。

部署节奏上，建议分三个阶段。第一阶段：所有服务器启用审核模式，运行两到四周，收集日志。第二阶段：根据审计结果完善允许规则，对非关键服务器切换到强制模式。第三阶段：全部服务器切换强制模式，并建立定期审查机制，每季度检查一次规则有效性。

日志审计方面，AppLocker的事件日志记录在"应用程序和服务日志" → "Microsoft" → "Windows" → "AppLocker"下。建议配置日志转发到集中的SIEM平台，实时监控被拦截的程序。如果发现大量来自同一用户或同一路径的拦截事件，很可能是正在进行的攻击行为，需要立即响应。

最后强调一点，AppLocker是纵深防御体系中的重要一环，但不能替代其他安全措施。它解决的是"什么程序能运行"的问题，而"谁在运行、从哪里运行、运行了什么"则需要结合进程监控、网络流量分析、EDR工具来共同完成。把AppLocker当成服务器安全的基础门槛，在此之上叠加更多防护层，才是真正成熟的安全架构。

配置AppLocker禁止未知脚本运行，是Windows Server安全加固中投入产出比最高的操作之一。它不需要额外购买软件，系统自带，配置逻辑清晰，防护效果立竿见影。核心要点就是：启用Application Identity服务、先审核后强制、默认拒绝加白名单、按发布者和路径精细控制、配合PowerShell执行策略和最小权限原则。只要按步骤做好，你的Windows Server就能有效抵御绝大多数基于脚本的攻击尝试。安全不是一劳永逸的事，定期审查和更新规则，才能让这道防线持续有效。