Windows服务器被植入恶意文件后，很多管理员的第一反应是查杀和删除，但真正有效的做法是从执行权限上做限制。恶意程序能跑起来的前提是它具备可执行条件，如果从一开始就阻断未知程序的执行通道，即使文件被上传到服务器也无法造成实质破坏。下面直接讲具体的限制方法和配置思路。

用AppLocker建立应用程序白名单

AppLocker是Windows Server自带的应用控制功能，比传统的软件限制策略更灵活，支持按发布者、文件哈希和路径三种方式建立规则。对于服务器环境，建议优先采用发布者规则，只允许经过数字签名且签名归属可信厂商的程序运行。配置时打开本地安全策略，在应用程序控制策略中创建AppLocker规则，针对可执行文件、脚本、Windows安装程序、DLL和封装应用分别设置。默认规则可以先导出再修改，避免误锁系统关键进程。规则建好后必须启动Application Identity服务，否则AppLocker不会生效。

实际配置中，先对服务器现有程序做一次扫描，让系统自动生成默认允许规则，然后在此基础上收紧。例如只允许Program Files目录和Windows目录下的程序执行，同时禁止用户从Temp、Downloads、回收站等常见恶意文件落盘位置启动任何可执行文件。对于脚本类文件，PowerShell和VBScript是重灾区，建议单独建立规则，只允许管理员指定目录下的脚本运行，其余一律拒绝。

通过软件限制策略实现路径级封堵

如果服务器系统版本较旧或不想启用AppLocker，软件限制策略仍然是有效手段。在本地安全策略中打开软件限制策略，新建策略后设置默认安全级别为“不允许的”，然后添加附加规则放行系统必需路径。这种方式逻辑简单粗暴，但需要仔细梳理放行清单，否则容易导致服务启动失败。重点放行的路径包括C:\Windows、C:\Program Files、C:\Program Files (x86)，以及业务程序实际安装目录。对于用户可写目录如C:\Users\Public、C:\Temp、IIS上传目录等，保持默认拒绝状态即可。

软件限制策略的优先级高于文件关联，即使恶意文件伪装成图片或文档，只要扩展名是可执行类型，仍然会被拦截。需要注意的是，该策略对批处理文件、脚本文件同样有效，但需要将对应扩展名加入“指定的文件类型”列表。常见的可执行扩展名包括exe、com、scr、bat、cmd、vbs、js、msi、ps1等，建议全部纳入管控。

锁定PowerShell执行策略与脚本日志

PowerShell是攻击者最常用的横向移动和权限维持工具，限制其执行能力比单纯查杀更有效。通过组策略或本地策略将PowerShell执行策略设置为Restricted或AllSigned。Restricted直接禁止任何脚本运行，AllSigned只允许有可信签名的脚本执行。对于需要运行运维脚本的服务器，建议使用AllSigned并部署内部代码签名证书，这样既保留自动化能力，又阻止未签名恶意脚本。

同时开启PowerShell的模块日志、脚本块日志和转录日志。脚本块日志能记录PowerShell实际执行的代码内容，即使攻击者使用编码或混淆命令，日志中也会保留解码后的脚本块。转录日志则完整记录整个PowerShell会话的输入输出，便于事后溯源。这些日志建议通过Windows事件转发集中存储，防止攻击者清理本地日志。

利用NTFS权限阻断恶意文件写入

执行权限限制解决的是“能不能跑”的问题，文件系统权限解决的是“能不能落盘”的问题。两者配合才能形成完整防线。对Web目录、上传目录、临时目录等用户可写位置，在NTFS权限中显式拒绝Everyone或IIS应用池账户的执行权限。具体做法是在目录属性的安全选项卡中，为对应账户勾选“拒绝执行”权限。拒绝权限优先级高于允许权限，即使目录中混入了exe文件，系统也会阻止其加载运行。

对于系统关键目录如C:\Windows\Temp，默认权限通常允许Users写入，但很多服务会调用该目录存放临时文件。如果业务允许，可以将该目录的执行权限单独剥离，只保留读写权限。同理，IIS的App_Data目录、ASP.NET临时编译目录、PHP上传目录都应该做类似处理。配置前务必测试业务功能是否正常，避免因权限过紧导致应用崩溃。

启用WDAC实现内核级应用控制

Windows Defender Application Control（WDAC）是比AppLocker更底层的应用控制方案，基于内核驱动强制执行，即使攻击者获得管理员权限也无法绕过。WDAC策略以XML文件形式部署，可以指定允许执行的程序签名、哈希或路径。配置WDAC需要先在参考服务器上运行策略生成工具，将当前系统所有合法程序纳入允许列表，然后部署到生产服务器。WDAC策略一旦启用，未列入白名单的程序即使被管理员手动双击也无法运行，这对防勒索软件和挖矿程序尤其有效。

WDAC的配置门槛较高，需要理解策略合并规则和补充策略机制。建议先在测试环境验证，确认业务程序全部正常运行后再推送到生产。对于运行关键业务的服务器，可以先用Audit模式运行WDAC，记录哪些程序会被阻止但不实际拦截，根据日志调整策略后再切换到Enforce模式。

禁用不必要的脚本宿主和组件

很多恶意文件依赖系统自带的脚本宿主执行，直接禁用这些组件可以大幅缩小攻击面。通过注册表或组策略禁用Windows Script Host，可以阻止vbs和js脚本运行。具体操作是在注册表HKLM\Software\Microsoft\Windows Script Host\Settings下创建Enabled键值并设为0。对于不需要运行cmd批处理的服务器，可以通过软件限制策略禁止cmd.exe和wscript.exe、cscript.exe的执行。对于IIS服务器，如果业务不依赖ASP，直接卸载ASP功能模块；不依赖PHP则卸载PHP扩展。减少活动组件就是减少可被利用的执行入口。

另外，系统自带的mshta.exe、regsvr32.exe、rundll32.exe、certutil.exe等工具经常被攻击者滥用执行恶意代码。如果业务不需要，可以通过AppLocker或软件限制策略单独禁止这些程序运行。对于必须保留的工具，用文件哈希规则精确限制只允许特定版本运行，防止攻击者替换或利用。

定期审计执行策略与实际生效状态

策略配置完成后不能一劳永逸，需要定期验证策略是否真正生效。使用gpresult命令检查组策略应用情况，用Get-AppLockerPolicy查看当前AppLocker规则，用Get-MpPreference查看WDAC状态。同时检查Application Identity服务是否正常运行，如果该服务被停止，AppLocker会失效。对于关键服务器，建议设置监控告警，一旦发现执行策略被修改或相关服务停止立即通知管理员。

日志审计方面，AppLocker和WDAC的阻止事件记录在Windows事件日志的应用程序和服务日志中，事件ID 8003和8004对应AppLocker的允许和阻止，WDAC的阻止事件ID为3076。将这些日志接入SIEM或集中日志平台，可以及时发现攻击者尝试执行恶意程序的行为。即使策略阻止了攻击，日志记录本身就是重要的安全情报。

限制程序执行权限不是单一技术手段能完成的事，需要AppLocker或WDAC做白名单控制、软件限制策略做路径封堵、NTFS权限做落盘阻断、PowerShell策略做脚本管控，再配合日志审计验证效果。这套组合配置下来，恶意文件即使被上传到服务器，也会因为无法执行而失去威胁。对于已经发生过入侵的服务器，建议在清理完恶意文件后立即按上述方案加固，防止二次感染。