Windows站点环境搭建中3个被忽略的安全断点

文章配图，仅供参考

　　但这不是最离谱的。你记不记得去年双十一前，我们灰度那批新机器，凌晨三点突然报502？当时运维小哥在工位上打电话谈房租，声音大得能盖过机箱嗡嗡响，我蹲在服务器前翻日志，翻到第三页才发现所有请求都卡在「Windows身份验证」那一步——原来那台机器的「本地安全策略」里，「网络访问: 本地账户的共享和安全模型」被默认设成了「仅来宾」，而我们的API网关用的是NTLM认证，这俩根本不兼容。后来回滚的时候，我发现灰度脚本里根本没覆盖这个配置项，合着之前测试环境能跑是因为测试机的策略是「经典」模式——这他妈也能过？

　　第三个断点更隐蔽。上个月我们接了个新需求，要在Windows站点上加个文件上传接口，前端传的是multipart/form-data，后端用HttpListener直接解析。测试的时候一切正常，可上线第一天就报「请求体过大」——我查了半天，发现是IIS的「requestFiltering」模块默认限制了请求体大小是30MB，而我们的需求文档里明确写了要支持50MB。更绝的是，这个限制在web.config里根本没显式配置，它是从machine.config继承的默认值——我原以为修改web.config就能覆盖，结果重启了三次IIS才发现，得在applicationHost.config里改「system.webServer/security/requestFiltering/requestLimits」的maxAllowedContentLength。这事儿最坑的是，本地开发环境用的是IIS Express，它的默认限制是4GB，所以测试的时候根本没暴露问题——你说这算不算「优胜劣汰」？环境越接近生产，坑越多，活下来的都是被坑过的。

　　说到这个，我想起上周咖啡机坏了，全组都靠外卖续命。那天我蹲在茶水间啃三明治，听前端小妹跟产品撕需求——产品非要在上传接口里加个「文件类型白名单」，前端说「后端已经做了校验，前端再写一遍是重复劳动」，产品说「用户可能绕过前端直接调接口」。我当时差点笑出声，心说你们争的这个「安全」，连IIS的requestFiltering都没配全，还扯什么前后端分离？后来我回工位翻了下代码，发现我们的白名单校验居然是用字符串.Contains()做的——用户传个「image.jpg.exe」就能绕过，这他妈比没校验还危险。

　　不过话说回来，这些断点之所以被忽略，说白了还是「惯性思维」在作怪。比如IIS的appPool回收，大家都默认用「基于内存」或「基于请求数」的触发条件，谁他妈会去改「固定时间间隔」？可我们的站点是凌晨处理定时任务，这时候突然回收appPool，正在跑的任务直接中断，脏数据就产生了。再比如Windows身份验证，开发环境用集成Windows认证，测试环境用匿名认证，生产环境用混合模式——每个环境的策略都不一样，可配置脚本里只写了「启用Windows认证」，没写具体模式，结果生产环境默认用了「仅NTLM」，而我们的域控又禁用了NTLMv1，最后导致部分老客户端连不上。这些细节，你不亲自踩一遍，根本不会注意。

　　还有那个文件大小限制，我查文档的时候发现，IIS 7.0之后，requestFiltering的配置优先级是这样的：machine.config > applicationHost.config > web.config。也就是说，就算你在web.config里写了maxAllowedContentLength="52428800"（50MB），如果applicationHost.config里没改，或者machine.config里有限制，最终生效的还是最小的那个值。这就像你给门装了三把锁，结果钥匙全在别人手里——更搞笑的是，IIS管理器里修改这个值，它会自动更新applicationHost.config，但通过PowerShell或web.config改，就不会。你说这设计是不是有病？

　　现在想想，这些断点之所以能存活这么久，可能是因为它们「不致命」——appPool回收导致任务中断，最多重跑一次；身份验证失败，用户换个浏览器就能解决；文件上传超限，前端弹个提示就行。可一旦遇到高并发或恶意攻击，这些小问题就会变成大漏洞。比如那个文件类型校验，如果用户传个「.jsp」文件，后端没校验扩展名，直接存到静态资源目录，服务器分分钟被挂马；再比如IIS的请求队列，如果默认的1024个请求被占满，新请求会直接返回503，可我们的监控只报超时，根本不报队列已满——等我们发现的时候，服务已经挂了十分钟。

　　所以我现在的结论是：Windows站点环境搭建，最危险的不是那些「显式配置」的东西，而是那些「默认值」和「隐式继承」的配置。就像你盖房子，地基里的钢筋少放了两根，表面看不出来，地震一来就塌了。下次再搭环境，我建议先跑一遍「IIS默认配置审计脚本」，把所有继承自父级的配置都列出来，逐个核对；再搞个「安全基线检查清单」，把身份验证、请求过滤、appPool回收这些关键项标红，强制要求测试环境必须和生产环境一致——哪怕测试环境用虚拟机，配置也得一模一样。当然，这说起来容易，做起来难——你看我们组现在，连咖啡机坏了都没人修，谁还有精力管这些「细节」？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!