windows服务器IIS站点安全运维配置

Windows服务器上的IIS站点安全运维，核心从来不是装一个防护软件就完事，而是要把“最小权限、最少暴露、最快发现”这三件事落到每一个配置项里。很多站点被入侵，并不是攻击手段有多高明，而是默认配置、过期组件、目录权限过大、日志没开全这些基础问题长期没人管。下面直接讲具体的配置方法和运维要点。

IIS跑在Windows Server上，系统本身不安全，IIS配置再好也没用。首先要确保服务器安装的是主流受支持的Windows Server版本，比如2016、2019或2022，并且已经安装最新月度累积更新。不要使用停止支持的老系统跑对外站点。系统安装完成后，只保留IIS相关的角色和服务，其他用不到的功能一律不装。服务器不要加入不必要的域或工作组环境，对外Web服务器建议使用独立工作组并设置高强度本地管理员密码。

IIS安装时，只勾选必要的功能模块。默认的“Web服务器”角色会带上很多用不到的组件，比如WebDAV发布、目录浏览、CGI、ASP（如果站点不用ASP）、ISAPI扩展等。安装完成后，在“服务器管理器”里检查角色服务，把不需要的全部卸载或禁用。攻击面越小，被利用的概率越低。

每个站点必须使用独立的应用程序池，不要多个站点共用一个池。这样某个站点被入侵后，攻击者无法直接通过应用池身份访问其他站点的文件和进程。应用程序池的.NET CLR版本按站点实际需要设置，托管管道模式如果站点不需要经典模式，统一用“集成”模式。

应用程序池的标识不要用默认的ApplicationPoolIdentity直接跑高权限任务，更不要改成LocalSystem或管理员账户。默认的ApplicationPoolIdentity本身就是低权限虚拟账户，适合大多数场景。如果站点需要写文件或访问特定目录，只给对应目录授予该应用池标识的修改权限，而不是给整个盘符或站点根目录完全控制。比如站点需要上传文件到D:\wwwroot\site1\uploads，就只对这个uploads目录给IIS AppPool\site1Pool授予修改权限，其他目录保持只读。

站点根目录的NTFS权限建议设置为：Administrators和SYSTEM完全控制，IIS AppPool\对应池只读和执行，其他用户无权限。不要在站点目录给Users或Everyone任何权限。

IIS默认会开启“目录浏览”，这在生产环境必须关闭，否则攻击者可以直接列出站点文件结构。在站点功能视图里打开“目录浏览”，点击“禁用”。同时检查“WebDAV创作规则”，如果不用WebDAV，直接在角色服务里卸载WebDAV发布模块。如果站点不需要在浏览器里显示详细错误信息，把“错误页”设置为“自定义错误页”并选择“详细错误”仅在本地显示，远程只返回通用错误，避免泄露物理路径和堆栈信息。

在“请求筛选”里，要限制URL长度、查询字符串长度和HTTP头大小。默认值可能过小，但也不建议完全放开。常见的做法是把允许的URL长度限制在2048字节以内，查询字符串限制在1024字节以内，同时拒绝包含双点号、分号、反斜杠等危险字符的请求。对于文件扩展名，只允许站点实际用到的类型，比如.aspx、.html、.css、.js、.jpg、.png、.webp等，其他扩展名全部拒绝。特别是.config、.asa、.bak、.old、.log、.sql这类敏感文件，必须在请求筛选中显式拒绝。

生产站点必须启用HTTPS，并且HTTP 80端口只做跳转或直接关闭。在IIS里安装有效的SSL证书后，站点绑定只保留443端口。如果必须保留80端口，在站点根目录的web.config里配置URL重写，把所有HTTP请求301重定向到HTTPS。不要使用自签名证书对外提供服务。

TLS协议版本要在系统层面控制。打开注册表，在HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols下，明确禁用SSL 2.0、SSL 3.0、TLS 1.0和TLS 1.1，只启用TLS 1.2和TLS 1.3。对于不支持TLS 1.2的旧客户端，直接拒绝连接，不要为了兼容性降低加密标准。同时检查IIS站点绑定的证书是否启用了HTTP/2，HTTP/2在TLS 1.2以上自动生效，可以提升传输效率。

IIS日志必须开启，并且字段要选全。在站点“日志”功能里，格式选W3C，字段至少包含日期、时间、客户端IP、用户名、方法、URI资源、URI查询、协议状态、协议子状态、用户代理、引用站点、耗时。日志目录不要放在默认的C:\inetpub\logs，建议放到独立的数据盘，并限制只有管理员和SYSTEM能访问。日志文件不要无限增长，按站点和日期分目录，保留至少90天，有条件可以接入集中日志平台。

光有日志不够，还要配置失败请求跟踪规则。在站点“失败请求跟踪”里，针对状态码400-599启用跟踪，设置跟踪文件数量上限和目录权限。当站点出现500错误或异常响应时，可以直接查看失败请求的详细管道日志，快速定位是哪个模块或代码出了问题。同时开启IIS的“请求监视”功能，在“工作进程”里可以看到当前请求的实时状态，发现异常长时间运行的请求可以手动终止。

IIS管理器默认通过本地控制台访问，如果必须远程管理，不要直接开放IIS管理服务到公网。使用Windows防火墙限制IIS管理端口（默认8172）只允许特定管理IP访问。更安全的做法是通过VPN或跳板机访问服务器内网，再连接IIS管理器。服务器上的远程桌面服务同样要限制来源IP，并修改默认3389端口。管理员账户必须启用双因素认证，至少也要使用强密码策略，禁止使用Administrator账户直接远程登录。

如果站点使用了FTP功能，FTP服务要单独配置隔离用户目录，禁用匿名访问，强制使用FTPS或SFTP。FTP账户密码不要与系统账户相同，并且FTP根目录不要指向站点根目录，避免通过FTP上传恶意脚本直接执行。

IIS层面的安全配置只能挡住一部分攻击，应用代码本身的漏洞才是最大的风险。对于ASP.NET站点，必须在web.config里设置customErrors模式为On或RemoteOnly，防止详细错误泄露。同时配置httpRuntime的requestValidationMode为4.5以上，启用请求验证，防止XSS和SQL注入的基础攻击。对于上传功能，必须在代码层校验文件类型、大小和内容，不能只依赖客户端校验。上传目录要设置为不可执行脚本，在IIS里对该目录的“处理程序映射”中移除所有脚本执行权限，只保留静态文件处理。

对于PHP站点，要在php.ini里禁用危险函数，比如exec、shell_exec、system、passthru、proc_open、popen、eval、assert等。关闭display_errors，开启log_errors，并设置错误日志路径。同时启用open_basedir限制PHP只能访问站点目录，防止跨站读取文件。PHP版本必须使用官方还在安全支持周期内的版本，过期的PHP版本存在大量已知漏洞。

Windows Server和IIS的补丁必须定期安装，不能因为怕重启就长期不打补丁。微软每月第二个周二发布安全更新，涉及IIS和HTTP.sys的漏洞往往危害极大，比如曾经的HTTP.sys远程代码执行漏洞和IIS短文件名枚举漏洞。建议在测试环境验证补丁后，生产环境在发布后一周内完成安装。对于无法立即打补丁的情况，要在防火墙或WAF层面做临时缓解规则。

除了系统补丁，站点使用的第三方组件也要持续关注安全公告。比如.NET Framework、ASP.NET Core运行时、PHP、MySQL、Redis等，只要是对外暴露的组件，都要纳入漏洞管理流程。可以使用漏洞扫描工具定期扫描站点，发现中高危漏洞及时修复。

安全运维不能只考虑防，还要考虑被攻破后如何快速恢复。IIS站点的备份要包含三个层面：站点文件、IIS配置、数据库。站点文件可以用Windows Server Backup或脚本定期复制到异地存储。IIS配置可以用appcmd命令导出，例如：

%windir%\system32\inetsrv\appcmd list site /config > D:\backup\sites.xml
%windir%\system32\inetsrv\appcmd list apppool /config > D:\backup\apppools.xml

数据库备份要根据实际使用的数据库类型制定计划，至少每天一次全量备份，并保留多份历史版本。备份文件要加密存储，并且不能放在站点可访问的目录下。

应急响应方面，要提前准备好检查清单：发现异常后先隔离服务器，保留内存镜像和日志副本，检查最近变更、计划任务、启动项、新增账户、异常进程、网络连接。IIS日志和系统事件日志是判断入侵路径的关键证据，不要直接删除或覆盖。如果确认被入侵，不要在原服务器上直接修复，应该用干净备份重建环境，再恢复数据。

建议每周做一次基础安全检查，每月做一次全面复查。检查项包括：IIS日志是否有大量404、500或异常请求；应用程序池是否频繁崩溃或回收；站点目录是否有新增的可疑文件；系统账户是否有新增或权限变更；防火墙规则是否有非授权修改；补丁是否全部安装；证书是否即将过期；备份是否成功执行。把这些检查项做成脚本或工单，避免遗漏。

IIS站点安全运维是一个持续的过程，不是一次性配置完就结束。攻击手段在不断变化，配置也要跟着调整。把基础加固做好，把监控和日志做全，把备份和应急做扎实，绝大多数攻击都能被挡住或在早期被发现。