IIS安全配置的核心结论是：通过最小化安装、及时补丁、权限收敛、请求过滤和强制HTTPS五步联动，绝大多数常见入侵路径都能被封死。
很多站长把IIS安全想复杂了，总觉得要装一堆安全设备才放心，IIS本身的安全基线并不难达到，关键是按顺序把每个环节做扎实，下面这套配置思路，来自多年Windows服务器运维经验的总结,每一步都能落到具体操作上。
IIS安全配置怎么做：先搞清楚攻击者是怎么进来的
要回答这个问题，得先站在攻击者的角度想事情，IIS服务器最常见的暴露面其实就三个：开放的端口、可执行的脚本权限、应用层的漏洞利用，你只要把这三个口子管住,服务器的安全等级就提升了大部分。
安装IIS时就要做减法
很多人在装IIS的时候，图省事直接勾选全部功能，这是最忌讳的，IIS的默认配置是给开发者调试用的,不是给生产环境用的。
安装时只保留必要的功能模块，具体操作路径：服务器管理器 → 添加角色和功能 → Web服务器（IIS）→ 角色服务,建议只勾选以下几项：
- 常见HTTP功能、默认文档、HTTP错误
- 健康与诊断：HTTP日志、请求监视
- 性能压缩
- 安全：请求筛选（这个必须装,后面配置隔离要用）
至于ASP.NET、CGI、FastCGI这些动态脚本模块，如果你用不到，一个都别装，凡是多装一个模块,就多一个被漏洞击穿的可能。
补丁管理是IIS加固的第一道防线
微软每个月第二个星期二发布安全更新，这个在业内叫Patch Tuesday，IIS和底层Windows操作系统的漏洞补丁，必须在发布后的两周内完成测试并部署到生产环境。
根据微软安全响应中心的历史数据，IIS相关的严重漏洞绝大多数都被纳入每月例行更新中，如果服务器长时间不打补丁，等于把家门钥匙挂在锁孔上，建议开启Windows自动更新，但要把重启时间设定在业务低峰期,例如凌晨两点到四点之间。
IIS短文件名漏洞修复方法及请求过滤规则
IIS短文件名漏洞，业内也叫8.3短名称泄露漏洞，是IIS最经典的隐患之一，攻击者利用通配符猜测网站目录下的短文件名，从而拿到服务器内部结构信息,为后续攻击做铺垫。
为什么这个漏洞一直修不干净
因为这个漏洞的根子不在IIS本身，而在Windows文件系统对短文件名的自动生成机制，即便你在IIS里把目录浏览关得死死的，只要硬盘上存在短文件名,攻击者依然可以通过特定的HTTP请求探测出来。
具体修复路径分两层
第一层：关闭短文件名生成。 以管理员身份打开命令提示符,执行以下命令：
fsutil behavior set disable8dot3 1执行完需要重启服务器生效，注意，这条命令只影响之后创建的文件和文件夹，已经生成的短文件名不会自动消失,所以还要做第二步。
第二层：用URL重写规则拦截探测请求。 在IIS里安装URL Rewrite模块，然后添加一条出站规则，把包含短文件名特征的请求直接返回404，具体操作：IIS管理器 → 选中站点 → URL重写 → 添加规则 → 请求阻止。
规则配置要点：
- 匹配条件设置为URL路径包含
~1之类的字符模式 - 动作类型选择中止请求
- HTTP状态码填404
这样就可以在IIS层面直接吞掉这些探测流量,同时不影响正常用户访问。
请求频率限制：被暴力破解前的外层刹车
2019年之后，针对IIS的暴力破解攻击呈现明显上升趋势，常见于wp-admin、后台登录页、.env文件探测等路径，别指望防火墙能挡下所有攻击,更有效的做法是在IIS的动态IP限制模块里做频率控制。
IIS安装好之后，默认没有动态IP限制功能，需要单独安装IIS Dynamic IP Restriction Extension组件，装完后在站点功能里找到IP地址和域限制,开启动态限制模板：
- 允许的最大并发请求数设为10
- 每分钟最大请求数设为300
- 超过阈值后封禁时间设为20分钟
这个配置适合大多数业务场景，既不会误伤正常用户,又能把快速遍历目录的攻击流量挡在外面。
网站被入侵后怎么排查：从IIS日志还原攻击路径
万一配置没做全，网站还是被入侵了，怎么快速定位问题？建议不要急着改代码，先看IIS日志，IIS的日志文件默认存放在C:inetpublogsLogFiles目录下，按站点ID分文件夹,打开就能看到每天的访问记录。
排查时优先看这三个特征：
- 同类URL反复出现：说明有人在扫你的目录结构，比如
/admin、/backup、/.git挨个试了一遍 - UserAgent字段异常：很多自动化攻击工具会留下特征，比如sqlmap、Nikto这些扫描器
- POST请求集中在单一页面：这通常是登录爆破，被攻击的页面大概率是后台入口或API接口
看完日志再用PowerShell查最近被修改的文件：
Get-ChildItem -Path C:inetpubwwwroot -Recurse | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-3)} | Sort-Object LastWriteTime -Descending
多数情况下，攻击者入侵后会在网站目录下留一个webshell文件，名字往往是随机字符串加asp/aspx后缀,查文件修改时间是定位webshell最快的手段。
IIS与Apache哪个更安全：别神话任何一个
这是很多人在选型时纠结的问题，我的观点是：没有绝对安全的Web服务器，只有配置到位的管理员。但随着网络安全等级保护制度在各行业的落地,IIS在Windows域环境里的安全天花板其实比很多人想象的高。
TLS加密配置是两者拉开差距的地方
IIS在Windows Server 2016以上版本对TLS 1.2和TLS 1.3的原生支持比Apache要省心，Apache经常要手动编译OpenSSL版本,而IIS只需要在注册表里关闭老版本协议即可。
行业共识认为，在相同硬件条件下，跑在Windows Server上的IIS配合Schannel，TLS握手性能优于Linux上Apache配合OpenSSL的组合,尤其适合高并发的小文件传输场景。
在IIS里强制HTTPS的操作路径：站点 → SSL设置 → 勾选”要求使用SSL” → 客户端证书选择”忽略”，然后把HTTP请求重定向到HTTPS，具体做法是在URL Rewrite里添加一条入站规则：
- 匹配条件：协议类型为HTTP
- 动作类型：重定向到HTTPS站点
- 重定向URL：
https://{HTTP_HOST}/{R:1}
TLS版本调整注意：不要直接禁用TLS 1.0，部分老用户还在用Windows 7和旧版浏览器，如果业务不敏感，可以把TLS 1.0设为可选而非禁用，如果要彻底禁，得先统计客户端兼容情况,再改注册表。
应用池隔离：IIS独有的纵深防御优势
IIS的应用池隔离机制，是Apache默认配置里没有的东西，每个站点跑在独立的应用池中，即使某个站点的代码被攻破，攻击者也只能拿到该应用池的权限，跨不到其他站点,这一特性特别适合虚拟主机商和服务器上跑了多套业务的用户。
配置要点：每个站点的应用池 → 高级设置 → 进程模型 → 标识，把默认的ApplicationPoolIdentity换成自定义的低权限账户，给这个账户只需要网站目录的读取权限,以及日志目录的写入权限即可。
IIS日志与基线核查：安全加固后的长跑
所有配置做完之后，把这份配置存档当作服务器的安全基线，以后每次改配置,都要对照基线做差异比对。
日志留存策略要合规
根据网络安全法第二十一条要求，网络运营者应当采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月，IIS详细日志的时间戳要打开UTC格式,默认的本地时间在跨时区分析的时候会产生偏差。
具体操作：选中网站 → 日志 → 字段选择，把Server Name、Server IP、Time Taken这些字段加上,修改后重载配置生效。
定期做一次自攻自检
防御IIS入侵最有效的手段之一，就是定期用扫描器模拟攻击，比如每周跑一次Nikto扫描自己的站点，看看有没有敏感目录暴露、SSL配置是否合格、报错页面是否泄露了IIS版本号，这一点很多企业忽略了,等收到漏洞报告才被动处理。
把IIS的Custom Errors功能打开，把所有500错误统一指向一个不含详细堆栈信息的页面，避免ASP.NET报错把物理路径和数据库连接串吐出来，生产环境不要开着Detailed Errors调试,这一条能防住很多信息泄露类漏洞。
IIS安全配置常见问题解答
IIS里配了HTTPS证书但浏览器还是提示不安全，怎么回事？
最常见的原因是服务器上还开着TLS 1.0或TLS 1.1，打开IIS管理器，双击站点下的SSL设置，确认勾选”要求使用SSL”，同时到注册表编辑器里把HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols下的TLS 1.0和1.1停用，改完重启服务器，再重新测试，浏览器提示不安全的另一个常见情况是证书链没装完整，中间证书没入库，只装了叶子证书,这个需要把CA下发的证书链全部导入到受信任的根证书颁发机构。
IIS返回403.14错误，目录列表被禁止但静态文件还是打不开，如何解决？
14的含义是目录中没有默认文档且目录浏览已关闭，如果在URL里明确输入了文件名仍然报403，大概率是IIS_USERS账户对物理目录的读取权限丢失，右键网站物理目录 → 属性 → 安全 → 编辑，添加IIS_IUSRS的读取和执行权限，并且不要勾选”包括可从该对象的父项继承的权限”之外的多余选项，另外检查站点对应的应用程序池是否已启动,停止状态的应用池同样会返回类似错误。